Understanding descriptive models, analytical models, and parametric modeling.

There are many sub-specialities within the systems engineering discipline.  Modeling and simulation specialists, analysts, requirements engineers, architects, IV&V engineers, Reliability Maintainability Safety & Supportability (RMSS) engineers, front-end, back-end, etc. We really are a diverse collection of skills, and sometimes, these skills get stovepiped.  MBSE is one technique that can facilitate cross-connecting these stovepipes.

SysML was built to support the construction of “system models” that are fundamentally descriptive in nature, that is they contain the same level of information that would have been found in description documents and specifications, such as the System/Segment Description Document (SSDD) or System/Segment Specifications (SSS).  The emphasis is on maintaining a consistent overall representation of the system, with carefully controlled levels of detail or abstraction, and ensuring that each subsystem and its interconnections are adequately described to enable consistency within the more detailed design.  Terminology, data definitions, and interfaces must all be maintained in a structured and consistent way.  Once the system model has been developed to an appropriate level of detail, these documents can be automatically generated from the model using the modeling tool’s scripting language or report writing capability.  The system model, in this context, clearly caters to the needs of the system architect and requirements engineering skills within systems engineering.

When systems engineers need to perform performance analyses or trade studies, however, they need a different sort of modeling capability.  Because the focus is on analysis rather than description, these models are referred to as analytical in nature.  They are not intended to provide a baseline for total system design, but rather to answer a specific technical performance question or provide data for a particular design decision.  As such, they don’t need consistency in terminology, interfaces, or level of detail… rather, they need enough fidelity and physical understanding to provide the necessary outputs.  These analytical models can be either static (representing properties in a manner independent of time, such as a table or spreadsheet), or dynamic (representing how properties vary over time, perhaps using a system of dynamic equations).

11.descr-ana

One or more dynamic models may be composed into a simulation, which also includes a set of initial conditions and a simulation engine to control and monitor of the execution.  Tools like Simulink provide a simulation environment that supports these three elements.

12.mod_sim

Clearly, the development of simulations for the purpose of analysis should be informing the overall system architecture, and decisions resulting from this analysis should somehow be reflected in the descriptive “system model”.  The following diagram explores some desirable relationships between the descriptive/specification (system) model, built in SysML, and the set of analytical models and associated simulations.

13.mbe

SysML was designed with this interface to analysis firmly in mind.  The parametric modeling capability in SysML has proven to be a flexible way to connect the structural, behavioral, and requirements aspects of the descriptive system model with the broad spectrum of analyses necessary to ensure a valid and feasible overall system design.

This paper is not intended to be a tutorial on parametric modeling, but rather an introduction to the concept. The following simple example may be illustrative.  Note that just like structure and behavior in SysML, parametrics can be modeled using both definition and useDefining parametric constraints (so that they can be reused) happens on a bdd:

14.air_comp_par

Note here that a the Constraint Flow Rate Equations represents a reusable set of equations, possibly even hierarchically defined, which can potentially be applied in many different contexts.  In this case, Flow Rate Equations are applied specifically to the Flow Rate Analysis block.  The Flow Rate Analysis  references Air Compressor Context as the context for the analysis, which (not shown here) provides access to all the value properties available within the air compressor structure and behavior… Such as various capacities, pressures, power, etc.  This bdd, being a diagram of definition, does NOT indicate specifically indicate which value properties in the structural/behavioral models are connected to which parameters of the constraint equations!  For that, we need a diagram of use, or a parametric (par) diagram:

15.air_comp_par_diag

The SysML specification does not provide any inherent mechanism for solving or evaluating the sets of constraint equations, but most tools have implemented some capability in this regard.  A growing number of tools, such as Phoenix Integration’s mbsepak and Intercax’s SLIM/paramagic/Melody, provide a direct dynamic linkage between SysML parametric models and a broad spectrum of analysis tools, simulation environments, and mathematical solvers.  I must note that these two companies provided this capability based on industry demand… meaning that there are an increasing number of sophisticated system modelers making heavy use of parametrics to drive and iterate system designs.

When this capability to link the system description to the system analyses works, it is much more impressive, meaningful, and powerful than simply animating the SysML descriptive model!  There is a separate section below about the stumbling block of “executable system models”.

So what is the “stumbling block”?  I have found that systems engineers who build descriptive models tend not  to build parametric models!  Sometimes, they use spreadsheets or tables of key parameters (KPPs, CPs, TPMs, MOEs), but the opportunity for directly linking to specific analysis models is so much richer, and could be so much more productive!  As vendors provide increasingly better support for parametric model connectivity to analysis & simulation, systems engineers have fewer and fewer excuses for NOT documenting key performance relationships in parametric models!

Leave a Reply

Your email address will not be published. Required fields are marked *