WO2009135707A1 - Teilnehmerknoten eines kommunikationssytems mit funktional getrenntem sende-ereignisspeicher - Google Patents

Teilnehmerknoten eines kommunikationssytems mit funktional getrenntem sende-ereignisspeicher Download PDF

Info

Publication number
WO2009135707A1
WO2009135707A1 PCT/EP2009/052578 EP2009052578W WO2009135707A1 WO 2009135707 A1 WO2009135707 A1 WO 2009135707A1 EP 2009052578 W EP2009052578 W EP 2009052578W WO 2009135707 A1 WO2009135707 A1 WO 2009135707A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
memory
sent
transmission
subscriber node
Prior art date
Application number
PCT/EP2009/052578
Other languages
English (en)
French (fr)
Inventor
Florian Hartwich
Marc Schreier
Franz Bailer
Markus Ihle
Tobias Lorenz
Christian Horst
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
Priority to RU2010149264/08A priority Critical patent/RU2537811C2/ru
Priority to EP09741925A priority patent/EP2294763A1/de
Priority to CN200980116066.4A priority patent/CN102100037B/zh
Priority to JP2011507848A priority patent/JP5237438B2/ja
Priority to US12/736,758 priority patent/US8732374B2/en
Publication of WO2009135707A1 publication Critical patent/WO2009135707A1/de

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/40006—Architecture of a communication node
    • H04L12/40032—Details regarding a bus interface enhancer
    • 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/40143—Bus networks involving priority mechanisms
    • 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/40215—Controller Area Network CAN

