WO2020259956A1 - Procédé de dialogue avec un calculateur sur bus embarqué de véhicule - Google Patents

Procédé de dialogue avec un calculateur sur bus embarqué de véhicule Download PDF

Info

Publication number
WO2020259956A1
WO2020259956A1 PCT/EP2020/065039 EP2020065039W WO2020259956A1 WO 2020259956 A1 WO2020259956 A1 WO 2020259956A1 EP 2020065039 W EP2020065039 W EP 2020065039W WO 2020259956 A1 WO2020259956 A1 WO 2020259956A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
command
field
response
auxiliary
Prior art date
Application number
PCT/EP2020/065039
Other languages
English (en)
Inventor
Eric Abadie
Original Assignee
Renault S.A.S
Nissan Motor Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renault S.A.S, Nissan Motor Co., Ltd. filed Critical Renault S.A.S
Priority to CN202080043378.3A priority Critical patent/CN114026537A/zh
Priority to EP20733358.4A priority patent/EP3991029A1/fr
Priority to US17/620,470 priority patent/US20220245085A1/en
Priority to KR1020227002402A priority patent/KR20220024905A/ko
Priority to JP2021576268A priority patent/JP2022538080A/ja
Publication of WO2020259956A1 publication Critical patent/WO2020259956A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4063—Device-to-bus coupling
    • G06F13/4068—Electrical coupling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Definitions

  • TITLE Dialogue process with a computer on a vehicle's on-board bus.
  • the invention relates to a method of dialogue with a computer on a vehicle's on-board bus.
  • the invention relates in particular to a dialogue method from a first bus on board a vehicle, with a first computer connected to a second bus on board the vehicle.
  • the method according to the invention is particularly useful for updating on-board computers, while at the same time allowing execution of real-time programs to operate the vehicle.
  • Updates to on-board computers and the execution of real-time programs generally require the issuance of commands on one or more on-board buses.
  • Time counters are generally implemented to monitor the length of time between issuing a command and receiving a response to that command, with the drawback of increasing the time as the quantity of commands increases.
  • document EP1434129A2 discloses a rewrite control apparatus for an on-board program in which a switching command is based on a signal coming from a time counter.
  • the disclosed apparatus controls two operational modes, a normal mode which could correspond to a diagnostic mode and an onboard program rewrite mode, usable for a computer update.
  • the disclosed apparatus switches from normal mode to rewrite mode when it receives a program rewrite command from a server, and switches from rewrite mode to normal mode when it receives a command to switch to normal mode for the rewrite mode.
  • Each switching has the disadvantage of leaving the current mode.
  • the subject of the invention is a method of dialogue 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, in which a third computer connected to the first on-board bus, processes a main command intended for the first computer, comprising steps in which:
  • the third computer generates a command to write a description of said main command in a first dedicated area of the second computer; - the third computer issues said write command to the second computer when the second computer is detected ready to respond to said write command;
  • the second computer sends one or more auxiliary commands to the first computer to respond to the main command after receiving said write command
  • the first computer sends a response to each auxiliary command received
  • the second computer stores each response received in a second dedicated area
  • the third computer issues a read command from said second dedicated zone, to the second computer when the second computer is detected ready to respond to said read command;
  • the second computer emits a response to the read command received
  • the third computer responds to the main command from at least one receipt of a response to the read command from the second zone of the second computer in which the response sent by the first computer is stored.
  • a two-state signal, ready, not ready is periodically emitted by the second computer, for which the method comprises steps in which the second computer positions the signal:
  • the method comprises a step in which the third computer waits for the signal positioned in the ready state after having received said signal positioned in the busy state.
  • said write command comprises a first frame which includes a first command identifier field, a first identifier field of the first dedicated area, and at least one description field of the main command.
  • the description of the main control includes a type field of the main control, an identification field of the second computer, and a field of identification of useful data for the second computer to develop the response sent.
  • the method comprises a step in which the second computer sends an acknowledgment to the first computer after receiving said write command.
  • the acknowledgment comprises a second frame which comprises an acknowledgment identifier field, and a second identifier field of the first dedicated zone.
  • said read command sent by the third computer comprises a third frame which comprises a second command identification field, and a first identifier field of the second dedicated area.
  • said response to the read command comprises a fourth frame which comprises a fourth field of identifier of response to the command, a second field of identifier of the second dedicated zone, to the less a field for recalling the description of the main command, and a content field for the response sent by the first computer.
  • said main command is a command for reading a datum resident in the first computer, for which the auxiliary command comprises a fifth frame which comprises a read command identification field and an identification field of said resident datum, of so that the response sent by the first computer comprises a sixth frame which comprises an identification field for responding to the read command, an identification field for said resident datum, and a field containing the value of said resident datum.
  • the read commands and the write commands are UDS Unified Diagnostic Services protocol compliant commands.
  • the method can also include steps in which:
  • the second computer checks whether the description of said main command is complete or not after receipt of said write command
  • the second computer sends to the first computer one or more auxiliary commands to respond to the main command only if the description of said main command is complete;
  • the second computer stores an alarm in the second dedicated zone if the description of said main control is not correct.
  • Figure 1 shows schematically an on-board vehicle system on which the invention is implemented
  • FIG. 2 schematically shows command frames with which the invention is implemented;
  • FIG. 3 shows process steps according to the invention for processing a main read command;
  • Figure 4 shows the steps of a first method according to the invention for processing a main installation command
  • Figure 5 shows steps of a second part of the method according to the invention for processing a main installation command
  • FIG. 6 shows the steps of a third and final part of the method according to the invention for processing a main installation command.
  • FIG. 1 shows two computers 9, 10 connected to an onboard bus 1 in a vehicle, and three computers 12, 13, 14 connected to an onboard bus 2 in the vehicle.
  • the computer 9 is for example an on-board computer dedicated to IVC (In Vehicle Communication) type telecommunications.
  • the computer 10 is for example an on-board computer of the IVI (In Vehicle Infotainment) type, the computer processing capacities of which are comparable to those of a microcomputer.
  • Other onboard computers, not shown, can be connected to onboard bus 1.
  • the computers 12, 13, 14 connected to the on-board bus 2 are preferably on-board vehicle control and command computers of the ECU (Electronic Control Unit) type.
  • a computer 11 connected to the on-board bus 1 and to the on-board bus 2, performs gateway functions between the two on-board buses.
  • FIG. 3 shows dialogue process steps in which the computer 10 processes a main command which is a command for reading a datum resident in one of the computers 12, 13, 14, for example in the computer 12.
  • This type of This command is useful, for example, for reading a digital component reference, or a version number of the digital component in the computer 12, for example with a view to deciding whether or not an update of the digital component is necessary.
  • the digital component can concern so much an executable program, a database or any other digital structure such as for example a source program or a table of parameters.
  • the computer 10 initially in a standby step 100, goes to a step 102 when a read request submitted by a higher order method, for example a method for updating the computer 12, validates a transition 101.
  • the read request may contain a computer identifier from among the computers 12, 13, 14 connected to the on-board bus 2, in this case the identifier of the computer 12.
  • the computer identifier may consist of an address of computer conforming to the communication protocol of bus 2, of CAN (Controller Area Network), Flex Ray or TTP type also known in aeronautics, automotive Ethernet or other fields.
  • the computer identifier can also consist of an ASCII character string which names the computer in its functional universe, for example “BCM” (Body Control Module for cash register control module), “HEVC” (Hybrid Electric Vehicle Controller for Hybrid Electric Vehicle Controller), “VDC” (acronym for Vehicle Dynamic Control) or other.
  • An ASCII character string has the advantage of being able to designate a computer independently of an on-board system architecture. Another advantage of an ASCII character string is that it is a mnemonic device that is more easily understood by humans.
  • the read request may contain a data identifier 63 in the identified computer.
  • step 102 the computer 10 constructs a description of the main command from the request which validated the transition 101, then generates a write command of the description of the main command in a first dedicated data area 61, resident in computer memory 1 1.
  • FIG. 2 shows an example of a write command which includes a frame 21.
  • the frame 21 comprises a field 31 identifying the command generated as a write command, a field 32 identifying the first dedicated zone 61, and at least one field 33, 34, 35 to contain the description 27 of the main command.
  • the type of main command is for example identified by two letters in ASCII code.
  • the first letter identifies a main command class, "E” for “execute”, “R” for read, or “W” for write.
  • the second letter in combination with the first identifies an action within the main command class, “EA” for “Perform an Activation”, “ED” for “Perform a Download”, “El” for “Perform an Installation” , “EC” for "Execute a Delete", “ER” for “Execute a Reset”, “RD” for "Read Data", “RX” for “Read Extended Data”, “WD” to write data.
  • Field 34 which makes up the description 27, gives an on-board computer identifier, in particular as indicated in the request.
  • Field 35, which makes up description 27, contains parameters useful for executing the command.
  • the parameters are identifiers of digital components to be installed, respectively to be activated.
  • the description 27 of the main control comprises a field 33 giving the type of the main control “RD”, a field 34 for identifying the computer connected to the bus 2, for example the functional name of the computer 12, and a parameter field 35, containing as a parameter useful to the computer 11 to participate in the processing of the main command, a data identifier to be read.
  • the use of a write command conforming to the UDS protocol for unified diagnostic services has the advantage of benefiting from the mechanism generally preinstalled in a majority of on-board computers in the automotive world, in particular for performing diagnostic functions. , without having to modify the lower communication layers to implement the dialogue method according to the invention.
  • the field 31 then contains the SID (Service Identifier for service identifier in English) $ 2E which is the known hexadecimal code of a writing of data by identifier DID.
  • a transition 103 from step 102 to step 104 is validated when the computer 11 is detected ready to respond to the write command supported by the frame 21.
  • the computer 11 performs a gateway function for another instance of the dialogue method according to the invention, or a gateway function for a command generated by another method such as for example a diagnostic method, the computer remains on standby on step 102.
  • the computer 10 does not unnecessarily encumber the bus 1 with attempted transmission of commands which would have no effect due to the occupation of the computer 11 by other functions.
  • the momentary putting on hold of the dialogue method on step 102 allows the execution of the diagnostic command without having to interrupt the diagnostic process.
  • the computer 11 which declares itself ready or not to process the commands issued within the framework of the dialogue method according to the invention.
  • the computer 11 periodically transmits on the bus 1, a signal comprising two states, ready, occupied or not ready.
  • the computer 11 sets the signal to the ready state by default. As soon as the computer 1 1 receives a command, whether it be from the dialogue method according to the invention or from any other method such as for example from the diagnostic method, the computer 1 1 positions the signal in the occupied state until it has finished processing the current order.
  • step 104 the computer 11 having been detected ready to respond to the write command, the computer 10 issues the write command to the computer 11.
  • the computer 10 can encapsulate the frame 21 in a CAN frame on the bus 1, or in another way, for example encapsulate the frame 21 in a frame over IP if the Ethernet protocol for vehicles is used. on bus 1.
  • FIG. 2 gives an example of an auxiliary command which comprises a frame 25 comprising a field 48 for identifying the command of reading and a field 49 for identifying the data resident in the computer 12. More particularly, the use of a read command conforming to the UDS protocol for unified diagnostic services has the advantages mentioned above.
  • the field 48 then contains the SID $ 22 which is the known hexadecimal code for reading data by DID identifier.
  • Field 49 contains the DID identifier of data area 63 of computer 12 which was indicated in field 35 of frame 21.
  • the 1 1 1 transition can make the process go directly from the initial step 1 10 to the 1 14 step.
  • the 1 1 1 transition takes the process from the initial step 1 10 to a step intermediate 1 12.
  • step 1 12 the computer 1 1 checks whether the main control description 27 is complete or not, with regard to pre-established safety rules which are not the subject of the present invention. In the case where step 1 12 is implemented, a transition 1 13 is validated if the main control description 27 is verified to be intact, or a transition 1 17 is validated if the main control description 27 is verified not to be intact. Step 1 14 is then activated after validation of transition 1 13.
  • step 1 14 the computer 1 1 positions the periodic signal in the occupied state, in other words after validation of the transition 1 1 1 by receiving the command writing from the computer 10.
  • the computer 11 responds to the write command by sending an acknowledgment of receipt or acknowledgment.
  • the computer 1 1 sends a frame 22 of which a first field 37 contains the SID code of value $ 6E, and of which a second field 38 contains the value of field 32 of the frame 21 to allow the computer 10 to recognize the write command sent to which the received acknowledgment corresponds.
  • the field 38 constitutes an identifier field of the first dedicated zone 61.
  • computer 10 waits for the signal positioned in the ready state.
  • the computer 12 initially in a standby step 120 of the dialogue method according to the invention, validates a transition 121 when it receives the auxiliary command materialized by the frame 25 sent by the computer 11 on the onboard bus 2.
  • a validation of the transition 121 activates a step 122 in which the computer 12 sends a response to the auxiliary command received.
  • the response sent to the computer 11 comprises a frame 26 which comprises a response identification field 50, here at the read command, a field 51 for identifying said resident datum, and a field 52 containing a value of the resident data item 63 identified by the field 51, as illustrated in FIG. 2.
  • field 50 then contains the SID $ 62 which is the known hexadecimal code of a response to read data by DID identifier.
  • Field 51 contains the DID identifier of data area 63 of computer 12 which was indicated in field 49 of frame 25. Computer 12 then returns to standby step 120.
  • Receipt of the response by the computer 1 1 validates a transition 1 15 which switches the dialogue method from step 1 14 to a step 1 16 in which the computer 1 1 generates a response description 28 to the main control which here is a command to read the resident data 63 in the computer 12.
  • the response description 28 comprises fields 43, 44, 45 which each respectively contain the values of the fields 33, 34, 35 of the command description 27 to identify that the response description is the one that corresponds to the main command description.
  • the response description 28 also includes a field 47 which contains the value contained in the field 52 of the frame 26.
  • the computer 1 1 stores the response description 28 in a second dedicated data area 62, resident in the memory of the computer 1 1 . In step 1 16, the computer 11 then positions the periodic signal in the ready state.
  • a transition 107 is validated when the computer 10 detects that the computer 11 is ready to respond.
  • the transition 107 is enabled by the reception of the periodic signal in the ready state.
  • a validation of the transition 107 activates a step 108 in the computer 10.
  • step 108 the computer 11 having been detected ready to respond to a read command, the computer 10 issues a read command of the second dedicated zone 62, to computer 1 1.
  • the read command is for example materialized by a frame 23 as shown in FIG. 2.
  • the frame 23 comprises a command identification field 39 as a read command, and an identifier field 40 of the second dedicated zone 62. of data.
  • the field 39 contains the value $ 22 which identifies a read command
  • the field 40 contains a value of DID which is the address of the dedicated zone 62 of data in memory. of calculator 1 1.
  • a transition 1 19 is validated when the computer 1 1 receives the read command materialized by the frame 23.
  • a validation of the transition 1 19 activates a step 124 in which the computer 11 sends a response to the computer 10.
  • the response to the read command received comprises a frame 24 which includes a field 41 of the command response identifier. reading, and an identifier field 42 of the second dedicated zone 62, so as to be able to verify that the frame 24 constitutes the response to the read command materialized by the frame 23.
  • the frame 24 subsequently contains the description 28 which comprises the fields 43, 44, 45 each containing a value equal respectively to that contained in each fields 33, 34, 35 to recall the description of the main command.
  • Description 28 also includes field 47 which contains the response to the main command.
  • the computer 1 1 then returns to the initial step 1 10 of standby with regard to the dialogue process according to the invention.
  • a transition 109 is validated when the computer 10 receives the response to the read command, materialized by the frame 24.
  • a validation of the transition 109 activates a step 126 in which the computer 10 responds to the main command from the content of the field 47 extracted from the response to the read command from the second dedicated zone of the computer 11 in which the memory is stored. response sent by the computer 12.
  • the computer 10 then returns to the initial standby step 100 with regard to the dialogue method according to the invention.
  • Update function processing is performed by main control processing in computer 10 at an upper layer level, comparable to diagnostic function processing.
  • the computer 11 can process frames linked to diagnostic functions by transferring them directly from bus 1 to bus 2 and vice versa, as a gateway.
  • the computer 11 can process frames linked to diagnostic functions by processing them by diagnostic functions resident in the computer 11.
  • the computer 1 1 can process frames linked to update functions by update functions resident in the computer 1 1 as it would do for by diagnostic functions resident in the computer 1 1.
  • the issuance of read and write commands linked to the processing of the main command from the computer 10 connected to the on-board bus 1 does not require a command received from a remote server to restart an update process as soon as the periodic signal is positioned in the ready state.
  • the updating process can be done without requiring a remote connection of the vehicle insofar as the update data has been previously downloaded into the computer 10.
  • the main command of the dialogue method when it is to read a data item in one of the computers 12, 13, 14 connected to the bus 2, could more simply be implemented by a simple command to read the data directly to the destination. of that of calculator 12, 13, 14 which hosts the given, for example the computer 12.
  • this a priori simpler solution would pose a problem of managing the total duration which would separate the transmission of the simple read command and the reception of the response, a duration which would be the sum of the necessary durations.
  • a first duration which separates the write command of the invention and the response to the write command is reduced to the sum of the times necessary for the transmission of the write command from the computer 10 to the computer 11, then to the transmission of the response, generally a simple acknowledgment, from the computer 1 1 to the computer 10.
  • a second period which separates the read command of the invention and the response to the read command is reduced to the sum of the times necessary for the transmission of the read command from computer 10 to computer 1 1, then to the transmission of the response from computer 1 1 to computer 10.
  • the method is robust with regard to an interruption which would occur during said third duration, for example in the event of the vehicle being switched off from electric ignition.
  • the method according to the invention can resume in the step in which it had stopped before the interruption.
  • step 1 12 in which the computer 1 1 checks whether the description 27 of the main control is intact or not
  • a transition 1 17 is validated when the description 27 of the main control is verified as not integrated .
  • a validation of the transition 1 17 activates a step 1 18 in which the computer 1 1 stores an alarm in the second dedicated zone 62 then positions the periodic signal in the ready state.
  • the dialogue method according to the invention is applicable to other main commands than the main command for reading a piece of data in a first computer connected to the on-board bus 2, for processing of which the computer 11 sends a single computer to the first computer.
  • auxiliary command consisting of a command to read the data, so as to respond to the main command.
  • FIG. 4 shows dialogue process steps in which the computer 10 processes a main command which is a command for installing a digital component, for example in the computer 12.
  • This type of command is useful, for example for installing one or more digital components.
  • the digital component can relate to an executable program, a database or any other digital structure such as for example a source program or a table of configuration parameters.
  • the installation request may contain a computer identifier among the computers 12, 13, 14 connected to the onboard bus 2, in this case the identifier of the computer 12.
  • the request for installation can contain a file, for example in HTML format with tags identifying blocks of physical memory of the computer 12 in each of which to write a content of the HTML file included between two tags identifying the same block of physical memory 64.
  • the memory blocks physical are of the rewritable permanent memory type, for example of the EEPROM type.
  • step 202 the computer 10 constructs a description of the main command from the request which validated the transition 201, then generates a write command of the description of the main command in the first dedicated data area 61, resident in computer memory 1 1.
  • FIG. 2 shows an example of a write command for which the field 31 of the frame 21 constantly identifies the command generated as a write command, the field 32 constantly identifies the first dedicated area 61.
  • the field 33 comprises for example two letters “El” which indicate a main command of the “Execute Installation” type.
  • the field 34 identifies, in particular by name the target computer connected to the bus 2 to which the main command applies, for example the computer 1.
  • the field 35 contains a parameter whose value identifies a package containing at least one digital component to be installed in the target computer.
  • field 31 then contains the SID $ 2E which is the known hexadecimal code for writing data by DID identifier, here corresponding to the dedicated zone 61.
  • a transition 203 of passing from step 202 to a step 204 is validated when the computer 11 is detected ready to respond to the write command supported by the frame 21.
  • the computer 11 performs a function gateway for another instance of the dialogue method according to the invention, or a gateway function for a command generated by another method such as for example a diagnostic method
  • the computer remains on standby in step 202.
  • the computer 10 does not unnecessarily encumber the bus 1 with attempts to send a command which would have no effect due to the occupation of the computer 11 by other functions.
  • the momentary putting on hold of the dialogue method in step 202 allows the execution of the diagnostic command without having to interrupt the diagnostic method.
  • the computer 1 1 sets the signal to the ready state by default. As soon as the computer 1 1 receives a command, whether it be from the dialogue method according to the invention or from any other method such as for example from the diagnostic method, the computer 1 1 positions the signal in the occupied state until it has finished processing the current order.
  • step 204 the computer 11 having been detected ready to respond to the write command, the computer 10 issues the write command to the computer 11.
  • the computer 10 can encapsulate the frame 21 in a CAN frame on the bus 1, or in another way, for example encapsulate the frame 21 in a frame over IP if the Ethernet protocol for vehicles is used. on bus 1.
  • the acknowledgment of proper execution of the write command is materialized by frame 22 in which field 37 contains the value $ 6E and field 38 contains the DID of zone 61.
  • a reception of the frame 22 in the computer 10 validates a transition 205 which causes the computer 10 to go from step 204 to a step 206 in which the computer 10 reads the state of the signal periodically transmitted by the computer 11, in waiting to read ready state.
  • the periodic signal further comprises an indication of the progress status of the execution of the steps in the computer 11.
  • step 21 2 the computer 1 1 positions the periodic signal in the busy state then sends to that of the computers 1 2, 1 3, 1 4 identified in the field 34, for example the calculator 1 2, a succession one or more first auxiliary commands to respond to the main command, from the description 27 of the main command, written in the dedicated data zone 61 of the computer 11.
  • the periodic signal further includes an indication of the state of progress
  • the computer 11 indicates the state of progress corresponding to step 212.
  • each first auxiliary command consists in reading an attribute of the computer 12, the knowledge of which is useful for correctly installing the or digital components.
  • a first auxiliary command the example given in FIG. 2 can be used which comprises the frame 25 comprising the read command identification field 48 and the identification field 49 of the data resident in the computer 12, corresponding to the read attribute.
  • Reception of the succession of first auxiliary commands in the computer 1 validates a transition 221 which activates a step 222 in which the computer 1 2 sends a response to each first auxiliary command received.
  • field 48 contains SID $ 22.
  • Each response to a first auxiliary command on the model of frame 26 in figure 2 contains SID $ 62 in field 50, the identification of the attribute in field 51 and the value read of the attribute in field 52.
  • a reception in the computer 1 1 of the last response to the succession of first auxiliary commands validates a transition 213 which switches the computer 1 1 from step 212 to a step 214 in which the computer 1 1 transmits to the computer 1 2, a succession of one or more second auxiliary commands to check that the computer 1 2 is not disturbed by a defect liable to harm the installation of the digital component.
  • FIG. 2 gives an example of an auxiliary command which comprises a frame 29 comprising an auxiliary command designation field 53, a target identification field 54 in the computer 12, to which the auxiliary command relates, and incidentally which includes or does not include a control extension field 55.
  • the target is in particular a fault code.
  • Receipt of the succession of second auxiliary commands in the computer 1 validates a transition 223 which activates a step 224 in which the computer 1 2 sends a response to each second auxiliary command received.
  • field 53 contains the SID $ 29 which designates a reading of DTC information (acronym for "Diagnostic Trouble Codes” for "Diagnostic Trouble Codes” in English).
  • Field 54 contains a fault identification code of generally five alphanumeric characters.
  • the first character is the letter P to designate a powertrain of the vehicle (for example comprising engine and gearbox), the letter C to designate a chassis of the vehicle, the letter B to designate a body vehicle, the letter U to designate a user network.
  • the second character is the number 0 to designate a generic fault, the number 1 to denote a manufacturing defect.
  • Each response to a second auxiliary command shown on the model of frame 30 in Figure 2, contains SID $ 59 in field 56, a reminder of the fault code in field 57, and the read value of a fault code status in a field 59, for example in default or out of default.
  • the computer 11 When the periodic signal also includes an indication of the progress state, the computer 11 indicates the progress state corresponding to the faulty or non-faulty state contained in field 59.
  • a reception in the computer 1 1 of the last response to the succession of second auxiliary commands validates a transition 215 which takes the computer 1 1 from step 214 to a step 216 in which the computer 1 1 transmits to the computer 1 2, a third auxiliary command to start an update session.
  • the frame 29 illustrated in Figure 2 It is possible to use the frame 29 illustrated in Figure 2 to materialize the third auxiliary command.
  • the target is in particular to complete the operation performed in the computer 12.
  • Receipt of the third auxiliary command in the computer 1 validates a transition 225 which activates a step 226 in which the computer 1 2 sends a response to the third auxiliary command received.
  • field 53 contains SID $ 10 which designates diagnostic session control. It is recalled that the availability of different services depends on the diagnostic session which is active. For example the session named “Extended Diagnostic Session ”is used to release additional diagnostic functions such as the adjustment of sensors. For example again, the session named “Safety System Diagnostic Session” is used to test all the diagnostic functions critical to safety such as for example to test the airbags. In the absence of a particular diagnostic session, a default session “Default Session” is generally active, in particular in step 120 and maintained until validation of the transition 225.
  • Field 54 contains a session identification code which in it occurrence, is specifically dedicated to the installation of one or more digital components in the computer 12, named for example “FOTA”.
  • the response to the third auxiliary command contains SID $ 50 in field 56, and a reminder of the session identification code in field 57.
  • the computer 11 indicates the progress status corresponding to the opening of the update session.
  • Receipt in the computer 1 1 of response to the third auxiliary command validates a transition 217 which causes the computer 1 1 to go from step 216 to a step 218 in which the computer 1 1 sends to the computer 1 2, a fourth auxiliary command to verify the absence of faults in the memory blocks of the computer 1 2, with a view to their use to write updates to digital components therein.
  • the target is in particular a memory fault code.
  • Receipt of the fourth auxiliary command in the computer 1 validates a transition 227 which activates a step 228 in which the computer 1 2 issues a response to the fourth auxiliary command received.
  • field 53 contains SID $ 19 which designates a diagnostic fault read.
  • the response to the fourth auxiliary command shown modeled on Frame 30 in Figure 2, contains SID $ 59 in field 56, and a reminder of the fault code in field 57.
  • Field 59 contains a value that indicates whether the fault identified by the code contained in field 57, is present or absent.
  • the periodic signal further includes a progress state indication, the computer 11 indicates the progress state corresponding to the state of presence or absence of the fault contained in field 59.
  • Receipt in the computer 1 1 of response to the last fourth auxiliary command validates a transition 219 which causes the computer 1 1 to go from step 218 to a step 220 in which the computer 1 1 transmits to the computer 1 2, a succession of fifth auxiliary commands to check for an absence of faults in the memory block counters of the computer 1 2, with a view to their use for writing the updates of digital components in the memory blocks.
  • the target is in particular a memory counter fault code.
  • field 53 contains SID $ 19 which designates a diagnostic fault read.
  • the response to every fifth auxiliary command, shown modeled on Frame 30 in Figure 2 contains SID $ 59 in field 56, and a reminder of the fault code in field 57.
  • Field 59 contains a value that indicates whether the fault identified by the code contained in field 57 is present or absent.
  • the periodic signal further comprises an indication of progress state
  • the computer 11 indicates the state of progress corresponding to the state of presence or absence of the fault contained in field 59.
  • FIG. 5 shows the steps which follow those of FIG. 4.
  • a reception in the computer 1 1 of response to the last fifth auxiliary command validates a transition 251 which makes the computer 1 1 go from step 220 to a step 252 first loop in which the computer 1 1 sends to the computer 1 2, a sixth auxiliary command to read a start address of the first memory block in the memory of the computer 1 2.
  • the target is in particular a data reference DID relating to a memory block address register in the computer 12.
  • field 53 contains the SID $ 22 which designates a data reading identified by the DID reference of field 54.
  • the response to the sixth auxiliary command, illustrated on the model of frame 30 in figure 2 contains SID $ 62 in field 56, and a reminder of the DID reference in field 57.
  • Field 59 contains a value which indicates the start address of the first memory block intended to load the first digital component therein .
  • Receipt in the computer 1 1 of response to the sixth auxiliary command validates a transition 253 which switches the computer 1 1 from step 252 to a step 254 of the first loop in which the computer 1 1 transmits to destination of the computer 1 2, a seventh auxiliary command to write a reference of the first digital component at the head of the first memory block in the memory of the computer 1 2.
  • the target is in particular a data reference DID relating to a digital component naming register in the computer 12.
  • field 53 contains the SID $ 2E which designates a data entry identified by the DID reference of field 54.
  • the response to the seventh auxiliary command illustrated on the model of the frame 30 in FIG. 2, contains the SID $ 6E in field 56, and a reminder of the DID reference in field 57.
  • Field 59 contains a value which indicates an acknowledgment of the write command.
  • Receipt in the computer 1 1 of response to the seventh auxiliary command validates a transition 255 which switches the computer 1 1 from step 254 to a step 256 of the first loop in which the computer 1 1 transmits to the computer 1 2, an eighth auxiliary command to request a loading of a digital component into a first memory block of the computer 1 2.
  • the target is in particular the address of the first memory block.
  • field 53 contains SID $ 34 which designates a request to load from computer 1 1 to computer 12.
  • a field 55 contains a size of the digital component to be loaded.
  • the response to the eighth auxiliary command, illustrated on the model of frame 30 in Figure 2 contains SID $ 74 in field 56, and a reminder of the memory block address in field 57.
  • Field 58 recalls the size digital component to load.
  • Field 59 contains a value that indicates a maximum acceptable upload size.
  • Receipt in the computer 1 1 of response to the eighth auxiliary command validates a transition 257 which switches the computer 1 1 from step 256 to a step 258 of the first loop in which the computer 1 1 transmits to the computer 1 2, a ninth auxiliary command to transfer the digital component content to the first memory block of the computer 1 2.
  • the target is in particular the address of the first memory block.
  • field 53 contains SID $ 36 which designates a command to transfer content from digital component in the current physical memory block.
  • the transfer is carried out in packets of maximum size. If the content size exceeds the maximum size of a packet. The transfer is repeated until complete transmission of the content.
  • the response to the ninth auxiliary command shown modeled on frame 30 in Figure 2, contains SID $ 76 in field 56, and a reminder of the memory block address in field 57.
  • Receipt in the computer 1 1 of response to the ninth auxiliary command validates a transition 259 which causes the computer 1 1 to go from step 258 to a step 260 of the first loop in which the computer 1 1 transmits to the computer 1 2, a tenth auxiliary command to exit the transfer.
  • Receipt of the tenth auxiliary command in the computer 1 validates a transition 269 which activates a step 270 in which the computer 1 2 sends a response to the tenth auxiliary command received.
  • field 53 contains SID $ 37 which designates a command to exit transfer mode.
  • the response to the ninth auxiliary command shown modeled on frame 30 in Figure 2, contains SID $ 77 in field 56, and a reminder of the memory block address in field 57.
  • Receipt in the computer 1 1 of response to the tenth auxiliary command validates a transition 291 which switches the computer 1 1 from step 260 to a step 292 of the first loop in which the computer 1 1 checks whether there is a next digital component to be loaded into a next memory block.
  • the presence of a following digital component validates a transition 293 which loops the method back to a re-execution of steps 252 to 292, each adapted to the next physical memory block in terms of identification, size and memory block address.
  • An absence of a digital component requiring a next physical memory block validates a transition 295 which activates a step 296 in which the computer 11 sends to the computer 12, an eleventh auxiliary command to check for an absence of faults in the writing of the memory blocks of the computer 12. It is here again possible to use the frame 29 illustrated in FIG. 2 to materialize the eleventh auxiliary command.
  • the target is in particular a memory fault code.
  • Receipt of the eleventh auxiliary command in the computer 1 validates a transition 271 which activates a step 272 in which the computer 12 sends a response to the eleventh auxiliary command received.
  • field 53 contains SID $ 19 which designates a diagnosed fault read.
  • the response to the eleventh auxiliary command shown modeled on Frame 30 in Figure 2, contains SID $ 59 in field 56, and a reminder of the fault code in field 57.
  • Field 59 contains a value that indicates whether the fault identified by the code contained in field 57, is present or absent.
  • FIG. 6 shows the last steps of the method following those illustrated by FIG. 5.
  • a reception in the computer 11 of response to the eleventh auxiliary command validates a transition 297 of the second loop which activates a step 298 in which the computer 1 1 sends to the computer 12, a twelfth auxiliary command to activate a first local program in which the computer 12 checks that the first digital component has been correctly written in the first memory block in the memory of computer 1 2.
  • each twelfth auxiliary command is in particular a condenser program reference stored in memory in computer 12.
  • Field 55 contains an address of the memory block to be checked.
  • the computer 12 sends a response to the twelfth auxiliary command received which contains the calculated condensate.
  • the response to the twelfth auxiliary command allows the computer 1 1 to compare the condensate calculated by the computer 1 2 with a condensate held by the computer 1 1 prior to the loading of content into the physical memory block.
  • the computer 11 can thus verify that the content of the physical memory block after rewriting, conforms to the content to be loaded into the physical memory block.
  • field 53 contains the SID $ 31 which designates a program activation identified by the reference the program reference of field 54.
  • Field 59 contains a value which indicates the start address of the first memory block intended to load the first digital component.
  • a reception in the computer 1 1 of response to the sixth auxiliary command validates a transition 299 which activates a step 300 in which the calculator 1 1 checks whether there is a next block of physical memory for a next digital component loading.
  • a subsequent physical memory block existence validates a transition 301 which loops back to step 298 in which the first block is replaced by the next block and so on until the last physical memory block.
  • each DTC fault processed by the computer 12 is stored with its own code in the dedicated memory of the computer 12, called an error memory, which can be read at any time.
  • error memory which can be read at any time.
  • additional information particularly related to the context of the appearance of the fault, is also stored and readable at any time.
  • the response to the thirteenth auxiliary command, illustrated on the model of frame 30 in Figure 2 contains SID $ 59 in field 56, and a callback of the DID reference in field 57.
  • Field 59 contains the contents of the memory. of errors.
  • Receipt in the computer 11 of a response to the thirteenth auxiliary command validates a transition 305 which activates a step 306 in which the computer 11 issues a fourteenth auxiliary command to the computer 12.
  • the fourteenth auxiliary command has the effect of making take it out computer 12 of the session opened in step 216 to return it to the default session.
  • the computer 12 only takes into account the commands originating from the computer 1 1 within the framework of the dialogue method described above.
  • the computer 12 can take into account both the commands from the computer 1 1 as part of the instance of the dialogue method described above with the lighting of FIGS. 5 and 6, that the commands from the computer 11 in the context of another instance of the dialogue method described above with the lighting of Figure 4, or that the commands received in the context of another method such as for example of a local diagnostic or remote diagnostic method.
  • the response to the fourteenth auxiliary command, illustrated on the pattern of frame 30 in Figure 2, contains SID $ 50 in field 56, and a callback of the session identification code in field 57.
  • the computer 11 indicates the progress state corresponding to the closure of the update session.
  • the computer 1 2 comprises a single activatable bank of rewritable memory and two non-activatable banks of rewritable memory.
  • the single activatable bank comprises memory blocks which contain the digital components executed and / or accessed in real time by the on-board computer 1 2 when the vehicle is in operation.
  • a first non-activatable bank comprises the memory blocks mentioned above for loading the digital update component (s).
  • a second non-activatable bank is used by the second local program, one execution of which consists in copying the contents of the activatable bank into the second non-activatable bank before copying the contents of the first non-activatable bank into the single activatable bank when the operation of the vehicle is stopped, so as to activate the only bank that can be activated with the digital components updated the next time the vehicle is restarted.
  • the computer 1 2 comprises two twin activatable banks of rewritable memory.
  • a first twin activatable bank comprises memory blocks which contain the digital components executed and / or accessed in real time by the on-board computer 12 when the vehicle is in operation.
  • a second twin activatable bank includes the memory blocks discussed above for loading the digital update component (s).
  • An execution of the second local program then simply consists of switching a real-time execution boot from the first twin activatable bank to the second twin activatable bank when the operation of the vehicle is stopped, so as to activate the second twin activatable bank with the digital components updated the next time the vehicle is restarted, for which the second bank can be activated twin will play the role of the first twin activatable bank and vice versa.
  • auxiliary commands preceding the fifteenth auxiliary command can be carried out while the vehicle is in operation.
  • the two embodiments described above have the advantage of requiring only a reduced time to switch the operation of the vehicle to the execution and / or access of the digital components in real time, in other words that 'a reduced period of shutdown of the operation of the vehicle to update the digital components.
  • the target entered in field 54 is in particular a switch program reference stored in memory in computer 12. Receipt of the fifteenth auxiliary command in computer 12, validates a transition 279 which activates a step 280 in which the computer 1 2 activates the second local program, in other words the switch program before issuing a response to the fifteenth auxiliary command received which contains an acknowledgment of proper execution of the second local program.
  • the computer 11 can thus verify that the computer 12 is ready for any future access and / or execution of up-to-date digital components.
  • field 53 contains the SID $ 31 which designates a program activation identified by the reference the program reference of field 54.
  • the response to the fifteenth auxiliary command illustrated on the model of frame 30 in figure 2, contains SID $ 62 in field 56.
  • a reception in the computer 11 in response to the fifteenth auxiliary command validates a transition 309 which activates a step 310 in which the computer 11 puts the periodic signal in the ready state.
  • the periodic signal can also include a degree of progress by phases grouping together several auxiliary controls. For example, the computer 11 positions the degree of progress in step 212 to indicate a phase of checking parameters, in step 252 to indicate an installation phase in progress, and in step 310 to indicate an end of the installation phase .
  • Receipt in the computer 10 of the periodic signal in the ready state validates a transition 207 which reactivates the initial step 100 in the computer 10, awaiting a possible other main command.

