# Presentation: 299814

## Draft #12 of Concept Modelfor Systems EngineeringMDSD review

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

## 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
- 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.

## Top Level Concept Model, Figure 1.

**Domain**
**of Interest**

**Element**

**System**

**Property**

**Structure**

**Physical**
**Property**

**Environment**

**System**
**Requirement**

- statement of

- Interacts with

- exhibits

- allocated to

**Stakeholder**
**    ****Need**

**Stakeholder**

- satisfied by

- represented by

- has

- allocated to

- budgeted to

**System**
**View**

- has view

- (1)

- (3)

- (5)

- (4)

- (6)

- (7)

- (8)

- derived from

- (9)

- (10)

**Behavior**

- (12)

- (14)

- (13)

**Reference**
**Document**

- (11)

- reference for

**Top Level Concept Model, Figure 1.**

- categorizes

- reference for

- verifies

- (see figure 10)

- contained in

- contained in

**C**

- built from

- part of

## Top Level  Model Description

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

## 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 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.

## 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.

## Diagram of Structure

**Port**

- (17)

**Interface**
**Specification**

- (19)

**Part**

- described by

- (15)

- Interconnection (18)

- 1

- 1

**Structure**

- (14)

**System Static Structure, Figure 2.**

**Link**

- (16)

## Description of Structure, Part, Part

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

## Interconnection, Interface , Spec

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

- Interconnection, Interface , Spec

## 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 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.

## Diagram of Behavior

**Behavior**

- (12)

**Function**

- (20)

**I/O**

- (21)

**Function**
**Ordering**

- (1)

- generates
-     and
- consumes

- orders

- (22)

**System**

- (4)

- allocated to

**Environment**

- (6)

- allocated to

**Behavior, Figure 3.**

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

## 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-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. 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.

## ResourceFunction Based Behavior

**                                       ****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.

**Resource****Function Based Behavior**

##                                    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.

## 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
-    resources that were captured during execution.

**Function** **Activation Rules**

##                                             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.

## Function Based Behavior

- orders

-       I/O

-   Function

- Function
- Ordering

- Regular
- Function
- Port

- Control
- Function
- Port

- Ordering
- Operations

- Activation
- Rules

- Script

- Sequence

- Iterate

- Loop
- Limit

- Loop

- And In

- And Out

- Multi-exit
- Function

- Or In

- Or Out

- Iterate
- Limit

- Terminate
- Rules

- Run
- Rules

- Start
- Rules

- has

- bound to

- Or

- And

- Replicate

- has

- has

- control

- Timing

- allocated to

- generates
- consumes

**Function Based Behavior, Figure 4.**

- Function
- Port

- Queue

- has

- stored in

- Probability

- assigned to

- Loop
- Exit

- has

- Resource

- triggers

- Function
- Exit

- controls
- sequence

- generates
- consumes
- captures &
- releases

- (12.1)

- (20.8)

- (20.7)

- (20.6)

- (20.5)

- (20.4)

- (20.3)

- (20.2)

- (20.1)

- (22.1)

- (22.2)

- (22.3)

- (22.5)

- (22.4)

- (22.20)

- (22.16)

- (22.14)

- (22.13)

- (22.12)

- (22.11)

- (22.10)

- (22.9)

- (22.8)

- (22.7)

- (22.6)

- (22.15)

- (22.19)

- (22.18)

- (22.17)

**Function Based Behavior**

- LIFO
- Queue

- FIFO
- Queue

- has

## Function Exit

**                                            ****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.

**Function Exit**

## 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.

## Structure and Physical Property, Figure 5.

**Port**

- (17)

**Interface**
**Specification**

- (19)

**Part**

- described by

- (15)

- Interconnection (18)

- 1

- 1

**Structure**

- (14)

**Structure and Physical Property, Figure 5.**

**Physical**
**Property**

- (13)

**Property**
**Value**

- measured in

- calculated
- to have

- working
- target

- measured
- to have

- assigns  parameter

- parameter value

- Name
- ID

- has a set

- declared
- to have

- modeled by

- assigned to

- has

- (25)

- (26)

- (29)

- (28)

- (27)

- (30)

- (34)

- (32)

- (33)

- (31)

- n

- is a parameter for

**Property**

- measured in/has

**AM Port**

## 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. 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.

## Cont Analytical Modeling

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

## Cont

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

## Cont Emergent 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.

