DE102014201682A1 - Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem - Google Patents

Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem Download PDF

Info

Publication number
DE102014201682A1
DE102014201682A1 DE102014201682.7A DE102014201682A DE102014201682A1 DE 102014201682 A1 DE102014201682 A1 DE 102014201682A1 DE 102014201682 A DE102014201682 A DE 102014201682A DE 102014201682 A1 DE102014201682 A1 DE 102014201682A1
Authority
DE
Germany
Prior art keywords
software
memory area
access
protected
cores
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
DE102014201682.7A
Other languages
English (en)
Inventor
Thomas Heinz
Bernd Mueller
Carsten Gebauer
Markus Schweizer
Jochen Ulrich Haenger
Peter Wegner
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 DE102014201682.7A priority Critical patent/DE102014201682A1/de
Priority to US14/603,544 priority patent/US10127161B2/en
Priority to CN201510044604.0A priority patent/CN104820626A/zh
Priority to KR1020150014255A priority patent/KR102271185B1/ko
Publication of DE102014201682A1 publication Critical patent/DE102014201682A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1433—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a module or a part of a module
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/0706—Error 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/0721—Error 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 within a central processing unit [CPU]
    • G06F11/0724—Error 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 within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error 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/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835—Timestamp

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessor, welcher mindestens zwei Rechenkerne (2, 3) aufweist, wobei jedem Rechenkern (2, 3) jeweils ein Speicherbereich (4, 5) zugeordnet wird und die Software (SW1, SW2) mit einer vorgegebenen Sicherheitsstufe auf einem der Rechenkerne (2, 3) verarbeitet wird. Bei einem Verfahren, welches einen hohen Grad an Freedom-from-Interference aufweist, wird die Software (SW1, SW2) mit der vorgegebenen Sicherheitsstufe nur auf dem Rechenkern (2, 3) verarbeitet, dem dieselbe Sicherheitsstufe zugeordnet ist, wobei während der Verarbeitung der Software (SW1, SW2) dieser Rechenkern (2, 3) nur auf den, diesem Rechenkern (2, 3) fest zugeordneten geschützten Speicherbereich (4, 5) zugreift.

