CAN-FD issuing method and system during vehicle reservation charging

Abstract

The invention provides a CAN-FD issuing method and system during reservation charging of a vehicle, relates to the technical field of vehicle-mounted electronics and Internet of Vehicles of new energy vehicles, and solves the technical problems of timing distortion and inaccurate triggering of a reservation charging start-stop instruction caused by dependence on external sleep duration or a specific hardware module during SOC awakening in the prior art. The method comprises the following steps: acquiring system UTC standard time after SOC awakening and converting the system UTC standard time into minutes of the day; performing time zone correction according to a target area where the vehicle is located to obtain a local time minute number; acquiring preset charging parameters including the starting time minute number after the charging starting time is converted, the charging duration minute number and the calculation of the charging ending time minute number; based on the local time minute number, the starting time minute number and the ending time minute number, whether the current time is in the reserved charging period is judged; and issuing a corresponding control instruction through the vehicle-mounted controller in combination with the current charging state. The method and device are used in the vehicle reservation charging process.

Description

Technical Field

[0001] This application relates to the field of new energy vehicle in-vehicle electronics and vehicle networking technology, and in particular to a CAN-FD transmission method and system for vehicle scheduled charging. Background Technology

[0002] In the field of new energy vehicle pre-charge technology, pre-charge functionality has become a core feature for improving user experience and optimizing grid load. It relies on the T-BOX as the communication hub between the vehicle, cloud, and user, linking multiple modules such as IVI, VCU, and BMS to achieve pre-charge parameter settings, charging command issuance, and status feedback. However, in existing technologies, in SMS wake-up scenarios, the sleep duration cannot be obtained after wake-up, making it impossible to calculate the sleep start time. In RTC wake-up scenarios, the timing function is heavily dependent on the RTC; if the RTC experiences data anomalies, it directly leads to timing distortion, further resulting in inaccurate triggering of pre-charge start / stop commands. This affects users' precise control over charging during off-peak electricity pricing periods and may also cause energy waste or invalid actions of onboard hardware modules due to mis-triggered commands, limiting the stability and reliability of the pre-charge function and failing to fully meet the core requirements for functional continuity and accuracy in onboard scenarios. Therefore, how to enable the SOC to achieve accurate timing and reliable triggering of pre-charge start / stop commands in various wake-up scenarios has become an urgent technical problem to be solved. Summary of the Invention

[0003] This application provides a CAN-FD sending method and system for vehicle scheduled charging, which solves the technical problems of timing distortion and inaccurate triggering of scheduled charging start and stop commands caused by external sleep duration or specific hardware modules during SOC wake-up in the prior art.

[0004] To achieve the above objectives, this application adopts the following technical solution: Firstly, a CAN-FD transmission method is provided for vehicle scheduled charging, including: S1, obtaining the system UTC standard time after the vehicle's SOC wake-up, and converting the standard time into the number of minutes of the day; S2, adjust the time zone of the minutes of the day according to the offset of the target area where the vehicle is located, and get the local time minutes; S3, obtain preset charging parameters, including the start time in minutes after the charging start time is converted and the charging duration in minutes. The charging end time in minutes is calculated based on the start time in minutes and the charging duration in minutes. S4 determines whether the current charging period is within the scheduled charging time based on the local time in minutes, the start time in minutes, and the end time in minutes; S5, based on the judgment result and the current charging status, issues corresponding control commands through the vehicle controller.

[0005] In conjunction with the first aspect mentioned above, in one possible implementation, the configuration rules for the preset charging parameters in S3 include: the charging start time is converted to a numerical range of 0-1439 minutes based on UTC standard time, the configuration range of the charging duration in minutes is 1-1380 minutes, and 1-minute accuracy is supported, and the reservation period defaults to the entire week from Monday to Sunday.

[0006] In conjunction with the first aspect mentioned above, in one possible implementation, obtaining the preset parameters in S3 includes: receiving the charging start time and charging duration input by the user through the in-vehicle infotainment system and converting them into corresponding minutes; and receiving the parameters sent by the user from the mobile terminal through the vehicle remote service platform and synchronizing them to the execution unit.

[0007] In conjunction with the first aspect mentioned above, in one possible implementation, S4 includes the determination of the same-day scenario and the cross-day status: if the end time minutes are less than 1440, it is determined to be the same-day scenario; when the local time minutes are greater than or equal to the start time minutes and less than the end time minutes, it is determined to be in the charging period; if the end time minutes are greater than or equal to 1440, it is determined to be the cross-day scenario; when the local time minutes are greater than or equal to the start time minutes and less than 1440, or when the local time minutes are greater than or equal to 0 and less than (end time minutes modulo 1440), it is determined to be in the charging period.

[0008] In conjunction with the first aspect mentioned above, in one possible implementation, the charging state in S5 includes charging and not charging; a control command to start charging is issued if and only if the determination result in S4 indicates that the charging period is in progress and the charging state is not charging; a CAN-FD command to stop charging is issued if and only if the charging period has expired and the charging state is charging.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, the control instructions in S5 include: local control instructions and remote synchronization instructions; the local control instructions are sent to the MCU via the SPI bus to drive the on-board charging module to perform charging start and stop actions; the remote synchronization instructions are sent to the vehicle remote service platform to provide feedback on the current charging status and perform remote synchronization of the charging status.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, the method employs a periodic polling mechanism to execute S1-S5, with a polling period of 1 second. During the polling process, only time calculation, parameter comparison, and instruction issuance judgment logic are executed. When no charging instruction is triggered, only basic timing and status monitoring are maintained.

