CN115580536A

CN115580536A - ECU upgrading method, device, equipment and storage medium based on UDS protocol

Info

Publication number: CN115580536A
Application number: CN202211152244.2A
Authority: CN
Inventors: 黄承丹; 李鹏; 唐善政
Original assignee: Youpao Automotive Technology Shanghai Co Ltd
Current assignee: Youpao Automotive Technology Shanghai Co Ltd
Priority date: 2022-09-21
Filing date: 2022-09-21
Publication date: 2023-01-06

Abstract

The invention discloses an ECU upgrading method, device, equipment and storage medium based on a UDS protocol. The scheme aims at an ECU which is not provided with an operating system under an Ethernet architecture, and the method applied to the server side comprises the following steps: sending a UDS request message to a target client to request to enter an ECU upgrading mode; after receiving a UDS response message which agrees to enter an ECU upgrading mode, sending a UDS request message to a target client to request for starting downloading ECU upgrading data; after receiving a UDS response message which agrees to start downloading ECU upgrading data, sending a UDS data message to a target client based on transmission parameters carried by the UDS response message; and after the ECU upgrading data is sent, sending a UDS request message to the target client to request to exit the ECU upgrading mode. The scheme designs an interactive flow and a message format based on a universal UDS protocol in the industry, finishes ECU upgrading through an Ethernet interface, and utilizes the Ethernet transmission advantage to consider upgrading efficiency while ensuring the applicability.

Description

ECU upgrading method, device, equipment and storage medium based on UDS protocol

Technical Field

One or more embodiments of the invention relate to the technical field of vehicle networking, and in particular to an ECU (electronic control unit) upgrading method, device, equipment and storage medium based on a UDS (Universal data System) protocol.

Background

In a vehicle implemented by combining a mechanical power technology and an Electronic information technology, an ECU (Electronic Control Unit) is one of core Electronic elements for controlling each component of the vehicle, and upgrading software of the ECU can improve performance experience simply and efficiently.

Under the ethernet architecture, for an ECU configured with an operating system, currently, in the related art, an SOA (Service-oriented architecture) may be used to implement an ECU upgrade, but for an ECU not configured with an operating system, an ECU upgrade may only be implemented in some conventional manners, which has certain disadvantages in terms of efficiency and the like.

Disclosure of Invention

In view of the above, one or more embodiments of the present invention provide a method, an apparatus, a device, and a storage medium for upgrading an ECU based on a UDS protocol.

In order to achieve the above object, one or more embodiments of the present invention provide the following technical solutions:

according to a first aspect of one or more embodiments of the present invention, a UDS protocol-based ECU upgrading method is provided, where the method is applied to a service side, and includes:

sending a UDS request message to a target client to request the target client to enter an ECU upgrading mode;

after receiving a UDS response message that the target client side agrees to enter an ECU upgrading mode, sending a UDS request message to the target client side to request the target client side to start downloading ECU upgrading data;

after receiving an UDS response message that the target client agrees to start downloading ECU upgrading data, sending an UDS data message to the target client based on transmission parameters carried in the UDS response message;

and after the ECU upgrading data is sent, sending a UDS request message to the target client to request the target client to exit the ECU upgrading mode.

In an alternative implementation, the method further comprises:

and before interaction with the target client, ECU upgrading data which are sent by a cloud and aim at the target client are received.

In an alternative implementation, before sending the UDS request message to request the target client to enter the ECU upgrade mode, or before sending the UDS request message to request the target client to start downloading ECU upgrade data, or before sending the UDS request message to request the target client to activate the ECU upgrade data, the method further includes:

and sending a UDS request message to the target client to request for carrying out security authentication with the target client, and carrying out subsequent other interactions with the target client under the condition that the security authentication is passed.

In an alternative implementation, the sending a UDS request packet to the target client to request security authentication with the target client includes:

sending a UDS request message to the target client to request the target client to provide a key seed;

and after receiving a UDS response message which is responded by the target client and carries a key seed, calculating and determining a server key based on a preset algorithm and the key seed, and sending a UDS request message to the target client to request the target client to determine whether security authentication passes or not based on the server key.

In an alternative implementation, the sending a UDS request message to the target client to request the target client to exit the ECU upgrade mode includes:

and after the ECU upgrading data is sent, calculating and determining a server side CRC code according to the ECU upgrading data, and sending a UDS request message to the target client side to request the target client side to determine whether to exit the ECU upgrading mode or not based on the server side CRC code.

In an alternative implementation, the method further comprises:

and after receiving a UDS response message that the target client agrees to quit the ECU upgrading mode, sending a UDS request message to the target client to request the target client to activate the ECU upgrading data based on the whole vehicle working condition, and receiving a UDS response message which carries the activation time of the ECU upgrading data and is responded by the target client.

According to a second aspect of one or more embodiments of the present invention, another UDS protocol-based ECU upgrading method is provided, where the method is applied to a client for an ECU not configured with an operating system under an ethernet architecture, and the method includes:

after receiving a UDS request message of a server requesting to enter an ECU upgrading mode, determining whether the current ECU state and communication state support entering the ECU upgrading mode, and if so, responding to the UDS response message agreeing to enter the ECU upgrading mode to the server;

after receiving a UDS request message of the server requesting to start downloading ECU upgrading data, determining whether the size of a program package of the ECU upgrading data is correct, and if so, responding to a UDS response message agreeing to start downloading the ECU upgrading data to the server; the UDS response message carries transmission parameters of the UDS data message used for transmitting the ECU upgrading data;

receiving a UDS data message sent by the server based on the transmission parameters;

and after receiving the UDS request message of the server requesting to exit the ECU upgrading mode, determining whether the ECU upgrading data is received completely, and if so, responding to the UDS response message agreeing to exit the ECU upgrading mode to the server.

In an alternative implementation manner, before receiving a UDS request message that a service end requests to enter an ECU upgrade mode, or before receiving a UDS request message that a service end requests to start downloading ECU upgrade data, or before receiving a UDS request message that a service end requests to activate ECU upgrade data, the method further includes:

and receiving a UDS request message which is requested by the server side to perform security authentication, performing security authentication with the server side, and performing subsequent other interactions with the server side under the condition that the security authentication is passed.

In a selectable implementation manner, the receiving a UDS request packet that the server side requests for security authentication, and performing security authentication with the server side includes:

after receiving the UDS request message of the server side requesting the key seed, responding the UDS response message carrying the key seed to the server side;

after receiving a UDS request message which is sent by the server and carries a server key, comparing a client key with the server key based on a preset algorithm, the key seed and the server key, and responding a UDS response message which passes security authentication to the server under the condition that the client key is consistent with the server key.

In an alternative implementation, the determining whether the ECU upgrade data is received includes:

