Integration der ISO mit einer qualifizierten ALM-Lösung

Transkript

1 Polarion Software Whitepaper Integration der ISO mit einer qualifizierten ALM-Lösung Zusammenfassung Die Komplexität in der Automobilindustrie wächst stetig. Dieses Wachstum führt zu immer größeren Anforderungen an die Sicherheit der beteiligten Systeme, die auch bei großem Variantenreichtum gewährleistet sein muss. Um dies sicher zu stellen, wurde im November 2011 die ISO Norm 26262, für Funktionale Sicherheit elektronischer und funktionaler Komponenten in Kraftfahrzeugen eingeführt. Die ISO empfiehlt dabei ausdrücklich den Einsatz spezieller Software, um beispielsweise Sicherheitsanforderungen und die verpflichtenden Abhängigkeiten während des Entwicklungsprozesses zu erstellen und zu verwalten. Diese Informationsbroschüre zeigt, wie eine bereits durch den TÜV Nord qualifizierte ALM-Lösung bei der Analyse und Verwaltung von Risiken und Gefahren unterstützt. Einleitung Das zentrale Thema dieses Industriebeitrages ist die ISO Es werden die benötigten Artefakte, sowie die nötigen Prozesse und Abhängigkeiten angesprochen und erläutert. Zu Demonstrationszwecken wird Polarion ALM eingesetzt und vorgestellt. Das Tool wurde in allen Bereichen vom TÜV Nord für die Entwicklung nach ISO 26262, bis zu der Sicherheitsklasse ASIL D qualifiziert. Abbildung 1. TÜV Siegel Diese Broschüre beinhaltet einen Abschnitt über die korrekte Einstufung in die Klassifikation ASIL nach der vorgegebenen Tabelle: Copyright 2015 Polarion Software - Die Vervielfältigung und Weitergabe dieses Dokuments in unveränderter Form ist gestattet. Abbildung 2. ASIL Klassifikation

