Funktionale Sicherheit für KMUs - Teil 3/8
Requirement bis Test Case
In den ersten beiden Teilen dieser Serie wurden die einzelnen Normen und deren Zusammenhänge behandelt sowie die frühen Phasen des Projektes und die Entstehung der SRS genauer betrachtet. Teil 3 diskutiert den Softwareentwicklungsprozess und die Product-Lifecycle-Management-Umgebung, die Dokumentations- und Entwicklungsumgebung, in der nachvollziehbar und auditierbar aus Requirements ein nach Regeln der IEC61508 zertifizierbares Produkt entstehen soll. Was beinhaltet solch eine Umgebung? Welche Werkzeuge gibt es? Welche Integration zwischen den Werkzeugen gibt es?
Bild: Mesco Systems GmbH / Dr. Johann PohanyIn der Vergangenheit war die Software ein Beiwerk, das die wenigen Funktionen eines Aktors oder Sensors angesteuert und die notwendige Kommunikation aufbereitet hat.
Bild: Mesco Systems GmbH / Dr. Johann Pohany
(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.
Bild: Mesco Systems GmbH / Dr. Johann PohanyVerwaltung 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.
Bild: Mesco Systems GmbH / Dr. Johann PohanySoftwareversionskontrolle
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.
Funktionale Sicherheit
Der Standard für funktionale Sicherheit, die IEC61508 empfiehlt, die Programmiersprache C nur für den niedrigsten Safety Integrity Level SIL1. Für SIL3 und SIL4 ist C nur mit geeigneten Codierungs-Standards und Analysetools verwendbar. Eine wichtige Komponente hierfür ist der Programmierstandard MISRA-C. MISRA-C 2004 umfasst etwa 140 Regeln, die in 21 Gruppen unterteilt sind, darunter Initialisierung, Datentypen, Strukturen oder Präprozessor. Ziel von MISRA-C ist es, die erwähnten Schwachstellen des C-Standards zu überwinden und potentielle Risiken bei der Programmierung weitgehend zu verhindern. Statische Code Analyse Tools wie PC-lint haben bereits Support für MISRA-C und, integriert in die ToolChain, helfen die Herausforderungen der Programmiersprache C für sicherheitsrelevante Applikationen zu meistern. Das effektive Management von Software Artefakten, insbesondere Quellcode wird durch solch einen Version Control Server übernommen. Weitere Begrifflichkeiten sind SC(C)M-Source Code (Configuration) Management, RCS - Revision Control System, VCS - Version Control System. Solche Systeme sind seit über 40 Jahren auf unterschiedlichen Plattformen am Markt. Eines der bekanntesten Systeme aus dem Windows Umfeld ist sicherlich Microsoft SourceSafe, aus dem open source Umfeld ist CVS ein heute häufig verwendetes Werkzeug, eine Ableitung davon ist Apache Subversion (SVN) welches als Alternative zu CVS entwickelt wurde um einige Nachteile von CVS zu eliminieren. Eine völlig andersartige Variante ist Git welches aus dem Umfeld von Linus Torvalds und Linux entwickelt wurde. Der sicherlich größte Vorteil von Git ist die Geschwindigkeit bei verteilten Standorten mit niedrigen Netzwerkbandbreiten zwischen den Standorten. Allerdings ist die Lernkurve für Entwickler aus dem "klassischen" CVS Umfeld deutlich größer und der Support für Windows Server ist ziemlich limitiert. Ein Derivat davon ist Mercurial welches einen besseren Windows Server Support bietet. Auch hier gibt es keinen Königsweg und es ist abhängig von den Entwicklern, den Administratoren und Projektleitern, die die Systeme benutzen werden.
Bild: Mesco Systems GmbH / Dr. Johann PohanyContinuous Integration Server
Der Continous Integration Server stellt das zentrale Werkzeug, in der die Software Integriert, compiliert und dem Build- und Test-Server komplette Versionen zur Verfügung gestellt wird. Häufig werden auf Basis des Integrations Servers statistische Quellcode Analyse Werkzeuge eingesetzt, um die Qualität der Software in einem sehr frühen Stadium beeinflussen zu können. Prominete Vertreter dieser Gattung sind Jenkins und Phyton, beide Werkzeuge haben die Möglichkeit der Integration in die oben genannten Versionskontrollsysteme. Aufgrund der Plug-in-Philosophie sind die Möglichkeiten dieser Werkzeuge sehr mächtig. Angefangen von simplen Untersuchungen, ob alle verwendeten variablen Objekte initialisiert sind bis hin zu statistischen Aussagen über Code-Coverage gibt es fast alles, was das Software-Entwicklerherz höher schlagen lässt. Der Build- und Test-Server hingegen versorgt das Validierungs- und Verifikationsteam mit den aktuell freigegebenen Testversionen und synchronisiert die Versionen für Hardware in the loop (HIL)"-Tests und "Device under Test (DUL)"-Tests.
Fazit
Die Nachvollziehbarkeit von der Anforderung bis zum durchgeführten Test und die überprüfbaren statistischen Aussagen ergeben sich durch die Integration der beschriebenen Werkzeuge. Die nachfolgende Graphik soll dies veranschaulichen. Die Toolchain ist eine Kombination der Prozesse mit den Werkzeugen. Allein die Prozesse können den Nachweis und Rückverfolgbarkeit nur schwerlich und mit erheblichem Aufwand generieren. Die Werkzeuge - die Toolchain - ohne Integration und definierten Prozessen kann dies auch nicht leisten. Eine intelligente Integration der einzelnen Werkzeuge kombiniert mit intelligenten Prozessen, die jeweils auf den benötigten Safety Integrity Level (von Standard Entwicklung ohne SIL Anforderung bis zur SIL3 Anforderung) adaptiert werden, ist das Mittel der Wahl. Der Aufbau der Prozesswelt und der Toolchain kann nicht in einem Big Bang erfolgen, sondern bedarf einer Zielvision und dem kontinuierlichen Umsetzen einzelner Schritte bis nach mehreren Iterationsstufen, die in Summe Jahre dauern können, das Ziel einer integrierten Prozess- und Werkzeugwelt erreicht ist.
(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.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
MESCO
Dieser Artikel erschien in SPS-MAGAZIN 1+2 2019 - 08.02.19.Für weitere Artikel besuchen Sie www.sps-magazin.de