and calculating and determining a client CRC code according to the currently received ECU upgrading data, comparing the client CRC code with a server CRC code carried in the UDS request message, and determining that the ECU upgrading data is completely received under the condition that the client CRC code is consistent with the server CRC code.

In an alternative implementation, the method further comprises:

and after receiving a UDS request message of the service end requesting to activate the ECU upgrading data, activating the ECU upgrading data in a local FBL mode, and responding a UDS response message carrying the activation time of the ECU upgrading data to the service end.

According to a third aspect of one or more embodiments of the present invention, an ECU upgrading apparatus based on a UDS protocol is provided, where the apparatus is applied to a server and includes a server receiving unit and a server requesting unit, and is for an ECU not configured with an operating system under an ethernet architecture; wherein:

the server receiving unit is used for receiving a UDS response message responded by a target client;

the server side request unit is used for sending a UDS request message to a target client side to request the target client side to enter an ECU upgrading mode;

the server side request unit is also used for sending a UDS request message to the target client side to request the target client side to start downloading ECU upgrading data after receiving the UDS response message that the target client side agrees to enter an ECU upgrading mode;

the server side request unit is also used for sending an UDS data message to the target client side based on the transmission parameters carried by the UDS response message after receiving the UDS response message that the target client side agrees to start downloading ECU upgrading data;

and the server side request unit is also used for sending a UDS request message to the target client side to request the target client side to exit the ECU upgrading mode after the ECU upgrading data is sent.

According to a fourth aspect of one or more embodiments of the present invention, an ECU upgrade apparatus based on the UDS protocol is provided, where the apparatus is applied to a client, a client receiving unit, and a client response unit, and is directed to an ECU not configured with an operating system under an ethernet architecture; wherein:

the client receiving unit is used for receiving a UDS request message sent by a server and a UDS data message sent by the server;

the client response unit is used for determining whether the current ECU state and the communication state support the ECU upgrading mode after receiving a UDS request message of the service end requesting to enter the ECU upgrading mode, and responding to the service end to a UDS response message agreeing to enter the ECU upgrading mode if the current ECU state and the communication state support the ECU upgrading mode;

the client response unit is further used for determining whether the size of a program package of the ECU upgrading data is correct or not after receiving a UDS request message of the server requesting to start downloading the ECU upgrading data, and responding to the UDS response message agreeing to start downloading the ECU upgrading data to the server if the size of the program package of the ECU upgrading data is correct; the UDS response message carries transmission parameters of the UDS data message used for transmitting the ECU upgrading data;

and the client response unit is also used for determining whether the ECU upgrading data is received completely after the UDS request message of the server requesting to exit the ECU upgrading mode is received, and responding the UDS response message agreeing to exit the ECU upgrading mode to the server if the ECU upgrading data is received completely.

According to a fifth aspect of one or more embodiments of the present invention, there is provided an electronic device, comprising:

a processor, and a memory for storing processor-executable instructions;

wherein the processor implements the steps of the method of the first or second aspect by executing the executable instructions.

According to a sixth aspect of one or more embodiments of the present invention, a computer-readable storage medium is proposed, on which a computer program is stored, which computer program, when being executed by a processor, carries out the steps of the above-mentioned first or second aspect of the method.

It can be seen from the above description that, in the present invention, under the ethernet architecture, the interaction flow and message format of ECU upgrade are designed based on the universal UDS protocol in the industry for the ECU not configured with an operating system, so that the software upgrade of the vehicle ECU is completed through the ethernet interface on the premise of not adopting the SOA mode, the problems in the related art are avoided, the ECU upgrade efficiency is effectively considered by using the transmission advantage of the ethernet while the applicability of the scheme is ensured and the development is facilitated, and in addition, the security authentication step further combined by the present invention can also improve the security of the ECU upgrade.

Drawings

FIG. 1 is a flowchart of a UDS protocol-based ECU upgrade method according to an exemplary embodiment.

Fig. 2 is a flowchart illustrating a method for requesting a target client to exit an ECU upgrade mode according to an exemplary embodiment.

Fig. 3 is a flowchart illustrating an ECU upgrade method based on the UDS protocol according to another exemplary embodiment.

FIG. 4 is a flowchart illustrating a UDS protocol-based ECU upgrade method in accordance with yet another exemplary embodiment.

Fig. 5 is a flowchart illustrating a method for performing security authentication between a server and a client according to an exemplary embodiment.

FIG. 6 is a flowchart of another UDS protocol-based ECU upgrade method according to an exemplary embodiment.

FIG. 7 is a flowchart illustrating a method for determining whether ECU upgrade data has been received in accordance with an exemplary embodiment.

FIG. 8 is a flowchart illustrating another UDS protocol-based ECU upgrade method in accordance with another exemplary embodiment.

FIG. 9 is a flowchart illustrating another UDS protocol-based ECU upgrade method in accordance with yet another exemplary embodiment.

Fig. 10 is a flowchart illustrating a method for performing secure authentication between a client and a server according to an exemplary embodiment.

Fig. 11 is an interaction diagram between a server and a client in an ECU upgrading process according to an exemplary embodiment.

Fig. 12 is a schematic structural diagram of an electronic device where an ECU upgrading apparatus based on the UDS protocol is located according to an exemplary embodiment.

Fig. 13 is a block diagram of an ECU upgrading apparatus based on the UDS protocol according to an exemplary embodiment.

FIG. 14 is a block diagram of another UDS protocol-based ECU upgrade device according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with one or more embodiments of the invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the invention, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the respective methods are not necessarily performed in the order shown and described. In some other embodiments, the method may include more or fewer steps than those described herein. In addition, a single step described in the present invention may be divided into a plurality of steps in other embodiments for description; multiple steps described in the present invention may be combined into a single step in other embodiments.

Thanks to the development of the related art, the current vehicle systems are already the products of the organic combination of the mechanical power technology and the electronic information technology, and they have better performance experience than the traditional automobiles.

An ECU (Electronic Control Unit), i.e., "a driving computer," as a core Electronic component of the vehicle is essentially a microchip for coordinating and controlling normal operation of each component of the vehicle, and a circuit of the ECU includes, but is not limited to, a microprocessor, a memory, an input/output interface, an analog-to-digital/digital-to-analog converter, and a driver, and specifically, the ECU may be an MCU (Microcontroller Unit) or an SoC (System on Chip), and the like.

In the related services of after-sale and the like of the vehicle, the ECU software upgrading, also called ECU chip tuning, is one of the most concise and efficient ways for improving the vehicle performance experience, and the ECU can achieve better performance expression or add more diversified functional services to the ECU by reading and writing new data.

