On-Board-Software
andere
On-Board-Software

Onboard-Software Flugzeuge

 

Der Hauptzweck von Regulierungsdokumenten und -normen besteht darin, Leitfäden für die Erstellung von Software für Bordsysteme in der Luftfahrt bereitzustellen, die geeignete Funktionen mit einem Sicherheitsniveau ausführen müssen, das die Anforderungen an die Lufttüchtigkeit von Flugzeugen erfüllt.

Unter internationalen Instrumente enthalten Softwareanforderungen AT ist das wichtigste Dokument DO-178, zuerst in 1978 formuliert Zum gegenwärtigen Zeitpunkt ist es verbesserte Versionen verwendet wird: DO-I78A, in Kraft seit 1985 Stadt und DO-I78B, in Kraft seit 1993 , bei dem der Aufmerksamkeit auf die Frage der Qualifizierung von Software-Tools zu zahlen.

In der Ukraine und Russland, gibt es Analoga dieser Dokumente: jeweils CT 178A mit 1998 Stadt und CT 178V mit 2004, die zusätzlich zu diesen Voraussetzungen sind Dokumente 178A RM und RM-178V.

DSTU ISO 9000-3-98 und DSTU 3918-1999 (ISO / IEC 12207:: 1995) Unter der Normenreihe ISO, in der Ukraine und der zugehörigen Software, wird von zwei dominiert. Die erste ist mit der Organisation und Tätigkeit des Qualitätssicherungssystems in Bezug auf die Software, der zweite Prozess-Lebenszyklus-Software gewidmet. Die Anforderungen der ISO-Normen direkt an die Zertifizierungsverfahren Sonne und ihre Bestandteile, einschließlich Software-Zertifizierungsverfahren verwandt.

Darüber hinaus ist die Zertifizierung von Unternehmen Luftfahrtindustrie, in diesem Fall, die Produktionsprozesse der Schöpfung und der Anwendungssoftware ARMAK Dokument "Richtlinien 21.2S", nämlich Abschnitt "Element 3. Qualitätssicherungs-Software ", die in zwei Teile geteilt wird:" Ein Teil A. Die Onboard-Software "und" Teil B:. Software für die Akzeptanz der Produkte "

Software bezieht sich auf die Onboard-Software der elektronischen Systeme der Streitkräfte, die einen Teil der Zertifizierungsgrundlage der Streitkräfte eines bestimmten Typs enthält und an Bord zum Zweck der Durchführung der notwendigen Funktionen für den Betrieb der Streitkräfte installiert. Softwaresysteme entwickelt, beispielsweise für die Prüfung der Sonne, wenn auch an Bord das Flugzeug nicht in der Luft, und bezieht sich auf den Prozess der Schaffung von Instrumenten AT.

Da die Funktionen integrierten digitalen Systemen werden über Software implementiert ist, ist die letztere Gegenstand besonderer Aufmerksamkeit Zertifizierungsstelle aufgrund seiner direkten Einfluss auf den sicheren Betrieb des Flugzeugs.

Kritikalität von funktionalen Bordsystemen und Software-Ebene. Das Hauptziel der Anerkennungsverfahren - ist vor allem gewisse Sicherheitsgarantien zu erhalten: Prävention von Tod, Verletzung, Krankheit, Verlust von Eigentum. Der Beginn der Zertifizierung für jedes komplexes technisches System ist es, die möglichen Auswirkungen des Verlustes (Impairment) der Systemfunktionen über die Sicherheit seines Betriebes oder für die Menschen und Eigentum nutzen zu analysieren. Und es spielt keine Rolle, was die Funktionsstörung verursacht - Anwenderfehler, Hardware-Fehler oder Software-Design-Fehler. Wichtig sind Tiefensteuerungssystem, die Identifizierung und die Fähigkeit Prellmittel des Systems, oder das System einer höheren Ebene der Hierarchie, die Notwendigkeit für die Redundanz, Rekonfiguration pariert. Um die Folgen der Verletzung der Funktionen des Systems zu analysieren, in der Regel müssen Sie mehrmals nach den folgenden Schritten zurückgehen, da die korrekte Definition der Kategorie der Schwere auf den Steifigkeitsanforderungen für die Software abhängig ist.

