July 15, 2005 1

Integrated Modular Avionics (IMA) Trends and Challenges

Eric E. Retko Sr. Staff Engineer, Smiths Aerospace

Company/Consultant DER eric@der-faa.com

July 15, 2005 2

Topical Outline

What is IMA per RTCA SC-200 def ? What are some of the Challenges? Where is IMA heading ? What is needed to support the future of

IMA? Open Discussion / Q & A

July 15, 2005 3

RTCA SC-200 Document “DO-IMA” draft in work Integrated Modular Avionics defined: “IMA is a shared set of flexible, reusable, and interoperable hardware and

software resources that, when integrated, form a platform that provides services, designed and verified to a defined set of safety and performance requirements, to host applications performing aircraft functions.”

Six tasks define the incremental acceptance of IMA systems in the certification process:

Task 1: Module acceptance Task 2: Application software/hardware acceptance Task 3: IMA system acceptance Task 4: Aircraft integration of IMA system - including Validation and Verification

(V&V) Task 5: Change of modules or applications Task 6: Reuse of modules or applications Approval of an IMA system installation may be based on the accumulation of

incremental acceptance, culminating in the complete design assurance needed to demonstrate that the installed system and functions comply with the applicable regulations and guidance

July 15, 2005 4

RTCA SC-200 Output

Significant to the IMA community, Why? Portable and recognized certification credit for

module and application “acceptance” letters for HW, SW or both.

The continued support of Industry and Certification authorities is needed to complete the final issuance of this document and its recognition as an acceptable means via an FAA AC and the EASA equivalent.

July 15, 2005 5

IMA: A word about the Challenges

• Maybe this topic was chosen because it’s easier to talk about what not to do !

• Disclaimer; Any examples, especially bad ones, are fictitious, even if it sounds real and you think you know who did it !

• Some examples or themes:

• How to do a preliminary safety analysis PSSA or FHA without specific function (unallocated IMA platform) FHA without the “F”

• Outdated specs, processes and methods

• Outdated/lagging guidance and regulations

• Lagging open standards

• FAA acceptance of new standards, technology and methodology

• FAA coordination too early, too late, not enough

July 15, 2005 6

Challenge: The Resource Allocation Process- Getting it right Who and What will host on the system and who make the trades for hosted vs. non hosted

applications? What SW and HW criticality levels will be supported ? Estimates of computing horsepower, MIPs, and memory requirements, SLOC estimates,

WCETs…. Computing throughput benchmarking …This always stirs debate Network bandwidth, control loop times, latency bounds, jitter I/O types and quantities to support new and legacy equipment Redundancy, separation, and availability requirements (multiple HW/SW copies and data

paths) Which federated LRUs will “hitchhike” on the IMA data bus? Who will manage the ICD and how does the information flow into the Requirements

Capture and V&V process? Compounding margins issue (padded resource estimates)

Get realistic estimates and revise them often as program design progresses

A scalable architecture provides a less painful out if initial requirements estimates prove to be off

July 15, 2005 7

Challenges: Convincing Suppliers to Host on the IMA Platformvs. Federated System

Early IMA programs suffered from a tendency for hosted function vendors to quote similar system price (or more) for a system without his traditional black box.

Trade studies (and encouragement) needs to be applied at the Aircraft level.

July 15, 2005 8

Challenges: Overcoming the Black Box Mentality : As suppliers move up the value chain and become responsible

for system level and aircraft level integration, a tendency toward their old “black box” mentality may exist. The result can be to not optimize the system in a manner that considers the big picture, keep “doing things the way we always have”, or worse yet assuming that “the integrator” must be doing that.

A strong system engineering group and knowledgeable DERs with heavily front loaded involvement is the best mitigation. Systems engineering should guide the HW,SW, and systems processes, allocate requirements, and determine optimum aircraft level solutions.

July 15, 2005 9

Challenge: The Requirements Capture Process- Getting it right

Have a system for requirements flow between platform partners and hosted functions

Establish requirements that are traceable, verifiable,

testable, unambiguous, and of course correct.

July 15, 2005 10

FAA/DER Challenges:

• How to manage and provide adequate FAA/ DER oversight of the complex and many tiered Partnering arrangements and the flow down of responsibilities and certification support.

• Coordinating multiple vendor cert engineers across varying locations and ACOs.

July 15, 2005 11

Challenges: COTS Hardware

Bottoms up technology flow means Consumer goods such as PCs, games and cell phones drive COTs component evolution, making vendors less responsive to “Aerospace Specific” safety driven demands

Limited or no availability of development data to support a DO-254 Design Assurance approach• DO-178B testing combined with other V&V has historically been

