Integrated and Modular Systems for Commercial Aviation · PDF fileIntegrated and Modular...

Integrated and Modular Systems Integrated and Modular Systems for Commercial Aviationfor Commercial Aviation

Frank M.G. DFrank M.G. DöörenbergrenbergAlliedSignal Commercial Avionics SystemsAlliedSignal Commercial Avionics Systems

Redmond, WARedmond, WA

Presented at UCLA “Modular Avionics” short courseFebruary 3-7 1997

phone: (206) 885phone: (206) 885--84898489 fax: (206) 885fax: (206) 885--2061 2061 ee--mail: :[email protected]: :[email protected]

Personal introduction

• Education:– MSEE Delft Univ. of Technology (1984)– MBA Nova Southeastern Univ. (1996)

• Work:–AlliedSignal Aerospace since 1984

• Principal Eng on Integrated Hazard Avoidance System program (‘96-)• Prog Mgr / Staff Eng on Be-200 Integr. Avionics program (‘94-’96)• Lead systems engineer on A330/340 SFCC program (‘89-93’)• Systems engineer on Boeing 7J7 PFCS prototype program (86-’89)• Engineer on autopilot and flight simulator program (‘84-’86)

• Miscellaneous:– Private pilot

Integrated and Modular Systems Integrated and Modular Systems for Commercial Aviationfor Commercial Aviation

Frank M.G.Frank M.G. DDöörenbergrenberg

phone: (425) 836phone: (425) 836--4594 e4594 e--mail: frank.mail: frank.doerenbergdoerenberg@@usausa.net .net ©1995-1997 F.M.G. Dörenberg

©1995-1997 F.M.G. Dörenberg

2

Personal introduction

• Education:– MSEE Delft Univ. of Technology (1984)– MBA Nova Southeastern Univ. (1996)– Enrolled in PhD/EE program at University of Washington

• Work:–AlliedSignal Aerospace since 1984

• Principal Eng on Integrated Hazard Avoidance System program (‘96-)• Prog Mgr / Staff Eng on Be-200 Integr. Avionics program (‘94-’96)• Lead systems engineer on A330/340 SFCC program (‘89-93’)• Systems engineer on Boeing 7J7 PFCS prototype program (86-’89)• Engineer on autopilot and flight simulator program (‘84-’86)

• Miscellaneous:– Private pilot


3

Integrated and Modular Avionics

• Introduction

Why change avionics?Why change avionics?• Integration• Modularization• Future .....


4

Global aviation system

IntegratedAviationSystem

Aircraft

Airlines &Operators

Airspace Sys.,ATC/ATM

Environment

Ground & SpaceInfrastructure

Gov’t & IndustryAgencies

AirframeMfrs

AvionicsMfrs

Payload

Crew

- changes must be considered in overall system context-

- many stakeholders, requirements, constraints, competition -


5

Aircraft sub-systems

Engine thrust

Electricalpower

Comm/NavSurveillance

Air Data

Cabin lighting

Structure& Gear

Computer/Data links

Fuel Mgt

FlightControl

Games& video

Phone& fax Cabin

call/PA

Audiovideo

Cargo/bag handling

Galleys & water/waste

Cabin airpress/temp

= req’d for ops in air transport system= req’d for cargo and pax comfort/well-being


6

Why change avionics?

• Airline/Operators’ point of view:to increase profit potential

¯ lower acquisition cost¯ reduced maintenance cost¯ profitable at reduced load factor

ROI, LCC, affordability, paybackseat-mile economicsserviceable and flyable with minimal maint. andflight crew training (inc. fleet commonality)

payload, range, route structures, fuel burn (weight & volume of equipment/wiring/installation/structure)

cont’d →

- familiar business criteria: benefits, cost, risks, profit -


7


• Airline/Operators’ point of view (cont’d):safety (e.g., CFIT, WX & Windshear Radar, TCAS)

reliability, dispatchabilitydeferred maint., reduced unscheduled maint.improved BITE (fault isolation, MTBUR/MTBF)

compliance with new regulations (e.g., TCAS)

increased crew & pax comfortgoal: on-time-arrival-rate = dispatchability-rate

(now: 80% vs. 98%). Currently, existing capability cannot be utilized due to ATC incompatibilities.

cont’d →


8


• Airline/Operators’ point of view (cont’d):reduced turnaround time at gate (productivity)

to support migration towards functionally flexible a/c (configuration changes) that allows:

– easy incorporation of systems changes– response to changes in operational environment

to have systems that are mature at entry into serviceinstead of years later (esp. for early ETOPS)

to reduce the cost of future software mods


9

Operators seek revenue enhancement

•Value-added in the areas of: operational efficiencyeconomic utility

and above allsafety

- no new technology for its own sake -ref.: Welliver, A.D.: “Higher-order technology: Adding value to an airplane,” Boeing publ., presented to Royal Aeronautical Society, London, Nov. 1991ref.: “Is new technology friend or foe?” editorial, Aerospace World, April 1992, pp. 33-35ref.: Fitzsimmons, B.: “Better value from integrated avionics?” Interavia Aerospace World, Aug. 1993, pp. 32-36ref.: ICARUS Committee: “The dollars and sense of risk management and airline safety”, Flight Safety Digest, Dec. ‘94, pp. 1-6


10

Gains from avionics technology investmentsA

irpla

ne O

pera

tiona

l Eff

ectiv

enes

s →

1900 1950 2000

Individual non-avionic technologies• aerodynamics• flight controls• structures• propulsion

Info integration technologies

Avionics technologies

Wright Flyer

- avionics is (growing) part of the equation -


11

Why change avionics? (cont’d)

• Authorities:ATC & ATMground- & space-based infrastructurefed & int’l (de-)regulationssafety (e.g., TCAS, smoke det.)

environment

• Avionics suppliers:customer satisfaction, one-stop-shoppingcost reduction / profitability marginstechnological leadershipstrategic shift from BFE (commodity) → SFE integrate competitors’ traditional products“integrate or die”

ref.: P. Parry: “Who’ll survive in the aerospace supply sector?”, Interavia, March ‘94, pp. 22-24ref.: R. Ropelewski, M. Taverna: “What drives development of new avionics?”, Interavia, Dec. ‘94, pp. 14-18 & Jan. ‘95, pp. 17-18


12


• Airframe manufacturer:

customer satisfaction, product performance, passenger appeal

significant cost reduction over previous generation (esp. for smaller a/c, due to seat-cost considerations; e.g. 100 paxtarget: $35M → $20M)

reduced cycle time:– a/c development– a/c production (e.g., equipment installation & wiring)

competition (incl. from used & stored a/c, teleconf.) cont’d →


13


•Airframe manufacturer (cont’d):

more demanding systems characteristics:– maint. deferred for 100-200 hrs or even until C-check

(fault tol., spare-in-box)

– fault-tolerance transparent to application s/w– brick-wall partitioned applications– all Aps & Ops software: on-board loadable/upgradeable– 100% fault detection and complete self-test (w/o test equipment)

– 95% reliability over a/c life (60k-100k hrs)

- more, better, cheaper, faster -

ref.: P. Parry: “Who’ll survive in the aerospace supply sector?”, Interavia, March ‘94, pp. 22-24ref.: R. Ropelewski, M. Taverna: “What drives development of new avionics?”, Interavia, Dec. ‘94, pp. 14-18 & Jan. ‘95, pp. 17-18


14


• Air traffic reasons:world/regional air traffic growthproductivity improvement: traffic volume, density, flowmaintain & enhance safety

• Technical & technological reasons:airframe or engine changesobsolescence, new capabilities

- system solutions to achieve conflict-free navigation while executingthe best performance flight-plan, moderated by passenger comfort -


15

Avionics business

• high-tech but low volume• typ. ½-life time frames:

airframe: 25 yearselectronics: 2 yearsdata buses: 10-15 yearsHOL: ?

- aircraft life-cycle: initial development, production run, through a/c lifespan after last one delivered -


16

Changing airtransport environment• (total) c o s t i s p a r a m o u n t• emerging markets• airlines (still) show cumulative net loss (carriers gradually

returning to fin. health; ‘95 global airline operating profits $6B vs. ‘92 loss of $2B)

• airline mergers, alliances, bankruptcies• airlines seek revenue enhancement and cost reductions• increasing airtraffic volume, delays• FANS/“free flight”: increased capacity, reduced separation, same or better safety

• airlines & airframers want RC↓, forcing suppliers’ NRC↑• no real competition yet from video/teleconf. (biz travel)

- airplanes are a commodity in rising cost environment -


17

Changing airtransport environment

DOC

Productivity≈ +5-6% p.a.

Revenue/Expense ratio

Yield

1960 65 70 75 80 85 90

Inde

x100

0

10

≈ -2.5-2.9% p.a.

- airline performance trends -ref.: Airline Business, January 1996, p. 29ref.: A. Smith: “Cost and benefits of implementing the new CNS/ATM systems”, ICAO Journal, Jan/Feb ‘96, pp. 12-15, 24


18

Scheduled passenger traffic trends

International

Domestic

1200

1000

800

600

400

200

1990

1991

1992

1993

1994

1995

Sche

dule

d pa

x (m

illio

ns)

≈ +5%/year19

96

1997

1998

1999

≈ +7%/year

2000

≈ +6%/year

2005

Σ =1.7 B

- World air traffic growth outpaces economic growth -

- world fleet is forecast todouble over 20 years -

(by 2015: ≈ 20,000 * > 50 seats )* ex CIS & Baltic states

ref.: Flight International, 3-9 January 1996, p. 27,28ref.: Boeing CAG Current Market Outlook 1995ref.: K. O’Toole: “Cycles in the sky”, Flight Int’l, 3-9 July 1996, p. 24ref.: “IATA raises five-year passenger forecast”, Flight Int’l, 6-12 Nov 1996, p. 8


19

Scheduled-passenger and freight traffic - steady growth

Passengers

Most likely (5.5% p.a.)

Most likely (7% p.a.)

Freight

ACTUAL ICAO FORECAST

5000

1000

300

500

100

30

Pax-k

m (b

illion

s, log

-scale

)

Tonn

e-km

(billi

ons,

log-sc

ale)

1985 1995 2005

- potential for airspace and airport congestion -ref.: C. Lyle: “Plan for guiding civil aviation in the 21st century repesents a renewed commitment by ICAO”, ICAO Journal, March 1997, pp. 5-


20

Changing airtransport environment

RPMs, billions

North AmericaIntra Asia Pacific

Intra EuropeTrans Pacific

North AtlanticAsia-Europe

CIS DomesticNo. Amer.-Lat. Amer.

Europe-Lat. Amer.Europe-AfricaLatin America

CIS International

0 200 400 600 800 1,000

1994 trafficGrowth 1995-2014

source: Boeing CAG Current Market Outlook 1995


21

Commercial aircraft sector - on the rebound80

60

40

20

0

Bill

ions

of 1

995

US

$

‘71-’75 ‘81-’85 ‘91-’95 ‘01-’05‘76-’80 ‘86-’90 ‘96-’00 ‘06-’10 ‘11-’15

Average annual new aircraft investments (world fleet)

Source: The Boeing Co. 100

75

50

25

0

Source: GE Capital Aviation Services

25 30 3520 Age in years

Perc

enta

ge re

tired

900

800

700

600

500

400

300

200

100

01958‘60‘62‘64‘66‘68‘70‘72‘74‘76‘78‘80‘82‘84‘86‘88‘90‘92‘94‘96‘98‘00‘02

Other

McDonnell Douglas

BoeingAirbus

Source: Lehman Bros.

1988 1989 1990 1991 1992 1993 1994 1995 1996 1997

1,000

750

500

250

0

Num

ber o

f airc

raft

Source: GE Capital Aviation Services

Serviceable a/c available for sale or lease

Retirement of aircraft

Air transport annual deliveries

ref.: A.L. Velocci: “Restraint, Airline health key to stable rebound”, AW&ST, Nov. 25 1996, pp. 36-38ref.: P. Sparaco: “Airbus plans increased production rate”, AW&ST, Nov. 15 1996, pp. 48-50


22

Direct Operating Cost

fuel maint.

crew

ownership

12-15%10-15%avionics & flight contr.

1/3

systemsEuro-regionals: ≈ 50% of DOC is beyondcontrol of owner/operator (fees forlanding /ATC/ground-handling + fuel)

ref.: P. Condom: “Is outsourcing the winning solution?”, Interavia Aerospace World, Aug. ‘93, pp. 34-36ref.: 1992 ATA study of U.S. airlines


23

Direct Operating Cost

Worldwide airlinesavg costs (1993)

12%

27%

11%7

12%G&A

pax services,promo,

ticketing/sales

landing fees etc

27%

4

747-400($6673/hr)

31%

17%32%

20%

737-500($1607/hr)

25% 26%

24%26%

737-300($1834/hr)

23%30%

23%24%

DC-9-30($1612/hr)

27%

33%29%

11%

Fokker-100($1661/hr)

20% 28%

14%38%

737-400($1797/hr)

8%

36%

27%

30%

747-200/300($7611/hr)

28%

16% 31%

25%

MD-80($1825/hr)

27%

19%27%

27%

DC-10-30($4306/hr)

34%

20%25%

25%

($3802/hr)

11%

17%

45%

27%

A300-600

MD-11($4530/hr)

15%20%

31%

34%

A320($4530/hr)

11%

25%

25%

40%

L-1011-1/200($3799/hr)

36%14%

25%25%

crew

maint. & o'haul

ownership(insurance,

possession, etc.)

fuel & oil

U.S. major carriersall items in U.S.$

per block houryear ending Sept. 31,'94

ref.: Air Transport World, Jan-May 1995ref.: “The guide to airline costs”, Aircraft Technology Engineering & Maintenance, Oct/Nov 1995, pp. 50-58


24

Aircraft operating statistics

B747-400B747-100L-1011DC-10-10A300-600MD-11DC-10-30B767-300ERB757-200B767-200ERA320-100/200B727-200B737-400MD-80B737-300DC-9-50B737-500B737-100/200DC-9-30F-100DC-9-10

ref.: ATA “Aircraft operating statistics - 1993”, http://www.air-transport.org

3983902882812662542482211861851491481441411311241131121009772

553520496492473524520493457483445430406422414369408387383366381

4,3313,0601,4981,4931,2073,4592,9472,2851,0862,031

974686615696613320532437447409439

3,3563,4902,3842,2291,9382,2322,6121,5491,0041,392

7711,251

775891748893708800798737740

$6,9395,3964,5644,2614,3324,5704,8163,2512,3033,0121,8162,2221,7791,7931,8181,9011,5941,7571,6901,6811,332

Number of Seats

SpeedAirborne

FlightLength

Fuelgph

OperatingCost per hr

all numbers are average

AircraftType/model


25

Big $ numbers

life-time maintenance cost (ROM), example:

• maintenance ≈ $1200/block hour • airplane life-time ≈ 60+ k hours• maintenance-over-life ≈ $75 million

- Boeing 747-400 -

ref.: Air Transport World, Jan-May 1995


26

Life Cycle Cost* (LCC)

•inflation corrected price-tag of airplanes has increased over the years**

•not completely offset by simultaneous reduction in DOC

Fact:Fact:* Net Present Value (NPV) of cost & benefit $-flows

New systems & technology can only be justified if they:

•take cost out of the airplane•reduce DOC•increase revenue

** contrary to e.g. consumer electronics


27

Save now and save later• increased reliability• reduced size, weight, power consumption, cooling• reduced development and production time/cost• easily upgraded/updated to new engine or airframe• easily upgraded/updated to new ATC environment• reduced crew workload• contribute to on-time departure and arrival• support accurate and simple diagnostics (w.o external test eq.)

• as common as possible fleet-wide for different aircraft• mature systems at entry-into-service (esp. for ETOPS out-of-the-

box)

ref.: C.T. Leonard: “How mechanical engineering issues affect avionics design”, Proc. IEEE NAECON, Dayton, OH, ‘89, pp. 2043-2049


28

Airlines’ primary product is reliable scheduled revenue service

Schedule deviations are expensive:

•departure delays (up to $10k / hour)

•flight cancellation (up to $50k)

•in-flight diversion (up to $45k)

•in terms of pax perception: incalculable

- 50% of delays/cancellations caused by improper maintenance -(other causes: equipment, crew, ATC*, WX, procedures, etc.)

* mid ‘90s cost to airlines in Eu due toATC delays est. at $1.9-2.5B p.a.

ref.: Commercial Airline Revenue Study by GE Aircraft Engines (Jan. ‘88 - Jan. ‘92)ref.: B. Rankin, J. Allen: “Maintenance Error Decision Aid”, Boeing Airliner, April-June ‘96, pp. 20-27


29

Average schedule deviation costs

- examples -

departure delays ($/hr)

flight cancellationturn-backin-flight diversion

B737$ 2k5$ 7k6$ 5k9$ 7k6

B757$ 5k0$ 14k9$ 10k9$ 12k8

B767$ 6k3$ 18k9$ 13k8$ 16k1

B747-400$ 9k3$ 37k2$ 22k6$ 28k7

ref.: BCAG 1993 Customer Cost Benefit Model


30

Boeing 777 Development Cost

Systems

Structures

Aero

Propulsion

Misc.

Payloads

47 %

28 %

5 %7 %

7 %

6 %≈ 70%

SoftwareHardware

Dev.+ V&V

≈ 30%

V&V

Develop-ment

½ ½

(engineering & labs)

ref.: P. Gartz, “Systems Engineering,” tutorial at 13th DASC, Phoenix /AZ, Oct. ‘94, & 14th DASC, Boston/MA, Nov. ‘95ref.: C. Spitzer, “Digital Avionics - an International Perspective,” IEEE AES Magazine, Vol. 27, No. 1, Jan. ‘92, pp. 44-45


31

Integrated Modular Avionics Architectures

- more than just a “cabinet solution” -

• Integration• Modularization• Standardization

- all are key attributes of partitioning -

