Data acquisition method, controller, and vehicle

Abstract

The present application provides a data acquisition method, a controller, and a vehicle, being capable of using a microcontroller unit (MCU) on a vehicle to acquire operation data of a system-on-chip (SoC), thereby achieving anomaly analysis of the SoC. In the method, an MCU and an SoC that are comprised in a controller of a vehicle are connected by means of a universal asynchronous receiver-transmitter (UART) interface, on this basis, the MCU can acquire operation data of the SoC by means of the UART interface, and then the MCU can forward the operation data to a first on-board component, thereby achieving anomaly analysis of the SoC.

Description

Data acquisition method, controller and vehicle

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 4, 2023, with application number 202311656437.6 and application name “Data Acquisition Method, Controller and Vehicle”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a data acquisition method, a controller, and a vehicle. Background Art

[0003] With the rapid development of intelligent driving technology, more and more vehicles are using system-on-chip (SoC) to control the normal operation of the vehicle. Among them, SoC is a chip-level system formed by combining a series of integrated circuits with specific functions on a chip, which can realize the control of multiple electronic control units (ECU) on the vehicle. Generally speaking, after the SoC is powered on, the various systems on the SoC will be started in order to ensure the normal operation of the SoC. When the SoC startup is abnormal, by obtaining relevant data during the SoC startup process, the abnormality in the SoC startup process can be quickly located, and then the cause of the SoC startup abnormality can be analyzed.

[0004] Currently, during the SoC testing phase, personnel can directly export relevant data from the SoC's startup process to testing equipment through the SoC's hardware interface, allowing for rapid analysis of the cause of SoC startup anomalies. However, to prevent the leakage of SoC information and functions, hardware interfaces are typically not retained during mass production. Consequently, relevant data from the SoC's startup process cannot be obtained through these interfaces. Consequently, when subsequent SoC startup anomalies occur, the cause cannot be effectively analyzed. Summary of the Invention

[0005] The present application provides a data acquisition method, a controller, and a vehicle, which can utilize the microcontroller unit MCU on the vehicle to obtain the operating data of the system-on-chip SoC, thereby realizing abnormal analysis of the SoC.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a data acquisition method is provided, which is applied to a microcontroller unit MCU in a vehicle controller. The controller also includes a system-on-chip SoC. The MCU is connected to the SoC via a universal asynchronous receiver / transmitter (UART) interface. The method includes: obtaining operating data of the SoC via the UART interface; and sending the operating data to a first vehicle-mounted component, wherein the operating data is used for abnormality analysis of the SoC.

[0008] In the first aspect of the solution, a new UART hardware path is added from the SoC to the MCU for vehicle controllers that include an MCU and a SoC. This allows the MCU to obtain the SoC's operating data through this UART hardware path. The MCU then transmits this acquired SoC operating data to the first on-board component for analysis and processing. This allows, after mass production of controllers that include both an MCU and SoC, if the SoC experiences a startup anomaly, personnel will have access to the SoC's operating data and can quickly analyze the cause of the anomaly.

[0009] In one possible implementation, after obtaining the SoC's operating data via the UART interface, the method further includes: compressing the operating data to obtain compressed operating data; and sending the operating data to the first vehicle-mounted component, including: sending the compressed operating data to the first vehicle-mounted component. In this way, the MCU can store a large amount of SoC operating data using a relatively small amount of memory space.

[0010] In one possible implementation, after obtaining the SoC's operating data via the UART interface, the method further includes: encrypting the operating data to obtain encrypted operating data; and sending the operating data to the first vehicle-mounted component, including: sending the encrypted operating data to the first vehicle-mounted component. This ensures the information security of the SoC's operating data, ensuring that even if an attacker obtains the SoC's operating data, they will be unable to understand its content.

[0011] In one possible implementation, after the MCU obtains the operating data of the SoC through the UART interface, it can either compress the operating data or encrypt the operating data. This application does not limit the order in which the compression and encryption processes are performed. For example, the operating data can be compressed first, and then the compressed operating data can be encrypted.

