Integrated and Modular Systems for Commercial ... - Nonstop Systems

Integrated and Modular Systems 

for Commercial Aviation 

Frank M.G. Dörenberg D renberg 

AlliedSignal Commercial Avionics Systems 

Redmond, WA 

Presented at UCLA “Modular Avionics” short course 

February 3-7 1997 

phone: (206) 885-8489 885 8489 fax: (206) 885-2061 885 2061 e-mail: mail: :frank.doerenberg@alliedsignal.com

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 

for Commercial Aviation 

Frank M.G. Dörenberg renberg 

phone: (425) 836-4594 836 4594 e-mail: e mail: frank.doerenberg 

frank. doerenberg@usa usa.net .net ©1995-1997 F.M.G. Dörenberg

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 

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

2

Integrated and Modular Avionics 

• Introduction 

�� Why change avionics? 

• Integration 

• Modularization 

• Future ..... 


3

Aircraft 

Airframe 

Mfrs 

Avionics 

Mfrs 

Global aviation system 

- changes must be considered in overall system context- 

Crew 

Payload 

Airlines & 

Operators 

Integrated 

Aviation 

System 

Gov’t & 

Industry 

Agencies 

Airspace Sys., 

ATC/ATM 

Ground & Space 

Infrastructure 

Environment 

- many stakeholders, requirements, constraints, competition - 


4

Engine thrust 

Structure 

& Gear 

Computer/ 

Data links 

Cabin air 

press/temp 

Fuel Mgt 

Aircraft sub-systems 

Flight 

Control 

Phone 

& fax Cabin 

call/PA 

= req’d for ops in air transport system 

= req’d for cargo and pax comfort/well-being 

Electrical 

power 

Games 

& video 

Air Data 

Audio 

video 

Comm/Nav 

Surveillance 

Cabin 

lighting 

Cargo/bag 

handling 

Galleys & 

water/waste 


5

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, payback 

� seat-mile economics 

� serviceable and flyable with minimal maint. and 

flight crew training (inc. fleet commonality) 

� payload, range, route structures, fuel burn (weight & 

volume of equipment/wiring/installation/structure) 

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

cont’d → 


6


• Airline/Operators’ point of view (cont’d): 

� safety (e.g., CFIT, WX & Windshear Radar, TCAS) 

� reliability, dispatchability 

� deferred maint., reduced unscheduled maint. 

� improved BITE (fault isolation, MTBUR/MTBF) 

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

� increased crew & pax comfort 

� goal: on-time-arrival-rate = dispatchability-rate 

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

incompatibilities. 

cont’d → 


7


• 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 service 

instead of years later (esp. for early ETOPS) 

� to reduce the cost of future software mods 


8

Operators seek revenue enhancement 

•Value-added in the areas of: 

� operational efficiency 

� economic utility 

and above all 

� safety 

- 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. 1991 

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

ref.: Fitzsimmons, B.: “Better value from integrated avionics?” Interavia Aerospace World, Aug. 1993, pp. 32-36 

ref.: ICARUS Committee: “The dollars and sense of risk management and airline safety”, Flight Safety Digest, Dec. ‘94, pp. 1-6 


9

Airplane Operational Effectiveness → 

Wright Flyer 

Gains from avionics technology investments 

Individual non-avionic technologies 

• aerodynamics 

• flight controls 

•structures 

• propulsion 

Avionics technologies 

Info integration technologies 

1900 1950 2000 

- avionics is (growing) part of the equation - 

10 

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

Why change avionics? (cont’d) 

• Authorities: 

� ATC & ATM 

� ground- & space-based infrastructure 

� fed & int’l (de-)regulations 

� safety (e.g., TCAS, smoke det.) 

� environment 

• Avionics suppliers: 

� customer satisfaction, one-stop-shopping 

� cost reduction / profitability margins 

� technological leadership 

� strategic 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-24 

ref.: R. Ropelewski, M. Taverna: “What drives development of new avionics?”, Interavia, Dec. ‘94, pp. 14-18 & Jan. ‘95, pp. 17-18 

11 



• 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 pax 

target: $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 → 

12 



•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-24 

ref.: R. Ropelewski, M. Taverna: “What drives development of new avionics?”, Interavia, Dec. ‘94, pp. 14-18 & Jan. ‘95, pp. 17-18 

13 



• Air traffic reasons: 

� world/regional air traffic growth 

� productivity improvement: traffic 

volume, density, flow 

� maintain & enhance safety 

• Technical & technological reasons: 

� airframe or engine changes 

� obsolescence, new capabilities 

- system solutions to achieve conflict-free navigation while executing 

the best performance flight-plan, moderated by passenger comfort - 

14 


Avionics business 

• high-tech but low volume 

• typ. ½-life time frames: 

� airframe: 25 years 

� electronics: 2 years 

� data buses: 10-15 years 

� HOL: ? 

- aircraft life-cycle: initial development, production run, 

through a/c lifespan after last one delivered - 

15 


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 - 

16 



10 

Index 100 

≈ +5-6% p.a. 

Productivity 

DOC 

Revenue/Expense ratio 

Yield 

0 

1960 65 70 75 80 85 90 

- airline performance trends - 

ref.: Airline Business, January 1996, p. 29 

ref.: A. Smith: “Cost and benefits of implementing the new CNS/ATM systems”, ICAO Journal, Jan/Feb ‘96, pp. 12-15, 24 

≈ -2.5-2.9% p.a. 

17 


Scheduled pax (millions) 

1200 

1000 

800 

600 

400 

200 

Scheduled passenger traffic trends 

1990 

- World air traffic growth 

outpaces economic growth - 

1991 

1992 

1993 

≈ +5%/year 

1994 

1995 

ref.: Flight International, 3-9 January 1996, p. 27,28 

ref.: Boeing CAG Current Market Outlook 1995 

ref.: K. O’Toole: “Cycles in the sky”, Flight Int’l, 3-9 July 1996, p. 24 

ref.: “IATA raises five-year passenger forecast”, Flight Int’l, 6-12 Nov 1996, p. 8 

Domestic 

1996 

1997 

≈ +7%/year 

1998 

1999 

Σ =1.7 B 

International 

2000 

- world fleet is forecast to 

double over 20 years - 

(by 2015: ≈ 20,000 * > 50 seats ) 

* ex CIS & Baltic states 

≈ +6%/year 

2005 

18 


5000 

Pax-km (billions, log-scale) 

1000 

300 

Scheduled-passenger and freight traffic - steady growth 

Passengers 

Freight 

Most likely (5.5% p.a.) 

Most likely (7% p.a.) 

ACTUAL ICAO FORECAST 

1985 1995 2005 

- potential for airspace and airport congestion - 

500 

Tonne-km (billions, log-scale) 

100 

30 

19 



North America 

Intra Asia Pacific 

Intra Europe 

Trans Pacific 

North Atlantic 

Asia-Europe 

CIS Domestic 

No. Amer.-Lat. Amer. 

Europe-Lat. Amer. 

Europe-Africa 

Latin America 

CIS International 

source: Boeing CAG Current Market Outlook 1995 

1994 traffic 

Growth 1995-2014 

RPMs, billions 

0 200 400 600 800 1,000 

20 


Billions of 1995 US $ 

80 

60 

40 

20 

900 

800 

700 

600 

500 

400 

300 

200 

100 

0 

Commercial aircraft sector - on the rebound 

Source: The Boeing Co. 

Average annual new aircraft investments (world fleet) 

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

Air transport annual deliveries 

Other 

McDonnell Douglas 

Airbus 

Boeing 

Source: Lehman Bros. 

0 

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

ref.: A.L. Velocci: “Restraint, Airline health key to stable rebound”, AW&ST, Nov. 25 1996, pp. 36-38 

ref.: P. Sparaco: “Airbus plans increased production rate”, AW&ST, Nov. 15 1996, pp. 48-50 

Percentage retired 

Number of aircraft 

100 

75 

50 

25 

0 

1,000 

750 

500 

250 

0 

20 

Retirement of aircraft 

Source: GE Capital Aviation Services 

25 

Age in years 

30 35 

Source: GE Capital Aviation Services 

Serviceable a/c available for sale or lease 

1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 

21 


crew 

fuel maint. 

ownership 

Euro-regionals: ≈ 50% of DOC is beyond 

control of owner/operator (fees for 

landing /ATC/ground-handling + fuel) 

Direct Operating Cost 

12-15% 

ref.: P. Condom: “Is outsourcing the winning solution?”, Interavia Aerospace World, Aug. ‘93, pp. 34- 

36 

ref.: 1992 ATA study of U.S. airlines 

10-15% 

avionics & flight contr. 

1/3 

systems 

22 


24% 

23% 

23% 30% 

737-300 

($1834/hr) 

16% 31% 

28% 

747-200/300 

($7611/hr) 

25% 

25% 

40% 

25% 

A320 

($4530/hr) 

11% 

27% 

32% 

27% 

Direct Operating Cost 

30% 

36% 

737-400 

($1797/hr) 

20% 

17% 

31% 

747-400 

($6673/hr) 

17% 

45% 

($3802/hr) 

8% 

11% 

A300-600 

26% 

24% 

25% 26% 

737-500 

($1607/hr) 

20% 25% 

34% 

DC-10-30 

($4306/hr) 

25% 

36% 

25% 

25% 

14% 

L-1011-1/200 

($3799/hr) 

38% 

14% 

20% 28% 

Fokker-100 

($1661/hr) 

27% 

27% 

27% 

MD-80 

($1825/hr) 

ref.: Air Transport World, Jan-May 1995 

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

19% 

landing fees etc 

pax services, 

promo, 

ticketing/sales 

G&A 

29% 

4 

27% 

DC-9-30 

($1612/hr) 

12 

% 

33% 

27% 

MD-11 

($4530/hr) 

12 

% 

11% 

20% 

15% 

31% 

34% 

7 

11% 

27% 

Worldwide airlines 

avg costs (1993) 

fuel & oil 

crew 

maint. & o'haul 

ownership 

(insurance, 

possession,etc.) 

U.S. major carriers 

all items in U.S.$ 

per block hour 

year ending Sept. 31,'94 

23 


Aircraft 

Type/model 

B747-400 

B747-100 

L-1011 

DC-10-10 

A300-600 

MD-11 

DC-10-30 

B767-300ER 

B757-200 

B767-200ER 

A320-100/200 

B727-200 

B737-400 

MD-80 

B737-300 

DC-9-50 

B737-500 

B737-100/200 

DC-9-30 

F-100 

DC-9-10 

Aircraft operating statistics 

Number of 

Seats 

398 

390 

288 

281 

266 

254 

248 

221 

186 

185 

149 

148 

144 

141 

131 

124 

113 

112 

100 

97 

72 

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

Speed 

Airborne 

553 

520 

496 

492 

473 

524 

520 

493 

457 

483 

445 

430 

406 

422 

414 

369 

408 

387 

383 

366 

381 

Flight 

Length 

4,331 

3,060 

1,498 

1,493 

1,207 

3,459 

2,947 

2,285 

1,086 

2,031 

974 

686 

615 

696 

613 

320 

532 

437 

447 

409 

439 

all numbers are average 

Fuel 

gph 

3,356 

3,490 

2,384 

2,229 

1,938 

2,232 

2,612 

1,549 

1,004 

1,392 

771 

1,251 

775 

891 

748 

893 

708 

800 

798 

737 

740 

Operating 

Cost per hr 

$6,939 

5,396 

4,564 

4,261 

4,332 

4,570 

4,816 

3,251 

2,303 

3,012 

1,816 

2,222 

1,779 

1,793 

1,818 

1,901 

1,594 

1,757 

1,690 

1,681 

1,332 

24 


Big $ numbers 

life-time maintenance cost (ROM), example: 

ref.: Air Transport World, Jan-May 1995 

• maintenance ≈ $1200/block hour 

• airplane life-time ≈ 60 + k hours 

• maintenance-over-life ≈ $75 million 

- Boeing 747-400 - 

25 


Fact: 

Life Cycle Cost* (LCC) 

•inflation corrected price-tag of airplanes 

has increased over the years** 

•not completely offset by simultaneous 

reduction in DOC 

New systems & technology can only be 

justified if they: 

•take cost out of the airplane 

•reduce DOC 

•increase revenue 

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

** contrary to e.g. consumer electronics 

26 


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-thebox) 

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

27 


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.) 

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 

* mid ‘90s cost to airlines in Eu due to 

ATC delays est. at $1.9-2.5B p.a. 

28 


Average schedule deviation costs 

departure delays ($/hr) 

flight cancellation 

turn-back 

in-flight diversion 

ref.: BCAG 1993 Customer Cost Benefit Model 

- examples - 

B737 

$ 2k5 

$ 7k6 

$ 5k9 

$ 7k6 

B757 

$ 5k0 

$ 14k9 

$ 10k9 

$ 12k8 

B767 

$ 6k3 

$ 18k9 

$ 13k8 

$ 16k1 

B747-400 

$ 9k3 

$ 37k2 

$ 22k6 

$ 28k7 

29 


Boeing 777 Development Cost 

Systems 

Structures 

28 % 

47 % 