Under the ethernet architecture, in some novel vehicles in which ECUs have operating systems, software upgrading of the ECUs may be completed in an SOA (Service-oriented architecture), but for an ECU not configured with an operating system, for example, in a case where the vehicle ECU is implemented only by an MCU, the ECU upgrading cannot be completed in the SOA, and it is too time-consuming and labor-consuming to independently establish a relevant protocol for this purpose, so that currently, for a vehicle ECU not configured with an operating system, remote upgrading is mostly performed through CAN transmission, transmission advantages of the ethernet cannot be utilized, and an urgent need exists in terms of upgrading efficiency.

In view of this, the present invention provides an ECU upgrading method based on a UDS protocol, where for an ECU not configured with an operating system under an ethernet architecture, an ECU upgrading process is implemented by an ethernet interface based on an industry-generic UDS protocol, and while ensuring universality, an ECU upgrading efficiency can be considered by using an ethernet transmission advantage.

First, a server and a client in the UDS protocol-based ECU upgrading method proposed by the present invention will be described.

It will be appreciated that a plurality of ECUs may be deployed in a vehicle, typically in different components of the vehicle, which may interact with each other in data. Common vehicle ECUs include an EMS (Engine Management System), a BMS (Battery Management System), and the like.

In the ECU upgrading method provided by the present invention, the server and the client are both actually ECUs in the vehicle, and the substitution is used in the description to clarify the interactive process in the upgrading process. The server is generally an ECU that coordinates and controls the entire vehicle networking, for example, the server may be a T-BOX (Telematics BOX), and the client may be any ECU on the vehicle that needs software upgrade.

Referring to fig. 1, fig. 1 is a flowchart illustrating an ECU upgrading method based on the UDS protocol according to an exemplary embodiment of the present invention.

The ECU upgrading method is applied to a service end aiming at the ECU which is not configured with an operating system under an Ethernet architecture, and can comprise the following specific steps:

step 102, sending a UDS request message to a target client to request the target client to enter an ECU upgrading mode.

In this embodiment, the interaction between the server and each client is performed based on a UDS protocol (Unified Diagnostic Services, ISO14229, unified Diagnostic service), and the message format, the interaction flow, and the like all conform to the requirements of the UDS protocol.

Referring to table 1, table 1 shows a schematic format diagram of a UDS message for ECU upgrade according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

…

Means of

Frame type

Reserve

Service/response parameters

…

Field value

0x01…

——

0x10/0x34...

…

TABLE 1

As shown in table 1 above, based on the related requirements on the message format in the UDS protocol, the present invention shows a frame structure of the UDS message that can be used in the present application, where the frame structure of the message specifies the frame type used for defining the overall usage of the message, the service parameter or response parameter used for defining the specific service or response of the message, and the Reserve field used for subsequent expansion.

The frame types comprise a service frame type 0x01 for representing requests and responses, a data frame type 0x02 for representing data to be flashed and an invalid frame type 0x00 for representing neglected data.

And under the condition that the UDS message is a UDS request message, the service parameters comprise a service parameter 0x10 for representing that the request enters an ECU upgrading mode, a service parameter 0x34 for representing that the request starts to download, a service parameter 0x37 for representing that the request exits the ECU upgrading mode, a service parameter 0x27 for representing that the request carries out security authentication and the like.

And in the case that the UDS message is a UDS response message, the response parameters comprise 0x7F representing a negative response, 0x50 representing an affirmative response for agreeing to enter an ECU upgrading mode, 0x74 representing an affirmative response for agreeing to start downloading ECU upgrading data, 0x77 representing an affirmative response for agreeing to exit the ECU upgrading mode, 0x67 representing safety authentication and the like.

It should be understood that the above message frame structure is a message format designed and allocated based on the related requirements of the UDS protocol, and it is within the scope of the present invention to modify applicability or utilize reserved fields for further development.

Before interacting with the target client, the server may obtain the ECU upgrade data for the target client, and in an alternative implementation, the server may obtain the ECU upgrade data for the target client from a cloud. The cloud may specifically be a vehicle-enterprise server or the like that provides after-sale service, and an implementation flow of transmitting the ECU upgrade data between the cloud and the server is not specifically limited.

After the ECU upgrading data for the target client side are obtained, the server side can send a UDS request message to the target client side through the Ethernet interface to request the target client side to enter an ECU upgrading mode.

Referring to table 2, table 2 is a schematic format diagram of a UDS request message requesting to enter an ECU upgrade mode according to an exemplary embodiment of the present invention.

	Field 1	Field 2	Field 3	Field 4	Field 5
						Means of	Frame type	Reserve	Reserve	Reserve	Service parameters
Field value	0x01	0x00	0x00	0x00	0x10

TABLE 2

As shown in table 2 above, in the UDS request message in which the server requests the target client to enter the ECU upgrade mode, the frame type is 00x1, and the service parameter is 0x10.

And after receiving the UDS request message, the target client can perform demodulation and other processing based on an Ethernet communication protocol and the UDS protocol, and respond to the request for entering an ECU upgrading mode.

And step 104, after receiving a UDS response message that the target client agrees to enter an ECU upgrading mode, sending a UDS request message to the target client to request the target client to start downloading ECU upgrading data.

In this embodiment, after sending a UDS request message requesting to enter an ECU upgrade mode to the target client, the server receives a UDS response message returned by the target client in response to the request, and performs demodulation and other processing based on an ethernet communication protocol and the UDS protocol, and when the UDS response message is a negative response, the server may terminate the upgrade, wait for the next session to perform software upgrade on the ECU, and when the UDS response message is a positive response, send the UDS request message to the target client through an ethernet interface to request the target client to start downloading ECU upgrade data.

Referring to table 3, table 3 is a schematic format diagram of a UDS request message for requesting to start downloading ECU upgrade data according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Service parameters

Package size

Field value

0x01

0x00

0x34

——

TABLE 3

As shown in table 3 above, in the UDS request message that the server requests the target client to start downloading the ECU upgrade data, the frame type is 0x01, the service parameter is 0x34, and the UDS request message also carries a parameter of a program package size, where the program package size is the program package size of the ECU upgrade data.

And after receiving the UDS request message, the target client can perform demodulation and other processing based on an Ethernet communication protocol and the UDS protocol, and responds to the request for starting downloading ECU upgrading data after determining that the size of the program package is correct.

It is noted that, in some cases, the server will also request the target client to erase the original data before requesting the target client to start downloading the ECU upgrade data.

Specifically, the server may send a UDS request message requesting to erase the original data to the target client, and send a UDS request message requesting to start downloading ECU upgrade data to the target client after receiving a UDS response message that the target client completes the original data erasure.

And step 106, after receiving a UDS response message that the target client agrees to start downloading ECU upgrade data, sending a UDS data message to the target client based on the transmission parameters carried in the UDS response message.

In this embodiment, after sending a UDS request message requesting to start downloading of ECU upgrade data to the target client, the server receives a UDS response message returned by the target client in response to the request, and performs demodulation and other processing based on an ethernet communication protocol and a UDS protocol, and when the UDS response message is a negative response, may terminate the upgrade and wait for the next session to perform the ECU software upgrade again.

And when the UDS response message is a positive response, the UDS response message should carry transmission parameters for subsequently transmitting the ECU upgrade data, such as a single packet data length SPS and a data packet minimum time interval PT, the server may send a UDS data message to the target client through an ethernet interface according to requirements of the transmission parameters, and a plurality of the UDS data messages may jointly complete transmission of the ECU upgrade data, and each of the UDS data messages carries a part of the ECU upgrade data.

Referring to table 4, table 4 is a schematic format diagram of a UDS data packet according to an exemplary embodiment of the present invention.

	Field 1	Field 2	Field 3	Field 4	Field 5 and successors
						Means of	Frame type	Reserve	Reserve	Reserve	Data to be transmitted
Field value	0x02	0x00	0x00	0x00	——

TABLE 4

As shown in table 4 above, in the UDS data packet sent by the server to the target client, the frame type is 0x02, and the other fields after the field is reserved are part of the ECU upgrade data to be sent this time, and the data length of the data should not exceed the single packet data length required by the SPS transmission parameter.

And step 108, after the ECU upgrading data is sent, sending a UDS request message to the target client to request the target client to exit the ECU upgrading mode.

In this embodiment, after the server finishes sending the ECU upgrade data for the target client, the server may send a UDS request message to the target client through an ethernet interface to request the target client to exit the ECU upgrade mode.

Referring to fig. 2, fig. 2 is a flowchart illustrating a method for requesting a target client to exit an ECU upgrade mode according to an exemplary embodiment of the present invention.

In order to ensure the integrity of the ECU upgrade data in the transmission process, in an alternative implementation manner, in step 108, the sending a UDS request message to the target client to request the target client to exit the ECU upgrade mode specifically includes:

and 108a, after the ECU upgrading data is sent, calculating and determining a service end CRC code aiming at the ECU upgrading data, and sending a UDS request message to the target client to request the target client to determine whether to exit the ECU upgrading mode or not based on the service end CRC code.

Specifically, the server may calculate and determine a Cyclic Redundancy Check (CRC) code of the server for the ECU upgrade data scheduled to be sent by the server, and send a UDS request packet carrying the CRC code of the server to the target client, so as to request the target client to determine whether the ECU upgrade data is completely transmitted and whether the ECU upgrade mode exits based on the CRC code of the server. The specific process of calculating the CRC code may refer to the related principle, which is not described herein,

referring to table 5, table 5 shows a schematic format diagram of a UDS request message requesting to exit the ECU upgrade mode according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Service parameters

Service side CRC code

Field value

0x01

0x00

0x37

——

TABLE 5

As shown in table 5 above, in the UDS request message that the server requests the target client to exit the ECU upgrade mode, the frame type is 0x01, the service parameter is 0x37, and the UDS request message also carries a parameter of a server CRC code.

And after receiving the UDS request message, the target client can perform demodulation and other processing based on an Ethernet communication protocol and the UDS protocol, and respond to the request for exiting the ECU upgrading mode after determining that the CRC code of the server is correct.

Referring to fig. 3, fig. 3 is a flowchart illustrating an ECU upgrading method based on the UDS protocol according to another exemplary embodiment of the present invention.

In an alternative implementation, the ECU upgrading method further includes the following steps:

and step 110, after receiving a UDS response message that the target client agrees to quit the ECU upgrading mode, sending a UDS request message to the target client to request the target client to activate the ECU upgrading data based on the whole vehicle working condition, and receiving a UDS response message which carries the activation time of the ECU upgrading data and is responded by the target client.

In this embodiment, after sending the UDS request message requesting to exit the ECU upgrade mode to the target client, the server receives an UDS response message returned by the target client in response to the request, performs demodulation and other processing based on an ethernet communication protocol and an UDS protocol, and meanwhile, in combination with parameters such as a vehicle operating condition, and the like, under the condition that the UDS response message is a positive response and it is determined that the target client can support ECU software upgrade, sends the UDS request message to the target client through an ethernet interface to request the target client to activate the ECU upgrade data, and then receives the UDS response message, which carries activation time of the ECU upgrade data and is returned by the target client after completing the ECU data refresh.

Referring to table 6, table 6 shows a schematic format diagram of a UDS request message for requesting activation of ECU upgrade data according to an exemplary embodiment of the present invention.

	Field 1	Field 2	Field 3	Field 4	Field 5
						Means of	Frame type	Reserve	Reserve	Reserve	Service parameters
Field value	0x01	0x00	0x00	0x00	0x1C

TABLE 6

As shown in table 6 above, in the UDS request message for requesting the target client to activate the ECU upgrade data, the frame type is 0x01, and the service parameter is 0x1C.

And after receiving the UDS request message, the target client can perform demodulation and other processing based on an Ethernet communication protocol and the UDS protocol, and respond to the request for activating the ECU to upgrade data.

Referring to fig. 4, fig. 4 is a flowchart illustrating an ECU upgrading method based on the UDS protocol according to another exemplary embodiment of the present invention.

In order to ensure the security of the ECU software upgrade, in an alternative implementation manner, in the above-mentioned ECU upgrade method based on the UDS protocol, before sending the UDS request message to request the target client to enter the ECU upgrade mode, or before sending the UDS request message to request the target client to start downloading the ECU upgrade data, or before sending the UDS request message to request the target client to activate the ECU upgrade data, the method may further include the following steps:

In this embodiment, before sending a UDS request message requesting entry of an ECU upgrade mode, requesting start of downloading ECU upgrade data, and requesting activation of the ECU upgrade data, the server may perform security authentication with the target client, interact with a key seed and a key through an ethernet interface, determine security of the session based on a predetermined unified encryption/decryption algorithm, and perform subsequent other steps if the security authentication is passed.

It can be understood that before sending the UDS request message, such as a request to erase original data and a request to roll back an original version, the server may also perform security authentication with the target client, and perform other subsequent steps if the security authentication is passed.

Referring to fig. 5, fig. 5 is a flowchart illustrating a method for performing security authentication between a server and a client according to an exemplary embodiment of the invention.

In a selectable implementation manner, the sending a UDS request packet to the target client to request security authentication with the target client specifically includes:

step 502, sending a UDS request message to the target client to request the target client to provide a key seed;

step 504, after receiving the UDS response packet carrying the key seed and responded by the target client, determining a server key based on a preset algorithm and the key seed calculation, and sending an UDS request packet to the target client to request the target client to determine whether the security authentication passes based on the server key.