[0012] In one possible implementation, obtaining the SoC's operating data via the UART interface includes: controlling the SoC to be powered on; obtaining the SoC's operating data via the UART interface during the SoC's system startup process; and caching the operating data. Thus, after the MCU controls the SoC to be powered on, it can begin obtaining the SoC's operating data during the system startup process via the UART interface and cache the data in the MCU's memory.

[0013] In one possible embodiment, transmitting the operating data to the first vehicle-mounted component includes transmitting the operating data to the first vehicle-mounted component upon detecting a startup anomaly of the SoC. In this manner, after the MCU obtains the operating data of the SoC and detects that the SoC has not started normally, the MCU may automatically transmit the operating data to the first vehicle-mounted component, allowing relevant personnel to obtain the operating data and locate the SoC anomaly.

[0014] In one possible implementation, transmitting the operating data to the first vehicle-mounted component includes transmitting the operating data to the first vehicle-mounted component in response to a first instruction from a user. In this manner, after the MCU obtains the operating data from the SoC and detects an enable instruction from the user, the MCU may transmit the operating data to the first vehicle-mounted component, thereby facilitating the user's understanding of the cause of the SoC startup anomaly.

[0015] In one possible implementation, the MCU is connected to the first vehicle-mounted component via a controller area network (CAN) bus, and transmitting operating data to the first vehicle-mounted component includes: dividing the operating data into multiple data slices; generating a CAN message corresponding to each of the multiple data slices; and transmitting the CAN message corresponding to each data slice to the first vehicle-mounted component via the CAN bus. Thus, when the MCU transmits the operating data of the SoC via the CAN bus, due to the relatively narrow CAN bus, all the operating data cannot be transmitted at once. Therefore, the operating data can be split and transmitted multiple times.

[0016] In one possible implementation, the first on-board component is an on-board communication component, which is used to establish a communication connection with an external device of the vehicle. The operating data is used to instruct the on-board communication component to transmit the operating data to the external device and instruct the external device to analyze and process the operating data. In this way, the MCU can forward the operating data from the SoC to a component on the vehicle with communication capabilities, allowing the operating data to be transmitted to the external device, making it easier for relevant personnel to review the operating data and analyze the cause of the anomaly.

[0017] In one possible implementation, the first onboard component is an onboard display device, where the operating data is used to instruct the onboard display device to analyze and process the operating data and display the analysis results. In this way, the MCU can forward the SoC's operating data to a component on the vehicle with display and analysis capabilities, allowing relevant personnel to directly view the cause of the anomaly through the component.

[0018] In a second aspect, a data acquisition device is provided, which is included in the MCU of the vehicle controller and has the function of implementing the above-mentioned first aspect or any possible design method thereof. This function can be implemented by hardware or by hardware executing corresponding software implementation. The hardware or software includes one or more modules or units corresponding to the above-mentioned functions. For example, the data acquisition device may include an acquisition module and a sending module. The acquisition module is used to obtain the operating data of the SoC through the UART interface; the sending module is used to send the operating data to the first vehicle-mounted component, and the operating data is used to perform abnormal analysis of the SoC.

[0019] In a third aspect, a microcontroller unit MCU is provided, which is applied to a vehicle. The MCU includes a processor, a memory and a universal asynchronous receiver / transmitter UART interface, wherein the UART interface is used to connect to a system-on-chip SoC, the memory is used to store a computer program or instruction, and the processor is used to run the computer program or instruction and execute the data acquisition method in any possible implementation of the first aspect above.

[0020] In a fourth aspect, a controller is provided, which includes the MCU and SoC according to the third aspect.

[0021] In a fifth aspect, a vehicle is provided, comprising the controller according to the fourth aspect.

[0022] In a sixth aspect, a chip system is provided. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via a circuit. The interface circuits are configured to receive a signal and send the signal to the processor, the signal including an instruction. The processor is configured to execute the instruction to perform the data acquisition method according to any possible implementation of the first aspect.