(engineering & labs) 

5 % 

7 % 

Aero 

6 % 

7 % 

Misc. 

Payloads 

Propulsion 

ref.: P. Gartz, “Systems Engineering,” tutorial at 13th DASC, Phoenix /AZ, Oct. ‘94, & 14th DASC, Boston/MA, Nov. ‘95 

ref.: C. Spitzer, “Digital Avionics - an International Perspective,” IEEE AES Magazine, Vol. 27, No. 1, Jan. ‘92, pp. 44-45 

Dev. 

+ V&V 

Development 

Hardware 

≈ 30% 

½ ½ 

V&V 

Software 

≈ 70% 

30 


Integrated Modular Avionics Architectures 

- more than just a “cabinet solution” - 



• Standardization 

- all are key attributes of partitioning - 

ref: Robinson, T.H., Farmer, R., Trujillo, E.: “Integrated Processing,” presented at 14th DASC, Boston/MA, Nov. 1995 

ref.: 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. 

31 


Dependability Taxonomy 

Attributes Means Impairments 

Safety 

Reliability 

Dispatchability 

Maintainability 

Integrity 

Dependability 

Fault avoidance 

Fault tolerance 

Fault removal 

Fault forecasting 

Faults 

Errors 

Failures 

- dependability: degree of justifyable reliance that can placed 

on 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-20 

ref.: F.J. Redmill (ed.): “Dependability of critical computer systems - 1”, 1988, 292 pp., Elsevier Publ., ISBN 1-85166-203-0 

ref.: 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 

32 


Fault Avoidance 

- prevent (by construction) faults from entering into, developing in, 

or propagating through the system - 

• 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 - 

33 


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-40 

ref.: D.P. Siewiorek, R.S. Swarz (eds.): “Reliable Computer Systems”, 2nd ed., Digital Press, ‘92, 908 pp., ISBN 1-55558-075-0 

ref.: M.R. Lyu (ed.): “Software fault tolerance”, Wiley & Sons, ‘95, 337 pp., ISBN 0-471-95068-8 

ref.: F.J. Redmill: “Dependability of critical computer systems - 1”, ITP Publ., ‘88, 292 pp., ISBN 1-85166-203-0 

ref.: B.W. Johnson: “Design and Analysis of fault tolerant systems”, Addison-Wesley, ‘89, 584 pp., ISBN 0-201-07570-9 

ref.: “25th Anniversary Compendium of Papers from Symposium on Fault Tolerant Computing”, IEEE Comp. Society Press, ‘96, 300 pp., ISBN 0-8186-7150-5 

ref.: 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

Fault Tolerance Taxonomy 

Fault Tolerance 

Redundancy 

• physical 

• temporal 

• data 

Redundancy Management 

Static (Fault Masking) Dynamic 

No fault reaction: 

• no fault detection 

• no reconfiguration 

Fault detection 

Examples of techniques: Examples of techniques: 

•interwoven 

logic 

• comparison (cross, voter, wrap-around) 

•hardwired 

multiple hardware • reasonableness check (rate, range, cross) 

redundancy 

• task execution monitor (a.k.a. Watch Dog) 

•error 

correcting code • checksum, parity, error detection code 

•majority 

voting (N-modular • diagnostic and built-in tests 

redundancy) 

Active 

• Similar 

• Dissimilar 

• adaptive voting & signal select 

• dynamic task reallocation 

• graceful degradation 

• n-parallel, k-out-of-n 

• s/w recovery (retry, rollback) 

• operational-mode switching 

Fault isolation & 

Reconfiguration 

Standby 

Examples of techniques: Examples of techniques: 

Hybrid 

Example of techniques: 

• pooled spares 

switch-in backup spare(s) 

• operating (hot, shadow) 

• non-operating (cold, flexed) 

35 


Fault Classifications 

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

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

Criteria Fault type 

Activity 

Duration 

Perception 

Cause 

Intent 

Count 

Time (multiple faults) 

Cause (multiple faults) 

Latent vs. active 

Transient vs. permanent 

Symmetric vs. asymmetric 

Random vs. generic 

Benign vs. malicious 

Single vs. multiple 

(Near-) Coincident vs. Distinct 

Independent vs. common-mode 

“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-6287 

36 


Redundancy 

• Attributes: 

� form (physical, temporal, performance, data, 

analytical) 

� similarity/diversity* 

� level of replication 

� physical distribution within a/c 

� allocation along end-to-end path 

� configuration (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 

37 


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 flown 

� avionics mfr needs this too: sells fewer spares ⇒ (much) less profit 

- 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-8 

ref.: M. Pecht (ed.): “Product reliability, maintainability. and supportability handbook”, CRC Press, ‘95, 413 pp., ISBN 0-8493-9457-0 

ref.: M. Doring: “Measuring the cost of dependability”, Boeing Airliner Magazine, Jul-Sep ‘94, pp. 21-25 

* unit pulls on maintenance alert only, not 

to rotate/canibalize/swap within a fleet 

38 


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 chain 

� share 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) - 

39 


1 

System 

Reliability 

λunit = 5x10-5 Example: 

/h 

MTBFunit = 20,000 hrs 

N-Parallel Redundancy 

0.5 

0 

20k 

(=MTBF) 

40k 

Operating 

time (hrs) 100k 

15 

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

10 

5 

Number of redundant units 

3 

0.5 

1 


1 

System 

Reliability 

λunit = 5x10-5 Example: 

/h 

MTBFunit = 20,000 hrs 

N-Parallel Redundancy 

0.5 

0 

20k 

(=MTBF) 

40k 

Operating 

time (hrs) 100k 

15 

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

10 

5 

60k 

Number of redundant units 

3 

Desired 

region 

0.5 

100k 

1 

0.9 - 0.95 


MTTF n-parallel ∝ ln(n) x MTTF unit 

= 

MTTF n 

MTTF 1 

MTTF as function of redundancy level 

3 

2 

1 

from n=1 2 

practical limit 

1 5 10 15 0 

- diminishing returns - 

(curves do not account for 

rel. penalty of complexity) 

Number of 

Parallel units 

0.5 

=∆ MTTF 

42 


Note: log-log scale 

F (t) 

2-out-of-N 

(t) 

F 2-out-of-2 

Parallel redundancy for system reliability 

0 

10 = 1 

-1 

10 

-2 

10 

-3 

10 

-4 

10 

-5 

10 

-6 

10 

-7 

10 

N=2 

N=4 

N=3 

F2-out-of-2 = 1 

F 

2-out-of-2 

0.001 0.01 0.1 1.0 10 

- adding redundancy is only effective for t

Redundancy 

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

1.0 

R config(t) 

0.5 

1/e 

0 

dual 

dual-dual 

quad 

t =MTTFunit 

1 

dual-triplex 

triplex 

dual-quad 

2 

- fault-tolerant configs exhibit 

s-curve reliability - 

t 

MTTF unit 

3 

= MTTF 

cube 

4-parallel 

3-parallel 

2-parallel 

simplex 

44 


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

MOTHER GOOSE & GRIMM 

45 


1.0 

R config(t) 

0.5 

1/e 

0 

dual 

dual-dual 

quad 

t =MTTFunit 

Redundancy 

1 

dual-triplex 

triplex 

dual-quad 

2 

- redundancy for fault-tolerance 

and extended system reliability - 

region of 

practical use 

t 

MTTF unit 

3 

= MTTF 

cube 

4-parallel 

3-parallel 

2-parallel 

simplex 

46 


1.0 

Rconfig(t) 

0.9 

0.8 

dual 

Redundancy 

2-p 

simplex 

triplex 

dual-dual 

quad 

3-p 

dual-triple 

cube 

4-p 

dual-quad 

0.5 1.0 

MTTFunit 

- region of practical use, enlarged - 

t 

47 


Relative MTTF of various configurations 

Simplex 

Dual 

Triplex 

Quad 

Dual-Dual 

Dual-Triplex 

Dual-Quad 

Triple-Dual 

Quad-Dual 

Triple-Triple 

2-Parallel 

3-Parallel 

4-Parallel 

Cube 

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

48 


Simplex 

Dual 

Triplex 

Quad 

Dual-Dual 

Dual-Triplex 

Dual-Quad 

Triple-Dual 

Quad-Dual 

Triple-Triple 

2-Parallel 

3-Parallel 

4-Parallel 

Cube 

Mission times of several configurations 

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

49 


note: output wraparounds not shown 

“Cube” configuration concept 

λ 1 λ 1 λ 1 λ b 

λ a λ a λ a 

λ b 

λ c λ c λ c 

3-parallel “cube” 

increased number of 

paths through the system 

λ b 

λ a 

λ b 

λ a 

λ c λ c λ c 

“optimized cube” 

if no single-thread ops., then 

don’t need 3 output modules 

- 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- 

λ b 

λ b 

50 


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) − 

51 


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 accuracy 

� reduce NFF/CND/RETOK* from 50% to < 10% 

• organizations, people 

• entire aviation system 

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 

* ATA est. NFF cost to US airline 

industry ≈ $100M p.a., avg $800 per 

removal (labor, shipping, sparing) 

52 


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 & compatibility 

� to: standardizing on 3 quite different approach 

aids (ILS, MLS, GNSS*) 

� so: CAAs, airports, operators free to choose one 

or more 

� and: world aviation authorities should promote 

the use of Multi-Mode Receivers (MMRs) or 

equivalent avionics 

* ICAO: GNSS > GPS (e.g., GNS+GLONASS, 

to ensure complete redundancy, esp. in landing ops.) 

ref.: W. Reynish: “Three systems, One standard?”, Avionics Magazine, Sept. ‘95, pp. 26-28 

ref.: D. Hughes: “USAF, GEC-Marconi test ILS/MLS/GPS receiver”, AW&ST, Dec. 4 ‘95, pp. 96 

ref.: R.S. Prill, R. Minarik: “Programmable digital radio common module prototypr”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 563-567 

53 

ref.: ARINC-754/755 (analog/digital MMR), ARINC-756 (GNLU) 


LRUs 

Integration trend 

FMGD 

System 

On 

Chip 

1970s 1980s 1990s 2000-2010 

-2 

-4 

-5 

λ ~10 λ ~10 

total 

total 

λ ~ 2x10 

total 

λ total 

point-to-point analog 

interconnect 

single-thread systems 

ARINC-429 digital 

interconnect 

single-thread LRUs 

ARINC-629 digital data 

bus between LRUs 

ARINC-659 backplane 

bus between LRMs 

fault tolerant LRUs 

high-speed fiber optic 

comm. between systems 

fault tolerant cards 

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

ref: BCAC/J. Shaw 

~10 

-7 

54 


Integration issues 

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

• airline: 

� no more option to pick favorite supplier for each federated LRU 

� but 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 

55 


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’s 

� partitioning must be part of architecture and independent of application 

software 

� increased importance of FMEA, FHA, etc. 

• mixed levels of criticality: certify at highest level, or certify the 

partitioning 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) 

56 


Fault Tolerance for Safety, Reliability, 

Larson 

NO unpleasant surprises! 

Dispatchability: 

57 


FAA/JAA Hazard Severity Classification 

Catastrophic 

Hazardous / 

Severe-Major 

Major 

Minor 

* 

Failure 

Condition 

Classification 

No Effect 

FAR /JAR 

25-1309 

AC25.1309-1A 

Effect of failure condition on 

aircraft and occupants 

• Prevents continued safe flight and landing 

• Loss of aircraft 

• Multiple deaths 

• Large reduction in safety margins or functional capabilities 

• Difficult for crew to cope with adverse operating conditions, and 

cannot be relied upon to perform tasks accurately & completely 

• Some passengers seriously injured (potentially fatal) 

• Significant reduction in safety margins or functional capabilities 

• Significant increase in crew workload or conditions impairing 

crew efficiency 

• Some passengers injured 

• Slight reduction of safety margins or functional capabilities 

• Slight increase in crew workload, well within capabilities 

• Operational limitations, diversions, flight plan changes 

• Inconvenience to passengers 

• No effect on operational capability of aircraft 

• No increase in crew workload 

• Concern, nuisance 

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

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

58 


Quant. 

Prob. 

1 

10-3 

10-5 

10-7 

10-9 

0 

FAA/JAA Probability Ranges 

JAR 

Qualitative 

Frequent 

Reasonably 

Probable 

Remote 

Extremely 

Remote 

FAR 

Qualitative 

Probable 

Improbable 

Extremely Improbable 

AMJ 25.1309 

* * 

AC 25.1309-1A 

- qualitative and quantitative - 

Qualitative Probability 

several times during operational 

life of each airplane 

occasionally during total 

operational life of all 

airplanes of particular type 

not expected to occur in entire 

fleet operational life 

* FAR & JAR are being harmonized 

59 


Hazard 

Probability 

Probable 

Improbable 

Extremely 

Improbable 

FAA/JAA Criticality Index 

Unacceptable 

Unacceptable 

Acceptable 

unless single failure 

Critical 

(A) 

failure contributes to, or 

causes a failure condition 

which would prevent 

continued safe flight and 

landing 

Unacceptable 

Conditionally 

Acceptable 

Acceptable 

unless single failure 

