Federal Aviation
1 / 13

Federal Aviation Administration 0 Complex Integrated Avionics ... - PowerPoint PPT Presentation

  • Updated On :

Federal Aviation Administration. Complex Integrated Avionic Systems and System Safety. Presentation to: Europe/U.S. International Aviation Safety Conference Name: Ali Bahrami Date: June 9, 2005. Electronic flight inst. Ex. 757/767. Integrated display system

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Federal Aviation Administration 0 Complex Integrated Avionics ...' - Pat_Xavi

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Federal Aviation


Complex Integrated Avionic Systems and System Safety

Presentation to: Europe/U.S. International Aviation Safety ConferenceName: Ali Bahrami

Date: June 9, 2005

Trends in avionics integration and complexity l.jpg

Electronic flight inst.

Ex. 757/767

Integrated display system

Ex. 747-400

Expanded IMA

Ex. Falcon EASy, ERJ-170

Integrated Mod Avionics (IMA)

Ex. 777

  • Integration within closely related functions

  • Most functionality in hardware/firmware

  • Integration of most display-related avionics functions

  • Most functionality re-programmable

  • Integration of avionics + some flt. control and airplane systems

  • More generic processors & software-based functionality

Trends in Avionics: Integration and Complexity




  • Integration of many avionics functions

  • Card-based processors in cabinet racks

Trends in avionics architectures l.jpg
Trends in Avionics: Architectures

  • Huge increases in:

    • Functional integration.

    • Software size and complexity.

  • Shift in techniques for isolation/independence:

    • Traditionally, redundant features were completely isolated – now they communicate with each other.

    • High/low criticality functions traditionally physically isolated from each other – now share computing and databus resources.

  • Mix of new and reused (“legacy”) software.

Trends in avionics tso l.jpg
Trends in Avionics: TSO

  • TSOs:

    • Traditionally, TSOs were used for simple equipment (e.g. seat belts) and well-defined “stand-alone” functions (e.g. air speed indicator). Installation issues were minimal.

    • Now, TSO requirements cover only a small fraction of the designed functionality.

    • TSO functionality may be embedded in an integrated avionics suite (“functional TSO”).

    • Vendors need TSOA to ship “brain-dead” hardware which doesn’t comply with the full TSO requirements until installed and software is loaded.

Trends in avionics engineering and business practices l.jpg
Trends in Avionics: Engineering and Business Practices

  • Increasing dependence on Commercial Off-the-Shelf (COTS) hardware and software. Examples:

    • Microprocessors (from PC industry).

    • Operating systems (e.g. Windows).

    • Graphic processors (from video game industry).

  • Changes in manufacturer-vendor relationships and responsibilities.

  • Global design and manufacturing of highly integrated avionics functions.

  • Shift from airframe manufacturer as “designer/builder” to “integrator/assembler.”

Certification challenges l.jpg
Certification Challenges

  • Integration and complexity:

    • Current processes (e.g. DO-178B/ED-12B for software) were developed with much simpler architectures in mind.

    • Experience is showing that there are complex and often unexpected “connections” between traditionally unrelated or independent functions, especially during failures.

    • Failures become more difficult to predict and diagnose.

    • It becomes less and less feasible to test all inter-related failure modes.

    • Fully integrated test facilities become more challenging and expensive to build and operate.

Certification challenges7 l.jpg
Certification Challenges

  • Software:

    • Software-based isolation and independence is much more “fluid” and difficult to assure than relying on hardware.

    • Mixing of COTS, reused, and new software – all developed by different processes and to different standards – makes assessing the safety issues much more difficult, especially in standardized ways.

Certification challenges8 l.jpg
Certification Challenges

  • “Functional” TSO:

    • Difficult to separate TSO issues from installation issues

      • TSO’d function may be part of the software that resides on a circuit card.

      • TSO compliance can only be assessed when installed in the host system.

      • Even simple issues like part marking become complicated.

      • TSO change processes were not developed with these complex TSO “packages” in mind.

  • Engineering and Business practices:

    • COTS products are not developed to traditional aviation standards.

    • Detailed certification data and knowledge often resides at vendor rather than manufacturer.

How the authorities have responded l.jpg
How the Authorities Have Responded

  • The authorities have already taken a number of actions to support recent IMA trends and specific projects, including:

    • Development of IMA AC and TSO.

    • Development of an Order on software reuse.

    • Approval of functional TSOs.

    • Numerous DO-178B/ED-12B “workarounds.”

    • Additional relevant guidance is in work.

  • However, continued industry support is needed…

What is needed to support the trend l.jpg
What is Needed to Support the Trend?

  • Current software certification methods did not envision modern IMA architectures, so we need new methods…

    • That are equally effective in ensuring safety…

    • While supporting the certification of IMA.

  • The current TSO process is not well-suited for embedded software functions, so we need new approaches to TSOA…

    • Which allow design and production approval for traditional TSO functions in IMA architectures…

    • While protecting the level of safety provided by type certification processes.

What is needed to support the trend11 l.jpg
What is Needed to Support the Trend?

  • When manufacturers out-source development and test:

    • New processes for authorities/manufacturer/vendor communication are needed.

  • Testing:

    • Testing of the IMA “pieces” will not find integration problems.

    • The actual airplane is not an adequate test environment for many IMA issues.

    • Full-scale integration test facilities may not be commercially viable.

    • Industry needs to help develop new approaches to integration testing that will find and characterize IMA problems before certification.

Authority industry partnership l.jpg
Authority-Industry Partnership

  • Cooperation is needed more than ever.

    • Traditional certification processes were developed to match past commercial practices

    • The pace of change is increasing

  • Industry will need to lead the effort to develop new methods of compliance.

    • New methods cannot just “do less” – they MUST preserve, and where possible, improve the level of safety.

    • Focus on safety-related issues while with IMA, it is more difficult to separate what is or is not “safety-related.”

Summary and future perspectives l.jpg
Summary and Future Perspectives

  • The authorities support industry’s efforts to advance the technology

    • Historic cooperation between the authorities and industry has been essential in developing viable and effective methods of compliance and safety assurance.

  • Cooperation is even more critical as we collectively support rapid technological advances while at the same time increase the level of safety.

  • Potential broader issue: Does the overall safety assessment process need to be revisited, to account for the migration of functionality (and failure conditions) from hardware to software?