CN118484212A

CN118484212A - Software flashing method and device of vehicle-mounted controller, electric vehicle and medium

Info

Publication number: CN118484212A
Application number: CN202410500589.5A
Authority: CN
Inventors: 李夫; 涂少波; 蒋湘鹏
Original assignee: Chongqing Selis Phoenix Intelligent Innovation Technology Co ltd
Current assignee: Chongqing Selis Phoenix Intelligent Innovation Technology Co ltd
Priority date: 2024-04-24
Filing date: 2024-04-24
Publication date: 2024-08-13

Abstract

The application relates to a software flashing method and device of a vehicle-mounted controller, an electric vehicle and a medium. The method comprises the following steps: acquiring identity information and refreshing information of a vehicle-mounted controller to be refreshed; determining a written brushing program for the vehicle-mounted controller based on the identity information; inputting the refreshing information into a refreshing program to perform software refreshing processing on a software program in the vehicle-mounted controller at least once to obtain the vehicle-mounted controller after the refreshing processing; the software refreshing process comprises a pre-programming stage, a main programming stage and a post-programming stage; the pre-programming stage is used for carrying out network preparation processing on the vehicle-mounted controller, the main programming stage is used for carrying out data refreshing processing on the vehicle-mounted controller, and the post-programming stage is used for carrying out resetting processing on the vehicle-mounted controller. The method utilizes the software program to be written by the writing program, can effectively reduce the production cost, improves the efficiency and the accuracy of writing the software into the vehicle-mounted controller, and is beneficial to development and application of electric vehicles.

Description

Software flashing method and device of vehicle-mounted controller, electric vehicle and medium

Technical Field

The present application relates to the field of vehicle-mounted controllers, and in particular, to a software flashing method of a vehicle-mounted controller, a software flashing device of a vehicle-mounted controller, an electric vehicle, a computer readable storage medium, and a computer program product.

Background

With the development of automotive electronics, vehicle-mounted ECU is widely used in automobiles. The ECU is composed of a Microprocessor (MCU), a memory (ROM, RAM), an input/output interface (I/O), an analog-to-digital converter (a/D), and large-scale integrated circuits such as shaping and driving. The ECU performs a jump in function by reading the data at run-time. When the automobile manufacturer updates the ECU data of the automobile type, the software program in the ECU is required to be written, and the updated data is written into the ECU to realize the upgrading.

At present, a software program in the ECU is generally stored in a FLASH (FLASH memory), and if an existing ECU software refreshing method is adopted, an operator needs to open a shell of the ECU and brush the shell in a J-LINK mode, so that the actual operation is very inconvenient. Or writing the brush-written code by adopting CANOE CAPL matched with PANEL, but the development tool of VECTOR company is required to be used, which not only leads to the increase of the development cost of the whole vehicle, but also informs the VECTOR company of the development requirement of the user, and does not accord with the confidentiality of the software refreshing specification of a host factory.

Disclosure of Invention

In view of the foregoing, the present disclosure provides a software flashing method of an in-vehicle controller, a software flashing device of an in-vehicle controller, an electric vehicle, a computer-readable storage medium, and a computer program product. The technical scheme of the present disclosure is as follows:

According to a first aspect of an embodiment of the present disclosure, there is provided a software flashing method of an in-vehicle controller, including:

Acquiring identity information and refreshing information of a vehicle-mounted controller to be refreshed;

determining a written brushing program for the vehicle-mounted controller based on the identity information;

inputting the refreshing information into the refreshing program to perform software refreshing processing on the software program in the vehicle-mounted controller at least once to obtain a vehicle-mounted controller after the refreshing processing;

The software refreshing processing comprises a pre-programming stage, a main programming stage and a post-programming stage;

The pre-programming stage is used for carrying out network preparation processing on the vehicle-mounted controller, the main programming stage is used for carrying out data refreshing processing on the vehicle-mounted controller, and the post-programming stage is used for carrying out resetting processing on the vehicle-mounted controller.

In an exemplary embodiment, the swipe information includes a physical address ID and a functional address ID for the in-vehicle controller;

the network preparation processing for the vehicle-mounted controller comprises the following steps:

requesting to enter an extended session mode for the vehicle-mounted controller based on the physical addressing ID and the functional addressing ID;

Based on the physical addressing ID, acquiring a security verification algorithm file aiming at the vehicle-mounted controller so as to acquire a first type security access right to the vehicle-mounted controller based on the security verification algorithm file;

under the condition of acquiring the first type of security access rights, detecting the brushing condition of the vehicle-mounted controller;

and under the condition that the detection of the brushing condition is passed, performing diagnostic fault code control on the vehicle-mounted controller to prohibit the vehicle-mounted controller from recording the diagnostic fault code, and performing communication control on the vehicle-mounted controller to prohibit the vehicle-mounted controller from sending and receiving non-diagnostic message information.

In an exemplary embodiment, the data writing process for the vehicle-mounted controller includes:

requesting entry into a programming session mode for the in-vehicle controller based on the physical addressing ID;

Based on the security verification algorithm file, obtaining a second type of security access right to the vehicle-mounted controller;

based on the physical addressing ID, FLASH DRIVER files aiming at the vehicle-mounted controller are obtained, and logic data in the FLASH DRIVER files are downloaded to the vehicle-mounted controller;

under the condition that the logic data is detected to be matched with the vehicle-mounted controller, acquiring a software refreshing file aiming at the vehicle-mounted controller, and downloading the logic data in the software refreshing file to the vehicle-mounted controller so as to refresh the software program to obtain a refreshed software program;

and based on the physical addressing ID, carrying out compatibility detection on the software program after the writing, and setting the software program after the writing to a valid state under the condition that the compatibility detection is passed.

In an exemplary embodiment, the resetting the on-board controller includes:

Based on the function addressing ID, carrying out communication control on the vehicle-mounted controller so as to start the vehicle-mounted controller to send and receive non-diagnostic message information;

Restarting the vehicle-mounted controller based on the physical addressing ID so that the vehicle-mounted controller jumps to the software program after the restarting;

based on the physical addressing ID, performing diagnosis fault code control on the vehicle-mounted controller so as to start the vehicle-mounted controller to record diagnosis fault codes;

based on the functional addressing ID, a switch from a programming session mode for the onboard controllers to a default session mode is requested.

In an exemplary embodiment, the obtaining the identity information and the brushing information of the vehicle-mounted controller to be brushed includes:

Responding to a user to select a target vehicle-mounted controller to be refreshed in a user interface, and acquiring identity information of the target vehicle-mounted controller;

Displaying a brushing type option box and an addressing ID input box aiming at the target vehicle-mounted controller in the user interface so as to acquire the selected target brushing type aiming at the target vehicle-mounted controller by the user, and the input physical addressing ID and functional addressing ID;

Wherein the target flush type includes a single flush type for single flushing the software program or a loop flush type for multiple flushing the software program.

In an exemplary embodiment, the software program in the vehicle-mounted controller is subjected to at least one software flashing process, including:

If the target flush type is a single flush type, performing one-time version upgrading or version rollback on the software program based on the flush program;

and under the condition that the target writing type is a cyclic writing type, acquiring the cyclic times input by the user, and carrying out version upgrading and version rollback on the cyclic times on the software program based on the writing program.