2 Die Entwicklung des Automobils Kraftfahrzeuge haben bis zum heutigen Tage eine lange Historie. Zu Zeiten des ersten Autos, das den Namen im heutigen Sinn verdient, dem Benz-Patent-Motorwagen Nummer 1 des Erfinders Carl Benz, waren Fahrzeuge einfache Wagen, die von simplen 4-Takt-Motoren angetrieben, eher an pferdlose Kutschen erinnerten. Im Laufe der Jahrzehnte wurden die verwendeten Mechaniken immer ausgefeilter, was nur durch neue und verfeinerte Entwicklungen, hauptsächlich in den Bereichen der Konstruktion und Fertigung möglich wurde. In den 1960ern folgte der erste Einsatz von elektronisch geregelten Systemen, was sich schließlich bis heute zu fast vollständig softwaregesteuerten Fahrzeugen weiterentwickelt hat. Je komplexer ein System wird, desto schwieriger ist es, den Überblick über alle Anforderungen an das System und Abhängigkeiten zwischen den einzelnen Bereichen zu überblicken. Ohne ausgearbeitete Entwicklungsprozesse wären Weiterentwicklungen durch extreme Kosten und Aufwände schon lange nicht mehr möglich. Während die Entwicklung von rein mechanischen Systemen oder Komponenten, wie dem ersten Automobil, bis heute weitestgehend ausgereift ist, und ab einem bestimmten Punkt automatisiert vonstatten geht, ist diese Entwicklung in der Software noch nicht an einem finalen Punkt angekommen. Bis vor wenigen Jahren wurden Softwareprojekte, seien es reine Anwendungen wie etwa für PC-Systeme oder Programme für Embedded Systeme, in den seltensten Fällen erfolgreich abgeschlossen. Fehlkalkulationen der Aufwände, resultierend aus mangelnder Übersicht der Abhängigkeiten der Systeme und Komponenten untereinander, waren oft der Grund. Auch heute noch sind Software-Architekturen extrem schwer zu verwalten und weiterzuentwickeln. Trotz stetig steigender Zahl der Lines of Code, die bei modernen Fahrzeugen oft in die mehrere Millionen gehen, muss sichergestellt werden, dass Fehlfunktionen weitestgehend ausgeschlossen sind. Sicherheitskritische Probleme, zum Beispiel im Code eines Steuergerätes, in entscheidenden Relais oder rein mechanischen Komponenten müssen im Vorfeld bedacht und verhindert werden. Bis vor wenigen Jahren waren Automobilhersteller komplett selbst dafür verantwortlich, für die Sicherheit Ihrer Fahrzeuge zu sorgen. Sie mussten selbst die besten Wege finden, um eben dieses Ziel zu erreichen. Seit Ende des Jahres 2011 wurde zur Unterstützung der Automobilindustrie sowie zur Garantie der Sicherheit aller Insassen eines Kraftfahrzeugs, die ISO Norm für Funktionale Sicherheit eingeführt. The radio and navigation system in the current S-class Mercedes-Benz requires over 20 million lines of code alone, and that car contains nearly as many ECUs as the new Airbus A380 (excluding the plane s in-flight entertainment system). Software in cars is only going to grow in both amount and complexity. Late last year, the business research firm Frost & Sullivan estimated that cars will require 200 million to 300 million lines of software code in the near future (WEB5) Alfred Katzenbach, former Director of Information Technology Management at Daimler AG Die ISO Jeder, der sich häufig mit Software-Lösungen auseinandersetzt, weiß, dass keine Software gänzlich ohne Fehler ist. Das trifft natürlich auch auf den Automobilbereich zu. Dadurch dass unsere Autos heutzutage immer umfassender durch Software gesteuert werden, steigt das Risiko für nicht mechanische Defekte immer stärker. Ist ein sicherheitsrelevantes Steuergerät von einem Fehler oder Ausfall betroffen, kann dies im schlimmsten Fall schwere Verletzungen oder den Tod der Fahrzeuginsassen oder anderer Verkehrsteilnehmer verursachen. Um solchen verheerenden Fehlfunktionen entgegenzuwirken, wurde in der Vergangenheit die Anwendung der IEC empfohlen. Diese Norm gibt ein gewisses Set an Entwicklungsprozessen vor, die allgemeingültig für sämtliche Bereiche sind, in denen die 2