CT 178V Dokument definiert fünf Kategorien von der Schwere der Funktionssysteme und damit fünf Ebenen der Software. Trotz der Tatsache, dass für bestimmte kritische Systeme und Software-Ebenen starr verbunden sind, der Prozess der Festlegung Ebenen der zulässigen Abweichungen in der einen oder der anderen Seite.

Geheimhaltungsgrad Software Kritikalität Kategorien wie folgt:

  • In einem Level - auf eine solche funktionelle System Fehlerbedingungen, die durch einen Fehler in der Software entstandene könnte zu einem katastrophalen Lage der Sonne führen, wenn es praktisch unmöglich ist, den Tod der Sonne und den Menschen zu verhindern. Die Wahrscheinlichkeit einer solchen Situation eine Flugstunde zu sein, fast unglaublich, t E. Weniger als 10 ~ 9.

  • Die Pegel in der Software einer solchen Funktionssystem, dessen Zustand Freistellung, die durch in der Software zu einem Fehler entstanden ist, kann für die Sonne zu einer Notfallsituation führen Notsituation durch eine signifikante Verschlechterung der Eigenschaften der Sonne oder Überschreitung der Grenze Einschränkungen gekennzeichnet, sowie solche körperlichen Belastung der Flugbesatzung, in dem es nicht genau und vollständig seine Funktionen ausführen. Eine Notfallsituation kann zu erheblichen Schäden an der Sonne führen oder Verletzungen an einzelne Opfer. Die Wahrscheinlichkeit einer solchen Situation eine Flugstunde sehr unwahrscheinlich, dh in dem Bereich von 10 M0 ~ 9 .. sein;

  • EIN-Pegel von - auf eine solche Funktionssystem, dessen Zustand Freistellung, die aufgrund eines Fehlers in der Software entstanden ist, kann für die Sonne zu einer schwierigen Situation führen, Die komplexe Situation durch eine deutliche Verschlechterung Sonne Eigenschaften aus, die Ausgabe eines oder mehrere Parameter der Betriebsgrenzen, ohne jedoch die Grenze Zwänge zu erreichen und eine Abnahme der Fähigkeit der Mannschaft wegen der erhöhten Arbeitsbelastung mit dieser Situation fertig zu werden und wegen der ungünstigen Bedingungen, die Besatzung Aktionen Effizienz reduzieren . Schwierige Situation kann Beschwerden für die Passagiere verursacht, einschließlich möglicherweise Verletzungen. Die Wahrscheinlichkeit einer schwierigen Situation für eine Stunde Flug unwahrscheinlich zu sein, das heißt, von 10 5-10-7 .. im Bereich;

  • Entsprechend dem Pegel D - an einer funktionalen Systemfehlerzustände, die durch einen Fehler in der Software entstandene könnte zu einer Komplikation der Flugbedingungen bei Flugzeugen führt. Diese Situation wird durch eine leichte Verschlechterung der Sonne oder einer leichten Zunahme der Arbeitsbelastung der Besatzung aus. Diese Situation kann vermieden werden, beispielsweise durch Änderung des Flugplans und für die Passagiere, sollte es nicht mehr als einige Unannehmlichkeiten führen;

  • Nach der Ebene von E - auf dieser Funktionssystem, das der Staat die Befreiung, die in der Software aufgrund eines Fehlers entstand nicht die operativen Fähigkeiten der Streitkräfte und wirkt sich die Last nicht auf die Mannschaft erhöhen. Erste von der Zertifizierungsstelle, um zu bestätigen, dass die Software auf dem Niveau E gehört, bedeutet dies, dass die Bestimmungen des Dokuments CT 178V ihm keine Anwendung.

 

CT 178A Dokument definiert drei Kategorien von kritischen Funktionen an Bord von Flugzeugen Systeme:

  • unerlässlich, wenn eine besondere Situation, die bei der Durchführung der Verletzung der mindestens eine der Funktionen der Streitkräfte entstehen können, als katastrophal oder Notfall gekennzeichnet;

  • Wichtig ist, dass, wenn eine besondere Situation, die bei der Durchführung der Verletzung der mindestens eine der Funktionen der Streitkräfte, sind komplex entstehen können;

  • unbedeutend, wenn eine besondere Situation, die bei der Durchführung der Verletzung der mindestens eine der Funktionen der Streitkräfte entstehen können, ist es, die Flugbedingungen oder Auswirkungen erschweren.

 

