Method for dialog with a computer on a vehicle's on-board bus

Abstract

To dialogue from a first vehicle bus in a vehicle with a first computer connected to a second vehicle bus, the second vehicle bus being connected to the first bus by a second computer, where a main command is processed for the first computer, the method comprises the steps of: - a third computer connected to the first vehicle bus generates (102) a write command to write a description of the main command in a first dedicated area of the second computer, then sends (104) the write command to the second computer when detecting (103) that the second computer is ready to respond to the write command; - the second computer sends (114) one or more secondary commands to the first computer to respond to the main command after receiving (111) the write command; - the first computer sends (122) a response (121) to each received secondary command, which the second computer stores (116) in a second dedicated area; - when detecting (107) that the second computer is ready to respond to a read command to read the second dedicated area, the third computer sends (108) the read command to the second computer, so that the second computer sends (124) a response (119) to the received read command; - the third computer responds (126) to the main command when receiving (109) the response to the read command to read the second area of the second computer.

Description

Technical Field

[0001] This invention relates to a method for communicating with a computer on a vehicle's onboard bus. More specifically, this invention relates to a method for communicating with a first computer from a first onboard bus in a vehicle to a second onboard bus connected to the vehicle.

[0002] The method according to the invention is particularly useful for updating onboard computers while allowing real-time programs to be executed to operate the vehicle. Background Technology

[0003] Updating onboard computers and executing real-time programs typically requires transmitting commands on one or more onboard buses. Timers are usually implemented to control the duration between sending a command and receiving a response to that command; however, the downside is that the duration increases with the number of commands.

[0004] For example, document EP 1434129 A2 discloses a device for controlling the rewriting of in-vehicle programs, wherein the switching command is based on a signal derived from a timer. The disclosed device controls two operating modes: a normal mode, which can correspond to a diagnostic mode; and a rewrite mode for rewriting in-vehicle programs, which can be used for computer updates. The disclosed device switches from normal mode to rewrite mode upon receiving a program rewrite command from a server, and switches from rewrite mode to normal mode upon receiving a command to switch to normal mode during rewrite mode. Each switching operation has the disadvantage of exiting the current mode. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, the present invention provides a method for communicating between a first onboard bus in a vehicle and a first computer connected to a second onboard bus connected to the vehicle, the first bus being connected to the second bus by a second computer, wherein a third computer connected to the first onboard bus processes main commands for the first computer, the method comprising the following steps:

[0006] - The third computer generates a write command that writes the description of the main command into the first dedicated area of ​​the second computer;

[0007] - When the second computer is detected to be ready to respond to the write command, the third computer sends the write command to the second computer;

[0008] - After receiving the write command, the second computer sends one or more auxiliary commands to the first computer in response to the main command;

[0009] - The first computer sends a response to each received auxiliary command;

[0010] - The second computer stores each received response in a second dedicated area;

[0011] - When the second computer is detected to be ready to respond to a read command to read the second private area, the third computer sends the read command to the second computer;

[0012] - The second computer sends a response to the received read command;

[0013] - When the third computer receives at least one response to a read command to read a second area of ​​the second computer, the third computer responds to the main command, and the response sent by the first computer is stored in the second area.

[0014] Specifically, the second computer periodically sends signals indicating a ready and unready state, and the method includes the following steps:

[0015] - The second computer sets the signal to an occupied state when it receives a write command from the third computer;

[0016] - The second computer sets the signal to a ready state when it receives a response from the first computer.

[0017] Advantageously, the method includes the following steps: after receiving the signal that is set to the occupied state, the third computer enters standby mode to wait for the signal to be set to the ready state.

[0018] Specifically, the write command includes a first frame, which includes a first identifier field for the command, a first identifier field for the first dedicated area, and at least one description field for the main command.

[0019] More specifically, the description of the master command includes standard fields for the master command, an identification field for the second computer, and a data identification field useful for the second computer to establish the response sent.

[0020] More specifically, the method includes the following steps: the second computer sends an acknowledgment to the first computer upon receiving the write command.

[0021] More specifically, the confirmation includes a second frame, which includes a confirmation identifier field and a second identifier field for the first dedicated area.

[0022] More specifically, the read command sent by the third computer includes a third frame, which includes a second command identifier field and a first identifier field for the second private area.

[0023] More specifically, the response to the read command includes a fourth frame, which includes a fourth identifier field for the response to the command, a second identifier field for the second dedicated area, at least one descriptive comment field for the main command, and a content field for the response sent by the first computer.

[0024] Specifically, the main command is a command for reading resident data in the first computer. The auxiliary command includes a fifth frame, which includes an identifier field for the read command and an identifier field for the resident data, such that the response sent by the first computer includes a sixth frame, which includes an identifier field for the response to the read command, an identifier field for the resident data, and a field containing the value of the resident data.

[0025] Preferably, these read commands and these write commands are commands that conform to the UDS (Unified Diagnostic Services) protocol.

[0026] The method may also include the following steps:

[0027] - When the second computer receives the write command, it checks whether the description of the main command is complete;

[0028] - The second computer sends one or more auxiliary commands to the first computer in response to the main command only when the description of the main command is complete;

[0029] - If the description of the main command is incomplete, the second computer stores a warning in the second dedicated area. Attached Figure Description

[0030] Further advantages and features of the invention will become apparent from the detailed description of embodiments provided in a non-limiting manner with reference to the accompanying drawings, in which:

[0031] [ Figure 1 ] Figure 1 A vehicle-mounted system implementing the present invention is illustrated schematically;

[0032] [ Figure 2 ] Figure 2 The command frame for implementing the present invention is illustrated schematically;

[0033] [ Figure 3 ] Figure 3 The steps of a method for processing a master read command according to the present invention are shown;

[0034] [ Figure 4 ] Figure 4 The steps of a first method for processing a master installation command according to the present invention are shown;

[0035] [ Figure 5 ] Figure 5 The steps of a second part of the method for processing a master installation command according to the present invention are shown;

[0036] [ Figure 6 ] Figure 6 The steps of the third and final parts of the method for processing the master installation command according to the present invention are shown. Detailed Implementation