3 Sicherheit von Personen gefährdet ist. Allgemeingültig deshalb, weil sie übergreifend für Produkte unterschiedlichster Branchen gilt. So können vom Verschlussmechanismus der Türen eines Atomkraftwerks über Insulinpumpen bis hin zu Kampfflugzeugen alle Produkte mit Hilfe der IEC mit Hinblick auf funktionale Sicherheit entwickelt werden. Der Nachteil der Norm liegt ebenfalls in genau dieser allgemeinen Gültigkeit. Der Detailgrad ist für die einzelnen Industriezweige nicht ausreichend, da nicht spezifisch genug auf spezielle Charakteristika der einzelnen Branchen eingegangen wird. Um Automobilherstellern, OEMs und Prüfinstituten bessere Hilfen geben zu können, wurde die ISO verfasst. Sie ist nach einhelligem Verständnis der deutschen Experten zur Funktionalen Sicherheit als Beitrag zum Stand der Wissenschaft und Technik in Bezug auf die Funktionale Sicherheit von Straßenfahrzeugen anzusehen. Was umfasst diese Norm? In zehn Kapiteln werden alle Prozesse beschrieben, die für die sicherheitskritische Entwicklung zu befolgen sind. Sie umfassen administrative Tätigkeiten, genau wie Prozesse der reinen Entwicklung, über Produktion, bis hin zum End of Life und der eventuellen Außerbetriebnahme des zu entwickelnden Produkts. Zusätzlich dazu werden alle nötigen Aktivitäten sowie geforderte Work Products beschrieben, um eine passende Nachweisbarkeit zu schaffen. Die Strenge, mit der die Prozesse eingehalten und Erzeugnisse produziert werden müssen, richtet sich dabei nach dem Automotive Safety Integrity Level, kurz ASIL. Es muss für jede umzusetzende Anforderung definiert werden und reicht von ASIL-A (sicherheits-unkritisch), bis ASIL-D (lebensbedrohliches Risiko). Application Lifecycle Management Begriffsklärung Die in der ISO beschriebenen Schritte zur Gewährleistung Funktionaler Sicherheit können in Bezug auf reine Softwareentwicklung auf eine Bezeichnung zusammengefasst werden. In der heutigen Softwareentwicklung fällt immer häufiger der Begriff ALM. Er steht für Application Lifecycle Management und beschreibt als Überbegriff den kompletten Software Lebenszyklus. Im Gegensatz dazu beschreibt die Abkürzung PLM, für Product Lifecycle Management, die Entwicklungsansätze eher von einer klassisch hardwarenahen Perspektive. Diese soll hier aber nicht weiter betrachtet werden. Abbildung 3. Application Lifecycle Management. Phases & Actions Prozesse Der Ablauf eines neuen Software-Projekts startet dabei mit dem Erfassen der Anforderungen sämtlicher Stakeholder. Sind diese vollständig und korrekt erfasst, geht es darum nach Dringlichkeit und anderen Attributen zu kategorisieren. Auf Basis dieser Attribute können anschließend Aussagen über eine Realisierbarkeit und zur weiteren Planung, entweder einzelner Anforderungen oder einer kompletten Gruppe von Anforderung, beispielsweise aus einem Pflichtenheft, getroffen werden. Ist das erledigt, ist die erste Phase beendet. 3

