Transcript 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 Conference
October 15, 2003
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
2
“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
3
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
4
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 objectoriented software in compliance with DO-178B
• NASA Langley has supported OOTiA by leading
workshops and supporting research
5
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
Data Analysis and Guideline Development
• Adapt AVSI guidelines, as appropriate
– adding other guidelines as needed
• Produce a Handbook for Object Oriented
Technology in Aviation (expected in ‘04)
6
OOTiA Handbook
Handbook for Object-Oriented
Technology in Aviation (OOTiA)
• 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
7
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
8
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
9
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-safetycritical systems
?
Advantages for
safety-critical
systems
10
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
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
12
Project Characteristics
Question 2: What project characteristics are
important with respect to OOT?
• 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
13
OOT Specific Resources
Question 3: What project resources, specific to
OOT, are needed?
• 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 DO178B
14
OOT Specific Resources (cont)
• OO tools introduce levels of abstraction that may
not clearly correspond to abstraction levels (highor 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
15
Level of FAA Involvement
Project characteristics
+
OOT specific resources
influence the level of
involvement that the
FAA has with a project
• Level of FAA involvement will dictate
– the number of software reviews, the stages of involvement,
and the nature of the reviews
– non-trivial consideration
16
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?
17
Influence
Handbook for Object-Oriented
Technology in Aviation
(OOTiA)
• The OOTiA handbook will influence the
approval process for an OO program
– but, does not eliminate the need for
compliance with DO-178B
The handbook is not
intended to be official
FAA policy or
guidance
– the intent is to provide guidelines for how to
use OOT to comply with the DO-178B
objectives
• 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
18
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
19
Requirements Challenge
• Is OOT is the correct approach for requirements
development and implementation for safety-critical
systems?
functional
decomposition
Decomposing
requirements
by
functionality
Verifying
increasing
functionality
object
orientation
objects &
operations
functionality
can be
widely
distributed
• Federal Aviation Regulations call for assurance of intended
functionality and assurance of no unintended functionality
20
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?
21
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
22
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
23
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
24