Entwicklungszyklen im Vergleich Embedded Linux contra proprietäres RTOS

Das enorme Angebot an kostenloser Software, der Fülle unterstützter Hardware und das ständig wachsende Ecosystem von Embedded Linux sind beeindruckend. Doch führt allein die Entwicklungsarbeit auf Basis von Embedded Linux zu einem schnellen und einfachen Design ?

Dieser Artikel beschreibt reale Erfahrungen bei der Entwicklung von Embedded Linux- und RTOS-Systemen und hilft Entwicklern, beim nächsten Embedded-Projekt die richtige Entscheidung zu treffen.

Eine Embedded-Linux-Distribution mit Kernel und Softwarepaketen enthält Millionen von Codezeilen, was ein attraktives Paket an vorgefertigter Software darstellt. Obwohl erhebliche Kenntnisse über die Abhängigkeiten und Konfigurationsdetails erforderlich sind, kommt diese Software in der Industrie häufig zum Einsatz. Ein proprietäres RTOS mit einer minimalen Codebasis und begrenzter Middleware-Verfügbarkeit kann die gleichen Software-Anforderungen erfüllen, der Ansatz aber unterscheidet sich zur Herangehensweise bei Linux.

Bei der Wahl von Embedded Linux oder eines proprietären Betriebssystems ist einiges zu beachten. Hier geht es nicht nur um die Kosten, sondern auch um die Komplexität, fortschrittliche Kompilier- und Debugging-Tools, Time to Market, Entwicklungseffizienz etc.

Als Beispiel soll ein internetfähiges Gerät mit einem Display betrachtet werden, das Informationen für Endanwender bereitstellt und auf fortschrittlichen Grafik-Frameworks wie Qt und OpenGL beruht. Optional können Endanwender Eingaben über einen Berührungsbildschirm machen. Die Time-to-Market ist kurz und es ist wenig Personal vorhanden. Worauf sollte der Applikations-Softwarestack also basieren? Sowohl die Benutzerschnittstelle als auch die Internetanbindung legen nahe, eine allseits beliebte Embedded-Linux-Lösung zu verwenden, denn viele Entwickler kennen sich bereits mit Linux-Desktop-Lösungen aus.

Die Hardwareseite muss ebenfalls in Betracht gezogen werden, da abzuklären ist, ob Linux unterstützt wird oder nicht. Ein häufig eingesetzter SoC-Baustein (System on Chip), der i.MX6 auf Basis eines Dual/Quad-Core-ARM Cortex-A9 von NXP, erscheint geeignet und unterstützt Linux, Android und QNX [1]. RTOS-Anbieter wie Green Hills Software mit »Integrity« [2] und Microsoft mit »Windows Embedded Compact« unterstützen über externe Dienstleister auch diese Hardware – genauso wie Wind River oder TimeSys, die kommerzielle Linux-Lösungen bereitstellen [1]. NXP bietet nicht nur eine, sondern zwei verschiedene Lösungen für Embedded Linux auf dem i.MX6: LTIB (Linux Target Image Builder) [3] und die heute so beliebte Yocto-Projektlösung [4]. Es gibt noch weitere Embedded-Linux-Build-Systeme, z. B. Buildroot, das aber in diesem Fall nicht anwendbar ist, da der Chiphersteller dies nicht unterstützt.

Viele Halbleiterhersteller stellen ihre Linux-Kernel-Patches (d. h. Treiber für ihre SoC-Peripherie) nur für spezielle Build-Systeme oder Kernel-Versionen zur Verfügung. Die Aktualisierung erfolgt nicht so häufig wie beim Standard-Linux-Kernel oder anderen Open-Source-Projekten. Dies macht neue Kernel und Funktionen auf diesen Hardwareplattformen in vielen Fällen nicht verfügbar und verhindert oder beeinträchtigt die Integration in andere Build-Systeme.

Indirekte Anforderungen

