Cockpit domain controller and vehicle

Abstract

The present application provides a cockpit domain controller. The controller comprises an SoC and an MCU; the MCU is provided with two SPI communication channels, two CAN communication channels, a PWM channel, an I2C channel, multiple temperature ADC acquisition channels, multiple voltage monitoring and acquisition channels, and multiple GPIO control channels; the MCU is connected to the SoC by means of the two SPI communication channels and one GPIO control channel; two CAN buses are each provided with a PDCM, a PDCF, an IBC, an EPS, and a VDC; the PWM channel is provided with a fan controller; one ADC channel is connected to a voltage monitoring channel, and another ADC channel is connected to a temperature measurement channel; the I2C channel is provided with a memory, a backup loudspeaker, and a real-time clock chip. The cockpit domain controller of the present application can provide real-time and secure data interaction between the SoC and other controllers.

Description

Cabin domain controller and vehicle TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle control, in particular to a cabin domain controller and a vehicle. BACKGROUND

[0002] Traditional MCU (Micro Controller Unit) applications of automobiles are generally designed in the form of independent controllers, communicate with other controllers for information transmission through CAN (Controller Area Network) communication, and design corresponding sensing units and control units according to control needs. If the traditional independent controller design is adopted in a cabin domain controller, additional hardware interfaces need to be added for external communication, and the core SoC (System on Chip) chip of the cabin domain controller cannot be cooperatively communicated.

[0003] SUMMARY

[0004] The present application aims to provide a cabin domain controller capable of solving at least one of the above technical problems. The specific scheme is as follows:

[0005] According to the specific embodiment of the present application, in a first aspect, the present application provides a cabin domain controller, comprising:

[0006] a SoC and an MCU;

[0007] The MCU is equipped with two-way SPI (Serial Peripheral Interface) communication, two-way CAN communication, one-way PWM (Pulse Width Modulation), one-way I2C (Inter-Integrated Circuit) bus, multi-way temperature ADC (Analogue to Digital Converter) acquisition, multi-way voltage monitoring acquisition, and multi-way GPIO control;

[0008] MCU controls the connection with SoC through two-way SPI communication and one-way GPIO (General Purpose Input Output) control. Two-way CAN bus is mounted with PDCM (Powertrain Domain Control Module), PDCF (Powertrain Domain Control Function), IBC (Integrated Brake Control), EPS (Electric Power Steering), VDC (Vehicle Domain Controller), one-way PWM is mounted with fan control, one-way ADC is connected with voltage monitoring, another way of ADC is connected with temperature detection, one-way I2C is mounted with memory, backup audio and real-time clock chip.

[0009] Optionally, in the two-way SPI communication, one-way SPI is responsible for forwarding non-functionally safe related CAN signals and interactive control commands to SoC;

[0010] Another way of SPI forwards functionally safe signals transmitted on CAN bus with E2E (End-to-End) verification to the safety domain of SoC.

[0011] Optionally, MCU is based on CP AUTOSAR (AUTomotive Open System ARchitecture) software architecture design, uses CAN protocol stack, can ensure the reception of CAN data, then forwards CAN signals to Android applications through independent SPI channel, key signals can be transmitted to applications in real time, and control signals can be quickly issued from applications to CAN bus.

[0012] Optionally, P1 path is used for transmitting functionally safe signals, E2E technology is used to receive data on CAN bus, and functionally safe related signals are forwarded to the safety domain of SOC side through independent SPI channel.

[0013] Optionally, two CAN channels, one channel realizes CAN communication interaction with other ECUs;

[0014] Another channel provides backup diagnosis capability for domain controller, SoC uses its Ethernet communication capability to realize the diagnosis of SoC through deployment of DoIP (Diagnostic communication over Internet Protocol).

[0015] Optionally, a CP AUTOSAR-based diagnostic service module is deployed on the MCU side, and a DoIP-based diagnostic service module is deployed on the QNX side.

[0016] Optionally, when DoIP or SoC runs abnormally, the diagnostic capability is lost, and backup diagnosis is implemented through the CAN of the MCU.

[0017] Optionally, when SoC software upgrade is abnormal and the SoC as a whole cannot implement software self-upgrade, the SoC is put into an upgrade mode through the CAN diagnostic interface of the MCU and in cooperation with hardware design, so as to realize the upgrade recovery of the SoC software.

[0018] Optionally, the main path for displaying the TT (Telltale, alarm prompt) icon corresponding to the functional safety signal is to receive the functional safety signal with E2E check in the CAN communication, receive the SPI channel for transmitting the functional safety signal, deliver the signal to the instrument application in the safety domain of the SoC side, and after logical judgment, send the icon to the instrument through the stringer connected to the instrument for icon display.

