Evaluierung von Methoden zur Entwicklung sicherheitskritischer ...

Evaluierung von Methoden zurEntwicklung sicherheitskritischerSoftwaresystemeInformatikprojektbeiProf. Dr. VoosvonTobias Hondorf29. April 2010Studiengang Angewandte InformatikFakultät für Elektrotechnik und Informatik

InhaltsverzeichnisAbbildungsverzeichnis 2Tabellenverzeichnis 21 Einführung - Was ist die Besonderheit an sicherheitskritischenAnwendungen? 32 Übersicht sicherheitskritischer Entwicklungsstandards in derEmbedded-Software 52.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Luftfahrt, ist und Zukunft . . . . . . . . . . . . . . . . . . . 72.3 andere Branchenspezifische Standards . . . . . . . . . . . . . 113 Vorgehen in der Luftfahrt allgemein 123.1 Entwicklungsmethoden . . . . . . . . . . . . . . . . . . . . . 143.1.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Implementierung . . . . . . . . . . . . . . . . . . . . 143.1.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Beispiel: Coding Standard 154.1 Kriterien für die Auswahl eines Standards . . . . . . . . . . 164.2 Mögliche Standards abhängig von der Programmiersprache . 184.2.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 MISRA-C Codebeispiel . . . . . . . . . . . . . . . . . . . . . 234.4 Prüfung der Einhaltung . . . . . . . . . . . . . . . . . . . . 275 Zusammenfassung 29Literaturverzeichnis 301

Abbildungsverzeichnis1 Rapid Prototyping im Projektfluss . . . . . . . . . . . . . . 13Tabellenverzeichnis1 IEC 61508 - Sicherheitsintegriätslevel . . . . . . . . . . . . . 72 DO-178B Kritikalitätsstufen . . . . . . . . . . . . . . . . . . 93 IEC61508 Programmiersprachen . . . . . . . . . . . . . . . . 182

1 Einführung - Was ist die Besonderheit ansicherheitskritischen Anwendungen?Um die Fragestellung, was die Besonderheit an Sicherheitskritischen Systemenist, zu klären, muss zunächst definiert werden, was ein sicherheitskritischesSystem ist. Der Begriff "sicherheitskritisches System" unterliegtkeiner allgemeingültigen Definition. Das deutsche Wort "Sicherheit" hatzwei Bedeutungen, zum einen der Schutz der Umwelt und des Menschenvor einem Objekt, die sog. Betriebssicherheit (engl. Safety) und zum anderender Schutz eines Objektes vor der Umwelt bzw. des Menschen hierspricht man von Angriffssicherheit (engl. Securtiy). In dieser Arbeit wirdder Begriff Sicherheit im Sinne von Betriebssicherheit also Safety verwendet.Safety vs.SecurityWas ist nun also ein sicherheitskritisches System? Allgemein kann gesagtwerden, dass ein System, von dem eine unmittelbare oder mittelbareGefahr für den Mensch oder die Umwelt ausgeht, als sicherheitskritischeingestuft wird. Die Sicherheitskritikalität eines Systems stellt besondereAnforderungen an seine Entwicklung. Und genau hierin liegt die Besonderheitsicherheitskritischer Anwendungen - die Anforderung nach Sicherheit.Ein sicherheitskritisches System muss nachweislich einen gewissen Grad anRobustheit und Sicherheit gewährleisten.Diese Arbeit betrachtet Sicherheitskritische Anwendungen im Sinne vonSoftware. Anders als Hardware kann Software nicht Ausfallen, sie ist freivon physikalischen Einflüssen. Ein Softwaresystem kann aber, auf Grundvon Fehlern in der Software selbst, zu Fehlfunktionen führen. Durch einenSoftwarefehler könnte das System mit falschen Werten oder Steueranweisungenversorgt werden. Im extremsten Fall stürzt die Software ab, was sichdurch eine permanente Unterbrechung des Programmablaufes äußert. Einesolche Unterbrechung kann Auswirkung auf das gesamte System haben.Kann das System durch einen Softwarefehler in einen gefährlichen Zustandversetzt werden, so ist die Software als sicherheitskritisch zu sehen. Undhat die Anforderung nach Sicherheit, aus der sich die Anforderung nachFehlerfreiheit ableitet.Diese Anforderung soll an einem kleinen Beispiel verdeutlicht werden.Im Alltag kommt jeder unweigerlich mit vielen elektronischen Systemen inKontakt in denen Software arbeitet. Ein einfaches Beispiel ist ein Fernsehgerät.An die Software auf einem solchen Gerät wird keine sicherheitskritischeAnforderung gestellt. Einer der schwersten Fehler die auftreten können wäreder Totalausfall im operationellen Betrieb. Selbstverständlich soll dieserFehler auch ohne sicherheitskritische Anforderungen nicht auftreten, dennwer kauft sich einen Fernseher der sich ständig abschaltet? Würde ein solcherFehler jedoch in 10.000 Betriebsstunden einmal Auftreten, so wäreSicherheitskritischeSoftwareFehlertoleranz3

diese Zahl tolerierbar. In jedem Fall würde von einem solchen Softwarefehlerkeine Gefahr für den Menschen ausgehen.Ein Gegenbeispiel wäre, der Totalausfall des "Fly-by-wire" Systems einesmodernen Passagierflugzeuges im operationellen Betrieb. Ein solcher Ausfallwürde unweigerlich zum Tod vieler Menschen führen. Das Auftretendieses Fehlers wird als nicht tolerierbar angesehen und muss deshalb ausgeschlossenwerden.Aus diesem Grund benötigen Systeme, die eine Gefahr für Mensch undUmwelt darstellen können, in der Regel eine Zulassung durch eine (meiststaatliche) Behörde. So brauchen ein Flugzeug, ein Auto oder auch z.B.Industrieroboter oder medizinische Geräte eine Zulassung um eingesetztwerden zu dürfen. Hierfür muss der Behörde ein Nachweis darüber erbrachtwerden, dass das jeweilige System ein gewisses Maß an Sicherheit erfüllt.Und die somit von dem System ausgehende Gefahr minimiert ist.Um diese Nachweise einheitlich Erbringen zu können, wurden Standardsfestgelegt, deren Einhaltung darauf abzielt ein System sicher zu machenund dies einer Zulassungsbehörde gegenüber Nachweisen zu können. Einallgemeingültiger Standard für die Softwareentwicklung in einem sicherheitskritischenSystem ist die Norm IEC 61508. Die Einhaltung dieser Normzielt auf eine allgemeine Zertifizierung eines Systems unter sicherheitskritischenAnforderungen ab. Neben der allgemeingültigen IEC 61508 gibt esnoch viele Branchenspezifische Normen. Diese sind dann an die Problemstellungenund Eigenheiten der jeweiligen Bereiche angepasst. So stellt dieEntwicklung eines Flugzeuges andere Anforderungen an die Sicherheit, alsz.B. ein chirurgisches Laserskalpell. Aus diesem Grund gibt es Standardsfür die Entwicklung in der Luftfahrt, als auch Standards zur Entwicklungvon medizinischen Geräten.Welcher Standard bei einer Entwicklung aber in letzter Konsequenz eingesetztwird, hängt von den Forderungen der Zertifzierungsbehörde und/oderdem Kunde ab.ZertifizierungsicherheitskritischerSystemeZusammenfassung Die Besonderheit an sicherheitskritischer Softwareist die Anforderung nach Sicherheit. Diese muss durch die Einhaltung vonStandards bzw. Normen nachweisbar sein.4

2 Übersicht sicherheitskritischerEntwicklungsstandards in derEmbedded-Software2.1 AllgemeinDer allgemeinste Standard für die Zertifizierung sicherheitskritischer Systemeist die Norm IEC/ISO 61508 "Funktionale Sicherheit sicherheitsbe- IEC 61508zogener elektrischer/elektronischer/programmierbarer elektronischer Systeme"[CEN01].Dieser Standard legt sich nicht auf ein Einsatzgebiet fest, sondern behandeltdie Sicherheitskritikalität im Allgemeinen. Er lässt sich somit auf dieunterschiedlichsten Einsatzgebiete zuschneiden und ist stark anpassungsfähigund kann auch zur Entwicklung eines unkritischen Systems verwendetwerden.Die IEC 61508 besteht aus folgenden 7 Teilen:• IEC 61508-1 Allgemeine Anforderungen• IEC 61508-2 Hardware• IEC 61508-3 Software• IEC 61508-4 Definitionen• IEC 61508-5 Richtlinien zu Teil 1, Beispiele zur Einstufung der Sicherheitsintegrität• IEC 61508-6 Richtlinien zu Teil 2 und 3• IEC 61508-7 Techniken, BeispieleWobei die Teile 1-4 normativ sind, also die dort beschriebenen Anforderungenals Prüf- und Zertifizierungskriterien verwendet werden können. DieTeile 5-7 haben rein informativen Inhalt. Sie enthalten Beispiele, Ansätzeund Strukturen, die als Ergänzung zu den ersten 4 Teilen zu sehen sind.Wie anhand der Teile der Norm zu sehen ist, beschäftigt sich diese nichtnur mit der Softwareentwicklung, sondern mit dem Gesamtsystem. Es giltzu verstehen, dass es keine alleinstehende Softwarezertifizierung gibt. EineZertifizierung erfolgt immer für das Gesamtsystem. Dies liegt in derTatsache begründet, dass ein System nur sicher sein kann, wenn "sichere"Software auf "sicherer" Hardware läuft. Die Software ist also ein Teil desGesamtsystems, deshalb müssen für diese Nachweise erbracht werden. Inder Praxis besteht zwar die Möglichkeit der Einzelzertifizierung, also derZertifizierung eines Softwaresystems oder einer Hardwareplattform, jedochZertifizierungerfolgt immerfür eingesamtesSystem5

