Intelligent driving domain controller maintenance system and method for vehicle

Abstract

The invention relates to an intelligent driving domain controller maintenance system and method for a vehicle. The system comprises a first system-on-chip, a micro-control unit and a second system-on-chip. The micro-control unit is used for cooperating with the first system-on-chip to execute an intelligent driving function of the vehicle; the second system-on-chip is connected with the first system-on-chip and the micro-control unit; wherein the second system-on-chip is configured to be in wireless connection with external debugging equipment of the intelligent driving domain controller so as to execute online operation on the first system-on-chip and the micro-control unit in a wireless mode, and the online operation comprises at least one of online debugging, log obtaining and software damage recovery operation. Therefore, the debugging and maintenance efficiency, flexibility and reliability of the intelligent driving domain controller can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of vehicle control, and in particular to a vehicle intelligent driving domain controller maintenance system and method, a storage medium, a controller, a vehicle and a computer program product. BACKGROUND

[0002] At present, the intelligent driving domain controller of a vehicle relies on a dedicated debugging device for maintenance, and needs to be connected to the debugging device in a wired manner and perform relevant maintenance operations offline.

[0003] However, wired connection makes the debugging device wiring complex, and the offline maintenance function is limited, which cannot accurately obtain the log file of the intelligent driving domain controller, nor can it perform remote debugging and fault repair functions. Therefore, the efficiency, flexibility and reliability of the existing debugging and maintenance of the intelligent driving control domain are poor. SUMMARY

[0004] The embodiments of the present application provide a vehicle intelligent driving domain controller maintenance system, which improves the efficiency, flexibility and reliability of the debugging and maintenance of the intelligent driving control domain to at least partially solve the above technical problems.

[0005] In order to achieve the above-mentioned purpose, according to the first aspect of the present application, a vehicle intelligent driving domain controller maintenance system is provided, comprising:

[0006] a first system on chip, a micro control unit and a second system on chip;

[0007] The micro control unit is configured to cooperate with the first system on chip to perform intelligent driving functions of the vehicle;

[0008] The second system on chip is connected with the first system on chip and the micro control unit;

[0009] The second system on chip is configured to be wirelessly connected with an external debugging device of the intelligent driving domain controller, so as to perform online operations on the first system on chip and the micro control unit, the online operations including at least one of online debugging, log acquisition and software damage recovery operations.

[0010] Optionally, the second system on chip is connected with the first system on chip and the micro control unit through a debugging interface, and the debugging interface includes at least one of UART, CAN, SPI and USB.

[0011] Optionally, the second system on chip is further connected with the first system on chip and the micro control unit through Ethernet.

[0012] Optionally, the second system chip and the first system chip, the micro control unit are commonly integrated in any one circuit board in the intelligent driving domain controller.

[0013] Optionally, the second system chip is connected to the central circuit board of the intelligent driving domain controller as an independent module through an interface.

[0014] Optionally, the system further comprises:

[0015] a security chip connected to the second system chip, configured to store authentication information of the second system chip;

[0016] a mobile hotspot module connected to the second system chip, configured to establish remote access authority to the second system chip.

[0017] According to a second aspect of the present application, a method for maintaining an intelligent driving domain controller of a vehicle is also provided, applied to the intelligent driving domain controller maintenance system of the vehicle as described above, the system comprising a first system chip, a second system chip and a micro control unit connected to each other, and the method comprising:

[0018] wirelessly connecting the second system chip to an external debugging device of the intelligent driving domain controller to perform online operations on the first system chip and the micro control unit in a wireless manner, the online operations including at least one of online debugging, log acquisition and software damage recovery operations.

[0019] Optionally, performing online operations on the first system chip and the micro control unit in a wireless manner comprises:

[0020] receiving an access request for the second system chip;

[0021] verifying access authority of an access party according to the access request;

[0022] in response to the access authority of the access party being verified, performing a first debugging operation on the first system chip and a second debugging operation on the micro control unit;

[0023] wherein the first debugging operation comprises at least one of state monitoring, restarting and modifying running parameters of the first system chip, and the second debugging operation comprises state monitoring and / or fault information diagnosis of the micro control unit.

[0024] Optionally, performing online operations on the first system chip and the micro control unit in a wireless manner comprises:

[0025] monitoring a first log file actively output by the first system-level chip and the micro control unit in real time, and adding a timestamp to the first log file and saving the first log file;

[0026] acquiring a second log file stored by the first system-level chip, and adding a timestamp to the second log file and saving the second log file;

[0027] The first log file is a log file that cannot be saved by the intelligent driving domain controller, and the second log file is a log file discarded by the first system-level chip.

[0028] Optionally, the first system-level chip and the micro control unit are executed online through a wireless manner, including:

