Model for Semantic Dictionary Draft by dffhrtcv3


									Draft #9 of Concepts Needed
 for System Static Structure

         David W. Oliver

    Version November 12, 2002
          Wakefield, R.I.
                         Concept Model for Systems Engineering

Semantic Dictionary and Accompanying Model
The concept model consists of two interlocking parts. The first part is the
semantic dictionary that defines each term. It is currently captured in an Excel
spread sheet. The definitions have been written to satisfy the ISO standard for
writing definitions that can be found on the BSCW web site. The definitions are
an ordered set. Definitions lower in the set use terms found higher in the set.
This helps prevent circular definition. Since the definitions are not arranged
alphabetically, they are numbered with a reference number to aid in locating them.

Definitions according to the ISO standard define kinds of things, composition
of things from other things, and associations among things. When one reads
ten or more text definitions the usual mind finds it difficult to remember the
many relationships implied. Hence a model accompanies the semantic dictionary.
The dictionary explains meanings in natural language. The model captures the
multitude of relationships in a graphic form so that the relationships can be
scanned. The model is written in UML 1.X, with indications of semantics
that are missing from the language.

                                                             Domain         (3)
                                                            of Interest

                                   C                                  (1)
        (7)             (6)
                                                                                        has view
Stakeholder              Environment                     SE_Thing


          (8)                                                         (4)
                                    Interacts with
Stakeholder     satisfied by                                System
  Need                                                                                                      (9)                                 (11)
                                          allocated to
                          System                                                                   Property                          Property
                        Requirement                                                                                                  Reference
    represented by                             statement of                                                          reference for


                derived from
                                                                                 (12)                         (14)                       (13)
                                                                   Behavior                        Structure

                                                                                    C                                C

Top Level Concept Model, Figure 1.
                                                                            allocated to                                    budgeted to

Top Level Model
The model needs to be read with reference to the definitions in the semantic
dictionary. It starts with SE_Thing that is any thing on which repeated
measurements can be made for the engineering purposes of interest. This is
a necessary definition because otherwise it is not possible to verify that a
design or implementation meets its requirements. SE_Thing is built from
SE_Thing in a hierarchy. The aggregation symbol has a small “C” in it to show
that what is meant is a decomposition into all of the parts. The special notation is
used because this concept is missing form UML 1.X.

The Domain of Interest constitutes all the things of interest to the application.

System is a kind of SE_Thing and thus it is built of systems in a hierarchy
and it must have measurable characteristics that are repeatable. What makes
the System unique is that it has well defined relationships with all of the things
with which it interacts. The collection of those things is its Environment. To
have a system it is necessary to characterize what is in the system and what is
in the environment along with the static and dynamic interactions between
system and environment. The Environment contains SE_Things and Systems.
Different persons in engineering, manufacturing, maintenance, and management
need different sets of information about the system. Manufacturing personnel
need to know about all the materials, nuts and rivets that go into the system and
how they assemble together. Maintenance personnel need to have diagnostic
information and deal with replaceable units of the system. There are a very large
number of such useful collections of information, each with its own context.
System View provides for the collection of such sets of information, each set in
a particular context.

An important subset of things in the environment are the Stakeholders. These are
all the persons and organizations with a need, preference, or interest in the system.
Stakeholders may include manufacturer, owner, user of owner’s services, user
of the system, operator, maintainer, government regulator. Stakeholder Need
represents their need, preference, interest, etc. in the system. If the System is
designed and implemented well, then it satisfies these needs in a manner that is
superior to competitive systems. It sells in the marketplace.

A Property is a named measurable or observable attribute, quality or
characteristic of an se_thing. If you can measure it or observe it it is called a
property. Properties have units, values, variances and probability distributions
associated with them. They may be looked up in handbooks of properties of
standard materials, they may be calculated from the structure of the thing, or
they may be measured directly. In general they are tensors and may be a function
of time. Because of the multiple ways of arriving at a property and its values, it
is important to have a Property Reference that establishes the source of the