[0011] Secondly, a CAN-FD data transmission system for scheduled vehicle charging is provided, comprising: a T-BOX, an in-vehicle infotainment system, an MCU, a TSP, and a BMS; the T-BOX is the core execution unit; the in-vehicle infotainment system is used to locally set preset charging parameters and synchronize them to the T-BOX; the BMS is used to collect battery charging status and feed it back to the T-BOX via the MCU; the MCU is used to receive local control commands issued by the T-BOX and drive the in-vehicle charging module to start and stop; the TSP is used to receive remote synchronization commands and remotely monitor the charging status.

[0012] In conjunction with the second aspect mentioned above, in one possible implementation, the T-BOX has a built-in non-volatile storage module for storing preset charging parameters, charging status markers, and time zone configuration information to ensure that data is not lost after the vehicle is powered off.

[0013] In conjunction with the second aspect mentioned above, in one possible implementation, the T-BOX connects to the MCU via the SPI bus, communicates with the in-vehicle infotainment system via the VSock virtual LAN, and remotely synchronizes with the TSP via a wireless communication network. The MCU connects to the BMS via the CAN-FD bus, and the system can respond to various SOC wake-up scenarios such as network wake-up, SMS wake-up, and RTC wake-up.

[0014] This application provides a CAN-FD transmission method and system for vehicle scheduled charging. Using UTC standard time as a reference, software logic completes the conversion from second-level timestamps to local minutes and time zone offset calibration, accurately adapting to both cross-day and same-day charging scenarios. It combines charging status subtotal to construct dual control logic for time judgment and status verification. Simultaneously, it relies on a non-volatile storage module to achieve persistent parameter storage and fault-tolerant processing. One-second low-power polling ensures real-time response and efficient resource utilization, effectively solving the technical problems of timing distortion and insufficient scenario adaptability in existing technologies. This achieves accurate and reliable execution of scheduled charging, full scenario coverage, and stable operation, significantly improving the functional applicability and user experience of scheduled charging for new energy vehicles.

[0015] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0016] Figure 1 A flowchart illustrating a CAN-FD transmission method for vehicle scheduled charging, provided in this application embodiment; Figure 2 A system architecture diagram of a CAN-FD data transmission system for vehicle scheduled charging provided in this application embodiment; Figure 3 System structure diagram of another CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment; Figure 4 A flowchart illustrating another CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment; Figure 5 A flowchart illustrating another CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment; Figure 6 A flowchart illustrating another method for sending CAN-FD commands during vehicle scheduled charging, as provided in this application embodiment. Detailed Implementation

[0017] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0018] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0019] The CAN-FD transmission method for vehicle pre-charging provided in this application embodiment can be applied to, for example... Figure 2 In a CAN-FD data transfer system for vehicle scheduled charging, as shown, Figure 2 As shown, the distributed system includes: T-BOX, in-vehicle infotainment system, MCU, vehicle remote service platform, and battery management system, among which: The T-BOX is the core execution unit; the in-vehicle infotainment system is used to set preset charging parameters locally and synchronize them to the T-BOX; the BMS is used to collect battery charging status and feed it back to the T-BOX; the MCU is used to receive local control commands issued by the T-BOX and drive the in-vehicle charging module to start and stop; and the TSP is used to receive remote synchronization commands and remotely monitor the charging status.

[0020] To address the technical problems of timing distortion and inaccurate triggering of scheduled charging start / stop commands in existing technologies, Figure 1 A flowchart illustrating a CAN-FD transmission method for vehicle scheduled charging, as provided in this application embodiment, is shown below. Figure 1 As shown, the method includes: S1, obtain the system UTC standard time after waking up the vehicle's SOC, and convert the standard time into the minutes of the current day.

[0021] The T-BOX (Telematics-Box, in-vehicle remote communication terminal) obtains the system UTC (Universal Time Coordinated) standard time after waking up the vehicle's SOC, which is the UTC second-level timestamp now_seconds output by the VCU. After converting it to a base-60 integer to obtain the cumulative minutes, it performs a modulo operation with a period of 1440 minutes (1 day) to remove redundant date-related information, retaining only the number of minutes now_minutes from 0 to 1439 of the current day. This is converted into a unified minute unit, adapting to the requirement of scheduled charging being triggered by time periods.

[0022] S2, based on the offset of the target area where the vehicle is located, corrects the time zone of the minutes of the day to obtain the local time minutes.

[0023] The vehicle's real-time geographic coordinates can be obtained through the positioning module integrated in the T-BOX, and then connected to the TSP (Telematics Service Provider) via wireless network. The TSP cloud platform matches the coordinates with the corresponding time zone information. For example, if the longitude falls within the 112.5°E – 127.5°E range, it is determined to be in the East 8 time zone, and the time zone offset is sent to the T-BOX. This ensures that the time zone parameters can be automatically updated when the vehicle travels across regions, avoiding errors in determining the scheduled charging time after crossing time zones.

[0024] In another implementation, users can manually select the vehicle's location or corresponding time zone through the in-vehicle infotainment system's settings interface and synchronize the settings to the T-BOX. This ensures the accuracy of the time zone information in case of positioning module failure or poor network signal, improving the system's fault tolerance.