[0029] When the first system-level chip cannot be started, a recovery request is sent to the second system-level chip;

[0030] In response to verification of the authority information of the requester being passed, an OTA upgrade package of the first system-level chip and the micro control unit is acquired;

[0031] The first system-level chip is executed through a debugging interface for underlying flashing, and software information in the OTA upgrade package is written into the first system-level chip after being upgraded and repaired;

[0032] The micro control unit is executed through a communication bus for OTA upgrade to a version matched with the first system-level chip.

[0033] Optionally, the underlying flashing bypasses a starting flow and a partition mechanism of the first system-level chip, and the repaired software information is written into the first system-level chip through an underlying firmware recovery manner.

[0034] According to a third aspect of the present application, a computer readable storage medium is provided, and a computer program is stored in the computer readable storage medium. The computer program is executed by a processor to implement the steps of the method.

[0035] According to a fourth aspect of the present application, a controller is provided, and a computer program is stored in the controller. The computer program is executed by a processor to implement the steps of the method.

[0036] According to a fifth aspect of the present application, a vehicle is provided, and the vehicle includes the controller.

[0037] According to a sixth aspect of the present application, a computer program product is provided, and the computer program product includes a computer program or instructions. The computer program or instructions are executed by a processor to implement the steps of the method.

[0038] In summary, the system of the embodiment of the present application can include a first system-level chip, a micro-control unit, and a second system-level chip; the micro-control unit is configured to perform intelligent driving functions of a vehicle in cooperation with the first system-level chip; the second system-level chip is connected with the first system-level chip and the micro-control unit; wherein the second system-level chip is configured to be wirelessly connected with an external debugging device of the intelligent driving controller, to perform online operations on the first system-level chip and the micro-control unit in a wireless manner, the online operations including at least one of online debugging, log acquisition, and software damage recovery operations. Thus, the present application does not need to rely on a wired connection to access the debugging device in the intelligent driving control domain, and the debugging personnel can use a wireless connection to access the external debugging device to the second system-level chip, and subsequently remotely access the second system-level chip to implement online debugging, log acquisition, and software damage recovery operations on the first system-level chip and the micro-control unit of the intelligent driving controller, thereby improving the efficiency, flexibility, and reliability of maintaining the intelligent driving controller. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0040] In order to more completely understand the present application and its beneficial effects, the following will be described in conjunction with the drawings, wherein the same reference numerals in the following description represent the same parts.

[0041] Figure 1 is an architecture diagram of an existing intelligent driving controller;

[0042] Figure 2 is an architecture diagram of an intelligent driving controller maintenance system of a vehicle provided by the present disclosure;

[0043] Figure 3 is a flowchart of debugging the intelligent driving controller provided by the present disclosure;

[0044] Figure 4 is a schematic diagram of log file processing of the intelligent driving controller provided by the present disclosure;

[0045] Figure 5 is a flowchart of software damage repair of the intelligent driving controller provided by the present disclosure;

[0046] Figure 6 is an architecture diagram of a controller provided by the present disclosure;

[0047] Figure 7 1 is an architectural diagram of a vehicle exemplarily provided by the present disclosure. DETAILED DESCRIPTION

[0048] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0049] Based on the problems mentioned in the above background technology, in the relevant technology, the debugging and upgrading of the existing intelligent driving domain controller mainly rely on wired connection methods, and require the use of Ethernet debugging boxes, CAN analyzers and other special debugging equipment for physical access.

[0050] During debugging, if Figure 1 As shown, developers need to access system status and log information through limited debugging interfaces (such as UART and CAN). Wired debugging relies on complex peripherals and physical connections, has limited functionality, and struggles to support remote collaboration. Furthermore, the limitations of the debugging interface result in incomplete access to underlying information. The logging system cannot preserve critical data over the long term, especially in the event of a system crash, which can lead to a lack of effective evidence for fault analysis. Traditional OTA upgrades require the involvement of the system-on-chip (SoC). If the SoC is completely damaged and "bricked," it cannot be restored remotely, forcing the vehicle to be returned to the factory for repair. This not only increases user time and costs, but also makes it difficult to trace the problem due to lost logs.

[0051] In order to solve the above problems, this application provides a vehicle intelligent driving domain controller maintenance system, such as Figure 2 As shown, the system may include a first system-on-chip, a microcontroller unit, and a second system-on-chip.

[0052] The first system-level chip in the intelligent driving control domain, referred to as the intelligent driving SoC or first SoC, is the main control core of the intelligent driving domain controller, integrating functions such as computing processing, algorithm execution, perception fusion, path planning, and system control. In actual applications, the main functions of the first system-level chip may include carrying the autonomous driving algorithm and operating system, controlling the data processing and fusion of sensors such as cameras, radars, GPS, and IMUs, coordinating task scheduling of the vehicle control execution layer (such as steering, acceleration and deceleration), and performing OTA upgrades, logging, CAN / Ethernet communications, and other functions (under normal operating conditions).

