Unternehmen stehen vor der Aufgabe, neue Geräte und Maschinen rundum betriebssicher beziehungsweise systemsicher zu gestalten, um Mitarbeiter zu schützen und die vorgeschriebenen Zertifizierungen zu erlangen. Den Grundsatz „Safety First!“ kennen wir schließlich alle, und er beschreibt sehr gut, worum es geht: Eine Aktion oder ein Gerät muss so sicher sein, dass keine Folgeschäden entstehen können. Übersetzt in die Sprache der Maschinenbauer: Die implementierten Safety-Features müssen im Falle eines Fehlers, einer Manipulation oder eines Systemausfalls dafür sorgen, dass eine Maschine auf eine sichere Ebene beziehungsweise in einen sicheren Zustand zurückfällt.

Multicore-Prozessoren bieten eine elegante Möglichkeit, Safety im Rahmen von Virtualisierung innerhalb des Automatisierungssystems zu verankern. Dazu spricht das System den Multi-Core-Prozessor über einen so genannten Hypervisor an. Durch einen schlanken Software-Layer wird die Geräte-Hardware so weit abstrahiert, dass darauf laufende Betriebssysteme, beispielsweise das einer Safety-SPS, nur eine virtualisierte Hardware sehen. Dies ermöglicht zum einen, mehrere Instanzen von Betriebssystemen auf derselben Hardware in so genannten Partitionen gleichzeitig laufen zu lassen; zum anderen lässt sich mit dem Hypervisor durch „Virtual Board Files“ die virtualisierte Hardware dem Einsatz-Zweck in jeder Partition gewissermaßen auf den Leib schneidern.

Einsatz-Szenario Safety: Ein zertifizierter Hypervisor ermöglicht den Betrieb von sicherheitsrelevanten Applikationen auf Basis des Echtzeit-Betriebssystems VxWorks zusammen mit unkritischen Software-Anwendungen auf einer einzigen Hardware-Plattform.

© Wind River

Ein typisches Einsatz-Szenario ist eine Steuerung mit Echtzeit-Anforderungen, grafischer Darstellungsmöglichkeit und einem User Interface. Ein Lösungsansatz bei Einsatz des Hypervisors wäre die Verteilung der Aufgaben auf zwei Betriebssysteme, beispielsweise VxWorks und Linux, wobei die Echtzeit-Steuerung unter VxWorks realisiert wird und Linux die Visualisierung übernimmt sowie das User Interface bereitstellt.

In diesem Szenario wären typische Devices, die für die Echtzeit-Steuerung benötigt werden, beispielsweise Realtime Clocks, CAN Interfaces oder (Realtime) Ethernet Interfaces unter VxWorks verfügbar. Devices für das User Interface und die Visualisierung, wie USB-Controller und Grafik-Controller sind der Linux-Partition zugeordnet. Diese Verteilung der physikalischen Hardware auf zwei oder mehrere virtuelle Hardware-Instanzen, den „Virtual Boards“, definieren die besagten Virtual Board Files. Unter anderem wird darin die Abbildung der CPU-Cores und des physikalischen Speichers festgelegt und die PCI-Devices, Interrupts und das Shared Memory zugeordnet.

Den Betriebssystemen lässt sich über die Virtual Board Files ein exklusiver Zugriff auf die physikalische Hardware zuteilen oder nur ein indirekter Zugriff über das Betriebssystem einer anderen Partition, das die exklusiven Zugriffsrechte besitzt. Auf diese Weise stehen beispielsweise nur einmal im System vorhandene Ethernet- oder serielle Anschlüsse mehreren Partitionen zur Verfügung, wobei der jeweilige Geräte-treiber nur in der Partition mit den exklusiven Zugriffsrechten geladen sein muss. Jede weitere Instanz greift dann über ein definiertes API auf dieses Device zu. Eine andere Möglichkeit, den Zugriff auf die Komponenten zu regeln, besteht darin, den Treiber in die Hypervisor-Schicht zu verlagern und jeder Partition dieses Device vir-tuell zur Verfügung zu stellen. Dabei muss unbedingt gewährleistet sein, dass keines der Betriebssysteme die Kontrollfunktion des Hypervisors umgeht.

Neben der Organisation der Hardware-Zugriffe hat der Hypervisor noch eine wichtige Aufgabe: die Verteilung der CPU-Ressourcen auf die Partitionen mithilfe eines Schedulers. Auf einem Multicore-Board, auf dem genau so viele Partitionen unter dem Hypervisor laufen wie CPU-Cores vorhanden sind, beschränkt sich die Funktionalität des Schedulers in der Regel darauf, jede Partition auf einem eigenen Core zu betreiben. Sind weniger CPU-Cores vorhanden als Partitionen, kümmert sich der Scheduler zudem um die Verteilung der Rechenzeit der Partitionen auf die Cores. Dabei werden drei Modelle unterstützt:

■ Bei sicherheitskritischen Anforderungen erfolgt das Scheduling nach festen Zeitscheiben. Jede Partition erhält dann zyklisch und in fester Reihenfolge eine bestimmte Rechenzeit.
■ Bei echtzeitkritischen Anwendungen werden die Zeitscheiben dagegen nach Prioritäten zugewiesen. Der Scheduler kümmert sich darum, dass jede Partition entsprechend ihrer Priorität Rechenzeit bekommt, wenn sie sie benötigt.
■ Der gleichzeitige Betrieb von echtzeit- und sicherheitskritischen Anwendungen ist ebenso möglich. Die Zeitscheiben für die kritischen und unkritischen Partitionen werden hier anhand der Zykluszeit der Echtzeit-Anwendung mit Berücksichtigung eines Zeitpuffers festgelegt.

Einsatzbereiche des Hypervisors

Einsatz-Szenario Hardware-Migration: Bestehende Applikationen lassen sich weiter verwenden und durch neue Funktionen in einer zweiten Partition ergänzen.

© Wind River

Ein Hypervisor stellt eine ideale Konsolidierungsplattform für Hardware-Ressourcen dar. Aufgrund der Leistungs-fähigkeit moderner CPUs und des Einsatzes von Multicore-CPUs lassen sich damit Applikationen, die zurzeit noch auf verschiedenen Hardware-Plattformen und Betriebssystemen laufen, auf einer gemeinsamen Hardware-Plattform zusammenfassen. Der Vorteil einer solchen Konsolidierungsplattform: Existierende Applikationen können bei geringem Aufwand für die Adaption an den Hypervisor weiter genutzt werden. Weniger, aber leistungsfähigere Boards reduzieren zudem die Hardware-Komplexität.

Ebenso eignet sich ein Hypervisor für die Gewährleistung von Security im Embedded-Bereich. Über dessen Konfigurator und Scheduler können jedem einzelnen Core der CPU jeweils eine individuelle Funktions-Partition zugewiesen werden So kann beispielsweise auf dem Core 1 eine Partition unter dem Betriebssystem VxWorks die klassischen SPS-Funktionalitäten abarbeiten, während auf dem zweiten Core die gesamte Visualisierung in einer separaten Partition unter Windows läuft. Auf einer dritten Partition im Core Nr. 3 lassen sich die Security-Maßnahmen implementieren, um den Netzwerk-Zugang für Fernwartung abzusichern, der in diesem Szenario die einzigste Schnittstelle nach außen darstellt.

Virtualisierung vereinfacht die Zertifizierung

Einsatz-Szenario Virtualisierung: Bisher real vorhandene Hardware wird auf virtuelle Boards verteilt – in diesem Fall sind es drei, auf denen VxWorks sowie eine Applikation ohne Betriebssystem laufen. MIPC (Multi-OS Interprocess Communication) ist ein Wind-River-spezifisches Protokoll für die schnelle Kommunikation zwischen Partitionen.

© Wind River

Der Aufwand für die Zertifizierung sicherheitskritischer Applikationen steigt bei Software mit dem Umfang des Quellcodes. Bei integrierten Implementierungen von sicherheitsrelevanter und nicht-sicherheitsrelevanter Steuerungssoftware müssen daher neben den Safety-Funktionen die Steuerungsapplikationen zertifiziert werden. Ganz anderes bei einer Virtualisierung: Mittels Hypervisor lassen sich die Sicherheitsfunktionen in eine eigene Partition auslagern, die gemäß der Norm IEC 61508 zu zertifizieren ist. Für die Steuerungsapplikationen in der anderen Partition muss lediglich der Nachweis erbracht werden, dass sie auf keinen Fall die Sicherheitsfunktionen beeinflussen können.

Änderungen und Updates der eigentlichen Applikationssoftware können die Entwickler damit beliebig oft vornehmen, ohne dass dabei eine erneute Zertifizierung erforderlich wird. Die Zertifizierung des Modells bietet die Freiheit, die nicht sicherheitskritischen Applikationen zu ändern. Dabei der Virtualisierung alle Partitionen auf einem einzigen (Multi-Core-) Prozessor ablaufen, ist nur eine einzige Hardware-Basis mit einer entsprechenden Entwicklungs­umgebung erforderlich, außerdem vereinfacht sich damit das Lifecycle-Management. Wind River unterstützt Safety-Produkte durch ein zertifizierbares Virtualisierungssystem, das mit einem hohen Sicherheitsgrad gewährleistet, dass die Anwendung stets in einem sicheren Zustand läuft.

Autor: Michael Gaudlitz ist Technical Account Manager bei der Firma Wind River in Ismaning.