Method for interacting with a computer on an on-board bus of a vehicle - Patents.com

The method addresses inefficiencies in vehicle bus command processing by using a third computer with UDS protocol and standby states to manage commands, ensuring efficient and reliable updates without mode switching.

JP7602493B2Active Publication Date: 2024-12-18NISSAN MOTOR CO LTD +1
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2021576268
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2019-06-25
Filing Date
2020-05-29
Publication Date
2024-12-18
Estimated Expiration
2040-05-29

AI Technical Summary

Technical Problem

Existing methods for updating onboard computers in vehicles face inefficiencies due to increased duration between command sending and response receipt as the number of commands increases, particularly on busy vehicle buses, leading to potential interruptions and complexity.

Method used

A method involving a third computer that processes main commands, sends write commands only when the second computer is ready, and uses a UDS protocol to manage commands efficiently, reducing the duration between sending and receiving responses by implementing a standby state and periodic signals.

Benefits of technology

This approach allows for efficient processing of commands without needing to switch between diagnostic and update modes, reducing total command duration and ensuring reliability even in high-activity vehicle environments.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007602493000001
    Figure 0007602493000001
  • Figure 0007602493000002
    Figure 0007602493000002
  • Figure 0007602493000003
    Figure 0007602493000003
Patent Text Reader

Abstract

A main command intended for a first computer connected to a first on-board bus is processed by a second computer from a first on-board bus in a vehicle to interact with the first computer connected to the first bus, and the method includes a step in which a third computer connected to the first on-board bus generates (102) a command to write a description of the main command to a first dedicated zone of the second computer, and then, when the second computer detects (103) that it is ready to respond to the write command, sends (104) the write command to the second computer; and after the second computer receives (111) the write command, sends one or more auxiliary commands to the first computer to respond to the main command. the first computer sends (114) a response to each received auxiliary command (121) that the second computer stores in the second dedicated zone (116); the third computer, when it detects (107) that the second computer is ready to respond to the read command, sends (108) a command to read the second dedicated zone to the second computer, resulting in the second computer sending (124) a response to the received read command (119); and the third computer receives (109) a response to the command to read the second zone of the second computer and responds to the main command (126).
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to a method for interacting with a computer on an on-board bus of a vehicle, and in particular to a method for interacting from a first on-board bus in a vehicle with a first computer connected to a second on-board bus of the vehicle. [Background technology]

[0002] The method according to the invention is particularly useful for updating an on-board computer while simultaneously executing a real-time program for operating the vehicle.

[0003] Real-time execution of updates and programs onboard a vehicle's computers typically requires commands to be sent over one or more vehicle buses. Typically, timers are implemented to control the duration separating sending a command and receiving a response to that command, but this has the drawback that the duration increases as the amount of commands increases.

[0004] For example, EP1434129A2 discloses a device for controlling reprogramming of an on-board program in a vehicle, where switching commands are based on a signal originating from a timer. The disclosed device controls two operating modes: a normal mode, which may correspond to a diagnostic mode, and a reprogramming mode for reprogramming an on-board program in a vehicle, which may be used for computer updates. The disclosed device switches from the normal mode to the reprogramming mode when it receives a program reprogramming command originating from a server, and switches from the reprogramming mode to the normal mode when it receives, during the reprogramming mode, a command to switch to the normal mode. Each switching operation has the disadvantage of terminating the ongoing mode. Summary of the Invention

[0005] In order to overcome the drawbacks presented in the prior art, the object of the present invention is to provide a method for interacting from a first on-board bus in a vehicle with a first computer connected to a second on-board bus of the vehicle, the first bus being connected to the second bus by a second computer, a third computer connected to the first on-board bus processing main commands intended for the first computer, the method comprising: - generating, by a third computer, a command for writing a description of said main command to a first dedicated zone of a second computer; - when the third computer detects that the second computer is ready to respond to the write command, sending the write command to the second computer; - after receiving the write command, the second computer sends one or more auxiliary commands to the first computer in response to the main command; - the first computer transmitting a response to each received auxiliary command; - storing, by a second computer, each received response in a second dedicated zone; - sending a command to read said second private zone intended for the second computer when the third computer detects that the second computer is ready to respond to said read command; - transmitting, by the second computer, a response to the received read command; - responding to the main command by the third computer after receiving at least one response to a command to read the second zone of the second computer, in which the response sent by the first computer is stored; Includes.

[0006] Specifically, the signal in two states, ready and not ready, is periodically transmitted by the second computer, and the method then includes: - upon receiving a write command originating from a third computer, - When a response is received from the first computer, it goes into the ready state. The method includes the step of setting.

[0007] Advantageously, the method includes the step of the third computer, after receiving said signal set to occupied, waiting for a signal set to ready.

[0008] Specifically, the write command comprises a first frame, the first frame comprising a first identifier field for a command, a first identifier field for a first dedicated zone, and at least one description field for a main command.

[0009] More specifically, the main command description comprises a standard field for the main command, an identification field for the second computer, and a useful data identification field for the second computer for establishing the response to be sent.

[0010] Also specifically, the method includes the step of the second computer sending an acknowledgment intended for the first computer upon receiving the write command.

[0011] More specifically, the acknowledgment comprises a second frame, the second frame comprising an acknowledgment identifier field and a second identifier field for the first dedicated zone.

[0012] More specifically, the read command sent by the third computer comprises a third frame, the third frame comprising a second command identification field and a first identifier field for a second dedicated zone.

[0013] Also specifically, the response to the read command comprises a fourth frame, the fourth frame comprising a fourth identifier field for the response to the command, a second identifier field for the second dedicated zone, at least one descriptive annotation field for the main command, and a content field for the response sent by the first computer.

[0014] Specifically, the main command is a command to read resident data in the first computer, whereas the auxiliary command comprises a fifth frame having an identification field for the read command and an identification field for the resident data, whereby the response sent by the first computer comprises a sixth frame having an identification field for the response to the read command, an identification field for the resident data, and a field containing a value for the resident data.

[0015] The read and write commands are preferably commands that comply with the UDS (Unified Diagnostic Services) protocol.

[0016] The method also - a second computer checking, upon receiving the write command, whether the description of the main command is complete; - sending one or more auxiliary commands to the first computer in response to the main command only if the description of the main command is complete; - a second computer storing a warning in a second dedicated zone if the description of the main command is not complete; may include.

