Management method and device, vehicle, medium and program product

Abstract

The application relates to the technical field of vehicle management and control, in particular to a management and control method and device, a vehicle, a medium and a program product. The method comprises the following steps: in response to a power-on signal of a vehicle, a first check request sent by a cloud and a second check request sent by a vehicle end are received respectively; a first check controller is controlled to analyze first cipher data in the first check request to generate a first check result, and a second check controller is controlled to analyze second cipher data in the second check request to generate a second check result; at least one driving parameter of the vehicle is determined based on the first check result and the second check result, so that the vehicle is managed and controlled according to the at least one driving parameter. Thus, the problem that a strategy for identifying and controlling by means of regulations and artificial detection in the related art cannot effectively identify and avoid the problem of illegal international sale is solved.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a control method, device, vehicle, medium and program product. Background Technology

[0002] In related technologies, the vehicle's VIN (Vehicle Identification Number) code is uploaded to the cloud in real time through the vehicle terminal, and the vehicle location is tracked by combining GPS (Global Positioning System) positioning; vehicle management can also be achieved by recording information on vehicle production, sales, logistics and other links; and vehicle management can also be achieved by recognizing vehicle document information through OCR (Optical Character Recognition) technology and comparing it with the database.

[0003] However, most of the related technologies rely solely on regulatory requirements and human detection to identify and control illegal international sales, which fails to effectively identify and circumvent such practices and urgently needs improvement. Summary of the Invention

[0004] This application provides a control method, device, vehicle, medium, and program product to address the fact that most related technologies rely solely on regulatory requirements and human inspection for identification and control, which fails to effectively identify and circumvent issues such as illegal international sales.

[0005] A first aspect of this application provides a vehicle management method, including cloud-based verification and vehicle-side verification. The method includes the following steps: in response to a vehicle power-on signal, receiving a first verification request sent from the cloud and a second verification request sent from the vehicle; controlling a first verification controller to parse first encrypted data in the first verification request to generate a first verification result, and controlling a second verification controller to parse second encrypted data in the second verification request to generate a second verification result; and determining at least one driving parameter of the vehicle based on the first verification result and the second verification result, so as to manage the vehicle according to the at least one driving parameter.

[0006] Optionally, in one embodiment of this application, controlling the first verification controller to parse the first ciphertext data in the first verification request to generate a first verification result includes: controlling the first verification controller to parse the first ciphertext data to generate corresponding first plaintext data; based on the first plaintext data, determining whether the first verification status of the first verification request is a verification passed status; if the first verification status is the verification passed status, generating the first verification result based on the verification passed status; if the first verification status is not the verification passed status, counting the number of anomalies where the first verification status is not the verification passed status, and generating a corresponding alarm signal and the signal level of the alarm signal based on the number of anomalies to obtain the first verification result.

[0007] Optionally, in one embodiment of this application, determining whether the first verification status of the first verification request is a verification passed status based on the first plaintext data includes: obtaining network data of the first verification controller; and determining whether the first verification status is the verification passed status based on the network data and the first plaintext data.

[0008] Optionally, in one embodiment of this application, generating a corresponding alarm signal and a signal level of the alarm signal based on the number of anomalies includes: detecting an alarm interval in which the number of anomalies falls based on the number of anomalies; generating the alarm signal based on the alarm interval; and determining the signal level based on the alarm signal.

[0009] Optionally, in one embodiment of this application, determining at least one driving parameter of the vehicle based on the first verification result and the second verification result includes: identifying the verification features of the corresponding verification controller based on the first verification result and the second verification result; and determining the at least one driving parameter based on the verification features.

[0010] A second aspect of this application provides a vehicle management device, including cloud-based verification and vehicle-side verification. The device includes: a receiving module, configured to receive a first verification request sent from the cloud and a second verification request sent from the vehicle in response to a power-on signal from the vehicle; a parsing module, configured to control a first verification controller to parse first encrypted data in the first verification request to generate a first verification result, and control a second verification controller to parse second encrypted data in the second verification request to generate a second verification result; and a determining module, configured to determine at least one driving parameter of the vehicle based on the first verification result and the second verification result, so as to manage the vehicle according to the at least one driving parameter.

[0011] Optionally, in one embodiment of this application, the parsing module includes: a parsing unit, configured to control the first verification controller to parse the first ciphertext data to generate corresponding first plaintext data; a judging unit, configured to judge, based on the first plaintext data, whether the first verification status of the first verification request is a verification passed status; a first generation unit, configured to generate the first verification result according to the verification passed status when the first verification status is the verification passed status; and a second generation unit, configured to count the number of anomalies when the first verification status is not the verification passed status, and generate a corresponding alarm signal and the signal level of the alarm signal according to the number of anomalies, so as to obtain the first verification result.