## Figure 6 Car Example

- Ta is an emergent property of Car. Dg is an assembly property of  Body

**Figure 6.**

##  Example of Fig 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.

-  Example of Fig 6

## Frisch Thurman comments

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

## 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.

##                                                                     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.

##                                                                                        Analytical_representation

- 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.
- 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_name
- The analytical_representation_name specifies the string for the human-interpretable identifier for this Analytical_representation.
- model_parameter_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.

##  model_representation

- 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
- model_parameters.
- 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.

##                                                                 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.

## 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.

## 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_language**
- 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.

## Probability Distributions

**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.

## Allocation of Requirement

- 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
- requirements, and non-feasible requirements. Consequently the
- generalization/specialization of Figure 6. Is non-exhaustive and inclusive.

## Figure 7 requirement Classification for allocation

- Functional
- Requirement

- Performance
- Requirement

- Physical
- Property
- Requirement

- Imposed Design
- Requirement

- Reference
- Requirement

- Interface
- Requirement

- based on content and allocation

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

- Effectiveness
- Measure

- User Defined

- non-exhaustive
- inclusive

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

- (10)

- (35)

- (36)

- (37)

- (38)

- (39)

- (40)

- (42)

## Figure 8 Requirement Allocation

- Physical
- Property

- Behavior

- System Static Structure

- I/O

- Function

- Function
- Ordering

- consume
- generate

- order

-            Part

- Interface
- Specification

- Port

- Requirement_S

- Functional
- Requirement

- Performance
- Requirement

- Physical
- Property
- Requirement

- Imposed Design

- Effectiveness
- Measures

- Interface
- Requirement

- based on allocation

- Regularization Function

- used in

- assigned to

- assigned to

- assigned to

- assigned to

** ****Requirement**** Allocations, Figure 8.**

-  allocated to

- bound to

- Reference
- Requirement

- Reference
- Source

- points to

- optimizes

- Weight

- Optimization
- Direction

- has

- has

- used in

- non-exhaustive
- inclusive

- assigned to

- assigned to

- (28)

- (43)

- (44)

- (45)

- assigned to

## Summary of Allocation 

-  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

- Summary of Allocation

## Physical Property & 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
-    ends.

- Physical Property & Time

## Physical Property & 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.

-                 Time
- Unit
- Mean Value
- Variance
- Probability Distribution

- Continuous
- Time

- Present
- Time

- Discrete
- Time

- Stop
- Time

- Start
- Time

- Time
- Interval

## System 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

## Verification Requirement Variation Event

**Verification**
**Plan**

- traces to

- satisfied by

- performed with

- uses

- specified by

- specified by

- generates

- assigned to

- causes

- causes

- causes

- causes

- scheduled by

- categorized by

- categorized by

- (10)

- (46)

- (47)

- (48)

- (49)

- (50)

- (53)

- (52)

- (51)

**Verification**
**Requirement**
**Status**

- (54)

- has

**Figure 10. Verification**

## Validation Procedure

**Validation**
**Plan**

- traces to

- satisfied by

- performed with

- uses

- specifies

- specifies

- generates

- assigned to

- causes

- causes

- causes

- causes

- schedules

- categorized by

- categorized by

**Stakeholder**
**    ****Need**

**Stakeholder**

- has

- (7)

- (8)

- derived from

- (10)

- represented by

- involves

- (59)

- (58)

- (57)

- (56)

- (55)

- (60)

**Figure 11. Validation**

## Risk digaram

- Risk Title
- Risk ID
- Context
- Risk Owner
- Originator
- Date found
- Date updated

- combine to

- likelihood of

- implies

- has

- has

- n

-  Approach Strategy
- Strategy ID
- Description/Assumptions
- Approach:
-    None assigned
-    Accept
-    Watch
-    Mitigate
-    Prevent
-    Transfer

- resolves

- implements

- AP233 Draft Concept
- Model for Risk
- March 20, 2002

-               Inputs
- Technology
- Program Plan
- Schedule/Cost Constraints
- Risk Management Plan

- incorporate

- drive

- drive

## Category

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

## System Engineering Definitions for pigeon UML

**Domain**
**of Interest**

- (1)

- (3)

- (4)

- (22.10)

- 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/generalization Depending on direction
- A number on each end of a line means mulitplcity

- 1

- 1

- MDSD Workshop 5 Feb 2003