Draft

1
Draft 12 of Concept Modelfor Systems
EngineeringMDSD review

• David W. Oliver
• Version March 27, 2003
• Wakefield, R.I.

2
Semantic Dictionary

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 alphabetica
lly, 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.
3
(3)
Domain of Interest
contained in
contained in
reference for
built from
C
categorizes
(5)
System View
(6)
(7)
has view
Stakeholder
Environment
Element
exhibits
part of
(1)
has
(4)
(8)
Interacts with
Stakeholder Need
satisfied by
System
(9)
(11)
allocated to
Reference Document
System Requirement
Property
represented by
statement of
reference for
(10)
derived from
(12)
(13)
(14)
verifies
Physical Property
Structure
Behavior
(see figure 10)
allocated to
budgeted to
Top Level Concept Model, Figure 1.
4
Top Level Model Description
Top Level Model The model needs to be read with
reference to the definitions in the
semantic dictionary. It starts with Element 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. Element is
built from Element 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 Element 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
Elements and Systems.
5
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. Stakeholder
s may include manufacturer, owner, user of
owners 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.
6
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 Reference Document that
establishes the source of the information. 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.
7
Kinds of Properties

• 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 Element 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.

8
Diagram of Structure
(14)
Structure
(19)
(17)
(15)
Interface Specification
described by
Part
Port
1
1
Interconnection (18)
(16)
Link
System Static Structure, Figure 2.
9
Description of Structure, Part, Part

Structure Structure is built from Part, Port,
and Interface Specification. Structure decomposes
hierarchically. This forces Part and Port to also
decompose hierarchically.
Part 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.
Port 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.
10
Interconnection, Interface , Spec

Interconnection 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 Properties.
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.
11
Behavior

Behavior Behavior is built from Function,
I/O (Input/Output), and Function Ordering as
shown in Figure 3. Any Element 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 1970s. 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.
12
Diagram of Behavior
(1)
Light blue background means this entity comes
from Figure 1.
(12)
Behavior
(20)
(21)
(22)
generates and consumes
Function Ordering
orders
Function
I/O
allocated to
allocated to
(6)
(4)
Environment
System
Behavior, Figure 3.
13
Description Function Based Behavior
A model for function Based Behavior is given in
Figure 4. I/O may trigger functions, starting or
terminating functions. I/O that triggers is
coupled to the function by binding to a Function
Control Port. I/O that does not trigger is bound
to a Regular Function Port. I/O arriving while a
function is active is stored in a queue unless it
is terminating I/O. Function ordering uses a set
of operators AND to define concurrency, Multi-exi
t 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.
Scripts are used to provide detailed control of
function ordering. Probabilities are assigned to
Or Out to facilitate execution of the behavior to
produce time lines or Monte Carlo
simulation. 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.
14
ResourceFunction Based Behavior

Resource
Function Based Behavior Resource is (1.)
the amount of input available to a function or
the amount of output available from it. (2.) or
the amount of property of a system available to a
function. Example 1. There exists some number of
missiles available to a missile battery available
for the function Shoot. Example 2. The
function transmit message may be allocated to a
satellite system, a fiber optic line, a microwave
link, etc. Each of these alternatives has some
value of the property bandwidth that may be
used by the function.
15
Function -
Resource Relationships
Function Based Behavior Captures
Captures indicates the resource which this object
requires (but does not destroy) during execution.
Resources are captured when the execution of
the function begins and released when the
function completes execution. Consumes
Consumes indicates the resource which this object
requires (and destroys) during execution.
Resources are consumed when the execution of
the function begins. Produces Produces
indicate the resource which is generated by the
function. Resources are produced when the
execution of the function completes.
16
Function Activation Rules

• Function
  Activation Rules
• Function
  Based Behavior
• 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 inputs that trigger
• the function are present at the function
  control ports. A function begins
• work if and only all resources to be utilized
  by that function are available.
• Otherwise it waits.
• 
  Run Rule
• Trigger signals received while a function is
  active are stored in queues.
• 
  Terminate Rule
• Functions complete generation of all their
  outputs, terminate, and pass
• activation to the next function when the time
  interval allocated to them
• expires. Functions complete production of all
  resources and return any

17

• I/O
  Queuing Rules
• Function
  Based Behavior
• A representative set of
  queuing rules follows
• 
  Triggering I/O
• Triggering I/O that arrives at function is
  stored in a FIFO queue. On
• its next activation the function uses the I/O
  first stored in the queue.
• 
  Non-triggering I/O
• Non-trigger signals received while a function is
  active are discarded.
• Non-trigger signals received while a function
  is dormant are stored in
• LIFO queues. It is the last I/O received that
  is used.

