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 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 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 Integrate information and relationships in a single repository with a model bus Models Multi-Aspect Model Models Models Multi-Aspect Model Model Bus Components Assemblies System Integrator IDE Modeling Simulation Analysis Virtual Integration File Sharing Configuration Management Model Bus Assembly Models Import/Export Supplier 1 IDE/Tools Better requirements Better integration Better communication Better consistency Assembly Models Multi-Aspect Model Multi-Aspect Model Model Bus Model Bus Models Models Components Assemblies Components Assemblies File Sharing Configuration Management... Supplier N IDE/Tools File Sharing Configuration Management File Sharing Configuration Management 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 & Model Bus Requirements Eclipse AADL OSATE Verification MatLab SimuLink Rhapsody Model SCADE TOPCASED? Design Version Esterel SysML DOORS 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 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 Parse & Process Modify Existing CM/SM Virtually Integrate Issues CM/SM Modified CM/SM Virtually Integrate Create New CM/SM New SM Specs Issues CM/SM CM/SM Parse & CM/SM Parse Modify Create Process & Parse Process & Modify Create Modify Create Process Modified CM/SM Modified CM/SM Modified Existing CM/SM Virtually CM/SM New CM/SM Existing CM/SM Virtually Integrate New CM/SM Existing CM/SM Virtually Integrate New CM/SM New SM Issues Integrate New SM Issues New SM Issues New Product Definition New SM New SM New SM 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 Definition Framework for Description of Components Rules for constructing and interconnecting components 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 Slide 9 9
Backup Slides Version Slide 10 10
Transition to System and SW Engineering Integration Based on Component-Based Architectures SoS and Systems are Composed Primarily of Components 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 A BLK SSn B C D CMP DET S1 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 Model- Centric 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 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