[0017] Further advantages and features of the invention will become apparent from reading the detailed description of embodiments given by way of non-limiting example with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0018] [Figure 1] 1 shows a schematic diagram of a system mounted on a vehicle in which the invention is implemented; [Diagram 2] FIG. 2 shows a schematic diagram of a command frame used to implement the present invention; [Diagram 3] FIG. 3 illustrates steps of the method according to the invention for processing a main read command; [Figure 4] FIG. 2 illustrates steps of a first method according to the invention for processing a main installation command. [Diagram 5] FIG. 4 illustrates the steps of the second part of the method according to the invention, for processing a main installation command. [Figure 6] FIG. 4 illustrates the third and final step of the method according to the invention, for processing a main installation command. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] FIG. 1 shows two computers 9, 10 connected to an on-board bus 1 in a vehicle, and three computers 12, 13, 14 connected to an on-board bus 2 in a vehicle. The computer 9 is, for example, an on-board computer dedicated to electrical communication of the IVC (In-Vehicle Communication) type. The computer 10 is, for example, an on-board computer of the IVI (In-Vehicle Infotainment) type, whose computing power is equivalent to that of a microcomputer. Other on-board computers not shown in the figure may be connected to the on-board bus 1. The computers 12, 13, 14 connected to the on-board bus 2 are preferably on-board computers for control and command components of the vehicle of the ECU (Electronic Control Unit) type. The computer 11 connected to the on-board bus 1 and the on-board bus 2 performs a gateway function between the two on-board buses.

[0020] 3 shows the steps of the interaction method, in which computer 10 processes a main command, which is a command to read resident data in one of computers 12, 13, 14, for example computer 12. This type of command is useful for example to read a digital component reference in computer 12, or a version number of a digital component, with a view to determining whether the digital component needs to be updated. A digital component may equally relate to an executable program, a database, or any other digital structure, such as, for example, a source program or a table of parameters.

[0021] The computer 10, initially in a wait step 100, transitions to step 102 when a read request submitted by a higher level method, e.g. a method for updating the computer 12, confirms transition 101. By way of example, the read request may include an identifier for identifying the computer among the computers 12, 13, 14 connected to the vehicle bus 2, in this case the identifier of the computer 12. The computer identifier may consist of a computer address according to the communication protocol of the bus 2, of the CAN (Controller Area Network), FlexRay or TTP type, also known in the aviation, automotive Ethernet or other fields. The computer identifier may also consist of a string of ASCII characters naming the computer in its functional space, e.g. "BCM" (Body Control Module), "HEVC" (Hybrid Electric Vehicle Controller), "VDC" (Vehicle Dynamic Control) or other. The advantage of a string of ASCII characters involves being able to specify the computer independently of the vehicle system architecture. A further advantage of a string of ASCII characters involves forming a mnemonic that is easier for a person to understand. As another example, the read request may include a data identifier 63 within the identified computer.

[0022] In step 102, the computer 10 constructs a description of the main command based on the request that identified the transition 101 and then generates a write command for the description of the main command in the first dedicated data zone 61, which resides in the memory of the computer 11.

[0023] 2 shows an example of a write command comprising a frame 21. The frame 21 comprises an identifier field 31 identifying the generated command as a write command, an identifier field 32 identifying a first dedicated zone 61 and at least one field 33, 34, 35 for containing a description 27 of the main command.

[0024] A field 33 constituting the description 27 gives the type of main command. By way of a completely non-limiting example, the type of main command is identified, for example, by two characters of ASCII code. The first character identifies the class of main command as "E" for "execute", "R" for "read" or "W" for "write". The second character, combined with the first character, identifies the action within the main command class as "EA" for "perform activation", "ED" for "perform download", "EI" for "perform installation", "EC" for "perform deletion", "ER" for "perform reinitialization", "RD" for "read data", "RX" for "read extended data", "WD" for "write data". A field 34 constituting the description 27 gives in particular the on-board computer identifier according to the one indicated in the request. A field 35 constituting the description 27 contains parameters useful for executing the command. By way of example, when the field 33 contains one of the "EI" and "EA" command types, the parameters are identifiers of the digital components to be installed and activated, respectively. In the example shown in FIG. 3, the main command description 27 comprises a field 33 giving the “RD” type of main command, an identification field 34 for the functional name of the computer connected to bus 2, e.g. computer 12, and a parameters field 35 containing identifiers of data to be read as parameters useful to computer 11 to assist in processing the main command.

[0025] More specifically, the use of write commands according to the UDS (Unified Diagnostic Services) protocol has the advantage of benefiting from the facilities that are pre-installed in most on-board computers in the automotive field in general, to perform diagnostic functions without having to modify the low level communication layers in particular to implement the interaction method according to the invention. In this particular case, field 31 contains the SID (Service Identifier) ​​$2E, which is a known hexadecimal code for data to be written by the DID identifier.

[0026] A transition 103 for going from step 102 to step 104 is confirmed when the computer 11 is detected as being ready to respond to a write command supported by the frame 21. In this way, if the computer 11 performs a gateway function for another instance of the interaction method according to the invention or for a command generated by another method, for example a diagnostic method, it remains in a waiting state in step 102. The computer 10 does not unnecessarily congest the bus 1 by attempting to send a command that would remain invalid because the computer 11 is occupied by another function. In the example of ongoing processing of a diagnostic command specific to another method, putting the interaction method in a waiting state momentarily in step 102 allows the diagnostic command to be executed without having to interrupt the diagnostic method.

[0027] Several solutions can be contemplated to detect whether computer 11 is ready to respond to a write command supported by frame 21. For example, if computer 10 is the only computer interacting with computer 11 on bus 1, a higher sequence control layer in computer 10 may control the ready or not ready state of computer 11. This solution may be difficult to implement when another computer 9 is trying to interact with computer 11 through bus 1, for example to perform remote diagnostics. Otherwise, computer 10 may monitor bus 1 to detect frames therein that are intended for computer 11, for example, computer 11 would not be ready to respond to a write command supported by frame 21. This alternative solution may quickly pose problems in terms of complexity in the case of numerous ways of using the channels of bus 1. Other solutions may be contemplated without departing from the scope of the invention.

[0028] According to a preferred solution for detecting whether the computer 11 is ready, within the scope of the interaction method according to the invention, it is the computer 11 itself that declares whether it is ready to process commands sent to it. The computer 11 periodically transmits through the bus 1 a signal with two states: ready and occupied or not ready.

[0029] In an initial wait step 110, computer 11 sets the signal to the ready state by default. As soon as computer 11 receives a command, either from an interaction method according to the invention or from any other method, for example a diagnostic method, computer 11 sets the signal to the occupied state until the processing of the ongoing command is finished.

