Budapesti Műszaki és Gazdaságtudományi Egyetem
Méréstechnika és Információs Rendszerek Tanszék
Szoftverfejlesztés a
repülőgépiparban
Azaz miért nem kell félnünk a szoftverhibáktól repülés közben
Horváth Ákos
BME-MIT
Motiváció
Repülőgép szoftverek története
0
50
100
150
200
250
300
350
400
MIPS LOC Mbyte/10 Digital links
A-310 (1983)
A-320 (1988)
A-340 (1993)
Exponenciális
növekedés
Mind az A380 és a B 787
több mint 100 millió LOC
~ 100 Mbyte
Ref: Subra de
Salafa and
Paquier
Fejlesztési folyamat jellemzői
Egyedi fejlesztési folyamat
(jellemzően a V modellre épülve)
Repülőgép szoftverfejlesztésre
jellemzők
 Szigorú tanúsítványozási folyamat
o DO-178B (és C)
 hogy bebizonyítsa
o tanúsítványozással
 a rendszer mentes a hibáktól
o teljesíti a követelményeket
nyomonkövethetőség a
követelményektől egészen a bináris
kódig!
Copyright© CERTIMOT ERC-HU Project
Tanúsítványozás – DO-178B (C)
 DO-178B - Software Considerations in Airborne Systems
and Equipment Certification
„DO-178B (and DO-278) are used to assure safety of
avionics software. These documents provide guidance in the
areas of SW development, configuration management,
verification and the interface to approval authorities”
 Az RTCA szabványa (Európán belül ED-12B)
 Teljes civil repülőgépipar által elfogadott szabvány
biztonságkritikus szoftverek fejlesztésére
o ajánlások
 1992 (új verzió 178C 2013)
 ~120 oldalas dokumentum
Szoftver szintek DO-178B
 Level A&B
o Fly-by-wire vezérlés
o Autópilóta
o Adat megjelenítési réteg
o Radar
o Hajtómű vezérlés
o Fekete doboz
 Level C&D
o Telemetria
o Küldetés tervezése és
nyomonkövetése
o Rendszer életjel figyelési
alrendszerek
o Valós-idejű adatrögzítés és
kiértékelés (szenzor)
Előírások (Objectives) eloszlása a DO-178B
0
5
10
15
20
25
30
35
40
45
Planning Dev. Verif. CM QA Cert.
Level A (66)
Level B (65)
Level C (57)
Level D (28)
Előírások (Objectives) eloszlása a DO-178B
0
5
10
15
20
25
30
35
40
45
Planning Dev. Verif. CM QA Cert.
Level A (66)
Level B (65)
Level C (57)
Level D (28)
Szoftverfejlesztés DO-178B
Verifikációs és validáció DO-178B
Nyomonkövethetőség
Verifikáció és
Validáció
Szoftver Verifikáció teszteléssel DO-178B
# A B C
Foo
Executed
1 0 0 0 NO
2 0 0 1 NO
3 0 1 0 NO
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Coverage
Type
Minimum # of
Test Cases Possible Combinations
Statement 1 4 or 6 or 8
IF(C AND( A OR B))
THEN Foo();  Statement Coverage (SC)
Level C
o Minden kifejezést egyszer
végre kell hajtani
kifejezés
Szoftver Verifikáció teszteléssel DO-178B
# A B C
Foo
Executed
1 0 0 0 NO
2 0 0 1 NO
3 0 1 0 NO
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Coverage
Type
Minimum # of
Test Cases Possible Combinations
Statement 1 4 or 6 or 8
Decision 2 4 or 6 or 8 + Any NO
IF(C AND( A OR B))
THEN Foo();  Decision Condition
Coverage (DC) Level B
o Minden feltétel minden
kimenetét végre kell hajtani
o Minden ki és bemeneti
pontot végre kell hajtani
feltétel
Szoftver Verifikáció teszteléssel DO-178B
# A B C
Foo
Executed
1 0 0 0 NO
2 0 0 1 NO
3 0 1 0 NO
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Coverage
Type
Minimum # of
Test Cases Possible Combinations
Statement 1 4 or 6 or 8
Decision 2 4 or 6 or 8 + Any NO
MCDC 4
2,3,4, and 6 OR 2,4,5
and 6
IF(C AND( A OR B))
THEN Foo();
 Modified Decision Condition Coverage