A Requirement is a statement of a Property that a System shall exhibit. The
relationship to System is handled by allocating the requirement to the system that
shall exhibit that property. This formality allows the engineer to consider
alternative allocations to different systems that may fulfill the requirement. It is
fundamental to trade-off among solutions. Requirements originate from
Stakeholder Needs. As the design proceeds in levels of detail, requirements
are derived from other requirements. These “derived from” relationships are
preserved as traceability relationships. In a real world problem requirements
will be changed from time to time. It is critical to trace from a requirement
that has changed to other requirements impacted by that change.
It is useful to distinguish among three kinds of properties.

    • Structure, the description of how a system decomposes into its parts
      and how the parts assemble to make the whole.

    • Behavior, what the system does in response to the things in its
      environment. This includes both desired responses that satisfy needs,
      and prevention of undesired responses (failures) that can cause injury,
      destruction, or loss.

    • Physical Property includes all the measurable or observable attributes,
      qualities or characteristic of an se_thing that cannot be observed
      in interaction with the environment. Additional instruments or tools
      are required to make the measurement or observation. Mass may
      require a scale for weighing, index of refraction may require use of
      an optical instrument.

    These three kinds of properties are described separately and then
    interrelated. This principle supports the consideration of alternatives.


                     (19)                          (17)                                         (15)
                        Specification   described by       Port                          Part

                                                  C                    1                               C

                                                                  Interconnection (18)


System Static Structure, Figure 2.


Structure is built from Part, Port, and Interface Specification.
Structure decomposes hierarchically. This forces Part and Port
to also decompose hierarchically.


The Part is simply a part or component list. The name used
follows the STEP manufacturing point of view of looking at a part or
component and talking about it as an assembly because their job is to
assemble it. This is a place where it may be advisable for clarity to use the
words component or part as an alias for Part.


Each Part (part or component) attaches to others at particular
locations. These locations are called Ports. This is a familiar idea when
one thinks of the port on a power cord that plugs into a port on the wall
to get electric power. It also applies to the surface of a bridge, a port, that
interacts with wind, a port. In the second case the concept is less intuitive
and more formal but it works. Ports connect to ports.

Interconnection specifies which ports attach to which other ports. Together
Part, Port, and Interconnection specify how parts go together
to constitute the whole. This description does not include Behavior or Physical

                               Interface Specification

Each port has associated with it a description, an Interface Specification, that
describes the geometry, forces, transferred material or energy or information,
protocols, how to assemble to it, and tests that may be required of the
port-to-port connection. For two ports to be interconnected their interfaces
must be compatible.

                  Structure, Behavior and Physical Property

Structure, Behavior and Physical Properties are described separately. Behavior
and Physical Properties are allocated or budgeted to Part to
complete the description.

Behavior is built from Function, I/O (Input/Output), and Function Ordering
as shown in Figure 3. Any SE_Thing may be I/O (Light blue shows an
entity comes from Figure 1.). A Function is a entity of transformation that
changes a set of inputs to a set of outputs. Function Ordering orders the
functions such that it is possible to represent sequence, concurrency,
branching, and iteration.

There are two major forms of representing Behavior. Function based behavior,
independent of state, emerged in systems engineering in the 1970’s. It provides
for completed functions to enable succeeding functions, for I/O to trigger
functions, and for ordering operators to represent sequence, branching, and
iteration. The SEDRES model represents this with a Petrie net model.
UML 2.0 contributors may be using a Petrie Net model. If so, then these
two models need careful comparison.


                                                                                              Light blue background means this
                       C                                                                      entity comes from Figure 1.



        (21)                               (20)                                            (22)
               I/O                                 Function             orders     Function
                               C                                   C

                                          (24)                   (6)                         (23)                              (4)
                                   External                                           Internal
                                                                 Environment                           allocated to   System
                                   Function                                           Function
                           1                      allocated to

                                                                 generates and consumes

Behavior, Figure 3.
                        Function Based Behavior