Betrachtet man jetzt die anderen Softwareanforderungen, findet man dort die Forderung nach signierter Software, vor allem auf Treiberebene, oder für signierte Kernel-Module, wenn es um Linux geht. Diese Funktion wurde mit dem Linux-Kernel 3.7 eingeführt [5]. Das Original-LTIB-System von NXP unterstützt für den i.MX6 aber nur Kernel 3.0. Dies macht den Einsatz von LTIB unmöglich oder fordert einen deutlichen Mehraufwand bei der Code-Portierung von einem neueren Linux-Kernel auf das LTIB-basierte System. Dieser Portierungsaufwand erfordert umfangreiche Kenntnisse über den Linux-Kernel und das Umschreiben von Treibern, kann sich aber auch als Aufgabe erweisen, die nie vollständig abgeschlossen wird. Dies würde den Rahmen eines Projekts sprengen, da dieser Weg bei der Wahl von Embedded Linux nicht beabsichtigt war. Der Fokus würde sich von den ursprünglichen Projektaktivitäten fort verlagern, was den Zeitplan durcheinanderbringt und eine Verzögerung der Projektabwicklung zur Folge hat. Die Entwickler müssten sich dann auf Aktivitäten konzentrieren, für die sie keine Zeit, kein Interesse oder auch kein Know-how haben. Dies ist nur eine dieser indirekten Anforderungen, die Störungen im Softwareentwicklungsprozess verursachen können – vor allem bei der Verwendung von Embedded Linux. Es gibt zahlreiche solche Fallstricke, die ein tieferes Verständnis der Auswirkungen erfordern.

Warum ist die Portierung so schwierig? Betrachten wir die allgemeine Forderung, dass eine grafische Benutzeroberfläche ein hardwarebeschleunigtes Grafiksystem wie OpenGL benötigt. Viele Halbleiterhersteller lizenzieren dafür die GPU und die Lizenzbedingungen erlauben ihnen, nur Binärversionen der Grafiktreiber zu erstellen. Leider sind diese Binärversionen oft nur für eine Linux-Kernel-Version freigegeben, die speziell für das aktuell unterstützte Build-System und/oder den SoC ausgelegt sind. Dies erschwert eine Änderung der Kernel-Version oder anderer grafikbezogener Softwarepa¬kete. Dieses Setup ist einer der Hinderungsgründe, warum die Original-Intel-Atom-CPU nicht in der Open-Source-Welt Fuß fassen konnte [6].

Bevor die Entscheidung für ein proprietäres RTOS getroffen wird, sollten die Anforderungen genau analysiert werden. Im ersten Schritt sollten RTOS-Anbieter gefragt werden, wie sie die spezifischen Anforderungen erfüllen würden. Die Anbieter sollten dafür Antworten bereitstellen. Auf der Referenzseite des SoC [1] ist ersichtlich, dass der Baustein von vielen großen RTOS-Anbietern unterstützt wird. Um aber den Umfang und die Verfügbarkeit des Angebots genauer kennenzulernen, muss jeder Anbieter direkt kontaktiert werden. Dabei können auch andere Merkmale wie funktionale Sicherheit oder Echtzeitfunktionen angeboten werden, die eine Linux-Lösung nicht bietet. In der Endanwendung kann sich dies als vorteilhaft erweisen.

RTOS-Anbieter greifen gerne auf ihr Partnernetzwerk zurück, gerade wenn erweiterte Middleware wie Grafikunterstützung oder Kommunikationssoftware erforderlich ist. Der wachsende Embedded-Markt zwingt diese Middleware-Anbieter mehr und mehr dazu, Allianzen und Partnerschaften mit verschiedenen Softwareanbietern einzugehen – und das nicht unbedingt nur im Embedded-Markt. Das Geschäft wächst in diesem Bereich, da auch andere Betriebssysteme als die üblichen oder gängigsten unterstützt werden. Dadurch entsteht ein Ecosystem unterstützter Softwarekomponenten. Obwohl einige Komponenten von verschiedenen Herstellern bezogen werden ist es nur selten nötig, gängige Software neu zu schreiben oder zu portieren, die nicht bereits zur Verfügung steht. Leider taucht diese Information nicht sofort auf, wenn man nach einem alternativen RTOS sucht. Die Besprechung der Anforderungen mit dem RTOS-Anbieter ist daher entscheidend.

Einer der Gründe für Linux ist, dass man sich nur auf den entsprechenden Software-Stack konzentrieren muss, das heißt, auf die Endanwendung. Das zugrundeliegende Build-System und die Konfiguration setzen bestimmte Anforderungen voraus, die möglicherweise im Widerspruch zum beabsichtigten Anwendungsbereich stehen.

Code erstellen, verstehen und konfigurieren