[0012] Optionally, in one embodiment of this application, the determining unit includes: an acquisition subunit, configured to acquire network data of the first verification controller; and a determining subunit, configured to determine whether the first verification state is the verification passed state based on the network data and the first plaintext data.

[0013] Optionally, in one embodiment of this application, the second generation unit includes: a detection subunit, configured to detect an alarm interval in which the number of abnormalities falls based on the number of abnormalities; a generation subunit, configured to generate an alarm signal based on the alarm interval; and a determination subunit, configured to determine the signal level based on the alarm signal.

[0014] Optionally, in one embodiment of this application, the determining module includes: an identification unit, configured to identify the verification features of the corresponding verification controller based on the first verification result and the second verification result; and a determining unit, configured to determine the at least one driving parameter based on the verification features.

[0015] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle control method as described in the above embodiments.

[0016] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle control method described above.

[0017] A fifth aspect of this application provides a computer program product, including a computer program that, when executed, implements the vehicle control method described above.

[0018] This application embodiment can respond to the vehicle's power-on signal and receive a first verification request sent from the cloud and a second verification request sent from the vehicle. It then parses the first encrypted data in the first verification request and the second encrypted data in the second verification request to generate corresponding verification results. This determines the vehicle's driving parameters for vehicle control. This dual verification significantly increases the difficulty of malicious attacks or tampering with the system, effectively preventing unauthorized vehicle access or malicious control, ensuring vehicle driving safety, improving the reliability of the vehicle control system, reducing the risk of vehicle loss of control due to system failures, and enabling flexible control of vehicle driving parameters to meet the personalized needs of different users and improve user experience. Therefore, it solves the problem that most related technologies rely solely on regulatory requirements and manual detection for identification and control, which fails to effectively identify and circumvent issues such as illegal international sales.

[0019] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0020] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a block diagram illustrating a vehicle control scheme according to an embodiment of this application; Figure 2 This is a block diagram illustrating another vehicle control scheme according to an embodiment of this application; Figure 3 A flowchart illustrating a vehicle control method according to an embodiment of this application; Figure 4 A flowchart illustrating the working principle of a vehicle control method according to an embodiment of this application; Figure 5 This is a block diagram of a vehicle control device provided according to an embodiment of this application; Figure 6 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0022] Before introducing the vehicle control method proposed in the embodiments of this application, the control scheme involved in the embodiments of this application will be introduced first.

[0023] Specifically, Figure 1 This is a block diagram illustrating a vehicle control scheme according to an embodiment of this application.

[0024] like Figure 1 As shown, the solution involves using in-vehicle networks to obtain vehicle location information to effectively identify and restrict vehicle use, thereby preventing the illegal international sale of vehicles. The main components are: the TSP (Telematics Service Provider) and TBOX (Telematics Box) communicate wirelessly. The TBOX sends periodic message flags (such as 0, 1, 2, etc.) to the VCU (Vehicle Control Unit) and ICM. The VCU provides real-time status feedback and sends the feedback values ​​to the ICM (Combination Instrument Module).

[0025] Figure 2 This is a block diagram illustrating another vehicle control scheme according to an embodiment of this application.

[0026] like Figure 2 As shown, the solution can be: by adding configuration words to the relevant controller TBOX / VCU of international vehicles, a vehicle restriction policy is triggered when an internationally assembled TBOX / VCU is installed on a domestic vehicle, thereby effectively controlling the installation of internationally assembled TBOX / VCUs on domestic vehicles.

[0027] The following description, with reference to the accompanying drawings, describes the control method, apparatus, vehicle, medium, and program product of embodiments of this application. Addressing the limitations of most strategies mentioned in the background art that rely solely on regulatory requirements and manual detection for identification and control, which fail to effectively identify and circumvent the problem of illegal international sales, this application provides a vehicle control method. In this method, in response to the vehicle's power-on signal, a first verification request sent from the cloud and a second verification request sent from the vehicle are received. The method then parses the first encrypted data in the first verification request and the second encrypted data in the second verification request to generate corresponding verification results, thereby determining the vehicle's driving parameters for vehicle control. This dual verification significantly increases the difficulty of malicious attacks or tampering with the system, effectively preventing unauthorized vehicle access or malicious control, ensuring vehicle driving safety, improving the reliability of the vehicle control system, reducing the risk of vehicle loss of control due to system failures, enabling flexible control of vehicle driving parameters, meeting the personalized needs of different users, and improving user experience. Therefore, this solves the problem that most related technologies, which rely solely on regulatory requirements and manual detection for identification and control, fail to effectively identify and circumvent problems such as illegal international sales.

[0028] Specifically, Figure 3 This is a flowchart of a vehicle control method provided according to an embodiment of this application.

[0029] like Figure 3 As shown, the vehicle management method includes cloud-based verification and vehicle-side verification, wherein the method includes the following steps: In step S301, in response to the vehicle's power-on signal, a first verification request sent from the cloud and a second verification request sent from the vehicle are received respectively.