ref: Robinson, T.H., Farmer, R., Trujillo, E.: “Integrated Processing,” presented at 14th DASC, Boston/MA, Nov. 1995ref.: L.J. Yount, K.A. Liebel, B.H. Hill: “Fault effect protection and partitioning for fly-by-wire/fly-by-light avionics systems”,

Proc. 5th AIAA/IEEE Computers in Aerospace Conf., Long Beach/CA, ‘85, 10 pp.


32

Dependability Taxonomy

Attributes Means Impairments

Dependability

SafetyReliabilityDispatchabilityMaintainabilityIntegrity

Fault avoidanceFault toleranceFault removalFault forecasting

FaultsErrorsFailures

- dependability: degree of justifyable reliance that can placedon a system’s delivery of correct and timely service -

ref.: Int’l Federation of Information Processing Working Group on Dependable Computing & Fault Tolerance (IFIP WG 10.4)ref.: Prasad, D., McDermid, J., Wand, I.: “Dependability terminology: similarities and differences”, IEEE AES Systems Magazine, Jan. ‘96, pp. 14-20ref.: F.J. Redmill (ed.): “Dependability of critical computer systems - 1”, 1988, 292 pp., Elsevier Publ., ISBN 1-85166-203-0ref.: A. Avizienis, J.-C. Laprie: “Dependable computing: from concepts to design diversity”, Proc. of the IEEE, Vol. 74, No. 5, May ‘86, pp. 629-638


33

Fault Avoidance

• controlled, disciplined, consistent Sys. Eng. process• simplicity, testability, etc.• reduced parts count, interconnects & interfaces (integrate!)• standards, analyses, simulations, lessons-learned, V&V• partitioning (for fault containment & isolation, cert., etc.)• shielding, grounding, bonding, filtering• controlled operating environment (cooling, heatsinks, etc.)• properly select, handle, screen, and de-rate parts• test• human factors• zero-tolerance for patch work in req’s & design• etc., etc.

- must address entire product life-cycle: from inception through disposal -

- prevent (by construction) faults from entering into, developing in,or propagating through the system -

Fault Tolerance- the ability of a system to sustain one or more specified faults

in a way that is transparent to the operating environment -

• achieved by adding & managing redundancy: one or more alternate means to perform a particular function or flight operation

• goal: only independent, multiple faults and design errors remain as reasonably possible causes of catastrophic failure conditions

• fail-passive, fail-safe, fail-active are fail-intolerant• “fault tolerant” does not imply “highly dependable”,

“fault free”, “ignorance tolerant”, or “full/fool proof”ref.: J.H. Lala, R. Harper: “Architectural principles for safety-critical real-time applications”, Proc. of the IEEE, Vol. 82, No. 1, Jan. ‘94, pp. 25-40ref.: D.P. Siewiorek, R.S. Swarz (eds.): “Reliable Computer Systems”, 2nd ed., Digital Press, ‘92, 908 pp., ISBN 1-55558-075-0ref.: M.R. Lyu (ed.): “Software fault tolerance”, Wiley & Sons, ‘95, 337 pp., ISBN 0-471-95068-8ref.: F.J. Redmill: “Dependability of critical computer systems - 1”, ITP Publ., ‘88, 292 pp., ISBN 1-85166-203-0ref.: B.W. Johnson: “Design and Analysis of fault tolerant systems”, Addison-Wesley, ‘89, 584 pp., ISBN 0-201-07570-9ref.: “25th Anniversary Compendium of Papers from Symposium on Fault Tolerant Computing”, IEEE Comp. Society Press, ‘96, 300 pp., ISBN 0-8186-7150-5ref.: J.C. Laprie, J. Arlat, C. Beounes, K. Kanoun, C. Hourtolle: “Hardware- and software-fault tolerance: definition and analysis of architectural solutions”, Proc. 17th

Symp. on Fault Tolerant Computing, Pittsburg/PA, July ‘87, pp. 116-121


35

Fault Tolerance Taxonomy

Fault isolation &Reconfiguration

• adaptive voting & signal select• dynamic task reallocation• graceful degradation• n-parallel, k-out-of-n• s/w recovery (retry, rollback)• operational-mode switching

• operating (hot, shadow)• non-operating (cold, flexed)

StandbyActive

Examples of techniques: Examples of techniques:switch-in backup spare(s)

• physical• temporal• data

Fault Tolerance

Redundancy Management

Static (Fault Masking) Dynamic

• comparison (cross, voter, wrap-around)• reasonableness check (rate, range, cross)• task execution monitor (a.k.a. Watch Dog)• checksum, parity, error detection code• diagnostic and built-in tests

• Similar• Dissimilar

• no fault detection• no reconfiguration

Fault detection

interwoven logichardwired multiple hardwareredundancyerror correcting codemajority voting (N-modularredundancy)

No fault reaction:

Examples of techniques: Examples of techniques:••

••

Hybrid

• pooled sparesExample of techniques:

Redundancy


36

Fault Classifications- fault tolerance approach is driven by the number & classes of faults

to protect against, as well as by criticality and risk-exposure -

ActivityDurationPerceptionCauseIntentCountTime (multiple faults)Cause (multiple faults)

Latent vs. activeTransient vs. permanentSymmetric vs. asymmetricRandom vs. genericBenign vs. maliciousSingle vs. multiple(Near-) Coincident vs. DistinctIndependent vs. common-mode

Criteria Fault type

“Nothing in nature is random ... A thing appears random only through the incompleteness of our knowledge” -- Spinoza, Dutch philosopher 1632-1677

ref.: N. Suri, C.J. Walter, M.M. Hugue (eds.): “Advances in ultra-reliable distributed systems”, IEEE Comp. Society Press, ‘95, 476 pp., ISBN 0-8186-6287ref.: M. Hugue: “Fault Type Enumeration and Classification”, ONR-910915-MCM-TR9105, Nov. 1991, 26 pp.


37

Redundancy

• Attributes:form (physical, temporal, performance, data, analytical)similarity/diversity*level of replicationphysical distribution within a/callocation along end-to-end pathconfiguration (grouping & interconnects)redundancy management concept (static, dynamic)

- more resources that required for fault-free single-thread operation -* Notes:- dissimilarity’s power is based on assumption that it makes simultaneous common-mode (generic) faults extremely improbable- dissimilarity does not reduce the probability of simultaneous random faults- dissimilarity provides little advantage against common-mode environmental faults (EMI, temp/vibe, power)- dissimilarity allows shift away from proving absence of generic faults, to demonstrating ability to survive them (cert. level!) - dissimilarity of design drives source of faults back to (common) requirements and system architecture- dissimilarity is fault avoidance tool, as long as independence is not compromised when fixing ambiguities or divergence


38

Higher reliability- will it make a difference in airline maintenance? -

• frequent cause of maintenance today is not avionics LRUs, but interconnects, sensors and actuators (as much as 60%)

• improving MTBUR* more important than increasing MTBF (goal: MTBUR/MTBF ratio ½ → 1)

• complete system forms a chain: high-rel is required at system level, not just at “box” level

• MTBF & MTBUR ↑↑ may lead to “Avionics By The Hour”:concept: operator leases equipment, only pays for actual hours flownavionics mfr needs this too: sells fewer spares ⇒ (much) less profit

* unit pulls on maintenance alert only, not to rotate/canibalize/swap within a fleet- keep the good part on the plane -

ref.: P. Seidenman, D. Spanovich: “Building a Better Black Box”, Aviation Equipment Maintenance, Feb. ‘95, pp. 34-36 ref.: D. Galler, G. Slenski: "Causes of Electrical Failures," IEEE AES Systems Magazine, August 1991, pp. 3-8ref.: M. Pecht (ed.): “Product reliability, maintainability. and supportability handbook”, CRC Press, ‘95, 413 pp., ISBN 0-8493-9457-0ref.: M. Doring: “Measuring the cost of dependability”, Boeing Airliner Magazine, Jul-Sep ‘94, pp. 21-25


39

Basic ways to increase system reliability

• higher intrinsic reliability (components)

• fault avoidance (entire life-cycle)

• fault tolerance redundant architecture*reconfigurable architecture (LRU failure typ. only involves single component)at box level → module level → chip level (with full BIT on-die)

• integration:reduce on-board & off-board interconnects: weakest link in the reliability chainshare resources (reduce duplication)

* redundancy may increase availability, but at same time increases prob. that redundant copies are inconsistent/diverge

- towards reliability of the wiring (exc. connectors) -


40

N-Parallel Redundancy

5

1

0.5

0

1

0.5

Number of redundant units

3

10

15Operating

time (hrs)100k

20k

λunit = 5x10-5/hMTBFunit = 20,000 hrs

Example:

(=MTBF)

40k

SystemReliabil i ty

- brute force: inefficient to achieve very high system reliability -37


41

N-Parallel Redundancy

5

1

0.5

0

1

0.5

Number of redundant units

3

10

15Operating

time (hrs)100k

20k

λunit = 5x10-5/hMTBFunit = 20,000 hrs

Example:

(=MTBF)

40k

SystemReliabil i ty

Desiredregion60k

100k

0.9 - 0.95

- goals: low cost & low redundancy but high rel. & safety -38


42

MTTF as function of redundancy levelMTTFn-parallel ∝ ln(n) x MTTFunit

from n=1 23

2

1

1 5 10 150

0.5

MTTFnMTTF1

practical limit

=

=∆ MTTF

Number ofParallel units

(curves do not account for rel. penalty of complexity)

- diminishing returns -


43

Parallel redundancy for system reliability

0.001 0.01 0.1 1.0 10

10 = 1

-110

-210

-410

-510

-310

-610

0

-710

F2-out-of-2

F2-out-of-N(t)(t)

tMTTFunit

N=3

N=4

N=2 F2-out-of-2

F2-out-of-2 = 1Note: log-log scale

- adding redundancy is only effective for t << MTTFunit -


44

RedundancyNote: curves are for fail-passive configs, except those shown for simplex, cube, and n-parallel

10

0.5

1.0

1/e

3-parallel

cube

Rconfig(t)

= MTTFdual

triplex

simplex

dual-dual

dual-quad

4-parallel

quad

2

2-parallel

t =MTTFunit

dual-triplex

3tMTTFunit

- fault-tolerant configs exhibits-curve reliability -


45

System architecture and design decisions ........

MOTHER GOOSE & GRIMM


46

Redundancy

10

0.5

1.0

1/e

3-parallel

cube

Rconfig(t)

= MTTFdual

triplex

simplex

dual-dual

dual-quad

4-parallel

quad

2

2-parallel

t =MTTFunit

dual-triplex

3tMTTFunit

- redundancy for fault-toleranceand extended system reliability -

region of practical use


47

Redundancy

1.0

Rconfig(t)0.9

0.8

0.5 1.0

cube

4-p2-p

3-p

dual-quad

dual-triple

quad

triplex

dual-dualsimplex

dual

MTTFunitt

- region of practical use, enlarged -


48

Relative MTTF of various configurations

SimplexDual

TriplexQuad

Dual-DualDual-Triplex

Dual-QuadTriple-DualQuad-Dual

Triple-Triple2-Parallel3-Parallel4-Parallel

Cube

note: MTTFs solely based on time-integration of reliability funct., and do not reflect system complexity; Markov analysis may give different result.


49

Mission times of several configurations

Time-to-R= 0.997 Time-to-R= 0.95 Time-to-R= 0.5 (Median TTF)

Simplex

Dual

Triplex

Quad

Dual-Dual

Dual-Triplex

Dual-Quad

Triple-Dual

Quad-Dual

Triple-Triple

2-Parallel

3-Parallel

4-Parallel

Cube


50

“Cube” configuration conceptnote: output wraparounds not shown

λb

3-parallel “cube”increased number of

paths through the system

“optimized cube”

λ1 λ1 λ1 λb

λa λa λa

λc λc λc

λb

λa λa

λc λc λc

if no single-thread ops., thendon’t need 3 output modules

λbλb λb

- use resources more efficiently: do not discard entire lane if only part fails -ref.: M. Lambert: “Maintenance-free avionics offered to airlines”, Interavia, Oct. ‘88, pp. 1088-


51

Integration is necessary because....

• Increase operational effectiveness via integration of information (e.g., safety)

• Must work smarter, not harder: – system reliability increases only slowly as redundancy level increases:

∝ ln(n)– above n = 3, adding redundancy is not effective– “brute force” will not get us there

• Unit-reliability is more powerful than redundancy level in achieving high system reliability

- Fit-and-forget system reliability (based on conventional redundancy) implies units with reliability of today’s components (λ ≈ 10-7/h) −


52

Integration of what?

• hardware, software, mechanical elements• data buses, RF apertures• related, interacting, closely associated, similar functions

& controls (reduce duplication)

• distributed information e.g., fusion for more meaningful pilot info (“smart alerting”, EMACS)e.g., improve performance (flight + thrust control, ECS)

• displays, controls, LRUs (esp. single-thread)

• BIT increase fault isolation accuracyreduce NFF/CND/RETOK* from 50% to < 10%

• organizations, people• entire aviation system

* ATA est. NFF cost to US airline industry ≈ $100M p.a., avg $800 per removal (labor, shipping, sparing)

ref.: P. Gartz: “Trends in Avionics Systems Architecture”, presented at the 9th DASC, Virginia Beach/VA, Oct. ‘90, 23 pp.ref.: Avionics Systems Eng. & Maint. Committee (ASEMC) of the Air Transport Ass’n (ATA)ref.: Avionics Magazine, Feb. 1996, p. 12


53

Integration trend: Multi-Mode Receiver (MMR)

• ICAO philosophy change (Comm/Ops meeting, Montreal ‘95):

from: single-system (e.g., VOR/DME) standard, ensuring int’l uniformity & compatibilityto: standardizing on 3 quite different approach aids (ILS, MLS, GNSS*)so: CAAs, airports, operators free to choose one or moreand: world aviation authorities should promote the use of Multi-Mode Receivers (MMRs) or equivalent avionicsref.: W. Reynish: “Three systems, One standard?”, Avionics Magazine, Sept. ‘95, pp. 26-28ref.: D. Hughes: “USAF, GEC-Marconi test ILS/MLS/GPS receiver”, AW&ST, Dec. 4 ‘95, pp. 96ref.: R.S. Prill, R. Minarik: “Programmable digital radio common module prototypr”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 563-567ref.: ARINC-754/755 (analog/digital MMR), ARINC-756 (GNLU)

* ICAO: GNSS > GPS (e.g., GNS+GLONASS, to ensure complete redundancy, esp. in landing ops.)


54

Integration trend

FMGD

1970s 1980s 1990s 2000-2010

LRUs SystemOn

Chip

λ total

-2~~10 λ total- 4~~10 λ total

- 5~~ 2x10 λ total

-7~~10

point-to-point analoginterconnect

system level redundancy box level redundancy card level redundancy chip level redundancy

single-thread systems single-thread LRUsfault tolerant LRUs

fault tolerant cards

ARINC-429 digitalinterconnect

ARINC-629 digital databus between LRUs high-speed fiber optic

comm. between systemsARINC-659 backplanebus between LRMs

ref: BCAC/J. Shaw


55

Integration issues

• “integrated system” is not a “package deal”• airline:

no more option to pick favorite supplier for each federated LRUbut gets improved availability, reduced sparing & LCC

• as levels of (functional) integration increase → more stringent availability & integrity req’s than for more distributed implementation

• if integration requires fault-tolerance (= redundancy), some of the gains from reduced duplication are lost

• compared to “conventional” LRUs, cabinet/LRM solutions pose challenge to effective shielding/bonding for EMI/Lightning protection

• partitioning provides change/growth flexibility: only re-certify changed areas


56

Integration issues (cont’d)

• loss of a shared resource affects multiple functions → potential for single-point/common-mode failure due to contaminated data flow, control flow, resource:

fault tolerance required to meet availability & integrity req’spartitioning must be part of architecture and independent of application softwareincreased importance of FMEA, FHA, etc.

• mixed levels of criticality: certify at highest level, or certify thepartitioning protection.

• criticality of the “whole” may be higher than that of “stand-alone”parts due to effects of loss (3x “essential” → “critical” ?)

• technology readiness (risk): development of fault-tolerant integrated architectures drives a/c level schedules (be mature at a/c program go-ahead)


57NO unpleasant surprises!

Dispatchability:

Larson

Fault Tolerance for Safety, Reliability,


58

FAA/JAA Hazard Severity Classification

Catastrophic

Hazardous /Severe-Major

Major

Minor

No Effect

Some passengers injuredSlight reduction of safety margins or functional capabilities

Operational limitations, diversions, flight plan changes

No effect on operational capability of aircraftNo increase in crew workloadConcern, nuisance

Slight increase in crew workload, well within capabilities

Inconvenience to passengers

Large reduction in safety margins or functional capabilitiesDifficult for crew to cope with adverse operating conditions, and

Some passengers seriously injured (potentially fatal)

Significant reduction in safety margins or functional capabilitiesSignificant increase in crew workload or conditions impairingcrew efficiency

Multiple deathsLoss of aircraftPrevents continued safe flight and landing

•••

••

•

••

•

••

••

•cannot be relied upon to perform tasks accurately & completely

••

FAR /JAR

Failure

Classification

Effect of failure condition onaircraft and occupantsCondition

25-1309AC25.1309-1A

*

*determined by performing Funct. Hazard Assess. (FHA)

- hazard severity: worst credible known/potential consequence of mishap -


59

FAA/JAA Probability Ranges

JARQualitative

Probable

Improbable

Extremely Improbable

Frequent

Reasonably

Remote

Remote

Probable

Extremely10-7

10-5

10-9

10-3

1

FARQualitative

0

several times during operationallife of each airplane

occasionally during totaloperational life of allairplanes of particular typenot expected to occur in entirefleet operational life

Qualitative ProbabilityQuant.Prob.

AC 25.1309-1AAMJ 25.1309

* *

* FAR & JAR are being harmonized

- qualitative and quantitative -


60

FAA/JAA Criticality Index

Improbable

Probable

ImprobableExtremely

Acceptable

Non-Essential

Acceptable

Acceptable

failure would no t contribute to, or causes a failure

condition which wouldsignificantly impact airplane

