Ich habe immer wieder über Sensoren, die ML-Ableitung der Ausgabe dieser Sensoren und die Anwendung beider in modernen Autos geschrieben. Ohne diese wären weder ADAS noch autonomes/teilautonomes Fahren möglich. Aber bis jetzt habe ich mich noch nie mit dem Transport zwischen Sensoren und dem Computer befasst, der das, was sie erzeugen, sicher in klare Bilder und eine genaue Objekterkennung umwandelt. Mixel und Rambus hielten kürzlich auf der MIPI DevCon einen Vortrag über diesen Transport, MIPI. Nützlich, da ich bisher davon ausgegangen war, dass die Daten irgendwie vom Sensor zum Rechner gelangen. Das Beispiel konzentrierte sich insbesondere auf Bildgebungssubsysteme. In diesem Vortrag ging es um die Kamera-serielle Schnittstelle (MIPI CSI-2) von Rambus und die physikalische Schnittstelle (MIPI C-PHY und MIPI D-PHY) von Mixel.
MIPI CSI-2 und PHY Sende- und Empfangsblöcke
MIPI CSI-2 ist die Funktion, die eine serielle Schnittstelle zwischen einer Kamera an einem Ende und einem ISP am anderen Ende definiert. Pixel strömen auf einer Seite ein und schließlich auf der anderen Seite wieder heraus, daher benötigt die Schnittstelle eine Sendefunktion und eine Empfangsfunktion. Da diese Funktionen in der Lage sein müssen, jede Kamera (oder mehr als eine Kamera) mit jedem ISP zu verbinden, benötigen sie ein hohes Maß an Flexibilität. Ein Beispiel ist die Bandbreitenanpassung zwischen dem Sensor und dem Endverbraucher, die beispielsweise einen kontinuierlichen Streaming-Fluss ermöglicht.
Zwischen den CSI-2-Sende- und Empfangsfunktionen übernimmt D-PHY (oder C-PHY) die physische Kommunikation. D-PHY verwendet differenzielle Signalisierung, während C-PHY eine clevere differenzielle Technik verwendet, die ein Trio von Signalen paarweise zusammen mit der Codierung betrachtet. Komplexes Zeug, unterstützt aber offenbar eine höhere Datenrate als D-PHY.
Sicherheit im PHY
Zurück in einem für mich vertrauteren Bereich sind diese geistigen Eigentumsrechte für Automobilanwendungen konzipiert, was Sicherheit zu einem entscheidenden Ziel macht. Sowohl der PHY als auch der Controller müssen die ISO 26262 FMEDA-Anforderungen für die entsprechende ASIL-Stufe erfüllen. Darüber hinaus erfordern sicherheitskritische Automobilanwendungen eine systeminterne Testbarkeit des MIPI PHY. Ich sehe, dass ähnliche systeminterne Testbarkeitsanforderungen auf ASIL-C/D-Ebenen für andere PHYs immer häufiger vorkommen, daher ist dies keine Überraschung. Der Mixel MIPI PHY unterstützt Full-Speed- und In-System-Loopback-Tests für die universelle Konfiguration (Tx+Rx) sowie eigene Implementierungen für bereichsoptimierte Nur-Übertragungs- und Nur-Empfangs-Konfigurationen namens TX+ und RX+.
Mixel wies außerdem darauf hin, dass zusätzliche Tests für geistiges Eigentum im Automobilbereich erforderlich sind: Stresstests, HTOL und Zuverlässigkeitstests (z. B. Alterung). Dazu gehört auch die Erfüllung der ISO 26262-Standards DFMEA und FMEDA. Gewährleistung der Gesamtzuverlässigkeit des geistigen Eigentums, die für die Fahrzeugsicherheit über eine Lebensdauer von mehr als 15 Jahren unerlässlich ist.
Sicherheit im CSI-2-Controller
Um die ASIL-B-Fehlerabdeckungsanforderungen zu erfüllen, verfügt Rambuss CSI-2 Controller Core mit integriertem Selbsttest (BIST). Dabei kommen BIST-Mechanismen zusammen mit bekannten Sicherheitsminderungstechniken zum Einsatz: ECC, CRC, Parität. Es ist interessant festzustellen, dass der BIST hier auf IP-Ebene und nicht auf Systemebene erfolgt. Ich habe das gleiche Prinzip für In-System-Tests im NoC gesehen. In beiden Fällen wird argumentiert, dass der BIST auf Funktionsebene aus mehreren Gründen besser ist als der auf Systemebene. Es kann tiefer gehen und mehr Vertrauen in die Sicherheitsabdeckung schaffen. Es ist auch dann verfügbar, wenn kein BIST auf Systemebene bereitgestellt wird, und bietet eine zentrale Rückmeldung, wenn das System nicht mehr betriebsbereit ist.
Bei Sicherheitsminderungstechniken bietet der CSI-2-Controller Paritätsschutz für Pixel und Pixelpuffer. Außerdem ECC für den Protokollheader und CRC für Paketdaten. Diese fügen Redundanz für Datenformatierung, Packlogik, kritische Zustandsmaschinen und andere kritische Blöcke hinzu. Die Paketreihenfolge wird überprüft und Bestellfehler werden gekennzeichnet. Eine weitere interessante Überprüfung, die ich bei sicherheitskritischen Anwendungen häufiger gesehen habe, ist ein Watchdog-Timer. Dies dient dazu, eingefrorene oder übermäßig verzögerte Vorgänge zu erkennen. Alle betonen, dass es bei hohen ASIL-Niveaus bei der Sicherheitsminderung nicht mehr nur um die grundlegenden Methoden geht. Entwickler fügen aktivere und komplexere Tests und Abhilfemaßnahmen hinzu, um ASIL-C/D zu erreichen.
Dieser Vortrag kann gefunden werden KLICKEN SIE HIER und ist ein guter Einstieg in das Thema.
Teile diesen Beitrag über:
