Data Coupling and Federal Aviation

Administration

Control Coupling
Integration Verification
Completion Criteria

Presented to: FAA Software/CEH Conference

By: Will Struck, FAA TAD ANM-111
Date: 27 July 2005
Presentation Overview

Data Coupling and Control Coupling Analyses

 Definitions
 History and References
 DO-178B, DO-248B, CAST Paper P-19
 03 Reno Conference Brainstorming Session
 Reno Feedback
 Challenges
 Questions

Data Coupling and Control Coupling Analyses Federal Aviation 2 2

27 July 2005 – Will Struck Administration
Definitions
• Coupling – the degree of dependence of one module upon
another; specifically, a measure of the chance that a defect in
one module will appear as a defect in the other, or the chance
that a change to one module will necessitate a change to
another.[*MPJ – Meilir Page-Jones, The Practical Guide to
Structured Systems Design, 1980]
- [software] The manner and degree of interdependence
between software modules. … Contrast with: cohesion.
[^IEEE Std 100-1992, Std. Glossary of EE Terms]
• Data Coupling – a form of coupling in which one module
communicates information to another …[*MPJ]
- A type of coupling in which output from one software
module serves as input to another module. [^IEEE]
- The dependence of a software component on data not
exclusively under the control of that component. [DO178B]

Data Coupling and Control Coupling Analyses Federal Aviation 3 3

27 July 2005 – Will Struck Administration
Definitions (Cont.)
• Control Coupling – a • Partitioning – a technique
type of coupling in which for providing isolation
one module communicates between functionally
information to another
independent software
module for the explicit
purpose of influencing the components to contain
execution of the latter. and/or isolate faults
[*MPJ] [DO-178B]
- The manner or degree by
which one software • Interface – a shared
component influences the
execution of another (common) boundary
software component. [^IEEE]
[DO-178B]

Data Coupling and Control Coupling Analyses Federal Aviation 4 4

27 July 2005 – Will Struck Administration
Definitions (Cont.)
• Data Flow – a pipeline along
which information of known data
composition is passed. [*MPJ]
- The sequence in which data
transfer, use and transformation
are performed during the execution
of a computer program. Contrast
with Control Flow. [^IEEE]
• Control Flow – The exe
sequence in which
operations are performed
during the execution of a
computer program. [^IEEE]

Data Coupling and Control Coupling Analyses Federal Aviation 5 5

27 July 2005 – Will Struck Administration
Previous Presentations
• FAA Software
Conferences
 2003 Reno Data &
Control Coupling
Brainstorming Session,
Rierson & Struck
 1998 Software
Coupling, Paasch

Data Coupling and Control Coupling Analyses Federal Aviation 6 6

27 July 2005 – Will Struck Administration
Previous Discussions & Papers
• RTCA DO-248B, Final Report for Clarification of DO-
178B “Software Considerations in Airborne
Systems and Equipment Certification”, Oct. 12,
2001: FAQ #67 (page 52) “What are data coupling
and control coupling and how are they verified?”
• * Data and Control Coupling Brainstorming
Session, 2003 FAA National Software Conference
(Reno), September 19, 2003 (and captured
feedback)
• CAST Position Paper 19: Clarification of Structural
Coverage Analyses of Data Coupling and Control
Coupling, Rev 2, January 2004 (Updated after Reno)

Data Coupling and Control Coupling Analyses Federal Aviation 7 7

27 July 2005 – Will Struck Administration
Purpose of Data Coupling Analysis *

• Completion check of the integration testing

• Verify design and architecture were implemented
• Identify and verify data dependencies and interfaces between
components, and identify inappropriate data dependencies
• Define and evaluate interface depth
• Determine and minimize data coupling interdependencies
• Determine and maximize cohesion
• Verify memory management
• Evaluate accurate use of global data and parameters
• Evaluate input/output data buffers
• Bound impact of changes and requirements effects

Data Coupling and Control Coupling Analyses Federal Aviation 8 8

27 July 2005 – Will Struck Administration
Purpose Control Coupling Analysis *

• Completion check of • Define & evaluate

the integration testing interface depth
• Verify design and • Assist in verifying
architecture were scheduling
correctly implemented • Assist in worst-case
• Identify and verify execution timing
control dependencies analysis
• Verify correct • Bound impact of
execution call changes and
sequence requirements effect(s)

