-
Die
Erfindung betrifft ein Verfahren zur transparenten Replikation einer
Softwarekomponente eines Softwaresystems, insbesondere gemäß dem AUTOSAR-Standard,
in einem zwei oder mehrere Verarbeitungseinheiten umfassenden Rechensystem,
wobei die Verarbeitungseinheiten über einen oder mehrere Kommunikationskanäle zum Austausch
von Daten miteinander verbunden sind.
-
AUTOSAR
ist ein in der Automobilindustrie entwickelter Standard, in dem
Schnittstellen und Interaktionen von Softwarekomponenten in Form
von XML-Beschreibungen (XML = Extendable Markup Language) spezifiziert
sind. AUTOSAR ermöglicht eine
architekturzentrische Modellierung von komplexen Softwaresystemen.
Dies bedeutet, dass Code zum Senden von Daten generiert wird, während eine Funktionalität (Algorithmen)
manuell implementiert oder durch rechnergestützte Werkzeuge generiert wird.
Für alle
Ein- und Ausgaben stehen generierte IO-Funktionen (IO = Input Output) zur Verfügung, die als
RTE Calls bezeichnet werden. Bausteine zum Modellieren von Funktionalitäten sind
sog. Komponenten und Kompositionen. Kompositionen umfassen eine
Mehrzahl an Komponenten, die über
Kommunikationsverbindungen miteinander verbunden sind. Komponenten
und Kompositionen sind über sog.
Ports miteinander verbunden. Ports bilden Kommunikationsschnittstellen,
um Daten zwischen einzelnen Komponenten auszutauschen sowie um Funktionsaufrufe
zwischen den Komponenten zu ermöglichen.
Je nach Ausgestaltung des Rechnersystems müssen die Softwarekomponenten
in sicherheitskritischen Applikationen an die jeweilige Hardwarearchitektur
angepasst werden. Alternativ kann spezielle Hardware zur transparenten
Replikation verwendet werden.
-
Es
ist Aufgabe der vorliegenden Erfindung, ein Verfahren zur transparenten
Replikation einer Softwarekomponenten eines Softwaresystems, insbesondere
gemäß dem AUTOSAR-Standard,
anzugeben, welches die unmodifizierte Verwendung von AUTOSAR-Softwarekomponenten
in sicherheitskritischen Applikationen ermöglicht, welche insbesondere
ein mehrkanaliges Rechensystem vorschreiben.
-
Diese
Aufgabe wird mit den Merkmalen des Patentanspruchs 1 gelöst. Vorteilhafte
Ausführungsformen
sind in den abhängigen
Ansprüchen
wiedergegeben.
-
In
dem erfindungsgemäßen Verfahren
zur transparenten Replikation einer Softwarekomponente eines Softwaresystems
in einem zwei oder mehrere Verarbeitungseinheiten umfassenden Rechensystem,
sind die Verarbeitungseinheiten über
einen oder mehrere Kommunikationskanäle zum Austausch von Daten
miteinander verbunden. Jede der Verarbeitungseinheiten umfasst eine
Laufzeitumgebung. Es werden jeweilige zu replizierende Laufzeitumgebungen
der Verarbeitungseinheiten mit einer Synchronisations- und Auswahlfunktionalität versehen.
-
Das
erfindungsgemäße Verfahren
ermöglicht
eine genaue Synchronisierung von Applikationen zwischen parallel
laufenden Laufzeitumgebungen. Hierbei benötigt das Verfahren keine Zeitsynchronisierung.
-
Das
erfindungsgemäße Verfahren
bedient sich dabei einer Erweiterung der Laufzeitumgebungen, sog.
Runtime-Environment RTE. Die AUTOSAR-Laufzeitumgebung ist eine werkzeuggenerierte Middleware,
welche unter anderem eine ortstransparente Kommunikation zwischen
Softwarekomponenten erlaubt. Um die Replikations-Transparenz bereitzustellen,
wird die Laufzeitumgebung um eine Synchronisations- und um eine
Auswahlfunktionalität (Voting-Funktionalität) erweitert.
-
Zwischen
den replizierten Laufzeitumgebungen wird hierbei ein virtueller
Kommunikationskanal gebildet. Die Kommunikation zwischen verschiedenen
Softwarekomponenten kann auf unterschiedliche Weise erfolgen: Im
Falle eines Sender-Empfänger- Systems kann diese „queued" oder „unqueued" erfolgen. Im Falle
eines Client-Server-Systems kann diese synchron oder asynchron erfolgen.
Die Kommunikation innerhalb einer Softwarekomponente kann unter
Verwendung sog. „inter-runable
variables" oder „exclusive
areas" erfolgen.
Die Kommunikation mit Diensten der Verarbeitungseinheit (sog. ECU
= Electronic Control Unit, Steuergerät) kann als Kommunikation mit
Diensten („Communication
with Services")
oder als Kommunikation mit Ein-/Ausgabe-Abstraktion („Communication
with IO Abstraction")
ausgebildet sein. Das interne Verhalten der Softwarekomponenten
umfasst folgende Möglichkeiten: „Invocation
of Runable Entities",
blockieren und deblockieren von Runables an „Wait Points", Empfang von Laufzeitumgebungsereignissen
(„Reception of
RTE Events", Speicher
pro Instanz („perinstants memory") und „Intitialization/Finalization". Eine genaue Beschreibung
der Kommunikation über
den virtuellen Kommunikationskanal kann dem Dokument „Specification
of the AUTOSAR Runtime Environment, Version 2.0.0" der Autosar GbR
entnommen werden.
-
Zur
Ausbildung einer Funktionalität
der Softwarekomponente erfolgt eine virtuelle Verschaltung einer
Anzahl an Komponenten, unabhängig
von der Verteilung der Komponenten auf den zu replizierenden Laufzeitumgebungen.
-
Die
Komponenten einer Funktionalität
werden zum Datenaustausch über
Kommunikationsschnittstellen, umfassend Sende- und Empfangsports, miteinander verbunden,
wobei den Empfangsports Daten Ereignis-getrieben oder durch zyklisches Abfragen
zugeführt
werden.
-
Der
Empfang von Daten löst
an einem der Empfangsports das Starten von Codesequenzen aus, die
auf den redundanten Verarbeitungseinheiten ablaufen. Die Codesequenzen
können
einen Laufzeitumgebungscode zur Kommunikation mit weiteren Komponenten
oder zum Aufruf von Diensten nutzen. Dies bedeutet, dass eine Software-Funktionalität durch
eine Sequenz von Codesequenz-Aufrufen dargestellt werden kann. Codesequenzen werden
auch als Runable Entities bezeichnet. Codesequenzen nutzen die Laufzeitumgebung
als Middleware, um Daten von anderen Komponenten auszutauschen oder
um sog. Remode Procedure-Aufrufe durchzuführen.
-
Gemäß einer
weiteren Ausgestaltung werden die Komponenten auf redundanten Verarbeitungseinheiten
dupliziert. Die Synchronisierung der Signalverarbeitungsschritte
erfolgt durch die Laufzeitumgebungen der redundanten Verarbeitungseinheiten.
Die Idee der transparenten Laufzeitumgebung besteht somit darin,
Redundanz durch die Laufzeitumgebung selbst sicherzustellen.
-
Die
Synchronisation erfolgt über
den Kommunikationskanal zwischen den zu replizierenden Laufzeitumgebungen.
Die Synchronisation kann über einen
Bus oder einen sog. „Dual-Port-RAM" erfolgen. Dies wird
auch als Synchronisierungskanal bezeichnet.
-
Gemäß einer
weiteren Ausführungsform werden
alle Signale, die an Eingangsports von Kompositionen anliegen, zeitgleich
den Eingangsports der redundanten Kompositionen zugeführt. Jede
der Komponenten umfasst dabei eine Mehrzahl an miteinander kommunikativ
verbundenen Komponenten.
-
In
einer weiteren Ausführungsform
werden alle Ausgangsports vor der Ausgabe eines Signals mit dem
Ergebnis der redundanten Komponente verglichen und zu einem gemeinsamen
Ergebnis geführt.
Dies beschreibt die Ausgangsfunktionalität in der Laufzeitumgebung,
die auch als Voting bezeichnet wird. Für jeden Ausgangsport, der einem
Voting unterzogen wird, muss eindeutig festgelegt sein, welche Aktion
oder Aktionen in einem Erfolgsfall und in einem Fehlerfall ausgeführt werden
müssen.
In einem Erfolgsfall stimmen beide Teilergebnisse der redundanten
Komponente, z. B. innerhalb festgelegter Toleranzen, überein.
Im Fehlerfall sind die von den redundanten Komponenten ermittelten
Teilergebnisse unterschiedlich. Portzugriffe oder andere IO-Funktionen,
die nicht nach außen
ge führt
sind, müssen zeitlich
synchronisiert werden, ohne ein Voting auszuführen.
-
Zum
Zeitpunkt einer Laufzeitumgebungsgenerierung wird ermittelt, welcher
der Verarbeitungseinheiten welche Komponenten zugeordnet wurden und
welcher der Verarbeitungseinheiten die zugehörigen redundanten Komponenten
zugeordnet wurden, aus welchen Informationen die Laufzeitumgebungen
physikalische Synchronisierungspfade für alle Synchronisierungspunkte
ermitteln und entsprechenden Laufzeitumgebungscode generieren. Unter einem
physikalischen Synchronisierungspfad wird die Verbindung zwischen
einer Verarbeitungseinheit und ihrer redundanten Partner-Verarbeitungseinheit bezeichnet.
Dies kann eine Punkt-zu-Punkt-Verbindung oder Bus, wie z. B. ein
CAN-Bus, Flexray-Bus etc.
sein.
-
Die
Erfindung wird nachfolgend weiter anhand der Figuren erläutert. Es
zeigen:
-
1 eine
schematische Darstellung eines mehrere Verarbeitungseinheiten umfassenden
Rechensystems, in welchem eine transparente Replikation einer Softwarekomponente
eines Softwaresystems veranschaulicht ist,
-
2 eine
schematische Darstellung einer virtuellen Verschaltung von Komponenten
einer Softwarekomponente,
-
3 eine
schematische Darstellung einer Software-Funktionalität in Form einer Sequenz von Codesequenz-Aufrufen,
-
4 eine
schematische Darstellung von duplizierten Codesequenzen, und
-
5 eine
schematische Darstellung, aus der ein Mapping von Softwarekomponenten
auf verschiedene Verarbeitungseinheiten illustriert ist.
-
1 zeigt
in einer schematischen Darstellung ein Rechensystem mit Verarbeitungseinheiten VEA,
VEB und VEC. Die Verarbeitungseinheiten VEA, VEB, VEC sind über zwei
Kommunikationskanäle
KK1, KK2 zum Datenaustausch miteinander verbunden. Die Kommunikationskanäle KK1,
KK2 können
beispielsweise durch einen Bus (z. B. CAN-Bus oder Flexray-Bus)
gebildet sein. Die Verarbeitungseinheiten VEA, VEB, VEC können beispielsweise
Steuergeräte
darstellen und sind allgemein sog. ECUs (Electronic Control Units).
Jede der Verarbeitungseinheiten umfasst in bekannter Weise eine Basissoftwarefunktionalität BSW. Diese
umfasst beispielsweise ein Betriebssystem, Mittel zur Kommunikation über die
Kommunikationskanäle,
Treiber zur Kommunikation oder zum Zugriff auf Speicher. Ferner
umfasst jede der Verarbeitungseinheiten eine Laufzeitumgebung RTE,
die auch als Runtime-Environment bezeichnet wird.
-
Den
Verarbeitungseinheiten VEA, VEB ist eine Softwarekomponente SWC1
zugeordnet. Die Softwarekomponente SWC1 umfasst zwei Instanzen SWC1A und SWC1B, wobei
erstere der Verarbeitungseinheit VEA und letztere der Verarbeitungseinheit
VEB zugeordnet ist. Die Instanzen SWC1a, SWC1b der Softwarekomponente
SWC bilden redundante Funktionalitäten aus, die auf den Laufzeitumgebungen
RTE der Verarbeitungseinheiten VEA und VEB durchgeführt werden.
-
Der
Verarbeitungseinheit VEC ist eine Softwarekomponente SWC2 zugeordnet.
Die Softwarekomponente SWC2 ist über
eine Kommunikationsverbindung KV mit der Softwarekomponente SWC1 verbunden.
Zu diesem Zweck verfügt
die Softwarekomponente SWC2 über
einen Port PR, der als Required Port bezeichnet wird. In entsprechender
Weise verfügt
die Softwarekomponente SWC1 über
einen Port PP, der als Provided Port bezeichnet wird. Die Kommunikationsverbindung
KV stellt in der schematischen Darstellung keine physikalische Verbindung,
sondern lediglich eine virtuelle Verbindung zur Darstellung der
Funktionalitäten
dar. Ein tatsächlicher
Datenaustausch erfolgt über
einen der Kommunikationskanäle
KK1 oder KK2.
-
Die
Laufzeitumgebungen RTE der Verarbeitungseinheiten VEA und VEB sind
gegenüber
einer Standard-AUTOSAR-Laufzeitumgebung erweitert. Allgemein ist
die AUTOSAR-Laufzeitumgebung eine werkzeuggenerierte Middleware,
welche unter anderem eine ortstransparente Kommunikation zwischen Softwarekomponenten
erlaubt. Zur Realisierung einer zusätzlichen Replikations-Transparenz sind
die Laufzeitumgebungen RTE der Verarbeitungseinheiten VEA und VEB
um eine Synchronisations- und Voting-Funktionalität (SyncF,
VoteF) erweitert. Zwischen den Laufzeitumgebungen RTE der Verarbeitungseinheiten
VEA und VEB ist ferner ein virtueller Kommunikationskanal SYNC eingezeichnet,
welcher auch als Synchronisierungspfad bezeichnet wird. Der Kommunikationskanal
ist Voraussetzung zur Realisierung einer Replikations-Transparenz.
Zur Realisierung der Replikations-Transparenz müssen folgende Eigenschaften
der Laufzeitumgebung entsprechend erweitert werden: Die Kommunikation zwischen
verschiedenen Softwarekomponenten. Die Kommunikation innerhalb einer
Softwarekomponente. Die Kommunikation mit Diensten der Verarbeitungseinheit
und das interne Verhalten der Softwarekomponente.
-
Unter
Bezugnahme auf die 2 bis 5 wird nachfolgend
die Modellierung der Replikationstransparenz beschrieben. Die Modellierung
beginnt mit einer virtuellen Verschaltung von Komponenten. Dies
ist beispielhaft in 2 dargestellt. Bei dieser virtuellen
Sicht können
Verbindungen KV zwischen Komponenten gezogen werden. Die Kommunikationsverbindungen
können
unabhängig
davon, wie die Komponenten auf die Ablauf-Plattform verteilt werden, gezogen werden.
Die in 2 dargestellte Funktionalität besteht aus den fünf Komponenten
A bis E, die über
Ports PE, PA miteinander verbunden sind. Diese Ports PE, PA bilden
die Schnittstellen zum Datenaustausch. Es existieren Sendeports
PA und Empfangsports PE.
-
An
Empfangsports PE können
Daten Ereignis-getrieben bzw. durch zyklisches Abfragen der Weiterverarbeitung
den Komponenten zugeführt werden.
In jedem Fall führt
der Empfang von Daten dazu, dass ein sog. Runable Entity re1, re2,
re3, re4, re5, re6 gestartet wird, in dessen Kontext die Verarbeitung
der Daten geschieht. Runable Entities sind Codesequenzen, die auf
einer oder verschiedenen Verarbeitungseinheiten ablaufen können. Diese
nutzen die Laufzeitumgebung als Middleware, um Daten von anderen
Komponenten auszutauschen bzw. um sog. RPC (Remote Procedure Calls)
auszuführen.
In 2 ist mit SEN ein Sensor bezeichnet, der über eine
Kommunikationsverbindung mit einem Empfangsport PE der Komponente
A verbunden ist. Ein Aktuator AKT ist über eine Kommunikationsverbindung
mit einem Sendeport PA der Komponente E verbunden. Die jeweiligen
Kommunikationsverbindungen KV, die einen Sendeport PA mit einem
Ausgangsport PE verbinden, sind entsprechend einer gewünschten
Funktionalität
gebildet.
-
RTE-Calls
RTEC bieten die einzige Möglichkeit,
Daten mit anderen Komponenten oder Diensten auszutauschen. Die Implementierung
der Codesequenzen über
Runable Entities besteht aus manuell implementiertem Code, der den
generierten Laufzeitumgebungscode zur Kommunikation mit weiteren Komponenten
oder zum Aufruf von Diensten nutzen kann. Dies bedeutet, dass eine
Softwarefunktionalität,
durch eine Sequenz von Runable Entitiy-Aufrufen (re1-re2-re3-re4-re5-re6)
dargestellt werden kann. Dies ist in 3 dargestellt.
Die Idee der transparenten Laufzeitumgebung besteht darin, Redundanz durch
die Laufzeitumgebung RTE sicherzustellen. Dies geschieht durch Duplikation
der Komponenten auf redundanten Verarbeitungseinheiten und die Synchronisierung
der Signal-Verarbeitungsschritte durch
die Laufzeitumgebung. Hierdurch wird erreicht, dass alle RTE-Calls
synchron durchgeführt
werden. Ferner können
zeitsynchrone Eingabe-Ausgabe-Operationen (I/O-Operationen) durchgeführt werden.
Die Synchronisation geschieht durch einen hoch-performanten Bus
oder „Shared- bzw. Dual-Port-Memory", was im Folgenden
auch als Synchronisierungskanal bezeichnet wird. Eine Duplikation
der Komponenten auf redundanten Verarbeitungseinheiten ist in 1 durch
die Instanzen SWC1A und SWC1B dargestellt.
-
4 zeigt
eine schematische Darstellung aus Sicht einer Runable Entity mit
duplizierten Runable Entities re1 bis re6. Ein System X (Instanz
einer Softwarekomponente) wurde durch das System X' dupliziert. Das
System X' führt alle
Verarbeitungsschritte wie das System X durch. Bei jedem RTE-Call RTEC
synchronisieren sich die Systeme X und X'. Dies ist durch die zwischen den RTE-Calls
verlaufenden Pfeile dargestellt.
-
Die
transparente Replikation von AUTOSAR-Softwarekomponenten erlaubt
eine beliebige Zahl von Softwarekomponenten (Komposition) redundant
auszuführen.
Eine Komposition hat Ein- und Ausgangsports, die nach außen geführt werden.
Im AUTOSAR werden diese als „Delegation
Ports" bezeichnet.
Ports, die intern verschaltet sind, werden in AUTOSAR als „Assembly
Ports" bezeichnet.
Delegation Ports repräsentieren
das Verhalten nach außen und
müssen
bei Redundanz-Überlegungen
besonders beachtet werden. Alle Signale und Eingangsports, die sog. „Required
Ports" müssen zeitgleich den
Eingangsports der redundanten Komponenten zugeführt werden. Alle Ausgangsports,
die „Provided Ports", müssen vor
der Ausgabe eines Signals mit dem Ergebnis der Partnerkomponente
verglichen und zu einem gemeinsamen Ergebnis kombiniert werden.
Dieser Vorgang wird als Auswahlfunktionalität oder Voting bezeichnet. Für jeden
Ausgangsport, der einem Voting unterzogen wird, muss eindeutig festgelegt
sein, welche Aktion oder Aktionen im Erfolgsfall und im Fehlerfall
ausgeführt
werden müssen.
Im Erfolgsfall stimmen beide Teilergebnisse, d. h. Ergebnisse, die
von den Systemen X und X' ermittelt
wurden, innerhalb festgelegter Toleranzen überein. Im Fehlerfall sind
die Teilergebnisse, die von den Systemen X und X' ermittelt wurden, unterschiedlich. Port-Zugriffe
und andere RTE-Calls, die nicht nach außen geführt sind, müssen zeitlich synchronisiert werden,
ohne ein Voting oder eine Auswahlfunktionalität auszuführen.
-
Anhand
von 5 wird die Synchronisierung im Detail erläutert. Die
AUTOSAR-Methode erlaubt ein statisches Mapping, dies bedeutet ein
Mapping zur Konfigurationszeit von Soft warekomponenten auf den Verarbeitungseinheiten.
Da das Mapping statisch ist, ist zum Zeitpunkt der Laufzeitumgebungs-Generierung bekannt,
welche Komponenten auf welche Verarbeitungseinheiten gemapped wurden.
Dies erlaubt dem Generator der Laufzeitumgebung physikalische Synchronisierungspfade
für alle Synchronisierungspunkte
zu finden und den entsprechenden Code zu generieren. Unter einem
physikalischen Synchronisierungspf ad wird die Verbindung zwischen
einer ECU-Instanz und ihrer redundanten Partner-Verarbeitungseinheit
bezeichnet. Dies kann eine Punkt-zu-Punkt-Verbindung als auch ein
Bus sein.
-
5 zeigt
die physikalische Sicht nach der Ausführung des Mappings für die am
Anfang gezeigte virtuelle Sicht (2). In 5 sind
die Instanzen der Softwarekomponente mit ECU1 und ECU2 bezeichnet.
Redundante Instanzen der Softwarekomponente sind mit ECU1' und ECU2' gekennzeichnet. Im
Beispiel der 5 wurden die Komponenten A und
B auf die ECU-Instanz ECU1 gemapped, während die Komponenten C, D
und E auf die ECU-Instanz ECU2 gemapped wurden. Jede der ECU-Instanzen
ECU1, ECU2 hat ein redundantes Doppel ECU1', ECU2', auf dem die Komponenten gleichermaßen gemapped
sind. Die ECU-Instanzen
verfügen zu
ihren redundanten Partnern jeweils über einen Synchronisationskanal
SYNC. In der dargestellten Konfiguration kann die Laufzeitumgebung
die Synchronisierung bei der transparenten Replikation von AUTOSAR-Softwarekomponenten übernehmen. Dies
bedeutet, die Funktionalität
zur Synchronisierung der replizierten AUTOSAR-Softwarekomponenten
kann ohne explizite Modellierung für die Applikation transparent,
generiert werden. In 5 ist ferner ein Auswahlschalter
SEL dargestellt, der mit dem Ausgang der ECU-Instanz ECU2 verbunden
ist. Weiterhin ist er mit dem Aktuator AKT verbunden. Die Schalterstellung
wird durch das Ausgangssignal der redundanten ECU-Instanz 2 ECU2' festgelegt. Im Fall,
dass die von den ECU-Instanzen ECU2 und ECU2' bestimmten Teilergebnisse identisch
sind, wird der Schalter geschlossen, so dass das Ausgangssignal
an den Aktuator AKT weitergeleitet werden kann.
-
Replikation
kann beispielsweise auf symmetrischen Mikrocontrollern erfolgen,
die durch einen direkten Kommunikationskanal mit niedrigen Latenzzeiten
(z. B. dual-ported RAM) miteinander verbunden sind. Replikation
kann auch auf diversitären
Mikrocontrollern erfolgen, die durch einen direkten Kommunikationskanal
mit direkten Latenzzeiten (z. B. dual-ported RAM) miteinander verbunden
sind. Replikation ist in einem durch CAN-Bus oder Flexray-Bus verbundenen
Netzwerk von Steuergeräten möglich. Replikation
ist ferner auf einem Mikrocontroller möglich. Dabei wird replizierter
Code zeitversetzt ausgeführt.