[0030] In step 104, computer 11 has been detected as being ready to respond to a write command, and computer 10 sends the write command to computer 11. To send the write command, computer 10 may encapsulate frame 21 within a CAN frame on bus 1, or alternatively, for example, may encapsulate frame 21 within an IP frame if a vehicle Ethernet protocol is used on bus 1.

[0031] Receipt of the write command at computer 11 identifies a transition 111 necessary to transition computer 11 from initial step 110 to step 114, where computer 11 transmits an auxiliary command to one of computers 12, 13, 14 identified in field 34, e.g. computer 12, in response to the main command, based on the description 27 of the main command written in the dedicated data zone 61 of computer 11.

[0032] In the particular case of FIG. 3, where the main command is a command to read resident data in computer 12, FIG. 2 shows an example of an auxiliary command with a frame 25 with an identification field 48 for the read command and an identification field 49 for the resident data in computer 12.

[0033] More specifically, the use of a read command according to the UDS protocol has the advantages mentioned above. In this particular case, field 48 contains the SID $22, which is a known hexadecimal code for the data to be read by the DID identifier. Field 49 contains the DID identifier of the data zone 63 of computer 12, indicated in field 35 of frame 21.

[0034] Transition 111 may transition the method directly from the initial step 110 to step 114. Transition 111 may preferably transition the method from the initial step 110 to an intermediate step 112, but this is not required.

[0035] In step 112, computer 11 checks whether main command description 27 is complete with respect to predefined security rules, which are not part of the subject matter of the present invention. If step 112 is performed, transition 113 is confirmed if main command description 27 is verified to be complete, or transition 117 is confirmed if main command description 27 is verified to be incomplete. Step 114 is then activated after the confirmation of transition 113.

[0036] In step 114 or from step 112, if present, in other words after confirmation of transition 111 by receiving a write command originating from computer 10, computer 11 puts the periodic signal into an occupied state. Concomitantly, computer 11 responds to the write command by sending an acknowledgement of receipt, or a positive response. For example, if the UDS protocol is used, computer 11 sends frame 22, the first field 37 of which contains the SID code with the value $6E and the second field 38 of which contains the value of field 32 of frame 21 to enable computer 10 to recognize the transmitted write command to which the received acknowledgement of receipt corresponds. In other words, field 38 forms an identifier field for the first dedicated zone 61.

[0037] Receipt by computer 10 of a periodic signal, or frame 22, set to the Occupied state confirms transition 105 which transitions the method at computer 10 from step 104 to step 106. At step 106, computer 10 is placed in a wait state for a signal to set to the Ready state.

[0038] Initially, in a waiting step 120 of the interaction method according to the invention, computer 12 checks transition 121 when it receives an auxiliary command, represented by frame 25, sent by computer 11 through the vehicle bus 2. The checking of transition 121 activates a step 122 in which computer 12 sends a response to the received auxiliary command. The response sent to computer 11 comprises frame 26, which in this case is a response to a read command, a response identification field 50, an identification field 51 for said resident data and a field 52 containing the value of the resident data 63 identified by field 51, as shown in FIG. 2.

[0039] In the particularly advantageous case of the use of the UDS protocol, field 50 contains SID $62, which is the known hexadecimal code of the response to the data read by the DID identifier. Field 51 contains the DID identifier of the data zone 63 of computer 12, indicated in field 49 of frame 25. Computer 12 then returns to the waiting step 120.

[0040] Receipt of the response by the computer 11 sees a transition 115 which transitions the interaction method from step 114 to step 116, where the computer 11 generates a description 28 of the response to the main command, in this case a command for reading resident data 63 in the computer 12. The response description 28 comprises fields 43, 44, 45, each of which contains the values ​​of fields 33, 34, 35 of the command description 27 for identifying that the response description is in fact the one corresponding to the main command description. The response description 28 also comprises a field 47, which contains the value contained in field 52 of the frame 26. The computer 11 stores the response description 28 in a second dedicated data zone 62, resident in the memory of the computer 11.

[0041] In step 116, computer 11 then sets the periodic signal to a ready state.

[0042] Transition 107 is acknowledged when computer 10 detects that computer 11 is ready to respond. In the preferred embodiment of the present invention, transition 107 is acknowledged through receipt of a periodic signal in the ready state.

[0043] The confirmation of transition 107 activates step 108 in computer 10. In step 108, computer 11 has been detected as ready to respond to a read command, and computer 10 transmits a read command from the second dedicated zone 62 targeted to computer 11. The read command is represented, for example, by frame 23, as shown in Figure 2. Frame 23 comprises an identification field 39 to identify the command as a read command, and an identifier field 40 for the second dedicated data zone 62.

[0044] Specifically, in the advantageous case of use of the UDS protocol, field 39 contains the value $22 identifying a read command, and field 40 contains a DID value which is the address of a dedicated data zone 62 in the memory of computer 11 .

[0045] Transition 119 is recognized when computer 11 receives a read command, represented by frame 23 .

[0046] The confirmation of transition 119 activates a step 124, in which computer 11 transmits a response to computer 10. The response to the received read command comprises a frame 24 comprising an identifier field 41 for identifying the response to the read command, so as to be able to check that frame 24 forms a response to the read command represented by frame 23, and an identifier field 42 for identifying the second dedicated zone 62. Frame 24 then comprises a description 28 comprising fields 43, 44, 45 each containing a value equal to that contained in fields 33, 34, 35, respectively, by annotation of the description of the main command. Description 28 also comprises a field 47, which contains the response to the main command.

[0047] The computer 11 then returns to the initial waiting step 110 in connection with the interaction method according to the invention.

[0048] Transition 109 is recognized when computer 10 receives a response to the read command represented by frame 24 .

[0049] Verification of transition 109 activates step 126, in which computer 10 responds to the main command based on the contents of field 47 extracted from the response to the read command in the second dedicated zone of computer 11, in which the response sent by computer 12 is stored.

[0050] The computer 10 then returns to the initial waiting step 100 in connection with the interaction method according to the invention.