Definitions

  • the present invention relates to a subscriber node of a communication system.
  • the communication system comprises a data bus to which the subscriber node and at least one further subscriber node are connected.
  • the subscriber node has a communication controller for sending messages over the data bus and / or for receiving messages from the data bus and message memory for buffering messages to be sent or received.
  • the invention further relates to a communication system comprising a data bus and a plurality of subscriber nodes connected thereto for the purpose of data transmission.
  • Subscriber nodes each have a communication controller for sending messages over the data bus and / or for receiving messages from the data bus and message memory for buffering messages to be sent or received.
  • the present invention also relates to a method for transmitting a message from a first subscriber node of a communication system via a data bus of the communication system to a second subscriber node of the communication system.
  • An application program of the first subscriber node places the message to be sent in a message memory, from where it is fetched from a communication controller in response to a send command from the application program and transmitted via the data bus.
  • CAN controller area network
  • This is an asynchronous, serial bus system developed by Bosch in 1983 for the networking of control units in automobiles and compiled in 1986 (see SAE Paper 860391, International Congress and Exposition, Detroit, Michigan, Feb. 24-28, 1986) was introduced with Intel to reduce the length of wire harnesses in automobiles and thereby space and weight to save.
  • the use of the CAN bus is not limited to the automotive sector.
  • the CAN bus has been introduced, for example, in building control technology and in machine tools.
  • the data transmission takes place in CAN in data frames (so-called frames), which in addition to the user data to be transmitted (the actual message) and configuration data at the beginning (header part) and test data at the end (CRC part) of the
  • a known communication system of the above type are a FlexRay bus, a Media Oriented Systems Transport (MOST) bus, or any fieldbus, such as a LIN (Local Interconnect Network) bus.
  • MOST Media Oriented Systems Transport
  • LIN Local Interconnect Network
  • messages are transmitted between a first and a second subscriber node by an application program of the first subscriber node copies the message to be sent in a message memory, from where they fetched on a transmission command of the application program from a communication controller and transmitted via the data bus becomes.
  • the application program of the subscriber node copies the message to be sent of the urgent send request into a message store, from where it is fetched on a send command of the application program from a communication controller and transmitted via the data bus. After completing the urgent send request, the application program resumes the interrupted transmission. For this purpose, it is necessary for the application program to have information about the status of the job processed before the urgent job
  • Send job The application program should have the option of to inform themselves about the result of sending orders and possible withdrawals of send orders.
  • the message stores whose contents are to be sent are connected to status bits. Often only the success of a send job can be displayed on the status bits. Some results, especially in the case of a withdrawal of a send job (Tx Cancellation), can not be represented by the status bits.
  • the present invention is based on the object of designing and further developing a subscriber node such that information about send jobs can be managed and made accessible to the application program.
  • the subscriber node has at least one transmission event memory functionally separated from the message memories, in which a transmission event is stored for at least one message to be sent or sent.
  • the information about the send jobs is not stored in the message stores whose contents are to be sent, but in a separate list as part of a send event memory.
  • This has the advantage that the application program does not have to gather the information from different message stores, but rather that the information can be retrieved at a fixed location, preferably in chronological order, and that the message stores are immediately available again after the resumption of a send job and continue to be used without having to wait for the result of this withdrawal.
  • a CPU of the subscriber node can turn to the processing of the next send job immediately after the return of a send job and, for example, store the message in the message store. Of course, the CPU is also available for any other activities after taking back.
  • the processing of successive send jobs can be accelerated in the event of a withdrawal of a send job, and the efficiency of the CPU can be improved.
  • the invention also has the advantage that the status flags on the status of a send job are not coupled to the message store. According to an advantageous development of the invention, it is proposed that the transmission event comprises at least one of the following events:
  • the application program of the subscriber node can therefore retrieve the exact status or the output of a preceding transmission job at any time. It is not only possible to retrieve information about whether the data transfer was successful, but also about the circumstances under which the transfer was successful (with or without withdrawal of the send request) and whether and under which circumstances the send request was withdrawn ( Transmission has not yet started (for example because the data bus was busy), transmission ends after loss of arbitration or transmission ends after error). This additional information allows the application program to continue taking a data transmission whose send job has been withdrawn to take appropriate measures, for example to issue a new send job.
  • an identifier of the at least one message to be sent or sent is stored in the transmission event memory.
  • the identifier preferably allows a unique identification of the message or the transmission request.
  • the identifier stored in the transmission event memory in addition to the transmission event for the at least one message to be sent or transmitted makes it possible to unambiguously assign the transmission event to a specific message or a specific transmission job even if several transmission events are stored in the event memory stored by various send jobs.
  • this makes it possible at any time to read out the transmission event for a specific message or for a specific transmission request. The greater the capacity of the event memory, the more send events with associated information can be stored.
  • a data length code of the at least one message to be sent or sent a time stamp indicating when the event has occurred
  • an address of the message store for which the send job existed a sequence counter that identifies data packets when larger amounts of data are sent sequentially in multiple messages with the same identifier
  • a timestamp may be important for certain application programs. If the subscriber node has several transmit message memories (so-called send buffers), it can be determined from the address of the message store for which the send job was present which send buffer is free for new send requests.
  • a sequence counter can be important, for example, in the case of a software download if, for example, at the end of the tape or during a workshop visit, subscriber nodes of the communication network designed as control devices are programmed new or with a new software version for the first time. The software is split into several, for example, 8-byte data packets, which have the same identifier. The sequence counter indicates for which of the data packets a transmission event has been stored in the event memory or which of the data packets has been transmitted successfully.
  • the transmit event memory is organized as a FIFO (First In First Out) memory.
  • the transmission event memory preferably has a plurality of memory elements, wherein information about a message to be sent or sent is stored in each memory element.
  • a capacity of the event memory of a few memory elements will suffice.
  • the transmit event memory comprises a Random Access Memory (RAM).
  • Conceivable is also a realization in another way, for example by means of flip-flops, but these require a relatively large silicon area and thus also cause relatively high costs.
  • the transmission event memory is formed as part of a message memory.
  • the size of the transmission event memory in particular the number of memory elements of the event memory, can be freely configured by software, for example by means of configuration bits. In this way, the size of the event memory can be easily adapted flexibly to the individual requirements.
  • the at least one subscriber node has at least one transmission event memory functionally separated from the message memories, in which a transmission event for at least one message to be sent or sent is stored.
  • the at least one subscriber node of the communication system according to the invention can also have features of one or more of the subclaims 2 to 8.
  • a transmission event for the message to be sent or transmitted be stored in a transmission event memory functionally separated from the message memory, and the application program can access the information stored in the event memory at any time.
  • FIG. 1 shows an example of a communication network according to the invention
  • FIG. 2 shows an example of a subscriber node according to the invention of a communication network according to FIG. 1; and FIG. 3 shows an example of a flow chart of a method according to the invention for message transmission via a communications network according to FIG. 1.
  • a communication system is designated in its entirety by the reference numeral 1.
  • the network 1 comprises a data bus 2, which is represented symbolically by a single line.
  • the data bus 2 may be formed as a one-, two- or multi-wire bus.
  • the physical layer of the data bus 2 may comprise one or more copper lines, one or more optical fiber lines, or also optical (e.g., infrared) or radio links.
  • Several subscriber nodes 3 are connected to the data bus 2, of which only three are shown by way of example in FIG. Each node 3 is connected to the data bus 2 via a communication module 4 (so-called communication controller CC).
  • the nodes 3 also have a host application 5 (so-called application program AP).
  • messages 7 can be transmitted according to a serial communication protocol (e.g., CAN, FlexRay, LIN, MOST, etc.).
  • the communication module 4 is responsible for receiving and sending messages 7 via the data bus 2.
  • the messages 7 each have a so-called header 8 with an identifier (so-called identifier) and further configuration bits.
  • the messages 7 also have a user data part 9 (so-called payload) and a so-called trailer 10.
  • the identifier enables unambiguous identification of the messages 7.
  • the identifier is, for example, a type of sender Address which allows the determination of the origin of the message 7 and identifies the content 9 of the message 7.
  • transmit buffer 11 and receive buffer 12 (Rx) are arranged as intermediate memories for outgoing or incoming messages 7.
  • the message stores 11, 12 may be integral with or separate from the communication controller 4.
  • the message stores 11, 12 are preferably constructed in the manner of a FIFO (First In First Out). They are, for example, designed as a random access memory (RAM).
  • FIFO First In First Out
  • the application program 5 of one of the subscribers 3 wants to send a message 7 via the data bus 2 to another subscriber 3, it first deposits the message 7 to be sent or its content 9 in the send buffer 11 (arrow 20 in FIG. 2). On one
  • the transmission of the message 7 via the data bus 2 is serial and can therefore take a relatively long time.
  • the present invention relates to the case that at any time during the processing of the transmission job this is withdrawn (so-called. Transmit Cancellation), for example, because initially another, especially urgent send job is to be processed.
  • the transmission job begins with the filing of the message 7 or its content 9 in the transmission buffer 11 and ends with the receipt of a response from the communication controller 4 that the message was sent successfully or not.
  • the transmission buffers 11 are connected to status bits which can provide information as to whether the transmission request has been successfully completed or not. Information about further events, in particular in the case of a withdrawal of the send request, can not be taken from the status bits.
  • a possibly already started send process i.e., Start Of Frame (SOF) already sent in the CAN
  • SOF Start Of Frame
  • the application program 5 can not remove the status bits.
  • the application program 5 must wait for the result of the send job and is blocked during this time, so to speak.
  • the present invention can provide improvements.
  • a transmission event memory 13 which is functionally separate from the message memories 11, 12 is provided in the subscriber node 3, in which a transmission event or status for at least one message 7 to be transmitted or sent is stored.
  • Tx Stat transmission event memory 13
  • the Communication network 1 be provided with a transmission event memory 13.
  • the event memory 13 is preferably formed as a random access memory (RAM) and organized in the manner of a FIFO.
  • the event memory 13 may also be designed as a read-only memory (eg flash memory, ROM, EEPROM).
  • the event memory 13 may be formed as an integral part of the communication controller 4 or separate from it.
  • the transmission event memory 13 can be separated from the message memories 11, 12 or as part of a message memory 11, 12 be formed. If the event memory 13 is part of a message memory 11, 12, the size of the event memory 13 can be defined flexibly by software, for example by means of configuration bits, according to the individual requirements.
  • the information about the status of the send jobs are therefore no longer stored in a message store 11 whose contents should be sent, but in a separate send event list. This preferably contains one entry per send or return event.
  • the information about the status of the transmission jobs can be managed in the communication module 4 and stored in the event memory 13 (arrow 23 in FIG. 2).
  • the application program 5 can pick up the information stored in the event memory 13 flexibly in terms of time (arrow 24 in FIG. 2). It is particularly advantageous that the information about the send jobs are now completely separate from the send buffer 11.
  • the application program 5 does not have to gather together the status information about the send jobs from different message stores 11, but that the information on a fixed Place (in the send event list in the transmission event memory 13) are preferably sorted by time. After the withdrawal of a transmission request, the message memory 11 can be used immediately without having to wait for the result of the transmission request or the withdrawal.
  • the application program 5 can read out the information stored in the event memory 13 at a later time, it does not have to react to it immediately (for example, by interrupt). If the event memory 13 threatens to overflow because the application program 5 reads it too seldom, a warning signal can be output in a first step, which can be associated with appropriate measures for accelerated or more frequent readout of at least part of the information. If the memory 13 actually overflows, an error signal may be output. In this case, the oldest entries in the send event memory 13 can be discarded to make room for the information of current send requests.
  • the event memory 13 contains temporally ordered results (message 7 sent, withdrawal of the send request) of send requests. Below are some examples of other events that can be stored in the event memory 13:
  • identifiers for example CAN identifiers
  • the identifier allows a unique identification and assignment of the stored information to certain messages, so that the messages do not necessarily have to be stored in a time sequence in the memory 13. It is also conceivable to include one or more of the following additional information in the transmission event memory 13:
  • a timestamp may be important to particular application programs. If the subscriber node 3 has multiple send buffers 11, it can be determined based on the address of the message store 11 for which the send job existed, which send buffer 11 is free for new send jobs.
  • a sequence counter can be important, for example, in the case of a software download if, for example, subscriber nodes 3 of the communications network 1 designed as control devices at the end of the tape or during a workshop visit are programmed for the first time or with a new software version.
  • the software is split into several, for example, 8-byte data packets, which all have the same identifier.
  • the sequence counter indicates for which of the data packets a transmission event has been stored in the event memory 13 or which of the data packets has been transmitted successfully.
  • the sequence counter has been entered into the message memory 11 by the application program 5 when the transmission request is issued.
  • the method according to the invention will be explained in more detail below with reference to a flowchart shown in FIG.
  • the method begins in a function block 30.
  • the application program 5 transmits data to be transmitted to a transmission buffer 11.
  • the application program 5 sends a transmission command in function block 32.
  • the communication controller 4 then fetches the data from the transmission buffer 11 in a function block 33.
  • the controller 4 stows the data 9 in a function block 34, the data corresponding to the communication protocol used 7 and brings the data in the appropriate format.
  • the message 7 is transmitted serially via the data bus 2.
  • the message transmission begins with the transmission of an SOF bit.
  • an event may occur which requires a withdrawal of the transmission request, for example the desire to send as soon as possible another message which is more urgent or more important than the message of the current one send request.
  • the occurrence of such an event is illustrated in FIG. 3 by a function block 36.
  • event 36 occurs during serial messaging.
  • the application program 5 resets the current send job.
  • the application program 5 can immediately store new data in a send buffer 11 in a function block 37, namely the data for the more urgent or more important message 7.
  • the application program 5 does not have the end of the transmission of the first message or Wait for the result of the first send job.
  • the status of the first transmission job is stored in the transmission event memory 13 by the communication controller 4 after the end of the transmission of the first message at a later time. This can be done at any time after the end of the transmission of the first message and is exemplified in Figure 3 by a function block 38.
  • a function block 39 the application program 5 sends a send command for the transmission of the further message.
  • the communication controller 4 fetches the new data from the transmission buffer 11 in a function block 40.
  • the controller 4 stows the data 9 in a function block 41 into a second message 7 corresponding to the communication protocol used and brings the data into the appropriate format.
  • the second message 7 is transmitted serially via the data bus 2.
  • the message transmission begins with the sending of a SOF bits.
  • the status of the second send request is stored in the transmission event memory 13 by the communication controller 4 after the end of the transmission of the second message at any later time. This is exemplified by a function block 43 in FIG.
  • the application program fetches the result of the first transmission request from the transmission event memory 13. This is done in the example shown in a function block 44 after completion of the transmission of the second message 7, which has led to the withdrawal of the first send job.
  • the application program 5 initiates in a function block
  • Important aspects of the present invention reside in the fact that the utilization of the host CPU is improved, it is possible to start transmitting a new message in the shortest possible time after a send job has been withdrawn, that more detailed information on the individual send jobs is available, and that the Storing the information about the send jobs in the event memory and the reading out of this information is temporally decoupled, without this leading to a blocking of the host CPU.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Erfindung betrifft einen Teilnehmerknoten (3) eines Kommunikationssystems (1), ein Kommunikationssystem (1) und ein Verfahren zum Übertragen einer Nachricht (7) in dem Kommunikationssystem (1). Die Nachricht (7) wird von einem ersten Teilnehmerknoten (3) des Kommunikationssystems (1) über einen Datenbus (2) des Kommunikationssystems (1) an einen zweiten Teilnehmerknoten (3) des Kommunikationssystems (1) übertragen. Ein Applikationsprogramm (5) des ersten Teilnehmerknotens (3) legt die zu sendende Nachricht (7) in einen Nachrichtenspeicher (11, 12) ab, von wo aus sie auf einen Sendebefehl des Applikationsprogramms (5) hin von einem Kommunikationscontroller (4) geholt und über den Datenbus (2) übertragen wird. Um insbesondere im Fall einer Rücknahme des Sendeauftrags die Auslastung und Effizienz einer Host-CPU verbessern zu können, wird vorgeschlagen, dass ein Sendeereignis für die zu sendende bzw. gesendete Nachricht (7) in mindestens einem von dem Nachrichtenspeicher (11, 12) funktional getrennten Sende-Ereignisspeicher (13) abgespeichert wird und das Applikationsprogramm (5) jederzeit auf die in dem Ereignisspeicher (13) abgespeicherten Informationen zugreifen kann.