Die Anforderungen führen letztlich zum Yocto-Projekt und dessen Build-System. Für jemanden, der mit dem Yocto-Projekt nicht vertraut ist, handelt es sich im Grunde um ein Open-Source-Projekt, das den Softwareentwicklungsprozess beim Erstellen eines Embedded-Linux-Systems besser macht. Hinter diesem Projekt steht die Linux Foundation [7]. Es beruht auf der OpenEmbedded-Architektur und wird von zahlreichen Tool-Anbietern sowie Halbleiterherstellern unterstützt. Für viele Embedded-Linux-Lösungen ist dies völlig ausreichend – solange man den damit verbundenen Aufwand und die Arbeit mit einplant.

Dabei sind einige Dinge zu berücksichtigen. Obwohl das Yocto-Projekt als einfache Lösung zum Erstellen einer eigenen Embedded-Linux-Distribution angeboten wird, die sich entsprechend den Anforderungen konfigurieren lässt, ist doch einiges an Wissen erforderlich, um diesen Anforderungen zu genügen. Das Projekt wird schnell als aufgeblähte Lösung angesehen, die leistungsfähige Build-Maschinen benötigt, die viel RAM und Festplattenspeicher belegen. Natürlich würde jeder Entwickler gerne solche Maschinen zur Verfügung haben, aber wir alle wissen, dass dies in der Realität nicht der Fall ist.

Der Standardaufbau eines Yocto-Projekt-Builds lädt einen erheblichen Teil an Build-Scripts und Software herunter, um verschiedene »Rezepte« für den Download, die Konfiguration, das Erstellen und die Installation verschiedener Komponenten im Embedded-Linux-System zu ermöglichen. In vielen Konfigurationen ist der erste Schritt der Download der Cross-Compiler-Toolchain-Quellen. Anschließend wird der Cross-Compiler für den Host-Rechner erstellt. Erst danach wird mit dem Aufbau des Zielsystems (Target) begonnen – in diesem Fall für den ARM Cortex-A9. Es gibt Möglichkeiten, das System so aufzubauen, dass auch eigenständige Compiler genutzt werden. Damit wird ein Neuaufbau (Rebuild) des Compilers vermieden, was aber die sorgfältige Auswahl einer geeigneten Toolchain erfordert. So kann es eine Herausforderung sein, die Hard-Float- vs. Soft-Float-Laufzeitbibliotheken bei der Verwendung der Compiler von Drittanbietern korrekt einzurichten. Dadurch ergibt sich das Risiko einer schlechten Fließkomma-Performance. Entwickler müssen daran denken, dass die Laufzeitbibliotheken (C/C++-Bibliotheken) für ihr Embedded-Linux-System vom Cross-Compiler angezogen werden, d. h. der Cross-Compiler stellt diese Bibliotheken zur Verfügung. Wenn man also erstmal einen Compiler bauen muss, nur um Zielsoftware erstellen zu können, wird die Host-Installation aufgebläht und der Build-Prozess mit unnötigen Build-Dateien überladen. Hinzu kommen der zusätzliche Zeitaufwand und unnötige Risiken. Bild 1 zeigt den Workflow des Yocto-Projekts.

Aus der Build-Perspektive wird ein RTOS wie Integrity oder VxWorks in der Regel mit einer validierten Version der Toolchain oder des Compilers ausgeliefert, deren dessen Verwendung obligatorisch ist. Beide müssen entweder vom RTOS-Anbieter oder einem Drittanbieter installiert oder beschafft werden. Dies steht im Gegensatz zum Yocto-Ansatz, der die Toolchain zu einem Teil des Build-Prozesses macht und die Erstellung aus Quellen mit den üblichen Einschränkungen bei Konfiguration, Building und Validierung vornimmt. Kommerzielle Linux-Alternativen wie Wind River Linux verpacken dies etwas anders. Selbst wenn Teile davon Yocto-konform sind, ist der Cross-Compiler ein Teil der Installation.

Sind das Build-System und der zugehörige Cross-Compiler installiert, muss das Konfigurationsmanagement des Embedded-Linux-Systems erfolgen.

Konfiguration