safety or crew ability tocope with adverse condit.

Essential (B)

Unacceptable

Acceptable

failure contributes to, orcauses a failure condition

which would preventcontinued safe flight and

landing

(A)

Unacceptable

Acceptable

unless single failure

Probability

failure contributes to, orcauses a failure conditionwhich would significantlyimpact airplane safety orcrew ability to cope withadverse operating condit.

Equipment (C)Critical

Unacceptable

unless single failure

Conditionally

Acceptable

Hazard

Category

- allowed combinations of hazard severity and probability -


61

FAA/JAA Hazard Index

Catastrophic

Hazardous /Severe-Major

Major

Minor

No Effect

D

E

FAR /JAR

ARP 4754

DO-178BDO-180

25.1309

A

B

C

Failure SystemDesign

AssuranceClassification LevelCondition

AC/AMJ

ProbabilityObjective

extremelyremote

remote

none

none

extremelyimprobable

Fail-safe Single-pointFailures

norequirement

norequirement

norequirement

norequirement

precluded

notrequired

notrequired

may berequired

may berequired

required

Failure Objectives

ref.: H.E. Roland, B. Moriarty: “System safety engineering and management”, 2nd ed., Wiley & Sons, ‘90, 367 pp., ISBN 0-471-61816-0

- hazard: potential/existing unplanned conditionthat can result in death, injury, illness, damage, loss -


62

“Don’t worry! Nothing can go wrong ....

go wrong..... go wrong....”

Hal, 2001: A Space Odyssey


63

Electro-Magnetic Interference (EMI) - sources

ref.: Clarke, C.A., Larsen, W.A.: “Aircraft Electromagnetic Compatibility”, DOT/FAA/CT-86/40, June 1987ref.: Shooman, L.M.: “A study of occurrence rates of EMI to aircraft with a focus on HIRF”, Proc. DASC-93, pp. 191-194ref.: RTCA Document DO-233 “Portable Electronic Devices Carried On Board Aircraft, Aug. ‘96Graphics adapted from: J.A. Schofield: “European standards shine spotlight on EMI”, Design News, 9-25-1995, pp. 58-60

CONDUCTED EMISSIONS

RADIATEDEMISSIONS

POWER DISTURBANCE

HUMAN ELECTRO- STATIC DISCHARGE

LIGHTNING

PERSONALELECTRONICDEVICES

RADIOFREQUENCY

Aircraft radiosAM/FM radioTV stationsGround radar

cell phoneslaptop PCsCD playersgames

Aircraft power 400 Hz E/MBus switchingInductive load switching

Switching regulatorsComputer clock & dataAnalog signal coupling

ELECTRONICUNIT & WIRING

- average EMI incident occurrence rate ≈ 5x10-3 per flight -


64

EMC: Electro-Magnetic Compatibility

• increased EMI-susceptibility of electronic devices:integration: higher chip density; (deep) sub-micron feature sizesreduced operating voltageslower levels of energy cause upsets

• increased reliance on digital computers (for flight-critical functions) that contain EMI-susceptible devices

• higher clock speeds:reduced susceptibility: PCB tracks become transmission linesbut absolute bandwidth for decent signal shapes goes up (≈10xfc)though bandwidth pushed into range with fewer x-mitters (civil)

• continued proliferation of EM transmitters (incl. PEDs), and increase in EM power

• reduced inherent Faraday-cage protection: increasingamounts of non-metallic airframe sections

ref.: C.A. Clarke, W.E. Larsen: “Aircraft Electromagnetic Compatibility”, Feb. ‘89, 155 pp., DOT/FAA/CT-88/10; same as Chapt. 11 of Dig. Systems Validation Handbook Vol. IIref.:G.L. Fuller: “Understanding HIRF - High Intensity Radiated Fields”, Avionics Comm. Publ., Leesburg/VA, ‘95, 123 pp., ISBN 1-885544-05-7ref.: M.L. Shooman: “A study of occurrence rates of EMI to aircraft with a focus on HIRF”, Proc. 12th DASC, Seattle/WA, Oct. ‘93, pp. 191-194


65

Requirements Taxonomy

Requirements• Mission• Safety• Reliability• Dispatchability

• Maintenance• Cost• Certificability• etc.

• Availability• Functionality• Performance• Operational

• Fault masking• Fault detection• Fault isolation• Fault recovery• etc.

Req's for Fault Avoidance(incl. Containment)

and Robustness

Req's for Fault Tolerance

Req's for Redundancy

Req's for Integrity Checks

Req's for Redundancy Management


66

Modularity issues

• modularization decreases the size of the Line Removable Item from LRU “box” to LRM “module”

• flexibility: add or remove functions and hardware• flexibility: change architecture (configure & reconfigure)• permits management of obsolescence: piece-meal update

on modular basis, as technology & economics justify• reconfigurability, expansion to meet future needs by

adding modules• facilitates fault tolerance (N+1 redundancy)

- module = building block -


67

Standardization issues• “generic”, can be used across variety of functions• economies of scale (production volume, recurring cost)• fewer unique designs and parts, re-use• fewer part numbers:

– smaller number of spares:

– spares acquisition (may be higher) & holding cost– logistics, supportability– documentation, configuration management– training, test equipment

• “overkill” penalty for being “universal” (must support highest system req’s → higher design assurance level)

PL = exp(-N).Σk i t1/k N

m!m

NS

m=0

- standardization ~ commonality -


68

Typical stand-alone LRU

Power supply

Processor core

Memory

Common I/O *

BIT hardware

OperatingSystem

BIT and Maint.functions

I/O processingand monitoring

HardwareResources

SoftwareResources

ApplicationChassis

Unique BIT* with EMI protection

Unique I/O*

Common

Unique

ref.: M.J. Morgan: “Integrated Modular Avionics for Next-Generation Commercial Aircraft”, IEEE AES Systems Magazine, Aug. ‘91, pp. 9-12ref.: D. Hart: “Integrated Modular Avionics - Part I - V”, Avionics, May-Nov. 1991


69

Integration of multiple LRUs

Uniquefunctions

LRU-1

LRU-2

LRU-3

HardwareResources

Software

Standardand

commonfunctions

Standardand

commonfunctions

Uniquefunctions

INTEGRATION

Power Supply

Processor CoreMemory

Shared I/O *

BIT hardware

OperatingSystem


I/O processing& monitoring

HardwareResources

SoftwareResources

Application-1Chassis

Unique BITApplication-2Unique BIT

Application-3

Unique BIT

Unique I/O * Unique I/O *

Unique I/O *


70

Integration of multiple LRUs

Uniquefunctions

LRU-1

LRU-2

LRU-3

HardwareResources

Software

Standardand

commonfunctions

Standardand

commonfunctions

Uniquefunctions

INTEGRATION

Power Supply

Processor CoreMemory

Shared I/O *

BIT hardware

OperatingSystem


I/O processing& monitoring

HardwareResources

SoftwareResources

Application-1Chassis

Unique BITApplication-2Unique BIT

Application-3

Unique BIT

Unique I/O * Unique I/O *

Unique I/O *

standardizevia end-to-end digitalization

from sensors to actuators


71

Integration & Modularization

• LRUs interact → interconnects

• Integration of LRUs → fewer interconnects:connectors (failure prone and very expensive if high pin-count)

wiring (weight)

communication h/w at both endscommunication s/w at both ends


72


• LRU integration reduces overlap/duplication of h/w and s/w functions:

processor coreI/O (un)formattinginput signal monitoring & selectionparameter derivationhardware monitoringEMI/Lightning protectionpower supplyfaul reporting, maintenance, BIT


73

Effect of integrating additional functions - exercise

IMA enclosure + 1st application

Federated Integrated

Each additional application


CPUI/O

PowerBus

Chass.Total

15%20%10%30%25%

100%

O/SI/O

Maint.BIT

Appl.Total

5%20%10%20%45%

100%

Rel

. har

dwar

e co

stR

el. s

oftw

are

com

plex

ity

-- - ≈ + ++

-- - ≈ + ++

CPUI/O

PowerBus

Chass.Total

15%20%10%30%25%

100%

O/SI/O

Maint.BIT

Appl.Total

5%20%10%20%45%

100%

Rel

. har

dwar

e co

stR

el. s

oftw

are

com

plex

ity

-- - ≈ + ++

-- - ≈ + ++


74

Effect of integrating additional functions - (gu)es(s)timates

O/SI/O

Maint.BIT

Appl.Total

5%20%10%20%45%

100%

7%20%13%25%45%

110%

+50%

same

+30%

same

same

Rel

. har

dwar

e co

stCPUI/O

PowerBus

Chass.Total

15%20%10%30%25%

100%

25%20%20%60%30%

155%

+2/3

same

double

double

+20%

Rel

. sof

twar

e co

mpl

exity



O/SI/O

Maint.BIT

Appl.Total

5%20%10%20%45%

100%

10%5%

45%

60%

half

half

same

-1/4

half

-80%

15%20%10%30%25%

100%

15%5%

5%

25%

CPUI/O

PowerBus

Chass.Total R

el. h

ardw

are

cost

Rel

. sof

twar

e co

mpl

exity



source: BCAG (adapted)


75

Effect of integrating additional functions - (gu)es(s)timates

Rel

. har

dwar

e co

stR

el. s

oftw

are

com

plex

ity

100%

25%

100%

60%

100%

155%





100%110%


Rel

. har

dwar

e co

stR

el. s

oftw

are

com

plex

ityassumes integration of relatedfunctions of equal size & complexity; 25% error margin


- the more you integrate, the “better” -source: BCAG (adapted)


76

assumes integration of related functions with equal size/complexity

Advantages of integrating additional functions

- not effective if only integrating 2 or 3 functions -

Number of system functions →1 2 4 6 8 10

Federated

Integrated


Federated

Integrated

25% error bar

1

2

4

6

8

10

Nor

mal

ized

har

dwar

e co

st →

25% error bar

1

2

4

6

8

10

Nor

mal

ized

softw

ar e

size

→

source: BCAG (adapted)


77

assumes integration of related functions with equal size/complexity

Well……..

- ??????????? -


Integrated

Federated

Integrated

1

2

4

6

8

10

Nor

mal

ized

har

dwar

e co

st →


1

2

4

6

8

10

Nor

mal

ized

softw

ar e

size

→

⌠⌡ Cost of cert., partitioning,config mgt


78


• Modularization reduces duplication of product development effort:

specificationdesignintegration and testqualificationV&V, certificationpart numberstime-to-marketprogram risk$$$


79


• Other factors:Natural tendency: trend towards more interaction & coordination between systems (flight & thrust control, safety, com/nav, etc.)

sub-optimal use of (now) distributed data/knowledgeNFF/CND/RETOK, MTBUR/MTBF typically at 50%FANS (com/nav/surveillance)


80

A historical note

“Modular electronics” dates back to several German military radios of the late 1930s!

• modules• chassis with “backplane”• standardization of parts• BIT

- reasons: technical, logistical, maintenance,and manufacturing-ref.: H.-J. Ellissen: “Funk- u. Bordsprechanlagen in Pantzerfahrzeugen” Die deutschen Funknachrichtenanlagen bis 1945, Band 3, Verlag Molitor, 1991, ISBN 3-928388-01-0 ref.: D. Rollema:: “German WW II Communications Receivers - Technical Perfection from a Nearby Past”, Part 1-3, CQ, Aug/Oct 1980, May 1981ref.: A. O. Bauer: “Receiver and transmitter development in Germany 1920-1945”, presented at IEE Int’l Conf. on 100 Years of Radio, London, Sept. 1995


81

German “WW II” radios

• Modules:die-cast Alu-Mg alloy module* for each stagecompletely enclosed & shielded, with internally shielded compartmentsgenerously applied decoupling (fault avoidance)

mechanically & electrically very stableeasily installed/removed w. 90° lock-screws (maint.)

simple (manufacturability: strategically distributed, no high skills)

* from mid-1943 on, only Goering’s Luftwaffe got Alu; Army/Navy got Zn alloy

ref.: Telefunken GmbH: “Luftboden-Empf-Programm 2-7500 m für die Bodenausrüstung der deutschen Luftwaffe”, Berlin, May 1941


82


• Chassis and “Backplane”:modules plug into chassismotherboard / backplane module (E52 “Köln” receiver, 1943)3-D arrangementassy slides into sturdy (!) cabinet


83


• Receiver standardization:40 kHz - 150 MHz covered with 4 radios with identical form, fit, operation

• Parts standardization:1 or 2 standard types of tubes per radio

– Lorenz Lo 6 K 39a: 6x RV12P2000– Telefunken Kw E a: 11x RV2P800– FuSprech. f.: 6x RV12P2000 + 1x RL12P10 (RX),

and 1x RV12P2000 + 2x RL12P10 (TX)– tricky circuitry

- spares logistics, test equipment -


84


• BIT:switchable meter for Vanode & Ianode of each radio stage, and for filament voltagenoise generator to measure RX sensitivity pass/fail, minimum servicability markings

- simple line maintenance-


85

Modular Electronics: Not a New Concept!

Modularconstruction

Lorenz E 10 aK(11x RV12P2000)

photo: courtesy Foundation Centre for German Communication & Related Technology 1920-1945, Amsterdam/NL, A.O. Bauer


86


- “backplane module” Bu 3 from Telefunken E 52 “Köln” -(1939-1945)



87


- “backplane module” Bu 3 from Telefunken E 52 “Köln” -(1939-1945)



88


TelefunkenE 52a

“Köln”

ref.: Telefunken GmbH: “Luftboden-Empf-Programm 2-7500 m für die Bodenausrüstung der deutschen Luftwaffe”, Berlin, May 1941


89

IMA - Integrated Modular Avionics

LRUs

LRMs

- the basic idea -


90

IMA - Integrated Modular Avionics

• Level-1: LRUs re-packaged into LRMs

• Level-2: databus integration and partitioning

• Level-3: all digital, global databuses

• Level-4: functional integration at LRM level

• Level-5: dynamic task allocation & reconfig.

- a range of concepts and configurations -(no hard distinction between levels)

ref.: R.J. Stafford: “IMA cost and design issues”, Proc. 6th ERA Avionics Conf., London/UK, Dec. ‘92, pp. 1.4.1-1.4.10


91

IMA Level-1

• LRUs re-packaged as LRMs in cabinet(s):several types of standardized I/O modules (mix of analog/discrete/digital)

external input data-concentratorsstandard computational moduleintegration only of power-supplies (shared)

no functional integration (LRUs mapped 1:1)

no new interactions (certification!)

ARINC-429 links between LRMs retainedARINC-429 links between “cabinets”


92

IMA Level-2 & -3

• Level-2: databus integration and partitioningnon-A429 inter-LRM communicationbroadcast databusseparation of application s/w and OSstandard OS (facilitates aps. s/w modularity)

• Level-3: all digital, global databusesfully digital I/O at cabinet level, possibly with external data concentratorsdata gateway modules to global bus networksremote electronics: digitization close(r) to sensors & actuators


93

IMA Level-4 & -5

• Level-4: functional integration at LRM levelmulti-function computational LRMsmore functions integrated (toward supra-function IMA)

strict partitioningstandard interfaces (towards F3I)

improved BITfault tolerance

• Level-5: dynamic task allocation & reconfig.flexibilitymore efficient h/w resource utilizationcertification


94

IMA cost indicators and prediction

• LCC cost drivers (RC & NRC):design & development cost & riskhardware, mechanical, data/signal interconnects, power interconnectsuse of standard components, OS, complexitycertification aspectsre-useability (future savings)weight/size/power/coolinginstallationmaintenance, support (NFF, spares, rel., org.)etc.

- IMA does not have an intuitively obvious bottom line advantage -


95

Major Areas of Systems Integration

Utility SystemsVMS

Communication& Navigation

Flight & Propulsion Control

“Safety” SystemsPax Services* *Entertainment,

Info, Telecom,Sales, Banking, etc.

Flying: Aviate, Navigate, Communicate(and have some fun ...)


96

Functional Integration

AT FADEC

FBW Prim. FC SERVOSAP/AL

FD

SERVOS

FMSATC/ATM

FBW Sec. FC

- inner & outer control loops -


97


AT FADEC


FD

SERVOS

FMSATC/ATM

FBW Sec. FC

- center of integration depends on avionics mfr’s forte -


98

AT FADEC


FD

SERVOS

FMSATC/ATM

FBW Sec. FC




99


AT FADEC


FD

SERVOS

FMSATC/ATM

FBW Sec. FC



100

Integration of CatIII Autoflight Computers

Test Computer

Pitch Trim

Yaw Damper

Logic Computer

LongitudinalComputer

LateralComputer

N1 Limit

Auto Throttle

FCC

FAC

FMC

TCC

FMGC

FAC

FMGEC

x1

x1

x2

x2

x2

x2

x2

x2

x1

x2

x2

x2

x2

x2 x2

14 7 4 2

A300

A310A300-600

A320

A330/340

Airbus AFCS example:1 analog and 3 digital generations

ref.: ”Is new technology a friend or foe?”, editorial in Aerospace World, April 1992, pp. 33-35


101

Integrated Flight & Thrust Control Systems

Examples: • Modular Flight Control & Guidance Computer

(EFCS by BGT/Germany)

• Propulsion Controlled Aircraft (PCA)(MDC/NASA, Boeing)

• Towards multi-axis thrust vectoring (civil)(NASA-LaRC, Calcor Aero Systems, Aeronautical Concept of Exhaust Ltd.)

ref.: E.T. Raymond, C.C. Chenoweth: “Aircraft flight control actuation system design”, SAE, ‘93, 270 pp., ISBN 1-56091-376-2ref.: Hughes, D., Dornheim, M.A.: “United DC-10 Crashes in Sioux City, Iowa,” Aviation Week & Space Technology, July 24, 1989, pp. 96-97ref.: Dornheim, M.A.: "Throttles land "disabled" jet," Aviation Week & Space Technology, September 4, 1995, pp. 26-27ref.: Devlin, B.T., Girts, R.D.: "MD-11 Automatic Flight System," Proc. 11th DASC, Oct. 1992, pp. 174-177 & IEEE AES Systems Magazine, March 1993, pp. 53-56ref.: Kolano, E.: “Fly by fire”, Flight International, 20 Dec. ‘95, pp. 26-29ref.: Norris, G.: “Boeing may use propulsion control on 747-500/600X”, Flight Int’l, 2-8 Oct. 1996, p. 4ref.: “Engine nozzle design - a variable feast?”, editorial in Aircraft Technology Engineering & Maintenance, Oct./Nov. 1995, pp. 10-11


