DE102017119062B4

DE102017119062B4 - Computerimplementiertes Verfahren zur Kommunikation zwischen Controllern und Kommunikationssystem

Info

Publication number: DE102017119062B4
Application number: DE102017119062.7A
Authority: DE
Inventors: Keyur R. Patel; Vinod Shankar Naganathan; Travis E. Waineo
Original assignee: Steering Solutions IP Holding Corp
Current assignee: Steering Solutions IP Holding Corp
Priority date: 2016-08-23
Filing date: 2017-08-21
Publication date: 2024-06-06
Anticipated expiration: 2037-08-22
Also published as: US20180063301A1; CN107770019A; US10992790B2; CN107770019B; DE102017119062A1

Abstract

Computerimplementiertes Verfahren zur Kommunikation zwischen Controllern, wobei das Verfahren umfasst, dass:von einem sendenden Controller ein Datentelegramm ohne Kenntnis eines Protokolls erzeugt wird, das eine Musterkennung (210), einen rollierenden Zähler (220), eine Botschaftenkennung (230), eine Signalgruppe (240), eine zyklische Redundanzprüfung (CRC) (250), ein Komplement der Musterkennung (210) und ein Komplement des rollierenden Zählers (220) umfasst;von dem sendenden Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen ersten empfangenden Controller gesendet wird, der ein erstes Kommunikationsprotokoll verwendet; undvon dem sendenden Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen zweiten empfangenden Controller gesendet wird, der ein zweites Kommunikationsprotokoll verwendet.

Description

HINTERGRUND
Diese Anmeldung betrifft allgemein eine Kommunikation zwischen elektronischen Steuerungseinheiten (ECUs) in einem Fahrzeug und insbesondere zwischen einer oder mehreren ECUs, die einem elektrischen Servolenkungssystem (EPS-System) in dem Fahrzeug zugeordnet ist/sind, und anderen ECUs in dem Fahrzeug.
Die zunehmende Verwendung von automatischen Fahrerassistenzsystemen (ADAS) hat dazu geführt, dass ein oder mehrere Controller von verschiedenen Teilsystemen in einem Fahrzeug miteinander kommunizieren. Die Kommunikation ermöglicht beispielsweise, dass die Teilsysteme Informationen gemeinsam nutzen, was wiederum ermöglicht, dass ein Teilsystem automatisch auf Maßnahmen reagieren kann, die von anderen Teilsystemen ergriffen werden.
Außerdem treiben zunehmende Fahrzeugsicherheitsanforderungen die Systemredundanz voran, um höhere Sicherheitsebenen zu erreichen. Redundanz wird durch die Ausdehnung des Steuerungssystems des Fahrzeugs bis hin zu dem Grad erreicht, dass redundante ECUs vorhanden sind. Dies wiederum erfordert ein robustes und ausfallsicheres Kommunikationsverfahren zwischen den zwei ECUs. Eine schlechte Kommunikationskopplung zwischen ECUs weist einen nachteiligen Effekt auf die Leistung des Gesamtsystems auf, was zu einer Gefährdung der Sicherheit führt.
Folglich ist es wünschenswert, über eine robuste Kommunikation zwischen Controllern zu verfügen.
DE 11 2005 000 523 T5 offenbart ein Netzwerkschnittstellensystem zur Verbindung eines Host-Systems mit einem Netzwerk, um dem Netzwerk von dem Host-System abgehende Daten zuzuführen und dem Host-System von dem Netzwerk eingehende Daten zuzuführen. Weiterer Stand der Technik ist aus US 2014 / 0 328 357 A1 bekannt.
ZUSAMMENFASSUNG
Aufgabe der Erfindung ist es, ein verbessertes computerimplementiertes Verfahren zur Kommunikation zwischen Controllern und ein verbessertes Kommunikationssystem bereitzustellen.
Zur Lösung der Aufgabe sind ein Verfahren mit den Merkmalen des Anspruchs 1 und ein Kommunikationssystem mit den Merkmalen des Anspruchs 11 vorgesehen. Vorteilhafte Ausbildungen der Erfindung sind den Unteransprüchen, der Beschreibung und den Zeichnungen zu entnehmen.
Es werden technische Lösungen beschrieben, um zu ermöglichen, dass elektronische Steuerungseinheiten (ECUs) in einem Fahrzeug über eine robuste Kommunikation zwischen Controllern verfügen. Beispielsweise verpackt eine ECU, etwa in einem Lenkungssystem, Daten in einem Datentelegramm ohne Kenntnis eines Protokolls, und überträgt das Datentelegramm ohne Kenntnis eines Protokolls auf mehreren Kommunikationskanälen an eine oder mehrere andere ECUs. Die ECU kann das Datentelegramm ohne Kenntnis eines Protokolls auf eine redundante Weise an eine andere CU übertragen.
Es werden ein oder mehrere Beispiele für ein computerimplementiertes Verfahren zur Kommunikation zwischen Controllern beschrieben. Das Verfahren umfasst, dass von einem sendenden Controller ein Datentelegramm ohne Kenntnis eines Protokolls erzeugt wird, welches eine Musterkennung, einen rollierenden bzw. rollenden Zähler, eine Botschaftenkennung, eine Signalgruppe, eine zyklische Redundanzprüfung (CRC), ein Komplement der Musterkennung und ein Komplement des rollierenden Zählers enthält. Das Verfahren umfasst ferner, dass von dem sendenden Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen ersten empfangenden Controller gesendet wird, der ein erstes Kommunikationsprotokoll verwendet, und dass von dem sendenden Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen zweiten empfangenden Controller gesendet wird, der ein zweites Kommunikationsprotokoll verwendet.
Es werden ein oder mehrere Beispiele für ein Kommunikationssystem beschrieben, das einen ersten Controller enthält, der ein erstes Kommunikationsprotokoll verwendet. Der erste Controller kommuniziert mit mehreren empfangenden Controllern ohne Kenntnis eines Protokolls, indem er ein Datentelegramm ohne Kenntnis eines Protokolls erzeugt, das eine Musterkennung, einen rollierenden Zähler, eine Botschaftenkennung, eine Signalgruppe, eine zyklische Redundanzprüfung (CRC), ein Komplement der Musterkennung und ein Komplement des rollierenden Zählers enthält. Der erste Controller sendet ferner das Datentelegramm ohne Kenntnis eines Protokolls an einen zweiten Controller, der ein zweites Kommunikationsprotokoll verwendet, und er sendet das Datentelegramm ohne Kenntnis eines Protokolls an einen dritten Controller, der ein drittes Kommunikationsprotokoll verwendet.
Ferner wird ein oder werden mehrere Beispiele für ein Computerprogrammprodukt beschrieben, das ein nicht vorübergehendes computerlesbares Medium enthält, welches computerausführbare Anweisungen aufweist. Die computerausführbaren Anweisungen veranlassen Controller in einem Kommunikationssystem dazu, ohne Kenntnis eines Protokolls zu kommunizieren, indem von einem ersten Controller, der ein erstes Kommunikationsprotokoll verwendet, ein Datentelegramm ohne Kenntnis eines Protokolls erzeugt wird, das eine Musterkennung, einen rollierenden Zähler, eine Botschaftenkennung, eine Signalgruppe, eine zyklische Redundanzprüfung (CRC), ein Komplement der Musterkennung und ein Komplement des rollierenden Zählers enthält. Ferner umfasst die Kommunikation, dass von dem ersten Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen zweiten Controller gesendet wird, der ein zweites Kommunikationsprotokoll verwendet, und dass das Datentelegramm ohne Kenntnis eines Protokolls von dem ersten Controller an einen dritten Controller gesendet wird, der ein drittes Kommunikationsprotokoll verwendet.
Diese und andere Vorteile und Merkmale werden aus der folgenden Beschreibung besser offenbar werden, wenn sie in Verbindung mit den Zeichnungen gelesen wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Der Gegenstand, der als die Erfindung betrachtet wird, wird speziell dargelegt und in den Ansprüchen am Ende der Beschreibung separat beansprucht. Die vorstehenden und andere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden genauen Beschreibung, wenn sie in Verbindung mit den beiliegenden Zeichnungen gelesen wird, bei denen:

1 ein Fahrzeug mit einem Lenkungssystem in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht.
2 ein Beispiel für ein Datentelegramm ohne Kenntnis eines Protokolls in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht.
3 ein Beispiel für ein Datentelegramm ohne Kenntnis eines Protokolls in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht.
4 ein beispielhaftes Kommunikationssystem in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht.
5 ein Kommunikationssystem in Übereinstimmung mit einer oder mehreren Ausführungsformen darstellt.
6 ein beispielhaftes Flussdiagramm für ein Verfahren zum Übertragen eines Datentelegramms ohne Kenntnis eines Protokolls in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht.
7 ein beispielhaftes Flussdiagramm für ein Verfahren zum Empfangen eines Datentelegramms ohne Kenntnis eines Protokolls in Übereinstimmung mit einer oder mehreren Ausführungsformen veranschaulicht.

GENAUE BESCHREIBUNG
Die Begriffe „Modul“ und „Teilmodul“ bezeichnen, so wie sie hier verwendet werden, eine oder mehrere Verarbeitungsschaltungen, etwa eine anwendungsspezifische integrierte Schaltung (ASIC), eine elektronische Schaltung, einen Prozessor (gemeinsam genutzt, dediziert, oder Gruppe) mit Speicher, der ein oder mehrere Software- oder Firmwareprogramme ausführt, eine kombinatorische Logikschaltung und/oder andere geeignete Komponenten, welche die beschriebene Funktionalität bereitstellen. Wie festzustellen ist, können die nachstehend beschriebenen Teilmodule kombiniert und/oder weiter unterteilt werden.
Mit Bezug nun auf die Figuren, in denen die Erfindung mit Bezugnahme auf spezielle Ausführungsformen beschrieben wird, ohne sie einzuschränken, ist in 1 eine beispielhafte Ausführungsform eines Fahrzeugs 10 veranschaulicht, das ein Lenkungssystem 12 enthält. In verschiedenen Ausführungsformen umfasst das Lenkungssystem 12 ein Lenkrad 14, das mit einem Lenkwellensystem 16 gekoppelt ist, welches eine Lenksäule, eine Zwischenwelle und die notwendigen Gelenke enthält. In einer beispielhaften Ausführungsform ist das Lenkungssystem 12 ein EPS-System, das ferner eine Lenkungsassistenzeinheit 18 enthält, welche mit dem Lenkwellensystem 16 des Lenkungssystems 12 und mit Spurstangen 20, 22 des Fahrzeugs 10 gekoppelt ist. Alternativ kann die Lenkungsassistenzeinheit 18 den oberen Abschnitt des Lenkwellensystems 16 mit dem unteren Abschnitt dieses Systems koppeln. Die Lenkungsassistenzeinheit 18 enthält beispielsweise einen (nicht gezeigten) Lenkungsmechanismus mit einer Zahnstange und einem Ritzel, der durch das Lenkwellensystem 16 mit einem Lenkungsaktormotor 19 und einem Getriebe gekoppelt sein kann. Im Betrieb stellt der Lenkungsaktormotor 19 dann, wenn ein Fahrzeugbediener das Lenkrad 14 dreht, die Unterstützung zum Bewegen der Spurstangen 20, 22 bereit, wodurch wiederum Lenkungsachsschenkel 24 bzw. 26 bewegt werden, die mit Straßenrädern 28 bzw. 30 des Fahrzeugs 10 gekoppelt sind.
Wie in 1 gezeigt ist, enthält das Fahrzeug 10 ferner verschiedene Sensoren 31, 32, 33, die beobachtbare Bedingungen des Lenkungssystems 12 und/oder des Fahrzeugs 10 detektieren und messen. Die Sensoren 31, 32, 33 erzeugen Sensorsignale auf der Grundlage der beobachtbaren Bedingungen. Bei einem Beispiel ist der Sensor 31 ein Drehmomentsensor, der ein eingegebenes Fahrerlenkraddrehmoment (HWT) erfasst, das von dem Bediener des Fahrzeugs 10 auf das Lenkrad 14 aufgebracht wird. Der Drehmomentsensor erzeugt auf dieser Grundlage ein Fahrerdrehmomentsignal. Bei einem anderen Beispiel ist der Sensor 32 ein Motorwinkel- und Drehzahlsensor, der einen Drehwinkel sowie eine Drehgeschwindigkeit des Lenkungsaktormotors 19 erfasst. Bei noch einem weiteren Beispiel ist der Sensor 32 ein Lenkradpositionssensor, der eine Position des Lenkrads 14 erfasst. Auf dieser Grundlage erzeugt der Sensor 33 ein Lenkradpositionssignal.
Ein Steuerungsmodul 40 empfängt das eine oder die mehreren Sensorsignale, die von den Sensoren 31, 32, 33 eingegeben werden, und es kann andere Eingaben empfangen, etwa ein Fahrzeuggeschwindigkeitssignal 34. Das Steuerungsmodul 40 erzeugt ein Befehlssignal zum Steuern des Lenkungsaktormotors 19 des Lenkungssystems 12 auf der Grundlage einer oder mehrerer der Eingaben und ferner auf der Grundlage der Lenkungssteuerungssysteme und Verfahren der vorliegenden Offenbarung. Die Lenkungssteuerungssysteme und Verfahren der vorliegenden Offenbarung wenden eine Signalaufbereitung an und führen eine Reibungsklassifizierung aus, um ein Oberflächenreibungsniveau 42 als Steuerungssignal zu bestimmen, das zum Steuern von Aspekten des Lenkungssystems 12 durch die Lenkungsassistenzeinheit 18 verwendet werden kann. Das Oberflächenreibungsniveau 42 kann auch als ein Alarm an ein ABS 44 und/oder ein ESC-System 46 gesendet werden, der eine Änderung bei der Oberflächenreibung anzeigt, welche ferner als Schlupf im Zentrum (d.h. bei einem niedrigeren Lenkradwinkel) oder als Schlupf außerhalb des Zentrums (d.h. bei einem höheren Lenkradwinkel) klassifiziert werden kann, wie hier weiter beschrieben wird.
Eine Kommunikation mit dem ABS 44, dem ESC-System 46 und anderen (nicht dargestellten) Systemen kann unter Verwendung beispielsweise eines Controllerbereichsnetzwerks-Busses (CAN-Busses) oder eines anderen Fahrzeugnetzwerks, das in der Technik bekannt ist, durchgeführt werden, um Signale auszutauschen, etwa das Fahrzeuggeschwindigkeitssignal 34. Bei einem oder mehreren Beispielen treiben Hardwarebegrenzungen und die Unterschiedlichkeit von Kommunikationskanälen Kommunikationskopplungen zwischen Mikrocontrollern zur Verwendung unterschiedlicher Protokolle voran, unter anderem beispielsweise CAN, serielle Kommunikationsschnittstelle (SCI), Multiprozessorkopplungsschnittstelle (MLI). Jedes Protokoll kann einen Teil der Sicherheitsaspekte der Datenbehandlung erfüllen, aber keines stellt inhärent sicher, dass alle Sicherheitsaspekte abgedeckt werden.
Das Steuerungsmodul 40 kann eine ECU sein. Das Fahrzeug 10 enthält zusätzliche ECUs. Das Steuerungsmodul 40 empfängt Informationen von den anderen ECUs, etwa das Fahrzeuggeschwindigkeitssignal 34, die Sensorinformationen und verschiedene andere Informationen. Wie zuvor beschrieben wurde, gibt es mehrere Kommunikationsverfahren, die zur Kommunikation zwischen Mikrocontrollern entworfen sind, unter anderem etwa die Protokolle SCI, CAN und MLI. Jedes Protokoll kann einen Teil der Sicherheitsaspekte der Datenbehandlung erfüllen, aber keines stellt inhärent sicher, dass alle Sicherheitsaspekte abgedeckt werden.
Sicherheitsaspekte der Datenbehandlung für eine Kommunikation zwischen Mikrocontrollern umfassen das Detektieren von veralteten Daten, beispielsweise eines alten Datentelegramms, das nach einer Verzögerung empfangen wird. Sicherheitsaspekte umfassen ferner das Detektieren, dass die Kommunikationen Daten verloren haben, zum Beispiel aufgrund eines verlorenen Datentelegramms. Ferner umfassen die Sicherheitsaspekte das Detektieren von irrelevanten Daten, zum Beispiel das zweifache (oder mehrfache) Empfangen des gleichen Datentelegramms. Die Sicherheitsaspekte umfassen ferner das Detektieren eines Datenintegritätsverlusts, zum Beispiel eines während der Übertragung gekippten Bits. Die Sicherheitsaspekte umfassen ferner das Detektieren eines Datenkonsistenzverlusts, zum Beispiel durch Detektieren deutlicher Start- und Stoppindikatoren für ein Datentelegramm. Noch weiter umfassen die Sicherheitsaspekte das Detektieren einer Kommunikation mit unvollständigen Daten, beispielsweise aufgrund eines verlorenen Signals, oder einer verlorenen Übertragungseinheit oder eines verlorenen Datentelegramms. Sicherheitsaspekte umfassen ferner das Detektieren eines Vertauschens von Daten, das durch ein vertauschtes Signal verursacht wird. Daher existiert für den Controller 40 die technische Herausforderung, dass er mit anderen Controllern im Fahrzeug 10 unter Verwendung einer Kommunikation zwischen Controllern kommunizieren soll, welche zumindest das Implementieren der vorstehenden Sicherheitsaspekte ermöglicht.
Ferner gibt es kein standardisiertes Datenbehandlungsverfahren, das mit allen Protokollen arbeitet. Typischerweise veranlassen Hardwarebegrenzungen und die Unterschiedlichkeit von Kommunikationskanälen, dass eine Kommunikationskopplung zwischen Mikrocontrollern mindestens zwei verschiedene Protokolle verwendet. Beispielsweise verwendet ein erster Controller, sagen wir der Controller 40 der EPS 12, ein CAN-Kommunikationsprotokoll mit einem ersten Typ von Paketstruktur, während ein zweiter Controller, sagen wir derjenige des ABS 44, das CAN-Protokoll mit einem zweiten Typ von Paketstruktur verwendet. Alternativ können die Controller unterschiedliche Paketstrukturen mit einem unterlegten SCI-Protokoll auf der physikalischen Schicht verwenden. Jedes Protokoll, sowohl das CAN als auch das SCI, verfügt über eingebaute Sicherheitsaspekte, aber ein Implementieren der Sicherheitsaspekte, etwa derjenigen, die vorstehend beschrieben sind, stellt eine technische Herausforderung dar, wenn die Kommunikation zwischen Mikrocontrollern wie in diesem Fall das Übersetzen zwischen mehreren Typen der Protokolle, die von den Controllern verwendet werden, umfasst. Es sei erwähnt, dass in anderen Beispielen die Controller in der Kommunikation zwischen Mikrocontrollern und die Protokolle, die von den Controllern verwendet werden, sich von denjenigen in dem vorstehenden Beispiel unterscheiden können.
Noch weiter sei erwähnt, dass das vorstehende Beispiel zwar die zwei Controller von separaten Teilmodulen des Fahrzeugs aufweist, jedoch bei einem oder mehreren Beispielen die zwei Controller Teil des gleichen Steuerungsmoduls sein können, zum Beispiel des Steuerungsmoduls 40 des EPS 12. Die zwei Controller in dem gleichen Steuerungsmodul 40 ermöglichen eine Redundanz für das Steuerungsmodul 40, so dass dann, wenn der erste Controller ausfällt, der zweite Controller den Betrieb übernimmt oder umgekehrt.
Die hier beschriebenen technischen Lösungen sprechen zumindest die zuvor beschriebenen technischen Herausforderungen in der Kommunikation zwischen Mikrocontrollern an. Die hier beschriebenen technischen Lösungen ermöglichen ein Standardverfahren zur Datenbehandlung, welches alle vorbestimmten Sicherheitsaspekte für die Kommunikation zwischen Mikrocontrollern abdeckt und ferner die Verwendung mehrerer Protokolle gleichzeitig ermöglicht. Ferner sind die hier beschriebenen technischen Lösungen robust gegen einen Ausfall eines oder mehrerer Kommunikationskanäle. Zudem ermöglichen die hier beschriebenen technischen Lösungen, dass eine Latenz für eine Bewertung zur Laufzeit zwischen Kanälen unter einem vorbestimmten Schwellenwert bleibt. Ferner ermöglichen die hier beschriebenen technischen Lösungen dass die Kommunikation auf der Grundlage einer „Ersetzung von Botschaften“ bewertet wird. Wenn beispielsweise eine Integritätsprüfung auf einem Kanal fehlschlägt, wird diese Botschaft von einem zweiten Kanal beschafft, der eine andere Implementierung des Protokolls verwenden kann.
2 veranschaulicht ein Datentelegramm für die Kommunikation zwischen Mikrocontrollern in Übereinstimmung mit einer oder mehreren Ausführungsformen. 3 veranschaulicht ein beispielhaftes Datentelegramm, das in Übereinstimmung mit dem exemplarischen Datentelegramm, welches in 2 veranschaulicht ist, erzeugt wurde. Indem sie dem Kommunikationsprotokoll unter Verwendung des Datentelegramms von 2 folgen, ermöglichen die technischen Lösungen das Erkennen von Kommunikationsproblemen, etwa veralteten Daten - ein altes Datentelegramm; verlorenen Daten - ein verlorenes Datentelegramm; irrelevanten Daten - ein nicht erwartetes Datentelegramm; Datenintegrität - ein gekipptes Bit; Datenkonsistenz - klarer Start und Stopp eines Datentelegramms; unvollständigen Daten - ein verlorenes Signal; Vertauschen von Daten - ein vertauschtes Signal. Informationen, die in Übereinstimmung mit einem derartigen Telegramm übertragen werden, können über mehrere Protokolle hinweg übertragen werden. Ferner ermöglicht die Verwendung derartiger Telegramme, dass die Kommunikation auf der Grundlage einer „Ersetzung von Botschaften“ bewertet wird. Es soll erwähnt werden, dass die Beispiele hier den Controller 40 des EPS 12 des Fahrzeugs 10 zum Implementieren der hier beschriebenen technischen Lösungen verwenden, dass in anderen Beispielen stattdessen jedoch andere Controller in dem Fahrzeug 10 verwendet werden können.
Während der Kommunikation zwischen Mikrocontrollern erzeugt der Controller 40 ein Datentelegramm 200 in Übereinstimmung mit dem Format, das in 2 dargestellt ist. Das Datentelegramm 200 enthält eine Musterkennung 210. Die Musterkennung 210 beschreibt einen Start des Datentelegramms 200 zum Synchronisieren von Daten bei asynchronen Kommunikationsprotokollen, wie etwa SCI. Bei asynchronen Kommunikationsprotokollen wird die Musterkennung 210 übergangen. Bei einem oder mehreren Beispielen, wie in 3 gezeigt ist, ist die Musterkennung 210 ein Wert mit 3 Bit (z.B. 101).
Das Datentelegramm 200 enthält ferner einen rollierenden Zähler 220, der verwendet wird, um auf neue Daten hin zu überwachen. Der empfangende Controller verwendet den rollierenden Zähler 220, um unter Verwendung eines Algorithmus/Moduls mit einem rollierenden Zähler festzustellen, ob das empfangene Datentelegramm neue Daten sind. Wenn der rollierende Zähler 220 beispielsweise aktualisiert worden ist, sind die Daten neu. Wenn der rollierende Zähler 220 den gleichen Wert enthält, sind die Daten alt. Wie in 3 gezeigt ist, ist der rollierende Zähler 220 bei einem oder mehreren Beispielen ein Wert mit 5 Bit. Zur Verwendung des rollierenden Zählers 220 bewegen sich sowohl der sendende als auch der empfangende Controller in den Zählersequenzen vorwärts. Der Sendercontroller und der Empfängercontroller führen Werte der jeweiligen rollierenden Zähler mit. Wenn der Sender zuvor den n-ten Zählerwert gesendet hat, dann sendet er als Nächstes den (n+1)-ten Wert. Wenn der Empfänger hingegen den n-ten Code wahrgenommen hat, akzeptiert er nur den (n+1)-ten Code oder irgendeinen späteren Wert des rollierenden Zählers. Wenn der empfangene Wert des rollierenden Zählers kleiner oder gleich dem n-ten Code ist, den der Empfänger bereits wahrgenommen hat, erkennt der Empfänger das Datentelegramm 200 als Duplikat und er ignoriert das Datentelegramm 200. Es sei erwähnt, dass das Vorstehende nur ein Beispiel zum Verwenden des rollierenden Zählers 220 für das Feststellen ist, ob die empfangenen Daten veraltet sind, und dass in anderen Beispielen andere Algorithmen verwendet werden können.
Das Datentelegramm 200 enthält ferner eine Botschaftenkennung 230. Die Botschaftenkennung 230 ist eine Kennung für die Signalgruppe 240.
Das Datentelegramm 200 enthält die Signalgruppe 240, welche ein oder mehrere Signale enthält, welche beispielsweise Datenbytes 0-n enthalten. Die Datenbytes enthalten Informationen, die von einem Controller an einen anderen weiter übertragen werden. Typischerweise beruht die Anzahl der Daten auf einer maximalen Anzahl von Signalen, auf welche ein Kommunikationsprotokoll eine Botschaft begrenzt. Das hier bereitgestellte Datentelegramm 200 ist flexibel, um eine beliebige Anzahl von Signalen in der Signalgruppe zu behandeln, und es kann folglich über mehrere Protokolle hinweg verwendet werden, die unterschiedliche Begrenzungen für die Anzahl von Signalen aufweisen. Der empfangende Controller verpackt das Datentelegramm 200 nach dem Empfangen in Übereinstimmung mit einem Protokoll, das von dem empfangenden Controller verwendet wird, neu und führt anschließend die Integritätsprüfungen an der neu verpackten Botschaft aus. Dies ermöglicht ferner, dass das Format des Datentelegramms 200 für mehrere Protokolle angewendet werden kann. Wie in 3 gezeigt ist, sind die Signale jeweils 8 Bit lang und die Nutzlast der Signalgruppe 240 enthält vier Signale, d.h. in diesem Beispiel jeweils 4 Bytes. Es versteht sich, dass in anderen Beispielen die Größen der Signale anders sind und auch, dass die Anzahl der Signale in der Signalgruppe 240 eine andere ist.
Bei einem oder mehreren Beispielen identifiziert die Botschaftenkennung 230 eine Trennung von Signalen in der Signalgruppe 240. Zum Beispiel zeigt die Botschaftenkennung eine oder mehrere Bit/Byte-Positionen in der Signalgruppe 240 an, an denen ein Signal startet und/oder endet. Wenn beispielsweise in der Darstellung von 3 jedes Datenbyte ein separates Signal ist, zeigt die Botschaftenkennung 230 an, dass die Signalgruppe 240 n Signale enthält, mit einem ersten Signal bei Bit 0, einem zweiten Signal bei Bit 8, einem dritten Signal bei Bit 16, und so weiter für jedes der n Signale. Bei einem oder mehreren Beispielen zeigt die Botschaftenkennung die einzelnen Signale in der Signalgruppe 240 an, indem sie Positionen und Größen der Signale in der Signalgruppe 240 bereitstellt.
Das Datentelegramm 200 enthält ferner einen Wert einer zyklischen Redundanzprüfung (CRC-Wert) 250. Bei einem oder mehreren Beispielen wird die CRC auf der Grundlage der Botschaftenkennung 230 und der Signale in der Signalgruppe 240 berechnet. Dadurch, dass diese CRC 250 auf diesen Werten beruht, wird die Integrität der Informationen, die übertragen werden, unabhängig von den Protokollen sichergestellt, die von den Sende- und Empfangsprotokollen verwendet werden. Die Musterkennung 210 und der rollierende Sender 220 werden durch Vergleichen mit den entsprechenden Komplementwerten 260 und 270 geschützt, und sind daher nicht in dem CRC-Feld 250 enthalten. Da die CRC 250 für die Signalgruppe 240 vorgesehen ist, deren Größe sich von einem Datentelegramm zum Nächsten verändern kann, beruht die CRC 250 auf der Größe der Signalgruppe 240. Das in 3 gezeigte beispielhafte Datentelegramm verwendet einen CRC-Wert mit 8 Bit, jedoch kann die CRC 250 in anderen Beispielen eine andere Anzahl von Bits enthalten.
Das Datentelegramm 200 enthält ferner ein Komplement (CMPL) 260 der Musterkennung und ein Komplement 270 des rollierenden Zählers. Das Komplement 260 der Musterkennung und das Komplement 270 des rollierenden Zählers werden verwendet, um das Ende des Datentelegramms 200 zu identifizieren und außerdem, um den Datenempfang zu prüfen. Wenn der Start des Datentelegramms 200 (Musterkennung 210 und der rollierende Zähler 220) und die entsprechenden Komplemente 260 - 270, wenn sie miteinander durch XOR verknüpft werden, alle Eins ergeben, dann wurde das vollständige Datentelegramm 200 aufgefangen und kann zur Prüfung des rollierenden Zählers und der CRC weitergeleitet werden. Andernfalls ist beim Empfangen des Datentelegramms 200 ein Fehler aufgetreten. In dem Beispiel von 3 ist das Komplement 260 der Musterkennung 3 Bit lang und das Komplement 270 des rollierenden Zählers ist 5 Bit lang, jedoch kann in anderen Beispielen ein beliebiges der Felder oder können beide Felder eine andere Anzahl von Bits enthalten.
Indem folglich das Datentelegramm 200 wie hier beschrieben erzeugt wird, implementiert eine Kommunikation zwischen Mikrocontrollern in dem Fahrzeug 10 die Sicherheitsaspekte dadurch, dass sie protokollunabhängig/ohne Kenntnis eines Protokolls ist. Die Musterkennung 210 und der rollierende Zähler 220 und die entsprechenden Komplementwerte 260 - 270 detektieren Datenkonsistenzprobleme während einer Übermittlung der Datentelegramme. Der rollierende Zähler 220 detektiert Probleme mit veralteten, verlorenen und irrelevanten Daten. Die CRC 250 detektiert Probleme mit unvollständigen Daten, Vertauschen von Daten und Datenintegrität. Da das Datentelegramm 200 wie hier beschrieben mehrere Datenbytes aufweisen kann, ohne eine Begrenzung bei der Größe der Daten, ermöglicht das Datentelegramm 200 ferner eine Kompatibilität mit mehreren Protokollen.
4 veranschaulicht ein beispielhaftes Kommunikationssystem 400 in einem Fahrzeug. Das System 400 enthält den Controller 40 oder ein beliebiges anderes Gerät, das über ein fahrzeuginternes Netzwerk 465 kommuniziert, etwa unter Verwendung der Protokolle CAN, SCI, MLI. Das System 400 enthält Hardware, etwa elektronische Schaltkreise.
Neben anderen Komponenten enthält das System 400 einen Prozessor 405, einen Arbeitsspeicher 410, der mit einem Speichercontroller 415 gekoppelt ist, und ein oder mehrere Eingabegeräte 445 und/oder Ausgabegeräte 440, etwa Peripheriegeräte oder Steuerungsgeräte, die über einen lokalen Eingabe/Ausgabe-Controller 435 kommunikationstechnisch gekoppelt sind. Diese Geräte 440 und 445 können beispielsweise Batteriesensoren, Positionssensoren (Höhenmesser, Beschleunigungsmesser, GPS), Anzeige/Identifikationsleuchten und dergleichen umfassen. Eingabegeräte wie eine herkömmliche Tastatur 450 und eine Maus 455 können mit dem Eingabe/Ausgabe-Controller 435 gekoppelt sein. Der Eingabe/Ausgabe-Controller 435 kann beispielsweise ein oder mehrere Busse oder andere drahtgebundene oder drahtlose Verbindungen sein, wie in der Technik bekannt ist. Der Eingabe/Ausgabe-Controller 435 kann zusätzliche Elemente aufweisen, die der Einfachheit halber weggelassen wurden, etwa Controller, Puffer (Caches), Treiber, Repeater und Empfänger, um Kommunikationen zu aktivieren.
Die Eingabe/Ausgabe-Geräte 440, 445 können ferner Geräte umfassen, die sowohl Eingaben als auch Ausgaben übermitteln, zum Beispiel einen Plattenmassenspeicher, eine Netzwerkschnittstellenkarte (NIC) oder einen Modulator/Demodulator (zum Zugreifen auf andere Dateien, Geräte, Systeme oder ein Netzwerk), einen Funkfrequenz-(RF)- oder anderen Sender/Empfänger, eine Telefonieschnittstelle, eine Bridge, einen Router und dergleichen.
Der Prozessor 405 ist ein Hardwaregerät zum Ausführen von Hardwareanweisungen oder von Software, speziell von denjenigen, die im Arbeitsspeicher 410 gespeichert sind. Der Prozessor 405 kann ein kundenspezifischer oder käuflich verfügbarer Prozessor, eine zentrale Verarbeitungseinheit (CPU), ein Zusatzprozessor unter mehreren Prozessoren, die dem System 400 zugeordnet sind, ein Halbleiter-Mikroprozessor (in der Form eines Mikrochips oder eines Chipsatzes), ein Makroprozessor oder ein anderes Gerät zum Ausführen von Anweisungen sein. Der Prozessor 405 enthält einen Cache 470, welcher einen Anweisungscache zum Beschleunigen des Holens von ausführbaren Anweisungen, einen Datencache zum Beschleunigen des Holens und Speicherns von Daten, und einen Translation Lookaside Buffer (TLB), der verwendet wird, um die Übersetzung von virtuellen Adressen in physikalische Adressen für sowohl ausführbare Anweisungen als auch Daten verwendet wird, enthalten kann, aber nicht darauf beschränkt ist. Der Cache 470 kann in einer Hierarchie mit mehreren Cacheebenen (L1, L2 und so weiter) organisiert sein.
Der Arbeitsspeicher 410 kann ein oder Kombinationen aus flüchtigen Speicherelementen (zum Beispiel Speicher mit wahlfreiem Zugriff, RAM, etwa DRAM, SRAM, SDRAM) und nichtflüchtigen Speicherelementen enthalten (zum Beispiel ROM, löschbaren, programmierbaren Festwertspeicher (EPROM), elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM), programmierbaren Festwertspeicher (PROM), Magnetband, Kompaktdisk-Festwertspeicher (CD-ROM), Disketten, Platten, Steckmodule, Kassetten oder dergleichen). Darüber hinaus kann der Arbeitsspeicher 410 elektronische, magnetische, optische oder andere Typen von Massenspeichermedien enthalten. Es sei erwähnt, dass der Arbeitsspeicher 410 eine verteilte Architektur aufweisen kann, bei der verschiedene Komponenten voneinander entfernt angeordnet sind aber für den Prozessor 405 zugänglich sein können.
Die Anweisungen im Arbeitsspeicher 410 können ein oder mehrere separate Programme umfassen, die jeweils eine geordnete Auflistung von ausführbaren Anweisungen zum Implementieren von logischen Funktionen umfassen. In dem Beispiel von 4 enthalten die Anweisungen in dem Arbeitsspeicher 410 ein geeignetes Betriebssystem (OS) 411. Das Betriebssystem 411 kann im Wesentlichen die Ausführung von anderen Computerprogrammen steuern und stellt Planungs-, Eingabe-/Ausgabe-Steuerungs-, Datei- und Daten-Verwaltungs-, Speicherverwaltungs-, und Kommunikationssteuerung- und ähnliche Dienste bereit. Bei einem oder mehreren Beispielen ist das OS 411 ein Echtzeitbetriebssystem (RTOS).
Zusätzliche Daten, die beispielsweise Anweisungen für den Prozessor 405 oder andere beschaffbare Informationen umfassen, können in einem Massenspeicher 420 gespeichert sein, welcher ein Massenspeichergerät sein kann, etwa ein Festplattenlaufwerk oder ein Solid State-Laufwerk (SSD). Die im Arbeitsspeicher 410 oder im Massenspeicher 420 gespeicherten Anweisungen können diejenigen umfassen, die ermöglichen, dass der Prozessor ein oder mehrere Aspekte der hier beschriebenen Systeme und Verfahren ausführen kann.
Das System 400 kann ferner einen Anzeigecontroller 425 enthalten, der mit einer Nutzerschnittstelle oder einer Anzeige 430 gekoppelt ist. In einigen Ausführungsformen kann die Anzeige 430 ein LCD-Bildschirm sein. In anderen Ausführungsformen kann die Anzeige 430 eine Vielzahl von LED-Statusleuchten enthalten. In einigen Ausführungsformen kann das System 400 ferner eine Netzwerkschnittstelle 460 zur Kopplung mit einem Netzwerk 465 enthalten. Das Netzwerk 465 kann ein IP-basiertes Netzwerk zur Kommunikation zwischen dem System 400 und einem externen Server, Client und dergleichen über eine Breitbandverbindung sein. In einer Ausführungsform kann das Netzwerk 465 ein Satellitennetzwerk sein. Das Netzwerk 465 überträgt und empfängt Daten zwischen dem System 400 und externen Systemen. In einigen Ausführungsformen kann das Netzwerk 465 ein gemanagtes IP-Netzwerk sein, das von einem Dienstleister verwaltet wird. Das Netzwerk 465 kann auf drahtlose Weise implementiert sein, zum Beispiel unter Verwendung drahtloser Protokolle und Technologien, etwa WiFi, WiMax, Satellit oder beliebige andere. Das Netzwerk 465 kann auch ein Netzwerk mit Paketumschaltung sein, etwa ein lokales Netzwerk, ein Weitbereichsnetzwerk, ein Metropol-Netzwerk, das Internet oder eine andere ähnliche Art von Netzwerkumgebung. Das Netzwerk 465 kann ein feststehendes drahtloses Netzwerk sein, ein drahtloses lokales Netzwerk (LAN), ein drahtloses Weitbereichsnetzwerk (WAN), ein persönliches Netzwerk (PAN), ein virtuelles privates Netzwerk (VPN), ein fahrzeuginternes Netzwerk, ein Intranet oder ein anderes geeignetes Netzwerksystem und es kann Ausrüstung zum Empfangen und Übertragen von Signalen enthalten. Das Netzwerk kann ein oder mehrere Protokolle verwenden, etwa CAN, SCI, MLI und dergleichen.
5 stellt ein Kommunikationssystem in Übereinstimmung mit einer oder mehreren Ausführungsformen dar. Das Kommunikationssystem 500 zeigt zwei Controller, einen ersten Controller 510 und einen zweiten Controller 520, die miteinander kommunizieren, etwa in einer Umgebung in einem Fahrzeug. Beispielsweise kann der erste Controller 510 der Controller 40 eines Lenkungssystems sein, und der zweite Controller 520 kann der Controller des ABS-Moduls 44 des Fahrzeugs 10 sein. Bei einem oder mehreren Beispielen können die Controller 510 - 520 Komponenten enthalten, die denjenigen des Systems 400 ähneln. Zum Beispiel enthalten die Controller jeweilige Netzwerkschnittstellen 512 und 522. Alternativ oder zusätzlich sind der erste Controller 510 und der zweite Controller 520 beide Teil des Steuerungsmoduls 40 des EPS 12 (oder eines beliebigen anderen Fahrzeugteilsystems) und die Kommunikation zwischen den zwei Controllern dient dazu, zu ermöglichen, dass das Steuerungsmodul 40 eine Redundanz für den Fall bereitstellt, dass einer der zwei Controller 510 - 520 einen Fehler aufweist.
Der erste Controller 510 sendet eine Botschaft 530 über die Netzwerkschnittstellen 512 und 522 an den zweiten Controller 520. Der erste Controller 510 verwendet eine erste Protokollimplementierung, die sich von einer zweiten Protokollimplementierung unterscheidet, die von dem zweiten Controller 520 genutzt wird, zum Beispiel aufgrund von Hardwarebeschränkungen. Entsprechend erzeugt der erste Controller 510 eine erste Botschaft unter Verwendung des ersten Protokolls. Die erste Netzwerkschnittstelle 512 verpackt die erste Botschaft neu unter Verwendung des Datentelegramms 200 ohne Kenntnis eines Protokolls, um die Botschaft 530 zu erzeugen. Die erste Netzwerkschnittstelle überträgt die Botschaft ohne Kenntnis eines Protokolls in Übereinstimmung mit dem Datentelegramm 200 an den zweiten Controller 520.
Nach Empfang der Botschaft 530 prüft die zweite Netzwerkschnittstelle 522 die Inhalte unter Verwendung der Paketkennung 210 und des rollierenden Zählers 220 (unter Verwendung der jeweiligen Komplemente). Beispielsweise kann der empfangende Controller 520 veraltete Daten mit dem rollierenden Zähler 220 auf der Grundlage eines Validierungsalgorithmus für den rollierenden Zähler detektieren. Der Algorithmus prüft beispielsweise, ob der rollierende Zähler 220 einen Wert wiederholt. Alternativ oder zusätzlich kann der empfangende Controller 520 verlorene Daten detektieren, wenn der rollierende Zähler 220 einen oder mehrere Werte überspringt, oder auf der Grundlage einer beliebigen anderen Technik, die in dem Algorithmus für den rollierenden Zähler genutzt wird.
Ferner wird die CRC 250 verwendet, um die Datenintegrität zu prüfen. Zum Beispiel kann der empfangende Controller 520 irrelevante Daten detektieren, wenn die Musterkennung 210 fehlschlägt und/oder im Fall einer Nichtübereinstimmung des rollierenden Zählers 220 oder wenn die Prüfung der CRC 250 fehlschlägt. Der empfangende Controller 520 kann ferner Probleme mit der Datenkonsistenz detektieren, wenn die CRC-Prüfung fehlschlägt. Zum Beispiel stellt der empfangende Controller 520 im Fall, dass die Prüfung der Musterkennung fehlschlägt, und/oder die CRC-Prüfung fehlschlägt, fest, dass unvollständige Daten empfangen wurden. Ferner kann der empfangende Controller 520 ein Vertauschen von Daten detektieren, wenn die CRC-Prüfung fehlschlägt.
Ferner stellt die zweite Netzwerkschnittstelle unter Verwendung eines Botschaftsformats in Übereinstimmung mit dem zweiten Protokoll, das von dem zweiten Controller 520 benutzt wird, die Signalgruppe 240 wieder her. Bei einem oder mehreren Beispielen führt die Botschaft 530 zu mehr als einer zweiten Protokollbotschaft bei dem zweiten Controller 520. Der zweite Controller 520 verwendet dann die wiederhergestellten Botschaften.
Bei einem oder mehreren Beispielen erzeugt der erste Controller 510 mehrere Datentelegramme 530 und 540 wie hier beschrieben und überträgt die mehreren Botschaften 530 - 540 unter Verwendung des Datentelegramms 200 ohne Kenntnis eines Protokolls über alle verfügbaren Kommunikationskanäle, wodurch ein reibungsloser Übergang zwischen den Controllern ermöglicht wird. Zum Beispiel sendet der erste Controller 510 die Botschaft 530 an den zweiten Controller 520, der ein zweites Protokoll nutzt, und zusätzlich eine Botschaft 540, die die gleichen Informationen wie die Botschaft 530 enthält, an einen dritten Controller 520b, der ein drittes Protokoll nutzt. Alternativ oder zusätzlich erzeugt die ECU ein einziges Datentelegramm 200 und überträgt Kopien des Datentelegramms 200 über alle verfügbaren Kanäle, zum Beispiel als Botschaft 530 und als Botschaft 540.
6 veranschaulicht ein beispielhaftes Flussdiagramm für ein Verfahren zum Übertragen von Datentelegrammen ohne Kenntnis eines Protokolls in Übereinstimmung mit einer oder mehreren Ausführungsformen. Der sendende Controller 510 erzeugt eine Botschaft in Übereinstimmung mit einem Kommunikationsprotokoll des sendenden Controllers, dem ersten Protokoll, wie bei Block 610 gezeigt ist. Ferner verpackt der sendende Controller 510 die Daten aus der Botschaft in Übereinstimmung mit dem Datentelegramm 200 ohne Kenntnis eines Protokolls, wie bei Block 620 gezeigt ist. Ferner überträgt der sendende Controller 510 das Datentelegramm 200 ohne Kenntnis eines Protokolls an einen oder mehrere empfangende Controller 520 unter Verwendung jeweiliger Kommunikationskanäle, wie bei Block 630 gezeigt ist. Folglich erzeugt der sendende Controller 510 Kopien des gleichen Datentelegramms ohne Kenntnis eines Protokolls und sendet diese an mehrere empfangende Controller unabhängig von den verschiedenen Protokollen, die von den empfangenden Controllern 520 genutzt werden.
7 veranschaulicht ein beispielhaftes Flussdiagramm für ein Verfahren zum Empfangen eines Datentelegramms ohne Kenntnis eines Protokolls in Übereinstimmung mit einer oder mehreren Ausführungsformen. Der empfangende Controller 520 empfängt ein Datentelegramm 200 ohne Kenntnis eines Protokolls, wie bei Block 710 gezeigt ist.
In Ansprechen darauf bestimmt der empfangende Controller 520 die Validität des Datentelegramms 200 unter Verwendung von Feldern in dem Datentelegramm 200, wie bei Block 720 gezeigt ist. Zum Beispiel werden die Musterkennung 210 und der rollierende Zähler 220 mit jeweiligen Komplementen 260 - 270 verglichen, wie bei Block 722 gezeigt ist. Beispielsweise wird eine XOR-Operation an der Musterkennung 210 und dem Komplement 260 der Musterkennung ausgeführt. Wenn das Resultat nicht aus lauter Einsen besteht, wird das Datentelegramm 200 als ungültig betrachtet. Bei einem oder mehreren Beispielen werden, wenn die Musterkennungsprüfung ergibt, dass das Datentelegramm gültig ist, der rollierende Zähler 220 und das Komplement 270 des rollierenden Zählers mit XOR verknüpft. Wenn dieses Ergebnis nicht aus lauter Einsen besteht, wird das Datentelegramm 200 als ungültig betrachtet. Bei einem oder mehreren Beispielen werden die Musterkennung 210 und der rollierende Zähler 220 mit den entsprechenden Komplementen 260 - 270 in einer einzigen Operation mit XOR verknüpft.
Ferner wird die Gültigkeit des rollierenden Zählers 220 mit einem Wert für den rollierenden Zähler des empfangenden Controllers 520 geprüft, wie bei Block 724 gezeigt ist. Des Weiteren wird die CRC 250 des Datentelegramms 200 verwendet, um die Datenintegrität der Signalgruppe 240 und der Botschaftenkennung 230 zu prüfen, wie bei Block 726 gezeigt ist.
Wenn alle Gültigkeitsprüfungen erfolgreich sind, verpackt die Netzwerkschnittstelle 522 des empfangenden Controllers 520 die Daten von den Signalen von dem Datentelegramm 200 in Übereinstimmung mit dem Protokoll des empfangenden Controllers neu, wie bei Block 740 und 750 gezeigt ist. Der empfangende Controller 520 greift auf die Daten von den wiederhergestellten Botschaften in dem Format des Protokolls des empfangenden Controllers zu und verwendet diese. Bei einem oder mehreren Beispielen werden die Daten von der Signalgruppe 240 auf der Grundlage der Positionen und Größen jedes Signals, die durch die Botschaftenkennung 230 bereitgestellt werden, in separate Signale extrahiert.
Wenn die Gültigkeitsprüfung des Datentelegramms 200 alternativ fehlschlägt, prüft der empfangende Controller 520, ob ein redundanter Kanal existiert, auf welchem das Datentelegramm 200 gesendet wurde, wie bei Block 730 und 750 gezeigt ist. Wenn ein redundanter Kanal existiert, greift der empfangende Controller 520 auf eine Kopie des Datentelegramms 200 ohne Kenntnis eines Protokolls aus dem redundanten Kanal zu, wie bei Block 760 gezeigt ist. Die Kopie des Datentelegramms 200 wird wie vorstehend beschrieben verarbeitet, wie bei Block 720 gezeigt ist.
Im Fall, dass keine weiteren redundanten Kopien des Datentelegramms 200 zum Zugriff für den empfangenden Controller 520 zur Verfügung stehen, meldet der empfangende Controller einen Kommunikationsfehler, wie bei Block 770 gezeigt ist.
Bei einem oder mehreren Beispielen implementiert das Steuerungsmodul 40 des Lenkungssystems 12 die hier beschriebenen technischen Lösungen. Zum Beispiel empfängt und/oder sendet das Steuerungsmodul 40 Informationen in Übereinstimmung mit dem hier beschriebenen Datenformat. Zum Beispiel erzeugt das Steuerungsmodul ein Datentelegramm, in dem Informationen wie hier beschrieben verpackt sind, bevor das Datentelegramm an eine andere ECU in dem Fahrzeug übertragen wird. Alternativ oder zusätzlich empfängt das Steuerungsmodul 40 ein Datentelegramm wie hier beschrieben ist. Das Steuerungsmodul bestimmt die Gültigkeit der Daten unter Verwendung des einen oder der mehreren Felder in dem Datentelegramm, wie hier beschrieben ist. Wenn das Steuerungsmodul 40 annimmt, dass das Datentelegramm in einer gültigen Form empfangen worden ist, fährt das Steuerungsmodul fort, die Daten in dem Datentelegramm zu zerlegen und zu nutzen. Im Fall, dass das Steuerungsmodul 40 das Datentelegramm überträgt, führt die empfangende ECU eine Gültigkeitsprüfung wie hier beschrieben aus, bevor sie die Daten, die von dem Steuerungsmodul 40 gesendet wurden, zerlegt und nutzt.
Die vorliegenden technischen Lösungen können ein System, ein Verfahren und/oder ein Computerprogrammprodukt bei einem beliebigen möglichen technischen Detailniveau der Integration sein. Das Computerprogrammprodukt kann ein oder mehrere computerlesbare Speichermedien enthalten, die darin enthaltene computerlesbare Programmanweisungen aufweisen, um zu veranlassen, dass ein Prozessor Aspekte der vorliegenden technischen Lösungen ausführt.
Aspekte der vorliegenden technischen Lösungen sind hier mit Bezug auf Flussdiagrammveranschaulichungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten in Übereinstimmung mit Ausführungsformen der technischen Lösungen beschrieben. Es versteht sich, dass jeder Block der Flussdiagrammveranschaulichungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammveranschaulichungen und/oder Blockdiagrammen durch computerlesbare Programmanweisungen implementiert werden können.
Die Flussdiagramme und Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und die Arbeitsweise von möglichen Implementierungen von Systemen, Verfahren und Computerprogrammprodukten in Übereinstimmung mit verschiedenen Ausführungsformen der vorliegenden technischen Lösungen. In dieser Hinsicht kann jeder Block in den Flussdiagrammen oder Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt von Anweisungen repräsentieren, welche ein oder mehrere ausführbare Anweisungen umfassen, um die beschriebenen logischen Funktionen zu implementieren. In einigen alternativen Implementierungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren beschrieben auftreten. Zum Beispiel können zwei Blöcke, die aufeinanderfolgend gezeigt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in Abhängigkeit von der betroffenen Funktionalität in der umgekehrten Reihenfolge ausgeführt werden. Außerdem soll erwähnt werden, dass jeder Block der Blockdiagramme und/oder Flussdiagrammveranschaulichungen und Kombinationen von Blöcken in den Blockdiagrammen und/oder Flussdiagrammveranschaulichungen durch spezialisierte hardwarebasierte Systeme implementiert werden können, welche die beschriebenen Funktionen oder Handlungen ausführen oder Kombinationen aus spezieller Hardware und Computeranweisungen ausführen.
Außerdem ist festzustellen, dass alle Module, Einheiten, Komponenten, Server, Computer, Endgeräte oder Vorrichtungen, die hier beispielhaft beschrieben sind, welche Anweisungen ausführen, computerlesbare Medien enthalten oder anderweitig darauf Zugriff aufweisen können, etwa Speichermedien, Computerspeichermedien oder Datenspeichergeräte (entfernbare und/oder nicht entfernbare) wie zum Beispiel Magnetplatten, optische Platten oder Bänder. Computerspeichermedien können flüchtige und nichtflüchtige, entfernbare und nicht entfernbare Medien umfassen, die mit einem beliebigen Verfahren oder in einer beliebigen Technologie zum Speichern von Informationen implementiert sind, etwa computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten. Derartige Computerspeichermedien können Teil des Geräts sein oder für dieses zugänglich oder damit verbindbar sein. Jede hier beschriebene Anwendung oder jedes hier beschriebene Modul kann unter Verwendung von computerlesbaren/vom Computer ausführbaren Anweisungen implementiert sein, die durch solche computerlesbare Medien gespeichert oder anderweitig vorgehalten werden können.
Obwohl die technischen Lösungen im Detail in Verbindung mit nur einer begrenzten Anzahl von Ausführungsformen beschrieben wurden, ist es leicht zu verstehen, dass die technischen Lösungen nicht auf diese offenbarten Ausführungsformen beschränkt sind. Stattdessen können die technischen Lösungen modifiziert werden, um eine beliebige Anzahl von Variationen, Veränderungen, Substitutionen oder äquivalenten Anordnungen aufzunehmen, die hier im Vorstehenden nicht beschrieben sind, welche aber mit dem Geist und dem Umfang der technischen Lösungen übereinstimmen. Obwohl verschiedene Ausführungsformen der technischen Lösungen beschrieben wurden, versteht es sich außerdem, dass Aspekte der technischen Lösungen nur einige der beschriebenen Ausführungsformen umfassen können. Folglich dürfen die technischen Lösungen nicht so aufgefasst werden, dass sie auf die vorstehende Beschreibung beschränkt sind.

