Vorrichtung und Verfahren zur Synchronisation von Uhren in Steuergeräten und Steuergerät

Die Erfindung betrifft das technische Gebiet der Synchronisation von Uhren in

Steuergeräten, die über ein Bussystem vernetzt sind. Solche Steuergeräte werden vielfach in Kraftfahrzeugen eingesetzt. Vernetzte Steuergeräte sind auch in anderen Gebieten der Technik zu finden, z.B. in der Automatisierungstechnik, Prozesstechnik, usw. Die Erfindung betrifft eine Vorrichtung und ein Verfahren zur Synchronisation von Uhren in Steuergeräten und ein entsprechend eingerichtetes Steuergerät.

In modernen Fahrzeugen werden eine Vielzahl von Steuergeräten verbaut. Alleine für den Antriebstrang werden eine Anzahl Steuergeräte eingesetzt, so z.B. Motor-Steuergerät, Getriebe-Steuergerät, ESP-Steuergerät, Fahrwerk-Steuergerät und weitere. Daneben gibt es auch noch weitere Steuergeräte, die im Bereich der Fahrzeugkarosserie verbaut werden und für bestimmte Komfortfunktionen sorgen. Als Beispiele werden genannt die Tür- oder Fensterheber-Steuergeräte, Klimaanlage-Steuergeräte, Sitzverstellungs-Steuergeräte, Airbag-Steuergeräte u.a. Dann gibt es weiterhin Steuergeräte, die zu dem Infotainment- Bereich zählen, wie Kamera-Steuergerät zur Umfeldbeobachtung, Navigationsgerät, RADAR- oder LIDAR-Gerät, Kommunikationsmodul und Entertainment-Gerät mit TV, Radio, Video und Musik-Funktion.

Typischerweise werden die Steuergeräte der verschiedenen Kategorien jeweils mit einem separaten, für die Gerätekategorie entsprechend ausgelegten Bus vernetzt. Es können daher mehrere verschiedene Bussysteme im Fahrzeug eingesetzt werden. Die

verschiedenen Bussysteme können dabei über Gateways miteinander verbunden sein, um einen Datenaustausch zu ermöglichen. Im Bereich der Antriebstrang-Steuergeräte wird typischerweise der CAN-Bus (Controller Area Network) eingesetzt, ebenfalls im Bereich der Komfort-Steuergeräte. Im Infotainment-Bereich kommen auch andere Bussysteme zum Einsatz, wie Bussysteme die auf Ethernet-Technologie beruhen, z.B. AVB (Audio Video Bridging) der auf der Standard-Familie nach IEEE 802.1 Standard basiert. Auch

Bussysteme, bei denen die Datenübertragung über Lichtwellenleiter geschieht, sind einsetzbar. Als Beispiele werden genannt der MOST Bus (Media Oriented System Transport) oder der D2B Bus (Domestic Digital Bus).

Ein Problem bei der Vernetzung von Steuergeräten ist die Zeit-Synchronisation der

Steuergeräte untereinander. Vielfach müssen die Steuergeräte ihre Steuerfunktionen synchron erledigen. Als Beispiel werden genannt sicherheitsrelevante Funktionen wie ein Bremsvorgang. Dabei arbeiten die Steuergeräte ESP-Steuergerät (enthält die ABS- Funktion), Motor-Steuergerät, Getriebe-Steuergerät und Fahrwerk-Steuergerät zusammen um z.B. bei einer Notbremsung die bestmögliche Bremsleistung zu realisieren.

Abweichungen von wenigen Millisekunden bei Einleitung und/oder der Abarbeitung der Notbremsfunktion können sich dann schon auf den Bremsweg auswirken.

Bei dem AVB-Bus gibt es ein spezifisches Protokoll, welches zur präzisen Synchronisation der Infotainment-Geräte vorgesehen ist. Das Protokoll wurde in dem Standard IEEE 802.1AS spezifiziert. Danach tauschen die Geräte periodisch Zeitinformationen aus, die es beiden Teilnehmern an einer Verbindung ermöglichen ihre lokalen Uhren sehr präzise zu synchronisieren. Beim AVB Bus dient die Synchronisation den folgenden Zwecken:

• um die Synchronizität von Datenströmen sicher zu stellen

• um eine gemeinsame Zeitbasis für das Abtasten / Empfangen von Datenströmen an einem Quellgerät und die Präsentation dieser Streams am Zielgerät mit demselben relativen Timing bereit zu stellen.

Innerhalb der Zeit-Domäne gibt es ein einziges Gerät namens„Grandmaster", das ein „Master-Timing-Signal" liefert. Alle anderen Geräte synchronisieren ihre Uhren mit dem „Master-Timing-Signal".

Für den Bereich des CAN-Busses gibt es ebenfalls Anforderungen was die Synchronisation der Uhren der Steuergeräte anbelangt. Die AUTOSAR-Organisation hat ein Protokoll spezifiziert, welches es erlaubt mehrere Steuergeräte, die mit einem CAN Bus miteinander verbunden sind, zeitlich zu synchronisieren. Die Spezifikation hat den Titel„Specification of Synchronized Time-Base Manager", AUTOSAR CP Release 4.3.0. Weitere Informationen zu diesem Thema finden sich in dem AUTOSAR-Dokument„Specification of Time

Synchronisation over CAN", AUTOSAR CP Release 4.3.0. Der Vorschlag bezieht sich aber auf eine Software-Lösung. Die erreichbare Genauigkeit der Zeitsynchronisation hängt dabei maßgeblich von der Genauigkeit der in den Synchronisationsnachrichten verwendeten, wie auch der in den Slave-Steuergeräten bei Ankunft der Synchronisationsnachrichten erfassten Zeitstempel ab.