Specifically, the server may send a UDS request message to the target client through an ethernet interface to request the target client to provide a key seed, and perform demodulation and other processing based on an ethernet communication protocol and a UDS protocol after receiving a UDS response message returned by the target client in response to the request, and terminate the current update when the UDS response message is a negative response, and wait for the next session to perform the ECU software update.

And under the condition that the UDS response message is a positive response, calculating and determining a server-side key based on a preset algorithm and a key seed carried in the UDS response message, and then sending a UDS request message carrying the server-side key to the target client to request the target client to determine whether the security authentication passes based on the server-side key. The specific form of the key and the key seed, and the encryption and decryption algorithm used are not particularly limited.

Referring to table 7, table 7 is a schematic format diagram of a UDS request message for requesting to provide a key seed according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6

Means of

Frame type

Reserve

Service parameters

Sub-service parameters

Field value

0x01

0x00

0x27

0x41/0x61

TABLE 7

As shown in table 7 above, in the UDS request message in which the server requests the target client to provide the key seed, the frame type is 0x01, the service parameter is 0x27, in the security authentication before the request to enter the ECU upgrade mode, the sub-service parameter is 0x41, in the security authentication before the request to start downloading the ECU upgrade data, and in the security authentication before the request to activate the ECU upgrade data, the sub-service parameter is 0x61.

After receiving the UDS request message, the target client may perform demodulation and other processing based on the ethernet communication protocol and the UDS protocol, and respond to the request for providing the key seed.

Referring to table 8, table 8 is a schematic format diagram of a UDS request packet requesting verification of a server-side key according to an exemplary embodiment of the present invention.

TABLE 8

As shown in table 8 above, in the UDS request message in which the server requests the target client to verify the server key, the frame type is 0x01, the service parameter is 0x27, in the security authentication before requesting to enter the ECU upgrade mode, the sub-service parameter is 0x42, in the security authentication before requesting to start downloading the ECU upgrade data, and in the security authentication before requesting to activate the ECU upgrade data, the sub-service parameter is 0x62, and in addition, the UDS request message also carries the parameter of the server key.

And after receiving the UDS request message, the target client can perform demodulation and other processing based on an Ethernet communication protocol and the UDS protocol, and after determining that the server-side key is correct, the target client responds to the request for verifying the server-side key.

It can be seen from the above description that, in the present invention, under the ethernet architecture, for the ECU not configured with an operating system, the interaction flow and message format of the ECU upgrade are designed based on the universal UDS protocol in the industry, so that on the premise of not adopting the SOA mode, the software upgrade of the vehicle ECU is completed through the ethernet interface, thereby avoiding the problems existing in the related art, while ensuring the applicability of the scheme and facilitating the development, the transmission advantage of the ethernet is utilized to effectively take account of the upgrade efficiency of the ECU, and in addition, the safety certification step further combined by the present invention can also improve the upgrade safety of the ECU.

Referring to fig. 6, fig. 6 is a flowchart illustrating another UDS protocol-based ECU upgrading method according to an exemplary embodiment of the present invention.

The ECU upgrading method is applied to a client and aims at the ECU which is not configured with an operating system under an Ethernet architecture, and can comprise the following specific steps:

step 602, after receiving a UDS request message requesting to enter an ECU upgrade mode from a server, determining whether a current ECU state and communication state support entering the ECU upgrade mode, and if so, responding to the UDS response message agreeing to enter the ECU upgrade mode from the server.

In this embodiment, the client is a target client to be upgraded for the ECU, and interacts with the server through an ethernet interface, performs demodulation and other processing based on an ethernet communication protocol and an UDS protocol after receiving the UDS request message sent by the server, determines whether the current ECU state and communication state support entering the ECU upgrade mode after determining that the server requests the server to enter the ECU upgrade mode, and returns a corresponding UDS response message to the server based on a state determination result.

Referring to table 9, table 9 is a schematic diagram illustrating a format of a UDS response message for agreeing to enter an ECU upgrade mode according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x50

0x00

TABLE 9

As shown in table 9 above, in the UDS response message that the client agrees to enter the ECU upgrade mode, the frame type is 0x01, the response parameter is 0x50, and the sub-response parameter is 0x00.

Referring to table 10, table 10 is a schematic diagram illustrating a format of a UDS response message that is not approved to enter the ECU upgrade mode according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successor

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x7F

0x22/0x78

Watch 10

As shown in table 10 above, in the UDS response message that the client does not agree to enter the ECU upgrade mode, the frame type is 0x01, the response parameter is 0x7F, and in the case that the relevant condition is not satisfied, the sub-response parameter is 0x22, and in the case that the response is overtime, the sub-response parameter is 0x78.

Step 604, after receiving the UDS request message of the server requesting to start downloading the ECU upgrade data, determining whether the size of the program package of the ECU upgrade data is correct, and if so, responding to the UDS response message agreeing to start downloading the ECU upgrade data to the server; and the UDS response message carries transmission parameters of the UDS data message used for transmitting the ECU upgrading data.

In this embodiment, after receiving the UDS request packet sent by the server, the client performs demodulation and other processing based on an ethernet communication protocol and an UDS protocol, determines that the server requests the server to start downloading ECU upgrade data, may obtain a size of a program packet carried in the UDS request packet and determine whether the size of the program packet is correct, and after determining that the size of the program packet is correct, may return an UDS response packet carrying transmission parameters to the server through an ethernet interface, and may return an UDS response packet representing a negative response if the size of the program packet is incorrect. The transmission parameters are used for negotiating the specific requirements of the UDS data message for subsequently transmitting the ECU upgrading data, and comprise a single-packet data length SPS and a data packet minimum time interval PT.

Referring to table 11, table 11 is a schematic format diagram of a UDS response message for approving the start of downloading ECU upgrade data according to an exemplary embodiment of the present invention.

TABLE 11

As shown in table 11 above, in the UDS response message in which the client agrees to start downloading the ECU upgrade data, the frame type is 0x01, the response parameter is 0x74, and in addition, the UDS response message also carries the SPS and PT transmission parameters.

Referring to table 12, table 12 is a schematic diagram illustrating a format of a UDS response message that does not agree to start downloading ECU upgrade data according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x7F

0x31/0x78

TABLE 12

As shown in table 12 above, in the UDS response message that the client does not agree to start downloading the ECU upgrade data, the frame type is 0x01, the response parameter is 0x7F, the sub-response parameter is 0x31 when the size of the package is incorrect, and the sub-response parameter is 0x78 when the response is overtime.

Step 606, receiving the UDS data message sent by the server based on the transmission parameter.