[0030] It is understood that, in the embodiments of this application, the first verification request sent by the cloud can be understood as using the TSP deployed on the cloud server to connect with the vehicle-side TBOX via wireless network, OTA (Over-the-Air) technology, etc., to realize data interaction and remote control, build an intelligent communication bridge between the vehicle and the cloud, and then use the TSP to send the first verification request to the vehicle-side TBOX.

[0031] The verification controllers involved in the second verification request sent by the vehicle include VCU, BMS (Battery Management System), MCU (Microcontroller Unit), etc., and this application does not impose specific restrictions.

[0032] Furthermore, in this embodiment of the application, two-way encrypted verification of the vehicle is achieved based on TSP, TBOX, VCU, BMS, MCU, etc.

[0033] It should be noted that, in the embodiments of this application, the power-on signal can be understood as the vehicle being powered on when the user unlocks the vehicle and switches the vehicle's power setting from off to on.

[0034] As one possible implementation, embodiments of this application can respond to the vehicle's power-on signal and receive a first verification request sent from the cloud and a second verification request sent from the vehicle.

[0035] For example, in this embodiment of the application, when the user unlocks the vehicle and switches the power switch from off to on, the TBOX receives the first verification request sent by the TSP, and the VCU, BMS, MCU, etc. initiate active verification to the TBOX and obtain the second verification request. Thereafter, an active verification is initiated every 30 minutes, and 5 frames are sent during each verification. This application does not impose any specific limitations.

[0036] TBOX utilizes the TCP (Transmission Control Protocol) to achieve reliable data transmission with cloud platforms or external systems. TCP is a connection-oriented, reliable, byte-stream-based transport layer communication protocol in the Internet protocol suite.

[0037] In step S302, the first verification controller is controlled to parse the first ciphertext data in the first verification request to generate a first verification result, and the second verification controller is controlled to parse the second ciphertext data in the second verification request to generate a second verification result.

[0038] It is understood that, in the embodiments of this application, the first encrypted data and the second encrypted data may include, but are not limited to, feature values, random numbers, vehicle restriction status, etc., and this application does not impose specific limitations. Feature values ​​may include vehicle fixed data, controller feature data, etc., and this application does not impose specific limitations; random numbers may be encrypted random numbers, and this application does not impose specific limitations; vehicle restriction status can be understood as the status should carry relevant instruction data, such as vehicle network lost data, vehicle restriction data, what kind of restrictions are applied to the vehicle, etc., and can be specifically set by those skilled in the art according to the actual situation, and this application does not impose specific limitations.

[0039] It should be noted that the first verification controller can be understood as TBOX, and the second verification controller can be understood as VCU, BMS, MCU, etc. This application does not impose any specific restrictions.

[0040] In some embodiments, the present application can control a first verification controller to parse the first ciphertext data in a first verification request, thereby generating a corresponding first verification result.

[0041] For example, in this embodiment of the application, the TBOX receives a first verification request and initiates active verification to the VCU, BMS, MCU, etc. After each verification, it performs a verification every 30 minutes, sending 5 frames each time. After receiving the first encrypted data sent by the TBOX, the VCU, BMS, MCU, etc. parse it and send the parsed first plaintext data back to the TBOX. The feedback data is also sent in 5 frames, thus obtaining the first verification result.

[0042] In some embodiments, the present application can control a second verification controller to parse the second ciphertext data in the second verification request, thereby generating a corresponding second verification result. For example, in response to the vehicle's power-on signal, the VCU immediately controls the TBOX to initiate an active verification. After each verification, a verification is performed every 30 minutes. Five frames are sent during each verification. The TBOX receives the second encrypted data sent by the VCU, parses it, obtains the second verification result, and sends five frames of feedback data.

[0043] Furthermore, if the second verification result is a pass, the VCU's own restriction status data is identified; if the second verification result is a fail, the number of anomalies is incremented by 1 each time, and the corresponding restriction policy is executed: when ① the number of anomalies is ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with the signal level = 0; ② when the number of anomalies is 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with the signal level = 1; IHU (Infotainment Head) After receiving the alarm signal, the infotainment unit (IHU) / ICM will sound a slow beep for 30 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit and will be restricted." ③ When the number of abnormalities is ≥3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the vehicle speed is limited to 20 km / h, and the anti-theft verification alarm signal is triggered, with a signal level of 2. After receiving the alarm signal, the IHU / ICM will sound a fast beep for 100 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit and will be restricted." ④ When the number of abnormalities exceeds 3, it will not be accumulated and will remain at 3. It should be noted that the number of abnormalities is remembered after power-off, and the number of abnormalities is cleared to zero when the verification passes.

[0044] For example, in response to the vehicle's power-on signal, the BMS immediately initiates an active verification to the TBOX. After each verification, a timer is set to perform a verification every 30 minutes. Five frames are sent during each verification. The TBOX receives the second encrypted data sent by the BMS, parses it, obtains the second verification result, and sends five frames of feedback data.