Um die Genauigkeit zu verbessern, hat die Organisation CiA (CAN in Automation) den Vorschlag hervorgebracht, die Erfassung der Zeitstempel („Frame Time Stamping") im CAN Controller vorzunehmen. Die Spezifikation hat den Titel„Frame time-stamping", CiA 603 Final Working Draft Version 0.0.5, Dezember 2016. Jedoch beschreiben weder AUTOSAR noch das CiA Dokument wie auf der Basis der gewonnenen Informationen die tatsächliche Zeitsynchronisation zu einem beliebigen

Zeitpunkt durchgeführt werden kann.

Die DE 10 207 222 A1 hat die zeitkonsistente Datenerfassung bei über den CAN Bus vernetzten Steuergeräten zum Thema. Durch das Buszugriffsverfahren CSMA-CA bedingt ist ein deterministischer Buszugriff unter den einzelnen Teilnehmern nicht möglich. Außerdem besteht das Problem, dass die verschiedenen Steuergeräte mit verschiedenen Taktraten arbeiten, so dass sich verschiedene Arbeitsgeschwindigkeiten ergeben.

Aus der EP 1 543 389 B1 ist es bekannt zur Synchronisation von über CAN-Bus vernetzten Steuergeräten Synchronisationsinformationen in die zu übertragenden Nutzdatenpakete einzufügen, so dass keine gesonderten Synchronisationsinformationen übertragen werden müssen. In dem Nutzdatenpaket wird die Information eingetragen, welcher Zeitschlitz in dem Steuergerät zur Abarbeitung kam, als das Datenpaket über den Bus gesendet wurde.

Aus der EP 3 015 227 A1 ist ein Verfahren zur Zeitsynchronisation von Uhren in

Steuergeräten, die in einem Netzwerk verteilt sind, bekannt. Bei dem Netzwerk handelt es sich um den Feldbus basierend auf dem EtherCAT Standard. Der Synchronisationsprozess wird per Interrupt von dem Master Controller gestartet.

Aus dem Bereich Ethernet sind verschiedene Protokolle zur Synchronisation von Uhren bekannt. Das bekannteste Network Time Protocol (NTP) ist ein Standard zur

Synchronisierung von Uhren in Computersystemen über paketbasierte

Kommunikationsnetze.

Die Erfindung setzt sich zum Ziel eine praktikable Umsetzung der in dem erwähnten CiA Dokument angedachten Lösung die Zeitsynchronisation in den CAN-Controller zu integrieren anzugeben.

Diese Aufgabe wird durch eine Vorrichtung zur Synchronisation von Uhren in Steuergeräten gemäß Anspruch 1 , ein Steuergerät gemäß Anspruch 1 1 , sowie ein Verfahren gemäß Anspruch 12, gelöst.

Die abhängigen Ansprüche beinhalten vorteilhafte Weiterbildungen und Verbesserungen der Erfindung entsprechend der nachfolgenden Beschreibung dieser Maßnahmen. Es wird eine vorteilhafte Hardware-Lösung für die Zeitsynchronisation im CAN Controller vorgeschlagen. Es werden die gemäß AUTOSAR-Standard vorgeschriebenen

Synchronisations-Botschaften genutzt. Dabei besteht eine Besonderheit der Lösung darin, dass die Vorrichtung eine Zeitstempeleinheit, eine Referenzzeit-Recheneinheit und einen Zwischenspeicher aufweist, wobei die Zeitstempeleinheit den Zeitpunkt der Ankunft einer Synchronisations-Botschaft nach der in der Vorrichtung vorhandenen lokalen Uhr erfasst, und diesen erfassten Zeitpunkt der Referenzzeit-Recheneinheit zur Verfügung stellt. Dabei werden die Synchronisations-Informationen die in den Synchronisations-Botschaften mitgeteilt werden, in dem Zwischenspeicher gesammelt werden und ebenfalls der

Referenzzeit-Recheneinheit zur Verfügung gestellt. Diese Lösung hat den Vorteil, dass die Netzwerkzeit, trotzdem, dass die Synchronisations-Botschaften nur periodisch in bestimmten Zeitabständen ankommen, mit Hilfe der erfassten Zeitstempel innerhalb des CAN-Controllers zu einem beliebigen Zeitpunkt berechnet werden kann. Das hat den Vorteil, dass für die Zeitsynchronisation auch zwischen den Synchronisationszeitpunkten eine hohe Genauigkeit erreicht werden kann, was sonst nicht der Fall ist. Aktionen, die von verschiedenen

Steuergeräten synchron durchgeführt werden müssen, sind damit zu beliebigen Zeitpunkten mit hoher Genauigkeit durchführbar.

Es ist von Vorteil, dass für die Vorrichtung ein Konfigurations-Register vorgesehen ist, das zur Einstellung der Berechnungsart der Zeitkorrekturwerte in der Referenzzeit-Recheneinheit dient. Es gibt verschiedene Methoden zur Berechnung der Netzwerkzeit, die bei AUTOSAR bereits angedacht sind. Diese können in der Referenzzeit-Recheneinheit vorgesehen werden. Über das Konfigurationsregister kann über die Applikationssoftware des

Steuergerätes die gewünschte Berechnungsart ausgewählt werden.

Wie beschrieben werden die Synchronisations-Botschaften im Format von dem AUTOSAR- Standard mit dem Titel„Specification of Time Synchronisation over CAN" entsprechend AUTOSAR CP Release 4.3.0 unterstützt. Dabei ist für die Übernahme der Daten in den Synchronisations-Botschaften SYNC und FUP ein Synchronisations-Register und für die Übernahme der Daten in den Synchronisations-Botschaften OFS und OFNS ein Offset- Register dem Zwischenspeicher vorgeschaltet. Dadurch kann sofort der Empfangspuffer des CAN-Controllers freigegeben werden für den Empfang weiterer Botschaften.

Die Architektur der Lösung mit Zeitstempeleinheit, Referenzzeit-Recheneinheit und

Zwischenspeicher ist sehr flexibel, so dass die Vorrichtung leicht weiter ausgebaut werden kann, wenn weitere Berechnungsarten unterstützt werden sollen. Bei AUTOSAR sind die beiden Ansätze„Rate Correction" und„Offset Correction" angedacht. Für die„Offset-Correction" sind die beiden Varianten„Jump Correction" und„Rate

Adaptation" angedacht. Dabei wird entweder eine Ratenanpassung vorgenommen oder aber es werden harte Sprünge bei der Synchronisierung in Kauf genommen. Beide

Berechnungsarten der Zeitkorrektur werden in der beschriebenen Lösung unterstützt.

Für die Implementierung gemäß des Vorschlages ist es von Vorteil, dass die

Zeitstempeleinheit lediglich das Eintreffen der Information in den Sychronisations-Botschaft SYNC mit einem Zeitstempel versieht. Die SYNC- Botschaft ist die erste für einen

Synchronisationszeitpunkt eintreffende Synchronisations-Botschaft. Für die anderen

Synchronisations-Botschaften braucht kein Zeitstempel erfasst zu werden. Die gesamte Verarbeitung der Synchronisations-Botschaften wird dadurch einfacher. Es braucht auch keine Schnittstelle zwischen Offset-Register und Zeitstempeleinheit vorgesehen werden.

Ebenfalls vorteilhaft ist, wenn zur Auslösung von zeitsynchronen Aktionen eine Interrupt- Generatoreinheit vorgesehen ist, die mit der Referenzzeit-Recheneinheit in Verbindung steht. Von der Referenzzeit-Recheneinheit bekommt die Interrupt-Generatoreinheit die genaue Netzwerkzeit. Diese wird in der Interrupt-Generatoreinheit genutzt um synchrone Aktionen durchzuführen. Dies kann durch Auslösung von Interrupts geschehen.

Dabei ist es von Vorteil, wenn für die Interrupt-Generatoreinheit ein Interruptkonfigurations- Register vorgesehen ist, über das einstellbar ist zu welchen Zeitpunkten oder mit welcher Zeitperiode ein Interrupt/Aktion ausgelöst werden soll.

Zusammengefasst gibt der Vorschlag eine besonders vorteilhafte Hardware- Implementierung für die Berechnung der Zeitkorrektur in einem lokalen Steuergerät eines Netzwerkes an. Dafür berechnet der CAN Controller das Taktverhältnis von seinem eigenen lokalen Takt zu dem Takt seines Synchronisationspartners. Dieses Taktverhältnis berechnet er aus zwei SYNC und Follow UP Nachrichten Paaren, die er über das Netz empfängt und seinem lokalen Eingangstaktsignal. Dies gilt unter der Annahme, dass sich der Offset welcher in den OFS und OFNS-Nachrichtenpaaren übermittelt wird im gleichen Zeitraum nicht ändert.

Bei bekanntem Taktverhältnis kann der CAN Controller unter Berücksichtigung des

Zeitoffsets, den er ebenfalls über das Netzwerk in den Synchronisations-Botschaften OFS und OFNS empfängt, zu einem beliebigen Zeitpunkt auf Basis seiner lokalen Zeit, und dem Eingangstaktsignal, die Netzwerkzeit berechnen. Der CAN-Controller kann dann die Zeitinformation über ein Register auslesbar machen. Zum anderen kann der CAN-Controller als Taktquelle nach der Netzwerkzeit dienen um so hochgenaue zeitsynchrone Operationen auszulösen.

Eine Erweiterung besteht darin, dass der CAN Controller beim Senden von Nachrichten diese automatisch mit aktuellen Zeitstempeln der Netzwerkzeit versieht.

Ein Ausführungsbeispiel der Erfindung ist in den Zeichnungen dargestellt und wird nachfolgend anhand der Figuren näher erläutert.

Es zeigen:

Fig. 1 ein Blockdiagramm für ein Fahrzeug-Bordnetzwerk mit Steuergeräten

verschiedener Kategorie;

Fig. 2 das Prinzip des Zeitsynchronisations-Prozesses mit Hilfe periodisch auftretender

Synchronisations-Nachrichten, wie er von AUTOSAR spezifiziert wurde; Fig. 3 die Gegenüberstellung zweier Varianten eines Blockschaltbildes einer CAN-

Busschnittstelle bei der die Funktion der Zeitsynchronisation einmal mit Hilfe von

Software und zum anderen mit Hardwaremitteln realisiert wurde;

Fig. 4 ein Blockschaltbild des Zeitsynchronisationsblocks im CAN-Controller, der bei der

Hardware-Lösung eingesetzt wird; und

Fig. 5 ein Diagramm, dass den Vergleich der verschiedenen Methoden der

Zeitkorrektur, die bei der Zeitsynchronisation einsetzbar sind, illustriert.

Die vorliegende Beschreibung veranschaulicht die Prinzipien der erfindungsgemäßen Offenbarung. Es versteht sich somit, dass Fachleute in der Lage sein werden, verschiedene Anordnungen zu konzipieren, die zwar hier nicht explizit beschrieben werden, die aber Prinzipien der erfindungsgemäßen Offenbarung verkörpern und in ihrem Umfang ebenfalls geschützt sein sollen.

Fig. 1 zeigt den typischen Aufbau eines Bordnetzwerkes eines modernen Kraftfahrzeuges. Mit der Bezugszahl 151 ist ein Motorsteuergerät bezeichnet. Die Bezugszahl 152 entspricht einem ESP-Steuergerät und die Bezugszahl 153 bezeichnet ein Getriebe-Steuergerät.

Weitere Steuergeräte wie ein Fahrdynamik-Steuergerät, usw. können im Kraftfahrzeug vorhanden sein. Die Vernetzung solcher Steuergeräte, die alle der Kategorie des

Antriebsstrangs zugerechnet werden, geschieht typischerweise mit dem CAN-Bussystem (Controller Area Network) 104 welches als ISO Norm standardisiert ist, ISO 1 1898. Da verschiedene Sensoren im Kraftfahrzeug installiert werden und diese nicht mehr nur an einzelne Steuergeräte angeschlossen werden, werden solche Sensordaten ebenfalls über das Bussystem 104 zu den einzelnen Steuergeräten übertragen. Beispiele von Sensoren im Kraftfahrzeug sind Raddrehzahlsensoren, Lenkwinkelsensoren, Beschleunigungssensoren, Drehratensensoren, Reifendrucksensoren, Abstandssensoren, Klopfsensoren,

Luftgütesensoren, usw. Die verschiedenen Sensoren mit dem das Fahrzeug ausgestattet ist, sind in der Figur 6 mit der Bezugszahl 161 , 162, 163 bezeichnet.

Das moderne Kraftfahrzeug kann aber noch weitere Komponenten aufweisen wie

Videokameras, z.B. als Rückfahrkamera oder als Fahrerüberwachungskamera als auch ein Radargerät für die Realisierung eines Radartempomaten oder zur Realisierung eines Abstandswarnungs- oder Kollisionswarnungsgerätes.

Im Kraftfahrzeug befinden sich dann auch noch weitere elektronische Vorrichtungen. Diese sind mehr im Bereich der Fahrgastzelle angeordnet und werden oft auch von dem Fahrer bedient. Beispiele sind eine Benutzerschnittstellenvorrichtung mit der der Fahrer Fahrmodi anwählen kann, aber auch klassische Komponenten bedienen kann. Darunter fallen

Gangwahl sowie auch Blinker-Steuerung, Scheibenwischersteuerung, Lichtsteuerung, usw. Diese Benutzerschnittstellenanordnung ist mit der Bezugszahl 130 versehen. Die

Benutzerschnittstellenanordnung 130 ist oft auch mit einem Dreh/Druckschalter ausgestattet, über den der Fahrer die verschiedenen Menüs anwählen kann die auf einem Display im Cockpit angezeigt werden. Andererseits fällt auch ein berührungsempfindliches Display in diese Kategorie. Selbst die Spracheingabe für die Bedienungsunterstützung fällt in diesen Bereich.

Davon unterschieden wird oft ein Navigationssystem 120, welches ebenfalls im Bereich des Cockpits verbaut wird. Die Route, welche auf einer Karte angezeigt wird, kann natürlich ebenfalls auf dem Display im Cockpit dargestellt werden. Weitere Komponenten, wie eine Freisprecheinrichtung können vorhanden sein, sind aber nicht näher dargestellt. Die

Bezugszahl 1 10 bezeichnet noch eine On-Board Unit. Diese On-Bord Unit 1 10 entspricht einem Kommunikationsmodul über das das Fahrzeug mobile Daten empfangen und senden kann. Typischerweise handelt es sich hier um ein Mobilfunk-Kommunikationsmodul, z. B. nach dem LTE-Standard. All diese Geräte sind dem Infotainment-Bereich zuzuordnen. Sie werden deshalb über ein auf die speziellen Bedürfnisse dieser Gerätekategorie ausgelegtes Bussystem 102 vernetzt. Es wird diesbezüglich auf die bereits erwähnten Bussysteme AVB (Audio Video Bridging), den MOST Bus (Media Oriented System Transport) oder den D2B Bus (Domestic Digital Bus) hingewiesen. Zu dem Zweck, das fahrzeugrelevante Sensordaten über die

Kommunikationsschnittstelle 1 10 zu einem anderen Fahrzeug oder zu einem Zentralrechner übertragen werden sollen, ist das Gateway 140 vorgesehen. Dieses ist mit beiden verschiedenen Bussystemen 102 und 104 verbunden. Das Gateway ist dazu ausgelegt die Daten, die es über den CAN-Bus 104 empfängt so umzusetzen, dass sie in das

Übertragungsformat des Infotainment-Busses 102 umgesetzt werden, so dass sie in den dort spezifizierten Paketen verteilt werden können. Für die Weiterleitung dieser Daten nach extern, also zu einem anderen Kraftfahrzeug oder zu einem Zentralrechner ist die On-Board- Unit 1 10 mit der Kommunikationsschnittstelle dazu ausgerüstet, diese Datenpakete zu empfangen und wiederum in das Übertragungsformat des entsprechend eingesetzten Mobilfunkstandards umzusetzen.

Fig. 2 zeigt jetzt den prinzipiellen Zeitsynchronisationsprozess, wie er von AUTOSAR spezifiziert wurde. Diesbezüglich wird für nähere Einzelheiten auf das AUTOSAR-Dokument „Specification of Time Synchronisation over CAN", AUTOSAR CP Release 4.3.0

hingewiesen. Im Prinzip geht es darum die lokalen Uhren, die in den einzelnen

Steuergeräten betrieben werden, mit der Zeit einer anderen Uhr oft als globale Zeit bezeichnet, zu synchronisieren. In diesem Zusammenhang werden die Steuergeräte, die jeweils mit lokaler Uhr ausgestattet sind, bei AUTOSAR als„Time-Slave" bezeichnet. Ein zentrales Steuergerät, bei AUTOSAR als„Time-Master" bezeichnet, gibt die Zeit vor, mit der die lokalen Uhren synchronisiert werden sollen. Bei der Übermittlung der

Synchronisationsinformation vom Time-Master an die Time-Slaves in einer Broadcast-CAN- Nachricht besteht das Problem, dass der Zeitwert aufgrund von CAN-spezifischen Effekten wie das spezielle Arbitnerungsverfahren und Software-spezifischen Verzögerungen, z.B. das Auftreten von Interrupts ungenau wird. Aus dem Grund wird bei AUTOSAR ein zweistufiger Prozess für die Zeitsynchronisation vorgeschlagen.

Dabei wird in einer per Broadcast übertragenen SYNC-Botschaft der zweite Teil (tOr) von der Zeitinformation die zur Synchronisation dient übertragen. CAN Botschaften sind in ihrer Größe des Nutzdatenfeldes auf 8 Byte begrenzt. Für die eigentlichen Zeitstempel bleibt sogar noch weniger Platz, darum muss die Zeitinformation geschickt auf mehrere

Botschaften aufgeteilt werden. Der zweite Teil (tOr) ist dabei der Teil in dem die Veränderung der Synchronisationszeit gegenüber des vorhergehenden Sychronisationsintervalls steckt. Dies entspricht also dem LSB-Teil der Synchronisationszeit. Der MSB-Teil kann länger gültig sein und wird mit größerem Zeitabstand aktualisiert. Im Beispiel des Bord-Netzwerkes von Fig. 1 übernimmt das Gateway 140 die Funktion des„Time-Masters". Um die genaue Zeit zu ermitteln wann die Synchronisationnachricht auf den Bus gegeben wird, wird eine CAN low- level Funktion genutzt, z.B. die Funktion„CAN transmit confirmation". Dabei wird ein

Zeitstempel erzeugt, wenn die„CAN transmit confirmation"-lnformation eingeht. Bei Empfang der SYNC-Botschaft in einem„Time Slave' -Steuergerät 151 , verwendet dieses ebenfalls einen CAN-Low-Level-Mechanismus, wie "CAN-receive indication", um den Zeitpunkt (t2r) zu bestimmen, wann die SYNC-Botschaft tatsächlich empfangen wurde.

In Fig. 2 ist tOr die Zeit, die als Synchronisationsinformation übertragen werden soll. Der zweite Teil dieser Zeit S(tOr) wird in der SYNC-Botschaft übertragen. Zum Zeitpunkt t1 r geht die SYNC-Botschaft raus. Der„Time-Master" erfasst dann noch einen Zeitstempel t1 r seiner Referenz-Uhr. Der Time-Master sendet dann noch eine zweite Botschaft per Broadcast an die„Time-Slaves". Es handelt sich um die sogenannte FUP-Botschaft entsprechend Follow- Up-Botschaft. Darin wird die Information t4r übertragen. Dabei entspricht die übertragene Information t4r dem Wert des Zeitstempels t1 r abzüglich der in der SYNC-Botschaft übertragenen Information s(tOr). Es gilt also: t4r = t1 r - s(tOr).

Die Information t4r entspricht dem Abstand zwischen der Zeitinformation, die in der vorhergehenden SYNC-Botschaft übertragen wurde und der tatsächlich ermittelten

Sendezeit t1 r für die SYNC-Botschaft. Für die FUP-Botschaft wird kein Zeitstempel genommen, weder auf der Sendeseite noch auf der Empfangsseite.

In dem Time-Slave 151 werden dann beide Informationen aus SYNC-Botschaft und FUP- Botschaft zusammengesetzt um die neue Zeit für die lokale Uhr zu berechnen. Dabei wird auch der zuvor ermittelte Zeitstempel t2r für die Ankunftszeit der SYNC-Botschaft benutzt. Es gilt:

New rel. Time = t3r - t2r + s(tOr) +t4r.

Die Bedeutung der Anteile t3r - t2r und s(tOr) + t4r ist in der Fig. 2 veranschaulicht.

AUTOSAR sieht auch die Verwendung von Offset-Synchronisations- Botschaften OFS und OFNS vor. Sie dienen zur Korrektur eines Offset-Wertes, um den die übermittelten Zeitwerte in den SYNC- Botschaften zu korrigieren sind. Die Korrekturwerte werden von dem Time- Master 140 in den OFS- und OFNS-Botschaften ebenfalls per Broadcast übertragen. Sowohl OFS als auch OFNS Botschaften enthalten eine Offset-Information, die allerdings auf Grund von Platz-Problemen, auf diese beiden Botschaften aufgeteilt werden muss.

Die Fig. 3 zeigt jetzt einen Vergleich der bei AUTOSAR vorgeschlagenen Implementierung der Zeitsynchronisation mit der hier neu vorgeschlagenen Implementierung. Dabei wird wieder von dem in Fig. 2 dargestellten Beispiel ausgegangen. Das Motorsteuergerät ist ein Time-Slave-Gerät, welches die Synchronisationsinformationen von dem Gateway 140 empfängt. Genauso werden aber auch die anderen Steuergeräte 152, 153 und Sensoren 161 , 162, 163 synchronisiert.

Im linken Teil ist die Software-Lösung dargestellt, wie sie bei AUTOSAR für die

Zeitsynchronisation vorgeschlagen wird. Mit der Bezugszahl 1510 ist die CAN-Schnittstelle des Motor-Steuergerätes 150 bezeichnet. Diese besteht aus den Hardware-Komponenten CAN-Controller 1513 und CAN-Transceiver (nicht dargestellt) und aus den beiden

Softwarekomponenten Applikations-Software 151 1 und der Zeitsynchronisations-Software 1512. Zwischen beiden Software-Komponenten gibt es eine Schnittstelle 1514.

Im rechten Teil ist die Hardware-Lösung dargestellt, wie sie hier für die Zeitsynchronisation vorgeschlagen wird. Mit der Bezugszahl 1520 ist die CAN-Schnittstelle des Motor- Steuergerätes 150 bezeichnet. Diese besteht aus den Hardware-Komponenten CAN- Controller 1513 und CAN-Transceiver (nicht dargestellt) und aus der Softwarekomponente Applikations-Software 1521. Statt des Softwareblocks 1512 ist in dem CAN-Controller 1522 ein Hardwareblock für die Zeitsynchronisation vorgesehen. Die Synchronisations- Botschaften 1516 (SYNC, FUP, OFS und OFNS) die vom Time-Master 140 stammen, werden in beiden Lösungen benutzt. Auch die weiteren CAN-Botschaften 1517 sind in beiden Fällen gleich. Bei der Software-Lösung gibt es eine Datenschnittstelle 1515 zwischen CAN-Controller 1513 und Software-Komponente 151 1. Neben der Datenschnittstelle 1523 zwischen CAN-Controller 1522 und Software-Komponente 1521 gibt es bei der Hardware- Lösung noch eine Registerschnittstelle 1524 zum Einstellen und Auslesen der Register des Hardwareblocks für die Zeitsynchronisation.

Fig. 4 zeigt die Struktur des Hardwareblocks für die Zeitsynchronisation gemäß der vorgeschlagenen Hardware-Lösung. Der Hardwareblock ist mit der Bezugszahl 1530 versehen. Die lokale Uhr wird durch einen Zähler gebildet, der mit dem lokalen Takt 2212 des Taktgebers getriggert wird. Zur Gewinnung von Zeitstempeln ist der Zähler mit einem Lokalzeit-Register 222 versehen. Die lokale Zeit kann von dem Mikrorechner des

Steuergerätes ausgelesen werden. Dafür ist ein entsprechender Bus 2213 an das Lokalzeit- Register 222 angeschlossen. Die Zeitstempel können in dem Zeitstempel-Register 226 erfasst werden. Das Zeitstempel-Register 226 ist dementsprechend über einen weiteren Bus 2218 mit dem Lokalzeit-Register 222 verbunden. Die SYNC- und FUP-Botschaften werden über den CAN-Bus 104 empfangen und die darin befindlichen

Synchronisationsinformationen (Zeitinformationen / Zeitstempel) werden in ein Sync-Register 228 übernommen. Dieses Sync-Register 228 steht über den Bus 2224 mit dem Zeitstempel- Register 226 in Verbindung. Bei Eintreffen der SYNC-Botschaft wird der Zeitstempel t2r erfasst, wie im Zusammenhang mit Fig. 3 erläutert. Der Zeitstempel wird über den Bus 2221 an eine Recheneinheit 221 zur Berechnung der globalen Netzwerkzeit weitergeleitet. Für die OFS- und OFNS-Botschaften gilt, dass sie über den CAN-Bus 104 empfangen werden und die darin befindlichen Synchronisationsinformationen (Zeitinformationen / Zeitstempel) in einem Offset-Register 229 übernommen werden. Dieses steht mit einem

Zwischenspeicherblock 227 über die Schnittstelle 2226 in Verbindung. In den

Zwischenspeicherblock 227 werden ebenfalls die Informationen von dem Sync-Register 228 übernommen. Dazu ist das Sync-Register 228 über die Schnittstelle 2225 mit dem

Speicherblock 227 verbunden. Der Speicherblock 227 dient dazu die über den Bus kommenden Werte in den SYNC-, FUP-, OFS- und OFNS-Botschaften zu sammeln und zu aggregieren. In einer Ausführungsform können die vier Teile der

Synchronisationsinformationen zu einem verwendbaren Zeitstempel zusammengerechnet werden. Dazu enthält der Zwischenspeicherblock eine kleine Recheneinheit. Dann kann die Recheneinheit 221 für die Berechnung der globalen Netzwerkzeit darauf zugreifen. Es reicht, wenn die Informationen von jeweils zwei aufeinanderfolgenden Synchronisationszyklen im Speicher bereitgestellt werden. Die Implementierung kann deshalb als Ringpuffer erfolgen, wobei die neuen Daten an einer Stelle zugeführt werden, und die abgespeicherten Daten an anderen Stelle entnommen werden. Bei Zuführung der Daten, werden die vorhandenen Daten überschrieben. Der Ringpuffer entspricht also einer Einheit zur Aggregation von Zeitinformationen.

Wie die Berechnung der globalen Netzwerkzeit in der Recheneinheit 221 funktioniert, wird nachfolgend mit Hilfe der Fig. 5 genauer erläutert. Hier können verschiedene

Berechnungsarten verwendet werden. Dazu ist die Recheneinheit 221 konfigurierbar ausgeführt. Es ist deshalb ein Konfigurationsregister 224 vorhanden. Dieses kann über die Anwendungssoftware 1521 eingestellt werden. Es ist dazu eine Busschnittstelle 2214 vorgesehen. Das Konfigurationsregister 224 steht über die Schnittstelle 2219 mit der Recheneinheit 221 in Verbindung. An die Recheneinheit 221 ist noch ein Interrupt-Generator 223 über den Bus 2220 angeschlossen. Der Interrupt-Generator 223 erzeugt Interrupts / Events, für zeitkritische Aktionen, die mit der globalen Netzwerkzeit gesteuert werden. Dazu wird die Netzwerkzeit über die Schnittstelle 2200 dem Interrupt-Generator 223 zur Verfügung gestellt. Der

Interrupt-Generator kann deshalb eine Timer/Counter-Einheit beinhalten, die zeitkritische Aktionen auslöst. Der Interrupt-Generator 223 ist deshalb auch programmierbar ausgelegt. Die Programmierung erfolgt über das Interrupt-Konfigurationsregister 225. Dieses Register 225 wird über die Anwendungssoftware programmiert. Dazu ist die entsprechende

Busschnittstelle 2217 dargestellt.

Fig. 5 zeigt die verschiedenen Methoden zur Synchronisation der lokalen Uhr 222 des Steuergerätes 151 . Entlang der Abszisse ist die lokale Zeit t aufgetragen; entlang der Ordinate ist die Netzwerkzeit t _n aufgetragen. Die Kurve B zeigt den Lauf der lokalen Uhr 222. Da die lokalen Uhr 222 mit dem lokalen Takt, betrieben wird, der von dem lokalen Quartz- Oszillator abgeleitet wird, ergibt sich eine zu große Steigung für die Kurve B. Durch die Synchronisierung wird der lokale Takt nicht verändert. Die Uhr 222 wird deshalb zu den Synchronisationszeitpunkten immer wieder nachgestellt, wird aber nach kurzer Zeit entweder wieder vorgehen, wenn die lokale Uhr im Slave schneller läuft als die Uhr im Time-Master oder nachgehen, wenn die lokale Uhr im Slave langsamer läuft als die Uhr im Time-Master. Das Synchronisationsintervall beträgt z.B. 125 ms. Der Messpunkt M(t1 , tn1 m) entspricht dem korrekten Wert der Netzwerkzeit, der sich über die Synchronisations-Botschaften SYNC, FUP, OFS und OFNS und dem dazu erfassten Zeitstempel t1 ergibt. Es ist praktisch der Sollwert. Der Punkt ACNT entspricht dem zu dem Synchronisationszeitpunkt in dem Steuergerät errechneten Wert für die Netzwerkzeit. Dieser ist aber mit einem Fehler behaftet, so dass eine Korrektur erforderlich ist. Ein Synchronisationszeitpunkt ist in Fig. 5 mit t1 bezeichnet. Der folgende Synchronisationszeitpunkt ist in Fig. 5 mit dem Zeitpunkt t2e angegeben. Zuvor war der Synchronisationszeitpunkt der Zeitpunkt tO, dieser ist aber in Fig. 5 nicht dargestellt.

Mit Kurve A ist der vom Time-Slave angenommene korrekte Lauf der globalen Netzwerkzeit illustriert. Genau genommen, ist es nicht der korrekte Lauf, sondern der, den der Slave mutmaßlich für den korrekten Verlauf hält. Dieser weicht auf Grund von Fehlern vom tatsächlichen, realen Verlauf ab, den ein potenzieller omnipräsenter Beobachter sehen könnte. Es ist deutlich das Auseinanderdriften der Zeit zwischen lokaler Uhr 222 und globaler Netzwerkzeit zu erkennen. Dabei müssen beide Uhren keine Absolutzeitwerte mit UTC- Bezug angeben. Im Bereich der Steuergeräte ist es üblich eine relative Zeit zu verwenden, etwa die Zeit nach dem Fahrzeugstart. Für einige Anwendungen ist der UTC-Bezug aber wünschenswert.

Zur Zeitkorrektur der lokalen Uhr werden bei AUTOSAR verschiedene Mechanismen vorgeschlagen. Diese sind„Rate Correction",„Rate Adaptation" und„Jump Correction". Die Kurve C veranschaulicht die Methode der "Rate Correction". Nach dieser Methode wird die lokale Zeit, wann immer sie ausgelesen wird nach folgender Formel korrigiert: t _n (t) = r ₁ * (t - ti) + t _nla bei t > t _x mit dem folgenden„Rate Correction"-Faktor Γ . tnlm ~ tnOm

r _x =

t ₁ — t ₀

Dabei sind die Werte und t _nla aus Fig. 5 ersichtlich. Die Werte t _n0m und t ₀ sind in Fig. 5 nicht eingezeichnet, entsprechen aber den Messwerten des vorhergehenden Intervalls. Sie sind in dem Speicherblock 227 noch verfügbar und können für die Berechnung von dort

übernommen werden. Wie mit Kurve C gezeigt, wird durch die Methode der„Rate

Correction" zwar die Steigung der Kurve B ab dem Zeitpunkt korrigiert, jedoch sind alle Werte, die auf diese Art und Weise korrigiert wurden noch um den Fehler εΐ zu groß.

Das Ergebnis der Korrektur nach der Methode der„Rate Adaptation" ist in Fig. 5 bei Kurve D ersichtlich. Dabei erfolgt neben der Korrektur nach der Methode„Rate Correction" noch eine weitere Korrektur, die praktisch über das laufende Synchronisationsintervall den Fehler ε1 ausgleicht. Die Berechnungsformeln für die Methode der„Rate Adaptation" lauten wie folgt: t _n (t) = a _x * (t— t _x ) + t _nla bei t > t _x und m ₁ = a _x mit dem folgenden„Rate Adaptation' -Faktor ai. a = .

Dabei ist t _2e der Zeitpunkt der von dem Time-Slave errechnet wird. Es handelt sich um den Wert nach der lokalen Uhr zu dem der nächste Synchronisationszeitpunkt zu erwarten ist, s. unten. Für die in Fig. 5 angegebenen Winkel gilt die folgende Beziehung:

Ύι ⁼ ßi ^{~ a} i ⁼ arctan(m ₀ )— ai-ctan^).