Dementsprechend gibt es drei Ebenen von Software:

  • 1 Stufe für die Kategorie "kritisch", um die anspruchsvollsten Software und die maximale Menge an Arbeit, um die Einhaltung der Zertifizierungsanforderungen und die maximale Menge an Unterlagen beweisen, erfüllt werden müssen;

  • Level 2 - für die Kategorie "wesentlich" mit geringeren Anforderungen;

  • Level 3 - für die Kategorie "nicht-essentiellen" die Mindestanforderungen.

Level-Software hängt nicht nur von der Kategorie der kritischen Funktionen. Wichtige Rolle der Architektur des Systems und die Struktur seiner Software abgespielt. Zum Beispiel kann das System im Standby-Analogkanal werden analysiert, dass die gesamte digitale Kanalfunktion duplizieren. Unter bestimmten Umständen kann dies ausreichend sein, um den Pegel zu verringern. Umgekehrt, wenn auf einem einzigen Sun-System analysiert wird so verwendet, dass seine Weigerung, eine kritische Kategorie, und die anderen Streitkräfte des gleichen Systemausfalls führen zu einer kritischen Betriebsbedingung der Systementwickler zu beantworten können ein höheres Niveau bestimmen. Ein wichtiger Einfluss auf die Höhe der Software bestimmen, sind auch Methoden des Designs. zum BeispielMaßnahmen, die Methode der Isolation oder Kontrolle als eine Methode der Schutz gegen bestimmte Fehlerbedingungen durch kontinuierliche Validierung der Funktion oder Multi-versioniert Methode, deren Umsetzung sieht die Schaffung von zwei oder mehr Softwarekomponenten, die eine Funktion auf unterschiedliche Weise und auf verschiedenen Software durchzuführen bietet die Möglichkeit, funktional unabhängig trennen Softwarekomponenten, um Fehler zu isolieren.

Die oben genannten numerischen Werte der Wahrscheinlichkeit des Auftretens von Sondersituationen beziehen sich nicht auf die Wahrscheinlichkeit unerkannter Fehler in der Software. Software kann nicht auf den entwickelten mathematischen Apparat der Theorie der Statistik angewandt werden, die möglichen bellt die Wahrscheinlichkeit von Ereignissen zu berechnen, da es keine direkte Verbindung zwischen der Wahrscheinlichkeit des Auftretens von bestimmten Situationen und ist nicht geeignet, Fehler in der Software zu erkennen. Somit können die Stufen von Indikatoren für die oder die Zuverlässigkeit auf der Basis einer Software-Ebene, nicht im System Sicherheitsbeurteilung verwendet werden, beispielsweise als Hardware-Fehlerrate verwendet.

Allerdings empfehlen die Vorschriften die Verwendung von diesen oder anderen quantitativen Kriterien für die Beurteilung der Qualität der Software oder um eine gewisse Qualität zu erzielen, unter Berücksichtigung der Tatsache, dass die Software-Industrie hat eine große Sammlung von Modellen und Messdaten, die Sie auf verschiedene Merkmale der Software zu bewerten ermöglichen sammelt. Darüber hinaus bei der Entwicklung und Verifikation von Software wird dringend empfohlen, eine Aufzeichnung der festgestellten Fehler und Nachteile, sowie Maßnahmen zu deren Bewältigung zu halten.

 

Die Prozesse der Entwicklung, Überprüfung und Validierung der Software

Die wichtigste Schritt bei der Schaffung eines etwaigen technischen Produktes ist sein Design, einschließlich Prototyping, testen Sie es, um die Einhaltung der Vorschriften zu überprüfen und, am Ende, die Zustimmung seiner Wartungsfreundlichkeit. Erstellen eines Software-Produkt entspricht in vollem Umfang dieser Prozesse.

Präsentiert den Prozess der Schaffung einer Software-Produkt von Interesse aus der Sicht der Erzielung bestimmter Sicherheitsgarantien. Hier, jedes Ereignis mit der Entwicklung von (P) verbunden ist, eine entsprechende Überprüfung Ereignis (B). Und sie beide die relevanten Dokumente (D) zu erzeugen.

