DE102017209328A1

DE102017209328A1 - Vorrichtung zur Synchronisation von Uhren in Steuergeräten und Steuergerät

Info

Publication number: DE102017209328A1
Application number: DE102017209328.5A
Authority: DE
Inventors: Alexander Meier
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2017-06-01
Filing date: 2017-06-01
Publication date: 2018-12-06
Also published as: WO2018234006A1

Abstract

Die Erfindung betrifft ein aufwandgünstiges Hardware-Architekturkonzept für die Durchführung der Synchronisation von Steuergeräten (151, 152, 153), die über den CAN-Bus (104) vernetzt sind. Für die Synchronisation sind nach dem AUTOSAR-Standard die Synchronisation-Botschaften SYNC, FUP, OFS und OFNS vorgesehen. Das Architekturkonzept sieht eine Zeitstempeleinheit (226), Referenzzeit-Recheneinheit (221) und einen Zwischenspeicher (227) vor. Die Zeitstempeleinheit (226) erfasst den Zeitpunkt der Ankunft einer Synchronisations-Botschaft nach der lokalen Uhr (222) des Steuergerätes und stellt diese Information der Referenzzeit-Recheneinheit (221) zur Verfügung.

Description

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 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 pä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 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, sowie ein Steuergerät gemäß Anspruch 11 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 AUOTSAR 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:

1 ein Blockdiagramm für ein Fahrzeug-Bordnetzwerk mit Steuergeräten verschiedener Kategorie;
2 das Prinzip des Zeitsynchronisations-Prozesses mit Hilfe periodisch auftretender Synchronisations-Nachrichten, wie er von AUTOSAR spezifiziert wurde;
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;
4 ein Blockschaltbild des Zeitsynchronisationsblocks im CAN-Controller, der bei der Hardware-Lösung eingesetzt wird; und
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.
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 11898. 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 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 110 bezeichnet noch eine On-Board Unit. Diese On-Bord Unit 110 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 110 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 110 mit der Kommunikationsschnittstelle dazu ausgerüstet, diese Datenpakete zu empfangen und wiederum in das Übertragungsformat des entsprechend eingesetzten Mobilfunkstandards umzusetzen.
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 Arbitrierungsverfahren 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 (t0r) 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 (t0r) 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 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“-Information 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 2 ist t0r die Zeit, die als Synchronisationsinformation übertragen werden soll. Der zweite Teil dieser Zeit S(t0r) wird in der SYNC-Botschaft übertragen. Zum Zeitpunkt t1r geht die SYNC-Botschaft raus. Der „Time-Master“ erfasst dann noch einen Zeitstempel t1r 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 t1r abzüglich der in der SYNC-Botschaft übertragenen Information s(t0r). Es gilt also: $t4r = t1r - s (t0r) .$
Die Information t4r entspricht dem Abstand zwischen der Zeitinformation, die in der vorhergehenden SYNC-Botschaft übertragen wurde und der tatsächlich ermittelten Sendezeit t1r 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 (t0r) + t4r .$
Die Bedeutung der Anteile t3r - t2r und s(t0r) + t4r ist in der 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 3 zeigt jetzt einen Vergleich der bei AUTOSAR vorgeschlagenen Implementierung der Zeitsynchronisation mit der hier neu vorgeschlagenen Implementierung. Dabei wird wieder von dem in 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 1511 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 1511. 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.
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 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 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.
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, tn1m) 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 5 mit t1 bezeichnet. Der folgende Synchronisationszeitpunkt ist in 5 mit dem Zeitpunkt t2e angegeben. Zuvor war der Synchronisationszeitpunkt der Zeitpunkt t0, dieser ist aber in 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_{1} * (t - t_{1}) + t_{n 1 a} b e i t \geq t_{1}$
mit dem folgenden „Rate Correction“-Faktor r₁: $r_{1} = \frac{t_{n 1 m} - t_{n 0 m}}{t_{1} - t_{0}}$
Dabei sind die Werte t₁ und t_n1a aus 5 ersichtlich. Die Werte t_n0m und t₀ sind in 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 t₁ korrigiert, jedoch sind alle Werte, die auf diese Art und Weise korrigiert wurden noch um den Fehler ε1 zu groß.
Das Ergebnis der Korrektur nach der Methode der „Rate Adaptation“ ist in 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_{1} * (t - t_{1}) + t_{n 1 a} b e i t \geq t_{1} u n d m_{1} = a_{1}$
mit dem folgenden „Rate Adaptation“-Faktor a₁: $a_{1} = \frac{t_{n 2 e} - t_{n 1 a}}{t_{2 e} - t_{1}} .$
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 5 angegebenen Winkel gilt die folgende Beziehung: $γ_{1} = β_{1} - α_{1} = arctan (m_{0}) - arctan (a_{1}) .$
Mit a₁: $a_{1} = \frac{t_{n 2 e} - t_{n 1 a}}{t_{2 e} - t_{1}}$
dabei entspricht m₀: der nach der gleichen Formel wie a₁ berechneten Steigung aus dem vorhergehenden Synchronisationsintervall.
In 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 ε1 erhalten. Dieser wird im Schritt der Jump Correction von dem zum Zeitpunkt t1 abgelesenen Wert der lokalen Uhr mit den Koordinaten (t₁, t_1na), s. 5 abgezogen. Dann liegen die korrigierten Werte auf der Kurve A, die den Verlauf der Netzwerkzeit t_n über der lokalen Zeit t wiedergibt. Die folgenden Formeln werden für diese Korrekturmethode eingesetzt: $t_{n} (t) = r_{1} * (t - t_{1}) + t_{n 1 m} b e i t \geq t_{1} u n d m_{1} = r_{1}$
wobei für r₁ wieder gilt, s. oben: $r_{1} = \frac{t_{n 1 m} - t_{n 0 m}}{t_{1} - t_{0}} .$
Der nächste zu erwartende Synchronisationszeitpunkt t_2e wird nach folgender Formel berechnet: $t_{2 e} = r_{1} * t_{s y n c} + t_{1}$
wobei für r₁ wieder gilt, s. oben: $r_{1} = \frac{t_{n 1 m} - t_{n 0 m}}{t_{1} - t_{0}} .$
Für den Fehlerwert ε₁ gilt: $ε_{1} = t_{n 1 a} - t_{n 1 m} .$
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: $α \leq α_{m a x}$
$α \geq α_{m i n}$
$ε \leq ε_{m a x}$
$| γ | \leq γ_{m a x} .$
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
110: 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
1511: 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
2211: 9. Schnittstelle
2212: 10. Schnittstelle
2213: 11. 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

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 10207222 A1 [0010]
EP 1543389 B1 [0011]
EP 3015227 A1 [0012]

