DO-178B - DO-178B - Wikipedia

Softwarové aspekty při certifikaci vzdušných systémů a zařízení
Nejnovější verze1. prosince 1992 (1992-12-01)
Organizace
DoménaLetectví
Zkratka
  • DO-178B
  • ED-12B

DO-178B, Softwarové aspekty při certifikaci vzdušných systémů a zařízení je pokyn zabývající se bezpečností kritické z hlediska bezpečnosti software používaný v určitých palubních systémech. Ačkoli to byl technicky vodítko, bylo to de facto standard pro vývoj avionický software systémů, dokud nebyl v roce 2012 nahrazen DO-178C.

The FAA aplikuje DO-178B jako dokument, který používá jako vodítko k určení, zda bude software spolehlivě fungovat ve vzdušném prostředí,[1] pokud je specifikováno technickou standardní objednávkou (TSO), pro kterou se požaduje certifikace. Ve Spojených státech je zavedení TSO do procesu certifikace letové způsobilosti a rozšířením DO-178B výslovně stanoveno v hlavě 14: Aeronautika a vesmír Kodex federálních předpisů (CFR), také známý jako Federální letecké předpisy, Část 21, hlava O.

Společně jej vyvinula bezpečnostní kritická pracovní skupina RTCA SC-167 z RTCA a WG-12 ze dne EUROCAE. RTCA zveřejnila dokument jako RTCA / DO-178B, zatímco EUROCAE dokument zveřejnila jako ED-12B.

Úroveň softwaru

The Úroveň softwaru, také známý jako Úroveň zajištění designu (DAL) nebo Úroveň zajištění rozvoje položek (IDAL), jak je definováno v ARP4754 (DO-178C pouze zmiňuje IDAL jako synonymum pro softwarovou úroveň[2]), se stanoví z proces posuzování bezpečnosti a analýza rizik zkoumáním účinků poruchového stavu v systému. Podmínky poruchy jsou kategorizovány podle jejich účinků na letadlo, posádku a cestující.

  • Katastrofální - Selhání může způsobit nehodu. Chyba nebo ztráta kritické funkce potřebné k bezpečnému letu a přistání letadla.
  • Nebezpečný - Porucha má velký nepříznivý dopad na bezpečnost nebo výkon, nebo snižuje schopnost posádky řídit letadlo v důsledku fyzického utrpení nebo vyššího pracovního vytížení nebo způsobuje vážná nebo smrtelná zranění cestujících. (Významné z hlediska bezpečnosti)
  • Hlavní, důležitý - Porucha je významná, ale má menší dopad než Nebezpečná porucha (například vede spíše k nepohodlí cestujících než ke zranění) nebo významně zvyšuje pracovní zátěž posádky (související s bezpečností)
  • Méně důležitý - Selhání je patrné, ale má menší dopad než závažné selhání (například způsobení nepohodlí cestujícím nebo změna rutinního letového plánu)
  • Žádný efekt - Porucha nemá žádný dopad na bezpečnost, provoz letadla nebo pracovní zátěž posádky.

Samotný DO-178B není určen k zajištění aspektů bezpečnosti softwaru. Bezpečnostní atributy v návrhu a implementované jako funkcionalita musí pro řízení řídit dalšími povinnými bezpečnostními úkoly systému a vykazovat objektivní důkazy o splnění výslovných bezpečnostních požadavků. Typicky jsou přidělovány bezpečnostní plány IEEE STD-1228-1994 a úkoly analýzy softwarové bezpečnosti jsou prováděny v postupných krocích (analýza požadavků, analýza návrhu nejvyšší úrovně, podrobná analýza návrhu, analýza úrovně kódu, analýza testů a analýza změn). Tyto softwarové bezpečnostní úkoly a artefakty jsou nedílnou podpůrnou součástí procesu pro stanovení závažnosti nebezpečí a stanovení DAL, které mají být dokumentovány v hodnocení bezpečnosti systému (SSA). Certifikační úřady požadují a DO-178B specifikuje správné DAL, které mají být stanoveny pomocí těchto komplexních analytických metod pro stanovení softwarové úrovně A-E. Jakýkoli software, který ovládá, ovládá a monitoruje funkce důležité z hlediska bezpečnosti, by měl dostávat nejvyšší úroveň DAL - úroveň A. Právě bezpečnostní analýzy softwaru, které řídí posouzení bezpečnosti systému, určují DAL, který řídí příslušnou úroveň přísnosti v DO-178B. Posouzení bezpečnosti systému v kombinaci s metodami, jako je SAE ARP 4754A určit DAL po zmírnění a může umožnit splnění cílů na úrovni softwaru DO-178B, pokud jsou v požadavcích vycházejících z bezpečnostních analýz redundance, bezpečnostní prvky návrhu a další architektonické formy zmírňování rizik. Ústředním tématem DO-178B je proto zajištění designu a ověření po stanovení nezbytných bezpečnostních požadavků.

