Fuel cell controller

Abstract

The invention relates to a fuel cell controller comprising a main control chip used for integrating vehicle control, vehicle body control and a vehicle-mounted terminal; the Flash storage module is used for storing program files required by the operation of the controller in a partitioned manner and is divided into two independent storage regions; the RAM storage module is used for temporarily storing real-time data in the operation process of the controller, and is divided into two independent areas which are respectively distributed to different cores of the main control chip; the 4G wireless communication module is used for establishing wireless connection between the controller and a remote server; and the SD card storage module is used for backing up and storing vehicle real-time operation data, fault data and an OTA upgrade package. By integrating vehicle control, vehicle body control and the vehicle-mounted terminal into the main control chip, the problems of single function and high cost of the terminal can be effectively solved according to the multi-module design of the embodiment of the invention, the functions of OTA non-inductive upgrading and the like are realized, the cost is reduced, the efficiency is improved, and the safety is ensured.

Description

TECHNICAL FIELD

[0001] The application relates to the cross field of automobile electronic control and Internet of Vehicles technology, and particularly relates to a fuel cell controller. BACKGROUND

[0002] At present, the TBOX vehicle terminal has single function and high price in China. In order to solve the problems of excessive number of controllers, high cost, low function safety level and the like, the TBOX (an important component of the Internet of Vehicles system), the VCU (vehicle control unit) and the BCM (body control unit) are integrated to meet the requirements of low cost, high performance and high safety level. The controller can perform OTA whole vehicle non-inductive upgrading and remote diagnosis, and reduces the on-site maintenance and upgrading of maintenance personnel.

[0003] The existing vehicle terminal TBOX has single function, low efficiency, low safety level and needs maintenance personnel to perform on-site maintenance and upgrading. Alternatively, the vehicle is taken to a 4S store for program upgrading. Therefore, a solution with higher integration and more comprehensive function is urgently needed. SUMMARY

[0004] Therefore, the application provides a fuel cell controller, which comprises: a main control chip configured to integrate vehicle control, body control and a vehicle terminal; a Flash storage module configured to store program files required for controller operation in a partitioned manner, and divided into two independent storage areas; a RAM storage module configured to temporarily store real-time data in the controller operation process, and divided into two independent areas and allocated to different cores of the main control chip; a 4G wireless communication module configured to establish wireless connection between the controller and a remote server; an SD card storage module configured to backup and store vehicle real-time operation data, fault data and OTA upgrade package.

[0005] In a possible implementation, the main control chip adopts an NXP-S32K324 dual-core chip, which comprises a first core and a second core; the first core is configured to run related programs of the vehicle control unit and the body control unit; the second core is configured to run related programs of the vehicle terminal.

[0006] In a possible implementation, the two independent storage areas of the Flash storage module are A area and B area; when the controller program runs in the A area, the B area program is refreshed in a non-inductive manner through OTA upgrading, and after the refreshing is completed, the running is switched to the B area; When the program runs in the B area, the A area program is refreshed by the OTA upgrade mode, and when any area program appears abnormal, it can automatically switch to another backup area.

[0007] In a possible implementation, two independent areas of the RAM storage module are respectively allocated to the first core and the second core of the master control chip, and the area allocated to the first core is used for temporarily storing real-time data generated in the running process of the vehicle control unit and the body control unit, and the area allocated to the second core is used for temporarily storing real-time data generated in the running process of the vehicle terminal.

[0008] In a possible implementation, the 4G wireless communication module also supports a 4G remote wake-up function. When the controller is in a sleep state, the 4G wireless communication module is connected to a constant power supply, and a heartbeat message is sent to a remote server every 3 minutes to avoid disconnection of a wireless connection due to a long time of no data interaction. When the server needs to wake up the controller, a wake-up message is sent to the 4G wireless communication module, and the 4G wireless communication module wakes up the controller by pulling up a wake-up pin.