Das Ausgangsmaterial für die Initiierung von Softwareentwicklungsprozessen sind die deklarierten Anforderungen an das System, die in Form eines entsprechenden Dokuments (DF <"Null">) formalisiert und genau aufgrund der Implementierung in Softwareanforderungen (D1) umgewandelt werden müssen Funktionen digitaler elektronischer Systeme werden, wie bereits erwähnt, von Software ausgeführt. Der Entwicklungsprozess für Softwareanforderungen (P1) ist der Prozess der Umwandlung von Systemanforderungen in Softwareanforderungen.

Um das Verständnis der Transformationsverfahren zu erleichtern, sowohl während der Entwicklung und ihre Überprüfungsverfahren wird empfohlen, in mindestens zwei Teile aufteilen: eine Design-Anforderungen hohem Niveau und anschließende Entwicklungsbedarf gering.

High-Level-Anforderungen direkt aus der Analyse von den Systemanforderungen im Hinblick auf den Eigenschaften seiner Konstruktion abgeleitet. Es ist notwendig, die folgenden Bedingungen einzuhalten: Jede Anforderung an dem System sollte für ein High-Level, und umgekehrt, die jeweils für einen hohen Grad an Software zu einem oder mehreren der Anforderungen übertragen werden, - in einer oder mehreren der Systemanforderungen, mit Ausnahme Derivat Ansprüche, die nicht direkt entstehen, werden die Systemanforderungen (z.B. Nachfrage Interruptverarbeitung in Abhängigkeit von den Eigenschaften des Zielrechners ausgewählt). Derivate von High-Level-Anforderungen in der Systemsicherheit Bewertungsprozess zu übertragen. Für High-Level umfassen Anforderungen funktionale und technische Anforderungen, die Interoperabilität und Sicherheitsanforderungen gefragt.

Low-Level-Anforderungen werden in Form von Software-Engineering angesetzt und durch die Analyse und Detaillierung Anforderungen auf hohem Niveau erhalten. Anforderungen niedrige Niveaus sind direkt mit den Verfahren der Codierung und Aggregation Software, t zusammen. E. Es sind die Anforderungen für die entsprechende Programmiersprachen, Compiler, Architektur und Middleware, die Struktur der Komponenten, auf die Klassifizierung von Software-Objekten an den Bediener Basis auf die Umwelt, der Entwicklung und Prüfung als auch auf die Art der Programmierung.

Verwandte Dokumente sind die Normen und andere normative Dokumente (D2) über die technische Spezifikationen für die Gestaltung, Programmierung Unterstützung. Die Überprüfung der Übung, die erste Stufe der Entwicklung Abschluss - ein Vergleich der Anforderungen an die Software-Systemanforderungen, um die Kompatibilität der Verteilung von Funktionen zwischen Hardware und Software und Schnittstellen, Vollständigkeit oder Angemessenheit der Anforderungen an die Software zu überprüfen. Die empfohlene Form der Dokumentation - eine Tabelle der Querverweise, die als separates Dokument Überprüfung ausgestellt werden kann, oder ein Teil eines allgemeinen Dokument sein, das alle Phasen der Überprüfungsverfahren und deren Ergebnisse sowie neu auftretende Probleme und Maßnahmen zur Bewältigung sie beschreibt.

Die nächsten Phasen der Entwicklung - Prozesse der Software-Entwicklung und Verwaltung ihrer Qualität zu planen. Der Hauptzweck der Planung - Identifizierung von Ressourcen und Action-Sequenzen, die Erreichung der Ziele zu gewährleisten. Es wird nach wie vor durch die Organisation (Beziehung) Prozesse bestimmt. Als Ergebnis sollten sie fünf Dokumente ausgestellt werden (das eine sinnvolle Kombination erlaubt ist): Pläne für die Zertifizierung (DZ), die Software-Entwicklungsplan, Planverifikation und Konfiguration Managementpläne (D6) und seine Qualität garantieren. Verifikations-Aktivitäten (V2, VZ) beziehen sich hauptsächlich auf die Koordinierung der Verfahren auf der Stufe der Genehmigung der Pläne, sowie deren Korrektur durch den Ausführungen, die in den späteren Phasen des Betriebs entstanden, und sogar Software. Der Inhalt der Dokumente weiter berücksichtigt.