Description

  • Stand der Technik
  • Die Erfindung betrifft ein Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessor, welcher mindestens zwei Rechenkerne aufweist, wobei jedem Rechenkern ein Speicherbereich zugeordnet wird und die Software mit einer vorgegebenen Sicherheitsstufe auf einen der Rechenkerne verarbeitet wird.
  • In der Automobilindustrie werden in Steuergeräten zur Steuerung verschiedener Abläufe eingebettete Systeme verwendet, bei welchem Multicore-Mikrocontroller eingesetzt werden. Diese Multicore-Mikrocontroller enthalten zwei oder mehr Rechenkerne. Für sicherheitsrelevante Anwendungen ist es üblich, diese Rechenkerne durch geeignete Hardwaremaßnahmen abzusichern, beispielsweise indem ein Rechenkern mit einem Lockstep im gekoppelten Rechenkern abgesichert wird oder eine fehlerredundante CPU verwendet wird. Bei einem Lockstep-Paar von Rechenkernen arbeiten zwei Rechenkerne synchron, wobei auf beiden Rechenkernen die gleiche Software abläuft und ein Vergleicher die Ergebnisse jeder Operation vergleicht. Bei Feststellung einer Ungleichheit wird eine Fehlermeldung ausgesendet. Als aktiver Busteilnehmer tritt das Lockstep-Paar aber nur als ein Teilnehmer auf. Ein solches Paar wird somit auch als ein abgesicherter Rechenkern bezeichnet.
  • Darüber hinaus ist im Automobilbereich für sicherheitsrelevante Elektroniksysteme die ISO 26262 relevant. Diese führt den Begriff des ASIL (Automotive Safety Integrity Level) ein und erlaubt es, verschiedene Systeme, Funktionen und Teilfunktionen nach ihrer Sicherheitsrelevanz in die verschiedenen Sicherheitsstufen ( ASILs) zu klassifizieren. Diese ASILs umfassen QM, A, B, C, D (aufsteigend sortiert). Falls verschiedene ASILs gleichzeitig in einem Rechensystem, beispielsweise einem Mikrorechner, verwendet werden, wird zwischen den verschiedenen Sicherheitsstufen eine gewisse Unabhängigkeit, eine sogenannte Freedom-from-Interference, gefordert.
  • Es ist wichtig, bei sicherheitsrelevanten Anwendungen Teile mit verschiedenen Sicherheitsstufen in einfacher Form voneinander zu trennen.
  • Offenbarung der Erfindung
  • Der Erfindung liegt somit die Aufgabe zugrunde, ein Verfahren zur Koexistenz von verschiedenen Sicherheitsstufen in einem Multicore-Prozessor anzugeben, bei welchem bei sicherheitsrelevanten Anwendungen mit verschiedenen Sicherheitsstufen versehenen Systemteile in einfacher Form voneinander getrennt werden.
  • Erfindungsgemäß wird die Aufgabe dadurch gelöst, dass der, den Softwareteil verarbeitende Rechenkern, dem der geschützte Speicherbereich zugeordnet ist, auf diesen Speicherbereich zugreift, wobei ein Zugriff mindestens einer der weiteren Rechenkerne des Multicore-Prozessors auf diesen zugeordneten geschützten Speicherbereich unterbunden wird. Dies hat den Vorteil, dass nur Systemteile miteinander kommunizieren, die derselben Sicherheitsstufe zugeordnet sind. Dadurch lassen sich die Systemteile des Multicore-Mikroprozessors mit unterschiedlichen Sicherheitsstufen einfach trennen. Eine solche Lösung erlaubt nicht nur eine möglichst gute Trennung dieser Rechenkerne und Speichereinheiten voneinander, sondern ermöglicht auch eine getrennte Entwicklung der einzelnen Systemteile. Aufgrund dessen ist eine Unabhängigkeit in Form einer Freedom-from-Interference in einem solchen Multicore-Mikroprozessorsystem gegeben. Durch diese Trennung kann eine fehlerhafte Einwirkung eines Systemteils des Multicore-Mikroprozessors auf einen anderen Systemteil des Multicore-Mikroprozessors mit hinreichender Sicherheit ausgeschlossen werden.
  • Vorteilhafterweise erlaubt eine zwischen den Rechenkernen und den Speicherbereichen ausgebildete Speicherschutzeinrichtung nur dem Rechenkern den Zugriff auf den geschützten Speicherbereich, der die gleiche Sicherheitsstufe aufweist und diesem Speicherbereich zugeordnet ist. Die grundsätzliche Idee besteht darin, dass auf jedem Rechenkern nur Software einer gegebenen Sicherheitsstufe läuft und dass sichergestellt wird, dass kein Rechenkern auf den geschützten Speicherbereich eines anderen Rechenkerns Zugriff hat. Auf jedem Rechenkern befindet sich somit Software mit einem ASIL. Mit fünf Rechenkernen lassen sich somit Systeme mit einer Sicherheitsstufe von ASIL QM, A, B, C, D realisieren. Dies ermöglicht eine Freedom-from-Interference-Argumentation in einer generischen Form und damit die Koexistenz verschiedener ASILs in einem Multicore-Mikroprozessor.
  • In einer Ausgestaltung erlaubt die zweistufig ausgebildete Speicherschutzeinrichtung einen Zugriff eines Rechenkerns auf den jeweiligen geschützten Speicherbereich über eine, in der Speicherschutzeinrichtung ausgebildete Hierarchieschicht. Die Speicherschutzeinrichtung erlaubt es, über eine geeignete Programmierung sicherzustellen, dass auf die ausgewählten geschützten Speicherbereiche nur bestimmte Busmaster Zugriff haben, was heißt, dass auf bestimmte Speicherbereiche des Multicore-Prozessors ein gegebener Master niemals Zugriff hat, unabhängig davon, welche Software auf ihm läuft.
  • In einer Variante überprüft die Software beim Startvorgang des Multicore-Prozessors, ob nur der, dem geschützten Speicherbereich zugeordnete Rechenkern Zugriff auf den geschützten Speicherbereich hat. Dadurch wird sichergestellt, dass die ausgewählten Bereiche, die eine vorgegebene Sicherheitsstufe umfassen, voneinander getrennt und von weiteren Bestandteilen des Multicore-Mikroprozessors nicht beeinflusst werden.
  • In einer Ausführungsform wird zur Überprüfung des Zugriffs auf den geschützten Speicherbereich eine Konfiguration aus der Speicherschutzeinrichtung ausgelesen oder die Speicherschutzeinrichtung durch die Software neu programmiert. Da die Neuprogrammierung nur während des Startvorganges des Multicore-Prozessors erfolgt, wird sichergestellt, dass bei Zugriff einer Software mit einer anderen Sicherheitsstufe während des Betriebes des Multicore-Prozessorsystems auf die Speicherschutzeinrichtung keine Veränderung der Konfiguration vorgenommen wird.
  • In einer weiteren Variante erfolgt die Neuprogrammierung der Speicherschutzeinrichtung statisch. Das heißt, dass nach dem Programmiervorgang die Programmierung nicht mehr verändert werden kann, was insbesondere durch die verwendete Form der Speicherschutzeinrichtung gewährleistet wird. Aufgrund dieser Vorgehensweise kann aber zum Zeitpunkt des Startens des Multicore-Mikroprozessors durch eine Software mit einer vorgegebenen Sicherheitsstufe abgesichert werden, dass unabhängig davon, ob Software mit einer anderen Sicherheitsstufe auf weiteren, in dem Multicore-Prozessorsystem enthaltenen Rechenkernen läuft, diese Software mit der anderen Sicherheitsstufe nicht auf den Bereich des Rechenkerns zugreifen kann, auf welchen die Software mit der vorgegebenen Sicherheitsstufe zugreift. Dies gilt auch dann, wenn eine weitere Software im laufenden Betrieb der Multicore-Prozessoreinheit nachgeladen wurde.
  • In einer Ausführungsform erlaubt die Konfiguration der Speicherschutzeinrichtung dem ersten, eine erste Sicherheitsstufe aufweisenden Rechenkern und einem zweiten, eine zweite Sicherheitsstufe aufweisenden Rechenkern einen Zugriff auf einen dritten geschützten Speicherbereich. Ein solcher Zugriff ist immer dann von besonderer Bedeutung, wenn die einzelnen Systemteile des Multicore-Mikroprozessors, wie der erste und der zweite Rechenkern, bei der Abarbeitung der auf ihnen laufenden Software mit verschiedenen Sicherheitsstufen miteinander kommunizieren müssen. Somit wird ein zusätzlicher geschützter Speicherbereich eingerichtet, auf welchem beide Systemteile zugreifen können. Dadurch wird gewährleistet, dass lediglich nur diese Software und keine weiteren anderen Softwarekomponenten auch auf den dritten geschützten Speicherbereich zugreifen können.
  • Vorteilhafterweise greift der erste Rechenkern auf den ersten geschützten Speicherbereich zu, während gleichzeitig der zweite Rechenkern auf den zweiten geschützten Speicherbereich zugreift. Somit kann die Software mit unterschiedlichen Sicherheitsstufen parallel nebeneinander auf den verschiedenen Rechenkernen abgearbeitet werden, wodurch der Abarbeitungsprozess infolge des parallelisierbaren Speicherzugriffs beschleunigt wird. Bei einem solchen parallelisierbaren Speicherzugriff gibt es keine Auswirkungen des Zugriffs zwischen der ersten Recheneinheit und dem ersten geschützten Speicherbereich sowie der zweiten Recheneinheit und dem zweiten geschützten Speicherbereich. Um einen solchen parallelisierbaren Speicherzugriff zu gewährleisten, können beispielsweise lokale Speicher mit einer direkten Verbindung zum Rechenkern verwendet werden, welche einen schnellen Zugriff erlauben. Weiterhin kann man über Crossbars einen echten parallelen Zugriff ermöglichen. Eine weitere Möglichkeit besteht in der Verwendung von Dual Ported Memories. Durch die Verwendung von Caches oder auch Prefetch Buffern lässt sich eine Parallelität ebenfalls häufig annähern. Insbesondere, wenn man Prefetch Buffer zeitlich so steuert, dass die Interconnect-Nutzung konfliktfrei verläuft, kann man die faktische Parallelisierung verbessern.
  • In einer weiteren Ausführungsform unterbindet ein Zeitmanagementsystem den gleichzeitigen Zugriff von dem ersten und dem zweiten Rechenkern auf den geschützten dritten Speicherbereich. Dadurch wird zuverlässig verhindert, dass ein gleichzeitiger Zugriff des ersten und des zweiten Rechenkerns auf den geschützten dritten Bereich erfolgt. Dadurch, dass eine Überlappung zweier Zugriffe verhindert wird, wird eine gegenseitige Beeinflussung der auf dem ersten bzw. dem zweiten Rechenkern ablaufenden Software unterbunden. Somit wird auch in diesem Fall die Freedom-from-Interference-Bedingung gewährleistet. Dies gilt auch bei einem nicht vollständig parallelisierbaren Verbindungssystem, wie beispielsweise einem Bus oder einem anderen Interconnect-System.
  • In der einfachsten Form einer solchen Zeitsteuerung umfasst das Zeitmanagementsystem einen Zeitplan, der festlegt, zu welchem Zeitpunkt der erste bzw. zweite Rechenkern auf den geschützten dritten Speicherbereich zugreifen. Zu einem gegebenen Zeitpunkt sollte damit höchstens eine Recheneinheit die Erlaubnis haben, auf den geschützten dritten Speicherbereich zuzugreifen. Ein solches zeitliches Ressourcenaufteilungskonzept ist beispielsweise gut für Bussysteme verwendbar, die in Steuergeräten von Kraftfahrzeugen eingesetzt werden, wie FlexRay, TTCAN, TTP/C. Somit werden Softwarekonflikte beim Zugriff verhindert und die Freedom-from-Interference erhöht.
  • In einer weiteren Variante wird zur Überwachung des Zugriffs des ersten bzw. zweiten Rechenkerns auf den geschützten dritten Speicherbereich ein Protokoll angefertigt, in welchem die Zugriffe der Rechenkerne auf den dritten geschützten Speicherbereich mit einem Zeitstempel versehen sind. Mit Hilfe eines solchen Zeitstempels lässt sich sehr einfach die zeitliche Reihenfolge der Zugriffe identifizieren und feststellen, ob ein Konfliktfall mit einer gegenseitigen Beeinflussung der Software, die unerwünscht ist, stattgefunden hat.
  • Vorteilhafterweise greift der Rechenkern mit einer vorgegebenen Sicherheitsstufe während der Verarbeitung der Software mit der entsprechenden Sicherheitsstufe nur auf ein geschütztes, für diese Verarbeitung ausgewähltes peripheres Element des Multicore-Mikroprozessors zu. Bei solchen peripheren Elementen des Multicore-Mikroprozessors kann es sich beispielsweise um A/D-Wandler, Kommunikationscontroller oder Timer handeln. Durch diese Festlegung wird gewährleistet, dass dasselbe periphere Element des Multicore-Mikroprozessors nicht gleichzeitig durch die, mit einer Sicherheitsstufe beaufschlagten Systemteile des Multicore-Mikroprozessors genutzt werden und daher keine gegenseitige Beeinflussung und somit Veränderung der Software möglich ist. Somit wird auch in diesem Fall eine Freedom-from-Interference ermöglicht, wodurch Konfigurationen und zerstörende Lesezugriffe unterbunden werden.
  • In einer Ausgestaltung wird das periphere Element nur während des Startvorganges des Multicore-Mikroprozessors konfiguriert. Damit wird sichergestellt, dass kein Softwarefehler die Konfiguration des peripheren Elementes verändern kann. Weiterhin wird zuverlässig verhindert, dass ein solcher Softwarefehler einen Einfluss auf eine andere Anwendung innerhalb des Multicore-Mikroprozessors hat, welcher das gleiche periphere Element benutzt. Sollte während des Startvorganges ein Fehler detektiert werden, so kann schon vor Inbetriebnahme des Multicore-Mikroprozessors ein Fehlersignal ausgegeben werden.
  • Abhängig davon, in welcher Form ein solcher Schutz gegen Konfigurationsänderungen möglich ist, kann es darüber hinaus noch sinnvoll sein, dass die Konfiguration des peripheren Elementes in vorgegebenen Zeitabständen lesend überprüft wird. Dies kann von jedem Systemteil des Multicore-Mikroprozessors durchgeführt werden und stellt einen aktiven Schutz gegen Konfigurationsfehler dar.
  • In einer Weiterbildung wird bei einem Download einer neuen Software auf den Multicore-Prozessor diese nur auf solchen Rechenkernen zum Ablauf gebracht, die keine Zuordnung zu einer Sicherheitsstufe und/oder keinen Zugriff auf die geschützten Speicherbereiche aufweisen. Somit kann auch während des Betriebes des Multicore-Mikroprozessors neue und zusätzliche Software geladen werden, ohne dass eine Beeinflussung auf die, einer bestimmten Sicherheitsstufe unterliegenden Systemteile des Multicore-Mikroprozessors erfolgt.
  • Die Erfindung lässt zahlreiche Ausführungsformen zu. Drei davon sollen anhand der in der Zeichnung dargestellten Figuren näher erläutert werden. Es zeigen:
  • 1: ein erstes Ausführungsbeispiel eines erfindungsgemäßen Multicore-Mikroprozessors,
  • 2: ein zweites Ausführungsbeispiel eines erfindungsgemäßen Multicore-Mikroprozessors,
  • 3: ein drittes Ausführungsbeispiel eines erfindungsgemäßen Multicore-Mikroprozessors,
  • 4: ein viertes Ausführungsbeispiel eines erfindungsgemäßen Multicore-Mikroprozessors.
  • Gleiche Merkmale sind mit gleichen Bezugszeichen gekennzeichnet.
  • 1 zeigt ein erstes Ausführungsbeispiel eines Multicore-Mikroprozessors 1, welches beispielsweise in eingebetteten Systemen in Steuergeräten von Kraftfahrzeugen verwendet wird und zwei Rechenkerne 2, 3 aufweist. Dem Rechenkern 2 ist der Speicherbereich 4 und dem Rechenkern 3 ist der Speicherbereich 5 zugeordnet. Beide Rechenkerne 2, 3 greifen auf die Speicherbereiche 4, 5 nur über eine entsprechende Speicherschutzeinrichtung 6 zu, welche als Memory Protection Unit (MPU) ausgebildet ist. Insbesondere erfolgt der Zugriff über eine entsprechende zweite Schicht der Memory Protection Unit, wie sie z. B. in der EP 2 461 251 A1 beschrieben ist, beispielsweise auch über eine zusätzliche Safety-MPU. Der Speicherbereich 4 ist dabei nur für den Rechenkern 2 zugreifbar, was heißt, dass der Rechenkern 3 nicht auf den Speicherbereich 4 zugreifen darf. Entsprechend darf der Rechenkern 3 nur auf den Speicherbereich 5 zugreifen, wobei der Rechenkern 2 nicht auf den Speicherbereich 5 zugreifen darf. Es ist denkbar, dass es noch weitere, nicht weiter dargestellte Speicherbereiche gibt, auf die aber beide Rechenkerne 2, 3 zugreifen können.
  • In Steuergeräten von Kraftfahrzeugen laufen Softwareanwendungen mit unterschiedlichen Sicherheitsstufen ab. Solche Sicherheitsstufen werden in ASILs (Automotive Safety Integrity Level) gekennzeichnet. Diese Anwendungen werden nach ihrer Sicherheitsrelevanz in die verschiedenen, Sicherheitsstufen darstellenden ASILs, wie QM, A, B, C, D aufsteigend klassifiziert. Beispielsweise können die folgenden Softwareanwendungen entsprechende ASILs aufweisen:
    ASIL D Steuerung des Antiblockiersystems,
    ASIL B Steuerung des Einspritzsystem,
    QM Klimaregelung des Fahrzeuginnenraumes.
  • Eine Software SW1, beispielsweise für die Steuerung des Antiblockiersystems des Kraftfahrzeuges, die die Sicherheitsstufe D aufweist, wird dabei nur auf dem Rechenkern 2 abgearbeitet, der für die Sicherheitsstufe D zugelassen ist. Eine zweite Anwendung in Form der Software SW2, beispielsweise der Benzineinspritzung, weist eine Sicherheitsstufe B auf. Diese Software SW2 wird ausschließlich auf dem Rechenkern 3 abgearbeitet, welcher für diese Sicherheitsstufe B zugelassen ist. Eine Freedom-from-Interference, d.h. eine Rückwirkungsfreiheit zwischen den beiden Softwareanwendungen, wird dadurch realisiert, dass die Software SW1 nur auf dem Rechenkern 2 zum Ablauf gebracht wird und die Software SW2 nur auf dem Rechenkern 3.
  • 2 zeigt ein zweites Ausführungsbeispiel des Multicore-Mikroprozessors 9, bei welchem der Multicore-Mikroprozessor um die Rechenkerne 7 und 8 erweitert ist. Auch auf diesen Rechenkernen 7 und 8 läuft jeweils der Softwareanwendung SW3 bzw. der Softwareanwendung SW4 ab. Auch bei diesem Ausführungsbeispiel ist die gewünschte Freedom-from-Interference von allen weiteren Softwareanwendungen SW3, SW4 auf die Software SW1 und auch SW2 dann gewährleistet, wenn gilt, dass die Recheneinheit 2 nur die Software SW1 und die Recheneinheit 3 nur die Software SW2 verarbeitet. Darüber hinaus muss gewährleistet sein, dass nur die Recheneinheit 2 Zugriff auf den Speicherbereich 4 und nur die Recheneinheit 3 Zugriff auf den Speicherbereich 5 hat. Wenn dies durch die Verwendung der bereits beschriebenen Speicherschutzeinrichtung 6 auf die Rechenkerne 2, 3 gewährleistet ist, dann kann variable, im stärksten Fall dynamisch herunter geladene Software diese Eigenschaft der Multicore-Mikroprozessors 9 nicht verändern, so dass die Freedom-from-Interference-Bedingungen sogar für alle Fälle garantiert wird. Für die Softwareanwendungen SW3 und SW4 bestehen keinerlei Forderungen, dass sie einer bestimmten Recheneinheit zugeordnet sind. Sie können weitgehend beliebig auf die Recheneinheiten 2, 3, 7 oder 8 verteilt sein.
  • Um sich zu vergewissern, dass die Rechenkerne 3, 7, 8 keinen Zugang zum besonders geschützten Speicherbereich 4 haben, liest die Software SW1 während eines Boot- oder Startvorganges die Konfiguration der Speicherschutzeinrichtung 6 aus und bewertet sie. Es besteht aber auch die Möglichkeit, dass die Konfiguration der Speicherschutzeinrichtung 6 durch die Software SW1 während des Boot- oder Startvorganges selbst programmiert wird. Dabei muss lediglich gewährleistet sein, dass diese Programmierung statisch ist, d.h. dass nach dem Bootvorgang an der Konfiguration nichts mehr verändert werden kann. Somit wird zum Startzeitpunkt von der Software SW1 abgesichert, dass, unabhängig davon welche Software SW2, SW3, SW4 auf anderen Rechenkernen 3, 7, 8 läuft, diese Software SW2, SW3, SW4 nicht auf den Speicherbereich 4 zugreifen kann. Dies gilt selbst dann, wenn diese Software SW2, SW3, SW4 im laufenden Betrieb nachgeladen wird. Voraussetzung dafür ist, dass die nachgeladene Software nicht auf dem Rechenkern 2 zum Ablauf kommt, sondern auf einem der anderen Rechenkerne 3, 7 bzw. 8.
  • In Anwendungsfällen kommt es regelmäßig vor, dass verschiedene Softwareanwendungen während der Verarbeitung miteinander kommunizieren müssen. Um dies auch bei der beschriebenen Konfiguration des Multicore-Mikroprozessors 11 zu gewährleisten, wird, wie in 3 dargestellt, ein Speicherbereich 10 eingeführt, auf welchen sowohl der Rechenkern 2 als auch der Rechenkern 3 über die Speicherschutzeinrichtung 6 Zugriff haben. Dabei ist die Speicherschutzeinrichtung 6 so konfiguriert, dass auf den Speicherbereich 4 nur der Rechenkern 2, auf den Speicherbereich 5 nur der Rechenkern 3 und auf den Speicherbereich 10 nur die Rechenkerne 2 und 3 Zugriff haben. In diesem Fall ist, unabhängig davon, wie viele weitere Rechenkerne 7 in dem Mikroprozessorsystem 11 vorliegen und welche Softwareanwendungen auf diesen läuft, gewährleistet, dass es keine Einflussmöglichkeit von weiteren Softwareanwendungen, anderen Recheneinheiten und anderen Speicherbereichen gibt.
  • Um auch bei einem Zugriff des Rechenkerns 2 bzw. des Rechenkerns 3 auf den Speicherbereich 10 eine Freedom-from-Interference zu realisieren, werden bestimmte Timing-Randbedingungen gesetzt und gegebenenfalls überwacht. Wenn sichergestellt ist, dass sich die Zugriffe auf einen Speicherbereich, eine Speicherstelle, einen Interconnect oder eine andere Source/Adresse nicht überlappen, kann ein Zugriffskonflikt verhindert werden. Um dies zu realisieren, wird ein Zeitplan eingeführt, in welchem hinterlegt ist, zu welchem Zeitpunkt der Rechenkern 2 und zu welchem Zeitpunkt der Rechenkern 3 auf den Speicherbereich 10 zugreifen können. Dabei wird gewährleistet, dass immer nur ein Rechenkern 2, 3 auf den Speicherbereich 10 zugreifen darf.
  • Es ist möglich, diese Art der Aufteilung zu überwachen, beispielsweise indem man das Prüfprogramm in ein Busprotokoll integriert oder indem man es auf Konflikte überwacht. Dies kann z.B. dadurch geschehen, dass der Konfliktfall protokolliert wird, indem z.B. ein geeignetes Datum eingefügt wird. Ein solches Protokoll kann beispielsweise die folgenden Bestandteile aufweisen:
    • – Der aktuelle Betreiber des Busses wird festgehalten, indem der Busmaster als auch die Softwarekomponente in Form der Aufgabe M oder des Betriebssystems Y gespeichert wird.
    • – Ein Zeitstempel wird gespeichert.
    • – Diese Informationen werden gespeichert und vorteilhafterweise in einem FIFO-Speicher mit einer endlichen Länge abgelegt. Bei bestimmten Ereignissen, wie Konflikten, wird dieser FIFO-Speicher kopiert, eventuell zusammen mit Informationen über das andere Systemteil, das zugreifen möchte.
  • Die Konflikte werden durch ein geeignetes Prüfprogramm ausgewertet. Im Falle kritischer Konflikte wird ein sicherer Systemzustand hergestellt.
  • Es gibt aber auch komplexere Interference-Möglichkeiten bei einem Austausch von Informationen. Wenn beispielsweise durch einen Fehler oder eine spezielle Eigenschaft einer Softwareanwendung, beispielsweise der Software SW1 in 3, ein auszutauschendes Datum, das in dem Speicherbereich 10 liegt, zeitlich oder inhaltlich nicht korrekt geliefert wird, dann kann dieser Fehler sich über diesen Austausch auf die Software SW2 auswirken. Für den Umgang mit solchen zeitlichen Problemen ist es ebenfalls möglich, Zeitinformationen z.B. Rundencounter oder Zeitstempel zu dem Datum hinzuzufügen. Die Korrektheit dieser Zeitinformation kann dann beim Auslesen mit überwacht werden. Beispielsweise kann überprüft werden, ob das Datum mit dem richtigen Rundencounter versehen ist. Bei einem Zeitstempel wird überprüft, ob das richtige „Alter“ vorliegt, z.B. „höchstens 10 ms alt“. Bei einer geeigneten Aufteilung der Softwareanwendungen kann diese Überwachung dann möglicherweise durch einen Betriebssystemservice oder eine Basissoftwarekomponente, die anwendungsunabhängig ist und nur geeignet konfiguriert wird, durchgeführt werden.
  • Die gleichen Mechanismen, die für den Zugriff auf einen gemeinsam genutzten Speicherbereich anwendbar sind, können auch für gemeinsam genutzte periphere Elemente, beispielsweise A/D-Wandler, Kommunikationscontroller oder Timer, etc. verwendet werden (4). Dies kann dadurch realisiert werden, dass das periphere Element 12, 13 nur in einem Bootvorgang konfiguriert werden kann. Anschließend kann eine Anwendung für das periphere Element 12, 13 konfiguriert werden, wobei andere Systemteile des Multicore-Mikroprozessors 15 die Konfiguration lesen und falls alles in Ordnung ist, von einer korrekten Konfiguration im Betrieb ausgegangen werden. Falls keine korrekte Konfiguration erfolgt ist, wird bereits beim Start des Multicore-Mikroprozessors 15 eine Fehlermeldung abgegeben. Abhängig davon, in welcher Form ein solcher Schutz gegen Konfigurationsänderung eingestellt ist, kann es darüber hinaus noch sinnvoll sein, dass die Konfiguration des peripheren Elementes 12, 13 regelmäßig lesend überprüft wird. Dies kann von jeder Softwareanwendung SW durchgeführt werden und stellt einen aktiven Schutz gegen Konfigurationsfehler dar.
  • Wenn neue oder zusätzliche Softwareanwendung SW per Download auf den Multicore-Mikroprozessor eines Steuergerätes geladen werden soll, dann ist es empfehlenswert, folgende Randbedingungen einzuhalten.
    • – Die schon vorhandenen Softwareanwendung, die gegen Interference von heruntergeladenen Softwareanwendungen geschützt werden soll, ist auf eine feste Teilmenge der Rechenkerne verteilt und verwendet einen fest definierten Speicherbereich.
    • – Die neu heruntergeladene Softwareanwendung wird nur auf anderen Rechenkernen zum Ablauf gebracht.
    • – Die Speicherschutzeinrichtung ist so konfiguriert, dass keine der anderen Rechenkerne auf den fest definierten Speicherbereich einen schreibenden Zugriff erhält.
    • – Im Optimalfall sind die Speicherzugriffe voll parallelisierbar.
  • 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
    • EP 2461251 A1 [0027]
  • Zitierte Nicht-Patentliteratur
    • ISO 26262 [0003]