[0025] The process of converting standard time to the current day's minutes includes: correcting the time zone based on the vehicle's time zone offset and the current day's minutes to obtain the local time minutes now_minutes_pek.

[0026] Specifically, taking the vehicle's location as the East 8 time zone as an example, using now_minutes_pek=(now_minutes+60 8) %1440 is used to achieve an offset to the East 8th time zone, i.e., adding 480 minutes. At the same time, the value overflow after the offset across days is avoided by taking the modulo of 1440. This solves the problem of inconsistency between the underlying UTC time of the system and the user's perceived local time, ensuring that the time triggering benchmark for scheduled charging is completely matched with the user's settings, and solving the problem of erroneous charging start / stop triggering caused by time zone deviation.

[0027] S3, obtain preset charging parameters, including the start time in minutes after the charging start time is converted and the charging duration in minutes. The charging end time in minutes is calculated based on the start time in minutes and the charging duration in minutes.

[0028] The configuration rules for the preset charging parameters include: the charging start time is converted to a value range of 0-1439 minutes based on UTC standard time, the configuration range of the charging duration in minutes is 1-1380 minutes, and it supports 1-minute precision. The reservation period is the entire week from Monday to Sunday by default.

[0029] The preset charging parameters include: receiving the charging start time and charging duration input by the user through the in-vehicle infotainment system and converting them into corresponding minutes; and receiving parameters sent by the user from the mobile terminal through the vehicle remote service platform and synchronizing them to the execution unit.

[0030] Specifically, the preset charging parameters can be obtained through the local configuration path via the following methods: Local configuration path: Users manually input the desired charging start time (e.g., 22:00) and charging duration (e.g., 8 hours) through the human-machine interface of the in-vehicle infotainment system (IVI). The in-vehicle infotainment system has built-in time conversion logic, which converts the input charging time into a value of 0-1439 minutes and the charging duration into a value of minutes. Then, the converted parameters are synchronized to the T-BOX via the VSock virtual LAN. The T-BOX stores the parameters in the built-in non-volatile storage module.

[0031] Remote configuration path: Users select the charging start time and charging duration through a mobile app and submit the information. The mobile app then uploads the parameters to the TPS. After the TPS verifies the format of the parameters, it sends them to the vehicle's T-BOX via wireless network. After receiving the parameters, the T-BOX converts the input charging time into a value of 0-1439 minutes and the charging duration into a value in minutes, and stores them synchronously.

[0032] Furthermore, the charging end time in minutes is calculated based on the start time in minutes and the charging duration in minutes, including: directly calculating the initial end time in minutes using addition, with the formula: initial end time in minutes end_minutes = start time in minutes + charging duration in minutes.

[0033] S4 determines whether the current charging period is within the scheduled charging time based on the local time in minutes, the start time in minutes, and the end time in minutes.

[0034] The determination process also includes the following: if the end time in minutes is less than 1440, it is determined to be a same-day scenario; if the local time in minutes is greater than or equal to the start time in minutes and less than the end time in minutes, it is determined to be a charging period. If the end time in minutes is greater than or equal to 1440, it is determined to be a cross-day scenario; if the local time in minutes is greater than or equal to the start time in minutes and less than 1440, or if the local time in minutes is greater than or equal to 0 and less than (the end time in minutes modulo 1440), it is determined to be a scheduled charging period.

[0035] Specifically, using 1440 minutes as the threshold, the charging scenarios are categorized by comparing the end time in minutes with this threshold: If the end time in minutes is less than 1440, it is determined to be a charging scenario for the same day. In this case, it is only necessary to complete the time period matching within the time range of the same day. When the local time in minutes is greater than or equal to the start time in minutes, and the local time in minutes is less than the end time in minutes, that is, start_minutes≤now_minutes_pek<end_minutes, it is determined to be within the scheduled charging period.

[0036] If the end time minutes are ≥1440, it is determined to be a cross-day scenario. If the local time minutes are ≥ the start time minutes and the local time minutes are <1440, i.e., start_minutes < now_minutes_pek < 1440, or the local time minutes are ≥0 and the local time minutes are < (end time minutes modulo 1440), i.e., 0 ≤ now_minutes_pek < end_minutes%1440, it is determined to be within the scheduled charging period.

[0037] S5, based on the judgment result and the current charging status, issues corresponding control commands through the vehicle controller.

[0038] The charging status includes charging and not charging.

[0039] A control command to start charging is issued only if the result of the determination in S4 indicates that the charging period is in progress and the charging status is not charging; a control command to stop charging is issued only if the charging period has expired and the charging status is charging.

[0040] Specifically, the charging status is global_charging_status (0 = not charging; 1 = charging). When the result of step S4 indicates that the charging period is in progress, the SPI command to start charging is sent to the MCU (Microcontroller Unit) only when global_charging_status = 0, to prevent repeated starts from causing the MCU to receive redundant commands and triggering hardware failures. When the result of step S4 indicates that the charging period has expired, the SPI command to stop charging is sent only when global_charging_status = 1, to avoid system abnormalities caused by mistakenly sending a stop command when the charging period is not in progress.

[0041] Based on this, the dual logic of time judgment and status verification avoids the repeated transmission of CAN-FD control commands, improves the reliability of vehicle electronics, reduces invalid command interactions through status logic, reduces communication overhead between SOC and MCU, and avoids hardware malfunctions due to repeated commands.