Mit ar.

tn, 2e - t,nla

dabei entspricht mo. der nach der gleichen Formel wie ai berechneten Steigung aus dem vorhergehenden Synchronisationsintervall.

In Fig. 5 ist noch eine dritte Methode der Korrektur dargestellt. Diese Methode enthält neben der„Rate Correction" noch einen Schritt der als„Jump Correction" bezeichnet wird. Nach der „Rate Correction" bleibt noch der Fehler ei erhalten. Dieser wird im Schritt der Jump

Correction von dem zum Zeitpunkt t1 abgelesenen Wert der lokalen Uhr mit den Koordinaten {t tina), s. Fig. 5 abgezogen. Dann liegen die korrigierten Werte auf der Kurve A, die den Verlauf der Netzwerkzeit t„ über der lokalen Zeit t wiedergibt. Die folgenden Formeln werden für diese Korrekturmethode eingesetzt: t _n (t) = r ₁ * (t— ti) + t _nlm bei t > t und m. = r wobei für r wieder gilt, s. oben:

Der nächste zu erwartende Synchronisationszeitpunkt t _2e wird nach folgender Formel berechnet:

t _2e = r ₁ * t ^■ s.ync wobei für r wieder gilt, s. oben:

Für den Fehlerwert ει gilt:

= nla - t,nlm- Grundsätzlich ist die Methode der Rate Adaptation zu bevorzugen. Allerdings ist sie nur anwendbar, wenn die folgenden Bedingungen für die Winkel eingehalten werden:

\Y\ ^ Ymax -

Die Offenbarung ist nicht auf die hier beschriebenen Ausführungsbeispiele beschränkt. Es gibt Raum für verschiedene Anpassungen und Modifikationen, die der Fachmann aufgrund seines Fachwissens als auch zu der Offenbarung zugehörend in Betracht ziehen würde.

Alle hierin erwähnten Beispiele wie auch bedingte Formulierungen sind ohne Einschränkung auf solche speziell angeführten Beispiele zu verstehen. So wird es zum Beispiel von

Fachleuten anerkannt, dass das hier dargestellte Blockdiagramm eine konzeptionelle Ansicht einer beispielhaften Schaltungsanordnung darstellt. In ähnlicher Weise ist zu erkennen, dass ein dargestelltes Flussdiagramm, Zustandsübergangsdiagramm, Pseudocode und dergleichen verschiedene Varianten zur Darstellung von Prozessen darstellen, die im

Wesentlichen in computerlesbaren Medien gespeichert und somit von einem Computer oder Prozessor ausgeführt werden können.

Es sollte verstanden werden, dass das vorgeschlagene Verfahren und die zugehörigen Vorrichtungen in verschiedenen Formen von Hardware, Software, Firmware,

Spezialprozessoren oder einer Kombination davon implementiert werden können.