Claims (15)

  1. Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessor, welcher mindestens zwei Rechenkerne (2, 3) aufweist, wobei einem Rechenkern (2) ein Speicherbereich (4) zugeordnet wird und die Softwareteile (SW1, SW2) mit je einer vorgegebenen Sicherheitsstufe auf je einem der Rechenkerne (2, 3) verarbeitet werden, dadurch gekennzeichnet, dass der, den Softwareteil (SW1) verarbeitende Rechenkern (2), dem der geschützte Speicherbereich (4) zugeordnet ist, auf diesen Speicherbereich (4) zugreift, wobei ein Zugriff mindestens einer der weiteren Rechenkerne (3, 7, 8) des Multicore-Prozessors (1, 9, 11, 15) auf diesen zugeordneten geschützten Speicherbereich (4) unterbunden wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine zwischen den Rechenkernen (2, 3) und den Speicherbereichen (4, 5) ausgebildete Speicherschutzeinrichtung (6) nur dem Rechenkern (2, 3) den Zugriff auf den Speicherbereich (4, 5) erlaubt, welcher dem geschützten Speicherbereich (4, 5) zugeordnet ist.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die zweistufig ausgebildete Speicherschutzeinrichtung (6) einen Zugriff eines Rechenkerns (2, 3) auf den jeweiligen geschützten Speicherbereich (4, 5) über eine, in der Speicherschutzeinrichtung (6) ausgebildete Hierarchieschicht erlaubt.
  4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass die Software (SW1) beim Startvorgang des Multicore-Prozessors (1, 9, 11, 15) überprüft, ob nur der dem geschützten Speicherbereich (4, 5) zugeordnete Rechenkern (2, 3) Zugriff auf den geschützten Speicherbereich (4, 5) hat.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass zur Überprüfung des Zugriffs auf den geschützten Speicherbereich (4, 5) eine Konfiguration aus der Speicherschutzeinrichtung (6) ausgelesen wird oder die Speicherschutzeinrichtung (6) durch die Software neu programmiert wird.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Neuprogrammierung der Speicherschutzeinrichtung (6) statisch erfolgt.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Konfiguration der Speicherschutzeinrichtung (6) dem ersten, eine erste Sicherheitsstufe aufweisenden Rechenkern (2) und einem zweiten, eine zweite Sicherheitsstufe aufweisenden Rechenkern (3) einen Zugriff auf einen dritten geschützten Speicherbereich (10) erlaubt.
  8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass während der erste Rechenkern (2) auf den ersten geschützten Speicherbereich (3) zugreift, gleichzeitig der zweite Rechenkern (3) auf den zweiten geschützten Speicherbereich (4) zugreift.
  9. Verfahren nach mindestens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Zeitmanagementsystem den gleichzeitigen Zugriff von dem ersten und dem zweiten Rechenkern (2, 3) auf den geschützten dritten Speicherbereich (10) unterbindet.
  10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das Zeitmanagementsystem einen Zeitplan umfasst, welcher festlegt, zu welchem Zeitpunkt der erste bzw. der zweite Rechenkern (2, 3) auf den geschützten dritten Speicherbereich (10) zugreifen.
  11. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass zur Überwachung des Zugriffs des ersten bzw. zweiten Rechenkerns (2, 3) auf den geschützten dritten Speicherbereich (10) ein Protokoll angefertigt wird, in welchem die Zugriffe der Rechenkerne (2, 3) auf den dritten geschützten Speicherkern (10) mit einem Datum versehen werden.
  12. Verfahren nach mindestens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Rechenkern (2, 3) mit einer vorgegebenen Sicherheitsstufe während der Verarbeitung der Software (SW1, SW2) mit der entsprechenden Sicherheitsstufe nur auf ein geschütztes, für diese Verarbeitung ausgewähltes peripheres Element (12) des Multicore-Prozessors (1, 9, 11, 15) zugreift.
  13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das periphere Element (12) nur während des Startvorgangs des Multicore-Prozessors (1, 9, 11) konfiguriert wird.
  14. Verfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass die Konfiguration des peripheren Elementes (12) in vorgegebenen Zeitabständen lesend überprüft wird.
  15. Verfahren nach mindestens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem Download einer neuen Software auf den Multicore-Prozessor (1, 9, 11) diese nur auf solche Rechenkerne (7, 8) zum Ablauf gebracht wird, die keine Zuordnung zu einer Sicherheitsstufe und/oder keinen Zugriff auf die geschützten Speicherbereiche (4, 5, 10) aufweisen.
