In der Vergangenheit war die Software ein Beiwerk, das die wenigen Funktionen eines Aktors oder Sensors angesteuert und die notwendige Kommunikation aufbereitet hat. Im Zeitalter von ethernetbasierten Realtime-Protokollen, funktional immer stärkeren Prozessoren und stetig wachsenden Anforderungen stellten sich die KMUs diesen Herausforderungen mit zusätzlichen Software-Entwicklern. Einzelne Werkzeuge wurden angeschafft, aber da es keinen definierten und eingehaltenen Software-Entwicklungsprozess gab, waren Freigaben oft schwer planbar und die Software-Fehler im Feld häuften sich. Änderungen wurden oft auf Zuruf implementiert und waren oft nur durch den Software-Entwickler selbst nachvollziehbar.
(Software-)Entwicklungsprozess
Es gibt Prozessmodelle wie z.B. das V-Modell, welches sich in Phasen unterteilt. Sind exakte Vorgaben einzuhalten und diese auch nach Vorgabe zu verifizieren, so ist dies das Prozessmodell der Wahl. Es ist das Standard-Prozessmodell für funktional sichere Entwicklungen, für anderweitige externe Auditierungen und Zertifizierungen und auch für öffentliche Auftraggeber. Dieses Prozessmodell wird meist mit iterativen Modellen kombiniert. Ein solch plangetriebener Prozess zeichnet sich dadurch aus, dass alle Aktivitäten im Voraus geplant werden und der Projektfortschritt gegen diesen Plan gemessen wird. Im Gegensatz dazu stehen agile (evolutionäre) Prozesse, die immer dann von Vorteil sind, wenn die Kundenanforderungen nicht sehr präzise sind oder Kundenanforderungen sich während der Projektlaufzeit ändern. Benutzeroberflächen sind ein Paradebeispiel dafür, das zugehörige Requirement „ease of use“ ist nicht sehr präzise und wird meist mehrfach neu interpretiert. Agile Ansätze z.B. aus Scrum helfen jedem Software-Entwicklungsprojekt und sind natürlich auch in Projekten mit funktionaler Sicherheit nach IEC61508-3 dienlich. Dies soll durch einige Analogien aufgezeigt werden:
- Motivation des Teams durch viel Kommunikation analog „daily scrum“
- Team als Gruppe von projekt-fremden Zugriffen abschotten
- Starker und qualifizierter Produktmanager analog „product owner“
- Review-Phasen während des Projekts analog „sprint retrospective“
- Metriken, um Projektfortschritt zu messen analog „release/sprint burndown“
- Priorisierung aller Anforderungen analog „product backlog“
- Iterative Entwicklung für die Messung des Projektfortschritts und der Motivation
- Daily (nightly) build der kompletten Software, „continuous integration“ um:
- Täglich eine lauffähige Version zu generieren
- Kontrolle über „header“ und build Mechanismen zu behalten
- Schnelle Reviews am „lebenden Objekt“ durchführen zu können
- Aktive Interaktion mit dem Kunden durch frühe „Prototypen“
Es gibt keine richtigen oder falschen Software-Entwicklungsprozesse, es gibt den richtigen Prozess für das jeweilige Projekt. Im (Software-) Entwicklungsprozess wird unterteilt in die Leistungsmanagement-Prozesse (Product Management, Project Management und Quality Management), die Leistungserbringungs-Prozesse (der eigentliche Kernprozess) und die Supportprozesse und Methoden. Eine wichtige Komponente hier ist der Change Management Prozess, also die Art und Weise wie Änderungen der Anforderungen in den Gesamtprozess einfliessen. Zentrales Element ist auch hier die Rückverfolgbarkeit und Dokumentation.
Verwaltung der Anforderungen
Das Requirement Tracing Tool erlaubt es strukturiert Anforderungen niederzulegen, zu gruppieren, zu verknüpfen. Meist beinhaltet es auch ein Fehler- und Anomalieverwaltungs- und Verfolgungsmodul und ein Modul zur Dokumentation und Verfolgung von Tests. Über Verknüpfungen kann verfolgt werden, ob jede Anforderung abgearbeitet, dokumentiert und getestet ist. Dieses System ist die zentrale Drehscheibe des Projektes. Als Beispiele für ein Requirement Tracing Tool kann Polarion von Siemens, Doors von IBM oder auch Enterprise Architect von Sparx Systems genannt werden, in Summe gibt es mehr als 30 namhafte Hersteller von solchen Systemen und es ist abzuklären welche Systemeigenschaften für das jeweilige Unternehmen am wichtigsten / am sinnvollsten sind.
Softwareversionskontrolle
Typischerweise werden neue Funktionalitäten in eine Folgeversion der aktuellen Softwareversion implementiert. Gleichzeitig gilt es Fehlerbehebungen und Korrekturen in die aktuelle Version einzupflegen. Es besteht also die Herausforderung Korrekturen, die in der aktuellen Version eingebracht wurden in die nächste Version mit zu übernehmen und gleichzeitig zu verhindern, dass zusätzliche Funktionen einer Folgeversion in die aktuelle Version übernommen werden. Es sind mehrere unterschiedliche Versionen parallel in Bearbeitung und müssen voneinander scharf getrennt werden. Die zweite Herausforderung ist das Zusammenarbeiten eines Teams an einer Software. Ein Entwickler kann für eine gesamte Funktionalität, für eine gesamte Objektklasse verantwortlich sein oder auch nur für eine bestimmte Funktion, für eine bestimmte Methode. In dieser Kette ist der Compiler, Linker und Debugger eine wichtige Komponente, die im Regelfall von einer Auditierungsstelle für Functional Safety Entwicklung zertifiziert und freigegeben wird. So gibt es prozessorspezifische Bibliotheken, Einstellungen etc., die zum einen von Prozessorherstellern wie ARM, Renesas, zum anderen von spezifischen Workbench Herstellern wie IAR, Keil angeboten werden. Ein TÜV-Zertifikat und der zugehörige Bericht sollten bestätigen, dass der spezifische Compiler bzw. die spezifische Workbench die Anforderungen für Entwicklungswerkzeuge der Klasse T3 nach IEC61508-3 erfüllt. Dies ermöglicht Kunden, den Compiler bzw. die Workbench für sicherheitsrelevante Entwicklung bis zu SIL3 (IEC61508) oder ASILD (ISO26262) ohne weitere Qualifizierungsmaßnahmen zu verwenden, solange die im Qualification Kit dokumentierten Empfehlungen und Bedingungen befolgt werden.
