Integrated Modular Avionics (IMA) Trends and Challenges

1
Integrated Modular Avionics (IMA) Trends and
Challenges

• Eric E. Retko
• Sr. Staff Engineer, Smiths Aerospace
  Company/Consultant DER
• eric_at_der-faa.com

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

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 (VV)
• 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

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.

5
IMA A word about the Challenges

• Maybe this topic was chosen because its 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

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

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.

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.

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.

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.

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

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.

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

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

15
Challenges The Tears of Integration

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

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

17
IMA Roles and Responsibilities
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 !

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!

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.

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
  outage 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 400 pm Eastern Daylight Time (1600 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.

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

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

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

25
Enablers Why we are here? Moores Law (MIPS
Doubles 18-24 months)
26
The IMA ENABLERS

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

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.

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.

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

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 !

31
HW and Systems Design Assurance.

• DO254 finally officially recognized in AC20-152
  !!!
• ARP4761/4754 update in progress S-18Airplane
  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.

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

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

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

35
Trend may be Towards Distributed IMA
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?

37
Open Discussion

• Open Discussion seeds
• General QA
• 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?

38
Thanks !

• Open discussion topics