In this embodiment, after the client agrees to start downloading the ECU upgrade data, the client may receive the UDS data packet sent by the server through the ethernet interface, the server sends a plurality of UDS data packets to the client according to the requirement of the transmission parameter for subsequent software upgrade of the ECU by the client, the plurality of UDS data packets jointly complete transmission of the ECU upgrade data, and each UDS data packet carries part of the ECU upgrade data.

Step 608, after receiving the UDS request message that the server requests to exit the ECU upgrade mode, determining whether the ECU upgrade data is received completely, and if so, responding to the UDS response message that the server agrees to exit the ECU upgrade mode.

In this embodiment, after receiving the UDS request message sent by the server, the client performs demodulation and other processing based on the ethernet communication protocol and the UDS protocol, determines whether the ECU upgrade data is received at present after the server requests that the server exits the ECU upgrade mode, and returns a corresponding UDS response message to the server based on a data reception result.

Referring to fig. 7, fig. 7 is a flowchart illustrating a method for determining whether ECU upgrade data is received according to an exemplary embodiment of the present invention.

In an alternative implementation, the determining whether the ECU upgrade data is received in step 608 includes:

step 608a, a client CRC code is calculated and determined for the currently received ECU upgrade data, and compared with the server CRC code carried in the UDS request message, and when the client CRC code is identical to the server CRC code, it is determined that the ECU upgrade data is completely received.

Specifically, the client may obtain a server CRC code carried in the UDS request message, calculate and determine a client CRC code for the currently received ECU upgrade data, check whether the server CRC code is consistent with the client CRC code, determine that the ECU upgrade data is completely received and return a UDS response message representing a positive response if the server CRC code is consistent with the client CRC code, and determine that the ECU upgrade data is not completely received and return a UDS response message representing a negative response if the server CRC code is inconsistent with the client CRC code. The specific process of calculating the CRC code may refer to a related principle, and is not described in detail.

Referring to table 13, table 13 is a schematic format diagram of a UDS response message for agreeing to exit the ECU upgrade mode according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successor

Means of

Frame type

Reserve

Response parameter

Client CRC code

Field value

0x01

0x00

0x77

——

Watch 13

As shown in table 13 above, in the UDS response message that the client agrees to exit the ECU upgrade mode, the frame type is 0x01, the response parameter is 0x77, and the UDS response message also carries a parameter of a client CRC code.

Referring to table 14, table 14 shows a schematic format diagram of a UDS response message that does not authorize exiting the ECU upgrade mode according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x7F

0x01/0x78

TABLE 14

As shown in table 14 above, in the UDS response message that the client does not agree to exit the ECU upgrade mode, the frame type is 0x01, the response parameter is 0x7F, and in the case that the CRC code check is inconsistent, the sub-response parameter is 0x01, and in the case that the response is overtime, the sub-response parameter is 0x78.

Referring to fig. 8, fig. 8 is a flowchart illustrating another UDS protocol-based ECU upgrading method according to another exemplary embodiment of the present invention.

and step 610, after receiving a UDS request message of the service end requesting to activate the ECU upgrading data, activating the ECU upgrading data in a local FBL mode, and responding a UDS response message carrying the activation time of the ECU upgrading data to the service end.

In this embodiment, after the client determines that the ECU upgrade data is completely received and returns a UDS response message representing an affirmative response to the server, the client receives a UDS request message sent by the server, performs demodulation and other processing based on an ethernet communication protocol and the UDS protocol, determines that the server requests the server to activate the ECU upgrade data, and then activates a program package in a local FBL (Flash Boot Loader) manner, and after the ECU software upgrade is completed, returns a UDS response message carrying activation time of the ECU upgrade data representing an affirmative response to the server through an ethernet interface, and returns a UDS response message representing a negative response if the ECU software upgrade fails.

Referring to table 15, table 15 is a schematic format diagram of a UDS response message for approving activation of ECU upgrade data according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Activation time

Field value

0x01

0x00

0x4C

——

Watch 15

As shown in table 15 above, in the UDS response message in which the client agrees to activate the ECU upgrade data, the frame type is 0x01, the response parameter is 0x4C, and the UDS response message also carries the activation time of the ECU upgrade data.

Referring to table 16, table 16 is a schematic diagram illustrating a format of a UDS response message that does not agree with activating ECU upgrade data according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x7F

0x22/0x78

TABLE 16

As shown in table 16 above, in the UDS response message that the client does not agree to exit the ECU upgrade mode, the frame type is 0x01, the response parameter is 0x7F, and in the case that the relevant condition is not satisfied, the sub-response parameter is 0x22, and in the case that the response is overtime, the sub-response parameter is 0x78.

Referring to fig. 9, fig. 9 is a flowchart illustrating another UDS protocol-based ECU upgrading method according to another exemplary embodiment of the present invention.

In order to ensure the security of the ECU software upgrade, in an alternative implementation manner, in the above-mentioned method for upgrading an ECU based on the UDS protocol, before receiving a UDS request message that a service end requests to enter an ECU upgrade mode, or before receiving a UDS request message that the service end requests to start downloading ECU upgrade data, or before receiving a UDS request message that the service end requests to activate ECU upgrade data, the method may further include the following specific steps:

In this embodiment, before receiving a UDS request message requesting entry of an ECU upgrade mode, requesting start of downloading ECU upgrade data, and requesting activation of the ECU upgrade data, the target client may perform security authentication with the server, interact with a key seed and a key through an ethernet interface, determine security of the session based on a predetermined unified encryption/decryption algorithm, and perform subsequent other steps if the security authentication is passed.

It is understood that before receiving a UDS request message, such as a request to erase original data and a request to roll back an original version, the target client may also perform security authentication with the server, and perform other subsequent steps if the security authentication is passed.

Referring to fig. 10, fig. 10 is a flowchart illustrating a method for performing security authentication between a client and a server according to an exemplary embodiment of the invention.

In an optional implementation manner, the receiving a UDS request packet that the server requests for performing security authentication, and performing security authentication with the server includes:

step 1002, after receiving the UDS request message of the server requesting the key seed, responding to the UDS response message carrying the key seed to the server;

and 1004, after receiving the UDS request message carrying the server key sent by the server, comparing a client key with the server key based on a preset algorithm, the key seed and the server key, and responding to the UDS response message passing the security authentication to the server when the client key is consistent with the server key.

Specifically, the client performs demodulation and other processing based on an ethernet communication protocol and a UDS protocol, and after determining that a UDS request packet for providing a key seed is received from the server, returns a UDS response packet carrying the key seed to the server through an ethernet interface.

