model-driven development of integrated support architectures · • the boeing company is currently...

Model-Driven Development of Integrated Support Architectures

Stan OfsthunAssociate Technical Fellow

The Boeing Company(314) 233-2300

October 13, 2004

Agenda

• Introduction• Health Management Framework

Process FrameworksModel-Based Design/Analysis FrameworksModel-Based Software FrameworksModel-Based Reasoning Frameworks

• Case StudyEngineering Models (Boeing ADVISE)Run Time Diagnostic Models (ISIS GME/TFPG)Practical Experiences and Issues

• Summary

The Need for Managing Complexity

Built In TestComponent

ModuleSubsystem

Integrated SoSHealth Management

Integrated DiagnosticsPrognostics

Vehicle Health Management

Given marginal historical diagnostic performance and increasing vehicle complexity/integration requirements, how do we produce a state of the art

Health Management (HM) capability within the target support system?

Diagnostic Development Evolution

Traditional barriers have hindered the development of cost effective and robust Health Management (HM) applications…

System Engineering Software Engineering

R&M

ID

Safety

Design

Vehicle

Orgs

Mission

Pgms

Diagnostic Development Evolution

…which can be addressed by having a more integrated approach to Health Management (HM) processes and tools.

System Engineering Software Engineering

CMMI SEI

MBHM Process Frameworks

Requirements Analysis

Requirements Validation

Functional Analysis

Functional Verification

Synthesis

Verification/Validation

Systems Integration& Control

Functional Trade Studiesand Assessments

Design Trade StudiesAnd Assessments

Requirements Baseline

Validated Baseline

Functional Architecture

Verified Functional Architecture

Physical Architecture

Verified Physical Architecture

Systems Analysis(Modeling and Simulation)

PROCESS INPUTS

Process Artifacts

Requirement & Constraint Conflicts

Decomposition & RequirementAllocation Alternatives

Design SolutionTrades & Impacts

Design Solution Requirements &Alternative Architecture Concepts

Requirements TradeStudies and Assessments

Requirement Trades & Impacts

Decomposition/AllocationTrades & Impacts

System “Best Value” Design Architecture

Derived Item Requirements for theNext Level of Decomposition

D950-10446-1 (IEEE-1220)

Requirements Analysis

Requirements Validation

Functional Analysis

Functional Verification

Synthesis

Verification/Validation

Systems Integration& Control

Functional Trade Studiesand Assessments

Design Trade StudiesAnd Assessments

Requirements Baseline

Validated Baseline

Functional Architecture

Verified Functional Architecture

Physical Architecture

Verified Physical Architecture

Systems Analysis(Modeling and Simulation)

PROCESS INPUTS

Process Artifacts

Requirement & Constraint Conflicts

Decomposition & RequirementAllocation Alternatives

Design SolutionTrades & Impacts

Design Solution Requirements &Alternative Architecture Concepts



Requirement Trades & Impacts

Decomposition/AllocationTrades & Impacts

System “Best Value” Design Architecture

Derived Item Requirements for theNext Level of Decomposition

D950-10446-1 (IEEE-1220)

SEI / CMMI

Because the HM function inherently touches every aspect of a system, decisions regarding HM requirements and design must be integral to the

overall Systems Engineering (SE) process.

MBHM Design/Analysis Frameworks

Model-Based design/analysis tools support the integration of HM and SEprocesses by providing an integrated assessment of many traditionally

disparate aspects of failure propagation.

Propulsion

Payload

Airframe

Crew Station

Fuel DeliveryFlight Control

f2

Comm

C1U42

f1

L3

UHF

Xmit

Avionics

f3

WrapTest

A/G CommTest

Weight

Reconfiguration

Redundancy

Cost

DiagnosticsReliability

Power

Weight

Reconfiguration

Redundancy

Cost


Power

Weight

Reconfiguration

Redundancy

Cost


Power

Top Down Decomposition

Bottom UpDesign

DesignInfluence

Specification Compliance

MaturationModel

ATECompatibility

Analysis

FaultCoverage (BIT)

AnalysisMission Reliability,

FMEA/FMECAFailurePropagation

Analysis

DesignInfluence


MaturationModel

DesignInfluence


MaturationModel

ATECompatibility

Analysis

FaultCoverage (BIT)



Analysis

Propulsion

Payload

Airframe

Crew Station

Fuel DeliveryFlight Control

f2

Comm

C1U42

f1

L3

UHF

Xmit

Avionics

f3

WrapTest

A/G CommTest

Weight

Reconfiguration

Redundancy

Cost


Power

Weight

Reconfiguration

Redundancy

Cost


Power

Weight

Reconfiguration

Redundancy

Cost


Power


Bottom UpDesign


Bottom UpDesign

DesignInfluence


MaturationModel

ATECompatibility

Analysis

FaultCoverage (BIT)



Analysis

DesignInfluence


MaturationModel

DesignInfluence


MaturationModel

ATECompatibility

Analysis

FaultCoverage (BIT)



Analysis

MBHM Software Frameworks

State of the art software frameworks support the integration of model-based diagnostics and prognostics into aerospace vehicles by providing a

layered, “unbundled” architecture.

System Failure Propagation Models• ISIS Timed Failure Propagation Graphs

Localized Performance Models• Electronics Built In Test• Motor Efficiency Monitors• Valve Transition Time Monitors • Etc.

Open System Architecture for Condition Based Maintenance

Sensor (Hardware Control)

Data Acquisition (Sampling, Scaling, Smoothing)

Interface Standards

Signal Processing Algorithms(Feature Extraction)

Interface Standards

State Detector Algorithms(Tests & Monitors)

Interface Standards

Diagnostic Algorithms(Data Fusion & Failure Isolation)

Interface Standards

Prognostic Algorithms(Prediction & Trending)

