Das Auto und die Automobilindustrie haben sich über die Jahrzehnte stetig weiterentwickelt. Nun gilt es, neuen Herausforderungen ins Auge zu blicken.

Bild: Shutterstock

Absichern von Datenübertragung Onboard Kommunikation: CAN und LIN Bus

09.10.2018

Fortwährende Entwicklungen in der Automobilindustrie erhöhen die Komplexität der Autos immer mehr. Dies führt zu einer zunehmenden Vernetzung einzelner Systeme beispielsweise durch CAN und LIN Bus. Hierbei muss nicht mehr nur die korrekte Übertragung sichergestellt, sondern neuerdings auch vor Manipulationen geschützt werden, sodass Daten, die auf Empfängerseite eine Aktion auslösen, auch wirklich von einem autorisierten Sender stammen.

Immer mehr Komponenten im Auto kommunizieren miteinander und können Einfluss auf das Fahrverhalten des Autos nehmen. Insbesondere Fahrassistenzsysteme, das autonome Fahren und Komfort-Funktionen tragen zur Komplexität bei. Im Bereich Antriebsstrang ist dabei der CAN-Bus die verbreitetste Vernetzungs-Lösung, im Bereich Komfortfunktionen ist der LIN-Bus, die am häufigsten anzutreffende Netzwerktechnologie.

Bei beiden Bussystemen wird die Information auf dem Bus in einem Frame übertragen, der neben den Daten auch noch einen Frame-Identifier und eine Prüfsumme beinhaltet (Abbildung 1). Diese Prüfsumme wird im Fall von CAN direkt durch die CAN-Controller-Hardware gebildet. Bei der LIN-Kommunikation wird der Frame in der Regel durch eine Softwareroutine erstellt, in der auch die Prüfsumme, nach einem allgemein bekannten Verfahren gebildet wird. Damit ist die Information in einem CAN- oder LIN-Frame dahingehend geschützt, dass ein Empfänger erkennen kann, ob der Frame so empfangen wurde, wie er vom Sender abgeschickt wurde.

Sicherheit durch Prüfsumme

Bei beiden Bus-Systemen wird im Fahrzeug vorwiegend mit einem statischen Daten-Mapping gearbeitet. Das heißt in einem Frame mit definiertem Identifier, repräsentiert ein bestimmtes Datum, wie etwa Byte 2, immer einen bestimmten Wert, wie die Drehzahl. Wer also einen Frame mit gültiger Prüfsumme auf dem Bus versendet, kann den angeschlossenen Systemen Informationen liefern, ohne dass der Empfänger eine Möglichkeit zur Überprüfung hat, ob die Information aus einer autorisierten Quelle stammt.

Um die Datenkommunikation gegen Reverse Engineering, gefälschte Bauteile und böswillige Einflussnahme zu schützen, wurden schon seit längerem zusätzliche Methoden angewendet, die im Wesentlichen auf der Einbringung von CRC-Werten in den Datenbereich beruhen (Abbildung 2). Ein vom Empfänger zunächst als gültig empfangener Frame wird dann dort einer zweiten Prüfung unterzogen und nur wenn der Empfänger einen gültigen CRC nachrechnet, werden die Daten überhaupt verwendet.

Sender und Empfänger müssen also in diesem Falle auf beiden Seiten über den Algorithmus zum Bilden und Prüfen des CRC verfügen. Da diese Algorithmen aber nicht allgemein bekannt sind, können nur autorisierte Parteien Systeme entwickeln, die dann an einem bestimmten Bus valide kommunizieren können. Nachdem in der Anfangszeit einige proprietäre CRC-Methoden eingesetzt wurden, war mit der Einführung eines Ende-zu-Ende Protokolls im Autosar-Standard eine standardisierte Methode für die zusätzliche CRC-Absicherung verfügbar. Die Definition eines Ende-zu-Ende Protokolls als Autosar Standard führte zu mehr Sicherheit. Diese ist nun einigen Herstellern scheinbar nicht mehr genug, da diese nun von fest definierten Parametern des Autosar-CRC abweichen. Diese proprietäre Abweichung führt dazu, dass auch LIN- und CAN-Adapter mehr Variablen zulassen müssen.

Profile und Varianten definieren Werte

Die Absicherung der CAN- und LIN-Kommunikation soll verhindern, dass unautorisierte Teilnehmer, die den Algorithmus zur Absicherung nicht kennen, andere Komponenten nicht steuern oder beeinflussen können. Daher prüfen Komponenten empfangene Frames, ob die Absicherung korrekt ist und verwerfen Frames, bei denen dies nicht der Fall ist. Auch wenn in der Praxis diese Prüfung zumindest zum jetzigen Zeitpunkt noch nicht alle Komponenten durchführen, so ist der Trend doch klar erkennbar. Die E2E-Protokoll-Spezifikation im Autosar-Standard definiert eine solche Absicherung anhand eines 8-Bit-CRC-Algorithmus. Hierbei werden verschiedene Profile und Varianten definiert, die sich durch die Daten unterscheiden, die zur CRC-Berechnung herangezogen werden.