[0051] From the above disclosure, it should be noted that the use of the UDS protocol for the commands of the interaction method according to the invention allows the main commands to be processed, which forms a computer update method, without the need to switch from diagnostic mode to update mode. The commands remain diagnostic commands in the interaction between the computers. The processing of the update functions is done by processing the main commands in the computer 10 at a higher layer, in a manner equivalent to the processing of the diagnostic functions. The computer 11 can process frames associated with the diagnostic functions by forwarding them directly from bus 1 to bus 2 and vice versa, as a gateway. The computer 11 can process frames related to the diagnostic functions by processing them by a diagnostic function resident in the computer 11. The computer 11 can process frames related to the update functions by an update function resident in the computer 11, as can be done for a diagnostic function resident in the computer 11. To process many pure diagnostic commands, such as update commands, a single protocol stack is sufficient, namely the UDS protocol stack. When a pure diagnostic command is sent from bus 1 to bus 2 in the absence of a command related to updating a digital component, computer 11 simply places the command in an update-related wait state and sets the periodic signal to an occupied state, as may occur when processing a pure diagnostic command. When an update-related command is sent from bus 1 to bus 2 in the absence of a pure diagnostic command, computer 11 simply ignores the pure diagnostic command and sets the periodic signal to an occupied state, as may occur when processing a command related to updating a digital component, so that the diagnostic method is free to resend the pure diagnostic command when computer 11 returns the periodic signal to a ready state.

[0052] The transmission of read and write commands associated with the processing of the main command from the computer 10 connected to the vehicle bus 1 does not require a command to be received from a remote server to resume the update process as soon as the periodic signal is set to a ready state. Thus, the update process can occur without the need for a remote connection of the vehicle, as long as the update data has been previously downloaded to the computer 10.

[0053] The above description given as an example for an update process in parallel with a diagnostic process is applicable to other processes in parallel with a diagnostic process by implementing the interaction method according to the invention.

[0054] When the main command of the interaction method is to read data of one of the computers 12, 13, 14 connected to the bus 2, it can be implemented more simply by a single command to read the data, directly targeted at the computer 12, 13, 14 that hosts the data, for example computer 12. However, this solution, a priori simple, raises the problem of managing the total duration that comes to separate the sending of the single read command and the receiving of the response, which is the sum of the duration needed to send a single read command from computer 10 to computer 11, then from computer 11 to computer 12, to send the response by computer 12, to send the response from computer 12 to computer 11, then from computer 11 to computer 10. This total duration can quickly become extremely critical when the activity on the buses 1 and 2 is high, as is often the case in a moving vehicle.

[0055] The replacement of a single read command by a write command in a first dedicated data zone of computer 11 followed by a read command in a second dedicated data zone of computer 11 allows the problem of excessive duration raised in the previous paragraph to be overcome. The first duration separating the write command of the invention and the response to the write command is reduced to the sum of the duration required to transmit the write command from computer 10 to computer 11 and then to transmit the response, typically a simple acknowledgment, from computer 11 to computer 10. The second duration separating the read command of the invention and the response to the read command is reduced to the sum of the duration required to transmit the read command from computer 10 to computer 11 and then to transmit the response from computer 11 to computer 10. The third duration separating the end of the first duration and the start of the second duration does not pose a problem, since in the waiting step 106 of the method the state of the periodic signal simply needs to be read continuously until it is detected that it is ready. In particular, the method is reliable with respect to interruptions that may occur during said third duration, for example in the case of an electrical disconnection of the vehicle: the method according to the invention can be restarted within the step that was stopped before the interruption.

[0056] According to an alternative embodiment comprising step 112, in which computer 11 checks whether main command description 27 is complete, transition 117 is confirmed when main command description 27 is verified to be incomplete. Confirmation of transition 117 activates step 118, in which computer 11 stores an alert in second dedicated zone 62 and then sets the periodic signal to the ready state.

[0057] The interaction method according to the invention is applicable to main commands other than a main command for reading data in a first computer connected to the vehicle bus 2, during whose processing the computer 11 sends to the first computer a single auxiliary command, formed by a command for reading data, in response to the main command.

[0058] 4 shows the steps of the interaction method, in which computer 10 processes a main command, e.g. a command for installing a digital component in computer 12. This type of command serves, for example, to install one or more digital components. A digital component may equally relate to an executable program, a database, or any other digital structure, e.g. a source program or a table of configuration parameters.

[0059] Initially in a wait step 100, the computer 10 transitions to step 202 when an installation request submitted by a higher level method, for example a method for updating the computer 12, confirms transition 201. As an example, the installation request may contain an identifier for identifying a computer among the computers 12, 13, 14 connected to the vehicle bus 2, in this case the identifier of the computer 12. As another example, the installation request may contain a file, for example in HTML format, with tags identifying blocks of physical memory of the computer 12, each of which is written with the contents of the HTML file between two tags identifying the same physical memory block 64. The physical memory blocks are of a persistent rewritable memory type, for example an EEPROM type.

[0060] In step 202, the computer 10 constructs a description of the main command from the request that identified the transition 201 and then generates a write command for the description of the main command in the first dedicated data zone 61, which resides in the memory of the computer 11.

[0061] Fig. 2 shows an example of a write command, where field 31 of frame 21 successively identifies the generated command as a write command and field 32 successively identifies the first dedicated zone 61. In the description 27 of the main command, field 33 comprises, for example, the two letters "EI" indicating a main command of the "perform installation" type. In the example shown in Fig. 4, field 34 specifically identifies the target computer, for example computer 1, connected to bus 2, to which the main command applies in particular. Field 35 contains a parameter, the value of which identifies a packet containing at least one digital component that is to be installed in the target computer.

[0062] In the particular case of the use of a write command according to the UDS protocol, the field 31 then contains the SID $2E, which is the known hexadecimal code of the data written by the DID identifier, in this case corresponding to the private zone 61.

[0063] Transition 203 for transition from step 202 to step 204 is confirmed when computer 11 is detected as ready to respond to a write command supported by frame 21. Here again, if computer 11 performs a gateway function for another instance of the interaction method according to the invention or for a command generated by another method, for example a diagnostic method, it remains in a waiting state in step 202. Computer 10 does not unnecessarily congest bus 1 by attempting to send a command that would remain invalid because computer 11 is occupied by another function. In the example of ongoing processing of a diagnostic command specific to another method, putting the interaction method in a waiting state momentarily in step 202 allows the diagnostic command to be executed without having to interrupt the diagnostic method.

[0064] Whether the computer 11 is ready can be detected, for example, by a signal with two states, ready and occupied, which is periodically transmitted by the computer 11 through the bus 1 .

[0065] In an initial wait step 110, computer 11 sets the signal to a ready state by default. As soon as computer 11 receives a command, whether this is an interactive method according to the invention or any other method, e.g. a diagnostic method, computer 11 sets the signal to an occupied state until processing of the ongoing command is completed.

