Vehicle remote control state prepositive judgment method based on power-on OTA upgrade

Abstract

The invention belongs to the technical field of vehicle electronic control, and particularly relates to a vehicle remote control state prepositive judgment method based on power-on OTA upgrade, which specifically comprises the following steps that: TBOX analyzes a specific CAN (Controller Area Network) message sent by a BCM (Body Control Module) to comprehensively judge two state identifications, namely a remote control mode and a safety certification success; based on the judgment, a set of complete logic control strategy is designed in a plurality of links such as OTA upgrading task triggering, executing and appointment awakening, so that upgrading is forbidden to be started in the remote control state or remote control instructions are shielded in the upgrading process, function conflicts are avoided, system stability is guaranteed, and the service life of the system is prolonged. And user experience is improved. According to the invention, the judgment and control logic is integrated in the TBOX, so that the participation of other controllers is reduced, and the system complexity and development cost are reduced.

Description

Technical Field

[0001] This invention relates to the field of vehicle electronic control technology, and in particular to a method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade. Background Technology

[0002] With the rapid development of intelligent and connected commercial vehicles, remote OTA software upgrades and remote control functions via mobile applications (such as remote door lock control, window operation, air conditioning start / stop, and vehicle location) have become mainstream features for OEMs to enhance product competitiveness. However, under the specific electrical architecture of traditional fuel-powered commercial vehicles, the realization of these two advanced functions faces a common prerequisite: the vehicle's electrical system needs to be powered on (e.g., switched to the ON position) to wake up and drive the relevant electronic control units.

[0003] Currently, mainstream passenger vehicles and high-end intelligent commercial vehicles often use a smart central control screen as the core node of the vehicle's intelligent domain, coordinating various functions. However, for traditional fuel-powered commercial vehicles that are cost-sensitive and have relatively simple electrical architectures, a more common solution is to use an onboard remote communication terminal as the main control unit to realize remote interaction functions. In this type of architecture, whether it is the execution of remote control commands via an APP or the downloading and flashing of OTA upgrade packages, it is often necessary to coordinate the body controller or other related controllers through a TBOX to control the ON position of the vehicle's power supply to meet the controller's operating voltage requirements.

[0004] This shared need for power-on functionality leads to potential conflicts in functional scenarios. For example, when a user is remotely turning on the air conditioning to pre-cool / pre-heat the vehicle using an app (the vehicle is powered on), the OTA system may attempt to initiate an upgrade due to the scheduled time or manual triggering by the user. Conversely, during an OTA upgrade (the vehicle is in a specific power-on upgrade mode), the user may intend to send remote control commands. Without effective state management and conflict arbitration mechanisms, the parallel or overlapping execution of these two functions may result in: 1) The vehicle is in an abnormal state, such as being interrupted by remote control commands during the upgrade process, which may cause the software to fail to flash or even brick the controller. 2) Function execution fails, resulting in a poor user experience; 3) The system logic is chaotic, which increases the difficulty of fault diagnosis.

[0005] In existing technologies, OTA upgrades typically set some basic pre-verification conditions, such as vehicle speed being zero, engine being off, gear being in parking gear (P), and handbrake being engaged. This information can be obtained through the vehicle's CAN network. However, existing OTA management platforms usually lack effective monitoring and judgment methods for the dynamic and high-level functional state of "whether the vehicle is under remote control via the APP". Therefore, there is an urgent need for a method that can accurately determine the remote control status of the vehicle in the early stages of the OTA upgrade process and design reasonable arbitration logic accordingly to resolve the above-mentioned functional conflict problem and ensure the stable and reliable operation of the system. Summary of the Invention

[0006] The primary objective of this invention is to overcome the shortcomings of existing technologies and provide a pre-judgment method for vehicle remote control status based on power-on OTA upgrades. This aims to resolve the execution conflict that may arise in traditional fuel-powered commercial vehicles when both remote control and OTA upgrade functions require the vehicle to be powered on. This invention accurately identifies the vehicle's remote control status and uses it as a mandatory precondition for OTA upgrades. A series of logical control strategies are designed to effectively avoid functional conflicts and ensure the stable and orderly execution of both functions.

[0007] Another objective of this invention is to simplify the system architecture and reduce reliance on other controllers (such as the central control screen, gateway, etc.) by centralizing the core logic of state judgment and conflict arbitration in the vehicle TBOX, thereby reducing the complexity of the vehicle's electrical system and the cost of software development and testing.

