DE102018205392A1 - Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten - Google Patents

Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten Download PDF

Info

Publication number
DE102018205392A1
DE102018205392A1 DE102018205392.8A DE102018205392A DE102018205392A1 DE 102018205392 A1 DE102018205392 A1 DE 102018205392A1 DE 102018205392 A DE102018205392 A DE 102018205392A DE 102018205392 A1 DE102018205392 A1 DE 102018205392A1
Authority
DE
Germany
Prior art keywords
task
interval
execution
communication
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018205392.8A
Other languages
English (en)
Inventor
Peter Haefele
Ranjith Kumar Venugopalan
Lou Guillot
Simon Kramer
Uwe Hartmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102018205392.8A priority Critical patent/DE102018205392A1/de
Priority to KR1020190040563A priority patent/KR20190118522A/ko
Priority to JP2019073938A priority patent/JP2019194848A/ja
Priority to CN201910280268.8A priority patent/CN110362413A/zh
Priority to US16/379,218 priority patent/US11048575B2/en
Publication of DE102018205392A1 publication Critical patent/DE102018205392A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/20Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24Handling requests for interconnection or transfer for access to input/output bus using interrupt
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • G06F11/0754Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/20Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/543User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation, bei dem zu kommunizierende Daten in einem Datenübertragungsintervall (K) durch Lesen aus einem ersten Datenbereich zur temporären Datenspeicherung und Speichern der gelesenen Daten in einem zweiten Datenbereich zur temporären Datenspeicherung zwischen einem ersten Task (T1) und einem zweiten Task (T2) kommuniziert werden, dadurch gekennzeichnet, dass ein Zeitintervall (11) für eine Ausführung des ersten Tasks (T1) und ein Kommunikationsintervall (12) für eine Ausführung des zweiten Tasks (T2) vorgegeben werden, wobei
a) eine Ausführung des Datenübertragungsintervalls (K) in einem Kommunikationsintervall (12) ausgelassen wird, wenn ein erster Task (T1) zeitlich unmittelbar vor dem Kommunikationsintervall (12) in einem letzten der Zeitintervalle (11) eines dem Kommunikationsintervall (12) unmittelbar vorhergehenden Kommunikationsintervalls (12) begann, über einen Endzeitpunkt (t6) dieses letzten Zeitintervalls (11) hinaus fortgesetzt wird und eine Ausführung eines zweiten Tasks (T2) des Kommunikationsintervalls (12) bereits begann, oder
b) eine Ausführung des Datenübertragungsintervalls (K) in einem Kommunikationsintervall (12) ausgelassen wird, wenn ein zweiter Task (T2) in einem dem Kommunikationsintervall (12) zeitlich unmittelbar vorhergehenden Kommunikationsintervall (12) begann, über einen Endzeitpunkt (t6) des vorhergehenden Kommunikationsintervalls (12) hinaus fortgesetzt wird, und eine Ausführung des ersten Tasks (T1) im Kommunikationsintervall (12) bereits begann.