[0045] Furthermore, if the second verification result is a pass, the BMS's own limitation status data is identified; if the second verification result is a fail, the number of anomalies is incremented by 1 each time, and the corresponding limitation strategy is executed: ① When the number of anomalies is ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 0; ② When the number of anomalies is 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 1; after receiving the alarm signal, the IHU / ICM will sound a slow beep for 30 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ③ When the number of anomalies is ≥ 3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the vehicle's output power is limited, and an anti-theft verification alarm signal is triggered, with a signal level of 1. 2; After receiving the signal, the IHU / ICM will beep for 100 seconds and display a pop-up message for 3 seconds: "The vehicle has an untrusted unit and will be restricted"; ④ When the number of verification errors exceeds 3, it will not be accumulated and will remain at 3; It should be noted that the number of errors is remembered after power-off, and the number of errors is cleared to zero when the verification passes.

[0046] For example, in response to the vehicle's power-on signal, the MCU immediately initiates an active verification to the TBOX. After each verification, a timer is set to perform a verification every 30 minutes. Five frames are sent during each verification. The TBOX receives the second encrypted data sent by the MCU, parses it, obtains the second verification result, and sends five frames of feedback data.

[0047] Furthermore, if the second verification result is a pass, the MCU's own limitation status data is identified; if the second verification result is a fail, the number of anomalies is incremented by 1 each time, and the corresponding limitation strategy is executed: ① When the number of anomalies is ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 0; ② When the number of anomalies is 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 1; after receiving the alarm signal, the IHU / ICM will sound a slow beep for 30 seconds and display a 3-second pop-up window: "The vehicle has an untrusted unit, the vehicle will be restricted"; ③ When the number of anomalies is ≥ 3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the vehicle's output power is limited, and an anti-theft verification alarm signal is triggered, with a signal level of 1. 2; After receiving the alarm signal, the IHU / ICM will sound a buzzer for 100 seconds and display a pop-up window for 3 seconds: "The vehicle has an untrusted unit and will be restricted"; ④ When the number of abnormalities exceeds 3, it will not be accumulated and will remain at 3; It should be noted that the number of abnormalities is remembered after power-off, and the number of abnormalities will be cleared to zero when the verification is passed. In summary, when the anti-theft verification level in this application embodiment is equal to 3, the following strategies are implemented: ① VCU limits the vehicle speed to 20 km / h; ② BMS limits the output power; ③ MCU limits the output torque.

[0048] In addition, in this embodiment of the application, the IHU / ICM monitors the anti-theft verification alarm signals of TBOX, VCU, BMS, and MCU, receives any signal value, and responds according to the level of the alarm signal. The higher the level, the faster the response.

[0049] Optionally, in one embodiment of this application, controlling the first verification controller to parse the first encrypted data in the first verification request to generate a first verification result includes: controlling the first verification controller to parse the first encrypted data to generate corresponding first plaintext data; based on the first plaintext data, determining whether the first verification status of the first verification request is a verification passed status; if the first verification status is a verification passed status, generating a first verification result based on the verification passed status; if the first verification status is not a verification passed status, counting the number of abnormalities where the first verification status is not a verification passed status, and generating a corresponding alarm signal and the signal level of the alarm signal based on the number of abnormalities to obtain the first verification result.

[0050] In some embodiments, the present application can generate first plaintext data by parsing first ciphertext data, and then determine whether the first verification state is a verification passed state based on the first ciphertext data and the second plaintext data. If the first verification state is a verification passed state, a first verification result is generated based on the verification passed state.

[0051] For example, in the embodiments of this application, when the first verification state is a verification passed state, the first verification result is determined to be a verification passed state, and the TBOX's own limitation state data is identified.

[0052] In some embodiments, when the first verification state is not a verification passed state, the first verification result can be obtained based on the number of anomalies in the first verification state that are not a verification passed state, the corresponding alarm signal, and the signal level of the alarm signal.

[0053] For example, in the embodiments of this application, if the first verification state is not a verification passed state, the first verification result can be determined as verification failed, and the number of abnormalities can be accumulated by 1 each time, and the corresponding restriction strategy can be executed: when ① the number of abnormalities is ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, and the platform triggers an alarm when connected to the network; at the same time, the anti-theft verification alarm signal is triggered, and the signal level = 0; ② when the number of abnormalities is 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, and the platform triggers an alarm when connected to the network; at the same time, the anti-theft verification alarm signal is triggered, and the signal level = 1, IHU / I After receiving the alarm signal, the CM will sound a slow buzzer for 30 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ③ When the number of abnormalities is ≥3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the network status is confirmed, and the platform triggers an alarm; at the same time, the anti-theft verification alarm signal is triggered, and the signal level = 2. After receiving the alarm signal, the IHU / ICM will sound a fast buzzer for 100 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ④ When the number of abnormalities exceeds 3, it will not be accumulated and will remain at 3; it should be noted that the number of abnormalities is remembered after power-off, and the number of abnormalities is cleared to zero when the verification is passed. Optionally, in one embodiment of this application, determining whether the first verification status of the first verification request is a verification passed status based on the first plaintext data includes: obtaining network data of the first verification controller; and determining whether the first verification status is a verification passed status based on the network data and the first plaintext data.