DE102014201682.7A 2014-01-30 2014-01-30 Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem Pending DE102014201682A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE102014201682.7A DE102014201682A1 (de) 2014-01-30 2014-01-30 Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
US14/603,544 US10127161B2 (en) 2014-01-30 2015-01-23 Method for the coexistence of software having different safety levels in a multicore processor system
CN201510044604.0A CN104820626A (zh) 2014-01-30 2015-01-29 用于使具有不同的安全等级的软件在多核处理器***中共存的方法
KR1020150014255A KR102271185B1 (ko) 2014-01-30 2015-01-29 멀티 코어 프로세서 시스템 내에서 상이한 안전 단계를 갖는 소프트웨어의 공존 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102014201682.7A DE102014201682A1 (de) 2014-01-30 2014-01-30 Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem

Publications (1)

Publication Number Publication Date
DE102014201682A1 true DE102014201682A1 (de) 2015-07-30

Family

ID=53523005

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014201682.7A Pending DE102014201682A1 (de) 2014-01-30 2014-01-30 Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem

Country Status (4)

Country Link
US (1) US10127161B2 (de)
KR (1) KR102271185B1 (de)
CN (1) CN104820626A (de)
DE (1) DE102014201682A1 (de)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017093029A1 (de) * 2015-11-30 2017-06-08 Robert Bosch Gmbh Verfahren zum betreiben eines mikrocontrollers
DE102016210423A1 (de) 2016-06-13 2017-12-14 Robert Bosch Gmbh Verfahren und Vorrichtung zum Übertragen von Daten
DE102019200812A1 (de) * 2019-01-23 2020-07-23 Audi Ag Verfahren zum Schützen einer Hauptfunktion eines Steuergeräts vor einer Behinderung ihres Betriebs durch einen Laufzeitfehler einer Nebenfunktion des Steuergeräts sowie Steuergerät, Kraftfahrzeug und Fahrzeugbatterie
DE102016223670B4 (de) * 2015-11-30 2021-04-29 Denso Corporation Elektronische Steuereinheit
WO2021122734A1 (de) * 2019-12-20 2021-06-24 Robert Bosch Gmbh Verfahren und vorrichtung zum betreiben einer recheneinrichtung
DE102022125711A1 (de) 2022-10-05 2024-04-11 Audi Aktiengesellschaft Verfahren zum Aktualisieren eines Steuergeräts eines Fahrzeugs
DE102022213911A1 (de) 2022-12-19 2024-06-20 Zf Friedrichshafen Ag Fahrzeugsteuergerät und Verfahren zum Betreiben desselben

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014209489A1 (de) * 2014-05-20 2015-11-26 Robert Bosch Gmbh Vorrichtung zum sicheren Einbinden einer Softwarekomponente in einem Kraftfahrzeug
US9694765B2 (en) * 2015-04-20 2017-07-04 Hitachi, Ltd. Control system for an automotive vehicle
JP6486485B2 (ja) * 2015-09-30 2019-03-20 日立オートモティブシステムズ株式会社 車載制御装置
DE102016003362A1 (de) * 2016-03-18 2017-09-21 Giesecke+Devrient Currency Technology Gmbh Einrichtung und Verfahren zur Auswertung von Sensordaten für ein Wertdokument
DE102016215345A1 (de) * 2016-08-17 2018-02-22 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur redundanten Datenverarbeitung
CN106339332B (zh) * 2016-08-23 2019-10-25 Oppo广东移动通信有限公司 一种信息处理方法、装置和终端
FR3065550A1 (fr) * 2017-09-29 2018-10-26 Continental Automotive France Procede d'echange protege de donnees entre deux taches
US20190243698A1 (en) * 2018-02-02 2019-08-08 Robert Bosch Gmbh Electronic Control Unit for Flexible Replacement of Replaceable Components in a Vehicle
JP7042709B2 (ja) * 2018-06-28 2022-03-28 ルネサスエレクトロニクス株式会社 半導体装置、制御システムおよび半導体装置の制御方法
CN108910637A (zh) * 2018-07-18 2018-11-30 迅达（中国）电梯有限公司 安全***
CN112528345A (zh) * 2019-09-18 2021-03-19 华为技术有限公司 通信方法、装置、计算机可读存储介质和芯片
CN111026573B (zh) * 2019-11-19 2023-08-18 中国航空工业集团公司西安航空计算技术研究所 一种多核处理***的看门狗***及控制方法
CN112035394B (zh) * 2020-07-27 2021-04-27 首都师范大学 面向实时处理的多核处理器的存储装置及数据处理方法
US20220349353A1 (en) * 2021-04-30 2022-11-03 Raytheon Technologies Corporation Gas turbine engine communication data management function
US11745724B2 (en) 2021-05-13 2023-09-05 Dana Belgium N.V. Diagnostic and control method for a vehicle system
US11535239B2 (en) 2021-05-13 2022-12-27 Dana Belgium N.V. Diagnostic and control method for a vehicle system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2461251A1 (de) 2010-12-03 2012-06-06 Robert Bosch GmbH Speicherschutzeinheit und Verfahren zur Steuerung eines Zugangs zu einer Speichervorrichtung

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3864509B2 (ja) * 1997-08-19 2007-01-10 株式会社日立製作所 マルチプロセッサシステム
US20030212889A1 (en) * 2002-05-13 2003-11-13 Khieu Andrew K. Method and system for exchanging data over networks using public key encryption
US7558775B1 (en) * 2002-06-08 2009-07-07 Cisco Technology, Inc. Methods and apparatus for maintaining sets of ranges typically using an associative memory and for using these ranges to identify a matching range based on a query point or query range and to maintain sorted elements for use such as in providing priority queue operations
US20060200481A1 (en) * 2005-03-04 2006-09-07 Khalid Goyan Method and system for data optimization and protection in DSP firmware
JP2007004661A (ja) * 2005-06-27 2007-01-11 Hitachi Ltd 仮想計算機の制御方法及びプログラム
US20080263256A1 (en) * 2007-04-20 2008-10-23 Motorola, Inc. Logic Device with Write Protected Memory Management Unit Registers
EP2225645B1 (de) * 2007-12-17 2011-07-27 Continental Teves AG & Co. oHG Speicherabbildungssystem, anforderungssteuerung, mehrfach-verarbeitungsanordnung, zentrale interrput-request-steuerung, vorrichtung, verfahren zur steuerung des speicherzugriffs und computerprogrammprodukt
DE102011086530A1 (de) * 2010-11-19 2012-05-24 Continental Teves Ag & Co. Ohg Mikroprozessorsystem mit fehlertoleranter Architektur
US9158592B2 (en) * 2011-05-02 2015-10-13 Green Hills Software, Inc. System and method for time variant scheduling of affinity groups comprising processor core and address spaces on a synchronized multicore processor
US9098709B2 (en) * 2012-11-13 2015-08-04 International Business Machines Corporation Protection of user data in hosted application environments
US9298914B1 (en) * 2013-12-03 2016-03-29 Symantec Corporation Enterprise data access anomaly detection and flow tracking

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2461251A1 (de) 2010-12-03 2012-06-06 Robert Bosch GmbH Speicherschutzeinheit und Verfahren zur Steuerung eines Zugangs zu einer Speichervorrichtung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ISO 26262

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017093029A1 (de) * 2015-11-30 2017-06-08 Robert Bosch Gmbh Verfahren zum betreiben eines mikrocontrollers
DE102016223670B4 (de) * 2015-11-30 2021-04-29 Denso Corporation Elektronische Steuereinheit
DE102016210423A1 (de) 2016-06-13 2017-12-14 Robert Bosch Gmbh Verfahren und Vorrichtung zum Übertragen von Daten
DE102019200812A1 (de) * 2019-01-23 2020-07-23 Audi Ag Verfahren zum Schützen einer Hauptfunktion eines Steuergeräts vor einer Behinderung ihres Betriebs durch einen Laufzeitfehler einer Nebenfunktion des Steuergeräts sowie Steuergerät, Kraftfahrzeug und Fahrzeugbatterie
WO2021122734A1 (de) * 2019-12-20 2021-06-24 Robert Bosch Gmbh Verfahren und vorrichtung zum betreiben einer recheneinrichtung
DE102022125711A1 (de) 2022-10-05 2024-04-11 Audi Aktiengesellschaft Verfahren zum Aktualisieren eines Steuergeräts eines Fahrzeugs
WO2024074402A1 (de) 2022-10-05 2024-04-11 Audi Ag Verfahren zum aktualisieren eines steuergeräts eines fahrzeugs
DE102022213911A1 (de) 2022-12-19 2024-06-20 Zf Friedrichshafen Ag Fahrzeugsteuergerät und Verfahren zum Betreiben desselben