muss bei der Zertifizierung eines Produkts dennoch das Gesamtsystem geprüftwerden. Teilprüfungszertifikate werden aber unterstützend anerkannt.Ein Beispiel hierfür sind COTS 1 Produkte die es im Hardware- sowie Softwaresektorgibt. Für diese existiert dann ggf. eine Vorabzertifizierung, diebei der Software in Form von Zertifizierungsartefakten vorliegt. Diese könnendann zur Zertifizierung des Endproduktes, zusammen mit den selbsterstellten Zertifzierungsunterlagen, für das Projekt beim Zertifizierer eingereichtwerden.Allgemeine Anforderungen Der erste Teil der IEC 61508 Norm enthältdie allgemeinen Anforderungen. Er beschreibt die Betrachtung des Gesamtlebenszykluseines Projektes. Diese Betrachtung geht über die reine Softwareentwicklunghinaus und schließt das Projekt, Konfigurations- und Dokumentationsmanagementmit ein. In den Anforderungen sind Projektphasendefiniert, bei deren Übergang die Norm eine Verifikation der Ergebnisse fordert.Es muss also ein Nachweis darüber erbracht werden, dass eine Phasekorrekt und den Anforderungen entsprechend abgeschlossen wurde, bevorzur nächst übergegangen werden darf. Über den gesamten Projektverlaufmuss die Dokumentation so erfolgen, dass jeder Vorgang durch dritte Vollständigrekonstruiert werden kann. Das heißt, dass eine detailierte Planungdurchgeführt werden muss, die das Vorgehen und die geforderten Ergebnissedefiniert. Durch die Dokumentation muss nachweisbar sein, dass dasvordefinierte Vorgehen angewandt und die geforderten Ergebnisse erzieltwurden.Sicherheitskritikalität Die IEC 61508 fordert, dass nach der Definitiondes gesamten Systems, eine Gefahren- und Risikoanalyse durchgeführt wird.Hierbei soll ermittelt werden, was es für potentielle Gefahren gibt und wiesich diese auf das System auswirken können. Für die Gefahren müssen entsprechendeGegenmaßnahmen ausgearbeitet werden. Hierzu kann Teil 5der Norm unterstützend herangezogen werden. Das Ergebnis der Analysesind Sicherheitsanforderungen an das Gesamtsystem, anhand derer sich dasSystem in eines der vier Sicherheitsintegritätslevel (SIL) einordnen lässt.Je nach zunehmender Kritikalität werden die Anforderungen an ein SILstrenger (SIL 1 = gering, SIL 4 = hoch). Das Ergebnis der Risiko- undGefahrenanalyse und die Einstufung in SIL, fließen direkt in die Software-Sicherheitsanforderungen (Beschrieben in IEC 61508 Teil 3) ein.DerProjektablaufmuss zu jedemZeitpunktnachweisbarseinSIL:SicherheitsintegritätslevelSoftwareentwicklung Je nach SIL einer Software müssen die Entwicklerin der Norm zitierte Strategien verwenden. Über die mögliche Kombinationder Strategien wird jedoch keine Aussage getroffen. Beispielsweise werdenkeine Anmerkung zu Codebeschränkungen gemacht. Oftmals wird in deraus der Automobilindustrie stammende MISRA Coding-Standard verwendet,dieser wird aber nicht explizit vorgeschrieben. Es ist ratsam Teil 71 Commercial of-the-shelf6

SILFehlerhäufigkeit4 10 −5 - 10 −43 10 −4 - 10 −32 10 −3 - 10 −21 10 −2 - 10 −1Tabelle 1: IEC 61508 - Sicherheitsintegriätslevel(Abgeleitet aus [CEN01])des Standard als Unterstützung für die in Teil 3 beschriebenen Software-Anforderungen zu verwenden. Für die Softwareentwicklung wird auch dasSoftwarelebenszyklusmodell verfolgt. Generell ist für die Norm ein modellbasiertesVorgehen verpflichtend, allerdings wird hier nur ein Vorschlag zumV-Modell gemacht. Die Verwendung dieses ist aber nicht zwingend. Diesrührt daher, dass viele Firmen ihre eigenen Vorgehensmodelle für Projekteentwickelt haben (diese sind oftmals stark an das V-Modell angelehnt.).Es soll hier Freiraum für diese individuellen Vorgehenslösungen gelassenwerden.Verwendungeines VorgehensmodellsZusammenfassung Die Norm beschreibt, dass der Geltungsbereich desSystems definiert werden muss. Es müssen Analysen durchgeführt werden,die Gefahren und Risiken genau festlegen. Die Softwareentwicklung musseinem in der Planung festgelegten Modell folgen, dass zwar frei wählbar IEC 61508ist, aber beim Übergang von einer in die nächste Phase Tests und Reviews auch für dieverlangt. So soll sichergestellt werden, dass die Anforderungen einer Phase Entwicklungerfüllt wurden, bevor mit der nächsten weiter gemacht wird. Grundsätzlichkann diese Norm auch zur Erstellung von nicht sicherheitskritischen sicherheits-von nicht-Systemen eingesetzt werden. Die Norm sieht es vor, das bereits definiertes kritischenVorgehen von Vorgänger- bzw. ähnlichen Projekten, in ein neues Projekt Systemenübernommen werden kann. Somit soll versucht werden, den Aufwand für anwendbarweitere Projekte möglich gering zu halten.2.2 Luftfahrt, ist und ZukunftDer Flugzeugbau wird im laufe seiner Entstehung und bis heute, als eine dergrößten ingeneurswissenschaftlichen Herausforderungen betrachtet. Warendie ersten Flugzeuge doch rein mechanisch und zählten zur Kategorie "Maschinenbau",so wäre heute die Elektronik nicht mehr wegzudenken. GroßePassagierflugzeug sind zu fliegenden High-Tech Computern geworden. DieSteuerung des Flugzeugs wird schon längst nicht mehr mechanisch, sonderelektronisch umgesetzt. Zahlreiche elektronische Geräte unterstützen diePiloten bei Steuerung, Navigation und Kommunikation - Geräte in denen7

Software arbeitet.Am Beispiel der Flugsteuerung (Fly-by-Wire) ist gut zu sehen, wie wichtigfehlerfreie und funktionierende Systeme sind. Ein Ausfall des Systemshätte katastrophale Folgen, daher gilt es einen solchen Fehler zu vermeiden.DO-178BDer DO-178B "Software considerations in airborne systems and equiptmentcertification" ist ein international anerkannter Standard zur Zertifizierungsicherheitskritischer Software im Bereich des Flugzeugbaus. Der U.S. AmerikanischeStandard wird in Europa unter dem Namen ED-12B verwendet.Der DO-178B umfasst, anders als der IEC 61508, nur den Software-Lebenszyklus. Es sind zwar Schnittstellen zum System-Lebenszyklus definiert,dieser wird aber nicht speziell betrachtet.Der DO-178B definiert Richtlinien, die den Einklang zwischen den Anforderungender Luftfahrt und der Software sicherstellen sollen. Diese Richtlinienbeschreiben Ziele für Software-Lebenszyklusprozesse, Aktivitäten um diesezu erreichen und Nachweise um die Einhaltung der Ziele zu überprüfen.Umfasst denSoftware-Lebenszyklus• Beschreiben der Ziele (objectives)• Beschreiben der (Prozess-)Aktivitäten die zur Erfüllung der Ziele führen• Beschreiben der Nachweise, die die Einhaltung der Ziele bestätigenDer Software-Lebenszyklus wird im Standard als die Gesamtheit allerProzesse sowie deren Abfolge und gegenseitige Beeinflussung verstanden.Er wird in folgende 6 Prozesse untergliedert:• Planung• Entwicklung• Verifikation• Konfigurationsmanagement• Qualitätssicherung• Schnittstelle zur ZertifizierungsbehördeWichtig ist, dass der Standard kein Prozessmodell im besonderen Vorschlägt,sondern nur einen Rahmen festlegt. Man hat die Freiheit ein Prozessmodellzu verwenden, das die Rahmenkriterien erfüllt. Das V-Modellwäre ein solches Prozessmodell, das den Rahmenbedinungen des DO-178B8

gerecht wird. Oftmals ist es aber so, dass Firmen selbst Prozessmodelledefinieren oder bereits vorhandene modifizieren um ihre über Jahre etabliertenund durch Erfahrung optimierten Prozesse verwenden zu können.Er legt aber dennoch ein gewisses Vorgehen fest, so muss das Software-Kritikalitätslevel (siehe Tabelle 2) festgelegt werden. Aus diesem leiten sichdann spezielle Anforderungen ab. So muss eine Software, die eine höhereKritikalität hat, ausführlicher und umfangreicher getestet werden, als eineweniger kritische.Design Assurance Levels (DAL)Level ALevel BLevel CLevel DLevel EFailure ConditionCatastrophicHazardous/Severe-MajorMajorMinorNo EffectTabelle 2: DO-178B Kritikalitätsstufen(gekürzt aus [Inc92] S.7)Planungsprozess Im Planungsprozess soll der Softwareentwicklungsprozessdefiniert werden. Die Abhängigkeit und Abfolge von Prozessen sollfestgelegt werden. Die Umgebung des Software-Lebenszyklus soll beschriebenwerden (welche Methoden und Tools werden eingesetzt?) und es sollfestgelegt werden, was für Entwicklungsstandards zur Anwendung kommen.Dabei muss stehts darauf geachtet werden, dass die Planung den Anforderungendes DO-178B genügt, denn dies ist für die erfolgreiche Zertifizierungessentiell! Im Detail sollen die folgenden Pläne ausgearbeitet werden:• Plan of Software Aspects of Certification• Software Development Plan• Software Verification Plan• Software Configuration Management Plan• Software Quality Assurance PlanNeben diesen Dokumenten fordert der Standard noch weitere Dokumente,deren Umfang je nach Kritikalitätsstufe der Software variiert. Der Standardstellt also formale Anforderungen an den Gesamten Projektablauf.Umfang derDokumente istabhänig vonderKritikatlität9

