Um einen hohen Standard in der Softwarequalität zu erreichen, helfen unterschiedliche Modelle für die einzelnen Entwicklungsphasen in einem Projekt. Die üblichen Ansätze für den Ablauf in der Software-Entwicklung greifen für gewöhnlich auf das V-Modell und auf das Modell für agile Entwicklungsmethoden zurück.
Doch Software muss heute immer komplexere Abläufe steuern. Für die Software-Entwicklung ergeben sich daraus neue Herausforderungen, beispielsweise um die strengen Anforderungen von Safety und Security zu meistern.
Mit Multicore die Akku-Kapazität besser nutzen
Ein kurzer Blick zurück: Mit der Einführung von Notebooks und der mobilen Verfügbarkeit von Rechenleistung stieß man schnell an die Grenzen der erzielbaren Rechenleistung pro Watt, ausgedrückt in Millionen Instruktionen pro Sekunde (MIPS). Je größer die Rechenleistung, desto mehr wurde der Akku damit belastet. Der gleiche Prozess vollzog sich bei den Mobiltelefonen.
Die Rettung kam nicht nur in Gestalt riesiger Akkupacks (auch die gab es, wenn man sie tragen wollte), sondern mit der Entwicklung von Multicore-Prozessoren, die mehr Software-Pakete parallel abarbeiten konnten, ohne den Prozessor stärker zu belasten. Damit hielten die Akkus der mobilen Geräte länger und die Geräte wurden leistungsfähiger, ohne viel mehr Strom zu verbrauchen.
In der PC-Welt fand die Umstellung von Single- auf Multicore bereits Anfang des Jahrtausends statt. Für die ersten Multicore-Notebooks musste man damals viel Geld auf den Ladentisch legen. Und das, obwohl die verfügbare PC-Software – entwickelt für Singlecore-Architekturen – für diese Herausforderung noch nicht gerüstet war.
Ohne Multicore-Umgebungen sind neue Herausforderungen nicht zu bewältigen
An einem vergleichbaren Punkt stehen wir heute in der Embedded-Welt: Während der Großteil der Embedded-Software weiterhin für Singlecore-Mikrocontroller entwickelt wird, stehen die neuen Herausforderungen bereits vor der Tür: Fahrerassistenzsysteme, autonomes Fahren, intelligente Ladekonzepte für Batterien im Auto und für Solaranlagen, sichere mobile Kommunikation und vieles mehr brauchen effiziente Software.
Ohne Multicore-Umgebungen sind diese neuen Herausforderungen nicht zu bewältigen. Dabei kommen zwei Aspekte besonders zum Tragen, an denen große Verantwortung seitens der Hersteller hängt:
Safety: Die Systeme dürfen Anwender und ihre Umwelt nicht gefährden
Security: Applikationen und Daten sollen sicher verwahrt werden. Unzulässige und nicht gewünschte Zugriffe sollen in jedem Fall vermieden werden
Multicore, Safety und Security bilden zusammen eine komplexe Ausgangslage für die Embedded-Programmierung. Die Suche nach klaren Antworten im Embedded-Bereich fällt dabei nicht immer zufriedenstellend aus, denn es gibt noch viel unbekanntes Terrain, wo diese drei Größen zusammentreffen.
Was müssen wir also in unseren Software-Projekten beachten und durchführen, damit am Ende qualitativ hochwertige Produkte entstehen, die in einem Multicore-System unter Berücksichtigung von Safety und Security zuverlässig abgearbeitet werden können?
1. Die System-Anforderungen und die funktionale Spezifikation (System Requirements, functional Specification) müssen klar getrennte Anforderungspfade für diese unterschiedlichen Herausforderungen aufweisen.
2. Die Software-Architektur hat entsprechend der unterschiedlichen Anforderungspfade unterschiedliche beziehungsweise getrennte Module zu enthalten und deren logische Verbindungen aufzuzeigen. Sie muss also für die neuen komplexen Systeme Multicore, Safety und Security berücksichtigen und abbilden.
3. Der Software-Entwurf (sprich: die Programmierung) hat sich an die Regeln zu halten, die sich aus den Requirements ergeben. So müssen zum Beispiel modulare/ prozedurale/ objektorientierte Programmierschritte zum Einsatz kommen. In einigen Fällen wird durch Software-Spezifikationen die Art der Programmierung genau festgelegt – Software-Entwicklung nach AUTOSAR, wie zum Beispiel die API für Treiber nach dem AUTOSAR-Standard (MCAL-Treiber) und selbst entwickelte Complex-Treiber, die RTE-Erweiterungen für Multicore...
4. Der Software-Test (Unit-, System-Test) hat genau nach den Vorgaben der Requirements und der definierten Software-Architektur zu prüfen, ob alle definierten Qualitätsmerkmale (Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz Änderbarkeit, Übertragbarkeit) eingehalten werden, insbesondere im Zusammenhang mit den strikten Realzeitanforderungen in der Embedded-Welt.
Durch umfassende Software-Requirements typische Fehler vermeiden
In den Software-Anforderungen beschreiben Entwickler den Zweck und die Absicht eines Softwaresystems sowie dessen (externes) Verhalten. Welche Erwartungen haben Nutzer an das Softwareprodukt, und wie benutzerfreundlich ist es? Wie übersichtlich ist der Programmaufbau, wie strukturiert die Programmierung und wie verständlich die Dokumentation? Mithilfe dieser und anderer Fragen lassen sich viele Fehler vermeiden.
Etwa 50 Prozent der typischen Fehler in der Software eines Systems basieren auf fehlenden oder fehlerhaften Anforderungen (Requirements). Am Ende des „Requirements Engineering“ stehen die Entwicklung und Pflege eines aussagekräftigen System Requirements Specification Dokuments, das die folgenden Anforderungen ausführt:
Geschäftsanforderungen: Hier definieren das Management und das Marketing die Ziele des Produkts
Benutzeranforderungen: Anforderungen an das Softwaresystem aus der Sicht der Benutzer
Funktionale Anforderungen definieren das Verhalten des Softwaresystems so, dass die Benutzeranforderungen erfüllt werden können
Projektanforderungen: Was muss alles erfüllt sein, damit das Softwareprojekt die funktionalen Anforderungen erfolgreich umsetzen kann? Dieser Aspekt zielt auf das Lifecycle Management ab und beinhaltet die Dokumentation des Softwaresystems sowie notwendige rechtliche Anforderungen. Darunter fallen unter anderem Lizenzen der eingesetzten Softwaretools und Hardwarekomponenten, die Berücksichtigung von Urheber-/ Markenrechten und Patenten sowie Qualitätsanforderungen an den Service
Insbesondere bei den funktionalen Anforderungen kommen die Merkmale der Softwarequalität ins Spiel. An dieser Stelle lohnen sich umfangreiche Analysen zu den Aspekten des Einsatzes von Multicore, Safety und Security im Projekt.
Das Requirements Engineering betrachtet außerdem folgende Anforderungen an die Software umfänglich:
Standards und Normen, zum Beispiel ISO 26262 (ISO-Norm für sicherheitsrelevante elektrische / elektronische Systeme in KFZ) und IEC 61508 (Funktionale Sicherheit von elektrischen / elektronischen / programmierbaren Steuerungssystemen)
Welche Software-Module beziehungsweise Software-Stacks werden eingesetzt?
Welche Programmierschnittstellen werden verwendet?
Welche Qualitätssicherung soll zum Einsatz kommen?
Anlegen eines Regelwerks zur Programmentwicklung (Clean Code, Solid-Prinzip und ähnliches), statische Codeanalyse-Methoden, Unit-Tests, Systemtests
Sind alle diese Requirements erfüllt, analysiert man die verwendeten Datentypen/ -strukturen und Zugriffsmethoden (wie Pointer), die Lebensdauer, eingesetzte Speicher sowie konkurrierende Speicherzugriffe auf diese Anforderungen hin. Eine Prüfung der Integrität der eingesetzten Tools, Dateien und Bibliotheken (insbesondere Versionskontrolle wie CVS) gehört ebenso dazu.
Weiterhin stellt man sich die Frage: Welche Daten-Sicherungsmethoden und Fehler-Reaktionen sollen zum Einsatz kommen? Hier kommt insbesondere aus der Sicht der Safety die FMEA (Failure Mode and Effects Analysis) ins Spiel:
Werden alle Realzeit-Anforderungen erfüllt?
In diesem Kontext spielen insbesondere die Anforderungen an die System-Perfomance eine Rolle. Werden alle Aufgaben im erwarteten und auch tolerierbaren Zeitfenster erfüllt? Das gilt insbesondere dann, wenn es um Antwortzeiten von Tasks und Funktionen, Datendurchsatz und die rechtzeitige Verfügbarkeit von Ressourcen geht. Klare Anforderungen sind aus der Sicht des statischen und dynamischen Verhaltens zu definieren.
Wie steht es um das Thema System-Flexibilität?
Skalierbarkeit, Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit sowie der Einsatz im internationalen Umfeld des Systems stehen ebenfalls im Rampenlicht der Anforderungsanalyse.
Was ist beim Einsatz von Multicore im Kontext von Safety und Security speziell an zusätzlichen Anforderungen zu betrachten und spezifizieren?
Art und Zugriffsrechte bei der Verwendung Core-privater und globaler Speicher (RAM, ROM, Flash etc.)
In Multicore-Architekturen betrachtet man die Spezifikation der Steuerung und der Synchronisation paralleler Abarbeitung von Funktionen und Prozessen sowie die Spezifikation der Anforderungen für das Reset- und Boot-Verhalten (insbesondere bei Multicore).
Adäquater und individueller Schutz und Zuteilungsmechanismen von Speicher-Ressourcen mit genauem Blick auf Safety-relevante Funktionen, Prozesse und verwendete Peripherien aus Sicht der einzelnen zugreifenden Cores
Inter-Core-Kommunikation und -Synchronisation
Spezifikation von globalen Zeitquellen und Synchronisationsmechanismen (Time Synchronization Mechanism)
Anforderungen an Betriebssysteme wie Multicore RTOS (Real-Time Operating System), insbesondere bei Anwendung von verschiedenen Safety-Klassen und Security
Betrachtung und Spezifikation von dynamischen Abläufen, Funktionen und Prozessen
Für die Anwendung von Stacks und Bibliotheken müssen der Aufbau sowie die Anwendungs- und Testvorgaben spezifiziert werden, insbesondere mit Blick auf Multicore, Safety und Security
Spezifikation der Schutzmechanismen von Security-Funktionen, Prozessen und Abläufen (zum Beispiel Kommunikation), Ressourcen (zum Beispiel Speicher) durch Firewalls, kryptografische Sicherung von Speicherinhalten und der Datenkommunikation beim Einsatz von High-Security-Modulen (HSM), außerdem Spezifikation der benötigten beziehungsweise geforderten Kryptografie-Methoden
Spezifikation des Kommunikationsmanagements – wer darf mit wem und wer muss mit wem kommunizieren? zum Beispiel beim Einsatz verschiedener Bussysteme: transparente Kommunikationsabläufe und Synchronisationsmechanismen (wie Spezifikation von Gateways)
Definition der Anforderungen für dynamische Methoden bei Verwendung von Multicore, Safety und Security
Für die Fehlererkennung und Fehlerbehandlung, insbesondere im Falle der Safety-Anforderungen, muss eine Spezifikation der Methoden, des Umfangs und der Abläufe erfolgen.
Spezifikation von Diagnose-Methoden und Diagnose-Interfaces
Spezifikation der statischen und dynamischen Testmethoden, insbesondere Datalogging-, Debugging- und Trace-Methoden unter Berücksichtigung von Multicore, Safety und Security
Spezifikation der zu verwendenden Art der Symboldefinition im Hinblick auf Multicore
Spezifikation der Software-Updatemethoden und deren Absicherungsmechanismen, aus statischer Sicht und bei Bedarf auch für dynamische Software-Updates
Spezifikation der Dokumentationsvorgaben
Fazit
Beim Einsatz von Multicore-Systemen wird eine umfassende und detaillierte Anforderungsanalyse mit Safety- und Security-Anforderungen für die Systemsicherheit zum Schlüssel des Projekterfolgs.