Data Coupling and Control Coupling Analyses Federal Aviation 9 9

27 July 2005 – Will Struck Administration
Common Approaches *
Data Coupling Analysis
• Evaluate number, type, range, and order of
data to function calls through testing &
analysis.
• Minimize and verify use of global data.
• Evaluate read/write access & memory
management.
• Data coupling analysis coverage may be a
by-product of good normal range and
robustness requirements-based tests.

Data Coupling and Control Coupling Analyses Federal Aviation 10 10

27 July 2005 – Will Struck Administration
Common Approaches *

Control Coupling Analysis

• Produce a malicious/rogue process
• Perform call tree analysis/review
• Use qualified tool to build actual call tree
during testing & compare to the design call
tree
• Use testing to assist control flow analysis
(using breakpoints to analyze proper
operation and sequence)

Data Coupling and Control Coupling Analyses Federal Aviation 11 11

27 July 2005 – Will Struck Administration
CAST Position
• More concern of data coupling and control coupling analyses
due to:
– Increases in software complexity and integration
– Increases in the size of projects
– Combining formerly separate functions, use of partitioning and other
protection mechanisms
– Increased use of object-oriented technology (OOT) and other methods
– Increased use of COTS software and general purpose
– Increased reliance on tools
– Proposals for unconventional methods
• Data coupling analysis and control coupling analysis are
performed for Software Levels A, B, and C applications.

Data Coupling and Control Coupling Analyses Federal Aviation 12 12

27 July 2005 – Will Struck Administration
Selected Comments on CAST Paper* (1)

• Clarify the separation between design and

verification. Benefits of good design to help meet
the objective.
• Two aspects: Identify design up front (must be
tracked). And verify later. Should clarify the
relationship between up front and end of day
activities.
• Focus on architectural aspects. Verification of the
architecture.
• Data dependence and control dependence relations
are addressed (data flow & control flow are verified
where the dependencies exist)

Data Coupling and Control Coupling Analyses Federal Aviation 13 13

27 July 2005 – Will Struck Administration
Selected Comments* (2)
• Focus on purpose of • Purpose of coupling
data coupling and analysis is to identify
control coupling dependencies inherent
in the design which
analyses
may not be adequately
• Put in to address tested by requirements-
coverage of integration based testing, and
testing and part of identify inappropriate
structural coverage to dependencies.
ensure that there is a • Satisfying this
complete suite of objective happens
integration tests during integration.

Data Coupling and Control Coupling Analyses Federal Aviation 14 14

27 July 2005 – Will Struck Administration
Selected Comments* (3)
• Partitioning and inter-process communication
sections make mention of data & control. Meant to
look at data and control flow across partitioning
boundaries. (Fred’s input)
• Suggestions for addressing the issue:
– Clarify primary purpose of DC/CC: confirmation of the
integration
– Come up with a workable definition of “component” in this
context.
– Workable definition of DC/CC in this context. Specializations
of data flow and control flow between these components.

Data Coupling and Control Coupling Analyses Federal Aviation 15 15

27 July 2005 – Will Struck Administration
Selected Comments* (4)
• Concentrate on things • Depending on the system
that would not be architecture and type, the
analysis approach may
addressed by R-BT vary. May depend on level
(e.g., interrupts). of system.
• Focus is on SW/SW • Emphasis that the analysis
integration. Consider should be performed during
addressing SW/HW design and confirmed
during verification. This is
integration test criteria verification of design.
in the paper. Still have • Addressing levels:
to put HW in to validate definitions of component,
assumptions of SW/SW definitions of coupling,
integration testing types of interactions

Data Coupling and Control Coupling Analyses Federal Aviation 16 16

27 July 2005 – Will Struck Administration
Selected Comments* (5)
• Document where data and control coupling should
be documented. Establishing the existence of data
and control coupling in the design data. Perhaps
architecture. Emphasize that it needs to be
documented, so there is something to verify.
• Emphasize that DC/CC should be documented in
the plans
• Value is to understand DC/CC. Use examples as
they apply to your system.
• Examples of issues that you are looking at, rather
than the solutions.
• Definitions backed up with examples.