[0009] In a possible implementation, the SD card storage module synchronously records vehicle real-time information reported by the controller every 10 seconds when the vehicle has no OTA flashing task. The vehicle real-time information includes whole vehicle data, drive motor data, vehicle position, extreme value data, and alarm data, and the data format complies with the GB32960 protocol standard. When the vehicle fails, the SD card storage module is also used for storing 30 seconds of data before a fault and 30 seconds of data after the fault uploaded to the server by the vehicle terminal.

[0010] In a possible implementation, the vehicle terminal integrated with the master control chip supports data interaction with a remote server, can complete vehicle login, receive an OTA upgrade task, report vehicle status and fault data, and needs to upload a SIM card number and a vehicle unique identifier VIN to the server when the vehicle is logged in.

[0011] In a possible implementation, when the Flash storage module receives an OTA upgrade package for flashing, if the ECU type corresponding to the upgrade is the controller itself, the upgrade package data is directly flashed to the Flash storage area of the controller itself. If the ECU type corresponding to the upgrade is the rest of the vehicle components, the upgrade package is temporarily stored in the SD card storage module backup, and then the upgrade package data is read from the SD card and flashed to the Flash memory of the corresponding component.

[0012] In a possible implementation, the 4G wireless communication module assists the vehicle-mounted terminal to receive the OTA upgrade task and the upgrade strategy file issued by the remote server in the OTA upgrade process, and the vehicle-mounted terminal downloads the upgrade strategy file and the upgrade package from the server based on the Http protocol through the 4G wireless communication module.

[0013] In a possible implementation, the fault data stored in the SD card storage module can be called by the remote server, and the vehicle remote diagnosis is realized by checking the fault data through the server, and when the program of a certain Flash storage area of the controller is abnormal, the controller can read the program from the backup data stored in the SD card storage module and switch to the backup program to run.

[0014] Advantages of the application: By integrating the vehicle control unit, the body control unit and the vehicle-mounted terminal in the main control chip, combining the Flash dual-zone SWAP, the RAM dual-core independent allocation, the 4G wireless connection and the SD card backup, according to the hardware architecture and the function design of various aspects of the application, the problems of single function and high cost of the TBOX can be solved, OTA non-inductive upgrade and remote wake-up diagnosis can be realized, the efficiency and safety can be improved, and the maintenance cost can be reduced.

[0015] Other features and aspects of the application will become apparent from the following detailed description of exemplary embodiments with reference to the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate examples of the application and together with the description, serve to explain the principles of the application.

[0017] Figure 1 A block diagram of a fuel cell controller according to an embodiment of the application is shown; DETAILED DESCRIPTION Various exemplary embodiments, features and aspects of the application will be explained below in detail with reference to the accompanying drawings. The same reference numbers in the drawings represent functionally the same or similar elements. Although various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0018] It should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application or simplifying the description, and therefore cannot be understood as indicating or implying that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application.

[0019] In addition, the terms "first", "second" are only for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first", "second" can explicitly or implicitly include one or more of the features. In the description of the present application, the meaning of "multiple" is two or more, unless otherwise explicitly specified.

[0020] The word "exemplary" here means "serving as an example, an implementation, or an illustration". Any implementation described as "exemplary" here is not necessarily to be construed as superior or better than other implementations.

[0021] In addition, in order to better illustrate the present application, a large number of specific details are given in the specific embodiments below. Those skilled in the art should understand that the present application can also be implemented without certain specific details. In some examples, methods, means, elements and circuits well known to those skilled in the art are not described in detail, in order to highlight the main idea of the present application.

[0022] The fuel cell controller of the present application is a domain controller integrating the functions of VCU, BCM and TBOX, using NXP-S32K324 dual-core dual-system architecture, Flash supporting SWAP partition, whole vehicle OTA non-inductive upgrade, 4G remote wake-up and diagnosis, applied in the cross field of automotive electronic control and Internet of Vehicles technology, playing a role in reducing the number of vehicle controllers to reduce cost, improving program running efficiency and security level, realizing vehicle remote monitoring, fault data retention and non-inductive upgrade, reducing the need for on-site maintenance.

