1. NASA Space Launch System (SLS) Independent Verification and Validation (IV&V) Analysis Processes within Enterprise Architecture (EA) September 11, 2013
Mark Lee
Guy Kubic
Cover Page
2013 NASA IV&V Workshop

2. Agenda
Objective: Describe how IV&V uses EA model and tools to perform IV&V on SLS Flight Software (FSW)
SLS Flight Software (FSW)
SLS Vehicle Design Architecture
Flight Computer Avionics Software (FCAS) Breakdown
Enterprise Architect (EA) Tools
Overview
Tools for IV&V
IV&V Performance
Definition
IV&V Three (3) Questions
EA Capabilities Map to Technical Framework (TF) Goals
Summary
EA to Perform IV&V Analysis
Conclusion
NOTES
The objective of this presentation is:
How to use Enterprise Architect (EA) tools to perform IV&V on the SLS Flight Software.
Our Target Discussion Topic which is the SLS Flight Software
How EA Modeling is utilized for both FSW development and IV&V
IV&V Performance using EA
Summary

3. SLS Vehicle Design Architecture
NOTES
There will be a figure of the SLS vehicle architecture
Talking points of what it does.
SLS vehicle includes SRBs, engines, FC and US, CS, Payloads and ICPS and Launch Abort System (LAS).

4. SLS-Flight Computer Avionics Software (FCAS)
SLS IV&V Scope
Guidance, Navigation & Control
Thrust Vector Control-Stages
Real Time Operating System
M&FM - Mission Manager
M&FM - Abort Manager
M&FM - FC Redundancy Manager
Redundant Inertial Navigation Unit
Core Stage Engine Control Unit
DOLILU
Flight Design
Mission Execution & Flight Ops
Upper Stage Engine Control Unit
1553 I/O
ICPS
NOTES
Functional breakdown of the SLS Flight Computer (FC) avionics architecture highlights Key Software (SW) design points.
This is SLS and use outside drawing with SRBs, engines, FC and US, CS, Payloads and ICPS and Launch Abort System (LAS).
The interface plane between FSW/FC spans multiple elements.
Facilitate definition of functional interfaces between FSW/FC and SLS elements.
Ensure FSW adherence to the design and interface requirements between the FSW and the elements.3 FSW/FCs which reside within Stages Element
Take away Providing IVV for this FC System
Big Deal, what is the value doing IVV and double checking
1: IV&V team provides analysis of the safety-critical SLS software

5. Enterprise Architect (EA) - Overview
EA is a full Software Development Life Cycle (SDLC) modeling Capability
SLS-FSW Vehicle Functional Analysis Model (VFAM) architecture
EA SPARX Systems package chosen as the Unified Modeling Language (UML)/SysML tool
NASA Trade study evaluated tools such as CRADLE by 3SL, Rhapsody by IBM, CORE by Vitech, and EA by SPARX Systems.
EA easy to create, navigate and view SLS Vehicle Functional Model
Generates complex VFAM requirements, diagram structures, flows deliverables
Relies heavily on UML hyperlinks between diagrams
Compared to “other” functional analysis tools (i.e. Visio, WORD, Excel)
EA is able to import DOORS requirements and specifications
Easily identify new, deleted, and modified requirements
NOTES
EA is a full FSW development Life Cycle (SDLC) modeling capability
NASA evaluated other tools including.
Reference SLS-RPT-072 version 2; May 30,2013
EA Offered SLS-FSW modeling and integration advantages;
Lower Cost;
Availability;
Tailoring Versions of diagrams;
EA easy to create, navigate and view SLS Vehicle Functional Model.
Generates complex SLS Vehicle Functional Analysis Model (VFAM) requirements, diagram structures, flows and deliverables;
Relies heavily on hyperlinks between diagrams;
Compared to Ad Hoc functional analysis tools (i.e. Visio, WORD, Excel).
EA is useful to import DOORS requirements and specifications.
2: IV&V using EA modeling and tools to support key IV&V objectives for SLS

6. Use of EA to Meet IV&V TF Goals
EA End-to-End Traceability for Consistency (TF3.1-TF3.3)
Inspect to validate requirements (Black Box [BB], Design Level Requirements [DLR]), and Design Elements against IV&V quality criteria
EA High Value, End-To-End Modeling (TF5.1-TF5.3)
Inspect trace to SLS-FSW requirements, design, implementation
EA Model, Manage and Trace Requirements (TF3,TF5)
Search SLS-FSW model build and report on BB and DLR hierarchy
Performs impact analysis on requirement and design changes throughout SDLC
EA Powerful Document Generation
Utilize standard EA generation of requirements reports from SLS-FSW model
Utilize customized scripts to generate report of requirements traces
EA Advanced UML Driven Architecture
Allows Automatic Interactive Visualization of SLS-VFAM
EA Tools for IV&V immediate impact analysis and views across the SDLC:
EA Manages Complex SLS VFAM release baselines
Powerful Database Modeling
High Value, End-To-End Modeling
End-to-End Traceability – Black Box and Design Level Requirements, analysis, and design elements
Model, Manage and Trace Requirements
Manage Complexity
Powerful Document Generation
Generation and Reverse Engineering of Source Code
Visualize your Applications
Advanced Model Driven Architecture
Debugging, Compiling and Visualizing Executing Code
Automation - Harness the Power
Systems Engineering and Simulation
Build upon UML 2.4.1
Effective Project Management
3: IV&V uses EA modeling functions and tools to achieve IV&V on SLS-FSW artifacts