In an exemplary embodiment, the method further comprises:

in the process of performing software refreshing processing on the software program, acquiring message request information and message response information of each message correspondingly generated, and storing the message request information and the message response information in a log file based on a preset function; and

And before the data refreshing processing is carried out on the vehicle-mounted controller, acquiring first version number information of the software program, after the data refreshing processing is carried out on the vehicle-mounted controller, acquiring second version number information of the software program, and storing the first version number information and the second version number information in a log file.

According to a second aspect of the embodiments of the present disclosure, there is provided a software flashing device of an in-vehicle controller, including:

The information acquisition module is used for acquiring the identity information and the refreshing information of the vehicle-mounted controller to be refreshed;

the brushing program module is used for determining a brushing program written for the vehicle-mounted controller based on the identity information;

the software refreshing module is used for inputting the refreshing information into the refreshing program so as to perform software refreshing processing on the software program in the vehicle-mounted controller at least once to obtain a vehicle-mounted controller after the refreshing processing;

According to a third aspect of the embodiments of the present disclosure, there is provided an electric vehicle including:

The system comprises a processor and a memory connected with the processor, wherein the memory stores program data, and the processor is used for calling the program data stored in the memory so as to realize the software flashing method of the vehicle-mounted controller.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium including therein program data which, when executed by a processor of a computer device, enables the computer device to perform a software flashing method of an in-vehicle controller as described in any of the above.

According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product comprising program instructions therein, which when executed by a processor of a computer device, enable the computer device to perform a software flashing method of an in-vehicle controller as described in any of the above.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

On one hand, the method determines the written refreshing program aiming at the vehicle-mounted controller through the identity information of the vehicle-mounted controller to be refreshed, and then performs at least one software refreshing treatment on the software program in the vehicle-mounted controller based on the refreshing program to obtain the vehicle-mounted controller after the refreshing treatment, so that the software refreshing flow of the vehicle-mounted controller is optimized, the software refreshing efficiency is effectively improved, and the consumption of manpower and material resources is reduced; on the other hand, the scheme is different from the existing software refreshing mode, the refreshing information of the vehicle-mounted controller to be refreshed is input into the refreshing program, the software refreshing process is carried out on the software program at least once through the refreshing program, the vehicle-mounted controller can be sequentially subjected to network preparation process, data refreshing process and reset process, and the final vehicle-mounted controller after refreshing process is obtained, so that the refreshing program can be utilized to refresh the software program, the production cost of enterprises is effectively reduced, the efficiency and the accuracy of carrying out software refreshing on the vehicle-mounted controller are improved, and development and application of electric vehicles are facilitated.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the related art, the drawings that are needed in the description of the embodiments of the present application or the related technologies will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and other related drawings may be obtained according to these drawings without inventive effort to those of ordinary skill in the art.

Fig. 1 is an application environment diagram illustrating a software flashing method of an in-vehicle controller according to an exemplary embodiment.

Fig. 2 is a flowchart illustrating a software flashing method of an in-vehicle controller according to an exemplary embodiment.

FIG. 3 is a flowchart illustrating another software flashing method of an onboard controller, according to an exemplary embodiment.

FIG. 4 is a block diagram illustrating steps of a pre-programming phase with respect to a software flashing process, according to an exemplary embodiment.

FIG. 5 is a block diagram illustrating the steps of a main programming phase with respect to a software flashing process, according to an exemplary embodiment.

FIG. 6 is a block diagram illustrating steps of a post-programming phase with respect to a software flashing process, according to an exemplary embodiment.

Fig. 7 is a block diagram showing a software flashing apparatus of an in-vehicle controller according to an exemplary embodiment.

FIG. 8 is a block diagram of an electric vehicle for on-board controller software flashing, according to an example embodiment.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

The term "and/or" in embodiments of the present application is meant to include any and all possible combinations of one or more of the associated listed items. Also described are: as used in this specification, the terms "comprises/comprising" and/or "includes" specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, and/or components, and/or groups thereof.

The terms "first," "second," and the like in this disclosure are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus.

In addition, although the terms "first," "second," etc. may be used several times in the present application to describe various operations (or various elements or various applications or various instructions or various data) etc., these operations (or elements or applications or instructions or data) should not be limited by these terms. These terms are only used to distinguish one operation (or element or application or instruction or data) from another operation (or element or application or instruction or data).

The software refreshing method of the vehicle-mounted controller provided by the embodiment of the application can be applied to an application environment shown in fig. 1. Wherein the terminal 102 communicates with the server 104 via a communication network. The data storage system may store data that the server 104 needs to process. The data storage system may be integrated on the server 104 or may be located on a cloud or other network server.

In some embodiments, referring to fig. 1, the server 104 obtains identity information and swipe information of an on-board controller to be swiped; determining a written brushing program for the vehicle-mounted controller based on the identity information; inputting the refreshing information into a refreshing program to perform software refreshing processing on a software program in the vehicle-mounted controller at least once to obtain the vehicle-mounted controller after the refreshing processing; the software refreshing process comprises a pre-programming stage, a main programming stage and a post-programming stage; the pre-programming stage is used for carrying out network preparation processing on the vehicle-mounted controller, the main programming stage is used for carrying out data refreshing processing on the vehicle-mounted controller, and the post-programming stage is used for carrying out resetting processing on the vehicle-mounted controller.

In some embodiments, the terminal 102 (e.g., mobile terminal, fixed terminal) may be implemented in various forms. The terminal 102 may be a mobile terminal including a mobile terminal such as a mobile phone, a smart phone, a notebook computer, a portable handheld device, a Personal Digital Assistant (PDA), a tablet Personal computer (PAD), etc., and the terminal 102 may also be a fixed terminal of an Automated teller machine (Automated TELLER MACHINE, ATM), an automatic all-in-one machine, a digital TV, a desktop computer, a stationary computer, etc.

In the following, it is assumed that the terminal 102 is a fixed terminal. However, those skilled in the art will appreciate that the configuration according to the disclosed embodiments of the present application can also be applied to a mobile type terminal 102 if there are operations or elements specifically for the purpose of movement.

In some embodiments, the data processing components running on server 104 may load any of a variety of additional server applications and/or middle tier applications being executed, including, for example, HTTP (hypertext transfer protocol), FTP (file transfer protocol), CGI (common gateway interface), RDBMS (relational database management system), and the like.

In some embodiments, the server 104 may be implemented as a stand-alone server or as a cluster of servers. The server 104 may be adapted to run one or more application services or software components that provide the terminal 102 described in the foregoing disclosure.

In some embodiments, the operating systems on which the application services or software components run may include various versions of Microsoft Windows, apple Macintosh, and/or Linux operating systems, various commercial or UNIX-like operating systems (including but not limited to various GNU/Linux operating systems, google Chrome OS, etc.), and/or mobile operating systems, such as iOS, windows Phone, android, OS, blackBerry, palm OS operating systems, and other online or offline operating systems, without specific limitation herein.