Entwicklungsprozess Es wird kein Enwicklungsprozess vorgeschrieben,sondern nur Ziele von Teilprozessen beschrieben. In welcher Reihenfolgediese ablaufen oder ob sie teilweise parallel ausgeführt werden, kann selbstdefiniert werden. Die Ergebnisse der Teilprozesse sollen stehts nachvollziehbarsein, d.h. die Anforderungen an die höheren Ebenen müssen sichin den Teilprozessen wiederfinden. Es besteht die Möglichkeit der Revisioneines vorangegangenen Entwicklungsschrittes, falls Inkonsistenzen oderFehler auftreten.Verifikation Durch die Verifikation sollen die Ergebnisse der Softwareentwicklung,auf Fehlerfreiheit und Richtigkeit, überprüft werden. Der Verifikationsprozesssoll Fehler aufspüren und diese an den Softwareentwicklungsprozesszurück melden, damit diese dann behoben werden können.Dies geschieht durch Reviews und Analysen. Zu den Zielen der Verifikationgehört es zu prüfen, ob die High-Level-Anforderungen in Architekturund Low-Level Requirements umgesetzt wurden, ob die Low-Level Anforderungenin Sourcecode umgesetzt wurden, ob der Ausführbare Code dieSoftwareanforderungen erfüllt und ob die im Standard für den jeweiligenDAL Level vorgesehen Mittel korrekt und vollständig eingesetzt wurden.Konfigurationsmanagement Die Aufgabe des Konfigurationsmanagementsist von organisatorischer Natur. Es legt Verantwortlichkeiten fest,sorgt für Nachvollziehbarkeit und betreibt Auswirkungskontrolle. Somitsind konkrete Ziele des Konfigurationsmanagementprozesses, beispielsweisedie Identifikation der Konfigurationseiniten (Configuration Items), die Sicherstellung,dass Schritte und insbesondere Änderungen durch Revisionennachvollziehbar sind, sowie die Verfügbarkeit der Daten, zu garantieren.Ergebnisse des Standards Der Standard stellt Anforderungen an dieEindeutigkeit, Vollständigkeit, Konsistenz, Klarheit, Verifizierbarkeit, Nachvollziehbarkeitund Änderbarkeit des Software-Lebenszyklus. Das Ergebnissetzt sich aus Plänen, Standards, Anforderungen, Design, Code, Verifikationsergebnissen,Berichten und Qualitätssicherungsdokumenten zusammen.Das Zentrale Dokument ist hierbei das "Plan of Software Aspects of Certification".Zusammenfassung Der DO-178B ist im Vergleich zu anderen Standards"gut lesbar", weil er Sachverhalte konkretisiert. Nach dem Abschluss derPlanungsphase sind die zum Einsatz kommenden Tools, Methoden sowieder Zeitplan festgelegt. Für die Verifikation und die Tests sind modellbasierteAnsätze vorgeschlagen. Die Anforderungen an Software, der höchstenKritikalitätsstufe (DAL-A), sind im Vergleich zu denen anderen SicherheitskritischenStandards sehr hoch.10

Vergleich DO-178B und IEC 61508 Der IEC 61508 ist eine europäischeNorm und findet kaum außerhalb Europas Anwendung. Die DO-178Bhat bezüglich internationaler Zulassungsrichtlinen (von allen Luftfahrtbehördenanerkannt) einen Referenzsstatus. Vieles aus DO-178B findet sichauch in anderen Standards zur sicherheitskritischen Softwarenentwicklungwieder.Der DO-178B schreibt zu erstellende Dokumente konkret vor.Im IEC61508 wird zwischen funktionalen Anforderungen und Integrationsanforderungenunterschieden. Beim DO-178B wird nach Low-Level undHigh-Level Anforderungen unterschieden.Viele Ansätzedes DO-178Bfinden sich imIEC61508wieder2.3 andere Branchenspezifische StandardsIn Abschnitt 2.1 wurde bereits darauf verwiesen, dass es für die unterschiedlichenBranchen jeweils spezielle Zertifizierungsstandards gibt.LuftfahrtDO-178B / ED-12BDie DO-178B wurde bereits im Abschnitt 2.2 behandelt.AutomobilOSEK/VDX, AUTOSARDas OSEK/VDX Gremium hat diverse Standards für Software im Automobilgeschaffen. So z.B. die Spezifikation OSEK-OS, welche ein Echtzeitbetriebssystemzum Einsatz in Embedded-Systemen beschreibt. Die wesentlichenTeile der OSEK Spezifikationen sind in ISO 17356 zusammengefasst.AUTOSAR ist ein internationaler Verbund mit dem Ziel, einen offenenStandard für Software-Architekturen in Kraftfahrzeugen zu etablieren.Verkehrstechnik (DIN) EN 50128Die EN 50128 ist eine europäische Norm für sicherheitsrelevante Softwaredes Schienenverkehrs.MedizintechnikFDA 510(k)U.S.-Amerikanischer Standard zur Zertifizierung medizinischer Geräte.Atomkraft (DIN) IEC 880Standard für Software für Rechner im Sicherheitssystem von Kernkraftwerken.Es werden Anforderungen für jede Stufe der Software-Entwicklung11

vom Entwurf über Entwicklung, Qualitätsprüfung, Betrieb und die Dokumentationfestgelegt.MilitärMIL-STD-498U.S.-Amerikanischer Standard zur Zertifizierung militärischer Geräte.3 Vorgehen in der Luftfahrt allgemeinDas Vorgehen in der Luftfahrt orientiert sich an den vom Kunden vorgegebenenAnforderungen. In der Regel wird ein Avionik-Projekt nach DO178Bzertifiziert, dies ist ebenso eine Vorgabe des Kunden. Infolgedessen werdendie Vorgaben und Richtlinien des DO178B eingehalten. Das Vorgehen orientiertsich somit an dem Standard. Oftmals legt der Kunde sein gewünschtesProzessmodell vor, das dann zur Entwicklung verwendet werden muss. Esspielt auch eine Rolle, ob es sich um eine Neu- oder Weiterentwicklung einesProduktes handelt. Aus diesen Gründen gibt es kein generell angewandtesVorgehen.Rapid Prototyping Um ein Beispiel für ein mögliches Vorgehen bei einerNeuentwicklung zu geben, möchte ich das "Rapid Prototyping" [AbRS94]anführen. Diese Methodik zielt auf das schnelle erzeugen von funktionalenModellen (Prototypen) in einem frühen Stadium des Projekts ab. Da dieseMethode informal ist, lassen sich Prototypen schnell erzeugen, ändern oderverwerfen. Es muss dabei nicht auf die Struktur, Wartbarkeit und Wiederverendbarkeitder Software geachtet werden. Ein Ansatz ist, durch einensolchen Prototypen, die Kundenanforderungen zu realisieren und zu testen.Bereits beim Prototyping können Probleme identifiziert werden, unddie Machbarkeit der Erfüllung der Anforderungen überprüft werden. Diesführt dazu, dass für Probleme Lösungen erarbeitet und getestet werdenkönnen, ohne dass ein formaler Weg eingehalten werden muss.Ein Vorteil zeigt sich in der hohen Flexibilität und den geringen Kostendieser Methode. Zudem kann dem Kunden bereits in einem frühen Stadiumdes Projektes ein funktionierendes Modell gezeigt werden, und durchKunden-Feedbacks können Anforderungen weiter spezifiziert und konkretisiertwerden. Somit können funktionale Prototypen erstellt werden, dieschon vor beginn der eigentlichen Entwicklung, die Komplexität und dieStruktur des Systems bzw. der Software erkennen lassen.SchnelleVerfügbarkeiteinesPrototypen-ModellsFrüheErkennung vonProblemenNachdem Abschluss des Prototypings wird die formale Entwicklung eingeleitet.Die erstellten Modelle werden analysiert und helfen bei der Konkretisierungder Anforderungen. Sie dienen aber nicht als Grundlage zurCodeerzeugung, sondern werden nach der Analyse weggeworfen. Da Problemstellungenbereits durch die Modelle bekannt sind, kann die Planung12

optimiert werden und Zeit zum Erarbeiten von Lösungsstrategien eingeplantwerden. Zudem kann die Planung direkt auf das Ziel gerichtet werden,da die "Richtung", in welche die Entwicklung geht, durch die Prototypenklar wurde. Ein Vorteil hierbei ist, dass die Entwicklung jetzt weitestgehendStraight-Through erfolgen kann, denn es wird zwar noch nicht identifizierteProbleme geben, jedoch wird diese Zahl geringer sein als ohne Prototyping.Somit wird kaum noch Zeit für formale Änderungen am Projekt benötigt.Ein realitätsnahes Beispiel wäre die Verwendung eines durch Dritte gefertigtenHardwaretreibers, der bei der Erstellung der Prototypen bereitsvorlag. Der Treiber ist so implementiert, dass bestimmte, für das Projektwichtige Funktionalitäten, nicht ermöglicht werden. Dies wäre beim Prototypingaufgefallen und man hätte ein Vorgehen definieren können. Wird derTreiber selbst geändert, neugeschrieben, oder vom Hersteller um die benötigteFunktionalität erweitert? Beim Prototyping kann jede der Lösungenverwendet werden, ohne Änderungen an der Projektplanung machen zumüssen. Wird aber dieses Problem bei einer formalen Entwicklung festgestellt,so muss es eine Änderung der Planung geben. Es muss begründetwerden warum der Treiber nicht verwendet werden kann, wie die genaueLösung aussieht und auf was für Komponenten der Software diese Änderungim Projekt Auswirkungen haben kann. Diese vermeintlich kleine Änderung,die durch den Austausch des Treibers vorgenommen wird, zieht einen enormenRattenschwanz an Formalien nach sich. Aus wirtschaftlicher Sicht istdies ein nicht unbedeutender Kostenfaktor.GezielteAusrichtungderEntwicklungauf die Lösungder ProblemeDas genannte Vorgehen ist in Abbildung 1 dargestellt. Es soll deutlichwerden, dass an Stelle der formalen Entwicklung zunächst das Rapid Prototypingsteht, dessen Ergebnisse dann zur formalen Planung des Projektsbeiträgt.Abbildung 1: Rapid Prototyping im ProjektflussBezugnehmend auf den DO-178B Standard kann diese Methodik verwendetwerden. Diese macht keine Vorgaben zur Verwendung bestimmter Methoden.Selbstverständlich müssen bestimmte Formalien eingehalten werdenum die Konformität zu wahren, jedoch wird Rapid Prototyping vor derformalen Planung durchgeführt. Da DO-178B auch keine Vorgehensmodellevorschreibt, ist eine Modellbasierter Ansatz in keinem Fall verbindlich.13Rapidprototypingist mitDO-178Bverwendbar

