EP2044736A1 - Procédé pour le fonctionnement d'un bus lin - Google Patents

Procédé pour le fonctionnement d'un bus lin

Info

Publication number
EP2044736A1
EP2044736A1 EP07765778A EP07765778A EP2044736A1 EP 2044736 A1 EP2044736 A1 EP 2044736A1 EP 07765778 A EP07765778 A EP 07765778A EP 07765778 A EP07765778 A EP 07765778A EP 2044736 A1 EP2044736 A1 EP 2044736A1
Authority
EP
European Patent Office
Prior art keywords
lin
protocol
diagnostic
service
slave
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP07765778A
Other languages
German (de)
English (en)
Inventor
Ingo Mauel
Ralf Machauer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP2044736A1 publication Critical patent/EP2044736A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/403Bus networks with centralised control, e.g. polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40234Local Interconnect Network LIN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Definitions

  • the invention relates to a method for operating a LIN bus, an arrangement comprising a LIN bus, a computer program and a computer program product.
  • LIN bus or a LIN network is a so-called field bus, which is involved in the electronic components, such as. Actuators and sensors mainly in the automotive industry.
  • the abbreviation LIN (Local Interconnect Network) stands for local interconnection network.
  • About LIN buses electronic components are interconnected, which are mainly in facilities that are not directly used for locomotion of the motor vehicle and, for example. Included in seats or doors. It is envisaged that a component and thus a subscriber is formed as a higher-level LIN master. The other components or subscribers are provided as LIN slaves. Normally, a LIN slave transmits data via the LIN bus only when requested to do so by the LIN master.
  • LIN buses are less complex than CAN (Controller Area Network) buses. Since they have a lower bandwidth, however, a lower data transmission rate is possible than with CAN buses. It should be noted, however, that LIN buses are less expensive than LAN buses.
  • the invention relates to a method for operating a LIN bus whose specifications are described in a normal operation by a LIN bus, in which an alternative communication protocol is tunneled through the LI N protocol to perform a special operation.
  • Such tunneling of the communication protocol by the LIN protocol modifies functional properties of the LIN bus or at least one subscriber of the LIN bus.
  • the at least one participant performs technical functions during the special operation and / or reacts to technical interactions that differ from functions and interactions of normal operation.
  • a service connected to the communication protocol is mapped onto a frame or frame of the LIN protocol.
  • a LI N frame is used to transmit another communication protocol therein.
  • at least one date of the frame is assigned depending on the service.
  • Parameters of the alternative communication protocol must also be assigned dependent on the service.
  • At least one participant of the LIN bus can be programmed via the communication protocol.
  • Alternatively or accompanying a diagnosis can be carried out during the special operation, wherein the alternative communication protocol is mapped to a trained as a diagnostic frame of the LIN protocol.
  • the invention also relates to an arrangement comprising a LIN bus with multiple subscribers. Specifications of the LIN bus are described in normal operation by a LIN protocol. To carry out a special operation, the arrangement is designed to tunnel an alternative communication protocol through the LIN protocol.
  • a first subscriber is typically designed as a master and at least one second subscriber as a slave.
  • the master transmits requests to the slave and the slave transmits responses to the master.
  • the arrangement or at least one participant of the arrangement is designed to carry out all the steps of the method according to the invention.
  • the computer program with program code means according to the invention is designed to carry out all steps of a method according to the invention when the computer program is executed on a computer or a corresponding arithmetic unit, in particular in an arrangement according to the invention.
  • the invention additionally relates to a computer program product with program code means which are stored on a computer-readable data carrier in order to carry out all the steps of a method according to the invention when the computer program is executed on a computer or a corresponding arithmetic unit, in particular a control unit in an arrangement according to the invention.
  • diagnostic frames or diagnostic frames of the LIN protocol it is possible to use diagnostic frames or diagnostic frames of the LIN protocol to transmit other communication and in particular diagnostic protocols therein. In an embodiment, this is done by the UDS protocol and the proprietary protocol.
  • the present invention extends the application of diagnostic protocols, such as Unified Diagnostic Services (UDS), proprietary services or KWP2000, to the LIN bus system, especially for Revision 2.0, as well as for older revisions, such that tunneling of these diagnostic protocols by the LIN Bus protocol is possible.
  • UDS Unified Diagnostic Services
  • KWP2000 proprietary services
  • a method for implementing a diagnostic mechanism for a LIN node can be performed.
  • the method is based on a concept for the LIN diagnosis and a configuration specification according to Revision 2.0.
  • This implements alternative approaches to collecting diagnostic data.
  • the concept takes into account a user-defined diagnosis "User Defined Diagnostic” and a diagnostic transport layer "Diagnostic Transport Layer”.
  • the diagnostic concept is to be understood as an extension or addition to a standard communication protocol and thus the LIN protocol of the LIN bus.
  • the requirements for this protocol are that an electronic control unit (ECU) uses a diagnostic concept that implements at least one of the communication protocols LIN 1.2, LIN 1.3, LIN 2.0, SAE J2602 (published in August 2004).
  • a data transmission rate in the communication protocol is defined by a respective project. If this project requires the use of different data transfer rates for normal applications and a diagnostic operation, it is possible to use a mechanism to change data transfer rates.
  • Diagnostic messages are typically transmitted within the LIN command frame reserved for master requests and slave responses as subscribers to the LIN bus, examples of which are shown in Table 1.
  • Table 2 Frame types for requests from the master and responses from the slave
  • Diagnostic frames typically comprise 8 bytes of data.
  • One possible structure of possible diagnostic frames is shown in Table 3 below.
  • NAD Node Addressing
  • PCI Protocol Control Information
  • the protocol control information includes information about the frame type and the transport layer flow control information.
  • the four most significant bits of the length of the message are transferred into the four least significant bits of the PCI byte.
  • the eight least significant bits of the length of the message are transferred to the LEN byte introduced in Table 3.
  • PCI 0x12
  • four least significant bits of the PCI comprise four most significant bits of the
  • the four most significant bits of the PCI include the frame type indicator
  • Length 0x2bd, number of data bytes in the message plus 1
  • LEN Oxbd, eight least significant bits of length
  • PCI 0x12
  • four least significant bits of the PCI comprise four most significant bits of the
  • the four most significant bits of the PCI include the frame type indicator
  • SID Service Identifier
  • NAD node address
  • the required definition of the service or diagnostic service is usually determined by the project or the user. Some users use ISO services or, for example, proprietary services. It is also possible for the user to define his own communication protocols that are alternative to the LIN protocol and thereby specific diagnostic services. Therefore, the user has to decide what kind of diagnostic services are used.
  • the abbreviation RSID (Response Service Identifier) from Table 3 stands for Answer Service Identifier and determines contents of the answer.
  • the RSID for a positive response is typically SID + 0x40.
  • the flow of communication depends on a number of requirements.
  • the user defines the course of the diagnostic communication in his system.
  • the process for each specific product is optimized to reduce the duration of manufacturing steps. Accordingly, the process is defined in particular by the nature of the project.
  • Table 7 gives an overview of errors that can occur during a communication.
  • Table 7 Communication error Depending on the type of node, ie a specific design of the LI N master or the LIN slave, different error mechanisms must be implemented. An overview of error handling, as it can be implemented in the slave node, is shown in Table 8.
  • Table 9 shows examples of error handling implemented in the master node.
  • Each project defines the behavior of the system after an error has occurred and how a transmission stream is stopped, eg by repeating the override. transmission, restart of the inquiry or response sequence or by a complete termination of the communication.
  • a diagnostic service according to UDS (Unified Diagnostic Services, standardized diagnostic service) for road vehicles
  • Table 10 shows an overview of diagnostic services within the LI N context. However, other services are also applicable. Examples of this embodiment are shown in Tables 10 to 13.
  • Table 10 includes the name of the service and its associated Service Identifier (SID), represented here as a hexadecimal value. Furthermore, a brief description is given for each diagnostic service.
  • the columns “Sub-function” and “SupPosRsp” (suppress positive response message, suppression of a positive response) define whether sub-functions exist for the respective diagnostic service and whether positive answers can be suppressed. Subfunctions are to be distinguished from subparameters. Sub-parameters can be used to concretize desired services or functions (eg memory size, memory address, etc.), whereas sub-functions call desired services under a specific flowchart, for example a soft reset or a hard or abrupt reset.
  • bit 7 of a parameter of the subfunction or of a service parameter byte is used to suppress a positive response for the respective service (Table 11).
  • the response service identifier which is the response service identifier, is to form positive responses by summing the response SID with the constant hexadecimal value 0x40. A negative answer is used for the RSID 0x7F.
  • the second byte is the SID that caused an error.
  • a third byte dependent on the SID describes the error in more detail.
  • Table 10 Overview of LIN Diagnostic Services
  • Table 11 shows a common structure of the service parameter byte
  • SPB Service parameter byte
  • the mentioned services of the communication protocol provided according to UDS are mapped onto the LIN frames or LIN frames.
  • Such mapping to the LIN frames is done according to the examples described below.
  • NAD 0x83, example of a node address
  • PCI 0x02, SID and a data byte, for a single frame
  • Example four Data transmission to the LIN slave.
  • NAD 0x83, example for node address
  • PCI 0x10, first frame with more than 6 bytes of data
  • Date 0x01
  • block sequence counter subparameter for SID 0x63 to UDS
  • Date2-Date4 data bytes to be transferred
  • NAD 0x83
  • Example of Node Address PCI 0x21
  • Second Data Frame Date 1-Date4 Data bytes to be transferred Date5-Date6: Unoccupied, set to 0xFF
  • a proprietary service can be mapped in the LIN diagnostic frames. Details of this embodiment are shown in Tables 14 to 17.
  • Table 15 shows an overview of some diagnostic services within the LI N context.
  • Table 15 includes the names of the services and the associated service identifiers SID ("block title"), represented here as hexadecimal values. Furthermore, a brief description of each diagnostic service is given.
  • mapping of the services to the LI N-frame can be done according to one of the following examples.
  • Example five Start of the diagnostic session.
  • NAD 0x83, example for node address PCI: 0x04, SID, 3 data bytes and checksum, single frame SID: 0x10, start of the diagnostic session
  • Table 16 applies to the start of the diagnostic session.
  • Example six Programming of 6 bytes of flash ROM to address 0x0123.
  • NAD 0x83
  • example of node address PCI 0x10
  • first frame more than 8 bytes of data
  • Date 2 0x23 LSB of the address, specified in the proprietary protocol Date 3
  • Date4 Data byte 1 and Data byte 2 Continuation Frame (CF):
  • NAD 0x83, example for node address
  • D1-D4 data bytes to be transmitted (byte 3 - byte 6)
  • a possible application of the invention is provided in the development phase of LIN components and thus of subscribers of LIN networks or buses, wherein such LIN components are designed in particular as electronic control units (ECU).
  • ECU electronice control units
  • LIN components and thus also buses are most common in the so-called body domain in the vehicle body and are used for flap actuators of ventilation systems, engines for seat adjustment or for the door electronics.
  • FIG. 1 shows a schematic diagram of an embodiment of a sequence of a communication in a LIN network.
  • FIG. 2 shows a schematic representation of a diagram for a sequence of a start of a diagnostic session.
  • FIG. 3 shows a schematic diagram of a sequence of a first embodiment of a diagnostic session.
  • FIG. 4 shows a schematic diagram of a sequence of a first embodiment of a diagnostic session.
  • a master 102 and a slave 104 of a LIN network 106 are shown schematically, which communicate with each other.
  • temporal requirements which are determined by a diagnostic protocol of the user, decided by the master 102. In the present embodiment, this means that the master cyclically sends 102 messages to the slave 102, thus indicating that the subsystem is in test mode.
  • the diagnostic communication in the LIN network 106 is accomplished by two types of communication, namely requests from the master 102 and responses from the slave 104. During a first period 112, and thus in a first case, the master 102 sends a first request 114 to the slave 104, with no special time parameters required.
  • a third, also unanswered request 122 is sent during a third time period 124.
  • the master 102 sends a fourth request 128 to which the slave 104 responds with a first response 130, whereupon the time-out 120 (traoutivi) is terminated.
  • the master 102 transmits a fifth request 134, which is responded to by the slave 104 with a second response 136.
  • the maximum value for a main time (T R ⁇ M ) is generally dependent on a state of the LIN network 106.
  • Figure 2 shows a schematic diagram of the sequence of the beginning of a diagnostic session 202 for an ECU programming a single slave in a LIN network.
  • this diagnostic session 202 is in a standard diagnostic session 204, an advanced diagnostic session 206 and a programming 208 of the diagnostic session 202.
  • the flash reprogramming diagnostic session 202 begins by reading 212 an identification of the slave, followed by a check 214 of a reprogramming state 210 in a second step.
  • a first change 216 of the diagnostic session type is performed in a third step.
  • suppression 218 of error entries takes place.
  • a second change 220 of the diagnostic session type takes place.
  • the flow of messages between master and slave specified here is based on the transmission of a deletion routine and a write routine for the memory, here a flash memory as well as two data blocks. If locking of the software is required, the erase and write routines of the flash memory are not completely stored on the electronic control unit (ECU) for safety reasons. During execution of the program sequence, missing parts of these routines are transferred to the slave. It is envisaged that two memory blocks of 64 bytes in length will be transferred to the slave and programmed into the flash memory. The individual steps shown in Figure 2 are used as an introduction to flash programming in the LIN network.
  • the communication in the LIN network takes place during normal operation with the LIN protocol.
  • alternative communication protocols are tunneled through the LIN protocol in the present embodiment.
  • the LIN protocol is switched to such an alternative communication protocol at the first change 216, a switchback from the alternative communication protocol to the LIN protocol takes place at the second change 220, so that the extended diagnostic session 206 for the LIN network with the alternative communication protocol takes place.
  • UDS UDS, KWP2000 or propriety services
  • the programming of the diagnostic session 202 is entered only in the so-called "bootloader". If there is a connection between equivalent subscribers and thus a point-to-point connection, the steps shown in FIG. 2 may be partially omitted. In this case, for UDS, the remaining programming process represented by the diagram of FIG. 3 and for the proprietary service of the diagram shown in FIG. 4 suffices.
  • the process of flash programming is controlled by sending a sequence of a diagnostic request to the slave.
  • the slave then sends a positive or negative answer.
  • error handling is required, with such error handling being project-specific.
  • FIG. 3 shows a diagram of a sequence of a first embodiment of a diagnostic session in the event that a communication protocol provided as UDS is tunneled through a LIN protocol when programming an electronic control unit in a LIN network.
  • a reprogramming of a slave which is designed as the electronic control unit (ECU) is carried out within the LIN network.
  • a start 304 of the programming session takes place, in a second step a security access 306 is granted in a UDS-specific manner and in a third step a fingerprint 308 is transmitted.
  • an exchange 310 of an erase routine is performed, whereupon, in a fifth step, a deletion 312 of a memory, here a flash memory, is performed. Steps four and five may be repeated as needed.
  • an exchange 314 of a write routine is performed, followed by a write 316 of the memory in a seventh step, and also the sixth and seventh steps may be repeated if necessary.
  • a confirmation 318 of the contents of the memory is carried out in the eighth step.
  • the programming of the diagnostic session is terminated by a reset 320. It should be noted that steps two, four, five, six, and eight in the boxes bordered by dashed lines within the diagram in the present embodiment optional to perform. Details about the steps can be found in the following tables.
  • the diagnostic data frames of the LIN are thus shown in FIG.
  • This embodiment is based on a flash programming of two data blocks of 64 bytes in length into the slave. Since there is no routine for erasing or writing the flash memory in the ECU, such routines are executed after being transferred to the ECU in the RAM. In addition, in this example no time information is provided, such as waiting for a response, since these depend on the hardware used. Only one order of the sequences of the message is described. First, a diagnostic programming session as shown in Table 19 is started.
  • Table 20 shows how a test device requests a seed from the LIN slave component with SID 0x27.
  • the next byte represents a parameter of a subfunction that requests the seed according to UDS.
  • the answer includes an arbitrarily chosen germ, for example 0x21 0x47.
  • Security access 306 continues, as shown in Table 21, by transmitting a calculated key based on the received seed.
  • a value 0x02 of the subfunction according to UDS specifies the "sendKey" function of the service 0x27 for sending the key. If the key matches, for example, 0x47 0x11, programming access is granted.
  • a software fingerprint 308 and thus a fingerprint of the software for storage in the slave is transmitted.
  • the xx and yy bytes may be populated according to the identity of the desired fingerprint 308.
  • the data of the fingerprint 308 according to UDS for example, 0x01 - 0x03, transmitted.
  • a transmission of the fingerprint 308 shows by way of example Table 22.
  • the program code can be checked as shown in Table 24.
  • Table 25 shows how to erase the flash memory using the erase routine that has just been reviewed.
  • An identity (ID) of the deleting routine is encoded as xxyy. Since deletion 312 takes some time, some of the RX diagnostic messages of the slave may be empty. Upon completion of the deletion, a positive response is sent. The time taken for deletion 312 is taken into account by a flash tool.
  • the following table 26 shows a message sequence with which the write routine for the slave is downloaded.
  • the transmitted bytes are checked for correctness with the instruction sequences listed in Table 27.
  • Table 27 Checking the Write Routine Now, the currently present first memory block is transmitted, which is shown in Table 28.
  • a download of 64 (0x40) data bytes at the address xxyy is requested.
  • the data is transmitted to the data transfer service (0x36) with consecutive frames.
  • This data transfer service begins with a request for 66 bytes of data (0x42, 64 data, 1 SID and 1 block sequence number byte).
  • all frames of the transmitted data are sent, a positive answer is received. Accordingly, the transmission can be completed with a sequence (0x37) to request the end of transmission (RequestTransferExit).
  • the following table 29 shows how a second memory block is downloaded. This is done according to the same scheme as the download shown in Table 28. Such a flash process takes a certain amount of time, which is why an interval has to be provided as a break before a download of the second data block can be started.
  • the diagnostic session can continue.
  • a check can be activated for all data transferred and stored in the non-volatile memory.
  • a final step in resetting the ECU is shown in Table 31.
  • such a hard reset service is used or abrupt reset (OxOl) requested.
  • OxOl abrupt reset
  • other descriptions of the parameter according to UDS may be provided.
  • FIG. 4 shows a diagram of a sequence of a second embodiment of a diagnostic session in the event that a proprietary communication protocol is tunneled through the LIN protocol when programming an electronic control unit in a LIN network.
  • a reprogramming of a slave which is designed as the electronic control unit (ECU) is carried out within the LIN network.
  • the first step is to start 404 the programming session.
  • a flash ROM access 406 and in a third step a RAM access 408 is provided.
  • a fingerprint 410 is transmitted.
  • the exchange 412 of a deleting routine is performed, whereupon, in a sixth step, the deletion 414 of a memory is performed. Steps five and six can be repeated as needed.
  • the replacement 416 of a write routine is performed, followed by the writing 418 of the memory in an eighth step, and the seventh and eighth steps may be repeated if necessary.
  • a confirmation 420 of a content of the memory is performed in the ninth step.
  • the programming of the diagnostic session is terminated by a reset 422. It should be noted that the steps two, three, five, six, seven, and nine in the dashed-bordered boxes may be optionally performed in the present embodiment.
  • the diagnostic data frames of the LIN are thus shown in detail in FIG.
  • This embodiment is based on a flash programming of two data blocks with a length of 64 bytes in the slave. Since there is no routine for erasing or writing the flash memory in the ECU, such routines are executed after being transferred to the ECU in the RAM. In addition, in this example, no time information is provided, such as waiting for a response, since these depend on the hardware used. Only one order of the sequences of the message is described. First, a diagnostic programming session as shown in Table 32 is started.
  • the flash ROM access 406 is provided (as shown in Table 33).
  • the erase routine and the write routine for the flash memory are loaded into the RAM, allowing RAM access 408
  • the fingerprint 410 of the software may be transferred to the slave according to Table 35.
  • the xx and yy bytes are populated according to the identity of the desired fingerprint 410.
  • the data of the fingerprint 410 for example yy, is transmitted.
  • the flash memory Since the slave uses a software lock in this example, the flash memory has no routine for deletion. Instead, program code for clearing the flash memory, as shown in Table 36, is at least partially transferred to the RAM address 0x01234 immediately before an erase operation.
  • Table 38 below shows how to erase the flash memory with the previously transmitted deleting routine.
  • the service for the corresponding routine has the name "BuIk Erase Flash ROM 16-bit address space", an associated subfunction 0x00 to the proprietary protocol means that the entire flash memory is deleted. Since the deletion takes some time, individual RX diagnostic messages of the slave may be empty. To indicate that the LIN slave is still waiting, a response stating that the tester is waiting should be sent at specific time intervals. After completion of the deletion process, a positive response is sent. The deletion time 414 is taken into account by a flash tool.
  • the following table 38 shows a message sequence with which a write routine for the slave is downloaded.
  • the "Program Flash ROM 16bit" service starts with a request for 68 data bytes (0x44; 64 data, 1 SID, 2 address bytes (0x0123) and 1 checksum byte). Finally, all frames of the transmitted data are sent, a positive answer is received.
  • Table 39 Downloading the first memory block Table 40 below begins with the download of a second memory block (address 0x123 + 40). This is also done as shown in Table 39. Before the download of the second memory block is started, an interval is to be introduced, since the flash process takes some time.
  • the diagnostic session can continue.
  • a check can be activated for all data transferred and stored in the non-volatile memory.
  • Table 41 below shows a diagnostic sequence suitable for this purpose.
  • the proprietary protocol starts a test routine with ID xyyx. Such a verification process takes a certain amount of time, which is why an interval must be taken into account until the arrival of a positive or negative response.
  • Table 41 Checking the Memory Block The last step of resetting the ECU is shown in Table 42.
  • the service "Transparent data block with parameter transfer” is requested with a hard reset (zz) of the parameters (OxOl).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un procédé pour le fonctionnement d'un bus LIN, dont les spécifications dans un fonctionnement normal sont décrites grâce à un bus LIN, avec lequel un protocole de communication alternatif est tunnelé par le protocole LIN pour opérer un fonctionnement spécial.