[0023] It can be understood that the beneficial effects that can be achieved by the above-mentioned device of the second aspect, the microcontroller unit MCU of the third aspect, the controller of the fourth aspect, the vehicle of the fifth aspect and the chip system of the sixth aspect can be referred to the beneficial effects of the first aspect and any possible implementation thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG1 is a schematic diagram of a vehicle architecture provided by an embodiment of the present application;

[0025] FIG2 is a schematic diagram of a system architecture provided by related technology;

[0026] FIG3 is a schematic diagram of a system architecture provided by related technology;

[0027] FIG4 is a flow chart of a data acquisition method provided in an embodiment of the present application;

[0028] FIG5 is a schematic diagram of a system architecture provided in an embodiment of the present application;

[0029] FIG6 is a timing diagram of a data acquisition method provided in an embodiment of the present application;

[0030] FIG7 is a flow chart of a data acquisition method provided in an embodiment of the present application;

[0031] FIG8 is a schematic structural diagram of a data acquisition device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0033] As shown in FIG1 , an embodiment of the present application provides a schematic diagram of the architecture of a vehicle 100 . Vehicle 100 may be a conventional vehicle or an autonomous vehicle for transporting personnel. Autonomous vehicles may also be referred to as unmanned vehicles or intelligent driving vehicles, and may be driven in manual mode, fully autonomous mode, or partially autonomous mode. When configured to operate in fully autonomous mode or partially autonomous mode, the autonomous vehicle may autonomously operate over a geographic area with minimal or no control input from the driver.

[0034] Optionally, vehicle 100 may be a ground-based vehicle, such as a car, bus, motorcycle, locomotive, subway, etc. Vehicle 100 may also be a water-based vehicle, such as a boat, hovercraft, submarine, etc. Vehicle 100 may also be a flying vehicle, such as an airplane, helicopter, etc. The embodiments of this application do not limit the specific type of vehicle 100.

[0035] In the embodiment of the present application, the vehicle 100 may include at least one controller 110 having control functions and computing functions, etc.

[0036] In some embodiments, controller 110 may be an electronic control unit (ECU). Different ECUs may implement different functions to control the normal operation of the vehicle. For example, the air conditioning ECU may control the temperature in the vehicle, while the engine ECU may control the engine's air intake, fuel injection, and ignition timing to control the vehicle's speed.

[0037] Various ECUs can be connected via an in-vehicle bus to enable data communication between them. The bus can be a controller area network (CAN) bus, a wired communication line such as an Ethernet bus, a local interconnect network (LIN) bus, a media-oriented system transport (MOST) bus, or FlexRay, or a line generated by a wireless communication module such as wireless fidelity (Wi-Fi), Bluetooth, or ZigBee.

[0038] In some embodiments, a vehicle may be divided into multiple domains based on functions, each domain including at least one domain controller, and each domain controller is used to manage multiple ECUs connected to one or more CAN buses within the domain.

[0039] The controller 110 may also be a domain controller. The domain controller may be a cockpit domain controller (CDC), or a smart cockpit platform, for controlling the smart cockpit. The domain controller may also be a vehicle domain controller (VDC), or a vehicle control platform, for controlling vehicle power. The domain controller may also be a mobile data center (MDC), or a smart driving platform, for controlling smart driving. The embodiments of the present application do not limit the type of domain controller.

[0040] The controller 110 may include a microcontroller unit (MCU) 111 and a SoC 112. The SoC 112 includes a universal asynchronous receiver / transmitter (UART) interface, which is a universal serial data bus used for asynchronous communication. In the SoC, the UART interface can be used for data transmission, debug instructions, and debug information output. In the embodiment of the present application, the MCU 111 and the SoC 112 can be connected via the UART interface. The MCU 111 is used to obtain operating data of the SoC 112 via the UART interface.

[0041] In the embodiment of the present application, the power supply of SoC 112 is controlled by MCU 111. MCU 111 is responsible for detecting the operating status of SoC 112 and executing operations such as powering on SoC 112, powering off SoC 112, and recovering from abnormalities. After MCU 111 powers on SoC 112, SoC 112 periodically transmits a heartbeat signal data packet to MCU 111. MCU 111 performs timing processing on the heartbeat signal. If one or more heartbeat signals are not received within a specified time, it is considered that SoC 112 has an abnormality and restarts.