(MCDC) Level A
o Minden feltétel minden kimenetét végre
kell hajtani
o Minden kondíció minden állapotát le kell
tesztelni
o Minden ki és bemeneti pontot végre kell
hajtani
o Minden kondícióra be kell látni, hogy
befolyásolja a tartalmazó feltételének a
döntését
kondíció
Nyomonkövethetőség DO-178B
 Teljes fejlesztési és üzemeltetési
(30+ év) életcikluson keresztül!
 Követelményektől akár a byte
kódig (Level A)
 Visszakövethetőség biztosítása
 Karbantarthatóság biztosítása
 Hibák visszavezetése
(tervezés/implementáció)
 Jellemezően használt eszközök
o Excel 
o Rational RequisitePro
o Rational Doors
REQ_HLR_SAFE_4_3_2_12:
The take-off angle cannot be
more than 55°
REQ_LLR_TOM_3_67: in the eps_line
method the calculated s1 variable
represents the angle of attack
Nyomonkövethetőség
Fejlesztő eszközök tanúsítványozása (DO-178B)
 Szoftver fejlesztő eszközök
o Hibákat injektálhat a végső rendszerbe
o Ugyan azon követelmények mint a fejlesztési folyamatra 
ugyan azon szintre kell verifikálni mint a fejlesztendő
rendszert!
o Pl., Scade Suite, Matlab Stateflow,
Wind River Diab compiler
Fejlesztő Eszköz
Verifikációs eszközök tanúsítványozás (DO-178B)
 Szoftver verifikációs eszközök
o Egyes hibákat nem detektál
o Normál működési határok között (pl., bemeneti
paraméterek) kell hibamentes működést biztosítani
o Pl., statikus kód analízis eszközök ASTRÉE, CAVEAT
Fejlesztő Eszköz
Modellvezérelt fejlesztés a
repülőgépiparban
A Hibatűrő Rendszerek Kutatócsoport projektjeiben
© DIANA, CERTIMOT, TRANS-IMA, SecureChange
Modellvezérelt fejlesztés biztonságkritikus rendszerekhez
Tradicionális V-Modell Modellvezérelt Fejlesztés
MDE ötletek DO-178C
• rendszermodellek korai validációja
• automatikus kódgenerálás
 Csökkentett fejlesztési költségek
Modellek a Fejlesztésben
Air Conditioning
Management
Required
Temperature
Cabine
Temperature
Heater
UI Feedback
In
Out
Out
Out
Heater
Controller
Terminator
In
In
Out
Out
In
Rendszer
modell
(Tervezés)
Architektúra
modell
(Tervezés)
Komponens
modell
(Tervezés)
Finomítás
Finomítás
Tervezés és verifikációs
dokumentumok
(Forráskód, konfigurációs táblák,
tesztesetek, hibafák, hibadetektorok)
Kódgenerálás Tesztgenerálás
Vertikálismodelltranszformációk
Komponens
Modell
(V&V)
Architektúra
modell
(V&V)
Rendszer
modell
(V&V)
Modellgenerálás
Visszavetítés
Modellgenerálás
Visszavetítés
Modellgenerálás
Visszavetítés
Horizontális modelltranszformációk
Formális
módszerek
Formális
módszerek
Modelltranszformációk a szoftverfejlesztésben
Modelltranszformációk
• tudás transzfer
• elméleti eredményekből
a gyakorlatba
DIANA (EU): ARINC 653
RTOS konfigurációs
leíróinak generálása
Embraer: HW-SW
allokáció és szimuláció
Tervezési
szabályok
Tervezési
szabályok
Tervezési
szabályok
Modell alapú analízis – formális módszerek
Rendszer modell
Rendszer modellezés
Matematikai modell
Modell
generálás
Matematikai analízis
Ellentmondások
listája Analízis
(pl., model checker)
Hiba javítása
Step 9:
-- System Variables (assigments) –
vystem_safety_receive16 = false
var_system_safety[Temp] =
sensorFailed
Modell alapú analízis – formális módszerek
Rendszer modell
Rendszer modellezés
Mathematical
model
Modell
generálás
Matematikai analízis
Ellentmondások
listája Analysis
(e.g model checker)
Hiba javítása
Step 9:
-- System Variables (assigments) –
vystem_safety_receive16 = false
var_system_safety[Temp] =
sensorFailed
 Program kód helyesség bizonyítása
 Model checking
 Szimbolikus futtatás
 Hibafa analízis
 Időzített automaták
 DO-178C 