[0037] Figure 1 Two computers 9 and 10 connected to vehicle bus 1 in the vehicle are shown, and three computers 12, 13, and 14 connected to vehicle bus 2 in the vehicle. Computer 9 is, for example, an on-board computer dedicated to IVC (In-Vehicle Communication) type communications. Computer 10 is, for example, an IVI (In-Vehicle Infotainment) type on-board computer with a processing power comparable to that of a microcomputer. Other on-board computers, not shown, may be connected to vehicle bus 1. Computers 12, 13, and 14 connected to vehicle bus 2 are preferably ECU (Electronic Control Unit) type on-board computers for controlling and commanding vehicle components. Computer 11 connected to vehicle bus 1 and vehicle bus 2 performs a gateway function between the two on-board buses.

[0038] Figure 3 The steps of the dialogue method are illustrated, in which computer 10 processes a master command for reading resident data in one of computers 12, 13, and 14 (e.g., computer 12). For example, this type of command is useful for reading references or version numbers of digital components in computer 12, in order to determine, for example, whether the digital component needs to be updated. The digital component can also relate to an executable program, a database, or any other digital structure, such as, for example, a source program or a parameter table.

[0039] Computer 10 is initially in standby step 100, transitioning to step 102 when a read request submitted via a higher-order method (e.g., a method for updating computer 12) triggers transition 101. As an example, the read request may contain an identifier (in this case, the identifier of computer 12) used to identify the computer from among computers 12, 13, and 14 connected to the vehicle bus 2. The computer identifier may consist of a computer address conforming to the communication protocol of bus 2 (CAN (Controller Area Network), FlexRay, or TTP type, which are also well-known in aviation, automotive Ethernet, or other fields). The computer identifier may also consist of ASCII strings that name the computer according to its functional scope, such as "BCM" (Body Control Module), "HEVC" (Hybrid Electric Vehicle Controller), "VDC" (Vehicle Dynamics Control), etc. The advantage of ASCII strings is their ability to specify computers independent of the vehicle system architecture. Another advantage of ASCII strings involves forming a mnemonic device that is more easily understood by humans. As another example, the read request may contain a data identifier 63 from the identified computer.

[0040] In step 102, computer 10 establishes a description of the main command based on the request that triggers transition 101, and then generates a write command for writing the description of the main command into a first dedicated data area 61 residing in the memory of computer 11.

[0041] Figure 2 An example of a write command including frame 21 is shown. Frame 21 includes an identifier field 31 that identifies the generated command as a write command, an identifier field 32 that identifies the first private area 61, and at least one field 33, 34, 35 for containing a description 27 of the main command.

[0042] Field 33 of description 27 provides the type of main command. By way of non-limiting illustration, the type of main command may be identified, for example, by two letters in ASCII code. The first letter identifies the category of the main command: "E" for "execute," "R" for "read," or "W" for "write." The second letter, combined with the first letter, identifies the operation within the main command category: "EA" for "execute activation," "ED" for "execute download," "EI" for "execute installation," "EC" for "execute deletion," "ER" for "execute reinitialization," "RD" for "read data," "RX" for "read extended data," and "WD" for "write data." Field 34 of description 27 provides the on-board computer identifier, specifically as indicated in the request. Field 35 of description 27 contains parameters useful for executing commands. As an example, when field 33 contains one of the command types "EI" or "EA," these parameters are identifiers of the digital components to be installed and activated, respectively. Figure 3 In the example shown, the description 27 of the main command includes a field 33 that provides a main command of type "RD", an identification field 34 for the computer connected to bus 2 (e.g., the function name of computer 12), and a parameter field 35 that contains an identifier of data that is read as a parameter useful for the auxiliary processing of the main command of computer 11.

[0043] More specifically, using write commands conforming to the UDS (Unified Diagnostic Services) protocol has the advantage of benefiting from mechanisms typically pre-installed in most onboard computers in the motor vehicle field, particularly for performing diagnostic functions, without having to modify the low-level communication layer to implement the dialogue method according to the invention. In this particular case, field 31 then contains the SID (Service Identifier) ​​$2E, which is the known hexadecimal code of the data written by the DID identifier.

[0044] When computer 11 is detected to be ready to respond to a write command supported by frame 21, transition 103 is triggered for the transition from step 102 to step 104. In this way, if computer 11 is performing gateway functionality for another instance of the dialogue method according to the invention, or for a command generated by another method (such as, for example, a diagnostic method), the computer remains in standby mode in step 102. Computer 10 will not unnecessarily congest bus 1 by attempting to send commands that would become invalid due to computer 11 being occupied by other functions. In the example where a diagnostic command specific to another method is being processed, temporarily placing the dialogue method in standby mode in step 102 allows the execution of the diagnostic command without interrupting the diagnostic method.

[0045] Several solutions can be envisioned to detect whether computer 11 is ready to respond to the write command supported by frame 21. For example, in the case where computer 10 will be the only computer communicating with computer 11 on bus 1, the upper-level sorting layer in computer 10 can control the ready or unready state of computer 11. This solution becomes difficult to implement when another computer 9 will communicate with computer 11 via bus 1, for example, to perform remote diagnostics. In other cases, computer 10 can, for example, observe bus 1 to detect frames therein for computer 11, as a result of which computer 11 will not be ready to respond to the write command supported by frame 21. This alternative solution will quickly introduce problems related to complexity when multiple methods are used to access the channel of bus 1. Other solutions can be envisioned without departing from the scope of the invention.

[0046] According to a preferred solution for detecting whether computer 11 is ready, it is computer 11 itself that declares whether it is ready to process commands sent within the scope of the dialogue method according to the invention. Computer 11 periodically sends signals via bus 1 that include two states: ready, occupied (or not ready).

[0047] In the initial standby step 110, the computer 11 defaults to setting the signal to the ready state. Once the computer 11 receives a command, whether from the dialogue method according to the invention or from any other method (such as, for example, a diagnostic method), the computer 11 sets the signal to the occupied state until the processing of the current command is completed.

[0048] In step 104, when it is detected that computer 11 is ready to respond to the write command, computer 10 sends the write command to computer 11. In order to send the write command, computer 10 may encapsulate frame 21 as a CAN frame on bus 1, or in other ways, such as encapsulating frame 21 as an IP frame if an automotive Ethernet protocol is used on bus 1.

[0049] The receipt of a write command in computer 11 triggers transition 111, which is required to transition computer 11 from initial step 110 to step 114, in which computer 11 sends an auxiliary command to the computer identified in field 34 (e.g., computer 12) of computers 12, 13, and 14 to respond to the main command based on the description 27 of the main command written in the dedicated data area 61 of computer 11.

