EP2044736A1 - Verfahren zum betreiben eines lin-busses - Google Patents

Verfahren zum betreiben eines lin-busses

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
English (en)
French (fr)
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/de
Withdrawn legal-status Critical Current

Links

Classifications

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

Die Erfindung betrifft ein Verfahren zum Betreiben eines LIN-Busses, dessen Spezifikationen in einem Normalbetrieb durch einen LIN-Bus beschrieben sind, bei dem zur Durchführung eines Sonderbetriebs ein alternatives Kommunikationsprotokoll durch das LIN-Protokoll getunnelt wird.

Description

Beschreibung
Titel
Verfahren zum Betreiben eines LIN-Busses
Die Erfindung betrifft ein Verfahren zum Betreiben eines LIN-Busses, eine Anordnung, die einen LIN-Bus aufweist, ein Computerprogramm und ein Computerprogrammprodukt.
Stand der Technik
Bei einem LIN-Bus bzw. einem LIN-Netzwerk handelt es sich um einen sogenannten Feldbus, der in die elektronischen Komponenten, wie bspw. Aktoren und Sensoren vorwiegend im Kraftfahrzeugbau eingebunden ist. Die Abkürzung LIN (Local Intercon- nect Network) steht für lokales Zwischenverbindungsnetzwerk. Über LIN-Busse sind elektronische Komponenten miteinander verbunden, die vorwiegend in Einrichtungen, die nicht unmittelbar der Fortbewegung des Kraftfahrzeugs dienen und bspw. in Sitzen oder Türen aufgenommen sind. Es ist vorgesehen, dass eine Komponente und somit ein Teilnehmer als übergeordneter LIN-Master ausgebildet ist. Die weiteren Komponenten bzw. Teilnehmer sind als LIN-Slaves vorgesehen. Üblicherweise überträgt ein LIN- Slave über den LIN-Bus nur dann Daten, wenn dieser von dem LIN-Master durch eine Anfrage dazu aufgefordert wurde.
LIN-Busse sind weniger komplex ausgebildet als CAN(Controller Area Network)-Busse. Da sie eine geringere Bandbreite aufweisen, ist jedoch eine geringere Datenübertra- gungsrate als bei CAN-Bussen möglich. Zu beachten ist aber, dass LIN-Busse kostengünstiger als LAN-Busse sind.
Offenbarung der Erfindung Die Erfindung betrifft ein Verfahren zum Betreiben eines LIN-Busses, dessen Spezifikationen in einem Normalbetrieb durch einen LIN-Bus beschrieben sind, bei dem zur Durchführung eines Sonderbetriebs ein alternatives Kommunikationsprotokoll durch das LI N -Protokoll getunnelt wird.
Durch ein derartiges Tunneln des Kommunikationsprotokolls durch das LIN-Protokoll werden funktionelle Eigenschaften des LIN-Busses oder mindestens eines Teilnehmers des LIN-Busses modifiziert. Somit ist es möglich, dass der mindestens eine Teilnehmer während des Sonderbetriebs technische Funktionen durchführt und/oder auf technische Wechselwirkungen reagiert, die sich von Funktionen und Wechselwirkungen des Normalbetriebs unterscheiden.
Zur Durchführung des Verfahrens ist in Ausgestaltung vorgesehen, dass ein mit dem Kommunikationsprotokoll verbundener Dienst auf einen Rahmen bzw. Frame des LIN- Protokolls abgebildet wird. Somit wird ein LI N- Rahmen dazu benutzt, um ein anderes Kommunikationsprotokoll darin zu übertragen. Dazu wird mindestens ein Datum des Rahmens in Abhängigkeit des Dienstes belegt. Parameter des alternativen Kommunikationsprotokolls sind des weiteren dienstabhängig zu belegen.
Während des Sonderbetriebs kann mindestens ein Teilnehmer des LIN-Busses über das Kommunikationsprotokoll programmiert werden. Alternativ oder begleitend kann während des Sonderbetriebs auch eine Diagnose durchgeführt werden, wobei das alternative Kommunikationsprotokoll auf einem als Diagnoserahmen ausgebildeten Rahmen des LIN-Protokolls abgebildet wird.
Es ist möglich, unterschiedliche alternative Kommunikationsprotokolle durch das LIN- Protokoll zu tunneln und dabei entsprechende Dienste auf dem Rahmen des LIN- Protokolls abzubilden. Beim Durchtunneln eines U DS- Protokolls durch das LIN- Protokoll wird ein U DS- Dienst auf dem Rahmen abgebildet. Beim Durchtunneln eines proprietären, eigenen Protokolls durch das LIN-Protokoll wird ein proprietärer Dienst auf dem Rahmen abgebildet. Beim Durchtunneln eines KWP2000- Protokolls durch das LIN-Protokoll wird ein KWP2000- Dienst auf dem Rahmen abgebildet. Die Erfindung betrifft außerdem eine Anordnung, die einen LIN-Bus mit mehreren Teilnehmern aufweist. Spezifikationen des LIN-Busses sind in einem Normalbetrieb durch ein LIN-Protokoll beschrieben. Zur Durchführung eines Sonderbetriebs ist die Anordnung dazu ausgebildet, ein alternatives Kommunikationsprotokoll durch das LIN- Protokoll zu tunneln.
In der Anordnung ist ein erster Teilnehmer typischerweise als Master und mindestens ein zweiter Teilnehmer als Slave ausgebildet. In diesem Fall ist zur Durchführung einer Kommunikation und einem damit verbundenen Datenaustausch vorgesehen, dass der Master an den Slave Anfragen übermittelt und der Slave and den Master Antworten übermittelt.
Die Anordnung oder zumindest ein Teilnehmer der Anordnung ist zur Durchführung sämtlicher Schritte des erfindungsgemäßen Verfahrens ausgebildet.
Das erfindungsgemäße Computerprogramm mit Programmcodemitteln ist zum Durchführen aller Schritte eines erfindungsgemäßen Verfahrens ausgebildet, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer erfindungsgemäßen Anordnung, ausgeführt wird.
Die Erfindung betrifft zudem ein Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einem Steu- ergerät in einer erfindungsgemäßen Anordnung, ausgeführt wird.
Mit der vorliegenden Erfindung ist es möglich, Diagnoseframes bzw. Diagnoserahmen des LIN-Protokolls dazu zu nutzen, andere Kommunikations- und insbesondere Diagnoseprotokolle darin zu übertragen. In Ausgestaltung erfolgt dies durch das UDS- Protokoll sowie das proprietäre Protokoll. Die vorliegende Erfindung erweitert die Anwendung von Diagnoseprotokollen, wie bspw. Unified Diagnostic Services (UDS), proprietäre Dienste oder KWP2000, für das LIN-Bussystem, insbesondere für eine Revision 2.0 als auch für ältere Revisionen, so dass ein Tunneln dieser Diagnoseprotokolle durch das LIN-Busprotokoll möglich ist. - A -
Mit der Erfindung kann somit ein Verfahren zur Implementierung eines Diagnosemechanismus für einen LIN-Knoten , in der Regel ein Slave, durchgeführt werden. Das Verfahren baut insbesondere auf einem Konzept für die LIN-Diagnose und eine Konfi- gurationsspezifikation nach Revision 2.0 auf. Dadurch werden alternative Vorgehensweisen zur Sammlung von Diagnosedaten implementiert. Das Konzept berücksichtigt in Ausgestaltung eine benutzerdefinierte Diagnose "User Defined Diagnostic" und eine Diagnosetransportschicht "Diagnostic Transport Layer". Das Diagnosekonzept ist als Erweiterung bzw. Zusatz zu einem Standardkommunikationsprotokoll und somit dem LIN-Protokoll des LIN-Busses zu verstehen. Als Anforderungen für dieses Protokoll ist vorgesehen, dass eine elektronische Kontrolleinheit (ECU) ein Diagnosekonzept benutzt, das mindestens eines der Kommunikationsprotokolle LIN 1.2, LIN 1.3, LIN 2.0, SAE J2602 (veröffentlicht im August 2004) implementiert.
Eine Datenübertragungsrate im Kommunikationsprotokoll wird durch ein jeweiliges Projekt definiert. Falls dieses Projekt eine Nutzung unterschiedlicher Datenübertragungsraten für normale Anwendungen und einen Diagnosebetrieb erfordert, ist eine Nutzung eines Mechanismus zur Änderung der Datenübertragungsraten möglich.
Diagnosebotschaften werden üblicherweise innerhalb des LIN-Befehlsrahmens, der für Anfragen des Masters und Antworten des Slaves als Teilnehmer des LIN-Busses reserviert ist, übertragen, Beispiele hierfür sind in Tabelle 1 dargestellt.
Tabelle 1: Diagnoseidentifikator
Für eine Zusammenfassung von Diagnosedaten sind sowohl für die Anfragen des Masters als auch für Antworten des Slaves die in der nachfolgenden Tabelle 2 beispielhaft dargestellten Rahmentypen vorgesehen:
Tabelle 2: Rahmentypen für Anfragen des Masters und Antworten des Slaves
Diagnoserahmen umfassen typischerweise 8 Datenbytes. Eine mögliche Struktur mög- licher Diagnoserahmen ist in der nachfolgenden Tabelle 3 dargestellt.
Tabelle 3: Struktur von Diagnoserahmen
Dabei steht die Abkürzung NAD (Note Address) für Knotenadresse. Dies ist in der Diagnose- und Konfigurationsspezifikation des LIN nach Version 2.0 erstmals spezifiziert worden. NAD bezeichnet die Adresse des Slave- Knotens, der über die Anfrage adressiert wird. NAD kann ebenfalls zur Anzeige einer Quelle einer Anfrage benutzt werden. Die nachfolgende Tabelle 4 zeigt ein Beispiel einer Nutzung der Knotenadresse (NAD) bei bestimmten Systemkonfigurationen.
Tabelle 4: Übersicht zur Definition von NAD Eine Struktur des in Tabelle 3 eingeführten PCI-Bytes ist in Tabelle 5 dargestellt. Die Abkürzung PCI (Protocol Control Information) steht für Protokollkontrollinformation. Die Protokollkontrollinformation umfasst Informationen über den Rahmentyp und die Trans- portschichtflusskontrollinformation.
Tabelle 5: Struktur des PCI-Bytes
Falls die Botschaft nicht in einen einzigen Rahmen passen sollte, werden die vier höchstwertigen Bits der Länge der Botschaft in die vier niedrigstwertigen Bits des PCI- Bytes übertragen. Die acht niedrigstwertigen Bits der Länge der Botschaft werden zu dem in Tabelle 3 eingeführten LEN-Byte übertragen. Die Botschaft kann maximal 4095 Bytes (Länge = Oxff) umfassen. In einem ersten Beispiel ergeben sich nachfolgende Werte:
Anzahl der Datenbytes in der Botschaft = 700 Byte (0x2bc) Länge = 0x2bd, Anzahl der Datenbytes in der Botschaft plus 1 LEN = Oxbd, acht niedrigstwertige Bits der Länge
PCI = 0x12, vier niedrigstwertige Bits des PCI umfassen vier höchstwertige Bits der
Länge, die vier höchstwertigen Bits des PCI umfassen die Rahmentypanzeige
In einem zweiten Beispiel ergeben sich folgende Werte:
Anzahl der Datenbytes in der Botschaft = 700 Byte (0x2bc)
Länge = 0x2bd, Anzahl der Datenbytes in der Botschaft plus 1
LEN = Oxbd, acht niedrigstwertige Bits der Länge
PCI = 0x12, vier niedrigstwertige Bits des PCI umfassen vier höchstwertige Bits der
Länge, die vier höchstwertigen Bits des PCI umfassen die Rahmentypanzeige
Die Abkürzung SID (Service Identifier) in Tabelle 3 steht für Dienstidentifikator und bestimmt die Anfrage, die durch die Slave- Knotenadresse durchgeführt werden soll. Ta- belle 6 zeigt den Zusammenhang zwischen SID und der Knotenadresse (NAD).
Tabelle 6: Korrelation zwischen SID und NAD
Die erforderliche Definition des Dienstes bzw. Diagnosedienstes wird in der Regel durch das Projekt oder den Anwender bestimmt. Einige Anwender benutzen ISO- Dienste oder beispielsweise proprietäre Dienste. Es ist auch möglich, dass der Anwender eigene zu dem LIN-Protokoll alternative Kommunikationsprotokolle und dabei bestimmte Diagnosedienste definiert. Demnach muss durch den Anwender entschieden werden, welche Art von Diagnosediensten benutzt werden. Die Abkürzung RSID (Response Service Identifier) aus Tabelle 3 steht für Antwort- dienstidentifikator und bestimmt Inhalte der Antwort. Der RSID für eine positive Antwort ist typischerweise SID + 0x40.
Die Interpretation von Datenbytes, die durch die Variablen Dl bis D6 für jeweils ein entsprechendes Datum 1 bis Datum 6 beschrieben sind, hängt von dem Dienstidentifi- kator oder dem Antwortdienstidentifikator ab. Falls ein Rahmen eines Protokolls nicht vollständig gefüllt wird, werden die ungenutzten Bytes mit Einsen (Oxff) gefüllt.
Der Ablauf der Kommunikation hängt von einer Anzahl von Erfordernissen ab. In Produktionsserien definiert bspw. der Anwender den Ablauf der Diagnosekommunikation in seinem System. In der Fertigung bzw. in der Fabrik wird der Ablauf für jedes spezifische Produkt optimiert, um die Dauer von Fertigungsschritten zu reduzieren. Demnach wird der Ablauf insbesondere durch die Art des Projekts definiert.
Tabelle 7 gibt eine Übersicht für Fehler, die bei einer Kommunikation auftreten können.
Tabelle 7: Kommunikationsfehler Abhängig von der Knotenart, also einer konkreten Ausbildung des LI N -Masters oder des LIN-Slaves, müssen unterschiedliche Fehlermechanismen implementiert werden. Eine Übersicht einer Fehlerbehandlung, wie sie in den Slave-Knoten implementiert werden kann, ist in Tabelle 8 dargestellt.
Tabelle 8: Reaktion auf Fehler im Slave-Knoten
Tabelle 9 zeigt Beispiele zu einer Fehlerbehandlung, die in dem Master- Knoten implementiert sind.
Tabelle 9: Reaktion auf Fehler im Master- Knoten
Jedes Projekt definiert die Verhaltensweise des Systems nach Auftauchen eines Fehlers und wie ein Übertragungsstrom gestoppt wird, z.B. durch Wiederholung der Über- tragung, Neustart der Anfrage- oder Antwortsequenz oder durch einen vollständiger Abbruch der Kommunikation.
In einer möglichen Ausgestaltung kann ein Diagnosedienst gemäß UDS (Unified Di- agnostic Services, vereinheitlichter Diagnosedienst) für Straßenfahrzeuge nach
ISO14229-1.2 aus dem Jahr 2003 für LIN-Busse und somit LIN-Protokolle angewandt werden. Hierzu zeigt nachfolgende Tabelle 10 eine Übersicht für Diagnosedienste innerhalb des LI N -Kontextes. Es sind jedoch auch andere Dienste anwendbar. Beispiele zu dieser Ausgestaltung sind in den Tabellen 10 bis 13 dargestellt.
Tabelle 10 umfasst den Namen des Dienstes und den zugehörigen Dienstidentifikator (Service Identifier, SID), der hier als Hexadezimalwert dargestellt ist. Des weiteren ist eine kurze Beschreibung für jeden Diagnosedienst angegeben. Die Spalten "Unterfunktionen" (sub-function) und "SupPosRsp" (suppress positive response message, Unter- drückung einer positiven Antwort) definieren, ob für den jeweiligen Diagnosedienst Unterfunktionen existieren und ob jeweils positive Antworten unterdrückt werden können. Hierbei sind Unterfunktionen von Unterparametern (subparameters) zu unterscheiden. Durch Unterparameter können gewünschte Dienste oder Funktionen (z.B. Speichergröße, Speicheradresse, usw.) konkretisiert werden, wohingegen Unterfunktionen ge- wünschte Dienste unter einem bestimmten Ablaufschema aufrufen, bspw. ein weiches Zurücksetzen oder ein hartes bzw. abruptes Zurücksetzen. Das höchstwertige Bit (bit 7) eines Parameters der Unterfunktion bzw. eines Dienstparameterbytes wird zur Unterdrückung einer positiven Antwort für den jeweiligen Dienst benutzt (Tabelle 11). In der Regel ist der RSID (response Service identifier), was für Antwortdienstidentifikator steht, für positive Antworten durch Summation des Antwort-SID mit dem konstanten Hexadezimalwert 0x40 zu bilden. Eine negative Antwort wird für den RSID 0x7F benutzt. In diesem Fall ist das zweite Byte der SID, der einen Fehler verursacht hat. Durch ein drittes von dem SID abhängiges Byte wird der Fehler genauer beschrieben. Tabelle 10: Übersicht zu LIN-Diagnosediensten
Tabelle 11 zeigt einen üblichen Aufbau des Dienstparameterbytes
Dienstparameterbyte (SPB)
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO
SupPosRsp Diagonsesitzungstyp
Tabelle 11: Diagnoseidentifikator
Gemäß dieser Ausgestaltung werden die erwähnten Dienste des nach UDS vorgesehenen Kommunikationsprotokolls auf die LIN-Rahmen bzw. LIN-frames abgebildet. Eine derartige Abbildung auf die LIN-Rahmen erfolgt gemäß der nachfolgend beschriebenen Beispiele.
Drittes Beispiel: Start der Standardeinstellung einer Diagnosesitzung.
NAD: 0x83, Beispiel für eine Knotenadresse,
PCI: 0x02, SID und ein Datenbyte, für einen Einzelrahmen
SID: 0x10, Diagnosesitzungskontrolldienst
Datuml: 0x02, durch UDS spezifizierte Programmierungssitzung
Tabelle 12: Diagnosesitzungskontrolle
Beispiel vier: Datenübertragung zum LIN-Slave.
NAD: 0x83, Beispiel für Knotenadresse
PCI: 0x10, erster Rahmen mit mehr als 6 Datenbytes
LEN: 0x09, SID und 8 Datenbytes sind zu übertragen
SID: 0x36, Übertragungsdaten
Datuml: 0x01, Blocksequenzzähler (Unterparameter für SID 0x63 nach UDS) Datum2-Datum4: zu übertragende Datenbytes
NAD: 0x83, Beispiel für Knotenadresse PCI: 0x21, Fortsetzungsrahmen (CF), zweiter Datenrahmen Datum 1-Datum4: zu übertragende Datenbytes Datum5-Datum6: nicht besetzt, auf OxFF gesetzt
Tabelle 13: Übertragungsdaten
In einer weiteren Ausgestaltung kann ein proprietärer Dienst in den LIN- Diagnoserahmen abgebildet werden. Details zu dieser Ausgestaltung sind in den Tabellen 14 bis 17 dargestellt.
"Checksumme" D2 = "Checksumme"
"Blocktester Warten" (Antwort ldentifikator OxFE Antwort ohne Anfrage)
Response ("Blocktitel") RSID = 0xFE
Tabelle 14: Abbildung vom proprietären Rahmen zum LI N- Rahmen
Tabelle 15 zeigt eine Übersicht einiger Diagnosedienste innerhalb des LI N -Kontextes. Tabelle 15 umfasst die Namen der Dienste und die zugehörigen Dienstidentifikatoren SID ("Blocktitel"), die hier als Hexadezimalwerte dargestellt sind. Des weiteren ist eine kurze Beschreibung zu jedem Diagnoseservice angegeben.
I mit Parameterübergabe" | | fisch besondere Befehle definiert werden.
Tabelle 15: Übersicht LIN-Diagnosedienste
Die Abbildung der Dienste auf den LI N- Rahmen kann nach einem der nachfolgenden Beispiele erfolgen.
Beispiel fünf: Beginn der Diagnosesitzung.
NAD: 0x83, Beispiel für Knotenadresse PCI: 0x04, SID, 3 Datenbytes und Checksumme, Einzelrahmen SID: 0x10, Beginn der Diagnosesitzung
Datum 1: xx, ECU Id Byte 1, im proprietären Protokoll spezifiziert Datum 2: xx, ECU Id Byte 2, im proprietären Protokoll spezifiziert Datum 3: es, Checksumme
Für den Start der Diagnosesitzung gilt Tabelle 16.
Tabellelδ: Start Diagnosesitzung
Beispiel sechs: Programmierung von 6 Bytes des Flash ROMs zur Adresse 0x0123.
Erster Rahmen (FF):
NAD: 0x83, Beispiel für Knotenadresse PCI: 0x10, erster Rahmen, mehr als 8 Datenbytes
LEN: OxOa, SID, 2 Adressenbytes, 6 Datenbytes und Checksumme sind zu übertragen
SID: 0x4b, "Program Flash ROM 16Bit Adressraum"
Datum 1: 0x01 MSB der Adresse, im proprietären Protokoll spezifiziert
Datum 2: 0x23 LSB der Adresse, im proprietären Protokoll spezifiziert Datum 3, Datum4: Datenbyte 1 und Datenbyte 2 Fortsetzungsrahmen (CF):
NAD: 0x83, Beispiel für Knotenadresse
PCI: 0x21, Fortsetzungsrahmen, zweiter Datenrahmen
D1-D4: zu übertragende Datenbytes (Byte 3 - Byte 6)
D5: es, Checksumme
D6: nicht benutzt, auf OxFF gesetzt
Tabelle 17: Datenübertragung
Eine mögliche Anwendung der Erfindung bietet sich bei der Entwicklungsphase von LIN-Komponenten und somit von Teilnehmern von LIN-Netzwerken bzw. Bussen, wobei derartige LIN-Komponenten insbesondere als elektronische Steuereinheiten (ECU) ausgebildet sind. Somit ist ein Flashen bzw. eine Softwareänderung von LIN- Komponenten am Bandende und innerhalb des LIN-Busses möglich. Außerdem ergibt sich die Möglichkeit, Diagnoseabfragen in dem LIN-Bus vornehmen zu können. LIN- Komponenten und somit auch -Busse sind am ehesten in der sog. Body- Domäne also im Fahrzeugaufbau verbreitet und werden für Klappenstellmotoren von Lüftungsanlagen, Motoren zur Sitzverstellung oder für die Türelektronik eingesetzt.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, dass die vorstehend genannten und die nachstehend noch zu erläu- ternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben. Kurze Beschreibung der Zeichnungen
Figur 1 zeigt in schematischer Darstellung ein Diagramm zu einer Ausführungsform eines Ablaufs einer Kommunikation in einem LIN-Netzwerk.
Figur 2 zeigt in schematischer Darstellung ein Diagramm zur einem Ablauf eines Beginns einer Diagnosesitzung.
Figur 3 zeigt in schematischer Darstellung ein Diagramm zu einem Ablauf einer ersten Ausführungsform einer Diagnosesitzung.
Figur 4 zeigt in schematischer Darstellung ein Diagramm zu einem Ablauf einer ersten Ausführungsform einer Diagnosesitzung.
Ausführungsformen der Erfindung
In dem Diagramm aus Figur 1 sind schematisch ein Master 102 und ein Slave 104 eines LIN-Netzwerks 106 dargestellt, die miteinander kommunizieren. Innerhalb des als LIN-Netzwerk 106 ausgebildeten Systems ist der Master 102 für die Zeiteinteilung 108 verantwortlich, da der Slave 104 lediglich eine Antwort senden kann, nachdem der Master 102 einen Header 110 eines Rahmens mit ID = 0x3d gesendet hat. Bei einer Diagnose eines Fahrzeugs, wobei eine Fahrzeugtesteinrichtung als Diagnose- Masterl02 vorgesehen ist, werden zeitliche Anforderungen, die durch ein Diagnose- Protokoll des Nutzers festgelegt sind, von dem Master 102 beschlossen. Dies bedeutet in vorliegender Ausführungsform, dass der Master zyklisch 102 Botschaften an den Slave 102 schickt, um somit anzuzeigen, dass sich das Untersystem im Testmodus befindet.
Die Diagnosekommunikation in dem LIN-Netzwerk 106 wird durch zwei Kommunikationsarten verwirklicht, nämlich von Anfragen (Requests) des Masters 102 und Antworten (Responses) des Slaves 104. Während eines ersten Zeitabschnitt 112 und somit in einem ersten Fall sendet der Master 102 eine erste Anfrage 114 an den Slave 104, wobei keine besonderen zeitlichen Parameter erforderlich sind. In einem zweiten Fall während eines zweiten Zeitabschnitts 116, bei dem von dem Slave 104 erwartet wird, eine Antwort an den Master 102 zu senden, ist vorgesehen, dass der Master eine zweite Anfrage 118 mit dem Header 110 mit ID = 0x3d versendet, der Slave 104 jedoch nicht antwortet. Um eine Beobachtung des Systems und somit des LIN-Netzwerks 106 zu gewährleisten, muss nach Versenden der zweiten Anfrage 118 eine Auszeit 120 bzw. ein Timeout (tRtOutM) in dem LIN-Netzwerk 106 implementiert werden. Der Master 102 sendet "0x3d", worauf der Slave 104 jedoch nicht antwortet, der Master 102 wiederholt die Botschaft mit "0x3d" bis die Auszeit abgelaufen ist. Eine Übersicht zu Zeiteinstellungen ist in nachfolgender Tabelle 18 vorgegeben. Eine dritte, ebenfalls unbeantwortete Anfrage 122 wird während eines dritten Zeitabschnitts 124 versendet. Während eines vierten Zeitabschnitts 126 sendet der Master 102 eine vierte Anfrage 128, auf die der Slave 104 mit einer ersten Antwort 130 reagiert, worauf die Auszeit 120 (traoutivi) beendet wird. Während eines fünften Zeitabschnitts 132 übermittelt der Master 102 eine fünfte Anfrage 134, auf die von dem Slave 104 mit einer zweiten Antwort 136 geantwortet wird.
Tabelle 18: Übersicht Zeitparameter
Um die Software einfach und übersichtlich zu halten, ist es möglich, die Rücksetzzeit 120 tRtoutM durch Zählen der 0x3d Rahmen ohne Antworten des Slaves 104 zu erfassen. Bei einer Beobachtung während des Beginns einer Kommunikation kann es erforderlich sein, längere Rücksetzzeiten 120 als bei normalen Arten der Kommunikation zu verwenden. Demnach ist der Maximalwert für eine Hauptzeit (TR^M) in der Regel von ei- nem Zustand des LIN-Netzwerks 106 abhängig.
Figur 2 zeigt in schematischer Darstellung ein Diagramm zum Ablauf des Beginns einer Diagnosesitzung 202 für eine ECU Programmierung eines einzelnen Slaves in einem LIN-Netzwerk. Dabei ist diese Diagnosesitzung 202 in eine Standarddiagnosesitzung 204, eine erweiterte Diagnosesitzung 206 und eine Programmierung 208 der Diagnosesitzung 202 unterteilt.
Die Diagnosesitzung 202 für die Flash- Reprogrammierung 210 beginnt mit dem Lesen 212 einer Identifikation des Slaves, in einem zweiten Schritt folgt eine Überprüfung 214 eines Zustands der Reprogrammierung 210.
Zu Beginn der erweiterten Diagnosesitzung 206 wird in einem dritten Schritt ein erster Wechsel 216 des Diagnosesitzungstyps vollzogen. Optional erfolgt in einem vierten Schritt eine Unterdrückung 218 von Fehlereinträgen. Zum Abschluss der erweiterten Diagnosesitzung 206 erfolgt ein zweiter Wechsel 220 des Diagnosesitzungstyps.
Der hier angegebene Fluss der Botschaften zwischen Master und Slave basiert auf der Übertragung einer Löschroutine und einer Schreibroutine für den Speicher, hier einem Flash-Speicher sowie auf zwei Datenblöcken. Falls eine Verriegelung der Software erforderlich ist, werden die Lösch- und Schreibroutinen des Flash-Speichers aus Sicherheitsgründen nicht vollständig auf der elektronischen Kontrolleinheit (ECU) abgelegt. Während einer Durchführung der Programmsequenz werden fehlende Teile dieser Routinen an den Slave übertragen. Es ist vorgesehen, dass zwei Speicherblöcke mit einer Länge von 64 Bytes zu dem Slave übertragen werden und in den Flash-Speicher programmiert werden. Die einzelnen in Figur 2 dargestellten Schritte werden als Einleitung zur Flash-Programmierung in dem LIN-Netzwerk benutzt.
Die Kommunikation in dem LIN-Netzwerk erfolgt während des Normalbetriebs mit dem LIN-Protokoll. Zur Realisierung von Sonderbetrieben, wie der Diagnosesitzung, werden in vorliegender Ausführungsform alternative Kommunikationsprotokolle durch das LIN- Protokoll getunnelt. Dabei erfolgt ein Umschalten des LIN-Protokolls zu einem derartigen alternativen Kommunikationsprotokoll bei dem ersten Wechsel 216, ein Rückschaltung von dem alternativen Kommunikationsprotokoll zu dem LIN-Protokoll erfolgt bei dem zweiten Wechsel 220, so dass die erweiterte Diagnosesitzung 206 für das LIN- Netzwerk mit dem alternativen Kommunikationsprotokoll erfolgt.
Zur Realisierung der Diagnosesitzung 202 mit dem anderen Diagnoseprotokoll kommen als Dienste UDS, KWP2000 oder propprietäre Dienste in Frage. Bei Nutzung des UDS-Dienstes wird die Programmierung der Diagnosesitzung 202 lediglich in den sog. "bootloader" eingegeben. Falls eine Verbindung zwischen gleichwertigen Teilnehmern und somit eine Punkt-zu-Punkt Verbindung vorliegt, können die in Figur 2 dargestellten Schritte teilweise weggelassen werden. In diesem Fall genügt für UDS der durch das Diagramm aus Figur 3 und für den proprietären Dienst der durch das Diagramm aus Figur 4 dargestellte, verbleibende Programmierungsprozess.
Der Vorgang zur Flash-Programmierung wird durch Senden einer Sequenz eines Diagnoseantrags zu dem Slave kontrolliert. Daraufhin übermittelt der Slave eine positive oder negative Antwort. Im Falle einer negativen Antwort ist eine Fehlerbehandlung erforderlich, wobei eine derartige Fehlerbehandlung projektspezifisch ist.
Figur 3 zeigt ein Diagramm zu einem Ablauf einer ersten Ausführungsform einer Diagnosesitzung für den Fall, dass ein als UDS vorgesehenes Kommunikationsprotokoll bei einer Programmierung einer elektronischen Steuereinheit in einem LIN-Netzwerk durch ein LIN-Protokoll getunnelt wird. Dabei wird eine Reprogrammierung eines Slaves, der als die elektronische Steuereinheit (ECU) ausgebildet ist, innerhalb des LIN-Netzwerks vorgenommen.
Dabei sind für eine Programmierung 302 der Diagnosesitzung mehrere Schritte vorgesehen. Mit einem ersten Schritt erfolgt ein Start 304 der Programmierungssitzung, in einem zweiten Schritt wird UDS-spezifisch ein Sicherheitszugang 306 gewährt und in einem dritten Schritt ein Fingerprint 308 übermittelt. Danach erfolgt in einem vierten Schritt ein Austausch 310 einer Löschroutine, worauf in einem fünften Schritt eine Lö- schung 312 eines Speichers, hier eines Flash-Speichers, durchgeführt wird. Die Schritte vier und fünf können bedarfsweise wiederholt werden. Danach wird in einem sechsten Schritt ein Austausch 314 einer Schreibroutine vorgenommen, worauf in einem siebten Schritt ein Schreiben 316 des Speichers erfolgt, auch der sechste und der siebte Schritt können erforderlichenfalls wiederholt werden. Eine Bestätigung 318 des In- halts des Speichers wird im achten Schritt durchgeführt. Im neunten Schritt wird die Programmierung der Diagnosesitzung durch ein Zurücksetzen 320 beendet. Es sei darauf hingewiesen, dass die Schritte zwei, vier, fünf, sechs und acht in den innerhalb des Diagramms gestrichelt umrandeten Kästen in der vorliegende Ausführungsform optional durchzuführen sind. Details zu den Schritten ergeben sich aus den nachfolgenden Tabellen.
Die Diagnosedatenrahmen des LIN sind somit in Figur 3 dargestellt. Dieses Ausführungsbeispiel basiert auf einer Flash-Programmierung von zwei Datenblöcken mit einer Länge von 64 Bytes in den Slave. Da in dem ECU keine Routine zum Löschen oder Schreiben des Flash-Speichers vorgesehen ist, werden derartige Routinen nach deren Übertragung zu dem ECU im RAM ausgeführt. Außerdem sind in diesem Beispiel keine Zeitangaben, wie bspw. für ein Warten auf eine Antwort, vorgesehen, da diese von der benutzten Hardware abhängen. Es ist lediglich eine Reihenfolge der Sequenzen der Botschaft beschrieben. Zunächst wird eine Diagnoseprogrammierungsitzung, wie in Tabelle 19 gezeigt, gestartet.
Tabelle 19: Start 304 der Diagnoseprogrammierungssitzung
Danach wird der Sicherheitszugang 306 eingesetzt, falls die ECU einen Verriegelungsmechanismus benutzt. In nachfolgender Tabelle 20 ist dargestellt, wie eine Testeinrichtung von der als LIN-Slave ausgebildeten Komponente mit SID 0x27 einen Seed anfordert. Das nächste Byte steht für einen Parameter einer Unterfunktion, die gemäß UDS den Seed anfordert. Die Antwort umfasst einen beliebig gewählten Keim, beispielsweise 0x21 0x47.
Tabelle 20: Sicherheitszugang 306, Lesen des Seeds (readSeed)
Der Sicherheitszugang 306 wird, wie in Tabelle 21 dargestellt, durch Übermittlung eines errechneten Schlüssels, der auf dem empfangenen Seed basiert, fortgesetzt. Ein Wert 0x02 der Unterfunktion gemäß UDS spezifiziert die "sendKey" Funktion des Dienstes 0x27 zum Senden des Schlüssels. Falls der Schlüssel, beispielsweise 0x47 0x11, passt, wird ein Programmierungszugang gewährt.
Tabelle 21: Sicherheitszugang 306, Senden des Schlüssels (sendkey)
Da nun ein Zugang zu dem Slave möglich ist, wird ein Software- Fingerprint 308 und somit ein Fingerabdruck der Software zur Speicherung in den Slave übertragen. Dabei können die xx und yy Bytes gemäß der Identität des gewünschten Fingerprints 308 besetzt werden. Danach werden die Daten des Fingerprints 308 gemäß UDS, beispielsweise 0x01 - 0x03, übermittelt. Eine Übertragung des Fingerprints 308 zeigt exemplarisch Tabelle 22.
Tabelle 22: Übermittlung des Fingerprints 308
Da in diesem Beispiel der Slave eine Softwareverriegelung benutzt, ist in dem Flash- Speicher keine Löschroutine abgelegt. Stattdessen wird ein Programmierungscode zum Löschen des Flash-Speichers, wie in Tabelle 23 gezeigt, unmittelbar vor einer Durchführung der Löschoperation zumindest teilweise übertragen.
Tabelle 23: Runterladen der Löschroutine
Nach einer kompletten Übertragung der Löschprozedur kann der Programmcode, wie in Tabelle 24 dargestellt, überprüft werden. Mit der Kontrollsequenz (0x31) der Routine wird in dem Slave eine Prozedur mit einer Routine mit ID = xxxx gestartet, wobei gemäß UDS eine Unterfunktion 0x01 = start festgelegt ist. Da zur Berechnung der Routine ein gewisser Zeitraum erforderlich ist, ist die Antwort verzögert. Ein derartiges Verhalten kann jedoch durch ein Testwerkzeug und somit eine Fahrzeugtesteinrichtung berücksichtigt werden. In einer positiven Antwort wird als Ergebnis der Routine yyyy mitgegeben.
Tabelle 24: Überprüfung Löschroutine
In Tabelle 25 ist gezeigt, wie der Flash-Speicher unter Verwendung der kurz zuvor ü- bermittelten Löschroutine gelöscht wird. Die Löschroutine wird durch die Kontrollsequenz 0x31 zu dieser Löschroutine aufgerufen und mit der Unterfunktion 0x01 = start gemäß UDS begonnen. Eine Identität (ID) der Löschroutine ist als xxyy kodiert. Da die Löschung 312 einen gewissen Zeitraum beansprucht, sind einige der RX- Diagnosebotschaften des Slaves gegebenenfalls leer. Nach Abschluss des Löschvorgangs wird eine positive Antwort gesendet. Die zur Löschung 312 beanspruchte Zeit wird durch ein Flash-Werkzeug berücksichtigt.
Tabelle 25: Speicherlöschung
Bedingt durch die Verriegelung der Software ist im vorliegenden Beispiel keine Schreibroutine zu dem nichtflüchtigen Speicher vorgesehen. Nachfolgende Tabelle 26 zeigt eine Botschaftssequenz, mit der die Schreibroutine für den Slave heruntergeladen wird.
Tabelle 26: Runterladen der Schreibroutine
Die übertragenen Bytes werden mit den in Tabelle 27 gelisteten Befehlssequenzen auf Richtigkeit überprüft.
Tabelle 27: Überprüfung der Schreibroutine Nun wird der aktuell vorliegende erste Speicherblock übertragen, was in Tabelle 28 dargestellt ist. Hierbei wird in einem ersten Schritt ein Herunterladen von 64 (0x40) Datenbytes an der Adresse xxyy angefordert. Nach einer positiven Antwort werden die Daten mit aufeinanderfolgenden Rahmen in den Datentransferdienst (0x36) übertragen. Dieser Datentransferdienst beginnt mit einer Anfrage nach 66 Datenbytes (0x42; 64 Daten, 1 SID und 1 Blocksequenznummernbyte). Zuletzt werden alle Rahmen der übertragenen Daten versendet, eine positive Antwort wird empfangen. Demnach kann die Übertragung mit einer Sequenz (0x37) zur Anforderung des Übertragungsendes (Re- questTransferExit) abgeschlossen werden.
Tabelle 28: Runterladen des ersten Speicherblocks
Mit nachfolgender Tabelle 29 ist dargestellt, wie ein zweiter Speicherblock herunterge- laden wird. Dies erfolgt nach demselben Schema wie das mit Tabelle 28 dargestellte Herunterladen. Ein derartiger Flash-Vorgang beansprucht einen gewissen Zeitraum, weshalb als Pause ein Intervall vorzusehen ist, bevor ein Herunterladen des zweiten Datenblocks begonnen werden kann.
Tabelle 29: Runterladen des zweiten Speicherblocks
Nach einer für den Flash-Vorgang vorgesehenen Wartezeit kann die Diagnosesitzung fortgesetzt werden. Für sämtliche übertragenen und in dem nichtflüchtigen Speicher gespeicherten Daten kann eine Überprüfung aktiviert werden. Nachfolgende Tabelle 26 zeigt eine hierfür geeignete Diagnosesequenz. Gemäß UDS wird eine Prüfroutine mit der ID xxyy und der Unterfunktion 0x01 = start begonnen. Ein derartiger Vorgang zur Überprüfung beansprucht einen gewissen Zeitraum, weshalb bis zum Eintreffen einer positiven oder negativen Antwort ein Intervall zu berücksichtigen ist.
Tabelle 30: Überprüfung der Speicherblöcke
Einen letzten Schritt zum Rücksetzen der ECU zeigt Tabelle 31. Im vorliegenden Beispiel wird ein derartiger Dienst zum Rücksetzen mit einem Parameter für ein hartes bzw. abruptes Rücksetzen (OxOl) angefordert. Es können jedoch auch andere Beschreibungen des Parameters gemäß UDS vorgesehen sein.
Tabelle 31: Rücksetzen der ECU
Figur 4 zeigt ein Diagramm zu einem Ablauf einer zweiten Ausführungsform einer Diagnosesitzung für den Fall, dass ein proprietäres Kommunikationsprotokoll bei einer Programmierung eines elektronischen Steuereinheit in einem LIN-Netzwerk durch das LIN- Protokoll getunnelt wird. Dabei wird eine Reprogrammierung eines Slaves, der als die elektronische Steuereinheit (ECU) ausgebildet ist, innerhalb des LIN-Netzwerks vorgenommen.
Dabei sind für eine Programmierung 402 der Diagnosesitzung mehrere Schritte vorge- sehen. Mit einem ersten Schritt erfolgt der Start 404 der Programmierungssitzung. In einem zweiten Schritt wird ein Flash- ROM-Zugang 406 und in einem dritten Schritt ein RAM-Zugang 408 bereitgestellt. In einem vierten Schritt wird ein Fingerprint 410 übermittelt. Danach erfolgt in einem fünften Schritt der Austausch 412 einer Löschroutine, worauf in einem sechsten Schritt die Löschung 414 eines Speichers durchgeführt wird. Die Schritte fünf und sechs können bedarfsweise wiederholt werden. Danach wird in einem siebten Schritt der Austausch 416 einer Schreibroutine vorgenommen, worauf in einem achten Schritt das Schreiben 418 des Speichers erfolgt, auch der siebte und der achte Schritt können erforderlichenfalls wiederholt werden. Eine Bestätigung 420 eines Inhalts des Speichers wird im neunten Schritt durchgeführt. Im zehnten Schritt wird die Programmierung der Diagnosesitzung durch ein Zurücksetzen 422 beendet. Es sei darauf hingewiesen, dass die Schritte zwei, drei, fünf, sechs, sieben und neun in den gestrichelt umrandeten Kästen in der vorliegende Ausführungsform optional durchgeführt werden können.
Die Diagnosedatenrahmen des LIN sind somit in Figur 4 detailliert dargestellt. Dieses Ausführungsbeispiel basiert auf einer Flash-Programmierung von zwei Datenblöcken mit einer Länge von 64 Bytes in den Slave. Da in dem ECU keine Routine zum Löschen oder Schreiben des Flash-Speichers vorgesehen ist, werden derartige Routinen nach deren Übertragung zu dem ECU im RAM ausgeführt. Außerdem sind in diesem Beispiel keine Zeitangaben wie beispielsweise für ein Warten auf eine Antwort, vorgesehen, da diese von der benutzten Hardware abhängen. Es ist lediglich eine Reihenfolge der Sequenzen der Botschaft beschrieben. Zunächst wird eine Diagnoseprogrammierungsitzung, wie in Tabelle 32 gezeigt, gestartet.
Tabelle 32: Start 404 der Programmierung der Diagnosesitzung
Danach wird der Flash- ROM-Zugang 406 bereitgestellt (wie in Tabelle 33 dargestellt).
Tabelle 33: Bereitstellung des Flash- ROM-Zugangs 406
Die Löschroutine und die Schreibroutine für den Flash Speicher werden in den RAM geladen, wobei der RAM-Zugang 408 ermöglicht wird
Tabelle 34: Bereitstellung des RAM-Zugangs 408
Da nun der Flash-ROM-Zugang 406 bereitgestellt ist, kann der Fingerprint 410 der Software nach Tabelle 35 zu dem Slave übertragen werden. Dabei werden die xx und yy Bytes gemäß der Identität des gewünschten Fingerprints 410 besetzt. Danach werden die Daten des Fingerprints 410, beispielsweise yy, übermittelt.
Tabelle 35: Übertragung des Fingerprints 410
Da der Slave in diesem Beispiel eine Softwareverriegelung verwendet, liegt im Flash- Speicher keine Routine zum Löschen vor. Stattdessen wird ein Programmcode zum Löschen des Flash-Speichers, wie Tabelle 36 zeigt, unmittelbar vor einer Löschoperation zumindest teilweise in die RAM-Adresse 0x01234 übertragen.
Tabelle 36: Runterladen der Löschroutine
In nachfolgender Tabelle 38 ist dargestellt, wie der Flash-Speicher mit der zuvor übertragenen Löschroutine gelöscht wird. Der Dienst für die entsprechende Routine besitzt die Bezeichnung "BuIk- Erase Flash ROM 16 Bit Adressraum", eine zugehörige Unter- funktion 0x00 zu dem proprietären Protokoll bedeutet, dass der komplette Flash- Speicher gelöscht wird. Da die Löschung einige Zeit beansprucht, können einzelnen RX- Diagnosebotschaften des Slaves leer sein. Um anzuzeigen, dass der LIN-Slave dennoch wartet, sollte eine Antwort, die besagt, dass der Tester wartet, in spezifischen Zeitintervallen übersendet werden. Nach Beendigung des Lösch prozesses wird eine positive Antwort gesendet. Die Zeit zur Löschung 414 wird durch ein Flash-Werkzeug berücksichtigt.
Tabelle 37: Löschung 414 des Speichers
Bedingt durch die Verriegelung der Software ist im vorliegenden Beispiel keine Routine zum Schreiben des nichtflüchtigen Speichers vorgesehen. Nachfolgende Tabelle 38 zeigt eine Botschaftssequenz, mit der eine Schreibroutine für den Slave heruntergeladen wird.
Tabelle 38: Schreibroutine Runterladen
Nun wird der erste, aktuell vorliegende Speicherblock übertragen, was in Tabelle 39 dargestellt ist. Der Dienst "Program Flash ROM 16bit" startet mit einer Anfrage nach 68 Datenbytes (0x44; 64 Daten, 1 SID, 2 Adressenbytes (0x0123) und 1 Checksummenbyte). Zuletzt werden alle Rahmen der übertragenen Daten versendet, eine positive Antwort wird empfangen.
Tabelle 39: Runterladen des ersten Speicherblocks Nachfolgende Tabelle 40 beginnt mit dem Herunterladen eines zweiten Speicherblock (Adresse 0x123+40). Dies erfolgt ebenfalls wie in Tabelle 39 dargestellt. Bevor das Herunterladen des zweiten Speicherblocks begonnen wird, ist ein Intervall einzuführen, da der Flash-Vorgang einige Zeit beansprucht.
Tabelle 40: Runterladen des zweiten Speicherblocks
Nach dem für den Flash- Vorgang vorgesehenen Intervall kann die Diagnosesitzung fortgesetzt werden. Für sämtliche übertragenen und in dem nichtflüchtigen Speicher gespeicherten Daten kann eine Überprüfung aktiviert werden. Nachfolgende Tabelle 41 zeigt eine hierfür geeignete Diagnosesequenz. Bei dem proprietären Protokoll wird eine Prüfroutine mit der ID xyyx begonnen. Ein derartiger Vorgang zur Überprüfung bean- sprucht eine gewisse Zeit, weshalb bis zum Eintreffen einer positiven oder negativen Antwort ein Intervall zu berücksichtigen ist.
Tabelle 41: Überprüfen des Speicherblocks Der letzte Schritt des Rücksetzens der ECU ist in Tabelle 42 dargestellt. Der Dienst "Transparenter Datenblock mit Parameterübergabe" wird mit einem harten Rücksetzen (zz) der Parameter (OxOl) angefordert.
Tabelle 42: Rücksetzen der ECU