untersucht) und Blackbox-Tests (Code ist unbekannt) unterschieden werden.Eine mögliche Testvarianten ist z.B. die in der DO-178B beschriebene"Code Coverage Analysis". Die hiervon aufwendige Form stellt der "modifiedcondition / decision coverage" (MC/DC) Test dar (wird gefordert beiDAL-A Zertifizierung, [Inc92] Tabelle A-7). In DO-178B wird zwischen denTeststufen "Low-Level Test", "Software Integration Test" und "Hardware/-Software Integration Test" unterschieden. Diese Begriff sind ein Äquivalentzu den in der (nicht Avionik-) Literatur gebräuchlichen Begriffen: "UnitTesting", "Integeration Testing" und "System Integration Testing".4 Beispiel: Coding StandardEin Coding Standard beschreibt Regeln zur Quellcode-Erstellung, welcheder Programmierer einzuhalten hat. Der Umfang eines Coding Standardshängt von den Zielen ab, die durch ihn erreicht werden sollen. Aus diesemGrund gibt es auch keinen einheitlichen und für jedes Projekt verbindlichenCoding Standard. Dies ist schon allein deshalb nicht möglich, weil einCoding Standard für eine Programmiersprache erstellt wird und nicht aufeine andere angewandt werden kann.Ziele einesCodingStadardsMögliche Ziele eines Coding Standards können sein:• Erhöhen der Lesbarkeit...• Verbessern der Robustheit...• Vereinfachung der Wiederverwendbarkeit...• Senken des Abstraktionsgrads...• Erzeugen von Modularität...• Erhöhung der Wartbarkeit...• Umsetzung von Programmierparadigmen 2• Vermeidung von Redundanzen...... des/im Quellcode(s).Diese Ziele werden auf unterschiedlichen Wegen erreicht. Hierzu beschreibtein Coding Standard ein Regelwerk. Die Einhaltung dieser Regeln wirdvom Programmierer verlangt und kann durch bestimmte Softwarewerkzeugeüberprüft werden. Ein Compilier, der zur Übersetzung des Codes verwendetwird, stellt in der Regel hierzu keine Mechanismen bereit.Realisierungder Ziele2 Programmierparadigmen sind z.B. Imperative-, Deklarative-, Objektorientierte-,Komponentenorientierte-, ...- und Generische-Programmierung.15

Mögliche Ansätze für Regeln zur Realisierung der Ziele:• Verringerung des Sprachumfangs(Welche Funktionalitäten dürfen / dürfen nicht benutzt werden)• Formatierung des Quelltextes(Einrückung, Absätze/Umbrüche, Leerzeichen, ...)• Namenskonventionen(homogener Aufbau von Funktionsnamen, Variablennamen, ...)• Anwendung bestimmter Entwurfsmuster(Design-Patterns)• Typisierung(Wahl des Typs eines Symbols)• Einheitliche Kommentierung(Um beispielsweise eine automatische Dokumentierung 3 zu ermöglichen)Solche Regeln sind Programmierern auch als "Programmierstil" bekannt.Da jeder Programmierer einen eigenen Programmierstil entwickelt (vergleichbarmit dem Schriftbild eines Aufsatzes), fällt es dem Einzelnen oftschwer sich einem solchen Regelwerk zu unterwerfen - umfangreiche CodingStandards stoßen nicht selten zunächst auf Ablehnung beim Programmierer.Jedoch sind die Vorteile eines Coding Standards klar erkennbar; durchgute Strukturierung und Homogenität erhöht sich die Nachvollziehbarkeit.So kann sich ein Dritter schneller in einem, nicht von ihm geschriebenen,Quellcode zurechtfinden (Wartbarkeit). Dies erzeugt eine Unabhängigkeitvom einzelnen Programmierer und führt zwangsweise weg von der Denkweise(überzogen dargestellt): "Ich schreibe den Code so, dass nur ich ihnverstehe, um das Projekt von mir abhängig zu machen.".Zudem kann beispielsweise durch die Verwendung genormter Kommentareund unter Zuhilfenahme diverser Softwarewerkzeuge die Dokumentation zueinem großen Teil automatisiert werden.Aus meiner Erfahrung macht die Erstellung gewisser Konventionen schonbei einem Projekt an dem mehr als eine Person arbeitet Sinn. Allein dasEinhalten von Kommentar- und Namenskonventionen erleichtert die gemeinsameProgrammierung ungemein.ProgrammierstilProjektgröße4.1 Kriterien für die Auswahl eines StandardsWie im vorangestellten Abschnitt erwähnt, ist die Auswahl eines CodingStandards von mehreren Kriterien abhängig. Das wichtigste Kriterium ist16

die Programmiersprache in welcher Code geschrieben wird. Aber auch Kundenanforderungen,Forderungen durch Standards/Normen oder der Wunschnach gut strukturiertem Code sind Konstanten, die bei der Auswahl einesCoding Standards berücksichtigt werden müssen.Folgende Kriterien gehören zu den wichtigsten:• ProgrammierspracheAbhänig vonder Programmiersprache• Anforderungen durch Kunden• Forderung durch Standards und Normen (DO-178B, IEC 61508-7)• Anforderung durch ProjektpartnerWird, wie z.B. in DO-178B, kein expliziter Coding Standard vorgeschrieben,so muss eine Auswahl getroffen werden.Das Eingeben des Ausdrucks "Coding Standard" bei Google Suche liefertmehrere Hundert Treffer. Dies zeigt die enorme Anzahl an bereits vorhandenenCoding Standards für die Unterschiedlichsten Programmiersprachen(C, C++, Java, PHP, .net extentions, usw.). Dies kommt von der Tatsache,dass es eben keinen allgemeingültigen, sondern Projektspezifische, CodingStandards gibt.Welcher Coding Standard ist nun aber für das Projekt der richtige? Musszwangsläufig ein eigener erstellt werden? Was genau muss ein solcher Standardenthalten um zum Projekt zu passen?Die Antworten auf diese Fragen liefert der Projektrahmen.Die verwendete Programmiersprache schränkt die Auswahl bereits ein. Ebensosetzt die Art der Applikation einen Rahmen. Ein Coding Standard fürein Windows Programm, das Werte aus einer statischen Tabelle grafischaufbereitet, ist ein anderer, als der für eine sicherheitskritische Steuerung.Sicherheitskritikalität ist also auch bei Coding Standards ein zentrales Thema.Angenommen das zu entwickelnde System soll in C geschrieben werden undwird als sicherheitskritisch nach IEC 61508 eingestuft, so muss ein CodingStandard verwendet werden. Dies ist der Norm zu entnehmen und wirddurch Tabelle 3 verdeutlicht.Ein möglicher Coding Standard für die Konstellation C, safety-critical,IEC61508-konform, wäre MISRA-C. Dieser dient häufig in Projekten alsGrundlage zur Erstellung eines eigenen Standards. Auch in Avionikprojektenfließen oftmals teile des MISRA Coding Standards ein. Gernerell sindAvionikprojekte von Natur aus sehr mächtig in ihrer Gesamtkomplexität,deshalb werden für solche Projekte in der Regel immer eigene Coding Standardserstellt. Diese beruhen, neben den Kundenanforderungen und Anforderungendurch Normen, auf langer Erfahrung.C ist ohneCodingStandard nichtfür sicherheitskritischeSystemegeeignet3 Zur automatisierten Dokumentierung gibt es Werkzeuge, wie z.B. Doxygen oder Javadoc,welche eine einheitliche Struktur der Kommentare voraussetzten.17

Programmiersprache SIL1 SIL2 SIL3 SIL 4C + o - -C mit Teilmenge und Codierrichtlinieund Verwendung von statischenAnalysewerkzeugen++ ++ ++ ++"++": Das Verfahren oder die Maßnahme wird für diesen Sicherheits-Integritätslevel besonders empfohlen.[...]"+": Das Verfahren oder die Maßnahme wird für diesen Sicherheits-Integritätslevel empfohlen. [...]"o": Das Verfahren oder die Maßnahme hat keine Empfehlung für oder gegen die Verwendung."–": Das Verfahren oder die Maßnahme wird für diesen Sicherheits-Integritätslevel ausdrücklich nichtempfohlen.Tabelle 3: IEC61508 Empfehlungen für Programmiersprachen(gekürzt aus IEC 61508-7 [CEN01], S. 81, Tabelle C.1 -Empfehlungen für bestimmte Programmiersprachen)4.2 Mögliche Standards abhängig von derProgrammierspracheDas letzte Kapitel hat gezeigt, dass die Programmiersprache das wichtigsteKriterium zur Auswahl eines Coding Standards ist. Unter der Annahme,das ein Coding Standard für sicherheitskritische Embedded-Projekte gesuchtwird, werden hier Coding Standards in Abhängigkeit zur Programmiersprachegenannt.4.2.1 CC ist die in der Embedded-Programmierung am häufigsten eingesetzt Programmiersprache.Dies ergibt sich aus der sehr einfachen Möglichkeiten,direkt auf die Hardware zuzugreifen. Zudem lässt sich mit C eine gute Kontrolleüber die Ressourcen (Speicher, CPU) erreichen. C hat aber auch seineTücken - ein unerfahrener Programmierer macht schnell Fehler, die nichtoffensichtlich sind aber zu Nebeneffekten führen können die dann schwerdiagnostizierbar sind (Laufzeitüberprüfung). Ausserdem ist die Sprache C,wie sie in ISO 9899:1990 definiert ist, oft nicht eindeutig. So ist manchesVerhalten implementationsabhänig (Compiler) oder auch undefiniert. Ausdiesem Grund macht es Sinn eine Richtlinie für die Erstellung von C-Codezu verwenden.Der populärste C Coding Standard ist MISRA-C in der aktuellen FassungMISRA-C:2004 [MIS04].Dieser Coding Standard wurde von der Motor Industry Software ReliablilityAsscociation (MISRA) erarbeitet. Und enthält 141 Regeln von denen121 als verbindlich und 20 als empfohlen eingeordnet sind. MISRA-Cbeschreibt eine "sichere" Teilmenge der in ISO 9899:1990 definierten Pro-C ist im EmbeddedbereichState-of-theartMISRA-C18

