1. Considering Object Oriented Technology in Aviation Applications Kelly J. Hayhurst and C. Michael Holloway NASA Langley Research Center Hampton VA 23681-2199 Presented at the 22nd Digital Avionics Systems Conference October 15, 2003

2. 2 Outline Background Object Oriented Technology in Aviation (OOTiA) Project Making the decision to use OOT in an aviation application – 5 high-level questions to ask before committing to a program using OOT Summary

3. 3 “What is object oriented programming? My guess is that object oriented programming will be in the 1980’s what structured programming was in the 1970’s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.” - T. Rentsch. Object Oriented Programming. ACM SIGPLAN Notices, 17(9):51-57, Sept. 1982

4. 4 OO Dilemma Object Oriented Technology (OOT) is popular in many industries – but is seldom used in the aviation industry Current regulatory objectives were formulated largely from a structured programming perspective There is much conservatism in determining how regulatory objectives can be met using OOT

5. 5 Object Oriented Technology in Aviation (OOTiA) Project The OOTiA project is sponsored by the FAA to develop recommendations for safe use of OOT in compliance with DO-178B Based initially on work conducted by the Aerospace Vehicle Systems Institute (AVSI) – Boeing, Goodrich, Honeywell, and Rockwell Collins – proposed a number of guidelines for producing object- oriented software in compliance with DO-178B NASA Langley has supported OOTiA by leading workshops and supporting research

6. 6 Approach Data Analysis and Guideline Development Data Collection Public workshops for the aviation software community to debate issues – April ‘02 and March ‘03 Web site (since Sep ‘01) for collecting data on safety and certification issues with OOT http://shemesh.larc.nasa.gov/foot/ Adapt AVSI guidelines, as appropriate – adding other guidelines as needed Produce a Handbook for Object Oriented Technology in Aviation (expected in ‘04)

7. 7 OOTiA Handbook 4 ~independent volumes Vol 1: Project Overview Vol 2: Concerns, Issues, and Questions Vol 3: Best Practices & Patterns Vol 4: Certification Practices Much of the handbook focuses on guidelines for how to use OOT – assumes the decision to use OOT has been made Handbook for Object-Oriented Technology in Aviation (OOTiA)

8. 8 Beyond the Handbook “Beyond the Handbook” was a special session at the 2nd OOTiA workshop to discuss questions that should be answered before the decision to use OOT is made What things do you need to consider when deciding whether or not to use OOT? The session produced 51 questions related to making a decision about whether to use OOT

9. 9 Areas to Consider Abstracted the 51 questions to a set of 5 high-level questions related to – Assessing the reality of the benefits of OOT – Knowing project characteristics – Identifying OOT specific resources – Understanding regulatory guidance for software – Recognizing technical challenges for implementing OOT in aviation applications The questions should be answered satisfactorily before committing to use OOT

10. 10 Reality of Benefits OOT is often claimed to be a more natural form of problem solution – resulting in heavier reuse than traditional alternatives Question 1: What are the benefits of OOT compared with current or alternative approaches? And, what evidence exists to support claimed benefits of better, cheaper, faster, safer, more reliable, more maintainable, etc.? Advantages claimed for OOT in non-safety- critical systems Advantages for safety-critical systems ?

11. Evidence “Our greatest need now, in terms of future progress rather than short-term coping with software engineering projects, is not for new languages or tools to implement our inventions, but for more in-depth understanding of whether our inventions are effective and why or why not.” - from “High-Pressure Steam Engines and Computer Software”, by Dr. Nancy Leveson, Computer, October 1994

12. 12 Lots of Data, but … Success stories, metrics, and lessons learned about using OOT are abundant – mostly in the non-safety critical communities Empirical evidence is scarce – Studies by Vessey & Conger and by Moynihan show benefits of structured methods over OOT