4 Anschließend folgt die Konzeptionsphase, in der die konkrete Umsetzung, das Design und die Implementierung geplant und durchgeführt werden. Erfahrungsgemäß kommt es während dieser Phase häufig zu Änderungen der initialen Anforderungen. Diese Änderungen müssen durch ein integriertes Change Management in die aktive Entwicklung einfließen, so dass möglichst zeitnah reagiert und die aktuelle Release-Planung angepasst wird. Ein besonders schnelles Reagieren ist dabei durch agile Entwicklungskonzepte wie SCRUM möglich. Im Hardwareumfeld ist die Realisierbarkeit agiler Prozesse technisch bedingt um einiges schwieriger als bei Softwareprojekten. Allgemein kann man sagen, je schneller die Reaktion auf eine Änderung, desto geringer die Kostensteigerung für das gesamte Projekt. Ist die Software schließlich ausgeliefert oder im Einsatz, ist der Lebenszyklus oft noch nicht zu Ende. Nach der Auslieferung wird in den meisten Fällen das Feedback der Anwender und Kunden gesammelt, so dass die gefundenen Bugs und Änderungswünsche erneut die vorher beschriebenen Phasen durchlaufen. Sie werden dann entweder auf die nächsten Service Releases oder Versionen geplant, umgesetzt oder abgelehnt. Tool-Qualifizierung Nachdem nun der grundsätzliche Daseinszweck der ISO sowie die Bedeutung der Abkürzung ALM geklärt sind, kann man einen speziellen Teil der Norm betrachten. Aus den bisherigen Erklärungen lässt sich entnehmen, dass die Anforderungen an die Automobilbranche, was die Einhaltung und Durchführung der geforderten Prozesse angeht, durch die Norm noch umfangreicher sind als durch die ältere IEC Eine sinnvolle Toolunterstützung wird, je nach Umfang der Entwicklungsaufwände, für eine neue Komponente unerlässlich. Dabei spielt es keine Rolle, welcher Art das unterstützende Werkzeug ist. Kommerzielle, freie oder selbst erstellte Software kann verwendet werden. Unter Teil 8, Kapitel 11 der ISO Confidence in the use of software tools werden alle Bedingungen für den Einsatz derartiger Tools definiert. Je nach Sicherheitsstufe der zu entwickelten Komponenten müssen die Werkzeuge unterschiedliche Qualitätsanforderungen erfüllen. So ist sichergestellt, dass nur qualitativ hochwertige Werkzeuge für die Entwicklung sicherheitskritischer Komponenten mit einem ASIL Level von D zum Einsatz kommen und nicht etwa Leben durch verfälschte Daten gefährden. Qualifizierung von Polarion ALM Anfang des Jahres 2012 begannen in Zusammenarbeit mit dem TÜV Nord und Polarion Software die ersten Schritte zu einer geplanten ISO Zertifizierung. Ziel des ganzen war es, als erster Toolanbieter eine komplette Zertifizierung für die werkzeugunterstützte Entwicklung von Software im Automobilbereich mit allen Anforderungen der Funktionalen Sicherheit bieten zu können. Etwa ein Jahr zuvor hatte schon das kanadische Unternehmen MKS (heute PTC) erfolgreich den Configuration Management Part des Tools Integrity für die normgerechte Entwicklung qualifiziert. Für die übrigen ALM-Teile gab es bis dahin allerdings noch keine Lösung, die Kunden direkt benutzen konnten. Ohne eine bestandene Prüfung durch eine unabhängige Stelle, beispielsweise durch den TÜV Nord, obliegt die Verantwortung der Qualifizierung den einsetzenden Unternehmen. Damit verbunden ist ein nicht unerheblicher Aufwand an Zeit und Kosten, der insbesondere bei kleinen, aber auch bei mittelständischen Unternehmen zu Verzögerungen aktiver Projekte führt. Der Ablauf Wichtig zu wissen ist, dass die Zertifizierung faktisch das Ergebnis einer erfolgreichen Qualifizierung, das heißt einer eingehenden Prüfung des Tools ist. Diese Prüfung bescheinigt bei erfolgreichem Abschluss die Konformität an die geprüften Normen, und dass alle von der Normen geforderten und definierten Arbeitsweisen abgebildet werden können. Wird dies durch eine staatlich anerkannte Stelle wie dem TÜV Nord durchgeführt, bringt es gleichzeitig Absicherungen bei der Haftung bei evtl. auftretenden Sicherheitsmängeln. 4