102

Modular Flight Control & Guidance Computer

FMGCFMC FGC

ELAC

FCDC

SEC

FAC

SFCC

FCGCFMC

Flight Mgt

A320 "baseline"

"50-100 Pax", high-end BizAv

FC/FG

integration

All Airbus LRUs: dual internal, dissimilar s/wA330/340: 3x FCPC, 2x FCSP, replacing ELACs & SECs

ref.: D. Brière, P. Traverse: “Airbus A320/330/340 electrical flight controls - a family of fault tolerant systems”, Proc. 23rd FTCS, Toulouse/F, June ‘93, pp. 616-623


103


FMGCFMC

AutoflightΣ 52 MCU

Flight Ctrl:Σ 50 MCU

FGC

ELAC

FCDC

SEC

FAC

SFCC

FCGCFMC

Flight Mgt:Σ 12 MCU

FC/FG total:

= 24 lanes, incl. 20 PSUs= 50 MCU volume

FC/FG total:

= 12 LRMs, 4 PSMs= 18 MCU volume

2 cabinets

11 LRUs modular

integration


104


BGT BodenseewerkGerätetechnik GmbH

• primary flight control (FBW), incl. backup• secondary flight control (FBW)• high-lift flight control (slat/flap FBW)• flight envelope protection• auto pilot w. CatIIIb auto-land• flight director• auto throttle

Integrated flight control & guidance functions:

ref.: D.T. McRuer, D.E. Johnson: “Flight control systems: properties and problems - Vol. 1 & 2”, Feb. ‘75, 165 pp. & 145 pp., NASA CR-2500/2501ref.: D. McRuer, I. Ashkenas, D. Graham: “Aircraft dynamics and automatic control”, Princeton Univ. Press, ‘73, 784 pp., ISBN 0-691-08083-6ref.: J. Roskam: “Airplane flight dynamic and automatic flight controls - Part 1 & 2”, Roskam A&E Corp., 1388 pp., LoC Card no. 78-31382ref.: R.J. Bleeg: “Commercial jet transport fly-by-wire architecture consideration”, Proc. 8th DASC, San Jose/CA, Oct. ‘88, pp. 399-406


105


• demonstrator program in cooperation with DASA• simulator and A340-rig tests: ongoing since 1Q91• flight test scheduled for 1Q98 on VFW614 test bed• certification: primary flight control only

(incl. dynamic task-reconfig concept)

• development & test program: full-function FCGC

Current FCGC-program development status:



106

VFW-614

Returned to service 1Q96 as test-bed for the BGT/DASA EFCS Programphoto: courtesy


107


Goals:

•low cost •no reduction in safety & performance vs.

conventional architectures•safely dispatchable with any single module failed•safely dispatchable with any two modules failed

(reduced performance)

•significantly reduced weight/size/power



108


• significant reduction of hardware: :integration of functions, enabled by computing performance (mixed criticality levels!) → reduced amount of interfacing (computer ↔ computer, lane ↔ lane)

• more efficient use of retained hardware:more paths through system: move away from rigid lane structureresource sharing, multi-use I/O hardwareno single-thread operation → reduced output h/w redundancygraceful degradation (shedding of lower criticality functions (FG) to retain higher (FC))

• lower cost hardware: no “ARINC-65X” backplane databus, connectors, module lever

• strict separation of I/O from computational functions• dissimilarity

Concept:



109


System architecture: 2 modular FCGCs•per FCGC:

2 dual Computing Modules (CPMs)2 dual I/O Modules (IOM type “A”):

– one mainly for PFC, the other mainly for FG

2 dual I/O Modules (IOM type “B”):– one mainly for Hi-Lift and Maintenance– the other mainly for PFC/SFC, and – can act as “NGU” minimum-PFC backup

2 or 3 Power Supply Modules (dep. on dispatch req’s)

A429 inter-FCGC, 10 Mbs serial inter-moduleA650 cabinet form factor, shorter LRMs

BGT BodenseewerkGerätetechnik GmbH - all modules are dual → fail-passive -


110


2x CPM(identical)

4x IOM

FCGC (x2)

X-puter +PowerPC

PowerPC +GP µP

A BA B

FC FG(FC)

- FCGC internal architecture -BGT Bodenseewerk

Gerätetechnik GmbH ref.: R. Reichel: “Modular flight control and guidance computer”,Proc. 6th ERA Avionics Conf., London/UK, Dec. ‘92, 9 pp.


111

FCGC redundancy management - examples

A BA B

FC FG(FC)

A BA B

FC FG(FC)

A BA B

FG(FC)

A BA B

FC FG(FC)

Fault Free


- elevator control reconfiguration in response to module failures -

- CPM failure -


112


FG(FC)

A

FC FG(FC)

FG(FC)

AA BA B BA B A BA B BA B

FC FG(FC)



- CPM + IOM failure -


113


A BA B

FG(FC)

A BA B

FC FG(FC)

A BA B

FG(FC)

A BA B

FG(FC)



- CPM + IOM + CPM failure -

lliedSignalA E R O S P A C E


• Introduction• Why change avionics?• Integration• Modularization

AlliedSignal programsAlliedSignal programs• Future .....


AlliedSignal Programs

•• Integrated Cockpit AvionicsIntegrated Cockpit Avionics• Integrated Hazard Avoidance System• Integrated Utilities System


Integrated Cockpit Avionics

• ARIA joint venture of AlliedSignal CAS with Russian partner NIIAO

ARIA = American-Russian Integrated Avionics NIIAO = “Scientific Research Institute of Aircraft Equipment”gov’t owned, frmr. part of “Flight Research Institute”located in Zhukovsky, Aviation City near MoscowARIA JV since 3Q92ARIA JV office in Moscow since 4Q93

• first program: Beriev BE-200amphibious multi-role jet aircraftprimary role: fire fighting (12 m3)


Beriev BE-200: Russian multi-role amphib


CIS Aviation Industry- business environment as seen by AlliedSignal -

Business Partner

Design Bureaux

Production Plants

Airlines

Private Operators

Issues NegativesPositives

• 4 major OEMs• several active programs• some CIS gov’t funding

• 16 major facilities• mixed military/civil

production• privatization process

on-going

• Aeroflot remains national carrier

• over 200 new airlines

• critical need for biz-jet operations

• no domestic producer

• real industry• good design capability

• skilled labor• access to raw material• know the end- user

• high demand for capacity• over 200 new airlines

• growing market• OEMs addressing the

neeed

• lack of market foreacst• excess design capacity• physical & managerial

separation from production• lack of customer support

network

• excess capacity in workforce and facilities

• updated production equipment required

• large fleet under-utilized• in need of updating• lack of support facilities• customer image problems

• biz-jet infrastructure not in place

• aging fleet of YAK-40s

ref.: K.R. Dilks: “Modernization of the Russian Air Traffic Control/ Air Traffic Management System”, Journal of Air Traffic Control, Jan/Mar ‘94, pp. 8-15ref.: V.G. Afanasiev: “The business opportunities in Russia: the new Aeroflot - Russian international airlines”, presented at 2nd Annual Aerospace-Aviation

Executive Symp., Arlington/VA, Nov. ‘94, 5 pp.


CIS Aviation Industry

Novosibirsk• AN mfg

Moscow• AS/ARIA• YAK• TU• IL• NIIAO

Saratov• YAK mfg

Kazan• TU mfg

Kiev• AN

Taganrog• BE

Irkutsk• BE mfg• Beta Air

design bureau

airframe production facility

GMT + 3 h

Note: map shows CIS + Ukraine


Time from 1st Flight to Certification

B-737-200 8B-737-300 9B-737-400 7B-737-500 10B-747 10B-747-400 9B-757 10B-767 10B-777 10DC-10 11MD-80 10MD-11 10

Average 10 mo.

A-300 17A-310 11A-320 12A-330 17A-340 11

Average 14 mo.

BAe-41 14BAe-125 12BAe-146 20

Average 15 mo.

Falcon-50 27Falcon-900 18

Average 22 mo.

IL-86 48IL-96 51IL-114 57-69TU-154 40TU-204 60Yak-42 66

Average 55 mo.

USA Europe CIS


ARIA-200 system architecture

I/O2 OMI/O

1FW

XPDR

to I/O-3

VSPS PSDC PS PSDC

Cabinet nr. 1 Cabinet nr. 2

VORVHF ADF

DME

RA

opt.

TACANopt.

HF

ILS MLS

TCASopt.

fromRMU-2

cp

cp

(portable)

to Flt Ctl

A/C Systemsto AudioSystem

from A/C Systems

AP+

AT

AP+

ATFWI/O

3I/O4

from

to/fromEngine Ctl

to IOM-1/2/3/4to FSM-1/2

VOR VHFADF

DMERAXPDR

opt.ACARSopt.

HFILS

fromRMU-1

cp

cp

opt.DATALOADER

cp

to I/O-2

toDisplays

CNS suite nr. 1 CNS suite nr. 2

Alt+

IAS

ADI

RMI

ADC-1 AHRS-1

cp

Stdby Instr.

RMU-2RMU-1

WX-RDR NDPFD EICASEICAS ND PFD

source sel. EICAS cp source sel.EFIS cp FC cp

brightness

IOM-2/4to

IOM-1/3to

6"x8"AM-LCD's

FMS/GPS-1 FMS/GPS-2

to CNS-2 to CNS-1

ADC-2AHRS-2

SensorsSensors

Flight & Radio Management

to CNS-1 to CNS-2

DisplaySystem

AlliedSignalOTS

AlliedSignalh/w

AlliedSignalh/w + core s/w

ref.: F. Dörenberg, L. LaForge: “An Overview of AlliedSignal’s Avionics Development in the CIS“, IEEE AES Systems Magazine, Feb. ‘95, pp. 8-12


ARIA-200 Integrated Modular Cabinets

I /O OMI/OFW

DC

PS PSDC

PS PSVS

Cabinet-1

Cabinet-2

FC

FW FCI/O I/O

PS = Power SupplyI/O = I/O ModuleDC = EICAS Data Concentrator ModuleVS = Voice Synthesizer Module

FC = Computer Module for Auto-Flight (AP/AT)OM = Computer Module for On-Board MaintenanceFW = Computer Module for Flight Warning


ARIA-200 avionics cabinet

•Mechanical structure and modules conform to ARINC 650volume ≈ 2/3 of AIMSweight ≈ 60% of AIMS

•Uses 3 standardized modules:Power Supply ModuleComputer Module (CM)Input/Output Module (IOM)

•Module-module communication: high speed A429 backplane

• Power consumption: < 400W total (115 Vac & 27 Vdc)

•Cooled by integral fans


ARIA-200 avionics cabinet

•Maximized design re-use for reduced development riskprocessor designI/O designBIT circuitryAda real-time execAlliedSignal graphics development tool suitecommon manufacturing processfewer part-numbers

• Identical computer module for multiple functions:Flight WarningFlight Control: AP & ATOn-Board Maintenance

• I/O consolidationsimplifies DU and FMS/MCDU


One Processor Board DesignProcessor Board for I/O-Module

Processor Board for Computer-Module

minus DPRAMsminus I/F-board connectors

minus database flash memory


Two Interface Board Designs

CM-Interface Board discrete outanalog in

A429 I/O3x(4+1)

discrete in

DC/DCconversion

x-channel comparator logic(flt ctl module only)


Two Interface Board Designs

IOM-Interface Board DC/DCconversion

A429 I/O8x(4+1)

analog

in & out


Computer Module (CM) “sandwich”

CM-Processor Board

CM-Interface Board


ARIA-200 Computer Module - technical data -

• module = computer board + interface board• SMT (exc. connectors & hold-up capacitors)• processor: 486 DX 33 @ 25 MHz• inputs/outputs:ARINC429 in & out:16+5discrete in & out: 48+12RS-232: 1 (shop maint.)• memory:512 kBRAM256 KB Boot RAMFlash (program mem & database)32kB NVM• software loadable via ARINC-615 • 1 AMU* width• application:auto-flight (x2)flight warning (x2)on-board maintenance (x1)

* 1 AMU-width = 1 MCU-width = 1/8 ATR-width = 1.1 inch


Input/Output Module (IOM) “sandwiches”

IOM-Processor Board

IOM-Interface Board

IOM-Processor Board

IOM-Interface Board


ARIA-200 I/O Module - technical data -

• module = 2x {computer board + interface board}• SMT (exc. connectors & hold-up capacitors)• processors: 486 DX 33 @ 25 MHz• inputs/outputs:ARINC429 in & out: 2x (36+9)discrete in & out: 2x (22+8)RS-232: 1+1 (shop maint.)• memory:RAMBootFlash (program mem & database)NVM• software loadable via ARINC-615 • 3 AMU width• application:to DUs, FDR, FCMs, FWMs, OMM, IOMsfrom a/c systems, CNS, EIS control panels


Russian Trivia

• Russians are generally well educated, many speak English, they know and love their culture

• 80% of Muscovites have a weekend datcha near Moscow• Nothing ever gets finished in Russia• From the “provinces” it can take 3 hours to get a phone call

to Moscow• Russians love dogs• Vodka plays a significant role in the Russian way of life• Life expectancy for a Russian male is 63 years• Somebody in Moscow collects manhole covers• The women are not short and stout in black head scarves,

they are surprisingly attractive


1


• Integrated Cockpit Avionics•• Integrated Hazard Avoidance SystemIntegrated Hazard Avoidance System• Integrated Utilities System


2

Exposure percentage based on a flight duration of 1.5 hours

Accidents* vs. flight phase* all accidents (hull loss + fatal)

1% 1% 14% 57% 11% 12% 3% 1%

NavFix

OuterMarker

Exposure, percentage of flight time

Flaps retracted

Load,taxi,

unload

Takeoff Initialclimb

Climb Cruise Descent Initialapproach

Finalapproach

Landing

4.8% 12.8% 7.4% 6.4% 5.7% 6.2% 6.6% 19.7% 30.3%

Excludes: • Sabotage • Military action • Turbulence injury • Evacuation injury

Percentage of accidents 50%

- worldwide commercial jet fleet, all acidents 1965-1994 -

ref.: Boeing Commercial Airplane Group “Statistical Summary of Commericial Jet Aircraft Accidents - Worldwide operations 1959-


3

Hazards external to aircraft

• Terrain

• In-Air

• On-Ground

• On-Aircraft


4


• Terrain:Controlled Flight Into Terrain (CFIT):

• worldwide, a leading cause of fatal accidents involving commercial air transports

• usually during approach phase of flight (3% departure), usually while decending at normal flight-path angle

• 25% VFR (esp. night time)

• 65% IFR (esp. non-precision with step-down fixes)

currently lacking: flight deck info in intuitive format

ref.: D. Carbaugh, S. Cooper: “Avoiding Controlled Flight Into Terrain”, Boeing Airliner, April-June ‘96, pp. 1-11ref.: D. Hughes: “CFIT task force to develop simulator training aid”, AV&ST, July 10, ‘95, pp. 22, 35, 38


5


• In-Air:atmospheric:

• turbulence (inc. Clear Air Turbulence, CAT)

• windshear/micro-bursts• precipitation (convective cells, tornadoes, hail, dry hail)

• icing conditions (super-cooled liquid water)

• wake vortex

environmental: • volcanic ash

traffic:• other aircraft (all classes)• birds

ref.: J. Townsend: “Low-altitude wind shear, and its hazard to aviation”, Nat’l Academy, Washington/DC, 1983ref.: L.S. Buurma: “Long-range surveillance radars as indicators of bird numbers aloft”, Israeli J. of Zoology, Vol. 41, ‘95, pp. 21-236


6

Hazards to aircraft (cont’d)

• On-Ground:runway incursionsother aircraftvehiclesanimalsother obstacles

• On-Aircraft:fire, smokewing ice


7

Jet aircraft in service & annual departures

12,000

10,000

8,000

6,000

4,0002,000

0

Aircraft

66 68 70 72 74 76 78 80 82 84 86 88 90 92 94

11,852

14121086420

Annualdepartures(Millions)

14.6

66 68 70 72 74 76 78 80 82 84 86 88 90 92 94

20

10

0

Accidentsper milliondepartures(annual rate)

Accident rates of US scheduled airlines (Part 125):1 per 333 M miles (95); 1 per 200 M miles (94)1 per 1.75 M departures (95); 1per 1.2M (94)

Accident rates of US scheduled airlines (Part 121):1 per 2,500 M miles (‘95); 1 per 1,250 M miles (94)1 per 4.2 M departures (95); 1 per 2M (94)

- worldwide operations 1965-1994 -

ref.: Boeing Commercial Airplane Group “Statistical Summary of Commericial Jet Aircraft Accidents - Worldwide operations 1959-


8

Projection

• stable accident rates + more aircraft + more traffic → more accidents

• extrapolation of past ten years’ worldwide accident rates and expected fleet growth:

one jet transport hull loss every week* by the year 2010 unless accident rates (=safety) improve.

• accident rates will improve, such that fatality rate is stable**: safety is the relative freedom frombeing subject to uncontrolled hazards: potentialor existing unplanned conditions/events that can result in death, injury, illness, damage to, or loss of equipment or property, or damage to the environment.safety is state in which the risk (real or perceived) < upper limit of acceptable risklimit is driven by whoever has to pay (in whatever form) for the consequences:equipment owners/operators, crew & pax, underwriters, society, etc.risk must also be seen vis-à-vis the benefit derived from the risky function or activity (here: air transport aviation).

* 1 per 4 - 7 days

** number of fatalities p.a. has been stable since 1947 (Bateman’s Law)