A model for function Based Behavior is given in Figure 4. I/O may be
regular I/O, it may trigger functions, or it may terminate functions.
Function ordering uses a set of operators: AND to define concurrency,
Multi-exit Function or OR to represent alternative paths, a sequence operator,
and LOOP, Iterate, and Replicate constructs. LOOP and ITERATE require
limits to control their termination. At leaf level scripts are used to provide
information like selection criteria for multiple exits from a function.

After tools are to exchange behavior information that includes timing, the
tool interpretation engines may execute the models to produce time lines or
perform Monte Carlo calculations. These results will differ unless the tools
agree on function activation rules.

A representative set of activation rules follows:

                                   Start Rule
• A function is activated and begins its work if and only if all preceding
  functions and threads of functions have completed and all triggering inputs
  are present. Otherwise it waits.

                                   Run Rule
• Trigger signals received while a function is active are discarded without
  any actions taken.

                                Terminate Rule
• Functions turn off when they have generated all their outputs or have
  received a Terminating Input.

                                         Behavior   C

                                                        allocated to
                     generates                                                Timing
           I/O       consumes
                                         Function                                              Function
   C                                C
                                                             orders                            Ordering

Regular             Terminating                                Ordering                                          Activation
  I/O                   I/O          terminates               Operations                                           Rules
           I/O           triggers

                                                                                                              Start       Run
                                                                                                              Rules       Rules
                           Or           Sequence        Loop              Iterate      And        Replicate

                                                    has               has                                          Rules
            Or Out                  Or In                                           And In       And Out

                                                        Loop              Iterate
                                                        Limit             Limit
Scripts    control        Multi-exit
                          Function                                                           Function Based Behavior, Figure 4.

State based behavior emerged from automata theory and has matured into
State Charts that provide for state explosion in highly concurrent models.
SEDRES has a representation for this and has demonstrated model transfer
between Statemate and Teamwork Real Time tools.

In the UML community Action Semantics are to provide a basis for
state based behavior. These two approaches require careful correlation. The
concept model here does not go beyond the very general notion of function
ordering, but notes the critical importance of correlation among emerging
detailed models.

                    Structure and Physical Properties

Physical Property, its relationship to the Structure hierarchy and to analysis
is shown in Figure 4. The key concept is that performance, behavior and
physical properties of the whole results from the structure, the behavior and
physical properties of the parts. They are not related to a class tree.

                                     assigned to Parameter_assignment                                                                     (25)
model_parameter_assignment (33)                                               (32)
                                                      assigned_parameter                                                 measured in
analytical_representation_name                                 assigned by                                                     (13)                             (26)
                                                                                                                      Physical        has         Property
                                                       Model_parameter                                                Property                     Value
                modeled by
                                                                                         represented by                Name
                                                           type_name                                                                                mean
                             (34)                                                                                       ID                         variance
                                                         unit of measure
                                                      reference_document                                                                         probability_
                                                         parameter_type                                                                          distribution
                                                           valid_range                                                                            histogram
name                                                      default_value
representation_language                                                                    assigned to
source_code                                                              (27)                     (28)                                           (30)
                                                                                Required/                Calculated             Target              Measured
                                                                                Budgeted                  Property              budget              Property
                                                                                Property                   Value               Property              Value
                             (14)                                                Value                                           Value

                                                      C                         declared
                                                                                                calculated             working
                                                                                to have                                                          measured
                                                                                                   to have              target
                                                                                                                                                   to have

(19)                          (17)                                               (15)
Specification     described by        Port                             Part

                              C                   1                                  C

                                             Interconnection (18)
                                                                                         Structure and Physical Property, Figure 5.                                    17
                             Discussion of Figure 5.

System Assemblies in the Part tree all have Physical Properties such
as mass, power consumption, geometry, MTBF, drag coefficient, etc. The
Physical Properties are assigned to a particular Part. A Physical
Property has a name and an ID that identifies it uniquely. For example, many
different System Assemblies have the Physical Property mass. Consequently
each of these assigned Physical Properties needs an ID. Each has an associated
unit in which it is measured.

