Autor: Dr. Ludger Janauschek, Airbus Defence and Space GmbH Bei der Software-Entwicklung eingebetteter Systeme in der Luftfahrt sind verschiedenste Standards zu ber\u00fccksichtigen. Einer der bekanntesten zivilen Standards ist DO-178C. Der vollst\u00e4ndige Entwicklungsprozess muss die Vorgabe der Standards erf\u00fcllen, dies beinhaltet insbesondere Tools und Methoden aus dem Bereich SDE. Tools, Hardware und Methoden im Bereich SDE befinden sich aktuell und permanent in Weiterentwicklung. Um eine moderne und effiziente SW-Entwicklung zu erreichen, sollte man hier akutell bleiben. Gerade hierdurch ergibt sich ein Konflikt mit dem Erhalt der Zertifizierung, da diese meist auf den Einsatz von bew\u00e4hrten und abgenommenen Tools und Methoden setzt und damit den Zustand der SDE „einfriert“. Projektlaufzeiten von mehr als 20 Jahren erschweren diese Situation. Dieser Vortrag wird die Ursachen dieses Spagats zwischen Aktualit\u00e4t und eingefrorenem Zustand sowie auch Methoden – teils Chancen – zur Bew\u00e4ltigung darstellen, aber auch Grenzen aufzeigen. Die Nutzungsdauer von Flugzeugmustern \u00fcberschreitet regelm\u00e4\u00dfig 40 Jahre. Einige Avionik-Systeme sind in diesen Flugzeugmustern \u00fcber die gesamte Nutzungsdauer in Betrieb; die meisten f\u00fcr mindestens f\u00fcr 20 Jahre. Zus\u00e4tzlich zur Nutzungsdauer muss noch die Planungs- und Entwicklungsphase ber\u00fccksichtigt werden. Hier werden die Entscheidungen f\u00fcr die Technologie (Target-HW, Target-SW, Host-HW, Host-SW\/Tools) getroffen und festgelegt.<\/p>\n \u00dcber die gesamte Nutzungsdauer hinweg erfolgen jedoch gerade bei der Avionik-SW Anpassungen an die jeweiligen aktuellen Anforderungen. Hierf\u00fcr ist eine funktionierende SDE sicherzustellen. Um den technologischen Fortschritt in der Software-Entwicklung nutzen zu k\u00f6nnen, ist eine moderne SDE erstrebenswert.<\/p>\n Bei diesen langen Laufzeiten ist das Thema Obsoleszenz ein st\u00e4ndiger Risikofaktor. Obsoleszenz trifft hier sowohl die Target-HW sowie auch die Host-HW und Host-SW. Kernthema dieses Vortrags ist die SDE, wodurch im Folgenden der Schwerpunkt auf den Host-Aspekten liegt. Die SDE umfasst hier: Host-HW, Host-Betriebssystem mit detaillierter Angabe des Patch-Levels, Cross-Compiler f\u00fcr Target-HW inklusive Debugger, Compiler f\u00fcr Host-Simulation inklusive Debugger, IDE und\/oder Editoren, Versionsverwaltungssystem, Testtools.<\/p>\n Rahmenbedingung f\u00fcr die HW-\/SW- und Tool-Auswahl werden durch Luftfahrtstandards gesetzt. In der Luftfahrt werden Zertifizierungen f\u00fcr das Flugzeugmuster nach dem jeweiligen Standard der Musterzulassung weiter fortgef\u00fchrt, d.h. bei einem 40 Jahre alten Flugzeugmuster ist der 40 Jahre alte Standard relevant [1]. Dies gilt in der Regel f\u00fcr Anpassungen. Bei gr\u00f6\u00dferen \u00c4nderungen oder Neueinbauten werden jedoch regelm\u00e4\u00dfig die aktuellen Standards angewendet. Dies f\u00fchrt dazu, dass sich bei einem \u00e4lteren Flugzeugmuster f\u00fcr verschiedene Komponenten viele Standards aus unterschiedlichen Zeiten angesammelt haben. Im Literaturverzeichnis ist eine \u00dcbersicht \u00fcber Standards gegeben. Es ist keine Seltenheit, dass gleichzeitig Standards von 1980 bis zur Jetztzeit zu ber\u00fccksichtigen sind.<\/p>\n Dies ist ein wesentlicher Grund f\u00fcr die lange Nutzungsdauer von Avionik-Rechnern. F\u00fcr den Ersatz muss nicht nur eine neue Zertifizierung im Umfang vergleichbar mit dem der Zertifizierung des Altger\u00e4ts durchgef\u00fchrt werden, sondern dar\u00fcber hinaus nach den meist strengeren aktuellen Standards. Die aktuellen Standards f\u00fcr Systementwicklung (ein Avionik-Rechner ist ein System bestehend aus mindestens den „items“ HW und SW) ist ARP4754A und f\u00fcr die SW-Entwicklung der Standard DO-178C; hier wird durch „objectives“ und „activities“ der Rahmen f\u00fcr den SW-Entwicklungsprozess festgelegt. Falls Entwicklungsschritte dem menschlichen Ingenieur durch Tools abgenommen werden, so muss das Toolergebnis verifiziert oder das Tool qualifiziert werden. Die Tool-Qualifizierung ist aus dem DO-178C [13] herausgel\u00f6st und im „technical supplement“ DO-330 [14] beschrieben. Analog zu den „software levels“ A bis E der Avionik-SW nach DO-178C gibt es im DO-330 „tool qualification level“ TQL-1 bis TQL-5, welche unter Ber\u00fccksichtigung der Tool „criteria“ ausgew\u00e4hlt werden. Der Entwicklungsprozess f\u00fcr Tools ist im Wesentlichen der gleiche wie f\u00fcr Avionik-SW gem\u00e4\u00df DO-178C, angepasst durch DO-330.<\/p>\n Die Nutzung der Tools und der Betrieb einer SDE ist z.B. f\u00fcr ein spezielles Umfeld in LTR 7030 [5] geregelt. Im zugeh\u00f6rigen Leitfaden [6] wird das Thema SW-Obsoleszenz angesprochen. SW-Obsoleszenz liegt hiernach vor bei technischem Veralten, durch ge\u00e4nderte gesetzliche Vorgaben oder aufgrund wirtschaftlicher Entscheidungen (z.B. Abk\u00fcndigungen). Gem\u00e4\u00df des Leitliniendokuments tritt SW-Obsoleszenz auf, wenn notwendige HW und\/oder SW nicht mehr funktioniert oder notwendige Modifikationen (z.B. zur Behebung von Fehlern, zur Anpassung an Betriebsumgebung, zur Weiterentwicklung des Tools \u2026) nicht mehr durchgef\u00fchrt werden k\u00f6nnen. Als Ursachen f\u00fcr SW-Obsoleszenz wird neben der Obsoleszenz der HW folgendes genannt: fehlende\/unvollst\u00e4ndige Dokumentation, fehlende Nutzungsrechte, fehlendes Personal.<\/p>\n Zum Thema Personal gibt es Regelungen auch in folgenden Standards: DO-178C [13], AQAP 2210 [8], EN9100 [2]. Hier wird im Wesentlichen gefordert, dass das Personal f\u00fcr die jeweiligen T\u00e4tigkeiten eingewiesen oder geschult und dies zu dokumentieren ist.<\/p>\n Der Langzeitbetrieb einer SDE erfordert zusammengefasst die In-Betrieb-Haltung von HW und SW und das Vorhandensein von geschultem Personal. M\u00f6gliche Ursachen f\u00fcr Obsoleszenz in diesen drei Bereichen sind:<\/p>\n Meist liegen zudem Abh\u00e4ngigkeitsketten vor, wie z.B. Tool \u2013 Betriebssystem \u2013 HW. Das hei\u00dft, ein eingefrorenes Tool (z.B. nach Ablauf des Supportvertrages) kann nur mit einer alten Betriebssystemkonfiguration (Version, Patch-Zustand) laufen, und diese alte Betriebssystemversion hat wiederum Einschr\u00e4nkungen auf die Host-HW.<\/p>\n M\u00f6gliche L\u00f6sungen f\u00fcr Obsoleszenz sind:<\/p>\n Die M\u00f6glichkeit von Support durch Hersteller von HW und SW ist meist dadurch stark eingeschr\u00e4nkt bzw. nicht existent, dass Supportvertr\u00e4ge jeweils einen aktuellen Patch-Level der HW, des Betriebssystems und der Anwendungs-SW verlangen. Bei einer eingefrorenen SDE ist dies jedoch nicht m\u00f6glich. Regelm\u00e4\u00dfig muss hier der fehlende Support durch Inhouse-Knowhow abgedeckt werden. Dies ist ein hohes Risiko.<\/p>\n Die oben genannten L\u00f6sungsans\u00e4tze haben auch ihre Schattenseiten. Der Betrieb von virtuellen Images ist davon abh\u00e4ngig, dass es moderne HW gibt, die diese alten Images betreiben kann. Der Aufwand an Lagerhaltung bedeutet hohe Kosten und Platzbedarf. Auch altern HW und Datentr\u00e4ger im Regal. Daher ist es w\u00fcnschenswert, die SDE nicht zu alt werden zu lassen, sondern sich an die aktuellen Entwicklungen rechtzeitig anzuh\u00e4ngen. Dies bedeutet die Herausforderungen der Requalifizierung von Tools nach DO-330 und der Rezertifizierung von Avionik-SW nach DO-178C.<\/p>\n Bei der Umstellung\/Modernisierung von Methoden und Prozessen, z.B. Strukturierte Analyse (SA\/RT) auf UML und objektorientiertes Design, ist zudem zu beachten, dass hierdurch zus\u00e4tzlich die „technical supplements“ DO-331 [15] und DO-332 [16] f\u00fcr modellbasierte Methoden und objektorientierte Technologie zu ber\u00fccksichtigen sind.<\/p>\n Die Avionik-SW-Entwicklung stellt einige spezielle Anforderungen und Herausforderungen an die SDE und deren Langzeitbetrieb. Einige L\u00f6sungsm\u00f6glichkeiten wurden aufgezeigt, jedoch auch Grenzen. Ziel dieses Konferenzbeitrages ist es auch, mit anderen Beteiligten in diesem Thema in Austausch zu kommen, um weitere L\u00f6sungen zu erarbeiten und zu finden.<\/p>\n [1]\u00a0 AC\u00a020-115C, Advisory Circular: Airborne Software Assurance, U.S. Department of Transportation, Federal Aviation Administration, 2013<\/p>\n [2]\u00a0 DIN\u00a0EN\u00a09100:2009, Qualit\u00e4tsmanagementsysteme \u2013 Anforderungen an Organisationen der Luftfahrt, Raumfahrt und Verteidigung, Berlin, 2009<\/p>\n [3]\u00a0 Fl\u00fchr H., Avionik und Flugsicherungstechnik: Einf\u00fchrung in Kommunikationstechnik, Navigation, Surveillance, Springer Vieweg Verlag, 2013<\/p>\n [4]\u00a0 Hinsch M., Industrielles Luftfahrtmanagment: Technik und Organisation luftfahrtteschnischer Betriebe, Springer Vieweg Verlag, 2012<\/p>\n [5]\u00a0 LTR\u00a07030-001, Luftfahrttauglichkeitsrichtline Software, Bundesamt f\u00fcr Wehrtechnik und Beschaffung, Ausgabe 3, Okt. 2001<\/p>\n [6]\u00a0 LTR\u00a07030 Leitfaden, Leitfaden zur Luftfahrttauglichkeitsrichtline Software, Bundesamt f\u00fcr Wehrtechnik und Beschaffung, Version 2, Aug. 2005<\/p>\n [7]\u00a0 NATO\u00a0AQAP\u00a02110, NATO Quality Assurance Requirements for Design, Development and Production, 2009<\/p>\n [8]\u00a0 NATO\u00a0AQAP\u00a02210, NATO Supplementary Software Quality Assurance Requirements to AQAP 2110, 2006<\/p>\n [9]\u00a0 Rierson L., Developing Safety-Critical Software, CRC Press, Boca Raton, 2013<\/p>\n [10]\u00a0 RTCA\u00a0DO-178, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 1982<\/p>\n [11]\u00a0 RTCA\u00a0DO-178A, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 1985<\/p>\n [12]\u00a0 RTCA\u00a0DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 1992<\/p>\n [13]\u00a0 RTCA\u00a0DO-178C, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 2011<\/p>\n [14]\u00a0 RTCA\u00a0DO-330, Software Tool Qualification Considerations, Washington, DC, RTCA, Inc., 2011<\/p>\n [15]\u00a0 RTCA\u00a0DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A, Washington, DC, RTCA, Inc., 2011<\/p>\n [16]\u00a0 RTCA\u00a0DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, Washington, DC, RTCA, Inc., 2011<\/p>\n [17]\u00a0 SAE\u00a0ARP4754A, Guidelines for Development of Civil Aircraft and Systems, Warrendale, SAE Aerospace, 2010<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2015<\/h3>\n
\n<\/strong><\/p>\n\n
\n
Zusammenfassung<\/h2>\n
Abk\u00fcrzungsverzeichnis<\/h2>\n
\n\n
\n AC<\/td>\n Advisory Circular<\/td>\n<\/tr>\n \n AQAP<\/td>\n Allied Quality Assurance Publications<\/td>\n<\/tr>\n \n ARP<\/td>\n Aerospace Recommended Practice<\/td>\n<\/tr>\n \n HW<\/td>\n Hardware<\/td>\n<\/tr>\n \n IDE<\/td>\n Integrierte Entwicklungsumgebung<\/td>\n<\/tr>\n \n RTCA<\/td>\n Radio Technical Commission for Aeronautics<\/td>\n<\/tr>\n \n SA\/RT<\/td>\n Structured Analysis with Real-Time Extensions<\/td>\n<\/tr>\n \n SDE<\/td>\n Softwareentwicklungsumgebung<\/td>\n<\/tr>\n \n SW<\/td>\n Software<\/td>\n<\/tr>\n \n UML<\/td>\n Unified Modeling Language<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Literatur- und Quellenverzeichnis<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n