DE102008001548B4

DE102008001548B4 - Teilnehmerknoten eines Kommunikationssystems, Kommunikationssystem und Verfahren zum Übertragen einer Nachricht in dem Kommunikationssystem

Info

Publication number: DE102008001548B4
Application number: DE102008001548.2A
Authority: DE
Inventors: Florian Hartwich; Marc Schreier; Franz Bailer; Markus Ihle; Tobias Lorenz; Christian Horst
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2008-05-05
Filing date: 2008-05-05
Publication date: 2017-03-02
Anticipated expiration: 2028-05-06
Also published as: JP5237438B2; JP2011520368A; DE102008001548A1; WO2009135707A1; RU2010149264A; CN102100037A; RU2537811C2; CN102100037B; EP2294763A1; US8732374B2; US20110167188A1

Abstract

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 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 und/oder empfangenen Nachrichten (7) aufweist, wobei 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 und/oder gesendete Nachricht (7) abgespeichert ist, dadurch gekennzeichnet, dass das Sendeereignis eine Rücknahme eines ersten Sendeauftrags anzeigt, wobei die Rücknahme des ersten Sendeauftrags veranlasst wird durch eine Abfrage, einen zweiten Sendeauftrag zu senden, Teilnehmerknoten wartet, bis der zweite Sendeauftrag abgeschlossen ist, bevor er das Sendeereignis bearbeitet, das die Rücknahme des ersten Sendeauftrags anzeigt.

Description