The software flashing method of the vehicle-mounted controller disclosed by the application can be applied to a software flashing system, wherein the software flashing system comprises an automobile development tool, hardware equipment and the vehicle-mounted controller. The automobile development tool may be VEHICLE SPY, for example. The automobile development tool integrates the functions of diagnosis, node/ECU (Electronic Control Unit) simulation, data acquisition, automatic test, in-car communication network monitoring and the like, and can communicate with various vehicle-mounted ECUs through connecting hardware equipment (such as diagnosis equipment), for example, the diagnosis equipment sends and receives various UDS messages with the vehicle-mounted ECUs based on UDS diagnosis service so as to communicate with both sides.

In some embodiments, the automotive development tool includes a hardware connection Function (SetUp-HardWare), a message view page (Spy Networks-Messages), an image panel (measure-GRAPHICAL PANELS), a reuse software module (Function Block), data variables (Application Signal), and a c-code interface (C Code lnterface).

The Function Block can run engineers to configure corresponding scripts and automatically execute the scripts so as to complete tasks of automatic execution.

Wherein the hardware connection function is used for connecting the automobile development tool with a hardware device (such as a gateway device).

The graphical interface is a user interface or a graphical interface in an automobile development tool, which allows engineers to customize the user interface, supporting adding a plurality of different types of tools, such as charts (graphs), bar-graphs, send buttons (transmitbuttons), drop-down menus (dropdowns), test buttons (test buttons), meters (meters), handles (knobs), displays (LEDs/lights), text displays (numericentrybox), and the like. Each tool can be resized and placed on the faceplate as desired. A set of tools and their test buttons may be selected and set in alignment. After the display is set, the panel may be locked to prevent tool position changes due to mouse movement. Engineers may create a collection of some graphical panels and distribute them to other people.

Wherein Application Signal is used to store variables that can hold values set by the user or that do not have to infer a computed signal from the network message. For example, a signal is created whose value changes with the function generator when it is associated with the function generator.

Wherein the c-code interface (C Code lnterface) provides a way to communicate with a communication protocol operated by the automotive development tool using the c-code. The use of the C code in the automotive development tool can reuse all of the functionality of the automotive development tool, such as: message decoding, message acceptance, database decoding, signal display, buffer capture, etc., the c-code interface supports event and process type based programming.

In one embodiment, the software flashing system may execute the following steps to perform the functions of the vehicle development tool of the present application, as follows:

step one: signal variables are added in Application Signal functions, and the added variables are transmitted to codes in the C Code Interface as variables selected by a user in a system Interface, such as variables representing a start signal, a load, a file storage path brushing, and the like.

Step two: adding the signal variable in the first step into a C Code Interface-Edit-EVENT HANDLER Code, and then generating a C Code function variable and an Interface of a corresponding message by the C Code Interface, so that an engineer can control the input and the output of the corresponding variable by calling the interfaces in a C Code; the generated information responds to the button management of the function interface and the image interface, and when an engineer clicks the button of the image interface, the function interface in the corresponding C code is executed to realize logic expected by the engineer.

Step three: in GRAPHICAL PANELS, various buttons required for realizing the functions of the automobile development tool are added, and the buttons are associated with corresponding signal messages and signal variables in the attribute setting function-signal function of each button so as to realize the functions of controlling the whole automobile development tool and the output functions in the display program.

In some embodiments, the implementation of the functions of the automobile development tool is as follows:

FLASH TYPE button: adding a Drop Down List button, and adding two Drop-Down options on its property page: a single swipe and a cyclic swipe, and associated with a signal variable FLASH TYPE, this information generates a C-language variable in CCodeInterface and changes its value as the button selects a different type of swipe, thereby changing the program's execution logic. If the single-time writing is selected, the writing program is run once; if a loop brush is selected, the brush program is run LoopTimes times.

Loop Times button: a Text Entry button is added and a signal variable LoopTimes is associated with its properties page, and the value of this c-variable is automatically changed at CCodeInterface when the user enters a number.

Flash Ecu button: and adding a Drop Down List button, adding a plurality of options on the attribute page of the Drop Down List button, respectively for different ECU ids, and associating a signal variable, wherein the variable automatically changes the value of the variable in CCodeInterface to the corresponding value along with the selection of different ECUs by a user, and the program judges the value and then selects the corresponding upgrading program to execute. The button can realize the upgrade and brushing functions of supporting multiple ECUs, and the application prospect is wider.

The Success times button, FALI TIMES button: two Text Entry buttons are added respectively and two variables which are successfully and unsuccessfully written in CCodeInterface are associated respectively, and the variables are automatically displayed on a software interface for a user to observe along with the change of the values of the two variables.

Version log file button: a Text Entry button is added and a path file variable is associated, and when a user inputs a path saved in the log, the value of the path variable is automatically changed in CCodeInterface for the fopen () function to call, so that the log file is saved to the corresponding folder.

Start button: an on off button control program is added to run.

Reprogramming status button: a Led is added and associated with a flush success/failure variable, which indicates a red light when the flush is successful as a green light indication.

In one embodiment, before executing the software flashing method of the in-vehicle controller disclosed in the present application, the software flashing system may complete development work based on an automobile development tool (e.g., VEHICLE SPY) to support the operation of the software flashing method of the in-vehicle controller.

In some embodiments, the software flashing system may create a message format of the UDS message to be sent and received based on the automotive development tool, and add a send interface and an accept interface for sending and receiving the UDS message in each day through the message Editor function on the tool, so that the diagnostic device/onboard ECU may send out the UDS message in a specific message format through the send interface, and receive the UDS message in a specific message format through the receive interface.

In some embodiments, the software flashing system may set a diagnostic request ID for each UDS message to be sent based on the Function Blocks Function in the automotive development tool; and setting a response ID value for each UDS message to be received.

In some embodiments, the software flashing system may add signal variables based on Application Signal functions in the automobile development tool, which will be used as variables to transmit the user selected values in the system interface to the code, such as file path, start signal, etc. in CCodeInterface

In some embodiments, the software flashing system may add various buttons needed to implement the functions of the system based on a system interface built in the automobile development tool, and associate the buttons with corresponding signal messages and signal variables in the attribute setup function-signal function of each button to realize the functions of the button control whole system and output functions in the display program.

In some embodiments, the software flashing system may add the set message information to the C Code Interface-Edit-EVENT HANDLER Code based on the car development tool, where the C Code Interface will generate a C Code function Interface of the corresponding message, and the engineer may send the message to the UDS of the corresponding service by calling these interfaces in the C Code, and generate button management of the information response function Interface and the image Interface. When the engineer clicks a button of the image interface, the function interface in the corresponding C code will execute to implement the logic desired by the engineer.

In some embodiments, the software flashing system may write a diagnostic self-upgrade program, i.e., a flashing program, for each ECU based on the C Code Interface in the automotive development tool. The engineer can click Open Project In Visual Studio in the system interface to open project engineering, automatically generate C code engineering and support file interacting with VEHICLE SPY3, automatically find API function of data block message, UDS message and signal, related application signal environment variable, etc., and improve development efficiency.