[0042] In the embodiment of the present application, after the SoC 112 is powered on, various systems on the SoC 112 are started in order, such as the basic input output system (BIOS), bootloader, operating system (OS), etc.

[0043] In some embodiments, the vehicle may also include an on-board communication component 120 with a communication function, such as a gateway, an on-board communication terminal, a vehicle computer, etc. Among them, the on-board communication terminal is also called a vehicle-mounted telecommunications box (telematics-box, T-box). The on-board T-box is a box with a communication function in the vehicle, which can provide a remote communication interface for the vehicle 100 and is usually hidden in the vehicle. The on-board T-box is mainly used to communicate with the background system (such as a server) / electronic equipment to realize the vehicle information display and vehicle control on the electronic equipment side. Among them, the electronic device can be a mobile phone, a tablet computer, a wearable device, etc. In one possible implementation method, the on-board T-box can read the data of each ECU in the vehicle through the CAN bus, and send the data to the background system (such as a server) or electronic equipment through the network for user viewing.

[0044] In some embodiments, the vehicle may further include an on-board display component 130 with a display function, such as a car computer. The car computer is also called an on-board computer or a car navigation. The car computer may include a host and a display screen. The host and display screen of the car computer may be arranged together or separately. The car computer is usually installed in the center console. The center console refers to the workbench in front of the driver and co-driver seats in the vehicle 100. The workbench is usually a carrier for devices such as the instrument panel, air conditioner, audio panel, storage box, and airbags. Optionally, the car computer can be connected to sensors in the vehicle, and the car computer can control the vehicle based on data from the sensors. Sensors in the vehicle may include but are not limited to temperature sensors, speed sensors, and image sensors.

[0045] In some embodiments, the controller 110 may be connected to the vehicle-mounted communication component 120 and the vehicle-mounted display component 130 via a bus to achieve data communication.

[0046] In some embodiments, the above-mentioned vehicle computer and vehicle-mounted communication terminal may also be an ECU in the vehicle.

[0047] It is understood that the embodiments of the present application do not limit the structure of the vehicle, which may include more components or devices. The methods in the following embodiments can all be implemented in a vehicle or controller having the above hardware structure.

[0048] Generally, when an SoC starts abnormally, relevant personnel can quickly locate the abnormality in the SoC startup process by obtaining relevant data during the SoC startup process, and then analyze the cause of the SoC startup abnormality.

[0049] Currently, during the SoC testing phase, as shown in Figure 2, personnel can directly connect a data cable from the SoC's hardware UART interface to a test device. This allows them to export relevant data from the SoC's startup process to the test device, allowing them to quickly analyze the cause of SoC startup anomalies. However, to prevent the leakage of SoC information and functions, the hardware UART interface is typically not retained during mass production of SoCs. This prevents personnel from accessing the hardware UART interface to obtain relevant data from the SoC's startup process. Consequently, when subsequent SoC startup anomalies occur, it is impossible to effectively analyze the cause.

[0050] In the information and communications technology (ICT) server sector, as shown in Figure 3, a baseboard management controller (BMC) can be attached to the server's SoC's UART interface to export the SoC's operating data via the UART interface. However, in the automotive sector, attaching a BMC to each SoC in the vehicle's controllers not only increases hardware and software adaptation costs but also raises information security concerns.

[0051] Therefore, to address the above-mentioned issues, the embodiments of the present application provide a data acquisition method that replaces the BMC in the ICT field with a functionally safe MCU on the vehicle, and adds a UART hardware path from the SoC to the MCU, allowing the MCU to obtain the SoC's operating data through this UART hardware path. The MCU then sends the obtained SoC's operating data to analyze and process SoC operating anomalies. This eliminates the need for additional hardware costs, and after mass production of controllers containing MCUs and SoCs, if the SoC experiences a startup anomaly, relevant personnel will have a path to obtain the SoC's operating data and quickly analyze the cause of the SoC startup anomaly.