7. Enterprise Architect (EA) – IV&V
IV&V analysis and hierarchy views across SDLC
EA End-to-End Traceability (TF3.1-TF3.3)
EA End-To-End Modeling (TF5.1-TF5.3)

8. Enterprise Architect (EA) – IV&V
EA Powerful Document Generation
Utilize standard EA generation of requirements reports from SLS-FSW model
Utilize customized scripts to generate report of requirements traces
EA Advanced UML Driven Architecture
Allows Automatic Interactive Visualization of SLS-VFAM

9. IV&V Performance
Definition - IVV SECTION (from IEEE 1012 V&V Std):
“The dynamics of software and the multitude of different logic paths available within software in response to varying system stimuli and conditions demand that the software V&V effort examine the correctness of the code for each possible variation in system conditions.”
Three IV&V Questions Examine Behavior of the In-Scope SLS Software:
Will the SLS Software do what it is supposed to do?
Will the SLS Software not do what it is not supposed to do?
Will the SLS Software respond as expected under adverse conditions?
4: IV&V examines software behavior in response to varying system conditions
5: IV&V perspectives take on the form of three (3) questions

10. EA Capabilities Map to TF Goals
IV&V uses EA to perform IV&V Analysis Methods to accomplish Technical Framework Goals associated with Requirements and Design
Enterprise Architect (EA) Tool
TF-3 (Requirements)
TF (Design)
End-to-End Traceability
3.1, 3.2, 3.3
5.1, 5.2, 5.3, 5.5 
Requirements Trace
Trace Report
5.1, 5.2, 5.3, 5.5
Design Level Requirement Link Report
Design Level Requirement Issue Report
Element Compliance
Event Analysis Rep
Parametric analysis
Difference Two Requirement Files for changes
IV&V analyzes SLS-FSW Specifications, Bbox, Wbox, Design, CM
IV&V makes an EA build after each SPRINT
IV&V traces for Completeness and Cohesiveness
IV&V methods applies 3 Questions to table for every tool, adhering to tool
Method put together on tools and scripts help us achieve these goals
Makes EA with functionality it easier enhancement to the tools.
IV&V TSR/TF methods provide framework using EA to assure consistency and quality 8
Apply EA to perform IV&V using tools and scripts we believe provide these functions on.
Specifications (Black box / White Box)
Design Implementation (We apply TF/METHODS to perform IVV)
Configuration Management (CM) Use TOOLS to apply methods.
Make EA build after each SPRINT
Trace Completeness and Cohesiveness
How 3 Questions Applied to Table – State we are trying to meet objectives
IPEP / TSR / Methods Traceability Using EA Tools
HAZARD
TF/METHODS provides application of Framework Assure consistency and quality
6: IV&V applies analysis methods using EA to accomplish Technical Framework goals

11. Summary
In Summary
IV&V uses EA tools to perform IV&V on SLS Flight Software (FSW)
1: IV&V team provides analysis of the safety-critical SLS software
2: IV&V using EA modeling and tools to support key IV&V objectives for SLS
3: IV&V uses EA modeling functions and tools to achieve IV&V on SLS-FSW artifacts
4: IV&V examines software behavior in response to varying system conditions
5: IV&V perspectives take on the form of three (3) questions
6: IV&V applies analysis methods using EA to accomplish Technical Framework goals

12. BACKUP

13. TF3 Elements and Methods
Narrative of TF Element
Method(s) to be Utilized
3.1
Ensure that the system requirements are of high quality and are consistent with acquirer needs as they relate to the system’s software.
1) Validate Requirements by Inspecting Against Quality Criteria
3.2
Ensure that all (in-scope) parent requirements are represented in the appropriate child requirements and that the child requirements do not introduce capability that is not required.
1) Validate Requirements by Inspecting Bidirectional Traces
3.3
Ensure that the software requirements are of high quality and adequately meet the needs of the system with respect to expectations of its customer and users, operational environment, and both functional and non-functional perspectives.
3.4
Ensure that the requirements for software interfaces with hardware, user, operator, and other systems are adequate to meet the needs of the system with respect to expectations of its customer and users, operational environment, dependability and fault tolerance, and both functional and non-functional perspectives.

14. TF5 Elements and Methods
Narrative of TF Element
Method(s) to be Utilized
5.1
Ensure that all (in-scope) requirements (e.g. SRS and IRS) are represented in the appropriate elements of the design (e.g. SDD and IDD) and that the design does not introduce capability that is not required.
1) Verify Software Design by Inspecting Traces to Requirements and Software Architecture
5.2
Ensure that the design provides the required capability (meeting software architecture and software requirements), is able to reliably meet user needs, and is sufficiently stable to proceed with implementation.
5.3
Ensure that the proposed software architecture satisfies the needs of the system, and that it is a feasible solution (i.e. will successfully satisfy the needs of the system, while still being practical).
5.4
Ensure that the internal and external software interface designs are provided for all (in-scope) interfaces with hardware, user, operator, software, and other systems and that they provide sufficient detail to enable the development of software components that implement the interfaces.
1) Verify Software Interface Design by Inspection Against Interface Requirements
5.5
Ensure that complex algorithms have been correctly derived, provide the needed behavior under off nominal conditions and assumed conditions, and that the derivation approach is known and understood to support future maintenance.