[0042] Furthermore, the control commands include: local control commands and remote synchronization commands; the local control commands include the SPI commands sent by the T-Box to the MCU, and the CAN-FD commands sent by the MCU to the on-board charging module to execute charging start and stop actions; the remote synchronization commands include the wireless communication network commands sent by the T-BOX to the vehicle remote service platform, which are used to provide feedback on the current charging status and perform remote synchronization of the charging status.

[0043] It should be noted that the SPI command embeds the CAN-FD payload. After receiving the SPI command, the MCU automatically adds the CAN-FD frame header field and sends it to the CAN-FD bus, which greatly reduces the complexity of protocol processing. Furthermore, it improves message processing efficiency by relying on the hardware encapsulation capability of the CAN-FD controller integrated in the MCU. Combined with the dual fault tolerance mechanism of SPI transmission verification and payload length verification, it effectively avoids invalid messages occupying bus bandwidth. At the same time, it adapts to the complex electromagnetic environment of the vehicle by taking advantage of the anti-interference characteristics of the CAN-FD differential signal.

[0044] Specifically, the local control command is generated by the T-BOX based on the charging period determination result and the current charging status, and is sent directly to the MCU via the vehicle SPI bus. The command includes a charging start / stop flag. After the MCU receives and verifies the command, it adds a CAN-FD header to the SPI command and sends the CAN-FD command to the OBC (On-Board Charger) to drive the OBC to perform the corresponding action. When the OBC receives the start charging command, it controls the on-board charging module to connect to the power supply to start charging. When the OBC receives the stop charging command, it controls the on-board charging module to cut off the power supply to terminate charging, thus realizing local closed-loop control of the charging action.

[0045] The remote synchronization command is generated synchronously by the T-BOX, and the command content includes the current charging status. The T-BOX converts the SPI command fed back by the MCU into a wireless communication network command through the built-in wireless communication module and uploads it to the TPS. After receiving the data, the platform parses and stores the data and synchronizes it to the user's APP in real time, so that the user can remotely view the vehicle charging status and realize remote monitoring and status traceability of the charging process.

[0046] Based on this, a complete chain of "user reservation - local execution - remote monitoring" has been constructed, which not only meets the local control requirements of the vehicle, but also supports users to check the charging status in real time through remote channels such as mobile APP, which is in line with the trend of intelligent and interactive modern vehicle systems.

[0047] Furthermore, the CAN-FD sending method when the vehicle schedules charging adopts a periodic polling mechanism to execute S1-S5, with a polling period of 1 second; during the polling process, only time calculation, parameter comparison and command sending judgment logic are executed, and only basic timing and status monitoring are maintained when the charging command is not triggered.

[0048] Specifically, to balance real-time performance and low power consumption, and to adapt to lightweight operation after SOC sleep and wake-up, a 1-second polling method is adopted to ensure that the time triggering delay is ≤1 second, meeting the triggering requirements of scheduled charging accurate to the minute. Moreover, only one time conversion and logic judgment are performed per second, reducing CPU utilization. Even if the SOC is woken up from the sphere and runs, it will not excessively consume the vehicle's power supply. This adapts to the scenario of lightweight operation after vehicle SOC sleep and wake-up. While ensuring the real-time performance of the function, it also takes into account the vehicle's static power consumption control, avoiding additional energy consumption caused by high code usage.

[0049] Figure 2 This application provides a system architecture diagram of a CAN-FD data transmission system for vehicle scheduled charging, as illustrated in the embodiments of this application. Figure 2 As shown, this system includes a T-BOX, an in-vehicle infotainment system, an MCU, a vehicle remote service platform, and a battery management system, among which: The T-BOX is the core execution unit of this system, which coordinates and completes the core operations of the entire process, including time processing, parameter management, scenario judgment, instruction issuance, and status synchronization.

[0050] Specifically, after the vehicle's SOC is woken up, the T-BOX autonomously acquires and calibrates the UTC second-level timestamp, converts and corrects the time zone to obtain the local time in minutes; it simultaneously receives the local configuration parameters of the in-vehicle infotainment system and the remote parameters issued by the vehicle's remote service platform, converts and stores them, calculates the charging end time in minutes, and then determines whether it is a charging scenario for the same day or a cross-day scenario. Combined with the battery management system, it generates remote synchronization network commands for the remote platform, and executes the entire process logic with low-power polling at a 1-second cycle, which has parameter fault tolerance processing capabilities. It completes data exchange with various in-vehicle modules, wireless communication and the remote platform through wireless communication networks, VSock virtual local area networks, SPI bus, and CAN-FD bus, ensuring the accurate and reliable operation of the scheduled charging function.

[0051] Furthermore, the T-BOX incorporates a built-in non-volatile storage module to store preset charging parameters, charging status markers, and time zone configuration information, ensuring data integrity even after vehicle power failure. The T-BOX also features parameter fault tolerance; when the retrieved preset charging parameters exceed the configuration range, it refuses to execute control command issuance logic and generates an error message. Through the built-in non-volatile storage module, the system achieves power-off protection for critical data, ensuring that user-configured charging plans and vehicle status can be restored after hibernation or unexpected power failure, thus guaranteeing the continuity and stability of the scheduled charging function. The introduction of the parameter fault tolerance mechanism effectively prevents erroneous command triggering due to data anomalies or configuration errors, protecting the hardware security of the vehicle charging system and enhancing the overall robustness of the system and the controllability of the user experience. This makes the scheduled charging system more practical and reliable in complex real-world in-vehicle environments.