[0053] The micro control unit of the intelligent driving domain control system is referred to as an intelligent driving MCU (Microcontroller Unit), which is an auxiliary controller and is responsible for system-level device control, low-speed communication management, safety task processing, etc. The micro control unit can be used to cooperate with the first system-level chip to perform the intelligent driving function of the vehicle. In actual application, the main functions of the micro control unit can include controlling the low-power devices on the vehicle (such as relays, motors, IO control, etc.), executing high real-time and low-power sub-tasks in the intelligent driving system (such as lamp control, power management, etc.), serving as a slave module of the first system-level chip to complete specific control logic, provide hardware state monitoring, and provide a diagnostic data upload interface (such as a CAN bus), etc.

[0054] The second system-level chip can be referred to as a debugging SoC or a second SoC, which is an auxiliary control chip newly added and is used for debugging access, log management, software recovery, OTA relay, etc. It is the core of system diagnosis and maintenance.

[0055] In some embodiments, the second system-level chip can be connected with the first system-level chip and the micro control unit. The second system-level chip can be configured to be wirelessly connected with an external debugging device of the intelligent driving domain controller to perform online operations on the first system-level chip and the micro control unit in a wireless manner. The online operations can include at least one of online debugging, log acquisition, and software damage recovery operations.

[0056] Specifically, the user can connect the external debugging device to the intelligent driving domain controller, and remotely access the second system-level chip through WiFi based on the debugging device. The second system-level chip connects the debugging port (such as UART, CAN, etc.) of the first system-level chip and the MCU through an internal wired interface, realizes remote debugging, state control, parameter modification, etc. of the intelligent driving system, and can be used for function diagnosis and problem troubleshooting in system running or abnormal state.

[0057] The second system-level chip can actively or passively acquire the running logs generated by the first system-level chip and the MCU, support local saving, timestamp unification, remote query and download of log information, can be used for long-span problem tracking, fault recovery and system state monitoring, and supports unified management of multiple log sources (such as CAN, Ethernet, UART, etc.).

[0058] When the software of the first system-level chip is damaged and cannot be started (such as “brick”), the second system-level chip can take over the upgrade process. The user remotely issues an OTA upgrade instruction and an upgrade package, and the second system-level chip performs empty board upgrade or recovery flashing through a bottom interface (such as USB, GPIO, CAN), can independently repair the software of the first system-level chip and the MCU, and improves the system stability and emergency response capability.

[0059] In summary, the second system-level chip of the present application provides a unified, secure and efficient remote maintenance portal through wireless means, and can perform at least one online operation on the master chip and micro control unit in the system, which is the core of realizing the remote debugging and maintenance capability of the intelligent driving domain control system.

[0060] It should be noted that for specific details of performing online operations on the first system-level chip and micro control unit of the intelligent driving control domain through the second system-level chip, please refer to the description of the intelligent driving domain controller maintenance method of the vehicle in the following.

[0061] In some embodiments, the second system-level chip can be connected with the first system-level chip and the micro control unit through a debugging interface. As shown in Figure 2 The debugging interface can include at least one of UART, CAN, SPI, and USB.

[0062] It can be understood that the second system-level chip of the present application is compatible with wired and wireless connection modes for communication with the first system-level chip and the micro control unit, for performing online debugging, log collection, system recovery and other operations.

[0063] Among them, UART refers to Universal Asynchronous Receiver / Transmitter, which is suitable for serial communication and is commonly used for basic log output and command interaction. The second system-level chip can read chip startup information, exception logs or send debugging commands through UART.

[0064] Among them, CAN refers to Controller Area Network, which is used for communication with MCU, performing diagnostic queries, OTA upgrades and other operations, and is suitable for control command interaction and real-time data acquisition in vehicle systems.

[0065] Among them, SPI refers to Serial Peripheral Interface, which is used for high-speed, synchronous data exchange and can be used for low-level interaction tasks such as reading internal status and data flow monitoring.

[0066] Among them, USB refers to Universal Serial Bus, which is used for image writing during blank board upgrade or "brick" recovery of the first system-level chip. It is usually used in conjunction with GPIO (General Purpose Input / Output) to control the chip flashing process.

[0067] In some embodiments, as Figure 2As shown, the second system-level chip can also be connected with the first system-level chip and the micro control unit through Ethernet. Specifically, the second system-level chip can directly access an Ethernet switch connected with the first system-level chip through Ethernet, and remote access to the first system-level chip and the MCU can be realized. When the system is normally started, the second system-level chip can perform SSH remote login, system monitoring, parameter modification and other operations through Ethernet.