- air traffic is not getting inherently more dangerous -

ref.: C.A. Shifrin: ‘Aviation safety takes center stage worldwide”, AW&ST, 4 Nov 1996, pp. 46-48ref.: “The dollars and sense of risk management and airline safety”, Flight Safety Digest, Vol. 13, No. 12, Dec. ‘94, pp. 1-6


9

AlliedSignal flight-safety products: core technology • Traffic Collision Avoidance System

TCAS II + Mode-S Transponder (active: up to 40 nm; planned: passive up to 100 nm)

• Weather Radar (incl. Doppler for turbulence)

• Windshear detectionpredictive/forward looking (via WX radar remote sensing; upto 5 nm, > 10 sec)

reactive (in GPWS, based on airmass accels + hor./vert. wind changes)

• Terrain detection: Ground Proximity Warning SystemRadAlt-based GPWSEnhanced GPWS (EGPWS= GPWS + terrain d-base)

• Flight recorders(SS)CVR, (SS)FDR

• Smoke detectionref.: D. Esler: “Trend monitoring comes of age”, Business & Commercial Aviation, July ‘95, pp. 70-75ref.: P. Rickey: “VCRs and FDRs”, Avionics Magazine, March ‘96, pp. 34-38


10

Terrain Avoidance

GPWS Functionality• Modes 1- 4• Mode 5 (Glide Slope)• Mode 6 (Altitude Callouts and Bank Angle)

plus Terrain Clearance Floor• around airports, aircraft in landing config• terrain database + position info

plus Forward Looking Terrain Avoidance• terrain database + position info

plus Situational Awareness/ Terrain Display• terrain database + position info• radar returns (Map Mode)


11

Worldwide Fatal Accidents 1988-1995

5

Other

20

15

10

5

0

1617

1 1

7

32

4

Excludes• Sabotage• Military action

Loss ofcontrolin flight

CFIT Fire Midaircollision

Landing Ice/snow

Windshear Runwayincursion

Fuelexhaustion

3

Number of accidents (left-hand scale)Number of fatalities (right-hand scale)

1200

900

600

300

0

- CFIT accounts for majority of fatal commercial airplane accidents -ref.: D. Carbaugh, S. Cooper: “Avoiding Controlled Flight Into Terrain”, Boeing Airliner Magazine, April-June 1996, pp. 1-11ref.: ICAO Journal, March 1997, p. 12


12

Worldwide CFIT Accidents 1945-1995commercial airplanes only

35

30

25

20

15

10

5

01945 50 55 60 65 70 75 80 85 90

Accid

ents

Rest ofWorld*

ICAOGPWS1979

USAGPWS1974

Year

USAPart 121/125

*no data prior to '64

- introduction of GPWS has reduced CFIT risk -ref.: D. Carbaugh, S. Cooper: “Avoiding Controlled Flight Into Terrain”, Boeing Airliner Magazine, April-June 1996, pp. 1-11


13

World-wide civil CFIT accidents - turbo engine a/c

16

21 2119

35

28 26

7 63 2

5 47

5

0

5

10

15

20

25

30

35

88 89 90 91 92 93 94 95YEAR ENDING

CFI

T A

CC

IDEN

TS P

ER Y

EAR

Regional Corporate Air Taxi →

Large Commercial Jets↓

1212

1611 Late warning,or improper

pilot response

Not GPWSequipped

GPWS WarningActivated

World-widecommercial jetCFIT accidents

1988-1995


14

EGPWS color coding scheme - simplified

Aircraft Elevation0

+2000’

+1000’

-500’

-1000’

-2000’

(variable)


15

Terrain map on Nav display

displaymode:

WX vs. Terr


16

SURROUNDING TERRAIN

(shades of green,yellow & red)

“CAUTION TERRAIN”

“TERRAIN AHEAD -PULL UP!”

Terrain threat on Nav display

Caution Area(solid yellow)

Warning Area(solid red)


17ref.: freeflight™ (moving map software for laptop PC), FreeFlight Inc, Pasadena, CA

Terrain display - 3-D vs. 2-D


18

World-wide terrain data base• End of “Cold War” helped provide 30 arc second data for ≈ 65%

of the world• Coverage has grown to 85 % of land mass• Includes 90% of world’s airports• Validation by Flight and Simulation• Terrain info: compressed into 20 MB flash memory

World-wide runway data base• Purchased from Jeppesen• All runways ≥ 3500 feet in length• Currently 4,750 airports and 6,408 runways• Runway info: Lat/Long of center, length, bearing, elevation


19

EGPWS Terrain Database (7/30/96, TSO Release)

Pink: 15 arcsec ≈ ¼ nmRed: 30 arcsec

Orange: 60 arcsecYellow: 120 arcsec

Green: 5 arcmin (enroute)Blue: missing data

Brown: Dig. Chart of the World


20

EGPWS Runway Database

- 4815 airports world-wide (runways ≥ 3500 ft) -

-150.00 -100.00 -50.00 0.00 50.00 100.00 150.00

-50.00

0.00

50.00


21

Enhanced GPWS functions

CENTERTINE

POINTS ALONG GROUNDTRACK

PLUS A LEAD ANGLE DURING TURNS

look-ahead distance

centerline: points along groundtrack plus: lead-angle during turns

≤ ¼ nm

f(dx to airport)

∠α = f(dx to airport, speed, turnrate,..)α

\

• Look-ahead alert and warning (60 sec, instead of 10-30 sec)

• Terrain-clearance independent of a/c landing configuration• Situational display of threatening terrain


22

Emerging technologies, incl. AlliedSignal developments

• Detection of:Wing ice (refinement)

Clear Air Turbulence (passive IR radiometry)

Wake vortexVolcanic ash

• Advanced X-band radar:derived from current WX/Windshear Radar

• Runway incursion detection• Terrain detection (Forward Looking GPWS)

• Landing aid (with d-base): runway ID, approach guidance

• Icing conditions (based on Zrefl of supercooled liquid H20)

• Synthetic vision systemIR doppler (improved CatII vision)


23

IHAS: integration of safety avionics

TCAS IITCAS II

terrain databasedisplay interface

a/c position

IHASIHAS

WX/WindshearWX/WindshearRadarRadar

GPWSGPWS EGPWSEGPWS

1996 ..................... 1999 .......

ModeMode--SS

WarningWarning& Caution& Caution

- a logical integration of numerous safety-avionics LRUs -


24

“Safety Avionics” - federated baseline

Master Warn Light

Master Warn Light

Other Aircraft Systems

GPWS

StickShakerL & R

Caution & WarningElectronics

- Right -

ATC TPR / Mode S

ATC TPR / Mode S

Caution & WarningElectronics

- left-

WARNING

CAUTION

WARNING

CAUTION

WX RadarAntenna

GND PROX

OVRD

Top ATCAntennaBottom ATC

Coax Switches

Aural WarnSpeaker

Aural WarnSpeaker

Discrete & AnalogInputs

TCAS/ATC CP

WX Radar CP

GPWS CP

Ant.Ctlr

WaveguideWaveguide

SwRADAR

RADAR

TCAS Processor

A453

AntennasWX/Terr

Displ.

Relay


25

“Safety Avionics”- IHAS baseline

WARNING

CAUTION

A453

WARNING

CAUTION

WX Radar

Antenna

Aural Warn Speaker

Master Warn Light

Aural Warn Speaker

Master Warn Light

Safety CP

Coax

Coax

IHAS - L

part of antennadrive unit

• Antenna Ctlr• R/T switching• RF front-ends

IHAS - R

Other Aircraft Systems

IHAS

IHAS

4 4

Dir. Ant. BottomTop

Omni Ant.

Top Bottom

High SpeedDig. Buses

Stick ShakerL & R

- major reduction in complexity -


26

Advantages of IHAS approach

• Added-value from safety point of view: greater degree of protection through sharing & integrating of informationreduced cockpit confusion through “smart”alerting

• based on total situational awareness• proper prioritization of visual & aural alerts• minimize misinterpretation of (sometimes conflicting

and potentially misleading) multiple alerts• reduction of crew workload during critical moments

optimization of hazards displaycont’d →

ref.: J.A. Donoghue: “Toward integrating safety”, Air Transport World, 11/95, p. 98-99


27

Advantages of IHAS approach (cont’d)

lower weight*: ≈ 50 - 70%**lower volume*: ≈ 50 - 60%**lower power*: ≈ 40 - 70%**lower installation cost (parts & labor)

• reduced wiring• fewer connectors• fewer trays• elimination of some ATC antennas • elimination of radar waveguide

higer system availability (more reliable, redundancy)

lower LCC

*compared to equivalentfederated suite on 777

**depends on config

- all the advantages of IMA (to OEMs & airlines) -

ref.: J.A. Donoghue: “Toward integrating safety”, Air Transport World, 11/95, p. 98-99


28

IHAS design goals

• Open architecture• Support software Level “A” (RTCA/DO-178B)

• Simultaneously support lower software levels• Minimize complexity at “A” level• Provide for incremental system evolution• Hold down cost of changes


29

Reducing the impact of change

$$

$$$$

$$$$$$

• Applicationcode / algorithm changesI/O details (in current channels)execution threads

• K_EXECprocessor time allocationpartition window positioningconnection of channels to partitions

• BIC Tableschannel bandwidth allocationsnode transmit permissions

- change containment to lower cost of system changes -


30

RDR-4BWX/Windshear Radar

E-GPWSEnhanced Gnd Prox

Warning System

TCAS-II

IHAS integrates “safety” sub-systems

CentralProcessingModules

WarningComputer

Mode-STransponder

PowerSupplysModule

I/OModules

RF + DSPModules

spare

spare

IHAS

WX

Radar

TCAS

ATC

Dual

CPM

Dual

CPM

IOM

IOM

Dual

PSM

6


31

Baselines: conventional vs. IHAS

TCAS

Ant. drivedir.ant.

a/c data&

power

Mode-S

omniant.

E-GPWS RadarFlight

WarningComputer

CPMPSM IOM

Backplane Data Bus

Power Bus

a/c power IOMTCAS +Mode-S Radar

a/c data

Ant. drive• OASYS + special modules for

Radar and TCAS/Mode-S processing

• integrated TCAS/Mode-S• IOMs shared by all functions• CPM shared by all functions

• E-GPWS• Fault Warning Computer• general processing for TCAS,

Mode-S, Radar• integration of “safety” information

special I/O&

processing

special I/O&

processing


32

IHAS characteristics

• Interfaces:digital: ARINC-429 and 629 analog: as required for specific aircraftinter-modular backplane bus: modified ARINC-659RF: 2 TCAS/Mode-S antennas (shared aperture, directional) power: multiple 115 Vac and 28 Vdc

• Mechanical:LRM form-factor: ARINC-600connectors: RF and modified ARINC-600

- conceptual -


33

IHAS generic LRMs

• Central Processing Module (CPM):functions:

• I/O and bus control• DSP-function control• system redundancy management

fault-tolerantsoftware loadable on-board

• Digital Signal Processors (DSPs):function: performing all signal processingmultiple DSP LRMs (redundancy)hi-speed serial I/F for unique functions (radar, TCAS)software loadable on-board

cont’d →- conceptual modular allocation -


34

IHAS generic LRMs (cont’d)

• Input/Output Modules (IOMs):functions:

• all external interfaces• display processors• audio output

multiple LRMs (redundancy)fault-tolerant

• Power Supply Module (PSU):functions:

• power input conditioning• power interrupt transparency• dc/dc up-conversion and distribution to all LRMs

multiple power sources (ac & dc)- conceptual modular allocation -


35

Node Software ArchitectureShared Function LibrariesShared functions in “execute-only”memory may be used by any partition

Partition ExecsThread schedulers, driven by event/priority/deadline; executes strictly within a partition created by K-Exec

ref.: A.S. Tanenbaum: “Distributed Operating Systems”, Prentice Hall, 1995, 614 pp., ISBN 0-13-219908-29

- modified “scheduler activation” type exec -

User-Modesoftware

P-Exec 1 P-Exec 1 P-Exec 1P-Exec 2

Lib. 1

Lib. 2

Lib. 3BIT

App 1

App 2

App 3

App 4App 5

Kernel-Modesoftware

Kernel ExecSimple, deterministic, round-robin scheduler and partition management

K-Exec

Processorand I/O

hardwareHost CPU & supporting logic Interrupt system, MMU, I/O

Hardware


36

Node architecture

P1

K-ExecK-ExecK-Exec K-Exec K-Exec

IPU IPU Special IOM Generic IOM Generic IOM

External I/O External I/O External I/O

P2 P3 P4 P5 P3 P6 P7 P8 P9 P10

Special H/W

Bus I/F Bus I/F Bus I/F Bus I/F Bus I/F

Fault-tolerant Backplane Databus


37

Processor selection criteria*

• processing throughputVAX-MIPs, Whet/Drystones, SPEC95, etc.don’t start with top-of-line (you may out-grow it before next gen is available = EOL)

• processor architecture & supportmust have believable roadmap for development of architecture (no AMD29K)life-cycle of avionics >> PCs

• embeddednessdesired: minimum number of external components, i.e., component integrationcounters, timers (incl. watchdog)cacheDRAM refreshfloating point unitmemory management unitserial port UARTJTAG port for debug, BIT, shop test, software load

• operating voltage 5, 3.3, 2.5, 2.2, 1.8, etc. Vdc

*not priotitized,n-exhaustive list

- desired: cheap, low-power embedded µP that does ∞ -loop in 10 msec -


38

Processor selection criteria - cont’d

• power consumption desired: < 0.5 W (no 35 W Pentium® Pro if using 4-10 µPs per cabinet or LRU)

• temperature range

• cache (instruction & data) size and levelL2/L3 may not be desired

• memory managementvirtual addresssing (page based)

• error checking capability (e.g., bus parity)

• exception & interrupt handling at Kernel & Application Exec levelat application level

• availability for integration eventually: processor-die + memory + peripherals + bus I/F into single ASIC

- hold-off actual selection as long as possible -


39

Processor selection criteria - cont’d

• support for multi-processor configurationsynchronizationfault detectionredundancy management

• in-house experience with processor familydesigncompilers, debuggers, emulators, etc.development/maintenance

• portability of existing/legacy softwareincl. device driver & O/S implications

• tools and supporting vendorsrobust compilers (validated) , linkers, debuggers, etc. (so-so for Intel)real-time O/S

• costrecurring cost of complete processor coredevelopment/maintenance

• availability of evaluation boards & simulators

ref.: M. Slater: “The microprocessor today”, IEEE Micro, Dec. 1996, pp. 32-44ref.: D. Hildebrand: “Memory protection in embedded systems”, Embedded Systems Programming, Dec. 1996, pp. 72-76


40

OASYS Backplane Databus

• derived from ARINC-659 standard:semi-duplex, serial, multi-drop, broadcasttable driven, deterministic, distributed controlfault tolerant, high integrity

• same integrity• same availability

but• higher bandwidth• reduced complexity:

fewer operational modes (simplicity, dev., V&V, cert.)simpler message protocolsimpler hardware

• easier to change & add applications:need for, and cost of changing bus traffic configuration

• easier to integrate system (debug, dev.)

• less costlyref.: K. Hoyme, K. Driscoll: “SAFEbus™ ”, Proc. 11th DASC, Seattle/WA, Oct. 1992, pp. 68-72ref.: E.E. Rydell: “Avionics “backbone” interconnection for busing in the backplane: advantages of serial busing”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp 216-220


41

Backplane databus: backbone of the system

• connects all processing nodes in the system

• integration of numerous conventional point-to-point and broadcast databuses between LRUs

• (time-)shared resource:• bus must provide fault tolerance (redundancy, distributed control, etc.)• bus interfaces must provide a high-integrity front-end• bus & bus protocol must ensure robust partitioning, while

supporting cost-effective development, upgrade & addition of applications

• supports multi-node architecture


42

Node architecture - generic processing module

- frame synchronized pair -

sets ofredundantbus lines

Bus I/FController

µP

DPRAM

Bus I/FController

µP

DPRAM

TableMem

TableMem

Clock

Clock

Clock

Clock


43

Node architecture - generic I/O module

sets ofredundantbus lines

Bus I/FController

µP

DPRAM

Bus I/FControllerTable

MemTableMem

analog, discrete, digital, audio

FIFO

I/F I/FClock

Clock Clock


44

Resource partitioning in all nodes: time & space

- the need for partitioning is driven bysharing of processing and communication resources -

• Space partitioning: • guarantees integrity of allocated program & data

memory space, registers, dedicated I/O

• Time partitioning: • guarantees timely access to allocated (shared)

processing & communication bandwidth• determinstic execution

- at functional level, an integrated system with a robust chain of partitioninglooks like a “virtual” federated system -


45

Growth Potential

Wake-vortex predictionWing-ice detectionClear Air Turbulence detectionVolcanic ash detectionEnhanced Vision System (EVS)

- expansion of IHAS baseline by integrating additional flight safety functions -


46

IHAS: stepping stone towards an integrated Enhanced Situational Awareness System (ESAS) ....

Warn & Caution

TCAS IIMode-S

WX/WindshearRadar

EGPWS

1999 .................………...................... 2005 .....

ESASESAS

Volc. AshVolc. Ash

RadarRadarTerrain & Obst.Terrain & Obst.

SensingSensing

IHASIHAS

Wake VortexWake VortexDryDry--HailHail

CATCAT

Cond. & Perf.Cond. & Perf.MonitoringMonitoring

HUDHUD

Radar Posn. Radar Posn. CorrelationCorrelation

ImagingImagingSensorsSensors

EVSEVS

Enh. TCASEnh. TCAS

ref.: F. George “Enhanced TCAS”, Business & Commercial Aviation, Oct. 96, pp. 60-63


47

Flight Operations Quality Assurance Tool (FOQA)

Accidents are not frequent enough to measure safety through accident ratesAbsence of accidents does not necessarily imply “safety”IHAS can monitor safety parameters for statistically meaningful measurement of “Merit of Safety Quality”• relative safety• how close to hazardous condition• how often• statistical only: not traceable to particular flights• can be used to indentify unsafe SIDs/STARs, ATC procedures,