Spezialprozessoren können anwendungsspezifische integrierte Schaltungen (ASICs), Reduced Instruction Set Computer (RISC) und / oder Field Programmable Gate Arrays (FPGAs) umfassen. Vorzugsweise wird das vorgeschlagene Verfahren und die Vorrichtung als eine Kombination von Hardware und Software implementiert. Die Software wird vorzugsweise als ein Anwendungsprogramm auf einer Programmspeichervorrichtung installiert. Typischerweise handelt es sich um eine Maschine auf Basis einer

Computerplattform die Hardware aufweist, wie beispielsweise eine oder mehrere

Zentraleinheiten (CPU), einen Direktzugriffsspeicher (RAM) und eine oder mehrere

Eingabe/Ausgabe (I/O) Schnittstelle(n). Auf der Computerplattform wird typischerweise außerdem ein Betriebssystem installiert. Die verschiedenen Prozesse und Funktionen, die hier beschrieben wurden, können Teil des Anwendungsprogramms sein, oder ein Teil der über das Betriebssystem ausgeführt wird. Bezugszeichenliste

100 Kfz-Elektronik

102 Infotainment-Bus

104 CAN-Bus

105 Kamera

1 10 On-Board Unit

120 Navigationssystem

130 Bedienungseinheit

140 Gateway

