Aerospace Vehicle Systems Institute
Aerospace Vehicle Systems Institute
System and Software Integration Verification
Texas Engineering
Experiment Station
The idea for this cooperative began in 1997 when Walt Gillette (now the
747X program manager Boeing Commercial Airplanes) met for a Texas A&M
College of Engineering, Advisory Council meeting. B. Don. Russell, the
A&M Associate Dean in charge of TEES, briefed Walt Gillette on a new
research cooperative A&M had recently established for the petroleum
industry. Walt was intrigued by the possibility of linking several industry
members to do cooperative R&D under the protection of the National
Cooperative Research and Production Act of 1993.
Walt Gillette wanted to improve the research for aircraft systems -- an area
he believed was a problem in Boeing’s efforts to effectively design and build
new commercial aircraft. These complex and expensive systems typically
pace airplane programs.
Walt’s vision is to use AVSI as a vehicle to work with experts throughout the
industry (Commercial and Defense), academia and elsewhere. Everyone
will benefit by leveraging resources and developing an improved ability to
work together.
1
Project Overview
„
Overall Concept of Operations
‹ Design and production based on early and continuous
integration (virtual => physical)
‹ Integrate, then build
„
Objective
‹ Shift architecting, design, and production activities to explicitly
address integration issues early, reducing program execution
risks, cycle time and cost
„
Approach
‹ Adopt/develop “integration-based” software and system
development processes with emphasis on integrating
component-based, model-based and proof-based development
Version
Aerospace Vehicle
Systems Institute
Slide 2
SSIV is a very ambitious, multi-year project to develop and demonstrate a
“virtual integration” approach to product development that is likely to
significantly affect how the aerospace industry handles embedded softwareintensive systems in the future. The key concept is to address integration
issues earlier and more comprehensively with improved consistent processes
and tools.
2
Participants
„ Current
‹ Active – BAE, Boeing, DoD (Army, Navy), FAA, GE Aerospace
(Smiths), Honeywell, Lockheed Martin, Rockwell Collins,
SEI/Carnegie Mellon
‹ Joining – Airbus, Dassault-Aviation, JPL/NASA
„ Potential
‹ Current AVSI members – DoD (Air Force), Goodrich, Hamilton
Sundstrand (UTC) {Sikorsky, P&W}
‹ Potential new members – General Dynamics, Meggitt, Northrup
Grumman, Raytheon, Thales, Woodworth
Version
Aerospace Vehicle
Systems Institute
Slide 3
Current membership suggests the strong leanings toward avionics and
electronic systems. Government agencies (FAA and NASA) typically join as
Liaison Members, under a change to the original agreement that essentially
allows such members to behave as full members with recognition that their
interests are public in nature and are not profit-motivated.
Universities, consultants, research
institutions, tool vendors and standards
bodies are not mentioned on this slide,
but are acknowledged to be absolutely
necessary to the success of the project.
3
Expanded objectives from the current draft AFE 60
4
Single Information and Relationships
Repository
‹Better
‹Better
‹Better
‹Better
„ Integrate information and
relationships in a single
repository with a “model bus”
Multi-Aspect Model Repository
Import/Export
Models
“Model Bus”
Models
Models
Multi-Aspect Model
Repository
“Model Bus”
Components
requirements
integration
communication
consistency
Assemblies
System Integrator
IDE
Modeling
Simulation
Analysis
Virtual Integration
Models
Assembly Models
Assembly Models
Multi-Aspect Model
Repository
“Model Bus”
Multi-Aspect Model
Repository
“Model Bus”
Components
Assemblies
Supplier 1 IDE/Tools
Models
...
Components
Assemblies
Supplier N IDE/Tools
File Sharing
File Sharing
File Sharing
Configuration
Management
Configuration
Management
Configuration
Management
File Sharing
Aerospace Vehicle
Configuration Management
Systems Institute
Slide 5
This chart is starts on the left with the repository of models and background
data in the integrators repository. The “model bus” is both an internal
conduit for developing an initial concept system and passing the “specs”
(in the form of models) to a supplier. Each of the suppliers has their
own repository of models and background (some of it proprietary) to
merge with the integrator’s “specs” model and perhaps improve upon
the system or subsystem. The project is designed to address the
colored (blue and green) parts of this process; it is hoped that the
file sharing and configuration management can be handled with
commercially available tools - not a part of this AVSI effort.
5
Overview of Multi-Aspect Model
Repository & Model Bus
Requirements
Eclipse
AADL
Verification
OSATE
MatLab
SimuLink
SCADE
Model
Repository
TOPCASED
Rhapsody
Esterel
Design
Version
?
DOORS
SysML
Aerospace Vehicle
Systems Institute
Integration/Deployment
Slide 6
In an earlier phase of the project AADL was chosen as the best starting point
•Language features
•Tool support (existing)
•Extensibility support (AADL is good, not perfect)
6
Modified Business Model
„ System Integrator defines a new product using internal
repository of virtual “parts”
„ Specifications for virtual subcomponents sent to suppliers
Aerospace Vehicle
Systems Institute
Slide 7
A modification to the approach of developing complex systems is
anticipated, placing the emphasis on model-based development.
This chart illustrates the flow of specs (in model form) to suppliers
and the return of component modules (CM) and system modules (SM)
back to be integrated in a virtual sense before any the product is produced.
7
Modified Business Model
(continued)
„ Virtual parts returned for virtual integration into a virtual product
‹ Cost savings realized by finding problems early on virtual
parts
„ Once the virtual product is satisfactory, the actual product is
developed
‹ Cycle-time reduction realized since re-work on physical parts
virtually eliminated
Repository
Repository
CM/SM
Repository
Repository
CM/SM
CM/SM
Parse &
Process
Modify
Parse & CM/SM
Modify
Create
Parse
&
Process
Modify
Create
Parse
&
Process
Modify
Create
Process
Modified CM/SM
Create
Modified CM/SM
Modified CM/SM
Existing CM/SM Virtually
New CM/SM
Existing CM/SM Virtually
Integrate New CM/SM
New SM
Existing CM/SM Virtually
Integrate New CM/SM
New SM
Integrate
Issues
Issues
New SM
Issues
Modified CM/SM
Existing CM/SM
Virtually
Integrate
Issues
New CM/SM
New SM
Specs
Issues
Virtually
Integrate
New Product Definition
New SM
New SM
New SM
Aerospace Vehicle
Systems Institute
Slide 8
The benefits of such an model-based development are summarized on
this chart - cost savings and cycle-time reduction are the overarching
drivers in most complex system’s development. This chart underscores
the feedback of the virtual integrations (both internal to the supplier and
the OEM as well as between supplier and OEM).
8
Deliverables
„ Component-Based Model Framework
‹ Multi-Aspect Model Repository Definition
™ Framework for Description of Components
z Rules for constructing and interconnecting
components
z Rules for property definitions supporting required
(integration) analyses
‹ Model Bus Definition for Consistent Model to Model
Information Interchange
„ Virtual Integration Analyses Definitions Catalog
„ Parametric Process Definition for achieving Virtual Integration
‹ Integrating Component-Based, Model-Based and Proof-Based
Development
„ Pilot Project(s) Results and Lessons Learned
Aerospace Vehicle
Systems Institute
Slide 9
9
Backup Slides
Version
Aerospace Vehicle
Systems Institute
Slide 10
10
Transition to System and SW Engineering
Integration Based on Component-Based
Architectures
„ SoS and Systems are Composed Primarily of
Components
SSn
‹ Modules that Encapsulate Both Data and
Functionality, and Are Configurable at Run-Time
‹ Requires accurate Modeling and Analysis of
Properties, Relationships, Attributes, Associations,
Interactions and Dependencies between Components
™ Control, Data, Timing, Sequencing, Synchronization,
Interrupts, Performance, Latency, Jitter, Safety,
Security, Reliability, Resources, Fault Tolerance, and
other Quality Factors
™ Composable, Reusable Software Modules
‹ Requires Two Perspectives
™ Independent of the context in which they are used
™ Dependent on the context in which they are used
‹ Requires Component-Based Model Framework
Aerospace Vehicle
Systems Institute
A
B
C
BLK
CMP
S1
D
DET
S2
Sensor
Slide 11
The sketch emphasizes that subsystems and systems are built up from
components that are composable and reusable (based on both
mathematical and empirical “proofs”. The models that allow this must be
consistent internally and must interface seamlessly in an integrated system.
11
Multi-Aspect Models for ModelCentric Development
„ Different models, modeling,
simulation and analysis
tools may be necessary for
‹ Different properties
‹ Different users
„ Compatible modelling tools
(open source or
commercially available)
‹ TOPCASED
‹ AADL
‹ MATLAB/Simulink
Aerospace Vehicle
Systems Institute
Slide 12
This chart illustrates four types of multiple-aspect models used to carry
out this scheme of consistent, not necessarily identical models. It is
imperative to recognize both the essential differences (purpose, intent,
and implementation) of models and the need for consistency in interfaces
to allow the strengths of these different properties to be harnessed in
an integrated system. Whatever the origin of the tool, this need for
consistency and proof-testing is a strong driver for this concept to work.
12
The overall effort is broken down into eight work packages in the expectation
that each work package is likely to have its own set of interested participants
and one or more AFEs to complete their tasks. Some work packages will
underpin or overarch the whole project - like WP0, which sets the
management structure for this multifaceted project. Similarly, WP6 and WP7
are concerned with how to adapt infrastructure to this style of model-based
development.
There are a lot of interactions between the subtasks of the different
WPs. The work is planned to take 3+ years to perform, and is split into five
phases: red label preparation, red label execution (initial pilot project), red
label assessment and revision for black label (i.e., preparation), black label
execution (final pilot project), black label validation (assessment) and
production preparation. Red label execution will be performed mainly by
researchers, and will use proof-of-concept prototype tools, some of which
may just be paper procedures. Black-label execution will be performed
mainly by program people and will use pre-production tools.
13