[0019] The backup path is directly communicated with the stringer by the MCU, and after receiving the CAN signal, the icon is sent to the instrument. The instrument can check the icons sent through the two paths to ensure that the TT icon is displayed correctly. When there is inconsistency, the TT icon sent by the MCU is directly adopted.

[0020] Optionally, the transmission of the functional safety signal is realized by means of an independent SPI channel, and the main warning sound is realized by deploying the AudiSrv service on the QNX side. After receiving the alarm signal on the CAN bus or Ethernet, the warning sound is played through the near-end power amplifier directly connected to the A2B (Automotive Audio Bus, vehicle audio bus) bus and the far-end power amplifier externally connected through the CAN bus. The AudMgr software module is deployed on the MCU to monitor the near-end power amplifier fault state sent by the QNX and the fault state sent by the far-end power amplifier controller AMP.

[0021] When the power amplifier has a problem, the backup power amplifier connected to the I2S bus of the MCU plays the preset warning sound in the MCU.

[0022] Optionally, a key power supply module design control path is designed to realize the orderly control of the power-on sequence and power-off of each module of the domain controller by means of the fast characteristics of the MCU, and to realize flexible remote hibernation and wake-up control in combination with CAN network management.

[0023] Optionally, a monitoring path is designed for each key power supply module, and the power output thereof is connected back to the MCU, and real-time monitoring of the power supply is realized through the GPIO or ADC of the MCU. The GPIO of the MCU can realize the judgment of the abnormality of the power supply of the whole vehicle, and the ADC of the MCU can realize the monitoring of the overvoltage and undervoltage of the power supply. When overvoltage or undervoltage occurs, the MCU sends abnormal information to the SOC through the SPI path for timely control, thereby ensuring the safety of the whole domain controller.

[0024] In addition, in combination with the diagnostic protocol, the abnormal points are stored as DTC (Diagnostic Trouble Code), and the diagnostic instrument can quickly diagnose the problem points through DoIP or CAN.

[0025] Optionally, according to the function of the domain controller, the voltage is divided into primary voltage control and monitoring, and an intelligent MOSFET is used in combination with an IC with reverse protection function to realize voltage monitoring. In this part, the power supply is first powered by the MCU through the method of voltage division and current limiting, and after the MCU software runs, the intelligent MOSFET is controlled to be turned on to support the power supply of larger loads, and the voltage output is checked back by using the ADC to perform closed-loop diagnosis.

[0026] Optionally, the secondary power supply is controlled by the MCU.

[0027] Firstly, the MCU controls the power supply of the MCU related peripheral circuit, including the power supply of the CAN transceiver and the backup power amplifier, to realize the rapid establishment of CAN communication with other ECUs.

[0028] Secondly, the MCU controls the power supply of the SoC to make the SoC core chip run, and the MCU uses the DI to synchronize the diagnosis of the power conversion chip state and uses the ADC to synchronize the monitoring of the power supply voltage of the SoC.

[0029] Thirdly, the MCU controls the PMIC in the SoC to realize the power supply of the functions controlled by the PMCI, and the MCU simultaneously checks back the PMIC state to realize the diagnosis of the PMIC state.

[0030] Fourthly, after the SoC power supply is stabilized, the MCU controls the power supply of the external devices of the SoC, including the USB, Ethernet, Bluetooth, central control screen, instrument screen, power amplifier and other external devices. The MCU also uses the DI and ADC to diagnose and monitor the power conversion chip state and the power supply output of the Bluetooth power supply, the central control chip power supply, the instrument power supply and the power amplifier power supply.

[0031] Optionally, the main heat dissipation points in the domain controller include a 12V power supply input part, a SoC system part, a high-speed memory UFS (Universal Flash Storage) used by the SoC, Bluetooth and WIFI modules for external communication, an audio amplifier part, and a camera power supply part. NTC (Negative Temperature Coefficient) is arranged in these high heat dissipation points, and the temperature of these heat dissipation points is collected by connecting the sampling points to the ADC of the MCU.

[0032] Optionally, the main power supply circuit, the camera, the Bluetooth, the UFS, and the SoC itself have high power consumption and generate a large amount of heat during operation. To ensure the safe operation, the MCU is designed to monitor the operating temperature. Temperature monitoring points are designed near the corresponding power supply modules in the hardware design, and NTC is used to monitor the temperature during operation.