used to exercise and certify the COTs system components Change Control and notification difficult to negotiate Field service history often limited to internal company data

• Limited sharing of failure data, PRs, errata, etc Need better information database collection and sharing via

Industry groups RTCA, SAE, or Cert authorities. ( AVSI, Stack International have made some progress)

July 15, 2005 12

Challenge: HW Component Obsolescence

Obsolescence Management Issues Demand for latest and greatest performance compete against

obsolescence and accumulated service experience Solutions:

• Lifetime or lastime buys• Planned technology insertion points, CPU and memory upgrades

w/ backward compatibility to the applications• Minimize future compatibility risk by avoiding use of special

instructions etc. to insure backward compatibility to the applications

• Have a strategy in place for the identification and mitigation of the effects of obsolescence.

July 15, 2005 13

Other Misc Challenge Areas

Test Platforms and SW Development Environments Reuse and Cost Of Change Distributed V and V PR Consolidation across companies Platform and HW/SW Config mgmt and compatibility checking Configuration Tools BITE Intermixing of HW/SW criticalities on data busses or in

cabinets. Examples:• Hardware VL protection on AFDX

• Protecting the shared cabinet resources from Low Integrity hosted hardware modules

July 15, 2005 14

Misc Challenges cont.

Independent and concurrent development of platforms and hosted applications

Legacy SW hosting Platform and OS Support of multiple programming languages Coding standards alignment Incremental qualification of the platform and applications

• Artifacts flow to suppliers and Support of hosted TSOs• Environmental qual of hosted TSOs• Protection of proprietary data and IP while sharing

responsibilities

July 15, 2005 15

Challenges: The “Tears” of Integration

Configuration Tools Dispatch and redundancy issues Support of hosted function issues Health Management and Fault Consolidation

July 15, 2005 16

Roles and Responsibilities

Each program has unique arrangements Extremes of IMA supplier roles

• One or two suppliers writing the software and providing all the hardware

• Many suppliers writing SW and multiple vendors providing hardware

Integration responsibilities may be shared Regardless of arrangements, usually the

Aircraft integrator is ultimately responsible, especially in the eyes of the Cert Authorities

July 15, 2005 17

IMA Roles and Responsibilities

July 15, 2005 18

Challenges: Multiple Tiers of Suppliers

Multiple Companies Subs, Subs of subs, and so on……… Multiple DERs Multiple ACOs Global partners EASA involvement

Be prepared for unique partnering arrangements !

July 15, 2005 19

IMA Programs Can Make for Strange Bedfellows

May be Partners on one program while competing on another

Protecting data rights while sharing openly

Be nice to your partners and competition, who knows what the next program will bring!

July 15, 2005 20

Challenge: Network Security Considerations

Network security considerations played a relatively minor role in the certification of federated systems because of the isolation, protection mechanisms and limited connectivity between these networks.

IMA systems trending to greater interconnectivity between secure and open networks. Examples:

• Maintenance data

• Data load Solutions: Level A firewalls, ground only maintenance interlocks, or other

methods.

July 15, 2005 21

The Fears of Integrationreduced independence… reduced diversity…. unintended coupling…..

On August 14, 2003, large portions of the Midwest and Northeast United States and Ontario, Canada, experienced an electric power blackout. The out age affected an area with an estimated 50 million people and 61,800 megawatts (MW) of electric load in the states of Ohio, Michigan, Pennsylvania, New York, Vermont, Massachusetts, Connecticut, New Jersey and the Canadian province of Ontario. The blackout began a few minutes after 4:00 pm Eastern Daylight Time (16:00 EDT), and power was not restored for 4 days in some parts of the United States. Parts of Ontario suffered rolling blackouts for more than a week before full power was restored.

A lesson from another industry: protect yourself from the other guys anomalous behavior and look well beyond the obvious for common mode/common cause sources.

July 15, 2005 22

IMA Has Become More Than Modules in a Rack! Cabinets Power supplies General Processing Modules I/O modules NICS Switches Graphics cards Data storage Fiber/copper translators Application Specific Modules

July 15, 2005 23

IMA Systems May Include Other LRUs in Addition to Modules in Multiple Cabinets or Racks

Remote data concentrators (RDCs) Remote network switches RPDUs, SPDAs Other LRUs that may provide generic or specific

aircraft functions that share the network backplane power, or other resources

Federated LRUs may share the same network Thus flexibility is required in bounding the IMA

system

July 15, 2005 24

Major Contributions in IMA Evolution to Date: EMB-170/Cessna/Falcon Primus EPIC, Honeywell B777 AIMS, Honeywell C-130 AMP, Smiths B767 Tanker, Smiths A380, Airbus/Thales B787, CCS Smiths Others