13. 13 Project Characteristics Product characteristics – size, criticality, and complexity of the software – maturity of the software requirements – applicability of OOT to the specific problem domain Product-line characteristics – Is the software a new product or part of a product family?  Has this product-type been certified before? – long-term upgrade and maintenance requirements Question 2: What project characteristics are important with respect to OOT?

14. 14 OOT Specific Resources Personnel resources at the individual and corporate levels – training and experience with OO methods for modeling, design, analysis and testing, and with OO tools  also a concern for regulators responsible for the software approval on the project being reviewed Administrative resources – industry standards for OOT  Object Management Group standard for OO modeling with the Unified Modeling Language – standards for OO languages – internal process standards  how those map to activities and data specified in DO- 178B Question 3: What project resources, specific to OOT, are needed?

15. 15 OOT Specific Resources (cont) OO tools introduce levels of abstraction that may not clearly correspond to abstraction levels (high- or low-level requirements or design) in DO-178B – for example, the visual model level Factors to consider for tools: – compatibility of new OO tools with existing tools, notations, and processes – configuration management – training – qualification costs

16. 16 Level of FAA Involvement Level of FAA involvement will dictate – the number of software reviews, the stages of involvement, and the nature of the reviews – non-trivial consideration Project characteristics + OOT specific resources influence the level of involvement that the FAA has with a project

17. 17 Regulatory Guidance DO-178B is not explicitly method specific –Are all of the objectives in DO-178B compatible with OOT? –Does an OOT-specific handbook imply the need for additional method-specific handbooks? How should the handbook be applied to a practical project, and is the handbook adequate? Question 4: How should regulatory guidance, including DO-178B and the OOTiA handbook, be applied in a practical project?

18. 18 Influence The trick is to provide clear guidelines – and clearly communicate those guidelines to regulators and software developers – misunderstandings between regulators and developers are another source of The handbook is not intended to be official FAA policy or guidance The OOTiA handbook will influence the approval process for an OO program –but, does not eliminate the need for compliance with DO-178B –the intent is to provide guidelines for how to use OOT to comply with the DO-178B objectives Handbook for Object-Oriented Technology in Aviation (OOTiA)

19. 19 Technical Challenges Requirements Verification Safety Question 5: What are the technical challenges in applying OOT to ensure the appropriate level of integrity required for the project?

20. 20 Requirements Challenge Is OOT is the correct approach for requirements development and implementation for safety-critical systems? functional decomposition object orientation Decomposing requirements by functionality Verifying increasing functionality objects & operations Federal Aviation Regulations call for assurance of intended functionality and assurance of no unintended functionality functionality can be widely distributed

21. 21 Verification Challenge “object oriented programs are generally more complex than their procedural counterparts. This added complexity results from inheritance, polymorphism, and the complex data interactions tied to their use. Although these features provide power and flexibility, they increase complexity and require more testing” - Roger Alexander, “Improving the Quality of Object-Oriented Programs,” IEEE Software, September/ October 2001, pp. 90-91 Are the objectives in DO-178B sufficient to cover this?

22. 22 Verification Challenges cont. General verification questions: – Can we adequately analyze OO software?  Can we do source to object code traceability, and control and data flow analysis? – Can we adequately test OO software? – Can we determine the error cases unique to OOT? Research by Jeff Offutt and others have shown new error classes in OO programs – additional research is needed to better understand the extent that existing methods are adequate for verifying OOT

23. 23 Safety Challenge Can system and safety assessments can be easily and accurately derived from an OO program? Safety analysis is often based on determining that an implemented function is both correct and safe – OOT complicates this analysis because operations related to a function can be widely distributed, making the function difficult to trace Safety analysis is not part of the life cycle activities specified in DO-178B – but, the effect of OO design and implementation on safety analysis should be carefully considered

24. 24 Summary Although the questions posed here are directed towards OOT -- they are valid for examining any new software development method The popularity of OOT does not guarantee its propriety for safety-critical systems Introducing new technologies within a context requiring compliance with safety regulations is – not simple and not swift  and that’s not necessarily a bad thing