[0023] Specific reference Figure 1 As a specific embodiment of the fuel cell controller of the present application, the fuel cell controller 100 comprises: The main control chip 110 is used to integrate vehicle control, body control and vehicle terminal.

[0024] Specifically, the main control chip 110 is the core operation and control unit of the fuel cell controller 100, and its core function is to realize the integration of vehicle control, body control and TBOX functions. Specifically, NXP-S32K324 chip is adopted, which has dual-core processing capability. Through the "dual-core dual-system independent running" architecture, the related programs of vehicle control unit (VCU) and body control module (BCM) are allocated to core 0, and the program of TBOX is allocated to core 1. This design breaks the traditional VCU, BCM and TBOX separate setting mode, which can not only reduce the number of vehicle controllers to reduce cost, but also avoid the data interaction delay between multiple controllers, while ensuring that a single module runs without affecting the normal implementation of vehicle control and body control functions, significantly improving the overall program execution efficiency and running stability.

[0025] The flash storage module 120 is used for partition storage of program files required for controller running, and is divided into two independent storage areas.

[0026] Specifically, the flash storage module 120 undertakes the partition storage task of program files required for controller running, and is specially divided into two independent storage areas A and B, adopting "SWAP partition" design logic. Its core advantage lies in the safety and continuity of program running and upgrading: when the controller runs normally, the program is only loaded and executed in one area (such as A area), at this time, the program in the other area (such as B area) can be "refreshed" by OTA upgrade, and after the refresh is completed, the controller can smoothly switch to B area running; conversely, the program in B area can refresh A area at the same time. In addition, if the program in any storage area is abnormal (such as damage, lag), the module can automatically trigger the switching mechanism to transfer the program loading task to the other backup area, avoid the controller downtime caused by program failure, and ensure the control stability during vehicle driving, while providing key hardware support for vehicle OTA non-inductive upgrade.

[0027] The RAM storage module 130 is used for temporary storage of real-time data in the controller running process, and is divided into two independent areas respectively allocated to different cores of the main control chip 110.

[0028] Specifically, the core role of the RAM storage module 130 is to temporarily store real-time data generated during the running of the controller, and is also divided into two independent areas, and according to the "core exclusive allocation" principle, it corresponds to the two cores of the main control chip 110. Among them, the area allocated to the core 0 running the VCU and BCM program is only used to temporarily store the real-time data generated during the running of the vehicle control unit and the vehicle body control module, and the area allocated to the core 1 running the TBOX program is specially used to temporarily store the real-time data during the running of the vehicle terminal. This "partition independent storage" design can realize the physical isolation of the two types of data, avoid the mutual interference of the data of different cores, for example, when the core 1 executes OTA upgrade to generate a large amount of temporary data, it will not occupy the RAM storage space of the core 0, and will not affect the rapid reading and processing of the real-time control data of the VCU and BCM, ensuring that the vehicle control function can still respond efficiently during the upgrade process.

[0029] 4G wireless communication module 140, for establishing wireless connection between the controller and the remote server.

[0030] Specifically, the 4G wireless communication module 140 is the "bridge" for the controller and the remote server to establish data interaction, not only bearing the basic wireless connection function, but also integrating the remote wake-up, OTA upgrade support and other key roles. In terms of data interaction, the module supports bidirectional communication between the vehicle terminal (TBOX) and the server, including: uploading the SIM card number and the vehicle unique identifier VIN during vehicle login to complete identity verification, receiving the OTA upgrade task and upgrade strategy file (including task ID, ECU type, upgrade package address) issued by the server, assisting the TBOX to download the upgrade strategy file and upgrade package from the server based on the Http protocol, reporting the vehicle online status, OTA upgrade result, fault data, etc. to the server. In terms of remote wake-up, the module uses the "constant power supply + heartbeat message" mechanism: even if the controller as a whole is in a sleep state, the 4G module still maintains constant power access, and sends a heartbeat message to the server every 3 minutes to prevent the wireless connection from being disconnected due to long time without data interaction. When the server needs remote control (such as emergency OTA upgrade, fault diagnosis), it can send a wake-up message to the module, and the module triggers the controller to wake up as a whole by pulling up the wake-up pin, realizing the remote controllable "sleep, wake-up", and reducing the dependence on local operation of the vehicle.

