Avionik-Software ist eingebettete Software mit gesetzlich beauftragten Sicherheits- und in der Avionik verwendeten Zuverlässigkeitssorgen. Der Hauptunterschied zwischen Luftfahrt-Software und herkömmlicher eingebetteter Software ist, dass der Entwicklungsprozess durch das Gesetz erforderlich ist und für die Sicherheit optimiert wird.

Es wird gefordert, dass der Prozess, der unten beschrieben ist, nur ein bisschen langsamer und kostspieliger ist (vielleicht 15 Prozent), als das normale ad hoc verwendet für die kommerzielle Software in einer Prozession geht. Da der grösste Teil der Software wegen Fehler scheitert, die Fehler an frühestmöglich beseitigend, ist Schritt auch eine relativ billige, zuverlässige Weise, Software zu erzeugen. In einigen Projekten, jedoch, dürfen Fehler in den Spezifizierungen nicht bis zur Aufstellung entdeckt werden. An diesem Punkt können sie sehr teuer sein, um zu befestigen.

Die Grundidee jedes Softwareentwicklungsmodells besteht darin, dass jeder Schritt des Designprozesses genannten "deliverables" von Produktionen hat. Wenn die deliverables für die Genauigkeit geprüft und befestigt werden, dann können normale menschliche Fehler nicht in gefährliche oder teure Probleme leicht hineinwachsen. Die meisten Hersteller folgen dem Wasserfall-Modell, um das Designprodukt zu koordinieren, aber fast alle erlauben ausführlich früherer Arbeit, revidiert zu werden. Das Ergebnis ist öfter an einem spiralförmigen Modell näher.

Weil eine Übersicht der eingebetteten Software eingebettetes System und Softwareentwicklungsmodelle sieht. Der Rest dieses Artikels nimmt Vertrautheit mit dieser Information an, und bespricht Unterschiede zwischen kommerziellen eingebetteten Systemen und kommerziellen Entwicklungsmodellen.

Allgemeine Übersicht

Da die meisten Avionik-Hersteller Software als eine Weise sehen, Wert hinzuzufügen, ohne Gewicht hinzuzufügen, nimmt die Wichtigkeit von der eingebetteten Software in Luftfahrt-Systemen zu.

Modernste kommerzielle Flugzeuge mit automatischen Kurssteuerungen verwenden Flugcomputer und so genannte Flugverwaltungssysteme, die das Flugzeug ohne das aktive Eingreifen des Piloten während bestimmter Phasen des Flugs fliegen können. Auch unter der Entwicklung oder in der Produktion sind entmannte Fahrzeuge: Raketen und Drohnen, die sich entfernen können, machen Sie eine Kreuzfahrt und landen Sie ohne Bordversuchseingreifen.

In vielen dieser Systeme ist Misserfolg unannehmbar. Die Zuverlässigkeit der Software, die in Bordfahrzeugen (bürgerlich oder militärisch) läuft, wird durch die Tatsache gezeigt, dass der grösste Teil von Luft geborene Unfälle wegen manueller Fehler vorkommt.

Durchführungsprobleme

Wegen der Sicherheitsvoraussetzungen regeln die meisten Nationen Avionik, oder nehmen mindestens Standards im Gebrauch durch eine Gruppe von Verbündeten oder einen Zollverein an. Die drei Durchführungsorganisationen, dass die meisten internationale Flugentwicklung betreffen, sind die Vereinigten Staaten, der E.U. und Russland.

In den Vereinigten Staaten haben Luftfahrt und andere Flugzeugsbestandteile Sicherheits- und Zuverlässigkeitsstandards, die durch die Bundesflugregulierungen, den Teil 25 für Transportflugzeuge, den Teil 23 für Kleine Flugzeuge und die Teile 27 und 29 für Rotorcraft beauftragt sind. Diese Standards werden von "benannten Technikvertretern" des FAA beachtet, die gewöhnlich von einem Hersteller bezahlt und durch den FAA bescheinigt werden.

In der Europäischen Union beschreibt der IEC "empfohlen" (obligatorisch!) Voraussetzungen für sicherheitskritische Systeme, die gewöhnlich ohne Änderung von Regierungen angenommen werden. Ein sicheres, zuverlässiges Stück der Avionik hat einen "CE Mark." Die Durchführungseinordnung ist bemerkenswert ähnlich, um Sicherheit in den Vereinigten Staaten und Kanada anzuzünden. Die Regierung bescheinigt Probelaboratorien, und die Laboratorien bescheinigen sowohl verfertigte Sachen als auch Organisationen. Im Wesentlichen wird das Versehen der Technik von der Regierung und dem Hersteller zum Probelaboratorium ausgegliedert.

Um Sicherheit und Zuverlässigkeit zu sichern, verlangen nationale Aufsichtsbehörden (z.B der FAA, CAA oder DOD) Softwareentwicklungsstandards. Einige vertretende Standards schließen MIL-STD-2167 für militärische Systeme ein, oder RTCA TUN - 178B für das Zivilflugzeug.