Fortsetzung des Entwicklungsprozesses ist ein Prozess, Software zu entwerfen. Dabei sind die High-Level-Software-Anforderungen für eine Anzahl von Iterationen des Design-Prozesses festgelegt, die Software-Architektur des Funktionierens Algorithmen zu bilden, unter Berücksichtigung der niedrigen Niveau der Anforderungen in einem solchen Ausmaß, dass auf ihnen war es möglich, den Quellcode zu machen. Gerecht zu werden Sicherheitsanforderungen sollte Steuerung der Steuer liefern und Datenflusses, beispielsweise einen Überwachungszeitgeber zur Verfügung zu stellen, die Überprüfung der Konsistenz und Vergleich Quer fließen natürlich mit der entsprechenden Reaktion auf das „Zurückweisung“ -Zustand. Design Ergebnisse werden in einem Dokument der Beschreibung des Projekts aufgezeichnet.

Die Überprüfung Übung V4 - Projektprüfungen auf Compliance-Anforderungen für Software und Standards für die Gestaltung, einschließlich der Überprüfung des Systembetriebs Algorithmen. Der Hauptzweck der Prüfung des Projektes ist die „Überprüfbarkeit“ zur Verfügung zu stellen. die Abfolge der Programmausführung, Datenströme und möglicher Verzerrung ihrer möglichen Auswirkung auf Hardware-Isolation und Integrität Funktionen: Dies sollte berücksichtigt zumindest die folgenden Faktoren getroffen werden. Die Überprüfung Dokument D13 sollte auf Antrag einer Software in Form von Querschnittsanalyse eine Tabelle der Einhaltung des Projektes sein. Rückzug von den Normen und Anforderungen zu beachten und zu begründen.

Alle Stufen so weit, können Lager Entwurfsphase der Software als vorläufig beschrieben. Nur als Ergebnis des Planungsprozesses (R5), Verbindungssoftwarekomponenten (R6) und die Integration der Software mit Hardware (R7) erscheint eigenen Software-Produkte in ihre endgültige Form.

Das erste Ergebnis des Verfahrens wird eine Low-Level-Anforderungen zu implementieren, immer einen Quellcode (D9), die in das Projekt umgesetzt werden soll. Accounting Software-Architektur im Design-Prozess wird in den Verfahren der Mehrkomponenten-Software und Integrationssoftware auf den Zielcomputer wird letztlich ausführbarer Objektcode (DOJ) und die entsprechende Verzeichnis-Konfigurationssoftware implementiert (D11). Fehlerhafte oder unzureichende Eingangsdaten in diesem Verfahren identifiziert wird, ist es notwendig, zu den bisherigen Verfahren zurückzukehren für Korrekturen oder Klarheit zu machen. Darüber hinaus ist die Umgebung der Software-Entwicklung (ist es, am häufigsten und die Umwelt ihrer Unterstützung) müssen klar und sorgfältig definiert und fixiert (D12) sein.

Unnötig zu sagen, in diesem Stadium der Entwicklung durchgeführt werden die umfangreichsten, die komplexeste in Inhalt und die wichtigsten Kontrollmaßnahmen (V5, V6, V7) unter dem Titel - Prüfsoftware (Test), um Fehler in der Software enthaltenen erkennen. Das Problem hierbei ist, dass die detektierten Fehler werden gewöhnlich eliminiert nicht identifiziert möglicherweise gar nicht vorhergesagt werden.

Der Inhalt aller drei Überprüfungsmaßnahmen.

Dieser Prozess besteht aus einer Anzahl von Iterationen, und schließt alle Positionen in jeder Iteration und für jedes Ereignis. Die Ergebnisse des Verfahrens sind in einem Dokument D13 aufgezeichnet.

Bewertungsprozesse der Softwareentwicklung wäre unvollständig ohne die Erwähnung der Pläne und UKPO GKPO. durch interne und externe Audits der Konfiguration sowie die entsprechenden organisatorischen und technologischen Verfahren implementiert werden und sind in den Minuten und D14 D15 wider.

Die Durchführung des Plans Software-Zertifizierungsurkunde D16 fixiert.