[0008] To achieve the above objectives, this invention provides a pre-judgment method for the remote control status of a vehicle based on over-the-air (OTA) upgrades. This method is applied to a vehicle's electronic and electrical architecture, which includes a TBOX, BCM, and an OTA master control module. The OTA master control module can be a software function module integrated within the TBOX or a separate ECU. The core of this method lies in the TBOX actively monitoring and determining the vehicle's remote control status, and providing this status information to the OTA upgrade process as a key decision-making basis.

[0009] The specific technical solution includes the following steps: Step 1: Establish a remote control status determination system.

[0010] When a vehicle executes a remote control function initiated by an app, the command flow is typically: User App → Telematics Service Platform (TSP) → TBOX → Vehicle Internal Network (e.g., CAN) → BCM / Actuator. In this invention, when the BCM successfully responds to the remote control command and begins to execute the corresponding action (e.g., controlling the door locks), it broadcasts two key status flags to the bus via a preset CAN message: 1) Remote control mode status indicator (indicating that the vehicle has entered a mode controlled by remote commands); 2) Security authentication success status indicator (indicating that the remote command has passed the vehicle's legality and security verification).

[0011] TBOX continuously listens for and parses these specific messages to obtain these two status indicators in real time.

[0012] Step 2: Define the comprehensive judgment logic for remote control status.

[0013] The TBOX internally maintains a status judgment logic unit. This logic stipulates that the vehicle is currently "in a valid remote control operating state" only when both a valid "remote control mode state" and a "safety authentication success state" are simultaneously captured from the CAN bus. In any other case, such as when only one state is detected, or when neither state is detected, the vehicle is determined to be "not in a valid remote control operating state." This "AND" logic judgment method improves the accuracy of status judgment and its anti-interference capability.

[0014] Step 3: Query the pre-upgrade status before OTA upgrade is triggered.

[0015] Regardless of whether the OTA upgrade task is triggered manually by the user, automatically detected by the system, or triggered at the scheduled time, before officially starting the upgrade process (especially controlling the vehicle to power on and enter upgrade mode), the OTA master control module must first send a status query request to the TBOX. After receiving the request, the TBOX immediately calculates the current remote control status determination result of the vehicle according to the logic in step two and feeds it back to the OTA master control module.

[0016] Step 4: Logical control and arbitration based on the results of the prior judgment.

[0017] The OTA master control module executes different control strategies based on the received status determination results: Conflict Handling (Upgrade Prohibition): If the determination result is "the vehicle is in a valid remote control operating state," the OTA main control module immediately prohibits the start or suspends the current upgrade task. Simultaneously, it provides the user with a clear status conflict warning through the human-machine interface (such as the dashboard or mobile app), for example, "The vehicle is under remote control and upgrade cannot be performed." Crucially, in this situation, the system will not force a power-off operation on the vehicle to perform an OTA upgrade, thus ensuring that ongoing remote control functions (such as remote air conditioning) can continue to operate without interference until the user actively terminates the process or the function is scheduled to end.

[0018] Upgrade Allowed: If the determination result is "the vehicle is not in a valid remote control operating state", the OTA main control module allows the subsequent upgrade process to continue. At this time, the system can safely control the vehicle to power on (if necessary) and enter the standard OTA process such as software download, verification, and flashing.

[0019] Furthermore, this invention refines the processing logic for several typical concurrent scenarios: Scenario A: OTA is triggered during the power-down process after remote control ends.

[0020] When the APP remote control function (such as car location, window lift) is completed and the vehicle enters the "passive power-down" timing process controlled by TBOX or BCM (i.e., automatically powering down after a period of time), if the user triggers an OTA upgrade at this time, the system will still perform a preliminary status query. If the remote control status indicator has not disappeared during the query (i.e., still within the "passive power-down" waiting period), the OTA upgrade will be prohibited; if the remote control status has been confirmed to have exited during the query, the OTA upgrade will be allowed to start immediately. At this time, the system will interrupt the original passive power-down process and switch to the "active power-on" process led by the OTA system to execute the upgrade task.

[0021] Scenario B: OTA scheduled upgrade time overlaps with remote control operation.

[0022] When the preset OTA upgrade appointment time arrives, the system will not unconditionally execute the upgrade. The TBOX or OTA main control module will first determine whether the vehicle is in remote control operation mode. If so, the scheduled upgrade task will be automatically skipped or delayed (logged and the user notified), the vehicle will maintain its current state, and the remote control function will not be affected. The scheduled upgrade will be attempted again when the next condition is met (e.g., not in remote control mode and reaching a new checkpoint).

[0023] Scenario C: Receive remote control command during OTA upgrade.

[0024] Once the vehicle has successfully entered the OTA upgrade activity state controlled collaboratively by the TBOX and the OTA main control module (e.g., during ECU flashing), the system enters "upgrade mode." In this mode, any newly received remote control commands from the APP will be directly blocked at the TBOX's protocol parsing layer. The TBOX will not forward these commands to the in-vehicle network, but will immediately reply to the user's APP with a remote control failure notification through the TSP platform. This "remote control blocking" state will continue until the entire OTA upgrade activity is completely completed and the vehicle performs the standard power-down procedure after the upgrade, and the system returns to normal operating mode.

[0025] Compared with the prior art, the present invention provides a method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade, which has the following beneficial effects: 1. By increasing the perception and judgment of the key operating condition of remote vehicle control status and making it a mandatory prerequisite for OTA upgrades, the risk of system conflicts, functional failures or hardware damage that may occur due to the competition between remote control and OTA upgrades for vehicle power-on control is fundamentally avoided, greatly improving the stability and reliability of the system.

[0026] 2. The designed arbitration logic always adheres to the principle of "prioritizing the execution of functions with clear user intent." In the event of a conflict, it prioritizes the complete execution of ongoing remote control functions and provides users with clear prompts, avoiding confusion and complaints caused by sudden interruptions or failures of functions, and enhancing users' trust and satisfaction with the brand's intelligent functions.

[0027] 3. This invention highly integrates the core status judgment and arbitration logic within the TBOX, fully leveraging the TBOX's role as a hub for remote communication and information exchange between the vehicle and the external environment. This reduces reliance on the central control screen, gateways, or other domain controllers for logical coordination, simplifying the complexity of the vehicle's network topology and software interaction. From a development perspective, it reduces the difficulty and workload of defining interfaces and jointly debugging between controllers; from a testing perspective, it reduces the number of test cases in multi-controller collaborative scenarios; and from a material cost perspective, it may reduce excessively high performance requirements for other controllers, thus contributing to overall cost control.

[0028] 4. The method proposed in this invention is based on a clear state machine and event-driven logic, and does not depend on specific hardware models or network bandwidth. This logic can be easily ported to different fuel commercial vehicle platforms, and can even be used in hybrid or new energy commercial vehicles with similar architecture after adaptation. As the functions of vehicles increase in the future, this state arbitration framework can be extended to include more functions that require mutually exclusive access to vehicle power resources (such as remote diagnostics, data acquisition, etc.), which has good foresight. Attached Figure Description

[0029] Figure 1 Basic logic flowchart for remotely controlling and powering on a vehicle; Figure 2 A flowchart illustrating the basic logic for powering on-OTA vehicle upgrades. Figure 3 This is a flowchart illustrating the remote control status judgment and arbitration logic during the OTA upgrade process described in this invention. Detailed Implementation

[0030] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0031] In the description of this invention, it should be understood that the terms "upper", "lower", "front", "rear", "left", "right", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0032] Example 1 describes the application of the present invention in a typical conventional fuel-powered tractor unit. This vehicle is equipped with a TBOX (as a remote communication and master control node), a BCM (responsible for low-voltage electrical control of the vehicle body), and an independent OTA master control module (integrated in the in-vehicle infotainment system, but closely communicating with the TBOX via the CAN bus). The vehicle supports remote air conditioning control, door unlocking, and other functions via a mobile APP, and supports FOTA (Firmware Over-the-Air) upgrades for all vehicle ECUs.