[0068] It can be understood that, compared with a serial port type interface (such as UART), Ethernet has higher transmission bandwidth, is suitable for transmission of large amounts of running log files, system images, diagnostic data and the like, and improves log collection efficiency and timeliness.

[0069] In the present application, the Ethernet connection supports online debugging and OTA software upgrade operation of the first system-level chip, and the second system-level chip can issue a debugging instruction or push an OTA package to the first system-level chip through Ethernet in a system running state. When the first system-level chip runs abnormally, the second system-level chip can still access its underlying service or flashing interface through the Ethernet interface, and remote recovery and maintenance of a completely damaged "brick" state system can be realized.

[0070] In summary, the second system-level chip of the present application connects the first system-level chip and the micro control unit through Ethernet, and can have stronger data transmission capability and remote debugging efficiency in terms of function implementation, which is an important path for the present scheme to realize high-reliability and high-bandwidth communication support. Complementary to the debugging interface (such as UART, CAN), the debugging flexibility, log integrity and remote maintenance capability of the system are further improved.

[0071] In some embodiments, the second system-level chip can be integrated with the first system-level chip and the micro control unit in any one circuit board in the intelligent driving domain controller.

[0072] Specifically, the three can be physically on the same hardware platform by being integrated on the same PCB circuit board. The second system-level chip can be directly mounted on the main PCB board of the intelligent driving domain controller, and form a unified hardware structure with the first system-level chip and the MCU. High-speed and wired connection between all chips is completed through wiring in the PCB, which improves signal integrity and system response speed.

[0073] On the same circuit board, the second system-level chip can be conveniently connected to the debugging interface (such as UART, CAN, SPI, USB, etc.) of the first system-level chip and the MCU, without additional jumper wires or external connectors, reducing overall wiring complexity and enhancing electromagnetic compatibility (EMC) design flexibility.

[0074] Through this integration mode, it is suitable for vehicle models with comprehensive functions and high requirements for debugging and maintenance or development stage products. In the early stage of software development or production line stage, the second system chip and its interface can be completely pasted to realize efficient debugging, flashing and diagnosis.

[0075] In addition, the application also supports the configuration of not pasting (default) the second system chip. When the product enters mass production or the software matures, the second system chip can be selected not to be soldered, thereby reducing the cost. Even if the second system chip is not enabled, the first system chip and the MCU can still run independently, without affecting the normal function.

[0076] In summary, by integrating the second system chip, the first system chip and the MCU together on the same PCB, the present application is one of the important ways to realize system compactness, wiring optimization and function integration. This integration mode improves the system stability, facilitates factory production and subsequent maintenance, and also provides flexible space for software and hardware decoupling and cost optimization.

[0077] In some embodiments, the second system chip can also be connected to the center circuit board of the intelligent driving domain controller as an independent module through an interface.

[0078] Specifically, the second system chip can be packaged as an independent small board module, with standard communication and power supply interfaces such as UART, CAN, USB, SPI, Ethernet, etc. The module can be connected to the domain control main PCB through pins, connectors or board-to-board interfaces without being fixedly pasted on the mainboard. It can be reused in multiple vehicle models or platforms, and different projects only need to reserve uniform interfaces on the mainboard without repeated development. The module can be installed during the debugging stage (such as R&D, production line testing), and can be removed after the product matures, reducing the cost. The universal module can be mass-produced, improving production capacity and further reducing unit price.

[0079] In summary, the present application designs the second system chip as a pluggable independent module connected to the domain control mainboard through an interface, which improves platform adaptability and maintenance flexibility, and provides convenience for hardware trimming and cost optimization.

[0080] In some embodiments, the system can also include a security chip and a mobile hotspot module.

[0081] Specifically, the security chip can be connected with the second system chip for storing authentication information of the second system chip, for example, the authentication information can include user certificates, public keys / private keys, encryption keys and other sensitive data. The security chip can provide access control and identity verification functions to ensure that only legitimate users can access the first system chip and the MCU through the second system chip, prevent unauthorized debugging or data theft, and improve the overall security and protection capability of the system.

[0082] The mobile hotspot module can also be a WiFi module, which can be connected with the second system-level chip, used to establish remote access permission of an external debugging device accessing the second system-level chip of the intelligent driving domain controller, provide wireless communication capability, and be used to establish remote connection between the user terminal (i.e. any debugging device) and the second system-level chip. After the user connects the module through WiFi, the second system-level chip can be remotely accessed to perform debugging, log acquisition or software recovery and the like. The mobile hotspot module supports establishing a debugging channel through a wireless manner in a closed state of the domain control shell, without disassembly or wiring, and cooperates with the security chip to realize safe, convenient and isolated remote debugging access permission management.