[0052] Furthermore, Figure 3 A system structure diagram of a CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment is shown below. Figure 3 As shown, the T-BOX connects to the MCU via the SPI bus, communicates with the in-vehicle infotainment system via the VSock virtual LAN, and remotely synchronizes with the TSP via a wireless communication network. The MCU connects to the BMS via the CAN-FD bus. The system can respond to various SOC wake-up scenarios, including network wake-up, SMS wake-up, and RTC wake-up. By integrating the high-speed in-vehicle communication capabilities of buses such as CAN-FD with the remote interaction advantages of wireless communication, the system constructs a dual-protection link of in-vehicle local control and vehicle-to-cloud remote synchronization. This ensures that charging commands are accurately transmitted to execution units such as the MCU and BMS, while simultaneously providing real-time feedback on charging status to the user, achieving a closed loop of control and monitoring. Multiple wake-up mechanisms completely eliminate the system's dependence on a single wake-up source. Regardless of whether the vehicle is in a scenario with poor network signal, can only receive SMS commands, or relies on a built-in clock trigger, it can reliably wake up and execute the scheduled charging task, significantly improving the system's robustness and availability under different operating conditions and ensuring the continuous online operation of core functions.

[0053] The in-vehicle infotainment system is used to set preset charging parameters locally and synchronize them to the T-BOX.

[0054] Specifically, the in-vehicle infotainment system provides a visual charging parameter setting entry through a human-machine interface, allowing users to manually input or select the start time and charging duration for scheduled charging. The built-in time conversion logic converts the user-input time period information into a numerical format of 0-1439 minutes based on UTC standard time. Then, the converted standardized preset charging parameters are synchronized to the T-BOX in real time through the VSock virtual LAN. It also supports pop-up reminders and status display after parameter setting is completed, making it easy for users to confirm the settings.

[0055] BMS is used to collect battery charging status and feed it back to T-BOX.

[0056] Specifically, the BMS system collects core data such as voltage, current, and charge of the power battery in real time. By analyzing this data, it determines the current charging status of the battery (charging / not charging) and feeds back information including the charging status identifier and data verification code to the MCU in real time via the vehicle's CAN-FD bus. The MCU then sends the charging status information to the T-BOX, which generates and issues a charging start / stop command. control The instructions provide precise status information.

[0057] The MCU is used to receive local control commands from the T-BOX and drive the on-board charging module to start and stop.

[0058] Specifically, the MCU receives local control commands from the T-BOX via the SPI bus, verifies the validity of the start / stop flag and check code in the command, and outputs the corresponding drive signal according to the command type after the verification is passed, controlling the power circuit of the on-board charging module to be connected or disconnected, so as to realize the precise start and stop of charging. At the same time, the execution result is fed back to the T-BOX via the SPI bus, forming a closed-loop control of sending-execution-feedback.

[0059] The TSP is used to receive remote synchronization commands and remotely monitor the charging status.

[0060] Specifically, the TSP receives remote synchronous wireless communication network commands uploaded by the T-BOX through the wireless communication network, parses and verifies the charging status identifier, command issuance timestamp, and vehicle identification code contained in the command, stores the verified charging status data in the cloud database in real time, and pushes it to the user's mobile APP simultaneously. This allows users to remotely view the vehicle's current charging status, charging period, and historical charging records, enabling full remote monitoring and data traceability of the charging process.

[0061] Based on this, this system uses the T-BOX as its core hub, integrating the in-vehicle infotainment system, BMS, MCU, and TSP to construct a collaborative intelligent charging control network. This enables fully automated management of the entire process, from user command input to charging execution and status feedback. Leveraging the T-BOX's intelligent decision-making and scheduling capabilities, the system integrates local interaction and remote synchronization channels to ensure accurate initiation and reliable execution of charging commands. Simultaneously, through real-time status monitoring and fault tolerance mechanisms, it significantly improves the stability, security, and user experience of the vehicle's scheduled charging function, providing an efficient and reliable energy management solution while meeting energy-saving requirements.

[0062] Figure 4 A flowchart illustrating another CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment is shown below. Figure 3 As shown, the method includes: After the system is woken up, it obtains the current second-level timestamp (now_second), the number of minutes of the day (now_minutes), and the local time minutes (now_minutes_pek). First, it determines whether the charging end time in minutes is 1440 or greater than 1440 to distinguish between cross-day and non-cross-day scenarios.

[0063] Specifically, after the system is woken up, it obtains the second-level timestamp (now_second) corresponding to the current system's UTC standard time through the T-BOX, and converts the second-level timestamp into the number of minutes of the day within the range of 0-1439 minutes using the calculation logic of the number of minutes of the day (now_minutes) = (now_second / 60) % 1440, removing redundant date information; then, according to the time zone offset of the target region where the vehicle is located, for example, 480 minutes need to be added for the East 8 time zone, the number of minutes of the day is corrected for time zone using the local minutes (now_minutes_pek) = (now_second / 60) % 1440. The formula w_minutes + time zone offset)%1440 calculates the local time in minutes that is consistent with the user's perception. At the same time, the modulo 1440 is used to avoid the overflow of the value after cross-day correction. After the time processing is completed, the converted charging end time in minutes (end_minutes) in the preset charging parameters is retrieved. By judging whether end_minutes==1440||end_minutes>1440 is true, it is determined whether the current scheduled charging scenario is a cross-day scenario (the judgment result is yes) or a non-cross-day scenario (the judgment result is no), which lays the foundation for the accurate determination of the charging period in the future.