elfogadott verifikációs
bizonyítékok
TRANS-IMA: Embraer BME-MIT
kooperáció
Friss levegő
szabályozó
Meleg levegő
szabályozó
Hőmérséklet
monitorozás
Hőmérsékelt
beállítása
TRANS-IMA: HW-SW allokáció
Pack
Controller
Zone
Controller
SW funkciók
(kritikus + nem kritikus)
3
System
Display
AirCond
Panel
3
Redundancia
Aft Zone
Forward
Zone
Flight
DeckAir
Conditioning
panel
System
Display
Zone
Controller
Pack
Controller
Pack
Pack
Pack
Controller
Federált
RTOS
TRANS-IMA: Funkciók allokálása
Pack
Controller
Zone
Controller
Aft Zone
Forward
Zone
Flight
DeckAir
Conditioning
panel
System
Display
Zone
Controller
Pack
Controller
Pack
Pack
Pack
Controller
3
System
Display
AirCond
Panel
3
1
3 2
7
példányok
4
5 6
8
Partíciók
ARINC 653
RTOS
Kényszerek
Kritikus és nem kritikus
funkciók nem mixelhetőek
Kritikus funkciók példányai
nem mixelhetőek
2
5
5
4
9
8
8
8
Memória igény+
kényszerek
További kényszerek
• WCET,
• ütemezés, etc.
• interfészek
• adattípusok
SW funkciók
(kritikus + nem kritikus)
TRANS-IMA: Kommunikációs utak allokálása
1
2
3
7
4
5
6
8
Communication
channels
Hőmérséklet
Nyomás
Pára
Aft Zone
Forward
Zone
Flight
DeckAir
Conditioning
panel
System
Display
Zone
Controller
Pack
Controller
Pack
Pack
Pack
Controller
Pack
Controller
Zone
Controller
3
System
Display
AirCond
Panel
3
SW funkciók
(kritikus + nem kritikus)
 ~300-500 funkció
 Komplex hardver architektúra
 Automatizált lépések
 Szimulálás Simulinkben
 Teljes tool-chain megvalósítása
Összefoglaló
 MDE = Modern fejlesztési módszer a
repülőgépiparban
o Megbízható szoftver tervezéséhez
• Szigorú külső tanúsítványozást lehetővé tesz
o Korai hibadetektálás
o Automatikus kódgenerálás
o Nyomonkövethetőség
 Repülőgépipar, mint szoftvermérnöki munka
o Lassan változó terület
o Emberekben/tudásban van az érték
o Hosszú távon is stabil ipar
o Cégek közötti átjárhatóság „támogatott