EP07765778A 2006-07-12 2007-07-03 Procédé pour le fonctionnement d'un bus lin Withdrawn EP2044736A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006032217A DE102006032217A1 (de) 2006-07-12 2006-07-12 Verfahren zum Betreiben eines LIN-Busses
PCT/EP2007/056687 WO2008006737A1 (fr) 2006-07-12 2007-07-03 Procédé pour le fonctionnement d'un bus lin

Publications (1)

Publication Number Publication Date
EP2044736A1 true EP2044736A1 (fr) 2009-04-08

Family

ID=38443345

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07765778A Withdrawn EP2044736A1 (fr) 2006-07-12 2007-07-03 Procédé pour le fonctionnement d'un bus lin

Country Status (5)

Country Link
US (1) US20090307400A1 (fr)
EP (1) EP2044736A1 (fr)
CN (1) CN101491016A (fr)
DE (1) DE102006032217A1 (fr)
WO (1) WO2008006737A1 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE538422T1 (de) 2008-09-08 2012-01-15 Siemens Ag Automatisierungssystem, gerät zur verwendung in einem automatisierungssystem und verfahren zum betreiben eines automatisierungssystems
WO2012016867A1 (fr) * 2010-08-03 2012-02-09 Continental Teves Ag & Co. Ohg Procédé de communication avec écho
JP2012080379A (ja) * 2010-10-04 2012-04-19 Renesas Electronics Corp 半導体データ処理装置及びデータ処理システム
JP5152297B2 (ja) 2010-10-28 2013-02-27 株式会社デンソー 電子装置
US8924025B2 (en) * 2011-04-28 2014-12-30 GM Global Technology Operations LLC Heating, ventilating, and air conditioning module for a vehicle
DE102012206390A1 (de) 2012-04-18 2013-10-24 Magna Car Top Systems Gmbh Steuereinrichtung mit Signalzusammenfassung
DE102013002647B3 (de) * 2013-02-15 2014-05-22 Audi Ag Kraftwagen mit einem Fahrzeugkommunikationsbus und Verfahren zum Erzeugen von Busnachrichten
DE102013002648B3 (de) * 2013-02-15 2014-05-22 Audi Ag Master-Busgerät für einen Fahrzeugkommunikationsbus eines Kraftwagens
CN103607258B (zh) * 2013-11-18 2018-07-06 深圳市道通科技股份有限公司 汽车电脑诊断设备中主从设备的通信方法、装置及系统
DE102014116909B4 (de) * 2014-11-19 2016-07-28 Infineon Technologies Ag Empfänger, Sender, Verfahren zum Wiedergewinnen eines zusätzlichen Datenwerts aus einem Signal und Verfahren zum Übertragen eines Datenwerts und eines zusätzlichen Datenwerts in einem Signal
DE102015204924B4 (de) * 2015-03-18 2022-05-25 Röchling Automotive SE & Co. KG LIN-Netzwerk
US10230592B2 (en) * 2016-03-02 2019-03-12 Oracle International Corporation Compound service performance metric framework
FR3076161B1 (fr) * 2017-12-21 2019-11-15 Psa Automobiles Sa Dispositif de supervision de defauts d’organe(s) esclave(s) pour un organe maitre d’un reseau multiplexe.
KR20200139059A (ko) * 2019-06-03 2020-12-11 현대자동차주식회사 제어기 진단 장치 및 그 방법
CN111736873B (zh) * 2020-06-22 2023-02-24 中国第一汽车股份有限公司 电子控制单元的程序更新方法、装置、设备和存储介质
CN115766889B (zh) * 2022-09-28 2024-06-21 重庆赛力斯凤凰智创科技有限公司 一种数据帧结构和数据通信方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10124800A1 (de) * 2001-05-21 2002-12-12 Siemens Ag Prozessautomatisierungssystem und Prozessgerät für ein Prozessautomatisierungssystem
DE10147445A1 (de) * 2001-09-26 2003-04-17 Bosch Gmbh Robert Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem
DE10156159A1 (de) * 2001-11-15 2003-05-28 Siemens Ag Verfahren zum Einsetzen eines höherwertigen Protokolls auf einem beschränkten Bussystem
DE10311395A1 (de) * 2003-03-13 2004-09-23 Robert Bosch Gmbh Kommunikationsvorrichtung mit asynchroner Datenübertragung über eine symmetrische serielle Schnittstelle
EP1530137A1 (fr) * 2003-11-10 2005-05-11 Robert Bosch Gmbh Système pour la simulation et procédé realisé par ordinateur pour la simulation et verification de systèmes de contrôle
EP1735672A1 (fr) * 2004-04-01 2006-12-27 Delphi Technologies, Inc. Procede et protocole pour des diagnostics de reseaux arbitrairement complexes de dispositifs
DE102004020393A1 (de) * 2004-04-23 2005-11-10 Endress + Hauser Gmbh + Co. Kg Funkmodul für Feldgeräte der Automatisierungstechnik
DE102006009098A1 (de) * 2006-02-28 2007-08-30 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
US20070260900A1 (en) * 2006-05-03 2007-11-08 Renesas Technology America, Inc. High-performance microprocessor with lower-performance microcontroller in a vehicle network
DE102006058184B4 (de) * 2006-11-29 2008-10-16 Atmel Germany Gmbh Integrierter Treiberschaltkreis für einen LIN-Bus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008006737A1 *