[0033] Optionally, NTC_MOSFET measures the temperature of the primary power supply circuit, NTC_UFS measures the temperature of the memory UFS, NTC_SoC measures the temperature of the SoC, and NTC_BTWLAN measures the temperature of the Bluetooth and WIFI power supply. In addition, the SoC itself has a CPU temperature measurement. The MCU monitors multiple temperature points and, according to the thermal management strategy, controls the cooling fan to dissipate heat when the temperature is too high. When the temperature exceeds the protection value, the MCU sends temperature abnormal information to the software module deployed in the SoC through SPI, notifies each application module to close the screen, Bluetooth, WIFI, and camera, and issues an alarm prompt.

[0034] Optionally, the MCU controls the path of the fan through PWM. The thermal management software module in the MCU combines the collected temperature to start the fan to dissipate heat when the temperature is too high. In combination with the structure of the domain controller, the effective thermal management of the domain controller is finally achieved.

[0035] Optionally, an EEPROM (Electrically Erasable Programmable Read Only Memory) is designed for the domain controller to provide storage support for the EOL and mileage storage in the domain controller, and also provides backup storage support for the DTC of the domain controller.

[0036] According to the specific embodiments of the present application, in a second aspect, the present application also provides a vehicle including the cockpit domain controller according to the foregoing.

[0037] Compared with the prior art, the above-mentioned scheme of the embodiments of the present application has at least the following beneficial effects:

[0038] The application provides real-time and safe data interaction of the SoC and other controllers by equipping the MCU in the cabin domain controller with multiple different communication interfaces, that is, the MCU is respectively equipped with two-way SPI communication, two-way CAN communication, one-way PWM, one-way I2C, multiple temperature ADC acquisition, multiple voltage monitoring acquisition, and multiple GPIO control. BRIEF DESCRIPTION OF DRAWINGS

[0039] FIG. 1 shows a hardware function block diagram of the cabin controller provided by the first embodiment of the application;

[0040] FIG. 2 shows a principle diagram of signal shunt processing design provided by the second embodiment of the application;

[0041] FIG. 3 shows a principle diagram of warning sound and backup design provided by the third embodiment of the application;

[0042] FIG. 4 shows a principle diagram of power management and power monitoring design provided by the fourth embodiment of the application. DETAILED DESCRIPTION

[0043] In order to make the objects, technical solutions and advantages of the application clearer, the following will further describe the application in detail with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the application, but not all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the application.

[0044] The terms used in the embodiments of the application are only for the purpose of describing the specific embodiments, and are not intended to limit the application. The singular forms "a", "an" and "the" used in the embodiments of the application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. "Multiple" generally includes at least two.

[0045] It should be understood that the term "and / or" used herein is only to describe the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in this paper generally represents that the front and rear associated objects are a "or" relationship.

[0046] It should be understood that although the terms first, second, third, etc. may be used in the embodiments of the application, these descriptions should not be limited to these terms. These terms are only used to distinguish the description. For example, without departing from the scope of the embodiments of the application, the first can also be called the second, and similarly, the second can also be called the first.

[0047] Depending on the context, the word "if' can be interpreted to mean "when" or "upon" or "in response to determining" or "in response to detecting." Similarly, the phrase "if determined" or "if detected (a stated condition or event)" can be interpreted to mean "upon determining" or "in response to determining" or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)," depending on the context.

[0048] It is also important to note that the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a product or article of manufacture that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such product or article of manufacture. An element proceeded by "comprises... a" does not, without more constraints, exclude the existence of additional identical elements in the product or article of manufacture that comprises the recited element.

[0049] It is specifically noted that symbols and / or numbers present in the description, if not marked in the description of the figures, are not figure references.

[0050] Traditional car MCU application, generally as an independent controller form design, using CAN communication with other controllers for information transmission, according to the control needs of the design of the corresponding sensor unit and control unit, in the cabin domain controller if according to the traditional independent controller design, need to increase the additional hardware interface, at the same time also can't with the core SoC chip of cabin domain controller for collaborative communication; Modern SoC of the cabin is mainly responsible for the display and audio-visual system control in the cabin, multi-screen driver, sensor data collection and processing, external Ethernet, Bluetooth, WIFI communication, based on Android to realize man-machine interaction, the cabin SoC to realize access to traditional ECU CAN communication, to achieve real-time safe and stable control, need to help MCU has the advantage, that is, to realize the stable MCU chip that meets the functional safety requirements, can achieve ms level real-time stable communication CAN communication; In order to make the whole cabin domain controller can meet the functional safety, the separate SoC chip and the operating system used can't reach, need to meet the functional safety requirements of MCU to support the implementation of functional safety signal link; With the integration of more and more functions of the cabin domain controller, the normal power supply tree of the system is more and more complex, in order to ensure the stability of the system, the power supply input to the cabin domain controller needs to be monitored, and the power supply of SoC and each connected peripheral needs to be monitored, for example, the power supply of SoC PMIC needs to be monitored, the power supply of serializer chip used for transmitting video signal with instrument needs to be monitored, and necessary protection measures are taken when power supply is abnormal; In order to drive multiple screen display, support multiple wireless communication, and meet the operation requirements of SoC itself, the power consumption of cabin domain controller is high, in order to ensure the operation of each chip in the normal temperature range, the temperature of the key heat point in the controller needs to be monitored, and the thermal management system designed by the controller is used to implement thermal management; The SoC of the cabin domain controller uses Linux system to realize the design of man-machine interaction with Android, and UFS is used for storage. Due to the system upgrade design, the information in the UFS will be erased due to upgrade. The information that needs to be stored in the domain controller (such as EOL) can't be stored. The EEPROM in MCU can well solve the problem of persistent storage, and the demand for high frequency erasing, such as the mileage of the vehicle, which generally requires to store 100 times per 1Km, to achieve 1 million km storage requirement.