[0052] The following will take the controller in Figure 1 as an example to introduce a data acquisition method provided by an embodiment of the present application. Wherein, the controller includes an MCU and a SoC, as shown in Figure 4, and the data acquisition method may include:

[0053] S410, MCU obtains the operation data of SoC through the UART interface.

[0054] It can be understood that since the MCU and SoC are connected through the UART interface, the MCU can directly obtain the operating data of the SoC through the UART channel.

[0055] The SoC's operational data can refer to a series of startup data after the SoC is powered on. This series of startup data can facilitate subsequent analysis of SoC startup anomalies. For example, the SoC's operational data can include a series of code data and instructions executed when the BIOS is booted, a series of code data executed when the bootloader is booted, and a series of code data executed when the OS is booted.

[0056] In some embodiments, the operating data of the SoC may also refer to execution data when the SoC implements various functions after startup. This series of execution data can facilitate subsequent abnormal analysis of the operating functions of the SoC.

[0057] S420. The MCU sends the operating data to the first vehicle-mounted component. The operating data is used for abnormality analysis of the SoC.

[0058] In an embodiment of the present application, after obtaining the operating data of the SoC, the MCU can send the operating data of the SoC so that relevant personnel can obtain the operating data of the SoC and parse the operating data through a matching parsing script to analyze and locate the cause of the abnormality of the SoC.

[0059] In the embodiment of the present application, the MCU can send the operating data of the SoC to a first vehicle-mounted component in the vehicle via the vehicle bus. The first vehicle-mounted component can be any component or device in the vehicle.

[0060] As one approach, the first in-vehicle component can be an in-vehicle communication component with communication capabilities, such as an in-vehicle gateway or T-box. After the MCU sends the SoC's operating data to this in-vehicle communication component, the in-vehicle communication component can then transmit the SoC's operating data to external devices in the vehicle, such as servers in the vehicle-to-cloud system or testing equipment with data detection and analysis capabilities. This allows relevant personnel to review the operating data and analyze the cause of any anomalies.

[0061] As shown in Figure 5, after MCU 111 obtains the operating data of SoC 112 through the UART channel, it forwards the SoC operating data to the onboard communication component via the vehicle's internal bus. The onboard communication component then reports the operating data to the vehicle-to-cloud system server 200. Relevant personnel can then read the operating data from the server and perform abnormal analysis on the SoC.

[0062] Optionally, the on-board communication component may also have data detection and analysis capabilities, so that after receiving the operating data of the SoC, the on-board communication component may also analyze and process the operating data, and after obtaining the analysis results, send them to the vehicle's external devices.

[0063] Alternatively, the first in-vehicle component can be an in-vehicle display unit with display functionality, such as a head unit. The MCU transmits the SoC's operating data to this in-vehicle display unit, which then analyzes and processes the data, displays the results, and allows personnel to directly identify the cause of the anomaly.

[0064] In some embodiments, due to the limited memory space of the MCU, it may not be able to carry a large amount of SoC operating data. Therefore, after the MCU obtains the operating data of the SoC, it can also compress the operating data to obtain compressed operating data, and then forward it to the first vehicle-mounted component. In this way, the MCU can use less memory space to store a large amount of SoC operating data. The compression algorithm can be any compression algorithm in the relevant technology, and the embodiments of the present application are not limited to this. For example, the Lz77 compression algorithm is used.

[0065] In some embodiments, since broadcasting the SoC's operating data over the CAN network may pose risks to information security and system compromise, the MCU, after acquiring the SoC's operating data, may also encrypt the data to obtain the encrypted data, which is then forwarded to the first on-board component. This ensures the information security of the SoC's operating data, ensuring that even if an attacker acquires the data, they will be unable to understand its content. The encryption algorithm may be any encryption algorithm known in the relevant art and is not limited in this embodiment of the present application.

[0066] In some embodiments, after the MCU obtains the operating data of the SoC, it may also compress the operating data of the SoC first, obtain the compressed operating data, and then encrypt the compressed operating data to obtain encrypted operating data.