Essential (B) 

failure contributes to, or 

causes a failure condition 

which would significantly 

impact airplane safety or 

crew ability to cope with 

adverse operating condit. 

Acceptable 

Acceptable 

Acceptable 

Non-Essential 

(C) 

failure would not 

contribute 

to, or causes a failure 

condition which would 

significantly impact airplane 

safety or crew ability to 

cope with adverse condit. 

- allowed combinations of hazard severity and probability - 

Equipment 

Category 

60 


Failure System 

Condition Design 

Assurance 

Classification Level 

Catastrophic 

Hazardous / 

Severe-Major 

Major 

Minor 

No Effect 

FAR /JAR 

AC/AMJ 

25.1309 

FAA/JAA Hazard Index 

A 

B 

C 

D 

E 

DO-178B 

DO-180 

ARP 4754 

Probability 

Objective 

extremely 

improbable 

extremely 

remote 

remote 

none 

none 

Failure Objectives 

Fail-safe Single-point 

Failures 

required 

may be 

required 

may be 

required 

not 

required 

not 

required 

precluded 

no 

requirement 

no 

requirement 

no 

requirement 

no 

requirement 

- hazard: potential/existing unplanned condition 

that can result in death, injury, illness, damage, loss - 

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

61 


“Don’t worry! 

Nothing can go wrong .... 

go wrong..... 

go wrong....” 

Hal, 2001: A Space Odyssey 

62 


Electro-Magnetic Interference (EMI) - sources 

LIGHTNING 

RADIO 

FREQUENCY 

HUMAN 

ELECTRO- 

STATIC 

DISCHARGE 

ELECTRONIC 

UNIT & WIRING 

Aircraft radios 

AM/FM radio 

TV stations 

Ground radar 

POWER DISTURBANCE 

ref.: Clarke, C.A., Larsen, W.A.: “Aircraft Electromagnetic Compatibility”, DOT/FAA/CT-86/40, June 1987 

ref.: Shooman, L.M.: “A study of occurrence rates of EMI to aircraft with a focus on HIRF”, Proc. DASC-93, pp. 191-194 

ref.: RTCA Document DO-233 “Portable Electronic Devices Carried On Board Aircraft, Aug. ‘96 

Graphics adapted from: J.A. Schofield: “European standards shine spotlight on EMI”, Design News, 9-25-1995, pp. 58-60 

PERSONAL 

ELECTRONIC 

DEVICES 

cell phones 

laptop PCs 

CD players 

games 

CONDUCTED EMISSIONS 

Aircraft power 400 Hz E/M 

Bus switching 

Inductive load switching 

Switching regulators 

Computer clock & data 

Analog signal coupling 

RADIATED 

EMISSIONS 

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

63 


EMC: Electro-Magnetic Compatibility 

• increased EMI-susceptibility of electronic devices: 

� integration: higher chip density; (deep) sub-micron feature sizes 

� reduced operating voltages 

� lower 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 lines 

� but 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: increasing 

amounts 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. 

II 

ref.:G.L. Fuller: “Understanding HIRF - High Intensity Radiated Fields”, Avionics Comm. Publ., Leesburg/VA, ‘95, 123 pp., ISBN 1-885544-05-7 

64 

ref.: 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 


Req's for Fault Avoidance 

(incl. Containment) 

and Robustness 

Requirements Taxonomy 

• Mission 

• Safety 

• Reliability 

• Dispatchability 

Requirements 

• Availability 

• Functionality 

• Performance 

• Operational 

Req's for Fault Tolerance 

Req's for Redundancy 

• Fault masking 

• Fault detection 

• Fault isolation 

• Fault recovery 

• etc. 

• Maintenance 

• Cost 

• Certificability 

• etc. 

Req's for Redundancy Management 

Req's for Integrity Checks 

65 


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 - 

66 


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: 

PL = exp(-N) .Σ 

1/k N 

m! 

– 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) 

kit 

- standardization ~ commonality - 

NS 

m=0 

m 

67 


Hardware 

Resources 

Processor core 

Memory 

Common I/O * 

BIT hardware 

Power supply 

Chassis 

Unique I/O * 

Typical stand-alone LRU 

* with EMI protection 

Software 

Resources 

Operating 

System 

I/O processing 

and monitoring 

BIT and Maint. 

functions 

Application 

Unique BIT 

ref.: M.J. Morgan: “Integrated Modular Avionics for Next-Generation Commercial Aircraft”, IEEE AES Systems Magazine, Aug. ‘91, pp. 9-12 

ref.: D. Hart: “Integrated Modular Avionics - Part I - V”, Avionics, May-Nov. 1991 

Common 

Unique 

68 


Resources 

Hardware Software 

Standard 

and 

common 

functions 

Unique 

functions 

Integration of multiple LRUs 



common 

functions 

Unique 

functions 

LRU-2 

LRU-1 

INTEGRATION 

LRU-3 

Hardware 

Resources 

Processor Core 

Memory 

Shared I/O * 

BIT hardware 

Power Supply 

Chassis 

Unique I/O * 

Unique I/O * 

Unique I/O * 

Software 

Resources 

Operating 

System 


& monitoring 


functions 

Application-1 

Unique BIT 

Application-2 

Unique BIT 

Application-3 

Unique BIT 

69 


Resources 

Hardware Software 



common 

functions 

Unique 

functions 

Integration of multiple LRUs 



common 

functions 

Unique 

functions 

LRU-2 

LRU-1 

INTEGRATION 

LRU-3 

standardize 

via end-to-end digitalization 

from sensors to actuators 

Hardware 

Resources 

Processor Core 

Memory 

Shared I/O * 

BIT hardware 

Power Supply 

Chassis 

Unique I/O * 

Unique I/O * 

Unique I/O * 

Software 

Resources 

Operating 

System 


& monitoring 


functions 

Application-1 

Unique BIT 

Application-2 

Unique BIT 

Application-3 

Unique BIT 

70 


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 ends 

� communication s/w at both ends 

71 



• LRU integration reduces overlap/duplication 

of h/w and s/w functions: 

� processor core 

� I/O (un)formatting 

� input signal monitoring & selection 

� parameter derivation 

� hardware monitoring 

� EMI/Lightning protection 

� power supply 

� faul reporting, maintenance, BIT 

72 


O/S 

I/O 

Maint. 

BIT 

Appl. 

Total 

CPU 

I/O 

Power 

Bus 

Chass. 

Total 

Effect of integrating additional functions - exercise 

Federated Integrated 

5% 

20% 

10% 

20% 

45% 

100% 

15% 

20% 

10% 

30% 

25% 

100% 

-- - ≈ + ++ 

-- - ≈ + ++ 

IMA enclosure + 1 st application 

Rel. hardware cost Rel. software complexity 

O/S 

I/O 

Maint. 

BIT 

Appl. 

Total 

CPU 

I/O 

Power 

Bus 

Chass. 

Total 


5% 

20% 

10% 

20% 

45% 

100% 

15% 

20% 

10% 

30% 

25% 

100% 

-- - ≈ + ++ 

-- - ≈ + ++ 

Each additional application 


73 


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

O/S 

I/O 

Maint. 

BIT 

Appl. 

Total 

CPU 

I/O 

Power 

Bus 

Chass. 

Total 

source: BCAG (adapted) 


5% 

20% 

10% 

20% 

45% 

100% 

15% 

20% 

10% 

30% 

25% 

100% 

+50% 

same 

+30% 

same 

same 

+2/3 

same 

double 

double 

+20% 

7% 

20% 

13% 

25% 

45% 

110% 

25% 

20% 

20% 

60% 

30% 

155% 


Rel. software complexity 

Rel. hardware cost 

O/S 

I/O 

Maint. 

BIT 

Appl. 

Total 

CPU 

I/O 

Power 

Bus 

Chass. 

Total 


5% 

20% 

10% 

20% 

45% 

100% 

15% 

20% 

10% 

30% 

25% 

100% 

half 

half 

same 

-1/4 

half 

-80% 

10% 

5% 

45% 

60% 

15% 

5% 

5% 

25% 



74 


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




100% 

155% 


100% 

110% 





100% 

100% 

- the more you integrate, the “better” - 

assumes integration of related 

functions of equal size & 

complexity; 25% error margin 

25% 


60% 



75 



functions with equal size/complexity 

Normalized softwar esize → 

10 

8 

6 

4 

2 

1 


Advantages of integrating additional functions 

Federated 

1 2 4 6 8 10 

Number of system functions → 

25% error bar 


- not effective if only integrating 2 or 3 functions - 

Normalized hardware cost → 

10 

8 

6 

4 

2 

1 

Federated 


1 2 4 6 8 10 


25% error bar 

76 



functions with equal size/complexity 

Normalized softwar esize → 

10 

8 

6 

4 

2 

1 


1 2 4 6 8 10 


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

Well…….. 

Normalized hardware cost → 

10 

8 

6 

4 

2 

1 

⌠ 

⌡ 

Federated 


1 2 4 6 8 10 


Cost of cert., partitioning,config mgt 

77 



• Modularization reduces duplication of 

product development effort: 

� specification 

� design 

� integration and test 

� qualification 

� V&V, certification 

� part numbers 

� time-to-market 

� program risk 

� $$$ 

78 



• 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/knowledge 

� NFF/CND/RETOK, MTBUR/MTBF 

typically at 50% 

� FANS (com/nav/surveillance) 

79 


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 1981 

80 

ref.: 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 


German “WW II” radios 

• Modules: 

� die-cast Alu-Mg alloy module* for each stage 

� completely enclosed & shielded, with internally 

shielded compartments 

� generously applied decoupling (fault avoidance) 

� mechanically & electrically very stable 

� easily installed/removed w. 90° lock-screws (maint.) 

� simple (manufacturability: strategically distributed, no high skills) 

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

* from mid-1943 on, only Goering’s Luftwaffe got Alu; 

Army/Navy got Zn alloy 

81 



• Chassis and “Backplane”: 

� modules plug into chassis 

� motherboard / backplane module 

(E52 “Köln” receiver, 1943) 

� 3-D arrangement 

� assy slides into sturdy (!) cabinet 

82 



• 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 - 

83 


• BIT: 


� switchable meter for V anode &I anode of each 

radio stage, and for filament voltage 

� noise generator to measure RX sensitivity 

� pass/fail, minimum servicability markings 

- simple line maintenance- 

84 


Modular Electronics: Not a New Concept! 

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

Modular 

construction 

Lorenz E 10 aK 

(11x RV12P2000) 

85 



- “backplane module” Bu 3 from Telefunken E 52 “Köln” - 

(1939-1945) 


86 



- “backplane module” Bu 3 from Telefunken E 52 “Köln” - 

(1939-1945) 


87 



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

Telefunken 

E 52a 

“Köln” 

88 


IMA - Integrated Modular Avionics 

LRUs 

- the basic idea - 

LRMs 

89 


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 

90 


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-concentrators 

� standard computational module 

� integration only of power-supplies (shared) 

� no functional integration (LRUs mapped 1:1) 

� no new interactions (certification!) 

� ARINC-429 links between LRMs retained 

� ARINC-429 links between “cabinets” 

91 


IMA Level-2 & -3 

• Level-2: databus integration and partitioning 

� non-A429 inter-LRM communication 

� broadcast databus 

� separation of application s/w and OS 

� standard OS (facilitates aps. s/w modularity) 

• Level-3: all digital, global databuses 

� fully digital I/O at cabinet level, possibly with 

external data concentrators 

� data gateway modules to global bus networks 

� remote electronics: digitization close(r) to 

sensors & actuators 

92 


IMA Level-4 & -5 

• Level-4: functional integration at LRM level 

� multi-function computational LRMs 

� more functions integrated (toward supra-function IMA) 

� strict partitioning 

� standard interfaces (towards F 3 I) 

� improved BIT 

� fault tolerance 

• Level-5: dynamic task allocation & reconfig. 

� flexibility 

� more efficient h/w resource utilization 

� certification 

93 


IMA cost indicators and prediction 

• LCC cost drivers (RC & NRC): 

� design & development cost & risk 

� hardware, mechanical, data/signal 

interconnects, power interconnects 

� use of standard components, OS, 

� complexity 

� certification aspects 

� re-useability (future savings) 

� weight/size/power/cooling 

� installation 

� maintenance, support (NFF, spares, rel., org.) 

� etc. 

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

94 


Major Areas of Systems Integration 

Communication 

& Navigation 

“Safety” Systems 

Flight & Propulsion 

Control 

VMS 

Utility Systems 

Pax Services* *Entertainment, 

Info, Telecom, 

Sales, Banking, etc. 

Flying: Aviate, Navigate, Communicate 

(and have some fun ...) 

95 


ATC/ATM 

FMS 

Functional Integration 

AT FADEC 

AP/AL 

FD 

FBW 

Sec. FC 

FBW 

Prim. FC 

SERVOS 

SERVOS 

- inner & outer control loops - 

96 


ATC/ATM 

FMS 


AT FADEC 

AP/AL 

FD 

FBW 

Sec. FC 

FBW 

Prim. FC 

SERVOS 

SERVOS 

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

97 


ATC/ATM 