[0064] Based on this, by independently acquiring UTC second-level timestamps and completing minute conversion and time zone correction through T-BOX, it completely eliminates the dependence on external sleep duration information and specific hardware timing modules such as RTC. This effectively avoids the timing distortion problems caused by the lack of sleep duration feedback from the wake-up source, hardware module failure, or signal interference in traditional solutions. At the same time, by using 1440-minute modulo operation to remove redundant date information and prevent overflow of the corrected time zone value, it ensures that the local time minutes accurately match the actual time perceived by the user. Combined with the scenario judgment logic of charging end time minutes, it provides a reliable time benchmark for full coverage of both cross-day and non-cross-day scheduled charging scenarios, ensuring the accuracy of subsequent charging period determination from the source, laying a solid foundation for the accurate issuance of scheduled charging start and stop commands, and taking into account both timing reliability and scenario adaptability.

[0065] Figure 5 A flowchart illustrating another CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment is shown below. Figure 3 As shown, the method includes: In cross-day scenarios, the system determines whether the current local time in minutes satisfies star_m≤now_minutes_pek<1440 or 0≤now_minutes_pek<end_minutes%1440 to identify whether the system is in a charging period. Then, it combines this with a global charging status flag (global_charging_status). Only when the system is in a charging period and not charging does it send a start charging command and set the charging status flag to 1 (i.e., in charging state). When the system is in a charging period and already charging, no operation is performed. When the system is not in a charging period and is charging, a stop charging command is sent and the charging status is set to 0 (i.e., not charging state). No operation is performed when the system is not in a charging period and not charging. Finally, the charging status is output, and after waiting 1 second, the system re-enters the loop, continuously monitoring time and status with a 1-second cycle to ensure accurate command issuance and low-power operation.

[0066] Specifically, after a cross-day charging scenario is determined (end_minutes==1440||end_minutes>1440), the system first retrieves the preset charging start time in minutes (start_m), the current local time in minutes after time zone correction (now_minutes_pek), and the remaining time period in minutes after the cross-day period obtained by calculating end_minutes%1440. The system then uses two conditions to determine whether the current period is within the scheduled charging period: if start_m≤now_minutes_pek<1440 (corresponding to the charging period of the same day in the cross-day scenario), or 0≤now_minutes_pek<end_minutes%1440 (corresponding to the charging period of the next day in the cross-day scenario), the system is determined to be within the scheduled charging period; otherwise, it is determined to be outside the charging period.

[0067] Subsequently, the system reads the global charging status flag (global_charging_status), which is updated in real time by the battery charging status feedback from the BMS. 0 represents no charging, and 1 represents charging. Based on the time period determination results, differentiated instruction logic is executed: If it is a charging period and global_charging_status is 0 (no charging), the T-BOX immediately generates and sends an SPI command to start charging to the MCU, while simultaneously setting global_charging_status to 1 and recording the charging start status; if it is a charging period and global_charging_status is 1 (charging), the current state is maintained, and no redundant commands are sent to avoid the MCU repeatedly executing the start operation; if it is a non-charging period and global_charging_status is 1 (charging), an SPI command to stop charging is sent to the MCU, and global_charging_status is set to 0, terminating the charging process; if it is a non-charging period and global_charging_status is 0 (no charging), no instructions are executed, and the basic monitoring status is maintained.

[0068] After the command is executed, the T-BOX synchronizes the current charging status (start charging / stop charging / maintain status) to the TSP platform so that users can view it remotely. Then the system enters a 1-second waiting period. After the waiting period ends, the local time minutes update, time period determination and status verification process are triggered again. The process is continuously looped with a fixed polling period of 1 second. This ensures real-time response to charging time period switching (delay ≤ 1 second) and minimizes CPU usage and vehicle power consumption by performing only lightweight logic such as time calculation and status comparison. This achieves the dual goals of precise control and low power consumption.

[0069] Based on this, the dual-condition judgment logic of "same day time period + next day time period" fully covers the demand for midnight reservation charging, completely solving the problem of chaotic cross-day timing in traditional solutions. It eliminates the need for users to split configurations, significantly improving scenario adaptability and user experience. Relying on the dual verification mechanism of "time period judgment + global charging status marking", CAN-FD commands are only issued when the status changes, eliminating redundant command issuance, reducing invalid actions of the MCU and charging module and bus communication load, and improving system reliability. The 1-second polling cycle ensures that the response delay for charging time period switching is ≤1 second, meeting the requirements for accurate triggering. At the same time, because only lightweight calculations are performed, the CPU utilization and vehicle power consumption are reduced, balancing real-time performance and low power consumption. Simultaneously, the status marking is updated synchronously after the command is executed and fed back to the TSP platform, constructing a complete closed loop of "judgment-issuance-update-synchronization", ensuring local control consistency and user remote controllability, and comprehensively improving the practicality and stability of the reservation charging function.

