SENT (Single Edge Nibble Transmission, SAE J2716) ist eine relativ neue serielle Schnittstelle, die ursprünglich für den Einsatz in Automobilen vorgesehen war, sich aber auch für andere Branchen eignet. Erste Anwender nutzen die im Jahr 2007 standardisierte Schnittstelle inzwischen in Sensoren für Drosselklappengeber, zum Messen von Druck und Luftmenge sowie zur Temperaturüberwachung. Das SENT-Protokoll ist als unidirektionales Ausgabeprotokoll definiert. Typischerweise müssen Sensoren ihre Daten in sicherheitsrelevanten Einsatzbereichen mit konstanter Datenrate ausgeben. Eine bidirektionale Kommunikation mit Bestätigungspaketen und Paketwiederholungen könnte hier zu Unterbrechungen führen. Sensorhersteller brauchen zum Kalibrieren daher eine zweite, bidirektionale Schnittstelle für die Kommunikation mit dem Gerät (Bild 1). Im späteren Einsatz genügt dann aber eine Drei-Draht-Anbindung.
Im Normalbetrieb beginnt das Sensormodul nach Power-ON selbständig mit der Übertragung der SENT-Daten. Dies entspricht weitgehend dem Betriebsmodell für Sensormodule mit Analogausgang. Es gibt jedoch einen wichtigen Unterschied: SENT ist nicht auf einen Datenparameter pro Übertragung beschränkt und kann problemlos weitere Mess- und Sensorwerte wie Temperatur, Produktionscodes, Diagnosedaten sowie andere Sekundärdaten ausgeben.
Die SENT-Schnittstelle kurz erklärt
- Das SENT-Protokoll eignet sich als Ersatz für die analoge Messwertübertragung oder den langsamen LIN-Bus
- Unidirektional und störsicher, drei Drähte (Versorgung, Signal, Masse)
- Kann mehrere Datenströme multiplexen
- Herausforderung: Das richtige Format auswählen
Welches Konzept hinter SENT steckt
Der Sender überträgt die Primärdaten üblicherweise über die beiden sogenannten Fast Data Channels (FDC1/2). Optional kann er Sekundärdaten per Slow Data Messaging (SDM) absetzen. Ein Beispiel für die Übertragung über FDC1/2 (Bild 2) zeigt, dass jeder Datenframe zwei 12-Bit-Datenwörter enthält. Optional sind auch andere Aufteilungen möglich, zum Beispiel 16 Bit für Signal 1 und 8 Bit für Signal 2.
Die grundlegende Zeiteinheit für SENT ist ein Tick und die minimale Dateneinheit ein Nibble (Halbbyte, also 8 Bit). Der kombinierte Taktimpuls besteht aus der Low-Periode mit anfänglich fester Breite gefolgt von der High-Periode variabler Breite und überträgt je ein Nibble. Ein Datenframe beginnt immer mit einem Synchronisierungs-/Kalibrierungsimpuls. Empfänger können diesen Impuls nutzen, um die Tickzeit der SENT-Ausgabe zu messen. Der Data-Frame endet üblicherweise mit einem CRC-/Prüfsummen-Nibble (Cyclic Redundancy Check) und einem optionalen Pausenimpuls.
Ticks und Nibbles im SENT-Protokoll
Ein Tick, also die Zeiteinheit für SENT-Übertragungen, dauert zwischen 3 und 90 µs. Für die Übertragung von Daten fasst SENT immer 4 Bit zu einem Nibble zusammen. In dieser Dateneinheit besitzt die anfängliche logische 0 eine feste Dauer von mindestens 5 Ticks. Es folgt eine logische 1 mit variabler Dauer. Über die Nibble-Gesamtdauer von 12 bis 27 Ticks codiert der Sender vier Datenbits:
- Dezimalwert 0: minimale Nibble-Breite von 12 Ticks = 0000 (binär)
- Dezimalwert 1: Nibble-Breite von 13 Ticks = 0001 (binär)
- Dezimalwert 2: Nibble-Breite von 14 Ticks = 0010 (binär)
- …
- Dezimalwert 14: Nibble-Breite von 26 Ticks = 1110 (binär)
- Dezimalwert 15: maximale Nibble-Breite von 27 Ticks = 1111 (binär)
Der Empfänger nutzt den anfänglichen Synchronisierungs-/Kalibrierungsimpuls, um zu messen, wie lange ein Tick bei der Sensorübertragung tatsächlich dauert. Dazu teilt er die Dauer des Impulses durch den Wert 56.
Erstes Nibble nach dem Synchronisierungs-/Kalibrierungsimpuls ist ein Status-/Kommunikations-Nibble. Es kommuniziert in Abhängigkeit vom SENT-Format den Status und/oder die Datenbits des langsamen Kanals. Auf den Inhalt der Nachricht folgt das Feld CRC/Prüfsumme; es dient der Fehlererkennung. An das Ende der Nachricht kann der Sender optional noch einen Pausenimpuls setzen. Dieser Impuls mit variabler Länge kann für eine gleichbleibende Tick-Zahl pro Nachricht sorgen.
Die wichtigsten Abkürzungen in den Bereichen Automotive und Elektronik
Automobil-Begriffe wie ABS und CAN gehörten zu den ersten TLAs (Three-Letter Acronyms, also Abkürzungen, die aus drei Buchstaben bestehen) im Automotive-Bereich, aber mittlerweile gibt es so viele Abkürzungen, dass selbst Experten manchmal ins Grübeln kommen – zumal die Abkürzungen mittlerweile nicht nur aus drei Buchstaben bestehen. Weil selbst Experten, die jeden Tag mit den Begriffen umgehen, manchmal durcheinander kamen, hat die Redaktion ein großes, ständig aktualisiertes Abkürzungsverzeichnis mit weit über 1.000 Einträgen erstellt, das der Übersichtlichkeit halber in mehrere Einzelbeiträge aufgeteilt ist. Zu den Rubriken zählen unter anderem ADAS und AD; Schnittstellen, Test, Diagnose und Frameworks; Elektromobilität; IoT, Wireless, Netzwerk und Schnittstellen sowie viele weitere.
Weitere Formate des Fast Data Channels
Neben dem beschrieben FDC-Format gibt es noch zwei weitere Varianten des Fast Data Channel: 12 Bit Single Secure Message und Fast Channel High Speed. Wie das Diagramm in Bild 3 zeigt, besteht eine im Format „12 Bit Single Secure Message“ übertragene Nachricht aus 12 Datenbits, einem 8-Bit-Aufwärtszähler und dem Kehrwert des höchstwertigen Daten-Nibbles.
Im unteren Teil von Bild 3 überträgt das Format „Fast Channel High Speed“ 12 Datenbits in vier Nibbles. Die Besonderheit dieses Formats besteht darin, dass das höchstwertige Bit in jedem der vier Nibbles immer eine logische 0 ist und nur die drei niederwertigen Bits in jedem der vier Daten-Nibbles die übertragenen Daten enthalten.
Wie Datenübertragung mit Slow Data Messages (SDM) funktioniert
Komplexer gestaltet sich das SENT-Protokoll für die Datenübertragung mittels SDMs (Slow Data Messages). Grundsätzlich werden per SDM immer nur mit jeweils zwei Bit übertragen, der SENT-Transmitter kann also in jeden Datenframe nur zwei SDM-Datenbits einfügen. Diese beiden Bits sind Bit 3 und Bit 2 des Status-Nibbles der beiden FDCs. Die Bezeichnung „Slow Data Message“ kommt daher, dass es viele FDC-Datenframes braucht, um einen Wert vollständig per SDM zu übertragen. So sind beispielsweise 16 FDC-Datenframes nötig, um acht SDM-Datenbits zu übertragen. Die eigentliche Leistungsfähigkeit dieser Funktion besteht darin, dass in jeden seriellen Nachrichtenzyklus bis zu 32 verschiedene Daten passen – ohne Auswirkungen auf die primären Sensordaten, welcher über die beiden FDCs gesendet werden.
Mit diesen SDMs lassen sich beispielsweise Temperaturmesswerte, Diagnosedaten und Produktionscodes kontinuierlich überwachen, also Daten, die sich üblicherweise nicht oder mit deutlich langsamerer Rate als die primären Sensordaten ändern. Jede der maximal 32 SDMs erhält eine ID, die mit den Daten übertragen wird. Die Liste der Nachrichten-IDs ist normalerweise pro Produkt eindeutig und häufig im Produktdatenblatt oder in Applikationsschriften definiert.
Für SDMs sind drei Formate verfügbar: „Short Serial Message“ für 8-Bit-Nachrichten und „Enhanced Serial Message“, das für 12- oder 16-Bit-Nachrichten konfiguriert werden kann. Alle drei Formate unterstützen das Senden einer CRC-Prüfsumme für SDMs im Anschluss an die SDM-ID und die Daten.
Normales und erweitertes SDM-Format
Das Short-Serial-Message-Format überträgt 8 Datenbits per SDM (Bild 4): Bit 3 im Status-Nibble des FDC-Datenframes beginnt mit der logischen 1 und ist dann in den folgenden 15 Frames eine logische 0. Diese Festlegung auf die logische 1, gefolgt von 15 Frames mit logischer 0, ermöglicht die Bestimmung von Anfang und Ende jeder SDM-Nachricht. Die SDM-ID, ein aus 8 Bit bestehendes Datenwort, und die 4-Bit-CRC in Statusbit 2 werden also mit jeweils einem Bit in mehreren FDC-Datenframes übertragen. Zum Senden einer SDM im Short-Serial-Message-Format sind 16 FDC-Datenframes nötig.
Das Enhanced-Serial-Message-Format (Bild 5) dagegen überträgt die SDM-Daten in einem 12- oder 16-Bit-Format. Ein Konfigurationsbit legt fest, ob es sich um das 12- oder das 16-Bit-Format handelt. Im 12-Bit-Format sind der SDM-ID mehr Bits zugewiesen. Bild 5 zeigt die 12-Bit-Variante.
Im Video erklärt: DIe SENT-Schnittstelle
Implementierungshinweise zu SENT
Die Herausforderung bei SENT besteht darin, das für die Applikation am besten geeignete Format zu ermitteln. Sobald Format und Datenmenge feststehen, legt sie der Entwickler im Design fest oder konfiguriert sie im nichtflüchtigen Speicher, sodass der Sensor die Daten nach dem Einschalten kontinuierlich überträgt. Eine weitere Schlüsselfunktion von SENT sind die aktiv geregelten und damit definierten Anstiegs- und Abfallzeiten. Sie reduzieren die EMV-Emissionen, ohne die Geschwindigkeit zu beschränken.
Am Markt sind verschiedene Werkzeuge zum Decodieren des SENT-Protokolls erhältlich, darunter Oszilloskope, Software sowie Mikroprozessoren mit integrierter SENT-Decodierungshardware. Die Schnittstelle wurde erstmals 2007 definiert und die SENT-Version 3.0 aus dem Jahr 2010 ist inzwischen zunehmend gefragt. In Abhängigkeit vom Einsatzbereich ist SENT eine echte technische und kommerzielle Alternative zur konventionellen analogen Messwertübertragung, insbesondere wegen der vielen zusätzlichen Datenübertragungsfunktionen.
(lei)