Considering Object Oriented Technology in Aviation Applications

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

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. Beyond the Handbook What things do you need to consider when deciding whether or not to use OOT? • “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 • The session produced 51 questions related to making a decision about whether to use OOT

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. Reality of Benefits 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.? • OOT is often claimed to be a more natural form of problem solution • resulting in heavier reuse than traditional alternatives ? 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. 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. 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 Project Characteristics Question 2: What project characteristics are important with respect to OOT?

14. 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 OOT Specific Resources Question 3: What project resources, specific to OOT, are needed?

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. Level of FAA Involvement • Level of FAA involvement will dictate • the number of software reviews, the stagesof 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. Regulatory Guidance Question 4: How should regulatory guidance, including DO-178B and the OOTiA handbook, be applied in a practical project? • 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?

18. Influence • 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) • 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

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

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

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