Der Zyklus der Software-Entwicklung abgeschlossen ist die Tests bestätigen die betriebliche Eignung von integrierten digitalen Funktionssystem (V9). Diese Tests werden als Teil des offiziellen Zertifikat (Zertifizierung), dass das System auf dieser Flugzeuge in der angegebenen Betriebsbedingungen einwandfrei funktioniert durchgeführt.

Die Dokumentation für Software-Zertifizierung. In den USA gab es offiziell 1987 Verfahren Institute SEI (Software Engineering Institute), die um das Niveau der technologischen Reife der Unternehmen, die Software-Entwicklung und Verbesserung des Entwicklungsprozesses zu bestimmen. Ursprünglich Capability Maturity

Model (CMM), und später - Capability Maturity Model Integration (CMMI). In Übereinstimmung mit dem Modell der höchsten ( „Optimierung“) Niveau der technologischen Reife - die fünfte - auf die Verbesserung der Prozesse Prozess zur Produktion auf der Basis eines mathematischen Modells mit den Methoden der parametrisch und Strukturoptimierung und die Organisation konzentriert sich vollständig automatisiert reagiert. Eines der Zeichen der unter der ersten ( „primary“) Ebene ist abhängig Organisation der einzelnen Programmierer, und eine der Bedingungen für den Übergang von dem zweiten ( „repeats“) Pegel auf eine dritte ( „Definitionen“) - Dokumentation von Prozesse unter Kontrolle entsprechender Service von der verantwortlichen Person geführt von der Geschäftsleitung der Organisation.

Alle Phasen des Software-Lebenszyklus einen Anfang und ein Ende der Dokumentation kann für immer existieren. Deshalb, um die Anforderungen an die Dokumentation zu formulieren - es heißt, die Anforderungen für alle obigen Verfahren die Erstellung von Software zu formulieren. Dokumentation ist die sehr Material Faktor, mit dem zertifizierten Software. Die Dokumentation ist auch ein Schlüsselelement bei der Untersuchung sorgfältig die Voraussetzungen von Katastrophen oder Notfälle analysiert.

Eine sehr wichtige Form und den Inhalt des Dokuments, die Einbeziehung von quantitativen und qualitativen Eigenschaften des Produkts, wobei die Tiefe der Überwachung und Analyse des Vorhandenseins der Möglichkeit der Aufzeichnung und Speicherung der Ebene der Verantwortung der Personen Signieren des Dokuments. Das schwächste Glied in der Dokumentation - vollständige Sicht auf die Erklärung zu ihren Anforderungen.