[0054] It is understood that, in determining whether the first verification state is a verification passed state, the embodiments of this application can obtain the network data of the first verification controller, and then determine whether the first verification state is a verification passed state based on the network data and the first plaintext data.

[0055] For example, in the embodiments of this application, when the network data is not connected to the network, the first verification state is determined to be not a verification passed state; when the first plaintext data does not match the data corresponding to the controller, the first verification state is determined to be not a verification passed state; when the network data is connected to the network and the first plaintext data matches the data corresponding to the controller, the first verification state is determined to be a verification passed state.

[0056] Optionally, in one embodiment of this application, generating a corresponding alarm signal and an alarm signal level based on the number of anomalies includes: detecting the alarm interval where the number of anomalies falls based on the number of anomalies; generating an alarm signal based on the alarm interval; and determining the signal level based on the alarm signal.

[0057] It is understood that the alarm intervals in this application embodiment can be divided into three: the first alarm interval is ≤1, and the signal level is 0; the second alarm interval is 2, and the signal level is 1; the third alarm interval is ≥3, and the signal level is 2. The specific settings can be made by those skilled in the art according to the actual situation, and this application does not impose any specific limitations.

[0058] In actual implementation, the embodiments of this application can generate corresponding alarm signals and determine corresponding signal levels based on the alarm interval where the number of abnormalities falls.

[0059] In step S303, based on the first verification result and the second verification result, at least one driving parameter of the vehicle is determined so as to control the vehicle according to at least one driving parameter.

[0060] In actual implementation, the embodiments of this application can determine the vehicle's driving parameters based on the first verification result and the second verification result, thereby controlling the vehicle.

[0061] Optionally, in one embodiment of this application, determining at least one driving parameter of the vehicle based on the first verification result and the second verification result includes: identifying the verification features of the corresponding verification controller based on the first verification result and the second verification result; and determining at least one driving parameter based on the verification features.

[0062] It is understood that, in the embodiments of this application, the verification features may include, but are not limited to, VCU speed limiting features, BMS output power limiting features, and MCU output torque limiting features. The specific features can be set by those skilled in the art according to the actual situation, and this application does not impose any specific limitations.

[0063] In some embodiments, the present application embodiments can determine the verification characteristics of the first verification controller and the verification characteristics of the second verification controller based on the first verification result and the second verification result, and then determine the driving parameters of the vehicle.

[0064] The following is a flowchart illustrating the working principle of the vehicle control method proposed in this application, using a specific embodiment as an example.

[0065] in, Figure 4 This is a flowchart illustrating the working principle of a vehicle control method according to an embodiment of this application.

[0066] like Figure 4 As shown, the main content of this method is as follows: (1) Verification in the cloud: In this embodiment, when the power switch is changed from off to on, the TBOX receives a first verification request and initiates active verification to the VCU, BMS, and MCU. After each verification, a verification is performed every 30 minutes, and 5 frames are sent during each verification. After receiving the first encrypted data sent by the TBOX, the VCU, BMS, and MCU parse it and send the parsed first plaintext data back to the TBOX, also sending 5 frames for the feedback data. When the anti-theft verification level is 3, the corresponding strategy is executed: ① The VCU limits the vehicle speed to 20 km / h; ② The BMS limits the output power; ③ The MCU limits the output torque.

[0067] Furthermore, in this embodiment, when the first verification result is "verification passed," the corresponding strategy is executed based on the TBOX's own limitation status data; when the first verification result is "verification failed," the number of exceptions is accumulated, incremented by 1 each time, and the corresponding limitation strategy is executed: ① When the number of exceptions ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, and the platform triggers an alarm when connected to the network; simultaneously, an anti-theft verification alarm signal is triggered, and the signal level = 0; ② When the number of exceptions = 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, and the platform triggers an alarm when connected to the network; simultaneously, an anti-theft verification alarm signal is triggered, and the signal level = 1. After receiving the alarm signal, the HU / ICM will sound a slow buzzer for 30 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ③ When the number of abnormalities is ≥3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the network status is confirmed, and the platform triggers an alarm; at the same time, the anti-theft verification alarm signal is triggered, and the signal level = 2. After receiving the alarm signal, the IHU / ICM will sound a fast buzzer for 100 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ④ When the number of abnormalities exceeds 3, it will not be accumulated and will remain at 3; it should be noted that the number of abnormalities is remembered after power-off, and the number of abnormalities is cleared to zero when the verification is passed. (2) Vehicle-side verification: VCU verification In this embodiment of the application, when the power setting is switched from off to on, the VCU initiates an active verification to the TBOX. After each verification, a verification is performed every 30 minutes. Five frames are sent during each verification. The TBOX receives the second encrypted data sent by the VCU, parses it, obtains the second verification result, and sends five frames of feedback data.

