In der AUTOSAR-Architektur befindet sich die Anwendungssoftware über dem RTE und besteht aus miteinander verbundenen AUTOSAR-SWCs. Diese Komponenten kapseln atomar verschiedene Komponenten der Anwendungssoftware-Funktionalität.
Abbildung 1: Anwendungssoftware
AUTOSAR SWC ist hardwareunabhängig und kann daher auf jede verfügbare Steuergeräte-Hardware integriert werden. Um den Informationsaustausch innerhalb und innerhalb des Steuergeräts zu erleichtern, kommuniziert AUTOSAR SWC ausschließlich über RTE.
AUTOSAR SWC enthält viele Funktionen und Variablen, die interne Funktionalität bereitstellen. Die interne Struktur von AUTOSAR SWC, nämlich seine Variablen und Funktionsaufrufe, ist durch Header-Dateien vor der Öffentlichkeit verborgen. Nur externe RTE-Aufrufe werden auf der öffentlichen Schnittstelle wirksam.
Abbildung 2: SWC
AUTOSAR SWC enthält auch Funktionen, die zur Laufzeit aufgerufen werden müssen. Diese C-Funktionen werden in AUTOSAR Runnables genannt.
Runnables können nicht alleine ausgeführt werden; sie müssen einer ausführbaren Entität des Betriebssystems zugewiesen werden. Solche Zuweisungen können durch Einfügen von Funktionsaufrufen von Runnables in den OS-Task-Körper durchgeführt werden.
Die Runnables werden dann in einer Schleife und/oder ereignisgesteuert im Kontext der aufrufenden OS-Task ausgeführt. Die Zuteilung der Aufgaben durch Runnables erfolgt gemäß den Abbildungen 3 und 4.
Abbildung 3: AUTOSAR-Layer-Software-Architektur – Zuordnung von Runnables
OS-Objekte in OS-Anwendungen können zu verschiedenen AUTOSAR-SWCs gehören. RTE implementiert einen Speicherbereich, auf den alle Mitglieder von Betriebssystemanwendungen uneingeschränkten Zugriff haben, um eine effiziente Kommunikation zwischen SWCs zu ermöglichen.
Vertrauenswürdige Betriebssystemanwendungen: „Vertrauenswürdige Betriebssystemanwendungen dürfen mit zur Laufzeit deaktivierten Überwachungs- oder Schutzfunktionen ausgeführt werden. Sie können ohne Einschränkung APIs betreiben, die auf Speicher zugreifen und Betriebssystemmodule müssen ihr Zeitverhalten zur Laufzeit nicht erzwingen und dürfen im privilegierten Modus ausgeführt werden.
Nicht vertrauenswürdige Betriebssystemanwendungen: „Ausführung nicht vertrauenswürdiger Betriebssystemanwendungen.“ mit zur Laufzeit deaktivierten Überwachungs- oder Schutzfunktionen ist nicht zulässig. Sie beschränken den Zugriff auf den Speicher, schränken den Zugriff auf die API des Betriebssystemmoduls ein und erzwingen dessen Zeitverhalten zur Laufzeit. Sie dürfen nicht im privilegierten Modus ausgeführt werden, wenn der Prozessor dies unterstützt.
3. Kommunikation und Code-Sharing
Gemäß Abbildung 4 und Abbildung 3 kann eine Betriebssystemanwendung mehrere AUTOSAR-SWCs und zugehörige Runnables enthalten. Nur Runnables dürfen direkt auf Variablen zugreifen und Funktionsaufrufe in ihren jeweiligen SWCs ausführen.
4. Speicherpartition in Anwendungssoftware
AUTOSAR OS ist immun gegen speicherbedingte Ausfälle, indem es Betriebssystemanwendungen in exklusiven Speicherbereichen platziert. Dieser Mechanismus wird als Speicherpartitionierung bezeichnet. Betriebssystemanwendungen sind voreinander geschützt, da Code, der in der Speicherpartition einer Betriebssystemanwendung ausgeführt wird, andere Speicherbereiche nicht ändern kann. Die entsprechenden Anforderungen in der AUTOSAR OS-Spezifikation sind in Tabelle 1 aufgeführt.
Tabelle 1: Speicherpartition von AUTOSAR OS-OS-Anwendungen
#🎜 🎜#
Anwendungssoftware kann aus SWCs mit unterschiedlichen ASIL-Levels bestehen. SWCs mit unterschiedlichen ASIL-Bewertungen sollten jedoch nicht denselben Betriebssystemanwendungen zugewiesen werden. Die Speicherpartitionierung bietet keine Störsicherheit zwischen SWCs, die denselben Betriebssystemanwendungen zugeordnet sind. Das Betriebssystem verhindert lediglich, dass andere Betriebssystemanwendungen fehlerhafte Zugriffe ausführen. Verhindert nicht, dass eine fehlerhafte SWC Speicherbereiche anderer SWCs in denselben Betriebssystemanwendungen verändert.
Hinweis: Einzelheiten zur Partitionierung auf Aufgabenebene finden Sie in der nachfolgenden Partitionierung. 5. Speicherpartitionierung in SWC
Mixed ASIL SWC kann aus Runnables mit unterschiedlichen ASIL-Bewertungen bestehen, daher ist eine Unterstützung erforderlich nicht betroffen von der Ausführungsumgebung, die zwischen diesen Runnables interferiert. Aus folgenden Gründen ist es nicht möglich, verschiedene Runnables einer SWC in unterschiedlichen Speicherpartitionen auszuführen:
Speicherpartitionen werden auf der Ebene der Betriebssystemanwendungen ausgeführt. Wie in Abbildung 3 und Abbildung 4 dargestellt, kann ein SWC nur einer Betriebssystemanwendung zugewiesen werden, sodass es nur eine Speicherpartition gibt. Darüber hinaus können SWC Runnables nur von einer Task von OS-Anwendungen aufgerufen werden.
Abbildung 6: SWC und Partitionen
Speicherpartitionen können nicht sein Wird verwendet, um Runnables im selben SWC zu trennen. Wenn es erforderlich ist, dass der SWC Runnables mit unterschiedlichen ASILs enthält und diese Runnables unabhängig und störungsfrei ausgeführt werden müssen, reicht die Speicherpartitionierung auf der Ebene der Betriebssystemanwendungen nicht aus, sondern die Speicherpartitionierung muss auf der Aufgabenebene durchgeführt werden. Die Methode ist in Abbildung 7 dargestellt.
Abbildung 7: Partitionierung auf Aufgabenebene Die zugehörigen Anforderungen zur Speicherpartitionierung auf Aufgabenebene sind in der AUTOSAR OS-Spezifikation in Tabelle 2 aufgeführt. Die Verwendung des schwachen Wortes „kann“ weist darauf hin, dass die Implementierung der Partitionierung auf Aufgabenebene für AUTOSAR OS optional ist. Daher unterstützt nicht jede AUTOSAR-Betriebssystemimplementierung die Speicherpartitionierung auf Aufgabenebene.
Tabelle 2: AUTOSAR-Betriebssystemanforderungen – Speicherpartitionierung auf Aufgabenebene
6. Implementierung der Speicherpartitionierung Mithilfe des Speicherpartitionierungsmechanismus können verschiedene technische Sicherheitskonzepte auf System- und Softwareebene implementiert werden.
Abbildung 8 zeigt eine mögliche Implementierung, während alle zugrunde liegenden Softwaremodule in einer Speicherpartition im vertrauenswürdigen/überwachten Modus ausgeführt werden (in Abbildung 8 rot hervorgehoben). Einige SWCs sind logisch gruppiert und in separaten nicht vertrauenswürdigen/Benutzermodus-Speicherpartitionen platziert (grün hervorgehoben). Das ausgewählte Softwaremodul gehört zur gleichen Speicherpartition im vertrauenswürdigen/verwalteten Modus wie das Basissoftwaremodul (siehe den vierten SWC, der in Abbildung 8 rot hervorgehoben ist). Möglicherweise gibt es mehrere nicht vertrauenswürdige/Benutzermodus-Partitionen, die jeweils eine oder mehrere SWCs enthalten.
Die Ausführung von SWCs in nicht vertrauenswürdigen/Benutzermodus-Speicherpartitionen ist eingeschränkt und kann keine anderen Speicherbereiche ändern, während die Ausführung von SWCs in vertrauenswürdigen/überwachten Programmspeicherpartitionen nicht eingeschränkt ist.
Moderne Mikrocontroller für sicherheitsrelevante Anwendungen unterstützen die Speicherpartitionierung durch dedizierte Hardware (Memory Protection Unit (MPU)).
HINWEIS: Es wird davon ausgegangen, dass Memory Slicing auf einem Mikrocontroller mit MPU oder ähnlichen Hardwarefunktionen implementiert wird.
Bei typischen MPU-Implementierungen kann einer nicht vertrauenswürdigen Anwendung der Zugriff auf mehrere Partitionen des Adressraums des Mikrocontrollers gestattet werden. Unter Zugriffskontrolle versteht man eine Kombination aus Lese-, Schreib- und Ausführungszugriff. Die MPU-Konfiguration ist nur im Monitormodus zulässig.
HINWEIS: Bei einigen Mikrocontroller-Implementierungen ist die MPU in den Prozessorkern integriert. Daher kontrolliert die MPU nur den Zugriff auf den zugehörigen Kern. Andere Busmaster (z. B. DMA-Controller und andere Kerne) werden von dieser segmentierten MPU-Instanz nicht gesteuert.
Die folgende Tabelle und Anwendungsfälle veranschaulichen eine Reihe möglicher Szenarien, wenn die Konfiguration der Speicherschutzeinheit von den Systemanforderungen abgeleitet wird. HINWEIS: Diese Tabelle ist möglicherweise nicht vollständig, wenn es um die Funktionen des verwendeten Hardwaregeräts geht. Tabelle 3: Speicherschutz-Konfigurationsschema Schlichtung usw.
Anwendungsfall 1: SWC befindet sich in derselben Partition.
SWCs in derselben Partition können auf die RAM-Bereiche des anderen zugreifen und daher möglicherweise den Speicherinhalt des anderen beschädigen.
Per Definition können SWCs nicht auf Peripheriegeräte zugreifen, da sie nichts über die zugrunde liegende Mikrocontroller-Architektur wissen sollten. Wenn SWC den direkten Zugriff auf Peripheriegeräte gestattet, kann ein unsicheres System entstehen.Anwendungsfall 2: SWC in verschiedenen Partitionen.
SWCs in unterschiedlichen Partitionen können nicht auf die RAM-Bereiche des anderen zugreifen und daher den Speicherinhalt des anderen nicht beschädigen.
Per Definition können SWCs nicht auf Peripheriegeräte zugreifen, da sie nichts über die zugrunde liegende Mikrocontroller-Architektur wissen sollten. Wenn einem SWC direkter Zugriff auf ein Peripheriegerät gewährt wird, kann ein potenziell unsicheres System entstehen. Anwendungsfall 3: MCAL-Treiber
Der MCAL-Treiber ist eine Sammlung von Funktionen wie Lesen/Schreiben/Initialisieren. Sie müssen von einer anderen Entität wie BSW oder CDD ausgeführt werden. Einzelheiten finden Sie in Abbildung 8.
Der MCAL-Treiber erfordert Lese-/Schreibzugriff auf den Peripherieraum des entsprechenden Peripherie-Hardwaremoduls. Abhängig von der Hardwarearchitektur kann auch ein Monitormodus des Prozessors erforderlich sein.
1. Speicherpartitionen von SWCs mit derselben ASIL-Bewertung.
Der ISO26262-Standard erfordert Immunität zwischen SWCs unterschiedlicher ASIL-Stufen [iii]. Der Standard fordert jedoch keine Störfestigkeit zwischen SWCs mit derselben ASIL-Bewertung.
Ermöglicht die Verwendung von Betriebssystemanwendungen, die aus einer großen Anzahl von SWCs bestehen. Wenn ein einzelner SWC einen Konflikt verursacht, der dazu führt, dass eine gesamte Speicherpartition heruntergefahren oder neu gestartet wird, sind auch alle anderen funktionierenden SWCs für diese Speicherpartition betroffen.
2. Die Speicherpartitionierung ist für vertrauenswürdige Betriebssystemanwendungen nicht verfügbar.
Die Ausführung der Speicherpartition im vertrauenswürdigen/überwachten Modus wird nicht vom Betriebssystem und einigen MMU/MPU-Hardwareimplementierungen gesteuert.
3. Die Speicherpartitionierung wird auf Aufgabenebene nicht unterstützt.
Die Implementierung der Partitionierung auf Aufgabenebene ist für die AUTOSAR OS-Implementierung nicht erforderlich. Daher wird die Störfestigkeit in OS-Anwendungen möglicherweise nicht unterstützt.
4. Leistungsverlust durch Speicherpartitionierung.
Abhängig von der Architektur der Anwendungssoftware und der Implementierung der Mikrocontroller-Hardware und des Betriebssystems kann die Verwendung der Speicherpartitionierung die Leistung beeinträchtigen. Dieser Nachteil erhöht sich mit der Anzahl der pro Zeiteinheit durchgeführten Kontextwechsel.
5. Keine grundlegende Softwarepartition.
Die aktuelle Spezifikation für die Basissoftware legt keine Speicherpartitionierung für Basis-SWCs mit unterschiedlichen ASIL-Stufen von verschiedenen Anbietern fest.
Das obige ist der detaillierte Inhalt vonSpeicherpartitionierung und implementierte funktionale Sicherheitsmechanismen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
So überprüfen Sie den Speicher
Was sind die Konfigurationsparameter des Videoservers?
So richten Sie einen sicheren VPS ein
Welche Fähigkeiten sind erforderlich, um in der PHP-Branche zu arbeiten?
AMD-Katalysator
Eigenschaft mit linearem Gradienten
So lösen Sie das Problem, dass diese Windows-Kopie nicht echt ist
was ist h5