Description

TEILNEHMERKNOTEN EINES KOMMUNIKATIONSSYTEMS MIT FUNKTIONAL GETRENNTEM SENDE-EREIGNISSPEICHER
Stand der Technik
Die vorliegende Erfindung betrifft einen Teilnehmerknoten eines Kommunikationssystems. Das Kommunikationssystem umfasst einen Datenbus, an den der Teilnehmerknoten und mindestens ein weiterer Teilnehmerknoten angeschlossen sind. Der Teilnehmerknoten weist einen Kommunikationscontroller zum Senden von Nachrichten über den Datenbus und/oder zum Empfangen von Nachrichten von dem Datenbus und Nachrichtenspeicher zum Zwischenspeichern von zu sendenden bzw. empfangenen Nachrichten auf. Die Erfindung betrifft des weiteren ein Kommunikationssystem umfassend einen Datenbus und meh- rere zum Zwecke der Datenübertragung daran angeschlossene Teilnehmerknoten. Die
Teilnehmerknoten weisen jeweils einen Kommunikationscontroller zum Senden von Nachrichten über den Datenbus und/oder zum Empfangen von Nachrichten von dem Datenbus und Nachrichtenspeicher zum Zwischenspeichern von zu sendenden bzw. empfangenen Nachrichten auf. Schließlich betrifft die vorliegende Erfindung auch ein Verfahren zum Cl- bertragen einer Nachricht von einem ersten Teilnehmerknoten eines Kommunikationssystems über einen Datenbus des Kommunikationssystems an einen zweiten Teilnehmerknoten des Kommunikationssystems. Dabei legt ein Applikationsprogramm des ersten Teilnehmerknotens die zu sendende Nachricht in einen Nachrichtenspeicher ab, von wo aus sie auf einen Sendebefehl des Applikationsprogramms hin von einem Kommunikationscont- roller geholt und über den Datenbus übertragen wird.
Ein Beispiel für ein bekanntes Kommunikationssystem der oben genannten Art ist ein CAN (Controller Area Network)- Kommunikationssystem. Dabei handelt es sich um ein asynchrones, serielles Bussystem, das 1983 von Bosch für die Vernetzung von Steuergeräten in Automobilen entwickelt und 1986 (vgl. SAE Paper 860391, International Congress and Exposition, Detroit, Michigan, Feb. 24-28, 1986) zusammen mit Intel vorgestellt wurde, um die Länge von Kabelbäumen in Kraftfahrzeugen zu reduzieren und dadurch Platz und Gewicht zu sparen. Der Einsatz des CAN-Busses ist allerdings nicht auf den Automobilbereich beschränkt. Der CAN-Bus hat zwischenzeitlich Einzug bspw. in der Gebäudeleittechnik und in Werkzeugmaschinen gehalten. Die Datenübertragung erfolgt in CAN in Datenrahmen (sog. Frames), die neben den zu übertragenden Nutzdaten (der eigentlichen Nachricht) auch Konfigurationsdaten am Anfang (Header- Teil) und Prüfdaten am Ende (CRC-Teil) des
Rahmens aufweisen. Andere Beispiele für ein bekanntes Kommunikationssystem der oben genannten Art ist ein FlexRay-Bus, ein MOST (Media Oriented Systems Transport) -Bus oder ein beliebiger Feldbus, bspw. ein LIN (Local Interconnect Network)-Bus.
In CAN und anderen Protokollen werden Nachrichten zwischen einem ersten und einem zweiten Teilnehmerknoten übertragen, indem ein Applikationsprogramm des ersten Teilnehmerknotens die zu sendende Nachricht in einen Nachrichtenspeicher kopiert, von wo aus sie auf einen Sendebefehl des Applikationsprogramms hin von einem Kommunikationscontroller geholt und über den Datenbus übertragen wird. Dabei besteht häufig die Not- wendigkeit, das Applikations-Programm über das Resultat von Sendeaufträgen und eventuellen Rücknahmen von Sendeaufträgen zu informieren. Dies ist bspw. der Fall, wenn während der Abarbeitung eines Sendeauftrags ein weiterer, eiligerer Sendeauftrag eingeht. In einem solchen Fall wird der anhängige Sendeauftrag zurückgenommen, ein eventuell bereits gestarteter Sendevorgang (Start Of Frame (SOF)-Bit bereits gesendet) wird jedoch nicht abgebrochen, sondern fortgesetzt bis entweder die Arbitration verloren geht, ein Fehler auftritt oder die Nachricht erfolgreich gesendet wurde. Da bei CAN und anderen Protokollen Daten seriell übertragen werden, kann es unter Umständen relativ lange dauern, bis das Ende des Datenrahmens erreicht ist. Während dieser Zeit ist die Recheneinheit (CPU; Central Processing Unit) des Teilnehmerknotens praktisch blockiert, da sie das Ende des Datenrahmens abwarten muss. Dies kann zudem zu einer inakzeptablen Verzögerung in der Abarbeitung des weiteren, eiligeren Sendeauftrags führen.
Erst nachdem das Ende des Datenrahmens des ersten Sendeauftrags erreicht ist, kann sich die CPU dem eiligen Sendeauftrag zuwenden. Dazu kopiert das Applikationsprogramm des Teilnehmerknotens die zu sendende Nachricht des eiligen Sendeauftrags in einen Nachrichtenspeicher, von wo aus sie auf einen Sendebefehl des Applikationsprogramms hin von einem Kommunikationscontroller geholt und über den Datenbus übertragen wird. Nach Erledigung des eiligen Sendeauftrags setzt das Applikationsprogramm wieder die unterbrochene Übertragung fort. Zu diesem Zweck ist es erforderlich, dass dem Applikati- onsprogramm Informationen über den Status des vor dem eiligen Auftrag bearbeiteten
Sendeauftrags zur Verfügung stehen. Das Applikationsprogramm sollte die Möglichkeit ha- ben, sich über das Resultat von Sendeaufträgen und eventuellen Rücknahmen von Sendeaufträgen zu informieren.
Deshalb sind bei den bekannten Teilnehmerknoten die Nachrichtenspeicher, deren Inhalt gesendet werden soll, mit Statusbits verbunden. Oft kann an den Statusbits nur der Erfolg eines Sendeauftrags angezeigt werden. Manche Ergebnisse, besonders im Falle der Rücknahme eines Sendeauftrags (Tx-Cancellation), können anhand der Statusbits nicht dargestellt werden.
Ausgehend von dem beschriebenen Stand der Technik liegt der vorliegenden Erfindung die Aufgabe zu Grunde, einen Teilnehmerknoten dahingehend auszugestalten und weiterzubilden, dass Informationen über Sendeaufträge verwaltet und dem Applikationsprogramm zugänglich gemacht werden können.
Offenbarung der Erfindung
Zur Lösung dieser Aufgabe wird ausgehend von dem Teilnehmerknoten der eingangs genannten Art vorgeschlagen, dass der Teilnehmerknoten mindestens einen von den Nachrichtenspeichern funktional getrennten Sende- Ereignisspeicher aufweist, in dem ein Sende- ereignis für mindestens eine zu sendende bzw. gesendete Nachricht abgespeichert ist.
Erfindungsgemäß werden also die Informationen über die Sendeaufträge nicht in den Nachrichtenspeichern, deren Inhalt gesendet werden soll, abgelegt, sondern in einer gesonderten Liste als Bestandteil eines Sende- Ereignisspeichers. Das hat den Vorteil, dass das Ap- plikationsprogramm die Informationen nicht aus verschiedenen Nachrichtenspeichern zusammensuchen muss, sondern dass die Informationen an einem festen Ort, vorzugsweise zeitlich sortiert abrufbar sind, und dass die Nachrichtenspeicher nach der Rücknahme eines Sendeauftrags sofort wieder zur Verfügung stehen und weiterverwendet werden können, ohne auf das Resultat dieser Rücknahme warten zu müssen. Insbesondere kann sich eine CPU des Teilnehmerknotens nach der Rücknahme eines Sendeauftrags gleich der Abarbeitung des nächsten Sendeauftrags zuwenden und bspw. die Nachricht in dem Nachrichtenspeicher ablegen. Selbstverständlich steht die CPU nach der Rücknahme auch für beliebig andere Tätigkeiten zur Verfügung. Mit der Erfindung kann also die Abarbeitung von aufeinander folgenden Sendeaufträgen im Falle einer Rücknahme eines Sendeauftrags be- schleunigt und die Effizienz der CPU verbessert werden. Die Erfindung hat außerdem den Vorteil, dass die Status- Flags über den Status eines Sendeauftrags nicht an den Nachrichtenspeicher gekoppelt sind. Gemäß einer vorteilhaften Weiterbildung der Erfindung wird vorgeschlagen, dass das Sendeereignis mindestens eines der folgenden Ereignisse umfasst:
Nachricht erfolgreich versendet, - Nachricht erfolgreich versendet, trotz Rücknahme eines Sendeauftrags,
Rücknahme des Sendeauftrags, Sendevorgang noch nicht begonnen, Rücknahme des Sendeauftrags, Sendevorgang nach Verlust der Arbitration beendet, und
Rücknahme des Sendeauftrags, Sendevorgang nach Fehler beendet.
Durch die in dem Sende-Ereignisspeicher abgelegten Sendeereignisse kann das Applikationsprogramm des Teilnehmerknotens also jederzeit den genauen Status bzw. den Ausgang eines vorangegangenen Sendeauftrags abrufen. Es können nicht nur Informationen abgerufen werden, ob die Datenübertragung erfolgreich war, sondern zusätzlich auch noch Informationen darüber, unter welchen Umständen die Übertragung erfolgreich war (ohne oder trotz Rücknahme des Sendeauftrags), und darüber, ob und unter welchen Umständen der Sendeauftrag zurückgenommen wurde (Sendevorgang noch nicht begonnen (bspw. weil der Datenbus besetzt war), Sendevorgang nach Verlust der Arbitration beendet oder Sendevorgang nach Fehler beendet). Diese zusätzlichen Informationen erlauben es dem Applikationsprogramm bei Fortsetzung einer Datenübertragung, deren Sendeauftrag zurückgenommen wurde, geeignete Maßnahmen zu treffen, bspw. einen neuen Sendeauftrag zu erteilen.
Gemäß einer bevorzugten Ausführungsform der Erfindung wird vorgeschlagen, dass in dem Sende-Ereignisspeicher eine Kennung der mindestens einen zu sendenden bzw. gesendeten Nachricht abgespeichert ist. Die Kennung erlaubt vorzugsweise eine eindeutige Identifikation der Nachricht bzw. des Sendeauftrags. Durch die zusätzlich zu dem Sendeereignis für die mindestens eine zu sendende bzw. gesendete Nachricht in dem Sende- Ereignisspeicher abgelegte Kennung ist selbst dann eine eindeutige Zuordnung des Sen- deereignisses zu einer bestimmten Nachricht bzw. einem bestimmten Sendeauftrag möglich, wenn in dem Ereignisspeicher mehrere Sendeereignisse von verschiedenen Sendeaufträgen abgespeichert sind. Das ermöglicht im Rahmen der Speicherkapazität des Ereignisspeichers jederzeit ein Auslesen des Sendeereignisses für eine bestimmte Nachricht bzw. für einen bestimmten Sendeauftrag. Je größer die Kapazität des Ereignisspeichers ist, des- to mehr Sendeereignisse mit dazugehörigen Informationen können abgelegt werden. Selbstverständlich können neben dem Sendeereignis und der Kennung auch weitere Informationen in dem Sende- Ereignisspeicher abgelegt werden. So wird bspw. vorgeschlagen, dass eine oder mehrere der folgenden Informationen in dem Sende-Ereignisspeicher abgespeichert sind: - ein Data- Length- Code der mindestens einen zu sendenden bzw. gesendeten Nachricht, eine Zeitmarke, die angibt, wann das Ereignis eingetreten ist, eine Adresse des Nachrichtenspeichers, für den der Sendeauftrag vorlag, und ein Sequenz-Zähler, der Daten-Pakete identifiziert, wenn größere Datenmengen sequentiell in mehreren Nachrichten mit der gleichen Kennung gesendet werden
Durch die zusätzlichen Informationen wird die Handhabung des gespeicherten Sendeereignisses durch das Applikationsprogramm erleichtert. Eine Zeitmarke kann für bestimmte Applikationsprogramme wichtig sein. Wenn der Teilnehmerknoten über mehrere Sende- Nachrichtenspeicher (sog. Sendebuffer) verfügt, kann anhand der Adresse des Nachrichtenspeichers, für den der Sendeauftrag vorlag, ermittelt werden, welcher Sendebuffer frei für neue Sendeaufträge ist. Ein Sequenz-Zähler kann bspw. bei einem Software- Download wichtig sein, wenn bspw. am Band- Ende oder während eines Werkstattaufenthalts als Steuergeräte ausgebildete Teilnehmerknoten des Kommunikationsnetzwerks erstmals neu oder mit einer neuen Softwareversion programmiert werden. Dabei wird die Software in mehrere zum Beispiel 8 Byte große Datenpakete aufgespalten, welche die gleiche Kennung aufweisen. Der Sequenz-Zähler gibt an, für welches der Datenpakete ein Sendeereignis in dem Ereignisspeicher abgelegt bzw. welches der Datenpakete erfolgreich übermittelt worden ist.
Vorteilhafterweise ist der Sende-Ereignisspeicher als ein FIFO (First In First Out)-Speicher organisiert. Vorzugsweise weist der Sende-Ereignisspeicher mehrere Speicherelemente auf, wobei in jedem Speicherelement Informationen zu einer zu sendenden bzw. gesendeten Nachricht abgespeichert sind. In der Praxis wird in aller Regel eine Kapazität des Ereig- nisspeichers von einigen Speicherelementen genügen. Für den Fall, dass der Sende- Ereignisspeicher überzulaufen droht, weil das Applikationsprogramm ihn zu selten ausliest, kann ein Warnsignal ausgegeben werden. Falls der Speicher tatsächlich überläuft kann ein Fehlersignal ausgegeben werden. Alternativ oder zusätzlich ist es denkbar, dass beim Cl- berschreiten der Kapazität des Sende- Ereignisspeichers einfach die als erstes abgelegten Einträge verworfen werden. Vorteilhafterweise umfasst der Sende-Ereignisspeicher einen Speicher mit wahlfreiem Zugriff (RAM; Random Access Memory). Denkbar ist auch eine Realisierung auf andere Weise, bspw. mittels Flip-Flops, wobei diese jedoch eine relativ große Siliziumfläche benötigen und damit auch relativ hohe Kosten verursachen. Besonders vorteilhaft ist eine Aus- gestaltung der Erfindung, bei der der Sende-Ereignisspeicher als Teil eines Nachrichtenspeichers ausgebildet ist. Trotz funktionaler Trennung von Nachrichtenspeicher und Sende- Ereignisspeicher können beide hardwaremäßig in dem gleichen Speicherelement, jedoch in unterschiedlichen Speicherbereichen ausgebildet sein. Vorteilhafterweise kann die Größe des Sende- Ereignisspeichers, insbesondere die Anzahl der Speicherelemente des Ereig- nisspeichers, softwaremäßig, bspw. mittels Konfigurationsbits, frei konfiguriert werden. Auf diese Weise kann die Größe des Ereignisspeichers auf einfache Weise an die individuellen Anforderungen flexibel angepasst werden.
Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung wird ausgehend von dem Kommunikationssystem der eingangs genannten Art vorgeschlagen, dass mindestens einer der Teilnehmerknoten mindestens einen von den Nachrichtenspeichern funktional getrennten Sende-Ereignisspeicher aufweist, in dem ein Sendeereignis für mindestens eine zu sendende bzw. gesendete Nachricht abgespeichert ist. Gemäß vorteilhafter Weiterbildungen kann der mindestens eine Teilnehmerknoten des erfindungsgemäßen Kommunikati- onssystems zudem Merkmale von einem oder mehreren der Unteransprüche 2 bis 8 aufweisen.
Schließlich wird als noch eine weitere Lösung der Aufgabe der vorliegenden Erfindung ausgehend von dem Verfahren zum Übertragen einer Nachricht der eingangs genannten Art vorgeschlagen, dass ein Sendeereignis für die zu sendende bzw. gesendete Nachricht in einem von dem Nachrichtenspeicher funktional getrennten Sende-Ereignisspeicher abgespeichert wird und das Applikationsprogramm jederzeit auf die in dem Ereignisspeicher abgespeicherten Informationen zugreifen kann.
Vorteilhafte Ausgestaltungen der Erfindung werden nachfolgend anhand der Figuren näher erläutert. Es zeigen:
Figur 1 ein Beispiel für ein erfindungsgemäßes Kommunikationsnetzwerk;
Figur 2 ein Beispiel für einen erfindungsgemäßen Teilnehmerknoten eines Kommunikationsnetzwerks nach Fig. 1; und Figur 3 ein Beispiel für ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens zur Nachrichtenübermittlung über ein Kommunikationsnetzwerk nach Fig. 1.
In Figur 1 ist ein erfindungsgemäßes Kommunikationssystem in seiner Gesamtheit mit dem Bezugszeichen 1 bezeichnet. Das Netzwerk 1 umfasst einen Datenbus 2, der symbolisch durch eine einzige Linie dargestellt ist. Selbstverständlich kann der Datenbus 2 als ein Ein-, Zwei- oder Mehrdrahtbus ausgebildet sein. Die physikalische Schicht des Datenbusses 2 kann eine oder mehrere Kupferleitungen, eine oder mehrere Glasfaserleitungen oder auch optische (z.B. Infrarot) oder Funkverbindungen umfassen. An den Datenbus 2 sind mehrere Teilnehmerknoten 3 angeschlossen, von denen in Figur 1 beispielhaft lediglich drei dargestellt sind. Jeder Knoten 3 ist über ein Kommunikations-Modul 4 (sog. Communication Controller CC) an den Datenbus 2 angeschlossen. Die Knoten 3 verfügen außerdem über eine Host-Applikation 5 (sog. Applikationsprogramm AP).
Über den Datenbus 2 können Nachrichten 7 nach einem seriellen Kommunikationsprotokoll (z.B. CAN, FlexRay, LIN, MOST u.a.) übertragen werden. Das Kommunikations-Modul 4 ist für den Empfang und das Versenden von Nachrichten 7 über den Datenbus 2 zuständig. Die Nachrichten 7 verfügen jeweils über einen sog. Header 8 mit einer Kennung (sog. Iden- tifier) und weiteren Konfigurationsbits. Neben dem Header 8 verfügen die Nachrichten 7 auch über einen Nutzdatenteil 9 (sog. Payload) und einen sog. Trailer 10. Die Kennung ermöglicht eine eindeutige Identifikation der Nachrichten 7. Bei CAN (Controller Area Network) ist die Kennung bspw. eine Art Absender-Adresse, welche die Ermittlung des Ursprungs der Nachricht 7 erlaubt und den Inhalt 9 der Nachricht 7 kennzeichnet.
Logisch zwischen Applikationsprogramm 5 und Kommunikationscontroller 4 sind Sendebuffer 11 (Tx) und Empfangsbuffer 12 (Rx) als Zwischenspeicher für aus- bzw. eingehende Nachrichten 7 angeordnet. Körperlich können die Nachrichtenspeicher 11, 12 integraler Bestandteil des Kommunikationscontrollers 4 oder getrennt von diesem ausgebildet sein. Die Nachrichtenspeicher 11, 12 sind vorzugsweise nach der Art eines FIFOs (First In First Out) aufgebaut. Sie sind bspw. als ein Speicher mit wahlfreiem Zugriff (sog. Random Access Memory; RAM) ausgebildet.
Wenn das Applikationsprogramm 5 einer der Teilnehmer 3 eine Nachricht 7 über den Datenbus 2 an einen anderen Teilnehmer 3 senden möchte, legt es zunächst die zu sendende Nachricht 7 bzw. deren Inhalt 9 in dem Sendebuffer 11 ab (Pfeil 20 in Figur 2). Auf einen
Sendebefehl des Applikationsprogramms 5 hin holt sich der Kommunikationscontroller 4 die Nachricht 7 bzw. deren Inhalt 9 aus dem Sendebuffer 11 (Pfeil 21 in Figur 2), bringt sie ge- maß dem Kommunikationsprotokoll, nach dem in dem Kommunikationssystem 1 Nachrichten 7 übertragen werden, in das richtige Format (z.B. Hinzufügen von Header 8 und Trailer 10) und übermittelt die Nachricht 7 über den Datenbus 2 (Pfeil 22 in Figur 2). Die Übertragung der Nachricht 7 über den Datenbus 2 erfolgt seriell und kann deshalb relativ lange dauern. Die vorliegende Erfindung betrifft den Fall, dass zu einem beliebigen Zeitpunkt während der Abarbeitung des Sendeauftrags dieser wieder zurückgenommen wird (sog. Transmit Cancellation), bspw. weil zunächst ein anderer, besonders eiliger Sendeauftrag abgearbeitet werden soll. Der Sendeauftrag beginnt mit dem Ablegen der Nachricht 7 bzw. deren Inhalt 9 in dem Sendebuffer 11 und endet mit dem Empfang einer Rückmeldung von dem Kommunikationscontroller 4, dass die Nachricht erfolgreich gesendet wurde oder nicht.
In einem solchen Fall und auch in anderen Fällen ist es erforderlich, dass das Applikationsprogramm 5 über das Resultat des Sendeauftrags und eine eventuelle Rücknahme des Sendeauftrags informiert wird. Daher sind im Stand der Technik die Sendebuffer 11 mit Statusbits verbunden, die Informationen liefern können, ob der Sendeauftrag erfolgreich abgewickelt wurde oder nicht. Informationen über weitere Ereignisse, insbesondere im Fall einer Rücknahme des Sendeauftrags, können den Statusbits nicht entnommen werden. Im Falle einer Rücknahme des Sendeauftrags wird im CAN ein eventuell schon gestarteter Sendevorgang (d.h. Start Of Frame (SOF) bereits gesendet) nicht abgebrochen, sondern fortgesetzt bis entweder die Arbitration verloren geht, ein Fehler auftritt oder die Nachricht erfolgreich gesendet wurde. Welches Ereignis letzten Endes nach der Rücknahme des Sendeauftrags eingetreten ist, kann das Applikationsprogramm 5 den Statusbits nicht entnehmen. Zudem muss das Applikationsprogramm 5 auf das Ergebnis des Sendeauftrags warten und ist während dieser Zeit gewissermaßen blockiert. Hier kann die vorliegende Erfindung Verbesserungen bieten.
Erfindungsgemäß wird in den Teilnehmerknoten 3 jeweils ein von den Nachrichtenspeichern 11, 12 funktional getrennter Sende- Ereignisspeicher 13 (Tx Stat) vorgesehen, in dem ein Sendeereignis bzw. ein Status für mindestens eine zu sendende bzw. gesendete Nach- rieht 7 abgespeichert ist. Selbstverständlich müssen nicht alle Teilnehmerknoten 3 des
Kommunikationsnetzwerks 1 mit einem Sende- Ereignisspeicher 13 versehen sein. Der Ereignisspeicher 13 ist vorzugsweise als ein Speicher mit wahlfreiem Zugriff (RAM) ausgebildet und nach Art eines FIFOs organisiert. Selbstverständlich kann der Ereignisspeicher 13 auch als ein Festwertspeicher (z.B. Flash-Speicher, ROM, EEPROM) ausgebildet sein. Der Ereignisspeicher 13 kann als integraler Bestandteil des Kommunikationscontrollers 4 oder getrennt von diesem ausgebildet sein. Außerdem kann der Sende-Ereignisspeicher 13 getrennt von den Nachrichtenspeichern 11, 12 oder als Teil eines Nachrichtenspeichers 11, 12 ausgebildet sein. Wenn der Ereignisspeicher 13 Teil eines Nachrichtenspeichers 11, 12 ist, kann die Größe des Ereignisspeichers 13 softwaremäßig, bspw. mittels Konfigurationsbits, den individuellen Anforderungen entsprechend flexibel definiert werden.
Die Informationen über den Status der Sendeaufträge werden also nicht mehr in einem Nachrichtenspeichern 11, deren Inhalt gesendet werden sollte, abgelegt, sondern in einer gesonderten Sende- Ereignisliste. Diese enthält vorzugsweise einen Eintrag pro Sendeoder Rücknahmeereignis. Mit Hilfe der vorliegenden Erfindung können die Informationen über den Status der Sendeaufträge in dem Kommunikationsmodul 4 verwaltet und in dem Ereignisspeicher 13 abgelegt werden (Pfeil 23 in Figur 2). Das Applikationsprogramm 5 kann die in dem Ereignisspeicher 13 abgelegten Informationen zeitlich flexibel abholen (Pfeil 24 in Figur 2). Besonders vorteilhaft ist, dass die Informationen über die Sendeaufträge nunmehr völlig getrennt sind von dem Sendebuffer 11. Ein weiterer Vorteil besteht darin, dass das Applikationsprogramm 5 die Statusinformationen über die Sendeaufträge nicht mehr aus verschiedenen Nachrichtenspeichern 11 zusammensuchen muss, sondern dass die Informationen an einem festen Ort (in der Sende- Ereignisliste im Sende- Ereignisspeicher 13) vorzugsweise zeitlich sortiert abrufbar sind. Nach der Rücknahme eines Sendeauftrags kann der Nachrichtenspeicher 11 sofort weiter verwendet werden, ohne auf das Resultat des Sendeauftrags bzw. der Rücknahme warten zu müssen. Das Applika- tionsprogramm 5 kann die in dem Ereignisspeicher 13 abgelegten Informationen zu einem späteren Zeitpunkt auslesen, es muss nicht sofort (z.B. per Interrupt) darauf reagieren. Falls der Ereignisspeicher 13 überzulaufen droht, weil das Applikationsprogramm 5 ihn zu selten ausliest, kann in einem ersten Schritt ein Warnsignal ausgegeben werden, das mit entsprechenden Maßnahmen zum beschleunigten oder öfteren Auslesen zumindest eines Teils der Informationen verbunden sein kann. Falls der Speicher 13 tatsächlich überläuft kann ein Fehlersignal ausgegeben werden. In diesem Fall können jeweils die ältesten Einträge in den Sende- Ereignisspeicher 13 verworfen werden, um Platz für die Informationen von aktuellen Sendeaufträgen zu schaffen.
Im einfachsten Fall enthält der Ereignisspeicher 13 zeitlich geordnete Ergebnisse (Nachricht 7 versendet, Rücknahme des Sendeauftrags erfolgt) von Sendeaufträgen. Nachfolgend sind einige Beispiele für weitere Ereignisse aufgeführt, die in dem Ereignisspeicher 13 abgelegt werden können:
1) Nachricht 7 erfolgreich gesendet, 2) Nachricht 7 erfolgreich gesendet, trotz Rücknahme des Sendeauftrags,
3) Sendeauftrag zurückgenommen, Sendevorgang nicht begonnen, 4) Sendeauftrag zurückgenommen, Sendevorgang nach Verlust der Arbitration beendet, und
5) Sendeauftrag zurückgenommen, Sendevorgang nach Fehler beendet.
Zusätzlich zu den Sendeereignissen für die zu sendenden bzw. gesendeten Nachrichten 7 können in dem Sende- Ereignisspeicher 13 auch weitere Informationen abgelegt sein. Für den Informationsgehalt eines Speicherelements des Speichers 13 gibt es verschiedene Ausbaustufen. Vorzugsweise sind in dem Speicher 13 auch Kennungen (z.B. CAN- Identifier) der Nachrichten 7 abgelegt. Die Kennung ermöglicht eine eindeutige Identifikation und Zuordnung der abgelegten Informationen zu bestimmten Nachrichten, so dass die Nachrichten nicht unbedingt in einer zeitlichen Reihenfolge in dem Speicher 13 abgelegt werden müssen. Auch die Aufnahme einer oder mehrerer der folgenden zusätzlichen Informationen in den Sende- Ereignisspeicher 13 ist denkbar:
1) ein Data-Length-Code, welcher die Länge des Nutzdatenteils 9 der mindestens ei- nen zu sendenden bzw. gesendeten Nachricht 7 angibt,
2) eine Zeitmarke, die angibt, wann das in dem Speicher 13 abgelegte Ereignis eingetreten ist,
3) eine Adresse des Nachrichtenspeichers 11, für den der Sendeauftrag vorlag, und
4) ein Sequenz-Zähler, der Daten-Pakete identifiziert, wenn mit Hilfe eines höheren Transport- Protokolls größere Datenmengen sequentiell in mehreren Nachrichten 7 mit der gleichen Kennung gesendet werden
Durch die zusätzlichen Informationen wird die Handhabung des gespeicherten Sendeereignisses durch das Applikationsprogramm 5 erleichtert. Eine Zeitmarke kann für bestimmte Applikationsprogramme 5 wichtig sein. Wenn der Teilnehmerknoten 3 über mehrere Sendebuffer 11 verfügt, kann anhand der Adresse des Nachrichtenspeichers 11, für den der Sendeauftrag vorlag, ermittelt werden, welcher Sendebuffer 11 frei für neue Sendeaufträge ist. Ein Sequenz-Zähler kann bspw. bei einem Software- Download wichtig sein, wenn bspw. am Band- Ende oder während eines Werkstattaufenthalts als Steuergeräte ausgebildete Teilnehmerknoten 3 des Kommunikationsnetzwerks 1 erstmals oder mit einer neuen Softwareversion programmiert werden. Dabei wird die Software in mehrere zum Beispiel 8 Byte große Datenpakete aufgespalten, welche alle die gleiche Kennung aufweisen. Der Sequenz-Zähler gibt an, für welches der Datenpakete ein Sendeereignis in dem Ereignisspeicher 13 abgelegt bzw. welches der Datenpakete erfolgreich übermittelt worden ist. Der Se- quenz-Zähler ist von dem Applikationsprogramm 5 bei Erteilung des Sendeauftrags in den Nachrichtenspeicher 11 eingetragen worden. Nachfolgend wird das erfindungsgemäße Verfahren anhand eines in Figur 3 gezeigten Ablaufdiagramms näher erläutert. Das Verfahren beginnt in einem Funktionsblock 30. In einem Funktionsblock 31 übermittelt das Applikationsprogramm 5 zu übertragende Daten an einen Sendebuffer 11. Das Applikationsprogramm 5 sendet einen Sendebefehl in Funktionsblock 32. Daraufhin holt der Kommunikationscontroller 4 in einem Funktionsblock 33 die Daten aus dem Sendebuffer 11. Anschließend verstaut der Controller 4 in einem Funktionsblock 34 die Daten 9 in eine dem verwendeten Kommunikationsprotokoll entsprechende Nachricht 7 und bringt die Daten in das entsprechende Format. Danach wird in einem Funktionsblock 35 die Nachricht 7 über den Datenbus 2 seriell übertragen. Die Nachrichtenübertra- gung beginnt mit dem Senden eines SOF-Bits.
Zu einem beliebigen Zeitpunkt während der Abarbeitung des Sendeauftrags (Funktionsblöcke 31 bis 35) kann ein Ereignis auftreten, welches eine Rücknahme des Sendeauftrags erforderlich macht, bspw. der Wunsch möglichst bald eine andere Nachricht zu senden, die eiliger oder wichtiger ist als die Nachricht des aktuellen Sendeauftrags. Das Auftreten eines solchen Ereignisses ist in Figur 3 durch einen Funktionsblock 36 veranschaulicht. In dem dargestellten Beispiel tritt das Ereignis 36 während der seriellen Nachrichtenübertragung auf. Das Applikationsprogramm 5 nimmt den aktuellen Sendeauftrag zurück.
Nach der Rücknahme des Sendeauftrags kann das Applikationsprogramm 5 in einem Funktionsblock 37 sofort wieder neue Daten in einem Sendebuffer 11 ablegen, nämlich die Daten für die eiligere bzw. wichtigere Nachricht 7. Das Applikationsprogramm 5 muss nicht das Ende der Übertragung der ersten Nachricht bzw. das Ergebnis des ersten Sendeauftrags abwarten. Dadurch kann die Auslastung und Effizienz einer Host-CPU (Central Pro- cessing Unit) des Teilnehmerknotens 3 verbessert werden. Der Status des ersten Sendeauftrags wird von dem Kommunikationscontroller 4 nach dem Ende der Übertragung der ersten Nachricht zu einem späteren Zeitpunkt in dem Sende- Ereignisspeicher 13 abgelegt. Dies kann zu einem beliebigen Zeitpunkt nach dem Ende der Übertragung der ersten Nachricht erfolgen und ist in Figur 3 beispielhaft durch einen Funktionsblock 38 veranschaulicht.
In einem Funktionsblock 39 sendet das Applikationsprogramm 5 einen Sendebefehl für die Übermittlung der weiteren Nachricht. Daraufhin holt der Kommunikationscontroller 4 in einem Funktionsblock 40 die neuen Daten aus dem Sendebuffer 11. Anschließend verstaut der Controller 4 in einem Funktionsblock 41 die Daten 9 in eine dem verwendeten Kommu- nikationsprotokoll entsprechende zweite Nachricht 7 und bringt die Daten in das entsprechende Format. Danach wird in einem Funktionsblock 42 die zweite Nachricht 7 über den Datenbus 2 seriell übertragen. Die Nachrichtenübertragung beginnt mit dem Senden eines SOF-Bits. Der Status des zweiten Sendeauftrags wird von dem Kommunikationscontroller 4 nach dem Ende der Übertragung der zweiten Nachricht zu einem beliebigen späteren Zeitpunkt in dem Sende-Ereignisspeicher 13 abgelegt. Dies ist in Figur 3 beispielhaft durch einen Funktionsblock 43 veranschaulicht.
Zu einem beliebigen Zeitpunkt nach dem Ende der Übertragung der ersten Nachricht 7 holt das Applikationsprogramm das Ergebnis des ersten Sendeauftrags aus dem Sende- Ereignisspeicher 13 ab. Dies geschieht in dem dargestellten Beispiel in einem Funktionsblock 44 nach Beendigung der Übertragung der zweiten Nachricht 7, die zur Rücknahme des ersten Sendeauftrags geführt hat. In Abhängigkeit von dem eingelesenen Ergebnisses des ersten Sendeauftrags veranlasst das Applikationsprogramm 5 in einem Funktionsblock
45 eine erneute Übertragung der ersten Nachricht 7 (Nachricht nicht erfolgreich gesendet) oder nicht (Nachricht erfolgreich gesendet). Dann ist das Verfahren in einem Funktionsblock
46 beendet.
Wichtige Aspekte der vorliegenden Erfindung sind darin zu sehen, dass die Auslastung der Host-CPU verbessert wird, nach Rücknahme eines Sendeauftrags innerhalb kürzester Zeit mit der Übermittlung einer neuen Nachricht begonnen werden kann, dass detailliertere Informationen zu den einzelnen Sendeaufträgen zur Verfügung stehen und dass das Ablegen der Informationen über die Sendeaufträge in dem Ereignisspeicher und das Auslesen dieser Informationen zeitlich entkoppelt ist, ohne dass es dadurch zu einer Blockierung der Host-CPU kommt.