Description

  • Stand der Technik
  • Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen Software Komponenten verteilt auf zwei oder mehr Tasks, die insbesondere in Zeitintervallen mit unterschiedlicher vorgegebener Zykluszeit ausgeführt werden.
  • Bedingt durch Fehler kann das Ende einer Zykluszeit, d.h. eines Zeitintervalls erreicht sein, bevor ein Task beendet ist, dessen Ergebnis zum Ende des Zeitintervalls an einen anderen Task übergeben werden soll. Für derartige Fehler ist eine deterministische Fehlerbehandlung wünschenswert.
  • Offenbarung der Erfindung
  • Diese wird durch das Verfahren und die Vorrichtung nach den unabhängigen Ansprüchen erreicht. Ein Computerprogramm und ein Computerprogrammprodukt sind ebenfalls vorgesehen.
  • Bezüglich des Verfahrens zur Fehlerbehandlung in einer Kommunikation, bei dem zu kommunizierende Daten in einem Datenübertragungsintervall durch Lesen aus einem ersten Datenbereich zur temporären Datenspeicherung und Speichern der gelesenen Daten in einem zweiten Datenbereich zur temporären Datenspeicherung zwischen einem ersten Task und einem zweiten Task kommuniziert werden, wird ein Zeitintervall für eine Ausführung des ersten Tasks und ein Kommunikationsintervall für eine Ausführung des zweiten Tasks vorgegeben, wobei
    1. a) eine Ausführung des Datenübertragungsintervalls in einem ersten Kommunikationsintervall ausgelassen wird, wenn ein erster Task zeitlich unmittelbar vor dem ersten Kommunikationsintervall in einem letzten Zeitintervall eines dem Kommunikationsintervall unmittelbar vorhergehenden Kommunikationsintervalls begann, über einen Endzeitpunkt dieses letzten Zeitintervalls hinaus fortgesetzt wird und eine Ausführung eines zweiten Tasks des ersten Kommunikationsintervalls bereits begann, oder
    2. b) eine Ausführung des Datenübertragungsintervalls in einem ersten Kommunikationsintervall ausgelassen wird, wenn ein zweiter Task in einem dem ersten Kommunikationsintervall zeitlich unmittelbar vorhergehenden zweiten Kommunikationsintervall begann, über einen Endzeitpunkt des vorhergehenden zweiten Kommunikationsintervalls hinaus fortgesetzt wird, und eine Ausführung des ersten Tasks im ersten Kommunikationsintervall bereits begann.
  • Das Zeitintervall und das Kommunikationsintervall sind logische Intervalle eines Schedulers, die auf festen Zeitscheiben beruhen und nicht verschoben werden können. Die angegebene Implementierung des Schedulers erzwingt jedoch nicht die Einhaltung der logischen Intervalle, sondern betrachtet ein tatsächliches Intervall erst dann als abgeschlossen, wenn der Scheduler eine Taskausführung in einem auf dieses tatsächliche Intervall unmittelbar folgenden neuen Intervall auch wirklich durchführt. Dadurch ist eine deterministische Kommunikation auch bei Lastspitzen möglich, welche ein Rechensystem so beeinträchtigen, dass Tasks ein Ende eines ihnen für ihre Ausführung zugeordneten logischen Intervalls nicht einhalten können. Dies ermöglicht eine effiziente Fehlerbehandlung, mit unterschiedlichen spezifischen Details abhängig von Kategorien mit unterschiedlicher vorgegebener, statischer, Task-Verteilung und Task-Scheduling. Dies ist ein wirksames Fehlerbehandlungskonzept für einen sporadischen Ausfall von Taskausführungen.
  • Vorzugsweise wird der Beginn des Datenübertragungsintervalls durch das Ende einer Ausführung des ersten Tasks ausgelöst, wenn die Ausführung des ersten Tasks später endet als eine Ausführung des zweiten Tasks, oder dass der Beginn des Datenübertragungsintervalls durch das Ende einer Ausführung des zweiten Tasks ausgelöst wird, wenn die Ausführung des zweiten Tasks später endet als eine Ausführung des ersten Tasks.
  • Vorzugsweise wird wenn eine Ausführung des ersten Tasks über ein Ende eines des Kommunikationsintervalls hinaus andauert, in dem die Ausführung des ersten Tasks begann, und wenn der Beginn des Datenübertragungsintervalls durch das Ende der Ausführung des ersten Tasks ausgelöst wird, eine unmittelbar auf die Ausführung des ersten Tasks folgende Ausführung des zweiten Tasks bis zum Ende des Datenübertragungsintervalls verzögert. Damit treten keine inkonsistenten Daten auf.
  • Vorzugsweise unterbleibt, wenn eine Ausführung des zweiten Tasks über ein Ende des Kommunikationsintervalls hinaus andauert, in dem die Ausführung des zweiten Tasks begann, und wenn der Beginn des Datenübertragungsintervalls durch das Ende der Ausführung des ersten Tasks ausgelöst wird, eine Auslösung des Datenübertragungsintervalls in diesem Kommunikationsintervall. Damit treten keine inkonsistenten Daten auf.
  • Vorzugsweise werden die zu kommunizierende Daten im Datenübertragungsintervall durch eine oder mehrere Instanzen außerhalb einer Hardware zur Ausführung des ersten Tasks und des zweiten Tasks kommuniziert. Durch die Auslagerung der Kommunikationsaufgabe an eine oder mehrere Instanzen ist eine deterministische Abarbeitung beispielsweise durch Direct Memory Access, DMA, oder Interrupt Service Routines, ISR, gewährleistet.
  • Die genannten Fehlerbehandlungskonzepte stellen sicher, dass die Datenkonsistenz jederzeit gewährleistet ist. Transaktionen zur Kommunikation oder Ausführungen von Tasks entfallen nur dann, wenn die Datenkonsistenz ansonsten nicht mehr gewährleistet werden kann. Die Fehlerbehandlungskonzepte ermöglichen eine Reduktion der Systemlast durch den Ausfall einzelner Taskausführungen und den Ausfall einzelner Transaktionen zur Erhöhung einer Robustheit des Gesamtsystems. Die Fehlerbehandlungskonzepte können auf Scheduling Information zugreifen um Laufzeitfehler wie mehrfache Prozessaktivierungen zu erkennen.
  • Vorzugsweise ist eine Dauer des Kommunikationsintervalls ein ganzzahliges Vielfaches einer Dauer für das Zeitintervall, wobei ein Kommunikationsintervall mehrere Zeitintervalle umfasst, wobei ein frühestes der mehreren Zeitintervalle zeitgleich mit dem Kommunikationsintervall beginnt. Damit sind die logischen Intervalle synchron.
  • Vorzugsweise beginnen während eines Kommunikationsintervalls wenigstens ein Zeitintervall, wobei sich Zeitintervalle zeitlich nicht überlappen, wobei das Datenübertragungsintervall entweder vor einer ersten Ausführung des ersten Tasks im frühesten der Zeitintervalle endet, oder nach Ende einer letzten Ausführung des ersten Tasks im spätesten der Zeitintervalle beginnt. Durch ein kooperatives Scheduling wird gewährleistet, dass die Kommunikation vollständig abgeschlossen ist, bevor die erste Taskausführung im neuen Intervall stattfindet. Im präemptiven Scheduling ist durch den Scheduler gewährleistet, dass keine Unterbrechung durch die beteiligten Prozesse stattfindet und Prozesse mit niedererer Priorität ggf. verdrängt werden.
  • Vorzugsweise wird eine Statusvariable abhängig von einem ersten Zustand der Ausführung der ersten Prozesse und abhängig von einem zweiten Zustand der Ausführung der zweiten Prozesse bestimmt, wobei das Datenübertragungsintervall abhängig von einem Wert der Statusvariablen gestartet wird. Die Statusvariable wird beispielsweise mittels eines ersten Zählerstands eines ersten Zustandszählers für den ersten Zustand und mittels eines zweiten Zählerstands eines zweiten Zustandszählers für den zweiten Zustand bestimmt.
  • Vorteilhafterweise wird der erste Zustandszähler korrigiert, wenn einer der ersten Prozesse in einem Kommunikationsintervall ausfällt, weil einer der ersten Prozesse, die während des Kommunikationsintervalls ablaufen sollen, mit Ausnahme des letzten der ersten Prozesse, die während des Kommunikationsintervalls ablaufen sollen, nicht zum Ende des ihm zugeordneten ersten Zeitintervalls beendet ist, und eine Ausführung eines ersten Tasks deshalb ausfällt, wobei der erste Zustandszähler auf einen Zustand korrigiert wird, den der erste Zustandszähler bei Ausführung des ausgefallenen ersten Tasks aufweisen würde.
  • Vorteilhafterweise wird eine Statusvariable abhängig von Prioritäten bestimmt, die dem ersten Task und dem zweiten Task zugeordnet sind, wobei wenn der Task, dem die niedrigste Priorität zugeordnet ist, als letzter Task in einem der Kommunikationsintervalle ausgeführt wird, ein Beginn eines Datenübertragungsintervalls, das auf ein Ende des Tasks mit der niedrigsten Priorität unmittelbar folgt, in ein unmittelbar anschließendes Kommunikationsintervall verschoben. Ein Task mit der höchsten Priorität wird im Zeitintervall zuerst oder gleichzeitig mit anderen Tasks aktiviert. Ein Task mit der niedrigsten Priorität wird auch fortgesetzt, wenn das Kommunikationsintervall vorüber ist. Die Kommunikation erfolgt anschließend im Datenübertragungsintervall.
  • Bezüglich der Vorrichtung zur Fehlerbehandlung in einer Kommunikation ist ein Prozessor und wenigstens einen temporären Datenspeicher vorgesehen, die ausgebildet sind zu kommunizierende Daten in einem Datenübertragungsintervall durch Lesen aus einem ersten Datenbereich des wenigstens einen temporären Datenspeichers und Speichern der gelesenen Daten in einem zweiten Datenbereich des wenigstens einen temporären Datenspeichers zwischen einem ersten Task und einem zweiten Task gemäß eines der Verfahren zu kommunizieren.
  • Vorteilhafterweise umfasst die Vorrichtung ein Modul zur Kommunikation der zu kommunizierende Daten mittels eines Direct Memory Access, DMA, oder mittels Interrupt Service Routines.
  • Weitere vorteilhafte Ausgestaltungen ergeben sich aus der folgenden Beschreibung und der Zeichnung. In der Zeichnung zeigt
    • 1 schematisch ein erstes zeitgesteuertes Verhalten von Tasks,
    • 2 schematisch ein erstes Fehlerbehandlungskonzept,
    • 3 schematisch ein zweites Fehlerbehandlungskonzept,
    • 4 schematisch ein zweites zeitgesteuertes Verhalten von Tasks,
    • 5 schematisch ein drittes Fehlerbehandlungskonzept,
    • 6 schematisch ein viertes Fehlerbehandlungskonzept,
    • 7 schematisch ein drittes zeitgesteuertes Verhalten von Tasks,
    • 8 schematisch ein fünftes Fehlerbehandlungskonzept,
    • 9 schematisch ein sechstes Fehlerbehandlungskonzept,
    • 10 schematisch eine Vorrichtung zur Kommunikation.
  • Ein Task ist ein Computerprogramm zur Laufzeit, dessen Ausführung vom Betriebssystem durch bestimmte Aktionen dynamisch kontrolliert wird. Tasks werden von einer Task-Steuerung des Betriebssystems verwaltet, die auch Scheduler genannt wird. Diese kann einen Task entweder so lange rechnen lassen, bis er endet, oder dafür sorgen, dass nach jeweils einer kurzen Zeitdauer der gerade ablaufende Task unterbrochen wird. Die Task-Steuerung kann so zwischen verschiedenen aktiven Tasks hin und her wechseln. Tasks können unterschiedlich lang sein und zu unterschiedlichen Zeitpunkten starten.
  • Für eine zeitliche Ausführung von Tasks werden in der Task-Steuerung wiederkehrende Zeitintervalle für eine zyklische Ausführung eines ersten Tasks und wiederkehrende Zeitintervalle für eine zyklische Ausführung eines zweiten Tasks vorgesehen. Im Beispiel ist eine Dauer des Zeitintervalls für die zweiten Tasks länger als eine Dauer des Zeitintervalls für die ersten Tasks. Beispielsweise hat das Zeitintervall für die ersten Tasks eine Länge von 5 ms. Beispielsweise hat das Zeitintervall für die zweiten Tasks eine Länge von 10 ms. Die Zeitintervalle sind logische Intervalle des Schedulers, die auf festen Zeitscheiben beruhen und nicht verschoben werden können.
  • Software Komponenten in Tasks können untereinander Daten austauschen. Zur Kommunikation zwischen den Tasks können die Daten in temporären Datenspeichern, insbesondre Buffern, zwischengespeichert werden. Zur Kommunikation werden beispielsweise zu kommunizierende Daten in einem Datenübertragungsintervall durch Lesen aus einem ersten Buffer und Speichern der gelesenen Daten in einem zweiten Buffer zwischen dem ersten Task und dem zweiten Task kommuniziert. Im Beispiel ist dem ersten Task ein erster Kanal mit einem ersten 5 ms Buffer für nur lesenden Zugriff und einem zweiten 5 ms Buffer für lesenden und schreibenden Zugriff zugeordnet. Im Beispiel ist dem zweiten Task ein zweiter Kanal mit einem ersten 10 ms Buffer für nur lesenden Zugriff und einem zweiten 10 ms Buffer für lesenden und schreibenden Zugriff zugeordnet. Allgemein können für eine Anzahl n Tasks n Kanäle mit 2n derartiger Buffer vorgesehen sein.
  • Die anhand der folgenden Beispiele angegebenen Implementierungen des Schedulers erzwingen nicht die Einhaltung der logischen Intervalle, sondern betrachten ein tatsächliches Intervall erst dann als abgeschlossen, wenn der Scheduler eine Taskausführung in einem auf dieses tatsächliche Intervall unmittelbar folgenden neuen Intervall auch wirklich durchführt. Allgemein sind bei der Fehlerbehandlung in einer Kommunikation zwischen Tasks die im Folgenden angegebenen Fehlerfälle klassifizierbar.
  • Scheduling Fehler:
    1. a) Schedule ist unvollständig oder nicht deterministisch
    2. b) Task ist nicht aktiviert (wurde ausgelassen)
    3. c) Task ist spontan aktiviert
    4. d) Buffer eines Kanals werden vor ihrer Initialisierung verwendet
  • Lastabhängige Fehler:
    1. a) Task-Ende wird überschritten (bei mehrfacher Task-Aktivierung)
    2. b) Kommunikation wurde in letztem Datenübertragungsintervall nicht beendet
    3. c) Kommunikation wurde in letztem Datenübertragungsintervall nicht ausgeführt
  • Speicher Fehler:
    1. a) Kanalzustand ist beschädigt
  • Die Scheduling Fehler a) bis c) können nur mittels externer Zeitreferenz, beispielsweise von einer Uhr oder einem Zähler, erkannt werden.
  • Die übrigen Fehler können zuverlässig mittels einer Kanalzustandsmaschine erkannt werden. Die folgenden Beispiele beschreiben Details eines Kommunikationsverfahrens und einer Fehler-Erkennung und Fehler-Heilung basieren auf dieser Kanalzustandsmaschine.
  • Ein Algorithmus welcher in einem Rechensystem das Kommunikationsverfahren und/oder das Fehlerbehandlungskonzept auf Basis der Scheduling Information selektiert verwendet eine Task zu Kern Zuordnung, einen Scheduling Typ, beispielsweise präemptiv oder kooperativ, sowie eine Priorität der an einer Kommunikation beteiligten Tasks und eine eventuell sequenzielle Ausführung durch ein Aktivierungs-Muster im System.
  • Es wird eine Kategorie „Concurreny Level“ ermittelt. Der Kategorie ist ein Kommunikationsverfahren und/oder ein entsprechendes Fehlerbehandlungskonzept zugeordnet.
  • Mögliche Kategorien des „Concurrency Level“ sind
  • Cooperative Core Local:
  • Die an der Kommunikation beteiligten Tasks weisen ein ausschließlich kooperatives Scheduling auf und werden auf demselben Rechenkern ausgeführt.
  • Preemtive Core Local:
  • Die an der Kommunikation beteiligten Tasks weisen ein präemptives Scheduling auf und werden auf demselben Rechenkern ausgeführt.
  • Parallel Cross Core:
  • Tasks werden auf mindestens zwei Rechenkernen ausgeführt.
  • Sequential Core Local:
  • Die Tasks werden sequentiell auf demselben Rechenkern ausgeführt.
  • Sequential Cross Core:
  • Die Tasks werden sequentiell auf mindestens zwei Rechenkernen ausgeführt.
  • Das Kommunikationsverfahren für eine Kommunikation in der Kategorie „Cooperative Core Local“ wird anhand der 1 beschrieben.
  • Das Kommunikationsverfahren ermöglicht eine Verteilung der Kommunikationslast auf alle beteiligten Tasks. Das Kommunikationsverhalten ermöglicht eine effiziente deterministische Kommunikation in einem Echtzeitsystem. Dabei wird eine Statusvariable S für eine Bestimmung von Kommunikationszeitpunkten verwendet. Die Statusvariable S kann einen der folgenden Zustände annehmen, die im Folgenden auch als Phasen der Statusvariable bezeichnet werden:
  • PROC_ACTIVE:
  • Mindestens einer der beteiligen Tasks verwendet die in den Buffern bereitgestellten Daten. Ein Überschreiben der Lesebuffer ist aus Konsistenzgründen nicht zulässig.
  • PROC_COMPLETE:
  • Alle Tasks habe die in einem logischen Intervall erforderliche Anzahl an Aktivierungen (unter Berücksichtigung evtl. Fehlerszenarien) abgeschlossen und die bereitgestellten Daten werden in diesem logischen Intervall nicht mehr benötigt.
  • TRANS_ACTIVE:
  • Die Lesebuffer der einzelnen Tasks werden aktualisiert. Eine Berechnung mit den enthaltenen Daten ist aus Konsistenzgründen nicht zulässig.
  • TRANS_COMPLETE:
  • Die Aktualisierung der Buffer ist abgeschlossen. Die Daten können für Berechnungen verwendet werden. Es ist allerdings kein Task aktiv.
  • In einem Kommunikationsintervall durchläuft die Statusvariable S die Zustände PROC_ACTIVE, PROC_COMPLETE, TRANS_ACTIVE, TRANS_COMPLETE, in dieser Reihenfolge. Die Zustände PROC_COMPLETE und TRANS_COMPLETE können übersprungen werden. In jedem Kommunikationsintervall soll ein Datenübertragungsintervall K ausgeführt werden. Während des Datenübertragungsintervalls K wird auf die Buffer schreibend und oder lesend zur Aktualisierung der Buffer zugegriffen. Das Kommunikationsintervall ist, wie in den folgenden Beispielen beschrieben synchron zu den logischen Intervallen des Schedulers definiert. In den beschriebenen Beispielen wird die Statusvariable S immer dann auf den Zustand PROC_ACTIVE gesetzt, wenn wenigstens ein Task ausgeführt wird. Die Statusvariable S wird während der Datenübertragungsintervalle K auf den Zustand TRANS_ACTIVE gesetzt. Der Zustand PROC_COMPLETE wird nach Abschluss aller Ausführungen eines Kommunikationsintervalls gesetzt. Der Zustand TRANS_COMPLETE wird erst nach Ende des Datenübertragungsintervalls gesetzt.
  • Für eine periodisch stattfindende Kommunikation berechnet sich das Kommunikationsintervall 12 als kleinstes gemeinsames Vielfaches, KGV, von Intervallen T1, T2, ..., Tn, die miteinander kommunizieren sollen.
  • Tn bezeichnet ein Intervall eines Tasks n. Die logischen Intervalle sind zeitlich synchron zu der Periode der einzelnen Tasks ablaufend definiert. Tasks werden vom Scheduler aktiviert. Bis zum Ende des Kommunikationsintervalls 12 sollten alle Task und das Datenübertragungsintervall K abgelaufen sein. Den Tasks sind jeweils Deadlines zugeordnet, bis zu denen die Tasks beendet sein müssen. Falls eine Berechnung eines Tasks nach seiner Aktivierung nicht rechtzeitig vor der diesem Task zugeordneten Deadline beendet werden kann, erfolgt eine darauf folgende Aktivierung dieses Tasks durch den Scheduler nicht. Falls zwar die Berechnung des Tasks nach seiner Aktivierung rechtzeitig vor der diesem Task zugeordneten Deadline beendet wird, das in diesem Kommunikationsintervall 12 vorgesehene Datenübertragungsintervall K jedoch nicht, ist die Fehlerbehandlung für die Kommunikation erforderlich.
  • Für das Beispiel aus 1 gilt für das Kommunikationsintervall I 2 = KGV ( 10 ms ,   5 ms ) = 10 ms .
    Figure DE102018205392A1_0001
  • Anstelle des KGV können auch andere gemeinsame Vielfache verwendet werden.
  • Im Folgenden wird anhand der 1 beschrieben, wie Phasen der Statusvariablen S sequentiell durchlaufen werden. Die Statusvariable S wird abhängig von einem ersten Zustand der Ausführung der ersten Tasks und abhängig von einem zweiten Zustand der Ausführung der zweiten Tasks bestimmt.
  • Die Kommunikation findet in dem Datenübertragungsintervall K statt, das abhängig von einem Wert der Statusvariablen S gestartet wird.
  • Die Statusvariable S wird beispielsweise mittels eines ersten Zählerstands eines ersten Zustandszählers Z1 für den ersten Zustand und mittels eines zweiten Zählerstands eines zweiten Zustandszählers Z2 für den zweiten Zustand bestimmt. Der erste Zustandszähler kann, wie in 1 dargestellt, die Zustände 2, 1, 0 annehmen. Der zweite Zustandszähler kann, wie in 1 dargestellt, die Zustände 1, 0 annehmen.
  • Der erste Zustandszähler Z1 beginnt in dem in 1 dargestellten zeitlichen Verlauf links mit dem ersten Zählerstand 2. Zu einem Zeitpunkt t1, der synchron zum ersten logischen Intervall 11 beginnt, beginnt eine erste Ausführung eines ersten Tasks T1. Zu einem Zeitpunkt t2, am Ende der ersten Ausführung des ersten Tasks T1 wird der erste Zählerstand auf 1 gesetzt. Zu einem Zeitpunkt t3, der synchron zur ersten Wiederholung des ersten logischen Intervall 11 beginnt, beginnt eine zweite Ausführung des ersten Tasks T1. Zu einem Zeitpunkt t4, am Ende der zweiten Ausführung des ersten Tasks T1 wird der erste Zählerstand auf 0 gesetzt.
  • Anschließend wird zum Zeitpunkt t4 das Datenübertragungsintervall K gestartet. Das Datenübertragungsintervall K endet zum Zeitpunkt t5. Zum Zeitpunkt t5 wird der erste Zählerstand auf 2 gesetzt.
  • Eine zweite und eine dritte Wiederholung des ersten logischen Intervalls 11 sind in 1 ebenfalls dargestellt. In der zweiten Wiederholung beginnt eine dritte Ausführung des ersten Tasks T1 synchron mit der zweiten Wiederholung des ersten logischen Intervalls 11 zu einem Zeitpunkt t6 und endet zu einem Zeitpunkt t7. Der erste Zählerstand wird zum Zeitpunkt t7 von 2 auf 1 gesetzt.
  • In der dritten Wiederholung beginnt eine vierte Ausführung des ersten Tasks T1 synchron mit der dritten Wiederholung des ersten logischen Intervalls 11 zu einem Zeitpunkt t8 und endet zu einem Zeitpunkt t9. Der erste Zählerstand wird zum Zeitpunkt t9 von 1 auf 0 gesetzt.
  • Der zweite Zustandszähler Z2 beginnt in 1 links mit dem zweiten Zählerstand 1. Zum Zeitpunkt t1 beginnt das zweite logische Intervall 12 synchron mit dem ersten logischen Intervall 11. Die erste Ausführung eines zweiten Tasks T2 beginnt nach Ende der ersten Ausführung des ersten Tasks T1 im Zeitpunkt t2. D.h. der erste Task T1 wird zwischen dem Zeitpunkt t1 und dem Zeitpunkt t2 verarbeitet als der zweite Task T2.
  • Die erste Ausführung des zweiten Tasks T2 endet zu einem Zeitpunkt t10, im Beispiel vor dem Zeitpunkt t3. Zum Zeitpunkt t10 wird der zweite Zählerstand von 1 auf 0 gesetzt. Am Ende des Datenübertragungsintervalls K, d.h. zum Zeitpunkt t5 wird der zweite Zählerstand von 0 auf 1 gesetzt.
  • Eine Wiederholung des zweiten logischen Intervalls 12 ist in 1 ebenfalls dargestellt. Zum Zeitpunkt t6 beginnt die Wiederholung des zweiten logischen Intervalls 12 synchron mit der dritten Wiederholung des ersten logischen Intervalls 11. Die zweite Ausführung eines zweiten Tasks T2 beginnt nach Ende der dritten Ausführung des ersten Tasks T1 im Zeitpunkt t7. D.h. der erste Task T1 wird zwischen dem Zeitpunkt t6 und dem Zeitpunkt t7 verarbeitet als der zweite Task T2. In der Wiederholung wird die zweite Ausführung des zweiten Tasks T2 zwischen den Zeitpunkten t8 und t9 zur vierten Ausführung des ersten Tasks T1 unterbrochen, um die vierte Wiederholung des ersten Tasks T1 vorzunehmen. Zum Zeitpunkt t9 wird die Wiederholung des zweiten Tasks T2 fortgesetzt und endet zu einem Zeitpunkt t11. Zum Zeitpunkt t11 wird der zweite Zählerstand auf 0 gesetzt und das Datenübertragungsintervall K wiederholt. Die Wiederholung des Datenübertragungsintervalls K endet zum Zeitpunkt t12. Der erste Zählerstand wird zum Zeitpunkt t12 auf 2 gesetzt. Der zweite Zählerstand wird zum Zeitpunkt t12 auf 1 gesetzt.
  • Zwischen den Zeitpunkten t1 und t4 sowie t6 und t9 ist ein Zugriff auf den ersten 5 ms Buffer B51 und den zweiten 5 ms Buffer B52 erlaubt. Zwischen den Zeitpunkten t1 und t10 sowie t6 und t11 ist der Zugriff auf einen ersten 10 ms Buffer B101 und einen zweiten 10 ms Buffer B102 erlaubt. Der Zugriff aus dem 5ms Task erfolgt im Beispiel zwischen t1 und t2, t3 und t4, t6 und t7 sowie t8 und t9, d.h. während der Ausführungen des ersten Tasks T1. Der Zugriff aus dem 10 ms Task erfolgt im Beispiel zwischen t2 und t10, d.h. während der ersten Ausführung des zweiten Tasks T2 sowie t6 und t7, d.h. pre-emptive vor der Ausführung der Wiederholung des zweiten Tasks T2. Im Datenübertragungsintervall K ist der Zugriff auf alle Buffer für die Tasks untersagt. Die Zugriffe aus den Tasks auf den ersten 5 ms Buffer B51 und ersten 10 ms Buffer B101 werden in 1 mit ein-direktionalen Pfeilen dargestellt. Die Zugriffe aus den Tasks auf die anderen Buffer werden in 1 mit bidirektionalen Pfeilen dargestellt. Im Datenübertragungsintervall K wird vom zweiten 5 ms Buffer B52 auf den zweiten 10 ms Buffer B102 geschrieben und vom ersten 10 ms Buffer B101 auf den ersten 5 ms Buffer B51 geschrieben.
  • Die Statusvariable S hat zwischen den Zeitpunkten t1 und t4 den Zustand PROC_ACTIVE.
  • Die Statusvariable S hat zwischen den Zeitpunkten t4 und t5 zwischen denen sowohl der erste Zustandszähler Z1 den ersten Zustandswert 0 hat als auch der zweite Zustandszähler Z2 den zweiten Zustandswert 0 hat, den Zustand TRANS_ACTIVE.
  • Die Statusvariable S hat zwischen den Zeitpunkten t5 und t6 den Zustand TRANS_COMPLETE.
  • Die Statusvariable S hat zwischen den Zeitpunkten t6 und t11 den Zustand PROC_ACTIVE.
  • Die Statusvariable S hat zwischen den Zeitpunkten t11 und t12 zwischen denen sowohl der erste Zustandszähler Z1 den ersten Zustandswert 0 hat als auch der zweite Zustandszähler Z2 den zweiten Zustandswert 0 hat, den Zustand TRANS_ACTIVE.
  • Die Statusvariable S hat in 1 ab dem Zeitpunkt t12 den Zustand TRANS_COMPLETE.
  • Da die Kommunikation im Kontext der Tasks stattfindet ist PROC_COMPLETE in diesem Szenario ein rein logischer Status der beim direkten Übergang von PROC_ACTIVE nach TRANS_ACTIVE entfällt.
  • Bei einer tatsächlichen Ausführung von Tasks kann das tatsächlich für eine vollständige Ausführung der Tasks und der Kommunikation erforderliche Kommunikationsintervall aufgrund der genannten Fehler vom Kommunikationsintervall abweichen. Eine Fehlerbehandlung wird anhand der 2 und der 3 beschrieben. Für Elemente, die bereits anhand der 1 beschrieben wurden, werden dieselben Bezugszeichen verwendet und auf die Beschreibung zu 1 verwiesen.
  • Im Unterschied zu der in 1 dargestellten Situation, erfolgt wie in 2 dargestellt während der ersten Wiederholung des ersten logischen Intervalls 11 eine Unterbrechung der zweiten Ausführung des ersten Tasks T1 zu einem Zeitpunkt t20. Die zweite Ausführung wird zu einem Zeitpunkt t21 vor dem Zeitpunkt t6 fortgesetzt und endet zu einem Zeitpunkt t22 vor dem Zeitpunkt t6. Zum Zeitpunkt t6 wird das Datenübertragungsintervall K begonnen. Das Datenübertragungsintervall K endet zu einem Zeitpunkt t23, der im Beispiel nach dem Zeitpunkt t6 liegt. Dies bedeutet, das Datenübertragungsintervall K endet nach dem Beginn der zweiten Wiederholung des ersten logischen Intervalls 11.
  • Die zweite Ausführung des zweiten Tasks T2 beginnt zum Zeitpunkt T23. Damit erhält die zweite Ausführung des zweiten Tasks T2 die neuesten Daten vom ersten Task T1. Die dritte Ausführung des ersten Tasks T1 wird in der dritten Wiederholung des ersten Intervalls 11 unterdrückt. Damit kann die zweite Ausführung des zweiten Tasks T2 vor Abschluss der dritten Wiederholung des ersten Intervalls 11 abgeschlossen werden.
  • Im Unterschied zu der in 1 dargestellten Situation, erfolgt wie in 3 dargestellt während der ersten Wiederholung des ersten logischen Intervalls 11 eine Unterbrechung der ersten Ausführung des zweiten Tasks T2 zum Zeitpunkt t3. Die zweite Ausführung des ersten Tasks T1 wird zu einem Zeitpunkt t30 nach dem Zeitpunkt t3 begonnen und endet zu einem Zeitpunkt t31 vor dem Zeitpunkt t6, d.h. während der ersten Wiederholung des ersten logischen Intervalls 11. Zum Zeitpunkt t31wird die erste Ausführung des zweiten Tasks T2 fortgesetzt. Zum Zeitpunkt t6 wird die erste Ausführung des zweiten Tasks T2 erneut unterbrochen, um die dritte Ausführung des ersten Tasks T1 bis zu einem Zeitpunkt T32 durchzuführen. Zum Zeitpunkt T32 wird die erste Ausführung des ersten Tasks T1 fortgesetzt und endet zu einem Zeitpunkt t33 vor dem Zeitpunkt t8. Zum Zeitpunkt t8 beginnt die vierte Ausführung des ersten Tasks T1. Zu einem Zeitpunkt t34 endet die vierte Ausführung des ersten Tasks T1. Zum Zeitpunkt t34 wird das Datenübertragungsintervall K begonnen. Das Datenübertragungsintervall K endet zu einem Zeitpunkt t35.
  • Die zweite Ausführung des zweiten Tasks T2 wird in der Wiederholung des logischen zweiten Intervalls 12 unterdrückt.
  • Durch Unterdrücken, d.h. Auslassen der jeweiligen Ausführung wird das Rechensystem determiniert entlastet. Ein Überschreiten einer logischen Intervallgrenze durch einen in Ausführung befindlichen Task wird im Folgenden als Task Deadline Verletzung bezeichnet. Als Reaktion auf eine derartige Task Deadline Verletzung resultiert ein Ausfall der nächsten periodischen Taskausführung durch die Kommunikationsinfrastruktur.
  • Dabei sind prinzipiell zwei Varianten zu Unterscheiden.
  • Variante 1:
  • Die Deadline Verletzung findet bei der letzten Ausführung eines Tasks im Datenübertragungsintervall statt.
  • Bei Variante 1 werden zwei weitere Varianten unterschieden:
  • Variante 1A:
  • Die Deadline Verletzung findet bereits vor dem Start einer Transaktion statt. Einer der beteiligten Tasks hat bereits mit der Berechnung im neuen Intervall begonnen. Der Statusübergang von PROC_ACTIVE geht in das neue Datenübertragungsintervall über. Die Aktualisierung der Buffer entfällt.
  • Variante 1B:
  • Hier findet wie in 2 dargestellt bereits eine Aktualisierung der Buffer statt. Der Status TRANS_ACTIVE ist gesetzt, während eine Deadline Verletzung stattfindet. Durch kooperatives Scheduling wird gewährleistet, dass die Kommunikation vollständig abgeschlossen ist bevor die erste Taskausführung im neuen Intervall stattfindet.
  • Variante 2:
  • Die Deadline Verletzung findet nicht bei der letzten Ausführung eines Tasks im Datenübertragungsintervall statt.
  • Bei Variante 2 werden lediglich die durch den Ausfall der Taskausführung verfälschten Zählerstände korrigiert. Dies hat keinen Einfluss auf die Kommunikation.
  • In 4 ist ein Kommunikationsverfahren für eine Kommunikation welche der Kategorie „Parallel Cross Core“ entspricht, dargestellt. Bezüglich der Elemente mit übereinstimmendem Bezugszeichen wird auch auf die Beschreibung zu 1 verwiesen.
  • Im Unterschied zu den vorher beschriebenen Beispielen werden Tasks auch parallel gerechnet. Zudem erfolgt die Durchführung der Kommunikation im Datenübertragungsintervall K durch ein Modul 400 zur Kommunikation der zu kommunizierende Daten mittels eines Direct Memory Access, DMA, oder mittels Interrupt Service Routines. Zum Start des Datenübertragungsintervalls K dient ein erster Trigger 301 und zum Start der Wiederholung des Datenübertragungsintervalls K dient ein zweiter Trigger 302.
  • Durch eine Auslagerung der Kommunikationsaufgabe an eine oder mehrere Instanzen wie DMA Hardware oder ISRs ist eine deterministische Abarbeitung gewährleistet. Die Instanzen können den Anforderungen entsprechend ebenfalls priorisiert werden und ermöglichen eine Verteilung der Kommunikationslast auf weitere Rechenkerne oder dedizierte Hardware Ressourcen.
  • Wie in 4 dargestellt findet aus den Tasks jeweils nur die Aktivierung der Aktualisierung statt. Die eigentliche Aktualisierung der Buffer wird durch eine weitere Instanz durchgeführt. Da alle beteiligten Tasks vollständig parallel ablaufen können, muss zu Beginn einer Ausführung der Status geprüft werden.
  • Im Falle von TRANS_ACTIVE wird die Ausführung so lange verzögert, bis die Aktualisierung der Daten Abgeschlossen ist. Bei der Verwendung eines Basic Task Modells wird dies durch Busy Wait erreicht. Der Zustand TRANS_COMPLETE wird ausschließlich in dem Kontext gesetzt, in welchem die Aktualisierung stattfindet.
  • In diesem Fall ist ein Fehlerbehandlungskonzept für den sporadischen Ausfall von Taskausführungen für eine Kommunikation möglich, welche der Kategorie „Parallel Cross Core“ entspricht. Dieses wird anhand der 5 und 6 näher erläutert. Bezüglich der Elemente mit übereinstimmendem Bezugszeichen wird auch auf die Beschreibung zu 2 verwiesen.
  • Im Unterschied zu den vorher beschriebenen Beispielen wird die erste Ausführung des zweiten Tasks zu einem Zeitpunkt t51 nach dem Zeitpunkt t2 unterbrochen und zu einem Zeitpunkt t52 vor dem Zeitpunkt t3 fortgesetzt. Zudem endet die erste Ausführung des zweiten Tasks T2 nach dem Zeitpunkt t3 und dem Zeitpunkt t20 vor dem Zeitpunkt t21 zu einem Zeitpunkt t53. Dies bedeutet, erste Tasks und zweite Tasks werden in diesem Beispiel zumindest zeitweise parallel gerechnet.
  • Zudem erfolgt die Durchführung der Kommunikation im Datenübertragungsintervall K durch das Modul 400 zur Kommunikation der zu kommunizierende Daten mittels des Direct Memory Access, DMA, oder mittels Interrupt Service Routines. Zum Start des Datenübertragungsintervalls K dient ein dritter Trigger 501, der am Ende der zweiten Ausführung des ersten Tasks T1 ausgelöst wird.
  • In 6 ist eine Kommunikation wie in 3 dargestellt. Bezüglich der Elemente mit übereinstimmendem Bezugszeichen wird insoweit auf die Beschreibung zu 3 verwiesen.
  • Im Unterschied zu den vorher beschriebenen Beispielen wird die erste Ausführung des zweiten Tasks T2 nicht zum Zeitpunkt t31 fortgesetzt, sondern bereits zu einem Zeitpunkt t61, der vor dem Zeitpunkt t31 und nach dem Zeitpunkt t30 liegt. Zudem wird die erste Ausführung des zweiten Tasks T2 nicht zum Zeitpunkt t6 unterbrochen. Dies bedeutet, erste Tasks und zweite Tasks werden in diesem Beispiel zumindest zeitweise parallel gerechnet.
  • Im Unterschied zu den vorher beschriebenen Beispielen erfolgt die Durchführung der Kommunikation im Datenübertragungsintervall K durch das Modul 400 zur Kommunikation der zu kommunizierende Daten mittels des Direct Memory Access, DMA, oder mittels Interrupt Service Routines. Zum Start des Datenübertragungsintervalls K dient ein vierter Trigger 601, der am Ende der vierten Ausführung des ersten Tasks T1 ausgelöst wird.
  • In 7 ist eine Kommunikation für ein Fehlerbehandlungskonzept für einen sporadischen Ausfall von Taskausführungen für eine Kommunikation dargestellt, welche der Kategorie „Preemtive Core Local“ entspricht, dargestellt. Bezüglich der Elemente mit übereinstimmendem Bezugszeichen wird auch auf die Beschreibung zu 1 verwiesen.
  • In dem im Folgenden anhand 7 beschriebenen Beispiel werden Tasks sequentiell gerechnet. Die ersten Tasks T1 werden dabei mit einer höheren Priorität gerechnet als die zweiten Tasks T2. Dies bedeutet, der Scheduler unterbricht eine Ausführung eines zweiten Tasks T2 sobald laut seiner Schedule eine Berechnung eines ersten Tasks T1 erforderlich ist.
  • Im Beispiel beginnen in dem in 7 dargestellten zeitlichen Ablauf bei einem Zeitpunkt t1 sowohl das erste logische Intervall 11 als auch das zweite logische Intervall 12 synchron. Der erste Zählerstand steht zu Beginn auf dem Wert 2, der zweite Zählerstand steht zu Beginn auf dem Wert 1. Die Statusvariable S hat vor dem Zeitpunkt t1 den Zustand TRANS_COMPLETE und ab dem Zeitpunkt t1 den Zustand PROC_ACTIVE. Aufgrund der Priorisierung beginnt die erste Ausführung des ersten Tasks T1 zum Zeitpunkt t1 und endet zu einem Zeitpunkt t2. Zum Zeitpunkt T1 wird der erste Zählerstand auf 1 gesetzt. Die Ausführung des zweiten Tasks T2 beginnt zum Zeitpunkt t2 und wird zu einem Zeitpunkt t3 unterbrochen, zu dem die erste Wiederholung des ersten logischen Intervalls 11 zeitgleich mit der zweiten Ausführung des ersten Tasks T1 beginnt. Zu einem Zeitpunkt t4 endet die zweite Ausführung des ersten Tasks T1 und der erste Zählerstand wird auf 0 gesetzt. Die Ausführung des zweiten Task T2 wird zum Zeitpunkt t4 fortgesetzt und endet zu einem Zeitpunkt t5, zu dem der zweite Zählerstand auf 0 gesetzt wird. Die Statusvariable S wird zum Zeitpunkt t5 auf den Wert PROC_COMPLETE gesetzt.
  • Da die Ausführung des zweiten Tasks T2 nach der zweiten Ausführung des ersten Task T1 endete, beginnt das Datenübertragungsintervall K erst zu einem Zeitpunkt t6, zu dem synchron die zweite Wiederholung des ersten logischen Intervalls 11 und die Wiederholung des zweiten logischen Intervalls 12 beginnen. Die Statusvariable S wird zwischen den Zeitpunkten t6 und t7 auf TRANS-ACTIVE gesetzt. Die dritte Ausführung des ersten Tasks T1 beginnt zu einem Zeitpunkt t7 am Ende des Datenübertragungsintervalls K. Zum Zeitpunkt t7 wird der erste Zählerstand auf 2 gesetzt, wird der zweite Zählerstand auf 1 gesetzt und wird die Statusvariable S auf PROC_ACTIVE gesetzt.
  • Die dritte Ausführung des ersten Tasks T1 endet zu einem Zeitpunkt t8, zu dem der erste Zählerstand auf 1 gesetzt wird. Die Wiederholung der Ausführung des zweiten Tasks T2 beginnt zum Zeitpunkt t8 und endet zu einem Zeitpunkt t9, zu dem der zweite Zählerstand auf 0 gesetzt wird. Zu einem auf den Zeitpunkt t9 folgenden Zeitpunkt t10 beginnt die dritte Wiederholung des ersten logischen Intervalls 11 und die vierte Ausführung des ersten Tasks T1. Zu einem Zeitpunkt t11 endet die vierte Ausführung des ersten Tasks T1. Der erste Zählerstand wird auf 0 gesetzt. Da die Wiederholung des zweiten Tasks T2 zum Zeitpunkt t11 bereits abgeschlossen ist, wird die Statusvariable S auf den Zustand TRANS_ACTIVE gesetzt. Die Wiederholung des Kommunikationsintervalls beginnt zum Zeitpunkt t11 und endet zum Zeitpunkt t12. Zum Zeitpunkt t12 wird die Statusvariable S auf den Zustand TRANS_COMPLETE gesetzt. Der erste Zählerstand wird auf den Wert 2 gesetzt, der zweite Zählerstand wird auf den Wert 1 gesetzt. Die Zugriffe der Tasks auf die Buffer finden wie zuvor beschrieben während der Ausführungen der Tasks statt.
  • In diesem Fall ist ein Fehlerbehandlungskonzept möglich, welches anhand der 8 und der 9 näher erläutert. Bezüglich der Elemente mit übereinstimmendem Bezugszeichen wird bezüglich der 8 auch auf die Beschreibung zu 2 und bezüglich 9 auch auf die Beschreibung zu 3 verwiesen.
  • In dem in 8 dargestellten Beispiel wird der erste Task T1 mit höherer Priorität als der zweite Task T2 ausgeführt. Zum Zeitpunkt t22 endet die zweite Ausführung des ersten Tasks T1. Zum Zeitpunkt t22 beginnt das Datenübertragungsintervall K. Dieser Zeitpunkt t22 ist kurz vor dem Zeitpunkt t6, zum dem die zweite Wiederholung des ersten Intervalls 11 beginnen sollte. Das Datenübertragungsintervall K startet somit noch während des zweiten logischen Intervalls 12, dauert jedoch noch über den Zeitpunkt t6 hinaus bis zum Zeitpunkt t23 an. Daher wird die Wiederholung des zweiten Tasks T2 bis zum Ende des Datenübertragungsintervalls K, d.h. bis zum Zeitpunkt t23 verzögert. Trotz der höheren Priorität des ersten Tasks T1 wird in diesem Fall der zweite Task T2 ununterbrochen ausgeführt, da der erste Task T1 in der zweiten Wiederholung des ersten Intervalls 11 ausgelassen wird. Dies bedeutet, der erste Task T1 wird zwar mit höherer Priorität ausgeführt, zur Fehlerbehandlung wird der erste Task T1 ausgelassen, wenn dies erforderlich ist.
  • In dem in 9 dargestellten Beispiel wird der erste Task T1 mit höherer Priorität als der zweite Task T2 ausgeführt. Die Ausführung des zweiten Tasks T2 dauert bis zum Zeitpunkt t33 an, der nach dem Zeitpunkt t6, d.h. innerhalb der Wiederholung des zweiten logischen Intervalls 12 liegt. Der zweite Task 2 wird bis zu seinem Ende Ausgeführt. Da das Datenübertragungsintervall K bis dahin noch nicht ausgeführt wurde, wird die Wiederholung des zweiten Tasks T2 nicht ausgeführt, sondern entfällt, unabhängig von Prioritäten der Tasks.
  • Wenn der Scheduling Fehler d) Buffer eines Kanals werden vor ihrer Initialisierung verwendet, einer der lastabhängigen Fehler a) Task-Ende wird überschritten (bei mehrfacher Task-Aktivierung), b) Kommunikation wurde in letztem Datenübertragungsintervall nicht beendet, c) Kommunikation wurde in letztem Datenübertragungsintervall nicht ausgeführt, oder der Speicher Fehler a) Kanalzustand ist beschädigt erkannt wurde, fällt in den Beispielen entweder ein Task aus, oder das Datenübertragungsintervall K wird verschoben. Ein Task fällt im Beispiel dadurch aus, dass seine Ausführung vom Scheduler nicht aktiviert wird. Das Datenübertragungsintervall wird im Beispiel dadurch verschoben, dass der Scheduler die Ausführung der Tasks und des Datenübertragungsintervalls zu den passenden Zeitpunkten aktiviert.
  • Die Verwendung einzelne Kommunikationsverfahren und Fehlerbehandlungskonzepte sind nicht auf die aufgeführten Kategorien „Concurrency Level“ beschränkt. Sie können auch in anderen Szenarien oder Kategorien wie „Sequential Core Local“ oder „Sequential Cross Core“ zur Anwendung kommen.
  • Die Kommunikationsverfahren und Fehlerbehandlungskonzepte sind nicht auf eine Kommunikation zwischen zwei Tasks beschränkt. In den Figuren wird der Übersichtlichkeit wegen auf eine Ausführung mit mehr als zwei Tasks verzichtet.
  • Eine Vorrichtung 1000 zur Kommunikation ist in 10 dargestellt. Die Vorrichtung 1000 umfasst einen Prozessor 1001 und wenigstens einen temporären Datenspeicher 1002 die ausgebildet sind zu kommunizierende Daten in dem Datenübertragungsintervall K durch Lesen aus dem ersten Datenbereich B51, B52 des wenigstens einen temporären Datenspeichers 1002 und Speichern der gelesenen Daten in dem zweiten Datenbereich B101, B102 des wenigstens einen temporären Datenspeichers 1002 zwischen dem ersten Task T1 und einem zweiten Task T2 gemäß des beschriebenen Verfahrens zu kommunizieren.
  • Die Vorrichtung nach Anspruch umfasst in einem Beispiel ein Modul 1003 das wie für das Modul 400 beschrieben zur Kommunikation der zu kommunizierende Daten mittels eines Direct Memory Access, DMA, oder mittels Interrupt Service Routines ausgebildet ist.