[0083] In summary, the security chip of the present application guarantees access legality and data security, the mobile hotspot module realizes remote wireless connection and access to the second system-level chip, and the two work cooperatively with the second system-level chip to build a safe, efficient and wiring-free intelligent debugging and maintenance system, which is the core supporting component for realizing wireless remote debugging of the present application.

[0084] The present application provides a vehicle intelligent driving domain controller maintenance method, please refer to Figure 3 The vehicle intelligent driving domain controller maintenance method provided by the embodiments of the present application is applied to the vehicle intelligent driving domain controller maintenance system as above, the system includes a first system-level chip, a second system-level chip and a micro control unit connected with each other, and the method includes the following steps.

[0085] Wirelessly connecting the second system-level chip with an external debugging device of the intelligent driving domain controller to perform online operation on the first system-level chip and the micro control unit through a wireless manner.

[0086] The online operation includes at least one of online debugging, log acquisition and software damage recovery operation. In some embodiments, the step S101 can include the following steps about online debugging:

[0087] Step S201, receiving an access request for the second system-level chip;

[0088] Step S202, verifying access permission of an access party according to the access request;

[0089] Step S203, in response to the access permission of the access party being verified, performing a first debugging operation on the first system-level chip and a second debugging operation on the micro control unit.

[0090] The first debugging operation includes at least one of state monitoring, restart and modification of running parameters of the first system-level chip, and the second debugging operation includes state monitoring and / or fault information diagnosis of the micro control unit.

[0091] Specifically, when the domain controller system is started, a user can initiate an access request to the second system-level chip through a WiFi or other wireless communication method based on an external debugging device accessing the smart driving domain controller, to establish a remote debugging connection. The purpose of the access request is to indirectly access and debug the first system-level chip and the micro control unit (MCU) through the second system-level chip. The user can access the second system-level chip and create a debugging session through a terminal device (such as a personal computer or a development workstation) based on a local area network or a remote cloud platform.

[0092] After receiving the access request, the second system-level chip calls the security chip connected thereto to verify the identity of the access party. The security chip stores authentication information related to the user, including certificates, public keys, or keys, etc. Only when the user identity authentication is passed, the system allows the execution of subsequent debugging operations, to ensure the legality of the visitor and prevent unauthorized access, and to ensure the security of system operation.

[0093] On the premise of passing the verification, the user can access the debugging interface of the first system-level chip and the MCU through the second system-level chip, and execute debugging commands. The second system-level chip plays a role of communication bridging and instruction intermediation in the process.

[0094] Specifically, in the process of the first debugging operation performed on the first system-level chip, the second system-level chip can obtain the running state information of the first system-level chip through an Ethernet or UART communication interface, including but not limited to CPU usage, memory occupation, disk remaining space, current running process, etc. In addition, the user can remotely send control commands, such as restart instructions, debugging mode enablement, log level adjustment, etc., to realize system control and parameter configuration of the first system-level chip, so as to achieve the purpose of dynamic optimization.

[0095] In the process of the second debugging operation performed on the micro control unit, the user can read the running state, control state, and sensor return data collected by the MCU through the second system-level chip, and access and analyze the diagnostic information reported by the MCU, such as fault codes, error logs, etc., through CAN, UART, or Ethernet communication, to realize accurate positioning and analysis processing of control abnormality, communication failure, and other problems.

[0096] Through the above manner, the user can realize remote access to the second system-level chip through a wireless network (such as WiFi) without physical connection, and logs in the system based on the SSH protocol for debugging. Once the connection is established, the user can not only monitor the running state of the first system-level chip in real time, obtain the running log of the first system-level chip and the MCU, but also can perform fine debugging operations including state switching and parameter adjustment, thereby guaranteeing the efficiency and accuracy of the debugging work. Since part of the debugging interface is not introduced through the wire harness IO in the traditional domain control structure, the method can provide more underlying information access capability, and provide an important supplement for system problem analysis.

[0097] In addition, thanks to the high-bandwidth communication capability of the Ethernet and the software deployment interface on the second system-level chip, the debugging method has the characteristics of simple operation and friendly interface, and even non-professional developers can complete the basic debugging task. At the same time, the method supports access and operation of the domain control system through a remote cloud, and the user does not need to carry a traditional Ethernet debugging box, a CAN tool and other special hardware devices, thereby significantly reducing the debugging cost and operation threshold.

[0098] In summary, the wireless online debugging method provided by the present application is superior to the traditional domain control system debugging scheme in terms of information acquisition integrity, remote access capability, security authentication mechanism and use convenience, and has a wide application prospect and promotion value.

[0099] In some embodiments, as shown in Figure 4 The step S101 can include the following steps about log processing:

[0100] The step S301 comprises: monitoring the first log file actively output by the first system-level chip and the micro control unit in real time, and adding a time stamp to the first log file and saving the first log file;