Claims

Ansprüche
1. Teilnehmerknoten (3) eines Kommunikationssystems (1) umfassend einen Datenbus (2), an den der Teilnehmerknoten (3) und mindestens ein weiterer Teilnehmerknoten (3) angeschlossen sind, wobei der Teilnehmerknoten (3) einen Kommunikationscont- roller (4) zum Senden von Nachrichten (7) über den Datenbus (2) und/oder zum Empfangen von Nachrichten (7) von dem Datenbus (2) und Nachrichtenspeicher (11, 12) zum Zwischenspeichern von zu sendenden bzw. empfangenen Nachrichten (7) aufweist, dadurch gekennzeichnet, dass der Teilnehmerknoten (3) mindestens einen von den Nachrichtenspeichern (11, 12) funktional getrennten Sende- Ereignisspeicher (13) aufweist, in dem ein Sendeereignis für mindestens eine zu sendende bzw. gesendete Nachricht (7) abgespeichert ist.
2. Teilnehmerknoten (3) nach Anspruch 1, dadurch gekennzeichnet, dass das Sendeereignis mindestens eines der folgenden Ereignisse umfasst: - Nachricht (7) erfolgreich versendet,
Nachricht (7) erfolgreich versendet, trotz Rücknahme eines Sendeauftrags, Rücknahme des Sendeauftrags, Sendevorgang noch nicht begonnen, Rücknahme des Sendeauftrags, Sendevorgang nach Verlust der Arbitration beendet, und - Rücknahme des Sendeauftrags, Sendevorgang nach Fehler beendet.
3. Teilnehmerknoten (3) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass in dem Sende-Ereignisspeicher (13) eine Kennung der mindestens einen zu sendenden bzw. gesendeten Nachricht (7) abgespeichert ist.
4. Teilnehmerknoten (3) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass eine oder mehrere der folgenden Informationen in dem Sende-Ereignisspeicher (13) abgespeichert sind: ein Data- Length- Code der mindestens einen zu sendenden bzw. gesendeten Nachricht (7), eine Zeitmarke, die angibt, wann das Ereignis eingetreten ist, eine Adresse des Nachrichtenspeichers (11, 12), für den der Sendeauftrag vorlag, und ein Sequenz-Zähler, der Daten-Pakete identifiziert, wenn größere Datenmengen sequentiell in mehreren Nachrichten (7) mit der gleichen Kennung gesendet werden.
5. Teilnehmerknoten (3) nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der Sende- Ereignisspeicher (13) mehrere Speicherelemente aufweist, wobei in jedem Speicherelement Informationen zu einer zu sendenden bzw. gesendeten Nachricht (7) abgespeichert sind.
6. Teilnehmerknoten (3) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der Sende- Ereignisspeicher (13) einen Speicher mit wahlfreiem Zugriff umfasst.
7. Teilnehmerknoten (3) nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Sende- Ereignisspeicher (13) als Teil eines Nachrichtenspeichers (11, 12) ausgebildet ist.
8. Teilnehmerknoten (3) nach Anspruch 7, dadurch gekennzeichnet, dass die Größe des Sende-Ereignisspeichers (13) mittels Konfigurationsbits konfigurierbar ist.
9. Kommunikationssystem (1) umfassend einen Datenbus (2) und mehrere zum Zwecke der Datenübertragung daran angeschlossene Teilnehmerknoten (3), wobei die Teilnehmerknoten (3) jeweils einen Kommunikationscontroller (4) zum Senden von Nachrichten (7) über den Datenbus (2) und/oder zum Empfangen von Nachrichten (7) von dem Datenbus (2) und Nachrichtenspeicher (11, 12) zum Zwischenspeichern von zu sendenden bzw. empfangenen Nachrichten (7) aufweisen, dadurch gekennzeichnet, dass mindestens einer der Teilnehmerknoten (3) mindestens einen von den Nachrichtenspeichern (11, 12) funktional getrennten Sende- Ereignisspeicher (13) aufweist, in dem ein Sendeereignis für mindestens eine zu sendende bzw. gesendete Nachricht (7) abgespeichert ist.
10. Verfahren zum Übertragen einer Nachricht (7) von einem ersten Teilnehmerknoten (3) eines Kommunikationssystems (1) über einen Datenbus (2) des Kommunikationssystems (1) an einen zweiten Teilnehmerknoten (3) des Kommunikationssystems (1), wobei ein Applikationsprogramm (5) des ersten Teilnehmerknotens (3) die zu sendende Nachricht (7) in einen Nachrichtenspeicher (11, 12) kopiert, von wo aus sie auf einen Sendebefehl des Applikationsprogramms (5) hin von einem Kommunikationscontroller
(4) geholt und über den Datenbus (2) übertragen wird, dadurch gekennzeichnet, dass ein Sendeereignis für die zu sendende bzw. gesendete Nachricht (7) in mindestens ei- nem von dem Nachrichtenspeicher (11, 12) funktional getrennten Sende- Ereignisspeicher (13) abgespeichert wird und das Applikationsprogramm (5) jederzeit darauf zugreifen kann.
PCT/EP2009/052578 2008-05-05 2009-03-05 Teilnehmerknoten eines kommunikationssytems mit funktional getrenntem sende-ereignisspeicher WO2009135707A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
RU2010149264/08A RU2537811C2 (ru) 2008-05-05 2009-03-05 Узел-абонент коммуникационной системы с функционально отдельным устройством памяти событий передачи
EP09741925A EP2294763A1 (de) 2008-05-05 2009-03-05 Teilnehmerknoten eines kommunikationssytems mit funktional getrenntem sende-ereignisspeicher
CN200980116066.4A CN102100037B (zh) 2008-05-05 2009-03-05 通信系统的具有功能分离的发送事件存储器的用户节点
JP2011507848A JP5237438B2 (ja) 2008-05-05 2009-03-05 機能的に区別される送信イベントメモリを備えた通信システムの加入者ノード
US12/736,758 US8732374B2 (en) 2008-05-05 2009-03-05 Subscriber node of a communication system having a functionally separate transmission event memory

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008001548.2 2008-05-05
DE102008001548.2A DE102008001548B4 (de) 2008-05-05 2008-05-05 Teilnehmerknoten eines Kommunikationssystems, Kommunikationssystem und Verfahren zum Übertragen einer Nachricht in dem Kommunikationssystem