Abstract

Pour dialoguer à partir d'un premier bus embarqué dans un véhicule, avec un premier calculateur connecté à un deuxième bus embarqué, connecté au premier bus par un deuxième calculateur, en traitement d'une commande principale destinée au premier calculateur, le procédé comprend des étapes dans lesquelles : - un troisième calculateur connecté au premier bus embarqué, génère (102) une commande d'écriture d'un descriptif de la commande principale dans une première zone dédiée du deuxième calculateur, puis émet (104) la commande d'écriture à destination du deuxième calculateur lorsque le deuxième calculateur est détecté (103) prêt pour répondre à la commande d'écriture; - le deuxième calculateur émet (114) à destination du premier calculateur une ou plusieurs commandes auxiliaires pour répondre à la commande principale après réception (111) de la commande d'écriture; - le premier calculateur émet (122) une réponse à chaque commande auxiliaire reçue (121) que le deuxième calculateur mémorise (116) dans une deuxième zone dédiée; - le troisième calculateur émet (108) une commande de lecture de la deuxième zone dédiée, à destination du deuxième calculateur lorsque le deuxième calculateur est détecté (107) prêt pour répondre à la commande de lecture, de sorte que le deuxième calculateur émet (124) une réponse à la commande de lecture reçue (119); - le troisième calculateur répond (126) à la commande principale à partir d'une réception (109) de réponse à la commande de lecture de la deuxième zone du deuxième calculateur.