[0050] exist Figure 3 The master command is a specific command used to read resident data in computer 12. Figure 2 An example of an auxiliary command is provided, which includes frame 25, which includes an identification field 48 for a read command and an identification field 49 for resident data in computer 12.

[0051] More specifically, using a read command conforming to the UDS protocol has the advantages described above. In this particular case, field 48 then contains SID $22, which is the known hexadecimal code of the data read by the DID identifier. Field 49 contains the DID identifier of the data area 63 of computer 12 indicated in field 35 of frame 21.

[0052] Transition 111 can directly transition the method from initial step 110 to step 114. Preferably, but not necessarily, transition 111 transitions the method from initial step 110 to intermediate step 112.

[0053] In step 112, computer 11 checks whether the description 27 of the main command is complete in terms of predetermined security rules that are not part of the subject matter of this invention. If step 112 is implemented and the description 27 of the main command is verified to be complete, transition 113 is triggered; otherwise, if the description 27 of the main command is verified to be incomplete, transition 117 is triggered. Step 114 is then activated after transition 113 is triggered.

[0054] In step 114 or starting from step 112 (if present), in other words, after triggering transition 111 by receiving a write command from computer 10, computer 11 puts a periodic signal into an occupied state. Simultaneously, computer 11 responds to the write command by sending a receive acknowledgment or confirmation. For example, when using the UDS protocol, computer 11 sends frame 22, whose first field 37 contains a SID code with the value $6E, and whose second field 38 contains the value of field 32 of frame 21, allowing computer 10 to identify the sent write command corresponding to the received receive acknowledgment. In other words, field 38 forms an identifier field for the first dedicated area 61.

[0055] The reception of a periodic signal or frame 22 set to an occupied state by computer 10 triggers transition 105 in computer 10, which transitions the method from step 104 to step 106. In step 106, computer 10 is placed in standby mode to wait for a signal to be set to a ready state.

[0056] When computer 12, initially in standby step 120 of the dialogue method according to the invention, receives an auxiliary command represented by frame 25 sent by computer 11 via vehicle bus 2, it triggers transition 121. The triggering of transition 121 activates step 122, in which computer 12 sends a response to the received auxiliary command. The response sent to computer 11 includes frame 26, which includes a response identification field 50 (in this case, a response to a read command), an identification field 51 for the resident data, and a field 52 containing the value of the resident data 63 identified by field 51, such as... Figure 2 As shown.

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

[0058] The receipt of the response by computer 11 triggers transition 115, which moves the dialogue method from step 114 to step 116. In step 116, computer 11 generates a description 28 of the response to the main command, in this case, a command to read resident data 63 from computer 12. The response description 28 includes fields 43, 44, and 45, each containing the values ​​of fields 33, 34, and 35 of the command description 27, respectively, to identify that the response description indeed corresponds to the description of the main command. The response description 28 also includes field 47, which contains the value contained in field 52 of frame 26. Computer 11 stores the response description 28 in a second dedicated data area 62 residing in the memory of computer 11.

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

[0060] When computer 10 detects that computer 11 is ready to respond, transition 107 is triggered. In a preferred embodiment of the invention, transition 107 is triggered by receiving a periodic signal indicating that the computer is in a ready state.

[0061] The triggering of transition 107 activates step 108 in computer 10. In step 108, upon detecting that computer 11 is ready to respond to a read command, computer 10 sends a command to computer 11 to read from the second dedicated area 62. For example, the read command is represented by frame 23, such as... Figure 2 As shown. Frame 23 includes an identifier field 39 for identifying the command as a read command and an identifier field 40 for the second private data area 62.

[0062] Specifically, where the UDS protocol is used, field 39 contains the value $22 that identifies the read command, and field 40 contains the DID value that serves as the address of a dedicated data area 62 in the memory of computer 11.

[0063] When computer 11 receives a read command represented by frame 23, transition 119 is triggered.

[0064] The triggering of transition 119 activates step 124, in which computer 11 sends a response to computer 10. The response to the received read command includes frame 24, which includes an identifier field 41 for identifying the response to the read command and an identifier field 42 for identifying the second private area 62, so as to be able to check whether frame 24 constitutes a response to the read command represented by frame 23. Frame 24 then includes description 28, which includes fields 43, 44, and 45, each containing a value equal to the value contained in each of fields 33, 34, and 35, respectively, to indicate the description of the main command. Description 28 also includes field 47, which contains the response to the main command.

[0065] Computer 11 then returns to the initial standby step 110 regarding the dialogue method according to the present invention.

[0066] When computer 10 receives a response to a read command represented by frame 24, transition 109 is triggered.

[0067] The triggering 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 to the second private area of ​​computer 11, where the response sent by computer 12 is stored.

[0068] Computer 10 then returns to the initial standby step 100 regarding the dialogue method according to the present invention.

[0069] As disclosed above, using the UDS protocol for commands in the dialogue method according to the present invention allows processing of the main commands forming the computer update method without having to switch from diagnostic mode to update mode. These commands remain diagnostic commands in the dialogue between computers. Processing of the update function is performed by processing the main commands in the upper-level computer 10 in a manner equivalent to processing of the diagnostic function. As a gateway, computer 11 can process frames associated with the diagnostic function by directly passing frames associated with the diagnostic function from bus 1 to bus 2 (and vice versa). Computer 11 can process frames associated with the diagnostic function by processing them through the diagnostic function residing in computer 11. Computer 11 can process frames associated with the update function residing in computer 11 by processing them through the update function residing in computer 11, just as it would for the diagnostic function residing in computer 11. A single protocol stack (i.e., the UDS protocol stack) is sufficient to handle both pure diagnostic commands and update commands. When a pure diagnostic command is sent from bus 1 to bus 2 in the absence of a command associated with updating the digital component, computer 11 sets a periodic signal to an occupied state, simply placing update-related commands that would occur while processing pure diagnostic commands into a waiting state. When an update-related command is sent from bus 1 to bus 2 in the absence of a pure diagnostic command, computer 11 sets the periodic signal to the idle state, simply ignoring the pure diagnostic command that would occur when processing commands related to digital component updates, so that when computer 11 returns the periodic signal to the ready state, the diagnostic method is free to resend the pure diagnostic command.