[0051] Modern cockpit domain controller generally adopts the architecture of SoC plus MCU, the SoC is responsible for display, audio-visual control, multi-screen driving, wireless communication of external multi-form, data management, human-computer interaction, and the MCU is responsible for CAN bus communication conversion, safety monitoring, thermal management control and power management. The application introduces a design of cockpit MCU, solves the real-time and safe CAN data interaction of SoC and other controllers, monitors the power supply of SoC, establishes a good temperature environment for the operation of SoC through thermal management, provides the ability of domain controller sleep and remote wake-up through supporting CAN bus network management, and ensures the compliance of the entire domain controller with functional safety requirements by means of the stable advantages of MCU.

[0052] First embodiment

[0053] Fig. 1 exemplarily shows a hardware function block diagram of the cockpit controller provided by the embodiment. Referring to Fig. 1, the application designs two CAN channels by means of MCU, one channel realizes CAN communication interaction with other ECUs, solving the problem of 10ms level signal transmission. The other channel provides flexible calibration and backup diagnosis capability for the domain controller, and the SoC realizes diagnosis of the SoC by deploying DoIP through the Ethernet communication capability, but when the DoIP or the SoC runs abnormally, the diagnosis capability will be lost, at this time, the backup diagnosis is realized through the CAN of MCU, which can provide support for diagnosing the hardware and running problems of the domain controller, and one important application is that when the SoC software upgrade appears abnormal and the SoC as a whole cannot realize software self-upgrade, the SoC enters a special upgrade mode through the CAN diagnosis interface of MCU and the hardware design, realizing the upgrade recovery of the SoC software.

[0054] The application designs the MCU and the SoC on the same hardware PCB, and the MCU and the SoC are designed with two-way SPI communication, one-way SPI is responsible for forwarding the CAN signals and interaction control commands irrelevant to functional safety to the SoC, establishing the CAN communication capability of the SoC, and also closely cooperating with the SoC to transfer internal information; the other way of SPI forwards the functional safety signals with E2E check on the CAN bus to the safety domain of the SoC, establishing the ability of the SoC to receive and send functional safety signals, and also decoupling the paths of non-functional safety and functional safety signals, reducing the design complexity of the lower functional safety related software modules.

[0055] The application is a multi-channel path of TT (Telltale) icon design of functional safety signal on the instrument, realizing backup verification of the TT icon, the main path of the corresponding TT icon display of the functional safety signal is that the functional safety signal with E2E verification in the CAN communication is received, the SPI channel transmitting the functional safety signal is received, the signal is transmitted to the instrument application of the SoC side safety domain, after logical judgment, the signal is transmitted to the instrument through the connection of the instrument's adder for icon display; the backup path is that the MCU directly communicates with the adder, after receiving the CAN signal, the signal is transmitted to the instrument, the instrument can verify the icons transmitted through the two paths, ensuring that the TT icon display is correct, when there is inconsistency, the TT icon transmitted by the MCU is directly adopted, through the above-mentioned multi-channel functional safety signal path design, the display of the high functional safety level icon is met.

[0056] The application is a backup sound alarm path designed for the domain controller, ensuring that when the main sound alarm of the SoC appears abnormal, the functional safety alarm sound is realized through the backup alarm sound path. The main alarm sound path of the cabin domain controller is through the power amplifier of the whole vehicle, when the power amplifier of the whole vehicle fails, the MCU is designed to monitor the fault state of the power amplifier, when the fault is identified, the backup speaker connected to the MCU is played, ensuring that the key boost sound can be played.

[0057] The application is a reliable control path designed for the key power supply module of the domain controller, realizing the orderly control of the power-on timing and power-off of each module of the domain controller by means of the fast characteristics of the MCU, and realizing flexible remote hibernation and wake-up control by combining CAN network management, providing flexible power management capability for the domain controller.