FMS 


AT FADEC 

AP/AL 

FD 

FBW 

Sec. FC 

FBW 

Prim. FC 

SERVOS 

SERVOS 


98 


ATC/ATM 

FMS 


AT FADEC 

AP/AL 

FD 

FBW 

Sec. FC 

FBW 

Prim. FC 

SERVOS 

SERVOS 


99 


Integration of CatIII Autoflight Computers 

A300 

N1 Limit 

Auto Throttle 

Test Computer 

Pitch Trim 

Yaw Damper 

Logic Computer 

Longitudinal 

Computer 

Lateral 

Computer 

x1 

x1 

x2 

x2 

x2 

x2 

x2 

x2 

A310 

A300-600 

TCC 

FMC 

FAC 

FCC 

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

x1 

x2 

x2 

x2 

Airbus AFCS example: 

1 analog and 3 digital generations 

A320 

FAC 

FMGC 

x2 

A330/340 

x2 FMGEC x2 

14 7 4 2 

100 


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-2 

ref.: Hughes, D., Dornheim, M.A.: “United DC-10 Crashes in Sioux City, Iowa,” Aviation Week & Space Technology, July 24, 1989, pp. 96-97 

ref.: Dornheim, M.A.: "Throttles land "disabled" jet," Aviation Week & Space Technology, September 4, 1995, pp. 26-27 

ref.: 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-56 

ref.: Kolano, E.: “Fly by fire”, Flight International, 20 Dec. ‘95, pp. 26-29 

ref.: Norris, G.: “Boeing may use propulsion control on 747-500/600X”, Flight Int’l, 2-8 Oct. 1996, p. 4 

ref.: “Engine nozzle design - a variable feast?”, editorial in Aircraft Technology Engineering & Maintenance, Oct./Nov. 1995, pp. 10-11 

101 


Modular Flight Control & Guidance Computer 

FMGC 

FMC FGC 

A320 "baseline" 

ELAC 

SEC 

FAC 

SFCC 

FCDC 

FMC 

Flight Mgt 

All Airbus LRUs: dual internal, dissimilar s/w 

A330/340: 3x FCPC, 2x FCSP, replacing ELACs & SECs 

integration 

"50-100 Pax", high-end BizAv 

FC/FG 

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 

FCGC 

102 



FMGC 

FMC 

Autoflight 

Σ 52 MCU 

FGC 

Flight Ctrl: 

Σ 50 MCU 

ELAC 

SEC 

FAC 

SFCC 

FCDC 

FC/FG total: 

11 LRUs 

= 24 lanes, incl. 20 PSUs 

= 50 MCU volume 

FMC 

Flight Mgt: 

Σ 12 MCU 

modular 

integration 

FCGC 

FC/FG total: 

2 cabinets 

= 12 LRMs, 4 PSMs 

= 18 MCU volume 

103 



BGT Bodenseewerk 

Gerätetechnik GmbH 

Integrated flight control & guidance functions: 

• 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 

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/2501 

ref.: D. McRuer, I. Ashkenas, D. Graham: “Aircraft dynamics and automatic control”, Princeton Univ. Press, ‘73, 784 pp., ISBN 0-691-08083-6 

ref.: J. Roskam: “Airplane flight dynamic and automatic flight controls - Part 1 & 2”, Roskam A&E Corp., 1388 pp., LoC Card no. 78-31382 

ref.: R.J. Bleeg: “Commercial jet transport fly-by-wire architecture consideration”, Proc. 8th DASC, San Jose/CA, Oct. ‘88, pp. 399-406 

104 



Current FCGC-program development status: 

• 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 



105 


photo: courtesy 

VFW-614 

Returned to service 1Q96 as test-bed for the BGT/DASA EFCS Program 

106 



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 



107 



• 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 structure 

� resource sharing, multi-use I/O hardware 

� no single-thread operation → reduced output h/w redundancy 

� graceful 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: 

108 



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-module 

� A650 cabinet form factor, shorter LRMs 



- all modules are dual → fail-passive - 

109 



2x CPM 

(identical) 

X-puter + 

PowerPC 

4x IOM 

PowerPC + 

GP µP 



FCGC (x2) 

FC FG 

(FC) 

A A B B 

- FCGC internal architecture - 

ref.: R. Reichel: “Modular flight control and guidance computer”, 

Proc. 6th ERA Avionics Conf., London/UK, Dec. ‘92, 9 pp. 

110 


FCGC redundancy management - examples 

FC FG 

(FC) 

A A B B 

Fault Free 



FC FG 

(FC) 

A A B B 

A A B B 

FG 

(FC) 

FC FG 

(FC) 

A A B B 

- elevator control reconfiguration in response to module failures - 

- CPM failure - 

111 



FG 

(FC) 

FC FG 

(FC) 

A A B B A A B B A A B B A A B B 



FG 

(FC) 

FC FG 

(FC) 


- CPM + IOM failure - 

112 



A A B B 

FG 

(FC) 



FC FG 

(FC) 

A A B B 

A A B B 

FG 

(FC) 

A A B B 


- CPM + IOM + CPM failure - 

FG 

(FC) 

113 


lliedSignal 

A E R O S P A C E 



• Why change avionics? 



�� AlliedSignal programs 

• Future .....

lliedSignal 


AlliedSignal Programs 

• Integrated Cockpit Avionics 

• Integrated Hazard Avoidance System 

• Integrated Utilities System

lliedSignal 


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 Moscow 

� ARIA JV since 3Q92 

� ARIA JV office in Moscow since 4Q93 

• first program: Beriev BE-200 

� amphibious multi-role jet aircraft 

� primary role: fire fighting (12 m 3 )

lliedSignal 


Beriev BE-200: Russian multi-role amphib

Business Partner 

Design Bureaux 

Production Plants 

Airlines 

Private Operators 

lliedSignal 


CIS Aviation Industry 

- business environment as seen by AlliedSignal - 

Issues Positives 

Negatives 

• 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-15 

ref.: 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.

lliedSignal 


Kiev 

•AN 

Taganrog 

•BE 

GMT + 3 h 

Moscow 

•AS/ARIA 

• YAK 

•TU 

•IL 

• NIIAO 

Saratov 

• YAK mfg 

CIS Aviation Industry 

Kazan 

•TU mfg 

Novosibirsk 

• AN mfg 

design bureau 

Note: map shows CIS + Ukraine 

Irkutsk 

•BE mfg 

• Beta Air 

airframe production facility

lliedSignal 


Time from 1 st Flight to Certification 

USA Europe CIS 

B-737-200 8 

B-737-300 9 

B-737-400 7 

B-737-500 10 

B-747 10 

B-747-400 9 

B-757 10 

B-767 10 

B-777 10 

DC-10 11 

MD-80 10 

MD-11 10 

Average 10 mo. 

A-300 17 

A-310 11 

A-320 12 

A-330 17 

A-340 11 


BAe-41 14 

BAe-125 12 

BAe-146 20 


Falcon-50 27 

Falcon-900 18 


IL-86 48 

IL-96 51 

IL-114 57-69 

TU-154 40 

TU-204 60 

Yak-42 66 

Average 55 mo.

AlliedSignal 

h/w 

AlliedSignal 

h/w + core s/w 

AlliedSignal 

OTS 

from 

RMU-2 

to 

Displays 

lliedSignal 


cp 

to I/O-3 

ARIA-200 system architecture 

WX-RDR PFD ND EICAS EICAS ND PFD 

brightness 

I/O 

2 OM 

I/O 

AP 

AP 

PS FW DC + PS 

PS VS 

I/O I/O 

+ 

DC FW PS 

1 

AT 

AT 3 4 

Cabinet nr. 1 to Flt Ctl 

Cabinet nr. 2 

VHF ADF 

ILS MLS 

TCAS 

opt. 

Sensors 

ADC-1 AHRS-1 

RA 

to 

IOM-2/4 

Display 

System 

6"x8" 

AM-LCD's 

VOR 

DME 

TACAN 

opt. 

source sel. EFIS cp EICAS cp FC cp 

source sel. 

from A/C Systems 

XPDR 

HF 

opt. 

Flight & Radio Management 

cp 

cp 

to CNS-2 to CNS-1 

to CNS-1 RMU-1 

RMU-2 

to CNS-2 

FMS/GPS-1 FMS/GPS-2 

to/from 

Engine Ctl 

to IOM-1/2/3/4 

to FSM-1/2 

cp 

DATA 

LOADER 

(portable) 

cp 

cp 

to Audio 

System 

opt. 

opt. 

opt. 

ACARS 

XPDR 

HF 

from 

A/C Systems 

CNS suite nr. 1 CNS suite nr. 2 

VOR ADF VHF 

RA 

to 

IOM-1/3 

Alt 

+ 

IAS 

DME 

ADI 

RMI 

Stdby Instr. 

Sensors 

AHRS-2 

ADC-2 

to I/O-2 

ILS 

from 

RMU-1 

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

lliedSignal 


ARIA-200 Integrated Modular Cabinets 

PS FW DC I/O I/O OM FC PS 

PS FW DC I/O I/O VS FC PS 

PS = Power Supply 

I/O = I/O Module 

DC = EICAS Data Concentrator Module 

VS = Voice Synthesizer Module 

Cabinet-1 

Cabinet-2 

FC = Computer Module for Auto-Flight (AP/AT) 

OM = Computer Module for On-Board Maintenance 

FW = Computer Module for Flight Warning

lliedSignal 


ARIA-200 avionics 

cabinet 

• Mechanical structure and modules conform to ARINC 650 

� volume ≈ 2/3 of AIMS 

� weight ≈ 60% of AIMS 

• Uses 3 standardized modules: 

� Power Supply Module 

� Computer Module (CM) 

� Input/Output Module (IOM) 

• Module-module communication: high speed A429 backplane 

• Power consumption: < 400W total (115 V ac & 27 V dc ) 

• Cooled by integral fans

lliedSignal 


ARIA-200 avionics 

cabinet 

• Maximized design re-use for reduced development risk 

� processor design 

� I/O design 

� BIT circuitry 

� Ada real-time exec 

� AlliedSignal graphics development tool suite 

� common manufacturing process 

� fewer part-numbers 

• Identical computer module for multiple functions: 

� Flight Warning 

� Flight Control: AP & AT 

� On-Board Maintenance 

• I/O consolidation 

� simplifies DU and FMS/MCDU

minus database flash memory 

minus DPRAMs 

minus I/F-board connectors 

lliedSignal 


One Processor Board Design 

Processor Board for I/O-Module 

Processor Board for Computer-Module

lliedSignal 


Two Interface Board Designs 

CM-Interface Board discrete out 

analog in 

x-channel 

comparator logic 

(flt ctl module only) 

DC/DC 

conversion 

discrete in 

A429 I/O 

3x(4+1)

lliedSignal 


Two Interface Board Designs 

IOM-Interface Board DC/DC 

conversion 

analog 

in & out 

A429 I/O 

8x(4+1)

lliedSignal 


Computer Module (CM) “sandwich” 

CM-Processor Board 

CM-Interface Board

lliedSignal 


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+5 

� discrete in & out: 48+12 

• 

� RS-232: 1 (shop maint.) 

memory: 

� 512 kBRAM 

� 256 KB Boot RAM 

� Flash (program mem & database) 

� 32kB NVM 

• software loadable via ARINC-615 

• 1AMU* 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

lliedSignal 


Input/Output Module (IOM) “sandwiches” 

IOM-Processor Board 

IOM-Interface Board 

IOM-Processor Board 

IOM-Interface Board

lliedSignal 


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: 

� RAM 

� Boot 

� Flash (program mem & database) 

• 

� NVM 

software loadable via 

• 

ARINC-615 

3AMUwidth 

• application: 

� to DUs, FDR, FCMs, FWMs, OMM, IOMs 

� from a/c systems, CNS, EIS control panels

lliedSignal 


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

lliedSignal 





Integrated Hazard Avoidance System 

• Integrated Utilities System 

1

lliedSignal 


* all accidents (hull loss + fatal) 

Excludes: 

• Sabotage 

• Military action 

• Turbulence injury 

• Evacuation injury 

Load, 

taxi, 

unload 

Takeoff Initial 

climb 

Accidents* vs. flight phase 

Flaps retracted 

Percentage of accidents 

Climb Cruise Descent Initial 

approach 

Exposure percentage based on a flight duration of 1.5 hours 

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

Exposure, percentage of flight time 

Nav 

Fix 

Final 

approach Landing 

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

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

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

Outer 

Marker 

50% 

2

lliedSignal 


Hazards external to aircraft 

• Terrain 

• In-Air 

• On-Ground 

• On-Aircraft 

3

lliedSignal 



• 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-11 

ref.: D. Hughes: “CFIT task force to develop simulator training aid”, AV&ST, July 10, ‘95, pp. 22, 35, 38 

4

lliedSignal 



• 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, 1983 

ref.: L.S. Buurma: “Long-range surveillance radars as indicators of bird numbers aloft”, Israeli J. of Zoology, Vol. 41, ‘95, pp. 21-236 

5

lliedSignal 


Hazards to aircraft (cont’d) 

• On-Ground: 