Die Durchführungsvoraussetzungen für die Software können im Vergleich zu anderer Software teuer sein, aber sie sind gewöhnlich das Minimum, das erforderlich ist, die notwendige Sicherheit zu erzeugen.

Entwicklungsprozess

Der Hauptunterschied zwischen Avionik-Software und anderen eingebetteten Systemen ist, dass die wirklichen Standards häufig viel ausführlicher und streng sind als kommerzielle Standards, die gewöhnlich durch Dokumente mit Hunderten von Seiten beschrieben sind.

Da der Prozess gesetzlich erforderlich ist, haben die meisten Prozesse Dokumente oder Software, um Voraussetzungen aus numerierten Paragrafen in den Spezifizierungen und Designs zu genauen Stücken des Codes, mit genauen Tests auf jeden und einem Kasten auf der Endzertifikat-Checkliste zu verfolgen. Das soll Übereinstimmung dem gesetzlich beauftragten Standard spezifisch beweisen.

Abweichungen von einem spezifischen Projekt bis die Prozesse beschrieben hier können wegen des Gebrauchs von alternativen Methoden oder niedrigen Sicherheitsniveau-Voraussetzungen vorkommen.

Fast alle Softwareentwicklungsstandards beschreiben, wie man durchführt und Spezifizierungen, Designs, das Codieren und die Prüfung verbessert (Sieh Softwareentwicklungsmodell). Jedoch fügen Avionik-Softwareentwicklungsstandards einige Schritte zur Entwicklung für die Sicherheit und das Zertifikat hinzu:

Menschliche Schnittstellen

Projekte mit wesentlichen menschlichen Schnittstellen sind gewöhnlich prototyped oder vorgetäuscht. Die Videokassette wird gewöhnlich behalten, aber der Prototyp hat sich sofort zurückgezogen nach der Prüfung, weil sonst älteres Management und Kunden glauben können, ist das System abgeschlossen. Eine Hauptabsicht ist, Probleme der menschlichen Schnittstelle zu finden, die Sicherheit und Brauchbarkeit betreffen können.

Gefahr-Analyse

Sicherheitskritische Avionik hat gewöhnlich eine Gefahr-Analyse. Die frühen Stufen des Projektes, haben Sie bereits mindestens eine vage Idee von den Hauptrollen des Projektes. Ein Ingenieur nimmt dann jeden Block eines Blockdiagramms und denkt die Dinge, die mit diesem Block schief gehen konnten, und wie sie das System als Ganzes betreffen. Nachher werden die Strenge und Wahrscheinlichkeit der Gefahren geschätzt. Die Probleme werden dann Voraussetzungen, die in die Spezifizierungen des Designs fressen.

Projektbeteiligen-Militär kryptografische Sicherheit schließt gewöhnlich eine Sicherheitsanalyse mit Methoden sehr wie die Gefahr-Analyse ein.

Wartungshandbuch

Sobald die Technikspezifizierung abgeschlossen ist, schreibend, dass das Wartungshandbuch anfangen kann. Ein Wartungshandbuch ist für Reparaturen, und natürlich notwendig, wenn das System nicht befestigt werden kann, wird es nicht sicher sein.

Es gibt mehrere Niveaus zu den meisten Standards. Ein Produkt der niedrigen Sicherheit wie eine Flugunterhaltungseinheit (ein fliegendes Fernsehen) kann mit einem schematischen und Verfahren für die Installation und Anpassung flüchten. Ein Navigationssystem, automatische Kurssteuerung oder Motor können Tausende von Seiten von Verfahren, Inspektionen und Takelage-Instruktionen haben. Dokumente sind jetzt (2003) alltäglich geliefert auf der CD-ROM in Standardformaten, die Text und Bilder einschließen.

Eine der sonderbareren Dokumentationsvoraussetzungen ist, dass die meisten kommerziellen Verträge eine Versicherung verlangen, dass Systemdokumentation unbestimmt verfügbar sein wird. Die normale kommerzielle Methode, diese Versicherung zur Verfügung zu stellen, soll bilden und ein kleines Fundament oder Vertrauen finanziell unterstützen. Das Vertrauen erhält dann einen Briefkasten aufrecht und legt Kopien (gewöhnlich in ultrafiche) in einer sicheren Position, wie vermieteter Raum in einer Bibliothek einer Universität (geführt als eine spezielle Sammlung), oder (seltener jetzt) begraben in einer Höhle oder einer Wüste-Position ab.

Design und Spezifizierungsdokumente

Diese sind gewöhnlich viel diejenigen in anderen Softwareentwicklungsmodellen ähnlich. Ein entscheidender Unterschied ist, dass Voraussetzungen gewöhnlich, wie beschrieben, oben verfolgt werden. In großen Projekten ist Voraussetzungsrückverfolgbarkeit solch eine große teure Aufgabe, dass es verlangt, dass große, teure Computerprogramme es führen.

Codeproduktion und Rezension

Der Code wird geschrieben, dann gewöhnlich von einem Programmierer nachgeprüft (oder Gruppe von Programmierern), der es ursprünglich (eine andere gesetzliche Voraussetzung) nicht geschrieben hat. Spezielle Organisationen führen auch gewöhnlich Coderezensionen mit einer Checkliste von möglichen Fehlern. Wenn ein neuer Typ des Fehlers gefunden wird, dass es zur Checkliste hinzugefügt, und überall im Code befestigt wird.