The diagnostic self-upgrading program has a single-time brushing function and an on-hook circulating brushing function, namely an engineer can set the brushing type of the diagnostic self-upgrading program. Under the condition that the type of the refreshing is a single refreshing type, namely, the diagnosis self-upgrading program applies a single refreshing function, so that the diagnosis self-upgrading program can carry out one-time version upgrading or version rollback on the software program; when the refreshing type is a cycle refreshing type, namely the diagnosis self-upgrading program applies a hang-up cycle refreshing function, so that the diagnosis self-upgrading program can be realized based on single refreshing, and is used for repeatedly carrying out a large number of version upgrading and version rollback processing on the software program to be released so as to verify whether the software version is abnormal during upgrading/rollback, and after the software version is tested to be abnormal, the software program to be released is released to a user for upgrading.

In an embodiment, after the self-upgrading program is diagnosed to apply the on-hook circulation refreshing function, the software refreshing system can also retest the upgrade success rate index, namely calculate the quotient between the successful upgrade times and the total on-hook circulation refreshing times to obtain the version stability of the software program to be released, so that the abnormal condition of the software version during upgrade/rollback can be verified according to the version stability of the software program to be released, and the software version can be readjusted or released to the user for upgrade according to the abnormal condition of the software version.

In some embodiments, the diagnostic device connected to the automobile development tool may automatically capture each received message and may enter the void spy_ EVERY MESSAGE (GENERIC MESSAGE ×p_msg) function in the C Code Interface, so that the request message and the received message response information sent by the diagnostic device or the onboard ECU may be obtained from the function, and the response of the specified message may be received by determining the ID and the data bit of the p_msg variable in the message and fed back to the software Interface and the log.

In an embodiment, the protocol by which the diagnostic device communicates with the onboard ECU during the ECU swiping is the UDS protocol. The server can control the diagnosis device and the vehicle-mounted ECU to send/receive different UDS messages and receive corresponding message response information based on a pre-added message format and a function API Interface in a C Code Interface.

Taking the conversation mode of switching the vehicle-mounted controller as a default conversation as an example, the diagnosis equipment sends a request message to the vehicle-mounted ECU and waits for the response of the vehicle-mounted ECU to the message. The flow for sending the message and receiving the corresponding response is realized in the system as follows:

① Based on the Messages Editor function in the automobile development tool, a request message and a response message are added, which are named as follows: diagnosticSessionControl _ defaultDiagnosticSession and process for preparing the same DiagnosticSessionControl _ defaultDiagnosticSession _PR.

② The function API of the message is added into the C Code Interface to automatically generate a corresponding data structure body to represent the message information of the message, and simultaneously generate a message sending API expressed as: TX_ DiagnosticSessionControl _ defaultDiagnosticSession _DW/u can_08_transmitfast.

③ And calling the API at the corresponding position of the refreshing flow to successfully send the message, and screening out the response information of the message from the response message.

The software flashing system can update, rollback and version test related to the flashing of the software program for different types of vehicle-mounted controllers based on the vehicle development tool. Therefore, in the first aspect, the method not only can upgrade the version of the vehicle-mounted controller through the UDS protocol, but also can test the version stability of the software program to be issued based on the on-hook circulation function of the flashing program, and can ensure that the version stability of the software program to be issued meets the requirement, and then the software program is distributed to the user for software upgrade, thereby ensuring the user experience; in a second aspect, diagnostic self-upgrade flushing of the onboard controllers may be implemented, providing engineers with more choices of flushing programs, reducing the degree of reliance on specific devices (e.g., CANOE); in a third aspect, executable files for a brusher may be generated for convenient execution on different devices; in the fourth aspect, protocols commonly used in a series of automobile development such as CAN, UDS and the like CAN be supported, and various hardware devices thereof are supported to be connected with various common ECU communication interfaces, so that an automobile development engineer CAN be facilitated to develop more functions.

In some embodiments, as shown in fig. 2 and 3, fig. 2 is a flowchart of an embodiment of a software flashing method for an in-vehicle controller according to the present application, and fig. 3 is a flowchart of another embodiment of a software flashing method for an in-vehicle controller according to the present application, where the method is applied to the server 104 in fig. 1, and the method includes the following steps:

step S11: and acquiring the identity information and the refreshing information of the vehicle-mounted controller to be refreshed.

The vehicle-mounted controller is a vehicle-mounted ECU to be subjected to software refreshing. In the development of the vehicle software, the server may use the flashing tool to send data information to the vehicle-mounted ECU via the ECU communication network (e.g., CAN bus) based on a certain protocol (e.g., UDS protocol), so as to update the software program in the vehicle-mounted ECU, for example, upgrade the program version of the vehicle-mounted ECU, solve the fault or diagnosis problem, and so on.

In some embodiments, the onboard ECU is a key component responsible for managing and controlling the various systems of the vehicle, such as an engine control unit, a brake system control unit, an air conditioning control unit, and the like. These vehicle-mounted ECUs store software programs for running various functions of the vehicle. Wherein the ECU brush may be used to update software programs in the vehicle ECU to repair bugs, improve performance, increase fuel efficiency, add functionality, etc. The brushing process is typically performed using a specialized brushing tool or device through a diagnostic interface connected to the vehicle. In the process of the refreshing, a new software program is loaded into the ECU to replace the original program.

In some embodiments, the UDS protocol, unified Diagnostic Services protocol, is an application layer protocol, which is defined in the ISO 14229-1 standard for diagnosis and servicing of vehicles. The UDS protocol includes a series of standardized diagnostic services such as reading trouble codes, erasing trouble codes, reading data, writing data, etc. Communication of the brushing tool in the ECU brushing with the onboard ECU relies on these standardized diagnostic services.

In some embodiments, the process of the server obtaining the identity information and the flashing information of the vehicle-mounted controller may be implemented based on the following manner:

Step one: and responding to the user to select the target vehicle-mounted controller to be refreshed in the user interface, and acquiring the identity information of the target vehicle-mounted controller.

Specifically, the user can select the types of all the vehicle-mounted controllers supported by the system through a drop-down list in the user interface, wherein the system allocates a controller id for each supported vehicle-mounted controller, and after the user selects the target vehicle-mounted controller, the corresponding identity information of the target vehicle-mounted controller can be determined according to the controller ids of the target vehicle-mounted controller.

Step two: a swipe type option box and an address ID input box for the target in-vehicle controller are presented in the user interface to obtain the selected target swipe type for the target in-vehicle controller by the user, and the input physical address ID and functional address ID.

The target flush type includes a single flush type for performing a single flush on the software program or a loop flush type for performing multiple flushes on the software program.

In some embodiments, when the target refresh type selected by the user for the target vehicle-mounted controller is a cycle refresh type, a corresponding cycle number input box is also required to be displayed in the user interface to obtain the cycle number input by the user. Wherein each round robin refresh is defined as one software version upgrade and one software version rollback.

In some embodiments, the physical addressing ID refers to a unique number in the system that is used to identify the onboard controllers, which may be a hardware address or physical location information of the onboard controllers; the function addressing ID is a logical number in the system for identifying the in-vehicle controller, which may be function or use information of the in-vehicle controller.

Step S12: based on the identity information, a written brush program for the on-board controller is determined.

Specifically, after the user selects the target vehicle-mounted controller, the server may determine the corresponding identity information according to the controller id of the target vehicle-mounted controller, and then determine, according to the identity information, the written and completed flashing program pre-associated with the vehicle-mounted controller.