Also Published As

Publication number Publication date
US20090307400A1 (en) 2009-12-10
DE102006032217A1 (de) 2008-01-24
CN101491016A (zh) 2009-07-22
WO2008006737A1 (fr) 2008-01-17

Similar Documents

Publication Publication Date Title
EP2044736A1 (fr) Procédé pour le fonctionnement d'un bus lin
EP2553590B1 (fr) Procédé de transférer des données via canopen bus
DE10219832B4 (de) Verfahren zum Kodieren von Steuergeräten in Verkehrsmitteln
EP2137030A2 (fr) Système de communication d'un véhicule et procédé pour faire fonctionner un système de communication
DE102014111962B4 (de) Kalibrieren einer elektronischen Steuerungseinheit eines Fahrzeugs
EP2825921B1 (fr) Dispositif de commande pour la commande de processus critiques pour la sécurité dans une installation automatisée et procédé de paramétrisation du dispositif de commande
DE102010026494A1 (de) Verfahren zur Konfigurierung einer Steuerungseinrichtung
EP1417469A2 (fr) Procede de communication et module de communication
EP2957075B1 (fr) Appareil maître pour bus de communication embarqué d'un véhicule à moteur
DE102006020562A1 (de) Anordnung und Verfahren zur Reprogrammierung von Steuergeräten
DE102007062763A1 (de) Verteiltes Diagnosesystem mit einem einzelnen Diagnose-Protokollserver und mehreren Datenquellen-Modulen für Verbrennungsmotoren
DE102011117083A1 (de) Slave-Steuergerät und Verfahren zur Programmierung eines Slave-Steuergeräts
EP2710436B1 (fr) Procédé et dispositif de paramétrage d'un esclave as-i
DE102009027168B4 (de) Verfahren zum Ermitteln einer übermittelten Telegramm-Datenlänge
EP1814763B1 (fr) Procédé et système pour mettre à disposition des données internes et pertinantes pour le diagnostique d'un véhicule
WO2012025323A1 (fr) Procédé de transmission d'une communication
EP1642422B1 (fr) Adaptation d'un reseau embarque dans un vehicule a des exigences modifiees
EP3948448B1 (fr) Procédé de modification, bornier comprenant un logiciel, et système de borniers pour modification d'un logiciel de commande d'un système d'automatisation
DE102007054810A1 (de) Verfahren zum Erkennen unterschiedlicher Kommunikationsprotokolle in einem Steuergerät
EP1885100B1 (fr) Méthode d'attribution d'adresses à des terminaux de communication
DE102016008587B4 (de) Zugriff auf ein über einen Datenbus eines Kraftfahrzeugs übermittelbares Steuersignal
DE10225567B4 (de) Kommunikationsverfahren und System hierfür
DE102020209221A1 (de) Verfahren zum Koppeln und Ankoppeln eines Sensors und Kommunikationsnetzwerk
DE102004020880A1 (de) Schnittstelle zur Kommunikation zwischen Fahrzeug-Applikationen und Fahrzeug-Bussystemen
DE102020214129A1 (de) Verfahren und System zum Kommunizieren über einen Kommunikationsbus

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090212

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090609

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091020