grammiersprache C. Zudem ist der Coding Standard in Anlehnung an dieIEC 61508 erstellt. Die ursprüngliche Fassung war speziell für die Entwicklungim Automotivebereich ausgerichtet, mit der Fassung von 2004 wurdeder Standard aber verallgemeinert.Der Coding Standard beschreibt Regeln zu den folgenden Kategorien( [MIS04] S. 1):• Umgebung• Spracherweiterungen• Dokumentation• Character-Sets• Identifiers (Symbole)• Typen• Konstanten• Deklaration und Definition• Initialisierung• Arithmetische Type-Konvertierung• Pointer Type-Konvertierung• Expressions• Controll Statement Expressions• Control Statements• Switch Anweisungen• Funktionen• Pointer und Arrays• Strukturen und Unions• Präprozessoranweisungen• Standard-Librarys• Laufzeitfehler19

Neben den eigentlichen Regeln, wird im Dokument zum Standard aufProblemstellungen eingegangen, die sich in der Embedded-Entwicklung ergebenund die zu "unsicherem" Code führen können; und es werden häufigeFehler, die bei der Programmierung unter C gemacht werden, durch die Regelnausgeschlossen. Zudem wird die Absicht, die hinter einer Regel steckt,stets erklärt und häufig anhand von Beispielen verdeutlicht.Beispiele für Regeln, entnommen aus dem MISRA-C Standard [MIS04].• "Rule 9.1 (required): All automatic variables shall have been assigneda value before being used.The intent of this rule is that all variables shall have been written tobefore they are read. This does not necessarily require initialisationat declaration. [...]" [MIS04] S. 33• "Rule 11.1 (required): Conversions shall not be performed betweenpointer to a function and andy type other than an integral type.Conversion of a function pointer to a different type of pointer resultsin undefined behaviour. This means, for example, that a pointer toa function cannot be converted to a pointer to a different type offunction. " [MIS04] S. 47• "Rule 14.7 (required): A fucntion shall have a single point of exit atthe end of the function.This is required by IEC 61508, under good programming style." [MIS04]S. 61• "Rule 14.4 (required): The goto statement shall not be used." [MIS04]S. 61Es fällt schnell auf, dass die Regeln durch ihre do / do not Struktur sehrklar formuliert sind. Dies macht es für den Programmierer einfach sie anzuwenden.Allerdings ist es in der Praxis nicht immer Zweckmäßig alle 141Regeln strikt zu befolgen. Denn oftmals lässt sich eine Verletzung unter bestimmtenGegebenheiten nicht vermeiden. Hier hat sich die sog. DeviationProcedure durchgesetzt, in welcher der Programmierer Regeln, die er teilweiseoder gar nicht beachtet, dokumentiert (Warum war die Verletzungnotwendig?). Es gibt noch andere Formen der Deviation Procedure, z.B.die Project Deviation, bei der zu beginn des Projektes der anzuwendendeRegelsatz, sowie die zu ignorierenden Regeln festgelegt werden. In der Praxiswerden beide Varianten, teilweise auch in Kombination, angewandt.Klare StrukturAnpassung desStandards20

An dieser Stelle möchte ich eine Literaturempfehlung aussprechen. DasWerk "Safer C: Developing Software for High-Integrity and Safety-CriticalSystems" von Les Hatton [Hat95] verdeutlicht die Problematiken, die beider Verwendung von C in sicherheitskritischen Systemen auftreten undkann in gewisser Weise als Leitfaden bei der Entwicklung solcher Systemedienen.Leitfaden zurEntwicklung4.2.2 C++Da C++ in sicherheitskritischer Embedded-Software immer häufiger eingesetztwird, gibt es für diese Programmiersprache auch populäre CodingStandards.Der Joint Strike Fighter Air Vehicle C++ Coding Standard (JSF C++)[Cor05] der Teilweise auf vielen MISRA-C Regeln aufbaut, und aus derAvionik stammt, beschreibt erstmals die Verwendung von C++ in sicherheitskritischerEmbedded Software, in dem er eine Teilmenge von C++beschreibt. Hierzu definiert er 221 Regeln. Ein signifikanter Unterschiedwird durch Regeln zur Codemetrik sichtbar, welche in MISRA-C nicht vorhandensind. Beispielsweise legt der Standard die maximale Länge einerFunktion fest; "Rule 1: Any one function (or method) will contain no morethan 200 logical source lines of code (L-SLOCs)." ( [Cor05] S. 12)Nach dem Erscheinen des JSF C++, reagierte auch MISRA mit ihremMISRA-C++ [MIS08] Coding Standard auf die Situation, dass C++ vermehrtin der Embedded Software eingesetzt wird.C++ wirdimmer häufigereingesetztJSF C++MISRA-C++Der Einsatz von C++ in Sicherheitskritischen Systemen, bringt gewisseProbleme mit sich, auf diese reagieren die Coding Standards. Einige Beispielewerden im Folgenden aufgeführt:• Präprozessor Anweisungen sind bis auf "include-guards" nicht erlaubt• Starke Restriktionen für Kontrollstrukturen (if,else,switch,while,for,do)• Restriktionen bei der Verwendung von goto und setjmp/longjmp• Einschränkung von impliziten und expliziten Typecasts• Instanzvariablen in Klassen sind generell "private"• Restriktion der Mehrfachvererbung• Verwendung von dynamischer Speicher-allocation stark eingeschränkt(new, delete)Um den Nutzen und die Absicht die hinter diesen Konventionen stecktverstehen zu können, wird exemplarisch das Beispiel "Einschränkung von21

impliziten und expliziten Typecasts" aufgegriffen. Hinter dieser Einschränkungverbirgt sich die Anforderung nach der Portabilität von Quellcode,denn C++ definiert keine fixen Speichergrößen für die Standard-Datentypen.C++ (auch so C) führt arithmetische Operationen immer als int oder longaus.Das Codelisting 1 zeigt ein Beispiel, bei dem zwei Werte vom Datentypshort multipliziert werden. Das Ergebnis wird in einer integer Variablegespeichert. Das Ergebnis dieser arithmetischen Operation ist auf einem32Bit System definiert und wäre wie erwartet 100000, hingegen ist auf einem16Bit Rechner das Ergebnis nicht definiert, denn die int32 Variablewürde vor der Operation in eine int (16Bit) Variable gewandelt werden,das Ergebnis würde zu einem Überlauf führen und das falsche Ergebniswürde zurück in die int32 Variable geschrieben werden; "result" enthälteinen falschen Ergebniswert. Somit ist dieser Quellcode nicht auf ein 16bitSystem portierbar.EinrealitätsnahesBeispiel1 s h o r t a = 1 0 0 0 0 ;2 s h o r t b = 1 0 ;3 i n t 3 2 r e s u l t = a ∗ b ;Listing 1: Arithmetische Operation C++Ein weiteres Beispiel für Probleme mit Datentypen ist der C++ Datentyp"char". Denn er kann entweder signed oder unsigned sein. Deshalb darfer in beiden Coding Standards ohne Präfix nur zur Speicherung von Zeichenverwendet werden.Vergleich JSF C++ sowie MISRA-C++ beruhen auf vielen MISRA-CRegeln. Beide Standards erlauben Makros nur in sehr restriktiver Form.Ebenso fordern beide Standards defensive Programmiertechniken. Unterschiedewerden z.B. in den JSF C++ Regeln zum Codestil und Codemetrikensichtbar, diese enthält MISRA-C++ nicht. MISRA-C++ erlaubt Exceptions,nicht aber so JSF C++. Null-Pointer werden nach MISRA-C++durch das NULL-Macro gehandhabt, JSF C++ empfiehlt hier die Verwendungvon 0.4.2.3 JavaFür Java gibt es keinen repräsentativen Coding Standard für sicherheitskritischen,echtzeitfähigen Code. Dies lässt sich durch die Tatsache erklären,dass Java noch keinen wirklichen Einzug in den sicherheitskritischenEmbedded-Bereich gehalten hat. Zwar gibt es gut durchdachte Ansätzezum Einsatz von Java im Embedded-Bereich, so z.B. Real-Time Java undJava ist kaumgebräuchlich insafety-criticalSystemen22