[0068] Furthermore, in this embodiment, when the second verification result is a pass, the corresponding strategy is executed based on the VCU's own restriction status data; when the second verification result is a fail, the number of anomalies is accumulated, incremented by 1 each time, and the corresponding restriction strategy is executed: ① When the number of anomalies is ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with the signal level = 0; ② When the number of anomalies is 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with the signal level = 1; IHU / I After receiving the alarm signal, the CM will sound a slow beep for 30 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ③ When the number of abnormalities is ≥3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the vehicle speed is limited to 20 km / h, and the anti-theft verification alarm signal is triggered, with the signal level = 2; After receiving the alarm signal, the IHU / ICM will sound a fast beep for 100 seconds and display a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ④ When the number of abnormalities exceeds 3, it will not be accumulated and will remain at 3; It should be noted that the number of abnormalities is remembered after power-off, and the number of abnormalities is cleared to zero when the verification is passed.

[0069] (3) Vehicle-side verification: BMS verification In this embodiment of the application, when the power setting is switched from off to on, the BMS initiates an active verification to the TBOX. After each verification, a verification is performed every 30 minutes. Five frames are sent during each verification. The TBOX receives the second encrypted data sent by the BMS, parses it, obtains the second verification result, and sends five frames of feedback data.

[0070] Furthermore, in this embodiment, when the second verification result is a successful verification, the corresponding strategy is executed based on the BMS's own restriction status data; when the second verification result is a failed verification, the number of abnormalities is accumulated, incremented by 1 each time, and the corresponding restriction strategy is executed: ① When the number of abnormalities is ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 0; ② When the number of abnormalities is 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, the vehicle is not restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 1; after receiving the alarm signal, the IHU / ICM emits a slow beep for 30 seconds and displays a 3-second pop-up message: "The vehicle has an untrusted unit, and the vehicle will be restricted"; ③ When the number of abnormalities is ≥ 3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the vehicle's output power is restricted, and an anti-theft verification alarm signal is triggered, with a signal level of 1. 2; After receiving the signal, the IHU / ICM will beep for 100 seconds and display a pop-up message for 3 seconds: "The vehicle has an untrusted unit and will be restricted"; ④ When the number of verification errors exceeds 3, it will not be accumulated and will remain at 3; It should be noted that the number of errors is remembered after power-off, and the number of errors is cleared to zero when the verification passes.

[0071] (4) Vehicle-side verification: MCU verification In this embodiment of the application, when the power level is switched from off to on, the MCU initiates an active verification to the TBOX. After each verification, a verification is performed every 30 minutes. Five frames are sent during each verification. The TBOX receives the second encrypted data sent by the MCU, parses it, obtains the second verification result, and sends five frames of feedback data.

[0072] Furthermore, in this embodiment, when the second verification result is a successful verification, the corresponding strategy is executed based on the MCU's own limitation status data; when the second verification result is not a successful verification, the number of abnormalities is accumulated, incremented by 1 each time, and the corresponding limitation strategy is executed: ① When the number of abnormalities ≤ 1, the anti-theft verification level = 1, the anti-theft verification command data is updated, the vehicle is not restricted; and an anti-theft verification alarm signal is triggered, with a signal level = 0; ② When the number of abnormalities = 2, the anti-theft verification level = 2, the anti-theft verification command data is updated, the vehicle is not restricted; and an anti-theft verification alarm signal is triggered, with a signal level = 1; after receiving the alarm signal, the IHU / ICM will sound a slow beep for 30 seconds and display a 3-second pop-up window: "The vehicle has an untrusted unit, the vehicle will be restricted"; ③ When the number of abnormalities ≥ 3, the anti-theft verification level = 3, the anti-theft verification command data is updated, the vehicle's output power is limited; and an anti-theft verification alarm signal is triggered, with a signal level = 2; After receiving the alarm signal, the IHU / ICM will sound a buzzer for 100 seconds and display a pop-up window for 3 seconds: "The vehicle has an untrusted unit and will be restricted"; ④ When the number of abnormalities exceeds 3, it will not be accumulated and will remain at 3; It should be noted that the number of abnormalities is remembered after power-off, and the number of abnormalities will be cleared to zero when the verification is passed.

[0073] Furthermore, in this embodiment, the IHU / ICM monitors the anti-theft verification alarm signals of the TBOX, VCU, BMS, and MCU, receives any signal value, and responds according to the alarm signal level; the higher the level, the faster the response.