[0066] During step 204, computer 11 has been detected as being ready to respond to a write command, and computer 10 sends the write command to computer 11. To send the write command, computer 10 may encapsulate frame 21 within a CAN frame on bus 1, or alternatively, for example, within a frame on IP if a vehicle Ethernet protocol is used on bus 1.

[0067] Receipt of the write command at computer 11 confirms transition 211, which transitions computer 11 from initial step 110 to step 212, where computer 11 writes description 27 to the first dedicated zone 61 and then immediately transmits an acknowledgment of proper execution of the write command to computer 10. When the UDS protocol is used as an example, the acknowledgment of proper execution of the write command is represented by frame 22, in which field 37 contains the value $6E and field 38 contains the DID of zone 61.

[0068] The reception of frame 22 at computer 10 confirms transition 205 which transitions computer 10 from step 204 to step 206, in which computer 10 reads the state of the signal transmitted periodically by computer 11 while waiting to read the ready state. In an advantageous variant of the method according to the invention, the periodic signal also comprises an indication of the state of progress of the execution of the step at computer 11.

[0069] During step 212, computer 11 sets the periodic signal to an occupied state and then transmits a series of one or more first auxiliary commands to a computer of computers 12, 13, 14 identified in field 34, e.g. computer 12, to respond to the main command based on the description 27 of the main command written in the dedicated data zone 61 of computer 11. When the periodic signal also comprises an indication of the state of progress, computer 11 indicates the state of progress corresponding to step 212.

[0070] In the particular case of Fig. 4, where the main command is a command for installing at least one digital component on a computer, each first auxiliary command involves reading attributes of the computer 12, the knowledge of which serves to correctly install one or more digital components. The example shown in Fig. 2 can be used for the first auxiliary command, the command comprising a frame 25 with an identification field 48 for the read command and an identification field 49 for the resident data of the computer 12, which corresponds to the read attribute.

[0071] Receipt of the first auxiliary command in a series at computer 12 confirms transition 221 which activates step 222, where computer 12 transmits a response to each first received auxiliary command.

[0072] When the command is used according to the UDS protocol, field 48 contains the SID $22. Each response to the first auxiliary command on the model of frame 26 of FIG. 2 contains the SID $62 in field 50, an attribute identification in field 51, and a readout value of the attribute in field 52.

[0073] Receipt at computer 11 of the final response to the series of first auxiliary commands confirms transition 213 which transitions computer 11 from step 212 to step 214, where computer 11 sends a series of one or more second auxiliary commands to computer 12 to check that computer 12 is not troubled by any faults that would likely prevent installation of the digital component.

[0074] 2 shows an example of an auxiliary command comprising a frame 29 comprising an auxiliary command specification field 53 to which the auxiliary command relates, an identification field 54 for identifying a target within computer 12, and optionally a command extension field 55. For the second auxiliary command, the target is specifically a fault code.

[0075] Receipt of a series of second auxiliary commands at computer 12 confirms transition 223 which activates step 224, where computer 12 transmits a response to each second received auxiliary command.

[0076] When the command is used according to the UDS protocol, field 53 contains a SID $29 indicating the readout of DTC ("diagnostic trouble code") information. Field 54 contains a fault identification code, typically based on five alphanumeric characters. By way of purely non-limiting example, the first character is the letter P indicating the vehicle powertrain (e.g. comprising the engine and gearbox), the letter C indicating the vehicle chassis, the letter B indicating the vehicle body, and the letter U indicating the user network. Also by way of purely non-limiting example, the second character is the number 0 indicating a general fault, the number 1 indicating a manufacturing fault. The following characters refer to an element of a subsystem of the system, identified by the letters in the header of the fault code, e.g. P01xx for fuel and oxidizer measurement, P02xx for fuel and oxidizer measurement more specifically associated with the injection circuit, and P04xx for auxiliary emission control. Each response to the second auxiliary command, shown in the model of frame 30 in FIG. 2, includes an SID $59 in field 56, a fault code annotation in field 57, and a readout of the status of the fault code in field 59, e.g., fault or not fault.

[0077] When the periodic signal also comprises an indication of a state of progress, the computer 11 indicates in the field 59 the state of progress corresponding to fault or non-fault.

[0078] Receipt of the final response to the second series of auxiliary commands at computer 11 confirms transition 215, which transitions computer 11 from step 214 to step 216, where computer 11 sends a third auxiliary command to computer 12 to initiate the update session.

[0079] 2 may be used to represent a third auxiliary command, in which the target specifically involves closing an action performed on the computer 12.

[0080] Receipt of the third auxiliary command at the computer 12 confirms transition 225 which activates step 226 where the computer 12 transmits a response to the third received auxiliary command.

[0081] When the command is used according to the UDS protocol, field 53 contains an SID $10 indicating the control of the diagnostic session. As a reminder, the availability of the various services depends on the diagnostic session that is active. For example, a session called "extended diagnostic session" is used to release additional diagnostic functions, such as adjusting sensors. As another example, a session called "safety system diagnostic session" is used to test all diagnostic functions that are critical for safety, such as testing airbags. In the absence of a specific diagnostic session, a "default session" is generally active, in particular in step 120, and is maintained until transition 225 is confirmed. Field 54 contains a session identification code, which in this case is specifically dedicated to the installation of one or more digital components in computer 12, for example called "FOTA". The response to the third auxiliary command, shown in the model of frame 30 in FIG. 2, contains an annotation of SID $50 in field 56 and a session identification code in field 57. When the periodic signal also comprises a progress status indication, computer 11 indicates a progress status corresponding to the start of an update session.

[0082] Receipt of a response to the third auxiliary command at computer 11 confirms transition 217 which transitions computer 11 from step 216 to step 218, where computer 11 sends a fourth auxiliary command to computer 12 to check that there are no faults in the memory blocks of computer 12 with a view to using them to write digital component updates therein.

[0083] Frame 29 shown in Figure 2 may be used to represent a fourth auxiliary command, for which the target is specifically a memory fault code.

[0084] Receipt of the fourth auxiliary command at the computer 12 confirms transition 227 which activates step 228 where the computer 12 transmits a response to the fourth received auxiliary command.

[0085] When the command is used according to the UDS protocol, field 53 contains an SID $19 indicating a diagnosed fault reading. The response to the fourth auxiliary command, shown in model frame 30 of Figure 2, contains an SID $59 in field 56 and a fault code annotation in field 57. Field 59 contains a value indicating whether or not there is a fault identified by the code contained in field 57. When the periodic signal also comprises a progress status indication, computer 11 indicates a progress status corresponding to a condition related to the presence or absence of a fault contained in field 59.