A Physical Property assigned to a particular Part has values. The
value may be expressed as a mean, a mean with variance, a probability
distribution, or a histogram. The value goes through a series of versions as the
system definition evolves. The Part is declared to have a Required
or Budgeted Value.

The Part may have a Target Budget Property Value used as a guide
or target as designers consider alternatives. A Part, as a whole,
may have a Calculated Property Value based on analysis of the properties,
behaviors and interactions of its parts. When a Part is built, it may
have a Measured Property Value.                                                    18
                            Discussion of Figure 5.
                 Calculated Property Values - Analytical Modeling

Any one assembly is an interconnection of assemblies one tier down in the tree.
The emergent properties of any assembly are a result of the properties,
interconnection,and interaction of the sub-assemblies from which it is built. The
relationships may be very non-linear in the physical world as observed with
phenomena like combustion and friction.
The basic relationships for analytical modeling of emergent properties
and budgeting of properties are shown in Figure 5. A set of engineering
equations or estimates, analytical models, are used by systems engineers
to budget properties to the interacting sub-assemblies as a guide to
designers at the lower level. When designs for all of the sub-assemblies
are available, their individual properties and interactions are better defined.
The same equations are used to calculate the emergent properties of the
complete assembly. The fidelity of the calculations increases as the
work proceeds.

A Part, as a whole, may have a Calculated Property Value based
on analysis of the properties, behaviors and interactions of its parts. This is
accomplished by estimation or by an analysis that solves the relevant
engineering equations. This makes it necessary to represent physical properties
as parameters in the equations of the relevant analysis model. Model Parameter
provides this parameterization. It has an attribute of its of the unit of measure
applicable to the analysis. This may be different from the unit assigned to
Physical Property. The reference_document attribute specifies the
standard document that contains the reference for the Model_parameter. A
default value and valid range can be specified when needed.

Parameter_assignment assigns parameters to the analytical equations that must
be solved, Analytical _representation. Each Analytical_representation may have
associated with it several Analytical_models that provide answers at different
levels of fidelity and with different efforts of computation.

          Emergent Properties and Budgeting of Properties
One may wish to develop a car that can accelerate from zero to sixty miles
per hour in 6.5 seconds or less. This is a required emergent property of the car.
This behavior is a result of the power of the drive train, the air resistance of the
body, the total mass of the car, and the friction of the tires on the road.
These parameters are inter-related by a second order differential equation.

The differential equation is first used to budget target values of mass, power,
drag coefficient, and tire friction to the appropriate components as targets
for the designers. When the designs are available with definite property
values, the same equations are used to calculate the emergent property,
time for acceleration from zero to sixty mph for the car.

Note that there may be several distinctly different approaches to the solution
of what sub-components to use. Thus it is useful for the assembly to have
relationships that indicate if it is an alternative or is selected as a solution, if it
meets requirements, and what its regularization function value may be as the
basis of selecting a particular solution from among the alternatives.
                                     Weight, Wc
                                     Time to Accelerate
                                        0 to 60 mph, Ta

       Body                      Chassis              Drive Train            Tires             Electrical
Weight, Wb                   Weight, Wch              Weight, Wdt         Weight, Wb           Weight, We
Drag Coefficient, Dg                                  Power, Pdt          Friction, Tf

                                             Engineering Equations
                          Wc = Wb + Wch + Wdt + Wh + We

                          Wc * d2x/dt2 + Dg * dx/dt = Tf *Wc         0 < dx/dt < Pdt/(Tf*Wc)
                          Wc * d2x/dt2 + Dg * dx/dt = Pdt/(dx/dt)    Pdt/(Tf*Wc) <dx/dt

                          initial condition: x=o, dx/dt=0

                          compute: t, Ta, when dx/dt=60 mph

  Figure 6.            Ta is an emergent property of Car. Dg is an assembly property of Body

                                                Example of Figure 6.

 The Table below is a crude map of the equations in Figure 6. Into the concept
 model defined in Figure 4 for the car example. Only the properties of car have
 been mapped. Note there are two analytical models. One is very simple and
 assumes constant traction once the car is in motion and rolling friction applies.
 The second is of higher fidelity and uses traction vs. Rpm. from actual engine
 data, including transmission gear changing.

 System    Physical             Required Model    Unit of     Default    Parameter      Analytical     Analytical Representation