[0070] Figure 6 A flowchart illustrating another CAN-FD transmission method for vehicle scheduled charging provided in this application embodiment is shown below. Figure 3 As shown, the method includes: In scenarios where the current local time in minutes does not span across days, the system directly checks whether the current local time in minutes satisfies start_m ≤ now_minutes_pek < end_minutes. Then, it combines the global charging status flag (global_charging_status) to send a start charging command and set the charging status flag to 1 (i.e., in charging state) only when the system is in a charging period and not in a charging state. When the system is in a charging period and already charging, no operation is performed. When the system is not in a charging period and is charging, a stop charging command is sent and the charging status is set to 0 (i.e., in non-charging state). No operation is performed when the system is not in a charging period and not charging. Finally, the system outputs the charging status and waits for 1 second before re-entering the loop. The system continuously monitors the time and status with a 1-second cycle to ensure the accuracy of command issuance and low-power operation.

[0071] Specifically, after determining that the charging scenario does not span across days (end_minutes < 1440), the system directly retrieves the preset charging start time in minutes (start_m), the current local time in minutes after time zone correction (now_minutes_pek), and the charging end time in minutes (end_minutes). The charging period is determined by a single condition: start_m ≤ now_minutes_pek < end_minutes. If this condition is met, it is determined that the system is in the scheduled charging period; otherwise, it is not in the charging period. The logic is simple, efficient, and suitable for the core scenario of charging within the same day.

[0072] Subsequently, the system reads the global charging status flag (global_charging_status) updated in real time by the BMS, where 0 indicates no charging and 1 indicates charging. Based on the time period determination result, precise instruction control is executed: if it is in the charging period and global_charging_status is 0, T-BOX immediately generates and sends an SPI instruction to start charging to the MCU, and at the same time sets the status flag to 1 to record the charging start status; if it is in the charging period and global_charging_status is 1, the current status is maintained and no redundant instructions are sent to avoid repeated hardware responses; if it is not in the charging period and global_charging_status is 1, an SPI instruction to stop charging is immediately sent to the MCU, and at the same time the status flag is set to 0 to terminate the charging process; if it is not in the charging period and global_charging_status is 0, no instructions are executed, and basic monitoring is maintained.

[0073] After the command is executed, T-BOX synchronizes the current charging status to the TSP platform to ensure remote visibility for users. The system then enters a 1-second waiting period. After the period ends, the local time update, time period determination, and status verification process are retried and restarted. The system runs in a fixed 1-second polling cycle, which not only meets the requirements for accurate triggering of scheduled charging through low-latency response, but also reduces CPU usage and power consumption with lightweight computing logic, achieving a balance between reliable control and low power consumption in scenarios that do not span across days.

[0074] Based on this, a simple judgment logic of "start_m≤now_minutes_pek<end_minutes" is adopted for charging scenarios that do not span across days. This logic can quickly and accurately identify the charging time period of the day without complex calculations, adapting to the core need of users to schedule charging within the same day and improving the efficiency of time period determination. Through dual verification of "time period determination + global charging status marking", the algorithm only sends a signal when the status changes. control The instructions eliminate redundant instructions that could lead to invalid hardware actions and bus communication load, ensuring system reliability. The 1-second polling cycle ensures that the response delay for switching charging periods is ≤1 second, meeting the triggering requirements accurate to the minute. It also significantly reduces CPU utilization and vehicle power consumption by performing only lightweight operations, achieving a balance between real-time performance and low power consumption. At the same time, the status flag is updated synchronously after the instruction is executed and fed back to the TSP platform, building a complete closed loop of "judgment-issuance-update-synchronization". This ensures the consistency of local control logic and supports users to remotely monitor the charging status in real time, comprehensively improving the practicality, stability and user experience of the scheduled charging function in scenarios that do not span across days.

[0075] In summary, through Figure 3 , Figure 4 , Figure 5The constructed three-level process logic forms a complete CAN-FD command delivery solution for vehicle scheduled charging: First, relying on T-BOX to independently obtain UTC second-level timestamps, after minute conversion, time zone correction, and 1440-minute modulo anti-overflow processing, it completely eliminates the dependence on external sleep duration and specific hardware timing modules, providing an accurate time reference for distinguishing between cross-day and non-cross-day scenarios, and avoiding timing distortion problems from the source; Second, for cross-day scenarios, a dual judgment logic of "same day time period + next day time period" is designed, while for non-cross-day scenarios, a simple and efficient single-condition judgment is adopted to achieve full coverage of all charging scenarios; Finally, through the dual verification mechanism of "time period judgment + global charging status marking", the command is only issued when the status changes, eliminating redundant interaction. Combined with 1-second low-power polling and TSP platform status synchronization, it not only ensures the accurate triggering of charging start and stop commands (response delay ≤ 1 second), but also reduces hardware loss and power consumption, while constructing a complete closed loop of "judgment-delivery-update-synchronization". The entire process takes into account the requirements of timing reliability, scenario adaptability, control precision and low power consumption, effectively solving the core problems of timing distortion and inaccurate command triggering in existing technologies under SOC multi-wake-up scenarios, and comprehensively improving the stability, practicality and user experience of the new energy vehicle scheduled charging function.