Claims (12)

  1. Verfahren zur Fehlerbehandlung in einer Kommunikation, bei dem zu kommunizierende Daten in einem Datenübertragungsintervall (K) durch Lesen aus einem ersten Datenbereich zur temporären Datenspeicherung und Speichern der gelesenen Daten in einem zweiten Datenbereich zur temporären Datenspeicherung zwischen einem ersten Task (T1) und einem zweiten Task (T2) kommuniziert werden, dadurch gekennzeichnet, dass ein Zeitintervall (11) für eine Ausführung des ersten Tasks (T1) und ein Kommunikationsintervall (12) für eine Ausführung des zweiten Tasks (T2) vorgegeben werden, wobei a) eine Ausführung des Datenübertragungsintervalls (K) in einem Kommunikationsintervall (12) ausgelassen wird, wenn ein erster Task (T1) zeitlich unmittelbar vor dem Kommunikationsintervall (12) in einem letzten der Zeitintervalle (11) eines dem Kommunikationsintervall (12) unmittelbar vorhergehenden Kommunikationsintervalls (12) begann, über einen Endzeitpunkt (t6) dieses letzten Zeitintervalls (11) hinaus fortgesetzt wird und eine Ausführung eines zweiten Tasks (T2) des Kommunikationsintervalls (12) bereits begann, oder b) eine Ausführung des Datenübertragungsintervalls (K) in einem Kommunikationsintervall (12) ausgelassen wird, wenn ein zweiter Task (T2) in einem dem Kommunikationsintervall (12) zeitlich unmittelbar vorhergehenden Kommunikationsintervall (12) begann, über einen Endzeitpunkt (t6) des vorhergehenden Kommunikationsintervalls (12) hinaus fortgesetzt wird, und eine Ausführung des ersten Tasks (T1) im Kommunikationsintervall (12) bereits begann.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Beginn des Datenübertragungsintervalls (K) durch das Ende einer Ausführung des ersten Tasks (T1) ausgelöst wird (301, 501), wenn die Ausführung des ersten Tasks (T1) später endet als eine Ausführung des zweiten Tasks (T2), oder dass der Beginn des Datenübertragungsintervalls (K) durch das Ende einer Ausführung des zweiten Tasks (T2) ausgelöst wird (302, 601), wenn die Ausführung des zweiten Tasks (T2) später endet als eine Ausführung des ersten Tasks (T1).
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass wenn eine Ausführung des ersten Tasks (T1) über ein Ende des Kommunikationsintervalls (12) hinaus andauert, in dem die Ausführung des ersten Tasks (T1) begann, und wenn der Beginn des Datenübertragungsintervalls (K) durch das Ende der Ausführung des ersten Tasks (T1) ausgelöst wird (501), eine unmittelbar auf die Ausführung des ersten Tasks (T1) folgende Ausführung des zweiten Tasks (T2) bis zum Ende des Datenübertragungsintervalls (K) verzögert wird.
  4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass wenn eine Ausführung des zweiten Tasks (T2) über ein Ende des Kommunikationsintervalls (12) hinaus andauert, in dem die Ausführung des zweiten Tasks (T2) begann, und wenn der Beginn des Datenübertragungsintervalls (K) durch das Ende der Ausführung des ersten Tasks (T1) ausgelöst wird (601), eine Auslösung des Datenübertragungsintervalls (K) in diesem Kommunikationsintervall unterbleibt.
  5. Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass die zu kommunizierende Daten im Datenübertragungsintervall (K) durch eine oder mehrere Instanzen außerhalb einer Hardware zur Ausführung des ersten Tasks (T1) und des zweiten Tasks (T2) kommuniziert werden.
  6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Dauer des Kommunikationsintervalls (12) ein ganzzahliges Vielfaches einer Dauer für das Zeitintervall (11) ist, wobei ein Kommunikationsintervall (12) ein oder mehrere Zeitintervalle (11) umfasst, wobei ein frühestes der Zeitintervalle (11) zeitgleich mit dem Kommunikationsintervall (12) beginnt.
  7. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass während eines Kommunikationsintervalls (12) wenigstens ein Zeitintervall (11) beginnt, wobei sich Zeitintervalle (11) zeitlich nicht überlappen, wobei das Datenübertragungsintervall (K) entweder vor einer ersten Ausführung des ersten Tasks (T1) im frühesten der Zeitintervalle (11) endet, oder nach Ende einer letzten Ausführung des ersten Tasks (T1) im spätesten der Zeitintervalle (11) beginnt.
  8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Statusvariable (S) abhängig von einem ersten Zustand der Ausführung der ersten Tasks (T1) und abhängig von einem zweiten Zustand der Ausführung der zweiten Tasks (T2) bestimmt wird, wobei das Datenübertragungsintervall (K) abhängig von einem Wert der Statusvariablen (S) gestartet wird.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass ein erster Zustandszähler (Z1) korrigiert wird, wenn einer der ersten Tasks (T1) in einem Kommunikationsintervall (12) ausfällt, weil einer der ersten Tasks (T1), die während des Kommunikationsintervalls (12) ablaufen sollen, mit Ausnahme des letzten der ersten Prozesse (T1), die während des Kommunikationsintervalls (12) ablaufen sollen, nicht zum Ende des ihm zugeordneten ersten Zeitintervalls (11) beendet ist, und eine Ausführung eines ersten Tasks (T1) deshalb ausfällt, wobei der erste Zustandszähler (Z1) auf einen Zustand korrigiert wird, den der erste Zustandszähler (Z1) bei Ausführung des ausgefallenen ersten Tasks (T1) aufweisen würde.
  10. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Statusvariable (S) abhängig von Prioritäten bestimmt wird, die dem ersten Task (T1) und dem zweiten Task (T2) zugeordnet sind, wobei wenn der Task, dem die niedrigste Priorität zugeordnet ist, als letzter Task in einem der Kommunikationsintervalle (12) ausgeführt wird, ein Beginn eines Datenübertragungsintervalls (K), das auf ein Ende des Tasks mit der niedrigsten Priorität unmittelbar folgt, in ein unmittelbar anschließendes Kommunikationsintervall (12) verschoben wird.
  11. Vorrichtung (1000) zur Fehlerbehandlung in einer Kommunikation gekennzeichnet durch einen Prozessor (1001) und wenigstens einen temporären Datenspeicher (1002) die ausgebildet sind zu kommunizierende Daten in einem Datenübertragungsintervall (K) durch Lesen aus einem ersten Datenbereich (B51, B52) des wenigstens einen temporären Datenspeichers (1002) und Speichern der gelesenen Daten in einem zweiten Datenbereich (B101, B102) des wenigstens einen temporären Datenspeichers (1002) zwischen einem ersten Task (T1) und einem zweiten Task (T2) gemäß eines Verfahren nach einem der Ansprüche 1 bis 10 zu kommunizieren.
  12. Vorrichtung nach Anspruch 11, dadurch gekennzeichnet, dass die Vorrichtung ein Modul (1003) zur Kommunikation der zu kommunizierende Daten mittels eines Direct Memory Access, DMA, oder mittels Interrupt Service Routines umfasst.