And after the client returns a UDS response message carrying a key seed to the server, the client receives a UDS request message carrying a server key sent by the server, the client can determine a client key based on a preset algorithm and the key seed calculation, check whether the server key is consistent with the client key, determine that the security authentication is passed if the server key is consistent with the client key, return a UDS response message representing a positive response, and determine that the security authentication is not passed if the server key is inconsistent with the client key, and return a UDS response message representing a negative response. The specific form of the key and the key seed, and the encryption and decryption algorithm used are not particularly limited.

Referring to table 17, table 17 is a schematic format diagram of a UDS response packet for providing a key seed according to an exemplary embodiment of the present invention.

TABLE 17

As shown in table 17 above, in the UDS response message in which the client provides the key seed, the frame type is 0x01, the response parameter is 0x67, in the security authentication before the request to enter the ECU upgrade mode, the sub-response parameter is 0x41, in the security authentication before the request to start downloading the ECU upgrade data, and in the security authentication before the request to activate the ECU upgrade data, the sub-response parameter is 0x61, and in addition, the UDS response message also carries the key seed parameter.

Referring to table 18, table 18 is a schematic diagram illustrating a format of a UDS response packet passing through security authentication according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x67

0x42/0x62

Watch 18

As shown in table 18 above, in the UDS response message that the client passes the security authentication, the frame type is 0x01, the response parameter is 0x67, in the security authentication before requesting to enter the ECU upgrade mode, the sub-response parameter is 0x42, in the security authentication before requesting to start downloading the ECU upgrade data, and in the security authentication before requesting to activate the ECU upgrade data, the sub-service parameter is 0x62.

Referring to table 19, table 19 is a schematic diagram illustrating a format of a UDS response packet that does not pass security authentication according to an exemplary embodiment of the present invention.

Field 1

Field 2

Field 3

Field 4

Field 5

Field 6 and successors

Means of

Frame type

Reserve

Response parameter

Sub-response parameter

Field value

0x01

0x00

0x7F

0x01/0x78/0x7E

Watch 19

As shown in table 19 above, in the UDS response message that the client does not pass the security authentication, the frame type is 0x01, the response parameter is 0x7F, the sub-response parameter is 0x01 in the case of inconsistency of key verification, the sub-response parameter is 0x78 in the case of response timeout, and the sub-response parameter is 0x7E in the case of non-ECU upgrade mode.

In order to make the technical solution provided by the present invention more clearly understood by those skilled in the art, the following description is further made with reference to the interactive diagram shown in fig. 11.

Referring to fig. 11, fig. 11 is an interaction diagram of a server and a client in an ECU upgrading process according to an exemplary embodiment of the present invention.

The interaction shown in fig. 11 is a complete interaction process in which the server and the target client successfully perform ECU upgrade based on the UDS protocol, and specifically includes the following steps:

step 1101, the server sends a UDS request message requesting the target client to provide a key seed to the target client.

Step 1102, the target client returns a UDS response packet carrying the key seed to the server.

Step 1103, the server calculates and determines a server key based on a preset algorithm and a key seed carried in the received UDS response message, and sends a UDS request message carrying the server key to the target client to request the target client to verify the server key.

And 1104, the target client checks whether the client key is consistent with the server key based on a preset algorithm, the key seed and the server key carried in the received UDS request message, and returns a UDS response message passing the security authentication to the server after determining that the client key is consistent with the server key.

In step 1105, the server sends a UDS request message to the target client requesting the target client to enter the ECU upgrade mode.

In step 1106, the target client returns a UDS response message agreeing to enter the ECU upgrade mode to the server.

Step 1107, the server sends a UDS request message to the target client requesting the target client to pass the key seed.

Step 1108, the target client returns a UDS response packet carrying the key seed to the server.

Step 1109, the server calculates and determines a server key based on a preset algorithm and a key seed carried in the received UDS response message, and sends a UDS request message carrying the server key to the target client to request the target client to check the server key.

In step 1110, the target client checks whether the client key is consistent with the server key based on a preset algorithm, the key seed and the server key carried in the received UDS request message, and returns a UDS response message passing the security authentication to the server after determining that the client key is consistent with the server key.

Step 1111, the server sends a UDS request message carrying a size of a program package to the target client requesting the target client to start downloading ECU upgrade data.

In step 1112, the target client verifies whether the size of the program packet carried in the received UDS request message is correct, and returns a UDS response message carrying transmission parameters, which agrees to start downloading the ECU upgrade data, to the server after determining that the size of the program packet is correct.

And step 1113, the server side sends the UDS data message to the target client side based on the transmission parameters carried in the received UDS response message until the ECU upgrading data is sent completely.

Step 1114, calculating and determining a service end CRC code for the ECU upgrade data, and sending a UDS request message carrying the service end CRC code to a target client requesting the target client to exit the ECU upgrade mode.

And 1115, calculating a client CRC code by the target client aiming at the currently received ECU upgrading data, checking whether the client CRC code is consistent with a server CRC code carried in the received UDS request message, and returning a UDS response message agreeing to exit the ECU upgrading mode to the server after determining that the client CRC code is consistent with the server CRC code.

Step 1116, the server sends a UDS request message requesting the target client to pass the key seed to the target client.

Step 1117, the target client returns the UDS response message carrying the key seed to the server.

Step 1118, the server calculates and determines a server key based on a preset algorithm and a key seed carried in the received UDS response message, and sends a UDS request message carrying the server key to the target client to request the target client to verify the server key.

And 1119, the target client checks whether the client key is consistent with the server key or not based on a preset algorithm, the key seed and the server key carried in the received UDS request message, and returns a UDS response message passing the security authentication to the server after determining that the client key is consistent with the server key.

Step 1120, the server sends a UDS request message to the target client for requesting the target client to activate ECU upgrade data.

Step 1121, the target client activates the ECU upgrade data by using a local FBL mode, and returns a UDS response message carrying the activation time of the ECU upgrade data to the server.

Referring to fig. 12, fig. 12 is a schematic structural diagram of an electronic device where an ECU upgrading apparatus based on the UDS protocol is located according to an exemplary embodiment of the present invention. On the hardware level, the electronic device includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210, although other hardware needed for services may be included. One or more embodiments of the invention can be implemented in software, for example, by the processor 1202 reading corresponding computer programs from the non-volatile memory 1210 into the memory 1208 and then running. Of course, besides software implementation, other implementations are not excluded from one or more embodiments of the present invention, such as logic devices or a combination of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 13, fig. 13 is a block diagram of an ECU upgrading apparatus based on the UDS protocol according to an exemplary embodiment of the present invention, which may be applied to the electronic device shown in fig. 12 to implement the technical solution of the present invention. The ECU upgrading device is applied to a server and comprises a server receiving unit 1310 and a server requesting unit 1320, aiming at an ECU not configured with an operating system under an ethernet architecture; wherein:

the server receiving unit 1310 is configured to receive a UDS response packet responded by a target client;