Ein solches System besteht aus einem Linux-Kernel, Hardware-bezogenen Patches und einer Reihe von Open-Source-Paketen, die jeweils ihre eigenen Konfigurationsschritte, Build-Prozesse etc. erfordern. Das Yocto-Projekt deckt bereits den Großteil davon ab. Es bietet sogar Vorlagen zum Erstellen spezifischer Lösungen für eigene Anwendungen. Dies wird jedoch flexibel gehandhabt und das Navigieren zwischen dem, was der Hardwareanbieter bereitstellt, den Anforderungen und den tatsächlich verfügbaren und getesteten Softwarelösungen kann leicht zur Verwirrung führen.

Das Verständnis aller Konfigurationsmöglichkeiten und Paketabhängigkeiten ist eines der größeren Hindernisse, die sich bei der Entwicklung eines Embedded-Linux-Systems ergeben. Entwickler verbringen damit sehr viel Zeit, die nicht im Zentrum der Anwendungsentwicklung steht. So kann die Unterstützung für eine Art von Softwarepaket eine Abhängigkeit für ein anderes Softwarepaket hervorrufen, das nicht im Build-System enthalten ist. Auch eine Abhängigkeit zu einer anderen Version dieses anderen Softwarepakets kann bestehen, von der vorher nichts bekannt war. Dies kann schwierig zu lösen sein und aufwendige Änderungen im System erfordern, die anfangs nicht geplant waren. Das Endergebnis kann dann sein, dass Entwickler entweder die Projektanforderungen über den Haufen werfen oder die Produktentwicklung abbrechen.

Dieses Abhängigkeitsdilemma ähnelt einem Top-Down-Ansatz beim Konfigurationsmanagement von Softwarepaketen. Jede Komponente oder jedes Paket muss konfiguriert werden, um weniger Abhängigkeiten zu erzeugen, oder eine Skalierung auf Ihre Anforderungen ist erforderlich. Ein entscheidender Faktor bei der Wahl eines Betriebssystems wie Linux ist die umfangreiche Netzwerkunterstützung des Linux-Kernels. Diese Unterstützung ist allerdings ebenfalls sehr komplex hinsichtlich der Feinabstimmung, falls spezielle Netzwerkanforderungen bestehen. Dies kann sogar zu Anforderungen bei Userspace-Applikationen führen, die entsprechend konfiguriert und erstellt werden müssen. Um die Anforderungen zu erfüllen, ist am Ende ein enormer Zeitaufwand erforderlich, um unterschiedliche Konfigurationen zu überprüfen und Abhängigkeiten aufzulösen.

Eine Fülle an Software

Viele Entwickler denken, dass der Zugriff auf den Quellcode ihnen dabei hilft, jeden auftretenden Fehler zu lösen, da die Quelle ein Verständnis des Systems vermittelt und einen Qualitätsbeweis darstellt. Bedenkt man jedoch, dass ein Embedded-Linux-System aus vielen Millionen Codezeilen besteht – welcher Entwickler will jemals diese gesamte Codebasis verstehen?

Viele proprietäre RTOS-Lösungen stellen ebenfalls den Quellcode für viele ihrer Komponenten zur Verfügung – wenn nicht sogar für alle. In der Realität beziehen sich die meisten (wenn nicht alle) Fehler in Entwicklungsprojekten auf Basis proprietärer RTOS-Lösungen nicht auf Probleme innerhalb der bereitgestellten Komponenten. Stattdessen ist der Benutzercode, der diese Komponenten verwendet, weitaus anfälliger für Probleme mit Softwarefehlern oder einer missverständlichen API-Nutzung. In diesem Fall helfen Training und Support, um ein Verständnis für das System zu erlangen, anstatt Millionen von Codezeilen zu lesen. Hinzu kommt, dass die RTOS-Lösungen, die Code ausgeben, weniger Speicherplatz auf der Festplatte einnehmen als die Linux-Alternative.

Bei einem proprietären RTOS bestehen ebenfalls Abhängigkeiten zu verschiedenen Versionen und Komponenten, die vom RTOS Anbieter oder dessen Partnernetzwerk unterstützt werden. Diese Unternehmen wollen jedoch Lösungen verkaufen und werden alternative Lösungen aushandeln, sobald Abhängigkeiten mit ins Spiel kommen. Demnach treten also nicht die gleichen Probleme durch Abhängigkeiten von Paketen auf, man muss jedoch auf die Softwarelösung zurückgreifen, die angeboten und unterstützt wird.