18
Function Based Behavior
generates consumes captures releases
Function Based Behavior
(20.7)
(12.1)
Resource
(20.1)
allocated to
Timing
generates consumes
Function Ordering
I/O
Function
orders
(20.2)
control
Script
has
(20.3)
(22.17)
bound to
stored in
Ordering Operations
Activation Rules
Function Port
controls sequence
Function Exit
(20.4)
Queue
(22.1)
triggers
(20.8)
Regular Function Port
Control Function Port
LIFO Queue
has
(22.19)
(22.18)
Run Rules
Start Rules
(20.5)
(20.6)
FIFO Queue
has
(22.11)
(22.8)
(22.2)
(22.12)
(22.6)
(22.3)
Sequence
Iterate
Loop
Or
And
Replicate
(22.16)
Terminate Rules
Probability
has
has
(22.20)
(22.9)
assigned to
Loop Limit
has
And In
And Out
Or In
Or Out
(22.5)
(22.13)
(22.15)
(22.4)
Iterate Limit
Loop Exit
Multi-exit Function
Function Based Behavior, Figure 4.
(22.10)
(22.7)
(22.14)
19
Function Exit
The
Function Exit Construct
Function Based Behavior A
Function Exit construct links a functional
decomposition to the exit paths identified for
the parent function. For example, assume you have
a Multi-exit Function with two exit paths. If
this is the leaf-level of your model,
scripting (or probabilities if no script is
defined) selects which path to take. However, if
this function is decomposed, there are Function
Exit constructs corresponding to the two exit
paths in the higher level function. When one of
the Exit constructs is encountered, execution of
the decomposition is complete and control is
passed to the corresponding exit path at the
higher level.
20
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.
21
(25)
has a set
measured in/has
Property
parameter value
(32)
(33)
measured in
assigns parameter
(13)
n
(26)
(31)
Physical Property
Property Value
has
modeled by
Name ID
(34)
assigned to
is a parameter for
(27)
(30)
(28)
(29)
(14)
AM Port
Structure
declared to have
calculated to have
working target
measured to have
(19)
(17)
(15)
Interface Specification
described by
Part
Port
1
1
Interconnection (18)
Structure and Physical Property, Figure 5.
22
Discussion of Figure 5
Discussion of Structure and
Physical Property 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. All of
these values are a result of a set
of measurements and analysis of the data. 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.
23
Cont Analytical Modeling

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.
24
Cont
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 model_parameter that in turn is a parameter
for analytical_model. Analytical_representation
has a set of parameter_assignments and is modeled
by one or several analytical models. be solved,
Analytical _representation. The several
Analytical_models provide answers at different
levels of fidelity and with different efforts of
computation. AM_port connects the analytical
results back to the appropriate location in
the part hierarchy.
25
Cont Emergent Properties
Emergent Properties and Budgeting of
Properties Example
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.
26
Figure 6 Car Example
Ta is an emergent property of Car. Dg is an
assembly property of Body
Figure 6.
27
Example of Fig 6

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.
It is hoped that reviewers Frisch and Thurman
will correct Figures 5. and 6. and this table.
28
Frisch Thurman comments

• Some definitions taken from the report of Frisch
  and Thurman are captured
• on the next three slides.
• Model_parameter
• 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
• default_value
• parameter_type
• reference_document
• type_name
• unit_of_measure
• valid_range
• default_value
• The default_value specifies a value for the
  parameter. The default_value need not be
  specified for a particular
• Model_parameter.
• parameter_type
• 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.

29
reference_document The reference_document
specifies either a specific document or an
identifier for the standard document that
contains the reference for the Model_parameter.
type_name The type_name specifies the string
used as the human-interpretable type name for the
Model_parameter. unit_of_measure 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 valid_range 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 Model_parameter.
30

Parameter_assignment Parameter_
assignment provides actual values for
characteristics declared formally by the
Model_parameter. The data associated with this
application object are the following
assigned_parameter parameter_value assigned_
parameter The assigned_parameter declares the
formal parameters assigned values by
the Parameter_assignment. parameter_value 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.
31


Analytical_representation An Analytical_represent
ation 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. NOTES 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
characteristics. 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
analytical_representation_name
model_parameter_assignment
model_representation analytical_representation_na
me The analytical_representation_name specifies
the string for the human-interpretable identifier
for this Analytical_representation. model_paramet
er_assignment 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.
32
model_representation The model_representation
specifies the Analytical_model as the basis model
for the Analytical_representation. Formal
constraints UR1 The analytical_representation_n
ame 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 model_pa
rameters. NOTE Only parameters declared in the
model_representation are assigned
values. Analytical_model Provides a
mathematical description of the properties of a
system. An Analytical_model may be a
Library_model. NOTES 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.
33