[0033] S101: Generation and capture of remote control status indicators.

[0034] When a user sends a "remotely turn on the air conditioner" command via a mobile app, the command is encrypted and sent to the vehicle manufacturer's TSP platform via the mobile network. The TSP platform verifies the user's identity and the command's legitimacy in the cloud, and then, according to the extended command format of the JT / T 808 Road Transport Vehicle Satellite Positioning System Terminal Communication Protocol (hereinafter referred to as the 808 protocol), sends the command to the vehicle's TBOX. The TBOX decrypts and verifies the command, converts it into a dedicated control message on the vehicle's internal CAN bus, and sends it to the BCM. Upon receiving the valid message, the BCM first controls the relevant relays to bring the network to the ON position (to wake up the air conditioner controller, etc.), and then executes the air conditioner start-up sequence. Simultaneously, the BCM continuously broadcasts two status messages on the CAN bus: Message ID 0x321, bit 0 of data byte 1 indicates "remote control mode activated (1-activated, 0-inactive)"; Message ID 0x322, bit 0 of data byte 1 indicates "remote command security authentication successful (1-success, 0-failure)". TBOX's internal software modules continuously monitor messages with IDs 0x321 and 0x322 and update two internal status variables in real time: RemoteCtrl_Mode and Security_Auth_OK.