[0031] SD card storage module 150, for backup storage of vehicle real-time running data, fault data and OTA upgrade package.

[0032] Specifically, the SD card storage module 150 is positioned as a "multi-dimensional data backup" system, primarily storing three types of key data: First, real-time vehicle operating data. When the vehicle has no OTA (Over-The-Air) flashing task, the module synchronously records the real-time information reported by the controller every 10 seconds. This real-time information includes vehicle data, drive motor data, vehicle location, extreme value data, and alarm data, and the data format strictly adheres to the GB32960 protocol standard to ensure data standardization and traceability. Second, fault data. When a vehicle malfunctions, the module automatically stores the data uploaded by the onboard terminal to the server for "30 seconds before the fault + 30 seconds after the fault," providing complete data support for maintenance personnel to remotely analyze the cause of the fault. Third, OTA upgrade package backup. When the OTA upgrade involves other vehicle components, the module first receives and temporarily stores the upgrade package, then assists in flashing the upgrade package data to the corresponding component's Flash memory, preventing the upgrade package from being lost during transmission. In addition, the fault data stored in the module can be retrieved by a remote server, supporting remote diagnosis by maintenance personnel; when the program in the controller's Flash storage area is abnormal, the backup program can also be read from the SD card through server control, further improving fault repair efficiency and reducing on-site maintenance needs.

[0033] Furthermore, such as Figure 1 As shown, the fuel cell controller 100 of this application includes a main control chip 110, a Flash storage module 120, a RAM storage module 130, a 4G wireless communication module 140, and an SD card storage module 150. The main control chip 110 is responsible for integrating vehicle control, body control, and the on-board terminal. The Flash storage module 120 can partition and store program files, divided into two independent storage areas. The RAM storage module 130 can temporarily store real-time data, also divided into two independent areas and allocated to different cores of the main control chip 110. The 4G wireless communication module 140 is used to establish a wireless connection between the controller and a remote server. The SD card storage module 150 is used to back up and store real-time vehicle operating data, fault data, and OTA upgrade packages.

[0034] In one possible implementation, the main control chip 110 uses an NXP-S32K324 dual-core chip, which includes a first core and a second core. The first core is used to run the relevant programs of the vehicle control unit and the body control unit, and the second core is used to run the relevant programs of the vehicle terminal.

[0035] Specifically, the main control chip 110 of the fuel cell controller 100 uses an NXP-S32K324 dual-core chip, which has two independent computing cores: a first core and a second core. In actual operation, the first core is dedicated to running the relevant programs for the Vehicle Control Unit (VCU) and Body Control System (BCM), handling tasks such as vehicle power control and control of body accessories (e.g., lights, doors, windows). The second core runs the relevant programs for the Vehicle Terminal Box (TBOX), primarily handling data interaction with the remote server and vehicle status reporting. This dual-core division of labor integrates vehicle control, body control, and onboard terminal functions, improving the controller's operating efficiency and functional integration.

[0036] In one possible implementation, the Flash storage module 120 has two independent storage areas, area A and area B. When the controller program is running in area A, it can seamlessly refresh the program in area B through OTA upgrade. After the refresh is completed, it can switch to run in area B. When the program is running in area B, it can seamlessly refresh the program in area A through OTA upgrade. And when the program in either area malfunctions, it can automatically switch to the other backup area.

