Startseite > Embedded > Hardware > Effektives Obsolescence-Management von Embedded-Systemen

Effektives Obsolescence-Management von Embedded-Systemen

24. Februar 2009, 10:25 Uhr | Gregor Braun, Key Account Manager von Sysgo

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Effektives Obsolescence-Management von Embedded-Systemen

Ein übergreifendes Konzept zum Obsolescence-Management hat das Softwareunternehmen Sysgo entwickelt. Welchen hohen Stellenwert das Obsolescence-Management hat, unterstreicht die Mitgliedschaft Sysgos in der Component Obsolescence Group Deutschland (COG-D). Die vor über vier Jahren gegründete Interessengruppe beschäftigt sich mit dem frühzeitigen Erkennen der Obsolescence-Thematik und dem Minimieren der negativen Auswirkungen. Mittlerweile sind knapp 60 Unternehmen aus allen Industriebranchen in der COG Deutschland vertreten.

Sysgo ist das einzige COG-Mitglied, das sich mit dem Obsolescence-Management im Bereich Embedded-Software beschäftigt. Sysgos Lösung zum Obsolescence-Management heißt PikeOS. Das Echtzeitbetriebssystem basiert auf einem MILS-konformen Mikrokernel, der alle Hardwarezugriffe kontrolliert. Das Besondere der PikeOS-Architektur ist die Fähigkeit, alle Ressourcen je nach Bedarf in Untergruppen (Subsets) einzuteilen.

Dank der Paravirtualisierungsfunktionalität können innerhalb von geschützten Software-Partitionen verschiedene Betriebssysteme, Laufzeitumgebungen und APIs gleichzeitig ablaufen. Voraussetzung dafür sind exakt überschaubare Kommunikationswege, die den Einsatz sicherheitskritischer und unkritischer Anwendungen auf ein und derselben Hardware ermöglichen. Dank dieser Leistungsmerkmale ist PikeOS dazu geeignet, veraltete Software durch die Isolierung in einer gesonderten Partition in ein modernes, leistungsfähiges Embedded-System zu integrieren.

Der Vorteil ist, dass der bereits vorhandene Legacy-Code weiter verwendet werden kann und nicht neu entwickelt werden muss. Die bewährte Software lässt sich dann z.B. zusammen mit Linux auf einer neuen Hardwareplattform betreiben. Die Modularität und Unabhängigkeit der getrennten Systeme bleibt dabei erhalten. Die Voraussetzung für das Isolieren und Kapseln unterschiedlicher Softwarepakte ist das in PikeOS implementierte Ressourcen- und Time-Partitioning. Bei dem Ressourcen-Partitioning erfolgt eine statische Belegung aller verfügbaren und temporären Ressourcen.

Jede Applikation erhält einen garantierten Zugriff auf die zugewiesenen Ressourcen, hat aber keinen Zugriff auf Ressourcen anderer Partitionen. Durch diese strikte Trennung ist sichergestellt, dass sich Fehler nicht auf andere Bereiche auswirken. Laufen Teilsysteme mit verschiedenen Sicherheitsstufen auf einem System, muss garantiert sein, dass unkritische Anwendungen sicherheitskritische nicht beeinflussen. Dadurch lassen sich in PikeOS beispielsweise ein Linux-basiertes Teilsystem und eine sicherheitskritische Anwendung mit eigenem Betriebssystem gemeinsam auf einer CPU-Plattform betreiben.

Alle Partitionen laufen im User-Mode und beeinflussen den damit stabilen Kernel-Mode nicht. Die so entstandenen Stand-alone-Lösungen, Personalities, sind unter anderem für POSIX, OSEK und Linux verfügbar. Erzeugt werden die einzelnen Partitionen mit definierten CPU-Ressourcen von der PikeOS-Systemsoftware (PSSW). PSSW lädt beim Start des Systems die Partitionsinhalte und steuert die Kommunikation zwischen den Partitionen.

Auch der Zugriff auf Ressourcen, die von mehreren Partitionen gemeinsam genutzt werden, wird von der PSSW kontrolliert. Das Time-Partitioning sieht eine statische Konfiguration der Ablaufreihenfolge und der Ausführungszeit vor. Damit können die für Worst-Case-Ausführungszeiten benötigten Ressourcen garantiert werden. Um allerdings auf kritische Events schnell und zuverlässig reagieren zu können, gibt es zusätzlich noch die Möglichkeit, die Ausführungsreihenfolge der Partitionen über deren Priorität zu beeinflussen.

Auf diese Weise kann man z.B. einen hochkritischen Interrupt Handler eine unkritische Entertainment Partition unterbrechen (preempten) lassen und somit niedrige Latenzzeiten erreichen. Die Prozesse auf niedriger Priorität können natürlich nicht das Laufzeitverhalten der Höherprioren beeinflussen. Zusätzlich ist es über diese Priorisierung ebenfalls möglich, Idle-Jobs auf einer niedrigen Priorität zu implementieren.