[0101] The step S302 comprises: obtaining the second log file stored by the first system-level chip, and adding a time stamp to the second log file and saving the second log file;

[0102] The first log file is a log file that cannot be saved by the intelligent driving domain controller, and the second log file is a log file discarded by the first system-level chip.

[0103] Specifically, after the domain controller is started, the second system-level chip can monitor the log information actively output by the first system-level chip and the micro control unit through various communication interfaces, such as but not limited to Ethernet, CAN, UART, etc. The above log information cannot be effectively recorded in the original system due to not passing through the file system cache or due to the limitation of the traditional domain control interface resources, and belongs to the first log file. The second system-level chip adds a time stamp to the log information and saves it locally for subsequent analysis and calling.

[0104] The second system chip can also actively access the internal file system of the first system chip to obtain log information generated by the first system chip but covered or discarded due to limited storage space, to form a second log file. These log files cannot be retained in the first system chip for a long time and are prone to loss due to insufficient partition design or power-off risk. The second system chip can also timestamp the extracted log and locally archive it.

[0105] In this way, the storage of log files not only enhances the integrity and traceability of logs, but also realizes a long-time span, multi-source, and unified management log storage mechanism that traditional domain control systems do not have, significantly improving the maintainability and fault analysis efficiency of the system.

[0106] In some embodiments, as shown in FIG. 1A, the step S101 can include the following steps about software damage recovery operation: Figure 5

[0107] Step S401, when the first system chip cannot be started, sending an upgrade recovery request to the second system chip;

[0108] Step S402, in response to the verification of the authority information of the requester being passed, obtaining the OTA upgrade package of the first system chip and the micro control unit;

[0109] Step S403, performing underlying flashing on the first system chip through the debugging interface, and writing the software information upgraded and repaired in the OTA upgrade package into the first system chip;

[0110] Step S404, performing OTA upgrade on the micro control unit through the communication bus to a version matching the first system chip.

[0111] Specifically, first, when it is detected that the first system chip cannot be normally started due to software failure, the user sends an upgrade recovery request to the second system chip through a wireless way (such as WiFi) to start the software recovery process.

[0112] Subsequently, after the second system chip receives the upgrade request, it calls the security chip connected thereto to verify the authority information of the requester, including authentication of user certificates, public keys, or access keys. Only when the authentication is passed, the second system chip can continue to perform subsequent operations, thereby ensuring the legality and security of the system recovery process.

[0113] ​Under the premise that the permission check passes, the second system-level chip requests a user side to obtain a software upgrade package for recovery, and the upgrade package includes an OTA image file applicable to the first system-level chip and a micro control unit (MCU). The user side transmits the OTA upgrade package to the second system-level chip after confirmation.

[0114] Then, the second system-level chip performs a bottom-layer flashing operation on the first system-level chip through a preset debugging interface (such as a USB and a GPIO), regardless of whether the first system-level chip is currently in a normal running state or a "brick" state. The operation directly writes repair software information in the OTA upgrade package into the first system-level chip, to realize system recovery and restart.

[0115] Meanwhile, the second system-level chip performs an OTA upgrade operation on the micro control unit through a communication bus (for example, a CAN bus), to update a software version of the micro control unit to a target version matched with the first system-level chip, to ensure correct cooperation of system functions.

[0116] In summary, the present application can independently complete a complete recovery process from remote instruction receiving, permission verification, upgrade package obtaining to bottom-layer software flashing when the first system-level chip cannot start or an OTA function is unavailable, to significantly improve self-recovery capability of the system in a serious software failure scenario. Compared with a traditional OTA upgrade path, the recovery method does not depend on a running state of the first system-level chip, can still perform a recovery task when the system is "bricked", and has higher applicability, safety and stability.

[0117] In some embodiments, the bottom-layer flashing can bypass a first system-level chip starting process and a partition mechanism, to write repaired software information into the first system-level chip in a bottom-layer firmware recovery manner.

[0118] Specifically, the first system-level chip is usually preset with a starting boot area (Boot ROM), and can enter a bottom-layer firmware flashing state under a specific starting condition (such as a GPIO configured as a flashing mode). The second system-level chip can trigger the chip to enter a bottom-layer flashing mode through a flashing interface (such as a USB and a GPIO) connected with the first system-level chip, to realize communication handshake with the Boot ROM level of the chip.

[0119] In the mode, the second system-level chip can directly write repair software images contained in the OTA upgrade package into a specified firmware area of a storage medium (such as a Flash or an eMMC) of the first system-level chip, bypassing an original operating system and a partition management mechanism of the first system-level chip. The flashing process does not need to depend on a normal starting state of the first system-level chip, and is also not constrained by a file system or a partition structure of the first system-level chip.