Der Code wird auch häufig durch spezielle Programme untersucht, die Genauigkeit (Statische Codeanalyse), wie FUNKEN-Prüfer für den FUNKEN (eine Teilmenge der Programmiersprache von Ada) oder Scharpie für die C-Familie von Programmiersprachen (in erster Linie C, obwohl) analysieren.

Die Bearbeiter oder speziellen Überprüfungsprogramme wie "Scharpie"-Kontrolle, um zu sehen, ob Typen von Daten mit den Operationen auf ihnen, auch solche Werkzeuge vereinbar sind, werden regelmäßig verwendet, um strengen Gebrauch von gültigen Programmiersprache-Teilmengen und Programmierstilen geltend zu machen.

Ein anderer Satz von Programmen misst Softwaremetrik, um nach Teilen des Codes zu suchen, die wahrscheinlich Fehler haben werden.

Alle Probleme werden befestigt, oder mindestens verstanden und zweimal kontrolliert.

Ein Code, wie Digitalfilter, grafische Benutzerschnittstellen und Trägheitsnavigationssysteme, wird so gut verstanden, dass Softwarewerkzeuge entwickelt worden sind, um die Software zu schreiben. In diesen Fällen werden Spezifizierungen entwickelt, und zuverlässige Software wird automatisch erzeugt.

Einheitsprüfung

"Einheit" Testcode wird geschrieben, um jede Instruktion des Codes mindestens einmal auszuüben, um 100-%-Codeeinschluss zu bekommen. Ein "Einschluss"-Werkzeug wird häufig verwendet, um nachzuprüfen, dass jede Instruktion durchgeführt wird, und dann der Testeinschluss ebenso aus gesetzlichen Gründen dokumentiert wird.

Dieser Test ist unter dem stärksten. Es zwingt ausführlich berichtete Rezension der Programm-Logik, und entdeckt den grössten Teil des Codierens, Bearbeiter und einige Designfehler. Einige Organisationen schreiben die Einheitstests vor dem Schreiben des Codes mit dem Softwaredesign als eine Modul-Spezifizierung. Der Einheitstestcode wird durchgeführt, und alle Probleme werden befestigt.

Integrationsprüfung

Da Stücke des Codes verfügbar werden, werden sie zu einem Skelett des Codes hinzugefügt, und im Platz geprüft, sich jede Schnittstelle Arbeiten zu überzeugen. Gewöhnlich sollte die in den Tests gebaute von der Elektronik zuerst beendet werden, um Brandwunde - in und Radioemissionstests der Elektronik zu beginnen.

Dann werden die wertvollsten Eigenschaften der Software integriert. Es ist für die Integratoren sehr günstig, eine Weise zu haben, kleine ausgewählte Stücke des Codes vielleicht von einem einfachen Menüsystem zu führen.

Einige Programm-Betriebsleiter versuchen, diesen Integrationsprozess einzuordnen, so dass nachdem ein minimales Niveau der Funktion erreicht wird, wird das System lieferbar an jedem im Anschluss an das Datum mit zunehmenden Beträgen von Eigenschaften, weil Zeit geht.

Schwarzer Kasten und Annahmeprüfung

Inzwischen beginnen die Testingenieure gewöhnlich, einen Testbohrturm zu sammeln, und einleitende Tests auf den Gebrauch durch die Softwareingenieure zu veröffentlichen. An einem Punkt bedecken die Tests alle Funktionen der Technikspezifizierung. An diesem Punkt beginnt die Prüfung der kompletten Luftfahrt-Einheit. Der Gegenstand der Annahmeprüfung ist zu beweisen, dass die Einheit sicher und in der Operation zuverlässig ist.

Der erste Test der Software und einer der schwierigsten, um sich in einer dichten Liste zu treffen, sind ein realistischer Test der Radioemissionen der Einheit. Das muss gewöhnlich früh im Projekt angefangen werden zu versichern, dass es Zeit gibt, um irgendwelche notwendigen Änderungen mit dem Design der Elektronik vorzunehmen.

Zertifikat

Jeder Schritt erzeugt einen lieferbaren, entweder ein Dokument, Code oder ein Testbericht. Wenn die Software alle seine Tests besteht (oder genug sicher verkauft zu werden), werden diese in einen Zertifikat-Bericht gebunden, der Tausende von Seiten wörtlich haben kann. Der benannte Technikvertreter, der um die Vollziehung gekämpft hat, entscheidet dann, ob das Ergebnis annehmbar ist. Wenn es ist, unterzeichnet er es, und die Luftfahrt-Software wird bescheinigt.

An diesem Punkt ist die Software gewöhnlich sehr gute Software durch jedes Maß.

Siehe auch

• TUN SIE - 178B
• Softwareentwicklungsmodell
• Gefahr-Analyse

Links

• Allgemeine Avionik-Softwarespezifizierung von Software Engineering Institute (SEI)