[0035] S102: Comprehensive determination of remote control status.

[0036] TBOX internally runs a state management task, which executes decision logic every 100ms. IF (RemoteCtrl_Mode == 1 AND Security_Auth_OK == 1) THEN Vehicle_Remote_Status = ACTIVE; / / The vehicle is in active remote control mode. ELSE Vehicle_Remote_Status = INACTIVE; / / The vehicle is not in a valid remote control state. END IF The determination result, Vehicle_Remote_Status, is stored in the non-volatile memory of TBOX and can be queried through specific diagnostic services or application layer interfaces.

[0037] S103: OTA upgrade triggering and pre-querying.

[0038] Suppose that when a user clicks the "Upgrade Now" button on the vehicle's infotainment screen while the vehicle is parked with the engine off, the OTA main control module inside the vehicle receives the trigger signal but does not act immediately. Instead, it first sends a "UDS (Unified Diagnostic Service) style" query request to the TBOX via the CAN bus. For example, it uses service 0x22 (read data by identifier) ​​to read a custom identifier F100, which is mapped to the Vehicle_Remote_Status variable inside the TBOX.

[0039] S104: Logical Arbitration and User Feedback.

[0040] Upon receiving the 0x22 F100 request, the TBOX immediately encapsulates the current Vehicle_Remote_Status value (e.g., ACTIVE) in a positive response message 0x62 F100 [Value] and returns it to the OTA master module. The OTA master module parses the status as ACTIVE and then executes the conflict resolution logic: 1. Cancel all subsequent operations after this "Upgrade Now" (such as powering on, downloading and verifying, etc.).

[0041] 2. A prompt box will pop up on the vehicle's infotainment screen: "Upgrade failed: Remote control of the vehicle was detected. Please end the remote control and try again. (Error code: E_OTA_1001)".

[0042] 3. No power-down command is sent to any controller, and the vehicle continues to maintain the current power-on state maintained by the remote air conditioning being turned on.

[0043] At this time, the user's remote air conditioning function remains completely unaffected and continues to operate. The user can view the air conditioning's operating status normally on the mobile app. When the user turns off the air conditioning via the app or after the air conditioning has reached the preset operating time, the app will send a "End Remote Control" command. After the BCM completes its execution and controls the vehicle to power off, it will stop broadcasting the activation status bits in messages 0x321 and 0x322. The TBOX detects the status change and updates Vehicle_Remote_Status to INACTIVE.

[0044] Example 2: This example provides a solution for a scenario where scheduled upgrades and remote control overlap. The user sets the OTA upgrade appointment time to 12:00 noon the next day via the vehicle's infotainment system the night before. At 11:50 the next day, the user remotely starts the driver's cabin heating function via the APP (vehicle power-on). At 12:00, the timer inside the TBOX triggers the scheduled upgrade event.

[0045] S201: Status check when the appointment time arrives.

[0046] When the OTA reservation service module in TBOX is woken up, its first action is not to perform an upgrade, but to call the internal status management interface to obtain the current Vehicle_Remote_Status. Since the heating function is running, the BCM is still broadcasting remote control status messages, so TBOX determines the status to be ACTIVE.

[0047] S202: Upgrade delay and status maintenance.

[0048] According to the pre-defined logic, the TBOX's OTA module determines that the upgrade conditions are not currently met. It marks the scheduled upgrade task as "delayed due to conflict" and records this event in the internal log. Simultaneously, the TBOX does not initiate any operations that might affect the current vehicle status, allowing the heating function to continue operating. The TBOX can be configured with a retry mechanism, such as checking Vehicle_Remote_Status again after 10 minutes. If it becomes INACTIVE and other conditions (such as network signal) are met, the upgrade will be automatically initiated; or the user can be notified the next time the vehicle's infotainment system wakes up that "the scheduled upgrade was not executed due to unforeseen circumstances; please trigger it manually."

[0049] Example 3: This example illustrates the shielding of remote control commands during the OTA upgrade process. The vehicle is currently performing an ECU joint upgrade task that is expected to take 25 minutes and has entered the flashing stage.

[0050] S301: Enter "Upgrade Mode" and set the command filter.

[0051] At the start of the upgrade process, the OTA master control module (or in collaboration with TBOX) will broadcast a "system upgrade in progress" status message to the vehicle. After confirming that it has entered the upgrade mode, TBOX will activate its internal "command filter", which works at the 808 protocol stack application layer of TBOX.

[0052] S302: Block and reject external remote control commands.