[0070] The sending of read and write commands related to the processing of master commands from computer 10 connected to the vehicle bus 1 does not require receiving commands from a remote server, so that the update process can be restarted immediately after the periodic signal is set to a ready state. Therefore, the update process can occur without a remote connection to the vehicle, provided that the update data has been previously downloaded to computer 10.

[0071] The above description, which has been provided by way of explaining the update process that runs parallel to the diagnostic process, is also applicable to other processes that run parallel to the diagnostic process by implementing the dialogue method according to the invention.

[0072] When the main command of the dialogue method is used to read data from one of the computers 12, 13, and 14 connected to bus 2, it can be more simply implemented by a single command directly targeting the computer (e.g., computer 12) hosting the data in computer 12, 13, or 14. However, this a priori simpler solution presents a problem in managing the total duration between the sending of the single read command and the receiving of the response, which would be the sum of the durations required for the following operations: sending a single read command from computer 10 to computer 11, then sending a single read command from computer 11 to computer 12, receiving a response from computer 12, receiving a response from computer 12 to computer 11, and then receiving a response from computer 11 to computer 10. If activity on buses 1 and 2 is frequent (as often happens in running vehicles), this total duration can quickly become excessive.

[0073] Replacing a single read command with a write command in the first dedicated data area of ​​computer 11, followed by a read command in the second dedicated data area of ​​computer 11, allows the avoidance of the excessively long duration problem that occurred in the previous stage. The first duration between a write command and a response to a write command in this invention is reduced to the sum of the duration required to send the write command from computer 10 to computer 11, and then to send the response (typically a simple acknowledgment) from computer 11 to computer 10. The second duration between a read command and a response to a read command in this invention is reduced to the sum of the duration required to send the read command from computer 10 to computer 11, and then to send the response from computer 11 to computer 10. The third duration between the end of the first duration and the beginning of the second duration is not important because in the waiting step 106 of the method, it is only necessary to continuously read the state of the periodic signal until it is detected as ready. In particular, the method is reliable against interruptions that will occur during the third duration (e.g., in the case of a vehicle power outage). The method according to the invention can restart in the step that was stopped before the interruption.

[0074] According to an alternative embodiment including step 112, in which the computer 11 checks whether the description 27 of the main command is complete, and when the description 27 of the main command is verified to be incomplete, a transition 117 is triggered. The triggering of transition 117 activates step 118, in which the computer 11 stores a warning in the second dedicated area 62 and then sets a periodic signal to a ready state.

[0075] The dialogue method according to the invention is applicable to main commands other than the main command for reading data in the first computer connected to the vehicle bus 2. During its processing, the computer 11 sends a single auxiliary command consisting of a command for reading data to the first computer in response to the main command.

[0076] Figure 4 The steps of the dialog method are illustrated, in which computer 10 processes a master command, which is a command for, for example, installing a digital component in computer 12. This type of command is useful, for example, for installing one or more digital components. The digital component may also involve an executable program, a database, or any other digital structure, such as, for example, a source program or a configuration parameter table.

[0077] Computer 10 is initially in standby step 100, transitioning to step 202 when an installation request submitted via a higher-order method (e.g., a method for updating computer 12) triggers transition 201. As an example, the installation request may contain an identifier (in this case, the identifier of computer 12) used to identify the computer from among computers 12, 13, and 14 connected to the vehicle bus 2. As another example, the installation request may contain an HTML-formatted file, for example, with tags identifying physical memory blocks of computer 12, the contents of which are written in each block between two tags identifying the same physical memory block 64. The physical memory block is a rewritable permanent memory type, such as an EEPROM.

[0078] In step 202, computer 10 establishes a description of the main command according to the request that triggers transition 201, and then generates a write command for writing the description of the main command into the first dedicated data area 61 residing in the memory of computer 11.

[0079] Figure 2 An example of a write command is shown, for which field 31 of frame 21 always identifies the generated command as a write command, and field 32 always identifies the first private area 61. In the description 27 of the main command, field 33 includes, for example, the two letters "EI" indicating a main command of the type "Execute Installation". Figure 4 In the example shown, field 34 specifically identifies the target computer, such as computer 1, to which the master command connected to bus 2 is applied. Field 35 contains a parameter whose value identifies a package containing at least one digital component to be installed in the target computer.

[0080] In the specific case of using a write command conforming to the UDS protocol, field 31 then contains SID $2E, which is the known hexadecimal code of the data written by the DID identifier, corresponding in this case to private area 61.

[0081] When computer 11 is detected to be ready to respond to a write command supported by frame 21, transition 203 is triggered for the transition from step 202 to step 204. Similarly, if computer 11 is performing gateway functionality for another instance of the dialogue method according to the invention, or for a command generated by another method (such as, for example, a diagnostic method), the computer remains in standby mode in step 202. Computer 10 will not unnecessarily congest bus 1 by attempting to send commands that would become invalid due to computer 11 being occupied by other functions. In the example where a diagnostic command specific to another method is being processed, temporarily placing the dialogue method in standby mode in step 202 allows the execution of the diagnostic command without interrupting the diagnostic method.

[0082] For example, whether computer 11 is ready can be detected by signals that include two states: ready and occupied, which are periodically sent by computer 11 through bus 1.

[0083] In the initial standby step 110, the computer 11 defaults to setting the signal to the ready state. Once the computer 11 receives a command, whether it is the dialogue method according to the present invention or any other method (such as, for example, a diagnostic method), the computer 11 sets the signal to the occupied state until the processing of the current command is completed.

[0084] During step 204, when it is detected that computer 11 is ready to respond to the write command, computer 10 sends the write command to computer 11. In order to send the write command, computer 10 may encapsulate frame 21 as a CAN frame on bus 1, or in other ways, such as encapsulating frame 21 as an IP frame if an automotive Ethernet protocol is used on bus 1.

[0085] Receiving a write command in computer 11 triggers transition 211, which moves computer 11 from initial step 110 to step 212. In step 212, computer 11 writes description 27 to the first dedicated area 61 and then immediately sends an acknowledgment to computer 10 confirming the successful execution of the write command. As an example, when using the UDS protocol, the acknowledgment of the successful 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 area 61.