[0067] In some embodiments, after the MCU obtains the operating data of the SoC, it may also first encrypt the operating data of the SoC, obtain the encrypted operating data, and then compress the encrypted operating data to obtain compressed operating data. The embodiments of the present application do not limit the order in which encryption and compression are performed.

[0068] The data acquisition method provided in an embodiment of the present application adds a UART hardware path from the SoC to the MCU for a vehicle controller that includes an MCU and a SoC. This allows the MCU to obtain the SoC's operating data through this UART hardware path, and the MCU then transmits the obtained SoC operating data to a first on-board component for analysis and processing of the operating data. This method allows personnel to obtain the SoC's operating data even if the SoC experiences a startup anomaly after mass production of a controller that includes an MCU and SoC, allowing them to quickly analyze the cause of the SoC startup anomaly.

[0069] Please refer to Figures 6 and 7. Figure 6 shows a timing diagram of a data acquisition method provided in an embodiment of the present application. Figure 7 shows a flow chart of a data acquisition method provided in an embodiment of the present application. The data acquisition method may include:

[0070] S510, MCU controls the SoC to be in a power-on state.

[0071] In the embodiment of the present application, when the SoC is in the ordering state and needs to be started, the MCU can power on the SoC, putting the SoC in the powered-up state. After the SoC is in the powered-up state, the SoC can sequentially start various systems on the SoC. During the startup process, the startup data of the SoC can be forwarded to the MCU via the UART interface.

[0072] S520: During the system startup process of the SoC, the MCU obtains the operating data of the SoC through the UART interface.

[0073] In the embodiment of the present application, after the MCU powers on the SoC, the MCU can obtain the operating data of the SoC through the UART interface.

[0074] S530 and MCU compress and encrypt the running data.

[0075] In an embodiment of the present application, after obtaining the operating data of the SoC, the MCU can compress and encrypt the operating data of the SoC, which not only ensures data security but also saves memory space of the MCU.

[0076] S540, MCU caches running data.

[0077] In the embodiment of the present application, after compressing and encrypting the running data, the MCU can temporarily store the compressed and encrypted running data and wait for subsequent determination whether to send it out.

[0078] S550: When the MCU detects a startup abnormality of the SoC, it sends operating data to the vehicle communication component.

[0079] In this embodiment of the present application, after the MCU powers on the SoC, the SoC periodically transmits a heartbeat signal packet to the MCU. The MCU then times the heartbeat signal. If it does not receive a heartbeat signal within a specified time, such as one minute, it is considered that the SoC has experienced a startup anomaly. At this point, the MCU can send the compressed and encrypted operating data to the vehicle's communication component.

[0080] Optionally, when the MCU sends the SoC's operating data via the CAN bus, the CAN bus is relatively narrow and cannot send all the operating data at once. Therefore, the operating data can be split and sent out in multiple times. The MCU divides the SoC's operating data into multiple data slices, generates a CAN message corresponding to each of the multiple data slices, and then cyclically sends the CAN message corresponding to each data slice to the on-board communication component via the CAN bus.

[0081] Optionally, when the MCU detects a startup anomaly of the SoC, it can also send operating data to the on-board display component, so that the on-board display device can analyze and process the operating data and display the analysis results.

[0082] In some embodiments, the MCU can also send operating data to the vehicle-mounted communication component or the vehicle-mounted display component in response to the user's first instruction. Thus, after the MCU obtains the SoC's operating data and detects the user's enable instruction, it can also send the operating data to the first vehicle-mounted component, allowing the user to understand the cause of the SoC startup anomaly.

[0083] Optionally, when the MCU detects a startup anomaly in the SoC, it can instruct the on-board display unit to display an anomaly prompt and an anomaly analysis option (e.g., an icon or a drop-down menu). When the user selects the anomaly analysis option, the MCU responds by transmitting temporarily stored SoC operating data to the on-board display unit, which then analyzes and processes the operating data and displays the analysis results.

[0084] S560: The vehicle-mounted communication component sends the operating data to the server.