Počet cílů, které mají být splněny (případně s nezávislostí), je určen úrovní softwaru A-E. Fráze „s nezávislostí“ označuje oddělení odpovědnosti, kde je objektivita procesů ověřování a ověřování zajištěna na základě jejich „nezávislosti“ od vývojového týmu softwaru. U cílů, které musí být uspokojeny s nezávislostí, nemusí být osobou ověřující položku (například požadavek nebo zdrojový kód) osoba, která položku vytvořila, a toto oddělení musí být jasně zdokumentováno.[3] V některých případech může být automatizovaný nástroj ekvivalentní nezávislosti.[4] Samotný nástroj však musí být kvalifikován, pokud nahradí lidskou kontrolu.

ÚroveňPoruchový stavCíle[5]S nezávislostíPoruchovost
AKatastrofální662510−9/ h
BNebezpečný651410−7/ h
CHlavní, důležitý57210−5/ h
DMéně důležitý28210−3/ h
EŽádný efekt00n / a

Procesy a dokumenty

Procesy jsou určeny k podpoře cílů podle úrovně softwaru (A až D - úroveň E byla mimo dosah DO-178B). Procesy jsou popsány jako abstraktní oblasti práce v DO-178B a je na plánovačích skutečného projektu, aby definovali a dokumentovali specifika toho, jak bude proces proveden. U skutečného projektu musí být na podporu cílů ukázány skutečné činnosti, které budou provedeny v kontextu procesu. Tyto činnosti definují plánovači projektu jako součást procesu plánování.

Tato objektivně založená povaha DO-178B umožňuje velkou flexibilitu, pokud jde o dodržování různých stylů životní cyklus softwaru. Jakmile je aktivita v procesu definována, obecně se očekává, že projekt respektuje tuto dokumentovanou aktivitu v rámci svého procesu. Kromě toho musí procesy (a jejich konkrétní činnosti) mít přesně definovaná vstupní a výstupní kritéria podle DO-178B a projekt musí prokázat, že tato kritéria dodržuje, protože provádí činnosti v procesu.

Flexibilní povaha procesů DO-178B a kritéria vstupu / výstupu znesnadňují první implementaci, protože tyto aspekty jsou abstraktní a neexistuje žádná „základní sada“ činností, z nichž by bylo možné pracovat. Záměrem DO-178B nebylo být normativní. Existuje mnoho možných a přijatelných způsobů, jak může skutečný projekt tyto aspekty definovat. To může být obtížné poprvé, kdy se společnost pokusí vyvinout systém civilní avioniky podle tohoto standardu, a vytvořila mezeru na trhu školení a poradenství DO-178B.

Pro obecný proces založený na DO-178B, a vizuální shrnutí je poskytována včetně fází zapojení (SOI) definovaných FAA v „Poradenství a pracovních pomůckách pro software a komplexní elektronický hardware“.

Plánování

Systémové požadavky jsou obvykle vstupem do celého projektu.

Poslední 3 dokumenty (standardy) nejsou pro softwarovou úroveň D vyžadovány.

Rozvoj

DO-178B není zamýšlen jako standard vývoje softwaru; jedná se o softwarové zajištění využívající soubor úkolů ke splnění cílů a úrovní přísnosti.

Výstupní dokumenty procesu vývoje:

Obvykle je vyžadována sledovatelnost od systémových požadavků ke všem zdrojovým kódům nebo spustitelným objektovým kódům (v závislosti na úrovni softwaru).

Obvykle se používá proces vývoje softwaru:

Ověření