Publications (1)

Publication Number Publication Date
WO2009135707A1 true WO2009135707A1 (de) 2009-11-12

Family

ID=40671353

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/052578 WO2009135707A1 (de) 2008-05-05 2009-03-05 Teilnehmerknoten eines kommunikationssytems mit funktional getrenntem sende-ereignisspeicher

Country Status (7)

Country Link
US (1) US8732374B2 (de)
EP (1) EP2294763A1 (de)
JP (1) JP5237438B2 (de)
CN (1) CN102100037B (de)
DE (1) DE102008001548B4 (de)
RU (1) RU2537811C2 (de)
WO (1) WO2009135707A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012080379A (ja) * 2010-10-04 2012-04-19 Renesas Electronics Corp 半導体データ処理装置及びデータ処理システム
NL1039562C2 (nl) * 2012-04-24 2013-10-28 Fusion Electronics B V Werkwijze, aansturing, berichtenontvangstmodule, databerichtformaat en netwerkprotocol voor een agrarisch systeem.
DE102017208836A1 (de) * 2017-05-24 2018-11-29 Wago Verwaltungsgesellschaft Mbh Statussignalausgabe
CN107153412B (zh) * 2017-06-16 2019-09-03 北方电子研究院安徽有限公司 一种具有发送fifo的can总线控制器电路
DE102019205488A1 (de) * 2019-04-16 2020-10-22 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768625A (en) * 1991-03-29 1998-06-16 Mitsubishi Denki Kabushiki Kaisha Vehicle based LAN a communication buffer memory having at least one more number of storage areas for receive status and source address than the number of areas for receive data
EP1085722A2 (de) * 1999-09-15 2001-03-21 Koninklijke Philips Electronics N.V. Behandlung von Nachrichtenende und Interrupt-Erzeugung in einem CAN-Modul, der eine hardwaremässige Zusammenfügung der mehrrahmigen CAN-Nachrichten ermöglicht
US20030187852A1 (en) * 2000-08-31 2003-10-02 Tsuyoshi Abe File transfer system, apparatus, method and computer readable medium storing file transfer program

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2087610B (en) * 1980-10-13 1984-08-08 Multiform Electronics Ltd Communications systems
US4827409A (en) * 1986-07-24 1989-05-02 Digital Equipment Corporation High speed interconnect unit for digital data processing system
JP2559394B2 (ja) * 1987-02-16 1996-12-04 株式会社日立製作所 通信制御装置
JPH04313936A (ja) * 1991-03-29 1992-11-05 Mitsubishi Electric Corp 通信装置
JP2731878B2 (ja) * 1992-02-18 1998-03-25 三菱電機株式会社 通信装置
US5548796A (en) * 1993-11-02 1996-08-20 National Semiconductor Corporation Method of automatic retransmission of frames in a local area network
CA2207791C (en) * 1994-12-13 2000-02-22 Novell, Inc. Method and apparatus to update or change a network directory
US6112268A (en) * 1997-06-16 2000-08-29 Matsushita Electric Industrial Co., Ltd. System for indicating status of a buffer based on a write address of the buffer and generating an abort signal before buffer overflows
US6968405B1 (en) * 1998-07-24 2005-11-22 Aristocrat Leisure Industries Pty Limited Input/Output Interface and device abstraction
JP2000134238A (ja) * 1998-10-27 2000-05-12 Matsushita Electric Ind Co Ltd 通信装置
US6560652B1 (en) * 1998-11-20 2003-05-06 Legerity, Inc. Method and apparatus for accessing variable sized blocks of data
FR2787267B1 (fr) * 1998-12-14 2001-02-16 France Telecom Dispositif et procede de traitement d'une sequence de paquets d'information
US6574770B1 (en) * 2000-06-29 2003-06-03 Lucent Technologies Inc. Error-correcting communication method for transmitting data packets in a network communication system
JP4313936B2 (ja) 2000-08-17 2009-08-12 太平洋セメント株式会社 焼成物の製造方法およびその装置
US6976072B2 (en) * 2001-03-30 2005-12-13 Sharp Laboratories Of America, Inc. Method and apparatus for managing job queues
CN1381982A (zh) * 2001-04-20 2002-11-27 爱达数码科技(杭州)有限公司 一种电话机
US6757776B1 (en) * 2002-07-17 2004-06-29 Cypress Semiconductor Corp. Control transaction handling in a device controller
US20050024664A1 (en) * 2003-07-30 2005-02-03 Schmidt William Randolph Printer formatter with print server
US7243172B2 (en) * 2003-10-14 2007-07-10 Broadcom Corporation Fragment storage for data alignment and merger
JP4536361B2 (ja) * 2003-11-28 2010-09-01 株式会社日立製作所 データ転送装置、記憶デバイス制御装置、記憶デバイス制御装置の制御方法
CN1705295A (zh) 2004-05-29 2005-12-07 华为技术有限公司 具有优先级的包传输系统及其方法
EP1801196A4 (de) 2004-10-06 2011-06-15 Universal Bio Research Co Ltd Reaktionsbehälter und reaktionskontrollvorrichtung
RU2305374C1 (ru) * 2005-12-14 2007-08-27 Ставропольский военный институт связи ракетных войск Способ гибридной коммутации и адаптивной маршрутизации и устройство для его осуществления
WO2007091128A1 (en) * 2006-02-09 2007-08-16 Freescale Semiconductor, Inc. A method for exchanging information with physical layer component registers
WO2008078582A1 (ja) * 2006-12-22 2008-07-03 Canon Kabushiki Kaisha 定着部材、その製造方法、それを用いた定着装置及び電子写真画像形成装置
JP5036406B2 (ja) * 2007-05-30 2012-09-26 エイチジーエスティーネザーランドビーブイ コンテンツデータ管理システム及び方法
US8159709B2 (en) * 2008-03-31 2012-04-17 Konica Minolta Laboratory U.S.A., Inc. Method for canceling a print job submitted to a printer
JP5136610B2 (ja) * 2010-08-06 2013-02-06 ブラザー工業株式会社 端末装置及びコンピュータプログラム
CN102347778B (zh) * 2011-08-05 2014-01-22 中国舰船研究设计中心 一种自适应干扰对消装置及其调试方法
JP5547148B2 (ja) * 2011-09-13 2014-07-09 株式会社東芝 メモリデバイス

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5768625A (en) * 1991-03-29 1998-06-16 Mitsubishi Denki Kabushiki Kaisha Vehicle based LAN a communication buffer memory having at least one more number of storage areas for receive status and source address than the number of areas for receive data
EP1085722A2 (de) * 1999-09-15 2001-03-21 Koninklijke Philips Electronics N.V. Behandlung von Nachrichtenende und Interrupt-Erzeugung in einem CAN-Modul, der eine hardwaremässige Zusammenfügung der mehrrahmigen CAN-Nachrichten ermöglicht
US20030187852A1 (en) * 2000-08-31 2003-10-02 Tsuyoshi Abe File transfer system, apparatus, method and computer readable medium storing file transfer program

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
RU2010149264A (ru) 2012-06-20
US8732374B2 (en) 2014-05-20
DE102008001548A1 (de) 2009-11-12
CN102100037A (zh) 2011-06-15
CN102100037B (zh) 2018-01-09
RU2537811C2 (ru) 2015-01-10
JP5237438B2 (ja) 2013-07-17
EP2294763A1 (de) 2011-03-16
JP2011520368A (ja) 2011-07-14
DE102008001548B4 (de) 2017-03-02
US20110167188A1 (en) 2011-07-07