[0058] The application is a monitoring path designed for the key power supply module of the domain controller, connecting the feedback of the power supply output to the MCU, realizing real-time monitoring of the power supply through the GPIO or ADC of the MCU, realizing the judgment of the whole vehicle abnormality of the power supply through the GPIO of the MCU, realizing the monitoring of the overvoltage and undervoltage of the power supply through the ADC of the MCU, when the overvoltage and undervoltage appear, the abnormal information is transmitted to the SOC through the SPI path for timely control, such as closing the screen, closing the sound, closing the Bluetooth or WIFI and the like wireless communication, ensuring the safety of the whole domain controller; in addition, the abnormal points are stored as DTCs by combining the diagnostic protocol, the problem points are quickly diagnosed by using the diagnostic instrument through DoIP or CAN.

[0059] The application is temperature monitoring and fan control path designed for main heat points in a domain controller. Through thermal simulation, main heat dissipation points in the domain controller include a 12V power supply input part, a SoC system part, a high-speed memory UFS used by the SoC, a Bluetooth and WIFI module for external communication, an audio amplifier part, and a camera power supply part. NTC is arranged at these high heat points, temperature collection of the heat points is realized by connecting sampling points to the ADC of the MCU, and the MCU controls the fan path through PWM. The thermal management software module in the MCU combines the collected temperature, starts the fan when high temperature occurs, and dissipates heat from the heat points. In combination with the structure heat dissipation design of the domain controller, effective thermal management of the domain controller is finally realized. At the same time, based on temperature monitoring of different points, over-temperature information is sent to the SoC, and the SoC can flexibly control to turn off the corresponding function, thereby ensuring the safe operation of the system.

[0060] The application is long-life EEPROM designed for the persistent storage of the domain controller, which provides storage support for EOL and mileage storage in the domain controller, and also provides backup storage support for the DTC of the domain controller.

[0061] The main functions of the cockpit domain controller hardware include camera video data collection and processing, central control screen display and interaction, instrument display, audio data playback, data storage management, external USB drive interface, external Bluetooth and WIFI communication, external Ethernet communication, external CAN signal communication. The MCU is mainly responsible for external CAN communication and CAN network management, power management of the domain controller, voltage monitoring, temperature monitoring, fan control, and persistent data storage.

[0062] As shown in FIG. 1, the MCU is designed with two-way SPI communication, two-way CAN communication, one-way PWM, one-way I2C mounted memory / backup audio / real-time clock chip, multi-way temperature ADC collection, multi-way voltage monitoring collection, and multi-way GPIO control.

[0063] The embodiment adopts the architecture design of MCU plus SoC, and simultaneously provides two-way SPI communication between the MCU and the SoC, and two-way CAN communication with other modules, thereby providing real-time and safe data interaction between the SoC and other controllers.

[0064] Meanwhile, the embodiment also provides a variety of services such as safety monitoring of the SoC, TT icon display, CAN communication and CAN network management, power management, voltage monitoring, thermal management control, temperature monitoring, fan control, and persistent data storage, thereby enriching the application scenarios of the cockpit domain controller.

[0065] Second embodiment

[0066] Figure 2 illustrates the schematic diagram of the signal shunt processing design. Referring to Figure 2, through the design of two-way SPI and two-way CAN communication, both the conventional control signal and the functional safety signal shunt processing are realized. As shown in Figure 2, one of the two-way SPI is the conventional CAN signal. Based on the CP AUTOSAR software architecture design, the mature CAN protocol stack is used to ensure the reliable reception of CAN data, and then the CAN signal is forwarded to the Android application through the independent SPI channel. The key signal can be transmitted to the application in real time, and the control signal can also be quickly issued from the application to the CAN bus. The P1 path is used to transmit the functional safety signal. The E2E technology is used to receive data on the CAN bus, and the functional safety related signal is forwarded to the safety domain (QNX) on the SOC side through the independent SPI channel. Then, the signal is sent to the instrument application through the functional safety processing service program for processing and sent to the instrument. The independent path can reduce the complexity of the development of the functional safety related software module, and exclude the influence of the non-functional safety software module. The functional safety signal is also transmitted through another path, that is, the P2 path, to the TT module deployed in the MCU. After the TT module is processed independently, the signal is sent to the instrument through the second I2C channel of the instrument interface chip. The instrument has a built-in verification program. When the icons of the P1 path and the P2 path are inconsistent, the icon of the P2 path is displayed as the reference. Through the icon information provided by the two paths, it is ensured that the display of the functional safety signal corresponding icon meets the functional safety ASIL B requirement.

