Considering Object Oriented Technology in Aviation Applications

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

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

• “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

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

• 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?

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

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

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

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

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

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

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

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

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