Zitierte Nicht-Patentliteratur

ISO Norm [0032]
ISO 11898 [0032]

Claims

Vorrichtung zur Synchronisation von Uhren in Steuergeräten (151, 152, 153), die über einen Kommunikationsbus (104) miteinander vernetzt sind, wobei die Steuergeräte (151, 152, 153) eine lokale Uhr (222) aufweisen, die periodisch mit einer globalen Uhr synchronisiert wird, wobei zur Synchronisierung periodisch Synchronisations-Botschaften, von einem Referenz-Zeitgeber (140) über den Kommunikationsbus (104) empfangen werden, dadurch gekennzeichnet, dass die Vorrichtung eine Zeitstempeleinheit (226) und eine Referenzzeit-Recheneinheit (221) und einen Zwischenspeicher (227) aufweist, wobei die Zeitstempeleinheit (226) den Zeitpunkt der Ankunft einer Synchronisations-Botschaft nach der lokalen Uhr (222) erfasst, und diesen erfassten Zeitpunkt der Referenzzeit-Recheneinheit (221) zur Verfügung stellt, wobei die Synchronisations-Informationen in den Synchronisations-Botschaften in dem Zwischenspeicher (227) gesammelt werden und ebenfalls der Referenzzeit-Recheneinheit (221) zur Verfügung gestellt werden.
Vorrichtung nach Anspruch 1, wobei ein Konfigurations-Register (224) vorgesehen ist, das zur Einstellung von Parametern und der Berechnungsart der Zeitkorrekturwerte in der Referenzzeit-Recheneinheit (221) dient.
Vorrichtung nach Anspruch 1 oder 2, wobei der Kommunikationsbus (104) als CAN Bus oder als CAN FD Bus entsprechend Controller Area Network und Controller Area Network Flexible Data Rate ausgeführt ist, und wobei die Synchronisations-Botschaften im Format von dem AUTOSAR-Standard mit dem Titel „Specification of Time Synchronisation over CAN“ entsprechend AUOTSAR CP Release 4.3.0 empfangen werden, wobei für die Übernahme der Daten in den Synchronisations-Botschaften SYNC und FUP ein Synchronisations-Register (228) und für die Übernahme der Daten in den Synchronisations-Botschaften OFS und OFNS ein Offset-Register (229) dem Zwischenspeicher (226) vorgeschaltet ist.
Vorrichtung nach Anspruch 3, wobei der Zwischenspeicher zur Aggregation der einzelnen Anteile in den Synchronisationsbotschaften SYNC, FUP und OFS, OFNS dient.
Vorrichtung nach Anspruch 3 oder 4, wobei über das Konfigurations-Register (224), die im AUTOSAR-Standard erwähnten Berechnungsarten „Rate Correction“ und „Offset Correction“ einstellbar sind.
Vorrichtung nach Anspruch 5, wobei über das Konfigurations-Register (224), die im AUTOSAR-Standard erwähnte Berechnungsart „Offset Correction“ nach den beiden Varianten „Jump Correction“ und „Rate Adaptation“ einstellbar ist.
Vorrichtung nach einem der Ansprüche 3 bis 6, wobei die Zeitstempeleinheit wenigstens das Eintreffen der Information in der Sychronisations-Botschaft SYNC mit einem Zeitstempel versieht.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei weiterhin zur Auslösung von zeitsynchronen Aktionen eine Interrupt-Generatoreinheit (223) vorgesehen ist, die mit der Referenzzeit-Recheneinheit (221) in Verbindung steht.
Vorrichtung nach Anspruch 8, wobei für die Interrupt-Generatoreinheit (223) ein Interruptkonfigurations-Register (225) vorgesehen ist, über das einstellbar ist zu welchen Zeitpunkten oder mit welcher Zeitperiode ein Interrupt ausgelöst werden soll.
Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Referenzzeit-Recheneinheit (221) eine Netzwerkzeit berechnet und wobei ein Register (225) vorgesehen ist, in das die berechnete Netzwerkzeit zum einfachen Auslesen für weitere Komponenten übernommen wird.
Steuergerät, dadurch gekennzeichnet, dass das Steuergerät eine Vorrichtung nach einem der Ansprüche 1 bis 10 aufweist.