[0085] In this embodiment of the present application, after receiving a CAN message, the on-board communication component can report the CAN message to a server. This allows personnel to retrieve the CAN message from the server and parse it using a supporting parsing script tool to obtain the original SoC operating data before encryption and compression. Furthermore, personnel can analyze SoC startup anomalies based on the parsed SoC operating data.

[0086] It is understandable that, in order to realize the above functions, the above-mentioned controller or MCU etc. includes hardware structures and / or software modules corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

[0087] It should be noted that the module division in the embodiments of the present invention is illustrative and represents only one logical functional division. In actual implementation, other divisions may be employed. For example, a controller or MCU may include memory, a processor, a communication interface, and a bus. The memory, processor, and communication interface are interconnected via a bus.

[0088] The present application also provides a data acquisition device that can be applied to the controller or MCU mentioned above and is used to execute the functions or steps executed by the controller or MCU in the above method embodiment.

[0089] In the embodiments of the present application, the data acquisition device and the like can be divided into functional modules according to the above method examples. For example, each functional module can be divided into different functional modules corresponding to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0090] As an example, please refer to Figure 8, which shows a schematic diagram of the structure of a data acquisition device provided in an embodiment of the present application. As shown in Figure 8, the data acquisition device 800 includes an acquisition module 801 and a transmission module 802. The acquisition module 801 is used to obtain operating data of the SoC via a UART interface. The transmission module 802 is used to transmit the operating data to the first vehicle-mounted component. The operating data is used to perform abnormality analysis on the SoC.

[0091] In a possible implementation, the data acquisition device 800 further includes a compression processing module for compressing the operating data to obtain compressed operating data. A sending module 802 is configured to send the compressed operating data to the first vehicle-mounted component.

[0092] In a possible implementation, the data acquisition device 800 further includes an encryption processing module for encrypting the operation data to obtain encrypted operation data. A sending module 802 is configured to send the encrypted operation data to the first vehicle-mounted component.

[0093] In a possible implementation, the acquisition module 801 is configured to: control the SoC to be in a power-on state; acquire the operating data of the SoC through a UART interface during system startup of the SoC; and cache the operating data.

[0094] In a possible implementation, the sending module 802 is configured to send the operating data to the first vehicle-mounted component when a startup abnormality of the SoC is detected.

[0095] In a possible implementation, the sending module 802 is configured to send the operating data to the first vehicle-mounted component in response to a first instruction from the user.

[0096] In one possible implementation, the MCU is connected to the first vehicle-mounted component via a controller area network (CAN) bus, and a sending module 802 is configured to divide the operating data into multiple data slices; generate a CAN message corresponding to each of the multiple data slices; and send the CAN message corresponding to each data slice to the first vehicle-mounted component via the CAN bus.

[0097] In one possible embodiment, the first vehicle-mounted component is a vehicle-mounted communication component, which is used to establish a communication connection with an external device of the vehicle, wherein: the operating data is used to instruct the vehicle-mounted communication component to send the operating data to the external device and instruct the external device to analyze and process the operating data.

[0098] In a possible implementation, the first vehicle-mounted component is a vehicle-mounted display device, wherein the operating data is used to instruct the vehicle-mounted display device to analyze and process the operating data and display the analysis results.

[0099] It should be noted that the information interaction, execution process, etc. between the modules in the data acquisition device 800 provided in Figure 8 are based on the same concept as the method embodiment corresponding to Figure 4 in this application. For specific contents, please refer to the description in the method embodiment shown above in this application, and will not be repeated here.

[0100] An embodiment of the present application also provides a microcontroller unit MCU, which is applied to a vehicle. The MCU includes a processor, a memory and a universal asynchronous receiver / transmitter (UART) interface. The UART interface, the memory and the processor are coupled, wherein the UART interface is used to connect to a system-on-chip (SoC), the memory is used to store computer programs or instructions, and the processor is used to run the computer programs or instructions. The various functions or steps performed by the MCU in the above method embodiment.

[0101] The embodiment of the present application further provides a controller, which includes the above-mentioned data acquisition device, or includes the above-mentioned MCU. Optionally, the controller is a domain controller or an electronic control unit ECU.