Assembly   Property    Unit      Value Parameter measure       value     assignment       repr.         model       Language

                                                                         Independent                   Conservation
                                3500 + -                      3500 + -      variable   Conservation of of mass; see
  Car       Weight    Pounds      100      Wc     Kilograms     100        equation 1      mass           equation     Math-ML
                                                                                                         Version 1:
             Time to                                                                   Force equation Constant
           accelerate                                                    time variable    with drag    traction; see
  Car      0 - 60 mph Seconds    > 6.5     Ta     Seconds       6.5      equation 2,3    coefficient      equation     Math-ML
                                                                                                         Version 2:
                                                                                                        traction vs.
                                                                                                         RPM; see
                                                                                                          equation     Math-ML

   It is hoped that reviewers Frisch and Thurman will correct Figures 5. and 6.
   and this table.
Some definitions taken from the report of Frisch and Thurman are captured
on the next three slides.

A Model_parameter is a formally declared variable of the analytical model provided for an external application to

populate at execution time in a computing environment.

EXAMPLE: In Spice, temperature is a Model_parameter that may be set at the execution time.

The data associated with this application object are the following:








The default_value specifies a value for the parameter. The default_value need not be specified for a particular



The parameter_type specifies either a boolean_property_type, a logical_property_type, a physical_property_type, or a

string_property_type for the Model_parameter.

The reference_document specifies either a specific document or an identifier for the standard document that contains the

reference for the Model_parameter.


The type_name specifies the string used as the human-interpretable type name for the Model_parameter.


The unit_of_measure specifies the string used as the descriptive label for the unit of measure associated with the

Model_parameter. The unit_of_measure need not be specified for a particular Model_parameter. The representation of

units described in ISO 10303-41 shall be used. Note that the unit used in requirements specification may differ from

the unit_of_measure used in analysis


The valid_range specifies the appropriate range of values of the Model_parameter. The valid_range need not be specified

or a particular Model_parameter. There may be more than one Coordinated_characteristic for a Model_parameter.

The valid_ranges need not be contiguous.

NOTE: The prefixes of the valid_range and default_value may be different as long as the base units are the same type.

Formal constraints:

UR1: The combination of the reference_document and the type_name shall be unique within a population of



Parameter_assignment provides actual values for characteristics declared formally by the Model_parameter.

The data associated with this application object are the following:



The assigned_parameter declares the formal parameters assigned values by the


The parameter_value specifies actual values for the Parameter_assignment.

Formal constraints:

WR1: The type of units of the parameter_value shall be the same as that of the assigned_parameter.


An Analytical_representation is the association of specific properties of specific System Assemblies with an Analytical_model in
order to unambiguously characterize the performance of a specific Part.


 1.This entity accomplishes a function similar to the parameter assignment part of a statement in a Spice netlist, or a function or
   subroutine call in a computer program. This capability is useful where the parts in the library have many parameters, not all of
   which apply to each simulation model that could be used for the part. This entity matches up the correct parameter values with
   the correct model.
 2.The properties specified should be in accordance with the capabilities and limitations of the Analytical_model. That is, the
   mathematical formulations in the Analytical_model apply over limited ranges of real product characteristics and environmental
 3.This part of ISO 10303 does not standardize qualification of Analytical_representations for an intended usage.

The data associated with this application object are the following:



The analytical_representation_name specifies the string for the human-interpretable identifier for this Analytical_representation.


The model_parameter_assignment specifies the role of the Parameter_assignment for the Analytical_representation. There shall
be one or more Parameter_assignment for the Analytical_representation.