Výstupy dokumentu vytvořené tímto procesem:

Obvykle je vyžadována analýza veškerého kódu a sledovatelnost od testů a výsledků po všechny požadavky (v závislosti na úrovni softwaru).

Tento proces obvykle zahrnuje také:

  • Testovací nástroje založené na požadavcích
  • Pokrytí kódu nástroje analyzátoru

Jiné názvy testů prováděných v tomto procesu mohou být:

Správa konfigurace

Dokumenty vedené správa konfigurace proces:

Tento proces zpracovává hlášení problémů, změny a související činnosti. Proces správy konfigurace obvykle poskytuje archivaci a identifikaci revize:

  • Vývojové prostředí zdrojového kódu
  • Jiná vývojová prostředí (např. Testovací / analytické nástroje)
  • Softwarový integrační nástroj
  • Všechny ostatní dokumenty, software a hardware

Zajištění kvality

Výstupní dokumenty z procesu zabezpečování kvality:

  • Software zajištění kvality záznamy (SQAR)
  • Kontrola shody softwaru (SCR)
  • Souhrn úspěchu softwaru (SAS)

Tento proces provádí kontroly a audity, aby prokázal soulad s DO-178B. Rozhraní s certifikační autoritou je také zpracováváno procesem zajišťování kvality.

Certifikační spojení

Typicky a Určený technický zástupce (DER) přezkoumává technické údaje jako součást předložení FAA ke schválení.

Nástroje

Software může automatizovat, pomáhat nebo jinak zpracovávat nebo pomáhat v procesech DO-178B. Všechny nástroje použité pro vývoj DO-178B musí být součástí procesu certifikace. Nástroje generující vložený kód jsou kvalifikován jako vývojové nástroje, se stejnými omezeními jako vložený kód. Nástroje používané k ověření kódu (simulátory, nástroj pro provádění testů, nástroje pro pokrytí, nástroje pro podávání zpráv atd.) Musí být kvalifikován jako ověřovací nástroje, mnohem lehčí proces spočívající v komplexním testování černé skříňky nástroje.

Nástroj třetí strany lze kvalifikovat jako ověřovací nástroj, ale vývojové nástroje musí být vyvinuty na základě procesu DO-178. Společnosti poskytující tento druh nástrojů jako COTS podléhají auditům certifikačních autorit, kterým poskytují úplný přístup ke zdrojovému kódu, specifikacím a všem certifikačním artefaktům.

Mimo tento rozsah musí být výstup každého použitého nástroje ručně ověřen člověkem.

Správa požadavků

Sledovatelnost požadavků se týká dokumentace životnosti požadavku. Mělo by být možné zpětně vysledovat původ každého požadavku a každá změna provedená v požadavku by proto měla být zdokumentována, aby se dosáhlo sledovatelnosti. Dokonce i použití požadavku po nasazení a použití implementovaných funkcí by mělo být dohledatelné.

Kritika

VDC Research poznamenává, že DO-178B se stal „poněkud zastaralým“ tím, že se dobře nepřizpůsobuje potřebám a preferencím dnešních inženýrů. Ve stejné zprávě to také berou na vědomí DO-178C se zdá být připraven tento problém řešit.[Citace je zapotřebí ]

Zdroje

  • DALEKO Část 23/25 § 1301 / § 1309
  • DALEKO Část 27/29
  • AC 23/25.1309
  • AC 20-115B
  • RTCA / DO-178B
  • FAA Order 8110.49 Software Approval Guidelines

Viz také

Reference

  1. ^ Poradní oběžník FAA 20-115B
  2. ^ RTCA / DO-178C „Softwarové aspekty při certifikaci vzdušných systémů a zařízení“, s. 116. „Jedním z příkladů je termín„ úroveň vývoje položky “(IDAL), který je pro software synonymem pro výraz„ úroveň softwaru “.
  3. ^ RTCA / DO-178B „Softwarové aspekty při certifikaci vzdušných systémů a zařízení“, s. 82
  4. ^ RTCA / DO-178B „Softwarové aspekty při certifikaci vzdušných systémů a zařízení“, str.82
  5. ^ RTCA / DO-178B „Softwarové aspekty při certifikaci vzdušných systémů a zařízení“, příloha A

externí odkazy