[0120] By the above mode, the application can independently complete system recovery when the first system-level chip is in an unstartable state or the OTA mechanism is invalid; can skip the original Bootloader and file system loading process, and realize system reconstruction from the bottom layer; supports partition reconstruction, Bootloader rewriting, system full image recovery and other operations, and has more comprehensive recovery capabilities; in cooperation with the security chip module of the second system-level chip, the authority verification and data protection of the flashing operation can be realized, and the safety and reliability of the operation process are ensured.

[0121] In summary, the bottom-layer flashing mechanism provided by the application significantly improves the recovery capability of the intelligent driving domain controller in the case of system abnormality, can ensure that the device still has the ability to quickly recover and run even in a serious failure scenario, and has strong practicality and promotional value.

[0122] Figure 6 is a block diagram of a controller 500 according to an exemplary embodiment, which can be the first system-level chip or the second system-level chip of the application. As shown in the figure, the controller 500 can include a processor 501, a memory 502. The controller 500 can also include one or more of a multimedia component 503, an input / output (I / O) component 504, and a communication component 505. Figure 6

[0123] ​The processor 501 is configured to control overall operations of the controller 500 to complete all or part of the steps in the above method. The memory 502 is configured to store various types of data to support the operations of the controller 500, which can include, for example, instructions for any application or method operating on the controller 500, and application-related data, such as contact data, transmitted and received messages, pictures, audio, video, and the like. The memory 502 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic storage, a flash memory, a magnetic disk, or an optical disk. The multimedia component 503 can include a screen and an audio component. The screen can be, for example, a touch screen, and the audio component is configured to output and / or input audio signals. For example, the audio component can include a microphone configured to receive external audio signals. The received audio signals can be further stored in the memory 502 or transmitted through the communication component 505. The audio component also includes at least one speaker configured to output audio signals. The I / O component 504 provides an interface between the processor 501 and other interface modules, which can be a keyboard, a mouse, a button, and the like. The buttons can be virtual buttons or physical buttons. The communication component 505 is configured to perform wired or wireless communication between the controller 500 and other devices. The wireless communication, such as WiFi, Bluetooth, near field communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, and the like, or a combination of one or more of them, is not limited herein. Therefore, the corresponding communication component 505 can include a WiFi module, a Bluetooth module, an NFC module, and the like.

[0124] In an example embodiment, the controller 500 can be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the methods described above.

[0125] In another example embodiment, a computer-readable storage medium including program instructions that, when executed by a controller, implement the steps of the methods described above is also provided. For example, the computer-readable storage medium can be the memory 502 described above including program instructions executable by the processor 501 of the controller 500 to complete each step included in the methods described above.

[0126] Figure 7 is a block diagram of a vehicle provided in an embodiment of the present application, as shown in the figure, the vehicle 600 includes the controller 500 described above. Figure 7

[0127] The embodiments of the present application also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, and the computer program causes a computer to execute part or all of the steps of any one of the audio processing methods described in the method embodiments above.

[0128] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all expressed as a combination of a series of actions, but those skilled in the art should know that the present application is not limited to the order of the actions described, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily necessary for the present application.

[0129] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0130] ​In several embodiments provided in the present application, it should be understood that the disclosed hardware can be implemented in other manners. For example, the above-described hardware embodiments are merely illustrative, and the division of the units can be different, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, hardware or software, which can be electrically or other forms.

[0131] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they can be located in one place or distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0132] In addition, the functional units in each embodiment of the application can be integrated into a processing unit, or each unit can be physically present alone, or two or more units can be integrated into one unit. The integrated unit can be realized in the form of hardware or in the form of a software program module.

[0133] The integrated unit, if implemented in the form of a software program module and sold or used as an independent product, can be stored in a computer readable storage unit. Based on this understanding, the technical solutions of the present application essentially or the part of the prior art that contributes to the technical solutions or the whole or part of the technical solutions can be embodied in the form of a software product, which is stored in a storage unit and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage unit includes: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0134] Those of ordinary skill in the art can understand that all or part of the steps of the various methods of the above embodiments can be completed by a program instructing relevant hardware, and the program can be stored in a computer readable storage unit, which can include a flash disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, etc.

[0135] The preferred embodiments of the present application are described in detail above with reference to the drawings, but the present application is not limited to the specific details of the above-described embodiments, and various simple modifications can be made to the technical solutions of the present application within the scope of the technical concept of the present application, and these simple modifications all belong to the protection scope of the present application.

[0136] In addition, it should be noted that each specific technical feature described in the above specific embodiments can be combined in any appropriate manner without contradiction, and in order to avoid unnecessary repetition, various possible combinations are not described again in the present application.