In one embodiment, each of the brushstrokes corresponds to a secure authentication algorithm and software brushstroke file associated with which the user has previously selected.

The security verification algorithm is used for enabling the server to enter a corresponding security level in the UDS service, and each different vehicle-mounted controller user can select a different security verification algorithm for the server. The server can open the file manager by controlling the flashing program to extract the security authentication algorithm that the user has previously selected for it to perform the corresponding security authentication job.

Wherein the software flashing files include app files and FLASH DRIVER files of the version to be flashed, and each different on-board controller user can select a different software flashing file for it. The server can open the file manager by controlling the flashing program to extract the app file and FLASH DRIVER file selected by the user in advance for it to perform the corresponding software flashing work.

In some embodiments, the app file and FLASH DRIVER file are hex files, and the server may parse the hex file selected by the user according to the file format and input the parsed data into the flash program for use. When the type of the in-vehicle controller is a cyclic type of the swipe, the server needs to select two different versions of app files for upgrade and rollback swipe.

Step S13: and inputting the refreshing information into a refreshing program to perform software refreshing processing on the software program in the vehicle-mounted controller at least once, so as to obtain the vehicle-mounted controller after the refreshing processing.

Wherein the software flashing program is developed based on the UDS protocol and can perform self-upgrading software flashing processing of the UDS, and the software flashing processing comprises a pre-programming stage, a main programming stage and a post-programming stage.

In one embodiment, the pre-programming stage is used for performing network preparation processing on the vehicle-mounted controller, which specifically includes waking up the vehicle-mounted controller, detecting a brushing condition, managing communication, and the like.

In one embodiment, the main programming stage is used for performing data refreshing processing on the vehicle-mounted controller, and specifically includes unlocking the vehicle-mounted controller with a specific security level, writing fingerprint information, downloading software and data, and the like.

In one embodiment, the post-programming stage is used to perform a reset process on the vehicle controller, which specifically includes resetting the vehicle controller or switching the session mode back to the default session mode.

In some embodiments, the server may implement a single swipe and an on-hook cycle swipe for different types of in-vehicle controllers, i.e., after the user selects the model of the target in-vehicle controller, the server will run the upgrade code (i.e., the swipe program) for the corresponding in-vehicle controller.

In one embodiment, the server performs at least one software flashing process on a software program in the in-vehicle controller, including: in the case that the target flush type is a single flush type, the software program is subjected to one-time version upgrade or version rollback based on the flush program.

In another embodiment, the server performs at least one software flashing process on a software program in the in-vehicle controller, including: and under the condition that the target writing type is the circulation writing type, acquiring the circulation times input by a user, and carrying out version upgrading and version rollback on the circulation times of the software program based on the writing program.

When the target refreshing type is a circulating refreshing type, the function is realized based on single refreshing, and is used for repeatedly carrying out a large number of version upgrading and version rollback processing when a new version software program is released, so as to verify whether the released software version is abnormal during upgrading/rollback, and then is released to a user for upgrading after testing whether the released software version is abnormal.

When the user inputs the expected circulation times, the software program with corresponding times is automatically executed by the refreshing program, the result of each refreshing is recorded and displayed on the software interface, and a log of key logic is saved so as to search the reason of the refreshing failure through the log. Two progress bars are created in the user interface for the progress of the single swipe and the number of whole cycles to intuitively display the current swipe progress for the user.

In one embodiment, in the process of software flashing, the response information of the key steps in the message and the status code information of the error negative response are stored in the log file, so that the cause of the flashing abnormality can be conveniently searched and tracked. The server may also configure both the message log and the version log to store both information separately.

Specifically, the server further includes obtaining message request information and message response information of each message correspondingly generated in the process of performing software refreshing processing on the software program, and storing the message request information and the message response information in the log file based on a preset function. For example, for the message log portion, the server saves the request information and response information for each UDS message and saves these message information to the log file using an fwrite function when sending and receiving UDS messages.

In an embodiment, when the server tests the flushing, in order to track whether the flushing is successful or not and the error reasons of the flushing failure, the message log and the versions before and after the flushing can be saved, namely, when the server upgrades or backs the flushing to the soft-shell program each time, the state information of the message generated at the key logic in the flushing process is printed in the display area and saved in the log system, after each flushing, the successful or failed count is updated, the version information before and after the flushing is recorded in the log system, and the progress bar is always synchronized.

Specifically, the server further includes acquiring first version number information of the software program before the data refreshing process is performed on the vehicle-mounted controller, acquiring second version number information of the software program after the data refreshing process is performed on the vehicle-mounted controller, and then storing the first version number information and the second version number information in the log file. For example, for the version log portion, the server reads the version number information of the software program once by each request before and after the software program is written, and saves it in the log file.

In the disclosed embodiment of the application, the server can carry out the update, the update rollback and the version test on the software program on different types of vehicle-mounted controllers based on the software update mode of the vehicle-mounted controllers. Thus, in the first aspect, the server can implement diagnostic self-upgrade flushing of the vehicle-mounted controller, providing more flushing program choices for engineers, and reducing the dependency on specific devices (e.g., CANOE); in a second aspect, a server may generate an executable file for a brusher to be conveniently executed on a different device; in the third aspect, the server may support a protocol commonly used in a series of automobile development such as CAN, UDS, etc., and various hardware devices thereof support connection with various common ECU communication interfaces, so that it may be convenient for an automobile development engineer to develop more functions.

In the process of software refreshing of the vehicle-mounted controller, on one hand, the scheme determines the refreshing program written for the vehicle-mounted controller through the identity information of the vehicle-mounted controller to be refreshed, and then performs software refreshing processing on the software program in the vehicle-mounted controller at least once based on the refreshing program to obtain the vehicle-mounted controller after the refreshing processing, so that the software refreshing flow of the vehicle-mounted controller is optimized, the software refreshing efficiency is effectively improved, and the consumption of manpower and material resources is reduced; on the other hand, the scheme is different from the existing software refreshing mode, the refreshing information of the vehicle-mounted controller to be refreshed is input into the refreshing program, the software refreshing process is carried out on the software program at least once through the refreshing program, the vehicle-mounted controller can be sequentially subjected to network preparation process, data refreshing process and reset process, and the final vehicle-mounted controller after refreshing process is obtained, so that the refreshing program can be utilized to refresh the software program, the production cost of enterprises is effectively reduced, the efficiency and the accuracy of carrying out software refreshing on the vehicle-mounted controller are improved, and development and application of electric vehicles are facilitated.

It will be appreciated by those skilled in the art that in the above-described methods of the embodiments, the disclosed methods may be implemented in a more specific manner. For example, the embodiment in which the server described above inputs the flush information into the flush program to perform the software flush process at least once on the software program in the in-vehicle controller, resulting in the in-vehicle controller after the flush process is merely illustrative.

In an exemplary embodiment, referring to fig. 4, fig. 4 is a flow chart illustrating an embodiment of a pre-programming stage of a software flashing process according to the present application. In step S13, that is, a process of performing network preparation processing on the vehicle-mounted controller by the server, specifically includes the following steps:

step one: based on the physical addressing ID and the functional addressing ID, an extended session mode for the vehicle-mounted controller is requested to be entered.