Interface Standards

Sensor (Hardware Control)

Data Acquisition (Sampling, Scaling, Smoothing)

Interface Standards

Signal Processing Algorithms(Feature Extraction)

Interface Standards

State Detector Algorithms(Fault Detection Tests & Monitors)

Interface Standards

Diagnostic Algorithms(Data Fusion & Fault Isolation)

Interface Standards

Prognostic Algorithms(Prediction & Trending)

Interface Standards

MBHM Reasoning Frameworks

Off the shelf reasoning tools provide standardized run time engines for executing failure propagation models and/or performance models within

an aerospace platform.

Plant(Aircraft Subsystem)

Regulator

Supervisory ControllerFault Adaptive Control Unit

HybridObserver

FaultDetector

Hybrid Diagn.

DiscreteDiagn.

Param.Estim.

Fusion

Predicted vs. Measured output

Symbolic Failure Modes

Fault Magnitude Parameters

Updated Physical Parameters

ControllerSelector

ReconfigurationManager

TransientManager

Plant ModelsActive State

Model

Case Study – Generic Fuel System

PP

PP

LXTank

RXTank

PwrCtl

PwrCtl

PwrCtl

PwrCtl

V

V

V

P

P

P P

Manifold

LWTank

RWTank

P P

V

LFTank

RFTank

LEngine

REngine

V

V

FM

FM

PT

PT

PT

PwrCtl

PwrCtl

PwrCtl

PwrCtl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

PwrCtl

PwrCtl

PPPP

PPPP

LXTank

RXTank

PwrCtl PwrCtl

PwrCtl PwrCtl

PwrCtl PwrCtl

PwrCtl PwrCtl

VV

V

V

P

P

P PP P

Manifold

LWTank

RWTank

P PP P

VV

LFTank

RFTank

LEngineLEngine

REngineREngine

V

V

FM

FM

PT

PT

PT

PwrCtl PwrCtl

PwrCtl PwrCtl

PwrCtl PwrCtl

PwrCtl PwrCtl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

Pwr

Ctl

PwrCtl PwrCtl

PwrCtl PwrCtl

A generic fuel system (GFS) was chosen as a representative aerospace subsystem because it requires vehicle power, electronic controls, and

mechanical pumps, valves, etc.

MBHM Case Study - Notional Architecture

Robust GFS health assessment requires the assimilation of data from existing vehicle/subsystem monitors (e.g., BIT) as well as the outputs of

dedicated IVHM algorithms.

Hist

ory

FI/FA

Rule Based Reasoner

XXX Failed, YYY Degraded

“Filtered”Health

PresentationLayer

“Reported”Health

FD

“Local”Health

GrayScale

Fail

XXX Failed, YYY Degraded, ZZZ failedFI

ISIS TFPG Reasoner (HA)(Fuel Subsystem)

“System”Health

Vehicle Contingency MgmtSubsystem Built In Test

Vehicle Data Acquisition(States, Modes, Commands, etc.)

IVHM Algorithms(Pump/Valve Response, etc.)

Subsystem Data Acquisition(Fuel Subsystem)

“Raw”Data

110101000001…

MetricsMaturation

Case Study – ADVISE Model

During the HW design, an ADVISE model is built to identify the sensors/tests/monitors and fault reporting logic necessary to provide the

required levels of fault detection and isolation.

TestFunction

FailureComponent

Case Study – TFPG Development Model

Model

TestCases

During the SW design, the ADVISE model is translated into a TFPG model using ISIS GME/FACT tools and ADVISE outputs are used for engineering

desktop validation of proper diagnosis.

Case Study – TFPG Run Time Model

During the SW design, the OSA-CBM compliant TFPG run time code is automatically generated and the test cases are reused for SW desktop

validation of proper run time diagnosis.

TFPG Domain Model

(C++ Code)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Fixed TFPG Engine

(C++ Code)Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


TFPG Domain Model

(C++ Code)xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


vxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Fixed TFPG Engine

(C++ Code)Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


Model

TestCases

Practical Experiences & IssuesCase Study Statistics• 244 unique ambiguity groups identified by ADVISE

• Static diagnosis using all defined tests, single fault assumption.

• 320 test cases used to verify run time diagnosis• Dynamic diagnosis using currently reported failures.

(e.g., some tests can only be run in certain modes or at certain rates)• Account for failure mode dependencies.

(e.g., a valve can’t be stuck open and stuck closed at the same time)• Account for multiple failure scenarios.

• ADVISE to TFPG Translation• Manual TFPG model required several weeks of labor and was 82% “accurate” on first try. • Translated model will require a few hours of labor and should be 100% accurate on first try. • Translated model was slightly smaller and faster.• Batch scripts automatically generate the necessary data sets for TFPG model/code testing from the ADVISE ambiguity group report

• Run Time Performance (target PPC processor / VxWorks / C++)• Real time diagnoses will be run in an event driven manner

• Event = mode change or monitor status change • Test cases averaged < 0.5 seconds of CPU time per event (max 1Hz rate anticipated) • Four large models run simultaneously with nearly linear memory & throughput demands

Summary• IVHM requires rigorous systems engineering to manage complexityand assure integrity.

• A model-based approach provides a disciplined methodology for supportingthe SE process:

• Successive refinement of diagnostic concepts and implementation.• Incremental transition from conceptual design to detailed design to validation.• Reuse of engineering data/models across design cycles.

• The Boeing Company is currently implementing a process-based, model-driven approach by employing tools from Boeing and ISIS, while evaluating other reasoners.

• The GFS case study is being used to document and benchmark the basic steps in the modeling process.

• Integration of the run time reasoners and models into Boeing’s desktop software development environment is on-going.

model-driven development of integrated support architectures · • the boeing company is currently...

Documents