NOTE: For each parameter declared in a model definition, an actual value must be assigned when that model is referenced,
unless there is a default assignment included in the source code for the model.


The model_representation specifies the Analytical_model as the basis model for the Analytical_representation.

Formal constraints:

UR1: The analytical_representation_name shall be unique within a population of Analytical_representation.

WR1: Each member of model_parameter_assignment.assigned_parameter shall be a member of model_representation

NOTE: Only parameters declared in the model_representation are assigned values.


Provides a mathematical description of the properties of a system. An Analytical_model may be a Library_model.


 1.In this part of ISO 10303 an Analytical_model includes the variable declarations of the mathematical description but may not
   include the assignment of actual values for the variables declared.
 2.This part of ISO 10303 provides support for computer systems to verify type consistency between product data defined in
    this part of ISO 10303 and product data captured by Analytical_models.
 3.This part of ISO 10303 describes the interfaces (ports) to an Analytical_model and provides support for type checking of the
    units used for the parameters that may be assigned values for an Analytical_model.


An Analytical_model provides a mathematical description of the properties of a system. An Analytical_model may be a

library model.


In this part of ISO 10303 an Analytical_model includes the variable declarations of the mathematical description but may

not include the assignment of actual values for the variables declared.

This part of ISO 10303 provides support for computer systems to verify type consistency between product data defined in

this part of ISO 10303 and product data captured by Analytical_models.

This part of ISO 10303 describes the interfaces (ports) to an Analytical_model and provides support for type checking

of the units used for the parameters that may be assigned values for an Analytical_model.

EXAMPLE: consider the case where actual values are not included: the Analytical_model for a resistor that is coded in

pseudocode. When the Analytical_model is referenced by an analytical_representation, literals will be supplied for items

declared in the interface; both connections and their parameters, and the simulator will ensure that types are compatible.


Usually the system is exercised in experiments to evaluate the usefulness of the system in the intended application.

The language, syntax, and internal semantics of an Analytical_model are not specified by this part of ISO 10303.

This part of ISO 10303 provides complete support for exchange of units, including SI units, derived units, and user

declared units.

This part of ISO 10303 provides complete support for prefixes of units.

The data associated with this application object are the following:








The access_mechanism is an inverse relationship that specifies that the existence of the Analytical_model is dependent

on the existence of the Analytical_model_port that specifies the Analytical_model as its accessed_analytical_model.

There shall be one or more Analytical_model_port for an Analytical_model.


The name specifies the string that is the identifier for the Analytical_model.


The parameter specifies the role of the Model_parameter for the Analytical_model. There shall be one or more

Model_parameter for a particular Analytical_model. Figure am illustrates the use of parameters.

NOTE: Parameters of a model are separated from their connections to support the nodal formulation.


The reference_document specifies the role of the document for the Analytical_model. The reference_document

includes interface specifications for Analytical_models of interest to the enterprise.


The representation_language specifies the Language_reference_manual that defines the semantics and syntax of the

computer interpretable strings in which the Analytical_model will be encoded. Figure am illustrates how the

representation_language is specified and coded.

NOTE: Only representation_languages that use characters from the ASCII code are supported by this part of ISO 10303.


The source_code specifies the role of ths specification for an Analytical_model. The source_code contains the

source code for the Analytical_model. Figure am illustrates how a source_code is specified and coded.

Formal constraints:

UR1: The combination of the name and the reference_document shall be unique within a population of Analytical_model.

UR2: The combination of the name and the source_code shall be unique within a population of Analytical_model.

                        Allocation of Requirements
Depending upon their content, requirements are allocated to different
parts of the information model. Requirements describing functions are
allocated to functions, etc. This is a useful way of classifying requirements
for the purpose of creating a logically consistent model or description of a

Within systems engineering there is no single standardized way of classifying
requirements and many different classifications for different purposes are
in use. The classification given in Figure 6. Is defined as shown because it
is useful for the purpose allocating or assigning requirements.