Claims

Ansprüche
1. Verfahren zum Betreiben eines LIN-Busses, dessen Spezifikationen in einem Normalbetrieb durch einen LIN-Bus beschrieben sind, bei dem zur Durchführung eines Sonderbetriebs ein alternatives Kommunikationsprotokoll durch das LIN- Protokoll getunnelt wird.
2. Verfahren nach Anspruch 1, bei dem ein mit dem Kommunikationsprotokoll verbundener Dienst auf einen Rahmen des LIN-Protokolls abgebildet wird.
3. Verfahren nach Anspruch 2, bei dem mindestens ein Datum des Rahmens in Abhängigkeit des Dienstes belegt wird.
4. Verfahren nach Anspruch 3, bei dem mindestens ein Datum des Diagnoseframes in Abhängigkeit des Dienstes belegt wird.
5. Verfahren nach einem der voranstehenden Ansprüche, bei dem mindestens ein Teilnehmer des LIN-Busses über das Kommunikationsprotokoll programmiert wird.
6. Verfahren nach einem der voranstehenden Ansprüche, bei dem während des Sonderbetriebs eine Diagnose durchgeführt wird, wobei das alternative Kommunikationsprotokoll auf einem Diagnoserahmen des LIN-Protokolls abgebildet wird.
7. Verfahren nach einem der voranstehenden Ansprüche, bei dem ein UDS-
Protokoll durch das LIN-Protokoll getunnelt wird, wobei ein UDS-Dienst auf dem Rahmen abgebildet wird.
8. Verfahren nach einem der Ansprüche 1 bis 6, bei dem ein proprietäres Protokoll durch das LIN-Protokoll getunnelt wird, wobei ein proprietärer Dienst auf dem Rahmen abgebildet wird.
9. Verfahren nach einem der Ansprüche 1 bis 6, bei dem ein KWP2000- Protokoll durch das LIN-Protokoll getunnelt wird, wobei ein KWP2000- Dienst auf dem Rahmen abgebildet wird.
10. Verfahren nach einem der voranstehenden Ansprüche, bei dem Parameter des alternativen Kommunikationsprotokolls dienstabhängig belegt werden.
11. Anordnung, die einen LIN-Bus mit mehreren Teilnehmern aufweist und deren Spezifikationen in einem Normalbetrieb durch ein LIN-Protokoll beschrieben sind, und die zur Durchführung eines Sonderbetriebs dazu ausgebildet ist, ein alternatives Kommunikationsprotokoll durch das LIN-Protokoll zu tunneln.
12. Anordnung nach Anspruch 11, bei der ein erster Teilnehmer als Master (102) und mindestens ein zweiter Teilnehmer als Slave (104) ausgebildet ist.
13. Anordnung nach Anspruch 12, bei dem zur Durchführung einer Kommunikation vorgesehen ist, dass der Master (102) an den Slave (104) Anfragen (114, 118, 122, 128, 134) übermittelt und der Slave (104) and den Master (102) Antworten (130, 136) übermittelt.
14. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 10 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Anordnung nach einem der Ansprüche 11 bis 13, ausgeführt wird.
15. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 10 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einem Steuergerät in einer Einrichtung nach einem der Ansprüche 11 bis 13, ausgeführt wird.
EP07765778A 2006-07-12 2007-07-03 Verfahren zum betreiben eines lin-busses Withdrawn EP2044736A1 (de)

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 (de) 2006-07-12 2007-07-03 Verfahren zum betreiben eines lin-busses