� runway incursions 

� other aircraft 

� vehicles 

� animals 

� other obstacles 

• On-Aircraft: 

� fire, smoke 

� wing ice 

6

lliedSignal 


12,000 

10,000 

8,000 

Aircraft 

6,000 

Annual 

departures 

(Millions) 

4,000 

2,000 

0 

14 

12 

10 

8 

6 

4 

2 

0 

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) 

Jet aircraft in service & annual departures 

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

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

- worldwide operations 1965-1994 - 

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

11,852 

14.6 

20 

Accidents 

per million 

departures 

(annual rate) 

10 

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) 

0 

7

lliedSignal 


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: potential 

or 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 risk 

� limit 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). 

- 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-48 

ref.: “The dollars and sense of risk management and airline safety”, Flight Safety Digest, Vol. 13, No. 12, Dec. ‘94, pp. 1-6 

* 1 per 4 - 7 days 

** number of fatalities p.a. has been 

stable since 1947 (Bateman’s Law) 

8

lliedSignal 


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 detection 

� predictive/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 System 

� RadAlt-based GPWS 

� Enhanced GPWS (EGPWS= GPWS + terrain d-base) 

• Flight recorders 

� (SS)CVR, (SS)FDR 

• Smoke detection 

ref.: D. Esler: “Trend monitoring comes of age”, Business & Commercial Aviation, July ‘95, pp. 70- 

75 

ref.: P. Rickey: “VCRs and FDRs”, Avionics Magazine, March ‘96, pp. 34-38 

9

lliedSignal 


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 


� plus Situational Awareness/ Terrain Display 


• radar returns (Map Mode) 

10

lliedSignal 


20 

15 

10 

5 

0 

16 

Loss of 

control 

in flight 

Worldwide Fatal Accidents 1988-1995 

17 

1 1 

CFIT Fire Midair 

collision 

7 

3 

2 

Excludes 

• Sabotage 

• Military action 

Number of accidents (left-hand scale) 

Number of fatalities (right-hand scale) 

Landing Ice/ 

snow 

4 

Windshear Fuel Runway 

exhaustion incursion 

- 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-11 

3 

5 

Other 

1200 

900 

600 

300 

0 

11

lliedSignal 


Accidents 

35 

30 

25 

20 

15 

10 

5 

Worldwide CFIT Accidents 1945-1995 

USA 

Part 121/125 

*no data prior to '64 

Rest of 

World* 

USA 

GPWS 

1974 

ICAO 

GPWS 

1979 

0 

1945 50 55 60 65 70 75 80 85 90 

Year 

- 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 

commercial airplanes only 

12

lliedSignal 


CFIT ACCIDENTS PER YEAR 

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

35 

30 

25 

20 

15 

10 

5 

0 

7 

World-wide 

commercial jet 

CFIT accidents 

1988-1995 

Regional Corporate Air Taxi → 

21 21 

6 

16 

Large Commercial Jets 

3 ↓ 2 

88 89 90 91 92 93 94 95 

YEAR ENDING 

Not GPWS 

equipped 

GPWS 

Warning 

Activated 

11 

19 

7 

12 

16 

28 

5 

35 

4 

26 

5 

Late warning, 

or improper 

pilot response 

13

lliedSignal 


EGPWS color coding scheme - simplified 

Aircraft Elevation 

+2000’ 

+1000’ 

-500’ 

(variable) 

-1000’ 

-2000’ 

0 

14

lliedSignal 


Terrain map on Nav display 

display 

mode: 

WX vs. Terr 

15

lliedSignal 


Terrain threat on Nav display 

SURROUNDING 

TERRAIN 

(shades of green, 

yellow & red) 

“CAUTION TERRAIN” 

Caution Area 

(solid yellow) 

“TERRAIN AHEAD - 

PULL UP!” 

Warning Area 

(solid red) 

16

lliedSignal 


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

Terrain display - 3-D vs. 2-D 

17

lliedSignal 


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 

18

lliedSignal 


Pink: 15 arcsec ≈ ¼nm 

Red: 30 arcsec 

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

Orange: 60 arcsec 

Yellow: 120 arcsec 

Green: 5 arcmin (enroute) 

Blue: missing data 

Brown: Dig. Chart of the World 

19

lliedSignal 


50.00 

0.00 

50.00 

EGPWS Runway Database 

-150.00 -100.00 -50.00 0.00 50.00 100.00 150.00 

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

20

lliedSignal 


≤ ¼nm 

f(dx to airport) 

α 

\ 

Enhanced GPWS functions 

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

look-ahead distance 

CENTERTINE 

POINTS ALONG GROUNDTRACK 

centerline: points along groundtrack 

plus: lead-angle during turns 

PLUS A LEAD ANGLE DURING TURNS 

• 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 

21

lliedSignal 


Emerging technologies, incl. AlliedSignal developments 

• Detection of: 

� Wing ice (refinement) 

� Clear Air Turbulence (passive IR radiometry) 

� Wake vortex 

� Volcanic 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 Z refl of supercooled liquid H 2 0) 

• Synthetic vision system 

� IR doppler (improved CatII vision) 

22

lliedSignal 


IHAS: integration of safety avionics 

terrain database 

display interface 

a/c position 

GPWS 

TCAS II 

Mode-S Mode 

WX/Windshear 

Radar 

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

EGPWS 

Warning 

& Caution 

IHAS 

- a logical integration of numerous safety-avionics LRUs - 

23

lliedSignal 


Master Warn Light 

Stick 

Shaker 

L & R 

WARNING 

CAUTION 

WARNING 

CAUTION 

Aural Warn 

Speaker 


Aural Warn 

Speaker 

“Safety Avionics” - federated baseline 

Caution & Warning 

Electronics 

-Right - 

Caution & Warning 

Electronics 

-left- 

Discrete & 

Analog 

Inputs 

WX Radar 

Antenna 

ATC TPR / Mode S 

Waveguide 

Ant. 

Ctlr 

ATC TPR / Mode S 

Sw 

WX Radar CP 

Other Aircraft Systems 

Waveguide 

TCAS Processor 

RADAR 

RADAR 

Coax Switches 

TCAS/ATC CP 

Antennas 

GPWS CP 

GND PROX 

Top ATC 

Antenna 

Bottom ATC 

OVRD 

GPWS 

A453 

Relay 

WX/Terr 

Displ. 

24

lliedSignal 


Stick Shaker 

L & R 

Aural Warn Speaker 


WARNING 

CAUTION 


WARNING 

CAUTION 

Aural Warn Speaker 

“Safety Avionics”- IHAS baseline 

Top 

Safety CP 

IHAS 

IHAS 

Dir. Ant. Bottom 

4 4 

IHAS - L 

IHAS - R 

Top Bottom 

Omni Ant. 

A453 

Other Aircraft Systems 

- major reduction in complexity - 

High Speed 

Dig. Buses 

Coax 

Coax 

• Antenna Ctlr 

• R/T switching 

• RF front-ends 

part of antenna 

drive unit 

WX 

Radar 

Antenna 

25

lliedSignal 


Advantages of IHAS approach 

• Added-value from safety point of view: 

� greater degree of protection through sharing & 

integrating of information 

� reduced 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 display 

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

cont’d → 

26

lliedSignal 


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 

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

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

*compared to equivalent 

federated suite on 777 

**depends on config 

27

lliedSignal 


• Open architecture 

IHAS design goals 

• 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 

28

lliedSignal 


$ 

$$ 

$$$ 

Reducing the impact of change 

• Application 

� code / algorithm changes 

� I/O details (in current channels) 

� execution threads 

• K_EXEC 

� processor time allocation 

� partition window positioning 

� connection of channels to partitions 

• BIC Tables 

� channel bandwidth allocations 

� node transmit permissions 

- change containment to lower cost of system changes - 

29

lliedSignal 

6 


RDR-4B 

WX/Windshear Radar 

W X 

R adar 

IHAS integrates “safety” sub-systems 

T 

C 

A 

S 

A 

T 

C 

RF + DSP 

Modules 

D ual 

C P 

M 

D ual 

C P 

M 

Central 

Processing 

Modules 

TCAS-II 

I 

O 

M 

I 

O 

M 

I/O 

Modules 

D ual 

P 

S 

M 

Power 

Supplys 

Module 

s 

p are 

Mode-S 

Transponder 

s 

p are 

E-GPWS 

Enhanced Gnd Prox 

Warning System 

IHAS 

Warning 

Computer 

30

lliedSignal 


a/c data 

& 

power 

dir. 

ant. 

Baselines: conventional vs. IHAS 

omni 

ant. 

Ant. drive 

E-GPWS TCAS Mode-S Radar 

Power Bus 

PSM CPM IOM 

a/c power IOM 

a/c data 

TCAS + 

Mode-S 

special I/O 

& 

processing 

Flight 

Warning 

Computer 

Ant. drive 

Radar 

special I/O 

& 

processing 

Backplane Data Bus 

• 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 

31

lliedSignal 


IHAS characteristics 

• Interfaces: 

� digital: ARINC-429 and 629 

� analog: as required for specific aircraft 

� inter-modular backplane bus: modified ARINC-659 

� RF: 2 TCAS/Mode-S antennas (shared aperture, directional) 

� power: multiple 115 V ac and 28 V dc 

• Mechanical: 

� LRM form-factor: ARINC-600 

� connectors: RF and modified ARINC-600 

- conceptual - 

32

lliedSignal 


IHAS generic LRMs 

• Central Processing Module (CPM): 

� functions: 

• I/O and bus control 

• DSP-function control 

• system redundancy management 

� fault-tolerant 

� software loadable on-board 

• Digital Signal Processors (DSPs): 

� function: performing all signal processing 

� multiple DSP LRMs (redundancy) 

� hi-speed serial I/F for unique functions (radar, TCAS) 

� software loadable on-board 

- conceptual modular allocation - 

cont’d → 

33

lliedSignal 


IHAS generic LRMs 

(cont’d) 

• Input/Output Modules (IOMs): 


• all external interfaces 

• display processors 

• audio output 

� multiple LRMs (redundancy) 

� fault-tolerant 

• Power Supply Module (PSU): 


• power input conditioning 

• power interrupt transparency 

• dc/dc up-conversion and distribution to all LRMs 

� multiple power sources (ac & dc) 

- conceptual modular allocation - 

34

lliedSignal 


Partition Execs 

Thread schedulers, driven by event/priority/deadline; 

executes strictly within a partition created by K-Exec 

User-Mode 

software 

Kernel-Mode 

software 

Processor 

and I/O 

hardware 

App 1 

Node Software Architecture 

App 2 

App 3 

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

P-Exec 2 

- modified “scheduler activation” type exec - 

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

App 4 

K-Exec 

Hardware 

Shared Function Libraries 

Shared functions in “execute-only” 

memory may be used by any partition 

App 5 

BIT 

Kernel Exec 

Simple, deterministic, roundrobin 

scheduler and partition 

management 

Lib. 1 

Lib. 2 

Lib. 3 

Host CPU & supporting logic 

Interrupt system, MMU, I/O 

35

lliedSignal 


P1 

Node architecture 

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

IPU IPU Special IOM Generic IOM Generic IOM 

Special H/W 

P2 P3 P4 P5 P3 P6 P7 P8 P9 P10 

K-Exec K-Exec K-Exec K-Exec K-Exec 

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

Fault-tolerant Backplane Databus 

36

lliedSignal 


Processor selection criteria* 

• processing throughput 

� VAX-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 & support 

� must have believable roadmap for development of architecture (no AMD29K) 

� life-cycle of avionics >> PCs 

• embeddedness 

� desired: minimum number of external components, i.e., component integration 

� counters, timers (incl. watchdog) 

� cache 

� DRAM refresh 

� floating point unit 

� memory management unit 

� serial port UART 

� JTAG port for debug, BIT, shop test, software load 

• operating voltage 

� 5, 3.3, 2.5, 2.2, 1.8, etc. Vdc 

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

*not priotitized, 

n-exhaustive list 

37

lliedSignal 


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 level 

� L2/L3 may not be desired 

• memory management 

� virtual addresssing (page based) 

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

• exception & interrupt handling 

� at Kernel & Application Exec level 

� at application level 

• availability for integration 

� eventually: processor-die + memory + peripherals + bus I/F into single ASIC 

- hold-off actual selection as long as possible - 

38

lliedSignal 


Processor selection criteria - cont’d 

• support for multi-processor configuration 

� synchronization 

� fault detection 

� redundancy management 

• in-house experience with processor family 

� design 

� compilers, debuggers, emulators, etc. 

� development/maintenance 

• portability of existing/legacy software 

� incl. device driver & O/S implications 

• tools and supporting vendors 

� robust compilers (validated) , linkers, debuggers, etc. (so-so for Intel) 

� real-time O/S 

• cost 

� recurring cost of complete processor core 

� development/maintenance 

• availability of evaluation boards & simulators 

ref.: M. Slater: “The microprocessor today”, IEEE Micro, Dec. 1996, pp. 32-44 

39

lliedSignal 


but 

OASYS Backplane Databus 

• derived from ARINC-659 standard: 

� semi-duplex, serial, multi-drop, broadcast 