Description

DESCRIPTION
TITRE : Procédé de dialogue avec un calculateur sur bus embarqué de véhicule.
L’invention concerne un procédé de dialogue avec un calculateur sur bus embarqué de véhicule. L’invention concerne notamment un procédé de dialogue à partir d’un premier bus embarqué dans un véhicule, avec un premier calculateur connecté à un deuxième bus embarqué du véhicule.
Le procédé selon l’invention, est particulièrement utile pour réaliser des mises à jour de calculateurs embarqués, en permettant parallèlement une exécution de programmes temps réel pour faire fonctionner le véhicule.
Les mises à jour de calculateurs embarqués et l’exécution de programmes temps réels, nécessitent généralement des émissions de commandes sur un ou plusieurs bus embarqués. Des compteurs de temps sont généralement mis en oeuvre pour contrôler la durée qui sépare l’émission d’une commande de la réception d’une réponse à cette commande, avec pour inconvénient une augmentation de durée lorsque la quantité de commandes augmente.
Par exemple le document EP1434129A2 divulgue un appareil de contrôle de réécriture pour programme embarqué dans lequel une commande de commutation est basée sur un signal issu d’un compteur de temps. L’appareil divulgué contrôle deux modes opérationnels, un mode normal qui pourrait correspondre à un mode de diagnostic et un mode de réécriture de programme embarqué, utilisable pour une mise à jour de calculateur. L’appareil divulgué commute du mode normal au mode de réécriture lorsqu’il reçoit une commande de réécriture de programme provenant d’un serveur, et commute du mode de réécriture au mode normal lorsqu’il reçoit une commande de commutation sur le mode normal pendant le mode de réécriture. Chaque commutation a pour inconvénient de quitter le mode en cours. Pour remédier aux inconvénients posés par l’état antérieur de la technique, l’invention a pour objet un procédé de dialogue à partir d’un premier bus embarqué dans un véhicule, avec un premier calculateur connecté à un deuxième bus embarqué du véhicule, le premier bus étant connecté au deuxième bus par un deuxième calculateur, dans lequel un troisième calculateur connecté au premier bus embarqué, traite une commande principale destinée au premier calculateur, comprenant des étapes dans lesquelles :
- le troisième calculateur génère une commande d’écriture d’un descriptif de ladite commande principale dans une première zone dédiée du deuxième calculateur ; - le troisième calculateur émet ladite commande d’écriture à destination du deuxième calculateur lorsque le deuxième calculateur est détecté prêt pour répondre à ladite commande d’écriture ;
- le deuxième calculateur émet à destination du premier calculateur une ou plusieurs commandes auxiliaires pour répondre à la commande principale après réception de ladite commande d’écriture ,
- le premier calculateur émet une réponse à chaque commande auxiliaire reçue ;
- le deuxième calculateur mémorise chaque réponse reçue dans une deuxième zone dédiée ;
- le troisième calculateur émet une commande de lecture de ladite deuxième zone dédiée, à destination du deuxième calculateur lorsque le deuxième calculateur est détecté prêt pour répondre à ladite commande de lecture ;
- le deuxième calculateur émet, une réponse à la commande de lecture reçue ;
- le troisième calculateur répond à la commande principale à partir d’au moins une réception de réponse à la commande de lecture de la deuxième zone du deuxième calculateur dans laquelle est mémorisée la réponse émise par le premier calculateur.
Notamment, un signal à deux états, prêt, non prêt, est émis périodiquement par le deuxième calculateur, pour lequel le procédé comprend des étapes dans lesquelles le deuxième calculateur positionne le signal :
- à l’état occupé après réception de la commande d’écriture en provenance du troisième calculateur ;
- à l’état prêt après réception de la réponse en provenance du premier calculateur.
Avantageusement, le procédé comprend une étape dans laquelle le troisième calculateur se met en attente du signal positionné à l’état prêt après avoir reçu ledit signal positionné à l’état occupé.
Particulièrement, ladite commande d’écriture comporte une première trame qui comprend un premier champ d’identifiant de commande, un premier champ d’identifiant de la première zone dédiée, et au moins un champ de descriptif de la commande principale.
Particulièrement aussi, le descriptif de la commande principale comporte un champ de type de la commande principale, un champ d’identification du deuxième calculateur, et un champ d’identification de donnée utile au deuxième calculateur pour élaborer la réponse émise.
Particulièrement aussi, le procédé comprend une étape dans laquelle le deuxième calculateur émet un acquittement à destination du premier calculateur après réception de ladite commande d’écriture.
Plus particulièrement, l’acquittement comporte une deuxième trame qui comprend un champ d’identifiant d’acquittement, et un deuxième champ d’identifiant de la première zone dédiée.
Particulièrement encore, ladite commande de lecture émise par le troisième calculateur comporte une troisième trame qui comprend un deuxième champ d’identification de commande, et un premier champ d’identifiant de la deuxième zone dédiée.
Particulièrement aussi, ladite réponse à la commande de lecture comporte une quatrième trame qui comprend un quatrième champ d’identifiant de réponse à la commande, un deuxième champ d’identifiant de la deuxième zone dédiée, au moins un champ de rappel du descriptif de la commande principale, et un champ de contenu de la réponse émise par le premier calculateur.
Spécialement, ladite commande principale est une commande pour lire une donnée résidente dans le premier calculateur, pour laquelle la commande auxiliaire comporte une cinquième trame qui comprend un champ d’identification de commande de lecture et un champ d’identification de ladite donnée résidente, de sorte que la réponse émise par le premier calculateur comporte une sixième trame qui comprend un champ d’identification de réponse à la commande de lecture, un champ d’identification de ladite donnée résidente, et un champ contenant la valeur de ladite donnée résidente.
De préférence, les commandes de lecture et les commandes d’écriture sont des commandes conformes au protocole UDS de services unifiés de diagnostic.
Le procédé peut aussi comprendre des étapes dans lesquelles :
- le deuxième calculateur vérifie si le descriptif de ladite commande principale est intègre ou non après réception de ladite commande d’écriture ;
- le deuxième calculateur émet à destination du premier calculateur une ou plusieurs commandes auxiliaires pour répondre à la commande principale uniquement si le descriptif de ladite commande principale est intègre ;
- le deuxième calculateur mémorise une alarme dans la deuxième zone dédiée si le descriptif de ladite commande principale n’est pas intègre.
D’autres avantages et caractéristiques de l’invention apparaîtront à la lecture de la description détaillée de modes de mise en oeuvre et de réalisation, à titre d’exemples illustratifs et non limitatif, en référence aux dessins annexés dans lesquels :
[Fig. 1 ] La figure 1 montre schématiquement un système embarqué de véhicule sur lequel est mise en oeuvre l’invention ;
[Fig. 2] La figure 2 montre schématiquement des trames de commandes avec lesquelles est mise en oeuvre l’invention ; [Fig. 3] La figure 3 montre des étapes de procédé conforme à l’invention pour traiter une commande principale de lecture ;
[Fig. 4] La figure 4 montre des étapes d’une première procédé conforme à l’invention pour traiter une commande principale d’installation ;
[Fig. 5] La figure 5 montre des étapes d’une deuxième partie de procédé conforme à l’invention pour traiter une commande principale d’installation ;
[Fig. 6] La figure 6 montre des étapes d’une troisième et dernière partie de procédé conforme à l’invention pour traiter une commande principale d’installation.
La figure 1 montre deux calculateurs 9, 10 connectés à un bus embarqué 1 dans un véhicule, et trois calculateurs 12, 13, 14 connectés à un bus embarqué 2 dans le véhicule. Le calculateur 9 est par exemple un calculateur embarqué dédié aux télécommunications de type IVC (In Vehicle Communication en anglais). Le calculateur 10 est par exemple un calculateur embarqué de type IVI (In Vehicle Infotainment en anglais), dont les capacités de traitement informatique sont comparables à celles d’un micro-ordinateur. D’autres calculateurs embarqués, non représentés, peuvent être connectés au bus embarqué 1 . Les calculateurs 12, 13, 14 connectés au bus embarqué 2, sont de préférence des calculateurs embarqués de contrôle-commande d’organes du véhicule de type ECU (Electronic Control Unit). Un calculateur 1 1 connecté au bus embarqué 1 et au bus embarqué 2, exerce des fonctions de passerelle entre les deux bus embarqués.
La figure 3 montre des étapes de procédé de dialogue dans lequel le calculateur 10 traite une commande principale qui est une commande pour lire une donnée résidente dans l’un des calculateurs 12, 13, 14, par exemple dans le calculateur 12. Ce type de commande est utile, par exemple pour lire une référence de composant numérique, ou un numéro de version du composant numérique dans le calculateur 12, en vue par exemple de décider si une mise à jour du composant numérique est nécessaire ou non. Le composant numérique peut concerner tant un programme exécutable, une base de données ou toute autre structure numérique comme par exemple un programme source ou une table de paramètres.
Le calculateur 10 initialement dans une étape 100 de veille, passe dans une étape 102 lorsqu’une requête de lecture soumise par un procédé d’ordre supérieur, par exemple un procédé de mise à jour du calculateur 12, valide une transition 101 . A titre illustratif, la requête de lecture peut contenir un identificateur de calculateur parmi les calculateurs 12, 13, 14 connectés sur le bus 2 embarqué, en l’occurrence l’identificateur du calculateur 12. L’identificateur de calculateur peut consister en une adresse de calculateur conforme au protocole de communication du bus 2, de type CAN (Controller Area Network), Flex Ray ou TTP aussi connus dans les domaines aéronautique, Ethernet automobile ou autre. L’identificateur de calculateur peut aussi consister en une chaîne de caractères ASCII qui nomme le calculateur dans son univers fonctionnel, par exemple « BCM » (Body Control Module pour module de contrôle de caisse en anglais), « HEVC » (Hybrid Electric Vehicle Controller pour Contrôleur de véhicule hybride électrique), « VDC » (acronyme de Vehicle Dynamic Control) ou autre. Une chaîne de caractères ASCII a pour avantage de pouvoir désigner un calculateur indépendamment d’une architecture de système embarqué. Une chaîne de caractères ASCII a aussi pour avantage de constituer un moyen mnémotechnique plus facilement compréhensible pour l’être humain. A titre illustratif encore, la requête de lecture peut contenir un identificateur de donnée 63 dans le calculateur identifié.
En étape 102, le calculateur 10 construit un descriptif de la commande principale à partir de la requête qui a validé la transition 101 , puis génère une commande d’écriture du descriptif de la commande principale dans une première zone dédiée 61 de données, résidente en mémoire du calculateur 1 1 .
La figure 2 montre un exemple de commande d’écriture qui comporte une trame 21 . La trame 21 comprend un champ 31 identifiant la commande générée en tant que commande d’écriture, un champ 32 identifiant la première zone dédiée 61 , et au moins un champ 33, 34, 35 pour contenir le descriptif 27 de la commande principale.
Le champ 33 qui compose le descriptif 27, donne un type de commande principale. A titre purement illustratif et non limitatif, le type de commande principale est par exemple identifié par deux lettres en code ASCII. La première lettre identifie une classe de commande principale, « E » pour « exécuter », « R » pour lecture ou « W » pour écriture. La deuxième lettre en combinaison avec la première, identifie une action au sein de la classe de commande principale, « EA » pour « Exécuter une Activation », « ED » pour « Exécuter un Téléchargement », « El » pour « Exécuter une Installation », « EC » pour « Exécuter une Suppression », « ER » pour « Exécuter une Réinitialisation », « RD » pour « Lire une Donnée », « RX » pour « Lire des données Etendues », « WD » pour écrire une donnée. Le champ 34 qui compose le descriptif 27, donne un identificateur de calculateur embarqué, notamment tel qu’il est indiqué dans la requête. Le champ 35 qui compose le descriptif 27, contient des paramètres utiles à l’exécution de la commande. A titre illustratif, lorsque le champ 33 contient l’un des types de commande « El », « EA », les paramètres sont des identificateurs de composants numériques à installer, respectivement à activer. Dans l’exemple illustré par la figure 3, le descriptif 27 de la commande principale comporte un champ 33 donnant le type de la commande principale « RD », un champ 34 d’identification du calculateur connecté au bus 2, par exemple le nom fonctionnel du calculateur 12, et un champ 35 de paramètres, contenant comme paramètre utile au calculateur 1 1 pour participer au traitement de la commande principale, un identificateur de donnée à lire.
Plus particulièrement, l’utilisation d’une commande d’écriture conforme au protocole UDS de services unifiés de diagnostic, présente l’avantage de bénéficier du mécanisme généralement préinstallé dans une majorité de calculateurs embarqués du monde automobile, notamment pour effectuer les fonctions de diagnostic, sans avoir à modifier les couches basses de communication pour mettre en oeuvre le procédé de dialogue conforme à l’invention. Dans ce cas particulier, le champ 31 contient alors le SID (Service Identifier pour identificateur de service en anglais) $2E qui est le code hexadécimal connu d’une écriture de données par identificateur DID.
Une transition 103 de passage de l’étape 102 à une étape 104, est validée lorsque le calculateur 1 1 est détecté prêt pour répondre à la commande d’écriture supportée par la trame 21 . De la sorte, si le calculateur 1 1 effectue une fonction de passerelle pour une autre instance du procédé de dialogue selon l’invention, ou une fonction de passerelle pour une commande générée par un autre procédé comme par exemple un procédé de diagnostic, le calculateur reste en attente sur l’étape 102. Le calculateur 10 n’encombre pas inutilement le bus 1 avec des tentatives d’émissions de commande qui resteraient sans effet en raison de l’occupation du calculateur 1 1 par d’autres fonctions. Dans l’exemple d’un traitement en cours d’une commande de diagnostic propre à un autre procédé, la mise en attente momentanée du procédé de dialogue sur l’étape 102, permet l’exécution de la commande de diagnostic sans avoir à interrompre le procédé de diagnostic.
Plusieurs solutions peuvent être envisagées pour détecter si le calculateur 1 1 est prêt pour répondre à la commande d’écriture supportée par la trame 21 . Par exemple dans le cas où le calculateur 10 serait le seul à dialoguer avec le calculateur 1 1 sur le bus 1 , une couche supérieure d’ordonnancement dans le calculateur 10, pourrait contrôler l’état prêt ou non du calculateur 1 1 . Cette solution serait difficile à mettre en oeuvre lorsqu’un autre calculateur 9, dialoguerait avec le calculateur 1 1 sur le bus 1 , par exemple pour exécuter un diagnostic à distance. Différemment, le calculateur 10 pourrait par exemple observer le bus 1 pour y détecter les trames à destination du calculateur 1 1 , pour lesquelles le calculateur 1 1 ne serait pas prêt pour répondre à la commande d’écriture supportée par la trame 21 . Cette autre solution présenterait rapidement un problème de complexité en cas de nombreux procédés empruntant la voie du bus 1 . D’autres solutions sont envisageables sans sortir du cadre de l’invention. Selon une solution préférée pour détecter si le calculateur 1 1 est prêt, c’est le calculateur 1 1 qui se déclare lui-même prêt ou non pour traiter les commandes émises dans le cadre du procédé de dialogue conforme à l’invention. Le calculateur 1 1 émet périodiquement sur le bus 1 , un signal comportant deux états, prêt, occupé ou non prêt.
Dans une étape initiale 1 10 de veille, le calculateur 1 1 positionne par défaut le signal à l’état prêt. Dès que le calculateur 1 1 reçoit une commande, que ce soit du procédé de dialogue selon l’invention ou de tout autre procédé comme par exemple du procédé de diagnostic, le calculateur 1 1 positionne le signal à l’état occupé jusqu’à avoir terminé le traitement de la commande en cours.
En étape 104, le calculateur 1 1 ayant été détecté prêt pour répondre à la commande d’écriture, le calculateur 10 émet la commande d’écriture à destination du calculateur 1 1 . Pour émettre la commande d’écriture, le calculateur 10 peut encapsuler la trame 21 dans une trame CAN sur le bus 1 , ou d’autre manière, par exemple encapsuler la trame 21 dans une trame sur IP si le protocole Ethernet pour véhicule est utilisé sur le bus 1 .
Une réception de la commande d’écriture dans le calculateur 1 1 , valide une transition 1 1 1 qui est nécessaire pour faire passer le calculateur 1 1 de l’étape initiale 1 10 à une étape 1 14 dans laquelle le calculateur 1 1 émet à destination de celui des calculateurs 1 2, 1 3, 1 4 identifié dans le champ 34, par exemple le calculateur 1 2, une commande auxiliaire pour répondre à la commande principale, à partir du descriptif 27 de la commande principale, écrit dans la zone dédiée 61 de données du calculateur 1 1 .
Dans le cas particulier de la figure 3 pour lequel la commande principale est une commande pour lire une donnée résidente dans le calculateur 12, la figure 2 donne un exemple de commande auxiliaire qui comporte une trame 25 comprenant un champ 48 d’identification de commande de lecture et un champ 49 d’identification de la donnée résidente dans le calculateur 12. Plus particulièrement, l’utilisation d’une commande de lecture conforme au protocole UDS de services unifiés de diagnostic, présente les avantages ci- dessus mentionnés. Dans ce cas particulier, le champ 48 contient alors le SID $22 qui est le code hexadécimal connu d’une lecture de données par identificateur DID. Le champ 49 contient l’identificateur DID de la zone de données 63 du calculateur 12 qui était indiquée dans le champ 35 de la trame 21 .
La transition 1 1 1 peut faire passer directement le procédé de l’étape initiale 1 10 à l’étape 1 14. De préférence mais non nécessairement, la transition 1 1 1 fait passer le procédé de l’étape initiale 1 10 à une étape intermédiaire 1 12.
Dans l’étape 1 12, le calculateur 1 1 vérifie si le descriptif de commande principale 27 est intègre ou non, au regard de règles de sécurité préétablies qui ne font pas l’objet de la présente invention. Dans le cas où l’étape 1 12 est mise en oeuvre, une transition 1 13 est validée si le descriptif de commande principale 27 est vérifié intègre, ou une transition 1 17 est validée si le descriptif de commande principale 27 est vérifié non intègre. L’étape 1 14 est alors activée après validation de la transition 1 13.
Dans l’étape 1 14, ou dès l’étape 1 12 si elle existe, le calculateur 1 1 positionne le signal périodique à l’état occupé, en d’autres termes après validation de la transition 1 1 1 par réception de la commande d’écriture en provenance du calculateur 10. Concomitamment, le calculateur 1 1 répond à la commande d’écriture par émission d’un accusé de bonne réception ou acquittement. Par exemple, dans le cas de l’utilisation du protocole UDS, le calculateur 1 1 émet une trame 22 dont un premier champ 37 contient le code SID de valeur $6E, et dont un deuxième champ 38 contient la valeur du champ 32 de la trame 21 pour permettre au calculateur 10 de reconnaître la commande d’écriture émise à laquelle correspond l’accusé de réception reçu. En d’autres termes, le champ 38 constitue un champ d’identifiant de la première zone dédiée 61 .
Une réception par le calculateur 10 du signal périodique positionné à l’état occupé, ou de la trame 22, valide une transition 105 qui fait passer le procédé de l’étape 104 à une étape 106 dans le calculateur 10. Dans l’étape 106, le calculateur 10 se met en attente du signal positionné à l’état prêt.
Le calculateur 12 initialement dans une étape de veille 120 du procédé de dialogue conforme à l’invention, valide une transition 121 lorsqu’il reçoit la commande auxiliaire matérialisée par la trame 25 émise par le calculateur 1 1 sur le bus 2 embarqué. Une validation de la transition 121 active une étape 122 dans laquelle le calculateur 12 émet une réponse à la commande auxiliaire reçue. La réponse émise à destination du calculateur 1 1 , comporte une trame 26 qui comprend un champ 50 d’identification de réponse, ici à la commande de lecture, un champ 51 d’identification de ladite donnée résidente, et un champ 52 contenant une valeur de la donnée résidente 63 identifiée par le champ 51 , comme illustré sur la figure 2.
Dans le cas particulièrement avantageux d’utilisation du protocole UDS, le champ 50 contient alors le SID $62 qui est le code hexadécimal connu d’une réponse à lecture de données par identificateur DID. Le champ 51 contient l’identificateur DID de la zone de données 63 du calculateur 12 qui était indiquée dans le champ 49 de la trame 25. Le calculateur 12 retourne ensuite à l’étape de veille 120.
Une réception de la réponse par le calculateur 1 1 valide une transition 1 15 qui fait passer le procédé de dialogue de l’étape 1 14 à une étape 1 16 dans laquelle la calculateur 1 1 génère un descriptif de réponse 28 à la commande principale qui ici est une commande pour lire la donnée résidente 63 dans le calculateur 12. Le descriptif de réponse 28 comprend des champs 43, 44, 45 qui contiennent chacun respectivement les valeurs des champs 33, 34, 35 du descriptif de commande 27 pour identifier que le descriptif de réponse est bien celui qui correspond au descriptif de commande principale. Le descriptif de réponse 28 comprend aussi un champ 47 qui contient la valeur contenue dans le champ 52 de la trame 26. Le calculateur 1 1 mémorise le descriptif de réponse 28 dans une deuxième zone dédiée 62 de données, résidente en mémoire du calculateur 1 1 . Dans l’étape 1 16, le calculateur 1 1 positionne ensuite le signal périodique à l’état prêt.
Une transition 107 est validée lorsque le calculateur 10 détecte que le calculateur 1 1 est prêt pour répondre. Dans le cas d’un mode de mise en oeuvre préférée de l’invention, la transition 107 est validée par la réception du signal périodique à l’état prêt.
Une validation de la transition 107 active une étape 108 dans le calculateur 10. En étape 108, le calculateur 1 1 ayant été détecté prêt pour répondre à une commande de lecture, le calculateur 10 émet une commande de lecture de la deuxième zone dédiée 62, à destination du calculateur 1 1 . La commande de lecture est par exemple matérialisée par une trame 23 comme représentée en figure 2. La trame 23 comprend un champ 39 d’identification de commande en tant que commande de lecture, et un champ 40 d’identifiant de la deuxième zone dédiée 62 de données.
Notamment, dans le cas avantageux d’utilisation du protocole UDS, le champ 39 contient la valeur $22 qui identifie une commande de lecture, et le champ 40 contient une valeur de DID qui est l’adresse de la zone dédiée 62 de données en mémoire du calculateur 1 1 .
Une transition 1 19 est validée lorsque le calculateur 1 1 reçoit la commande de lecture matérialisée par la trame 23.
Une validation de la transition 1 19 active une étape 124 dans laquelle le calculateur 1 1 émet une réponse à destination du calculateur 10. La réponse à la commande de lecture reçue comporte une trame 24 qui comprend un champ 41 d’identifiant de réponse à commande de lecture, et un champ 42 d’identifiant de la deuxième zone dédiée 62, de manière à pouvoir vérifier que la trame 24 constitue la réponse à la commande de lecture matérialisée par la trame 23. La trame 24 contient à la suite le descriptif 28 qui comporte les champs 43, 44, 45 contenant chacun une valeur égale respectivement à celle contenue dans chacun des champs 33, 34, 35 pour rappeler le descriptif de la commande principale. Le descriptif 28 comporte aussi le champ 47 qui contient la réponse à la commande principale.
Le calculateur 1 1 retourne ensuite dans l’étape initiale 1 10 de veille au regard du procédé de dialogue selon l’invention.
Une transition 109 est validée lorsque le calculateur 10 reçoit la réponse à la commande de lecture, matérialisée par la trame 24.
Une validation de la transition 109 active une étape 126 dans laquelle le calculateur 10 répond à la commande principale à partir du contenu du champ 47 extrait de la réponse à la commande de lecture de la deuxième zone dédiée du calculateur 1 1 dans laquelle est mémorisée la réponse émise par le calculateur 12.
Le calculateur 10 retourne ensuite dans l’étape initiale 100 de veille au regard du procédé de dialogue selon l’invention.
On retiendra de l’exposé qui précède que l’utilisation du protocole UDS pour les commandes du procédés de dialogue selon l’invention, permet de traiter une commande principale qui compose un procédé de mise à jour de calculateur, sans avoir à commuter d’un mode de diagnostic à un mode de mise à jour. Les commandes restent des commandes de diagnostic au niveau du dialogue entre calculateurs. Un traitement de fonction de mise à jour s’effectue par un traitement de commande principale dans le calculateur 10 à un niveau de couche supérieure, de manière comparable à un traitement de fonction de diagnostic. Le calculateur 1 1 peut traiter des trames liées à des fonctions de diagnostic en les transférant directement du bus 1 au bus 2 et réciproquement, en tant que passerelle. Le calculateur 1 1 peut traiter des trames liées à des fonctions de diagnostic en les en les traitant par des fonctions de diagnostic résidentes dans le calculateur 1 1 . Le calculateur 1 1 peut traiter des trames liées à des fonctions de mise à jour par des fonctions de mise à jour résidentes dans le calculateur 1 1 comme il le ferait pour par des fonctions de diagnostic résidentes dans le calculateur 1 1 . Une seule pile protocolaire suffit, à savoir la pile protocolaire UDS, pour traiter tant des commandes purement de diagnostic que des commandes de mise à jour. Lorsqu’une commande purement de diagnostic est transmise du bus 1 au bus 2 en absence de commande liée à la mise à jour de copmposant numérique, le calculateur 1 1 positionne le signal périodique à l’état occupé, mettant simplement en attente une commande liée à la mise à jour qui se présenterait pendant le traitement de la commande purement de diagnostic. Lorsqu’une commande liée à la mise à jour est transmise du bus 1 au bus 2 en absence de commande purement de diagnostic, le calculateur 1 1 positionne le signal périodique à l’état occupé, ignorant simplement la commande purement de diagnostic qui se présenterait pendant le traitement de la commande liée à la mise à jour de composant numérique, laissant libre le procédé de diagnostic de réémettre la commande purement de diagnostic lorsque le calculateur 1 1 repositionne le signal périodique à l’état prêt.
L’émission des commandes de lecture et d’écriture liées au traitement de la commande principale à partir du calculateur 10 connecté au bus 1 embarqué, ne nécessite pas de commande reçue d’un serveur distant pour relancer un processus de mise à jour dès que le signal périodique est positionné à l’état prêt. Ainsi le processus de mise à jour peut se faire sans nécessiter de connexion à distance du véhicule dans la mesure où les données de mise à jour ont été préalablement téléchargées dans le calculateur 10.
Ce qui vient d’être expliqué à titre illustratif pour un processus de mise à jour concomitant à un processus de diagnostic, est applicable à d’autres processus concomitant au processus de diagnostic par mise en oeuvre du procédé de dialogue selon l’invention.
La commande principale du procédé de dialogue, quand elle est pour lire une donnée dans l’un des calculateur 12, 13, 14 connecté au bus 2, pourrait plus simplement être mise en oeuvre par une simple commande de lecture de la donnée à destination directement de celui des calculateur 12, 13, 14 qui héberge la donnée, par exemple le calculateur 12. Cependant cette solution a priori plus simple poserait un problème de gestion de la durée totale qui séparerait l’émission de la simple commande de lecture et la réception de la réponse, durée qui serait la somme des durées nécessaires à la transmission de la simple commande de lecture du calculateur 10 au calculateur 1 1 , puis à la transmission de la simple commande de lecture du calculateur 1 1 au calculateur 12, de l’émission de la réponse par le calculateur 12, de la transmission de la réponse du calculateur 12 au calculateur 1 1 , puis à la transmission de la réponse du calculateur 1 1 au calculateur 10. Cette durée totale pourrait se révéler rapidement rédhibitoire en cas de forte activité sur les bus 1 et 2 comme c’est souvent le cas dans un véhicule en fonctionnement.
Le remplacement de la simple commande de lecture par une commande d’écriture dans la première zone dédiée de données du calculateur 1 1 , suivie d’une commande de lecture dans la deuxième zone dédiée de données du calculateur 1 1 , permet de s’affranchir du problème de durée trop longue évoquée au paragraphe précédent. Une première durée qui sépare la commande d’écriture de l’invention et la réponse à la commande d’écriture se réduit à la somme des durées nécessaires à la transmission de la commande d’écriture du calculateur 10 au calculateur 1 1 , puis à la transmission de la réponse, généralement un simple acquittement, du calculateur 1 1 au calculateur 10. Une deuxième durée qui sépare la commande de lecture de l’invention et la réponse à la commande de lecture se réduit à la somme des durées nécessaires à la transmission de la commande de lecture du calculateur 10 au calculateur 1 1 , puis à la transmission de la réponse du calculateur 1 1 au calculateur 10. Peu importe une troisième durée qui sépare la fin de la première durée et le début de la deuxième durée car dans l’étape d’attente 106 du procédé, il suffit de lire en permanence l’état du signal périodique jusqu’à le détecter prêt. Notamment, le procédé est robuste au regard d’une interruption qui interviendrait pendant ladite troisième durée, par exemple en cas de mise hors contact électrique du véhicule. Le procédé selon l’invention peut reprendre dans l’étape dans laquelle il s’était arrêté avant l’interruption. Selon la variante de réalisation qui comprend l’étape 1 12 dans laquelle le calculateur 1 1 vérifie si le descriptif 27 de la commande principale est intègre ou non, une transition 1 17 est validée lorsque le descriptif 27 de la commande principale est vérifié non intègre. Une validation de la transition 1 17 active une étape 1 18 dans laquelle le calculateur 1 1 mémorise une alarme dans la deuxième zone dédiée 62 puis positionne le signal périodique à l’état prêt.
Le procédé de dialogue selon l’invention est applicable à d’autres commandes principales que la commande principale pour lire une donnée dans un premier calculateur connecté au bus 2 embarqué, en traitement de laquelle le calculateur 1 1 émet à destination du premier calculateur une seule commande auxiliaire consistant en une commande de lecture de la donnée, de manière à répondre à la commande principale.
La figure 4 montre des étapes de procédé de dialogue dans lequel le calculateur 10 traite une commande principale qui est une commande pour installer un composant numérique, par exemple dans le calculateur 12. Ce type de commande est utile, par exemple pour installer un ou plusieurs composants numériques. Le composant numérique peut concerner tant un programme exécutable, une base de données ou toute autre structure numérique comme par exemple un programme source ou une table de paramètres de configuration.
Le calculateur 10 initialement dans l’étape 100 de veille, passe dans une étape 202 lorsqu’une requête d’installation soumise par un procédé d’ordre supérieur, par exemple un procédé de mise à jour du calculateur 12, valide une transition 201. A titre illustratif, la requête d’installation peut contenir un identificateur de calculateur parmi les calculateurs 12, 13, 14 connectés sur le bus 2 embarqué, en l’occurrence l’identificateur du calculateur 12. A titre illustratif encore, la requête d’installation peut contenir un fichier, par exemple au format HTML avec des balises identifiant des blocs de mémoire physique du calculateur 12 dans chacun desquels écrire un contenu du fichier HTML compris entre deux balises identifiant un même bloc de mémoire physique 64. Les blocs de mémoire physique sont de type à mémoire permanente réinscriptible, par exemple de type EEPROM.
En étape 202, le calculateur 10 construit un descriptif de la commande principale à partir de la requête qui a validé la transition 201 , puis génère une commande d’écriture du descriptif de la commande principale dans la première zone dédiée 61 de données, résidente en mémoire du calculateur 1 1.
La figure 2 montre un exemple de commande d’écriture pour lequel le champ 31 de la trame 21 identifie de manière constante la commande générée en tant que commande d’écriture, le champ 32 identifie de manière constante la première zone dédiée 61. Dans le descriptif 27 de la commande principale, le champ 33 comprend par exemple deux lettres « El » qui indiquent une commande principale de type « Exécuter Installation ». Dans l’exemple illustré par la figure 4, le champ 34 identifie, notamment nommément le calculateur cible connecté au bus 2 auquel s’applique la commande principale, par exemple le calculateur 1., Le champ 35, contient un paramètre dont la valeur identifie un paquet contenant au moins un composant numérique à installer dans le calculateur cible.
Dans le cas particulier d’utilisation d’une commande d’écriture conforme au protocole UDS, le champ 31 contient alors le SID $2E qui est le code hexadécimal connu d’une écriture de données par identificateur DID, ici correspondant à la zone dédiée 61.
Une transition 203 de passage de l’étape 202 à une étape 204, est validée lorsque le calculateur 1 1 est détecté prêt pour répondre à la commande d’écriture supportée par la trame 21. Ici encore, si le calculateur 1 1 effectue une fonction de passerelle pour une autre instance du procédé de dialogue selon l’invention, ou une fonction de passerelle pour une commande générée par un autre procédé comme par exemple un procédé de diagnostic, le calculateur reste en attente sur l’étape 202. Le calculateur 10 n’encombre pas inutilement le bus 1 avec des tentatives d’émissions de commande qui resteraient sans effet en raison de l’occupation du calculateur 1 1 par d’autres fonctions. Dans l’exemple d’un traitement en cours d’une commande de diagnostic propre à un autre procédé, la mise en attente momentanée du procédé de dialogue sur l’étape 202, permet l’exécution de la commande de diagnostic sans avoir à interrompre le procédé de diagnostic.
Il est possible de détecter si le calculateur 1 1 est prêt, par exemple au moyen du signal comportant deux états, prêt, occupé, émis par le calculateur 1 1 périodiquement sur le bus 1 , un signal.
Dans l’étape initiale 1 10 de veille, le calculateur 1 1 positionne par défaut le signal à l’état prêt. Dès que le calculateur 1 1 reçoit une commande, que ce soit du procédé de dialogue selon l’invention ou de tout autre procédé comme par exemple du procédé de diagnostic, le calculateur 1 1 positionne le signal à l’état occupé jusqu’à avoir terminé le traitement de la commande en cours.
En étape 204, le calculateur 1 1 ayant été détecté prêt pour répondre à la commande d’écriture, le calculateur 10 émet la commande d’écriture à destination du calculateur 1 1 . Pour émettre la commande d’écriture, le calculateur 10 peut encapsuler la trame 21 dans une trame CAN sur le bus 1 , ou d’autre manière, par exemple encapsuler la trame 21 dans une trame sur IP si le protocole Ethernet pour véhicule est utilisé sur le bus 1 .
Une réception de la commande d’écriture dans le calculateur 1 1 , valide une transition 21 1 qui fait passer le calculateur 1 1 de l’étape initiale 1 10 à une étape 212 dans laquelle le calculateur 1 1 écrit le descriptif 27 dans la première zone dédiée 61 puis émet sans délai à destination du calculateur 1 0 un accusé de bonne exécution de la commande d’écriture . A titre illustratif en cas d’utilisation du protocole U DS, l’accusé de bonne exécution de la commande d’écriture, est matérialisé par la trame 22 dans laquelle le champ 37 contient la valeur $6E et le champ 38 contient le D I D de la zone 61 . Une réception de la trame 22 dans le calculateur 10, valide une transition 205 qui fait passer le calculateur 10 de l’étape 204 à une étape 206 dans laquelle le calculateur 10 lit l’état du signal périodiquement émis par le calculateur 1 1 , en attente de lire l’état prêt. Dans une variante avantageuse du procédé selon l’invention, le signal périodique comporte de plus une indication d’état de progression de l’exécution des étapes dans le calculateur 1 1 .
En étape 21 2, le calculateur 1 1 positionne le signal périodique à l’état occupé puis émet à destination de celui des calculateurs 1 2, 1 3, 1 4 identifié dans le champ 34, par exemple le calcu lateur 1 2, une succession d’une ou plusieurs premières commandes auxiliaires pour répondre à la commande principale, à partir du descriptif 27 de la commande principale, écrit dans la zone dédiée 61 de données du calculateur 1 1 . Lorsque le signal périodique comporte de plus une indication d’état de progression, le calculateur 1 1 indique l’état de progression correspondant à l’étape 212.
Dans le cas particulier de la figure 4 pour lequel la commande principale est une commande pour installer au moins un composant numérique dans le calculateur, chaque première commande auxiliaire consiste à lire un attribut du calculateur 12, dont la connaissance est utile pour installer correctement le ou les composants numériques. On peut utiliser à titre de première commande auxiliaire, l’exemple donné en figure 2 qui comporte la trame 25 comprenant le champ 48 d’identification de commande de lecture et le champ 49 d’identification de la donnée résidente dans le calculateur 12, correspondant à l’attribut lu.
Une réception de la succession de premières commandes auxiliaires dans le calculateur 1 2, valide une transition 221 qui active une étape 222 dans laquelle le calculateur 1 2 émet une réponse à chaque première commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 48 contient le SID $22. Chaque réponse à première commande auxiliaire sur le modèle de la trame 26 en figure 2, contient le SID $62 dans le champ 50, l’identification de l’attribut dans le champ 51 et la valeur lue de l’attribut dans le champ 52.
Une réception dans le calculateur 1 1 de dernière réponse à la succession de premières commandes auxiliaires, valide une transition 213 qui fait passer le calculateur 1 1 de l’étape 212 à une étape 214 dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une succession d’une ou plusieurs deuxièmes commandes auxiliaires pour vérifier que le calculateur 1 2 n’est pas troublé par un défaut susceptible de nuire à l’installation du composant numérique.
La figure 2 donne un exemple de commande auxiliaire qui comporte une trame 29 comprenant un champ 53 de désignation de commande auxiliaire, un champ 54 d’identification de cible dans le calculateur 12, sur laquelle porte la commande auxiliaire, et accessoirement qui comprend ou non un champ 55 d’extension de commande. Pour une deuxième commande auxiliaire, la cible est notamment un code de défaut.
Une réception de la succession de deuxièmes commandes auxiliaires dans le calculateur 1 2, valide une transition 223 qui active une étape 224 dans laquelle le calculateur 1 2 émet une réponse à chaque deuxième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $29 qui désigne une lecture d’information DTC (acronyme de « Diagnostic Trouble Codes » pour « Codes de Trouble Diagnostiqué » en anglais). Le champ 54 contient un code d’identification de défaut sur généralement cinq caractères alphanumériques. A titre purement illustratif et non limitatif, le premier caractère est la lettre P pour désigner un groupe motopropulseur du véhicule (par exemple comprenant moteur et boîte de vitesses), la lettre C pour désigner un châssis du véhicule, la lettre B pour désigner un corps du véhicule, la lettre U pour désigner un réseau utilisateur. A titre aussi purement illustratif et non limitatif, le deuxième caractère est le chiffre 0 pour désigner un défaut générique, le chiffre 1 pour désigner un défaut de fabrication. Les caractères suivants se réfèrent à des éléments de sous-système du système identifié par la lettre en tête du code de défaut, par exemple P01 xx pour les mesures de carburant et de comburant, P02xx pour les mesures de carburant et de comburant plus spécifiquement liées au circuit d’injection, P04xx pour les contrôles auxiliaires d’émission. Chaque réponse à deuxième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $59 dans un champ 56, un rappel du code de défaut dans un champ 57 et la valeur lue d’un état du code de défaut dans un champ 59, par exemple en défaut ou hors défaut.
Lorsque le signal périodique comporte de plus une indication d’état de progression, le calculateur 1 1 indique l’état de progression correspondant à l’état en défaut ou hors défaut contenu dans le champ 59.
Une réception dans le calculateur 1 1 de dernière réponse à la succession de deuxièmes commandes auxiliaires, valide une transition 215 qui fait passer le calculateur 1 1 de l’étape 214 à une étape 216 dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une troisième commande auxiliaire pour démarrer une session de mise à jour.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la troisième commande auxiliaire. Pour la troisième commande auxiliaire, la cible est notamment de clôturer l’opération effectuée dans le calculateur 12.
Une réception de la troisième commande auxiliaire dans le calculateur 1 2, valide une transition 225 qui active une étape 226 dans laquelle le calculateur 1 2 émet une réponse à la troisième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $10 qui désigne un contrôle de session diagnostique. On rappelle qu’une disponibilité de différents services, dépend de la session de diagnostic qui est active. Par exemple la session nommée « Extended Diagnostic Session » est utilisée pour libérer des fonctions additionnelles de diagnostic comme par exemple l’ajustement de capteurs. Par exemple encore, la session nommée « Safety System Diagnostic Session » est utilisée pour tester toutes les fonctions de diagnostic critiques pour la sécurité comme par exemple de tester les coussins gonflables. En absence de session de diagnostic particulière, une session par défaut « Default Session » est généralement active, notamment en étape 120 et maintenue jusqu’à validation de la transition 225. Le champ 54 contient un code d’identification de session qui en l’occurrence, est spécifiquement dédiée à l’installation d’un ou plusieurs composants numériques dans le calculateur 12, nommé par exemple « FOTA ». La réponse à troisième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $50 dans le champ 56, et un rappel du code d’identification de session dans le champ 57. Lorsque le signal périodique comporte de plus une indication d’état de progression, le calculateur 1 1 indique l’état de progression correspondant à l’ouverture de la session de mise à jour.
Une réception dans le calculateur 1 1 de réponse à la troisième commande auxiliaire, valide une transition 217 qui fait passer le calculateur 1 1 de l’étape 216 à une étape 218 dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une quatrième commande auxiliaire pour vérifier une absence de défauts dans les blocs mémoires du calculateur 1 2, en vue de leur utilisation pour y écrire des mises à jour de composants numériques.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la quatrième commande auxiliaire. Pour la quatrième commande auxiliaire, la cible est notamment un code de défaut mémoire.
Une réception de la quatrième commande auxiliaire dans le calculateur 1 2, valide une transition 227 qui active une étape 228 dans laquelle le calculateur 1 2 émet une réponse à la quatrième commande auxiliaire reçue. En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $19 qui désigne une lecture de défaut diagnostiqué. La réponse à quatrième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $59 dans le champ 56, et un rappel du code de défaut dans le champ 57. Le champ 59 contient une valeur qui indique si le défaut identifié par le code contenu dans le champ 57, est présent ou absent. Lorsque le signal périodique comporte de plus une indication d’état de progression, le calculateur 1 1 indique l’état de progression correspondant à l’état de présence ou d’absence du défaut contenu dans le champ 59.
Une réception dans le calculateur 1 1 de réponse à la dernière quatrième commande auxiliaire, valide une transition 219 qui fait passer le calculateur 1 1 de l’étape 218 à une étape 220 dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une succession de cinquièmes commandes auxiliaires pour vérifier une absence de défauts dans les compteurs de blocs mémoires du calculateur 1 2, en vue de leur utilisation pour écrire les mises à jour de composants numériques dans les blocs mémoire.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser chaque cinquième commande auxiliaire. Pour la cinquième commande auxiliaire, la cible est notamment un code de défaut compteur mémoire.
Une réception de la succession de cinquièmes commandes auxiliaires dans le calculateur 1 2, valide une transition 229 qui active une étape 230 dans laquelle le calculateur 1 2 émet une réponse à chaque cinquième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $19 qui désigne une lecture de défaut diagnostiqué. La réponse à chaque cinquième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $59 dans le champ 56, et un rappel du code de défaut dans le champ 57. Le champ 59 contient une valeur qui indique si le défaut identifié par le code contenu dans le champ 57, est présent ou absent. Lorsque le signal périodique comporte de plus une indication d’état de progression, le calculateur 1 1 indique l’état de progression correspondant à l’état de présence ou d’absence du défaut contenu dans le champ 59.
La figure 5 montre les étapes qui suivent celles de la figure 4. Une réception dans le calculateur 1 1 de réponse à la dernière cinquième commande auxiliaire, valide une transition 251 qui fait passer le calculateur 1 1 de l’étape 220 à une étape 252 de première boucle dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une sixième commande auxiliaires pour lire une adresse de début de premier bloc mémoire en mémoire du calculateur 1 2.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser chaque sixième commande auxiliaire. Pour la sixième commande auxiliaire, la cible est notamment une référence DID de donnée relative à un registre d’adressage de blocs mémoire dans le calculateur 12.
Une réception de la sixième commande auxiliaire dans le calculateur 1 2, valide une transition 261 qui active une étape 262 dans laquelle le calculateur 1 2 émet une réponse à la sixième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $22 qui désigne une lecture de donnée identifiée par la référence DID du champ 54. La réponse à la sixième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $62 dans le champ 56, et un rappel de la référence DID dans le champ 57. Le champ 59 contient une valeur qui indique l’adresse de début du premier bloc mémoire prévu pour y charger le premier composant numérique.
Une réception dans le calculateur 1 1 de réponse à la sixième commande auxiliaire, valide une transition 253 qui fait passer le calculateur 1 1 de l’étape 252 à une étape 254 de la première boucle dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une septième commande auxiliaires pour écrire une référence de premier composant numérique en tête du premier bloc mémoire en mémoire du calculateur 1 2.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser chaque septième commande auxiliaire. Pour la septième commande auxiliaire, la cible est notamment une référence DID de donnée relative à un registre de nommage de composants numériques dans le calculateur 12.
Une réception de la septième commande auxiliaire dans le calculateur 1 2, valide une transition 263 qui active une étape 264 dans laquelle le calculateur 1 2 émet une réponse à la septième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $2E qui désigne une écriture de donnée identifiée par la référence DID du champ 54. La réponse à la septième commande auxiliaire, illustrée sur le modèle de la trame 30 en figure 2, contient le SID $6E dans le champ 56, et un rappel de la référence DID dans le champ 57. Le champ 59 contient une valeur qui indique un acquittement de la commande d’écriture.
Une réception dans le calculateur 1 1 de réponse à la septième commande auxiliaire, valide une transition 255 qui fait passer le calculateur 1 1 de l’étape 254 à une étape 256 de la première boucle dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une huitième commande auxiliaires pour requérir un chargement de composant numérique dans un premier bloc mémoire du calculateur 1 2.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la huitième commande auxiliaire. Pour la huitième commande auxiliaire, la cible est notamment l’adresse du premier bloc mémoire.
Une réception de la huitième commande auxiliaire dans le calculateur 1 2, valide une transition 265 qui active une étape 266 dans laquelle le calculateur 1 2 efface le contenu du bloc mémoire en cours puis émet une réponse à la huitième commande auxiliaire reçue, qui accuse la bonne exécution de la huitième commande. On rappelle ici qu’un bloc de mémoire physique de type réinscriptible, nécessite un effacement préalablement à une réécriture.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $34 qui désigne une requête de chargement du calculateur 1 1 vers le calculateur 12. Un champ 55 contient une taille du composant numérique à charger. La réponse à la huitième commande auxiliaire, illustrée sur le modèle de la trame 30 en figure 2, contient le SID $74 dans le champ 56, et un rappel de l’adresse du bloc mémoire dans le champ 57. Le champ 58 rappelle la taille du composant numérique à charger. Le champ 59 contient une valeur qui indique une taille maximale acceptable de chargement.
Une réception dans le calculateur 1 1 de réponse à la huitième commande auxiliaire, valide une transition 257 qui fait passer le calculateur 1 1 de l’étape 256 à une étape 258 de la première boucle dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une neuvième commande auxiliaire pour transférer le contenu de composant numérique vers le premier bloc mémoire du calculateur 1 2.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la neuvième commande auxiliaire. Pour la neuvième commande auxiliaire, la cible est notamment l’adresse du premier bloc mémoire.
Une réception de la neuvième commande auxiliaire dans le calculateur 1 2, valide une transition 267 qui active une étape 268 dans laquelle le calculateur 1 2 émet une réponse à la neuvième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $36 qui désigne une commande de transfert de contenu de composant numérique dans le bloc de mémoire physique courant. De manière connue, le transfert est réalisé par paquets de taille maximale. Si la taille du contenu dépasse la taille maximale d’un paquet. Le transfert est réitéré jusqu’à transmission totale du contenu. La réponse à la neuvième commande auxiliaire, illustrée sur le modèle de la trame 30 en figure 2, contient le SID $76 dans le champ 56, et un rappel de l’adresse du bloc mémoire dans le champ 57.
Une réception dans le calculateur 1 1 de réponse à la neuvième commande auxiliaire, valide une transition 259 qui fait passer le calculateur 1 1 de l’étape 258 à une étape 260 de la première boucle dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une dixième commande auxiliaire pour quitter le transfert.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la dixième commande auxiliaire.
Une réception de la dixième commande auxiliaire dans le calculateur 1 2, valide une transition 269 qui active une étape 270 dans laquelle le calculateur 1 2 émet une réponse à la dixième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $37 qui désigne une commande de sortie du mode de transfert. La réponse à la neuvième commande auxiliaire, illustrée sur le modèle de la trame 30 en figure 2, contient le SID $77 dans le champ 56, et un rappel de l’adresse du bloc mémoire dans le champ 57.
Une réception dans le calculateur 1 1 de réponse à la dixième commande auxiliaire, valide une transition 291 qui fait passer le calculateur 1 1 de l’étape 260 à une étape 292 de la première boucle dans laquelle le calculateur 1 1 vérifie s’il existe un composant numérique suivant à charger dans un bloc mémoire suivant. Une présence de composant numérique suivant valide une transition 293 qui reboucle le procédé sur une réexécution des étapes 252 à 292, adaptées chacune au bloc de mémoire physique suivant en termes d’identification, de taille et d’adresse de bloc mémoire. Une absence de composant numérique nécessitant un bloc de mémoire physique suivant, valide une transition 295 qui active une étape 296 dans laquelle le calculateur 1 1 émet à destination du calculateur 12, une onzième commande auxiliaire pour vérifier une absence de défauts dans l’écriture des blocs mémoires du calculateur 12. II est possible ici encore d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la onzième commande auxiliaire. Pour la onzième commande auxiliaire, la cible est notamment un code de défaut mémoire.
Une réception de la onzième commande auxiliaire dans le calculateur 1 2, valide une transition 271 qui active une étape 272 dans laquelle le calculateur 12 émet une réponse à la onzième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $19 qui désigne une lecture de défaut diagnostiqué. La réponse à onzième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $59 dans le champ 56, et un rappel du code de défaut dans le champ 57. Le champ 59 contient une valeur qui indique si le défaut identifié par le code contenu dans le champ 57, est présent ou absent.
La figure 6 montre les dernières étapes du procédé à la suite de celles illustrées par la figure 5. Une réception dans le calculateur 1 1 de réponse à la onzième commande auxiliaire, valide une transition 297 de deuxième boucle qui active une étape 298 dans laquelle le calculateur 1 1 émet à destination du calculateur 12, une douzième commande auxiliaire pour activer un premier programme local dans lequel le calculateur 12 vérifie que le premier composant numérique a été correctement écrit dans le premier bloc mémoire en mémoire du calculateur 1 2.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser chaque douzième commande auxiliaire. Pour la douzième commande auxiliaire, la cible inscrite dans le champ 54 est notamment une référence de programme condenseur stocké en mémoire dans le calculateur 12. Le champ 55 contient une adresse du bloc mémoire à vérifier.
Une réception de la douzième commande auxiliaire dans le calculateur 1 2, valide une transition 273 qui active une étape 274 dans laquelle le calculateur 1 2 active le programme condenseur qui consiste notamment à calculer un condensât du contenu écrit dans le bloc de mémoire physique. Le calculateur 12 émet une réponse à la douzième commande auxiliaire reçue qui contient le condensât calculé. La réponse à la douzième commande auxiliaire permet au calculateur 1 1 de comparer le condensât calculé par le calculateur 1 2 à un condensât détenu par le calculateur 1 1 préalablement au chargement de contenu dans le bloc de mémoire physique. Le calculateur 1 1 peut ainsi vérifier que le contenu du bloc de mémoire physique après réécriture, est conforme au contenu à charger dans le bloc de mémoire physique.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $31 qui désigne une activation de programme identifié par la référence la référence de programme du champ 54. La réponse à la douzième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $62 dans le champ 56, et un rappel de la référence DID dans le champ 57. Le champ 59 contient une valeur qui indique l’adresse de début du premier bloc mémoire prévu pour y charger le premier composant numérique.
Une réception dans le calculateur 1 1 de réponse à la sixième commande auxiliaire, valide une transition 299 qui active une étape 300 dans laquelle le calculateur 1 1 vérifie s’il existe un bloc de mémoire physique suivant pour un chargement suivant de composant numérique.
Une existence de bloc mémoire physique suivant valide une transition 301 qui reboucle sur l’étape 298 dans laquelle le premier bloc est remplacé par le bloc suivant et ainsi de suite jusqu’au dernier bloc de mémoire physique.
Une absence de bloc mémoire physique suivant, valide une transition 303 qui active une étape 304 dans laquelle calculateur 1 1 émet à destination du calculateur 12, une treizième commande auxiliaire pour lire une mémoire du calculateur 1 2 dédiée au stockage de défauts détectés. Une réception de la treizième commande auxiliaire dans le calculateur 12, valide une transition 275 qui active une étape 276 dans laquelle le calculateur 12 émet une réponse à la treizième commande auxiliaire reçue qui contient les défauts détectés au cours de l’exécution des étapes précédentes. En cas d’utilisation de commandes conformes au protocole UDS, le champ
53 contient le SID $19 qui désigne une lecture d’information de Diagnostic de Trouble Codé (DTC). On rappelle que chaque défaut DTC traité par le calculateur 12 est stocké avec son propre code dans la mémoire dédiée du calculateur 12, dite mémoire d’erreurs, qu’il est possible de lire à tout moment. Associé à chaque défaut, des informations supplémentaires, notamment liées au contexte d’apparition du défaut, sont aussi stockées et lisibles à tout moment. La réponse à la treizième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $59 dans le champ 56, et un rappel de la référence DID dans le champ 57. Le champ 59 reprend le contenu de la mémoire d’erreurs. Une réception dans le calculateur 1 1 de réponse à la treizième commande auxiliaire, valide une transition 305 qui active une étape 306 dans laquelle le calculateur 1 1 émet une quatorzième commande auxiliaire à destination du calculateur 12. La quatorzième commande auxiliaire a pour effet de faire sortir le calculateur 12 de la session ouverte en étape 216 pour le faire revenir dans la session par défaut. Ainsi le calculateur 12 ne prend en compte entre les étapes 216 et 306 que les commandes issues du calculateur 1 1 dans le cadre du procédé de dialogue ci-dessus exposé. Avant l’étape 216 et après l’étape 306, le calculateur 12 peut prendre en compte tant les commandes issues du calculateur 1 1 dans le cadre de l’instance du procédé de dialogue ci-dessus exposée avec l’éclairage des figures 5 et 6, que les commandes issues du calculateur 1 1 dans le cadre d’une autre instance du procédé de dialogue ci-dessus exposée avec l’éclairage de la figure 4, ou encore que les commandes reçues dans le cadre d’un autre procédé comme par exemple d’un procédé de diagnostic local ou de diagnostic à distance.
Une réception de la quatorzième commande auxiliaire dans le calculateur 1 2, valide une transition 277 qui active une étape 278 dans laquelle le calculateur 1 2 émet une réponse à la quatorzième commande auxiliaire reçue.
En cas d’utilisation de commandes conformes au protocole UDS, le champ
53 contient le SID $10 qui désigne un contrôle de session diagnostique. Le champ
54 contient le code d’identification de session qui en l’occurrence, est la session par défaut « Default Session ». La réponse à quatorzième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $50 dans le champ 56, et un rappel du code d’identification de session dans le champ 57. Lorsque le signal périodique comporte de plus une indication d’état de progression, le calculateur 1 1 indique l’état de progression correspondant à la fermeture de la session de mise à jour.
Une réception dans le calculateur 1 1 de réponse à la quatorzième commande auxiliaire, valide une transition 307 qui fait passer le calculateur 1 1 de l’étape 306 à une étape 308 dans laquelle le calculateur 1 1 émet à destination du calculateur 1 2, une quinzième commande auxiliaire pour activer un deuxième programme local. Selon un premier mode de réalisation, le calculateur 1 2 comprend une unique banque activable de mémoire réinscriptible et deux banques non activables de mémoire réinscriptible. L’unique banque activable comprend des bloc mémoire qui contiennent les composants numériques exécutés et/ou accédés en temps réel par le calculateur embarqué 1 2 lorsque le véhicule est en fonctionnement. Une première banque non activable comprend les blocs mémoire évoqués ci-dessus pour charger le ou les composants numériques de mise à jour. Une deuxième banque non activable est utilisée par le deuxième programme local, dont une exécution consiste à recopier le contenu de la banque activable dans la deuxième banque non activable avant de recopier le contenu de la première banque non activable dans l’unique banque activable lorsque le fonctionnement du véhicule est arrêté, de manière à activer l’unique banque activable avec les composants numériques mis à jour à la prochaine remise en fonctionnement du véhicule.
Selon un deuxième mode de réalisation, le calculateur 1 2 comprend deux banques activables jumelles de mémoire réinscriptible. Une première banque activable jumelle comprend des bloc mémoire qui contiennent les composants numériques exécutés et/ou accédés en temps réel par le calculateur embarqué 12 lorsque le véhicule est en fonctionnement. Une deuxième banque activable jumelle comprend les blocs mémoire évoqués ci-dessus pour charger le ou les composants numériques de mise à jour. Une exécution du deuxième programme local, consiste alors simplement à commuter un amorçage d’exécution temps réel de la première banque activable jumelle vers la deuxième banque activable jumelle lorsque le fonctionnement du véhicule est arrêté, de manière à activer la deuxième banque activable jumelle avec les composants numériques mis à jour à la prochaine remise en fonctionnement du véhicule, pour lequel la deuxième banque activable jumelle jouera le rôle de la première banque activable jumelle et réciproquement.
On notera que tout ou partie des commandes auxiliaires précédant la quinzième commande auxiliaire, peuvent être effectuées pendant le fonctionnement du véhicule. Les deux modes de réalisation ci-dessus exposés présentent l’avantage de ne nécessiter qu’une durée réduite pour basculer le fonctionnement du véhicule sur l’exécution et/ou l’accès des composants numériques en temps réel, en d’autres termes qu’une durée réduite de mise à l’arrêt de fonctionnement du véhicule pour effectuer une mise à jour des composants numériques.
Il est possible d’utiliser la trame 29 illustrée en figure 2 pour matérialiser la quinzième commande auxiliaire. Pour la quinzième commande auxiliaire, la cible inscrite dans le champ 54 est notamment une référence de programme commutateur stocké en mémoire dans le calculateur 12. Une réception de la quinzième commande auxiliaire dans le calculateur 12, valide une transition 279 qui active une étape 280 dans laquelle le calculateur 1 2 active le deuxième programme local, en d’autres termes le programme commutateur avant d’émettre une réponse à la quinzième commande auxiliaire reçue qui contient un accusé de bonne exécution du deuxième programme local. Le calculateur 1 1 peut ainsi vérifier que le calculateur 12 est prêt pour tout accès et/ou exécution futurs de composants numériques lis à jour.
En cas d’utilisation de commandes conformes au protocole UDS, le champ 53 contient le SID $31 qui désigne une activation de programme identifié par la référence la référence de programme du champ 54. La réponse à la quinzième commande auxiliaire, illustré sur le modèle de la trame 30 en figure 2, contient le SID $62 dans le champ 56. Une réception dans le calculateur 11 de réponse à la quinzième commande auxiliaire, valide une transition 309 qui active une étape 310 dans laquelle le calculateur 1 1 met le signal périodique à l’état prêt. Le signal périodique peut aussi comprendre un degré d’avancement par phases regroupant plusieurs commandes auxiliaires. Par exemple le calculateur 1 1 positionne le degré d’avancement en étape 212 pour indiquer une phase de vérification de paramètres, en étape 252 pour indiquer une phase d’installation en cours, et en étape 310 pour indiquer une fin de phase d’installation.
Une réception dans le calculateur 10 de signal périodique à l’état prêt valide une transition 207 qui réactive l’étape initiale 100 dans le calculateur 10, en attente d’une éventuelle autre commande principale.