[0067] The diagnostic service module (Diag) based on CP AUTOSAR is deployed on the MCU side, and the diagnostic service module (DM) based on DoIP is deployed on the QNX. The normal diagnostic path is through DoIP. When the DoIP path fails, the diagnostic function is realized through the backup diagnostic path on the MCU side. At the same time, through the CAN channel diagnostic path on the MCU side, support is provided for the SoC to enter the bare machine program (or the SoC program upgrade exception). Through the CAN diagnostic service, the configuration Soc is started to enter the qFile mode, and the software upgrade is ensured when the SoC program cannot run in the case of death.

[0068] In this embodiment, the conventional control signal and the functional safety signal are shunted, which effectively reduces the development complexity of the functional safety related software module and excludes the influence of the non-functional safety software module.

[0069] Third Embodiment

[0070] Figure 3 shows the schematic diagram of the warning sound and backup design. Referring to Figure 3, the playing of the warning sound (Chime) in the cockpit domain controller and the display of the TT signal provide the driver with various warning prompts, the transmission of the functional safety signal is realized by means of an independent SPI channel, the main warning sound is realized by deploying the AudiSrv service on the QNX side, after receiving the alarm signal on the CAN bus or Ethernet, the warning sound is played through the near-end power amplifier directly connected to the A2B bus and the remote power amplifier externally connected through the CAN bus, the MCU deploys the AudMgr software module, monitors the near-end power amplifier failure state sent by QNX and the failure state sent by the remote power amplifier controller AMP, when the power amplifier has a problem, the backup power amplifier connected to the I2S bus of the MCU plays the warning sound preset in the MCU, ensuring that the key warning prompt sound can be played.

[0071] The embodiment adopts backup design for the warning sound to be played, ensuring that the key warning prompt sound can still be normally played when the power amplifier has a problem.

[0072] Fourth embodiment

[0073] Figure 4 illustrates the schematic diagram of the power management and power monitoring design. Referring to Figure 4, there are many external devices in the cabin domain controller, and the voltage system for power supply is also different. The reliable and stable power supply of each device is the key to the reliable operation of the cabin domain controller. To ensure that each functional module can be powered on in order, the MCU controls the power supply to be powered on in a certain order, and the key power modules are read back and monitored, and the state of the key power conversion chip is monitored. As shown in Figure 4, according to the function of the domain controller, the voltage is divided into primary voltage control and monitoring, and an intelligent MOSFET is used to realize the voltage monitoring and reverse protection function of the IC. This part of the power supply is first powered on through voltage division and current limiting to supply power to the MCU. After the MCU software runs, the intelligent MOSFET is turned on to support the power supply of larger loads (the path of UBat->Uin in Figure 4), and the voltage output is checked and controlled by the ADC to perform closed-loop diagnosis. The secondary power supply is mainly controlled by the MCU. First, the MCU controls the power supply of the MCU related peripheral circuit (PeriPwr part in the figure), including the power supply of the CAN transceiver and the backup power amplifier, to realize the rapid establishment of CAN communication with other ECUs. Second, the MCU controls the power supply of the SoC (SoCPwr in the figure) to allow the SoC core chip to run. The MCU uses DI to synchronize the diagnosis of the power conversion chip state and uses ADC to synchronize the monitoring of the power supply voltage to the SoC. Third, the MCU controls the power supply of the PMIC in the SoC to realize the power supply of the functions controlled by the PMCI. The MCU also checks the PMIC state to diagnose the PMIC state. Fourth, after the SoC power supply is stable, the MCU controls the power supply of the external devices of the SoC, including USB (USBPwr in the figure) / Ethernet (EthernetPwr in the figure) / Bluetooth (BtPwr in the figure) / center control screen strip (IVIPwr in the figure) / instrument screen strip (IcPwr in the figure) / power amplifier (AmpPwr in the figure) / other peripherals (SoCPeriPwr). The MCU diagnoses and monitors the power conversion chip state and power output of the Bluetooth power supply / center control strip power supply / instrument power supply / power amplifier power supply and other peripherals using DI and ADC.

[0074] The power consumption of the main power supply circuit, the camera, Bluetooth, UFS and SoC itself in the cockpit domain controller is high, and a large amount of heat is generated during operation. In order to ensure the safe operation, the MCU monitors the operating temperature. The temperature monitoring points are designed near the corresponding power supply modules in the hardware design, and NTC is used to monitor the temperature during operation. As shown in FIG. 4, NTC_MOSFET measures the temperature of the first power supply circuit, NTC_UFS measures the temperature of the memory UFS, NTC_SoC measures the temperature of the SoC, and NTC_BTWLAN measures the temperature of the Bluetooth and WIFI power supply. At the same time, the CPU temperature inside the SoC itself is also measured. The MCU monitors multiple temperature points, and according to the thermal management strategy, when the temperature is too high, the MCU controls the cooling fan through PWM to cool the domain controller. When the temperature exceeds the protection value, the MCU sends the temperature abnormal information to the software module (pmSrv) deployed in the SoC through SPI, notifies each application module to close the screen / Bluetooth WIFI / camera, and issues an alarm prompt.