[0074] The vehicle management method proposed in this application can respond to the vehicle's power-on signal and receive a first verification request sent from the cloud and a second verification request sent from the vehicle. It then parses the first encrypted data in the first verification request and the second encrypted data in the second verification request to generate corresponding verification results, thereby determining the vehicle's driving parameters for vehicle management. This dual verification significantly increases the difficulty of malicious attacks or tampering with the system, effectively preventing unauthorized vehicle access or malicious control, ensuring vehicle driving safety, improving the reliability of the vehicle management system, reducing the risk of vehicle loss of control due to system failures, and enabling flexible control of vehicle driving parameters to meet the personalized needs of different users and improve user experience. This solves the problem that most related technologies rely solely on regulatory requirements and manual detection for identification and control, failing to effectively identify and circumvent issues such as illegal international sales.

[0075] Next, the vehicle control device proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0076] Figure 5 This is a block diagram of a vehicle control device provided according to an embodiment of this application.

[0077] like Figure 5 As shown, the vehicle control device 10 includes cloud-based verification and vehicle-side verification. The vehicle control device 10 includes a receiving module 100, a parsing module 200, and a determining module 300.

[0078] The receiving module 100 is used to receive the first verification request sent by the cloud and the second verification request sent by the vehicle in response to the vehicle's power-on signal.

[0079] The parsing module 200 is used to control the first verification controller to parse the first ciphertext data in the first verification request to generate the first verification result, and to control the second verification controller to parse the second ciphertext data in the second verification request to generate the second verification result.

[0080] The determination module 300 is used to determine at least one driving parameter of the vehicle based on the first verification result and the second verification result, so as to control the vehicle according to the at least one driving parameter.

[0081] Optionally, in one embodiment of this application, the parsing module 200 includes: a parsing unit, a judgment unit, a first generation unit, and a second generation unit.

[0082] The parsing unit is used to control the first verification controller to parse the first ciphertext data in order to generate the corresponding first plaintext data.

[0083] The judgment unit is used to determine, based on the first plaintext data, whether the first verification status of the first verification request is a verification passed status.

[0084] The first generation unit is used to generate a first verification result based on the verification pass status when the first verification status is the verification pass status.

[0085] The second generation unit is used to count the number of times the first verification state is not the verification passed state when the first verification state is not the verification passed state, and generate a corresponding alarm signal and the signal level of the alarm signal according to the number of abnormalities, so as to obtain the first verification result.

[0086] Optionally, in one embodiment of this application, the determination unit includes: an acquisition subunit and a determination subunit.

[0087] The acquisition subunit is used to acquire network data from the first verification controller.

[0088] The judgment subunit is used to determine whether the first verification state is a verification passed state based on network data and the first plaintext data.

[0089] Optionally, in one embodiment of this application, the second generation unit includes: a detection subunit, a generation subunit, and a determination subunit.

[0090] The detection subunit is used to detect the alarm range where the number of abnormalities falls, based on the number of abnormalities.

[0091] The generation sub-unit is used to generate alarm signals based on alarm intervals.

[0092] The determination subunit is used to determine the signal level based on the alarm signal.

[0093] Optionally, in one embodiment of this application, the determining module 300 includes: an identification unit and a determining unit.

[0094] The identification unit is used to identify the verification features of the corresponding verification controller based on the first verification result and the second verification result.

[0095] A determination unit is used to determine at least one driving parameter based on verification features.

[0096] It should be noted that the explanation of the above-mentioned vehicle control method embodiment also applies to the vehicle control device of this embodiment, and will not be repeated here.

[0097] The vehicle control device proposed in this application embodiment can respond to the vehicle's power-on signal and receive a first verification request sent from the cloud and a second verification request sent from the vehicle. It then parses the first encrypted data in the first verification request and the second encrypted data in the second verification request to generate corresponding verification results, thereby determining the vehicle's driving parameters for vehicle control. This dual verification significantly increases the difficulty of malicious attacks or tampering with the system, effectively preventing unauthorized vehicle access or malicious control, ensuring vehicle driving safety, improving the reliability of the vehicle control system, reducing the risk of vehicle loss of control due to system failures, and enabling flexible control of vehicle driving parameters to meet the personalized needs of different users and improve user experience. Therefore, it solves the problem that most related technologies rely solely on regulatory requirements and manual detection for identification and control, failing to effectively identify and circumvent issues such as illegal international sales.

[0098] Figure 6 This is a schematic diagram of the structure of a vehicle according to an embodiment of this application. The vehicle may include: The memory 601, the processor 602, and the computer program stored on the memory 601 and capable of running on the processor 602.

[0099] When the processor 602 executes the program, it implements the vehicle control method provided in the above embodiments.

[0100] Furthermore, the vehicle also includes: Communication interface 603 is used for communication between memory 601 and processor 602.