etc.


48

Ex.: Safety Margin Prediction for CFIT

3o Glideslope

Terrain Clearance

Runway

Nominal

Terrain Clearance

Pro

babi

lity

0

Probability ofCFIT

- similar statistical process as done for autoland cert. -


49

Unified AlliedSignal IMA approach • Necessity for SBUs/SBEs to have IMA:

response to RFIscompetitive reasons

• Single concept for multiple SBUs/SBEs: IHAS approach with Application Specific I/O Modulessingle-company & generic solution towards Customer

• Reduced NRE across applications: re-use of backplane, modules, circuit design, O/S, BIT, V&V, etc.fewer specific test equipmentsharing / pooling of resources from various SBUs/SBEs

• Reduced RE:economies of scale for “generic” modules and backplanefewer partnumbers (documentation, spares, test equipm., etc.)interchangeability of modules across applications

• Enhanced functionality, safety, and utility:e.g., integration of information (e.g., IHAS “smart alerting”)

- benefits to Customer and to AlliedSignal -


50

“common” “specific”

IOM

CPM(dual)

PSM(dual)

Bus+

Mechtbd

tbd

Radar RF/DSP

TCAS RF/DSP

O/SMaint S/WBIT S/W

Com/NavIMA

- maximum re-use of common resources -

Unified AlliedSignal IMA approach

Appl. S/W

IHAS

UtilitiesControl IMA

lliedSignalA E R O S P A C E 1


• Integrated Cockpit Avionics• Integrated Hazard Avoidance System•• Integrated Utilities SystemIntegrated Utilities System


Typical transport aircraft systems

On-Board Maint

Condition Mon.Pax Entertain.

Pax Comm.

Flight Safety- FDR, CVR- TCAS- GPWS- WX

Flight Warning

Hyd Supply

Landing GearsSteering

Brakes

Control SurfaceActuation

Lighting- external- flight deck- cabin

Elec Pwr GenElec Pwr Distr

Load Mgt

DC sensorsWindshld Heat

Thermal Mgt

APU Control

Thrust Reverse

Engine Control

Fuel Control

Bleed Air

Cargo Fire ProtEng. Fire Prot

Cabin Air- pressure- conditioning

Avionics Cooling

Anti-IceSmoke Detect

Bleed Leak Det

PFCS

AFSSFCS

FMSAP/AT

Perf Mgt

Cargo HandlingPotable Water

Lavs & WasteGalley

Escape SystemOxygen

Displays

CNS Radios

Data Concentr.

Comm Mgt

Air Data &Inertial Ref

AvionicsAvionics Flight ControlFlight Control

Environmental ControlEnvironmental Control

ElectricalElectrical

PayloadPayload HydroHydro--MechanicalMechanical

PropulsionPropulsion

ref.: D. Parry: “Electrical Load Management for the 777”, Avionics Magazine, Feb. ‘95, pp. 36-38ref.: “Avionics on the Boeing 777, Part 1-11”, Airline Avionics, May ‘94 - June ‘95ref.: M.D.W. McIntyre, C.A. Gosset: “The Boeing 777 fault tolerant air data inertial reference system ”, Proc. 14th DASC, Boston/MA, Nov. ‘95, pp. 178-183ref.: G. Bartley: “Model 777 primary flight control system”, Boeing Airliner Magazine, Oct/Dec ‘94, pp. 7-17ref.: R.R. Hornish: “777 autopilot flight director system”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 151-156


Typical Environmental Control System


Typical Environmental Control System

• valves– motor– solenoid

• compressors– motor, turbine– air-fan

• fluid pump• other EM devices

Sub-system Functions:• engine starting• bleed-air temp/press regulation • cabin pressure• cabin cooling• anti-ice, de-ice, de-fog• cooling hydr/electr/mech power devices• avionics cooling

Internal Sensors:• temperature• pressure• air flow• fluid flow• humidity• angular speed• ang./lin. position

Internal Actuators:

• air data• heat load on/off• load shedding• throttle setting• air/gnd status• fuel/coolant temp• flow/temp/press

demand

Signal Outputs:Signal Inputs:• valve drives• actuator drives• temp/flow/press• fault/warning• fuel flow recirc.

demand

• air flow at suitable temp & press

• coolant flow at suitable temp & press

• O2, N2 flow• APU air

• bleed/APU air• hydr fluid/coolant• electr. power• pneum. servo pwr• ram air• fuel

Physical Inputs: Physical Outputs:

- multi-variable, multi-channel control -


Integrated Utilities System

• very I/O intensive:up to ≈ 90 sensorsup to ≈ 60 effectors

• wide variety of I/O:sensors: pressures, temperatures, flows, speeds, humidityeffectors: valves, compressors, pumps, ejectors, other EM deviceseven next generation will still have many analog I/Os

• involves switching high levels of electrical power: 25 - 100 kW precludes long cables: switching-electronics close to (or bolted onto) engine

• future engines:electrical start instead of air (requires > 100 kW!)bleed-air system will be deleted through mech. integration (civil only)

Environmental control:


Environmental Control System (ECS) - technology trends

Integrated Utilities

Integrated Systems

Microprocessor/Software

1960 1970 1980 1990 2000

C5AC5A

DCDC--1010FF--1515

FF--18 C/D18 C/D

B757/767B757/767

MDMD--1111

FF--2222

SystemComplexity

A330/340A330/340BB--22

ICECSICECS

747747DC9DC9

A320A320

777777

VV--2222

FF--18 E/F 18 E/F

B767 EBASB767 EBAS

Hybrid Analog Digital

Solid State Analog

Magnetic Amplifier

JASTJAST

ref.: “Jane’s Avionics, 1992-1993”, Jane’s Information Group Inc., 664 pp., ISBN 0-7106-0990-6ref.: “Jane’s All the World’s Aircraft, 1993-1994”, Jane’s Information Group Inc., 733 pp., ISBN 0-7106-1066-1


- Components of AlliedSignal F-22 ATF IECS -

- over 120 control channels -


AlliedSignal MD-11 ECS Controller and Sensors


Related utilities sub-systems that require control at or near the engine





PropulsionPropulsionOn-Board Maint


Pax Comm.


Flight Warning

Hyd Supply


Brakes




Load Mgt


Thermal Mgt

APU Control

Thrust Reverse

Engine Control

Fuel Control

Bleed Air



Avionics Cooling


Bleed Leak Det

PFCS

AFSSFCS

FMSAP/AT

Perf Mgt


Lavs & WasteGalley

Escape SystemOxygen

Displays

CNS Radios

Data Concentr.

Comm Mgt


- technology demonstration -


Environmental Control & Thermal Management System

VaporCycleUnit

APU

GroSouPowSouAirc

Comp

FliDe

En

undrceer

rceraftuters

ghtck

gine

SelectorDisplays

Controls

Diagnostics

Windows

BleedAir

AirCycleUnit

Anti-IceDe-Ice

CabinTemp

EquipLoads

ThermalMgmt

Fuel

CabinPressure

demand

demand

demand

avionicsradarhydraulicselectr. power


J/IST Suite Consensus Demonstration Architecture

Combustor

Heat Exchanger

Fuel

Starter/Generator

Engine

APU

A/CLoads

EngineOil

Ble

ed-A

ir

Electr. PowerDistribution

T/EMMController

FADEC

ExternalPower

OtherSub-systemControllers

On same shaft:• APU• starter/generator• bleed-air compressor

- mechanical integration and controls integration -ref.: J/IST RFP


Integrated Modular Utilities Control System

ECS

Bleed AirAPU

Vapor Cycle Sys.

Hydraulic Sys.Electric Power

Cabin Pressure

Sensors &Actuators

DigitalInterface

OtherFunctions

PowerElectronics

PowerSupply

CPUModule

Conventional ControlsConventional Controls Integrated Thermal/Environmental ControlIntegrated Thermal/Environmental Control

- mechanical integration forces controls integration -


Integration of controls

• Integrated control system has higher criticality• So, (more) fault tolerance required

•T/EMM Controller is based on MAFT: Multi-computer Architecture for Fault Tolerance:

a platform of 4* semi-autonomous computer nodes (lanes)connected by a serial-link broadcast bus networkeach of the 4 nodes (lanes) is partitioned into a Computing Module and an I/O Modulethe computing module is partitioned into an Applications Processor and an RTEM (Real-Time Executive Module) co-processor

* MAFT is not limited to 4 nodes

ref.: C.J. Walter, R.M. Kieckhafer, A.M. Finn: “MAFT: a Multicomputer Architecture for Fault-Tolerance in Real-Time Control Systems”, Proc. IEEE Real Time Systems Symp., San Diego/CA, Dec. ‘85, 8 pp.

ref.: C.J. Walter: “MAFT: an architecture for reliable fly-by-wire flight control”, proc. 8th DASC, San Jose/CA, Oct. ‘88, pp. 415-421ref.: L. Lamport, R. Shostak, M. Pease: “The Byzantine Generals Problem”, ACM Trans. on Programming Languages & Systems, Vol. 4, No. 3, July ‘82, pp. 382-401ref.: M. Barborak, M. Malek, A. Dahbura: “The Consensus Problem in Fault-Tolerant Computing”, ACM Computing Surveys, Vol. 25, No. 2, June ‘93, pp. 171-220


RTEM-based systemfully connected broadcast network

RTEM

AP

IOP

RTEM

AP

IOP

RTEM

AP

IOP

RTEM

AP

IOP

(repeated for all nodes)

system busses


MAFT/RTEM

• MAFT: original theory & concepts developed and patented by Bendix Aerospace Technology Center, Columbia/MD (1970s)

• Concept:fault tolerant co-processor which provides RedMan functions for real-time mission-critical systemsdedicated h/w, makes overhead functions transparent to APs: looks like peripheral (memory mapped or I/O port)deterministic, design-for-validation (certification)to reduce system development, validation cost supports dissimilar AP µPs & N-Version s/w to protect against generic faults makes no assumptions regarding types of faults/errors to be tolerated: any fault/error is possible, no matter how malicious


Real-Time Executive Module (RTEM)

• Hardware-implemented executive (overhead) functions associated with redundancy mgmt:

fault-tolerant inter-channel communicationfault-tolerant inter-channel synchronizationvotingerror detection, isolation, recoverydynamic system reconfiguration

• faulty channel exclusion• healthy channel readmission

fault tolerant task schedulingRTEM-AP interface

• Provides mathematically provable correctness


Global consistency • Basis for reliability in a distributed fault-tolerant system• Must be established on all critical system parameters• Two forms of agreement:

“Byzantine Agreement” (exact agreement) on boolean data• Agreement: all healthy lanes agree on contents of every message

sent.• Validity: all healthy lanes agree on contents of messages sent by

any other healthy lane, as originally sent.“Approximate Agreement” (interactive consistency) on numerical data

• Agreement: all healthy lanes eventually (within acceptable time, after multiple rounds of vote/exchange/vote) agree on values that are within an acceptable deviance “ε” of each other, ∀ ε > 0

• Validity: the voted value obtained by each healthy lane must be within the range of initial values generated by the healthy lanes.

- the ability of non-faulty lanes to reach agreement despite presence of (some) faulty lanes -


RTEM-based node

RTEM

ApplicationsProcessor

fully connectedbroadcast network

Input/OutputProcessor

systembus(es)

Discrete I/OAnalog I/O


RTEM block-diagram

MessageChecker

Voter

FaultTolerator

Transmitter

Synchronizer

TaskScheduler

TaskCommunicator

to all other nodesfrom all other nodes +wrap from own node

to/fromapplicationsprocessor


Real-Time Executive Module (RTEM)

• Transmitter + Receivers + Message Checker:fault-tolerant inter-channel communication

• Voter:Approximate (with deviance limit), or Boolean

• Task Scheduler:event driven, priority based, globally verified (inc. WDT)allows wide variety of execution times & iteration rates

• Synchronizer:loose-sync (frame based), periodic resync (exchange, vote, correct local clocks = distr. FT global clock)

• Fault Tolerator:collects inputs from all error detection mechanisms (≈ 25), and generates error reports (voted)

lliedSignalA E R O S P A C E 21RTEM Prototype Board - VME 6U


RX/TX Conn.

RTEM Prototype Board

Recvr (x4)X-mitter (x1)

Msg ChkrMem Mgt

Sync

VoterTaskSched

Flt Tol.Buf. Ctl

Seq


MAFT/RTEM Hardware Integration

Single-Chip RTEM≈ 80k gates FPGA

RTEM Prototype Boardmid-’90s

5x FPGA Chip SetVME 6U

TTL-version MAFTmid-’80s

2x3x7 ft cabinet


Candidate systems for Integrated Utilities

21222324252627282930

Air ConditioningAutoflightCommunicationsElectric PowerEquipment/FurnishingsFire ProtectionFlight ControlsFuelHydraulic PowerIce and Rain Protection

313233343536384549

Indicating/Recording SystemsLanding GearLightsNavigationOxygenPneumatic SystemWater/WasteCentral Maintenance SystemAirborne Auxiliary Power

indicates candidate system

- airframe systems by ATA chapter -


2

Some thoughts on the future ........

further cost reduction• avionics NRC: systems & software

engineering, architecture/integration• production RC

deletion of avionics• GPS “sole means of nav” by 2010 in USA• demise of NDB, VOR, DME, ILS

additional avionics & functions• ATN, GPS, CMS, FBW, ESAS, ....

consolidation/integration of avionicsmore datalinking

• ADS, WX cont’d →ref.: A. Gerold: “The Federal Radionavigation Plan”, Avionics Magazine, May 1996, pp. 34-35


3

FANS: Future Air Navigation System

source: B. Evans: “The Age of Data Link”, Avionics Magazine, Jan. ‘96, pp. 28-


4

Future ........ (cont’d)

• device density and performance• system complexity and size• remote electronics:

end-to-end digitalizationinterfacing & computing closer to data source or to point of application“smart” sensors, actuators, skins, etc.

• standard real-time operating systemsapplication transparency to hardwarestrict partitioning

cont’d →ref.: M. Rodriguez, M. Stemig: “Evolution of embedded avionics operating systems”, presented at DASC-95, Boston/MA, Nov. ‘95, 5 pp.


5

Component and System Performance trends

Note: curves not necessarily drawn to scaleProcessing & Memory

Density

time

Level of FunctionalIntegration

PowerWeight Volume

"now-ish"

SystemCost

Reliability

ref.: G. Stix: "Toward 'point One' - Trends in Semiconductor Manufacturing," Scientific American, February 1995, pp. 90-95ref.: G.D. Hutcheson, J.D. Hutcheson: "Technology and Economics in the Semiconductor Industry," Scientific American, January 1996, pp. 54-62


6

ref.: G.D. Hutcheson, J.D. Hutcheson: "Technology and Economics in the Semiconductor Industry," Scientific American, January 1996, pp. 54-62ref.: M. Slater: “The microprocessor today”, IEEE Micro, Dec. 1996, pp. 32-44

Exponential increase of

transistor density80786

YEAR OFAVAILABILITY

NU

MB

ER

OF

TR

AN

SIS

TO

RS

PE

R C

HIP

1970 '72 2000'74 '76 '78 '80 '82 '84 '86 '88 '90 '92 '94 '96 '98103

410

510

610

710

810

910TIME FRAMES FOR

LITHOGRAPHY SYSTEMS

CONTACT ALIGNERS

PROXIMITY ALIGNERS

PROJECTION ALIGNERS

FIRST G-LINE STEPPERS

ADVANCED G-LINE STEPPERS

FIRST I-LINE STEPPERS

ADVANCED I-LINE STEPPERS

FIRST DEEP-UV STEPPERS

INTEL MICROPROCESSOR

MOTOROLA MICROPROCESSORSIZE OF MEMORY (DRAM) IN BITS4004

8080

8086

80286

6800

80386

80486

PENTIUM

80786

PENTIUMPRO

68000

6802068030

68040

POWER PC 601

1K

16K

4K

256K

64K

POWER PC 604

POWER PC 620

1M

4M

16M

64M

256M

Current range: 106 → 50x106

transistor per chip; can be used to:• increase performance (PC µPs)

and/or• integrate more functions with µP and evolve towards complete system-on-chip (embedded applications)


7

Component and System Performance trends

- DSP integration through the decades -

1982 1992 2002Die sizeTechnology sizeMipsMHzRAMROMPricePower TransistorsWafer size

50 mm3 µ5 Mips20 MHz144 words1.5k words$150250 mW/Mips

3-in wafer50k transistors

50 mm0.8 µ40 Mips80 MHz1k words4k words$1512.5 mW/Mips500k transistors6-in wafer

50 mm0.25 µ400 Mips200 MHz16k words1.5M words$1.500.25 mW/Mips5M transistors12-in wafer

source: Texas Instruments

- further price/performance improvements to be expected -ref.: EE Times, May 22, ‘95, p. 16


8


• new, certifiable bi-directional databuses: – integrate databuses → reduce wiring & h/w

ARINC-629 ASICs & coupler very expensive– SAE Avionics Systems Div.: 2 Gbit/s

serial/parallel databus iniative “Unified Network Interconnect”, based on IEEE SCI

– NASA/Industry AGATE initiative: ECHELON databus

• new, simpler, affordable backplane bus: – ARINC-659 h/w and ARINC-650 connectors

very expensive

ref.: C. Adams: “Emerging Databus Standards”, Avionics Magazine, March ‘96, pp. 18-25ref.: K. Hoyme, K. Driscoll: “SAFEbusTM”, Proc. 11th DASC, pp. 68-72ref.: “Automated cockpits special report - Part 1 & 2”, Aviation Week & Space Technology, Jan 30 ‘95, pp. 52-65, Feb. 6 ‘95, pp. 48-55


9


• improved human factors (safety)

• “open standard” LRMs, LRM → BFE?

• electrical power: 270 Vdc, Vac, battery backup?

• HOL source code ownership?

• “more electric” aircraft ? (e.g., development of powerful rare-earth PM motors)

• full-time APUs (much higher APU rel., APU bleed-air → more efficient engines)