DE102018205392.8A 2018-04-10 2018-04-10 Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten Pending DE102018205392A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102018205392.8A DE102018205392A1 (de) 2018-04-10 2018-04-10 Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten
KR1020190040563A KR20190118522A (ko) 2018-04-10 2019-04-08 분산형 소프트웨어 컴포넌트들 간의 통신에서 오류 처리를 위한 방법 및 장치
JP2019073938A JP2019194848A (ja) 2018-04-10 2019-04-09 分散したソフトウェアコンポーネント間の通信におけるエラー処理のための方法および装置
CN201910280268.8A CN110362413A (zh) 2018-04-10 2019-04-09 用于分布式软件组件之间的通信中错误处理的方法和设备
US16/379,218 US11048575B2 (en) 2018-04-10 2019-04-09 Method and device for error handling in a communication between distributed software components

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018205392.8A DE102018205392A1 (de) 2018-04-10 2018-04-10 Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten

Publications (1)

Publication Number Publication Date
DE102018205392A1 true DE102018205392A1 (de) 2019-10-10

Family

ID=67991259

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018205392.8A Pending DE102018205392A1 (de) 2018-04-10 2018-04-10 Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten

Country Status (5)

Country Link
US (1) US11048575B2 (de)
JP (1) JP2019194848A (de)
KR (1) KR20190118522A (de)
CN (1) CN110362413A (de)
DE (1) DE102018205392A1 (de)

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6567840B1 (en) * 1999-05-14 2003-05-20 Honeywell Inc. Task scheduling and message passing
US7020877B2 (en) * 2002-05-20 2006-03-28 Dell Products L.P. Method to distribute periodic task workload
JP2005301812A (ja) * 2004-04-14 2005-10-27 Hitachi Ltd デジタル制御装置およびこれを用いたエンジン制御装置
EP1870806A1 (de) * 2006-06-19 2007-12-26 Wolfgang Pree GmbH System zur Ausführung von verteilter Software
JP2008046857A (ja) * 2006-08-16 2008-02-28 Seiko Epson Corp 情報処理装置、情報処理方法及びそのプログラム
JP2011170619A (ja) * 2010-02-18 2011-09-01 Toyota Motor Corp マルチスレッド処理装置
US8607247B2 (en) * 2011-11-03 2013-12-10 Advanced Micro Devices, Inc. Method and system for workitem synchronization
US9176872B2 (en) * 2013-02-25 2015-11-03 Barco N.V. Wait-free algorithm for inter-core, inter-process, or inter-task communication
US9519490B2 (en) * 2013-03-07 2016-12-13 Microsoft Technology Licensing, Llc Adaptive data synchronization
JP2016013782A (ja) * 2014-07-02 2016-01-28 株式会社デンソー 車載電子制御装置
US10133602B2 (en) * 2015-02-19 2018-11-20 Oracle International Corporation Adaptive contention-aware thread placement for parallel runtime systems
US10157092B2 (en) * 2015-04-27 2018-12-18 Oracle International Corporation Automatic targeted system suspension based upon downstream system failure detection
DE102016202305A1 (de) * 2016-02-16 2017-08-17 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Steuergeräts
US10776167B2 (en) * 2016-09-19 2020-09-15 Texas Instruments Incorporated Bandwidth controlled data synchronization for image and vision processor
US10360118B2 (en) * 2016-10-17 2019-07-23 Cboe Exchange, Inc. Low latency system having high availability computer architecture
DE102017200669A1 (de) * 2017-01-17 2018-07-19 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Steuergeräts, Computerprogramm und Verfahren zum Generieren des Computerprogramms
CN110998529B (zh) * 2017-07-31 2021-08-20 三菱电机株式会社 信息处理装置以及信息处理方法
US10552215B1 (en) * 2017-08-05 2020-02-04 Jia Xu System and method of handling real-time process overruns on a multiprocessor
GB2569269B (en) * 2017-10-20 2020-07-15 Graphcore Ltd Synchronization in a multi-tile processing arrangement
GB2569273B (en) * 2017-10-20 2020-01-01 Graphcore Ltd Synchronization in a multi-tile processing arrangement