Specifically, as shown in the figure, the server first requests entry into a default session mode for the in-vehicle controller by physical addressing ID based on UDS diagnostic service, its service code being "10 01"; then, through physical addressing ID, DID data of the vehicle-mounted controller are read, wherein the DID data comprise information of part number 0xF187, version number F189 and the like, and the service code is '2 xXX'; then, the vehicle-mounted controller requests to enter an expanding session (whole vehicle) mode by the function addressing ID, and the service code of the vehicle-mounted controller is 10/83.

Step two: based on the physical addressing ID, a security verification algorithm file for the vehicle-mounted controller is obtained, so that a first type of security access right for the vehicle-mounted controller is obtained based on the security verification algorithm file.

In an embodiment, in the swiping procedure, for safety reasons, the server needs to verify the security keys of the diagnostic device and the vehicle-mounted controller through the security verification algorithm file before unlocking the first type of security access authority of the diagnostic device to the vehicle-mounted controller, so that the diagnostic device can swipe the vehicle-mounted controller according to the corresponding security level.

Specifically, the server first controls the diagnostic device to request "Seed" to the in-vehicle controller by the physical address ID based on the UDS diagnostic service, the service code of which is "27 01"; then controlling the diagnosis equipment to obtain a Seed returned randomly by the vehicle-mounted controller through physical addressing ID, wherein the service code is 67 01 4c b5 6c 9c; then, the control diagnosis equipment calculates a corresponding Key Key based on the Seed and sends the Key Key to the vehicle-mounted controller, and the service code of the Key Key is 27 02 f0 95 51 dd; and finally, comparing the Key Key calculated by the vehicle-mounted controller with the Key Key calculated by the diagnosis equipment, and unlocking the first type of safety access authority of the diagnosis equipment to the vehicle-mounted controller if the comparison is consistent, otherwise, unlocking is unsuccessful, and the service code is 67 02.

In one embodiment, the manner in which the "Seed" is requested and the "Key Key" is calculated and compared is a secure access control manner. The Seed is a randomly generated challenge code used for initiating a verification request to the vehicle-mounted controller. Key is a correct response to the Seed, and the correct Key can be generated and returned only after the in-vehicle controller correctly verifies the Seed. The Seed-Key mechanism can ensure that only authorized users or devices can access and execute specific security operations, and improves the security and protection capability of the system. The matching process of Seed and Key is typically implemented by a specialized encryption algorithm (e.g., algorithm Key) and security protocol (e.g., UDS protocol).

The server stores keys of security verification algorithms for various vehicle-mounted controllers in a file manager in a dll file mode in a dynamic link library in advance, and when unlocking is needed, the server calls out corresponding security verification algorithm files based on a physical addressing ID to verify.

In one embodiment, the flow of the store and call of the dll file is as follows: ① The user selects a corresponding dll file from the opened file manager, and the path of the dll file is saved into the dll file path through a dll file path reading function; ② The secure verification algorithm in the dll file is loaded by calling a LoadLibrary () function through the dll file path reading function; ③ Invoking UDS service to obtain seeds, and taking the seeds as the parameters of a security verification algorithm to calculate to obtain keys; ④ And calling the UDS service to send a key, and unlocking the first type of security access authority of the diagnosis equipment to the vehicle-mounted controller under the condition that verification is passed.

Step three: and under the condition of acquiring the first type of security access rights, detecting the brushing condition of the vehicle-mounted controller.

Specifically, the server first controls the diagnostic device to request routine services from the in-vehicle controller through the physical address ID based on the UDS diagnostic service to check whether the in-vehicle controller satisfies the flush condition, the service code of which is "$31 01 02 03"; and then after the detection of the brushing condition is passed, controlling the vehicle-mounted controller to set a flag bit, and simultaneously starting a 5-second timer, wherein when the timer counts out, or the vehicle-mounted controller receives a request of a programming session, or the vehicle-mounted controller is restarted and reset due to any reason, the flag bit is cleared.

Step four: and under the condition that the detection of the brushing condition is passed, performing diagnostic fault code control on the vehicle-mounted controller to prohibit the vehicle-mounted controller from recording the diagnostic fault code, and performing communication control on the vehicle-mounted controller to prohibit the vehicle-mounted controller from sending and receiving non-diagnostic message information.

Specifically, the server first controls the diagnostic device to perform diagnostic trouble code control on the in-vehicle controller by the functional addressing ID based on the UDS diagnostic service to prohibit it from recording DTC data, the service code of which is "85"; and, the control diagnostic device performs communication control service to the vehicle-mounted controller through the function addressing ID to prohibit the vehicle-mounted controller from sending and receiving non-diagnostic message messages through the CAN network, wherein the service codes are "$28 83 01 and $28 83 03".

Wherein, after the control diagnosis device completes the transmission of the message about "$28 83 01", the transmission of the message about "$28 83 03" needs to be performed again with a delay of 1s, and after the transmission of the message about "$28 83 03" is completed, the subsequent steps need to be performed again with a delay of 1 s.

Wherein diagnostic trouble code control refers to management and control operations on trouble codes (Diagnostic Trouble Code, DTC) when making a vehicle diagnosis. The fault code is used to indicate a fault or problem in the vehicle. Closing the recording DTC data means: the fault codes already stored in the vehicle system are cleared or marked as resolved so that they are no longer displayed or recorded in the subsequent diagnostic process.

In an exemplary embodiment, referring to fig. 5, fig. 5 is a flow chart illustrating an embodiment of a main programming phase of a software flashing process according to the present application. In step S13, that is, a process of performing data writing processing on the vehicle-mounted controller by the server, specifically includes the following steps:

Step one: based on the physical addressing ID, a request is made to enter a programming session mode for the in-vehicle controller.

Specifically, as shown in the figure, the server requests entry into a programming session mode for the in-vehicle controller by physical addressing ID based on UDS diagnostic service, whose service code is "10 02".

Step two: based on the security verification algorithm file, the second type of security access rights to the vehicle-mounted controller are obtained.

Specifically, the server first controls the diagnostic device to set a first security service level to the in-vehicle controller by a physical addressing ID request based on the UDS diagnostic service, the service code of which is "27 09"; the diagnostic device is then controlled to set a second security service level to the on-board controller, the service code of which is "27 a", via the physical addressing ID request.

Step three: based on the physical addressing ID, FLASH DRIVER files for the vehicle-mounted controller are acquired, and logic data in FLASH DRIVER files are downloaded to the vehicle-mounted controller.

The FLASH DRIVER file is a file for supporting the writing operation of the ECU, and includes hardware information of the ECU and writing algorithm. The FLASH DRIVER file is typically provided by the ECU manufacturer for communication with the writing tool to ensure that new software programs or configuration files are properly written to the ECU's memory.

In an embodiment, FLASH DRIVER files and subsequent software refreshing files (i.e. APP files) for the vehicle-mounted controller are stored in the hex files in the local file manager according to a unified hexadecimal file format, so that after FLASH DRIVER files and software refreshing files for the vehicle-mounted controller are acquired, the local files need to be imported into a refreshing program first, file data are analyzed according to the hex files, and then stored in a c-code structure variable for being read by the refreshing program.