[0037] Specifically, the Flash storage module 120 is divided into two independent storage areas, A and B. When the controller is running normally, if the program is running in area A, the program in area B can be seamlessly refreshed via OTA (Over-The-Air) upgrade. The entire refresh process will not affect the normal driving and control of the vehicle. After the refresh is complete, the controller will automatically switch to running the program in area B. Conversely, when the program is running in area B, the program in area A can be seamlessly refreshed via OTA upgrade. Furthermore, if the program in either area A or area B malfunctions, such as program corruption or lag, the controller can automatically switch to the backup area to ensure the continuity of program operation and the stability of vehicle control.

[0038] In one possible implementation, the two independent areas of the RAM storage module 130 are respectively allocated to the first core and the second core of the main control chip 110, and the area allocated to the first core is used to temporarily store real-time data generated during the operation of the vehicle control unit and the body control unit, while the area allocated to the second core is used to temporarily store real-time data generated during the operation of the vehicle terminal.

[0039] Specifically, the RAM storage module 130 is also divided into two independent areas, which are respectively allocated to the first core and the second core of the main control chip 110. The area allocated to the first core is used to temporarily store real-time data generated by the vehicle control unit and body control unit during operation, such as the vehicle's real-time speed, power output parameters, and control commands for body accessories. The area allocated to the second core is used to temporarily store real-time data generated by the on-board terminal during operation, such as the vehicle's real-time location information and temporary data interacting with the server. This regional storage method avoids interference between data generated by different cores, ensuring high efficiency in data storage and processing.

[0040] In one possible implementation, the 4G wireless communication module 140 also supports 4G remote wake-up functionality. When the controller is in sleep mode, the 4G wireless communication module 140 is connected to a constant power supply and sends a heartbeat message to the remote server every 3 minutes to avoid the wireless connection being disconnected due to a long period of no data interaction. When the server needs to wake up the controller, it sends a wake-up message to the 4G wireless communication module 140, and the 4G wireless communication module 140 wakes up the controller by pulling up the wake-up pin.

[0041] Specifically, the 4G wireless communication module 140 has a 4G remote wake-up function. When the controller is in sleep mode, the 4G wireless communication module 140 is connected to the vehicle's constant power supply and sends a heartbeat message to the remote server every 3 minutes to maintain the wireless connection with the server and prevent the wireless connection from being lost due to a long period of no data interaction. When the remote server needs to wake up the controller, it sends a wake-up message to the 4G wireless communication module 140. After receiving the message, the 4G wireless communication module 140 wakes up the entire controller by pulling up the wake-up pin, thereby enabling remote control or data interaction operations.

[0042] In one possible implementation, when the vehicle is not undergoing an OTA flashing task, the SD card storage module 150 synchronously records the real-time vehicle information reported by the controller every 10 seconds. The real-time vehicle information includes vehicle data, drive motor data, vehicle location, extreme value data, and alarm data, and the data format conforms to the GB32960 protocol standard. When the vehicle malfunctions, the SD card storage module 150 is also used to store the data uploaded by the vehicle terminal to the server 30 seconds before the malfunction and 30 seconds after the malfunction.