[0075] The embodiment realizes effective power supply monitoring of each module through two-stage power supply monitoring management. At the same time, the embodiment also provides temperature monitoring of key points and corresponding fan cooling control.

[0076] Finally, it should be noted that: each embodiment in the specification is described in a progressive manner, and each embodiment focuses on the difference from other embodiments. The same or similar parts of each embodiment can be referred to. For the system or device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant part can be referred to the method part.

[0077] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A cockpit domain controller, characterized in that, Comprise: System on Chip (SoC) and Micro Control Unit (MCU); The MCU is equipped with two-way Serial Peripheral Interface (SPI) communication, two-way Controller Area Network (CAN) communication, one-way Pulse Width Modulation (PWM), one-way Integrated Circuit Bus (I2C), multi-way Temperature Analog-to-Digital Converter (ADC) acquisition, multi-way voltage monitoring acquisition, and multi-way General Purpose Input / Output (GPIO) control; The MCU is connected with the SoC through two-way SPI communication and one-way GPIO control, two-way CAN bus is mounted with Power Domain Control Module (PDCM), Power Domain Control Function (PDCF), Integrated Brake Control System (IBC), Electric Power Steering (EPS), and Vehicle Domain Controller (VDC), one-way PWM is mounted with fan control, one-way ADC is connected with voltage monitoring, and the other way ADC is connected with temperature detection, one-way I2C is mounted with memory, backup audio, and real-time clock chip.

2. The cabin domain controller of claim 1, wherein, In the two-way SPI communication, one-way SPI is responsible for forwarding non-functionally safe related CAN signals and interactive control commands to the SoC; The other way SPI forwards the functionally safe signals transmitted on the CAN bus with E2E inspection to the safety domain of the SoC.

3. The cabin domain controller of claim 2, wherein, The MCU is based on CP AUTOSAR software architecture design and uses CAN protocol stack to ensure the reception of CAN data, and then forwards the CAN signals to Android applications through independent SPI channels, and the key signals can be transmitted to the applications in real time, and the control signals can be quickly issued from the applications to the CAN bus.

4. The cabin domain controller of claim 2, wherein, P1 path is used to transmit functionally safe signals, and E2E technology is used to receive data on the CAN bus, and the functionally safe related signals are forwarded to the safety domain of the SOC side through independent SPI channels.

5. The cockpit domain controller of claim 1, wherein, Two CAN channels, one channel realizes CAN communication interaction with other ECUs; The other channel provides backup diagnosis capability for the domain controller, and the SoC realizes diagnosis of the SoC through deployment of DoIP with the help of its Ethernet communication capability.

6. The cabin domain controller of claim 5, wherein, The diagnosis service module based on CP AUTOSAR is deployed on the MCU side, and the diagnosis service module based on DoIP is deployed on QNX.

7. The cabin domain controller of claim 6, wherein, When DoIP or SoC runs abnormally, the diagnosis capability will be lost, at which time backup diagnosis is realized through the CAN of the MCU.

8. The cabin domain controller of claim 7, wherein, When the SoC software upgrade appears abnormal and the SoC as a whole cannot realize software self-upgrade, the SoC is put into upgrade mode through the CAN diagnosis interface of the MCU and the hardware design to realize software upgrade recovery of the SoC.

9. The cockpit domain controller of claim 1, wherein, The main path of the corresponding TT icon display is that the functionally safe signals with E2E check in the CAN communication are received, the SPI channel transmitting the functionally safe signals is received, the signals are transmitted to the instrument application of the SoC side safety domain, after logical judgment, the signals are sent to the instrument through the stringer connected with the instrument for icon display; The backup path is directly communicated with the stringer by the MCU, after receiving the CAN signal, the signal is sent to the instrument, the instrument can check the icons sent by the two paths to ensure that the TT icon display is correct, when there is inconsistency, the TT icon sent by the MCU is directly adopted.

10. The cockpit domain controller of claim 1, wherein, The transmission of function safety signal is realized by independent SPI channel, the main warning sound is realized by AudiSrv service deployed on QNX side, after receiving the alarm signal on CAN bus or Ethernet, the warning sound is played through the near-end power amplifier directly connected to A2B bus and the far-end power amplifier externally connected through CAN bus, MCU deploys AudMgr software module to monitor the near-end power amplifier fault state sent by QNX and the fault state sent by the far-end power amplifier controller AMP; When the power amplifier has a problem, the backup power amplifier connected to the I2S bus of MCU plays the preset warning sound in MCU.

