-
Die
Erfindung betrifft ein Verfahren zum Betreiben einer Recheneinheit,
eine Recheneinheit, ein Computerprogramm und ein Computerprogrammprodukt.
-
Stand der Technik
-
Bei
Kraftfahrzeugen ist es üblich,
Programmteile oder Programmcodes für eine Recheneinheit, d.h.
für eine
Mikroprozessor-Anordnung bzw. ein Mikroprozessor-System, von mehreren
Herstellern einzusetzen. Diese werden anschließend von einem Systemintegrator
zu einer lauffähigen
Gesamtsoftware zusammengebunden. Ein derartiges Mikroprozessor-System
kann beispielsweise zur Motorsteuerung in einem Kraftfahrzeug vorgesehen
sein. Die Gesamtsoftware wird anschließend in den zumeist persistenten
Speicher des Mikroprozessor-System geladen
und zur Ausführung
gebracht. Die Programmteile der verschiedenen Hersteller kommunizieren über vorher
verbindlich definierte Schnittstellen miteinander, um die vorgesehene
Gesamtfunktionalität
der Mikroprozessor-Anordnung bereitzustellen. Diese Programmteile
aus dem Stand der Technik sind in einem Flash gespeichert und können nicht verändert werden.
-
Mit
Kooperationsmodellen, wie bspw. den Projekten ASAM (Association
for Standardization of Automation and Measuring Systems), MSR (Manufacturer
Supplier Relationship) oder AUTOSAR (Automotive Open System Architecture),
ist eine Zusammenarbeit von Herstellern und Zulieferern in der Automobilbranche
vorgesehen. Die voranstehend beispielhaft erwähnten Projekte haben u.a. das
Ziel, standardisierte Schnittstellen für Softwarefunktionalitäten festzulegen,
so dass mittels derartiger Standards ein Automobilhersteller die
sogenannten Softwarekomponenten von verschiedenen, z.T. konkurrierenden
Zulieferbetrieben beziehen und ohne Anpassungsaufwand zu einem Gesamtsystem
integrieren kann. Bei diesen Projekten sind zwischen unterschiedlichen
Programmteilen von verschiedenen Herstellern unbeabsichtigte Wechselwirkungen
zu erwarten.
-
In
aktuellen Mikroprozessor-Anordnungen sind unterschiedliche Programmteile
jedoch auch in der Lage, neben den offiziell definierten Schnittstellen,
beabsichtigt oder unbeabsichtigt, den Programmablauf beliebiger
anderer Programmteile und damit auch die Programmteile anderer Hersteller
zu beeinflussen. Die Automobilindustrie versucht deshalb unter anderem
durch standardisierte Codierrichtlinien, wie z.B. den so genannten
MISRA-Standard, derartige unbeabsichtigte Beeinflussungen zu verhindern.
-
Der
Systemintegrator eines derart bereitgestellten Softwaresystems ist
jedoch aus IP-schutzrechtlichen
und zeitlichen Gründen
nicht in der Lage, einen vollständigen
Funktionstest des Gesamtsystems durchzuführen. Ebenfalls aus IP-schutzrechtlichen
Gründen
stellen die Zulieferer nur ausführbare Softwarekomponenten
jedoch nicht den Quelltext zur Verfügung. Dem Systemintegrator
ist daher regelmäßig nicht
bewusst, ob er einen vollständigen
Funktionstest durchführen
kann. Dies bedeutet, dass er beispielsweise nicht nachweisen kann,
ob er alle Verzweigungen des zugelieferten Programmcodes in ihrem
Verhalten im Gesamtkontext überprüft hat.
Demnach ist keine 100%ige Testabdeckung realisierbar.
-
Selbst
für den
Fall, dass alle Zulieferer den Quellcode für ihre Softwarekomponenten
zur Verfügung
stellen würden,
ist eine vollständige
Testabdeckung aufgrund der Skalierbarkeit in endlicher Zeit nicht
möglich,
da für
aktuelle Software oder Softwaresysteme derart viele Kombinationsmöglichkeiten existieren,
dass ein vollständiger
Test nur unter sehr großem
Zeitaufwand durchzuführen
ist. Selbst bei einer Beschränkung
auf nur eine Softwarekonfiguration, ist bspw. für Eingangswerte (Inputs) in
das System, insbesondere unter Einbeziehung laufzeitlicher Aspekte,
eine Anzahl der zu testenden Kombinationsmöglichkeiten sehr groß.
-
Auch
ein sehr ausführlicher
Funktionstest, der bereits beim Zulieferer durchgeführt wird,
birgt das Risiko, dass sich eine getestete Funktion nach Integration
in die Gesamtsoftware beim Systemintegrator anders als beim Zulieferer
während
der Testphase verhält.
Dies kann zum Beispiel daran liegen, dass die Konsequenzen eines
eventuellen Fehlverhaltens nicht dieselben wie im Gesamtsystem sind. Es
kann sogar sein, dass die vom Zulieferer getesteten Konfigurationen
kein Fehlverhalten zeigen, jedoch eine vom Systemintegrator verwendete
Konfiguration im Gesamtsystem fehlerhaft ist.
-
Ein
Fehlverhalten einer ersten Softwarekomponenten eines ersten Zulieferers,
das sich als Folge eines Fehlverhaltens einer zweiten Softwarekomponente
eines zweiten Zulieferers ergibt, ist durchaus denkbar und kann
bei einem dadurch ausgelösten Unfall
zu Personenschäden
führen.
-
Als
ein anwendungsbezogenes Beispiel ist vorgesehen, dass in einem Motorsteuergerät zwei konkrete
Implementierungen von Softwarekomponenten integriert sind, wobei
eine erste Softwarekomponente die Steuerung der Fensterheber und
eine zweite Softwarekomponente innerhalb des Motors die Berechnung
einer benötigten
Einspritzmenge für ein
angefordertes Moment betrifft.
-
Dabei
kann es vorkommen, dass in der Softwarekomponente zur Steuerung
der Fensterheber eine Fehlfunktion auftritt. Zudem kann bei der
beschriebenen Konfiguration von Softwarekomponenten eine Berechnung
der Einspritzmenge durch das Gesamtsystems derart modifiziert werden,
dass es aufgrund einer beabsichtigten Veränderung einer Fensterposition
zu einer unbeabsichtigten Momentenerhöhung kommt, wodurch das Fahrzeug
beschleunigt wird, was zu einem Unfall führen kann.
-
Dieser
Fehlerfall ist selbst unter Berücksichtigung
der voranstehend beschriebenen Maßnahmen nicht auszuschließen. Bereits
die fehlerhafte Berechnung eines Feld-Indexes kann einen fehlerhaften Pointer
erzeugen, der nun an beliebige Stellen des Speichers, z.B. in den
Bereich der Einspritzmengenberechnung, zeigt und dort zu Schreibzugriffen
führen
kann. Die Codierrichtlinie MISRA kann ein derartiges Fehlverhalten
nicht ausschließen,
da Datenfelder bei der Programmierung häufig benötigt werden.
-
Diesbezüglich stellt
sich bspw. unter juristischen Aspekten die Frage, ob nun der Systemintegrator
oder der Zulieferer im Sinne der Produkthaftung für den entstandenen
Schaden verantwortlich ist. Dabei ist zu berücksichtigen, dass der Systemintegrator
nicht in der Lage ist, das System vollständig zu testen. Der Zulieferer,
dessen Komponenten eine falsche Mengenerhöhung berechnet hat, kann sich nur
schwer gegen derartige Fehleingriffe von außen absichern. Zudem kann der
Zulieferer, dessen Komponente die unbeabsichtigte Modifikation vorgenommen
hat, nicht wissen, in welchem konkreten Gesamtsystem seine Komponente
eingesetzt wird.
-
Unter
technischen Gesichtspunkten stellt sich die Frage, wie eine derartige
temporäre
Fehlfunktion überhaupt
nachgewiesen werden kann. Üblicherweise
treten konkrete Fehler nur zeitlich begrenzt auf und sind spätestens
nach Abschalten des Steuergeräts
nicht mehr vorhanden. Um einen Fehler zweifelsfrei nachzuweisen,
müsste
der komplette Zustand des Steuergeräts eingefroren werden. Auch eine
Reproduktion eines derartigen Fehlers ist extrem schwierig. Selbst
wenn die Reproduktion gelingen sollte, ist damit nur bewiesen, dass
dieser Fehler möglich
ist. Es ist jedoch nicht nachgewiesen, dass der reproduzierte Fehler
auch tatsächlich
die Ursache des Unfalls war.
-
In
aktuellen Betriebssystemen für
den Server-/Desktop-Bereich aber auch im Bereich für eingebettete
(embedded) Anwendungen sind hierfür Speicherschutzmechanismen
bekannt. Durch sie ist die Modifikation von unerlaubten Bereichen
von vornherein unterbunden. Die Speicherschutzmechanismen sind je
nach Betriebssystem und Hardware-Unterstützung unterschiedlich implementiert.
Zum Beispiel kann mit Hilfe einer auf der Prozessor-Hardware verfügbaren Memory
Mapping Unit (MMU) der auszuführende
Code in einen virtuellen, geschützten Speicherbereich
abgebildet bzw. gemapped werden.
-
Bei
einigen Betriebssysteme werden die Speicherbereiche verschiedener
Prozesse bzw. Tasks gegeneinander durch die Verwendung von ebenfalls
hardwareunterstützen
Operationsmodi mit unterschiedlichen Zugriffsrechten abgeriegelt.
Im Falle eines Zugriffsversuchs des auszuführenden Codes außerhalb
des zugewiesenen Bereichs kommt es zu entsprechenden Systemmeldungen, wie
z.B. „Schreibschutzverletzung
in Modul X". Der Anwender
hat dann die Möglichkeit,
den bereits schon gestoppten Prozess mit einer geeigneten Eingabe,
z.B. „OK", vollständig zu
beenden.
-
Diese
Interprozesskommunikation ist grundsätzlich nur über Betriebsystemfunktionen
möglich. Dies
bedeutet, dass Daten aus einem Prozess A beispielsweise über eine
Zwischenablage einem anderen Prozess B zur Verfügung gestellt werden. Diese Kapselung
ist bei großen
Datenmengen jedoch ressourcenintensiv, da nicht nur der Speicherplatz
sondern auch die Rechenleistung, um die Daten von A nach B zu kopieren,
mehrfach bereitgestellt werden muss.
-
Ein
Wechsel zwischen zwei Prozessen, beispielweise bei Desktop-Betriebssystemen,
oder zwischen zwei Tasks, insbesondere im embedded bzw. eingebetteten
Bereich, wird als Kontextwechsel bezeichnet. Ein solcher Kontextwechsel
erfordert in der Regel eine aufwendige Sicherung sämtlicher
Registerinhalte des Programm-Stacks bzw. Programm-Stapelspeichers
und der Programmstatusinformationen. Je nach Hardwareunterstützung beanspruchen
derartige Operationen Zeitspannen im Millisekundenbereich. Will
der Anwender zwischen den Tasks wechseln, ist dieser Kontextwechsel
bspw. in einem Windows-System mit einer Dauer von wenigen Millisekunden
für den
Anwender kaum spürbar.
-
In
einer Waschmaschine, einem Getränkeautomaten
aber auch in größeren industriellen
Anlagen sind diese Kontextwechselzeiten ebenfalls unproblematisch,
sofern Steuerung und Regelungen im Zehntel-Sekundenbereich arbeiten.
Falls schnellere Lösungen
notwendig sind, werden dafür
meistens wegen geringer Stückzahlen
und überschaubarer
Varianz Einzellösungen
bereitgestellt.
-
Der
automotive Bereich ist im Unterschied zu den beschriebenen Beispielen
durch hohe Stückzahlen
und einen immer stärker
werdenden Wettbewerb geprägt,
wodurch ein enormer Kostendruck entsteht. Dies hat zur Folge, dass
elektronische Steuerungssysteme für diesen Markt nur dann eingesetzt
werden können,
wenn sie unter möglichst
geringem Einsatz von Ressourcen, was insbesondere einen RAM- oder
Flashspeicher und eine Rechenleistung betrifft, bereitgestellt werden
können.
Ein elektronisches Steuergerät
für Motorsteuerungen
weist zur Zeit einen peristenten Flash-Speicher mit 2 MB Speicherplatz
und einen RAM mit 64 KB Speicherplatz als 32-Bit-Rechner bei 44
MHz Taktfrequenz auf.
-
Zudem
erfordert eine Individualisierung im automotiven Markt bei gleichzeitig
erhöhten
Ansprüchen
an Komfort, Leistung und Abgasgesetzen eine immer höhere Variantenvielfalt.
Für die
Software bedeutet dies eine wachsende Vereinzelung von Softwarekomponenten
bei steigender Komplexität.
In einem Motorsteuergerät
laufen heutzutage 10 bis 30 Tasks, auf die sich bei automotiven
Systemen bzw. Einrichtungen im embedded Bereich bis zu 1000 Prozesse
verteilen können.
Durch diese Prozesse sind unter anderem Steuer- und Regelungen implementiert,
deren Reaktionszeiten im Millisekundenbereich liegen.
-
Die
beiden, gegenläufigen
Anforderungen lassen jedoch Lösungen
für Betriebssysteme,
die aus der Server- oder Desktop-Domäne bekannt sind, aber auch
Standards aus dem embedded Bereich bei automotiven Anwendungen nicht
zu. Die heutigen Betriebssysteme für automotive Applikationen
sind in bezug auf die Scheduling-Funktionen sehr schlank ausgelegt
und genügen
einem eigenen OSEK-Standard. Gewünschte
Echtzeiteigenschaften werden hierbei durch ein zum Übersetzungszeitpunkt
festgelegtes, statisches Scheduling realisiert. Die Interprozesskommunikation
wird beim Binden der einzelnen Objekt-Codes mit Hilfe von globalen
Variablen ressourcenoptimiert realisiert. Informationen werden nur dann
kopiert, wenn dies aus Datenkonsistenzgründen notwendig ist. Dabei werden
in der Regel keine Speicherschutzverfahren berücksichtigt.
-
Ein
Priorisierungsverfahren von Informationsgebern ist in der Druckschrift
DE 103 34 535 A1 beschrieben.
Das Priorisierungsverfahren dient der koordinierten Antriebsstrangsteuerung
für ein
Kraftfahrzeug. Bei Durchführung
des Priorisierungsverfahrens wird eine Liste mit Anforderern nach
Priorität aufsteigend
oder abfallend sortiert. Die sortierte Liste wird sequentiell beginnend
mit dem Anforderer mit der höchsten
Priorität
abgearbeitet. Das Abarbeiten der Liste wird abgebrochen, sobald
ein Anforderer einen Anforderungswunsch enthält, um diesen Anforderungswunsch
auszuwählen.
-
Die
Druckschrift
DE 103
34 536 A1 beschreibt ein Computersystem mit wenigstens
einem Prozessor und wenigstens einem Speicher zur koordinierten
Antriebsstrangsteuerung für
ein Kraftfahrzeug. Das Computersystem weist eine Softwarearchitektur
mit verschiedenen Komponenten auf. Hierbei ist eine erste Komponente
als ein Operationssystem mit Betriebssystem und spezifischen Diensten als
Basis für
alle anderen Elemente und Anwendungen ausgebildet. Eine zweite Komponente
ist als eine Basisfunktionalität
zur Umsetzung universeller Anforderungen ausgebildet. Als dritte
Komponente ist eine Schicht zur Koordinierung von Aufgaben für Funktionen
der Basisfunktionalität
und zur Einbindung von Plug-Ins als vierte Komponenten vorgesehen.
Wenigstens ein Plug-In dient einer Umsetzung von konkreten Aufgaben
bzw. Funktionen, die über
die Funktionen der Basisfunktionalität hinausgehen und von der Schicht
koordiniert werden. Dabei sind die Plug-Ins insbesondere modulartig
austauschbar.
-
Offenbarung der Erfindung
-
Die
Erfindung betrifft ein Verfahren zum Betreiben einer Recheneinheit,
die zur Kontrolle mindestens eines Steuergeräts ausgebildet ist, bei dem auf
der Recheneinheit zwischen Programmteilen in volatilen Speichern
unterschiedlichen Ursprungs gegenseitige Zugriffsrechte definiert
werden.
-
Bei
einem volatilen und somit veränderlichen oder
flüchtigen
Speicher für
einen Programmteil bzw. einen Programmcode handelt es sich bspw.
um einen als RAM ausgebildeten Datenbereich, in dem der Programmteil
abgelegt sein kann. Im automotiven Bereich sind die beschriebenen
Programmteile als Codes, die von einem Prozessor ausführbar sind, ausgebildet.
-
Bei
dem Verfahren werden in einer Ausgestaltung Programmteile in volatilen
Speichern mit unterschiedlichen Ursprüngen geclustert, angehäuft, gruppiert
und/oder über
Schnittstellen, durch die die Zugriffsrechte festgelegt werden,
verbunden. Somit können
die Programmteile in den volatilen Speichern zueinander gekoppelt
bzw. konfiguriert werden. Eine derartige Clusterung, Anhäufung oder
Gruppierung kann bspw. für
insbesondere statische Variablen der Programmteile in den volatilen
Speichern vorgesehen sein. Ein Kontrollieren des mindestens einen Steuergeräts durch
die Recheneinheit umfasst die Möglichkeit,
dass die Recheneinheit das mindestens eine Steuergerät regelt
oder steuert.
-
Die
Zugriffsrechte können
in mehrere globale Blöcke
unterteilt werden. Dies kann bedeuten, dass lediglich Programmteile
in volatilen Speichern oder Programmteile desselben Ursprungs lesend und/oder
schreibend und demnach manipulierend auf ihre zugehörigen Speicher
und somit Datenbereiche zugreifen können. Für Programmteile in volatilen Speichern
mit unterschiedlichen Ursprüngen
können die
Zugriffsrechte geeignet festgelegt werden. Dies kann ursprungsunabhängig bedeuten,
dass zwei Programmteile in zwei volatilen Speichern gegenseitig
unterschiedliche Zugriffsrechte besitzen. So kann ein erster Programmteil
in einem ersten volatilen Speicher auf einen Datenbereich lesend
und schreibend zugreifen, wohingegen der zweite Programmteil in
einem zweiten volatilen Speichern keinerlei Zugriffsrechte auf den
Datenbereich besitzt.
-
Somit
können
die Programmteile in den volatilen Speichern über ihren Ursprung und somit
insbesondere über
ihre Herkunft identifiziert werden. Dies bedeutet typischerweise,
dass die Programmteile in volatilen Speichern unterschiedlichen
Ursprungs von unterschiedlichen Herstellern und die Programmteile in
den volatilen Speichern desselben Ursprungs von demselben Hersteller
stammen. Für
Programmteile in den volatilen Speichern desselben Ursprungs sind gegenseitige
Zugriffsrechte in der Regel seitens des Herstellers definiert.
-
Eine
Ausführungsform
der Erfindung führt
zu einem Prozess-Scheduling-Layout mit den Eigenschaften, dass eine
Clusterung bzw. Anhäufung
aller Prozesse der Herstellerfirmen und somit aller Prozesse desselben
Ursprungs gegeben ist. Dabei kann bspw. eine Aufspaltung der Cluster
in drei globalen Blöcke
eines Informationsprozesses erfolgen, ggf. ist eine weitere Aufteilung
der Cluster aufgrund einer Analyse von Send-Receive-Beziehungen
durchzuführen.
Durch diese drei globalen Blöcke
werden verschiedene Zugriffsrechte festgelegt.
-
Bei
einer Variante der Erfindung ist vorgesehen, dass die Programmteile
in den volatilen Speichern in der Regel innerhalb der Gesamtsoftware statisch
gebunden sind.
-
Durch
ein Zugriffsrecht kann ein Zugriff eines ersten Programmteils in
einem ersten volatilen Speicher auf einen zweiten Programmteil in
einem zweiten volatilen Speicher zumindest einseitig reguliert werden.
Mit einer gegenseitigen Regulierung können die Pogrammteile in den
volatilen Speichern vor einer gegenseitigen unbeabsichtigten Beeinflussung
geschützt
werden.
-
In
einer weiteren Ausgestaltung des Verfahrens wird eine Zugehörigkeit
von mindestens einer Softwarekomponente eines Pogrammteils in einem volatilen
Speicher zu mindestens einem Meta-Datum definiert bzw. beschrieben
und somit mindestens eine Anweisung für eine Verknüpfung zwischen
den Programmteilen in den volatilen Speichern unterschiedlichen
Ursprungs generiert. Dabei kann das mindestens eine Meta-Datum für Konfigurationsfunktionen
zu einem Übersetzungszeitpunkt,
durch den eine Zeitplanung konfiguriert und/oder eine Optimierungsstrategie
generiert wird, bereitgestellt werden.
-
Die
Programmteile in den volatilen Speichern können auf der Recheneinheit
und insbesondere innerhalb einer statischen Gesamtsoftware der Recheneinheit
ausgeführt
werden. Somit können
in der Recheneinheit mehrere Implementierungen von Programmteilen
in volatilen Speichern unterschiedlichen Ursprungs integriert sein.
-
Bei
einer Ausführung
der Erfindung können Betriebssystemfunktionen
der mindestens einen Recheneinheit zu einer Laufzeit berücksichtigt
werden.
-
Des
weiteren kann bei einer Variante des Verfahrens zur Modifikation
des Pogrammteils in dem volatilen Speicher typischerweise nur ein
passender, exklusiver Speicherbereich der Recheneinheit freigegeben
werden, wobei dieser Speicherbereich bspw. einfach zusammenhängend ausgebildet ist.
-
Dabei
kann insbesondere zur Absicherung ein Schattenspeicher bspw. Shadowbereich
des Speicherbereichs zur Realisierung einer möglichen Strategie zur Realisierung
der Erfindung bereitgestellt werden.
-
Gemäß einer
Ausgestaltung der Erfindung kann in einem gemeinsamen Speicherbereich
ein Zugriff auf eine Botschaft über
einen Betriebssystemaufruf erfolgen. Alternativ oder ergänzend hierzu kann
insbesondere ein gemeinsamer Zugriff über getrennte Speicherbereiche
erfolgen.
-
In
weiterer Ausgestaltung können
zumindest von Komponenten der Programmteile in den volatilen Speichern
bzw. von Softwarekomponenten Kopien der volatilen Speicher und somit
der volatilen Datenbereiche bereitgestellt oder angelegt werden.
-
Die
Erfindung betrifft des weiteren eine Recheneinheit, die zur Kontrolle
mindestens eines Steuergeräts
ausgebildet ist. Dabei ist die Recheneinheit dazu vorgesehen, zwischen
Programmteilen in volatilen Speichern unterschiedlichen Ursprungs
gegenseitige Zugriffsrechte zu definieren.
-
Diese
Recheneinheit kann als eine Komponente eines Steuergeräts ausgebildet
sein oder zumindest mit mindestens einem Steuergerät zusammenwirken.
Dabei ist die Recheneinheit bspw. zur Kontrolle mindestens eines
Steuergeräts
für den
automotiven Bereich vorgesehen.
-
Die
erfindungsgemäße Recheneinheit
ist zur Durchführung
mindestens eines Schritts des erfindungsgemäßen Verfahrens ausgebildet.
-
Die
Erfindung betrifft außerdem
ein Computerprogramm mit Programmcodemitteln, um alle Schritte eines
erfindungsgemäßen Verfahrens
durchzuführen,
wenn das Computerprogramm auf einem Computer oder einer entsprechenden
Recheneinheit, insbesondere einer erfindungsgemäßen Recheneinheit, ausgeführt wird.
-
Das
erfindungsgemäße Computerprogrammprodukt
mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind,
ist zum Durchführen
aller Schritte eines erfindungsgemäßen Verfahrens ausgebildet,
wenn das Computerprogramm auf einem Computer oder einer entsprechenden
Recheneinheit, insbesondere einer erfindungsgemäßen Recheneinheit, ausgeführt wird.
-
Mit
der Erfindung ist es in Ausgestaltung möglich, unter Berücksichtigung
von Hersteller- oder Zulieferanteilen, durch die die Programmteile
in den volatilen Speichern in der Regel bereitgestellt werden, und
durch die somit Ursprünge
von den Programmteilen in den volatilen Speichern bestimmt sind,
in Echtzeit-Systemen und insbesondere in Echtzeit-Software-Systemen, einen Speicherschutz bereitzustellen.
-
Mit
der hier vorgestellten Erfindung kann u.a. gewährleistet werden, dass verschiedene
ausführbare
Programmteile in den volatilen Speichern von unterschiedlichen Herstellern,
die voneinander unabhängig
sind, auf der Recheneinheit oder einem Prozessor laufen können, ohne
sich dabei unbeabsichtigt zu beeinflussen. Die Erfindung kann in
weiterer Ausgestaltung auch Softwarearchitekturen oder Softwaresysteme
betreffen, bei denen verschiedene Programmteile in verschiedenen
volatilen Speichern zur Realisierung eines sog. statischen Schedulings
bzw. Ablaufplans zumindest teilweise in definierten Ablaufreihenfolgen
zueinander in Ausführung
kommen müssen.
Dies ist zum Beispiel bei Steuergeräten im automotiven Bereich
der Fall.
-
Somit
bietet die Erfindung Schutz vor einem fremden gegenseitigen Zugriff
der volatilen Datenbereiche der Programmteile in den volatilen Speichern unterschiedlichen
Ursprungs und somit von verschiedenen voneinander unabhängigen Herstellern,
falls die Programmteile in den volatilen Speichern in einer insbesondere
statisch gebundenen Gesamtsoftware auf einer Mikropozessor-Anordnung
oder einem entsprechenden Mikropozessor-System zur Ausführung gebracht
werden.
-
Dadurch
ergibt sich in Ausgestaltung, dass das statische und/oder automatisch
zu einem Übersetzungszeitpunkt
konfigurierte Scheduling zum Ausführungszeitpunkt annähernd keine
Rechenleistung für
administrative Aufgaben benötigt.
Des weiteren benötigt
eine Interprozesskommunikation gemäß der heutigen, zum Übersetzungszeitpunkt
stattfindenden Optimierungsstrategien nur geringfügig mehr
Ressourcen in Form eines RAM-Speichers und/oder einer Rechenleistung.
Mit der Erfindung kann sich des weiteren ergeben, dass keine zusätzlichen
laufzeitkritischen Kontextwechsel stattfinden. Zudem ist es in einer
Ausführungsform
möglich,
dass im Falle einer Zugriffsverletzung Lösungsstrategien bereitgestellt
werden, die im Gesamtsystem zu einer sicheren Systemreaktion führen.
-
Eine
weitere Ausgestaltung der Erfindung basiert auf dem Zusammenspiel
von Funktionen in drei Ebenen, nämlich
der Bereitstellung von Meta-Daten für Konfigurationsfunktionen
zum Übersetzungszeitpunkt,
den zur Laufzeit realisierten Betriebssystemfunktionen und der Hardware
und somit der Recheneinheit.
-
Bei
einer denkbaren Anwendung können
für heute
existierende Schnittstellen- und Konfigurationsmodelle von AUTOSAR,
ASAM oder MSR unterschiedliche Meta-Daten in Form einer XML-Datei
bereitgestellt werden. Dies betrifft Scheduling-Informationen für Prozesse
und Tasks sowie deren Deklaration. Als Meta-Daten können des
weiteren Sende- und Empfangsbeziehungen von sogenannten Botschaften
sowie Zugehörigkeitsbeziehungen
von Variablen, Botschaften, Kalibrierparametern, Prozessen usw.
zu Programmteilen in volatilen Speichern bzw. zu deren Softwarekomponenten
bereitgestellt werden. Außerdem
sind ergänzend
oder alternativ Zugehörigkeitsbeziehungen
der Softwarekomponenten der Programmteile in den volatilen Speichern
zu ihren Herstellerfirmen bereitstellbar.
-
Bei
einer sogenannten Botschaft (Message), die in einer zusätzlichen
Ausführung
der Erfindung realisiert werden kann, handelt es sich um eine globale
Variable, die zur Interprozesskommunikation verwendet wird. Dabei
wird sichergestellt, dass im Fall von möglicher Dateninkonsistenz durch
zeitversetzten Zugriff auf diese Variable bei Taskunterbrechungen
die Variableninhalte über
Kopien derart gepuffert werden, dass alle zugreifenden Prozesse über eine
Taskausführungsdauer
immer gleiche Dateninhalte vorfinden.
-
Im
Rahmen der Erfindung kann mindestens eines von verschiedenen Zugriffsrechten
realisiert werden. Üblicherweise
sind drei verschiedene Zugriffsrechte in drei globalen Blöcken geclustert.
Die Recheneinheit weist in der Regel mehrere Speicher- oder RAM-Bereiche
auf, wobei jeweils ein Speicherbereich und somit ein volatiler Speicher
für einen
Programmteil eines Ursprungs vorgesehen ist.
-
Dabei
umfasst ein erstes Zugriffsrecht eine Anhäufung bzw. Clusterung aller
statischen Variablen der Herstellerfirmen in je einen RAM-Bereich
bspw. über "SectionCompany[x].private
mit x = 0... n – 1", so dass der jeweilige
RAM-Bereich nur von der Herstellerfirma selbst benutzt werden darf.
Somit hat nur die Herstellerfirma, was ein Lesen, Schreiben sowie Ändern der
Programmteile in den volatilen Speichern umfasst, einen Zugriff
auf volatile Datenbereiche, die ihren Ursprung bei dieser Herstellerfirma
haben.
-
Ein
zweites Zugriffsrecht umfasst eine Clusterung aller statischen Variablen
der Herstellerfirmen in je einen RAM-Bereich, wobei "SectionCompany[x].public.read
mit x = 0... n – 1" gilt. Dies bedeutet, dass
nur die Herstellerfirma x der Programmteile in den volatilen Speichern
diese Programmteile in diesen volatilen Speichern ändern und
somit beschreiben darf. Den anderen Herstellerfirmen oder Entwicklungspartnern
wird nur ein lesendes Zugriffsrecht gestattet.
-
Ein
drittes Zugriffsrecht umfasst eine Clusterung aller statischen Variablen
der Herstellerfirmen in je einen RAM-Bereich, demnach gilt "SectionCompany[x].public.
write mit x = 0... n – 1". Somit dürfen alle anderen
Entwicklungspartner die Programmteile in den volatilen Speichern
manipulieren, d.h. umschreiben und lesen.
-
Im
automotiven Bereich wird im Rahmen eines Prozess-Scheduling-Layouts
eine void-void Top-Levelfunktion innerhalb einer Aufgabe oder eines
Tasks als ein Prozess bezeichnet. Eine Systemfunktion wird regelmäßig durch
mindestens einen Prozess realisiert, so dass der mindestens eine
Prozess und somit auch mehrere Prozesse in verschiedenen Tasks abgearbeitet
werden können.
Durch dieses Konzept der Prozesse ist ein Stapelspeicher oder Stack
zwischen den verschiedenen Prozessaufrufen immer leer und die Prozesse
können
sich somit nicht über
den Stack beeinflussen. Bei Bedarf kann ein Stackpointer zwischen
den Prozessaufrufen überprüft werden.
-
Die
Sequenz der Prozessaufrufe wird typischerweise durch Send- und Receive-
bzw. Sende- und
Empfangs-Beziehungen der Botschaften zu einer Interprozesskommunikation
sowie durch einen globalen Informationsverarbeitungsprozess bestimmt.
Hierbei betrifft in Ausgestaltung die Interprozesskommunikation
Prozesse im automotiven Bereich. Durch globale Informationsverarbeitungsprozesse
werden Sensordaten von Sensoren erfasst und verarbeitet, außerdem werden
Stellwerte für
Aktuatoren ausgeben.
-
Erreicht
ein Task zur Laufzeit eine derartige Clustergrenze, werden für das Task
und somit für
den jeweils als nächstes
zur Ausführung
kommenden Cluster die jeweiligen ursprungs- oder herstellerspezifischen
Speicherbereiche unter Berücksichtigung eines
RAM-Layouts vom Betriebssystem zum Lesen bzw. zum Schreiben freigegeben.
In einer Variante der Erfindung findet somit kein Kontextwechsel
zwischen zwei Softwarekomponenten statt, d.h. es wird keine Speicherverwaltung
(Memory Management Unit, MMU) und damit kein virtueller Speicher
eingesetzt. Die Programmteile in den volatilen Speichern und insbesondere
Softwarekomponenten werden bspw. innerhalb eines Taskkontextes gegeneinander geschützt. Daraus
folgt, dass in einer Variante der Erfindung die oben genannten Probleme
der Lösungsansätze aus
anderen Domänen,
wie bspw. ein exzessiver Laufzeitoverhead, der in Verbindung mit
einer MMU durch viele Kontextwechsel erfolgt, sowie Speicherschutzprobleme
der bisherigen Betriebssysteme im automotiven Bereich nicht auftreten.
-
Die
vorliegende Erfindung kann auch ein Betriebssystem umfassen. Ein
derartiges Betriebsystem kann in Abhängigkeit einer jeweiligen Ausgestaltung
einen Mechanismus zur Festlegung der nicht beschreibbaren Speicherbereiche
von Softwarekomponenten und insbesondere von Sätzen der Softwarekomponenten
und somit der Programmteile in den volatilen Speichern erzeugen.
Dies kann zu einer Integrationszeit der Recheneinheit oder des Systems,
in der Regel zu einer Zeit, während
der sog. Softwareimages bzw. -bilder erzeugt werden, erfolgen. Zu
einer eigentlichen Laufzeit, wenn das Steuergerät oder System im Fahrzeug in
Betrieb ist, kann von diesem Betriebssystem für die jeweils in der Ausführung befindlichen
Komponente der modifizierbare Speicherbereich eingestellt werden.
-
Mit
der Erfindung können
im automotiven Bereich unterschiedliche Strategien zum Schutz eines Speichers
der Recheneinheit realisiert werden. Nachfolgend werden vier Beispiele
für derartige
Strategien vorgestellt. Mit mindestens einer dieser Strategien kann
der beabsichtigte und/oder unbeabsichtigte bspw. schreibende Zugriff
auf einen exklusiven Datenbereich einer anderen Softwarekomponente
vermieden werden.
-
Hierzu
können
bei der Generierung einer statischen Schedulingreihenfolge eines
Tasks zwischen Programmteilen in volatilen Speichern bzw. zwischen Softwarekomponenten-Clustern, d.h. eine
zur Laufzeit zeitlich einfach zusammenhängende Menge von Prozessen jeweils
eines Herstellers, automatisch Betriebssystemaufrufe eingefügt werden.
Somit wird für diese
Cluster bzw. Gruppierungen von Programmteilen in volatilen Speichern
nur mindestens ein passender exklusiver Speicherbereich des Herstellers
zur Modifikation, typischerweise zum Lesen und/oder Schreiben, freigeben
und ein gesamter verbleibender Speicherbereich bzw. Datenspeicher
für den
lesenden und/oder schreibenden Zugriff gesperrt.
-
Eine
ggf. vorzusehende Verknüpfung
bzw. ein Link der Gesamtsoftware oder eines Systems, das die Programmteile
in den volatilen Speichern umfasst, ist dazu ausgebildet, dass alle
statischen Daten eines Herstellers, der in der Regel mehrere Softwarekomponenten-Cluster
beisteuert, in einem einfach zusammenhängenden Speicherbereich oder RAM-Bereich
liegen. Hierbei kann in Ausgestaltung eine Zuordnung bzw. Allokation
von einem dynamischen Speicher über "malloc()/free()" verboten werden.
-
Zusätzlich kann
der Stapelspeicher an jeder Clustergrenze vollständig abgeräumt werden, dies kann bspw.
bedeuten, dass der Stackpointer zur Bereitstellung einer erweiterten,
redundanten Sicherheitsmaßnahme
auf den Anfang gesetzt wird.
-
Mit
diesen Strategien kann garantiert werden, dass voreinander geschützte Softwarekomponenten-Cluster
einen modifizierenden Zugriff auf die exklusiven Datenbereiche der
anderen Cluster bzw. Softwarekomponenten-Cluster haben.
-
Des
weiteren kann mit mindestens einer der Strategien auch in dem gemeinsamen
Speicherbereich ein unbeabsichtigter Schreibzugriff vermieden werden.
Im Rahmen der Erfindung sind in Abhängigkeit davon, welche Strategie
am sinnvollsten ist, unterschiedliche Vorgehensweisen möglich. Die
Strategien können
hierbei auch von der Hardware beeinflußt werden.
-
Eine
erste Strategie betrifft einen schreibenden und/oder lesenden Zugriff
auf eine Message, die als ein Datum in dem gemeinsamen Speicherbereich ausgebildet
ist. Diese erste Strategie wird üblicherweise
nur über
einen Betriebssystemaufruf auf der Recheneinheit ausgeführt. Der
Betriebssystemaufruf greift auf das Datum im Kontext eines privilegierten Nutzers
bzw. Users, einen sog. Superuser, der bei der Verwendung des Prozessors
mit besonderen Rechten ausgestattet ist, zu. Der gemeinsame Speicherbereich
ist nur für
diesen Superuser beschreibbar, was auch die Variante, dass nur der
Superuser auf den gemeinsamen Speicherbereich zugreift, umfassen
kann. Daraus folgt, dass alle unbeabsichtigten Modifikationen, z.B. über fehlerhafte Zeiger
bzw. Pointer, abgewiesen werden und entsprechende weitere Maßnahmen,
bspw. das Auslösen
einer Exception/Trap, durchgeführt
werden können.
-
Diese
erste Strategie kann die Realisierung von "Input-Messages" für
Softwarekomponenten von anderen Herstellern, die in der Regel wegen
der Clustergrenzen vor Modifikationen geschützt sind, erlauben.
-
Im
Rahmen einer zweiten Strategie ist vorgesehen, dass es verschiedene, üblicherweise
voneinander getrennte oder unabhängige
Speicherbereichsmodule und keinen gemeinsamen Speicherbereich gibt.
Die Messages sind hierbei jeweils in einem exklusiven Speicherbereichsmodul
des Programmteil- bzw. Softwarekomponenten-Clusters abgelegt. Demzufolge
ergibt sich u. a., dass keine beabsichtigte und/oder unbeabsichtigte
Modifikation durch andere Cluster möglich ist.
-
Bei
einer dritten Strategie kann ein Konzept zum Einsatz kommen, das
u.a. eine Realisierung von Input-Messages erlaubt. Bei diesem Konzept
werden zur Aufbau- bzw. Build-Zeit alle Softwarekomponenten der
Programmteile in den volatilen Speichern daraufhin geprüft, ob diese
eine Input-Message einer Komponente eines anderen Herstellers beschreiben. Ist
dies der Fall, so wird für
mindestens eine zu schreibende Komponente eine Kopie der Message angelegt,
auf die diese mindestens eine schreibende Komponente schreiben kann.
Diese Komponente be- oder überschreibt
während
ihrer Ausführungszeit
die Kopie der Message, die von dem Betriebssystem hierzu bereitgestellt
wird. Bei dieser dritten Strategie kann berücksichtigt werden, dass wiederum
nur der Hersteller der schreibenden Komponente diese Kopie beschreiben
darf, wodurch Modifikationen durch andere Hersteller ausgeschlossen
sind. Anschließend
wird z.B. an der Clustergrenze des Betriebssystems, das in diesem
Kontext als priviligierter User bzw. Superuser arbeitet, der Wert
der Kopie auf die ursprüngliche
bzw. originale Message kopiert. Bei diesem Mechanismus ist es sinnvoll,
dass jeweils nur eine andere Komponente auf diese Input-Message schreibt.
Dies kann jedoch vom Betriebssystem zur Build-Zeit überprüft werden.
-
In
einer weiteren Variante können
ebenfalls mehrere schreibende Komponenten auf die Input-Message einer Komponente
schreiben. Für
jede dieser schreibenden Komponenten wird vom Betriebssystem ein
eigene Kopie der Input-Message zur Verfügung gestellt. Kommt bspw.
jene Komponente zur Ausführung,
die die Input-Message zur Verfügung
gestellt hat, so ist des weiteren vorgesehen, dass diese dem Betriebssystem
geeignet mitteilt, wie mit mehreren Kopien der Input-Message umgegangen
wird. Dies könnte
z.B. durch eine sogenannte Callback-Funktion einer Komponente geschehen. Diese
Callback-Funktion kann von dem Betriebssystem vor dem Aufruf der
eigentlichen Komponente eine Anzahl und Schreibreihenfolge sämtlicher
Kopien übergeben
und/oder bereitstellen. Die Komponente kann außerdem mit einer Callback-Funktion
vollständig
generisch auf die Daten zugreifen und die für sie geeignete Verarbeitung
durchführen,
dies kann z.B. bedeuten, dass nur der letzte Wert, die Summe mehrerer
Werte und/oder der Durchschnitt aller Werte berücksichtigt wird bzw. werden.
-
Bei
einer vierten Strategie wird der gemeinsame Speicherbereich per
Betriebssystemaufruf ohne einen privilegierten User beschrieben
und/oder gelesen. Zur Absicherung ist bei dieser vierten Strategie
ein Schatten- bzw. Shadowbereich des gemeinsamen Speicherbereichs
vorgesehen. Durch diesen Schattenbereich kann die Konsistenz des
gemeinsamen Speicherbereichs mit einem zusätzlichen Mechanismus sicherstellt
werden.
-
Die
vierte Strategie kann durch eine erste Variante realisiert werden.
Bei dieser ersten Variante wird bei jedem Schreib- und/oder Lesezugriff
jeweils ein Originaldatum mit einem entsprechenden oder zugeordneten
Datum im Schattenbereich verglichen. Bei Nichtübereinstimmung des Datums mit
dem Originaldatum kann durch geeignete Maßnahmen reagiert werden.
-
Zusätzlich oder
alternativ kann zur Durchführung
der vierten Strategie eine zweite Variante zur Anwendung kommen.
Bei dieser zweiten Varianten laufen Checksummenalgorithmen über beide Speicherbereiche,
die anschließend
miteinander verglichen werden. Bei Nichtübereinstimmung der Checksummen
wird in geeigneter Weise reagiert. Typischerweise können bei
Ausführung
des Checksummenalgorithmus durch nicht-atomare Schreib- und Lesezugriffe,
z.B. durch sog. Read-Write-Locks, Maßnahmen gegen Dateninkonsistenz
getroffen werden.
-
Da
bei unbeabsichtigten Zugriffen in der Regel niemals beide Speicherbereiche
zufällig
synchron modifizieren werden, werden bei beiden Varianten zu der
vierten Strategie Inkonsistenzen erkannt, so dass entsprechend reagiert
werden kann.
-
Die
in Ausgestaltung unter Berücksichtigung einer
der beiden Varianten durchzuführende
Strategie ist bspw. dann anwendbar, wenn die genutzte Hardware kein
Konzept eines privilegierten Nutzers (Superusers) unterstützt.
-
Ein
Ausführungsbeispiel
der Erfindung kann eine RAM-Ausgestaltung bzw. ein RAM-Layout des Arbeitsspeichers
(RAM) betreffen. In einem Entwicklungsverbund mit n verschiedenen
Entwicklungspartnern können über die
in den Meta-Daten beschriebenen Zugehörigkeiten von Variablen und
Software-Funktionen zu Software -Komponenten und damit zu den jeweiligen
Herstellerfirmen Verknüpfungs- bzw.
Linkanweisungen generiert werden, die zu dem RAM-Layout mit drei unterschiedlich strikten
Zugriffsrechten und daraus resultierenden unterschiedlichen Eigenschaften
führen.
-
Weitere
Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der
Beschreibung und der beiliegenden Zeichnungen.
-
Es
versteht sich, dass die vorstehend genannten und die nachstehend
noch zu erläuternden Merkmale
nicht nur in der jeweils angegebenen Kombination, sondern auch in
anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne
den Rahmen der vorliegenden Erfindung zu verlassen.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt
in schematischer Darstellung eine Architektur eines Arbeitsspeichers
einer ersten Ausführungsform
der erfindungsgemäßen Recheneinheit.
-
2 zeigt
in schematischer Darstellung eine Vorgehensweise zur Handhabe von
Programmteilen in volatilen Speichern im Rahmen einer zweiten Ausführungsform
des erfindungsgemäßen Verfahrens.
-
3 zeigt
in schematischer Darstellung eine Rechneranordnung mit einer zweiten
Ausführungsform
der erfindungsgemäßen Recheneinheit.
-
Ausführungsformen
der Erfindung
-
Die
Erfindung ist anhand von Ausführungsformen
in den Zeichnungen schematisch dargestellt und wird im folgenden
unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
-
1 zeigt
in schematischer Darstellung eine Architektur eines Arbeitsspeichers
einer ersten Ausführungsform
einer erfindungsgemäßen Recheneinheit 2.
Bei dieser schematischen Darstellung sind ein erster Programmteil 4 in
einem ersten volatilen Speicher 5, hier in einem ersten
RAM-Bereich, ein zweiter Programmteil 6 in einem zweiten
volatilen Speicher 7, hier in einem zweiten RAM-Bereich,
sowie ein dritter Programmteil 8 in einem dritten volatilen
Speichern 9, hier in einem dritten RAM-Bereich, übereinanderliegend
dargestellt. Es ist vorgesehen, dass diese drei Programmteile 4, 6, 8 in
den drei volatilen Speichern 5, 7, 9 von
unterschiedlichen Herstellerfirmen, nämlich von einer ersten Herstellerfirma
im Falle des ersten Programmteils 4 in dem ersten volatilen
Speicher 5, einer zweiten Herstellerfirma im Fall des zweiten
Programmteils 6 in dem zweiten volatilen Speicher 7 und
einer dritten Herstellerfirma im Fall des dritten Programmteils 8 in
dem dritten volatilen Speicher 9, bereitgestellt werden.
Dies bedeutet, dass diese drei Programmteile 4, 6, 8 in
den drei volatilen Speichern 5, 7, 9 unterschiedliche
Ursprünge
haben.
-
Es
ist vorgesehen, dass jeder Programmteil 4, 6, 8 in
jeweils einem volatilen Speicher 5, 7, 9 eine erste
Softwarekomponente 10 aufweist, die in der vorliegenden
Ausführungsform
auch als private Softwarekomponente 10 definiert ist und
somit vor Zugriffen durch jeweils einen anderen Programmteil 4, 6, 8 in
einem anderen volatilen Speicher 5, 7, 9 geschützt ist.
Für jeweils
eine zweite Softwarekomponente 12 der drei Programmteile 4, 6, 8 in
den volatilen Speichern 5, 7, 9 ist ein öffentliches,
lesendes Zugriffsrecht festgelegt, was bedeutet, dass auch Programmteile 4, 6, 8 in
den volatilen Speichern 5, 7, 9 unterschiedlichen
Ursprungs zumindest teilweise gegenseitig auf diese zweiten Softwarekomponenten 12 zugreifen
können.
Außerdem
weist jeder Programmteil 4, 6, 8 in jeweils
einem volatilen Speicher 5, 7, 9 eine
dritte Softwarekomponente 14 auf. Diese dritten Softwarekomponenten 14 können programmteilübergreifend
schreibend manipuliert werden.
-
Des
weiteren weisen die zweiten Softwarekomponenten 12 Lesebereiche 16 auf,
für die
durch eine Mehrfachablage für
lesende Aufgaben und somit Tasks eine Datenkonsistenz bereitgestellt
ist.
-
Entsprechend
weisen die dritten Softwarekomponenten 12 Schreibbereiche 18 auf,
für die durch
eine Mehrfachablage für
schreibende Aufgaben und somit Tasks eine Datenkonsistenz bereitgestellt
ist.
-
In
der vorliegenden Ausführungsform
ist vorgesehen, dass die schematisch dargestellte Recheneinheit 2 mit
einer Anzahl hier nicht dargestellter Steuergeräte zusammenwirkt und somit
diese Steuergeräte
kontrolliert. Innerhalb der Recheneinheit 2 sind die verschiedenen
Programmteile 4, 6, 8 in den volatilen
Speichern 5, 7, 9 innerhalb einer Gesamtsoftware
derart zueinander gekoppelt, dass zwischen den Programmteilen 4, 6, 8 in
den volatilen Speichern 5, 7, 9 unterschiedlichen
Ursprungs gegenseitige Zugriffsrechte definiert sind. Dies bedeutet,
dass die Programmteile 4, 6, 8 in den
volatilen Speichern 5, 7, 9 softwarekomponentenabhängig je
nach Zugriffsrecht aufeinander lesend, schreibend oder gar nicht zugreifen
können.
-
Durch
Definition der Zugriffsrechte wird bei Betrieb der Recheneinheit 2 vermieden,
dass sich die Programmteile 4, 6, 8 in
den volatilen Speichern 5, 7, 9 gegenseitig
beabsichtigt oder unbeabsichtigt derart beeinflussen, dass eine
ungewollte Fehlfunktion eines jeweiligen Steuergeräts hervorgerufen
wird.
-
2 zeigt
in schematischer Darstellung eine Vorgehensweise zur Handhabe von
Programmteilen in volatilen Speichern im Rahmen einer Ausführungsform
eines erfindungsgemäßen Verfahrens. Dabei
sind in dem Diagramm von 2 ein erstes Task 20 sowie
ein zweites Task 22 dargestellt.
-
Das
erste Task 20 umfasst erste Prozessausführungssequenzen 24 einer
ersten Herstellfirma, zweite Prozessausführungssequenzen 26 einer zweiten
Herstellfirma, eine dritte Prozessausführungssequenz 28 einer
dritten Herstellfirma sowie vierte Prozessausführungssequenzen 30 einer
vierten Herstellfirma. In ähnlicher
Weise ist das zweite Task 22 in erste Prozessausführungssequenzen 24 der
ersten Herstellfirma, in zweite Prozessausführungssequenzen 26 der
zweiten Herstellfirma, in dritte Prozessausführungssequenzen 28 der
dritten Herstellfirma und in vierte Prozessausführungssequenzen 30 der
vierten Herstellfirma unterteilt. Außerdem sind während des
zweiten Tasks 22 mindestens ein erster Kontextwechsel 32 und
mindestens ein zweiter Kontextwechsel 34 vorgesehen.
-
Mit
der vorliegenden Erfindung kann in der zweiten Ausführungsform
bei einer Generierung der Prozesssequenzen zumindest ein weiteres
Kriterium berücksichtigt
werden. Somit ist es möglich,
in einem Entwicklungsverbund mit den Herstellerfirmen und somit
Entwicklungspartnern die Zugehörigkeiten
von Prozessen zu Tasks 20, 22 zu identifizieren.
Weiterhin kann bei einem Erzeugen bzw. Generieren der Prozessausführungssequenz 24, 26, 28, 30 die
Clusterung nach Herstellerfirmen zur Minimierung des Prozesswechsel-Overheads
als weiteres Kriterium eingehen.
-
Mit
dem Diagramm aus 2 wird somit eine Prozess-Clusterung
nach Herstellerfirmen dargestellt. Dabei findet zwischen den Prozesswechseln innerhalb
eines Prozess-Clusters der zweite Kontextwechsel 34 statt.
Außerhalb
wird der erste Kontextwechsel 32 durchgeführt, wodurch
die Zugriffsrechte in einer Speicherverwaltung über ein Betriebssystem neu
vergeben werden.
-
3 zeigt
in schematischer Darstellung eine Rechneranordnung 100,
die eine zweite Ausführungsform
einer erfindungsgemäßen Recheneinheit 102 umfasst.
Innerhalb einer Gesamtsoftware 104 der Recheneinheit 102 sind
hier vier verschiedene Programmteile 106, 108, 110, 112 in
volatilen Speichern zueinander gekoppelt. Des weiteren ist die Recheneinheit 102 und
somit auch die Rechneranordnung 100 mit hier zwei dargestellten
Steuergeräten 114, 116 verbunden,
so dass die Recheneinheit 102 mit diesen Steuergeräten 114, 116 wechselwirkt
und diese somit funktionell beeinflusst sowie von den Steuergeräten 114, 116 Daten
empfängt.
-
Im
Rahmen dieser Ausführungsform
ist vorgesehen, dass die vier Programmteile 106, 108, 110, 112 in
den volatilen Speichern unterschiedliche Ursprünge haben, was bedeutet, dass
diese Programmteile 106, 108, 110, 112 in
den volatilen Speichern von verschiedenen Herstellern unabhängig voneinander
bereitgestellt und erst auf der Rechneranordnung 102 innerhalb
der Gesamtsoftware 104 gemeinsam abgespeichert und gleichzeitig
ausgeführt
werden.
-
Um
bei einer Ausführung
der Programmteile 106, 108, 110, 112 in
den volatilen Speichern eine unbeabsichtigte Wechselwirkungen zwischen
diesen Programmteilen 106, 108, 110, 112 in
den volatilen Speichern zu vermeiden, sind zwischen den Programmteilen 106, 108, 110, 112 in
den volatilen Speichern gegenseitige Zugriffsrechte 118, 120 definiert, durch
die eine gegenseitige Manipulation der Programmteile 106, 108, 110, 112 in
den volatilen Speichern festgelegt ist.
-
Dabei
sind mit den Doppelpfeilen lesende und schreibende Zugriffsrechte 118 und
mit den einfachen Pfeilen nur lesende Zugriffsrechte 120 zwischen
den Programmteilen 106, 108, 110, 112 in
den volatilen Speichern dargestellt. Demnach ist ein erster Programmteil 106 in
einem ersten volatilen Speicher dazu berechtigt, auf einen zweiten
Programmteil 108 in einem zweiten volatilen Speicher lesend
und schreibend sowie auf einen vierten Programmteil 112 in
einem vierten volatilen Speicher nur lesend zuzugreifen. Der zweite
Programmteil 108 in dem zweiten volatilen Speicher ist
dazu berechtigt, auf den ersten Programmteil 106 in dem
ersten volatilen Speicher nur lesend und auf den vierten Programmteil 112 in dem
vierten volatilen Speicher lesend und schreibend zuzugreifen. Ein
dritter Programmteil 110 in einem dritten volatilen Speicher
ist dazu berechtigt, auf den vierten Programmteil 112 in
dem vierten volatilen Speicher lesend zuzugreifen. Der vierte Programmteil 112 in
dem vierten volatilen Speicher ist dazu berechtigt, auf den ersten
Programmteil 106 in dem ersten volatilen Speicher sowie
den zweiten Programmteil 108 in dem zweiten volatilen Speicher
lesend zuzugreifen, des weiteren ist der vierte Programmteil 112 in
dem vierten volatilen Speicher dazu berechtigt, auf den dritten
Programmteil 110 in dem dritten volatilen Speicher lesend
und schreibend zuzugreifen. Des weiteren sind zwischen dem ersten
Programmteil 106 in dem ersten volatilen Speicher und dem dritten
Programmteil 110 in dem dritten volatilen Speicher keine
Zugriffsrechte definiert. Demnach ist zwischen diesen beiden Programmteilen 106, 110 in den
jeweiligen volatilen Speichern kein Zugriff möglich.