Analytical_model An
Analytical_model provides a mathematical
description of the properties of a system. An
Analytical_model may be a library model.
NOTES 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. NOTES 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.
34

• This part of ISO 10303 provides complete support
  for prefixes of units.
• The data associated with this application object
  are the following
• access_mechanism
• name
• parameter
• reference_document
• representation_language
• source_code
• access_mechanism
• 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.
• name
• The name specifies the string that is the
  identifier for the Analytical_model.
• parameter
• 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.

35
reference_document 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. representation_langua
ge 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. source_code 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.
36
Probability Distributions
Probabilities are applied to the values of
physical properties, and to the performance
requirement time duration assigned to functions.
A list follows of representative probability
distributions used in systems engineering tools.
37
Allocation of Requirement
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 system. 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 requi
rements, and non-feasible requirements.
Consequently the generalization/specialization of
Figure 6. Is non-exhaustive and inclusive.
38
Figure 7 requirement Classification for allocation
A Requirement Classification, needed to show how
requirements are allocated to Behavior System
Structure
(10)
System Requirement
User Defined
based on content and allocation
non-exhaustive inclusive
Functional Requirement
Performance Requirement
Physical Property Requirement
Interface Requirement
Effectiveness Measure
(35)
(42)
(38)
(36)
(37)
Imposed Design Requirement
Reference Requirement
(39)
(40)
Classification of Requirements for the Purpose of
Allocation, Figure 7.
39
Figure 8 Requirement Allocation
Property
Requirement Allocations, Figure 8.
Physical Property
Behavior
System Static Structure
assigned to
assigned to
consume generate
Function Ordering
order
Part
Port
I/O
Function
Interface Specification
allocated to
bound to
assigned to
assigned to
(28)
Reference Source
Interface Requirement
assigned to
Physical Property Requirement
assigned to
points to
assigned to
Functional Requirement
Performance Requirement
Reference Requirement
Imposed Design
Effectiveness Measures
used in
based on allocation
non-exhaustive inclusive
has
Regularization Function
has
(45)
Optimization Direction
Requirement_S
Weight
optimizes
used in
(44)
(43)
40
Summary of Allocation
Summary of Allocation Relationships

• Functional Requirements are assigned to to
  functions
• Performance 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

41
Physical Property Time
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
• begins.
• Stop Time is a Present Time that states where in
  Present Time a Time Interval

42
Physical Property Time
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.

43
Refined Decomposition for Physical Property and
Time, Figure 9.
Time Unit Mean Value Variance Prob
ability Distribution
Continuous Time
Present Time
Discrete Time
Time Interval
Stop Time
Start Time
44
System Engineering Management
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 discussion. 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
45
Verification Requirement Variation Event
(10)
categorized by
categorized by
traces to
(47)
(48)
satisfied by
performed with
(46)
causes
causes
has
specified by
scheduled by
uses
(50)
Verification Requirement Status
specified by
(54)
(53)
Verification Plan
(52)
(49)
causes
causes
assigned to
(51)
generates
Figure 10. Verification
46
Validation Procedure
(10)
(7)
(8)
Stakeholder Need
Stakeholder
represented by
has
involves
derived from
traces to
categorized by
categorized by
(57)
(56)
(55)
satisfied by
performed with
causes
causes
(60)
specifies
schedules
uses
(58)
(59)
specifies
Validation Plan
causes
causes
assigned to
generates
Figure 11. Validation
47
Risk digaram
Individual Risk Risk Title Risk ID Context Risk
Owner Originator Date found Date updated
AP233 Draft Concept Model for Risk March 20, 2002
combine to
incorporate
implements
Approach Strategy Strategy ID Description/Assump
tions Approach None assigned Accept
Watch Mitigate Prevent Transfer
drive
Inputs
Technology Program Plan Schedule/Cost
Constraints Risk Management Plan
drive
implies
has
resolves
likelihood of
has
n
48
Category
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. Categ
ories 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 language. 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 -
generalization.
49
System Engineering Definitions for pigeon UML
(3)
Domain of Interest
Box means Class or Meta Class (top is name) or
type 2nd box means attributes 3rd box means
Methods or member functions Diamond means
aggregation/decomposition Line means relationship
(words on line describe relationship) (XX) Means
look at Concept semantic dictionary Diamond with
a C in the middle means a Complete
decomposition Loop line with Diamond means
hierarchal decomposition of items of the same
type Arrow/triangle means specialization/generali
zation Depending on direction A number on each
end of a line means mulitplcity
(1)
(4)
(22.10)
1
1
MDSD Workshop 5 Feb 2003