11. The cockpit domain controller of claim 1, wherein, The key power supply module design control path, with the help of MCU start fast characteristics, realizes the orderly control of the power-on sequence and power-off of each module of the domain controller, and realizes flexible remote sleep and wake-up control combined with CAN network management.

12. The cabin domain controller of claim 11, wherein, The key power supply module design monitoring path is connected to the feedback of the power supply output to the MCU, and the real-time monitoring of the power supply is realized through the GPIO or ADC of the MCU, the abnormal judgment of the power supply of the whole vehicle is realized through the GPIO of the MCU, the overvoltage and undervoltage of the power supply are monitored through the ADC of the MCU, when overvoltage and undervoltage occur, the abnormal information is sent to SOC through SPI path for timely control to ensure the safety of the whole domain controller. In addition, combined with the diagnosis protocol, the abnormal point is stored as DTC, and the problem point can be quickly diagnosed by using the diagnostic instrument through DoIP or CAN.

13. The cabin domain controller of claim 12, wherein, According to the function of the domain controller, the voltage is divided into primary voltage control and monitoring, which is realized by intelligent MOSFET and IC with reverse protection function of voltage monitoring machine. The first step of this part of power supply is to supply power to MCU through voltage division and current limiting, and after the MCU software runs, the intelligent MOSFET is turned on to support the power supply of larger load, and the voltage output is checked and controlled by ADC to execute closed-loop diagnosis.

14. The cabin domain controller of claim 12, wherein, The second power supply is controlled by MCU; First, MCU controls the power supply of MCU related peripheral circuit, including CAN transceiver power supply, backup power amplifier power supply, to realize the rapid establishment of CAN communication with other ECUs; Second, MCU controls the power supply of SoC to make SoC core chip run, MCU uses DI to synchronize the diagnosis of power supply conversion chip state and uses ADC to synchronize the monitoring of SoC power supply voltage; Third, MCU controls the power supply of PMIC in SoC to realize the power supply of the functions controlled by PMCI, and MCU checks the PMIC state to realize the diagnosis of PMIC state; Fourth, after the stable power supply of SoC, MCU controls the power supply of external devices of SoC, including USB / Ethernet / Bluetooth / center screen strip / instrument screen strip / power amplifier / other external devices, MCU also uses DI and ADC to diagnose and monitor the power supply conversion chip state and power supply output of Bluetooth power supply / center control strip power supply / instrument power supply / power amplifier power supply.

15. The cockpit domain controller of claim 1, wherein, The main heat dissipation points in the domain controller are the 12V power supply input part, the SoC system part, the high-speed memory UFS used by the SoC, the Bluetooth and WIFI modules for external communication, the audio amplifier part, and the camera power supply part. NTC is used to layout these high heat points, and the temperature of these heat points is collected by connecting the sampling points to the ADC of the MCU.

16. The cabin domain controller of claim 15, wherein, The main power supply circuit, camera, Bluetooth, UFS, and SoC itself have high power consumption and generate a lot of heat during operation. To ensure the safety of operation, the MCU monitors the operating temperature. Temperature monitoring points are designed near the corresponding power supply modules in the hardware design, and NTC is used to monitor the temperature during operation.

17. The cabin domain controller of claim 16, wherein, NTC_MOSFET measures the temperature of the primary power supply circuit, NTC_UFS measures the temperature of the memory UFS, NTC_SoC measures the temperature of the SoC, and NTC_BTWLAN measures the temperature of the Bluetooth and WIFI power supply. The SoC itself also has CPU temperature measurement. The MCU monitors multiple temperature points and, according to the thermal management strategy, turns on the cooling fan to cool the domain controller when the temperature exceeds the alarm value. When the temperature exceeds the protection value, the MCU sends temperature abnormal information to the software module deployed in the SoC through SPI, notifies each application module to close the screen, Bluetooth, WIFI, and camera, and issues an alarm prompt.

18. The cabin domain controller of claim 15, wherein, In addition, the MCU controls the path of the fan through PWM. The thermal management software module in the MCU combines the collected temperature to start the fan to cool the heat points when the temperature is high. Combined with the structure of the domain controller, the MCU finally realizes effective thermal management of the domain controller.

19. The cockpit domain controller of claim 1, wherein, EEPROM is designed for the domain controller to store EOL and mileage storage, and also provides backup storage support for the DTC of the domain controller.

20. A vehicle characterized by The application includes: The cockpit domain controller according to any one of claims 1 to 19.

Images