[0086] Receipt of a response to the final, fourth auxiliary command at computer 11 confirms transition 219 which transitions computer 11 from step 218 to step 220 where computer 11 sends a series of fifth auxiliary commands to computer 12 to check that there are no faults in the memory block counters of computer 12 from the perspective of using them to write updates to the digital components to the memory blocks.

[0087] 2 may be used to represent each of the fifth auxiliary commands. For the fifth auxiliary command, the target is specifically the memory counter fault code.

[0088] Receipt of a fifth auxiliary command in a series at computer 12 confirms transition 229 which activates step 230, where computer 12 transmits a response to each fifth received auxiliary command.

[0089] When the command is used according to the UDS protocol, field 53 contains an SID $19 indicating a diagnosed fault reading. The response to each of the fifth auxiliary commands, shown in the model of frame 30 of Figure 2, contains an SID $59 in field 56 and a fault code annotation in field 57. Field 59 contains a value indicating whether or not there is a fault identified by the code contained in field 57. When the periodic signal also comprises a progress status indication, computer 11 indicates a progress status corresponding to a condition related to the presence or absence of a fault contained in field 59.

[0090] Figure 5 shows steps subsequent to those of Figure 4. Receipt at computer 11 of a response to the final, fifth auxiliary command sees transition 251 which transitions computer 11 from step 220 of the first loop to step 252, where computer 11 sends a sixth auxiliary command to computer 12 to read the starting address of the first memory block in the memory of computer 12.

[0091] 2 may be used to represent each of the sixth auxiliary commands. For the sixth auxiliary commands, the target is specifically a DID data reference relating to a memory block addressing register in computer 12.

[0092] Receipt of the sixth auxiliary command at the computer 12 confirms transition 261 which activates step 262 where the computer 12 transmits a response to the sixth received auxiliary command.

[0093] When the command is used according to the UDS protocol, field 53 contains SID $22 indicating the reading of data identified by the DID reference in field 54. The response to the sixth auxiliary command, shown in the model of frame 30 of Figure 2, contains SID $62 in field 56 and the annotation of the DID reference in field 57. Field 59 contains a value indicating the starting address of the first memory block to be provided for loading the first digital component therein.

[0094] Receipt of a response to the sixth auxiliary command at computer 11 confirms transition 253 which transitions computer 11 from step 252 to step 254 of the first loop, where computer 11 sends a seventh auxiliary command to computer 12 to write a reference to the first digital component into the header of the first memory block in the memory of computer 12.

[0095] 2 may be used to represent each of the seventh auxiliary commands. For the seventh auxiliary command, the target is specifically a DID reference to data relating to a digital component naming register in computer 12.

[0096] Receipt of the seventh auxiliary command at the computer 12 confirms transition 263 which activates step 264 where the computer 12 transmits a response to the seventh received auxiliary command.

[0097] When the command is used according to the UDS protocol, field 53 contains SID $2E indicating the writing of data identified by the DID reference in field 54. The response to the seventh auxiliary command, shown in the model of frame 30 in Figure 2, contains SID $6E in field 56 and an annotation of the DID reference in field 57. Field 59 contains a value indicating an acknowledgment of the write command.

[0098] Receipt of a response to the seventh auxiliary command at computer 11 confirms transition 255 which transitions computer 11 from step 254 to step 256 of the first loop, where computer 11 sends an eighth auxiliary command to computer 12 requesting that the digital component be loaded into the first memory block of computer 12.

[0099] Frame 29 shown in Figure 2 may be used to represent the eighth auxiliary command, for which the target is specifically the address of the first memory block.

[0100] Receipt of the eighth auxiliary command at computer 12 confirms transition 265 which activates step 266, where computer 12 deletes the contents of the ongoing memory block and then transmits a response to the eighth received auxiliary command acknowledging proper execution of the eighth command. It should be noted that in this case, a physical memory block of rewritable type needs to be deleted before being rewritten.

[0101] When the command is used according to the UDS protocol, field 53 contains SID $34 indicating a request to load from computer 11 to computer 12. Field 55 contains the size of the digital component to be loaded. The response to the eighth auxiliary command, shown in the model of frame 30 of FIG. 2, contains SID $74 in field 56 and annotated address of a memory block in field 57. Field 58 indicates the size of the digital component to be loaded. Field 59 contains a value indicating the maximum allowed load size.

[0102] Receipt of a response to the eighth auxiliary command at computer 11 confirms transition 257 which transitions computer 11 from step 256 to step 258 of the first loop, where computer 11 sends a ninth auxiliary command to computer 12 to transfer the contents of the digital component to the first memory block of computer 12.

[0103] Frame 29 shown in Figure 2 may be used to represent the ninth auxiliary command, for which the target is specifically the address of the first memory block.

[0104] Receipt of the ninth auxiliary command at the computer 12 confirms transition 267 which activates step 268 where the computer 12 transmits a response to the ninth received auxiliary command.

[0105] When the command is used according to the UDS protocol, field 53 contains SID $36, indicating a command to transfer the contents of the digital component to the current physical memory block. In known manner, the transfer is performed by packets of maximum size. If the size of the contents exceeds the maximum size of a packet, the transfer is repeated until all the contents have been sent. The response to the ninth auxiliary command, shown in the model of frame 30 in FIG. 2, contains an annotation of SID $76 in field 56 and the address of the memory block in field 57.

[0106] Receipt of a response to the ninth auxiliary command at computer 11 confirms transition 259 which transitions computer 11 from step 258 to step 260 of the first loop, where computer 11 sends a tenth auxiliary command to computer 12 to terminate the transfer.

[0107] Frame 29 shown in FIG. 2 may be used to represent a tenth auxiliary command.

[0108] Receipt of the tenth auxiliary command at computer 12 confirms transition 269 which activates step 270 where computer 12 transmits a response to the tenth received auxiliary command.

[0109] When the command is used according to the UDS protocol, field 53 contains SID $37, which indicates an end transfer mode command. The response to the ninth auxiliary command, shown in the model of frame 30 of Figure 2, contains SID $77 in field 56 and an annotation of the address of a memory block in field 57.

[0110] Receipt of a response to the tenth auxiliary command at computer 11 sees transition 291 which transitions computer 11 from step 260 of the first loop to step 292, where computer 11 checks whether there is a subsequent digital component to be loaded into a subsequent memory block.

[0111] The presence of a subsequent digital component validates transition 293 which loops the method back to re-executing steps 252 through 292, each matched to a subsequent physical memory block in terms of identity, size, and memory block address.