5 Am Anfang der Qualifizierung steht dabei die Definition des konkreten Rahmens der Zusammenarbeit. Im Falle Polarion war der Umfang beschrieben durch: IEC Teil 1: Allgemeine Anforderungen für Funktionale Sicherheit von elektrischen/elektronischen programmierbaren sicherheitsrelevanten Systemen IEC Teil 3: Software-Anforderungen für Funktionale Sicherheit von elektrischen/elektronischen programmierbaren sicherheitsrelevanten Systemen ISO Teil 3: Funktionale Sicherheit bei der Produktentwicklung für Straßenfahrzeuge auf Software-Ebene ISO Teil 8: Funktionale Sicherheit bei unterstützenden Prozessen der Entwicklung für Straßenfahrzeuge Nach Definition des Rahmens müssen seitens des Herstellers drei Arbeitsprodukte erstellt werden. Als erstes kommt der Software Tool Specification Plan (STQP). Dieser beinhaltet generelle Informationen des zu qualifizierenden Tools, wie beispielsweise den Namen, den Anwendungsbereich und qualitätssichernde Maßnahmen während der Entwicklung. Zusätzlich enthalten ist bereits an dieser Stelle eine Liste aller für den definierten Rahmen benötigten Anwendungsfälle, die Techniken und Maßnahmen der Softwarenentwicklung, einschließlich Maßnahmen zur Fehlerbehebung und Diagnose. Als letzter Bestandteil ist das beanspruchte, bzw. angestrebte Konfidenz-Niveau für die zielsetzenden Normen anzugeben. Der zweite Teil der benötigten Unterlagen sollte standardmäßig zur Verfügung stehen. Die Tooldokumentation wird auch durch die unabhängige Stelle unter anderem auf folgende Punkte geprüft: Die Softwarearchitektur Operationale Umgebung und Maßnahmen Installations- und Betriebsanweisungen bzw. Nutzerschulungen in Bezug auf Vollständigkeit Bekannte Einschränkungen und Probleme Als letztes muss vom Hersteller eine Software Tool Classification Analysis (STCA) durchgeführt werden. Diese kann auch Teil des oben erwähnten STQP sein. Sind alle Informationen verfügbar, wird vom Qualifizierer ein Software Tool Qualification Report erstellt, in dem genau beschrieben wird, wie die Qualifikation durchgeführt wurde und gegebenenfalls, welche Einschränkungen währenddessen festgestellt wurden. Die Qualifikation Im Rahmen der Qualifikation wurde der komplette ALM-Prozess behandelt und durchgespielt. Dabei wurden nicht nur die schon am Anfang angesprochenen Bereiche wie Requirements Management, Test Management oder Change Management behandelt, sondern auch sehr toolspezifische Anwendungsfälle wie das Anlegen eines neuen Projekts, oder das Erstellen so genannter Work Items - der digitalen Repräsentation bspw. einer Anforderung, eines Testfalls oder einer Aufgabe. Mit diesen Grundfunktionen und einem für den Anwendungsfall passend konfigurierten Polarion Server wurden nun Tests zur Software-Spezifizierung, zum Design der Software- Architektur sowie des Software-Unit-Designs und des Software-Tests durchgeführt. 5

6 Das Resultat Als Ergebnis der knapp 10 monatigen Zusammenarbeit zwischen TÜV Nord und Polarion Software kann letzten Endes festgestellt werden, dass Polarion ALM für die Entwicklung sicherheitskritischer Systeme oder für die Entwicklung mit sicherheitsangepassten Lebenszyklen verwendet werden kann. Als Werkzeug gewährleistet es die benötigten Sicherheitsstufen bis zu einem ASIL D für ISO 26262, bzw SIL 3 für IEC Die Bedingungen für diese Klassifizierung sind, dass mit einer Standard-Installation gearbeitet wird, keine Änderungen am zugrundeliegenden Subversion Repository durch Dritthersteller-Tools vorgenommen werden und dass nur von Polarion offiziell unterstützte Webbrowser verwendet werden. Durch Erreichen einer derartigen Einstufung, erwirbt sich der Hersteller das Recht das passende Zertifikat (siehe Abbildung 1) zu nutzen. Über Polarion Software Polarion Software ist ein führender Anbieter einer durchgängigen und zu 100% Browser-basierten Plattform für Anforderungs-, Test- und Application-Lifecycle-Management (ALM). Polarion wird von globalen Unternehmen in einer Vielzahl von Branchen eingesetzt, wie zum Beispiel im Automobilbau, in der Medizintechnik und in der Luft- und Raumfahrt. Kunden erzielen mit Polarion die für die Herstellung Ihrer Produkte nötige Agilität, Traceability und Compliance. Käufer der mit Polarion entwickelten Produkte erwarten eine herausragende Qualität und Sicherheit. Mehr als 2,5 Millionen Anwender weltweit vertrauen deswegen auf Polarion, um die Zusammenarbeit in ihren Unternehmen voranzutreiben, ALM und Product Lifecycle Management (PLM) zu verküpfen und um ihre hochwertigen Produkte auf den Markt zu bringen. Weitere Informationen unter: Europe, Middle-East, Africa: Polarion Software GmbH Americas & Asia-Pacific: Polarion Software, Inc. Kesselstraße Stuttgart, GERMANY 1001 Marina Village Parkway, Suite 403, Alameda, CA 94501, USA Tel Tel Fax Fax info@polarion.com - info@polarion.com