Also Published As

Publication number Publication date
KR102271185B1 (ko) 2021-07-01
CN104820626A (zh) 2015-08-05
KR20150091013A (ko) 2015-08-07
US20150212952A1 (en) 2015-07-30
US10127161B2 (en) 2018-11-13

Similar Documents

Publication Publication Date Title
DE102014201682A1 (de) Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
WO2013171122A2 (de) Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts
EP2698678B1 (de) Konfigurationstechnik für ein Steuergerät mit miteinander kommunizierenden Anwendungen
EP1061447A2 (de) Partitionierung und Überwachung von softwaregesteuerten Systemen
DE102016202305A1 (de) Verfahren und Vorrichtung zum Betreiben eines Steuergeräts
EP3566398B1 (de) Verfahren und halbleiterschaltkreis zum schützen eines betriebssystems eines sicherheitssystems eines fahrzeugs
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
DE102013016114B3 (de) Bussystem und Verfahren für geschützte Speicherzugriffe
DE102013202961A1 (de) Verfahren zum Überwachen eines Stackspeichers in einem Betriebssystem eines Steuergeräts eines Kraftfahrzeuges
DE102016116221A1 (de) Verfahren und Einrichtung zur Überwachung der Ausführung eines Programmcodes
DE102016224206A1 (de) Fahrzeugsteuervorrichtung
DE102005037226A1 (de) Verfahren und Vorrichtung zur Festlegung eines Startzustandes bei einem Rechnersystem mit wenigstens zwei Ausführungseinheiten durch markieren von Registern
EP1894101A1 (de) Verfahren und vorrichtung zum überwachen eines unerlaubten speicherzugriffs einer rechenvorrichtung, insbesondere in einem kraftfahrzeug
DE102010027287A1 (de) Verfahren und Vorrichtung zum prüfen eines Hauptspeichers eines Prozessors
EP2338111B1 (de) Verfahren und vorrichtung zum testen eines rechnerkerns in einer mindestens zwei rechnerkerne aufweisenden recheneinheit
DE112015002881B4 (de) Speichervorrichtung, Flash-Speicher-Steuervorrichtung und Programm
DE102018210733A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
WO2017102655A1 (de) Mikrocontrollersystem und verfahren zur kontrolle von speicherzugriffen in einem mikrocontrollersystem
DE102018123563B4 (de) Verfahren zur Zwischenkernkommunikation in einem Mehrkernprozessor
WO2017153411A1 (de) Verfahren zum betreiben eines steuergeräts für ein kraftfahrzeug
EP3391279B1 (de) Mikrocontrollersystem und verfahren zur kontrolle von speicherzugriffen in einem mikrocontrollersystem
DE102021212594A1 (de) Verfahren zum Starten einer Speichereinheit einer Recheneinheit
DE102022202335A1 (de) Computerimplementiertes verfahren zur speicheroptimierung eines partitionierten systems
DE102014209592A1 (de) Verfahren zum Erzeugen einer Hypervisor-Einheit und Hypervisor-Einheit
DE102015214389A1 (de) Verfahren und Vorrichtung zum Aktualisieren einer auf einer physischen Maschine unter einem Hypervisor betriebenen virtuellen Maschine

Legal Events

Date Code Title Description
R012 Request for examination validly filed