die Jazelle 4 Technologie, allerdings finden diese in der Praxis noch kaumAnwendung. Langfristig gesehen wird Java auch im Embedded-Bereich eineimmer größere Rolle spielen. Somit darf man davon ausgehen, dass inden nächsten Jahren ein repräsentativer Coding Standard für Java für denEmbedded-Bereich erscheinen wird.(Um Verwechslungen vorzubeugen: Java wird in der Embedded Softwareeingesetzt (Handy, PDA, ...) allerdings nicht im Kontext der harten Echtzeitund Sicherheitskritikalität - hier sind C/C++ die momentan noch bessereAlternative.)4.3 MISRA-C CodebeispielIn diesem Kapitel wird der MISRA-C Coding Standard anhand von einemQuellcodebeispiel verdeutlicht. Hierzu wurde als Grundlage die "MISRA-CExemplar Suite" verwendet, diese enthält zu den meisten MISRA Regelnsehr ausführliche Codebeispiele. Um einen Überblick und ein Gefühl fürMISRA-C zu bekommen, wurde der nachfolgende Code (Listings 2, 3, 4und 5) aus Beispielen der Exemplar Suite erstellt und erweitert.Der Code enthält Kommentare (grün gefärbt), die auf die jeweiligen Regelnhinweisen und eine Aussage über die Konformität (compliant / notcompliant) der jeweiligen Code-Stelle machen.Listing 2: collection.c1 #i n c l u d e " mc2_types . h"2 #i n c l u d e "mc2_header . h"3 #i n c l u d e " s t d l i b . h"4 /∗5 ∗ 2 0 . 9 The i n p u t / output l i b r a r y s h a l l not be used i n p r o d u c t i o n code6 ∗/7 #i n c l u d e /∗ Not Compliant to i n c l u d e s t d i o . h ∗/8 /∗9 ∗ 2 0 . 1 2 The time h a n d l i n g f u n c t i o n s o f s h a l l not be used10 ∗/11 #i n c l u d e /∗ Not Compliant to i n c l u d e time . h ∗/12131415 /∗16 ∗ 2 . 3 The c h a r a c t e r s e q u e n c e17 ∗ "/∗" s h a l l not be used w i t h i n a comment . Not Compliant18 ∗/19 #d e f i n e DISABLE_IRQS asm { "CLI" }20 #d e f i n e ENABLE_IRQS asm { " SEI " }2122 s t a t i c v o i d mc2_0201_fn1 ( v o i d ) ;23 s t a t i c v o i d mc2_0201_fn2 ( v o i d ) ; // This comment i s Not Compliant : Rule 2 . 224 s t a t i c v o i d mc2_0201_fn3 ( v o i d ) ;25 s t a t i c v o i d mc2_0401_fn1 ( v o i d ) ;26 s t a t i c v o i d mc2_0601_fn1 ( v o i d ) ;27 s t a t i c v o i d mc2_0701_fn1 ( v o i d ) ;28 s t a t i c v o i d mc2_0802_fn1 ( c o n s t int32_t q u a l i f i e r _ p a r a m ) ;29 s t a t i c v o i d mc2_0807_fn1 ( v o i d ) ;30 s t a t i c v o i d mc2_0901_fn1 ( v o i d ) ;31 s t a t i c v o i d mc2_1306_fn1 ( v o i d ) ;32 s t a t i c v o i d mc2_2004_fn1 ( v o i d ) ;3334 /∗35 ∗ 9 . 3 In an enumerator l i s t , the "=" c o n s t r u c t s h a l l not be used t o36 ∗ e x p l i c i t l y i n i t i a l i s e members o t h e r than the f i r s t , u n l e s s a l l37 ∗ i t e m s a r e e x p l i c i t l y i n i t i a l i s e d .38 ∗/4 Jazelle ist eine von ARM entwickelte Technologie, die darauf abzielt eine Java VMdirekt in den Prozessor zu integrieren (Stichwort: Java Prozessor). Es gibt bereitsProzessoren die diese Technik teilweise unterstützen, z.B. ARM7EJ-S.23