[0043] Specifically, when the vehicle is not undergoing OTA (Over-The-Air) flashing, the SD card storage module 150 synchronously records the real-time vehicle information reported by the controller every 10 seconds. This real-time vehicle information includes overall vehicle data (such as the vehicle's overall operating status parameters), drive motor data (such as motor speed and torque), vehicle location, extreme value data (such as extreme speeds during driving), and alarm data, and all data formats strictly comply with the GB32960 protocol standard. When a vehicle malfunctions, the SD card storage module 150 also stores the data uploaded by the vehicle terminal to the server for the 30 seconds before and after the malfunction, providing complete data support for subsequent fault analysis and diagnosis.

[0044] In one possible implementation, the vehicle terminal integrated by the main control chip 110 supports data interaction with a remote server, and can complete vehicle login, receive OTA upgrade tasks, report vehicle status and fault data. When logging in, the vehicle needs to upload the SIM card number and the vehicle's unique identifier (VIN) to the server.

[0045] Specifically, the vehicle terminal integrated into the main control chip 110 supports data interaction with a remote server. In practical applications, the vehicle terminal can complete vehicle login operations. During the login process, it needs to upload the SIM card number and the vehicle's unique identifier (VIN) to the server so that the server can identify and verify the vehicle's identity. Simultaneously, the vehicle terminal can also receive OTA upgrade tasks from the server and promptly report the vehicle's status (such as operating status, fault status, etc.) and fault data to the server, achieving information exchange between the vehicle and the server.

[0046] In one possible implementation, when the Flash storage module 120 receives an OTA upgrade package for flashing, if the ECU type corresponding to the upgrade is the controller itself, it directly flashes the upgrade package data to its own Flash storage area; if the ECU type corresponding to the upgrade is other parts of the vehicle, it temporarily stores the upgrade package in the SD card storage module 150 for backup, and then reads the upgrade package data from the SD card and flashes it to the Flash memory of the corresponding part.

[0047] Specifically, when the Flash storage module 120 receives an OTA upgrade package for flashing, it will adopt different flashing methods depending on the type of the corresponding ECU (Electronic Control Unit) being upgraded. If the type of the corresponding ECU being upgraded is the controller itself, the Flash storage module 120 will directly flash the upgrade package data to its own Flash storage area; if the type of the corresponding ECU being upgraded is other components of the vehicle (such as the motor controller, battery management system, etc.), the Flash storage module 120 will first temporarily store the upgrade package in the SD card storage module 150 for backup, and then read the upgrade package data from the SD card and flash it to the Flash memory of the corresponding component, ensuring the safety and reliability of the upgrade operation.

[0048] In one possible implementation, during the OTA upgrade process, the 4G wireless communication module 140 assists the vehicle terminal in receiving the OTA upgrade task and upgrade strategy file issued by the remote server, and the vehicle terminal downloads the upgrade strategy file and upgrade package from the server based on the HTTP protocol through the 4G wireless communication module 140.

[0049] Specifically, during the OTA upgrade process, the 4G wireless communication module 140 assists the vehicle terminal in data interaction with the remote server. Specifically, the 4G wireless communication module 140 helps the vehicle terminal receive OTA upgrade tasks and upgrade policy files from the remote server. Furthermore, the vehicle terminal can download the upgrade policy files and upgrade packages from the server via the 4G wireless communication module 140 using the HTTP protocol, providing network communication support for the smooth execution of the OTA upgrade.

[0050] In one possible implementation, the fault data stored in the SD card storage module 150 can be retrieved by a remote server. By viewing the fault data through the server, remote vehicle diagnosis can be achieved. At the same time, when a program in a certain Flash storage area of ​​the controller is abnormal, the server can control the controller to read the program from the backup data stored in the SD card storage module 150 and switch to the backup program for execution.

[0051] Specifically, the fault data stored in the SD card storage module 150 can be retrieved by a remote server. When a vehicle malfunctions and requires remote diagnostics, the server can retrieve the fault data stored in the SD card storage module 150, allowing maintenance personnel to view this data and thus enabling remote vehicle diagnostics. Simultaneously, if a program in a specific Flash storage area of ​​the controller malfunctions, the server can control the controller to read the program from the backup data stored in the SD card storage module 150, switch to the backup program, and quickly restore the controller's normal functionality, reducing the need for on-site maintenance.

[0052] Furthermore, this design uses the NXP-S32K324 as the main control chip 110. The software divides the Flash storage module 120 into two storage areas (A / B areas). When the program is running in area A, the program in area B can be seamlessly refreshed via OTA. After the refresh is complete, the program switches to area B. Conversely, when the program is running in area B, the program in area A can be seamlessly refreshed via OTA. If a program in one area malfunctions, the system switches to the backup area to ensure more stable vehicle operation. The software divides the RAM storage module 130 into two areas, designated as core 0 and core 1 respectively. The VCU and BCM run in core 0, and the TBOX runs in core 1. When performing an OTA remote upgrade, core 1 updates the program without affecting the normal operation of the vehicle.

[0053] OTA Upgrade Details: OTA upgrades are implemented using a 4G wireless communication module 140. After the vehicle terminal (TBOX) connects to the server, vehicle login is required. Vehicle login requires the SIM card number and the vehicle's unique identifier (VIN). After successful vehicle login, the server platform updates the vehicle status to online. The server platform then creates an OTA upgrade task and sends it to the vehicle terminal (TBOX). The specific process is as follows: 1. The server platform checks whether the OTA protocol version of the vehicle terminal is correct. If the version is correct, the OTA upgrade is performed; otherwise, the upgrade task is terminated.

[0054] 2. The server platform queries the current software version of the vehicle terminal. If the versions are inconsistent, an OTA upgrade is performed; otherwise, the upgrade task is terminated.

[0055] 3. The server platform asks the car owner via WeChat mini-program whether they agree to the upgrade. If they agree, the OTA upgrade will proceed; otherwise, the upgrade task will be terminated.

[0056] 4. The server sends out the upgrade strategy file address. The strategy file contains the task ID, the type of ECU to be upgraded, and the download address of the upgrade package.

[0057] 5. The vehicle terminal downloads the policy file to its local machine via HTTP protocol, performs MD5 verification and parsing, and extracts the current task ID, ECU type, and upgrade package download address. If the vehicle terminal's verification and parsing are correct, it returns a positive response to the server. Otherwise, it sends a negative response to the server.

[0058] 6. If the resolved ECU type is self-upgrading, the upgrade package data is flashed into its own Flash memory. If the resolved ECU type is another component, the upgrade package is first stored in the SD card storage module 150 as a backup, and then flashed into the corresponding component's Flash memory.

[0059] 7. After flashing is complete, report a successful flashing to the server platform.

[0060] When the vehicle has no OTA (Over-The-Air) update task, it periodically reports real-time vehicle information every 10 seconds, and the reported data is synchronously recorded on the SD card. The real-time information reported includes: vehicle data, drive motor data, vehicle location, extreme value data, and alarm data, with the data format conforming to the GB32960 protocol standard. When a vehicle malfunctions, the onboard terminal transmits data from the 30 seconds before and after the malfunction to the server and synchronously records it in the SD card storage module 150. This allows maintenance personnel to remotely view the vehicle fault, improving troubleshooting efficiency. Furthermore, maintenance personnel can switch the program to a backup program via the server platform.

[0061] 4G Wireless Communication Module 140 Remote Wake-up Implementation Scheme: The 4G wireless communication module 140 remote wake-up can be used for remote vehicle control and OTA upgrades. When the controller is in sleep mode, the 4G module is continuously powered, and it sends a heartbeat message to the server every 3 minutes to prevent the wireless connection from being lost due to prolonged lack of data interaction. When the server wakes up the controller, it sends a message to the vehicle terminal through the server platform. The 4G module wakes up the vehicle terminal controller by pulling its wake-up pin high.

[0062] The fuel cell controller described in this application integrates VCU, BCM, and TBOX using the NXP-S32K324 as its core. The Flash storage module is divided into A / B zones to support OTA seamless upgrades and fault switching. The RAM storage module stores data in cores to ensure vehicle operation during upgrades. OTA is implemented via a 4G wireless communication module. The TBOX transmits SIM card and VIN login information. After server verification, tasks are sent and the TBOX downloads and flashes the data. When there are no tasks, GB32960 standard data is transmitted every 10 seconds and stored on the SD card. In case of a fault, 30 seconds of data before and after the fault are stored. The 4G is powered by constant power and sends heartbeat messages. The server can wake up the controller, ultimately reducing costs, improving performance, enhancing safety, and minimizing the need for on-site maintenance and upgrades.

[0063] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A fuel cell controller characterized by comprising: The application relates to a controller for a vehicle, which comprises the following parts: a main control chip for integrating vehicle control, body control and a vehicle terminal; a flash storage module for partitioning and storing program files required by a controller, and being divided into two independent storage areas; a RAM storage module for temporarily storing real-time data in a running process of the controller, and being divided into two independent areas respectively allocated to different cores of the main control chip; a 4G wireless communication module for establishing wireless connection between the controller and a remote server; an SD card storage module for backup storage of vehicle real-time running data, fault data and an OTA upgrade package.

2. The fuel cell controller of claim 1, wherein, The main control chip adopts an NXP-S32K324 dual-core chip, and comprises a first core and a second core; the first core is used for running related programs of a vehicle control unit and a body control unit; the second core is used for running related programs of a vehicle terminal.

3. The fuel cell controller of claim 1, wherein, The two independent storage areas of the flash storage module are A area and B area; when controller programs run in the A area, programs in the B area are refreshed in an OTA upgrade mode, and after the refreshing is completed, the programs are switched to run in the B area; when programs run in the B area, programs in the A area are refreshed in the OTA upgrade mode, and when programs in any area are abnormal, the programs can be automatically switched to another backup area.

4. The fuel cell controller of claim 1, wherein, The two independent areas of the RAM storage module are respectively allocated to the first core and the second core of the main control chip, and the area allocated to the first core is used for temporarily storing real-time data generated in a running process of a vehicle control unit and a body control unit, and the area allocated to the second core is used for temporarily storing real-time data generated in a running process of a vehicle terminal.

5. The fuel cell controller of claim 1, wherein, The 4G wireless communication module also supports a 4G remote wake-up function; when the controller is in a sleep state, the 4G wireless communication module is connected to a constant current, and a frame of heartbeat message is sent to a remote server every 3 minutes, so that wireless connection is avoided from being disconnected due to long-time no data interaction; when the server needs to wake up the controller, a wake-up message is sent to the 4G wireless communication module, and the 4G wireless communication module realizes wake-up of the controller by pulling up a wake-up pin.

6. The fuel cell controller of claim 1, wherein, When the vehicle has no OTA writing task, the SD card storage module synchronously records vehicle real-time information reported by the controller every 10 seconds; the vehicle real-time information comprises vehicle data, driving motor data, vehicle position, extreme value data and alarm data, and the data format follows a GB32960 protocol standard; when the vehicle has a fault, the SD card storage module is also used for storing 30 seconds of data before a fault and 30 seconds of data after the fault uploaded to the server by a vehicle terminal.

7. The fuel cell controller of claim 1, wherein, The vehicle terminal integrated by the main control chip supports data interaction with a remote server, can complete vehicle login, receive an OTA upgrade task, report vehicle state and fault data, and needs to upload a SIM card number and a vehicle unique identifier VIN to the server during vehicle login.

8. The fuel cell controller of claim 1, wherein, When the flash storage module receives an OTA upgrade package for writing, if an ECU type corresponding to the upgrade is the controller itself, the upgrade package data is directly written to a flash storage area of the controller. If the corresponding ECU type is upgraded to the rest of the vehicle components, the upgrade package is temporarily stored in the SD card storage module backup, and the upgrade package data is read from the SD card and written to the corresponding component Flash memory.

9. The fuel cell controller of claim 1, wherein, In the OTA upgrade process, the 4G wireless communication module assists the vehicle terminal in receiving the OTA upgrade task and upgrade strategy file issued by the remote server, and the vehicle terminal downloads the upgrade strategy file and upgrade package from the server based on the Http protocol through the 4G wireless communication module.

10. The fuel cell controller of claim 1, wherein, The fault data stored in the SD card storage module can be called by the remote server, and the vehicle remote diagnosis can be realized by checking the fault data through the server. When the program of a certain Flash storage area of the controller is abnormal, the controller can read the program from the backup data stored in the SD card storage module and switch to the backup program for running.

Images