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, NGCNikki Johnson, NGCSteve Raque, NASA IV&V

Executive PresentationSeptember, 2008MAC-N IV&V Research

2

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

3

Agenda

• Problem Statement and Research Objectives

• Modeling Language Overview

• AADL / SRM Integration Approaches Investigated

• Common Techniques for AADL Infusion

• Performance Validation & Verification

• Summary

4

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

5

Modeling Language Overview

• Modeling History– AADL and UML standards were established to model systems – Government researched a variety of modeling methods for

systems• DoD 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

6

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

7

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

8

Performance Validation & 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

9

Summary

• Manually transferring performance data from the AADL model to the UML model is a viable approach to performance IV&V

• 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

Internet Site – http://www.aadl.info