39 t y p e d e f enum40 {41 mc2_0903_green_1 ,42 mc2_0903_yellow_1 = 5 /∗ Not Compliant ∗/43 } mc2_0903_colour_1 ;4445 t y p e d e f enum46 {47 mc2_0903_green_2 = 5 ,48 mc2_0903_yellow_2 = 5 /∗ Compliant ∗/49 } mc2_0903_colour_2 ;5051 /∗52 ∗ 6 . 4 B i t f i e l d s s h a l l o n l y be d e f i n e d to be o f type u n s i g n e d i n t or s i g n e d53 ∗ i n t .54 ∗/55 s t r u c t b i t f i e l d56 {57 u n s i g n e d bf_unsigned : 4 ;58 s i g n e d bf_signed : 2 ;59 u n s i g n e d i n t bf_unsigned_i : 6 ;60 s i g n e d i n t bf_signed_i : 5 ;61 i n t b f _ i n t : 5 ; /∗ Not Compliant ∗/62 char bf_char : 6 ; /∗ Not Compliant ∗/63 enum bf_enum { bf_enumerated } : 2 ; /∗ Not Compliant ∗/64 s h o r t bf_short : 5 ; /∗ Not Compliant ∗/65 u n s i g n e d char bf_unsigned_char : 3 ; /∗ Not Compliant ∗/66 } ;6768 /∗69 ∗ 8 . 7 O b j e c t s s h a l l be d e f i n e d at b l o c k s c o p e i f they a r e o n l y a c c e s s e d from70 ∗ w i t h i n a s i n g l e f u n c t i o n .71 ∗/72 s t a t i c int32_t should_be_local ; /∗ Not Compliant ∗/7374 s t a t i c v o i d mc2_0807_fn1 ( v o i d )75 {76 s t a t i c int32_t l o c a l _ s s d = 0 ; /∗ Compliant ∗/77 }787980 /∗81 ∗ 2 . 1 Assembly l a n g u a g e s h a l l be e n c a p s u l a t e d and i s o l a t e d .82 ∗ A l l use o f a s s e m b l e r i n t h i s f i l e i s not c o m p l i a n t with Rule 1 . 183 ∗/84 /∗ Conforming example − a l l a s s e m b l e r i s e n c a p s u l a t e d i n MACROS ∗/85 s t a t i c v o i d mc2_0201_fn1 ( v o i d )86 {87 DISABLE_IRQS ; /∗ D i s a b l e a l l i n t e r r u p t s . ∗/88 use_int16 ( 0 ) ; /∗ Do something . ∗/89 ENABLE_IRQS; /∗ Enable a l l i n t e r r u p t s . ∗/90 }9192 /∗ Non−conforming example − a s s e m b l e r and ’C ’ a r e mixed i n a ’C ’ f u n c t i o n . ∗/93 s t a t i c v o i d mc2_0201_fn2 ( v o i d )94 {95 asm { "CLI" } ; /∗ Not Compliant ∗/96 use_int16 ( 1 ) ; /∗ Do something . ∗/97 asm { " SEI " } ; /∗ Not Compliant ∗/98 }99100 /∗ Conforming example − a l l a s s e m b l e r i s e n c a p s u l a t e d i n a ’C ’ f u n c t i o n . ∗/101 s t a t i c v o i d mc2_0201_fn3 ( v o i d )102 {103 asm { "CLI" } ; /∗ D i s a b l e a l l i n t e r r u p t s . ∗/104 asm { "NOP" } ; /∗ Do n o t h i n g . ∗/105 asm { " SEI " } ; /∗ Re−e n a b l e a l l i n t e r r u p t s . ∗/106 }107108 s t a t i c v o i d mc2_0401_fn1 ( v o i d )109 {110 /∗ Not Compliant − a l l hexadecimal e s c a p e s e q u e n c e s a r e banned ∗/111 /∗ 4 . 1 Only t h o s e e s c a p e s e q u e n c e s t h a t a r e d e f i n e d i n the ISO C s t a n d a r d s h a l l be used .112 /∗ The f o l l o w i n g l i s t i s not e x h a u s t i v e ∗/113 use_char ( ’ \ x0 ’ ) ; /∗ Not Compliant ∗/114 use_char ( ’ \ x01 ’ ) ; /∗ Not Compliant ∗/115 use_char ( ’ \ x12 ’ ) ; /∗ Not Compliant ∗/116 use_char ( ’ \xAB ’ ) ; /∗ Not Compliant ∗/117118 /∗ 4 . 2 T r i g r a p h s s h a l l not be used . ∗/119 /∗ T r i g r a p h s − Non Compliant ∗/120 use_char_ptr ( " ? ? ( " ) ; /∗ Not Compliant ∗/121 use_char_ptr ( " ? ? ) " ) ; /∗ Not Compliant ∗/122 use_char_ptr ( "??

132 {133 char_t c h a r a c t e r _ v a l u e = ’ a ’ ; /∗ Compliant ∗/134 char_t p l a i n _ c h a r a c t e r _ d a t a = ’ b ’ ;135 int8_t numeric_value = 5 ;136 int8_t signed_numeric_value = 0 ;137 uint8_t unsigned_numeric_value = 0U; /∗ U to comply with Rule 1 0 . 6 ∗/138139 use_char ( c h a r a c t e r _ v a l u e ) ;140 /∗ Compliant − but i m p l e m e n t a t i o n dependent ∗/141 c h a r a c t e r _ v a l u e = ( char_t ) numeric_value ;142143 w h i l e ( c h a r a c t e r _ v a l u e == numeric_value ) /∗ Not Compliant − t y p e s ∗/144 {145 w h i l e ( c h a r a c t e r _ v a l u e == ’ 2 ’ )146 {147 c h a r a c t e r _ v a l u e = numeric_value ; /∗ Not Compliant ∗/148 }149 }150151 w h i l e ( signed_numeric_value == ’ 1 ’ ) /∗ Not Compliant ∗/152 {153 unsigned_numeric_value = p l a i n _ c h a r a c t e r _ d a t a ;154 }155 }156157 /∗158 ∗ 7 . 1 Octal c o n s t a n t s ( o t h e r than z e r o ) and o c t a l e s c a p e s e q u e n c e s s h a l l not be159 ∗ used .160 ∗/161 s t a t i c v o i d mc2_0701_fn1 ( v o i d )162 {163 int8_t o c t a l _ c o n s t , n_octal_const ;164 char_t ∗ n_octal_point = " abc \017 " ; /∗ Not Compliant ∗/165166 n_octal_const = 0 1 7 ; /∗ Not Compliant ∗/167168 }169170 /∗171 ∗ 8 . 2 Whenever an o b j e c t or f u n c t i o n i s d e c l a r e d o r d e f i n e d , i t ’ s type s h a l l be172 ∗ e x p l i c i t l y s t a t e d .173 ∗/174 /∗ 8 . 3 For each f u n c t i o n parameter the type g i v e n i n the d e c l a r a t i o n and175 ∗ d e f i n i t i o n s h a l l be i d e n t i c a l , and the r e t u r n t y p e s s h a l l a l s o be176 ∗ i d e n t i c a l .177 ∗/178 s t a t i c v o i d mc2_0802_fn1 ( int32_t q u a l i f i e r _ p a r a m ) /∗ Not Compliant ∗/179 {180 c o n s t i m p l i c i t _ c o n s t _ i n t = 1 ; /∗ Not Compliant − i m p l i c i t type ∗/181 c o n s t int16_t e x p l i c i t _ c o n s t _ i n t = 2 ;182 }183184 /∗185 ∗ 9 . 1 A l l automatic v a r i a b l e s s h a l l have been a s s i g n e d a v a l u e b e f o r e186 ∗ b e i n g used .187 ∗/188 s t a t i c v o i d mc2_0901_fn1 ( v o i d )189 {190 int32_t v a r i a b l e 1 = 1 ;191 int32_t v a r i a b l e 2 = 1 ;192 int32_t v a r i a b l e 3 ;193 int32_t v a r i a b l e 4 ;194195 v a r i a b l e 1 = v a r i a b l e 2 ; /∗ Compliant ∗/196 v a r i a b l e 3 = v a r i a b l e 4 ; /∗ Not Compliant ∗/197 }198199 /∗200 ∗ 1 3 . 6 Numeric v a r i a b l e s b e i n g used w i t h i n a f o r l o o p f o r i t e r a t i o n201 ∗ c o u n t i n g s h a l l not be m o d i f i e d i n the body o f the l o o p .202 ∗203 ∗/204 s t a t i c v o i d mc2_1306_fn1 ( v o i d )205 {206 uint16_t mc2_1306_var1 ;207 uint16_t mc2_1306_var2 ;208209 mc2_1306_var1 = 5U;210211 f o r ( mc2_1306_var2 = 1U;212 ( mc2_1306_var2 < 22U ) && ( mc2_1306_var1 != 8U ) ;213 mc2_1306_var2++ )214 {215 mc2_1306_var2 = mc2_1306_var2 + mc2_1306_var1 ; /∗ Not c o m p l i a n t ∗/216 mc2_1306_var1 = 6U ( ) ;217 }218 }219220 /∗221 ∗ 2 0 . 4 Dynamic heap memory s h a l l not be used .222 ∗/223 s t a t i c v o i d mc2_2004_fn1 ( v o i d )224 {25

225 char_t ∗ mc2_2004_p ;226227 mc2_2004_p = ( char_t ∗ ) m a l l o c ( 11U ) ; /∗ Not Compliant : use o f m a l l o c ∗/228 ( v o i d ) r e a l l o c ( mc2_2004_p , 20U ) ; /∗ Not Compliant : use o f r e a l l o c ∗/229 f r e e ( mc2_2004_p ) ; /∗ Not Compliant : use o f f r e e ∗/230 }231232 v o i d mc2 ( v o i d )233 {234 c o n s t int32_t q u a l i f i e r _ p a r a m = 1 0 ;235 /∗ Not c o m p l i a n t : 2 . 4 S e c t i o n s o f code s h o u l d not be "commented out " . ∗/236 /∗237 mc2_0201_fn1 ( ) ;238 ∗/239 mc2_0201_fn2 ( ) ;240 mc2_0201_fn3 ( ) ;241 mc2_0401_fn1 ( ) ;242 mc2_0601_fn1 ( ) ;243 mc2_0701_fn1 ( ) ;244 mc2_0802_fn1 ( q u a l i f i e r _ p a r a m ) ;245 mc2_0807_fn1 ( ) ;246 mc2_0901_fn1 ( ) ;247 mc2_1306_fn1 ( ) ;248 mc2_2004_fn1 ( ) ;249 }250251252 /∗ end o f mc2_0201 . c ∗/1 #i n c l u d e " mc2_types . h"2 #i n c l u d e "mc2_header . h"34 int32_t main ( v o i d ) ;56 int32_t main ( v o i d )7 {8 mc2 ( ) ;910 r e t u r n 0 ;11 }Listing 3: mc2_main.cListing 4: mc2_types.h1 #i f n d e f MC2_TYPES_H2 #d e f i n e MC2_TYPES_H34 t y p e d e f s i g n e d i n t bool_t ; /∗ Used f o r Boolean by e n f o r c e m e n t examples ∗/5 t y p e d e f char char_t ;6 t y p e d e f s i g n e d char int8_t ;7 t y p e d e f s i g n e d s h o r t int16_t ;8 t y p e d e f s i g n e d i n t int32_t ;9 t y p e d e f s i g n e d l o n g int64_t ;10 t y p e d e f u n s i g n e d char uint8_t ;11 t y p e d e f u n s i g n e d s h o r t uint16_t ;12 t y p e d e f u n s i g n e d i n t uint32_t ;13 t y p e d e f u n s i g n e d l o n g uint64_t ;14 t y p e d e f f l o a t f l o a t 3 2 _ t ;15 t y p e d e f double f l o a t 6 4 _ t ;16 t y p e d e f l o n g double f l o a t 1 2 8 _ t ;1718 #e n d i f1 #i f d e f MC2_HEADER_H23 #e r r o r F i l e mc2_header . h i n c l u d e d 2nd time45 #e l s e6 #d e f i n e MC2_HEADER_H78 /∗ F u n c t i o n s r e t u r n i n g a v a r i a b l e ∗/910 e x t e r n bool_t get_bool ( v o i d ) ;11 e x t e r n char_t get_char ( v o i d ) ;12 e x t e r n int8_t g e t _ i n t 8 ( v o i d ) ;13 e x t e r n int16_t g e t _ i n t 1 6 ( v o i d ) ;14 e x t e r n int32_t g e t _ i n t 3 2 ( v o i d ) ;15 e x t e r n int64_t g e t _ i n t 6 4 ( v o i d ) ;16 e x t e r n uint8_t get_uint8 ( v o i d ) ;17 e x t e r n uint16_t get_uint16 ( v o i d ) ;18 e x t e r n uint32_t get_uint32 ( v o i d ) ;19 e x t e r n uint64_t get_uint64 ( v o i d ) ;20 e x t e r n f l o a t 3 2 _ t g e t _ f l o a t 3 2 ( v o i d ) ;21 e x t e r n f l o a t 6 4 _ t g e t _ f l o a t 6 4 ( v o i d ) ;22 e x t e r n f l o a t 1 2 8 _ t g e t _ f l o a t 1 2 8 ( v o i d ) ;Listing 5: mc2_header.h26

2324 e x t e r n bool_t ∗ get_bool_ptr ( v o i d ) ;25 e x t e r n char_t ∗ get_char_ptr ( v o i d ) ;26 e x t e r n int8_t ∗ get_int8_ptr ( v o i d ) ;27 e x t e r n int16_t ∗ get_int16_ptr ( v o i d ) ;28 e x t e r n int32_t ∗ get_int32_ptr ( v o i d ) ;29 e x t e r n int64_t ∗ get_int64_ptr ( v o i d ) ;30 e x t e r n uint8_t ∗ get_uint8_ptr ( v o i d ) ;31 e x t e r n uint16_t ∗ get_uint16_ptr ( v o i d ) ;32 e x t e r n uint32_t ∗ get_uint32_ptr ( v o i d ) ;33 e x t e r n uint64_t ∗ get_uint64_ptr ( v o i d ) ;34 e x t e r n f l o a t 3 2 _ t ∗ g e t _ f l o a t 3 2 _ p t r ( v o i d ) ;35 e x t e r n f l o a t 6 4 _ t ∗ g e t _ f l o a t 6 4 _ p t r ( v o i d ) ;36 e x t e r n f l o a t 1 2 8 _ t ∗ g e t _ f l o a t 1 2 8 _ p t r ( v o i d ) ;3738 /∗ F u n c t i o n s t h a t use a v a r i a b l e ∗/3940 e x t e r n v o i d use_bool ( bool_t use_bool_param ) ;41 e x t e r n v o i d use_char ( char_t use_char_param ) ;42 e x t e r n v o i d use_int8 ( int8_t use_int8_param ) ;43 e x t e r n v o i d use_int16 ( int16_t use_int16_param ) ;44 e x t e r n v o i d use_int32 ( int32_t use_int32_param ) ;45 e x t e r n v o i d use_int64 ( int64_t use_int64_param ) ;46 e x t e r n v o i d use_uint8 ( uint8_t use_uint8_param ) ;47 e x t e r n v o i d use_uint16 ( uint16_t use_uint16_param ) ;48 e x t e r n v o i d use_uint32 ( uint32_t use_uint32_param ) ;49 e x t e r n v o i d use_uint64 ( uint64_t use_uint64_param ) ;50 e x t e r n v o i d u s e _ f l o a t 3 2 ( f l o a t 3 2 _ t use_float32_param ) ;51 e x t e r n v o i d u s e _ f l o a t 6 4 ( f l o a t 6 4 _ t use_float64_param ) ;52 e x t e r n v o i d u s e _ f l o a t 1 2 8 ( f l o a t 1 2 8 _ t use_float128_param ) ;5354 e x t e r n v o i d use_bool_ptr ( bool_t ∗ use_bool_ptr_param ) ;55 e x t e r n v o i d use_char_ptr ( char_t ∗ use_char_ptr_param ) ;56 e x t e r n v o i d use_int8_ptr ( int8_t ∗ use_int8_ptr_param ) ;57 e x t e r n v o i d use_int16_ptr ( int16_t ∗ use_int16_ptr_param ) ;58 e x t e r n v o i d use_int32_ptr ( int32_t ∗ use_int32_ptr_param ) ;59 e x t e r n v o i d use_int64_ptr ( int64_t ∗ use_int64_ptr_param ) ;60 e x t e r n v o i d use_uint8_ptr ( uint8_t ∗ use_uint8_ptr_param ) ;61 e x t e r n v o i d use_uint16_ptr ( uint16_t ∗ use_uint16_ptr_param ) ;62 e x t e r n v o i d use_uint32_ptr ( uint32_t ∗ use_uint32_ptr_param ) ;63 e x t e r n v o i d use_uint64_ptr ( uint64_t ∗ use_uint64_ptr_param ) ;64 e x t e r n v o i d u s e _ f l o a t 3 2 _ p t r ( f l o a t 3 2 _ t ∗ use_float32_ptr_param ) ;65 e x t e r n v o i d u s e _ f l o a t 6 4 _ p t r ( f l o a t 6 4 _ t ∗ use_float64_ptr_param ) ;66 e x t e r n v o i d u s e _ f l o a t 1 2 8 _ p t r ( f l o a t 1 2 8 _ t ∗ use_float128_ptr_param ) ;676869 e x t e r n v o i d mc2 ( v o i d ) ;7071 #e n d i f4.4 Prüfung der EinhaltungSicherheitskritische Standards und Normen fordern eine Überprüfung undAnalyse des Codes durch geeignete Programme. Zum einen soll die Einhaltungeines vorgegebenen Coding Standards überprüft werden, zum anderensoll die Komplexität des Codes (Nesting usw.) bestimmt werden. ZurDurchführung dieser Aufgabe gibt es Software-Werkzeuge, die den Code(semi-)automatisch statisch überprüfen können.OpenSource Programme zur "statischen Code-Analyse":• BLAST• Fragma-C• SplintKommerzielle Programme zur "statischen Code-Analyse":• Greenhills Software Double Check• LDRA Testbed27

• PC-Lint• QA-C• Red Lizard’s GoannaPC-Lint und QA-C zählen zu den bekanntesten Code-Analyse-Tools. DieTestergebnisse dieser Werkzeuge können zur Zertifizierung nach den StandardsDO-178B sowie IEC 61508 beitragen.Exemplarisch wird PC-Lint vorgestellt. PC-Lint ist allgemein gesprochenein "Rule-Checker". Anhand von einem vorgegebenen Regelwerk wirdQuelltext auf Konformität überprüft. PC-Lint bringt MISRA-C bereits alsRegelwerk mit (zu dem Enthält es Prüfungen zu Scott Mayers EffectiveC++ und Dan Saks), eine Anpassung der Regeln ist jederzeit manuellmöglich. Es kann also auch ein neuer, selbst erstellter Standard eingepflegtwerden. Dies ist in Anbetracht des häufigen Einsatzes von Deviation Procedures(wie in Abschnitt 4.2.1) sinnvoll.PC-Lint ist ein Werkzeug, das sich in die bekannteren Entwicklungsumgebungenintegrieren lässt. Somit ist eine Ausführung bequem per Mausklickmöglich. Alternativ lässt sich PC-Lint komplett über die Befehlszeile bedienen,dies führt zu einer hohen Flexibilität in der Anwendung.Die Prüfung lässt sich für ein ganzes Projekt oder aber für ein Modul durchführen.PC-Lint erzeugt nach einem Prüflauf eine Ausgabe-Datei, in derdie gefundenen nicht konformen Codestellen vermerkt sind. Wurde bei derKonfiguration zusätzlich noch das Regelwerk von Mayers und/oder Saks gewählt,dann bekommt man außerdem hinweise auf potentielle Fehlerquellenim analysierten Code. Das Ganze kann man sich ähnlich wie die Fehlermeldungeneines Compilers vorstellen. Und in der Tat lässt sich, z.B. in VisualStudio 5 , die PC-Lint Ausgabe elegant in das Konsolen-Fenster umleiten.PC-LintIntegration inIDEEs bedarf etwas Einarbeitungszeit um den Umgang mit diesem Werkzeugzu beherrschen. Unterstützend wirken hierbei die Ausführliche Dokumentationsowie Beispiele.Wie bereits erwähnt wurde, ist PC-Lint ein kommerzielles Tool, das aber imVergleich zu ähnlichen Produkten in der unteren Preisklasse 6 schwebt. Leiderstellt der Hersteller "Gimpel Software" keine Testversion bereit, jedochbietet die Herstellerwebseite 7 eine Live-Demo, in der man auch selbstgeschriebenenCode Prüfen lassen kann.Aus meiner Sicht, ist PC-Lint den in der Auflistung (s.o.) genannten open-Source Prüfwerkzeugen überlegen. Dies äußert sich durch seinen großenUmfang, die ausgereifte Art eigene Regeln ein zu pflegen, seiner hohenAkzeptanz in der Industrie und nicht zuletzt der Anerkennung durch dieZertifizierungsstellen.5 IDE von Microsoft.6 Preisliste auf Herstellerwebseite: http://www.gimpel.com7 vgl. Fn. 6.28

5 ZusammenfassungDiese Arbeit hat gezeigt, dass bei der Entwicklung von sicherheitskritischenSystemen bestimmte Richtlinien eingehalten werden müssen. DieseRichtlinien werden zum einen von den zuständigen Zertifzierungsbehördenvorgeschrieben, können aber auch zum anderen selbst erweitert und angepasstwerden.Es hat sich herausgestellt das die Anwendung von Richtlinien auch beiunkritischen Systemen Sinn macht, denn dadurch wird dem Projekt einstrukturierter Rahmen vorgegeben.Es wurde deutlich, dass diese Standards in der Regel zwar keine konkretenMethoden zur Software-Entwicklung vorschreiben, jedoch in der Praxisoftmals ein objektorientiertes und modellorientiertes Vorgehen gewähltwird. Die letztendliche Implementierung durch Code geschieht jedoch manuell,und höchstens in Anlehnung an ein Modell. Auf keinen Fall wird aberein Modell 1:1 umgesetzt. 8 Es hat sich weiter gezeigt, dass die Beschreibungsolcher Modelle oftmals durch formale, mathematische Sprachen erfolgt.Um die Auswirkungen, die Zertifizierungsrichtlinien auf den letztendlicherstellten Code haben, zu verdeutlichen, wird der Begriff Coding Standardeingeführt. Und es wird vermittelt, dass ein solcher durch die meisten Zertifzierungsrichtlinienvorgeschrieben ist. Es zeigte sich, dass die Auswahleines Coding Standards stark von der verwendeten Programmierspracheund den Anforderungen durch Zertifzierungsrichtlinien abhängt.Um ein konkretes Beispiel aus der Industrie anzuführen, wurde der MISRA-C Coding Standard ausführlich betrachtet und durch Beispiele dessen Anwendungerläutert. Um die Einhaltung eines Coding Standards zu Prüfen,wurden Testwerkzeuge vorgestellt, die für diese Aufgabe geeignet sind.Fazit Diese Arbeit hat deutlich gemacht, wie komplex und anspruchsvolldie Entwicklung von sicherheitskritischen Systemen ist. Und es wird klar,dass Dokumentation (im weitesten Sinne) für einen sehr hohen Aufwandsorgt, der aber unumgänglich ist (Avionik Projektaufwand: 10% Code-Erstellung; 90% Tests, Dokumentation, Verifizierung & Validierung, Management,Zertifizierung).8 Ein Modell ist ein Abbild der Wirklichkeit, nicht jedoch die Wirklichkeit selbst. Dieswird oftmals vergessen oder falsch verstanden.29

Literatur[AbRS94] Dr. Ramon Acosta, Carla burns, William Rzepka, and JamesSidoran. Applying Rapid Prototyping Techniques in the RequirementsEngineering Environment. IEEE, 1994.[BB87][BH99]Bolognesi and Brinksma. Introduction to the ISO specificationlanguage LOTOS. Computer Networks and ISDN Systems, 1987.http://jucmnav.softwareengineering.ca/ftp/pub/Lotos/Intro/BB-LotosTutorial.pdf.Bharadway and Heitmeyer. Hardware / Software co-design andco-validation using SCR method. IEEE, 1999.[CEN01] CENELEC. Europäische Norm 61508: Funktionale Sicherheitsicherheitsbezogener elektrischer/elektronischer/programmierbarerelektronischer Systeme (Deutsche Fassung). VDE VERLAGGMBH, Berlin, 2001.[Cor05]Lockheed Martin Corporation. Joint Strike Fighter Air VehicleC++ Coding Standards for the system development and demonstrationprogram. MISRA Limited, 2005.[FK04] Peter Forbrig and Immo Kerner. Softwareentwicklung. FachbuchverlagLeipzig, München, 1. auflage edition, 2004. ISBN3-446-22578-1.[Hat95][Inc92][Jon90][MIS04][MIS08][Spi92]Les Hatton. Safer C: Developing Software for High-Integrity andSafety-Critical Systems (The Mcgraw-Hill International Seriesin Software Engineering). McGraw-Hill Companies, 1995. ISBN9780077076405.RTCA Inc. Software Considerations in Airborne Systems andEquipment Certification. RTCA, Washington D.C. / USA, 1992.Cliff Jones. Systematic Software Development using VDM. Prenticehall, New York, 2. auflage edition, 1990. ISBN 0-1388-0733-7.MISRA. MISRA-C: 2004, Guidelines for the use of the C languagein critical systems. MISRA Limited, Warwickshire UK,2004. ISBN 0-9524-1562-3.MISRA. MISRA-C++: 2008, Guidelines for the use of the C++language in critical systems. MISRA Limited, Warwickshire UK,2008.J. M. Spivey. The Z Notation: A Reference Manual. Prenticehall, New York, 2. auflage edition, 1992. ISBN 0-1397-8529-9.30