[0112] The absence of any digital components needing a subsequent physical memory block confirms transition 295 which activates step 296, where computer 11 sends an eleventh auxiliary command to computer 12 to check that there are no failures in writing the memory block of computer 12.

[0113] In this case, frame 29 shown in Figure 2 may also be used to represent an eleventh auxiliary command, for which the target is specifically a memory fault code.

[0114] Receipt of the eleventh auxiliary command at computer 12 confirms transition 271 which activates step 272 where computer 12 transmits a response to the eleventh received auxiliary command.

[0115] When the command is used according to the UDS protocol, field 53 contains an SID $19 indicating a diagnosed fault reading. The response to the eleventh auxiliary command, shown in model frame 30 of Figure 2, contains an SID $59 in field 56, and a fault code annotation in field 57. Field 59 contains a value indicating whether or not the fault identified by the code contained in field 57 is present.

[0116] Figure 6 shows the final steps of the method following those shown in Figure 5. Receipt of a response to the eleventh auxiliary command at computer 11 confirms transition 297 of a second loop that activates step 298, where computer 11 sends a twelfth auxiliary command to computer 12 for activating a first local program, where computer 12 checks that the first digital component has been correctly written to the first memory block in the memory of computer 12.

[0117] 2 may be used to represent each of the twelfth auxiliary commands. For the twelfth auxiliary command, the target, specifically registered in field 54, is a compressed program reference stored in memory within computer 12. Field 55 contains the address of the memory block to be checked.

[0118] Receipt of the twelfth auxiliary command at computer 12 confirms transition 273 which activates step 274, where computer 12 activates a compression program, which among other things involves calculating the compression of the contents written to the physical memory block. Computer 12 transmits a response to the twelfth received auxiliary command which includes the calculated compression. The response to the twelfth auxiliary command enables computer 11 to compare the compression calculated by computer 12 with the compression held by computer 11 before the contents were loaded into the physical memory block. In this way computer 11 can check that the contents of the physical memory block, after the rewrite, are consistent with the contents to be loaded into the physical memory block.

[0119] When the command is used according to the UDS protocol, field 53 contains a SID $31 indicating the activation of the program identified by the program reference in field 54. The response to the twelfth auxiliary command, shown in the model of frame 30 in Figure 2, contains an annotation of the SID $62 in field 56 and a DID reference in field 57. Field 59 contains a value indicating the starting address of the first memory block provided for loading the first digital component.

[0120] Receipt of a response to the sixth auxiliary command at the computer 11 confirms transition 299 which activates step 300, where the computer 11 checks whether a next physical memory block exists for the subsequent loading of the digital component.

[0121] The existence of a next physical memory block checks transition 301 which loops back to step 298 where the first block is replaced by the next block, and so on until the last physical memory block.

[0122] The absence of a next physical memory block confirms transition 303 which activates step 304, where computer 11 sends a thirteenth auxiliary command to computer 12 to read the memory of computer 12 for storing the detected fault.

[0123] Receipt of the thirteenth auxiliary command at computer 12 confirms transition 275 which activates step 276, where computer 12 transmits a response to the thirteenth received auxiliary command including any faults detected when executing the previous steps.

[0124] When the command is used according to the UDS protocol, field 53 contains SID $19, which indicates the reading of diagnostic trouble code (DTC) information. It should be noted that each DTC fault processed by computer 12 is stored with its own code in a dedicated memory of computer 12, called error memory, which can be read at any time. In connection with each fault, additional information is also stored, which can be read at any time, particularly related to the circumstances regarding the occurrence of the fault. The response to the thirteenth auxiliary command, shown in the model of frame 30 in FIG. 2, contains the SID $59 in field 56 and the annotation of the DID reference in field 57. Field 59 uses the contents of the error memory.

[0125] The receipt of a response to the thirteenth auxiliary command at the computer 11 confirms the transition 305 which activates a step 306, where the computer 11 sends a fourteenth auxiliary command to the computer 12. The effect of the fourteenth auxiliary command is to cause the computer 12 to terminate the open session of the step 216 so as to return it to the default session. Thus, between the steps 216 and 306, the computer 12 only takes into account commands originating from the computer 11 in the context of the interaction method described above in the context of Figs. 5 and 6, as there are many commands originating from the computer 11 in the context of another case of the interaction method described above in the context of Fig. 4, and also as there are commands received in the context of another method, for example a local or remote diagnostic method.

[0126] Receipt of the fourteenth auxiliary command at the computer 12 confirms transition 277 which activates step 278 where the computer 12 transmits a response to the fourteenth received auxiliary command.

[0127] When the command is used according to the UDS protocol, field 53 contains SID $10, indicating diagnostic session control. Field 54 contains the session identification code, which in this case is the "default session". The response to the fourteenth auxiliary command, shown in the model of frame 30 of Figure 2, contains an annotation of SID $50 in field 56 and the session identification code in field 57. When the periodic signal also comprises an indication of the state of progress, computer 11 indicates a state of progress corresponding to the end of the update session.

[0128] Receipt of a response to the fourteenth auxiliary command at computer 11 confirms transition 307 which transitions computer 11 from step 306 to step 308, where computer 11 sends a fifteenth auxiliary command to computer 12 to activate the second local program.

[0129] According to a first embodiment, the computer 12 comprises a single activatable bank of rewritable memory and two non-activatable banks of rewritable memory. The single activatable bank comprises a memory block containing digital components executed and / or accessed in real time by the on-board computer 12 when the vehicle is running. The first non-activatable bank comprises the memory block mentioned above for loading one or more updated digital components. The second non-activatable bank is used by a second local program, the execution of which involves copying the contents of the activatable bank to the second non-activatable bank when the vehicle is not running, before copying the contents of the first non-activatable bank to the single activatable bank, so as to activate the single activatable bank with the updated digital components the next time the vehicle is running.

[0130] According to a second embodiment, the computer 12 comprises two paired activatable banks of rewritable memory. The first paired activatable bank comprises memory blocks containing digital components executed and / or accessed in real time by the on-board computer 12 when the vehicle is running. The second paired activatable bank comprises the aforementioned memory blocks for loading one or more updated digital components. The execution of the second local program then involves switching from the first paired activatable bank to the second paired active bank to start real-time execution when the vehicle is not running, so that the next time the vehicle is running, the second paired activatable bank is activated with the updated digital components, while the second paired activatable bank operates as the first paired active bank, and vice versa.