Der proprietäre RTOS-Ansatz für das Konfigurationsmanagement ist auch hier eine Lösung des Problems. In der Regel werden nur die Komponenten mit einbezogen, die gewünscht sind. Demnach kommt ein einfacher Bottom-up-Ansatz zur Anwendung. Somit wird weit weniger Zeit für die Konfiguration von Komponenten aufgewendet, da sie bereits von den Anbietern für den Anwendungsfall vorbereitet sind. Damit verkürzt sich die Time-to-Market.

Schulung, Training und Support

Geht es um das allgemeine Linux-Wissen, gibt es eine Vielzahl von Linux- und sogar Embedded-Linux-Ressourcen, da sich Embedded Linux nicht allzu sehr von der Desktop-Version unterscheidet. Das Hauptproblem ist, viele Entwickler sind mit Desktop-Linux-Lösungen und entsprechenden Tools für die Entwicklungsunterstützung vertraut. Sie gehen dann davon aus, dass die gleichen Ressourcen auch für die Embedded-Plattform zur Verfügung stehen. Dadurch entsteht eine Wissenslücke rund um die Möglichkeiten einer Embedded-Linux-Lösung.

Dies ist auch ein Problem, wenn ein Übergang auf eine neue Betriebssystemplattform für die zukünftige Entwicklung erfolgt. Nicht alle Bibliotheken (oder Middleware) werden genauso angeboten, wie man es gewohnt ist. Viele Unternehmen bieten Schulungen für Embedded-Linux-Systeme an. Zahlreiche Informationen stehen auch online zur Verfügung – solange man weiß, wo man suchen muss. Leider gehen die Schulungen nicht tief genug in das Konfigurationsmanagement und die Lösung von Paketabhängigkeitsproblemen ein.

Die meisten, wenn nicht alle RTOS-Anbieter bieten auch professionelle Schulungen – entweder über eigenes Personal oder durch Anbieter, die speziell auf solche Schulungen ausgerichtet sind. Sie geben dem Anwender bestmögliches Wissen zum Erlernen des neuen Betriebssystems, der Schnittstellen und zugehörigen Tools mit auf den Weg. Der Umfang der Schulungen unterscheidet sich nicht wesentlich von dem, was man aus der Open-Source-kennt.

Wenn Dinge nicht wie erwartet funktionieren und Probleme auftreten, die nicht verstanden werden, ist Support und Unterstützung erforderlich. Für viele Entwickler ist dann die Open-Source-Umgebung die richtige Lösung, da die Antwort im Code liegt. Doch das Lesen und Verständnis von vielen Millionen Codezeilen, aus denen das System besteht, ist nicht durchführbar. Zum Glück haben viele Entwickler bereits ähnliche Probleme erlebt und sind bereit, in Internetforen Fragen zu beantworten. Dies kann allerdings sehr zeitaufwendig sein und verlagert den Fokus des Entwicklers auf die Lösungsfindung eines Problems. Am Ende muss man sich auf den kooperativen Geist anderer Menschen außerhalb der eigenen Organisation verlassen, um Hilfe zu erhalten.

Ein proprietäres RTOS kann anfangs noch problematischer sein, dann ist eine Schulung erforderlich, um einen schnellen Entwicklungsstart zu garantieren. Meist gibt es keine Support-Foren, in denen Fragen beantwortet werden. Auch Online-Guides stehen selten zur Verfügung, um bei speziellen Aufgaben zu helfen. Die meisten RTOS-Anbieter bieten jedoch professionelle Unterstützung, die tatsächlich zur Behebung von Problemen beitragen kann. Dies trifft auch auf kommerzielle Linux-Alternativen zu, da eines der Geschäftsmodelle dieser Unternehmen die Bereitstellung von Support-Dienstleistungen ist, sobald deren Open-Source-Lösungen verwendet werden. Es kommt nur auf die Entscheidung an, ob Zeit oder Kosten ein Problem sind, da entweder Zeit mit Entwicklern verbracht werden muss, um Antworten zu finden, oder Geld für Support-Dienstleistungen investiert werden muss, um Hilfe von anderen zu erhalten.

Entwicklerfokus

