# Presentation: 871758

## Using Architecture and Analysis Design Language (AADL) to Independently Validate and Verify (IV&V) System Performance Requirements and Design Performance With System Models

- Tom Hempler, NGC
- Nikki Johnson, NGC
- Steve Raque, NASA IV&V

- Executive Presentation
- September, 2008
- MAC-N IV&V Research

## Collaboration Team and Stakeholders

- Lisa Montgomery – NASA IV&V Research Lead
- Steve Raque – NASA POC for AADL Research Infusion, SRM/ Validation Product Line Lead
- Frank Huy – NASA IV&V Verification Product Line Lead
- Ken McGill – NASA POC for the system being modeled
- Tom Hempler – Principal Investigator
- Nikki Johnson – Senior Systems Analyst

## Agenda

- Problem Statement and Research Objectives
- Modeling Language Overview
- AADL Features and Analysis Tools
- Performance Validation and Verification Approach
- Common Techniques for AADL Infusion
- Tool Technology Integration
- AADL/SRM Integration Approaches Investigated
- Solutions Investigated
- Requirements Analysis
- Summary

## Problem Statement and Research Objectives

- Problem Statement
- Performance requirements, design and implementation validation and verification when tasked by NASA programs, is currently accomplished manually on a limited basis.
- Objectives
- Provide an overview of AADL infusion techniques examined during the investigation
- Report on AADL technology infusion alternatives for performance analysis of the system reference model
- Characterize the UML extension for AADL and its applicability to validating and verifying performance of the modeled system

## Modeling Language Overview

- Modeling History
- AADL and UML standards were established to model systems
- Government researched a variety of modeling methods for systems
- Department of Defense researched UML to model functionality
- NASA researched AADL to model performance and UML to model behavior
- JPL researched AADL and applied its processes to flight projects
- Model Language Comparison
- Both languages support threads and system/software architecture
- Unlike UML, AADL fills the performance analysis gap when modeling systems; and it extends the IV&V capability with dynamic analysis
- Like UML, AADL is used to model the structure and operations of the system

**Notes:**
AADL is the SAE Architecture Analysis and Design Language, formerly Avionics
SAE is the Society of Automotive Engineers

## AADL Features and Analysis Tools 

- AADL Features and Analysis Tools

**Scheduling Analysis**

**Future Research**

**Notes:**
OSATE and TOPCASE give us the analysis

## Tool Technology Integration

- J-Unit Test Suites

- Design Docs

- Requirements Docs

- Source Code

- C++

- XMI

- Java

- Java

- Java

- Together®

- Eclipse

- UML

- OSATE

- AADL

- State Rover®

- Assertion State Charts

## Common Techniques for AADL Infusion

- Use MARTE profile with embedded AADL support or an AADL profile to construct a UML model with performance constraints
- Construct architecture as a common domain for both AADL and UML models
- Extract assertions from AADL flows and test using SRM bridges
- Use validated assertions to test AADL feature attributed architecture, validate performance requirements, and verify as-designed performance
- Use OSATE/AADL to construct a performance loaded architecture
- Construct architecture with components, data flows, and threads
- Attribute architecture with performance requirements during validation and as-designed performance during verification
- Analyze system performance while adjusting performance parameters
- Flow optimum performance attributes into SRM domain via XMI for assertion testing

## AADL/SRM Integration Approaches Investigated

- Utilize XMI to transfer artifacts between OSATE and Together
- Export AADL model using XML files created in the OSATE environment
- Import AADL model into the UML model using Together’s XMI feature
- Utilize Java files to transfer artifacts between OSATE and Together
- Generate Java code for AADL model and import it into Together
- Create AADL domain model from Java files within the Together UML model
- Utilize the AADL profile to build an AADL model in Together
- Create the AADL performance model as part of the UML System Model
- Attribute the UML domain with AADL performance parameters
- Manual Transfers between OSATE and Together
- Create AADL model and UML model independently
- Analyze system performance within OSATE and manually attribute the UML domain model with AADL performance attributes

## Transferring Model Data Using XMI 

- Transferring Model Data Using XMI

- Creating an AADL text or graphic model, the  executable version of it is viewed as an XML file with an AAXL file extension
- UML exported XML files have a UML2 file extension
- To import the AAXL file, its extension is changed to UML2, and imported by browsing for it
- Both the file extension and the XML tags are incompatible between together and OSATE
- Additional R&D on an AADL to UML XMI translator and a companion UML to AADL XMI translator are required to convert the tags to a compatible format

