Flight Software Architectural Modeling with SAVE

1
Flight Software Architectural Modeling with SAVE

• Mark Reid, JHU/APL
• Leah Kelley, City College of New York

2
Agenda

• Parties Involved in this Work
• Radiation Belt Storm Probe (RBSP) Prototype
  Overview
• Software Architecture Visualization and
  Evaluation (SAVE) Tool Overview
• SAVE Tool Applied to the RBSP Prototype
• Conclusions

3
Parties Involved

• Direct Involvement
• Leah Kelly, City College of New York
• NASA/APL Summer Intern who generated the models
  of the software and supported evaluation of the
  prototype architecture
• Indirect Involvement
• B. Heggestad, H. Malcom, C. Monaco, G. Oxton, M.
  Reid, (JHU/APL)
• Matthew Hillyard, (University of Michigan,
  NASA/APL Summer Intern)
• Radiation Belt Storm Probes (RBSP) Flight
  Software Prototype Developers
• NASA Goddard Space Flight Center, Flight Software
  Branch
• Developed the core Flight Executive (cFE) used in
  the RBSP prototype
• Fraunhofer Center for Experimental Software
  Engineering (CESE),
• University of Maryland
• Developed the SAVE Tool used to generate the
  models

4
RBSP Prototype Overview

• The RBSP team performed prototyping of heritage
  application software with NASAs core Flight
  Executive (cFE)
• Repackaged heritage routines into cFE
  applications
• Ran on BAE RAD750 development board for
  benchmarking
• Within this prototype we wanted to
• Remove call and access dependencies from
  application packages
• Move common utility software routines into a
  shared library
• Demonstrate functionality and evaluate the
  performance of our software in this architecture

5
RBSP Flight Software Concept
6
Software Architecture Visualization and
Evaluation (SAVE) Tool Overview

• Created by Fraunhofer CESE
• Eclipse-based plug-in tool
• Provides graphic representation of software
  architecture
• Purpose
• Create model of desired architecture
• Extract architecture from existing project
• Version Control

7
SAVE Diagram Elements(C/C Project Model)

• Subsystem
• A file folder, depicted as a white rectangle
  containing either components or other subsystems.
  In the RBSP model, the subsystem level just
  above the component level is equivalent to the
  cFE application level.
• Component
• A C source or header file, depicted as a yellow
  box in the diagram
• Subcomponent
• A portion of a C source or header file, often a
  function or data structure. These are not shown
  on the model as individual icons. A component
  containing subcomponents is depicted as a yellow
  rectangle with a circular arrow in its lower
  right corner.
• Relation
• A connection between two elements, depicted as an
  arrow originating from a source and terminating
  at a target
• Relations primarily exist at the
  component/subcomponent level. In a collapsed
  view, relations appear to connect subsystems.

8
SAVE Diagram Elements(C/C Project Models)
9
Types of Relations in SAVE C/C Models

• Access Relation
• A function reads from and/or writes to a
  variable, which may or may not be part of a data
  structure.
• Call Relation
• One function calls another function.
• Import Relation
• A C source or header file imports data from
  another C source or header file. These relations
  are generated from the include statements.
• Containment Relation
• A component is found entirely within a subsystem.
  Usually there is no arrow, although the circular
  arrows indicates a component contains
  subcomponents.
• Aggregate
• If multiple relations of different types
  originate from the same source component and
  terminate at the same target component, they can
  be combined into one arrow. The thickness of the
  arrow gives a rough indication as to the number
  of relationships contained in the aggregate. A
  thick arrow will generally contain more relations
  than a thin arrow.

10
System Level View of RBSP Prototype in SAVE Model

• Applications are dependent on standard includes
  and cFE API includes

11
View of Prototype Applications in SAVE Model
12
Unwanted Include Dependencies Identified by the
Model
13
Unwanted Access Dependency Identified by the Model
14
Relation Information View (Details)
15
SAVE Tool Benefits

• Generate diagrams of system architecture on
  multiple levels
• User can select level of detail to view
• Additional views of a model can be created from
  an existing diagram, allowing user to illustrate
  portions of a large model in more detail
• Can create a model of an element (i.e. component)
  and its neighbors
• Neighbors are both files that target the
  component and files that the component targets
• Rapid visualization and comparison of
  architectures of different systems
• Quick method to visualize dependencies at the
  application level during software development

16
Conclusions

• Is this type of tool useful and is there a time
  when it should be used?
• YES
• Useful to quickly check if your desired
  architecture has been achieved
• If used, use for the early builds where
  dependencies are established
• Is it worth spending time generating these models
  during later development?
• Probably not always, especially if the
  development team is small
• Other tools may give developers more specific
  information
• Dependency information at the function level is
  more difficult to extract directly from the model
• Logic flow at the function level is not modeled
• May be useful to run against final releases to
  ensure unwanted dependencies havent crept into
  the system

17
Questions?