the server request unit 1320 is configured to send a UDS request message to a target client to request the target client to enter an ECU upgrade mode;

the server request unit 1320 is further configured to, after receiving a UDS response message that the target client agrees to enter an ECU upgrade mode, send a UDS request message to the target client to request the target client to start downloading ECU upgrade data;

the server request unit 1320 is further configured to, after receiving a UDS response message that the target client agrees to start downloading the ECU upgrade data, send a UDS data message to the target client based on a transmission parameter carried in the UDS response message;

the server request unit 1320 is further configured to send a UDS request message to the target client to request the target client to exit the ECU upgrade mode after the ECU upgrade data is sent.

Optionally, the server receiving unit 1310 is further configured to:

and before interacting with the target client, receiving ECU upgrading data aiming at the target client and sent by the cloud.

Optionally, the server request unit 1320, before sending the UDS request message to request the target client to enter the ECU upgrade mode, or before sending the UDS request message to request the target client to start downloading the ECU upgrade data, or before sending the UDS request message to request the target client to activate the ECU upgrade data, is further configured to:

Optionally, the server request corresponds to 1320, and when sending a UDS request packet to the target client to request security authentication with the target client, the server request is specifically configured to:

Optionally, the server request unit 1320, when sending a UDS request message to the target client to request the target client to exit the ECU upgrade mode, is specifically configured to:

and after the ECU upgrading data are sent, calculating and determining a service end CRC code aiming at the ECU upgrading data, and sending a UDS request message to the target client to request the target client to determine whether to exit an ECU upgrading mode or not based on the service end CRC code.

Optionally, the server request unit 1320 is further configured to:

Referring to fig. 14, fig. 14 is a block diagram of another UDS protocol-based ECU upgrading apparatus according to an exemplary embodiment of the present invention, which may be applied to the electronic device shown in fig. 12 to implement the technical solution of the present invention. The ECU upgrading device is applied to a client and comprises a client receiving unit 1410 and a client response unit 1420, aiming at the ECU which is not configured with an operating system under an Ethernet architecture; wherein:

the client receiving unit 1410 is configured to receive a UDS request message sent by a server and a UDS data message sent by the server;

the client response unit 1420 is configured to determine whether the current ECU state and communication state support entering the ECU upgrade mode after receiving a UDS request message requesting the server to enter the ECU upgrade mode, and if so, respond to the server a UDS response message agreeing to enter the ECU upgrade mode;

the client response unit 1420 is further configured to determine whether the size of the program package of the ECU upgrade data is correct after receiving the UDS request message that the server requests to start downloading the ECU upgrade data, and if so, respond to the UDS response message that agrees to start downloading the ECU upgrade data to the server; the UDS response message carries transmission parameters of the UDS data message used for transmitting the ECU upgrading data;

the client response unit 1420 is further configured to determine whether the ECU upgrade data is received completely after receiving the UDS request message that the server requests to exit the ECU upgrade mode, and if so, respond to the server a UDS response message that agrees to exit the ECU upgrade mode.

Optionally, the client receiving unit 1410, before receiving a UDS request message that the server requests to enter the ECU upgrade mode, or before receiving a UDS request message that the server requests to start downloading ECU upgrade data, or before receiving a UDS request message that the server requests to activate ECU upgrade data, is further configured to:

Optionally, the client response unit 1420, when receiving the UDS request packet requested by the server to perform security authentication and performing security authentication with the server, is specifically configured to:

Optionally, the client response unit 1420, when determining whether the ECU upgrade data is received completely, is specifically configured to:

Optionally, the client response unit 1420 is further configured to:

and after receiving a UDS request message which is sent by the service end and requests to activate the ECU upgrading data, activating the ECU upgrading data in a local FBL mode, and responding a UDS response message carrying the activation time of the ECU upgrading data to the service end.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

The foregoing description of specific embodiments of the present invention has been presented. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the embodiment or embodiments of the invention is for the purpose of describing the particular embodiment only and is not intended to be limiting of the embodiment or embodiments of the invention. As used in one or more embodiments of the present invention and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used herein to describe various information in one or more embodiments of the invention, such information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present invention. The word "if," as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination," depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not intended to limit the scope of the present invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. An ECU upgrading method based on a UDS protocol is characterized in that the method is applied to a service end aiming at an ECU which is not configured with an operating system under an Ethernet architecture, and the method comprises the following steps:

after receiving a UDS response message that the target client agrees to enter an ECU upgrading mode, sending a UDS request message to the target client to request the target client to start downloading ECU upgrading data;

after receiving a UDS response message that the target client agrees to start downloading ECU upgrading data, sending a UDS data message to the target client based on transmission parameters carried by the UDS response message;

2. The method of claim 1, further comprising:

3. The method of claim 1, wherein before sending the UDS request message to request the target client to enter the ECU upgrade mode, or before sending the UDS request message to request the target client to begin downloading ECU upgrade data, or before sending the UDS request message to request the target client to activate ECU upgrade data, the method further comprises:

4. The method of claim 3, wherein sending a UDS request message to the target client to request secure authentication with the target client comprises:

5. The method of claim 1, wherein sending a UDS request message to the target client to request the target client to exit ECU upgrade mode comprises:

6. The method of claim 1, further comprising:

7. An ECU upgrading method based on a UDS protocol is characterized in that the method is applied to a client for ECUs not configured with an operating system under an Ethernet architecture, and comprises the following steps:

8. The method according to claim 7, wherein before receiving a UDS request message for the server to request entry into the ECU upgrade mode, or before receiving a UDS request message for the server to request start of downloading ECU upgrade data, or before receiving a UDS request message for the server to request activation of ECU upgrade data, the method further comprises:

9. The method according to claim 8, wherein the receiving the UDS request packet that the server side requests for security authentication and performing security authentication with the server side includes:

10. The method of claim 7, wherein the determining whether the ECU upgrade data is received comprises:

11. The method of claim 7, further comprising:

12. The ECU upgrading device based on the UDS protocol is characterized in that the device is applied to a server aiming at the ECU which is not provided with an operating system under an Ethernet architecture, and comprises a server receiving unit and a server requesting unit; wherein:

13. The ECU upgrading device based on the UDS protocol is characterized in that the device is applied to a client aiming at the ECU which is not provided with an operating system under an Ethernet architecture, and comprises a client receiving unit and a client response unit; wherein:

the client response unit is used for determining whether the current ECU state and the communication state support entering the ECU upgrading mode after receiving a UDS request message of a server requesting to enter the ECU upgrading mode, and responding to the server a UDS response message agreeing to enter the ECU upgrading mode if the current ECU state and the communication state support entering the ECU upgrading mode;

14. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the steps of the method of any one of claims 1-11 by executing the executable instructions.

15. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 11.