Beide standardisierten Profile definieren feste Werte als Initialwert, Polynom und XOR-Wert für die CRC-Berechnung. Profil 1 ergänzt die Eingangs-Daten aus dem Frame um eine Konstante, deren Verwendung durch die gewählte Variante (1A 16Bit, 1A, 8Bit, 1B, 1C) beeinflusst wird. Zudem wird ein Zähler im Datenbereich vorgegeben. Profil 2 besitzt ebenfalls einen Zähler in den Daten, der aber zusätzlich noch zur Auswahl eines Wertes aus eines konstanten 16 Werte Speichers verwendet wird. Die Freiheitsgrade liegen daher in der Auswahl der Variante und der Konstante bei Profil 1 beziehungsweise dem 16-Werte-Speicher bei Profil 2.

Kommunikation der Komponenten

Die Werte für die Startposition des Eingangs-Blocks, die Länge des Eingangs-Blocks, die Startposition des CRC, die Startposition des Zählers, die Länge des Zählers, der Start-Wert des Zählers und der End-Wert des Zählers sind wie auch die CRC-Werte fest definiert. In verschiedenen Projekten von Lipowsky Industrie-Elektronik wurden allerdings schon Bus-Teilnehmer verwendet, die vom Autosar-Standard abweichen und einige dieser Werte proprietär bestimmen. Die Kommunikation mit diesen Komponenten war aus diesem Grund nicht auf Anhieb möglich. Dieses Problem betrifft vor allem CAN- und LIN-Adapter, die zur Entwicklung und dem Test entsprechender Komponenten eingesetzt werden. Diese müssen nicht mehr lediglich die standardisierten Varianten unterstützen, sondern praktisch alle möglichen Variationen erlauben, um eine universelle Einsatzmöglichkeit zu erlauben. Besonders betroffen davon sind daher Firmen und Abteilungen, die sich auf das Testen von Komponenten spezialisiert haben. Hier ist eine Restbus-Simulation notwendig, um den Einsatz einzelner Komponenten im Umfeld des Autos zu simulieren.

Vielfältige Einsatzmöglichkeiten

Die Lösung der Baby-LIN-Geräte von Lipowsky Indus-
trie-Elektronik besteht darin, möglichst viele Variationen zuzulassen. Auch bei der Verwendung der Autosar-CRCs können Initialwert, Polynom und XOR-Wert der CRC-Berechnung sowie die Startposition des Eingangs-Blocks, die Länge des Eingangs-Blocks, die Startposition des CRC, die Startposition des Zählers, die Länge des Zählers, der Start-Wert des Zählers und der End-Wert des Zählers frei gewählt werden. Somit sind diese LIN- und CAN-Adapter für Abweichungen gewappnet und erlauben einen breiten Einsatz im Entwicklungs- und Test-Umfeld.

Die Absicherung der CAN- und LIN-Kommunikation macht in sicherheitsrelevanten Bereichen wie der Automobil-Industrie Sinn und wird dort bereits vielfach eingesetzt. Die Einführung von Standards wie dem Autosar-E2E-Protokoll soll den Umgang mit dieser Technik vereinfachen und deren breite Anwendung unterstützen.

CAN- und LIN-Kommunikation absichern

In der Praxis steigen durch diese Methoden auch die Anforderungen an Bus-Simulationssysteme, die überall dort zum Einsatz kommen, wo Komponenten, die im Fahrzeug per CAN- oder LIN-Bus angeschlossen sind, außerhalb des Fahrzeugs gehandhabt werden müssen. Das ist zum Beispiel bei der Produktion, in der Entwicklung und beim Test solcher Komponenten der Fall. Jüngst beobachtete Abweichungen bei einzelnen Herstellern vom Standard erfordern zusätzliche Optionen bei den Simulations-Tools, damit diese alle diese Varianten beherrschen. Zum Beispiel hat mittlerweile die entsprechende Konfigurationsmaske des Baby-LIN-Simulations-Tools je nach gewähltem Profil zwischen 14 und 28 Parameter, um diese CRC-Funktionalität universell einstellbar zu machen.

Wenn man die Entwicklung beobachtet, kann davon ausgegangen werden, dass es durch neue proprietäre Abweichungen immer wieder Erweiterung an diesen Methoden geben wird. Hier zeigt sich dann, ob der Tool Hersteller, neben den aktuellen Anforderungen, auch zukünftige Entwicklungen durch entsprechende Weiterentwicklungen und Update Strategien seiner Produkte einfach abbilden kann.

Bildergalerie

  • Abbildung 1: Aufbau eines LIN-Frames mit der Checksumme im letzten Byte.

    Bild: Lipowsky Industrie-Elektronik

  • Abbildung 2: Die Absicherung von Frame-Daten über einen einfachen 8-Bit-CRC innerhalb der Daten.

    Bild: Lipowsky Industrie-Elektronik

  • Absicherung von Frame Daten über AUTOSAR CRC Profil 1.

    Bild: Lipowsky Industrie-Elektronik

  • Absicherung von Frame Daten über AUTOSAR CRC Profil 2.

    Bild: Lipowsky Industrie-Elektronik

Firmen zu diesem Artikel
Verwandte Artikel