Among them, the HEX file, i.e. Intel HEX format file, is a file type commonly used in the programming of microcontrollers, and is generally used for the transmission and programming of firmware or program codes. One HEX file includes the following parts: file header: the inclusion of version information about the file format, as well as the start address, may help the programmer or programming tool identify and properly process the file content. Data recording area: each row in the file represents a HEX record, each record containing the length of a piece of data, the address, and the data itself. These records are arranged sequentially, reflecting the layout of the program in memory. Extended linear address record (ELA): if the program code needs to use an extended address space, this type of record would be included in the HEX file to indicate a switch in address space. Ending the record: a record indicating the end of the file indicating that all program data has been transferred.

In an embodiment, the reading of the hex file by the server may be based on the following procedure: ①: responding to a file selection function button in a triggering user Interface, and triggering a file path reading function realized in a C Code Interface; ② Selecting a corresponding hex file in an opened file manager, wherein a file path reading function pre-stores the file path into the hex file path; ③ The method comprises the steps of calling a hex file analysis function, wherein input parameters are a hex file path, calling a fopen () function to open a hex file of the path in the hex file analysis function, reading the whole hex file line by using a fgets () function, and analyzing data according to a hex file format and storing the data in a structure body; ④ Splitting the structural body data into a plurality of data segments with the number not exceeding 1024 bytes, and sending the data segments to the vehicle-mounted controller in the form of message information according to the segments, wherein the number of bytes transmitted by each segment is not more than 1024 bytes.

Specifically, the server firstly controls the diagnosis device to write the pre-prepared fingerprint information into the vehicle-mounted controller in a DID data writing mode through physical addressing ID based on the UDS diagnosis service, and the service code is '2E F1 84'; then the diagnosis device is controlled to send a downloading request to the vehicle-mounted controller through the physical addressing ID, and the service code of the diagnosis device is 34; then, under the condition that the downloading request passes, the diagnosis equipment is controlled to transmit FLASH DRIVER file data in the file to the vehicle-mounted controller through the physical addressing ID, and the service code is 36; then after the file data is downloaded, controlling the diagnosis equipment to request the vehicle-mounted controller to exit the downloading through the physical addressing ID, wherein the diagnosis equipment is returned to transmit the file data to the vehicle-mounted controller under the condition that the downloading of the file data is not completed; then under the condition that the diagnosis equipment exits from downloading, determining whether the vehicle-mounted controller has downloaded the logic block data in the FLASH DRIVER file, wherein under the condition that the logic block data is not downloaded, returning to the step that the diagnosis equipment transmits the file data to the vehicle-mounted controller; in the case that the logical block data is the completion of the download, the subsequent steps are continued.

Step four: under the condition that the detection logic data is matched with the vehicle-mounted controller, a software refreshing file aiming at the vehicle-mounted controller is obtained, and logic data in the software refreshing file is downloaded to the vehicle-mounted controller so as to refresh a software program, and the software program after refreshing is obtained.

Specifically, after acquiring a software flashing file for the in-vehicle controller, the server first controls the diagnostic device to detect whether the downloaded logical data about FLASH DRIVER files matches the in-vehicle controller based on the UDS diagnostic service, the service code of which is "$31 01 02 02"; then the diagnosis equipment is controlled to send a brushing sequence for erasing FLASH to the vehicle-mounted controller through the physical addressing ID, and the service code of the brushing sequence is "$3101FF 00"; then the diagnosis device is controlled to send a downloading request to the vehicle-mounted controller through the physical addressing ID, and the service code of the diagnosis device is 34; then, under the condition that the downloading request passes, the diagnosis equipment is controlled to transmit file data in the software refreshing file to the vehicle-mounted controller through the physical addressing ID, and the service code is 36; then after the file data is downloaded, controlling the diagnosis equipment to request the vehicle-mounted controller to exit the downloading through the physical addressing ID, wherein the diagnosis equipment is returned to transmit the file data to the vehicle-mounted controller under the condition that the downloading of the file data is not completed; then under the condition that the diagnosis equipment exits from downloading, determining whether the vehicle-mounted controller has downloaded logic block data in the software refreshing file, wherein under the condition that the logic block data is not downloaded completely, returning to the step that the diagnosis equipment transmits the file data to the vehicle-mounted controller; in the case that the logical block data is the completion of the download, the subsequent steps are continued.

Step five: and carrying out compatibility detection on the software program after the writing based on the physical addressing ID, and setting the software program after the writing to a valid state under the condition that the compatibility detection is passed.

Specifically, after completion of downloading the software flashing file, the server controls the diagnostic device to send a routine control service to the in-vehicle controller through the physical addressing ID based on the UDS diagnostic service to detect the integrity and dependency of the software program, and after the detection is passed, sets the software program after the flashing to a valid state, the service of which is encoded as "$31 FF 01".

In an exemplary embodiment, referring to fig. 6, fig. 6 is a flow chart illustrating an embodiment of a post-programming phase of a software flashing process according to the present application. In step S13, that is, a process of resetting the vehicle-mounted controller by the server, specifically includes the following steps:

Step one: based on the function addressing ID, the vehicle-mounted controller is subjected to communication control so as to start the vehicle-mounted controller to send and receive non-diagnostic message information.

Specifically, the server controls the diagnostic device to perform communication control on the in-vehicle controller through the function addressing ID based on the UDS diagnostic service to turn on the in-vehicle controller to send and receive non-diagnostic message messages, the service codes of which are "$28 80 01 and $28 80 03".

Step two: and restarting the vehicle-mounted controller based on the physical addressing ID so that the vehicle-mounted controller jumps to the software program after the restarting.

Specifically, the server controls the diagnosis device to restart the vehicle-mounted controller through the physical addressing ID based on the UDS diagnosis service, so that the vehicle-mounted controller jumps to the software program after being refreshed, and the service code of the software program is "$11 01"; then, a 5 second delay timer is set to control the diagnostic device to re-activate the connection to the on-board controller after a delay of 5 seconds.

Step three: and on the basis of the physical addressing ID, performing diagnosis fault code control on the vehicle-mounted controller so as to start the vehicle-mounted controller to record the diagnosis fault code.

Specifically, the server controls the diagnosis equipment to perform diagnosis fault code control on the vehicle-mounted controller through the function addressing ID based on the UDS diagnosis service so as to start the vehicle-mounted controller to record the diagnosis fault code, and the service code is "$14"; then, the diagnosis device is controlled to carry out DTC setting service on the vehicle-mounted controller through the function addressing ID so as to start the function of recording DTC data by the vehicle-mounted controller through the CAN network, and the service code is "$85 81".

Step four: based on the functional addressing ID, a switch to a default session mode is requested for the programming session mode of the in-vehicle controller.

Specifically, the server controls the diagnostic device to transmit an extended session request to the in-vehicle controller through the functional addressing ID based on the UDS diagnostic service, so that the in-vehicle controller causes the switching from the programming session mode to the default session model, the service of which is encoded as "$1081".