Also Published As

Publication number Publication date
JP2019194848A (ja) 2019-11-07
CN110362413A (zh) 2019-10-22
US20190310909A1 (en) 2019-10-10
KR20190118522A (ko) 2019-10-18
US11048575B2 (en) 2021-06-29

Similar Documents

Publication Publication Date Title
DE3750306T2 (de) System zum Gewährleisten der logischen Unversehrtheit von Daten.
DE60210633T2 (de) Verfahren und vorrichtungen zur verbesserung des durchsatzes von eingebetteten prozessoren auf cache-basis durch umschalten von tasks als reaktion auf eine cache-verfehlung
DE69107506T2 (de) Verfahren und Vorrichtung zur Gleichzeitigkeitssteuerung von gemeinsamen Datenaktualisierungen und Abfragen.
DE102013214756A1 (de) Verfahren und vorrichtung zum verbessern des verarbeitungsleistungsvermögens eines mehrkernprozessors
DE3886756T2 (de) Betriebsmittelzugriff für Multiprozessorrechnersystem.
DE102007060806A1 (de) Rangbasierter Speicher-Lese/Schreib-Mikrobefehls-Scheduler
DE102014103139B4 (de) Parallelisierte Ausführung von Single-Core Steuerungssoftware auf Multi-Core Fahrzeugsteuergeräten
EP3417373B1 (de) Verfahren und vorrichtung zum betreiben eines steuergeräts
DE2101949A1 (de) Verfahren zum Schutz von Datengruppen in einer Multiprocessing-Datenverarbeitungsanlage
DE60125540T2 (de) Verfahren und gerät für einen ablaufsplanungstreiber zum implementieren eines protokolls mittels zeitschätzungen für anwendung mit einem gerät das keine unterbrechungen erzeugt
DE102007051803A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung
DE102013202774A1 (de) Vorrichtung, Verfahren und System zum Steuern eines Prozessors
DE102009055752A1 (de) Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung
DE102016221526A1 (de) Vorrichtung und Verfahren zum Bearbeiten einer Mehrzahl Aufgaben
EP3080668A1 (de) Verfahren zur beeinflussung eines steuerprogramms eines steuergeräts
DE102018205390A1 (de) Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten
DE102013022564B4 (de) Aufrechterhalten der Bandbreiten-Servicequalität einer Hardware-Ressource über einen Hardware-Zähler
DE102018205392A1 (de) Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten
DE102021131057A1 (de) System und Verfahren zur Ausführung einer Aufgabe eines Betriebssystems für ein Fahrzeug
DE102014103818A1 (de) Verfahren zum Berechnen der Auslastung einer CPU
DE102016113968A1 (de) Prozessor zur korrelationsbasierter Endlosschleifenerkennung
DE112020005072T5 (de) Datenverarbeitungseinrichtung
DE10228778B4 (de) Hardware-Verfahren zum Implementieren von atomischen Semaphoroperationen unter Verwendung von Codemakros
EP3901780A1 (de) Digitale schaltanordnung und verfahren zur konfiguration zumindest einer konfigurierbaren hardwarekomponente
DE102021209509A1 (de) Verfahren und Vorrichtung zum Bearbeiten von zumindest einer ersten und einer zweiten Rechenoperation in einer Recheneinheit