Eine spezifische Liste der Dokumente für die Zertifizierung der Software ist abhängig von der Software (von der Kritikalität des Systems) und ist in den Prozess der Genehmigung des Plans der Zertifizierung mit der Zertifizierungsstelle bestimmt. Das folgende zeigt kurz das Wesen und die bereits genannten Dokumenten.

  • D1 "Software-Anforderungen" - enthält eine Beschreibung der Transformation der Systemanforderungen, Software-Anforderungen mit der Freisetzung von den Anforderungen der hohen und niedrigen Pegel und mit besonderem Augenmerk auf die Sicherheit und die möglichen Fehlerbedingungen. Definiert werden Leistungskriterien Merkmale und mögliche Einschränkungen, wie Speicher, Zeit-Frequenz, für die Wechselwirkung. Besondere Aufmerksamkeit wird auf die Isolierung von Softwarekomponenten ausgezahlt.

  • D2 - "Standards der Softwareentwicklung" - Plural Liste. Zumindest - das ist eine Liste von formalen Normen, Anforderungen Entwicklung, Design, Programmierung, Test-Software. Zusammen mit den Normen - ein paar Dokumente.

  • Ihre Inhalte - Methoden für die Erstellung, Strukturierung Regeln, Beschränkungen des Projekts (beispielsweise der Ausschluss von Rekursion, dynamische Objekte, alternative Symbole der Daten), Grenzen, was Komplexität (zB Verschachtelung von Anrufen, die Verwendung von Hopfen) auf Sprache und Compiler, Umwelt und Werkzeuge.

  • CLE - "Plan-Software-Zertifizierung" wird zur Genehmigung an den Staat Zertifizierungsstelle diente, definiert Verfahren, Methoden zum Nachweis der Übereinstimmung mit den Anforderungen an das Produkt, um ihn auf ein System für die Streitkräfte und die erforderliche Dokumentation.

  • D4 "Software-Entwicklungsplan" - definiert den Lebenszyklus der Software-Entwicklung, das Zusammenspiel der Darsteller und der Entwicklungsumgebung.

  • D5 - "Plan Software-Verifikation" - definiert die Schritte (die Position des Entwicklungsprozesses und Kriterien für den Übergang in den Prüfungsverfahren), Techniken, Verfahren, Umwelt und Werkzeuge der Überprüfung, einschließlich Software-Tools, Anweisungen zum Erreichen der erforderlichen Qualitätsparameter (Sicherheit) und Anweisungen auf Rescan und Prüfung nach Änderungen an der Software, die die Beseitigung der festgestellten Fehler zu garantieren.

  • D6 - "Software Configuration Management Plan" - legt die Regeln zur Identifizierung von Software und Geräteeinheiten, die Grundversion und Rückverfolgbarkeit auf derivative Versionen von den Regeln des Change Management, die Regeln der Ordnung und Konfigurationsstatus Buchhaltung, Archivierung, Überwachung und Schutz der Datenübertragungseinheit-Software.

  • D7 - "Plan Qualitätssicherungssoftware" legt den Umfang, die Zuständigkeiten und Befugnisse der Inspektion und Prüfung und andere Aktivitäten, um den Prozess der Erlangung Garantien, einschließlich Berichte über Probleme, deren Überwachung und Abhilfemaßnahmen zusammen.

  • D8 - "Beschreibung der Projektsoftware" - enthält eine detaillierte Beschreibung, wie die Software die Anforderungen der High-Level-Anforderungen, einschließlich Algorithmen, Datenstrukturen trifft, und wie Software-Anforderungen, Aufgaben und Prozessen zugeordnet. Darüber hinaus eine Beschreibung der Software-Architektur, Bibliotheken, I / O-Datenströme und die Kontrolle der Verteilung von Ressourcen und die damit verbundenen Beschränkungen, Verfahren, Terminplanung, Interprozessschemata und inter-Application-Sharing, Unterbrechungen, Software-Komponenten, Verfahren zu ihrer Isolation.

  • D9 "Source Code" - beinhaltet den Quellencode, die Compileranweisungen für die Codegenerierung, Datenbearbeitung und Download-Links.

  • D10 - "Objekt ausführbaren Code" - enthält den Code, die für die direkte Umsetzung des Zielprozessors, Rechner, t E. Eines, das in das System der Avionik geladen ist..

  • D11 - "Produktkonfigurationssoftware" - definiert die Konfiguration der als Einheit gelieferte Produkt. Es muss die Software als Ganzes zu identifizieren, wobei jede Komponente auf die Dokumente und Medien entspricht.

  • D12 - "Produkt Environment Software" - enthält eine Beschreibung des Software-Lebenszyklus-Umgebung, von der Phase der Festlegung der Anforderungen und Finishing-Phase der Abschreibung von Produkt zu verwenden. In dem Katalog von Entwicklungswerkzeugen, Verifikation, Tracking-Software identifiziert, liefert Daten über die Qualifikation von Werkzeugen.

  • D13 - "Die Verfahren und die Ergebnisse der Überprüfung" kann in zwei oder drei Dokumente, die für die Überprüfung, Analyse beschrieben werden müssen Verfahren aufgeteilt werden, die Prüfung in allen Phasen der Entwicklung, Anwendungsbeispiele und Testergebnisse der identifizierten Komponenten der Software-Verfahren. Alle Probleme und Korrekturmaßnahmen sind im Detail beschrieben.

  • D14 - "Protokolle UKPO."

  • D15 - "Protokolle GKPO."

  • D16 - "Die endgültige Entscheidung über die Software" - ist das Hauptdokument, das die Umsetzung des "Plan von Software-Zertifizierung" und dem Ausmaß, in dem die "Software-Anforderungen" sichert. Es muss eine kurze Beschreibung des Systems und Software, Zertifizierungsbedingungen (Abkommen), Eigenschaften, Identifikation und Zustand der Software-Dokumentation für eine Liste der Software und eine Erklärung der Umfang, in dem Software-Anforderungen enthalten.

Blog und Artikel

nach oben