[0137] In addition, any combination can be made between various different embodiments of the present application, as long as it does not deviate from the idea of the present application, and it should also be considered as disclosed in the present application.

[0138] In the description of the present application, the terms "first", "second" are only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more features. In the description of the present application, the meaning of "multiple" is two or more, unless otherwise specifically limited.

[0139] In the above embodiments, the description of each embodiment is focused on, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0140] The embodiments, embodiments and related technical features of the present application can be combined, replaced with each other without conflict.

[0141] The above is only the preferred embodiment of the present application, and does not limit the present application in any form, but any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present application without departing from the technical solution content of the present application still belongs to the scope of the technical solution of the present application.

Claims

1. A vehicle intelligent driving domain controller maintenance system, characterized in that: include: A first system-on-chip, a microcontroller unit, and a second system-on-chip; The microcontroller unit is used to cooperate with the first system-level chip to execute the intelligent driving function of the vehicle; The second system-on-chip is connected to the first system-on-chip and the microcontroller unit; Among them, the second system-level chip is configured to be wirelessly connected to the external debugging device of the intelligent driving domain controller so as to perform online operations on the first system-level chip and the microcontroller unit wirelessly, and the online operations include at least one of online debugging, log acquisition and software damage recovery operations.

2. The system according to claim 1, wherein: The second system-on-chip is connected to the first system-on-chip and the microcontroller unit via a debugging interface, and the debugging interface includes at least one of UART, CAN, SPI, and USB.

3. The system according to claim 2, characterized in that The second system-on-chip is also connected to the first system-on-chip and the micro control unit via Ethernet.

4. The system according to claim 3, characterized in that The second system-level chip, the first system-level chip, and the microcontroller unit are integrated together on any circuit board in the intelligent driving domain controller.

5. The system according to claim 3, wherein: The second system-level chip serves as an independent module and is connected to the central circuit board of the intelligent driving domain controller through an interface.

6. The system according to claim 1, wherein: The system further comprises: a security chip, connected to the second system-on-chip, and configured to store authentication information of the second system-on-chip; The mobile hotspot module is connected to the second system-on-chip and is used to establish remote access rights to the second system-on-chip.

7. A method for maintaining a vehicle's intelligent driving domain controller, characterized in that: An intelligent driving domain controller maintenance system for a vehicle according to any one of claims 1 to 6, the system comprising a first system-on-chip, a second system-on-chip, and a microcontroller unit connected to each other, the method comprising: The second system-level chip is wirelessly connected to the external debugging device of the intelligent driving domain controller to perform online operations on the first system-level chip and the microcontroller unit in a wireless manner. The online operations include at least one of online debugging, log acquisition and software damage recovery operations.

8. The method according to claim 7, characterized in that Performing online operations on the first system-level chip and the micro control unit in a wireless manner includes: receiving an access request for the second system-on-chip; Verifying the access rights of the accessing party according to the access request; In response to the access authority of the access party being verified, performing a first debugging operation on the first system-on-chip and performing a second debugging operation on the micro control unit; The first debugging operation includes at least one of status monitoring, restarting, and modifying operating parameters of the first system-level chip, and the second debugging operation includes status monitoring and / or fault information diagnosis of the micro control unit.

9. The method according to claim 8, characterized in that Performing online operations on the first system-level chip and the micro control unit in a wireless manner includes: monitoring in real time a first log file actively output by the first system-level chip and the microcontroller unit, adding a timestamp to the first log file, and saving the timestamp; Obtaining a second log file stored in the first system-on-chip, adding a timestamp to the second log file, and saving the timestamp; Among them, the first log file is a log file that the intelligent driving domain controller cannot save, and the second log file is a log file discarded by the first system-level chip.

10. The method according to claim 7, characterized in that Performing online operations on the first system-level chip and the micro control unit in a wireless manner includes: When the first system-on-chip fails to start, sending an upgrade recovery request to the second system-on-chip; In response to the verification of the permission information of the requesting party being successful, obtaining an OTA upgrade package for the first system-on-chip and the microcontroller unit; Performing bottom-level flashing on the first system-on-chip through the debugging interface to write the upgraded and repaired software information in the OTA upgrade package into the first system-on-chip; An OTA upgrade is performed on the microcontroller unit to a version matching the first system-on-chip through a communication bus.

11. The method according to claim 10, characterized in that The bottom-level flashing bypasses the first system-on-chip startup process and partition mechanism, and writes the repaired software information into the first system-on-chip through bottom-level firmware recovery.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 7 to 11 are implemented.

13. A controller having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 7 to 11 are implemented.

14. A vehicle, characterized in that: Including the controller according to claim 13.

15. A computer program product, characterized in that The method comprises a computer program or instructions, which implements the steps of the method according to any one of claims 7 to 11 when executed by a processor.

Images