Claims

Computerimplementiertes Verfahren zur Kommunikation zwischen Controllern, wobei das Verfahren umfasst, dass: von einem sendenden Controller ein Datentelegramm ohne Kenntnis eines Protokolls erzeugt wird, das eine Musterkennung (210), einen rollierenden Zähler (220), eine Botschaftenkennung (230), eine Signalgruppe (240), eine zyklische Redundanzprüfung (CRC) (250), ein Komplement der Musterkennung (210) und ein Komplement des rollierenden Zählers (220) umfasst; von dem sendenden Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen ersten empfangenden Controller gesendet wird, der ein erstes Kommunikationsprotokoll verwendet; und von dem sendenden Controller das Datentelegramm ohne Kenntnis eines Protokolls an einen zweiten empfangenden Controller gesendet wird, der ein zweites Kommunikationsprotokoll verwendet.
Computerimplementiertes Verfahren nach Anspruch 1, wobei der sendende Controller ein drittes Kommunikationsprotokoll verwendet, das sich von dem ersten und von dem zweiten Kommunikationsprotokoll unterscheidet.
Computerimplementiertes Verfahren nach Anspruch 1, wobei das Datentelegramm ohne Kenntnis eines Protokolls in Ansprechen darauf ungültig ist, dass eine XOR-Operation der Musterkennung (210) und des Komplements der Musterkennung (210) nicht zu einem Ergebnis führt, das aus lauter Einsen besteht.
Computerimplementiertes Verfahren nach Anspruch 1, wobei das Datentelegramm ohne Kenntnis eines Protokolls in Ansprechen darauf ungültig ist, dass ein Ergebnis einer XOR-Operation des rollierenden Zählers (220) und des Komplements des rollierenden Zählers (220) nicht zu lauter Einsen führt.
Computerimplementiertes Verfahren nach Anspruch 1, wobei das Datentelegramm ohne Kenntnis eines Protokolls in Ansprechen darauf ungültig ist, dass der rollierende Zähler (220) von dem Datentelegramm ohne Kenntnis eines Protokolls kleiner oder gleich einem Wert eines rollierenden Zählers (220) ist, der in einem empfangenden Controller gespeichert ist.
Computerimplementiertes Verfahren nach Anspruch 1, wobei die CRC (250) einen CRC-Wert umfasst, der auf der Botschaftenkennung (230) und der Signalgruppe (240) von dem Datentelegramm ohne Kenntnis eines Protokolls beruht.
Computerimplementiertes Verfahren nach Anspruch 1, wobei die Signalgruppe (240) mehrere Signale umfasst, wobei die Botschaftenkennung (230) eine Anzahl der Signale und eine Größe jedes Signals anzeigt.
Computerimplementiertes Verfahren nach Anspruch 1, wobei das Datentelegramm ohne Kenntnis eines Protokolls keine Größenbegrenzung aufweist.
Computerimplementiertes Verfahren nach Anspruch 1, das ferner umfasst, dass: von dem ersten empfangenden Controller eine Gültigkeit des Datentelegramms ohne Kenntnis eines Protokolls geprüft wird; in Ansprechen darauf, dass das Datentelegramm ohne Kenntnis eines Protokolls gültig ist: von dem ersten empfangenden Controller die Signalgruppe (240) aus dem Datentelegramm ohne Kenntnis eines Protokolls extrahiert wird, wobei die Signalgruppe (240) eine Vielzahl von Signalen umfasst; und von dem ersten empfangenden Controller eine oder mehrere Botschaften in Übereinstimmung mit dem ersten Kommunikationsprotokoll unter Verwendung der Signale erzeugt wird/werden.
Computerimplementiertes Verfahren nach Anspruch 9, das ferner umfasst, dass: von dem zweiten empfangenden Controller eine Gültigkeit des Datentelegramms ohne Kenntnis eines Protokolls geprüft wird; in Ansprechen darauf, dass das Datentelegramm ohne Kenntnis eines Protokolls gültig ist: von dem zweiten empfangenden Controller die Signalgruppe (240) aus dem Datentelegramm ohne Kenntnis eines Protokolls extrahiert wird, wobei die Signalgruppe (240) die Vielzahl von Signalen umfasst; und von dem zweiten empfangenden Controller eine oder mehrere Botschaften in Übereinstimmung mit dem zweiten Kommunikationsprotokoll unter Verwendung der Signale erzeugt wird/werden.
Kommunikationssystem, umfassend: einen ersten Controller, der ein erstes Kommunikationsprotokoll verwendet, und der ausgestaltet ist, um mit mehreren empfangenden Controllern ohne Kenntnis eines Protokolls zu kommunizieren, indem: ein Datentelegramm ohne Kenntnis eines Protokolls erzeugt wird, das eine Musterkennung (210), einen rollierenden Zähler (220), eine Botschaftenkennung (230), eine Signalgruppe (240), eine zyklische Redundanzprüfung (CRC) (250), ein Komplement der Musterkennung (210) und ein Komplement des rollierenden Zählers (220) umfasst; das Datentelegramm ohne Kenntnis eines Protokolls an einen zweiten Controller gesendet wird, der ein zweites Kommunikationsprotokoll verwendet; und das Datentelegramm ohne Kenntnis eines Protokolls an einen dritten Controller gesendet wird, der ein drittes Kommunikationsprotokoll verwendet.
Kommunikationssystem nach Anspruch 11, wobei das Datentelegramm ohne Kenntnis eines Protokolls in Ansprechen darauf ungültig ist, dass ein Ergebnis einer XOR-Operation der Musterkennung (210) und des Komplements der Musterkennung (210) nicht lauter Einsen ergibt.
Kommunikationssystem nach Anspruch 11, wobei das Datentelegramm ohne Kenntnis eines Protokolls in Ansprechen darauf ungültig ist, dass ein Ergebnis einer XOR-Operation des rollierenden Zählers (220) und des Komplements des rollierenden Zählers (220) nicht lauter Einsen ergibt.
Kommunikationssystem nach Anspruch 11, wobei die CRC (250) einen CRC-Wert umfasst, der auf der Botschaftenkennung (230) und der Signalgruppe (240) von dem Datentelegramm ohne Kenntnis eines Protokolls beruht.
Kommunikationssystem nach Anspruch 11, wobei der zweite Controller ausgestaltet ist, um eine Kommunikation ohne Kenntnis eines Protokolls zu empfangen, in dem er: eine Gültigkeit des Datentelegramms ohne Kenntnis eines Protokolls unter Verwendung eines oder mehrerer Felder des Datentelegramms ohne Kenntnis eines Protokolls prüft; und in Ansprechen darauf, dass das Datentelegramm ohne Kenntnis eines Protokolls gültig ist: die Signalgruppe (240) aus dem Datentelegramm ohne Kenntnis eines Protokolls extrahiert, wobei die Signalgruppe (240) eine Vielzahl von Signalen umfasst; und eine oder mehrere Botschaften in Übereinstimmung mit dem zweiten Kommunikationsprotokoll unter Verwendung der Signale erzeugt.