• new processor architectures (e.g., “wormhole computer”?)

• ??


10


On-Board Maint


Pax Comm.


Flight Warning

Hyd Supply


Brakes




Load Mgt


Thermal Mgt

APU Control

Thrust Reverse

Engine Control

Fuel Control

Bleed Air



Avionics Cooling


Bleed Leak Det

PFCS

AFSSFCS

FMSAP/AT

Perf Mgt


Lavs & WasteGalley

Escape SystemOxygen

Displays

CNS Radios

Data Concentr.

Comm Mgt






PropulsionPropulsion

66--7 IMAs + remotes7 IMAs + remotes


11

System Complexity and Size - trends -

installedsoftware

↑

0

20 MB

10 MB

747-200 757/767-200

747-400A310

A320

A330/340

1970 1980 1990Year

1995198519751970 1980 19900

Year

747-200757/767-200

100 k

50 k

↑

↑

777-200100 MB

80 MB

150 k 777-200

747-400

Apollo

↑Total airplane

signal interfaces(digital words / labels

& analog)

partially drivenby Ada req't

> 2M

SLO

Cs

SystemSize

SystemComplexity

2x every 2 years

ref.: P. Gartz: “Systems Engineering,” tutorial at 13th & 14th DASC, Boston/MA, Nov. 1995; ref.: Airbus Industries (pers. conv.)ref.: P. Gartz: “Trends in avionics systems architecture”, presented at 9th DASC, Virginia Beach/VA, Oct. ‘90, 23 pp.ref.: P. Pelton, K. Scarborough.: “Systems Engineering Experiences from the 777 AIMS program,” proc. 14th AIAA/IEEE DASC, Boston/MA, Nov. 1995


12

System complexity - trends -

777-200

747-400

757/767-200747-200

150k

100k

50k

01970 1980 1990

↑Total airplane

signal interfaces(digital words / labels

& analog)



13

System size - trends -

777-200

A330/340

A320

747-400

757/767-200

A310

747-200

Apollo

100 MB

80 MB

20 MB

10 MB

01970 1980 1990

partially driven by Ada req.

2x every 2 years



14

Software Size - example: 777-200excl. BFE equipment

600

500

400

300

200

100

Sour

ce L

ines

of C

ode

(kSL

OCs

)

AIMSCMS CNI

ECSELEC

Flt Ctl

Mech/HydProp

Flt Deck

490

415377

278230

168126

49 30

Total: 2.1 MSLOCs

combined Elec/Mech 634k > AIMS

- mech/elec systems SLOC combined is larger than AIMS -source: BCAG


15

System Complexity and Size

Typical large jetliner:≈ 8,000 inputs & outputsthese I/Os interface to ≈ 700 peripheral units at various parts of the aircraft≈ 90 different avionics units≈ 160 microprocessors (≈ 8 types)adding/changing of avionics is complicated & expensivemany flight-deck switches & controls (e.g., 250 on 747-400, down from 900 on 747-200)

source: Airbus Industries


16

Avionics interconnection system*• Example: Boeing 747

some 1,500 circuit breakers200,000 individually marked lengths of cabletotal ≈ 225 km (140 miles)400,000 connections14,000 connectors3,000 splices35,000 ring terminalsover 1,000,000 individual parts“system” accounts for ≈ 10% of a/c price tag

* exc. main power feeds

ref.: A. Emmings: “Wire power”, British Airways World Engineering, Iss. 8, July/Aug. ‘95, pp. 40-43


17

Extrapolation ......

Given:• 777 processing power ≈ equivalent to

1,000 x 486Assuming:

• Moore’s Law (2x every 18 months)Hence:

• “single-processor” 777 within 15 years....

“Computers in the future may weigh no more than 1.5 tons”Popular Mechanics magazine, 1949

- forecasting the wonders of modern technology -13

ref.: Gordon Moore, 1966, on performance, complexity, and number of transistors per


18

Enabling technologies

• Components• Architectures• Communication• Design / development processes

- bottom line: technology, people, processes -


19


- components -

integration (incl. RF)miniaturization, high-density packaging, improved chip-to-package size efficiency(Multi Chip Module, Chip-On-Board, Flip-Chip,Chip-Scale- Package, 3-D stacking, etc.)high temperature electronics (THE, e.g. SiC)fault-tolerant electronics (FTE), chip-level redundancychip & inter-chip BIT

ref.: G. Derman: “Interconnects & Packaging - Part 1: Chip-Scale Packages”, EE Times, 26 Feb. ‘96, pp. 41,70-72ref.: T. DiStefano, R. Marrs: “Building on the surface-mount infrastructure”, EE Times, 26 Feb. ‘96, pp. 49ref.: HITEN (High Temp. Electronics Network)“Aerospace applications of High Temperature Electronics”, 13 May ‘96, http://www.hiten.com/hiten/categories/aeroref.: S. Birch: “The hot issue of aerospace electronics”, SAE Aerospace Engineering, July ‘95, pp. 4-6ref.: J.A. Sparks: “High temperature electronics for aerospace applications”, proc. ERA Avionics Conf., London,Nov./Dec. ‘94, pp. 8.2.1-8.2.5


20

Enabling technologies- components -•MCMs:

reduced size, increased performancelow inductive/capacitive parasiticslower supply noise & ground bouncevery expensive (mfg & test)3-D stacking (e.g., memory) poses thermal problemsmilitary niche market for time being

MCMPCB SMT device

thru-holedevice

MCM substratePCB SMT devicethru-hole

device

ref.: J.H. Mayer: “Pieces fall into place for MCMs”, Military & Aerospace Electronics, 20 March ‘96, pp. 20-



- drivers for high-volume = low-cost components -

• (mobile) PC and Com industry :circuit integration & packagingPC-Card: highest density PCB technology (PCMCIA)

powerful general-purpose processors

• Automotive industry:high temperature electronicscoming: ruggedized “laptop” LCDs*(temp/vibe/sunlight environment similar to aviation application)

* there is no reason why (smart) Display Units cannotbe reduced to the size of notebook PC


22

Electronics evolution


23

Enabling technologies- design / development -

• Integration causes a shift in responsibilities:component suppliers → circuit integrators

hardware designers → chip/module integrators

avionics suppliers → system integrators


24

Examples of integration at component level

• processor modules• power supply modules • RF modules• I/O modules


25 Example: PC mother-board in a module

236-pinconnector

5.4 cm(2 1/8 in.)

8.5 cm (3 3/8 in.)

Cardio™-486, 5/96486DX2/DX425-100 MHz

up to 32 MB RAMup to 4 MB Flash512 kB VRAM

256 kB BIOS ROM LCD/RGB SVGA

IDE Hard/Floppy DrKeyboard ctlr

Power Mgt

Complete 486 PC AT

with PC-card form factor

(frmr PCMCIA)

photo: courtesy Seiko/Epson via S-MOS Systems Inc, San Jose/CA


26

Example: integrated power supply modulesphoto: courtesy Analog Devices, Norwood/MA, 199628 → 5 Vdc/dc converter (100 W)

ADDC02805S

7 cm (2 3/4 in.)

3.8 cm(1½ in.)

ref.: D. Maliniak: “Modular dc-dc converter sends power density soaring”, Electronic Design, Aug. 21 ‘95, pp. 59-


27

Example: integrated X-band power module

Texas Instruments transmitter module

6x HFET MMIC @ 12 W13 dB gain400 MHz bandw.

> 30% PAE (9.5-9.9 GHz)built-in modulator

built-in gate regulator

waveguide outputMTBF > 400k hrs6.5 x 3.8 x 0.5 cm (2½ x 1.1 x 0.2 in.)

ref.: J. Sweder et al.: “Compact, reliable 70-watt X-band power module with greater than 30-percent PAE”, proc. MTT symposium, June 1996


28

Example: integrated discrete-to-digital interface

DD-03201

•Inputs:• 96 non-redundant, or • 32 triplex inputs

•Configurable:• 28V/Open• 28V/Gnd, or• Open/Gnd

•Interface:• µP or • A429 output

•Programmable debounce•BIST•MTBF @ 64° C, est.:

• 270,000 hrs (96 in)• 333,000 hrs (32 in)

•Size: 2.8x2.8 cm (1.1 x 1.1”)

ref.: DDC (ILC Data Device Corp.) databook 1996


29

Cold-Cathode Field Emission Displays (FEDs)

Anode

Red phosphor Blue phosphorGreen phosphor

Indium-ten-oxide layer

Gate row line +

Blue sub-pixelRed sub-pixel Green sub-pixel

Individual pixel

Resistivelayer

MicrotipsColumn line

CathodeCathode conductor

Glass

Glass face plate

- CRT performance & image quality in low-power flat-panel display -(emerging challenge to AM-LCDs?)

ref.: ”FED up with LCDs?”, Portable Design, March ‘96, pp. 20-25


30

“PCMCIA” vs. AIMS Avionics Cabinet

AIMS:47”x18”x9.6”111 lbs

“PCMCIA”:6.5”x4.5”x3.0”2 lbs


31


more components become “complex”* (not 100% analyzable or 100% testable)

hardware-near-software

must apply design assurance to devices & tools, as already req’d for software (DO-178); but who will do this for COTS?

- component integration issues -

* not necessarily high gate count

ref.: RTCA DO-180ref.: BCAG: "777 Application Specific Integrated Circuits (ASIC) Certification Guideline," Boeing Doc. 18W001; also: RTCA Paper No. 535-93/SC180-11, December 1993ref.: Honeywell Commercial Flight Systems: "ASIC Development and Verification Guidelines," Honeywell Spec. DS61232-01 Rev A, January 1993; also: RTCA Paper No. 536-93/SC180-12ref.: Harrison, L.H., Saraceni, P.J.: "Certification Issues for Complex Digital Hardware," Proc. 13th AIAA/IEEE DASC, Phoenix/AZ, Nov. 1994, pp. 216-220


32


- architectures -

dynamic resource allocation

move away from brute force redundancy

scalable redundancy (GenAv ↔ AT)

partitioning


33

Resource Partitioning- part of system architecture and safety strategy -

• Physical and logical organization of a system such that:a partition does not contaminate an other’s data & codestorage areas, or I/O failure of a resource that is shared by multiple partitions does not affect flight safetyfailure of a dedicated partition-resource does not cause adverse effects in any other partitionfailure of a partition does not reduce the timely access toshared resources by other partitions

- architectural means for providing isolation of functionally independent resources, for fault containment & isolation, and potential reduction of verification effort -

ref.: RTCA DO-178, DO-180


34

Resource Partitioning (cont’d)

• Partitions cannot be trusted:an independent protection mechanism must be provided against breaches of partitioningall failures of the protection mechanism must be detectable

• Advantages of partitioning:provides an effective means to meet safety req’smaximizes ability to detect & contain errors/faults allows partitions to be updated & certified separatelyallows re-V&V to be limited to changed partitionallows incremental & parallel design, test, integrationsupports cost-effective development, cert., maint., updatesallows mixed-criticality (not within same partition!)provides flexibility in responding to evolving system req’s

ref.: M.J. Morgan: “Integrated modular avionics for next-generation commercial airplanes”, IEEE AES Magazine, Vol. 6, No. 9, Aug. ‘91, pp. 9-12


35


- communication -

fiber-optic communication (incl. on-chip)

low(er) cost multi-directional databus

air-ground, air-air

ref.: M. Paydar: “Air-ground data links offer operational benefits as well as new possibilities”, ICAO Journal, May 1997, pp.13-15


36

Enabling technologies- design / development -

capturing complete set of validated req’ssoftware auto-codesoftware V&Vhardware V&V (DO-180: hardware-near-software, “complex” hardware)EMI/Lightning certificationre-use

ref.: NATO AGARD Advisory Report 274: “Validation of flight critical control systems”, Dec. ‘91, 91 pp., ISBN 92-835-0650-2


37 Enabling technologies

10,000

1,000

100

10

1

High

Medium

LowRequire-

mentsDesign,

DevelopmentTest

Production &Deployment

In fl uenceon

Ou tcome

Cost t o FixProblems

- it clearly pays to do the right thing up front* -

- design / development -

* but plan for inevitable need to correct/change req’s, as insight into the need and the “best” solution grows during development (and customer changes its mind)

ref.:Port, O., Schiller, Z., King, R.W.: “A smarter way to manufacture,” Business Week, April 30, 1990, pp. 110-117


38

Enabling technologies- design & development -

World Class - 3

Structured - 2

Defined - 1

Undefined - 0

EquivalentMaturity Level

Percentage ofSurveyed firms

Return-on-Sales p.a.1987-1991

Sales Growth p.a.1987-1991

(141 companies total) SampleAverage

4%

36

52

36

17

4.7%

6.7%

9.3% 16%

8.1%

7.3%

5.1%SampleAverage

8%

0.5%

- business performance is linked to engineering maturity level -

ref.: “Excellence in quality management”, McKinsey & Co., Inc., 1992ref.: Dion, R.: “Process improvement and the corporate balance sheet”, IEEE Software, Vol. 10, No. 4, July 1993, pp. 28-35


39


s/w ≈ 2/3 of system development cost: prime area for improvement systems engineering to provide req’s set:• F3I, performance (inc. timing), technology, etc.• complete, validated, traceable, consistent, unambiguous

eliminate errors via (V&V-ed) autocodestandard libraries of software modules (re-use)automated V&V tools

- certified software is too expensive -ref.: EIA Interim Std 632 “Systems Engineering”, Dec. 1994ref.: IEEE 1220 Std for Appl. and Mgt of the Systems Engineering Process, Dec. 1994


40

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to

produce bigger and better idiots. So far, the universe is winning.”

Rich Cook, comedian

BIBLIOGRAPHY

BOOKS

F.J. Redmill (ed.): “Dependability of critical computer systems - 1”, 1988, 292 pp., ITP Publ., ISBN 1-85166-203-0D.P. Siewiorek, R.S. Swarz (eds.): “Reliable computer systems”, 2nd ed., Digital Press, ‘92, 908 pp., ISBN 1-55558-075-0M.R. Lyu (ed.): “Software fault tolerance”, Wiley & Sons, ‘95, 337 pp., ISBN 0-471-95068-8B.W. Johnson: “Design and analysis of fault tolerant systems”, Addision-Wesley, ‘89, 584 pp., ISBN 0-201-07570-9“25th Anniversary Compendium of Papers from Symposium on Fault Tolerant Computing”, IEEE Comp. Society Press, ‘96, 300 pp., ISBN 0-8186-7150-5N. Suri, C.J. Walter, M.M. Hugue (eds.): “Advances in ultra-reliable distributed systems”, IEEE Comp. Society Press, ‘95, 476 pp., ISBN 0-8186-6287M. Pecht (ed.): “Product reliability, maintainability, and supportability handbook”, CRC Press, ‘95, 413 pp., ISBN 0-8493-9457-0H.E Roland, B. Moriarty: “System safety engineering and management”, 2nd ed., Wiley & Sons, ‘90, 367 pp., ISBN 0-471-61816-0G.L. Fuller: "Understanding HIRF - High Intensity Radiated Fields," publ. by Avionics Communications, Inc., Leesburg, VA, 1995, 123 pp., ISBN 1-885544-05-7J. Curran: “Trends in advanced avionics”, Iowa State Univ. Press, ‘92, 189 pp., ISBN 0-8138-0749-2J.R. Newport: “Avionic system design”, CRC Press, ‘94, 332 pp., ISBN 0-8493-2465-3C.R. Spitzer: “Digital Avionics Systems - Principles and Practices”, 2nd ed., McGraw-Hill, ‘93, 277 pp., ISBN 0-07-060333-2I.C. Pyle: “Developing safety systems - a guide using Ada”, Prentice Hall, ‘91, 254 pp., ISBN 0-13-204298-3E.T. Raymond, C.C. Chenoweth: “Aircraft flight control actuation system design”, SAE, ‘93, 270 pp., ISBN 1-56091-376-2D.T. McRuer, D.E. Johnson: “Flight control systems: properties and problems - Vol. 1 & 2”, 165 pp. & 145 pp., NASA CR-2500 & -2501D. McRuer, I. Ashkenas, D. Graham: “Aircraft dynamics and automatic control”, Princeton Univ. Press, ‘73, 784 pp., ISBN 0-691-08083-6J. Roskam: “Airplane flight dynamics and automatic flight controls - Part 1 & 2”, Roskam A&E Corp., 1388 pp., Library of Congress Card No. 78-31382NATO Advisory Group for Aerospace R&D : “AGARD Advisory Report 274 - Validation of Flight Critical Control Systems”, dec. ‘91, 126 pp., ISBN 92-835-0650-2C.A. Clarke, W.E. Larsen: “Aircraft Electromagnetic Compatibility”, feb. ‘85, 155 pp., DOT/FAA/CT-88/10; same as Chapter 11 of Digital Systems Validation Handbook

Vol. IIR.A. Sahner, K.S. Trivedi, A. Puliafito: “Performance and reliability analysis of computer systems”, Kluwer Academic Publ., 1995, ISBN 0-7923-9650-2E.L. Wiener, D.C. Nagel (eds.): “Human factors in aviation”, Academic Press, 1988, 684 pp., ISBN 0-12-750031-6

Reliability Analysis Center (RAC) of the DoD Information Analysis Center (1-800-526-4802):“The Reliability Sourcebook 'How and Where to Obtain R&M Data and Information,” RAC Order Code: RDSC-2, periodic updates“Practical Statistical Analysis for the Reliability Engineer,” RAC Order Code: SOAR-2“RAC Thermal Management Guidebook,” RAC Order Code: RTMG“Developing Reliability Goals/Requirements”, October 1996, 34 pp., RAC Order Code: RBPR-2“Designing for Reliability”, October 1996, 74 pp., RAC Order Code: RBPR-3“Measuring Product Reliability”, September 1996, 47 pp., RAC Order Code: RBPR-5“Reliability Toolkit: Commercial Practices”, RAC Order Code: CPE“Fault Tree Analysis Application Guide", RAC Order Code: FTA“Failure Mode, Effects and Criticality Analysis", RAC Order Code: FMECA