151 Motor-Steuergerät

152 ESP-Steuergerät

153 Getriebe-Steuergerät

161 Sensor 1

162 Sensor 2

163 Sensor 3

221 Netzwerkzeit-Recheneinheit

222 Lokalzeit-Register

223 Interrupt-Generator

224 Konfigurations-Register

225 Interrupt Konfigurations-Register

226 Zeitstempel-Erfassungseinheit

227 Zwischenspeicher

228 Synchronisations-Register

229 Offset-Register

1510 1. Architektur CAN-Busschnittstelle

151 1 1. Applikations-Software

1512 Zeitsynchronisations-Software

1513 1. CAN-Controller

1514 1. Schnittstelle

1515 2. Schnittstelle

1516 3. Schnittstelle

1517 4. Schnittstelle

1520 2. Architektur CAN-Busschnittstelle

1521 2. Applikations-Software

1522 2. CAN-Controller 1523 5. Schnittstelle

1525 6. Schnittstelle

1526 7. Schnittstelle

2210 8. Schnittstelle

221 1 9. Schnittstelle

2212 10. Schnittstelle

2213 1 1 . Schnittstelle

2214 12. Schnittstelle

2215 13. Schnittstelle

2216 14. Schnittstelle

2217 15. Schnittstelle

2218 16. Schnittstelle

2219 17. Schnittstelle

2220 18. Schnittstelle

2221 19. Schnittstelle

2222 20. Schnittstelle

2223 21 Schnittstelle

2224 22 Schnittstelle

2225 23 Schnittstelle

2226 24 Schnittstelle