[0086] Receiving frame 22 in computer 10 triggers transition 205, which moves computer 10 from step 204 to step 206, in which computer 10 reads the status of signals periodically sent by computer 11 while waiting to read the ready status. In an advantageous variant of the method according to the invention, the periodic signals also include indications of the progress status of step execution in computer 11.

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

[0088] exist Figure 4 In specific cases, where the main command is used to install at least one digital component in the computer, each first auxiliary command involves reading attributes of the computer 12, knowledge of which is useful for the correct installation of one or more digital components. The first auxiliary commands can use... Figure 2 The example provided includes frame 25, which includes an identification field 48 for a read command and an identification field 49 for resident data in computer 12, which corresponds to the attributes being read.

[0089] The computer 12's receipt of a series of first auxiliary commands triggers a transition 221 of activation step 222, in which the computer 12 sends a response to each received first auxiliary command.

[0090] When using commands conforming to the UDS protocol, field 48 contains SID $22. For each response to the first auxiliary command ( Figure 2 The model in frame 26 contains SID $62 in field 50, the attribute identifier in field 51, and the attribute read value in field 52.

[0091] The receipt of the last response of computer 11 to a series of first auxiliary commands triggers transition 213, which transitions computer 11 from step 212 to step 214, in which computer 11 sends a series of one or more second auxiliary commands to computer 12 to check that computer 12 is not being interfered with by a fault that could hinder the installation of digital components.

[0092] Figure 2 An example of an auxiliary command is provided, which includes frame 29, comprising an auxiliary command specification field 53, an identification field 54 for identifying a target in computer 12 associated with the auxiliary command, and incidentally, the auxiliary command may or may not include a command extension field 55. For a second auxiliary command, the target is specifically a fault code.

[0093] The computer 12's receipt of a series of second auxiliary commands triggers a transition 223 to activation step 224, in which the computer 12 sends a response to each received second auxiliary command.

[0094] When using commands compliant with the UDS protocol, field 53 contains SID $29 indicating a read of DTC (“Diagnostic Trouble Code”) information. Field 54 contains a fault identification code typically based on five alphanumeric characters. As a non-limiting example only, the first character is the letter P, indicating the vehicle's powertrain (e.g., including the engine and transmission); C, indicating the vehicle chassis; B, indicating the body; and U, indicating the user network. Furthermore, as a non-limiting example only, the second character is a number, with 0 indicating a general fault and 1 indicating a manufacturing fault. The following characters refer to elements of a subsystem of the system identified by the letters in the fault code header; for example, P01xx indicates fuel and oxidizer measurements, P02xx indicates fuel and oxidizer measurements more specifically associated with the injection circuitry, and P04xx indicates auxiliary emission controls. Figure 2 Each response to the second auxiliary command shown on the model of middle frame 30 includes SID $59 in field 56, a note for the fault code in field 57, and a read value for the fault code status in field 59, such as fault or non-fault.

[0095] When the periodic signal also includes an indication of the progress status, the computer 11 indicates the progress status corresponding to the fault or non-fault status contained in field 59.

[0096] The receipt of the last response of a series of second auxiliary commands by computer 11 triggers a transition 215 that moves computer 11 from step 214 to step 216, in which computer 11 sends a third auxiliary command to computer 12 to initiate an update session.

[0097] Figure 2 Frame 29 shown can be used to represent a third auxiliary command. For the third auxiliary command, the target specifically relates to shutting down the operation being performed in computer 12.

[0098] The computer 12's receipt of the third auxiliary command triggers transition 225 of activation step 226, in which the computer 12 sends a response to the received third auxiliary command.

[0099] When using commands conforming to the UDS protocol, field 53 contains the SID $10, indicating the control of the diagnostic session. It is important to note that the availability of various services depends on the active diagnostic session. For example, a session called the "Extended Diagnostic Session" is used to release additional diagnostic functions, such as, for example, sensor adjustments. As another example, a session called the "Safety System Diagnostic Session" is used to test all safety-critical diagnostic functions, such as, for example, testing airbags. In the absence of a specific diagnostic session, the "Default Session" is typically active, particularly in step 120, and remains active until transition 225 is triggered. Field 54 contains a session identification code, in this case, specifically dedicated to installing one or more digital components, such as those called "FOTA," on computer 12. Figure 2 The response to the third auxiliary command shown on the model of mid-frame 30 includes a comment on SID $50 in field 56 and the session identification code in field 57. When the periodic signal also includes an indication of the progress status, computer 11 indicates the progress status corresponding to the initiation of the update session.

[0100] The receipt of the response of computer 11 to the third auxiliary command triggers a transition 217 that moves computer 11 from step 216 to step 218, in which computer 11 sends a fourth auxiliary command to computer 12 to check for faults in the memory blocks of computer 12 in order to use them to write updates of digital components therein.

[0101] Figure 2 Frame 29 shown can be used to represent a fourth auxiliary command. The target of this fourth auxiliary command is specifically a memory fault code.

[0102] The computer 12's receipt of the fourth auxiliary command triggers transition 227 of activation step 228, in which the computer 12 sends a response to the received fourth auxiliary command.

[0103] When using commands compliant with the UDS protocol, field 53 contains the SID $19 indicating a read with a diagnosed fault. Figure 2 The response to the fourth auxiliary command shown on the model of frame 30 includes a note in field 56 for SID $59 and in field 57 for the fault code. Field 59 contains a value indicating whether the fault identified by the code included in field 57 exists or does not exist. When the periodic signal also includes an indication of the progress status, computer 11 indicates the progress status corresponding to the status in field 59 related to the presence or absence of the fault.

[0104] The receipt of the response of computer 11 to the last fourth auxiliary command triggers transition 219, which transitions computer 11 from step 218 to step 220, in which computer 11 sends a series of fifth auxiliary commands to computer 12 to check for the absence of faults in the memory block counters of computer 12 in order to use them to write updates of digital components in the memory block.

[0105] Figure 2 Frame 29 shown can be used to represent each of the fifth auxiliary commands. For the fifth auxiliary command, the target is specifically a memory counter fault code.

[0106] The computer 12's receipt of a series of fifth auxiliary commands triggers a transition 229 of activation step 230, in which the computer 12 sends a response to each received fifth auxiliary command.

[0107] When using commands compliant with the UDS protocol, field 53 contains the SID $19 indicating a read with a diagnosed fault. Figure 2 The response to each fifth auxiliary command shown on the model of frame 30 includes a note in field 56 for SID $59 and field 57 for the fault code. Field 59 contains a value indicating whether the fault identified by the code included in field 57 exists or does not exist. When the periodic signal also includes an indication of the progress status, computer 11 indicates the progress status corresponding to the status in field 59 related to the presence or absence of the fault.

[0108] Figure 5 It shows Figure 4 The steps following the steps. The receipt of the response of computer 11 to the last fifth auxiliary command triggers a transition 251 that transitions computer 11 from step 220 to step 252 of the first loop, in which 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.

[0109] Figure 2 Frame 29 shown can be used to represent each sixth auxiliary command. For the sixth auxiliary command, the target is specifically a DID data reference associated with the memory block addressing register in computer 12.

[0110] The computer 12's receipt of the sixth auxiliary command triggers transition 261 of activation step 262, in which the computer 12 sends a response to the received sixth auxiliary command.

[0111] When using commands compliant with the UDS protocol, field 53 contains SID $22 indicating a read of data identified by the DID reference in field 54. Figure 2The response to the sixth auxiliary command shown on the model of middle frame 30 includes a note with SID$62 in field 56 and DID references in field 57. Field 59 contains a value indicating the starting address of the first memory block provided for loading the first digital component therein.

[0112] The receipt of the response of computer 11 to the sixth auxiliary command triggers a transition 253 that moves computer 11 from step 252 of the first loop to step 254, in which computer 11 sends a seventh auxiliary command to computer 12 for writing a reference to the first digital component in the header of the first memory block in the memory of computer 12.

[0113] Figure 2 Frame 29 shown can be used to represent each seventh auxiliary command. For the seventh auxiliary command, the target is specifically a DID data reference associated with the digital component name register in computer 12.

[0114] The computer 12's receipt of the seventh auxiliary command triggers transition 263 of activation step 264, in which the computer 12 sends a response to the received seventh auxiliary command.

[0115] When using commands compliant with the UDS protocol, field 53 contains SID $2E indicating a write to data identified by the DID reference in field 54. Figure 2 The response to the seventh auxiliary command shown on the model in frame 30 includes a comment with SID$6E in field 56 and DID references in field 57. Field 59 contains a value indicating confirmation of the write command.

[0116] The receipt of the response of computer 11 to the seventh auxiliary command triggers a transition 255 that moves computer 11 from step 254 of the first loop to step 256, in which computer 11 sends an eighth auxiliary command to computer 12 to request that digital components be loaded into the first memory block of computer 12.

[0117] Figure 2 Frame 29 shown can be used to represent the eighth auxiliary command. For the eighth auxiliary command, the target is specifically the address of the first memory block.

[0118] The computer 12's receipt of the eighth auxiliary command triggers transition 265 of activation step 266, in which the computer 12 deletes the contents of the current memory block and then sends a response to the received eighth auxiliary command, which triggers the correct execution of the eighth command. It is important to note in this case that a rewritable physical memory block needs to be deleted before rewriting.

[0119] When using commands conforming to the UDS protocol, field 53 contains the SID $34 representing the request to load from computer 11 to computer 12. Field 55 contains the size of the digital component to be loaded. Figure 2 The response to the eighth auxiliary command shown on the model of frame 30 includes a comment for SID $74 in field 56 and the address of the memory block in field 57. Field 58 comments on the size of the digital component to be loaded. Field 59 contains a value indicating the maximum acceptable load size.

[0120] The receipt of the response of computer 11 to the eighth auxiliary command triggers a transition 257 that transitions computer 11 from step 256 of the first cycle to step 258, in which computer 11 sends a ninth auxiliary command to computer 12 for transferring the contents of the digital components to the first memory block of computer 12.

[0121] Figure 2 Frame 29 shown can be used to represent the ninth auxiliary command. For the ninth auxiliary command, the target is specifically the address of the first memory block.

[0122] The computer 12's receipt of the ninth auxiliary command triggers transition 267 of activation step 268, in which the computer 12 sends a response to the received ninth auxiliary command.

[0123] When using commands conforming to the UDS protocol, field 53 contains the SID $36 of the command indicating that the contents of the digital component are being transferred to the current physical memory block. In a known manner, transfers are performed in packets of maximum size. If the content size exceeds the maximum packet size, the transfer is repeated until all content has been sent. Figure 2 The response to the ninth auxiliary command shown on the model of middle frame 30 includes a note on SID $76 in field 56 and the address of the memory block in field 57.

[0124] The receipt of the response of computer 11 to the ninth auxiliary command triggers a transition 259 that moves computer 11 from step 258 of the first loop to step 260, in which computer 11 sends a tenth auxiliary command to computer 12 to exit the transfer.

[0125] Figure 2 Frame 29 shown can be used to represent the tenth auxiliary command.

[0126] The computer 12's receipt of the tenth auxiliary command triggers transition 269 of activation step 270, in which the computer 12 sends a response to the received tenth auxiliary command.

[0127] When using commands conforming to the UDS protocol, field 53 contains the SID $37, which indicates the exit command in the delivery mode. Figure 2 The response to the ninth auxiliary command shown on the model of middle frame 30 includes a comment for SID $77 in field 56 and the address of the memory block in field 57.

[0128] The receipt of the response of computer 11 to the tenth auxiliary command triggers a transition 291 that moves computer 11 from step 260 of the first loop to step 292, in which computer 11 checks whether there are subsequent digital components to be loaded into subsequent memory blocks.

[0129] The presence of subsequent digital components triggers transition 293, which loops the method back to the re-execution of steps 252 to 292, each step adapting to the subsequent physical memory block in terms of identifier, size, and memory block address.

[0130] The absence of a digital component requiring a subsequent physical memory block triggers transition 295 of activation step 296, in which computer 11 sends an eleventh auxiliary command to computer 12 to check for faults when writing to the memory block of computer 12.

[0131] in this case, Figure 2 Frame 29 shown can also be used to represent the eleventh auxiliary command. For the eleventh auxiliary command, the target is specifically a memory fault code.

[0132] The computer 12's receipt of the eleventh auxiliary command triggers transition 271 of activation step 272, in which the computer 12 sends a response to the received eleventh auxiliary command.

[0133] When using commands compliant with the UDS protocol, field 53 contains the SID $19 indicating a read with a diagnosed fault. Figure 2 The response to the eleventh auxiliary command shown on the model of frame 30 includes a comment on SID $59 in field 56 and a fault code in field 57. Field 59 contains a value indicating whether the fault identified by the code included in field 57 exists or does not exist.

[0134] Figure 6 The method is shown in Figure 5 The final step following the steps shown. The receipt of the eleventh auxiliary command by computer 11 triggers the transition 297 of the second loop of activation step 298, in which computer 11 sends a twelfth auxiliary command to computer 12 to activate the first local program, in which computer 12 checks whether the first digital component has been correctly written into the first memory block in the memory of computer 12.

[0135] Figure 2Frame 29 shown can be used to represent each twelfth auxiliary command. For the twelfth auxiliary command, the target recorded in field 54 is specifically a condenser program reference stored in the memory of computer 12. Field 55 contains the address of the memory block to be inspected.

[0136] The receipt of the twelfth auxiliary command by computer 12 triggers transition 273 of activation step 274, in which computer 12 activates a condenser program specifically involved in calculating the condensate for writing the contents into the physical memory block. Computer 12 sends a response to the received twelfth auxiliary command containing the calculated condensate. The response to the twelfth auxiliary command allows computer 11 to compare the condensate calculated by computer 12 with the condensate held by computer 11 before loading the contents into the physical memory block. Therefore, computer 11 can check that the contents of the rewritten physical memory block are consistent with the contents to be loaded into the physical memory block.

[0137] When using commands conforming to the UDS protocol, field 53 contains SID $31 indicating activation of the program identified by the program reference in field 54. Figure 2 The response to the twelfth auxiliary command shown on the model of middle frame 30 includes a comment with SID $62 in field 56 and DID references in field 57. Field 59 contains a value indicating the starting address of the first memory block provided for loading the first digital component therein.

[0138] The receipt of the response of computer 11 to the sixth auxiliary command triggers transition 299 of activation step 300, in which computer 11 checks whether there is a next physical memory block for subsequent loading of digital components.

[0139] The presence of the next physical memory block triggers a loop back to transition 301 at step 298, in which the first block is replaced by the next block, and so on, until the last physical memory block.

[0140] The absence of the next physical memory block triggers transition 303 of activation step 304, in which computer 11 sends a thirteenth auxiliary command to computer 12 to read the memory used by computer 12 to store the detected fault.

[0141] The computer 12's receipt of the thirteenth auxiliary command triggers transition 275 of activation step 276, in which the computer 12 sends a response to the thirteenth auxiliary command containing the fault detected during the execution of the previous steps.

[0142] When using commands compliant with the UDS protocol, field 53 contains SID $19 indicating a read of Diagnostic Trouble Code (DTC) information. It should be noted that each DTC fault processed by computer 12 has its own code stored in computer 12's dedicated memory (called error memory), which can be read at any time. Additional information associated with each fault (particularly with the context in which the fault occurred) is also stored and can be read at any time. Figure 2 The response to the thirteenth auxiliary command shown on the model of mid-frame 30 includes comments referencing SID $59 in field 56 and DID in field 57. Field 59 uses the contents of the faulty memory.

[0143] The receipt of the thirteenth auxiliary command by computer 11 triggers transition 305 of activation step 306, in which computer 11 sends the fourteenth auxiliary command to computer 12. The fourteenth auxiliary command causes computer 12 to exit the session opened in step 216 and return to the default session. Therefore, within the context of the above-described dialogue method, computer 12 only considers commands originating from computer 11 between steps 216 and 306. Before step 216 and after step 306, computer 12 can consider commands originating from computer 11. Figure 5 and Figure 6 Within the context of the above-described dialogue method instance, the commands derived from computer 11 can also be considered in reference to Figure 4 The commands originating from computer 11 within the context of another instance of the above-described dialogue method, or even commands received within the context of another method (such as, for example, a local diagnostic method or a remote diagnostic method).

[0144] The computer 12's receipt of the fourteenth auxiliary command triggers transition 277 of activation step 278, in which the computer 12 sends a response to the received fourteenth auxiliary command.

[0145] When using commands compliant with the UDS protocol, field 53 contains the SID $10, which indicates diagnostic session control. Field 54 contains the session identification code, which in this case is "default session". Figure 2 The response to the fourteenth auxiliary command shown on the model of mid-frame 30 includes a note for SID $50 in field 56 and the session identification code in field 57. When the periodic signal also includes an indication of the progress status, computer 11 indicates the progress status corresponding to the closure of the update session.

[0146] The receipt of the response of computer 11 to the fourteenth auxiliary command triggers a transition 307 that moves computer 11 from step 306 to step 308, in which computer 11 sends a fifteenth auxiliary command to computer 12 to activate the second local program.

[0147] According to a first embodiment, the computer 12 includes a single activatable rewritable memory group and two non-activatable rewritable memory groups. The single activatable group includes memory blocks containing digital components that are executed and / or accessed in real time by the onboard computer 12 while the vehicle is running. The first non-activatable group includes the aforementioned memory blocks for loading one or more updated digital components. A second local program uses the second non-activatable group; execution of this second local program involves copying the contents of the activatable group to the second non-activatable group when the vehicle is not running, and then copying the contents of the first non-activatable group to the single activatable group, so that the single activatable group can be activated using updated digital components the next time the vehicle is running.

[0148] According to a second embodiment, the computer 12 includes two dual-activated rewritable memory groups. The first dual-activated group includes memory blocks containing digital components that are executed and / or accessed in real time by the onboard computer 12 when the vehicle is running. The second dual-inactive group includes the aforementioned memory blocks for loading one or more updated digital components. The execution of the second local program then simply involves switching from the first dual-activated group to the second dual-activated group when the vehicle is not running, so that the second dual-activated group is activated with updated digital components the next time the vehicle is running. For this purpose, the second dual-activated group will function as the first dual-activated group, and vice versa.

[0149] It should be noted that all or some of the auxiliary commands preceding the fifteenth auxiliary command can be executed while the vehicle is running. The advantage of the two embodiments described above is that switching the vehicle's operation to real-time execution and / or access to digital components requires only a very short duration; in other words, the duration of stopping the vehicle to update the digital components is very short.

[0150] Figure 2 Frame 29 shown can be used to represent the fifteenth auxiliary command. For the fifteenth auxiliary command, the target written in field 54 is specifically a switching program reference stored in the memory of computer 12.

[0151] The receipt of the fifteenth auxiliary command by computer 12 triggers transition 279 of activation step 280, in which computer 12 activates the second local program, in other words, the switching program before sending a response to the received fifteenth auxiliary command, which includes confirmation of the correct execution of the second local program. Therefore, computer 11 can check whether computer 12 is ready for any future access and / or execution of digital components that are read as up-to-date.

[0152] When using commands conforming to the UDS protocol, field 53 contains SID $31 indicating activation of the program identified by the program reference in field 54. Figure 2 The response to the fifteenth auxiliary command shown on the model of mid-frame 30 includes SID $62 in field 56.

[0153] The receipt of the response of computer 11 to the fifteenth auxiliary command triggers transition 309 of activation step 310, in which computer 11 sets a periodic signal to a ready state. The periodic signal may also include a phased progress level consisting of several auxiliary commands. For example, computer 11 sets the progress level in step 212 to indicate the parameter verification phase, sets the progress level in step 252 to indicate the current installation phase, and sets the progress level in step 310 to indicate the end of the installation phase.

[0154] The computer 10's reception of a periodic signal in a ready state triggers a transition 207, which reactivates the initial step 100 in the computer 10, awaiting any further master commands.

Claims

1. A method for communicating from a first onboard bus (1) in a vehicle, the method comprising: - The first computer (12, 13, 14) is directly connected to the second vehicle bus (2) in the vehicle, and the first computer is not directly connected to the first vehicle bus (1) in the vehicle. - The first vehicle bus in the vehicle is connected to the second vehicle bus in the vehicle via a second computer (11), the second computer (11) being directly connected to the first vehicle bus in the vehicle and the second vehicle bus in the vehicle; - A third computer (10) in the vehicle is directly connected to the first vehicle bus in the vehicle. The third computer (10) processes the main commands for the first computer (12, 13, 14) and the third computer is not directly connected to the second vehicle bus in the vehicle. - A write command is generated (102) by the third computer (10) which is in the vehicle and directly connected to the first vehicle bus, to write the description (27) of the main command into the first dedicated data area (61) of the second computer (11); - When it is detected (103) that the second computer (11) is ready to respond to the write command, the third computer (10) in the vehicle and directly connected to the first vehicle bus in the vehicle sends (104) the write command to the second computer (11); - After the second computer (11) receives the write command (111), it sends one or more auxiliary commands (114) to the first computer (12, 13, 14) in response to the main command. - The first computer (12, 13, 14) sends (122) a response to each received auxiliary command (121); - At least one received response (115) is stored (116) in a second dedicated data area (62) via the second computer (11); - When it is detected (107) that the second computer (11) is ready to respond to a read command to read the second private data area (62) of the second computer, the read command (108) is sent via the third computer (10) in the vehicle and directly connected to the first vehicle bus in the vehicle to read the second private data area of ​​the second computer; - A response (124) to the received read command (119) is sent via the second computer (11); and - Upon receiving at least one response to a read command (109) to read the second private data area of ​​the second computer (11), the third computer responds to the master command (126) via a first vehicle bus in the vehicle and directly connected to the vehicle, and stores the response sent by the first computer (12, 13, 14) in the second private data area.

2. The method as described in claim 1, wherein, The second computer (11) periodically sends signals including ready and unready states via the first vehicle bus (1), and this includes the following steps: - When the second computer (11) receives a write command originating from the third computer (10), it sets the signal (112) to an occupied state; - The second computer (11) sets the signal (116) to a ready state when it receives (115) a response from the first computer (12, 13, 14).

3. The method as described in claim 2, characterized in that, The method includes the following steps: after receiving (105) the signal set to the occupied state, the third computer (10) enters standby (106) to wait for the signal to be set to the ready state.

4. The method according to any one of claims 2 and 3, characterized in that, The signal also includes the progress of one or more of the auxiliary commands sent by the second computer (11).

5. The method according to any one of claims 1 to 3, characterized in that, The write command includes a first frame (21) which includes at least one field (33, 34, 35) of a first identifier field (31) for the write command, a first identifier field (32) for the first private data area (61) and a description (27) of the main command.

6. The method according to any one of claims 1 to 3, characterized in that, The description (27) of the main command includes standard fields (33) for the main command, an identification field (34) for the second computer (12, 13, 14) and parameter fields (35) useful for the second computer (12, 13, 14) to establish the sent response.

7. The method according to any one of claims 1 to 3, characterized in that, The method includes the following steps: when the second computer (11) receives the write command (111), it sends an acknowledgment (112) to the first computer (10).

8. The method as described in claim 7, characterized in that, The confirmation includes a second frame (22), which includes a confirmation identifier field (37) and a second identifier field (38) for the first dedicated data area (61).

9. The method according to any one of claims 1 to 3, characterized in that, The read command sent by the third computer (10) includes a third frame (23) which includes a second command identifier field (39) and a first identifier field (40) for the second private data area (62).

10. The method according to any one of claims 1 to 3, characterized in that, The response to the read command includes a fourth frame (24), which includes a fourth identifier field (41) for the response to the read command, a second identifier field (42) for the second private data area (62), at least one descriptive comment field (43, 44, 45) for the main command, and a content field (47) for the response to the main command.

11. The method according to any one of claims 1 to 3, characterized in that, These read and write commands are in accordance with the Unified Diagnostic Services Protocol.

12. The method according to any one of claims 1 to 3, comprising the following steps: - When the second computer (11) receives the write command (111), it checks whether the description of the main command (112) is complete; - The second computer (11) sends (114) one or more auxiliary commands to the first computer (12, 13, 14) in response to the main command only when the description of the main command is complete (113); - If the description of the main command is incomplete, the second computer (11) stores (118) a warning (117) in the second private data area.

13. The method according to any one of claims 1 to 3, characterized in that, The main command is a command for reading resident data in the first computer, wherein the auxiliary command includes a fifth frame (25), the fifth frame including an identification field (48) for the read command and an identification field (49) for the resident data, and wherein the response sent by the first computer (12, 13, 14) includes a sixth frame (26), the sixth frame including an identification field (50) for the response to the read command, an identification field (51) for the resident data and a field (52) containing the value of the resident data.

14. The method according to any one of claims 1 to 3, characterized in that, The main command is used to install digital components in the first computer.

Images