[0053] At this point, if a user attempts to remotely unlock the vehicle via the app, the app command reaches the TSP and is sent to the TBOX. The TBOX's protocol parsing layer receives the command normally, but before passing it to the application layer's business processing module, it first undergoes a check by a "command filter." The filter detects that the current system mode is "upgrading," so it directly intercepts the unlock command without performing any in-vehicle network forwarding or executing normal business logic. Simultaneously, the TBOX constructs an 808 protocol command response message containing a "failure" result code (such as 0x01) and returns it to the user's app through the TSP platform. The app displays "Remote unlock failed."

[0054] S303: Restore.

[0055] Only after the entire OTA upgrade process is completed, the OTA main control module broadcasts a "system upgrade complete" message, and controls the vehicle to perform a standard power-down-power-on reset process, does the TBOX remove the "command filter" and restore normal command processing capabilities.

[0056] As can be seen from the above embodiments, the present invention effectively solves the functional conflict between vehicle remote control and OTA upgrade under a specific architecture through a rigorous state perception, judgment and logic arbitration mechanism. The solution is specific, feasible and has good engineering practical value.

[0057] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for pre-judging the remote control status of a vehicle based on over-the-air (OTA) upgrade, characterized in that, The method is applied to vehicles including an in-vehicle communication terminal TBOX, a body control module (BCM), and an over-the-air (OTA) master control module, and includes the following steps: S1: Establish the criteria for determining the remote control status of the vehicle; the TBOX monitors and parses the CAN bus messages from the BCM in real time to obtain the remote control status identifier; the status identifier includes at least the remote control mode status and the security authentication success status; S2: Make a comprehensive judgment based on the status identifier; only when the remote control mode status and the security authentication success status are confirmed to be valid at the same time, the TBOX determines that the vehicle is currently in a valid remote control operation state; otherwise, it determines that the vehicle is not in a valid remote control operation state. S3: Before the OTA upgrade task is triggered, a preliminary status judgment is performed; before starting the upgrade process, the OTA main control module sends a query request to the TBOX to obtain the current vehicle remote control status judgment result obtained from step S2. S4: Execute logic control based on the result of the prior judgment; if the judgment result indicates that the vehicle is in a valid remote control operating state, the OTA main control module prohibits the start or suspension of the current OTA upgrade task and provides feedback to the user with a status conflict prompt; if the judgment result indicates that the vehicle is not in a valid remote control operating state, the OTA upgrade process is allowed to continue.

2. The method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade as described in claim 1, characterized in that, In step S4, when OTA upgrades are disabled because the vehicle is in a remote control state, the method further includes: The OTA main control module or TBOX does not perform an active power-off operation on the vehicle to ensure that the currently ongoing remote control function can continue to run until it ends normally.

3. The method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade as described in claim 1, characterized in that, The method also includes processing logic for OTA-triggered scenarios during the period after the remote control function ends and the vehicle is powered off: When the remote control function is completed and the vehicle enters the passive power-down process controlled by the TBOX or BCM, if an OTA upgrade trigger command is received, steps S3 and S4 are executed. If it is determined that the remote control status has been exited, the OTA upgrade task is allowed to be executed immediately, and the upgrade power-on process led by the OTA system is switched.

4. The method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade as described in claim 1, characterized in that, The method also includes logic for handling conflicts between OTA appointment upgrade scenarios and remote control functions: When the preset OTA scheduled upgrade time arrives, the TBOX or OTA main control module first executes step S2 to determine whether the vehicle is in remote control operation mode at this time. If the vehicle is in remote control mode, scheduled OTA upgrades will be prohibited, and the vehicle's current power status will be maintained until the remote control function is terminated by the user or the timeout period expires.

5. The method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade as described in claim 1, characterized in that, The method also includes processing logic for scenarios where remote control commands are received during OTA upgrades: Once the vehicle has entered the OTA upgrade activity state triggered by the TBOX and OTA main control module, if a remote control command is received from the mobile terminal APP, the TBOX will block the remote control command and directly send a message to the mobile terminal APP that the remote control execution failed. The remote control function will remain disabled until the current OTA upgrade activity is completed and the vehicle completes the upgrade and power-off process.

6. The method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade as described in claim 1, characterized in that, The remote control mode status and the successful security authentication status are broadcast by the BCM via a preset CAN message after successfully responding to a legitimate remote control command forwarded by the TBOX from the cloud server (TSP).

7. The method for pre-judging the remote control status of a vehicle based on power-on OTA upgrade as described in claim 1, characterized in that, The OTA main control module is integrated into the TBOX, or it can function as an independent vehicle controller and communicate with the TBOX via the vehicle network.

Images