[0131] It should be noted that all or some of the auxiliary commands preceding the fifteenth auxiliary command may be performed while the vehicle is moving. The two embodiments described above have the advantage of only requiring a short duration to switch the operation of the vehicle to execute and / or access the digital components in real time, in other words, to stop the vehicle from moving in order to update the digital components.

[0132] 2 may be used to represent the fifteenth auxiliary command, for which the target, specifically written into field 54, is a switching program reference stored in memory within computer 12.

[0133] Receipt of the fifteenth auxiliary command at computer 12 confirms transition 279 which activates step 280, where computer 12 activates the second local program, in other words the switching program, before sending a response to the fifteenth received auxiliary command that includes an acknowledgment of proper execution of the second local program. In this way computer 11 can check that computer 12 is ready for any future access and / or execution of the digital component that is read as up to date.

[0134] When the command is used according to the UDS protocol, field 53 contains SID $31 which indicates the activation of the program identified by the program reference in field 54. The response to the fifteenth auxiliary command, shown in the model of frame 30 in Figure 2, contains SID $62 in field 56.

[0135] Receipt of a response to the fifteenth auxiliary command at computer 11 confirms transition 309 which activates step 310, where computer 11 sets the periodic signal to a ready state. The periodic signal may also comprise a progress indicator in a phase that integrates several auxiliary commands. For example, computer 11 places a progress indicator in step 212 to indicate a parameter verification phase, in step 252 to indicate an ongoing installation phase, and in step 310 to indicate the end of the installation phase.

[0136] Receipt of the periodic signal in the ready state at the computer 10 validates transition 207, which reactivates the initial step 100 at the computer 10 while waiting for any other main command.

Claims

1. A method for interacting with a first on-board bus (1) in a vehicle, the method comprising the steps of: - connecting a first computer (12, 13, 14) which is not directly connected to a first on-board bus (1) in said vehicle directly to a second on-board bus (2) in said vehicle; - connecting said first on-board bus (1) in said vehicle to said second on-board bus (2) in said vehicle by means of a second computer (11) directly connected to said first on-board bus (1) in said vehicle and to said second on-board bus (2) in said vehicle; - connecting directly to the first on-board bus (1) in the vehicle a third computer (10) in the vehicle which is not directly connected to the second on-board bus (2) in the vehicle and which processes main commands intended for the first computer (12, 13, 14), - generating (102) by said third computer (10) a write command for writing (27) said main command description (27) to a first dedicated data zone (61) of said second computer (11); - when it is detected (103) that said second computer (11) is ready to respond to said write command, said third computer (10) sending (104) said write command to said second computer (11); - after said second computer (11) has received (111) said write command, sending (114) one or more auxiliary commands to said first computer (12, 13, 14) in response to said main command; - a step (122) of said first computer (12, 13, 14) sending a response to each received auxiliary command (121); - said second computer (11) storing (116) at least one received response (115) in a second dedicated data zone (62); - when it is detected (107) that said second computer (11) is ready to respond to a read command, said third computer (10) sending (108) said read command for reading said second dedicated data zone (62) intended for said second computer (11); - said second computer (11) sending (124) a response to said read command (119) received; - a step (126) of said third computer responding to said main command after receiving (109) at least one response to said read command for reading said second dedicated data zone of said second computer (11) in which said response sent by said first computer (12, 13, 14) is stored; Including, A signal having two states, READY and NOT READY, is periodically transmitted by the second computer (11) through the first vehicle bus (1), and the method further comprises: said second computer (11) receiving (111) said write command originating from said third computer (10), setting (112) said signal in a not ready state; - when said second computer (11) receives (115) said response originating from said first computer (12, 13, 14), it sets (116) said signal to a ready state; The method includes:

2. 2. The method of claim 1, further comprising the step of: the third computer (10) waiting (106) for the signal to be set to the ready state after receiving (105) the signal to be set to the not ready state.

3. 3. The method according to claim 1 or 2, characterized in that the signal also comprises one or more progresses of the auxiliary command sent by the second computer (11).

4. 4. The method according to claim 1, wherein the write command comprises a first frame (21), the first frame (21) comprising a first identifier field (31) for the write command, a first identifier field (32) for the first dedicated data zone (61), and at least one field (33, 34, 35) of the description (27) of the main command.

5. 5. The method according to claim 1, wherein the description (27) of the main command comprises a standard field (33) for the main command, an identification field (34) for the second computer (12, 13, 14) and a useful parameters field (35) for the second computer (12, 13, 14) for establishing the response to be sent.

6. 6. The method according to claim 1, further comprising a step (112) of the second computer (11) receiving (111) the write command and sending an acknowledgement intended for the first computer (10).

7. 7. The method of claim 6, wherein the acknowledgment comprises a second frame (22), the second frame (22) comprising an acknowledgment identifier field (37) and a second identifier field (38) for the first dedicated data zone (61).

8. 8. The method according to claim 1, wherein the read command sent by the third computer (10) comprises a third frame (23), the third frame (23) comprising a second command identification field (39) and a first identifier field (40) for the second dedicated data zone (62).

9. 9. The method according to claim 1, wherein the response to the read command comprises a fourth frame (24), the fourth frame (24) comprising a fourth identifier field (41) for the response to the read command, a second identifier field (42) for the second dedicated data zone (62), at least one descriptive annotation field (43, 44, 45) for the main command, and a content field (47) for the response to the main command.

10. 10. The method according to claim 1, wherein the read and write commands are commands according to the UDS (Unified Diagnostic Services) protocol.

11. a step (112) of said second computer (11) checking, upon receiving (111) said write command, whether said description of said main command is complete; - said second computer (11) sending (114) one or more auxiliary commands to said first computer (12, 13, 14) to respond to said main command only if said description of said main command is complete (113); - said second computer (11) storing (118) a warning in said second dedicated data zone if said description of said main command is not complete (117); The method of any one of claims 1 to 10, comprising:

12. 12. The method according to claim 1, wherein the main command is a command for reading resident data in the first computer, the auxiliary command comprises a fifth frame (25) with an identification field (48) for a read command and an identification field (49) for the resident data, and the response sent by the first computer (12, 13, 14) comprises a sixth frame (26) with an identification field (50) for a response to the read command, an identification field (51) for the resident data and a field (52) containing a value for the resident data.

13. 12. The method of claim 1, wherein the main command is a command for installing a digital component on the first computer.

Citation Information

Patent Citations

  • Repeating device

    JP2014230140A

  • In-vehicle relay device

    JP2016127449A

  • Repeating device, ECU, and on-vehicle system

    JP2017028523A

  • Communication device

    JP2017118317A