[0101] The memory 601 is used to store computer programs that can run on the processor 602.

[0102] The memory 601 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0103] If the memory 601, processor 602, and communication interface 603 are implemented independently, then the communication interface 603, memory 601, and processor 602 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, 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 representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0104] Optionally, in a specific implementation, if the memory 601, processor 602, and communication interface 603 are integrated on a single chip, then the memory 601, processor 602, and communication interface 603 can communicate with each other through an internal interface.

[0105] The processor 602 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0106] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the vehicle control method described above.

[0107] This application also provides a computer program product, including a computer program that, when executed, implements the vehicle control method described above.

[0108] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0109] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0110] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0111] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). In addition, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically by optically scanning paper or other media, then editing, interpreting or otherwise processing them as necessary, and then storing them in computer memory.

[0112] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0113] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0114] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0115] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for controlling vehicles, characterized in that, This includes verification at the cloud and verification at the vehicle end, wherein the method includes the following steps: In response to the vehicle's power-on signal, the system receives a first verification request sent from the cloud and a second verification request sent from the vehicle terminal. The first verification controller is controlled to parse the first ciphertext data in the first verification request to generate a first verification result, and the second verification controller is controlled to parse the second ciphertext data in the second verification request to generate a second verification result. When parsing the first ciphertext data, if the corresponding first verification state is not a verification pass state, the number of abnormalities is counted, and a corresponding alarm signal is generated according to the alarm interval to which the number of abnormalities belongs, and the signal level of the alarm signal is determined. Based on the first verification result, the second verification result, the number of anomalies, the alarm signal, and the signal level, at least one driving parameter of the vehicle is determined, so as to control the vehicle according to the at least one driving parameter.

2. The method according to claim 1, characterized in that, The process of controlling the first verification controller to parse the first ciphertext data in the first verification request to generate a first verification result includes: The first verification controller is controlled to parse the first ciphertext data to generate the corresponding first plaintext data; Based on the first plaintext data, determine whether the first verification status of the first verification request is a verification passed status; If the first verification status is the verification passed status, then the first verification result is generated based on the verification passed status; If the first verification status is not the verification passed status, then the number of times the first verification status is not the verification passed status is counted, and a corresponding alarm signal and the signal level of the alarm signal are generated according to the number of abnormalities to obtain the first verification result.

3. The method according to claim 2, characterized in that, The step of determining whether the first verification status of the first verification request is a verification passed status based on the first plaintext data includes: Obtain the network data of the first verification controller; Based on the network data and the first plaintext data, determine whether the first verification status is the verification passed status.

4. The method according to claim 2, characterized in that, The step of generating a corresponding alarm signal and the signal level of the alarm signal based on the number of anomalies includes: Based on the number of anomalies, detect the alarm interval in which the number of anomalies falls; The alarm signal is generated based on the alarm range; Based on the alarm signal, the signal level is determined.

5. The method according to claim 1, characterized in that, Determining at least one driving parameter of the vehicle based on the first verification result and the second verification result includes: Based on the first verification result and the second verification result, the verification characteristics of the corresponding verification controller are identified; Based on the verification features, the at least one driving parameter is determined.

6. A vehicle control device, characterized in that, The device includes both cloud-based verification and vehicle-side verification, wherein the device comprises: The receiving module is used to receive the first verification request sent by the cloud and the second verification request sent by the vehicle in response to the vehicle's power-on signal. The parsing module is used to control the first verification controller to parse the first ciphertext data in the first verification request to generate a first verification result, and to control the second verification controller to parse the second ciphertext data in the second verification request to generate a second verification result. When parsing the first ciphertext data, if the corresponding first verification status is not a verification pass status, the number of abnormalities is counted, and a corresponding alarm signal is generated according to the alarm interval to which the number of abnormalities belongs, and the signal level of the alarm signal is determined. The determination module is used to determine at least one driving parameter of the vehicle based on the first verification result, the second verification result, the number of anomalies, the alarm signal, and the signal level, so as to control the vehicle according to the at least one driving parameter.

7. The apparatus according to claim 6, characterized in that, The parsing module includes: The parsing unit is used to control the first verification controller to parse the first ciphertext data to generate the corresponding first plaintext data; The judgment unit is used to determine, based on the first plaintext data, whether the first verification status of the first verification request is a verification passed status; The first generation unit is configured to generate the first verification result based on the verification pass status when the first verification status is the verification pass status. The second generation unit is used to count the number of times the first verification state is not the verification passed state when the first verification state is not the verification passed state, and generate a corresponding alarm signal and the signal level of the alarm signal according to the number of abnormalities, so as to obtain the first verification result.

8. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the vehicle control method as described in any one of claims 1-5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the vehicle control method as described in any one of claims 1-5.

10. A computer program product, characterized in that, Includes a computer program, which, when executed, is used to implement the vehicle control method as described in any one of claims 1-5.

Images