© 1997 F.M.G. Dörenberg1

ARTICLES (referenced in presentation slides)

A.D. Welliver: “Higher-order technology: adding value to an airplane,” Boeing publ., presented to Royal Aeronautical Society, London, Nov. 1991Anon.:“Is new technology friend or foe?” editorial, Aerospace World, April 1992, pp. 33-35B. Fitzsimmons: “Better value from integrated avionics?” Interavia Aerospace World, Aug. 1993, pp. 32-36ICARUS Committee: “The dollars and sense of risk management and airline safety”, Flight Safety Digest, Dec. ‘94, pp. 1-6P. Parry: “Who’ll survive in the aerospace supply sector?”, Interavia, March ‘94, pp. 22-24R. Ropelewski, M. Taverna: “What drives the development of new avionics?”, Interavia, Dec. ‘94, pp. 14-18, Jan. ‘95, pp. 17-18A. Smith: “Cost and benefits of implementing the new CNS/ATM systems”, ICAO Journal, Jan/Feb ‘96, pp. 12-15, 24K. O’Toole: “Cycles in the sky”, Flight In’l, 3-9 July 1996, p. 24C.A. Shifrin: “FAA paints upbeat air travel picture”, AW&ST, March 11 ‘96, pp. 30-31J. Moxon: “Outrageous ATC charges anger European regional”, Flight Int’l, 23-29 Oct 1996, p. 12P. Condom: “Is outsourcing the winning solution?” Interavia Aerospace World, Aug. 1993, pp. 34-36Anon.: “The guide to airline costs”, Aircraft Technology Engineering & Maintenance, Oct/Nov ‘95, pp. 50-58C.T. Leonard: “How mechanical engineering issues affect avionics design”, Proc. IEEE NAECON, Dayton/OH, ‘89, pp. 2043-2049B. Rankin, J. Allen: “Maintenance Error Decision Aid”, Boeing Airliner, April-June ‘96, pp. 20-27P. Gartz, “Systems Engineering,” tutorial at 13th & 14th AIAA/IEEE DASCC. Spitzer, “Digital Avionics - an International Perspective,” IEEE AES Magazine, Vol. 27, No. 1, Jan. ‘92, pp. 44-45T.H. Robinson , R. Farmer, E. Trujillo: “Integrated Processing,” presented at 14th AIAA/IEEE DASC, Boston/MA, Nov. 1995L.J. Yount, K.A. Kiebel, B.H. Hill: “Fault effect protection and partitioning for fly-by-wire/fly-by-light avionics systems”, Proc. 5th AIAA/IEEE Computers in Aerospace Conf., Long

Beach/CA, ‘85, 10 pp.D. Prasad, J. McDermid, I. Wand: “Dependability terminology: similarities and differences”, IEEE AES Magazine, Jan. ‘96, pp. 14-20A. Avizienis, J.-C. Laprie: “Dependable computing: from concepts to design diversity”, Proc. of the IEEE, Vol. 74, No. 5, May ‘86, pp. 629-638J.H. Lala, R. Harper: “Architectural principles for safety-critical real-time applications”, Proc. of the IEEE, Vol. 82, No. 1, Jan. ‘94, pp. 25-40J.-C. Laprie, J. Arlat, C. Beounes, K. Kanoun, C. Hourtolle: “Hardware- and software-fault tolerance: definition and analysis of architectural solutions”, Proc. 17th Symp. on Fault Tolerant

Computing, Pittsburg/PA, July ‘87, pp. 116-21J.F. Meredith: "Fault Tolerance as a Means of Achieving Extended Maintenance Operation," Proc. 1994 ERA Avionics Conf. and Exhib. "Systems Integration - is the sky the limit?", London,

Nov./Dec. 1994, pp. 11.8.1-11.8.9, ERA Report 94-0973 F. Wang, K. Ramamritham: “Determining the redundancy levels for fault tolerant real-time systems”, IEEE Trans. on Computers, Vol. 44, No. 2, Feb. ‘95, pp. 292-301P.S. Babcock: "An introduction to reliability modeling of fault-tolerant systems," Charles Stark Draper Lab. Report CSDL-R-1899J. Rushby: “Critical system properties: survey and taxonomy”, Reliability Engineering and System Safety, Vol. 43, 1994, pp. 189-219M. McElvany Hugue: “Fault Type Enumeration and Classification”, ONR-910915-MCM-TR9105, 26 pp.J.B. Bowles: “A survey of reliability-prediction procedures for microelectronic devices”, IEEE Trans. on Reliability, Vol. 41, No. 1, March ‘92, pp. 2-12S.F. Morris: “Use and Application of MIL-HDBK-217”, J. of the IES, Nov/Dec ‘90, pp. 40-46D. McRuer, D. Graham: “Eighty years of flight control: Triumphs and Pitfalls of the Systems Approach”, J. Guidance and Control, Vol. 4, No. 4, Jul/Aug ‘81, pp. 353-362R.W. Butler, G.B. Finelli: “The infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software”, IEEE Trans. on Software Engineering, Vol. SE-19, No. 1, Jan. ‘93, pp. 3-12P. Seidenman, D. Spanovich: “Building a better black box”, Aviation Equipment Maintenance, Feb. ‘95, pp. 34-36M. Doring: “Measuring the cost of dependability”, Boeing Airliner Magazine, July-Sept 1994, pp. 21-25D. Galler, G. Slenski: “Causes of electrical failures”, IEEE AES Systems Magazine, Aug. ‘91, pp. 3-8P. Gartz: “Trends in avionics systems architecture”, presented at the 9th DASC, Virginia Beach/VA, Oct. ‘90, 23 pp.M. Lambert: “Maintenance-free avionics offered to airlines”, Interavia, Oct. ‘88, pp. 1088-1089



M.L. Shooman: "A study of occurrence rates of EMI to aircraft with a focus on HIRF," Proc. 12th DASC, Seattle/WA, October 1993, pp. 191-194W. Reynish: “Three systems, One standard?”, Avionics Magazine, Sept. ‘95, pp. 26-28D. Hughes: “USAF, GEC-Marconi test ILS/MLS/GPS receiver”, AW&ST, Dec. 4 ‘95, pp. 96R.S. Prill, R. Minarik: “Programmable digital radio common module prototypr”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 563-567B.D. Nordwall: “HIRF threat to digital avionics less than expected”, AW&ST, Feb. 14, ‘94, pp. 52-54M.J. Morgan: “Integrated modular avionics for next-generation commercial aircraft”, IEEE AES Systems Magazine, Aug. ‘91, pp. 9-12D.C. Hart: “A Primer on IMA”, Avionics, April 1994, pp. 30-41D.C. Hart: “Integrated Modular Avionics - Part I - V” Avionics, May 1991, pp. 28-40, November 1991, pp. 25-29D. Rollema: “German WW II Communications Receivers - Technical Perfection from a Nearby Past”, Part 1-3, CQ, Aug/Oct 1980, May 1981A.O. Bauer: “Receiver and transmitter development in Germany 1920-1945”, presented at IEE Int’l Conf. on 100 Years Radio, London/UK, Sept. ‘95.H.-J. Ellissen: “Funk- u. Bordsprechanlagen in Pantzerfahrzeugen”, Die deutschen Funknachrichtenanlagen bis 1945, Band 3”, Molitor Verlag, ‘91, ISBN-3-928388-01-0R.J. Stafford: “IMA cost and design issues”, Proc. ERA Avionics Conf., London/UK, Dec. ‘92, pp. 1.4.1-1.4.9P.J. Prisaznuk: “Integrated Modular Avionics”, proc. IEEE NAECON-92, Dayton/OH, May 1992, pp. 39-45J.R. Todd: “Integrating controls and avionics on commercial aircraft”, proc. IEEE NAECON-92, Dayton/OH, May 1992, pp. 46-62R. Little: “Advanced avionics for military needs”, Computing & Control Engineering Journal, January 1991, pp. 29-34R.D. Trowern: “Designing an Inflight Entertainment System”, Avionics Magazine, Oct. ‘94, pp. 46-49D. Hughes, M.A. Dornheim: “United DC-10 crash in Sioux City, Iowa”, AW&ST, July 24, ‘89, pp. 96-97M.A. Dornheim: “Throttles land “disabled” jet”, AW&ST, Sept. 4, ‘95, pp. 26-27B.T. Devlin, R.D. Girts: “MD-11 Automatic Flight System”, Proc. 11th DASC, Oct. ‘92, pp. 174-177; also: IEEE AES Magazine, March ‘93, pp. 53-56E. Kolano: “Fly by fire”, Flight International, Dec. 20, ‘95, pp. 26-29G. Norris: “Boeing may use propulsion control on 747-500/600X”, Flight Int’l, 2-8 Oct ‘96, p. 4Anon.: “Engine nozzle design - a variable feast?”, Aircraft Technology Engineering & Maintenance, Oct/Nov ‘95, pp. 10-11B. Gal-Or: “Civilizing military thrust vectoring flight control”, Aerospace America, April ‘96, pp. 20-21D. Brière, P. Traverse: “Airbus A320/330/340 electrical flight controls - a familiy of fault tolerant systems”, Proc. 23rd FTCS, Toulouse/F, June ‘93, pp. 616-23R.J. Bleeg: "Commercial JetTransport Fly-By-Wire Architecture Considerations," Proc. AIAA/IEEE 8th DASC, San Jose/CA, October 1988, pp. 309-406R. Reichel: “Modular flight control and guidance computer”, Proc. 6th ERA Avionics Conf., London/UK, Dec. ‘92, 9 pp.K.R. Dilks: “Modernization of the Russian Air Traffic Control/ Air Traffic Management System”, Journal of Air Traffic Control, Jan/Mar ‘94, pp. 8-15V.G. Afanasiev: “The business opportunities in Russia: the new Aeroflot - Russian international airlines”, presented at 2nd Annual Aerospace-Aviation Executive Symp., Arlington/VA,

Nov. ‘94, 5 ppF. Dörenberg, L. LaForge: “An Overview of AlliedSignal’s Avionics Development in the CIS“, IEEE AES Systems Magazine, Feb. ‘95, pp. 8-12.S.L. Pelton, K.D. Scarbrough: “Boeing systems engineering experiences from the 777 AIMS program”, presented at 14th AIAA/IEEE DASC, Boston/MA, Nov. 1995, 10 pp.D. Parry: “Electrical Load Management for the 777”, Avionics Magazine, Feb. ‘95, pp. 36-38Anon.: “Avionics on the Boeing 777, Part 1-11”, Airline Avionics, May ‘94 - June ‘95M.D.W. McIntyre, C.A. Gosset: “The Boeing 777 fault tolerant air data inertial reference system ”, Proc. 14th DASC, Boston/MA, Nov. ‘95, pp. 178-183G. Bartley: “Model 777 primary flight control system”, Boeing Airliner Magazine, Oct/Dec ‘94, pp. 7-17R.R. Hornish: “777 autopilot flight director system”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 151-156 C.J. Walter, R.M. Kieckhafer, A.M. Finn: “MAFT: a Multicomputer Architecture for Fault-Tolerance in Real-Time Control Systems”, Proc. IEEE Real Time Systems Symp., San

Diego/CA, Dec. ‘85, 8 pp. C.J. Walter: “MAFT: an architecture for reliable fly-by-wire flight control”, proc. 8th DASC, San Jose/CA, Oct. ‘88, pp. 415-421L. Lamport, R. Shostak, M. Pease: “The Byzantine Generals Problem”, ACM Trans. on Programming Languages & Systems, Vol. 4, No. 3, July ‘82, pp. 382-401M. Barborak, M. Malek, A. Dahbura: “The Consensus Problem in Fault-Tolerant Computing”, ACM Computing Surveys, Vol. 25, No. 2, June ‘93, pp. 171-220J.A. Donoghue: “Toward integrating safety”, Air Transport World, Nov. ‘95, pp. 98-99D. Carbaugh, S. Cooper: “Avoiding Controlled Flight Into Terrain”, Boeing Airliner, April-June ‘96, pp. 1-11M. Slater: “The microprocessor today”, IEEE Micro, Dec. 1996, pp. 32-44D. Hildebrand: “Memory protection in embedded systems”, Embedded Systems Programming, Dec. 1996, pp. 72-76D. Esler: “Trend monitoring comes of age”, Business & Commercial Aviation, July ‘95, pp. 70-75C.A. Shifrin: “Aviation safety takes center stage worldwide”, AW & ST, 4 Nov ‘96, pp. 46-48


M. Rodriguez, M. Stemig: “Evolution of embedded avionics operating systems”, presented at 14th AIAA/IEEE DASC, Boston/MA, Nov. 1995M. Tippins: “FMS Moving toward complete integration”, Professional Pilot, June 1993, pp. 48-52F.B. Murphy: “A perspective on the Autonomous Airplane operating in the Global Air Transportation System”, presented to ICCAIA, Everett/WA, March 1992, 13 slidesJ. Townsend: “Low-altitude wind shear, and its hazard to aviation”, Nat’l Academy, Washington/DC, 1983F. M.G. Doerenberg, A. Darwiche: "Application of the Bendix/King Multicomputer Architecture for Fault Tolerance in a Digital Fly-By-Wire Flight Control System," Proc.

MIDCON/IEEE Technical Conf., Dallas, TX, Aug.-Sept. 1988, pp. 267-272L.H. Harrison, P.J. Saraceni: "Certification Issues for Complex Digital Hardware," Proc. 13th DASC, Phoenix/AZ, November 1994, pp. 216-220V. Riley: "What avionics engineers should know about pilots and automation," Proc. AIAA/IEEE 14th DASC, Boston/MA, November 1995, pp. 252-257R.W. Morris: "Increasing Avionic BIT Coverage Increases False Alarms," SAE Communications in Reliability, Maintainability, and Supportability, Vol. 1, No. 2, July 1994, pp. 3-8A. Gerold: “The Federal Radionavigation Plan”, Avionics Magazine, May ‘96, pp. 34-35Anon.: “Enhanced situation awareness technology for retrofit and advanced cockpit design”, Proc. Human Behavior Conf. at AEROTECH ‘92, SAE Publ, No. SP-933, 191 pp.Anon.: “Industrial-strength formal specification techniques”, Proc. IEEE Workshop, Boca Raton/FL, April ‘95, IEEE Computer Society Press, 172 pp., ISBN 0-8186-7005-3Anon.: “Automated cockpits special report” Aviation Week & Space Technology, Part 1 (Jan. 30, ‘95, pp. 56-65), Part 2 (Feb. 6, ‘95, pp. 48-55)E.E. Rydell: “Avionics “backbone” interconnection for busing in the backplane: advantages of serial busing”, Proc. 13th DASC, Phoenix, AZ, Nov. 1994, pp. 17-22M. Rodriguez, M. Stemig: “Evolution of embedded avionics operating systems”, presented at DASC-95, Boston/MA, Nov. ‘95, 5 pp.P. Parry, C. Vincenti-Brown: “Window to the 21st century”, World Aerospace Development 1995, 41st Paris Airshow, Cornhill Publ. , pp. 27-33 , ISBN 1-85938-0409G. Stix: "Toward 'point One' - Trends in Semiconductor Manufacturing," Scientific American, February 1995, pp. 90-95G.D. Hutcheson, J.D. Hutcheson: "Technology and Economics in the Semiconductor Industry," Scientific American, January 1996, pp. 54-62C. Adams: “Emerging Databus Standards”, Avionics Magazine, March ‘96, pp. 18-25K. Hoyme, K. Driscoll: “SAFEbusTM”, Proc. 11th DASC, pp. 68-72A. Emmings: “Wire power”, British Airways World Engineering, Iss. 8, July/Aug. ‘95, pp. 40-43G. Derman: “Interconnects & Packaging - Part 1: Chip-Scale Packages”, EE Times, 26 Feb. ‘96, pp. 41,70-72T. DiStefano, R. Marrs: “Building on the surface-mount infrastructure”, EE Times, 26 Feb. ‘96, pp. 49S. Birch: “The hot issue of aerospace electronics”, SAE Aerospace Engineering, July ‘95, pp. 4-6J.A. Sparks: “High temperature electronics for aerospace applications”, proc. ERA Avionics Conf., London/UK, Nov./Dec. ‘94, pp. 8.2.1-8.2.5J.H. Mayer: “Pieces fall into place for MCMs”, Military & Aerospace Electronics, 20 March ‘96, pp. 20-22D. Maliniak: “Modular dc-dc converter sends power density soaring”, Electronic Design, Aug. 21 ‘95, pp. 59-63J. Sweder, et al.: “Compact, reliable 70-Watt X-band power module with greater than 30-percent PAE”Anon.: ”FED up with LCDs?”, Portable Design, March ‘96, pp. 20-25K. Sewel: “FED technology threatens LCD in flat-panel race”, Military & Aerospace Electronics, Dec. 1996, p. 19BCAG: "777 Application Specific Integrated Circuits (ASIC) Certification Guideline," Boeing Doc. 18W001; also: RTCA Paper No. 535-93/SC180-11, December 1993Honeywell Commercial Flight Systems: "ASIC Development and Verification Guidelines," Honeywell Spec. DS61232-01 Rev A, January 1993; also: RTCA Paper No. 536-93/SC180-12O. Port, Z. Schiller, R.W. King: “A smarter way to manufacture,” Business Week, April 30, 1990, pp. 110-117R. Dion: “Process improvement and the corporate balance sheet”, IEEE Software, Vol. 10, No. 4, July 1993, pp. 28-35

SAE 4761: Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment”, Dec. 1996ARINC 650: IMA Packaging and InterfacesARINC 652: Guidance for Avionics Software ManagementARINC 653: Standard Application Software Environment for IMAARINC 659: Backplane Data BusARINC 629: Multi-Transmitter Data BusARINC-754/755: (analog/digital MMR), ARINC-756 (GNLU)

Integrated and Modular Systems for Commercial Aviation · PDF fileIntegrated and Modular...

Documents

Transcript of Integrated and Modular Systems for Commercial Aviation · PDF fileIntegrated and Modular...