� table driven, deterministic, distributed control 

� fault tolerant, high integrity 

• same integrity 

• same availability 

• higher bandwidth 

• reduced complexity: 

� fewer operational modes (simplicity, dev., V&V, cert.) 

� simpler message protocol 

� simpler hardware 

• easier to change & add applications: 

� need for, and cost of changing bus traffic configuration 

• easier to integrate system (debug, dev.) 

• less costly 

ref.: K. Hoyme, K. Driscoll: “SAFEbus ”, Proc. 11th DASC, Seattle/WA, Oct. 1992, pp. 68-72 

40

lliedSignal 


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 

41

lliedSignal 


Node architecture - generic processing module 

sets of 

redundant 

bus lines 

Clock 

Table 

Mem 

Clock 

µP 

DPRAM 

Bus I/F 

Controller 

- frame synchronized pair - 

µP 

DPRAM 

Bus I/F 

Controller 

Clock 

Clock 

Table 

Mem 

42

lliedSignal 


sets of 

redundant 

bus lines 

Node architecture - generic I/O module 

Table 

Mem 

Clock 

µP 

DPRAM 

Bus I/F 

Controller 

analog, discrete, digital, audio 

I/F I/F 

FIFO 

Clock Clock 

Bus I/F 

Controller 

Table 

Mem 

43

lliedSignal 


Resource partitioning in all nodes: time & space 

- the need for partitioning is driven by 

sharing 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 partitioning 

looks like a “virtual” federated system - 

44

lliedSignal 


Growth Potential 

� Wake-vortex prediction 

� Wing-ice detection 

� Clear Air Turbulence detection 

� Volcanic ash detection 

� Enhanced Vision System (EVS) 

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

45

lliedSignal 


IHAS: stepping stone towards an integrated 

Enhanced Situational Awareness System (ESAS) .... 

EGPWS 

TCAS II 

Mode-S 

Warn & Caution 

WX/Windshear 

Radar 

Enh. TCAS 

IHAS 

Cond. & Perf. 

Monitoring 

Volc. Ash 

Wake Vortex 

Radar 

Terrain & Obst. 

Sensing 

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

Dry-Hail Dry Hail 

HUD 

CAT 

Radar Posn. 

Correlation 

Imaging 

Sensors 

EVS 

ESAS 

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

46

lliedSignal 


Flight Operations Quality Assurance Tool (FOQA) 

�Accidents are not frequent enough to measure safety 

through accident rates 

�Absence 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. 

47

lliedSignal 


Probability of 

CFIT 

Ex.: Safety Margin Prediction for CFIT 

Terrain 

Clearance 

Probability 

0 

3 o Glideslope 

Nominal 

Terrain Clearance 

Runway 

- similar statistical process as done for autoland cert. - 

48

lliedSignal 


Unified AlliedSignal IMA approach 

• Necessity for SBUs/SBEs to have IMA: 

� response to RFIs 

� competitive reasons 

• Single concept for multiple SBUs/SBEs: 

� IHAS approach with Application Specific I/O Modules 

� single-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 equipment 

� sharing / pooling of resources from various SBUs/SBEs 

• Reduced RE: 

� economies of scale for “generic” modules and backplane 

� fewer 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 - 

49

lliedSignal 


“common” “specific” 

IOM 

CPM 

(dual) 

PSM 

(dual) 

Bus 

+ 

Mech 

O/S 

Maint S/W 

BIT S/W 

Unified AlliedSignal IMA approach 

IHAS 

Utilities 

Control IMA 

Com/Nav 

IMA 

- maximum re-use of common resources - 

Radar RF/DSP 

TCAS RF/DSP 

Appl. S/W 

tbd 

tbd 

50

lliedSignal 





• Integrated Utilities System 

1

lliedSignal 


CNS Radios 

Comm Mgt 

Displays 

Data Concentr. 

Air Data & 

Inertial Ref 

On-Board Maint 

Pax Comm. 

Pax Entertain. 

Condition Mon. 

Flight Warning 

Flight Safety 

- FDR, CVR 

- TCAS 

- GPWS 

- WX 

FMS 

AP/AT 

Perf Mgt 

Typical transport aircraft systems 

Bleed Air 

Bleed Leak Det 

Avionics Cooling 

Cargo Fire Prot 

Eng. Fire Prot 

Smoke Detect 

Anti-Ice 

Cabin Air 

- pressure 

- conditioning 

Environmental Control 

PFCS 

SFCS 

AFS 

Avionics Flight Control 

Elec Pwr Gen 

Elec Pwr Distr 

Load Mgt 

Windshld Heat 

DC sensors 

Lighting 

- external 

- flight deck 

- cabin 

Cargo Handling 

Potable Water 

Lavs & Waste 

Galley 

Escape System 

Oxygen 

Electrical 

Hyd Supply 

Control Surface 

Actuation 

Landing Gears 

Steering 

Brakes 

Engine Control 

Thermal Mgt 

Thrust Reverse 

Fuel Control 

APU Control 

Propulsion 

Payload Hydro-Mechanical 

Hydro Mechanical 

ref.: D. Parry: “Electrical Load Management for the 777”, Avionics Magazine, Feb. ‘95, pp. 36-38 

ref.: “Avionics on the Boeing 777, Part 1-11”, Airline Avionics, May ‘94 - June ‘95 

ref.: 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-183 

ref.: G. Bartley: “Model 777 primary flight control system”, Boeing Airliner Magazine, Oct/Dec ‘94, pp. 7-17 

ref.: R.R. Hornish: “777 autopilot flight director system”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 151-156 

2

lliedSignal 


Typical Environmental Control System 

3

Signal Inputs: 

• air data 

• heat load on/off 

• load shedding 

• throttle setting 

• air/gnd status 

• fuel/coolant temp 

• flow/temp/press 

demand 

lliedSignal 


Typical Environmental Control System 

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 

Signal Outputs: 

• valve drives 

• actuator drives 

• temp/flow/press 

• fault/warning 

• fuel flow recirc. 


Internal Sensors: Internal Actuators: 

Physical Inputs: 

• bleed/APU air 

• hydr fluid/coolant 

• electr. power 

• pneum. servo pwr 

• ram air 

• fuel 

• temperature 

• pressure 

• air flow 

• fluid flow 

• humidity 

• angular speed 

• ang./lin. position 

• valves 

– motor 

– solenoid 

• compressors 

– motor, turbine 

– air-fan 

• fluid pump 

• other EM devices 

Physical Outputs: 

• air flow at suitable 

temp & press 

• coolant flow at 

suitable temp & 

press 

• O2, N2 flow 

• APU air 

- multi-variable, multi-channel control - 

4

lliedSignal 


Integrated Utilities System 

Environmental control: 

• very I/O intensive: 

� up to ≈ 90 sensors 

� up to ≈ 60 effectors 

• wide variety of I/O: 

� sensors: pressures, temperatures, flows, speeds, humidity 

� effectors: valves, compressors, pumps, ejectors, other EM devices 

� even 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) 

5

Environmental Control System (ECS) - technology trends 

Integrated Utilities 

Integrated Systems 

Microprocessor/ 

Software 

Hybrid Analog Digital 

Solid State Analog 

Magnetic Amplifier 

lliedSignal 


System 

Complexity 

DC9 

C5A 

DC-10 DC 10 

747 

F-15 15 

F-18 18 C/D 

B757/767 

�� MD-11 MD 11 

777 

� B767 EBAS 

A330/340 

1960 1970 1980 1990 2000 

B-2 

A320 

V-22 22 

ICECS 

F-22 22 

F-18 18 E/F 

ref.: “Jane’s Avionics, 1992-1993”, Jane’s Information Group Inc., 664 pp., ISBN 0-7106-0990-6 

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

�� JAST 

6

lliedSignal 


- Components of AlliedSignal F-22 ATF IECS - 

- over 120 control channels - 

7

AlliedSignal MD-11 ECS Controller and Sensors 

lliedSignal 


8

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

lliedSignal 


CNS Radios 

Comm Mgt 

Displays 


Air Data & 

Inertial Ref 


Pax Comm. 




Flight Safety 

- FDR, CVR 

- TCAS 

- GPWS 

- WX 

FMS 

AP/AT 

Perf Mgt 

Bleed Air 





Smoke Detect 

Anti-Ice 

Cabin Air 

- pressure 



PFCS 

SFCS 

AFS 


Elec Pwr Gen 


Load Mgt 

Windshld Heat 

DC sensors 

Lighting 

- external 

- flight deck 

- cabin 

Electrical 


Potable Water 

Lavs & Waste 

Galley 

Escape System 

Oxygen 

- technology demonstration - 

Propulsion 

Hyd Supply 


Actuation 


Steering 

Brakes 


Thermal Mgt 


Fuel Control 

APU Control 



9

Environmental Control & Thermal Management System 

Engine 

APU 

Ground 

Source 

Power 

Source 

Aircraft 

Computers 

Flight 

Deck 

lliedSignal 


Bleed 

Air 




Diagnostics 

Controls 

Selector 

Displays 

Anti-Ice 

De-Ice 

Air 

Cycle 

Unit 

Vapor 

Cycle 

Unit 

Windows 

Cabin 

Temp 

Equip 

Loads 

Thermal 

Mgmt 

Fuel 

Cabin 

Pressure 

avionics 

radar 

hydraulics 

electr. power 

10

A/C 

Loads 

lliedSignal 


J/IST Suite Consensus Demonstration Architecture 

Fuel 

Engine 

Oil 

ref.: J/IST RFP 

Engine 

Bleed-Air 

APU 

Other 

Sub-system 

Controllers 

FADEC 

T/EMM 

Controller 

Electr. Power 

Distribution 

External 

Power 

- mechanical integration and controls integration - 

Combustor 

Heat Exchanger 

Starter/Generator 

On same shaft: 

• APU 

• starter/generator 

• bleed-air compressor 

11

lliedSignal 


Integrated Modular Utilities Control System 

ECS 

Cabin Pressure 

Vapor Cycle Sys. 

Bleed Air 

APU 

Electric Power 

Hydraulic Sys. 

Power 

Supply 

Sensors & 

Actuators 

CPU 

Module 

Power 

Electronics 

Digital 

Interface 

Other 

Functions 

Conventional Controls Integrated Thermal/Environmental Control 

- mechanical integration forces controls integration - 

12

lliedSignal 


Integration of controls 

• Integrated control system has higher criticality 

• So, (more) fault tolerance required 

* MAFT is not limited to 4 nodes 

• 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 network 

� each of the 4 nodes (lanes) is partitioned into a Computing 

Module and an I/O Module 

� the computing module is partitioned into an Applications 

Processor and an RTEM (Real-Time Executive Module) 

co-processor 

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-421 

ref.: L. Lamport, R. Shostak, M. Pease: “The Byzantine Generals Problem”, ACM Trans. on Programming Languages & Systems, Vol. 4, No. 3, July ‘82, pp. 382-401 

ref.: 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 

13

lliedSignal 


RTEM 

AP 

IOP 

RTEM-based system 

fully connected broadcast network 

(repeated for all nodes) 

RTEM 

AP 

IOP 

RTEM 

AP 

IOP 

RTEM 

AP 

IOP 

system busses 

14

lliedSignal 


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 systems 

� dedicated 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 

15

lliedSignal 


Real-Time Executive Module (RTEM) 

• Hardware-implemented executive (overhead) 

functions associated with redundancy mgmt: 

� fault-tolerant inter-channel communication 

� fault-tolerant inter-channel synchronization 

� voting 

� error detection, isolation, recovery 

� dynamic system reconfiguration 

• faulty channel exclusion 

• healthy channel readmission 

� fault tolerant task scheduling 

� RTEM-AP interface 

• Provides mathematically provable correctness 

16

lliedSignal 


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 - 

17

lliedSignal 


Analog I/O 

RTEM-based node 

RTEM 

Applications 

Processor 

Input/Output 

Processor 

fully connected 

broadcast network 

Discrete I/O 

system 

bus(es) 

18

from all other nodes + 

wrap from own node 

lliedSignal 


RTEM block-diagram 

Message 

Checker 

Fault 

Tolerator 

Voter 

Transmitter 

Synchronizer 

Task 

Scheduler 

Task 

Communicator 

to all other nodes 

to/from 

applications 

processor 

19

lliedSignal 


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) 

20

lliedSignal 


RTEM Prototype Board - VME 6U 

21

lliedSignal 


Recvr (x4) 

X-mitter (x1) 

Msg Chkr 

Mem Mgt 

Task 

Sched 

Flt Tol. 

Buf. Ctl 

Seq 

RTEM Prototype Board 

RX/TX Conn. 

Voter 

Sync 

22

lliedSignal 


MAFT/RTEM Hardware Integration 

TTL-version MAFT 

mid-’80s 

2x3x7 ft cabinet 

Single-Chip RTEM 

≈ 80k gates FPGA 

5x FPGA Chip Set 

VME 6U 

RTEM Prototype Board 

mid-’90s 

23

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

lliedSignal 


Candidate systems for Integrated Utilities 

Air Conditioning 

Autoflight 

Communications 

Electric Power 