It is not possible to enforce any process with an information model and AP233
is intended to support both pest practices and other practices in use. Hence, any
collection of requirements may contain compound requirements, contradictory
requirements, and non-feasible requirements. Consequently the
generalization/specialization of Figure 6. Is non-exhaustive and inclusive.

             A Requirement Classification,
         needed to show how requirements are
      allocated to Behavior & System Structure

                               System Requirement                      User Defined

                              non-exhaustive       based on content and allocation

    Effectiveness     Functional        Temporal                 Physical             Interface
      Measure        Requirement       Requirement               Property            Requirement
    (42)            (35)                    (36)                Requirement                   (38)
                           Imposed Design
                            Requirement             Reference
                                        (39)        Requirement

Classification of Requirements for the Purpose of Allocation, Figure 7.

 Requirement Allocations, Figure 8.                                                                          Property

                        C    Behavior                         System Static Structure         C               Physical
                                   C                                                C                         Property        assigned to
                                                assigned to

       consume                                   Function
I/O    generate     Function           order                                   Interface              Port                    Part
                                       allocated to
      bound to                                                                                                  assigned to
                                                              (28)                      assigned to
                                                Source                   Interface

                                                                                                                                                 assigned to
          assigned to
                                                                        Requirement                                  Physical
                              assigned to             points to
       Functional            Temporal                  Reference
      Requirement           Requirement               Requirement

                                                                         Effectiveness                  used in
                                                                                                                         Imposed Design
                                                 based on allocation       Measures
                            non-exhaustive                             has
                                                                                             has         Regularization Function            (45)
                                    Requirement_S                Direction              Weight           used in                 optimizes
                                                                                              (44)                                                             34
                 Summary of Allocation Relationships

• Functional Requirements are assigned to to functions

• Temporal Requirements are assigned to functions

• Function is allocated to Part (red used because of line crossings)

• I/O is bound to ports (red used because of line crossings)

• Interface Requirements are assigned to Interfaces

• Physical Property Requirements are assigned to Part

• Imposed Design is assigned to the Part on which it is imposed

• Reference Requirements point to a Reference Source that may contain
  requirements of all the kinds in the classification

                          Physical Property and Time

Figure 9. Shows draft models for Physical Property and Time. Physical Property
and Part are under study by a team member and improved models
are expected for Figure 9. and Figure 5.

The model for time in Figure 9. is preliminary and needs discussion.

• Continuous Time is a dimension along with three spatial dimensions used by science
  and engineering to describe reality using math. It has no past, present or future.

• Present Time recognizes a standard of year, month, week, day, hour, minute, and
  second to represent past, present, and future. It is the basis of plans and schedules.

• Time Interval provides a time duration that may be assigned to a task or function to
  represent how long the task will take for completion.

• Start Time is a Present Time that states where in Present Time a Time Interval

• Stop Time is a Present Time that states where in Present Time a Time Interval
                        Physical Property and Time

• Discrete Time is time represented by clock pulses of negligible duration.
  In this approximation events occur on each clock pulse.

Time is one of the most accurately measured quantities that we have. Current
accuracy of measurement is about one part in 10 -13. Research underway may
extend this to 10 -17. Many properties now have primary standards based in
part on time.

Refined Decomposition for Physical Property and Time, Figure 9.

Measurement                Measurement                                      Time
Infrastructure               Method                               Unit
                                                                  Mean Value
                                 measures                         Variance
                                                                  Probability Distribution

              Physical Property       (13)
           Unit                              Continuous           Present           Time      Discrete
           Mean Value                          Time                Time            Interval    Time
           Probability Distribution
           Value Range
                                                          Start             Stop
                                                          Time              Time

                  Systems Engineering Management

Three Models follow that are important to systems Engineering Management.

The models for verification and validation are at first draft level and need