[0102] The present application also provides a chip system, which includes at least one processor and at least one interface circuit. The processor and the interface circuit can be interconnected via a line. The interface circuit can read instructions stored in a memory and send the instructions to the processor. When the instructions are executed by the processor, the chip system can perform the various functions or steps performed by the MCU in the above method embodiment. Of course, the chip system can also include other discrete components, which are not specifically limited by the present application.

[0103] An embodiment of the present application further provides a computer program product. When the computer program product runs on an MCU, the MCU is enabled to execute each function or step executed by the MCU in the above method embodiment.

[0104] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0106] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0107] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be covered by the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A data acquisition method, characterized in that: A microcontroller unit MCU is applied to a controller of a vehicle, the controller further comprising a system-on-chip SoC, the MCU is connected to the SoC via a universal asynchronous receiver-transmitter UART interface, and the method comprises: Acquire the operation data of the SoC through the UART interface; The operation data is sent to a first vehicle-mounted component, where the operation data is used to perform abnormality analysis on the SoC.

2. The method according to claim 1, characterized in that After acquiring the operation data of the SoC through the UART interface, the method further includes: compressing the operation data to obtain compressed operation data; The sending the operation data to the first vehicle-mounted component comprises: The compressed operation data is sent to the first vehicle-mounted component.

3. The method according to claim 1 or 2, characterized in that: After acquiring the operation data of the SoC through the UART interface, the method further includes: Encrypting the operation data to obtain encrypted operation data; The sending the operation data to the first vehicle-mounted component comprises: The encrypted operation data is sent to the first vehicle-mounted component.

4. The method according to any one of claims 1 to 3, characterized in that: The obtaining the operation data of the SoC through the UART interface includes: Controlling the SoC to be in a power-on state; During the system startup process of the SoC, obtaining the operation data of the SoC through the UART interface; The operating data is cached.

5. The method according to any one of claims 1 to 4, characterized in that: The sending the operation data to the first vehicle-mounted component comprises: When a startup abnormality of the SoC is detected, the operation data is sent to a first vehicle-mounted component.

6. The method according to any one of claims 1 to 4, characterized in that: The sending the operation data to the first vehicle-mounted component comprises: In response to a first instruction from a user, the operation data is sent to a first vehicle-mounted component.

7. The method according to any one of claims 1 to 6, characterized in that: The MCU is connected to the first vehicle-mounted component via a controller area network (CAN) bus, and the sending of the operation data to the first vehicle-mounted component includes: Splitting the operating data into a plurality of data slices; Generate a CAN message corresponding to each data slice in the multiple data slices; The CAN message corresponding to each data piece is sent to the first vehicle-mounted component via the CAN bus.

8. The method according to any one of claims 1 to 7, characterized in that: The first vehicle-mounted component is a vehicle-mounted communication component, and the vehicle-mounted communication component is used to establish a communication connection with an external device of the vehicle, wherein: The operating data is used to instruct the vehicle-mounted communication component to send the operating data to the external device, and to instruct the external device to analyze and process the operating data.

9. The method according to any one of claims 1 to 7, characterized in that: The first vehicle-mounted component is a vehicle-mounted display device, wherein: The operating data is used to instruct the vehicle-mounted display device to analyze and process the operating data and display the analysis result.

10. A microcontroller unit MCU, characterized in that: Applied to a vehicle, the MCU includes a processor, a memory and a universal asynchronous receiver-transmitter (UART) interface, the UART interface, the memory and the processor are coupled, wherein the UART interface is used to connect to a system-on-chip (SoC), the memory is used to store a computer program or instruction, and the processor is used to run the computer program or instruction to execute the method as described in any one of claims 1-9.

11. A controller, characterized in that: The controller includes the MCU as claimed in claim 10 and the SoC.

12. A vehicle, characterized in that: The vehicle includes the controller of claim 11.

13. A chip, characterized in that: The chip includes an interface circuit and a processor, the interface circuit and the processor are interconnected via a line, the interface circuit is used to receive a signal, the signal includes an instruction, and the processor is used to run the instruction to execute the method as described in any one of claims 1-9.

Images