Equipment/Furnishings 

Fire Protection 

Flight Controls 

Fuel 

Hydraulic Power 

Ice and Rain Protection 

� 

31 

32 

33 

34 

35 

36 

38 

45 

49 

Indicating/Recording Systems 

Landing Gear 

Lights 

Navigation 

Oxygen 

Pneumatic System 

Water/Waste 

- airframe systems by ATA chapter - 

Central Maintenance System 

Airborne Auxiliary Power 

� indicates candidate system 

24

1 



• Why change avionics? 



�� Future ..... 

©1997 F.M.G. Dörenberg

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 avionics 

� more 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 


4 

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

• device density and performance 

• system complexity and size 

• remote electronics: 

� end-to-end digitalization 

� interfacing & computing closer to data 

source or to point of application 

� “smart” sensors, actuators, skins, etc. 

• standard real-time operating systems 

� application transparency to hardware 

� strict partitioning 

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

cont’d → 


5 

Component and System Performance trends 

Note: curves not necessarily drawn to scale 

"now-ish" 

Processing & Memory 

Density 

ref.: G. Stix: "Toward 'point One' - Trends in Semiconductor Manufacturing," Scientific American, February 1995, pp. 90-95 

ref.: G.D. Hutcheson, J.D. Hutcheson: "Technology and Economics in the Semiconductor Industry," Scientific American, January 1996, pp. 54-62 

Level of Functional 

Integration 

Reliability 

System 

Cost 

Power 

Weight 

Volume 

time 


6 

NUM BER OF TRANSISTORS PER CHIP 

9 

10 

8 

10 

7 

10 

6 

10 

5 

10 

4 

10 

4K 

1K 

4004 

TIME 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 

8080 

6800 

68000 

16K 

64K 

8086 

80286 

POWER PC 601 

80486 

256K 

68030 

68020 80386 

INTEL MICROPROCESSOR 

MOTOROLA MICROPROCESSOR 

SIZE OF MEMORY (DRAM) IN BITS 

YEAR OF AVAILABILITY 

ref.: G.D. Hutcheson, J.D. Hutcheson: "Technology and Economics in the Semiconductor Industry," Scientific American, January 1996, pp. 54-62 

ref.: M. Slater: “The microprocessor today”, IEEE Micro, Dec. 1996, pp. 32-44 

68040 

80786 

80786 

PENTIUM 

PRO 

POWER PC 604 

PENTIUM 

10 

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

3 

1M 

POWER PC 620 

4M 

16M 

64M 

256M 

Exponential 

increase of 

transistor density 

Current range: 10 6 → 50x10 6 

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 

Die size 

Technology size 

Mips 

MHz 

RAM 

ROM 

Price 

Power 

Transistors 

Wafer size 

ref.: EE Times, May 22, ‘95, p. 16 

- DSP integration through the decades - 

1982 1992 2002 

50 mm 

3 µ 

5 Mips 

20 MHz 

144 words 

1.5k words 

$150 

250 mW/Mips 

50k transistors 

3-in wafer 

50 mm 

0.8 µ 

40 Mips 

80 MHz 

1k words 

4k words 

$15 

12.5 mW/Mips 

500k transistors 

6-in wafer 

50 mm 

0.25 µ 

400 Mips 

200 MHz 

16k words 

1.5M words 

$1.50 

0.25 mW/Mips 

5M transistors 

12-in wafer 

source: Texas Instruments 

- further price/performance improvements to be expected - 


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-25 

ref.: K. Hoyme, K. Driscoll: “SAFEbus TM ”, Proc. 11th DASC, pp. 68-72 

ref.: “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 

CNS Radios 

Comm Mgt 

Displays 


Air Data & 

Inertial Ref 


Pax Comm. 




Flight Safety 

- FDR, CVR 

- TCAS 

- GPWS 

- WX 

FMS 

AP/AT 

Perf Mgt 


Bleed Air 





Smoke Detect 

Anti-Ice 

Cabin Air 

- pressure 



PFCS 

SFCS 

AFS 


Elec Pwr Gen 


Load Mgt 

Windshld Heat 

DC sensors 

Lighting 

- external 

- flight deck 

- cabin 


Potable Water 

Lavs & Waste 

Galley 

Escape System 

Oxygen 

Electrical 


Thermal Mgt 


Fuel Control 

APU Control 

Propulsion 

Hyd Supply 


Actuation 


Steering 

Brakes 



6-7 7 IMAs + remotes 


11 

150 k 

↑ 

Total airplane 

signal interfaces 

(digital words / labels 

& analog) 

100 k 

50 k 

System Complexity and Size - trends - 

747-200 

System 

Complexity 

747-400 

777-200 

757/767-200 

0 

1970 1980 

Year 

1990 

↑ 

↑ 

installed 

software 

100 MB 

80 MB 

20 MB 

10 MB 

System 

Size 

2x every 2 years 

A310 

partially driven 

by Ada req't 

A320 

A330/340 

747-400 

777-200 

747-200 

757/767-200 

Apollo 

0 

1970 1975 1980 1985 1990 

Year 

1995 

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 

↑ 

> 2M SLOCs 


12 

150k 

↑ 

Total airplane 

signal interfaces 

(digital words / labels 

& analog) 

100k 

50k 

747-200 

System complexity - trends - 

757/767-200 

747-400 

0 

1970 1980 1990 




777-200 


13 

100 MB 

80 MB 

20 MB 

10 MB 

747-200 

Apollo 

System size - trends - 

2x every 2 years 

A310 

757/767-200 

A320 

747-400 

A330/340 

0 

1970 1980 1990 

partially driven 

by Ada req. 




777-200 


14 

source: BCAG 

Source Lines of Code 

(kSLOCs) 

600 

500 

400 

300 

200 

100 

Software Size - example: 777-200 

490 

AIMS 

415 

CMS 

377 

CNI 

278 

ECS 

230 

ELEC 

Total: 2.1 MSLOCs 

combined Elec/Mech 634k > AIMS 

168 

Flt Ctl 

126 

Mech/Hyd 

49 

Flt Deck 

- mech/elec systems SLOC combined is larger than AIMS - 

excl. BFE equipment 

30 

Prop 


15 

System Complexity and Size 

Typical large jetliner: 

� ≈ 8,000 inputs & outputs 

� these 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 & 

expensive 

� many 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 breakers 

� 200,000 individually marked lengths of cable 

� total ≈ 225 km (140 miles) 

� 400,000 connections 

� 14,000 connectors 

� 3,000 splices 

� 35,000 ring terminals 

� over 1,000,000 individual parts 

� “system” accounts for ≈ 10% of a/c price tag 

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

* exc. main power feeds 


17 

Given: 

Extrapolation ...... 

• 777 processing power ≈ equivalent to 

1,000 x 486 

Assuming: 

• 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 - 

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

13 


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 

redundancy 

� chip & inter-chip BIT 

ref.: G. Derman: “Interconnects & Packaging - Part 1: Chip-Scale Packages”, EE Times, 26 Feb. ‘96, pp. 41,70-72 

ref.: T. DiStefano, R. Marrs: “Building on the surface-mount infrastructure”, EE Times, 26 Feb. ‘96, pp. 49 

ref.: HITEN (High Temp. Electronics Network)“Aerospace applications of High Temperature Electronics”, 13 May ‘96, http://www.hiten.com/hiten/categories/aero 

ref.: S. Birch: “The hot issue of aerospace electronics”, SAE Aerospace Engineering, July ‘95, pp. 4-6 

ref.: 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 


- components - 

• MCMs: 

� reduced size, increased performance 

� low inductive/capacitive parasitics 

� lower supply noise & ground bounce 

� very expensive (mfg & test) 

� 3-D stacking (e.g., memory) poses thermal problems 

� military niche market for time being 

PCB 

PCB 

thru-hole 

device 

thru-hole 

device 

MCM 

MCM 

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

substrate 

SMT device 

SMT device 



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

• (mobile) PC and Com industry : 

� circuit integration & packaging 

� PC-Card: highest density PCB technology (PCMCIA) 

� powerful general-purpose processors 

• Automotive industry: 

� high temperature electronics 

� coming: ruggedized “laptop” LCDs* 

(temp/vibe/sunlight environment similar to aviation application) 

* there is no reason why (smart) Display Units cannot 

be reduced to the size of notebook PC 


22 

Electronics evolution 


23 


- 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 

236-pin 

connector 

Example: PC mother-board in a module 

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

8.5 cm (3 3/8 in.) 

5.4 cm 

(2 1/8 in.) 

Cardio-486, 5/96 

486DX2/DX4 

25-100 MHz 

up to 32 MB RAM 

up to 4 MB Flash 

512 kB VRAM 

256 kB BIOS ROM 

LCD/RGB SVGA 

IDE Hard/Floppy Dr 

Keyboard ctlr 

Power Mgt 

Complete 

486 PC AT 

with PC-card 

form factor 

(frmr PCMCIA) 


26 

Example: integrated power supply modules 

28 → 5 Vdc/dc converter (100 W) 

ADDC02805S 

3.8 cm 

(1½ in.) 

7 cm (2 3/4 in.) 

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

photo: courtesy Analog Devices, Norwood/MA, 1996 


27 

Example: integrated X-band power module 

6x HFET MMIC @ 12 W 

13 dB gain 

400 MHz bandw. 

Texas Instruments transmitter module 

> 30% PAE (9.5-9.9 GHz) 

built-in modulator 

built-in gate regulator 

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

waveguide output 

MTBF > 400k hrs 

6.5 x 3.8 x 0.5 cm (2½ x 1.1 x 0.2 in.) 


28 

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

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”) 


29 

Cold-Cathode Field Emission Displays (FEDs) 

Anode 

Red phosphor 

Cathode 

Red sub-pixel Green sub-pixel 

Glass face plate 

Individual pixel 

Green phosphor 

Cathode conductor 

Glass 

Column line 

Microtips 

Blue sub-pixel 

Blue phosphor 

Indium-ten-oxide layer 

Gate row line + 

Resistive 

layer 

- 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 

AIMS: 

47”x18”x9.6” 

111 lbs 

“PCMCIA” vs. AIMS Avionics Cabinet 

“PCMCIA”: 

6.5”x4.5”x3.0” 

2 lbs 


31 


- component integration issues - 

� more components become “complex”* (not 

100% analyzable or 100% testable) 

� hardware-near-software 

* not necessarily high gate count 

� must apply design assurance to devices & 

tools, as already req’d for software (DO- 

178); but who will do this for COTS? 

ref.: RTCA DO-180 

ref.: BCAG: "777 Application Specific Integrated Circuits (ASIC) Certification Guideline," Boeing Doc. 18W001; also: RTCA Paper No. 535-93/SC180-11, December 1993 

ref.: Honeywell Commercial Flight Systems: "ASIC Development and Verification Guidelines," Honeywell Spec. DS61232-01 Rev A, January 1993; also: RTCA Paper No. 536-93/SC180-12 

ref.: 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 & code 

storage areas, or I/O 

� failure of a resource that is shared by multiple partitions 

does not affect flight safety 

� failure of a dedicated partition-resource does not cause 

adverse effects in any other partition 

� failure of a partition does not reduce the timely access to 

shared 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 partitioning 

� all failures of the protection mechanism must be detectable 

• Advantages of partitioning: 

� provides an effective means to meet safety req’s 

� maximizes ability to detect & contain errors/faults 

� allows partitions to be updated & certified separately 

� allows re-V&V to be limited to changed partition 

� allows incremental & parallel design, test, integration 

� supports cost-effective development, cert., maint., updates 

� allows 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 



� capturing complete set of validated req’s 

� software auto-code 

� software V&V 

� hardware V&V (DO-180: hardware-nearsoftware, 

“complex” hardware) 

� EMI/Lightning certification 

� re-use 

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


37 

High 

Medium 

Low 


Influence 

on 

Outcome 

Requirements 


Design, 

Development 

Test 

Cost to Fix 

Problems 

Production & 

Deployment 

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

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

10,000 

1,000 

100 

10 

1 

* 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) 


38 

Equivalent 

Maturity Level 

World Class - 3 

Structured - 2 

Defined - 1 

Undefined - 0 


Percentage of 

Surveyed firms 

17 

- design & development - 

36 

36 

(141 companies total) 

52 

Return-on-Sales p.a. 

1987-1991 

0.5% 

4.7% 

6.7% 

Sample 

Average 

4% 

Sales Growth p.a. 

1987-1991 

9.3% 16% 

8.1% 

7.3% 

5.1% 

Sample 

Average 

8% 

- business performance is linked to engineering maturity level - 

ref.: “Excellence in quality management”, McKinsey & Co., Inc., 1992 

ref.: 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: 

• F 3 I, performance (inc. timing), technology, etc. 

• complete, validated, traceable, consistent, unambiguous 

� eliminate errors via (V&V-ed) autocode 

� standard libraries of software modules (re-use) 

� automated V&V tools 

ref.: EIA Interim Std 632 “Systems Engineering”, Dec. 1994 

ref.: IEEE 1220 Std for Appl. and Mgt of the Systems Engineering Process, Dec. 1994 

- certified software is too expensive - 


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 


1 