Similar Documents

Publication Publication Date Title
EP2882145B1 (de) Verfahren und Filteranordnung zum Speichern von Informationen über einen seriellen Datenbus eines Kommunikationsnetzwerks eingehender Nachrichten in einem Teilnehmer des Netzwerks
EP1298849A2 (de) Verfahren und Vorrichtung zur Übertragung von Informationen auf einem Bussystem und Bussystem
DE102011122644B4 (de) Nachrichtenverlustverhinderung unter Verwendung eines Senderpuffers und Verkehrsgestaltung in durch ein Ereignis ausgelösten verteilten eingebetteten Echtzeitsystemen
DE102008001548B4 (de) Teilnehmerknoten eines Kommunikationssystems, Kommunikationssystem und Verfahren zum Übertragen einer Nachricht in dem Kommunikationssystem
EP0903666B1 (de) Verfahren zum Verteilen von Datenpaketen einer Betriebssoftware
DE102011122646B4 (de) Nachrichtenverlustverhinderung durch Verwendung von Sender- und Empfängerpuffern in durch ein Ereignis ausgelösten verteilten eingebetteten Echtzeitsystemen
DE102011015966A1 (de) Automatisierungssystem
WO2007010024A1 (de) Flexray-kommunikationsbaustein, flexray-kommunikationscontroller und verfahren zur botschaftsübertragung zwischen einer flexray-kommunikationsverbindung und einem flexray-teilnehmer
DE60036121T2 (de) Hochgeschwindigkeitsverbindung für eingebettete Systeme in einem Rechnernetzwerk
WO1993005601A1 (de) Verfahren zur datenübertragung und datenverarbeitungsanlage mit verteilten rechnerknoten
DE19935127B4 (de) Verfahren zum Betrieb eines Vermittlungssystems für Datenpakete
EP1642207B1 (de) Zuordnung von stationsadressen zu kommunikationsteilnehmern in einem bussystem
DE10307424A1 (de) Datenvermittlungsvorrichtung und Multiplex-Kommunikationssysteme
DE102019125545B3 (de) Datenübertragungsverfahren, segment-telegramm und automatisierungskommunikationsnetzwerk
EP1892631A2 (de) Verfahren und Vorrichtung zum Einspeisen von Daten in einen seriellen Datenbus
DE19846913A1 (de) Elektronische Steuereinrichtung mit einem parallelen Datenbus und Verfahren zum Betreiben der Steuereinrichtung
EP2130328A1 (de) Verfahren zum transfer von daten in mehrere steuergeräte
DE102019003389A1 (de) Weiterleitungsvorrichtung
DE602004011760T2 (de) Speichervorrichtung für Datenpackete mit beliebiger Länge
DE69725570T2 (de) Paketendeerkennung zum speichern von mehreren paketen in einem sram
DE10260807A1 (de) Sendeverfahren für eine Zeitreferenz über ein Übertragungsmedium und hiermit korrespondierender Zeitgeberblock
WO2012136783A1 (de) Verfahren und vorrichtung zur datenübertragung zwischen verbundenen bussystemen
DE60305090T2 (de) Eingebettetes System mit mehreren Kanälen zum Empfang von Daten
DE102022200501A1 (de) Verfahren zur paketorientierten Datenkommunikation zwischen zwei Recheneinheiten
DE102021201120A1 (de) Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980116066.4

Country of ref document: CN

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

Ref document number: 09741925

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009741925

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011507848

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 7747/CHENP/2010

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2010149264

Country of ref document: RU