Data Coupling and Control Coupling Analyses Federal Aviation 17 17

27 July 2005 – Will Struck Administration
Selected Comments* (6)
• Benefit/justification: These are the kind of errors
that happen in the field and are difficult to find in
the lab. Costs more to find and fix it later.
– Helps with maintenance
• At some time there does need to be a specific definition of
component, even if it is defined on a project-by-project basis.
– Defining component versus level. Granularity of component varies by
implementation.
– Applicant should define what they mean by “component” in their
architecture. And the levels at which they are performing their DC/CC.
– What kind of components are meant by DC/CC (related to level,
architectural concerns, behavioral concerns)

Data Coupling and Control Coupling Analyses Federal Aviation 18 18

27 July 2005 – Will Struck Administration
DCA & CCA Challenges * (1)
• “Analysis” vs. “testing” is often misunderstood.
Should it be static or dynamic. Running a test vs.
looking at link map and call tree.
– DO-178B requests by analysis that DC/CC is covered by your
tests.
• Unclear: The static analysis vs. test cases. Can it
be shown through analysis? Does it “have” to be
test focused?
• Two major approaches (static vs. dynamic): are
both okay?

Data Coupling and Control Coupling Analyses Federal Aviation 19 19

27 July 2005 – Will Struck Administration
DCA & CCA Challenges * (2)
• It’s often not • Requires more than
articulated by analysis that the
developers what is design is correct. Must
being done to address show that linker
the DC/CC – it may be
documented in pieces implemented it
throughout their plans correctly.
but doesn’t have a • Selective linkers can
complete description. cause problems.
• Sometimes assumed
that it is just a
byproduct of the R-BTs

Data Coupling and Control Coupling Analyses Federal Aviation 20 20

27 July 2005 – Will Struck Administration
DCA & CCA Challenges* (3)

• Difficult to measure and determine when

you are done. How do you know what is
adequate? We have a measure for MC/DC
but there isn’t a measure for this.
• Inconsistent interpretation (may be
addressed by “what is adequate”)
– Different ACOs
– Different CAAs

Data Coupling and Control Coupling Analyses Federal Aviation 21 21

27 July 2005 – Will Struck Administration
DCA & CCA Challenges
The impact of: • COTS components,
• Object-oriented Tech. (OOT) including OS, libraries, APIs
approaches & methods (little or no visibility into
internals, lacking data &
• Model-Based Dev. (MBD)
design assurance)
approaches & methods
• “Partial” compliance and
• IMA Concept (acceptance of
Integrator completion
pieces developed
independently, is the sum of • Reuse
the pieces enough for the • Run-Time Libraries
whole?) • Deactivated code and
• Common mode/cause Dead code
failures (software design • Smart versus dumb linkers
errors)

Data Coupling and Control Coupling Analyses Federal Aviation 22 22

27 July 2005 – Will Struck Administration
Solutions/Ideas* (1)
• Ensuring accuracy of • Control coupling of OS:
the link map – may not built a qualified tool
be possible through that did analysis at
object level and
analysis for some followed the tree up.
implementations Was required to do
• Attack the global (data) more than analysis that
pool issue first. Next the design is correct.
look for asynchronous Must show that linker
interface to the global implemented it
correctly.
pull (may not be able to
• Static analysis for data
test)
coupling

Data Coupling and Control Coupling Analyses Federal Aviation 23 23

27 July 2005 – Will Struck Administration
Solutions and Ideas* (2)

• Link map approach has been used and

analyzed to determine coupling issues.
Situations where have multiple producers of
data – these are particular areas of concern.
• Document what is acceptable / adequate
across international community

Data Coupling and Control Coupling Analyses Federal Aviation 24 24

27 July 2005 – Will Struck Administration
Selected Future Concerns*
• Clarify this in DO-178C
• Concern that guidance
could become overly
prescriptive Keep the
(CAST) paper as
educational.
• Guidance is in DO-178B,
intent isn’t to change that.
• Emphasize value of the
activity: e.g., Detecting
latent and anomalous
errors. Ensuring that the
implementation works.

Data Coupling and Control Coupling Analyses Federal Aviation 25 25