Stand der Technik
Die vorliegende Erfindung betrifft einen Teilnehmerknoten eines Kommunikationssystems, nach dem Oberbegriff des unabhängigen Anspruchs 1. Die Erfindung betrifft des weiteren ein Kommunikationssystem umfassend einen Datenbus nach dem Oberbegriff des unabhängigen Anspruchs 4. Schließlich betrifft die vorliegende Erfindung auch ein Verfahren zum Übertragen einer Nachricht von einem ersten Teilnehmerknoten eines Kommunikationssystems über einen Datenbus des Kommunikationssystems nach dem Oberbegriff des Anspruchs 10.
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 Notwendigkeit, 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 Applikationsprogramm Informationen über den Status des vor dem eiligen Auftrag bearbeiteten Sendeauftrags zur Verfügung stehen. Das Applikationsprogramm sollte die Möglichkeit haben, 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.
Zudem ist aus der US 5,768,625 A der Aufbau eines Kommunikationssystems insbesondere eines Pufferspeichers, bekannt, wobei derselbe eine Vielzahl von Pufferspeicherinformationen aufweist, die gesendet und empfangen werden. Weiterhin werden in einem Statusregister Daten gespeichert, die mit den Daten verbunden sind, die gesendet und gespeichert werden. Ein Übertragungsfehlerspeicher speichert zudem Informationen, die mit dem Sendestatus der Informationen verbunden sind, die übertragen werden, wenn die Speicherinformationen des Puffers übertragen werden, wobei zusätzlich ein Emfangsfehlerspeicher vorhanden ist, der Informationen speichert, die mit dem Emfpangsstatus der Informationen verbunden sind, die empfangen werden, wenn die Pufferspeicherinformationen empfangen werden.
In der US 6,574,770 B1 wird ein Kommunikationssystem beschrieben, das mehrere Teilnehmerknoten aufweist, wobei ein Fehlerübertragungsprotokoll in dem System implementiert ist. Jeder Teilnehmerknoten kann seinen zu übertragenen Verkehr (Datenpakete) in einzelne Abschnitte auftrennen. Ein erster Abschnitt wird demnach solange übertragen, bis die Übertragung als vollständig angezeigt wird und als unvollständig bezeichnet, bis das Signal Übertragung vollständig.
In der GB 2087610 A wird ein Kommunikationssystem gezeigt, das in der Lage ist, verschiedene Status einer großen Anzahl von Dateneingängen zu kontrollieren. Diese Daten werden im Zusammenhang mit Eingabeadressdaten verschlüsselt und über einen Datenbus versendet.
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 weist der erfinderische Teilnehmerknoten der eingangs genannten Art die Merkmale des unabhängigen Anspruchs 1 auf.
Erfindungsgemäß kann also zu einem beliebigen Zeitpunkt während des Abarbeiten eines Sendeauftrags ein Ereignis auftreten, welches die Rücknahme eines Sendeauftrags auslöst. Das hat den Vorteil, dass wichtigere Nachrichten priorisiert versendet werden können. Nach der Rücknahme eines Sendeauftrags steht der Nachrichtenspeicher sofort wieder zur Verfügung und kann weiterverwendet werden, ohne auf das Resultat der 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 beschleunigt 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 Sendeereignisses 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, desto 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 Ereignisspeichers 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 Ü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 Ausgestaltung 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 Ereignisspeichers, 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 ein Kommunikationssytem vorgeschlagen, das die Merkmale des unabhängigen Anspruchs 9 aufweist.
Schließlich weist ein Verfahren zur Lösung der erfinderischen Aufgabe die Merkmale des unabhängigen Anspruchs 10 auf.
Vorteilhafte Ausgestaltungen der Erfindung werden nachfolgend anhand der Figuren näher erläutert. Es zeigen:
1 ein Beispiel für ein erfindungsgemäßes Kommunikationsnetzwerk;
2 ein Beispiel für einen erfindungsgemäßen Teilnehmerknoten eines Kommunikationsnetzwerks nach 1; und
3 ein Beispiel für ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens zur Nachrichtenübermittlung über ein Kommunikationsnetzwerk nach 1.
In 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 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. Identifier) 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 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 2), bringt sie gemäß 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 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 Nachricht 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 Sende- oder 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 2). Das Applikationsprogramm 5 kann die in dem Ereignisspeicher 13 abgelegten Informationen zeitlich flexibel abholen (Pfeil 24 in 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 Applikationsprogramm 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 einen 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 Sequenz-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 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übertragung 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 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 Processing Unit) des Teilnehmerknotens 3 verbessert werden. Der Status des ersten Sendeauftrags wird von dem Kommunikationscontroller 4 nach dem Ende der Übertragung der eiligeren bzw. wichtigeren Nachricht zu einem späteren Zeitpunkt in dem Sende-Ereignisspeicher 13 abgelegt. Dies kann zu einem beliebigen Zeitpunkt nach dem Ende der Übertragung der eiligeren bzw. wichtigeren Nachricht erfolgen und ist in 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 Kommunikationsprotokoll 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 3 beispielhaft durch einen Funktionsblock 43 veranschaulicht.
Zu einem beliebigen Zeitpunkt nach dem Ende der Übertragung der zweiten 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 Ergebnis 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

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 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 und/oder empfangenen Nachrichten (7) aufweist, wobei 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 und/oder gesendete Nachricht (7) abgespeichert ist, dadurch gekennzeichnet, dass das Sendeereignis eine Rücknahme eines ersten Sendeauftrags anzeigt, wobei die Rücknahme des ersten Sendeauftrags veranlasst wird durch eine Abfrage, einen zweiten Sendeauftrag zu senden, Teilnehmerknoten wartet, bis der zweite Sendeauftrag abgeschlossen ist, bevor er das Sendeereignis bearbeitet, das die Rücknahme des ersten Sendeauftrags anzeigt.
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.
Teilnehmerknoten (3) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass in dem Sende-Ereignisspeicher (13) eine Kennung der mindestens einen zu sendenden und/oder gesendeten Nachricht (7) abgespeichert ist.
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 und/oder 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.
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 und/oder gesendeten Nachricht (7) abgespeichert sind.
Teilnehmerknoten (3) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der Sende-Ereignisspeicher (13) einen Speicher mit wahlfreiem Zugriff umfasst.
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.
Teilnehmerknoten (3) nach Anspruch 7, dadurch gekennzeichnet, dass die Größe des Sende-Ereignisspeichers (13) mittels Konfigurationsbits konfigurierbar ist.
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 und/oder empfangenen Nachrichten (7) aufweisen, 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 und/oder gesendete Nachricht (7) abgespeichert ist, dadurch gekennzeichnet, dass das Sendeereignis eine Rücknahme eines ersten Sendeauftrags anzeigt, wobei die Rücknahme des ersten Sendeauftrags veranlasst wird durch eine Abfrage, einen zweiten Sendeauftrag zu senden, und der mindestens eine Teilnehmerknoten wartet, bis der zweite Sendeauftrag abgeschlossen ist, bevor er das Sendeereignis bearbeitet, das die Rücknahme des ersten Sendeauftrags anzeigt.
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, ein Sendeereignis für die zu sendende und/oder gesendete Nachricht (7) in mindestens einem von dem Nachrichtenspeicher (11, 12) funktional getrennten Sende-Ereignisspeicher (13) abgespeichert wird und das Applikationsprogramm (5) jederzeit darauf zugreifen kann, dadurch gekennzeichnet, dass das Sendeereignis eine Rücknahme eines ersten Sendeauftrags anzeigt, wobei die Rücknahme des ersten Sendeauftrags veranlasst wird durch eine Abfrage, einen zweiten Sendeauftrag zu senden, und solange gewartet wird, bis der zweite Sendeauftrag abgeschlossen ist, bevor das Sendeereignis bearbeitet wird, das die Rücknahme des ersten Sendeauftrags anzeigt.