BOOKS 

BIBLIOGRAPHY 

F.J. Redmill (ed.): “Dependability of critical computer systems - 1”, 1988, 292 pp., ITP Publ., ISBN 1-85166-203-0 

D.P. Siewiorek, R.S. Swarz (eds.): “Reliable computer systems”, 2 nd ed., Digital Press, ‘92, 908 pp., ISBN 1-55558-075-0 

M.R. Lyu (ed.): “Software fault tolerance”, Wiley & Sons, ‘95, 337 pp., ISBN 0-471-95068-8 

B.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-5 

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-6287 

M. Pecht (ed.): “Product reliability, maintainability, and supportability handbook”, CRC Press, ‘95, 413 pp., ISBN 0-8493-9457-0 

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

G.L. Fuller: "Understanding HIRF - High Intensity Radiated Fields," publ. by Avionics Communications, Inc., Leesburg, VA, 1995, 123 pp., ISBN 1-885544-05-7 

J. Curran: “Trends in advanced avionics”, Iowa State Univ. Press, ‘92, 189 pp., ISBN 0-8138-0749-2 

J.R. Newport: “Avionic system design”, CRC Press, ‘94, 332 pp., ISBN 0-8493-2465-3 

C.R. Spitzer: “Digital Avionics Systems - Principles and Practices”, 2 nd ed., McGraw-Hill, ‘93, 277 pp., ISBN 0-07-060333-2 

I.C. Pyle: “Developing safety systems - a guide using Ada”, Prentice Hall, ‘91, 254 pp., ISBN 0-13-204298-3 

E.T. Raymond, C.C. Chenoweth: “Aircraft flight control actuation system design”, SAE, ‘93, 270 pp., ISBN 1-56091-376-2 

D.T. McRuer, D.E. Johnson: “Flight control systems: properties and problems - Vol. 1 & 2”, 165 pp. & 145 pp., NASA CR-2500 & -2501 

D. McRuer, I. Ashkenas, D. Graham: “Aircraft dynamics and automatic control”, Princeton Univ. Press, ‘73, 784 pp., ISBN 0-691-08083-6 

J. Roskam: “Airplane flight dynamics and automatic flight controls - Part 1 & 2”, Roskam A&E Corp., 1388 pp., Library of Congress Card No. 78-31382 

NATO Advisory Group for Aerospace R&D : “AGARD Advisory Report 274 - Validation of Flight Critical Control Systems”, dec. ‘91, 126 pp., ISBN 92-835-0650-2 

C.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. II 

R.A. Sahner, K.S. Trivedi, A. Puliafito: “Performance and reliability analysis of computer systems”, Kluwer Academic Publ., 1995, ISBN 0-7923-9650-2 

E.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örenberg

2 

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. 1991 

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

B. Fitzsimmons: “Better value from integrated avionics?” Interavia Aerospace World, Aug. 1993, pp. 32-36 

ICARUS Committee: “The dollars and sense of risk management and airline safety”, Flight Safety Digest, Dec. ‘94, pp. 1-6 

P. Parry: “Who’ll survive in the aerospace supply sector?”, Interavia, March ‘94, pp. 22-24 

R. Ropelewski, M. Taverna: “What drives the development of new avionics?”, Interavia, Dec. ‘94, pp. 14-18, Jan. ‘95, pp. 17-18 

A. Smith: “Cost and benefits of implementing the new CNS/ATM systems”, ICAO Journal, Jan/Feb ‘96, pp. 12-15, 24 

K. O’Toole: “Cycles in the sky”, Flight In’l, 3-9 July 1996, p. 24 

C.A. Shifrin: “FAA paints upbeat air travel picture”, AW&ST, March 11 ‘96, pp. 30-31 

J. Moxon: “Outrageous ATC charges anger European regional”, Flight Int’l, 23-29 Oct 1996, p. 12 

P. Condom: “Is outsourcing the winning solution?” Interavia Aerospace World, Aug. 1993, pp. 34-36 

Anon.: “The guide to airline costs”, Aircraft Technology Engineering & Maintenance, Oct/Nov ‘95, pp. 50-58 

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

B. Rankin, J. Allen: “Maintenance Error Decision Aid”, Boeing Airliner, April-June ‘96, pp. 20-27 

P. Gartz, “Systems Engineering,” tutorial at 13th & 14th AIAA/IEEE DASC 

C. Spitzer, “Digital Avionics - an International Perspective,” IEEE AES Magazine, Vol. 27, No. 1, Jan. ‘92, pp. 44-45 

T.H. Robinson , R. Farmer, E. Trujillo: “Integrated Processing,” presented at 14th AIAA/IEEE DASC, Boston/MA, Nov. 1995 

L.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-20 

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 

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-40 

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-21 

J.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-301 

P.S. Babcock: "An introduction to reliability modeling of fault-tolerant systems," Charles Stark Draper Lab. Report CSDL-R-1899 

J. Rushby: “Critical system properties: survey and taxonomy”, Reliability Engineering and System Safety, Vol. 43, 1994, pp. 189-219 

M. 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-12 

S.F. Morris: “Use and Application of MIL-HDBK-217”, J. of the IES, Nov/Dec ‘90, pp. 40-46 

D. 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-362 

R.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-12 

P. Seidenman, D. Spanovich: “Building a better black box”, Aviation Equipment Maintenance, Feb. ‘95, pp. 34-36 

M. Doring: “Measuring the cost of dependability”, Boeing Airliner Magazine, July-Sept 1994, pp. 21-25 

D. Galler, G. Slenski: “Causes of electrical failures”, IEEE AES Systems Magazine, Aug. ‘91, pp. 3-8 

P. 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 


3 

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-194 

W. Reynish: “Three systems, One standard?”, Avionics Magazine, Sept. ‘95, pp. 26-28 

D. Hughes: “USAF, GEC-Marconi test ILS/MLS/GPS receiver”, AW&ST, Dec. 4 ‘95, pp. 96 

R.S. Prill, R. Minarik: “Programmable digital radio common module prototypr”, Proc. 13th DASC, Phoenix/AZ, Nov. ‘94, pp. 563-567 

B.D. Nordwall: “HIRF threat to digital avionics less than expected”, AW&ST, Feb. 14, ‘94, pp. 52-54 

M.J. Morgan: “Integrated modular avionics for next-generation commercial aircraft”, IEEE AES Systems Magazine, Aug. ‘91, pp. 9-12 

D.C. Hart: “A Primer on IMA”, Avionics, April 1994, pp. 30-41 

D.C. Hart: “Integrated Modular Avionics - Part I - V” Avionics, May 1991, pp. 28-40, November 1991, pp. 25-29 

D. Rollema: “German WW II Communications Receivers - Technical Perfection from a Nearby Past”, Part 1-3, CQ, Aug/Oct 1980, May 1981 

A.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-0 

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

P.J. Prisaznuk: “Integrated Modular Avionics”, proc. IEEE NAECON-92, Dayton/OH, May 1992, pp. 39-45 

J.R. Todd: “Integrating controls and avionics on commercial aircraft”, proc. IEEE NAECON-92, Dayton/OH, May 1992, pp. 46-62 

R. Little: “Advanced avionics for military needs”, Computing & Control Engineering Journal, January 1991, pp. 29-34 

R.D. Trowern: “Designing an Inflight Entertainment System”, Avionics Magazine, Oct. ‘94, pp. 46-49 

D. Hughes, M.A. Dornheim: “United DC-10 crash in Sioux City, Iowa”, AW&ST, July 24, ‘89, pp. 96-97 

M.A. Dornheim: “Throttles land “disabled” jet”, AW&ST, Sept. 4, ‘95, pp. 26-27 

B.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-56 

E. Kolano: “Fly by fire”, Flight International, Dec. 20, ‘95, pp. 26-29 

G. Norris: “Boeing may use propulsion control on 747-500/600X”, Flight Int’l, 2-8 Oct ‘96, p. 4 

Anon.: “Engine nozzle design - a variable feast?”, Aircraft Technology Engineering & Maintenance, Oct/Nov ‘95, pp. 10-11 

B. Gal-Or: “Civilizing military thrust vectoring flight control”, Aerospace America, April ‘96, pp. 20-21 

D. 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-23 

R.J. Bleeg: "Commercial JetTransport Fly-By-Wire Architecture Considerations," Proc. AIAA/IEEE 8th DASC, San Jose/CA, October 1988, pp. 309-406 

R. 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-15 

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 

F. 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-38 

Anon.: “Avionics on the Boeing 777, Part 1-11”, Airline Avionics, May ‘94 - June ‘95 

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-183 

G. Bartley: “Model 777 primary flight control system”, Boeing Airliner Magazine, Oct/Dec ‘94, pp. 7-17 

R.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-421 

L. Lamport, R. Shostak, M. Pease: “The Byzantine Generals Problem”, ACM Trans. on Programming Languages & Systems, Vol. 4, No. 3, July ‘82, pp. 382-401 

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 

J.A. Donoghue: “Toward integrating safety”, Air Transport World, Nov. ‘95, pp. 98-99 

D. Carbaugh, S. Cooper: “Avoiding Controlled Flight Into Terrain”, Boeing Airliner, April-June ‘96, pp. 1-11 

M. Slater: “The microprocessor today”, IEEE Micro, Dec. 1996, pp. 32-44 

D. Hildebrand: “Memory protection in embedded systems”, Embedded Systems Programming, Dec. 1996, pp. 72-76 

D. Esler: “Trend monitoring comes of age”, Business & Commercial Aviation, July ‘95, pp. 70-75 

C.A. Shifrin: “Aviation safety takes center stage worldwide”, AW & ST, 4 Nov ‘96, pp. 46-48 


4 

M. Rodriguez, M. Stemig: “Evolution of embedded avionics operating systems”, presented at 14th AIAA/IEEE DASC, Boston/MA, Nov. 1995 

M. Tippins: “FMS Moving toward complete integration”, Professional Pilot, June 1993, pp. 48-52 

F.B. Murphy: “A perspective on the Autonomous Airplane operating in the Global Air Transportation System”, presented to ICCAIA, Everett/WA, March 1992, 13 slides 

J. Townsend: “Low-altitude wind shear, and its hazard to aviation”, Nat’l Academy, Washington/DC, 1983 

F. 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-272 

L.H. Harrison, P.J. Saraceni: "Certification Issues for Complex Digital Hardware," Proc. 13th DASC, Phoenix/AZ, November 1994, pp. 216-220 

V. Riley: "What avionics engineers should know about pilots and automation," Proc. AIAA/IEEE 14th DASC, Boston/MA, November 1995, pp. 252-257 

R.W. Morris: "Increasing Avionic BIT Coverage Increases False Alarms," SAE Communications in Reliability, Maintainability, and Supportability, Vol. 1, No. 2, July 1994, pp. 3-8 

A. Gerold: “The Federal Radionavigation Plan”, Avionics Magazine, May ‘96, pp. 34-35 

Anon.: “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-3 

Anon.: “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-22 

M. 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-0409 

G. Stix: "Toward 'point One' - Trends in Semiconductor Manufacturing," Scientific American, February 1995, pp. 90-95 

G.D. Hutcheson, J.D. Hutcheson: "Technology and Economics in the Semiconductor Industry," Scientific American, January 1996, pp. 54-62 

C. Adams: “Emerging Databus Standards”, Avionics Magazine, March ‘96, pp. 18-25 

K. Hoyme, K. Driscoll: “SAFEbus TM ”, Proc. 11th DASC, pp. 68-72 

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

G. Derman: “Interconnects & Packaging - Part 1: Chip-Scale Packages”, EE Times, 26 Feb. ‘96, pp. 41,70-72 

T. DiStefano, R. Marrs: “Building on the surface-mount infrastructure”, EE Times, 26 Feb. ‘96, pp. 49 

S. Birch: “The hot issue of aerospace electronics”, SAE Aerospace Engineering, July ‘95, pp. 4-6 

J.A. Sparks: “High temperature electronics for aerospace applications”, proc. ERA Avionics Conf., London/UK, Nov./Dec. ‘94, pp. 8.2.1-8.2.5 

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

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

J. 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-25 

K. Sewel: “FED technology threatens LCD in flat-panel race”, Military & Aerospace Electronics, Dec. 1996, p. 19 

BCAG: "777 Application Specific Integrated Circuits (ASIC) Certification Guideline," Boeing Doc. 18W001; also: RTCA Paper No. 535-93/SC180-11, December 1993 

Honeywell Commercial Flight Systems: "ASIC Development and Verification Guidelines," Honeywell Spec. DS61232-01 Rev A, January 1993; also: RTCA Paper No. 536-93/SC180-12 

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

R. 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. 1996 

ARINC 650: IMA Packaging and Interfaces 

ARINC 652: Guidance for Avionics Software Management 

ARINC 653: Standard Application Software Environment for IMA 

ARINC 659: Backplane Data Bus 

ARINC 629: Multi-Transmitter Data Bus 

ARINC-754/755: (analog/digital MMR), ARINC-756 (GNLU)

Integrated and Modular Systems for Commercial ... - Nonstop Systems

Create successful ePaper yourself

Delete template?

Save as template?