27 July 2005 – Will Struck Administration
Selected Thoughts and Ideas*
• Some OO methods may help with the
DC/CC.
• This is a subjective area where prescriptive
solutions may not be possible.
• Def Std –055 requires more than 178B in the
static analysis area.
• Concern regarding ability to review the
analysis data.
• Is the analysis SW level dependent or
should it be?

Data Coupling and Control Coupling Analyses Federal Aviation 26 26

27 July 2005 – Will Struck Administration
Thoughts and Ideas*
• How does complexity
of the system or design
fall into the picture?
• Need to qualify CM
tools?
• Look at definition of
RSC vs. component for
DC/CC.

Data Coupling and Control Coupling Analyses Federal Aviation 27 27

27 July 2005 – Will Struck Administration
A simple view
Guidance of DO-178B and other documents is
primarily from an internal software application
perspective

Application
Inputs Outputs

Event OS/Exec
Processor/Memory

Data Coupling and Control Coupling Analyses Federal Aviation 28 28

27 July 2005 – Will Struck Administration
A more complex view
Multiple Applications
and Functions
Shared I/O Dedicated
Processes
& Devices
Inputs Outputs
OS/Partitioning
Shared Processor &
Shared Memory
Events

Dedicated

Data Coupling and Control Coupling Analyses Federal Aviation 29 29

27 July 2005 – Will Struck Administration
Challenge 1 - IMA Concept

• Shared processor, OS, memory, I/O

• Common protection

App 1 App 2 App n

Monitor
Common Support Software (OS, API, I/O, partitioning, HM, FM, RM, etc.)

Platform Hardware
Common Power Common Databuses

Data Coupling and Control Coupling Analyses Federal Aviation 30 30

27 July 2005 – Will Struck Administration
Challenge 2 Distributed Systems
• Aircraft functions and applications are often
“distributed” across multiple software parts,
hardware parts (e.g., processors, memory),
networks and aircraft equipment

F F F F F
Mon 2.1 o.1 2.m DAU
1.1 1.2
Common Databus
SP SM DM
Common Databus
F F F F F
2.2 o.2 o.p 1.n RDC
o.3 RAC
Data Coupling and Control Coupling Analyses Federal Aviation 31 31
27 July 2005 – Will Struck Administration
Design and Data
To ensure coverage of Should there be other life
data and control cycle data items, e.g.:
coupling, depending • Integration Plan
on the “system” • Integration Standards
architecture, is better
• Interface specifications
guidance needed for:
• Design Principles / • User’s Guides
rules / methods? • Coupling Verification
• Recommendations for Procedures and Cases
higher level functions? • System- or Function-
• Arch. conditionals? wide DCA and CCA

Data Coupling and Control Coupling Analyses Federal Aviation 32 32

27 July 2005 – Will Struck Administration
Integrated and Distributed Functions
How do the definitions of data coupling and control
coupling need to be updated, and verification
analyses enhanced, to reflect that the software
applications and functions:
May share common platforms, OS, I/O, protection
and other resources with other apps/functions?
May not be wholly self-contained in a unit, but may
be distributed across multiple hardware and
equipment parts?

Should there be standard approach(es) and coverage

criteria depending on the architecture & SW Level?

Data Coupling and Control Coupling Analyses Federal Aviation 33 33

27 July 2005 – Will Struck Administration
Conclusion
Options, Address in :
• DO-178C/ED-12C
• Supplement
• Modification to DO-248B
• IMA AC 20-145
• New AC, Order, Notice
• RTCA SC200 / EUROCAE
WG60 IMA
• SAE S-18 Rev to ARP 4754,
4761
• Other?

Data Coupling and Control Coupling Analyses Federal Aviation 34 34

27 July 2005 – Will Struck Administration
Proposal
• De facto software “standard” encourages use of
good design practices and discourages use of
features that cannot be easily verified, without
being prescriptive.
• To ensure more consistency of application and
“standardization”, perhaps it should be revised to
be more prescriptive, relative to:
Simple versus complex versus very complex system
architectures (single unit, multiple unit, complex IMA)
Safety and protection features of system
Software level(s) of components, amount of coupling
• Questions or Comments?

Data Coupling and Control Coupling Analyses Federal Aviation 35 35

27 July 2005 – Will Struck Administration