On-board processing method and apparatus, vehicle, storage medium, and program product
Patent Information
- Application Number
- PCT/CN2025/082947
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-03-17
- Publication Date
- 2026-09-24
Smart Images
Figure CN2025082947_24092026_PF_FP_ABST
Abstract
Description
An on-board processing method, apparatus, vehicle, storage medium, and program product. Technical Field
[0001] This application relates to the field of vehicle networking technology, and in particular to an in-vehicle processing method, device, vehicle, storage medium and program product. Background Technology
[0002] With the development of automotive technology, people's demands for the intelligence and aesthetics of vehicles are also increasing. To meet the diverse needs of users, automakers produce a variety of different vehicle models based on the same platform, including but not limited to: small cars, microcars, compact cars, mid-range cars, high-end cars, luxury cars, sedans, multi-purpose vehicles (MPVs), and sport utility vehicles (SUVs). Even the same model of vehicle is sometimes divided into high-end, mid-range, and low-end versions. These different models or configurations (collectively referred to as vehicle types) differ in their appearance, configuration, and performance.
[0003] Currently, different vehicle models are configured with a separate software package for each model. By matching each vehicle model with its corresponding software package, the in-vehicle control unit can be activated normally. However, in order to cope with the rapid release of a large number of vehicle models, improve R&D efficiency, and reduce version maintenance costs, more and more research is focusing on shared software packages for multiple models. But when multiple models share a single software package, the default factory software package's model or capability set may not match the actual production models. When this software package is released to the original equipment manufacturer (OEM) production line, it may fail to activate the in-vehicle control unit due to model incompatibility, thus failing to configure the correct model for the vehicle, creating a vicious cycle.
[0004] In summary, ensuring the normal activation of the vehicle's control unit is a critical technical issue that needs to be addressed in the technical solution of sharing software packages across multiple vehicle models. Summary of the Invention
[0005] This application provides an in-vehicle processing method, device, vehicle, storage medium, and program product to solve the technical problem that existing technologies cannot properly wake up the in-vehicle control unit when implementing a multi-vehicle shared software package.
[0006] Firstly, this application provides an in-vehicle processing method applicable to in-vehicle processing devices. The in-vehicle processing device can be a vehicle or a component within a vehicle, such as a vehicle controller, domain controller, or electronic control unit; or it can be an external device or component, such as a cloud server, user terminal, or other vehicle. The method includes: receiving a first wake-up command; obtaining the vehicle's current mode; if the current mode is platform mode, waking up a first control unit; if the current mode is vehicle model mode, waking up the first control unit when the first wake-up command matches a second wake-up command corresponding to the vehicle model mode; wherein, platform mode is the mode when the vehicle is not configured with a vehicle model, and vehicle model mode is the mode after the vehicle is configured with a vehicle model.
[0007] Based on the above methods, a multi-mode sleep / wake-up system can be designed for vehicles. In platform mode, i.e., when no vehicle model is configured, the vehicle's first control unit can be woken up using any wake-up command. In vehicle model mode, i.e., when the vehicle model is specifically configured, the first control unit can only be woken up using the wake-up command corresponding to that vehicle model. This ensures that the first control unit can be woken up normally when no vehicle model is configured, facilitating the implementation of a multi-vehicle shared software package solution, while also ensuring secure wake-up after vehicle model configuration, thus balancing the success rate and security of vehicle wake-up.
[0008] In one possible design, the first control unit could be a low-power component in the intelligent driving computing platform, such as a microcontroller unit (MCU).
[0009] Based on the above design, the in-vehicle processing method can be applied to intelligent driving computing platforms or their products. Even if different vehicle models have different sleep / wake-up messages for their intelligent driving computing platforms, the MCU in the intelligent driving computing platform can be successfully woken up even when no vehicle model is configured. This supports the promotion of solutions where intelligent driving computing platforms of different models share the same software upgrade package. Furthermore, this design wakes up a low-power component rather than a high-power component via any wake-up command, thus reducing the likelihood of safety issues. It also allows for the safe power-up of other high-power components based on the woken-up low-power component, balancing wake-up success rate and safety.
[0010] In one possible design, when the current mode is platform mode, the first control unit is allowed to send messages within the whitelist, while when the current mode is vehicle model mode, the first control unit is allowed to send any type of message that corresponds to the vehicle model.
[0011] Based on the above design, messages in the whitelist can be understood as messages that can be parsed by the vehicle bus even when the vehicle model is not configured. By configuring the platform mode, only messages in the whitelist can be sent. Even if the first control unit is woken up before configuring the vehicle model, it can be ensured that the first control unit will not send messages that the bus cannot parse, which would cause the vehicle bus to hang up. This ensures the safety of waking up the first control unit.
[0012] In further possible designs, the messages in the whitelist include upgrade messages and / or diagnostic messages.
[0013] Based on the above design, upgrade services and / or diagnostic services can be performed even when the vehicle model is not configured, ensuring the availability of upgrade and / or diagnostic services.
[0014] In one possible design, in response to the operation of activating the first control unit, the vehicle model information stored locally is obtained. If the vehicle model information is stored locally, the current mode of the vehicle is configured as the vehicle model mode, the wake-up command corresponding to the vehicle model information is activated, and the message sending switch corresponding to the vehicle model information is turned on. If the vehicle model information is not stored locally, the current mode of the vehicle is configured as the platform mode, the wake-up command for all vehicle models is activated, and the message sending switch in the whitelist is turned on.
[0015] Based on the above design, the current mode of the vehicle and the corresponding message sending switch can be configured during the initialization phase, thereby avoiding additional configuration processes and saving system processing resources.
[0016] In one possible design, after waking up the first control unit in platform mode, a first message can be received. This first message indicates the first vehicle model information, which is then saved. For example, the first vehicle model information can be stored locally on the first control unit, essentially configuring the vehicle model within the first control unit after waking it up. In this way, the intelligent driving computing platform can wake up or power on other control units based on the first vehicle model information stored locally on the first control unit, ensuring the safety of waking up or powering on other control units.
[0017] In one example of the above design, the sender of the first message can be any device or tool. For example, the vehicle model can be configured by loading the first message into the first control unit through an external tool such as a diagnostic tool, or by sending the first message to the first control unit through an internal component such as a gateway. The latter method does not require adding an electrical inspection station, and the complexity of vehicle configuration is lower.
[0018] In one example of the design above, the first vehicle model information can be used only to indicate the vehicle model, without including specific details related to the model. For example, it can only indicate whether the vehicle model is model A or model B, without including information such as the vehicle's configuration version or function switches. In other words, the first vehicle model information can be a temporary model used for safety wake-up or powering on other control units, and is not the final, official version used in the end.
[0019] In one example of the above design, the first message can directly or indirectly indicate the vehicle model, with the following two possible scenarios:
[0020] Scenario 1: The first message contains the first vehicle model information to clearly indicate the vehicle model. In this case, the first message is also called the vehicle model notification message. The vehicle model indicated by the first message can be the official vehicle model, that is, the model that the vehicle will ultimately use, and there is no need to reconfigure the vehicle model later.
[0021] Scenario Two: The first message contains business characteristic information, which is used to indicate the first vehicle model information. In other words, the first message is used to indirectly indicate the vehicle model. In this case, the first message is also called the business characteristic message. Although the vehicle model indicated by the first message is not clear enough, it can be used as a temporary vehicle model to safely power on other control units. After power-on, the permanent vehicle model can be reconfigured.
[0022] In one example of scenario two above, the service characteristic information may include, but is not limited to, one or more of the following: the device identifier of the destination device of the first message, high-voltage signal, liquid cooling signal, ignition signal, etc.
[0023] Based on the above examples, multiple business characteristic information can be combined to clearly distinguish vehicle models. For example, high-voltage signals, liquid cooling signals, and ignition signals usually have a corresponding relationship with vehicle models and can be used to indirectly indicate the vehicle model. In addition, different vehicle models may correspond to the same high-voltage signal, liquid cooling signal, and ignition signal, but by using the device identifier of the destination device of the first message, it can be known which vehicle the first message was sent to, and thus the vehicle model can be further distinguished based on that vehicle identifier.
[0024] In one example of the above design, after saving the first vehicle model information, a first power-on command can also be received. When the first power-on command matches the second power-on command of the vehicle model corresponding to the first vehicle model information, the second control unit is powered on. The second control unit is different from the first control unit.
[0025] Based on the above example, by configuring the vehicle model information before powering on the second control unit after waking up the first control unit, the second control unit will only be powered on normally when the power-on command sent matches the power-on command corresponding to the configured vehicle model information. This can avoid attacks using non-vehicle model matching messages, ensure the safety of the second control unit when it is powered on, and prevent problems such as disk drop and vehicle power failure.
[0026] In a further example of the above example, when the first control unit is an MCU in the intelligent driving computing platform, the second control unit can be an electronic control unit other than the MCU in the intelligent driving computing platform, such as an electronic control unit (ECU) with higher power consumption than the MCU, including but not limited to: system on chip (SOC), other MCUs, or other ECUs.
[0027] Based on the above example, the low-power MCU in the intelligent driving computing platform can be woken up by any wake-up message, and the vehicle model information can be configured in the MCU. Then, the high-power ECU in the intelligent driving computing platform can be powered up by the power-on message corresponding to the configured vehicle model information, so as to ensure that the intelligent driving computing platform is successfully woken up when no vehicle model is configured, and then the components in the intelligent driving computing platform are safely powered up.
[0028] In a further example of the above example, after powering on the second control unit, a second message can also be received from the diagnostic device. The second message contains the second vehicle model information, and the second vehicle model information is activated.
[0029] Based on the above examples, the actual vehicle model can be configured via diagnostic equipment after the second control unit is powered on, thereby activating the software package capability set of the actual vehicle model. For instance, if the second control unit is powered on after indirectly indicating the vehicle model through a service characteristic message, then that vehicle model is only temporary and is only used for the second control unit. Therefore, configuring the actual vehicle model via diagnostic equipment after powering on the second control unit ensures that the final available capability set is the capability set of the actual vehicle model, thus ensuring the accuracy of vehicle functions.
[0030] It should be noted that the operation of sending the second message by the diagnostic device is placed after the second control unit is powered on because the second control unit has a diagnostic interface, while the first control unit does not. Therefore, the second message sent by the diagnostic device can only be received through the diagnostic interface in the second control unit after the second control unit is powered on, so as to fill in the second vehicle model information.
[0031] Optionally, since both the first and second control units have been activated and powered on, the second vehicle model information is stored both locally in the first and second control units. For example, the second vehicle model information can be used to overwrite the first vehicle model information originally stored locally in the first control unit, and the second vehicle model information can be stored locally in the second control unit. The first and second control units work together to make the second vehicle model information effective.
[0032] Optionally, unlike the first vehicle model information, which is a temporary model used only to power on the second control unit, the second vehicle model information is the officially used model. It not only needs to carry the specific vehicle model but also detailed information related to the model, including model, configuration, style, and feature set. If the vehicle model in the second vehicle model information is the same as the vehicle model in the first vehicle model information, then the second vehicle model information can be considered to include the first vehicle model information. In addition, it also includes information not carried in the first vehicle model information.
[0033] Optionally, loading second vehicle model information through diagnostic equipment is just one example. In other examples, second vehicle model information can also be loaded through other external tools, or second vehicle model information sent by external devices can be received through internal components such as gateways, etc. There are many possible configuration methods, which are not specifically limited here.
[0034] In one example of the above design, the second vehicle model information can be activated as follows: if the second vehicle model information is different from the locally stored vehicle model information, the second vehicle model information is stored locally and the first control unit is restarted. This restart is used to activate the software package for the vehicle model corresponding to the second vehicle model information.
[0035] Based on the above design, before configuring the vehicle model, it can be determined whether the vehicle model to be configured is the currently active model. If so, there is no need to configure the vehicle model to save unnecessary configuration resources. If not, the vehicle model can be configured by restarting to ensure the availability of the configuration.
[0036] It should be noted that the execution entity of the vehicle control method in the first aspect above can be a small module within the intelligent driving computing platform. This module is always in a dormant state, possessing communication and message parsing functions. Although the intelligent driving computing platform is not yet started, as long as a message is sent to this small module, the module can obtain and parse the message, and then perform corresponding operations based on the message. For example, it might first wake up some low-power units in the intelligent driving computing platform, such as the MCU, then configure a temporary vehicle model, and power on higher-power units, such as the SOC, based on the temporary vehicle model, and finally configure the official vehicle model. This dormant small module can be located anywhere within the intelligent driving computing platform, such as within the MCU, the SOC, or outside of both the MCU and the SOC, etc., without specific limitations.
[0037] Secondly, this application provides an in-vehicle processing method applicable to in-vehicle processing devices. The in-vehicle processing device can be a vehicle or a component within a vehicle, such as a vehicle controller, domain controller, or electronic control unit; alternatively, it can be an external device or component, such as a cloud server, user terminal, or other vehicle. The method includes: receiving a first message indicating first vehicle model information; saving the first vehicle model information; and powering on a second control unit based on the first vehicle model information.
[0038] Based on the above method, the vehicle model can be configured first, and then the second control unit can be powered on based on the configured vehicle model to ensure the safety performance of the second control unit when powered on.
[0039] In one possible design, receiving the first message could specifically mean receiving the first message from the gateway.
[0040] Based on the above design, the gateway configuration method does not require setting up an electrical inspection station, and the configuration complexity is low.
[0041] In one possible design, the first vehicle model information is used only to indicate the vehicle model and does not include specific details related to the vehicle model.
[0042] In one possible design, the first message contains information about the first vehicle model, or the first message contains business characteristic information used to indicate the first vehicle model information.
[0043] In further possible designs, the business characteristic information may include one or more of the following: the device identifier of the destination device in the first message, high-voltage signal, liquid cooling signal, and ignition signal.
[0044] In one possible design, the second control unit could be a relatively high-power component in the intelligent driving computing platform, such as a System-on-a-Chip (SoC).
[0045] In one possible design, the first vehicle model information is saved, specifically by storing the first vehicle model information locally in the first control unit, which is different from the second control unit.
[0046] In further designs, the first control unit can be a relatively low-power component in the intelligent driving computing platform, such as an MCU.
[0047] In one possible design, the second control unit is powered on based on the first vehicle model information. Specifically, this can be achieved by receiving a first power-on command and powering on the second control unit when the first power-on command matches the second power-on command for the vehicle model corresponding to the first vehicle model information.
[0048] In a further possible design, after the second control unit is powered on, it can also receive a second message from the diagnostic equipment, which contains the second vehicle model information, and the second vehicle model information becomes effective.
[0049] In a further possible design, the second vehicle information corresponds to the official vehicle, including the vehicle model and related details.
[0050] In a further possible design, the activation of the second vehicle model information includes: if the second vehicle model information is different from the locally stored vehicle model information, then the second vehicle model information is stored locally and the first control unit is restarted. This restart is used to activate the software package of the vehicle model corresponding to the second vehicle model information, wherein the first control unit is different from the second control unit.
[0051] In a further possible design, the first control unit could be an MCU in the intelligent driving computing platform, and the second control unit could be an ECU other than the first control unit in the intelligent driving computing platform, such as a SOC, another MCU, or another ECU.
[0052] In one possible design, the first control unit, which is different from the second control unit, can be woken up before the first message is received.
[0053] In one example of the above design, waking up the first control unit can be achieved by either waking up the first control unit via the adaptive cruise control (ACC) power line or by waking up the first control unit via a first wake-up command.
[0054] Based on the above design, the first control unit can be woken up via the ACC power line or a wake-up command according to the needs of the application scenario, which provides high flexibility.
[0055] In one example of the above design, the first control unit is woken up by the first wake-up command. Specifically, the first wake-up command is received. If the current mode of the vehicle is platform mode, the first control unit is woken up. If the current mode of the vehicle is vehicle model mode, the first control unit is woken up when the first wake-up command matches the second wake-up command of the vehicle model corresponding to the vehicle model mode. Here, platform mode is the mode when the vehicle is not configured with a vehicle model, and vehicle model mode is the mode after the vehicle is configured with a vehicle model.
[0056] In a further example, when the current mode is platform mode, the first control unit is allowed to send messages from the whitelist; when the current mode is vehicle model mode, the first control unit is allowed to send messages that correspond to the vehicle model.
[0057] In a further example, the messages in the whitelist include upgrade messages and / or diagnostic messages.
[0058] In a further example, in response to the operation of starting the first control unit, the vehicle model information stored locally is obtained. If the vehicle model information is stored locally, the current mode of the vehicle is configured as the vehicle model mode, the wake-up command corresponding to the vehicle model information is activated, and the message sending switch corresponding to the vehicle model information is turned on. If the vehicle model information is not stored locally, the current mode of the vehicle is configured as the platform mode, the wake-up command for all vehicle models is activated, and the message sending switch in the whitelist is turned on.
[0059] Thirdly, this application provides an in-vehicle processing device that has the function of implementing the method of the first aspect or any of the designs in the first aspect, or has the function of implementing the method of the second aspect or any of the designs in the second aspect. For example, the in-vehicle processing device includes modules, units, or means for performing the operations involved in the methods of the first aspect or any of the designs or examples in the first aspect, or includes modules, units, or means for performing the operations involved in the methods of the second aspect or any of the designs or examples in the second aspect. Specifically, the module, unit, or means can be implemented by software, by hardware, or by a combination of software and hardware.
[0060] Fourthly, this application provides an in-vehicle processing device, which includes an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer programs or instructions for implementing the functions involved in the methods of the first aspect or any of the designs or examples of the first aspect, or stores part or all of the necessary computer programs or instructions for implementing the functions involved in the methods of the second aspect or any of the designs or examples of the second aspect. The one or more processors can execute the computer programs or instructions, and when the computer programs or instructions are executed, cause the in-vehicle processing device to implement the methods of the first aspect or any of the designs or examples of the first aspect, or implement the methods of the second aspect or any of the designs or examples of the second aspect. The interface circuit is used to implement communication functions within the in-vehicle processing device and / or communication functions between the in-vehicle processing device and other devices or components.
[0061] In one possible design, the communication interface can be a transceiver, or an input / output interface. Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.
[0062] In another possible design, when the on-board processing device is a chip or chip system, the communication interface can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip or chip system. The processor can also be manifested as a processing circuit or logic circuit.
[0063] The above-mentioned on-board processing device may be a control unit in the vehicle, or a module (such as a processor, chip or chip system) in the control unit, or a logic node, logic module or software that can realize all or part of the controller functions.
[0064] Fifthly, this application provides an intelligent driving computing platform that has the functionality to implement the method of the first aspect or any one of the designs described above, or has the functionality to implement the method of the second aspect or any one of the designs described above. Alternatively, the intelligent driving computing platform includes an on-board processing device as described in the third aspect or any one of the designs described above, or includes an on-board processing device as described in the fourth aspect or any one of the designs described above.
[0065] Optionally, the on-board processing device can be an intelligent driving computing platform or a component thereof. For example, it can be any electronic control unit in the intelligent driving computing platform, including but not limited to: a mobile data center (MDC), an MCU, a SOC, or other electronic control units. The MCU and the SOC are two different chips in the MDC. When the MDC implements the function of the method in any of the designs or examples of the first or second aspect described above, it can be considered that the MCU and the SOC are combined to implement the method in any of the designs or examples of the first or second aspect described above.
[0066] Sixthly, this application provides an in-vehicle processing system, including an in-vehicle processing device as described in the third aspect or any of the designs in the third aspect, or including an in-vehicle processing device as described in the fourth aspect or any of the designs in the fourth aspect, or including an intelligent driving computing platform as described in the fifth aspect or any of the designs in the fifth aspect.
[0067] Optionally, the vehicle processing system may further include a gateway connected to the vehicle processing device for sending one or more of the first wake-up command, the first power-on command, and the first message mentioned above to the vehicle processing device. The vehicle processing device wakes up the first control unit according to the first wake-up command, configures the temporary vehicle model according to the first message, and powers on the second control unit according to the first power-on command.
[0068] Optionally, the first control unit is the MCU in the intelligent driving computing platform, and the second control unit is another ECU in the intelligent driving computing platform besides the MCU, such as the SOC.
[0069] Optionally, the on-board processing system may also include a diagnostic device connected to the on-board processing unit for sending the second message mentioned above to the on-board processing unit. The second message includes second vehicle model information, and the on-board processing unit configures the official vehicle model based on the second vehicle model information.
[0070] Seventhly, this application provides a vehicle including an on-board processing device as described in the third aspect or any of the designs in the third aspect, or including an on-board processing device as described in the fourth aspect or any of the designs in the fourth aspect, or including an intelligent driving computing platform as described in the fifth aspect or any of the designs in the fifth aspect, or including an on-board processing system as described in the sixth aspect or any of the designs in the sixth aspect.
[0071] Eighthly, this application provides a computer-readable storage medium storing computer-readable instructions that, when read and executed by a computer, cause the computer to perform the method described in the first aspect or any of the designs or examples of the first aspect, or to perform the method described in the second aspect or any of the designs or examples of the second aspect.
[0072] Ninthly, this application provides a computer program product that, when read and executed by a computer, causes the computer to perform the method described in the first aspect or any of the designs or examples of the first aspect, or to perform the method described in the second aspect or any of the designs or examples of the second aspect.
[0073] In a tenth aspect, this application provides a chip for reading a computer program stored in a memory and executing the method described in the first aspect or any of the designs or examples of the first aspect, or executing the method described in the second aspect or any of the designs or examples of the second aspect. Optionally, the chip may include a processor coupled to the memory, for reading the computer program stored in the memory and implementing the method described in the first aspect or any of the designs or examples of the first aspect, or implementing the method described in the second aspect or any of the designs or examples of the second aspect. Optionally, the chip may also include components such as a memory, a communication interface, and a power supply module. The memory is used to store the computer program; the communication interface is used to receive and send data; and the power supply module is used to supply power to the processor.
[0074] Eleventhly, this application provides a chip system including a processor for supporting a computer in implementing the methods of the first aspect or any of the designs or examples of the first aspect, or in implementing the methods of the second aspect or any of the designs or examples of the second aspect. In one possible design, the chip system further includes a memory for storing necessary programs and data for the computer. The chip system may be composed of chips or may include chips and other discrete devices.
[0075] The technical effects that can be achieved in the second to eleventh aspects mentioned above can be referred to the description of the beneficial effects in the first aspect mentioned above, and will not be repeated here. Attached Figure Description
[0076] Figure 1 illustrates a possible system architecture applicable to this application;
[0077] Figure 2a illustrates, for example, different configurations of different vehicle models provided in this application;
[0078] Figure 2b illustrates an exemplary schematic diagram of one software package per vehicle model provided in this application;
[0079] Figure 2c illustrates a schematic diagram of the vehicle manufacturing process for a multi-model shared software package provided in this application;
[0080] Figure 2d illustrates a schematic diagram of a vehicle configuration method for a multi-vehicle shared software package provided in this application;
[0081] Figure 2e illustrates a vehicle configuration diagram of an intelligent driving computing platform provided in this application;
[0082] Figure 3 illustrates a schematic flowchart of an in-vehicle processing method provided in this application;
[0083] Figure 4a illustrates an exemplary schematic diagram of the format of a first message provided in this application;
[0084] Figure 4b illustrates an exemplary schematic diagram of another first message format provided in this application;
[0085] Figure 5 illustrates an exemplary initialization process diagram of an intelligent driving computing platform provided in this application;
[0086] Figure 6 illustrates an exemplary wake-up process diagram of an intelligent driving computing platform provided in this application;
[0087] Figure 7 illustrates, for example, a module flow diagram of an intelligent driving computing platform provided in this application in two modes;
[0088] Figure 8 illustrates, for example, a vehicle configuration process diagram of an intelligent driving computing platform provided in this application;
[0089] Figure 9 illustrates, for example, a vehicle configuration process diagram of another intelligent driving computing platform provided in this application;
[0090] Figure 10 illustrates, for example, a power-on process diagram of an intelligent driving computing platform provided in this application;
[0091] Figure 11 illustrates an exemplary schematic diagram of the module implementation of three vehicle configuration methods provided in this application;
[0092] Figure 12 illustrates an exemplary module implementation process in the prior art for waking up the MCU and powering on / off the SOC via messages;
[0093] Figure 13a illustrates a schematic diagram of the module flow of an on-board processing method provided in Implementation Scheme 1;
[0094] Figure 13b illustrates an exemplary execution flow diagram of an on-board processing method provided in Implementation Scheme 1;
[0095] Figure 14a illustrates a schematic diagram of the module flow of an on-board processing method provided in Implementation Scheme 2;
[0096] Figure 14b illustrates an exemplary execution flow diagram of an on-board processing method provided in Implementation Scheme 2;
[0097] Figure 15 illustrates a flowchart of another vehicle-mounted processing method provided in this application;
[0098] Figure 16 illustrates an exemplary module implementation flow of hard-wired wake-up of the MCU and power-on / off SOC in the prior art.
[0099] Figure 17a illustrates, for example, a schematic diagram of the module flow of an on-board processing method provided in Implementation Scheme 3;
[0100] Figure 17b illustrates an exemplary execution flow diagram of an on-board processing method provided in Implementation Scheme 3;
[0101] Figure 18a illustrates a schematic diagram of the module flow of an on-board processing method provided in Implementation Scheme 4;
[0102] Figure 18b illustrates an exemplary execution flow diagram of an on-board processing method provided in Implementation Scheme 4;
[0103] Figure 19 illustrates an exemplary schematic diagram of a module architecture for implementing an in-vehicle processing method provided in this application;
[0104] Figure 20 illustrates a possible structural diagram of an on-board processing device provided in this application;
[0105] Figure 21 illustrates a possible structural diagram of another vehicle-mounted processing device provided in this application;
[0106] Figure 22 illustrates a possible structural schematic diagram of another vehicle-mounted processing device provided in this application;
[0107] Figure 23 illustrates a possible structural diagram of an in-vehicle processing system provided in this application. Detailed Implementation
[0108] The in-vehicle processing solution provided in this application can be applied to vehicle-to-everything (V2X) networks, such as vehicle-to-everything (V2X), long-term evolution-vehicle (LTE-V) communication, and vehicle-to-vehicle (V2V) communication. For example, it can be applied to vehicles with communication capabilities, or to devices within vehicles that have communication capabilities. These devices include, but are not limited to, in-vehicle terminals, in-vehicle controllers, in-vehicle computing platforms, in-vehicle modules, in-vehicle components, in-vehicle chips, in-vehicle units, in-vehicle radar, or in-vehicle cameras, and other sensors. Vehicles can implement the in-vehicle processing method provided in this application through these in-vehicle terminals, controllers, modules, components, chips, units, radar, or cameras. Alternatively, the in-vehicle processing solution provided in this application can also be used in other intelligent terminals with communication capabilities besides vehicles, or installed in other intelligent terminals with communication capabilities besides vehicles, or installed in components of such intelligent terminals. These intelligent terminals can be intelligent transportation equipment, smart home devices, robots, etc. Examples include, but are not limited to, smart terminals or controllers, chips, radar or cameras, and other sensors and components within smart terminals.
[0109] The in-vehicle processing solution provided in this application will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.
[0110] Figure 1 is a schematic diagram of a possible system architecture applicable to this application, which includes a diagnostic device 110 and a vehicle 120. Optionally, it may also include a host computer (not shown in the figure). The host computer is located one level above the diagnostic device 110 and is mainly responsible for issuing control commands to the diagnostic device 110 to drive the diagnostic device 110 to complete diagnostic and maintenance operations on the vehicle 120. The host computer is generally a personal computer (PC), a host computer / master computer, or an upper computer. The screen displays various signal changes of the lower-level device, such as signals indicating successful wake-up, successful power-on, power level, hydraulic pressure, water level, and temperature, so that diagnostic personnel can view them in a timely manner and quickly determine the configuration effect and corresponding measures. The lower-level device here is the controlled device, namely the vehicle 120 shown in Figure 1.
[0111] The diagnostic device 110 mentioned above can refer to a diagnostic instrument, a diagnostic server, or a diagnostic server cluster. Diagnostic device 110 is an instrument for diagnosing the electronic brake-force distribution (EBD) system, primarily responsible for diagnosis and maintenance. Diagnostic device 110 typically has a diagnostic cable, and vehicle 120 has a pre-installed diagnostic interface. When diagnostics or maintenance of vehicle 120 components is required, diagnostic personnel can insert one end of the diagnostic cable from diagnostic device 110 into the diagnostic interface of vehicle 120, and then input configuration commands on the host computer to transmit the configuration commands to diagnostic device 110, which in turn sends them to vehicle 120 via the diagnostic cable. The diagnostic interface can refer to a unified diagnostic services (UDS) interface, an on-board diagnostics (OBD) interface, or any other interface capable of command transmission. The diagnostic interface is configured in the vehicle's diagnostic (DIAG) component, working in conjunction with pre-built diagnostic protocols to achieve the diagnosis and configuration of in-vehicle components, such as vehicle model configuration.
[0112] In some scenarios, the diagnostic device 110 and the vehicle 120 can also be connected wirelessly. Wireless methods can include mobile communication networks (such as 5G or future communication networks), wireless local area networks (WLANs), or short-range communication technologies. Short-range communication technologies here refer to technologies where the communicating parties transmit information via radio waves over a short distance (e.g., within 100 meters), including but not limited to: Bluetooth, Wi-Fi, Near Field Communication (NFC), Wi-Fi Aware, general short-range communication technologies, and short-range communication technologies specified by the Starlight Alliance.
[0113] The above 120 vehicles include any type of vehicle capable of communication. Examples include intelligent vehicles, electric vehicles, digital cars, sedans, trucks, motorcycles, buses, lawnmowers, recreational vehicles, amusement park vehicles, construction equipment, trams, or golf carts. These vehicles can be pure electric vehicles (pure EV / battery EV), hybrid electric vehicles (HEV), range-extended electric vehicles (REEV), plug-in hybrid electric vehicles (PHEV), other new energy vehicles (NEV), or gasoline-powered vehicles. These vehicles can be used in areas such as intelligent driving, assisted driving, or connected vehicles.
[0114] For example, as shown in Figure 1, vehicle 120 may include N functional domains, where N is an integer greater than or equal to 2. These N functional domains may include, but are not limited to, the following: Power Domain, Body Domain, Chassis Domain, Cabin Domain, Intelligent Vehicle Domain, and Network Connected Domain. Each functional domain includes multiple ECUs, one of which acts as a domain controller, connecting (also called sub-controllers) to the other ECUs. The domain controller contains domain control software, which, by controlling the sub-controllers, enables the implementation of the corresponding functional domain's functions. For instance, the Power Domain controller is the core of the vehicle's powertrain system; by controlling its sub-controllers such as the engine and transmission, it provides the vehicle with robust power output. The Body Domain controller safeguards vehicle stability and safety; by controlling its sub-controllers such as door locks, lights, wipers, and window locks, it provides passengers with a higher level of driving safety and a more comfortable experience. The chassis domain controller is the core of vehicle handling performance. By controlling its subordinate suspension and steering systems, it enables stable handling and precise driving. The cockpit domain controller is crucial for creating a comfortable driving environment. By controlling its subordinate audio acquisition components, seat adjustment components, and air conditioning, it enables human-vehicle interaction, voice control, intelligent reminders, and intelligent monitoring, providing a highly personalized and comfortable driving experience. The intelligent driving domain controller is the core of intelligent driving. By controlling its subordinate radar and camera modules, it collects environmental and road information, enabling intelligent assisted driving functions such as autonomous driving, driver assistance, and valet parking, bringing users a completely new driving experience. The connectivity domain controller is the core of vehicle networking. By controlling its subordinate communication modules, it enables vehicle networking, historical data reporting, and emergency call functions.
[0115] As shown in Figure 1, the vehicle 120 may also include components such as a telematics box (T-Box) and a gateway (GW). The T-Box is used to enable information interaction between the vehicle 120 and other devices. For example, the vehicle 120 can connect to the diagnostic device 110, user terminal, cloud server, and other vehicles through the T-Box. Based on this connection, the vehicle 120 can send information to the diagnostic device 110, user terminal, cloud server, and other vehicles, and can also receive information sent by the diagnostic device 110, user terminal, cloud server, and other vehicles. The GW, as the vehicle's communication gateway, supports one or more components in the vehicle's integrated hardware and software platform, i.e., the vehicle computing platform, such as the mobile data center (MDC), human-machine interaction (HMI), telematics control unit (TCU), T-Box, vehicle integrated / integration unit (VIU), vehicle domain controller (VDC), the above domain controllers, or other ECUs. The GW is a core component in the vehicle's electronic and electrical architecture. As the data interaction hub of the vehicle network, it can route network data from different networks, such as the controller area network (CAN), local interconnect network (LIN), and media-oriented system transport (MOST) network.
[0116] It should be noted that the form and quantity of the diagnostic device 110 and vehicle 120 shown in Figure 1 are for illustrative purposes only and do not constitute a limitation on this application. Furthermore, the architecture shown in Figure 1 may include other devices besides the diagnostic device 110 and vehicle 120, such as supplier equipment, manufacturer equipment, production line equipment, and sales equipment; this application does not specifically limit these. Also, the diagnostic device 110 in this application can integrate all functions onto a single physical device, or it can distribute functions across multiple independent physical devices, or it can be functionally divided software or a combination of software and hardware; this application does not specifically limit these.
[0117] Based on the system architecture shown in Figure 1, the background technology involved in this application will be introduced below.
[0118] Among the many functional domains of a vehicle, the intelligent driving domain is particularly important. Also known as the intelligent driving computing platform, the intelligent driving domain is the "brain" of the car, enabling functions such as panoramic perception, map and sensor fusion positioning, decision-making, planning, and control. Its performance directly affects driving comfort and safety, and it has become one of the basic configurations of a car.
[0119] Intelligent driving computing platforms are applicable to various scenarios, such as traffic jam following, highway cruising, and automated valet parking for passenger vehicles; port freight and long-haul logistics for commercial vehicles; and mining trucks, cleaning vehicles, and unmanned delivery vehicles. These platforms not only need to interface with other ECUs within the vehicle but also require external sensors to acquire input data. Based on this data, they perform algorithmic decision-making, planning, and control to achieve intelligent driving.
[0120] However, as shown in Figure 2a, due to differences in corporate logos among different automakers, vehicles produced by different automakers have different models. These different models differ in their electrical / electronic architecture (EE / EEA), sensor selection, communication matrices, and application functional safety level requirements (such as vehicle mode (VM)). Therefore, the customization and adaptation workload for each automaker's new models is enormous. To reduce this workload, different models from various automakers need to support a series of hardware. However, because different hardware differs in computing power and resources, number of chips, input-output (IO) interfaces, and internal interconnection methods, the software package capabilities available for each model need to be tailored to match its specific vehicle type. For example, for intelligent driving computing platforms, due to differences in other ECUs, external sensors, and functions that interface with the platform across different vehicle models, coupled with varying delivery schedules for each model, currently, a separate software upgrade package for the intelligent driving computing platform is typically released for each model. For example, as shown in Figure 2b, a vehicle upgrade package 1 for the intelligent driving computing platform is released for vehicle model 1, a vehicle upgrade package 2 for the intelligent driving computing platform is released for vehicle model 2, and so on, with a vehicle upgrade package M for the intelligent driving computing platform released for vehicle model M. Managing so many vehicle upgrade packages presents a huge challenge, both in terms of version control and spare parts standardization.
[0121] To cope with the rapid release of software packages for a large number of vehicle models, improve R&D efficiency, and reduce maintenance costs, it is hoped that a strategy and solution of sharing software packages across multiple vehicle models can be adopted to reduce maintenance versions. The vehicle preparation process for sharing software packages across multiple vehicle models can be seen in Figure 2c. Assuming that the same software package is to be used for the intelligent driving computing platform of both sedans and SUVs, the entire preparation process includes the following four steps:
[0122] The first step is to manufacture intelligent driving computing platform equipment for cars and intelligent driving computing platform equipment for SUVs on the equipment manufacturing line and ship them to the OEM R&D line.
[0123] The second step involves creating a shared software package for both sedans and SUVs on the OEM R&D line. This package is then pre-installed into the intelligent driving computing platform devices for both sedans and SUVs in a pre-built installation environment. The intelligent driving computing platform devices with the shared software package are then shipped to the OEM production line. This shared software package supports the full set of capabilities for multiple vehicle models, as shown in Figure 2d(A). Essentially, it integrates capability releases for multiple vehicle models into the software package, allowing the platform delivery packages for models 1 through M to contain the same software package. During the manufacturing phase, multiple models 1 through M share a single software version, and during upgrades, a unified upgrade package can be released.
[0124] The third step is to assemble the intelligent driving computing platform equipment with other vehicle equipment into a complete vehicle on the OEM production line to obtain sedans and SUVs. The software package in the current sedans and SUVs is not yet effective.
[0125] The fourth step involves the OEM production line, during the in-system testing phase, using a diagnostic tool to issue vehicle configuration words to sedans and SUVs. This allows the sedans and SUVs to identify their respective models and activate the corresponding capability sets. For example, issuing a vehicle configuration word enabling model 1 to a sedan activates the capability set of model 1 in the software package, and issuing a vehicle configuration word enabling model 2 to an SUV activates the capability set of model 2 in the software package. Optionally, as shown in Figure 2d(B), the issued vehicle configuration words can be sent to the database in the intelligent driving computing platform via DIAG for persistent storage and can be retrieved by the application (APP) in the intelligent driving computing platform to enable the software version matching the vehicle model.
[0126] Based on the above preparation process, a multi-vehicle shared software package can be implemented, supporting rapid vehicle replication and reducing maintenance versions. However, at present, the multi-vehicle shared software package is only an ideal solution and is not easy to implement. This is mainly because before diagnosing and configuring the vehicle in the fourth step mentioned above, it is necessary to wake up and power on the ECU in the intelligent driving computing platform. However, the wake-up and power-on messages corresponding to different vehicle models are somewhat different. If the vehicle model is not successfully configured, the wake-up and power-on messages in the shared software package are inconsistent with the actual vehicle model, causing the ECU in the intelligent driving computing platform to fail to be woken up normally, and thus the vehicle model cannot be successfully configured.
[0127] For example, referring to Figure 2e, current intelligent driving computing platforms generally have two types of ECUs: MCUs and SOCs. These two ECUs are combined to form the mobile data center (MDC) of the intelligent driving computing platform. An MCU is a monolithic integrated circuit that integrates a processor core (usually a microprocessor), memory (such as flash memory and random access memory, RAM), and I / O interfaces. It has limited processing power and memory and storage resources, but high reliability. It is mainly responsible for performing real-time vehicle control tasks, such as engine control, braking systems, and steering systems, ensuring the safe and reliable operation of the vehicle's basic functions. An SOC, on the other hand, is an integrated circuit that integrates all components of a computer or electronic system onto a single chip, including a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), memory, peripheral devices, and interfaces. It possesses powerful computing and data processing capabilities, as well as a large amount of memory and storage. It is mainly responsible for processing large amounts of data from sensors such as cameras, radar, and lidar, running deep learning algorithms, and performing object recognition, environmental perception, decision-making, and planning. Because of the high integration of SOCs, their design and verification are more complex, requiring additional security mechanisms to ensure reliable system operation. Therefore, existing intelligent driving computing platforms integrate both SOCs and MCUs. The MCU serves as the chip platform for the safety subsystem, while the SOC serves as the operating platform for intelligent driving applications, in order to accommodate the minimum guarantee of safe parking and considerations for the intelligent driving ecosystem.
[0128] Based on the intelligent driving computing platform shown in Figure 2e and the architecture shown in Figure 1, in the normal wake-up and power-on process, the vehicle needs to be started first, for example, by powering the vehicle with a key. After the vehicle is powered on, the T-BOX is woken up. The T-BOX sends wake-up messages and power-on messages (such as ignition signals, high-voltage signals, etc.) to the vehicle gateway GW. The GW broadcasts the wake-up messages and power-on messages to the controller area network (CAN) bus or other buses, thereby publishing them to the MCU in the intelligent driving computing platform. After receiving the wake-up messages and power-on messages, if the MCU determines that they are consistent with the currently effective wake-up messages and power-on messages, it wakes up the internal components and powers on the components in the SOC. The power-down operation of the SOC is similar. Only when the power-down message is consistent with the currently effective power-down message will the MCU power down the components in the SOC, thereby powering down the SOC.
[0129] Due to enterprise standards, the wake-up and power-on / off messages for different vehicle models typically differ. Each MCU uses its own specific wake-up and power-on / off messages corresponding to its vehicle model. For example, the MCU for vehicle model 1 uses wake-up message 0x41 and power-on / off message 0x312, the MCU for vehicle model 2 uses wake-up message 0x42 and power-on / off message 0x313, and so on. The MCU for vehicle model M uses wake-up message 0x4M and power-on / off message 0x31M. Therefore, when each vehicle model has its own independent software package, there is only one software package per vehicle. This package is specifically designed for the vehicle model, and the wake-up and power-on / off messages contained within it are those specific to its vehicle model. By matching the software package version with the vehicle model, the wake-up and power-on / off messages received by the MCU are consistent with its own active wake-up and power-on / off messages, thus enabling the MCU to wake up and the SOC to power on / off normally.
[0130] However, if multiple vehicle models share the same software package, the vehicle model or capability set of the software package shipped from the factory may not be consistent with the actual vehicle model produced. For example, as shown in Figure 2e, if the default software package is for vehicle model 1, then the wake-up message and power-on / off message received by the gateway of each vehicle will be wake-up message 0x41 and power-on / off message 0x312 for vehicle model 1. Only the wake-up message 0x41 and power-on / off message 0x312 effective for the MCU of vehicle model 1 match the wake-up message 0x41 and power-on / off message 0x41 received by the MCU, thus enabling normal wake-up of the MCU and power-on / off of the SOC. However, the wake-up message and power-on / off message effective for the MCUs of vehicles models 2 to M are inconsistent with the wake-up message and power-on / off message actually received by the MCU. This causes vehicles of models 2 to M to be unable to properly wake up the MCU and power on / off the SOC. Therefore, after the intelligent driving computing platform devices of models 2 to M are released to the OEM production line, even if the diagnostic equipment sends the vehicle configuration word to the SOC, the SOC cannot configure the correct vehicle model according to the vehicle configuration word because the SOC is not powered on normally, thus forming an infinite loop.
[0131] In summary, according to existing wake-up and power-on solutions, if intelligent driving computing platforms of different vehicle models share the same software upgrade package, the sleep / wake-up and power-on messages of the intelligent driving computing platforms of different models will be different, leading to problems such as the inability to properly wake up the MCU and power on the SOC. Therefore, to implement a solution for sharing software packages across multiple vehicle models, the following two technical problems must be solved:
[0132] Problem 1: When the same upgrade package is configured on different vehicle models, the wake-up messages for the MCU may differ between models, necessitating a solution for ensuring proper MCU wake-up. Without a clearly defined vehicle model, if the wake-up message sent externally (e.g., from the vehicle gateway) doesn't match the specific wake-up message for that model, the MCU cannot be woken up correctly. However, since the customer's model is already commercially available or their company standards are fixed, it's impossible to persuade them to modify the wake-up message for that model. Therefore, ensuring proper MCU wake-up before configuring the vehicle model is a crucial issue to address. Furthermore, it's necessary to consider the possibility that after MCU wake-up, if the messages sent externally by the intelligent driving computing platform don't match the vehicle's specifications, it could cause the vehicle's CAN bus to hang.
[0133] Question 2: Before a specific vehicle model is defined for the intelligent driving computing platform, if the power-on message sent by an external source (such as the vehicle gateway) to the SOC is incorrect, it's impossible to safely power on the SOC. If the vehicle model is already commercially available or the enterprise standard is finalized, the power-on message and electrical testing station for that model cannot be modified. Powering on the SOC using arbitrary messages could lead to risks such as disk drops and vehicle power failure. Furthermore, besides powering on the SOC, other modules also need to recognize the vehicle model differences to function properly. Therefore, how to safely power on the SOC or other control units besides the MCU after waking it up is also a problem that needs to be solved.
[0134] In response to this, this application provides an in-vehicle processing method that supports any wake-up message to wake up the first control unit (such as an MCU) when no vehicle model is configured, and supports configuring the vehicle model through vehicle model notification messages or service feature messages sent through a gateway, thereby powering on the second control unit (such as a SOC or other control units besides the MCU) normally. However, after the vehicle model is configured, only the wake-up message corresponding to the vehicle model is supported to wake up the first control unit, and the power-on message corresponding to the vehicle model is supported to power on the second control unit.
[0135] The above solutions can be deployed in intelligent driving computing platforms or their products. When using a multi-vehicle shared software package in intelligent driving scenarios, even if the sleep wake-up and power-on message mechanisms of different vehicle models are different, the intelligent driving products can still be woken up and powered on normally, solving the current technical limitations of multi-vehicle shared software packages, while also meeting the requirements of car manufacturers for safe wake-up and safe power-on.
[0136] Based on the above, the in-vehicle processing method provided in this application will be described in detail below with reference to the specific accompanying drawings.
[0137] Please refer to Figure 3, which illustrates a possible flowchart of an in-vehicle processing method provided in this application. This method can be executed by a vehicle, and more specifically, by any computing platform with computing capabilities within the vehicle, such as an intelligent driving computing platform, a gatekeeper (GW), a T-Box, an in-vehicle controller, an in-vehicle intelligent driving computing platform product, or a computing platform with other functional domains.
[0138] For ease of understanding, the following description uses an intelligent driving computing platform to perform on-board processing as an example. However, this intelligent driving computing platform can also be replaced by any other on-board computing platform with computing capabilities. This application does not make any specific limitations on this.
[0139] As shown in Figure 3, the method includes the following steps:
[0140] Step 301: Receive the first wake-up command.
[0141] Optionally, the intelligent driving computing platform receives a first wake-up command sent from outside the intelligent driving computing platform. For example, it may receive a first wake-up command from a gateway, or a first wake-up command loaded from an external tool; there are no limitations on this.
[0142] In one example, combining Figures 1, 2c, and 2e above, on the OEM R&D line, R&D personnel can wake up the T-Box in the vehicle by starting the vehicle, and the T-Box sends the first wake-up command to the intelligent driving platform through the GW.
[0143] Optionally, the intelligent driving computing platform includes a small module that remains in a dormant state, possessing communication and message parsing capabilities. Even before other components in the intelligent driving computing platform are activated, any message sent to the platform can be received by this small module. The module then parses the received message and executes corresponding operations based on the parsing results.
[0144] For ease of understanding, the following description uses the intelligent driving computing platform to perform on-board processing as an example. However, the operations of the intelligent driving computing platform can be replaced by the operations of this small module in the intelligent driving computing platform, and will not be repeated.
[0145] Step 302: Obtain the vehicle's current mode.
[0146] Optionally, the intelligent driving computing platform can obtain the vehicle's current mode from the local system. The vehicle's current mode can be platform mode or vehicle model mode. Platform mode is the mode before the vehicle is configured with a vehicle model, while vehicle model mode is the mode after the vehicle is configured with a vehicle model.
[0147] Optionally, the vehicle model can be configured in multiple ways. For example, the vehicle can be configured in default platform mode at the factory, and then the model can be configured according to the user's needs when the user purchases the vehicle, thus switching to model mode. Alternatively, the vehicle can enter the assembly stage on the production line before leaving the factory, and the model can be configured after the vehicle is fully assembled. In this case, the vehicle is already configured with a model at the factory and is in model mode. Alternatively, the user can configure the vehicle to either platform mode or model mode according to their needs during the usage phase, without any restrictions.
[0148] Step 303: Determine whether the vehicle's current mode is platform mode. If not, proceed to step 304; if yes, proceed to step 305.
[0149] Step 304: When the first wake-up command matches the second wake-up command corresponding to the vehicle model mode, the first control unit is woken up.
[0150] Optionally, in vehicle model mode, only the second wake-up command corresponding to that vehicle model mode is activated. For example, only the network management (NM) parameter in the wake-up message related to the second wake-up command is activated, while the NM parameters in wake-up messages related to other vehicle models are disabled. Based on this, upon receiving the first wake-up command, if the NM parameter of the first wake-up command is the same as the NM parameter of the second wake-up command, it indicates that the first and second wake-up commands match, and the first wake-up command is the wake-up command for the corresponding vehicle model. In this case, the intelligent driving computing platform can normally wake up the first control unit, that is, power on all components inside the first control unit normally. Conversely, if the NM parameter of the first wake-up command is different from the NM parameter of the second wake-up command, it indicates that the first and second wake-up commands do not match, and the first wake-up command is not the wake-up command for the corresponding vehicle model. In this case, to prevent the vehicle from being attacked after being illegally woken up, the intelligent driving computing platform may not wake up the first control unit, that is, it may not power on the components inside the first control unit. In other words, the intelligent driving computing platform can simply ignore the first wake-up command.
[0151] In one example, the intelligent driving platform can also return a message indicating whether the wake-up was successful or failed to the T-Box, so that the T-Box can perform the next operation based on the response. Optionally, if the first control unit fails to wake up, the intelligent driving computing platform can also record the relevant information about the wake-up failure in an error log, so that developers can review it and adjust the wake-up strategy in a timely manner.
[0152] In one example, after the first control unit is normally woken up in vehicle mode, the intelligent driving computing platform can also allow the first control unit to send messages, such as any type of message corresponding to the vehicle model. Since this message matches the vehicle's current configuration, it can be successfully parsed and received on the vehicle's CAN bus (or other types of bus) after being sent, thus preventing the CAN bus from becoming stuck.
[0153] In one example, after the first control unit is normally woken up in vehicle mode, the second control unit can also be powered on. The second control unit differs from the first control unit. The first control unit can be understood as a unit with relatively low power consumption, while the second control unit is understood as a unit with relatively high power consumption. For example, when the first control unit is an MCU in the intelligent driving computing platform, the second control unit can be any other control unit in the intelligent driving computing platform besides that MCU, such as a SOC, another MCU, or another ECU. Before the intelligent driving computing platform starts up, neither the first nor the second control unit is woken up. If a small module in the intelligent driving computing platform, which is in a dormant state, receives a first wake-up command and a first power-on command, it first wakes up the relatively low-power first control unit according to the first wake-up command, and then powers on the relatively high-power second control unit according to the first power-on command. This small module can be located within the first control unit, the second control unit, or other units, such as outside the first and second control units; there are no limitations.
[0154] Optionally, the sender of the first power-on command can be any device or tool. For example, the second control unit can be woken up by loading the first power-on command into the intelligent driving computing platform through an external tool such as a diagnostic tool, or by sending the first power-on command to the intelligent driving computing platform through an internal component such as a gateway. The latter method does not require an additional electrical testing station and has lower complexity in the wake-up operation.
[0155] For example, taking the gateway sending the first power-on command as an example, referring to Figure 1 above, the T-Box can also send the first power-on command to the intelligent driving computing platform through the GW. It should be understood that the first power-on command can be sent to the intelligent driving platform together with the first wake-up command, or the first wake-up command can be sent first and then the first power-on command; there is no limitation. Since the first control unit has already been woken up and the vehicle model has been configured, the intelligent driving computing platform can compare whether the first power-on command matches the second power-on command corresponding to the current vehicle model. For example, it can determine whether the relevant parameters in the first power-on command are the same as those in the second power-on command. If they are the same, it means that the first power-on command is the power-on command corresponding to the current vehicle model, and the intelligent driving computing platform can normally power on the second control unit, that is, power on the various components inside the second control unit. Conversely, if they are different, it means that the first power-on command is not the power-on command corresponding to the current vehicle model. In this case, to avoid damage caused by frequent power-on / off commands from non-current vehicle model components in the second control unit, the intelligent driving computing platform can choose not to power on the second control unit, that is, not power on the various components in the second control unit.
[0156] Based on the above, in vehicle model mode, that is, when the vehicle model has been configured, only the wake-up command corresponding to the vehicle model can normally wake up the first control unit, and only the power-on command corresponding to the vehicle model can normally power on the second control unit. In this way, the safety of waking up the first control unit and the safety of powering on the second control unit can be ensured.
[0157] Step 305: Wake up the first control unit.
[0158] Optionally, in platform mode, wake-up commands for all vehicle models are activated, for example, the NM parameters in the wake-up messages related to all wake-up commands are activated. Thus, upon receiving the first wake-up command, regardless of whether the first wake-up command is for a specific vehicle model, the NM parameters in the first wake-up command are already included in the currently activated NM parameters. Therefore, the intelligent driving computing platform can normally wake up the first control unit, that is, power on all components within the first control unit. Based on this, when the first control unit is the MCU in the intelligent driving computing platform, even when no vehicle model is specified, any type of wake-up command can normally wake up the MCU, thus providing support for MCU wake-up in scenarios where multiple vehicle models share the same software package.
[0159] Understandably, in platform mode, after the first control unit is woken up by any wake-up command, although the first control unit is woken up, the vehicle model has not yet been configured. If the intelligent driving computing platform sends a message to the outside world, the message is likely to be incompatible with the corresponding vehicle model. After the message enters the vehicle's CAN bus, it cannot be parsed and received, which will cause the entire vehicle's CAN bus to hang.
[0160] To avoid the aforementioned issues, in one example, after waking up the first control unit in platform mode, the intelligent driving computing platform can also prohibit the first control unit from sending messages, or only allow the first control unit to send messages from a whitelist. Here, messages in the whitelist can include upgrade messages and / or diagnostic messages, and optionally, other messages that are clearly free of security issues, such as messages that do not require consideration of the vehicle model. Thus, even if the first control unit is woken up before configuring the vehicle model, it can be ensured that the first control unit does not send messages incompatible with the vehicle model, avoiding a deadlock on the vehicle's CAN bus.
[0161] Optionally, after waking up the first control unit in platform mode, the vehicle model can also be configured. At this stage, since only the first control unit is awakened and the other control units in the intelligent driving computing platform (referred to as the second control unit) are not powered on, the vehicle model cannot be configured via diagnostic equipment. This is because the configuration method of diagnostic equipment requires the diagnostic equipment to send a vehicle model configuration word to the diagnostic interface in the vehicle. However, the diagnostic interface is located in the second control unit, and currently only the first control unit is awakened; the second control unit is not yet powered on. Therefore, the diagnostic interface cannot function. Based on this, to achieve vehicle model configuration, this application designs a first message to indicate vehicle model information, and designs a method for either external tools to load the first message into the intelligent driving computing platform, or for internal components such as a gateway to send the first message to the intelligent driving computing platform. The latter method does not require an additional electrical diagnostic station, and the complexity of vehicle model configuration is lower.
[0162] Taking the gateway sending the first message as an example, referring to Figure 1 above, after waking up the first control unit in platform mode, the T-Box can also send the first message to the intelligent driving computing platform via the GW. The first message is used to indicate the first vehicle model information. After receiving the first message, the intelligent driving computing platform parses the first message to obtain the first vehicle model information and saves it. Optionally, since the first control unit has been woken up, each module in the first control unit can work normally. Among them, the module related to the configured vehicle model can receive the first message, parse the first message to obtain the first vehicle model information, and store the first vehicle model information locally in the first control unit. In this way, the first control unit can determine the vehicle model based on the locally stored first vehicle model information, thereby providing support for the subsequent safe power-on of the second control unit.
[0163] The first message can explicitly indicate vehicle model information or indirectly indicate vehicle model information, corresponding to the following two message formats:
[0164] Message format one: The first message includes the first vehicle model information, which includes a clearly defined vehicle model.
[0165] As an example, the first message can be presented in the format shown in Figure 4a. This first message is specifically designed for vehicle model configuration and is a newly added message. Because this first message clearly indicates the vehicle model, it can also be called a specific vehicle model notification message.
[0166] Optionally, assuming the message is transmitted on the vehicle's CAN bus, the first message can specifically be a CAN message, such as a CAN data frame message or a CAN extended frame message. As shown in Figure 4a, the first message can include seven segments: start of frame (SOF), arbitration field (AF), control field (CF), data field (DF), cyclic redundancy check (CRC) segment, acknowledge (ACK) segment, and end of frame (EOF).
[0167] The frame start segment (SLS) is the segment indicating the beginning of a frame, typically a 1-bit dominant bit that identifies the start of a data frame. The arbitration segment indicates data priority, determining transmission priority based on the message identifier (ID); a smaller ID value indicates higher priority. The control segment indicates the number of valid bytes in the data segment, usually consisting of 6 bits. The data segment can contain 0 to 8 bytes of data, starting from the most significant bit (MSB). The CRC segment checks for transmission errors, typically consisting of a 15-bit CRC sequence and a 1-bit CRC delimiter. The CRC sequence is calculated based on all data preceding the CRC segment—the SLS, arbitration frame, control segment, and data segment. The CRC delimiter is always recessive and primarily used as a separator. The ACK segment confirms successful reception, including an acknowledgment bit and an acknowledgment separator. The frame end segment indicates the end of a frame, typically consisting of 7 recessive bits that identify the end of a data frame.
[0168] As shown in Figure 4a, the first vehicle model information can be carried in the data segment of the first message. This information includes the vehicle manufacturer and model, and optionally, sensor numbers and function switches. The sensor number refers to the code of the sensors connected to the vehicle, indicating the number of sensors connected and their respective sensor groups. The function switches indicate which functions the vehicle supports, such as whether it has advanced autonomous driving capabilities or a parking function. The sensor numbers and function switches are primarily designed to differentiate between different configurations of the same vehicle model. Even within the same model, there are high-end, mid-range, and low-end configurations. The number, type, and functions of the sensors connected to different configurations are usually different. Therefore, by combining the vehicle manufacturer, model, sensor number, and function, it is possible to identify which manufacturer, model, and configuration the current vehicle belongs to. This facilitates matching the wake-up command to the vehicle's configuration during the wake-up phase, improving wake-up security.
[0169] In some scenarios, information such as sensor numbers and function switches in the first message can also serve as functional extensions. For example, it can be designed to facilitate the vehicle to perform other functions based on this information, such as for communication and interaction between the vehicle and other devices.
[0170] Message format two: The first message includes business characteristic information, which is used to indicate the first vehicle model information.
[0171] As an example, the first message can be presented in the format shown in Figure 4b. This first message belongs to an existing type of service characteristic message, that is, a message transmitted during the process of a vehicle performing a service. Different vehicle models may have some differences in specific service characteristic information. Therefore, the specific service characteristic information in the existing message can be used to indirectly indicate which vehicle model the current vehicle belongs to.
[0172] As shown in Figure 4b, in the first message, service characteristic information can be carried in the data segment, including one or more of the following: high-voltage signal, liquid cooling signal, and ignition signal. Generally, the high-voltage signal, liquid cooling signal, and ignition signal are defined differently for different vehicle models. For example, the high-voltage signal for vehicle model 1 is defined as 0x110, while that for vehicle model 2 is defined as 0x120; the liquid cooling signal for vehicle model 1 is defined as 0x11, while that for vehicle model 2 is defined as 0x21; and the ignition signal for vehicle model 1 is defined as 0x1011, while that for vehicle model 2 is defined as 0x2011. Therefore, based on the high-voltage signal, liquid cooling signal, ignition signal, and other service characteristic information carried in the data segment of the first message sent by the vehicle, it is possible to indirectly indicate which vehicle model the current vehicle belongs to.
[0173] Optionally, service characteristic information can also be carried in the control segment, including the device ID of the destination device in the first message. In some scenarios, different vehicle models may use the same service characteristic signal in the data segment of the first message, but the ID of this service characteristic information in the control segment is different. For example, vehicle model 1 and vehicle model 3 both use the same liquid cooling signal 0x11, but the ID of this liquid cooling signal sent to vehicle model 1 is defined as 0x123, while the ID sent to vehicle model 2 is defined as 0x213. In this scenario, the liquid cooling signal in the data segment of the first message alone cannot distinguish between vehicle model 1 and vehicle model 3. It is necessary to combine the ID in the control segment and the liquid cooling signal in the data segment to accurately distinguish between vehicle model 1 and vehicle model 3.
[0174] It should be emphasized that Figure 4b above only provides some possible service characteristic signals as examples. However, this application does not limit the service characteristic information used to identify vehicle models to these signals only. It can also be any other service characteristic signal or a combination of one or more of them. As long as the service characteristic signal can differ across different vehicle models, or in other words, any difference in existing service messages, it can be used as a mechanism for identifying vehicle models. This application does not make any specific limitations in this regard.
[0175] In addition, Figures 4a and 4b above and related content only show two possible message formats that can indicate the information of the first vehicle model. These two message formats are only used as examples of CAN communication mechanism to introduce two CAN messages. However, other message formats can also be used in actual vehicle scenarios. For example, they may be non-CAN messages, such as ETH or other types of messages. This application does not make specific limitations on this.
[0176] Optionally, after waking up the first control unit and saving the first vehicle model information in platform mode, the second control unit can also be powered on. The second control unit is a control unit in the intelligent driving computing platform other than the first control unit. For example, it may include a control unit with higher power consumption than the first control unit, or a control unit that needs to sense vehicle model differences to function properly. For instance, when the first control unit is an MCU in the intelligent driving computing platform, the second control unit could specifically be a SOC in the intelligent driving computing platform, a higher-power MCU, or an ECU that only functions after configuring the vehicle model.
[0177] It should be noted that the operation to wake up the first control unit is set before saving the first vehicle model information, while the operation to power on the second control unit is set after saving the first vehicle model information. This is mainly to consider the wake-up success rate of the first control unit and the power-on safety of the second control unit. The first control unit is a relatively small microcontroller with low security and low power consumption. It can be woken up with just a low voltage input. Therefore, the first control unit can be woken up using any wake-up message to ensure a high wake-up success rate. However, the second control unit is a more complex chip with high power consumption and high software system requirements, making it very susceptible to damage. If the second control unit is triggered by any power-on / off message before saving the first vehicle model information, the frequent arrival of power-on / off messages can easily lead to frequent power-on / off cycles of the second control unit, thereby damaging the file system of the second control unit and causing serious safety problems, such as disk drops and vehicle power failure. Therefore, the second control unit cannot be triggered by any power-on / off message; it must be powered on and off only after saving the first vehicle model information.
[0178] Based on this, this application sets the entire processing logic of the intelligent driving computing platform as follows: first, wake up the first control unit; then, configure the first vehicle model information via the first message; and finally, power on the second control unit. Specifically, after waking up the first control unit in platform mode and storing the first vehicle model information locally in the first control unit, the intelligent driving computing platform can also receive a first power-on command and determine whether the first power-on command matches the second power-on command corresponding to the first vehicle model information stored locally in the first control unit. If they match, it means that the first power-on command is the power-on command corresponding to the currently saved first vehicle model information, and not an attack command. Therefore, the intelligent driving computing platform can power on each component in the second control unit, thereby normally powering on the second control unit. If they do not match, the first power-on command is ignored. In this way, the intelligent driving computing platform will only normally power on the second control unit when the sent power-on command matches the power-on command corresponding to the saved vehicle model information, thereby avoiding attacks using non-vehicle model matching messages and ensuring the security of the second control unit during power-on.
[0179] Optionally, the vehicle model information can correspond to either a formal vehicle model or a temporary vehicle model. A formal vehicle model is the vehicle model itself, a clearly defined model. A temporary vehicle model, on the other hand, is a model temporarily configured for the safe power-on of the second control unit; this model may or may not be the same as the vehicle's original model. Therefore, if the first vehicle model information stored in the first message is a formal vehicle model, then after powering on the second control unit based on the first vehicle model information, the vehicle is already under its designated model and does not require reconfiguration via diagnostic equipment. However, if the first vehicle model information stored in the first message is a temporary vehicle model, then reconfiguration is required to place the vehicle under its designated model.
[0180] For example, in one scenario, the first vehicle model information might only indicate the vehicle model without containing specific details. For instance, it might only indicate whether the vehicle is model A or model B, excluding vehicle configuration versions and function switches. In this case, the first vehicle model information is a temporary model, used only for safely waking up or powering on other control units, and not as the final, official version. Therefore, after powering on the second control unit based on the first vehicle model information, the official vehicle model still needs to be configured.
[0181] Optionally, the configuration of the official vehicle model can be achieved by external tools such as diagnostic equipment loading diagnostic application messages into the intelligent driving computing platform, or by internal components such as gateways sending vehicle configuration messages to the intelligent driving computing platform, without limitation.
[0182] Taking sending a diagnostic application message to the intelligent driving computing platform via diagnostic equipment as an example, after powering on the second control unit, R&D personnel can also send a second message (i.e., a diagnostic application message) to the vehicle via the diagnostic equipment. This second message includes second vehicle model information, which corresponds to the actual vehicle model. This information is received by the T-Box in the vehicle and forwarded to the GW (Power Gateway), which then forwards it to the intelligent driving computing platform. The intelligent driving computing platform parses the diagnostic application message to obtain the second vehicle model information and applies it, thus updating the vehicle model from the one corresponding to the first model information to the one corresponding to the second model information.
[0183] Understandably, the operation of sending the second message by the diagnostic device is placed after the second control unit is powered on because the second control unit has a diagnostic interface, while the first control unit does not. Therefore, the second message sent by the diagnostic device can only be received through the diagnostic interface in the second control unit after the second control unit is powered on, and the second vehicle model information in the second message can be activated.
[0184] Alternatively, there are two main ways to implement the second vehicle model information:
[0185] In one implementation, the intelligent driving computing platform can store the second vehicle model information locally, or replace the locally stored first vehicle model information, and then perform a restart operation. After restarting, the intelligent driving computing platform performs an initialization operation, activating the software package capability set corresponding to the vehicle model corresponding to the locally stored second vehicle model information, thereby updating the vehicle model to the model corresponding to the second vehicle model information; or,
[0186] In another implementation, the intelligent driving computing platform can first compare the second vehicle model information with the locally stored vehicle model information. If they are the same, it means that the currently active vehicle model is the one that needs to be active and does not need to be reactivated. Therefore, the intelligent driving computing platform does not need to perform the activation operation and can directly end the processing. If the vehicle model information does not exist locally or exists locally but is different from the second vehicle model information, it means that the vehicle model has not yet been configured, or although the vehicle model has been configured, it is not the one that needs to be active. In this case, the intelligent driving computing platform can store the second vehicle model information locally or replace the locally stored vehicle model information and perform a restart operation. The restart operation is mainly used for the initialization of the intelligent driving computing platform. During the initialization process, the software package capability set of the vehicle model corresponding to the locally stored second vehicle model information will be activated, thereby configuring the vehicle model. For details on the initialization-related content, please refer to Figure 5 below, which will not be explained here.
[0187] By adopting the latter implementation method, the vehicle model will only be reconfigured when the second vehicle model information to be effective is different from the currently configured vehicle model information (for example, after configuring the vehicle model through the first message, there are other vehicle model modification operations, resulting in the vehicle model being different from the vehicle model configured in the first message, and possibly the same as the vehicle model corresponding to the second vehicle model information in the second message). This can reduce unnecessary restart operations of the intelligent driving computing platform and ensure the availability of the intelligent driving computing platform.
[0188] Optionally, the first vehicle model information is a temporary model used only to power on the second control unit. Unlike the first vehicle model information, the second vehicle model information is the officially used model. It not only needs to carry the specific vehicle model but also detailed information related to the model, including more specific details such as model, configuration, style, and function set. If the vehicle model in the second vehicle model information is the same as the vehicle model in the first vehicle model information, then the second vehicle model information can be considered to include the first vehicle model information. In addition, it also includes information not carried in the first vehicle model information.
[0189] Optionally, since both the first and second control units have been activated and powered on, the intelligent driving computing platform can store the second vehicle model information locally in both the first and second control units. For example, the second vehicle model information can be used to overwrite the first vehicle model information originally stored locally in the first control unit, and the second vehicle model information can be stored locally in the second control unit. In this way, the first and second control units can work together to activate the second vehicle model information, such as turning on the software function switch corresponding to the second vehicle model information stored locally.
[0190] Based on the in-vehicle processing method described above, before configuring a specific vehicle model, the first control unit can be woken up by wake-up messages from all shared vehicle models. Simultaneously, it supports the identification and configuration of temporary vehicle models through specific vehicle model notification messages or proprietary business characteristic messages, thereby safely powering on the second control unit, ultimately achieving the goal of sharing software across multiple vehicle models. In this way, both the first and second control units can be woken up and powered on normally, ensuring safe wake-up and power-on in subsequent commercial scenarios. Even if the sleep wake-up and power-on message mechanisms differ between different vehicle models, the intelligent driving product can still be woken up and powered on normally, while ensuring its safety.
[0191] The vehicle modes mentioned above can be configured during the initialization process of the intelligent driving computing platform. After configuring the vehicle modes during the initialization phase, the intelligent driving computing platform enters the operation phase. During the operation phase, it performs wake-up operations (i.e., wake-up of the first control unit), vehicle model configuration operations, and power-on operations (i.e., power-on of the second control unit) according to the vehicle modes.
[0192] To facilitate understanding of the solution, the following explanation will use an MCU as the first control unit and an SOC as the second control unit as an example to illustrate the specific implementation of the four operations of the intelligent driving computing platform: initialization, wake-up, vehicle configuration, and power-on.
[0193] Initialization of the intelligent driving computing platform
[0194] Please refer to Figure 5, which shows a schematic diagram of the initialization process of an intelligent driving computing platform provided in this application, including the following steps:
[0195] Step 501, Start Initialization.
[0196] Optionally, the intelligent driving computing platform can perform initialization operations each time the vehicle is powered on, started, or restarted.
[0197] Step 502: Obtain the vehicle model information stored locally.
[0198] Optionally, during initialization, the intelligent driving computing platform first powers on the MCU within the platform, more specifically, it powers on a dormant submodule within the MCU, causing the submodule to start and check if the vehicle model information is already stored in the local system. For ease of understanding, the following description uses the MCU as the execution entity, but it should be understood that the MCU operations described below can also be replaced by this submodule within the MCU, without specific limitations.
[0199] Step 503: Determine if the vehicle model is configured. If yes, proceed to step 504; otherwise, proceed to step 508.
[0200] Step 504: Set the vehicle's current mode to model mode.
[0201] Optionally, if the local system stores vehicle model information, it means that the vehicle configuration word has been configured through the second message sent by the diagnostic device, or the vehicle model information has been configured through the first message. In this case, the MCU can set the current mode of the vehicle to the vehicle model mode according to the vehicle model information stored locally.
[0202] Here, setting it to vehicle model mode indicates that the intelligent driving computing platform has entered a vehicle model-specific mode, and the vehicle model is considered reliable at this time.
[0203] Step 505: Obtain the wake-up parameters for the vehicle model corresponding to the vehicle model mode.
[0204] Optionally, the MCU can obtain the parameters of the corresponding NM wake-up message, such as ID or group, from the local system based on the vehicle model. These parameters are then used as the parameters to be applied. Here, ID refers to the ID of the NM wake-up message corresponding to the vehicle model, and group refers to the grouping of the NM wake-up message in the NM wake-up protocol. After configuring the ID and group, only NM wake-up messages with the same ID within that group can successfully wake up the MCU; wake-up messages with other IDs or other groups will not be able to wake up the MCU.
[0205] As an example, the MCU's local system stores upgrade packages:
[0206] If a one-vehicle-one-package approach is adopted, the upgrade package only contains the package for the current vehicle model. Therefore, the MCU can directly use the parameters of the NM wake-up message contained in the package as parameters to be activated. Optionally, the parameters of the power-on / off messages contained in the package can also be used as parameters to be activated to facilitate the subsequent power-on / off operations of the second control unit.
[0207] If a shared software package is used for multiple vehicle models, the upgrade package contains software packages for multiple models. The MCU can first obtain the software package for the vehicle model corresponding to the currently set vehicle model mode from the upgrade package, and then find the parameters of the NM wake-up message from that software package as the parameters to be applied. Optionally, the parameters of the power-on / off message can also be found from the software package as parameters to be applied, so as to facilitate the subsequent power-on / off operation of the second control unit.
[0208] Alternatively, in another example, the MCU's local system can also store the mapping relationship between vehicle models and various parameters. The MCU can directly query the mapping relationship based on the vehicle model mode currently configured for the vehicle to obtain the various parameters corresponding to the current vehicle model, including the parameters of the NM wake-up message and the parameters of the power-on / off messages. The MCU uses these parameters as parameters to be applied.
[0209] Of course, there may be other ways to implement it, which will not be listed here.
[0210] Step 506: Activate the wake-up parameters corresponding to the vehicle model.
[0211] Optionally, the MCU can write the parameters to be applied into the hardware unit used for wake-up, thereby configuring and applying the parameters of the NM wake-up message corresponding to the vehicle model mode, as well as the parameters of the power-on / off messages for that vehicle model. The hardware unit used for wake-up is located within the MCU and is a hardware module within the MCU.
[0212] Step 507: Turn on the switch to allow sending CAN messages.
[0213] Optionally, the MCU also includes a hardware unit for sending CAN messages, called the sending unit. The MCU can enable the sending unit's function by turning on its switch, allowing the sending unit to send CAN messages. Here, although the switch for sending CAN messages is turned on, the sending unit will still check whether the CAN message to be sent is a CAN message of the currently configured vehicle model before performing the specific sending operation. Only CAN messages of the configured vehicle model will be sent; CAN messages of other models will not be sent to avoid CAN bus hangs.
[0214] Step 508: Set the vehicle's current mode to platform mode.
[0215] Optionally, if vehicle model information cannot be obtained from the local system, it means that the vehicle model has not yet been configured and there is no clear vehicle model information. In this case, the MCU can set the vehicle's current mode to platform mode, indicating that the vehicle is currently in the factory platformization stage, the vehicle model is clearly not yet configured, and the intelligent driving computing platform does not represent the capability set of any vehicle model.
[0216] Step 509: Configure the mechanism for waking up by any message.
[0217] Optionally, the MCU can write the parameters of the NM wake-up message and the power-on / off message for all vehicle models into the hardware unit used for wake-up, thereby configuring and activating the parameters of the NM wake-up message and the power-on / off message for all vehicle models.
[0218] Step 510: Turn off the switch for sending CAN messages.
[0219] Optionally, the MCU can disable the switch for sending CAN messages, thereby preventing the sending unit from sending all CAN messages. Alternatively, it can enable the sending switch for messages within the whitelist and disable the sending switch for messages outside the whitelist. This allows the sending unit to send CAN messages within the whitelist but prohibits the sending of CAN messages outside the whitelist, preventing the CAN bus from being suspended due to the accidental transmission of CAN messages that are incompatible with the vehicle model. The CAN messages in the whitelist include diagnostic messages and / or upgrade messages, as well as other messages that are not related to the vehicle model.
[0220] Based on the above, during the initialization phase of the intelligent driving computing platform, if vehicle model information is already configured locally, it is set to vehicle model mode, the wake-up mechanism for the corresponding wake-up message is set, and the message sending switch is turned on, allowing the intelligent driving computing platform to perform normal wake-up and power-on / off procedures. If vehicle model information is not yet configured locally, it is set to platform mode, the wake-up mechanism for all wake-up messages is set, and some or all message sending switches are turned off. This ensures normal MCU wake-up while preventing the bus from being stuck due to the accidental sending of non-vehicle model matching messages.
[0221] Wake-up operation of intelligent driving computing platform
[0222] Please refer to Figure 6, which illustrates the wake-up process of an intelligent driving computing platform provided in this application. The process includes the following steps:
[0223] Step 601: Enter the operation phase.
[0224] Optionally, the intelligent driving computing platform enters the operation phase after completing the above initialization operations.
[0225] Step 602: Receive the wake-up message.
[0226] Optionally, after entering the operational phase, the intelligent driving computing platform can wait for an external wake-up message, such as a wake-up message sent by a gateway. This wake-up message can be received by the MCU in the intelligent driving computing platform. The MCU then initiates the wake-up operation of the intelligent driving computing platform based on the wake-up message, which is the wake-up operation of all modules in the MCU except for those in a dormant state.
[0227] Step 603: Obtain system mode.
[0228] Optionally, after receiving the wake-up message from the gateway, the MCU begins to obtain the system mode from the local system, which is the vehicle's current mode. Based on the configuration during the initialization phase, if the vehicle model information has not yet been configured, the obtained system mode is the platform mode; if the vehicle model information has already been configured, the obtained system mode is the vehicle model mode.
[0229] Step 604: Determine whether the system mode is platform mode. If yes, proceed to step 605; otherwise, proceed to step 607.
[0230] Step 605: Wake up the MCU.
[0231] Here, if the obtained system mode is platform mode, it means that the vehicle model has not yet been configured. Since the wake-up parameters of the NM wake-up messages corresponding to all vehicle models are applied during the initialization phase when no vehicle model is configured, the MCU can power on all internal components that are not yet powered, regardless of whether the received wake-up message is a vehicle model matching message, thus waking up the MCU normally. In other words, any message can wake up the MCU.
[0232] Step 606: Prohibit the sending of CAN messages not on the whitelist.
[0233] Optionally, since the CAN message sending switch outside the whitelist is turned off for platform mode during the initialization phase, the MCU is prohibited from sending CAN messages outside the whitelist after being woken up in platform mode.
[0234] It should be noted that in existing automotive solutions, whitelists are only used during software package upgrades. This application, however, sets the whitelist during the wake-up process. The whitelist includes upgrade and / or diagnostic messages. Based on this, the MCU can perform upgrades and / or diagnostics even when no vehicle model is configured, avoiding interruptions to upgrade and / or diagnostic services and ensuring service availability. Furthermore, since other messages, such as those related to vehicle control, cannot be sent by the MCU outside the whitelist, it also ensures that the MCU is not controlled by unauthorized messages during wake-up when no vehicle model is configured, thus ensuring the security of vehicle control.
[0235] Step 607: Obtain local vehicle model information.
[0236] Step 608: Based on the local vehicle model information, determine whether the received wake-up message is a wake-up message specific to this vehicle model. If yes, proceed to step 609; otherwise, proceed to step 611.
[0237] Step 609: Wake up the MCU.
[0238] Optionally, if the obtained system mode is vehicle model mode, it means that the vehicle has been configured with a vehicle model. Since the initialization phase only applies the wake-up parameters of the NM wake-up message corresponding to the configured vehicle model after configuring the vehicle model, the MCU will only power on the internal components that have not yet been powered on when the received wake-up message is a message that matches the configured vehicle model, so as to wake up the MCU normally.
[0239] Based on this, if the current system is in vehicle model mode, the MCU can obtain the configured vehicle model information from the local system. Then, based on this information, it determines the wake-up parameters for the corresponding NM wake-up message—that is, the wake-up parameters that took effect during the initialization phase. It then compares these effective wake-up parameters with the wake-up parameters of the received wake-up message. If they match, it means the received wake-up message is specific to the currently configured vehicle model, and the MCU is allowed to wake up. If they don't match, it means the received wake-up message is not specific to the currently configured vehicle model, and to ensure the security of MCU wake-up, no action is taken; that is, the MCU is not woken up.
[0240] Step 610: Allow the sending of CAN messages.
[0241] Optionally, since the switch to allow CAN message transmission is enabled for vehicle model mode during the initialization phase, after waking up the MCU in vehicle model mode, the MCU is allowed to send CAN messages to the outside world. More specifically, the MCU is allowed to send CAN messages of the vehicle model type.
[0242] Step 611: Do not process.
[0243] Step 612, End.
[0244] Optionally, after waking up the MCU in platform mode and prohibiting the sending of CAN messages outside the whitelist, or after waking up the MCU in vehicle mode and allowing the sending of CAN messages, or after failing to wake up the MCU in vehicle mode, the MCU wake-up process is terminated, that is, the wake-up operation of the intelligent driving computing platform is terminated.
[0245] To translate the above wake-up operations into a module perspective, please refer to Figure 7, which shows the module flowcharts of the intelligent driving computing platform in two modes. Figure 7(A) shows the module flow in platform mode, and Figure 7(B) shows the module flow in vehicle model mode. In this example, the small module in the intelligent driving computing platform that is in a dormant state is referred to as the wake-up and power-on module, and the intelligent driving computing platform locally stores the vehicle mode.
[0246] As shown in Figure 7(A), during the initialization state, the vehicle model is not yet determined, and the intelligent driving computing platform is configured in platform mode, where any message can wake up the MCU. Therefore, when the wake-up message sent by the gateway reaches the wake-up and power-on module in the intelligent driving computing platform, regardless of which vehicle model the wake-up message belongs to, the wake-up and power-on module can wake up the MCU. Furthermore, it prohibits the sending of messages outside the whitelist, such as CAN messages controlling the vehicle chassis, to ensure the safety of vehicle control.
[0247] Furthermore, as shown in Figure 7(B), after the host computer (or diagnostic device) sends the vehicle model information to the intelligent driving computing platform, the platform switches from platform mode to vehicle model mode, where only specific vehicle model messages can wake up the MCU. Therefore, when the wake-up message sent by the gateway reaches the wake-up and power-on module in the intelligent driving computing platform, the wake-up and power-on module can only wake up the MCU and allow message transmission if the wake-up message corresponds to the currently switched vehicle model. This allows the MCU to enter normal operating mode.
[0248] Based on the above, in the wake-up process of the intelligent driving computing platform, if in vehicle model mode, only wake-up messages corresponding to that vehicle model can wake up the MCU, and sending messages corresponding to that vehicle model is allowed to ensure safe wake-up in scenarios where a vehicle model is configured. However, if in platform mode, wake-up messages corresponding to all vehicle models can wake up the MCU, and sending messages outside the whitelist is prohibited. This ensures normal MCU wake-up in scenarios where no vehicle model is configured, while also maintaining vehicle control safety. For example, it can prevent the bus from crashing due to the accidental sending of non-vehicle model-matched messages in scenarios where no vehicle model is configured.
[0249] Vehicle configuration operation of intelligent driving computing platform
[0250] Based on the above description of Figure 3, the vehicle configuration operation can be instructed to the intelligent driving computing platform via a first message sent by the gateway. This first message can be a new vehicle notification message or an existing business feature message. The vehicle configuration methods for these two message types are explained below using Figures 7 and 8 respectively.
[0251] First, please refer to Figure 8, which shows a schematic diagram of the vehicle configuration process of an intelligent driving computing platform provided in this application. This process corresponds to the vehicle configuration process when the first message is a vehicle notification message. As shown in Figure 8, it mainly includes the following steps:
[0252] Step 801: Start vehicle configuration.
[0253] Optionally, during the wake-up phase of the intelligent driving computing platform, if the MCU is woken up in platform mode, then since no vehicle model has been configured yet, the intelligent driving computing platform needs to initiate vehicle model configuration. Conversely, if the MCU is woken up in vehicle model mode, since the vehicle model has already been configured locally, the intelligent driving computing platform does not need to reconfigure the vehicle model. Alternatively, if it needs to be updated to a different vehicle model, the intelligent driving computing platform can also initiate vehicle model configuration to replace the locally configured vehicle model.
[0254] Step 802: Receive vehicle model notification message.
[0255] Optionally, after waking up the MCU in the intelligent driving computing platform, if it is necessary to configure the vehicle model, a vehicle model notification message can be sent to the MCU through the gateway. The vehicle model notification message includes specific vehicle model information, as shown in Figure 4a above.
[0256] Step 803: Verify whether the vehicle model notification message is correct. If not, proceed to step 804; if yes, proceed to step 805.
[0257] Optionally, the MCU can verify whether the format of the vehicle model notification message is correct, whether the message is complete, and whether the message has been tampered with. For example, it can use CRC segment encryption verification to determine whether the message has been tampered with. If all verifications pass, the vehicle model notification message is determined to be a correct message. If at least one verification fails, the message is determined to be an incorrect message.
[0258] Step 804: Log the error.
[0259] Here, when the vehicle model notification message is an incorrect message, it means that the message may be an attack message, or the message format or integrity itself is incorrectly configured, and the vehicle model cannot be configured based on the message. In this case, the MCU can record the message in the error log and end the vehicle model configuration. Recording it in the error log is to facilitate subsequent R&D personnel to view the log and correct the message.
[0260] Step 805: Update vehicle model information.
[0261] Here, when the vehicle model notification message is a correct message, the vehicle model needs to be configured according to the message. In this case, the MCU can parse the data segment content in the vehicle model notification message to obtain the vehicle model information to be configured, and can even know the vehicle configuration information, such as whether it is a low-end, mid-range, or high-end vehicle.
[0262] Furthermore, the MCU treats all the acquired information as valid vehicle model information and stores it locally. For example, if the vehicle model information does not exist locally, the valid vehicle model information is directly added to the local system. If the vehicle model information already exists in the local system, it is used to replace the original vehicle model information, thus updating and persisting this information to the local system.
[0263] Step 806: Update the capability set corresponding to the vehicle model.
[0264] Optionally, after storing the vehicle model information in the local system, the MCU can also update the software package capability set corresponding to the vehicle model. For example, it can send the vehicle model information to the SOC so that the vehicle model configuration module in the SOC can turn on the switch of the software package capability set corresponding to the updated vehicle model information and turn off the switch of the software package capability set corresponding to the original vehicle model information.
[0265] Step 807: Determine whether the new vehicle model and the local vehicle model are consistent. If not, proceed to step 808; otherwise, proceed to step 809.
[0266] Step 808: Restart the MCU.
[0267] Step 809: End vehicle configuration.
[0268] Optionally, after updating the vehicle information and capability set in the local system, the MCU can compare the updated vehicle information with the vehicle currently used by the intelligent driving computing platform. If the two vehicle types are different, it means the currently used vehicle is not the one that needs updating, and the currently used vehicle needs to be deactivated, while the vehicle that needs updating is activated, and the vehicle configuration ends. Conversely, if the two vehicle types are different, it means the currently used vehicle itself is the one that needs updating, and the vehicle configuration does not need to be activated again. Therefore, the MCU can directly end the vehicle configuration.
[0269] Optionally, when updating a vehicle model, if the vehicle does not support online updates, the model needs to be updated by restarting the intelligent driving computing platform. That is, the intelligent driving computing platform can be shut down and then restarted to power it back on. Upon powering on, the platform will execute the initialization process described above. During initialization, it reads locally stored vehicle model information and immediately loads the corresponding model, allowing the intelligent driving computing platform to switch from platform mode to vehicle model mode, or from one vehicle model mode to another.
[0270] Of course, in other examples, if the vehicle is highly intelligent and supports online updates, the intelligent driving computing platform can directly update the vehicle model that needs to be updated without restarting and disable the currently used vehicle model. In this case, the intelligent driving computing platform's operations will not be interrupted.
[0271] Based on the above, the vehicle model to be configured can be directly indicated through the vehicle model notification message. The MCU can directly configure the vehicle model according to the vehicle model indicated by the vehicle model notification message without performing additional matching operations, which can simplify the complexity of the vehicle model configuration process.
[0272] Next, please refer to Figure 9, which shows a schematic diagram of the vehicle configuration process of another intelligent driving computing platform provided in this application. This process corresponds to the vehicle configuration process when the first message is a business feature message. As shown in Figure 9, it mainly includes the following steps:
[0273] Step 901: Start vehicle configuration.
[0274] For example, after waking up the MCU in platform mode, or when waking up the MCU in vehicle mode and needing to reconfigure the vehicle model, the intelligent driving computing platform can initiate vehicle model configuration operations.
[0275] Step 902: Receive service feature message.
[0276] Optionally, a service feature message can be sent to the MCU through a gateway. The service feature message includes service feature information, which is used to indirectly indicate vehicle model information. The format of the service feature message is shown in Figure 4b above.
[0277] Step 903: Extract key information from the business feature message.
[0278] Optionally, after receiving a service feature message, the MCU can first verify its correctness, such as checking the message format, integrity, and tamper-proof nature. If all verifications pass, the service feature message is considered correct, and the MCU can extract key information. Conversely, if at least one verification fails, the service feature message is considered incorrect, and the MCU can directly terminate the vehicle configuration and record the error in the error log for developers to correct.
[0279] Step 904: Determine the vehicle model to be configured based on the extracted key information.
[0280] Optionally, the key information in the service characteristic message is the service characteristic information within it. Combining this with the format shown in Figure 4b, the MCU can parse the data segment content of the service characteristic message to obtain service characteristic information such as the high-voltage model, liquid cooling signal, and ignition signal. Based on the correspondence between these service characteristic information and the vehicle model, the MCU can determine the vehicle model indicated by the service characteristic message.
[0281] In some scenarios, if the vehicle model cannot be identified based solely on the data segment content, the control segment content, which is the device ID of the destination device in the business characteristic message, can also be combined to identify the vehicle model to be configured.
[0282] Step 905: Update vehicle model information.
[0283] Here, the MCU can identify the vehicle model or even update the configuration and persist it to the local system.
[0284] Step 906: Update the capability set corresponding to the vehicle model.
[0285] Here, the MCU can also update the software package capability set for the corresponding vehicle model, such as sending the vehicle model information to the SOC so that the vehicle configuration module in the SOC can update the software package capability set for the corresponding vehicle model.
[0286] Step 907: Determine whether the new model and the local model are consistent. If not, proceed to step 908; otherwise, proceed to step 909.
[0287] Step 908: Restart the MCU.
[0288] Step 909: End vehicle configuration.
[0289] Here, after updating the vehicle model information and capability set in the local system, the MCU compares the updated vehicle model with the vehicle model currently used by the intelligent driving computing platform. If the two vehicle models are different, the updated vehicle model is applied directly, or the updated vehicle model is applied during the initialization phase via a restart, while the currently used vehicle model is deactivated, and vehicle model configuration ends. Conversely, if the two vehicle models are different, vehicle model configuration ends directly.
[0290] Based on the above, the vehicle model to be configured can be indirectly indicated through the business feature message. The MCU first indirectly perceives the vehicle model to be configured based on the key information in the business feature message, and then performs vehicle configuration based on the vehicle model, which can also realize the vehicle configuration process.
[0291] Power-on operation of the intelligent driving computing platform
[0292] Please refer to Figure 10, which shows a schematic diagram of the power-on process of an intelligent driving computing platform provided in this application. The process includes the following steps:
[0293] Step 1001: Start the power-on process.
[0294] Optionally, after waking up the MCU in vehicle mode, or after waking up the MCU in platform mode and configuring the vehicle model through the first message, the intelligent driving computing platform can initiate the power-on process.
[0295] Step 1002: Receive power-on message.
[0296] Optionally, after initiating the power-on process, the intelligent driving computing platform can wait for an externally input power-on message, such as a power-on message sent by a gateway. This power-on message can be sent to the intelligent driving computing platform together with the wake-up message or carried in the first message, or it can be sent to the intelligent driving computing platform separately, without limitation.
[0297] In one example, the power-on message can be received by the MCU in the intelligent driving computing platform. The MCU initiates the power-on operation of the intelligent driving computing platform based on the power-on message, which is also the power-on operation of the SOC.
[0298] Step 1003: Obtain local vehicle model information.
[0299] Step 1004: Based on the local vehicle model information, determine whether the received power-on message is a power-on message unique to this vehicle model. If not, proceed to step 1005; if yes, proceed to step 1006.
[0300] Step 1005: Do not process.
[0301] Step 1006: Power on the SOC.
[0302] Optionally, since a vehicle model has already been configured, the MCU can obtain the configured vehicle model information from the local system. Then, based on this information, it determines the relevant parameters of the power-on message corresponding to the vehicle model—that is, the parameters of the power-on message that has already taken effect during the initialization phase. It then compares these parameters with the parameters of the received power-on message. If they match, it means the received power-on message is specific to the currently configured vehicle model, and the MCU can power on all components within the SOC, thus powering on the SOC normally. Conversely, if they do not match, it means the received power-on message is not specific to the currently configured vehicle model. In this case, to avoid frequent power-ups and shutdowns that could damage the chip, the MCU can choose not to process the power-on message, i.e., not power on the SOC. Thus, the MCU only powers on the SOC when the received power-on message matches the configured vehicle model, ensuring the safety of SOC power-on.
[0303] Step 1007: End the power-on process.
[0304] Here, after the SOC is powered on normally, or after it is determined that the SOC will not be powered on, the MCU can end the power-on process.
[0305] Optionally, after a normal power-on SOC, if a vehicle model update is still required, steps 1008 and 1009 can also be performed:
[0306] Step 1008: Receive diagnostic application message.
[0307] Optionally, a diagnostic application message can be sent to the SOC via a diagnostic device. Since the SOC is already powered on normally, it can successfully receive and parse the diagnostic application message to obtain the vehicle configuration word.
[0308] Step 1009: Update the local vehicle model based on the vehicle configuration word in the diagnostic application message.
[0309] Here, the vehicle configuration word can be updated to the local system for persistent storage. Optionally, the intelligent driving computing platform can also be restarted to perform the initialization operation mentioned above, read the latest vehicle configuration word from the local system, and apply the corresponding vehicle model and capability set.
[0310] Based on the above, by powering on the SOC after configuring the vehicle model, it can be ensured that only power-on messages matched with the currently configured vehicle model can power on the SOC, while power-on messages matched with other vehicle models cannot power on the SOC. In this way, risks such as disk drop and vehicle power depletion caused by frequent power-on and power-off of the SOC can be avoided.
[0311] The above content describes the entire process of the intelligent driving computing platform, from initialization to MCU wake-up, vehicle configuration, and finally SOC power-on. Before SOC power-on, the vehicle model can be configured using vehicle model notification messages or service characteristic messages. After the SOC is powered on normally according to the configured vehicle model, the vehicle model can be updated using diagnostic application messages. This process involves three types of messages: vehicle model notification messages, service characteristic messages, and diagnostic application messages. All three types of messages can be used to configure the vehicle model, corresponding to three different vehicle model configuration methods.
[0312] Please refer to Figure 11, which shows a schematic diagram of the module implementation for three vehicle configuration methods provided in this application. In this example, the MCU and SOC can reside in the same electronic control unit, i.e., the MDC. The MCU and SOC are two different chips within the MDC. The MDC (or MCU) includes a message receiving module, a vehicle model parsing and conversion module, a storage management module, a vehicle model configuration database, and a power-on / off module. It also includes various applications (APPs) for implementing intelligent driving functions.
[0313] As shown in Figure 11, the message receiving module connects externally to the gateway and diagnostic equipment of the intelligent driving computing platform, and internally to the vehicle model parsing and conversion module, which in turn connects to the storage management module. The storage management module is primarily responsible for managing the vehicle model configuration database, ensuring persistent storage of vehicle model information, and also for interfacing with the APP to send the vehicle model information stored in the database to the APP based on its needs. In addition, the power-on / off module, connected to the SOC, is mainly responsible for powering on and off the SOC and is not shown in the figure.
[0314] Table 1 shows a comparison diagram of the three message types corresponding to the three vehicle configurations:
[0315] Table 1
[0316] Based on Figure 11 and Table 1 above, there are three possible vehicle configurations:
[0317] Vehicle configuration method 1: Send vehicle model notification messages to MDC via the gateway. Vehicle model notification messages are applicable to new customers, that is, vehicles that have just been produced but have not yet left the factory. By adding vehicle model notification messages to the vehicle's whole vehicle communication matrix, the vehicle model can be clearly indicated, and there is no need to add an electrical inspection station as in traditional diagnostic equipment configuration.
[0318] Vehicle configuration method 2 involves sending service characteristic messages to the MDC via the gateway. These messages are suitable for existing customers, meaning vehicles already manufactured. Since the communication matrix for these vehicles is fixed and cannot be modified, specific service characteristic information can be used to indirectly indicate different vehicle models. The service characteristic information used must differ across vehicle models. This method does not require additional electrical inspection stations and eliminates the need for users to return their vehicles to the factory for maintenance. It allows for seamless adaptation without the user's awareness, resulting in a better user experience.
[0319] Vehicle configuration method 3 involves sending diagnostic application messages to the MDC via diagnostic equipment. For example, diagnostic application messages can be configured and sent to the MDC using the diagnostic information diagnostic (DID) method. This method is a traditional vehicle configuration method, requiring a clearly defined electrical inspection station. It offers relatively high reliability and safety, but it necessitates ensuring that the MDC in both the vehicle and the intelligent driving computing platform supports CAN bus-based diagnostic communication (DOCAN) access.
[0320] Furthermore, as shown in Figure 11, all messages—including vehicle model notification messages, business feature messages, and diagnostic application messages—are received by the message receiving module in the MDC. This module forwards the received messages to the vehicle model parsing and conversion module. The vehicle model parsing and conversion module parses the received messages to obtain vehicle model-related information, converts it into corresponding vehicle model information, and then informs the storage management module. The storage management module then persistently stores this vehicle model information in the vehicle model configuration database, thus performing the write-to-vehicle-model and storage operation. When the APP needs to read the vehicle model during the implementation of intelligent driving functions, it sends a read request to the storage management module. The storage management module reads the corresponding vehicle model information from the vehicle model configuration database and returns it to the APP, enabling the APP to complete the corresponding functions based on this information.
[0321] Furthermore, after configuring the vehicle model, the SOC can be powered on and off via the power-on / off module. Although not shown in the diagram, it can be understood that the power-on / off module can also be connected to the message receiving module and the storage management module. When the SOC needs to be powered on or off, a power-on / off message can be sent to the message receiving module through the gateway. The message receiving module then forwards the power-on / off message to the power-on / off module. The power-on / off module reads the vehicle model information stored in the vehicle model configuration database through the storage management module and compares the received power-on / off message with the power-on / off message in the currently stored vehicle model information. If they match, the corresponding power-on / off operation is performed on the SOC; otherwise, no action is taken.
[0322] As an example, if the vehicle model is configured via a service feature message before powering on the SOC, considering that this service feature message indirectly indicates the vehicle model using existing service feature information, its explicit indication of the vehicle model is insufficient. Therefore, the vehicle model information indicated in the service feature message can only be used to temporarily activate the vehicle model for normal SOC power-on. However, the indicated vehicle model configuration still needs to be explicitly defined; that is, a diagnostic application message needs to be sent by the diagnostic device to reconfigure the specific vehicle model. Conversely, if the vehicle model is configured via a vehicle model notification message, then the vehicle model itself is a specific model, such as the vehicle itself being the specific model corresponding to the vehicle. In this case, it is not necessary to reconfigure the vehicle model via a diagnostic application message, thus reducing the complexity of vehicle model configuration.
[0323] Based on the above, several specific implementation schemes are given below to further explain the vehicle-mounted processing method provided in this application.
[0324] Before introducing the specific implementation scheme, please refer to Figure 12, which shows a possible module implementation flow of the existing MCU wake-up and power-on / off SOC scheme. As shown in Figure 12, in the existing technology, the MCU is equipped with a wake-up and power-on module, and the SOC is equipped with a vehicle configuration module. The wake-up and power-on module is connected to an external vehicle gateway, and the vehicle configuration module is connected to an external diagnostic device.
[0325] In existing technologies, after vehicle assembly, a wake-up message and a power-on message are first sent to the wake-up and power-on modules in the MCU via the vehicle gateway. The wake-up message is used to wake up the MCU, and the power-on message is used to power on the SOC. After the SOC is powered on, a diagnostic application message carrying a vehicle configuration word is sent to the vehicle configuration module in the SOC via a diagnostic device. The vehicle configuration module configures the vehicle model and activates the corresponding capability set based on the vehicle configuration word. According to this implementation, only a specific single vehicle model message can wake up the MCU; if the vehicle model messages are inconsistent, the MCU cannot be woken up. Therefore, if a multi-vehicle shared software package solution is used, in the customer's vehicle assembly line, due to mismatched wake-up messages, the MCU cannot be woken up normally, thus preventing vehicle model configuration via diagnostic equipment. Therefore, existing implementations can only use one software package per vehicle model.
[0326] Both Implementation Scheme 1 and Implementation Scheme 2 can solve this technical problem in the prior art.
[0327] Implementation Plan 1: After waking up the MCU using a wake-up message, configure the vehicle model using a vehicle model notification message.
[0328] Please refer to Figure 13a, which exemplarily illustrates a module flow diagram of the in-vehicle processing method provided in Implementation Scheme 1. In this example, the MCU includes not only a wake-up and power-on module but also a vehicle model dynamic recognition module, and the SOC includes a vehicle model configuration module. The wake-up and power-on module and the vehicle model dynamic recognition module are externally connected to the external vehicle gateway, while the vehicle model dynamic recognition module is internally connected to the vehicle model configuration module in the SOC.
[0329] Compared to the existing intelligent driving computing platform shown in Figure 12, the vehicle model dynamic recognition module in Figure 13a is a new module. This module can be located inside or outside the MCU; Figure 13a uses the former as an example. After vehicle assembly, wake-up and power-on messages are sent to the wake-up and power-on modules in the MCU via the vehicle gateway, as well as a vehicle model notification message is sent to the vehicle model dynamic recognition module in the MCU. The wake-up and power-on module uses the wake-up message to wake up the MCU based on the vehicle's current mode, while the vehicle model dynamic recognition module uses the vehicle model notification message to identify the vehicle model and send it to the vehicle model configuration module in the SOC, thus completing the vehicle model configuration. After successful vehicle model configuration, the wake-up and power-on module can use the power-on message to power on the SOC normally.
[0330] Taking a vehicle model that has not yet been configured as an example, please refer to Figure 13b, which shows a schematic diagram of the execution flow of the in-vehicle processing method provided in Implementation Scheme 1. This flow includes the following steps:
[0331] Step 1301, Start.
[0332] Here, the intelligent driving computing platform will perform initialization operations after startup. During the initialization process, since the vehicle model has not yet been configured, there is no vehicle model information in the local system of the intelligent driving computing platform. The intelligent driving computing platform will configure the vehicle in platform mode and disable the message sending switch for messages not on the whitelist.
[0333] Step 1302: Wake up the MCU with an arbitrary wake-up message.
[0334] Here, in platform mode, wake-up messages corresponding to all vehicle models are effective. Therefore, any wake-up message can wake up the MCU. For example, referring to Figure 13a, after the wake-up and power-on module in the MCU receives a wake-up message sent by the vehicle gateway, regardless of whether the wake-up message is the wake-up message corresponding to the vehicle model itself, the wake-up and power-on module in the MCU will normally power on other ECUs in the MCU, that is, normally wake up the MCU.
[0335] Step 1303: Receive vehicle model notification message.
[0336] For example, referring to Figure 13a, the vehicle model dynamic recognition module in the MCU receives a vehicle model notification message sent by the vehicle gateway. This message carries a specific vehicle model, such as the vehicle's actual model. After identifying the vehicle model carried in the notification message, the vehicle model dynamic recognition module sends the relevant information to the vehicle configuration module in the SOC.
[0337] Step 1304: Switch vehicle model.
[0338] Here, since the vehicle model has not yet been configured, the intelligent driving computing platform's local system does not store model information. After receiving the model information sent by the model dynamic recognition module, the model configuration module in the SOC can directly store this information in the local system and restart the intelligent driving computing platform. Upon restarting, the intelligent driving computing platform performs initialization operations, applies the locally stored model information, completes the model configuration, and activates the corresponding capability set for the model. Of course, in other scenarios, if the intelligent driving computing platform has a higher configuration, it can also support direct model configuration without restarting.
[0339] Step 1305: The SOC can be powered on normally.
[0340] Here, since the vehicle model has already been configured, the SOC can be powered on normally. For example, after receiving the power-on message from the vehicle gateway, the wake-up and power-on module needs to compare the power-on message with the power-on message corresponding to the currently configured vehicle model to see if they are consistent. If they are consistent, the various ECUs in the SOC will be powered on, thus powering on the SOC normally. If they are inconsistent, no action will be taken.
[0341] Step 1306: Wake up the MCU via a specific message.
[0342] Here, since the vehicle model has already been configured, if the MCU needs to be woken up again, only the wake-up message corresponding to the currently configured vehicle model can wake up the MCU. For example, if the wake-up and power-on module receives a wake-up message sent by the vehicle gateway again, it needs to compare the wake-up message with the wake-up message corresponding to the currently configured vehicle model to see if they match. If they match, the other ECUs in the MCU are powered on, thus waking up the MCU normally. If they do not match, no action is taken.
[0343] Step 1307, End.
[0344] Here, after the SOC is powered on normally, the intelligent driving computing platform ends the operation of waking up the MCU and powering on the SOC, and begins to execute relevant business.
[0345] In Implementation Scheme 1, the vehicle model notification message itself contains a specific vehicle model. This vehicle model can be used as the official vehicle model for capability set activation. In other words, after the SOC is powered on, there is no need to send diagnostic application messages through diagnostic equipment; the solution of sharing software packages across multiple vehicle models can be directly implemented. In other words, Implementation Scheme 1 only requires interaction between the vehicle gateway and the intelligent driving computing platform to complete the entire process of MCU wake-up, vehicle model configuration, and SOC power-on, without the need for diagnostic equipment. However, it should be understood that if the vehicle model needs to be modified after the SOC is powered on, diagnostic application messages can still be sent to the SOC through diagnostic equipment to reconfigure the vehicle model.
[0346] Implementation Plan 2: After waking up the MCU using a wake-up message, configure the vehicle model using a service feature message.
[0347] Please refer to Figure 14a, which exemplarily illustrates the module flow diagram of the vehicle processing method provided in Implementation Scheme 2. This module flow is similar to that in Implementation Scheme 1, except that the vehicle gateway sends a service feature message to the vehicle model dynamic identification module in the MCU. This service feature message indicates a temporary vehicle model and is only used for normal power-on of the SOC. Therefore, after powering on the SOC, the vehicle model needs to be reconfigured, for example, by sending a vehicle control word to the vehicle model configuration module in the SOC through a diagnostic device to complete the final vehicle model configuration.
[0348] Taking a vehicle model that has not yet been configured as an example, please refer to Figure 14b, which shows a schematic diagram of the execution flow of the in-vehicle processing method provided in Implementation Scheme 2. This flow includes the following steps:
[0349] Step 1401, Start.
[0350] Here, after the intelligent driving computing platform starts, it performs initialization operations to configure the vehicle in platform mode.
[0351] Step 1402: Wake up the MCU with an arbitrary wake-up message.
[0352] Here, in platform mode, any wake-up message can wake up the MCU. For example, referring to Figure 14a, after the wake-up and power-on module in the MCU receives a wake-up message sent by the vehicle gateway, regardless of whether the wake-up message is the wake-up message corresponding to the vehicle model itself, it will normally power on other ECUs in the MCU, thus normally waking up the MCU.
[0353] Step 1403: Receive service feature message.
[0354] For example, referring to Figure 14a, the vehicle model dynamic recognition module in the MCU receives the service feature message sent by the vehicle gateway. The service feature message carries service feature information, which is related to the vehicle model. Based on this relationship, the vehicle model dynamic recognition module determines the vehicle model corresponding to the service feature information in the service feature message and sends the vehicle model-related information to the vehicle model configuration module in the SOC.
[0355] Step 1404: Switch to a temporary vehicle model.
[0356] Here, after receiving the vehicle information from the vehicle dynamic recognition module, the vehicle configuration module in the SOC stores the vehicle information in the local system and activates the vehicle by restarting the intelligent driving computing platform. Alternatively, the vehicle can be configured directly without restarting. Since the vehicle configured at this time is indirectly indicated by the business feature message and lacks explicitness, this vehicle is considered a temporary vehicle, not the final vehicle.
[0357] Step 1405: The SOC can be powered on normally.
[0358] Here, since a temporary vehicle model has already been configured, the SOC can be powered on normally based on the temporary vehicle model. For example, after the wake-up and power-on module receives the power-on message sent by the vehicle gateway, it needs to compare the power-on message with the power-on message corresponding to the currently configured temporary vehicle model. If they match, the SOC is powered on normally; if they do not match, no action is taken.
[0359] Step 1406: Configure the vehicle model using diagnostic equipment.
[0360] Here, the temporary vehicle model configured via the business characteristic message is only used to power on the SOC. This temporary model is not necessarily the actual vehicle model. To execute the business normally, the vehicle needs to be updated from the temporary model to the official model. In this case, a diagnostic application message can be sent from the diagnostic device to the vehicle configuration module in the SOC. The diagnostic application message carries the vehicle configuration word. The vehicle configuration module updates the vehicle model originally stored in the local system based on the vehicle configuration word, thus making the official model effective.
[0361] Step 1407: Wake up the MCU via a specific message.
[0362] Here, because the vehicle model has been updated, if the MCU needs to be woken up again, only the wake-up message corresponding to the updated vehicle model can wake up the MCU. For example, if the wake-up and power-on module receives a wake-up message from the vehicle gateway again, it needs to compare the wake-up message with the wake-up message corresponding to the updated vehicle model. If they match, the MCU will be woken up normally; if they do not match, no action will be taken.
[0363] Step 1408, End.
[0364] Here, the intelligent driving computing platform ends the operation of waking up the MCU and powering on the SOC, and begins to execute relevant business operations.
[0365] In Implementation Scheme 2, temporary vehicle models can be identified by receiving service characteristic messages, thus enabling normal power-on of the SOC. After power-on, the official vehicle model can be configured through diagnostic equipment, ultimately achieving capability activation according to the official vehicle model and realizing a solution for multiple vehicle models sharing the same software package. Compared to Implementation Scheme 1, Implementation Scheme 2 requires three-way interaction between the vehicle gateway, diagnostic equipment, and intelligent driving computing platform to complete the entire process of MCU wake-up, vehicle model configuration, and SOC power-on. The involvement of diagnostic equipment is essential, and the vehicle models configured by the diagnostic equipment offer higher security and reliability.
[0366] It should be noted that configuring the official vehicle model via diagnostic equipment after powering on the SOC in Implementation Scheme 2 is just one example. In another example, the official vehicle model can also be configured by sending a vehicle model notification message through the gateway. Essentially, the gateway first sends a service characteristic message to activate the temporary vehicle model for normal SOC power-on, and then sends a vehicle model notification message to complete the final vehicle model configuration. In this case, only the gateway and the intelligent driving computing platform need to interact, resulting in lower complexity. Of course, other vehicle model configuration schemes may exist, which are not limited here.
[0367] The above content introduces an in-vehicle processing method provided in this application from the perspective of how to normally wake up the MCU. This in-vehicle processing method implements the wake-up and message sending status mechanism based on specific mode definitions. For example, in mode 1 (i.e., platform mode), it wakes up by any message and prohibits the external transmission of messages. In mode 2 (i.e., vehicle model mode), it wakes up by a specific vehicle model message and allows the external transmission of messages, so that products supporting shared vehicle models can be woken up normally and safely.
[0368] Next, from the perspective of vehicle model configuration, this application can also provide another in-vehicle processing method. This in-vehicle processing method does not limit the MCU wake-up method. That is to say, different modes can be configured to ensure MCU wake-up in the manner described above, or no mode can be configured, and the MCU can be woken up in the existing manner. However, after waking up the MCU, the vehicle model needs to be configured via a message, and the SOC is powered on after configuring the vehicle model. The specific implementation of this in-vehicle processing method will be briefly explained below.
[0369] Please refer to Figure 15, which shows a flowchart of another vehicle-mounted processing method provided in this application. For ease of understanding, it is assumed below that the first control unit is an MCU and the second control unit is a SOC. However, it should be understood that the MCU described below can be replaced by the first control unit, and the SOC can be replaced by the second control unit; this application does not specifically limit this. As shown in Figure 15, the process includes the following steps:
[0370] Step 1501: Receive the first message, which is used to indicate the first vehicle model information.
[0371] Here, the first message can be a message from an external tool, such as a diagnostic device, loaded into the intelligent driving platform, or a message sent from an internal component, such as a gateway; there is no limitation. In one example, the first message can be a vehicle model notification message or a business notification message, as described above, and will not be repeated here.
[0372] Optionally, the MCU can be woken up before the first message from the gateway is received.
[0373] Optionally, the MCU can be woken up in any way. For example, the MCU can be woken up by a wake-up message or a first wake-up command, as described in Implementation Scheme 1, Implementation Scheme 2, and other content above. Alternatively, the MCU can be woken up via the adaptive cruise control (ACC) power line, also known as the power-on line, which is a hard-wired wake-up method. The wake-up process can be found in Implementation Scheme 3 or Implementation Scheme 4 below, which will not be described in detail here.
[0374] Step 1502: Save the information of the first vehicle model.
[0375] Here, the information of the first vehicle model can be saved locally in the MCU.
[0376] Step 1503: Power on the second control unit based on the first vehicle model information.
[0377] Here, the MCU can safely wake up the SOC based on the locally stored first vehicle model information.
[0378] For example, the MCU can also receive a first power-on command, such as a first power-on command from the gateway, then retrieve the first vehicle model information stored locally, and compare the first power-on command with the second power-on command corresponding to the first vehicle model information. If they match, it means that the first power-on command is the power-on command for the currently configured vehicle model, and therefore, the MCU can power on the SOC normally. Conversely, if they do not match, it means that the first power-on command is invalid, and the MCU will not process it.
[0379] Optionally, after the MCU powers on the SOC, if it is necessary to update the vehicle model, it can also receive vehicle model configuration messages. These messages can be messages loaded from external devices such as diagnostic equipment or messages sent from the gateway, without limitation.
[0380] Taking a vehicle configuration message from a diagnostic device as an example, this message, also known as a diagnostic application message, contains second vehicle information. The MCU then activates this second vehicle information. For instance, the second vehicle information is stored in the local system, and the intelligent driving computing platform is restarted. This causes the platform to perform the initialization operations described above, configuring the vehicle to match the second vehicle information and activating the software package capabilities of that vehicle.
[0381] Optionally, before applying the second vehicle model information, the MCU can first retrieve the locally stored vehicle model information and compare it with the second vehicle model information. If the vehicle model information does not exist locally, or if the locally stored vehicle model information exists but differs from the second vehicle model information, it indicates that the vehicle model needs to be updated. In this case, the MCU can store the second vehicle model information locally and restart the intelligent driving computing platform. Conversely, if the locally stored vehicle model information exists and is the same as the second vehicle model information, it means that the currently applied vehicle model is the one indicated by the second vehicle model information. In this case, there is no need to update the vehicle model, and the MCU does not perform any processing.
[0382] In one example, if the first message is the aforementioned service characteristic message, since it is a service message already in use in the vehicle, its information content is limited and its vehicle model is unclear. Therefore, it can be assumed that the actual vehicle model needs to be reconfigured after power-on SOC. That is, a second message carrying the second vehicle model information is sent via diagnostic equipment. If the first message is the aforementioned vehicle model notification message, then all vehicle model information can be carried in the vehicle model notification message. In this case, there is no need to reconfigure the vehicle model.
[0383] Based on the vehicle processing method shown in Figure 15, even if the SOC is not powered on, the vehicle model can be configured through the first message sent by the gateway, providing support for the SOC that is powered on normally and assisting in the implementation of a solution that shares software packages among multiple vehicle models.
[0384] To facilitate understanding of the solution, we will now introduce two possible implementations of the vehicle-mounted processing method shown in Figure 15 through implementation schemes three and four. Both implementations take the hard-wired wake-up of the MCU as an example. The wake-up method via wake-up message can be found in implementation schemes one and two above, and will not be repeated here.
[0385] Before introducing the specific implementation scheme, please refer to Figure 16, which illustrates a possible module implementation flow of the hard-wired MCU wake-up and power-on / off SOC scheme in the prior art. As shown in Figure 16, in the prior art, after vehicle assembly, the MCU is first woken up by applying voltage to it via the ACC hardwire through the vehicle power management module. Then, the SOC power-on message is sent to the wake-up and power-on module in the MCU through the vehicle gateway to power on the SOC. After the SOC is powered on, the vehicle configuration word is sent to the vehicle configuration module in the SOC through the diagnostic equipment to configure the vehicle model and activate the corresponding capability set. According to this implementation method, only a specific single power-on message can power on the SOC. Therefore, if a multi-vehicle shared software package scheme is used, if the power-on message sent by the gateway and the vehicle model of the intelligent driving computing platform product are inconsistent on the customer's vehicle assembly line, the MCU cannot power on the SOC, and thus cannot configure the vehicle configuration word through the diagnostic equipment. Therefore, the prior art implementation scheme can only have one software package per vehicle model.
[0386] Both Implementation Scheme 3 and Implementation Scheme 4 below can solve this technical problem in the prior art.
[0387] Implementation Plan 3: After waking up the MCU using a hard wire, configure the vehicle model using the vehicle model notification message.
[0388] Please refer to Figure 17a, which exemplarily illustrates a module flow diagram of the vehicle processing method provided in Implementation Scheme 3. In this example, after vehicle assembly is completed, the MCU can be hardwired and woken up first through the vehicle power management module. Then, a vehicle model notification message is sent to the vehicle model dynamic identification module in the MCU through the vehicle gateway, and a power-on message is sent to the wake-up and power-on module in the MCU. The vehicle model dynamic identification module uses the vehicle model notification message to identify the vehicle model and sends it to the vehicle model configuration module in the SOC, thereby completing the vehicle model configuration. After successful vehicle model configuration, the wake-up and power-on module can use the power-on message to power on the SOC normally.
[0389] Please refer to Figure 17b, which shows a schematic diagram of the execution flow of the on-board processing method provided in Implementation Scheme 3. The flow includes the following steps:
[0390] Step 1701, Start.
[0391] Here, after the intelligent driving computing platform starts, it performs initialization operations and applies the locally stored configuration information.
[0392] Step 1702: Wake up the MCU via ACC hardwire.
[0393] Here, referring to Figure 17a above, the vehicle power management module can apply voltage to the ACC hardwire connected to the MCU, thereby directly powering on the MCU. Furthermore, considering the low power consumption of the MCU, a small voltage level can be applied to the MCU to meet the power consumption requirements.
[0394] Step 1703: Receive vehicle model notification message.
[0395] For example, referring to Figure 17a, a vehicle model notification message can be sent from the vehicle gateway to the vehicle model dynamic identification module in the MCU. This message carries a specific vehicle model, such as the vehicle's actual model. After identifying the vehicle model carried in the notification message, the vehicle model dynamic identification module sends the relevant information to the vehicle configuration module in the SOC.
[0396] Step 1704: Switch vehicle model.
[0397] Here, the vehicle configuration module in the SOC can store the vehicle information sent by the vehicle dynamic recognition module to the local system, and restart the intelligent driving computing platform, so that the intelligent driving computing platform can perform initialization operations, activate the locally stored vehicle information, complete the vehicle configuration, and activate the corresponding capability set of the vehicle.
[0398] Step 1705, the SOC can be powered on normally.
[0399] Here, since the vehicle model has already been configured, only power-on messages matching the vehicle model can power on the SOC normally. That is to say, if the power-on message sent by the vehicle gateway is consistent with the power-on message corresponding to the currently configured vehicle model, the wake-up and power-on modules in the MCU can power on the SOC; otherwise, no processing is performed.
[0400] Step 1706: Wake up the MCU via a specific message.
[0401] Here, since the vehicle model has already been configured, if the MCU needs to be woken up again, only the wake-up message corresponding to the currently configured vehicle model can wake up the MCU. That is to say, if the vehicle gateway sends a wake-up message later, the wake-up and power-on modules in the MCU will only wake up the MCU if the wake-up message is consistent with the wake-up message corresponding to the currently configured vehicle model; otherwise, no processing will be performed.
[0402] Step 1707, End.
[0403] Here, the intelligent driving computing platform ends the operation of waking up the MCU and powering on the SOC, and begins to execute relevant business operations.
[0404] In implementation scheme three, the MCU is woken up by hardware ACC and then receives the vehicle model notification message, which can identify and configure the official vehicle model, so that the SOC can be powered on correctly. Moreover, after the SOC is powered on, there is no need to reconfigure the vehicle model through diagnostic equipment.
[0405] Implementation Plan 4: After waking up the MCU using a hardwired method, configure the vehicle model using service feature messages.
[0406] Please refer to Figure 18a, which exemplarily illustrates a module flow diagram of the vehicle processing method provided in Implementation Scheme 4. This module flow is similar to that in Implementation Scheme 3, except that the vehicle gateway sends a service feature message to the vehicle model dynamic identification module in the MCU. This service feature message indicates a temporary vehicle model and is only used for normal power-on of the SOC. Therefore, after powering on the SOC, the vehicle model needs to be reconfigured, for example, by sending a vehicle control word to the vehicle model configuration module in the SOC through a diagnostic device to complete the final vehicle model configuration.
[0407] Please refer to Figure 18b, which shows a schematic diagram of the execution flow of the on-board processing method provided in Implementation Scheme 4. The flow includes the following steps:
[0408] Step 1801, Start.
[0409] Here, after the intelligent driving computing platform starts, it performs initialization operations and applies the locally stored configuration information.
[0410] Step 1802: Wake up the MCU via ACC hardwire.
[0411] Here, referring to Figure 18a above, the vehicle power management module can apply voltage to the ACC line connected to the MCU, thereby powering on the MCU directly, and the power-on voltage is a small level.
[0412] Step 1803: Receive service feature message.
[0413] For example, referring to Figure 18a, a business feature message can be sent from the vehicle gateway to the vehicle model dynamic identification module in the MCU. The vehicle model dynamic identification module determines the vehicle model corresponding to the business feature information in the business feature message based on the relationship between the business feature information and the vehicle model, and sends the vehicle model-related information to the vehicle model configuration module in the SOC.
[0414] Step 1804: Switch to a temporary vehicle model.
[0415] Here, the vehicle configuration module in the SOC stores the vehicle information sent by the vehicle dynamic recognition module to the local system and activates the vehicle configuration by restarting the intelligent driving computing platform. Alternatively, the vehicle configuration can be performed directly without restarting. Since the vehicle configuration at this time is indirectly indicated by the business feature message and lacks explicitness, this vehicle configuration is considered a temporary vehicle configuration, not a formal one.
[0416] Step 1805: The SOC can be powered on normally.
[0417] Here, the SOC can be powered on normally based on the configured temporary vehicle model. For example, if the power-on message sent by the vehicle gateway is consistent with the power-on message corresponding to the currently configured temporary vehicle model, the wake-up and power-on modules in the MCU can power on the SOC; otherwise, no action is taken.
[0418] Step 1806: Configure the vehicle model using diagnostic equipment.
[0419] Here, the temporary vehicle model configured via the business characteristic message is only used to power on the SOC. To execute the business normally, the vehicle needs to be updated from the temporary model to the final model. In this case, a vehicle configuration word can be sent to the vehicle configuration module in the SOC via a diagnostic device. The vehicle configuration module then updates the vehicle model originally stored in its local system based on the vehicle configuration word, thus making the final model effective.
[0420] Step 1807: Wake up the MCU via a specific message.
[0421] Here, because the vehicle model has been updated, only the wake-up message corresponding to the updated model can wake up the MCU. For example, if the wake-up and power-on module receives a wake-up message from the vehicle gateway again, the MCU can be woken up normally only if the wake-up message matches the wake-up message corresponding to the updated model; otherwise, no action is taken.
[0422] Step 1808, End.
[0423] Here, the intelligent driving computing platform ends the operation of waking up the MCU and powering on the SOC, and begins to execute relevant business operations.
[0424] In implementation scheme four, the MCU is woken up via hardware ACC and then receives service characteristic messages, which allows for the identification of temporary vehicle models and the correct power-on of the SOC. After powering on the SOC, the official vehicle model can be configured using a diagnostic tool, ultimately enabling capabilities to be activated according to the determined vehicle model, and ultimately allowing multiple vehicle models to share the upgrade package.
[0425] Based on the vehicle processing method described above, vehicle identification, configuration, and updates can be performed by defining proprietary vehicle notification messages or existing business feature messages, thereby activating the corresponding vehicle's capability set, achieving smooth vehicle switching, and enabling the business functions of specific vehicle models to work normally. For example, it can enable the safe power-on of the SOC of intelligent driving platform products, and enable products that support co-packaged vehicle models to power on and off normally and process safely.
[0426] The above implementation schemes one through four describe four possible implementation schemes of the vehicle processing method provided in this application. In each of these four implementation schemes, the MCU wake-up and power-on module, the vehicle model dynamic recognition module, and the SOC vehicle model configuration module are combined to realize the MCU wake-up, vehicle model configuration, and SOC power-on operations. In one example, considering that the MCU wake-up and power-on module is mainly used to implement the MCU wake-up and SOC power-on functions, while the MCU vehicle model dynamic recognition module and the SOC vehicle model configuration module are combined to perform the vehicle model configuration function, the MCU vehicle model dynamic recognition module and the SOC vehicle model configuration module can also be combined into one module, called the vehicle model recognition and management module.
[0427] Based on this, please refer to Figure 19, which shows a schematic diagram of the module architecture for implementing an in-vehicle processing method provided in this application. In this architecture, the intelligent driving computing platform includes a wake-up and power-on module, as well as a vehicle model recognition and management module. The wake-up and power-on module runs in the MCU and is connected to the vehicle gateway outside the intelligent driving computing platform. It is mainly responsible for the sleep and wake-up of the MCU in the intelligent driving computing platform, as well as the power-on and wake-up management of the SOC. The vehicle model recognition and management module is connected to the vehicle gateway and diagnostic equipment outside the intelligent driving computing platform. It is mainly responsible for the recognition and conversion of vehicle models in the multi-vehicle shared software package solution, as well as the activation of vehicle-related capability sets. The vehicle model recognition and management module can run in both the SOC and the MCU. For example, the sub-module responsible for dynamic vehicle model recognition in the vehicle model recognition and management module runs in the MCU, while the module responsible for vehicle model configuration runs in the SOC.
[0428] It is understood that the architecture shown in Figure 19 is only one possible software or hardware architecture, but other modular architectures may also exist, as long as they can achieve the in-vehicle processing solution described above. This application does not make any specific limitations on this.
[0429] The above implementation scheme can be deployed in intelligent / autonomous driving computing platform products. For example, it can be loaded into intelligent driving software or run as a hardware module in in-vehicle intelligent driving products. Through wake-up mechanisms and vehicle model switching mechanisms in specific modes, safe wake-up and power-on of intelligent driving computing platform products in multi-vehicle co-operation scenarios can be achieved, supporting the promotion of multi-vehicle co-operation solutions.
[0430] However, it should be understood that the above implementation scheme is not only applicable to in-vehicle intelligent driving computing platform products, but also applicable to any in-vehicle computing platform, such as gateways, T-Boxes, vehicle control systems, etc. This application does not make any specific limitations in this regard.
[0431] Based on the vehicle-mounted processing method described above, this application can also provide a vehicle-mounted processing device that can be used to execute the above vehicle-mounted processing method. The relevant features can be found in the above embodiments, and will not be repeated here.
[0432] In one possible implementation, Figure 20 shows a possible structural schematic diagram of an in-vehicle processing device provided in this application. The in-vehicle processing device 2000 can be the intelligent driving computing platform or a module in intelligent driving (e.g., MCU, circuit, chip, or chip system, etc.) described in the above embodiments, or it can be a logic node, logic module, or software applied to or used in conjunction with the intelligent driving computing platform or its modules, capable of realizing all or part of the functions of the intelligent driving computing platform.
[0433] The vehicle-mounted processing device 2000 may include modules or units for implementing the methods corresponding to the intelligent driving computing platform side in the above method embodiments. For example, in one possible design, the vehicle-mounted processing device 2000 may include: a transceiver unit 2010, an acquisition unit 2020, and a wake-up unit 2030. The transceiver unit 2010 may also be referred to as a communication unit, transceiver, transceiver device, or transceiver unit, etc., and the acquisition unit 2020 and the wake-up unit 2030 may also be collectively referred to as a processing unit, processor, processing chip, processing board, or processing device, etc.
[0434] The acquisition unit 2020 is used to perform the acquisition operation in the above-mentioned vehicle processing method, the wake-up unit 2030 is used to perform the wake-up operation in the above-mentioned vehicle processing method, and the transceiver unit 2010 can be used to perform the sending operation and receiving operation in the above-mentioned vehicle processing method. The device in the transceiver unit 2010 that implements the receiving function can be regarded as the receiving unit, and the device in the transceiver unit 2010 that implements the sending function can be regarded as the sending unit. That is, the transceiver unit 2010 includes a receiving unit and a sending unit.
[0435] For example, in one embodiment, if the vehicle processing device 2000 executes the vehicle processing method shown in Figure 3 above, then: the transceiver unit 2010 is used to receive a first wake-up command, the acquisition unit 2020 is used to acquire the current mode of the vehicle, and the wake-up unit 2030 wakes up the first control unit if it determines that the current mode is platform mode, and wakes up the first control unit if it determines that the current mode is vehicle model mode, and wakes up the first control unit when the first wake-up command matches the second wake-up command of the vehicle model corresponding to the vehicle model mode. Here, platform mode is the mode when the vehicle is not configured with a vehicle model, and vehicle model mode is the mode after the vehicle is configured with a vehicle model.
[0436] In another possible implementation, Figure 21 shows a possible structural schematic diagram of another vehicle-mounted processing device provided in this application. The vehicle-mounted processing device 2100 may be the intelligent driving computing platform or a module in intelligent driving (e.g., MCU, circuit, chip or chip system, etc.) in the above embodiments, or it may be a logic node, logic module or software applied to the intelligent driving computing platform or its module, or used in conjunction with the intelligent driving computing platform or its module, capable of realizing all or part of the functions of the intelligent driving computing platform.
[0437] The vehicle-mounted processing device 2100 may include modules or units for implementing the methods corresponding to the intelligent driving computing platform side in the above method embodiments. For example, in one possible design, the vehicle-mounted processing device 2100 may include: a transceiver unit 2110, a storage unit 2120, and an activation unit 2130. The transceiver unit 2110 may also be referred to as a communication unit, transceiver, transceiver device, or transceiver unit, etc., and the storage unit 2120 and the activation unit 2130 may also be collectively referred to as a processing unit, or a processor, processing chip, processing board, or processing device, etc.
[0438] The storage unit 2120 is used to perform the storage operation in the above-mentioned vehicle processing method, the activation unit 2130 is used to perform the activation operation in the above-mentioned vehicle processing method, and the transceiver unit 2110 can be used to perform the sending operation and receiving operation in the above-mentioned vehicle processing method. The device in the transceiver unit 2110 that implements the receiving function can be regarded as the receiving unit, and the device in the transceiver unit 2110 that implements the sending function can be regarded as the sending unit. That is, the transceiver unit 2110 includes a receiving unit and a sending unit.
[0439] For example, in one embodiment, if the vehicle processing device 2100 executes the vehicle processing method in FIG15 above, then: the transceiver unit 2110 is used to receive a first message, the first message is used to indicate the first vehicle model information, the storage unit 2120 is used to store the first vehicle model information, and the activation unit 2130 is used to activate the second control unit according to the first vehicle model information.
[0440] It is understood that the division of units in the above-described device is merely a logical functional division. One function can correspond to one functional unit, or two or more functions can be integrated into one functional unit. In actual implementation, all or some units can be integrated onto a single physical entity, or distributed across different physical entities. Furthermore, the aforementioned functional units can be implemented in hardware, software, or a combination of both. Whether a function is executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for specific applications, but such implementations should not be considered beyond the scope of this application.
[0441] In one example, the functional unit in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as: one or more application-specific integrated circuits (ASICs), or one or more central processing units (CPUs), one or more MCUs, one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms.
[0442] In another possible implementation, please refer to Figure 22, which shows another possible structural schematic of the in-vehicle processing device. The in-vehicle processing device 2200 shown in Figure 22 includes at least one processor 2210 and interface circuitry 2220. The at least one processor 2210 is coupled to a memory. Optionally, the memory may be located within the in-vehicle processing device 2200 and integrated with the processor 2210, or it may be located outside the in-vehicle processing device 2200. For example, the in-vehicle processing device 2200 may also include at least one memory 2230. The at least one memory 2230 stores the necessary computer programs (or instructions) and / or data for implementing any of the above embodiments; the at least one processor 2210 can execute the computer programs (or instructions) and / or data stored in the at least one memory 2230 to complete the methods in any of the above embodiments.
[0443] The vehicle-mounted processing device 2200 can interact with other devices through the interface circuit 2220. For example, the interface circuit 2220 can be a transceiver, circuit, bus, module, pin, or other type of communication interface. When the vehicle-mounted processing device 2200 is a chip-type device or circuit, the interface circuit 2220 can also be an input / output circuit, capable of inputting information (or receiving information) and outputting information (or sending information). The processor can be an integrated processor, microprocessor, integrated circuit, or logic circuit, and the processor can determine the output information based on the input information.
[0444] The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 2210 may operate in conjunction with the memory 2230 and the interface circuit 2220. This embodiment does not limit the specific connection medium between the processor 2210, the memory 2230, and the interface circuit 2220.
[0445] Optionally, referring to Figure 22, the processor 2210, the memory 2230, and the interface circuit 2220 are interconnected via a bus. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 22, but this does not indicate that there is only one bus or one type of bus.
[0446] In the embodiments of this application, the processor 2210 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.
[0447] In this embodiment, the memory 2230 can be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). The memory 2230 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory 2230 in this embodiment can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.
[0448] When the on-board processing device 2200 is used to implement the above method embodiments, the processor 2210 is used to implement the functions of the acquisition unit 2020 and the wake-up unit 2030. The interface circuit 2220 is used to implement the functions of the transceiver unit 2010, which will not be described again here.
[0449] Based on the above description, this application may also provide an intelligent driving computing platform, as shown in FIG23. The intelligent driving computing platform 2310 may include an on-board processing device 2311. The on-board processing device 2311 may be any of the aforementioned on-board processing devices, such as the on-board processing device 2100 shown in FIG21, or the on-board processing device 2200 shown in FIG22, without any specific limitation.
[0450] Based on the above description, this application may also provide an in-vehicle processing system 2300, as shown in FIG23, which includes an intelligent driving computing platform, such as the intelligent driving computing platform 2310 described above.
[0451] Optionally, as shown in Figure 23, the vehicle processing system 2300 may also include a vehicle gateway 2320. The vehicle gateway 2320 is connected to the intelligent driving computing platform 2310, such as to the vehicle processing device 2311 in the intelligent driving computing platform 2310. It is used to send one or more of the first wake-up command, the first power-on command, and the first message mentioned above to the vehicle processing device 2311. The vehicle processing device 2311 wakes up the first control unit according to the first wake-up command, powers up the second control unit according to the first power-on command, and configures the vehicle model according to the first message, as described above, without further elaboration.
[0452] Optionally, as shown in Figure 23, the vehicle processing system 2300 may also include a diagnostic device 2330. The diagnostic device 2330 is connected to the intelligent driving computing platform 2310, such as to the vehicle processing device 2311 in the intelligent driving computing platform 2310, and is used to send a diagnostic application message to the vehicle processing device 2311. The diagnostic application message includes a vehicle model configuration word, and the vehicle processing device 2311 configures the vehicle model according to the vehicle model configuration word.
[0453] Optionally, as shown in Figure 23, the vehicle processing system 2300 may also include a vehicle chassis 2340, which is connected to the intelligent driving computing platform 2310, such as to the vehicle processing device 2311 in the intelligent driving computing platform 2310, for performing corresponding operations according to the control instructions of the vehicle processing device 2311, such as driving the wheels to steer.
[0454] It should be noted that the vehicle-mounted processing system 2300 may also include other structures or devices, such as mechanical transmission systems, motor controllers, wheel axles, etc., which are not specifically limited in this application.
[0455] Based on the above description, this application may also provide a vehicle, which may include the above-mentioned vehicle-mounted processing system, intelligent driving computing platform or vehicle-mounted processing device. The vehicle-mounted processing system may be any of the aforementioned vehicle-mounted processing systems, such as the vehicle-mounted processing system 2300 shown in FIG. 23. The intelligent driving computing platform may be any of the aforementioned intelligent driving computing platforms, such as the intelligent driving computing platform 2310 shown in FIG. 23. The vehicle-mounted processing device may be any of the aforementioned vehicle-mounted processing devices, such as the vehicle-mounted processing device 2000 shown in FIG. 20, or the vehicle-mounted processing device 2200 shown in FIG. 22, or the vehicle-mounted processing device 2311 shown in FIG. 23.
[0456] For example, the aforementioned vehicles may include, but are not limited to: cars, trucks, buses, recreational vehicles, amusement park vehicles, construction vehicles, trams, golf carts, trains, driverless cars, intelligent cars, and digital cars.
[0457] Based on the vehicle-mounted processing method described above, this application may also provide a computer-readable storage medium storing a computer program or instructions, which, when executed on a computer, implement the vehicle-mounted processing method as described in any of the above embodiments.
[0458] Based on the in-vehicle processing method described above, this application can also provide a computer program product, which includes a computer program that, when executed by a computer, implements the in-vehicle processing method as described in any of the above embodiments.
[0459] In this application, "at least one" means one or more, and "more than one" means two or more. "Including at least one" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple. Additionally, in this application, the terms "exemplarily" or "optionally" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "optional" in this application should not be construed as preferred or advantageous over other embodiments or designs. Alternatively, it can be understood that the use of the terms "exemplary" or "optional" is intended to present concepts in a specific manner and does not constitute a limitation on this application.
[0460] It is understood that the various numerical designations used in this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic. The terms "first," "second," "third," and similar expressions are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or device is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.
Claims
1. A vehicle-mounted processing method, characterized in that, The method includes: Receive the first wake-up command; Get the vehicle's current mode; If the current mode is platform mode, then the first control unit is woken up; If the current mode is a vehicle model mode, then the first control unit is woken up when the first wake-up command matches the second wake-up command of the vehicle model corresponding to the vehicle model mode; The platform mode refers to the mode when the vehicle is not configured with a specific model, while the model mode refers to the mode after the vehicle is configured with a specific model.
2. The method as described in claim 1, characterized in that, The method further includes: When the current mode is platform mode, the first control unit is allowed to send messages from the whitelist; When the current mode is vehicle model mode, the first control unit is allowed to send messages that correspond to the vehicle model. The messages in the whitelist include upgrade messages and / or diagnostic messages.
3. The method as described in claim 1 or 2, characterized in that, After waking up the first control unit in the platform mode, the system further includes: Receive a first message, which is used to indicate the first vehicle model information; Save the information of the first vehicle model.
4. The method as described in claim 3, characterized in that, The first message contains the first vehicle model information, or the first message contains service feature information, which is used to indicate the first vehicle model information.
5. The method as described in claim 4, characterized in that, The business characteristic information includes one or more of the following: The first message contains the device identifier, high-voltage signal, liquid cooling signal, and ignition signal of the destination device.
6. The method according to any one of claims 3 to 5, characterized in that, After saving the first vehicle model information, the method further includes: Receive the first power-on command; When the first power-on command matches the second power-on command corresponding to the vehicle model information of the first vehicle model, the second control unit is powered on. The second control unit is different from the first control unit.
7. The method as described in claim 6, characterized in that, The first control unit is a microcontroller unit (MCU) in the intelligent driving computing platform, and the second control unit is an electronic control unit other than the first control unit in the intelligent driving computing platform.
8. The method as described in claim 6 or 7, characterized in that, Following the power-on second control unit, the system also includes: Receive a second message from the diagnostic device, the second message containing second vehicle model information; The second vehicle model information is now effective.
9. The method as described in claim 8, characterized in that, The effective second vehicle model information includes: If the second vehicle model information is different from the locally stored vehicle model information, the second vehicle model information is stored locally, and the first control unit is restarted. The restart is used to activate the software package for the vehicle model corresponding to the second vehicle model information.
10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: In response to the operation of activating the first control unit, the vehicle model information stored locally is obtained; If vehicle model information is stored locally, the current mode of the vehicle is configured to the vehicle model mode, the wake-up command corresponding to the vehicle model information is activated, and the message sending switch corresponding to the vehicle model information is turned on. If vehicle model information is not stored locally, the current mode of the vehicle will be configured to the platform mode, the wake-up command for all vehicle models will be activated, and the message sending switch in the whitelist will be turned on.
11. A vehicle-mounted processing method, characterized in that, The method includes: Receive a first message, which is used to indicate the first vehicle model information; Save the information of the first vehicle model; Based on the information of the first vehicle model, the second control unit is powered on.
12. The method as described in claim 11, characterized in that, The first message contains the first vehicle model information, or the first message contains service feature information, which is used to indicate the first vehicle model information.
13. The method as described in claim 12, characterized in that, The business characteristic information includes one or more of the following: The first message contains the device identifier, high-voltage signal, liquid cooling signal, and ignition signal of the destination device.
14. The method according to any one of claims 11 to 13, characterized in that, The step of powering on the second control unit based on the first vehicle model information includes: Receive the first power-on command; When the first power-on command matches the second power-on command corresponding to the vehicle model information of the first vehicle model, the second control unit is powered on.
15. The method as described in claim 14, characterized in that, Following the power-on second control unit, the system also includes: Receive a second message from the diagnostic device, the second message containing second vehicle model information; The second vehicle model information is now effective.
16. The method as described in claim 15, characterized in that, The effective second vehicle model information includes: If the second vehicle model information is different from the locally stored vehicle model information, the second vehicle model information is stored locally and the first control unit is restarted. The restart is used to activate the software package for the vehicle model corresponding to the second vehicle model information. The first control unit is different from the second control unit.
17. The method according to any one of claims 11 to 16, characterized in that, Before receiving the first message, the process also includes: The first control unit is activated by controlling the ACC power line via adaptive cruise control; or... The first control unit is awakened by the first wake-up command; The first control unit is different from the second control unit.
18. The method as described in claim 17, characterized in that, The step of waking up the first control unit via a first wake-up command includes: Receive the first wake-up command; If the vehicle's current mode is platform mode, then the first control unit is activated; If the current mode of the vehicle is a vehicle model mode, then the first control unit is woken up when the first wake-up command matches the second wake-up command of the vehicle model corresponding to the vehicle model mode; The platform mode refers to the mode when the vehicle is not configured with a specific model, while the model mode refers to the mode after the vehicle is configured with a specific model.
19. The method as described in claim 18, characterized in that, The method further includes: When the current mode is platform mode, the first control unit is allowed to send messages from the whitelist; When the current mode is vehicle model mode, the first control unit is allowed to send messages that correspond to the vehicle model. The messages in the whitelist include upgrade messages and / or diagnostic messages.
20. The method according to any one of claims 16 to 19, characterized in that, The first control unit is a microcontroller unit (MCU) in the intelligent driving computing platform, and the second control unit is an electronic control unit other than the first control unit in the intelligent driving computing platform.
21. The method according to any one of claims 16 to 20, characterized in that, The method further includes: In response to the operation of activating the first control unit, the vehicle model information stored locally is obtained; If vehicle model information is stored locally, the current mode of the vehicle is configured to the vehicle model mode, the wake-up command corresponding to the vehicle model information is activated, and the message sending switch corresponding to the vehicle model information is turned on. If vehicle model information is not stored locally, the current mode of the vehicle will be configured to the platform mode, the wake-up command for all vehicle models will be activated, and the message sending switch in the whitelist will be turned on.
22. A vehicle-mounted processing device, characterized in that, It includes units and / or modules for implementing the method as described in any one of claims 1 to 10, or units and / or modules for implementing the method as described in any one of claims 11 to 21.
23. A vehicle-mounted processing device, characterized in that, The device includes a processor coupled to a memory, the processor being configured to execute a computer program or instructions stored in the memory to cause the on-board processing device to perform the method as claimed in any one of claims 1 to 10, or to perform the method as claimed in any one of claims 11 to 21.
24. A vehicle, characterized in that, Includes the vehicle-mounted processing device as described in claim 22 or 23.
25. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions that, when executed, implement the method as claimed in any one of claims 1 to 10, or the method as claimed in any one of claims 11 to 21.
26. A computer program product, characterized in that, The computer program product includes computer program code that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 10, or the method as described in any one of claims 11 to 21.