AP 233 & PLCS Relevant Happenings at PDES Inc. Offsite Meeting, March
8-12, 1999

By Harold P. Frisch

NASA/Goddard Space Flight Center

PDES Inc.

March 16, 1999

The PDES Inc. semi-annual offsite meeting was held in Virginia Beach
March 8-12. Relative to STEP AP 233 - Systems Engineering (SE) a lot of
unscheduled happenings happened. In my opinion these will support AP
233's internal infrastructure and the infrastructure needed to interface
AP 233 with all system relevant engineering analysis domains. These
happenings also have relevance to the PLCS (Product Life Cycle Support)
project. This project is being initiated by NATO/CALS with substantive
global participation from both industry and governments. "PLCS on a
Page" is appended to the end of this note.

![](media/image1.emf){width="6.017361111111111in" height="4.15in"}

Figure 1 - From David Leal's NAFEMS presentation at PDES Inc Offsite
meeting

# High Level Planning Model for STEP AP 107 - Engineering Analysis Core Model.

Much debate revolved around the need to harmonize such engineering
analysis AP's as:

-   209 (structures) and 210 (electronics) and their envisioned
    extensions into:

-   electromechanical,

-   thermal,

-   computational fluid dynamics,

-   electromagnetics and

-   other analysis domains

-   along with the need to support the various engineering analysis
    needs of:

-   systems engineering (SE) and

-   product life cycle support (PLCS) analysis.

At the onset of the meeting the bubbles "behaviour" and "analysis model"
were absent from figure 1. Harmonization was finally achieved by adding
these bubbles along with their associated dependency arrows.

### Inside of "Behaviour"

I view the "Behaviour" bubble to be the *keystone* for interfacing
specific domain and multi-domain engineering analysis to the SE & PLCS
views of the total system.

Both SE & PLCS need to aggregate and assimilate information from a
variety of engineering analysis domains. There is a need to:

-   know assumptions and limitations associated with all analysis models
    used and

-   specify a list of product characterization and maturity measures
    that define analysis deliverables and their maturity status.

I see this information being represented and exchanged at the behaviour
bubble

From the perspective of the engineering analysis domains the behaviour
bubble is where:

-   assumptions and limitations are to be defined for SE & PLCS
    customers and

-   where engineering analysis results are summarized and delivered to
    SE & PLCS customers as an instantiated list of product
    characterization and maturity measures.

### Inside of "Analysis Model"

The "analysis model" bubble is where all behaviour analysis is done. The
behaviour bubble defines what type of analysis is needed and records
associated assumptions and limitations; it does not define analysis
methodology. For example, in the domain of linear elasticity the SE &
PLCS customer should not care if continuum or finite element theory is
used to produce results. The customer does need to know if results are
based upon the theory of linear or non-linear elasticity. If the
customer desires to know analysis details AP 209 (metallic and composite
structures) has the ability to trace modeling details associated with
each modeling iteration cycle used to produce the deliverables.

### Traceability from Requirements to Modeling Detail

The SE & PLCS domains provide traceability from basic system
requirements through all derived requirements and down to the list of
deliverables. These are the product characterization and maturity
parameters used to define each physical and functional element of the
system's architecture.

Within each engineering analysis domain, modeling detail is aggregated
in a traceable manner to produce the product characterization measures
to be delivered to the customer. This clean interface of product
characterization and maturity measures enables total up and down
traceability between modeling detail and the initial system requirements
set.

### AP 107 Modularity Status

Relative to the development of AP 107, the pink colored bubbles in
figure 1 exist within AP 104 (finite element analysis) & 209 (metallic
and composite structures). These now need to be extracted and put into a
modularized format. The other modules need to be developed in a generic
enough manner to satisfy all users and customers of engineering
analysis.

### Inside "State" and "Properties"

The bubbles "state" and "properties" were also discussed. These modules
are also important to SE & PLCS. The following SE & PLCS relevant points
were made:

-   "State" is an extremely broad concept. It spans the entire life
    cycle. It focuses in on very specialized engineering analysis
    behaviour views or expands to cover a very broad system operations
    and performance view. For SE & PLCS the concept of "state" needs to
    be harmonized across the following product life cycle views:

-   as measured

-   as required

-   as proposed

-   as designed

-   as build

-   as operated

-   as maintained

-   as disposed

-   "Properties" is a concept that has very fuzzy boundaries. What is
    important is that generic product property information be decoupled
    from analysis. An illustration of good and bad information modeling
    practices relative to property definition and its representation is
    provided in figures 2 and 3.

### Need for the Concept of "Design Parameters"

The properties bubble needs to be revisited with the needs of SE & PLCS
in mind. To me "derived properties" and their utilization in support of
multi-disciplinary analysis will be a challenge to harmonize.

I do not yet see how to resolve the "derived properties" issue but my
feeling is that provision is needed for a subcategory of "derived
properties" called "design parameters". The designer has direct control
over these. All other "derived properties" change due to relationships
and constraints that the design engineer must be aware of and
accommodate.

Figure 2 - From David Leal's NAFEMS presentation at PDES Inc Offsite
meeting![](media/image2.emf){width="6.0256944444444445in"
height="2.8958333333333335in"}

![](media/image3.emf){width="5.965277777777778in" height="3.1125in"}

### 

Figure 3 - From David Leal's NAFEMS presentation at PDES Inc Offsite
meeting

### 

### Provision to Support Design Optimization

There will be a need to support system "design optimization" relative to
both operational performance and life cycle costs. This
multidisciplinary engineering domain is based upon sensitivity analysis.
Sensitivity analysis is concerned with the relationship between the
"design parameters" available to the design engineer and some small set
of state dependent cost functions to be minimized. The cost functions
are a function of the system's state variables that are interrelated by
the system's physical design constraints and the laws of physics. This
is an extremely generic, complex and useful engineering analysis domain
that spans both statics and dynamics and crosses all life cycle views.

### Near Term Action

David Leal has accepted the action item to provide a generic definition
of "state" for AP 107 consistent with the above thoughts. He will pass
it through the Engineering Analysis group for comment and then present
it at a Modules workshop scheduled for April in London. We will probably
(hopefully) be able to start a discussion of "Properties" at the ISO
STEP meeting in Lillehammer in June.

### The Unified System Semantics (USS) Set

During the San Francisco STEP meeting of the AP 233 team it was proposed
that there was a need to introduce into the current set of Units of
Functionality (UoF) a capability for organizations to create a
product-line specific "Uniform System Semantics" set. It was argued
that:

-   if AP 233's current set of UoFs enable the *unambiguous*
    representation of requirements, function and behavior,

-   and if the semantics used for defining product measures is
    *ambiguous*,

-   then the product's systems engineering data model will also be
    *ambiguous*

    This semantics set contains all product characterization and
    maturity measures relevant to products within a product line. Every
    measure of interest to the systems engineer is contained within the
    USS set. *This is key!*

    From the systems engineering perspective requirements are allocated
    to the physical and functional architecture with the hierarchical
    decomposition of function leading to functional elements each of
    which have behaviour. The systems engineer uses the USS set to
    define exactly what should be delivered by the responsible domain
    engineers. From the responsible domain engineers perspective the
    same information defines what must be delivered. This is the clean
    interface required. AP 233 tracks requirements down to the interface
    while the domain AP's track the details of the domain analysis and
    associated design iterations.

    See the NASA STEP Central website
    http://misspiggy.gsfc.nasa.gov/step - ap203recprac for the link to
    an indepth development of "Uniform System Semantics (USS) &
    Linguistic Variables"

### Representation and Exchange of Mathematical Expressions {#representation-and-exchange-of-mathematical-expressions .unnumbered}

Eliot Kimber of ISOGEN International Corp provided a STEP and SGML/XML
workshop. Eliot was one of the principle developers of XML. During the
workshop the status of markup languages for mathematics were discussed.
The following information list was extracted from Eliot's presentation
material:

-   OpenMath

-   SGML-based language for representing mathematics

-   Predates MathML

-   Intended for program to program communication

-   Focuses on semantic presentation

-   Does not address presentation

-   Does not appear to be as well thought out as MathML

