Presentation on theme: "July 15, 2005 1 Integrated Modular Avionics (IMA) Trends and Challenges Eric E. Retko Sr. Staff Engineer, Smiths Aerospace Company/Consultant DER"— Presentation transcript:
July 15, 2005 1 Integrated Modular Avionics (IMA) Trends and Challenges Eric E. Retko Sr. Staff Engineer, Smiths Aerospace Company/Consultant DER email@example.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 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
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 Platform vs. 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 Integration reduced 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 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? Moores 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-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.
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