Szoftverfejlesztés a repülőgépiparban

  • 1.
    Budapesti Műszaki ésGazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Szoftverfejlesztés a repülőgépiparban Azaz miért nem kell félnünk a szoftverhibáktól repülés közben Horváth Ákos BME-MIT
  • 2.
  • 3.
    Repülőgép szoftverek története 0 50 100 150 200 250 300 350 400 MIPSLOC Mbyte/10 Digital links A-310 (1983) A-320 (1988) A-340 (1993) Exponenciális növekedés Mind az A380 és a B 787 több mint 100 millió LOC ~ 100 Mbyte Ref: Subra de Salafa and Paquier
  • 4.
    Fejlesztési folyamat jellemzői Egyedifejlesztési folyamat (jellemzően a V modellre épülve) Repülőgép szoftverfejlesztésre jellemzők  Szigorú tanúsítványozási folyamat o DO-178B (és C)  hogy bebizonyítsa o tanúsítványozással  a rendszer mentes a hibáktól o teljesíti a követelményeket nyomonkövethetőség a követelményektől egészen a bináris kódig! Copyright© CERTIMOT ERC-HU Project
  • 5.
    Tanúsítványozás – DO-178B(C)  DO-178B - Software Considerations in Airborne Systems and Equipment Certification „DO-178B (and DO-278) are used to assure safety of avionics software. These documents provide guidance in the areas of SW development, configuration management, verification and the interface to approval authorities”  Az RTCA szabványa (Európán belül ED-12B)  Teljes civil repülőgépipar által elfogadott szabvány biztonságkritikus szoftverek fejlesztésére o ajánlások  1992 (új verzió 178C 2013)  ~120 oldalas dokumentum
  • 6.
    Szoftver szintek DO-178B Level A&B o Fly-by-wire vezérlés o Autópilóta o Adat megjelenítési réteg o Radar o Hajtómű vezérlés o Fekete doboz  Level C&D o Telemetria o Küldetés tervezése és nyomonkövetése o Rendszer életjel figyelési alrendszerek o Valós-idejű adatrögzítés és kiértékelés (szenzor)
  • 7.
    Előírások (Objectives) eloszlásaa DO-178B 0 5 10 15 20 25 30 35 40 45 Planning Dev. Verif. CM QA Cert. Level A (66) Level B (65) Level C (57) Level D (28)
  • 8.
    Előírások (Objectives) eloszlásaa DO-178B 0 5 10 15 20 25 30 35 40 45 Planning Dev. Verif. CM QA Cert. Level A (66) Level B (65) Level C (57) Level D (28)
  • 9.
  • 10.
    Verifikációs és validációDO-178B Nyomonkövethetőség Verifikáció és Validáció
  • 11.
    Szoftver Verifikáció tesztelésselDO-178B # A B C Foo Executed 1 0 0 0 NO 2 0 0 1 NO 3 0 1 0 NO 4 0 1 1 YES 5 1 0 0 NO 6 1 0 1 YES 7 1 1 0 NO 8 1 1 1 YES Coverage Type Minimum # of Test Cases Possible Combinations Statement 1 4 or 6 or 8 IF(C AND( A OR B)) THEN Foo();  Statement Coverage (SC) Level C o Minden kifejezést egyszer végre kell hajtani kifejezés
  • 12.
    Szoftver Verifikáció tesztelésselDO-178B # A B C Foo Executed 1 0 0 0 NO 2 0 0 1 NO 3 0 1 0 NO 4 0 1 1 YES 5 1 0 0 NO 6 1 0 1 YES 7 1 1 0 NO 8 1 1 1 YES Coverage Type Minimum # of Test Cases Possible Combinations Statement 1 4 or 6 or 8 Decision 2 4 or 6 or 8 + Any NO IF(C AND( A OR B)) THEN Foo();  Decision Condition Coverage (DC) Level B o Minden feltétel minden kimenetét végre kell hajtani o Minden ki és bemeneti pontot végre kell hajtani feltétel
  • 13.
    Szoftver Verifikáció tesztelésselDO-178B # A B C Foo Executed 1 0 0 0 NO 2 0 0 1 NO 3 0 1 0 NO 4 0 1 1 YES 5 1 0 0 NO 6 1 0 1 YES 7 1 1 0 NO 8 1 1 1 YES Coverage Type Minimum # of Test Cases Possible Combinations Statement 1 4 or 6 or 8 Decision 2 4 or 6 or 8 + Any NO MCDC 4 2,3,4, and 6 OR 2,4,5 and 6 IF(C AND( A OR B)) THEN Foo();  Modified Decision Condition Coverage (MCDC) Level A o Minden feltétel minden kimenetét végre kell hajtani o Minden kondíció minden állapotát le kell tesztelni o Minden ki és bemeneti pontot végre kell hajtani o Minden kondícióra be kell látni, hogy befolyásolja a tartalmazó feltételének a döntését kondíció
  • 14.
    Nyomonkövethetőség DO-178B  Teljesfejlesztési és üzemeltetési (30+ év) életcikluson keresztül!  Követelményektől akár a byte kódig (Level A)  Visszakövethetőség biztosítása  Karbantarthatóság biztosítása  Hibák visszavezetése (tervezés/implementáció)  Jellemezően használt eszközök o Excel  o Rational RequisitePro o Rational Doors REQ_HLR_SAFE_4_3_2_12: The take-off angle cannot be more than 55° REQ_LLR_TOM_3_67: in the eps_line method the calculated s1 variable represents the angle of attack Nyomonkövethetőség
  • 15.
    Fejlesztő eszközök tanúsítványozása(DO-178B)  Szoftver fejlesztő eszközök o Hibákat injektálhat a végső rendszerbe o Ugyan azon követelmények mint a fejlesztési folyamatra  ugyan azon szintre kell verifikálni mint a fejlesztendő rendszert! o Pl., Scade Suite, Matlab Stateflow, Wind River Diab compiler Fejlesztő Eszköz
  • 16.
    Verifikációs eszközök tanúsítványozás(DO-178B)  Szoftver verifikációs eszközök o Egyes hibákat nem detektál o Normál működési határok között (pl., bemeneti paraméterek) kell hibamentes működést biztosítani o Pl., statikus kód analízis eszközök ASTRÉE, CAVEAT Fejlesztő Eszköz
  • 17.
    Modellvezérelt fejlesztés a repülőgépiparban AHibatűrő Rendszerek Kutatócsoport projektjeiben © DIANA, CERTIMOT, TRANS-IMA, SecureChange
  • 18.
    Modellvezérelt fejlesztés biztonságkritikusrendszerekhez Tradicionális V-Modell Modellvezérelt Fejlesztés MDE ötletek DO-178C • rendszermodellek korai validációja • automatikus kódgenerálás  Csökkentett fejlesztési költségek
  • 19.
    Modellek a Fejlesztésben AirConditioning Management Required Temperature Cabine Temperature Heater UI Feedback In Out Out Out Heater Controller Terminator In In Out Out In
  • 20.
    Rendszer modell (Tervezés) Architektúra modell (Tervezés) Komponens modell (Tervezés) Finomítás Finomítás Tervezés és verifikációs dokumentumok (Forráskód,konfigurációs táblák, tesztesetek, hibafák, hibadetektorok) Kódgenerálás Tesztgenerálás Vertikálismodelltranszformációk Komponens Modell (V&V) Architektúra modell (V&V) Rendszer modell (V&V) Modellgenerálás Visszavetítés Modellgenerálás Visszavetítés Modellgenerálás Visszavetítés Horizontális modelltranszformációk Formális módszerek Formális módszerek Modelltranszformációk a szoftverfejlesztésben Modelltranszformációk • tudás transzfer • elméleti eredményekből a gyakorlatba DIANA (EU): ARINC 653 RTOS konfigurációs leíróinak generálása Embraer: HW-SW allokáció és szimuláció Tervezési szabályok Tervezési szabályok Tervezési szabályok
  • 21.
    Modell alapú analízis– formális módszerek Rendszer modell Rendszer modellezés Matematikai modell Modell generálás Matematikai analízis Ellentmondások listája Analízis (pl., model checker) Hiba javítása Step 9: -- System Variables (assigments) – vystem_safety_receive16 = false var_system_safety[Temp] = sensorFailed
  • 22.
    Modell alapú analízis– formális módszerek Rendszer modell Rendszer modellezés Mathematical model Modell generálás Matematikai analízis Ellentmondások listája Analysis (e.g model checker) Hiba javítása Step 9: -- System Variables (assigments) – vystem_safety_receive16 = false var_system_safety[Temp] = sensorFailed  Program kód helyesség bizonyítása  Model checking  Szimbolikus futtatás  Hibafa analízis  Időzített automaták  DO-178C  elfogadott verifikációs bizonyítékok
  • 23.
  • 24.
    Friss levegő szabályozó Meleg levegő szabályozó Hőmérséklet monitorozás Hőmérsékelt beállítása TRANS-IMA:HW-SW allokáció Pack Controller Zone Controller SW funkciók (kritikus + nem kritikus) 3 System Display AirCond Panel 3 Redundancia Aft Zone Forward Zone Flight DeckAir Conditioning panel System Display Zone Controller Pack Controller Pack Pack Pack Controller
  • 25.
    Federált RTOS TRANS-IMA: Funkciók allokálása Pack Controller Zone Controller AftZone Forward Zone Flight DeckAir Conditioning panel System Display Zone Controller Pack Controller Pack Pack Pack Controller 3 System Display AirCond Panel 3 1 3 2 7 példányok 4 5 6 8 Partíciók ARINC 653 RTOS Kényszerek Kritikus és nem kritikus funkciók nem mixelhetőek Kritikus funkciók példányai nem mixelhetőek 2 5 5 4 9 8 8 8 Memória igény+ kényszerek További kényszerek • WCET, • ütemezés, etc. • interfészek • adattípusok SW funkciók (kritikus + nem kritikus)
  • 26.
    TRANS-IMA: Kommunikációs utakallokálása 1 2 3 7 4 5 6 8 Communication channels Hőmérséklet Nyomás Pára Aft Zone Forward Zone Flight DeckAir Conditioning panel System Display Zone Controller Pack Controller Pack Pack Pack Controller Pack Controller Zone Controller 3 System Display AirCond Panel 3 SW funkciók (kritikus + nem kritikus)  ~300-500 funkció  Komplex hardver architektúra  Automatizált lépések  Szimulálás Simulinkben  Teljes tool-chain megvalósítása
  • 27.
    Összefoglaló  MDE =Modern fejlesztési módszer a repülőgépiparban o Megbízható szoftver tervezéséhez • Szigorú külső tanúsítványozást lehetővé tesz o Korai hibadetektálás o Automatikus kódgenerálás o Nyomonkövethetőség  Repülőgépipar, mint szoftvermérnöki munka o Lassan változó terület o Emberekben/tudásban van az érték o Hosszú távon is stabil ipar o Cégek közötti átjárhatóság „támogatott