[0076] It should be noted that, in addition to the specific embodiments described above, those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Although the description of the present invention is presented in conjunction with preferred embodiments, this does not mean that the features of the invention are limited to those embodiments. On the contrary, the purpose of describing the invention in conjunction with embodiments is to cover other options or modifications that may be derived based on the claims of the present invention. To provide a deep understanding of the invention, many specific details are included in the above description, and the invention may also be implemented without using these details. Furthermore, to avoid confusion or obscuring the focus of the invention, some specific details will be omitted in the description. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0077] It should be noted that in this specification, similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0078] In the description of this embodiment, it should be noted that the terms "upper," "lower," "inner," "bottom," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of the invention is in use. They are only for the convenience of describing the 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 the invention. The terms "first," "second," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0079] In the description of this embodiment, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set up," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this embodiment based on the specific circumstances.

[0080] While the present invention has been illustrated and described with reference to certain preferred embodiments, those skilled in the art should understand that the above description is a further detailed explanation of the invention in conjunction with specific embodiments, and should not be construed as limiting the specific implementation of the invention to these descriptions. Various changes in form and detail can be made by those skilled in the art, including several simple deductions or substitutions, without departing from the spirit and scope of the invention.

Claims

1. A CAN-FD transmission method for vehicle scheduled charging, characterized in that, The CAN-FD data transmission system used in vehicle scheduled charging includes a T-BOX, and the method includes: S1, Obtain the system UTC standard time after the vehicle's SOC wake-up, and convert the standard time into minutes of the current day; S2, adjust the time zone of the minutes of the day according to the offset of the target area where the vehicle is located, and obtain the local time minutes; S3, obtain preset charging parameters, the preset charging parameters include the start time in minutes after the charging start time is converted and the charging duration in minutes, and calculate the charging end time in minutes based on the start time in minutes and the charging duration in minutes; S4 determines whether the current charging period is within the scheduled charging time based on the local time in minutes, the start time in minutes, and the end time in minutes; S5, based on the judgment result and the current charging status, issues corresponding control commands through the vehicle controller.

2. The CAN-FD transmission method for vehicle scheduled charging according to claim 1, characterized in that, The configuration rules for the preset charging parameters in S3 include: the charging start time is converted to a value range of 0-1439 minutes based on UTC standard time, the configuration range of the charging duration in minutes is 1-1380 minutes, and 1 minute accuracy is supported. The reservation period is the entire week from Monday to Sunday by default.

3. The CAN-FD transmission method for vehicle scheduled charging according to claim 1, characterized in that, The S3 step of acquiring preset charging parameters includes: The system receives the user's input of charging start time and charging duration through the in-vehicle infotainment system and converts them into corresponding minutes. The vehicle remote service platform receives parameters sent by users from their mobile devices and synchronizes them to the execution unit.

4. The CAN-FD transmission method for vehicle scheduled charging according to claim 1, characterized in that, The determination in S4 includes the determination of the current day's scenario and the cross-day status: If the end time in minutes is less than 1440, it is determined to be a scene of the same day. If the local time in minutes is greater than or equal to the start time in minutes and less than the end time in minutes, it is determined to be a charging period. If the end time minutes are ≥1440, it is determined to be a cross-day scenario. When the local time minutes are ≥ the start time minutes and the local time minutes are <1440, or the local time minutes are ≥0 and the local time minutes are < (end time minutes modulo 1440), it is determined to be a charging period.

5. The CAN-FD transmission method for vehicle scheduled charging according to claim 1, characterized in that, The charging status in S5 includes charging and not charging; A control command to start charging is issued if and only if the determination result in S4 is that the charging period is in progress and the charging status is not charging. A control command to stop charging shall be issued only if the charging period has expired and the charging status is "charging".

6. The CAN-FD transmission method for vehicle scheduled charging according to claim 1, characterized in that, The control commands in S5 include: local control commands and remote synchronization commands; Local control commands are sent to the MCU via the SPI bus to drive the on-board charging module to perform charging start and stop actions; The remote synchronization command is sent to the vehicle's remote service platform to provide feedback on the current charging status and perform remote synchronization of the charging status.

7. The CAN-FD transmission method for vehicle scheduled charging according to claim 1, characterized in that, The method employs a periodic polling mechanism to execute S1-S5, with a polling period of 1 second; During the polling process, only time calculation, parameter comparison and instruction issuance judgment logic are executed. When no charging instruction is triggered, only basic timing and status monitoring are maintained.

8. A CAN-FD transmission system for vehicle scheduled charging, characterized in that, The system includes: T-BOX, in-vehicle infotainment system, MCU, TSP and BMS; T-BOX, the core execution unit; The in-vehicle infotainment system is used to set preset charging parameters locally and synchronize them to the T-BOX; BMS is used to collect battery charging status and feed it back to T-BOX via MCU; The MCU is used to receive local control commands from the T-BOX and drive the on-board charging module to start and stop. The TSP is used to receive remote synchronization commands and remotely monitor the charging status.

9. A CAN-FD transmission system for vehicle scheduled charging according to claim 8, characterized in that, The T-BOX has a built-in non-volatile storage module for storing preset charging parameters, charging status markers, and time zone configuration information, ensuring that data is not lost after the vehicle is powered off.

10. A CAN-FD transmission system for vehicle scheduled charging according to claim 8, characterized in that, The T-BOX is connected to the MCU via the SPI bus, communicates with the in-vehicle infotainment system via the VSock virtual LAN, and remotely synchronizes with the TSP via a wireless communication network. The MCU is connected to the BMS via the CAN-FD bus. The system can respond to various SOC wake-up scenarios such as network wake-up, SMS wake-up, and RTC wake-up.

Images