July 15, 2005 25

Enablers: Why we are here? Moore’s Law (MIPS Doubles 18-24 months)

July 15, 2005 26

The IMA “ENABLERS”

Microprocessor evolution -CPUs Open Architectures Commercial partitioned RTOs APIs such as AE653 Data Bus Bandwidths

July 15, 2005 27

IMA Enablers: Open Architecture

Real Time Operating Systems (RTOS) The availability of AE653 API based COTs

RTOs is a large contributor. The partitioned OS allows for hosting of

unrelated functions without unintended coupling.

July 15, 2005 28

Enablers: TSO-C153

Allows for individual module credit only, but not for module to module or platform integration or for the integrated HW/OS.

Perhaps a future TSO-C153 revision or a new TSO

could allow for approval of a Hosted application ready IMA system that includes the OS.

July 15, 2005 29

Enablers: Data Bus Advances are Key to IMA Present and Future

MIL STD 1553 ARINC 429 ARINC 629 Firewire 1394b CAN TTP Ethernet ASCB– ERJ-170 AFDX---A380 , B787 Fibre Channel 2Gbit -- F18, F35, C-130 AMP Safebus -----777

Fiber optic continues to replace copper due to its bandwidth and EME tolerance in many cases

July 15, 2005 30

IMA Seems to Attract Significant Attention From the Cert Authorities

Good News: The cert authorities tend to task their A team with IMA programs

Bad News: The cert authorities tend to task their A team with IMA programs

So….Be prepared to use their help and keep them well informed !

July 15, 2005 31

HW and Systems Design Assurance…. DO254 finally officially recognized in AC20-152 !!! ARP4761/4754 update in progress S-18—Airplane Safety

Assessment Committee The term “Level A HW” is based on context of the above For level A systems:

• The entire HW and System development process should be be structured, not just the CEH/ASIC/PLD. If not following DO-254, then there should be acceptable company processes in place.

July 15, 2005 32

FAA Interface Challenges, from the DER perspective Accepting new standards Accepting new methodologies Dealing with the many players and coordinating across

multiple ACOs Concurrent and incremental acceptance. FAA is taking a

conservative approach for now that tends to defer any award of TSOs or other equipment approvals until near TC or STC award

Difficulties delegating more as complexities and new technologies are introduced while facing internal resource constraints

July 15, 2005 33

Useful IMA Guidance ARP 4761, Guidelines and Methods for Conducting the Safety Assessment

Process on Civil Airborne Systems and Equipment ARP 4754, Certification Considerations for Highly Integrated or Complex

Aircraft Systems TSO-C153, Integrated Modular Avionics Hardware Elements AC20-145, Guidance For Integrated Modular Avionics (IMA) That Implement

TSO-C153, Authorized Hardware Elements SC-200 RTCA WP#400, “DO-IMA” coming soon AC20-148, Reusable Software Components ARINC 653 Avionics Application Software Standard Interface RTCA DO-254, Design Assurance Guidance for Airborne Electronic

Hardware RTCA DO-178B, Software Considerations in Airborne Systems and

Equipment Certification

July 15, 2005 34

Where May IMA Technology Be Heading? More COTs HW modules Closed loop control, FADECS Flight controls Lower cost and more GA and 14 CFR 23 aircraft, RPVs HUMS/fatigue monitoring Artificial intelligence Airborne Interconnectivity internet and data More Video processing More non critical functions hosted as cost come down More of the connectivity theme Neural networks Adaptive structures Technology may flow both up and down from GA to transport

July 15, 2005 35

Trend may be Towards Distributed IMA

July 15, 2005 36

Superceding Technologies ?? What trends may cause an “Integration Reversal”? Reduced dependencies on shared cabinet resources, ex;

advances in power conditioning and lower wattages reduce the need for cooling provided by Cabinet or ECS.

Smaller cheaper computing resources and I/O devices can be placed closer to the sensors and effectors with less urgent need to combine functions, lessening zonal hazard exposure

Miniature connectors allow for more I/O to smaller LRMs Wireless networking CPU cooling and power conditioning improvements Note that the importance of the Network still likely prevails Eventually will we see throw away LRMs? Other comments?

July 15, 2005 37

Open Discussion

Open Discussion seeds:• General Q&A

• Where do we go from here?

• More COTs modules? Standard HW interface?

• What does industry need from FAA ?

• What does FAA need from industry ?

• What will IMA systems look like in 10-15 years?

July 15, 2005 38

Thanks !

Open discussion topics