Der Zweck bei Embedded-Linux-Lösungen ist, bestehende Softwarefunktionen zu erweitern und die Entwicklungsdauer zu verkürzen. Wird die eingesparte Zeit für andere Dinge als die eigentlich zu entwickelnde Software verwendet, fehlt der Entwicklerfokus. Um diesen aufzubauen müssen auch die Support-Tools jenseits des Compilers berücksichtigt werden, z. B. der Debugger, die IDE und andere Tools. Alle Embedded-Linux-Systeme und sogar einige proprietäre Echtzeit-Betriebssysteme wie QNX Neutrino oder PikeOS verlassen sich in irgendeiner Form auf den GNU-Compiler gcc [8]. Der GNU-Compiler ist kein schlechter Compiler, doch sein Partner-Debugger gdb erfordert etwas Konfigurationsarbeit und Wissen, damit er das Debugging entsprechend unterstützt. Natürlich könnte man Eclipse-basierte Konfigurationen und vorkonfigurierte Setups wie jene für kommerzielle Linux-Lösungen verwenden. Letztendlich verwenden viele Entwickler printf() Debugging [9], vor allem weil bessere Tools fehlen oder nicht genug Know-how oder zu wenig Zeit vorhanden ist, um die Debugging-Lösung entsprechend zu konfigurieren.

Genau hier geben sich RTOS-Anbieter etwas mehr Mühe, da deren Debugging-Lösungen üblicherweise vorkonfiguriert und mehr oder weniger sofort einsatzfähig sind. In einigen Fällen müssen Entwickler ihren Ansatz für die Softwareentwicklung überdenken, aber am Ende haben sie Zugriff auf gute Tools, was für den Entwicklerfokus und die Produktivität von hoher Bedeutung ist. Bild 2 zeigt den Multi-Debugger von Green Hills Software.

In Wirklichkeit ist die Anwendungsentwicklung für jedes Betriebssystem äußerst unkompliziert, wenn gängige APIs wie POSIX, Socket-APIs für die Anbindung und OpenGL oder andere Standardschnittstellen für fortschrittliche Grafik zum Einsatz kommen. Das bedeutet, dass das Schreiben von Anwendungscode nicht von der Wahl des RTOS abhängt, sondern mehr vom einfachen Zugang und richtigen Setup der Entwicklungstools.

Das gleiche gilt für die Entwicklung der Gerätetreiber. Ein Gerätetreiber ist einfach eine Anwendung, die bestimmte Randbedingungen einhalten muss, z. B. eine Hardware- und eine Betriebssystem-Schnittstelle. Der Unterschied zwischen Embedded Linux und jedem proprietären RTOS hängt natürlich von der Architektur des Betriebssystems ab. Am Ende zählen die richtigen Tools und Debugging-Techniken, mit denen man sich auf die Aufgabe konzentrieren und die Anwendung sowie Gerätetreiber entwickeln kann. Effiziente Debugger und Performance-Überwachungstools für die Anwendungs- und Treiberentwicklung erhöhen eindeutig die Effizienz der Entwickler.

Zusammenfassung

Obwohl Embedded Linux auf den ersten Blick sehr attraktiv ist – aufgrund seiner geringen Investitionskosten – müssen nicht nur die Beschaffungskosten für die Tools, das Betriebssystem und die Middleware-Komponenten mit einbezogen und analysiert werden. Hinzu kommen:

  • Time-to-Market: Nicht zu unterschätzen ist die Zeit, die zur Problemlösung für das Konfigurationsmanagement und die Softwarepaketabhängigkeiten mit einbezogen werden muss.
  • Entwicklereffizienz: Der Zugriff auf effiziente, einfach zu bedienende und vorkonfigurierte Tools macht Entwickler effizienter. Das Auffinden und Beheben von Fehlern geht einfacher vonstatten und am Ende steht letztlich bessere Softwarequalität.
  • Kosten: Auch die Entwicklungsdauer ist ein Kostenfaktor eines Projekts. Entwickler sollten deshalb in der Lage sein, sich auf die eigentliche Anwendungsentwicklung zu konzentrieren.

Am Ende können noch andere Anforderungen bestehen, die eine Wahl zwischen Embedded Linux und einem proprietären RTOS erübrigen oder die Entscheidung in einem sehr frühen Entwicklungsstadium erfordern, da einige Anforderungen zu einem späteren Zeitpunkt nicht mehr hinzugefügt werden können. Anforderungen, um funktionale Sicherheit zu erzielen, hohe Angriffssicherheit oder Echtzeit-Eigenschaften, sind wesentlich wichtiger für ein System, wenn es darauf ankommt.

Über den Autor:

Marcus Nissemark ist Field Applications Engineer bei Green Hills Software.