Publications (1)

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

Family

ID=38443345

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07765778A Withdrawn EP2044736A1 (de) 2006-07-12 2007-07-03 Verfahren zum betreiben eines lin-busses

Country Status (5)

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

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 (de) * 2010-08-03 2012-02-09 Continental Teves Ag & Co. Ohg Kommunikationsverfahren mit echo
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 (de) * 2003-11-10 2005-05-11 Robert Bosch Gmbh Simulationssystem und Computerimplementiertes Verfahren zur Simulation und Verifikation von Kontrollsystemen
EP1735672A1 (de) * 2004-04-01 2006-12-27 Delphi Technologies, Inc. Verfahren und protokoll zur diagnose beliebig komplexer netzwerke von einrichtungen
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 (de) 2008-01-17

Similar Documents

Publication Publication Date Title
EP2044736A1 (de) Verfahren zum betreiben eines lin-busses
EP2553590B1 (de) Verfahren zur übertragung von daten über einen canopen-bus
DE10219832B4 (de) Verfahren zum Kodieren von Steuergeräten in Verkehrsmitteln
EP2137030A2 (de) Kommunikationssystem eines fahrzeugs und verfahren zum betreiben eines kommunikationssystems
DE102014111962B4 (de) Kalibrieren einer elektronischen Steuerungseinheit eines Fahrzeugs
EP2825921B1 (de) Steuerungsvorrichtung zum steuern von sicherheitskritischen prozessen in einer automatisierten anlage und verfahren zur parameterierung der steuerungsvorrichtung
DE102010026494A1 (de) Verfahren zur Konfigurierung einer Steuerungseinrichtung
EP1417469A2 (de) Kommunikationsverfahren und kommunikationsmodul
EP2957075B1 (de) Master-busgerät für einen fahrzeugkommunikationsbus eines kraftwagens
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 (de) Verfahren und vorrichtung zur parametrierung eines as-i-slaves
DE102009027168B4 (de) Verfahren zum Ermitteln einer übermittelten Telegramm-Datenlänge
EP1814763B1 (de) Verfahren und System zur Bereitstellung von internen diagnoserelevanten Informationen in einem Fahrzeug
WO2012025323A1 (de) Verfahren zur durchführung einer kommunikation
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen
EP3948448B1 (de) Verfahren, softwareklemme und klemmensystem zur änderung einer steuerungssoftware eines automatisierungssystems
DE102007054810A1 (de) Verfahren zum Erkennen unterschiedlicher Kommunikationsprotokolle in einem Steuergerät
EP1885100B1 (de) Verfahren zur automatischen Adressvergabe an einen Kommunikationsteilnehmer und Kommunikationsteilnehmer
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