The model for Risk was discussed with the Risk Working Group at
the INCOSE 2002 symposium. AP233 is waiting for there corrections
and changes. The existing model is based on information from the
risk working group, NASA Goddard Risk Attributes in SLATE
‘GPM’ Data Base March 7,2002 (Dave Everett), and from NASA
JPL Risk Process Diagram


                                 categorized by                             categorized by
                    traces to
                                                                                              (47)                                    (48)
                     Verification                                                   Verification                            Verification
                (46)                              satisfied by                                          performed with
                     Requirement                                                      Event                                 Procedure

                                         causes                         causes

        has                                             Risk                            uses                 scheduled by         specified by

     Verification                                                                       Verification                                  (50)
     Requirement                                                                       Configuration
(54)                                                             (53)                                       specified by    Verification
                                                                 (52)                                (49)
                                       causes                            causes

               assigned to

                              (10)                                     (8)                           (7)
                     System                                  Stakeholder                  Stakeholder
                   Requirement                                 Need
                                     represented by                            has                            involves

             derived from
                  traces to                                           categorized by
                              categorized by

                  (55)                                                                  (56)                                  (57)
                     Validation                                                Validation                           Validation
                                              satisfied by                                     performed with
                    Requirement                                                  Event                              Procedure

                                     causes                       causes
(60)                                                Risk                          uses            schedules              specifies
   Requirement                                                                     Validation (58)
     Status                                                                      Infrastructure
                                                                                                 specifies          Validation

                                  causes                           causes

             assigned to


Individual Risk                     Related Risk                                                     Contingency Plan
                                   R-R Title
Risk Title        combine to
                                   R-R ID
                                                          AP233 Draft Concept                        Plan ID
Risk ID                                                                                              Triggers
Context                            Risk Title               Model for Risk                           Date Applied
Risk Owner                         Risk ID                  March 20, 2002                           Date Closed
Originator                         Select Rule                                                       Closed by
                                   Category Name                                   incorporate
Date found                                                   Lessons Learned                         Closing_Rationale
Date updated                                                 Lesson Title                            Mitigation_Effects
                                                             Lesson ID                                 _Description
                                                             Lesson Date                             implements
                                                             Lesson Description
                                                             Lesson Category                     Approach Strategy
                    Risk                                                                         Strategy ID
             Window_open                                                                         Description/Assumptions
             Window_closed                                           Inputs                      Approach:
             Risk_Handling                                   Technology                            None assigned
             Time Frame                    drive             Program Plan                         Accept
             Priority                                        Schedule/Cost Constraints             Watch
            has          implies                             Risk Management Plan                  Mitigate
    Status                                                          Consequence                    Transfer
  Status Title       Risk Title                                     Risk Title
  Status ID          Risk ID                                        Risk ID
                                                   likelihood of
  Risk ID            Type: a (%),b,c                                Type: a,b,c
                                                                    Consequence                           Impact
  Risk Title         Probability Distribution:                                     has
                                                                      number                         Risk Title
  Status Names:        Name                                                                      n
                                                                    Probability_                     Risk ID
   Submitted           Mean
                                                                    Distribution                     Affected_Thing_Title
   Retired            Variance
                                                                                                     Severity             42
The decomposition tree for Part is more than a simple parts
tree. At any node one may introduce a category of parts. For example, an
automobile may have several different engines that can be used in the
automobile, each providing a different level of economy and performance.

Categories are a grouping of elements into a set based on defined properties
that serve as selection criteria for which elements of all those in the universe
belong in that set Explanation: It is categorization that enables us to define
alternatives and create taxonomies for libraries. This is one of the forms of
generalization/specialization. Note that this is NOT INHERITANCE as found in
object-oriented software languages. Physical elements, matter and energy, do
not inherit their properties. Rather they posses the properties of themselves and
can be identified by measurement of those properties. For a discussion of these
issues in computer science see the work of Barbara Liskov and her CLU

Note: the subcategories may be exclusive or inclusive and
      the subcategories may exhaust the super category or not
      there are four such possibilities
Category is the basic concept in the physical world to support specialization -

To top