On one hand, the method determines the written refreshing program for the vehicle-mounted controller through the identity information of the vehicle-mounted controller to be refreshed, and then performs software refreshing processing on the software program in the vehicle-mounted controller at least once based on the refreshing program to obtain the refreshed vehicle-mounted controller, so that the software refreshing flow of the vehicle-mounted controller is optimized, the software refreshing efficiency is effectively improved, and the consumption of manpower and material resources is reduced; on the other hand, the scheme is different from the existing software refreshing mode, the refreshing information of the vehicle-mounted controller to be refreshed is input into the refreshing program, the software refreshing process is carried out on the software program at least once through the refreshing program, the vehicle-mounted controller can be sequentially subjected to network preparation process, data refreshing process and reset process, and the final vehicle-mounted controller after refreshing process is obtained, so that the refreshing program can be utilized to refresh the software program, the production cost of enterprises is effectively reduced, the efficiency and the accuracy of carrying out software refreshing on the vehicle-mounted controller are improved, and development and application of electric vehicles are facilitated.

It should be understood that, although the steps in the figures of fig. 2-6 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps may be performed in other sequences without strict order of execution unless explicitly stated herein. Moreover, at least a portion of the steps of fig. 2-6 may include multiple steps or stages that are not necessarily performed at the same time, but may be performed at different times, nor does the order in which the steps or stages are performed necessarily occur sequentially, but may be performed alternately or alternately with other steps or at least a portion of the steps or stages in other steps.

It should be understood that the same/similar parts of the embodiments of the method described above in this specification may be referred to each other, and each embodiment focuses on differences from other embodiments, and references to descriptions of other method embodiments are only needed.

Fig. 7 is a block diagram of a software flashing device of a vehicle-mounted controller according to an embodiment of the present application. Referring to fig. 7, the software flashing apparatus 10 of the in-vehicle controller includes: an information acquisition module 11, a program module 12 for refreshing, and a software refreshing module 13.

The information acquisition module 11 is used for acquiring identity information and refreshing information of the vehicle-mounted controller to be refreshed;

Wherein the brushware module 12 is configured to determine, based on the identity information, a brushware program that has been written for the vehicle-mounted controller;

The software refreshing module 13 is configured to input the refreshing information into the refreshing program, so as to perform software refreshing processing on a software program in the vehicle-mounted controller at least once, thereby obtaining a vehicle-mounted controller after the refreshing processing;

In an embodiment, the swipe information includes a physical addressing ID and a functional addressing ID for the in-vehicle controller;

In the aspect of the network preparation process for the in-vehicle controller, the software flashing device 10 of the in-vehicle controller is further configured to perform:

In an embodiment, in the aspect of performing the data writing process on the in-vehicle controller, the software writing device 10 of the in-vehicle controller is further configured to perform:

In one embodiment, in the aspect of the resetting the in-vehicle controller, the software flashing device 10 of the in-vehicle controller is further configured to perform:

In one embodiment, in the aspect of acquiring the identity information and the refresh information of the on-board controller to be refreshed, the software refresh device 10 of the on-board controller is further configured to perform:

In an embodiment, in the aspect of performing the software flashing process on the software program in the in-vehicle controller at least once, the software flashing device 10 of the in-vehicle controller is further configured to perform:

In one embodiment, the software flashing device 10 of the vehicle-mounted controller is further configured to perform:

Fig. 8 is a block diagram of an electric vehicle provided by an embodiment of the present application. Referring to fig. 8, the electric vehicle includes a processor, a memory, an Input/Output interface (I/O) and a communication interface. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface is connected to the system bus through the input/output interface. Wherein the processor of the electric vehicle is configured to provide computing and control capabilities. The memory of the electric vehicle includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the electric vehicle is used for storing mileage maintenance data of the electric vehicle. The input/output interface of the electric vehicle is used for exchanging information between the processor and an external device. The communication interface of the electric vehicle is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements a software flashing method for an in-vehicle controller as described above.

In some embodiments, a computing system in an electric vehicle may run one or more operating systems, including any of the operating systems discussed above, as well as any commercially available server operating systems. The electric vehicle may also run any of a variety of additional server applications and/or middle tier applications, including HTTP (hypertext transfer protocol) servers, FTP (file transfer protocol) servers, CGI (common gateway interface) servers, super servers, database servers, and the like. Exemplary database servers include, but are not limited to, those commercially available from (International Business machines) and the like.

In some embodiments, the processor generally controls overall operation of the electric vehicle, such as operations associated with display, data processing, data communication, and recording operations. The processor may include one or more processor components to execute a computer program to perform all or part of the steps of the methods described above. Further, the processor component may include one or more modules that facilitate interactions between the processor component and other components. For example, the processor assembly may include a multimedia module to facilitate controlling interactions between the user electric vehicle and the processor with the multimedia assembly.

The embodiment of the application provides a computer readable storage medium. The computer readable storage medium stores a computer program, wherein the computer program when executed by a processor implements a software flashing method of the in-vehicle controller as described above.

The units integrated with the functional units in the various embodiments of the present application may be stored in a computer-readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present application may be embodied essentially or partly in the form of a software product or all or part of the technical solution, where the computer-readable storage medium includes several instructions to cause a computer device (which may be a personal computer, a system server, or a network device, etc.), an electronic device (such as MP3, MP4, etc., also may be a smart terminal such as a mobile phone, a tablet computer, a wearable device, etc., also may be a desktop computer, etc.), or a processor (processor) to perform all or part of the steps of the methods of the embodiments of the present application.

The embodiment of the application provides a computer program product. The computer program product includes program instructions executable by a processor of an electric vehicle to implement a software flashing method for an onboard controller as described above.

It will be appreciated by those skilled in the art that embodiments of the present application may provide a software flashing method of an in-vehicle controller, a software flashing device of an in-vehicle controller, an electric vehicle, a computer readable storage medium or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer program instructions (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods of software flashing of an in-vehicle controller, apparatus of software flashing of an in-vehicle controller, electric vehicle, computer-readable storage medium, or computer program product according to embodiments of the application. It will be understood that each flowchart and/or block of the flowchart and/or block diagrams, and combinations of flowcharts and/or block diagrams, can be implemented by computer program products. These computer program products may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the program instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program products may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the program instructions stored in the computer program product produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the program instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any adaptations, uses, or adaptations of the disclosure following the general principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for software flashing of a vehicle-mounted controller, the method comprising:

2. The method of claim 1, wherein the swipe information includes a physical addressing ID and a functional addressing ID for the onboard controllers;

3. The method of claim 2, wherein the performing a data swiping process on the onboard controller comprises:

4. The method of claim 3, wherein the resetting the on-board controller comprises:

5. The method of claim 1, wherein the obtaining the identity information and the brushing information of the vehicle-mounted controller to be brushed comprises:

6. The method of claim 5, wherein the performing at least one software flashing process on the software program in the in-vehicle controller comprises:

7. The method according to claim 1, wherein the method further comprises:

8. A software flashing apparatus for a vehicle-mounted controller, the apparatus comprising:

9. An electric vehicle comprising a processor and a memory coupled to the processor, wherein the memory has program data stored therein, the processor being configured to retrieve the program data stored in the memory to perform the method of any of claims 1-7.

10. A computer readable storage medium having stored therein program instructions, which when executed by a processor, implement the method of any of claims 1-7.