## Transferring Model Data Using Java Files

- AADL executable files are generated in XML
- AADL does not generate Java files
- Java files can be created and executed in OSATE to represent AADL elements and imported into Together
- Together converts the Java files to UML objects
- Additional R&D is required to translate XML into Java for successful integration

## Integrating Model Data Using the UML Profile

- AADL profiles are not available for all UML tools
- AADL profile needs to be developed for Together
- OMG has a standard in-work
- AADL model elements are stereotyped UML classes
- Assertions are used to test AADL behavior when performance attributes have been added to UML classes
- AADL profile does not provide performance analysis capability
- Additional research is required to integrate analysis tools

## AADL Profile for UML

## Transferring Model Data Manually

- Use the same domain architecture for both AADL and UML models
- Create AADL text or graphic model with performance attributes

## Transferring Model Data Manually

- Analyze system performance as performance attributes
- Manually transfer performance attributes to the UML model
- Extract assertions from AADL flows and test within the UML model using assertion bridges
- Use validated assertions to test AADL feature attributed architecture, validate performance requirements, and verify as-designed performance
- Manually transfer performance data is the current viable approach

## Performance Validation and Verification

- Model system architecture and assign performance attributes in UML and AADL to establish migration points
- Characterize critical performance parameters vital to a system’s correct operation such as:
- Sensor/command data latency and update rates
- CPU utilization
- Synchronous/asynchronous task management
- Data-bus packet definitions and update rates
- End-to-end latency, jitter, execution flow
- Validate real-time architecture concerns and critical performance constraints using SPT (Schedulability, Performance and Timing) analysis within the AADL model
- Validate performance requirements within the UML model using validated SPT from AADL
- Designed and implemented performance is verified through the OSATE tests for latency, processing time, and schedulability tests conducted on the AADL model
- Performance requirements are verified and validated through the use of Assertion Test Suites, J-Unit Tests and performance analysis using AADL in concert with UML

## Validate Performance Requirements

- RoCSE 3.3.1.18.6
- Command - Control Latency shall be [very small]

- RGA 3.2.1.1
- Time stamped Angular Rate Data Update
- Rate shall be [very quick]
- RGA 3.2.1.1.10 Angular Rate Data Latency shall be [very small]

- RoCSE 3.3.2.3.3
- Data Time-Stamping Accuracy shall be [very good]

- RoCSE 3.1 Receive commands and give status via 1553B
- RoCSE 3.3.1.19
- Sensor Readings shall be transmitted via 1553B

- FC 3.3.1.18.6
- Issue Command – Control message within a [short time] of receiving a command

- CTC 3.5.16.1.1
- 1553B Driver processing time shall be [a small amount of time] per function

- Actuator Latencies

- Sensor Latencies

- System Performance Compilation Example (sanitized)

- Finding missing performance requirements and modeling them revealed end-to-end performance issues

- Missing bus performance specs are provided by suppliers’ performance tables

- Missing requirements found in related specs are issued as findings.

- 1553 Bus

- 422 Bus

- Technology design constraints define max data throughput

## Verify Architecture and Design

- FS Thrust
- Effectors

**For ten minutes of flight, critical performances are required**.
- Receive asynchronous commands from three Flight Computers within a short time
- Process all (3) copies in less than receive time frame
- Update thrust effectors within a very short time
- Update status back to Flight Computer within time to account for redundancy

- FC

- RoCS

- Effector Latency is very short

- FC

- FC

- Command Latency is short

- RoCS Status Update Latency is short

- Status Time Stamp Accuracy is **inconsistent** among requirements specifications

- FS Thrust Build Up Rate is thousands of pound-feet in a short time interval

- FS Pressure Build Up Rate is a lot of pressure in a very short time

- RGA

- Rock & Tilt angular data update latency is very short

## Summary

- Manually transferring performance data from the AADL model to the UML model is a viable approach to performance IV&V
- Additional R&D is needed to:
- Create an AADL to UML XMI translator and a companion UML to AADL XMI translator to convert the tags to a compatible format
- Translate XML into Java for successful integration
- Integrate AADL analysis tools
- Continue performance analysis using AADL plug-in tools
- Future Work
- Extend model based IV&V by using AADL profiles for UML
- Extract assertions from AADL flows and test using SRM bridges
- Use validated assertions to test performance attributed architecture, validate performance requirements, and verify as-designed performance