-   MathML

-   XML language for representing mathematics

-   Two forms: presentational and semantic ("content")

-   Presentation form enables typesetting

-   Semantic form conveys meaning of expression

-   Semantic form could be applicable to representation of EXPRESS
    expressions

-   Semantic MathML Markup

-   Provides elements for common operators, relations, functions and
    data types

-   Can declare local variables within an expression

-   General enough to describe any expression system

-   All EXPRESS specific functions would be late-bound in MathML

-   EXPRESS specific expression language could be specialization of
    MathML

As an illustration of the need to semantic content, A + B = C is
ambiguous from a mathematical operations perspective. The symbols A, B,
C may represent scalars, matrices, vectors, sets, etc. The symbol + may
imply summation, aggregation, union, etc. If the equation is just for
presentational purposes within a contextual setting it is unambiguous
and adequate.

MathML supports both presentational and semantic representational needs.
Such groups as Mathematica are also picking up MathML. It appears that
MathML, which is an XML language for representing mathematics, will
satisfy all of the mathematical representation needs of AP 233.

### Representation of Assumptions and Limitations

The Behaviour bubble needs to contain this information to support the
views of both SE & PLCS and domain engineering analysis.

-   In the SE & PLCS view there is a need to know assumptions and
    limitations associated with the behaviour model. Context is evident
    and a presentational (typesetting) representation is adequate for
    the systems engineer.

-   The engineering domain view may need to use the descriptive
    expressions as the mathematical model of behaviour. This need
    requires the semantic form. For example, this would enable the
    expression to be directly processed by a software capability such as
    Mathematica. In a more general context a parser to unambiguously
    interpret the mathematical expression for other computational
    purposes could be created.

### Modularity

Discussions were held with developers and owners of AP 107, 109, 209,
210, PDM, EMSI and those leading the AP modularity effort. It appears to
me that AP 233's data model has now reached a reasonable state of
maturity. I feel that the ISO STEP meeting in Lillehammer would be a
ideal place take a first look at associated harmonization issues
relative to other data models for requirements, function, behaviour and
configuration management representation. Rogerio leads the PDES Inc.
modularity effort, he has promised to contact Sylvain to see if a
liaison meeting can be arranged. I suggest, near the end of the week.

## "PLCS on a Page"

**PLCS Initiative to extend STEP into Product Support**

A major, new, international initiative has recently been started to
accelerate the development of standards for Product Life Cycle Support
(PLCS) data.

Building on a proposal from the International CALS Congress, a group of
major industrial sponsors have joined forces to launch a 3-year project
to accelerate the development of International Standards that address
the information needed for through life product support.

Expected participants include: Lockheed Martin Corporation, Boeing,
Marconi Electronic Systems (includes GEC Marine), British Aerospace,
Rolls-Royce, Saab, DNV and several NATO Defence Ministries.

Based on the established techniques of STEP, the PLCS Initiative seeks
to provide global agreement on how to define and communicate the
information needed by users to plan and execute support for complex,
long life assets. The work will take full advantage of current STEP
standards and of work by the three major STEP Centres to develop an open
architecture for product data management (PDM) software.

As products grow more complex it is becoming ever more difficult to keep
the information required for maintenance in line with the changing
product. The information needed to conduct maintenance is also growing.
Configuration data, diagnostic data, failure modes, connection diagrams,
assembly drawings, special tools and test equipment, spares details,
test requirements the absence of any of these may stop the work in
progress. Improved feedback is needed to track maintenance costs and
eliminate the causes of downtime.

Areas to be addressed by the new standards include life cycle
Configuration Management and Change Control, Support Engineering,
Inventory Management and the conduct of Maintenance and defect
reporting. ISO/TC184/SC4/WG3/T8 are the responsible ISO Working Group.

Potential additional participants should contact the project leaders
directly on

nco@cals.nato.be or crawf03@ibm.net.

The statement of technical requirements, information requirements and
the current version of the data model can all be downloaded from website
http://www.cals-international.org/public/plcs/refdocs/1refdoc.htm . The
cals-international web site home page is www.cals-international.org.