Claims

REVENDICATIONS
1. Procédé de dialogue à partir d’un premier bus (1 ) embarqué dans un véhicule, avec un premier calculateur (12, 13, 14) connecté à un deuxième bus (2) embarqué du véhicule, le premier bus étant connecté au deuxième bus par un deuxième calculateur (1 1 ), dans lequel un troisième calculateur (10) connecté au premier bus embarqué, traite une commande principale destinée au premier calculateur (12, 13, 14), comprenant des étapes dans lesquelles :
- le troisième calculateur (10) génère (102) une commande d’écriture d’un descriptif (27) de ladite commande principale dans une première zone dédiée (61 ) de données du deuxième calculateur (1 1 ) ;
- le troisième calculateur (10) émet (104) ladite commande d’écriture à destination du deuxième calculateur (1 1 ) lorsque le deuxième calculateur (11 ) est détecté (103) prêt pour répondre à ladite commande d’écriture ;
- le deuxième calculateur (1 1 ) émet (1 14) à destination du premier calculateur (1 2, 1 3, 14) une ou plusieurs commandes auxiliaires pour répondre à la commande principale après réception (1 1 1 ) de ladite commande d’écriture ;
- le premier calculateur (1 2, 1 3, 14) émet (122) une réponse à chaque commande auxiliaire reçue (121 ) ;
- le deuxième calculateur (1 1 ) mémorise (1 16) au moins une réponse reçue (115) dans une deuxième zone dédiée (62) de données ;
- le troisième calculateur (10) émet (108) une commande de lecture de ladite deuxième zone dédiée (62), à destination du deuxième calculateur (11 ) lorsque le deuxième calculateur (1 1 ) est détecté (107) prêt pour répondre à ladite commande de lecture ;
- le deuxième calculateur (1 1 ) émet (124), une réponse à la commande de lecture reçue (1 19) ;
- le troisième calculateur répond (126) à la commande principale à partir d’au moins une réception (109) de réponse à la commande de lecture de la deuxième zone dédiée du deuxième calculateur (11 ) dans laquelle est mémorisée la réponse émise par le premier calculateur (12, 13, 14).
2. Procédé selon la revendication 1 , dans lequel un signal comportant deux états, prêt, non prêt, est émis périodiquement par le deuxième calculateur (1 1 ) sur le premier bus (1 ), et qui comprend des étapes dans lesquelles :
- le deuxième calculateur (1 1 ) positionne (1 12) le signal à l’état occupé après réception (1 11 ) de la commande d’écriture en provenance du troisième calculateur (10) ;
- le deuxième calculateur (1 1 ) positionne (1 16) le signal à l’état prêt après réception (1 15) de la réponse en provenance du premier calculateur (12, 13, 14).
3. Procédé selon la revendication 2, caractérisé en ce qu’il comprend une étape dans laquelle le troisième calculateur (10) se met en attente (106) du signal positionné à l’état prêt après avoir reçu (105) ledit signal positionné à l’état occupé.
4. Procédé selon l’une des revendications 2 ou 3, caractérisé en ce que ledit signal comporte aussi un degré d’avancement de la ou desdites commandes auxiliaires émises par le deuxième calculateur (1 1 ).
5. Procédé selon au moins l’une des revendications 1 à 4, caractérisé en ce que ladite commande d’écriture comporte une première trame (21 ) qui comprend un premier champ (31 ) identifiant ladite commande d’écriture, un premier champ (32) identifiant la première zone dédiée (61 ), et au moins un champ (33, 34, 35) de descriptif (27) de la commande principale.
6. Procédé selon l’une des revendications 1 à 5, caractérisé en ce que le descriptif (27) de la commande principale comporte un champ (33) de type de la commande principale, un champ (34) d’identification du deuxième calculateur (12, 13, 14), et un champ (35) de paramètre utile au deuxième calculateur (12, 13, 14) pour élaborer la réponse émise.
7. Procédé selon l’une des revendications 1 à 6, caractérisé en ce qu’il comprend une étape dans laquelle le deuxième calculateur (11 ) émet (1 12) un acquittement à destination du premier calculateur (10) après réception (1 1 1 ) de ladite commande d’écriture.
8. Procédé selon la revendication 7, caractérisé en ce que l’acquittement comporte une deuxième trame (22) qui comprend un champ (37) d’identifiant d’acquittement, et un deuxième champ (38) d’identifiant de la première zone dédiée (61 ).
9. Procédé selon l’une des revendications 1 à 8, caractérisé en ce que ladite commande de lecture émise par le troisième calculateur (10) comporte une troisième trame (23) qui comprend un deuxième champ (39) d’identification de commande, et un premier champ (40) d’identifiant de la deuxième zone dédiée (62).
10. Procédé selon l’une des revendications 1 à 9, caractérisé en ce que ladite réponse à la commande de lecture comporte une quatrième trame (24) qui comprend un quatrième champ (41 ) d’identifiant de réponse à la commande de lecture, un deuxième champ (42) d’identifiant de la deuxième zone dédiée (62), au moins un champ (43, 44, 45) de rappel du descriptif de la commande principale, et un champ (47) de contenu de la réponse à la commande principale.
1 1. Procédé selon l’une des revendications 1 à 10, caractérisé en ce que les commandes de lecture et les commandes d’écriture sont des commandes conformes au protocole UDS de services unifiés de diagnostic.
12. Procédé selon l’une des revendications précédentes, comprenant des étapes dans lesquelles :
- le deuxième calculateur (11 ) vérifie (1 12) si le descriptif de ladite commande principale est intègre ou non après réception (1 1 1 ) de ladite commande d’écriture ;
- le deuxième calculateur (1 1 ) émet (1 14) à destination du premier calculateur (1 2, 13, 14) une ou plusieurs commandes auxiliaires pour répondre à la commande principale uniquement si le descriptif de ladite commande principale est intègre (1 13) ;
- le deuxième calculateur (1 1 ) mémorise (1 18) une alarme dans la deuxième zone dédiée si le descriptif de ladite commande principale n’est pas intègre (117).
13. Procédé selon l’une des revendications 1 à 12, caractérisé en ce que ladite commande principale est une commande pour lire une donnée résidente dans le premier calculateur, en ce que la commande auxiliaire comporte une cinquième trame (25) qui comprend un champ (48) d’identification de commande de lecture et un champ (49) d’identification de ladite donnée résidente, et en ce que la réponse émise par le premier calculateur (12, 13, 14) comporte une sixième trame (26) qui comprend un champ (50) d’identification de réponse à la commande de lecture, un champ (51 ) d’identification de ladite donnée résidente, et un champ (52) contenant une valeur de ladite donnée résidente.
14. Procédé selon l’une des revendications 1 à 12, caractérisé en ce que ladite commande principale est une commande pour installer un composant numérique dans ledit premier calculateur.
PCT/EP2020/065039 2019-06-25 2020-05-29 Procédé de dialogue avec un calculateur sur bus embarqué de véhicule WO2020259956A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202080043378.3A CN114026537A (zh) 2019-06-25 2020-05-29 用于在车辆的车载总线上与计算机进行对话的方法
EP20733358.4A EP3991029A1 (fr) 2019-06-25 2020-05-29 Procédé de dialogue avec un calculateur sur bus embarqué de véhicule
US17/620,470 US20220245085A1 (en) 2019-06-25 2020-05-29 Method of dialogue with a computer on an on-board bus of a vehicle
KR1020227002402A KR20220024905A (ko) 2019-06-25 2020-05-29 차량의 온보드 버스에서 컴퓨터와 대화하는 방법
JP2021576268A JP2022538080A (ja) 2019-06-25 2020-05-29 車両の車載バス上のコンピュータと対話する方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR1906883 2019-06-25
FR1906883A FR3097988B1 (fr) 2019-06-25 2019-06-25 Procédé de dialogue avec un calculateur sur bus embarqué de véhicule.