Editor's Notes

  • #3 Segfault -> repülés -> félés -> fly-by-wire ami ugyancsak szoftver 
  • #4 500 to 800 engineers. + CAD modeler another 1500
  • #6 European Aviation Safety Agency Federal Aviation Administration
  • #8 Verifikáció azaz az ellenőrzés
  • #9 Absztrakt előírás –> konkrét megvalósításról nem mond semmit se!
  • #10 Story: arien 5 rakéta kontraktok mennyire jól jöttek volna! (64 bit float-# 16 bit unsigned integer , arine 4-re volt tervezve ahol olyan adat nem jöhetett volna) High-Level requirements Based on system analysis and safety assessment Black-box view of the software component System level considerations Functional requirements by mode of operation Performance criteria Timing requirements Memory size constraints HW and SW interfaces Low-Level requirements and Software Architecture SW requirements Derived from High-Level requirements Design constraints Task allocation Algorithms Data Structures Input/output definitions Data and Control flows Resource management and scheduling (e.g., partition scheduling in ARINC 653) Design Methods
  • #11 Target computer: PC szimulátr, PC-vel összeköthető target HW de még földi áram ellátás és dobozolás, valós repügép méretek és áram ellátás -> itt is van, hogy kijönnek problémák ütemezésben lehet szoros esetben gond! Source Code Usually collection of „high-level” language and assembly Includes linker files, compile commands etc. Executable Completely target computer specific „machine readable” Final output is the integrated system on the target platform
  • #12 Kód-fedettség: minden részét a programnak teszteljük, de az sok mindent jelenthet Minor error 1-500k Dollar Major bug 1-500M Dollar (pl. 787 3 hétre földön maradtak, mert volt valami gond az akkumlátorokkal) Ami emberileg lehetséges meg fognak tenni, hogy kiderítsék ha valami hiba történt -> nem lehet megúszni) A MCDC Level B + 100% Modifed Condition Decision Coverage B DC Level C + 100% Decision Coverage + Independent Designer and Verifer C SC Level D + 100% Low-Level Requirement Coverage +100% Statement Coverage D 100% High-Level Requirement Coverage
  • #13 Minor error 1-500k Dollar Major bug 1-500M Dollar (pl. 787 3 hétre földön maradtak, mert volt valami gond az akkumlátorokkal) Ami emberileg lehetséges meg fognak tenni, hogy kiderítsék ha valami hiba történt -> nem lehet megúszni) A MCDC Level B + 100% Modifed Condition Decision Coverage B DC Level C + 100% Decision Coverage + Independent Designer and Verifer C SC Level D + 100% Low-Level Requirement Coverage +100% Statement Coverage D 100% High-Level Requirement Coverage
  • #14 Minor error 1-500k Dollar Major bug 1-500M Dollar (pl. 787 3 hétre földön maradtak, mert volt valami gond az akkumlátorokkal) Ami emberileg lehetséges meg fognak tenni, hogy kiderítsék ha valami hiba történt -> nem lehet megúszni) Csak eszközzel van esély ilyet mérni A MCDC Level B + 100% Modifed Condition Decision Coverage B DC Level C + 100% Decision Coverage + Independent Designer and Verifer C SC Level D + 100% Low-Level Requirement Coverage +100% Statement Coverage D 100% High-Level Requirement Coverage
  • #19 Model-driven engineering aims at transforming the V model into a Y model by providing early validation of system models with hidden formal methods (up here), and automated generation of source code (down there). As a result, MDE promises to significantly reduce development costs. 0:25
  • #23 Lockeed-Martin vs Rockwell Collins (Steven P. Miller)