Publications (1)

Publication Number Publication Date
WO2020259956A1 true WO2020259956A1 (fr) 2020-12-30

Family

ID=67999913

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/065039 WO2020259956A1 (fr) 2019-06-25 2020-05-29 Procédé de dialogue avec un calculateur sur bus embarqué de véhicule

Country Status (7)

Country Link
US (1) US20220245085A1 (fr)
EP (1) EP3991029A1 (fr)
JP (1) JP2022538080A (fr)
KR (1) KR20220024905A (fr)
CN (1) CN114026537A (fr)
FR (1) FR3097988B1 (fr)
WO (1) WO2020259956A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220242231A1 (en) * 2021-02-01 2022-08-04 CANshift LLC Automatic transmission control system utilizing paddle shifters

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1434129A2 (fr) 2002-12-19 2004-06-30 Komatsu Ltd Dispositif de contrôle de réécriture pour un programme embarqué
US20150071115A1 (en) * 2012-05-16 2015-03-12 Bayerische Motoren Werke Aktiengesellschaft Data Logging or Stimulation in Automotive Ethernet Networks Using the Vehicle Infrastructure
US20170351445A1 (en) * 2015-01-05 2017-12-07 Autonetworks Technologies, Ltd. Vehicle-mounted relay device
US20180203685A1 (en) * 2015-07-23 2018-07-19 Denso Corporation Relay device, electronic control unit, and vehicle-mounted system
WO2019069308A1 (fr) * 2017-10-03 2019-04-11 Argus Cyber Security Ltd. Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10140109B2 (en) * 2014-02-25 2018-11-27 Ford Global Technologies, Llc Silent in-vehicle software updates
CN110406485B (zh) * 2014-04-17 2023-01-06 松下电器（美国）知识产权公司 非法检测方法及车载网络系统
US10157158B2 (en) * 2017-01-27 2018-12-18 Ford Global Technologies, Llc Method and apparatus for distributed computing using controller area network protocols

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1434129A2 (fr) 2002-12-19 2004-06-30 Komatsu Ltd Dispositif de contrôle de réécriture pour un programme embarqué
US20150071115A1 (en) * 2012-05-16 2015-03-12 Bayerische Motoren Werke Aktiengesellschaft Data Logging or Stimulation in Automotive Ethernet Networks Using the Vehicle Infrastructure
US20170351445A1 (en) * 2015-01-05 2017-12-07 Autonetworks Technologies, Ltd. Vehicle-mounted relay device
US20180203685A1 (en) * 2015-07-23 2018-07-19 Denso Corporation Relay device, electronic control unit, and vehicle-mounted system
WO2019069308A1 (fr) * 2017-10-03 2019-04-11 Argus Cyber Security Ltd. Système et procédé de validation d'une authenticité de communication dans des réseaux embarqués

Also Published As

Publication number Publication date
FR3097988B1 (fr) 2021-06-04
KR20220024905A (ko) 2022-03-03
US20220245085A1 (en) 2022-08-04
FR3097988A1 (fr) 2021-01-01
EP3991029A1 (fr) 2022-05-04
CN114026537A (zh) 2022-02-08
JP2022538080A (ja) 2022-08-31

Similar Documents

Publication Publication Date Title
US11650807B2 (en) Self-healing learning system for one or more controllers
WO2020259956A1 (fr) Procédé de dialogue avec un calculateur sur bus embarqué de véhicule
WO2022064118A1 (fr) Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle
WO2021023694A1 (fr) Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule
FR3099264A1 (fr) Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde
FR3099265A1 (fr) Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution, une mémoire de sauvegarde et une mémoire de contrôle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20733358

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021576268

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20227002402

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020733358

Country of ref document: EP

Effective date: 20220125