Draft #12 of Concept Model for Systems Engineering MDSD review
description
Transcript of Draft #12 of Concept Model for Systems Engineering MDSD review
1
Draft #12 of Concept Modelfor Systems Engineering
MDSD review
David W. Oliver
Version March 27, 2003
Wakefield, R.I.
2
Concept Model for Systems Engineering
Semantic Dictionary and Accompanying ModelThe concept model consists of two interlocking parts. The first part is thesemantic dictionary that defines each term. It is currently captured in an Excelspread sheet. The definitions have been written to satisfy the ISO standard forwriting definitions that can be found on the BSCW web site. The definitions arean ordered set. Definitions lower in the set use terms found higher in the set.This helps prevent circular definition. Since the definitions are not arrangedalphabetically, they are numbered with a reference number to aid in locating them.
Definitions according to the ISO standard define kinds of things, compositionof things from other things, and associations among things. When one readsten or more text definitions the usual mind finds it difficult to remember themany relationships implied. Hence a model accompanies the semantic dictionary.The dictionary explains meanings in natural language. The model captures themultitude of relationships in a graphic form so that the relationships can bescanned. The model is written in UML 1.X, with indications of semanticsthat are missing from the language.
Semantic Dictionary
3
Domainof Interest
Element
System
Property
StructurePhysicalProperty
Environment
C
C
SystemRequirement
statement of
Interacts with
exhibits
allocated to
Stakeholder Need
Stakeholder
satisfied by
represented by
has
allocated to budgeted to
SystemView
has view
(1)
(3)
(5)
(4)
(6)(7)
(8)
derived from
(9)
(10)
Behavior
C
(12) (14) (13)
ReferenceDocument
(11)
reference for
Top Level Concept Model, Figure 1.
categorizes
Category
(2)
reference for
Verification
verifies
(see figure 10)
contained in contained in
C
Cbuilt from
part of
4
Top Level ModelThe model needs to be read with reference to the definitions in the semanticdictionary. It starts with Element that is any thing on which repeatedmeasurements can be made for the engineering purposes of interest. This is a necessary definition because otherwise it is not possible to verify that adesign or implementation meets its requirements. Element is built fromElement in a hierarchy. The aggregation symbol has a small “C” in it to showthat what is meant is a decomposition into all of the parts. The special notation isused 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 hierarchyand it must have measurable characteristics that are repeatable. What makesthe System unique is that it has well defined relationships with all of the thingswith which it interacts. The collection of those things is its Environment. Tohave a system it is necessary to characterize what is in the system and what isin the environment along with the static and dynamic interactions betweensystem and environment. The Environment contains Elements and Systems.
Top Level Model Description
5
Different persons in engineering, manufacturing, maintenance, and managementneed different sets of information about the system. Manufacturing personnelneed to know about all the materials, nuts and rivets that go into the system andhow they assemble together. Maintenance personnel need to have diagnosticinformation and deal with replaceable units of the system. There are a very largenumber of such useful collections of information, each with its own context.System View provides for the collection of such sets of information, each set ina particular context.
An important subset of things in the environment are the Stakeholders. These areall the persons and organizations with a need, preference, or interest in the system.Stakeholders may include manufacturer, owner, user of owner’s services, userof the system, operator, maintainer, government regulator. Stakeholder Needrepresents their need, preference, interest, etc. in the system. If the System isdesigned and implemented well, then it satisfies these needs in a manner that issuperior 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 aproperty. Properties have units, values, variances and probability distributionsassociated with them. They may be looked up in handbooks of properties ofstandard materials, they may be calculated from the structure of the thing, orthey may be measured directly. In general they are tensors and may be a functionof time. Because of the multiple ways of arriving at a property and its values, itis important to have a Reference Document that establishes the source of theinformation.
A Requirement is a statement of a Property that a System shall exhibit. Therelationship to System is handled by allocating the requirement to the system thatshall exhibit that property. This formality allows the engineer to consideralternative allocations to different systems that may fulfill the requirement. It isfundamental to trade-off among solutions. Requirements originate fromStakeholder Needs. As the design proceeds in levels of detail, requirementsare derived from other requirements. These “derived from” relationships arepreserved as traceability relationships. In a real world problem requirementswill be changed from time to time. It is critical to trace from a requirementthat has changed to other requirements impacted by that change.
7
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 theninterrelated. This principle supports the consideration of alternatives.
Kinds of Properties
8
Port
C
(17)Interface
Specification
C
(19)
Partdescribed by
(15)
Interconnection (18)
1
1
Structure
C
(14)
System Static Structure, Figure 2.
Link
(16)
Diagram of Structure
9
Structure
Structure is built from Part, Port, and Interface Specification.Structure decomposes hierarchically. This forces Part and Portto 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 orcomponent and talking about it as an assembly because their job is toassemble it. This is a place where it may be advisable for clarity to use thewords component or part as an alias for Part.
Port
Each Part (part or component) attaches to others at particularlocations. These locations are called Ports. This is a familiar idea whenone thinks of the port on a power cord that plugs into a port on the wallto get electric power. It also applies to the surface of a bridge, a port, thatinteracts with wind, a port. In the second case the concept is less intuitiveand more formal but it works. Ports connect to ports.
Description of Structure, Part, Part
10
Interconnection
Interconnection specifies which ports attach to which other ports. TogetherPart, Port, and Interconnection specify how parts go togetherto constitute the whole. This description does not include Behavior or PhysicalProperties.
Interface Specification
Each port has associated with it a description, an Interface Specification, thatdescribes the geometry, forces, transferred material or energy or information,protocols, how to assemble to it, and tests that may be required of theport-to-port connection. For two ports to be interconnected their interfacesmust be compatible.
Structure, Behavior and Physical Property
Structure, Behavior and Physical Properties are described separately. Behaviorand Physical Properties are allocated or budgeted to Part tocomplete the description.
Interconnection, Interface , Spec
11
Behavior
Behavior is built from Function, I/O (Input/Output), and Function Orderingas shown in Figure 3. Any Element may be I/O (Light blue shows anentity comes from Figure 1.). A Function is a entity of transformation thatchanges a set of inputs to a set of outputs. Function Ordering orders thefunctions 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 providesfor completed functions to enable succeeding functions, for I/O to triggerfunctions, and for ordering operators to represent sequence, branching, anditeration. The SEDRES model represents this with a Petrie net model.UML 2.0 contributors may be using a Petrie Net model. If so, then thesetwo models need careful comparison.
Behavior
12
Behavior
C
(12)
Function
C
(20)
I/O
C
(21)
FunctionOrdering
Element
C
(1)
generates andconsumes
orders
(22)
System
(4)
allocated to
Environment
(6)
allocated to
Behavior, Figure 3.
Light blue background means thisentity comes from Figure 1.Diagram of Behavior
13
Description Function Based Behavior
A model for function Based Behavior is given in Figure 4. I/O may triggerfunctions, starting or terminating functions. I/O that triggers is coupled to thefunction by binding to a Function Control Port. I/O that does not trigger isbound to a Regular Function Port. I/O arriving while a function is active isstored 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 requirelimits to control their termination. Scripts are used to provide detailed controlof function ordering. Probabilities are assigned to Or Out to facilitateexecution of the behavior to produce time lines or Monte Carlo simulation.
After tools are to exchange behavior information that includes timing, thetool interpretation engines may execute the models to produce time lines orperform Monte Carlo calculations. These results will differ unless the toolsagree on function activation rules.
14
Resource Function Based Behavior
Resource is:
(1.) the amount of input available to a function or the amount ofoutput 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 batteryavailable for the function “Shoot”.
Example 2. The function “transmit message” may be allocated to a satellitesystem, a fiber optic line, a microwave link, etc. Each of these alternativeshas some value of the property “bandwidth” that may be used by the function.
ResourceFunction Based Behavior
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 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
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
C
CC orders
Function Based Behavior
I/O
Function FunctionOrdering
RegularFunction
Port
ControlFunction
Port
OrderingOperations
ActivationRules
Script
Sequence Iterate
LoopLimit
Loop
And In And Out
Multi-exitFunction
Or InOr Out
IterateLimit
TerminateRules
RunRules
StartRules
hasbound to
Or And
C
Replicate
has
has
control
Timingallocated togenerates
consumes
Function Based Behavior, Figure 4.
FunctionPortQueue
has
stored in
Probability
assigned to
LoopExit
has
Resource
triggers
FunctionExit
controlssequence
generatesconsumescaptures &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
LIFOQueue
FIFOQueue
has
19
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.
Function Exit
20
State based behavior emerged from automata theory and has matured intoState Charts that provide for state explosion in highly concurrent models.SEDRES has a representation for this and has demonstrated model transferbetween Statemate and Teamwork Real Time tools.
In the UML community Action Semantics are to provide a basis forstate based behavior. These two approaches require careful correlation. Theconcept model here does not go beyond the very general notion of functionordering, but notes the critical importance of correlation among emergingdetailed models.
Structure and Physical Properties
Physical Property, its relationship to the Structure hierarchy and to analysisis shown in Figure 4. The key concept is that performance, behavior andphysical properties of the whole results from the structure, the behavior andphysical properties of the parts. They are not related to a class tree.
21
Port
C
(17)
InterfaceSpecification
C
(19)
Partdescribed by
(15)
Interconnection (18)
1
1
Structure
C
(14)
Structure and Physical Property, Figure 5.
Required/BudgetedProperty
Value
CalculatedProperty
Value
MeasuredProperty
Value
Targetbudget
PropertyValue
PhysicalProperty
(13)
Unit
PropertyValue
measured in
calculatedto have
workingtarget
measuredto have
assigns parameter
Model_parameter
type_nameunit of measure
reference_documentparameter_type
valid_rangedefault_value
Parameter_assignment
parameter_valueassigned_parameter
parameter value
Analytical_model
namerepresentation_languagereference_documentparametersource_code
Analytical_representation
model_parameter_assignmentmodel_representationanalytical_representation_name
meanvariance
probability_distributionhistogram
NameID
has a set
declaredto 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
22
Discussion of Structure and Physical Property Figure 5.System Assemblies in the Part tree all have Physical Properties suchas mass, power consumption, geometry, MTBF, drag coefficient, etc. ThePhysical Properties are assigned to a particular Part. A PhysicalProperty has a name and an ID that identifies it uniquely. For example, manydifferent System Assemblies have the Physical Property mass. Consequentlyeach of these assigned Physical Properties needs an ID. Each has an associatedunit in which it is measured.
A Physical Property assigned to a particular Part has values. Thevalue may be expressed as a mean, a mean with variance, a probabilitydistribution, or a histogram. All of these values are a result of a set ofmeasurements and analysis of the data. The value goes through a series ofversions as the system definition evolves. The Part is declared to have aRequired or Budgeted Value.
The Part may have a Target Budget Property Value used as a guideor 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 mayhave a Measured Property Value.
Discussion of Figure 5
23
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. Therelationships may be very non-linear in the physical world as observed withphenomena like combustion and friction.. The basic relationships for analytical modeling of emergent propertiesand budgeting of properties are shown in Figure 5. A set of engineeringequations or estimates, analytical models, are used by systems engineersto budget properties to the interacting sub-assemblies as a guide todesigners at the lower level. When designs for all of the sub-assembliesare available, their individual properties and interactions are better defined.The same equations are used to calculate the emergent properties of thecomplete assembly. The fidelity of the calculations increases as thework proceeds.
Cont Analytical Modeling
24
A Part, as a whole, may have a Calculated Property Value basedon analysis of the properties, behaviors and interactions of its parts. This isaccomplished by estimation or by an analysis that solves the relevantengineering equations. This makes it necessary to represent physical propertiesas parameters in the equations of the relevant analysis model. Model Parameterprovides this parameterization. It has an attribute of its of the unit of measureapplicable to the analysis. This may be different from the unit assigned toPhysical Property. The reference_document attribute specifies thestandard document that contains the reference for the Model_parameter. Adefault 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 ofparameter_assignments and is modeled by one or several analytical models.be solved, Analytical _representation. The several Analytical_models provideanswers at different levels of fidelity and with different efforts of computation.AM_port connects the analytical results back to the appropriate location in thepart hierarchy.
Cont
25
Emergent Properties and Budgeting of PropertiesExample
One may wish to develop a car that can accelerate from zero to sixty milesper 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 thebody, 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 targetsfor the designers. When the designs are available with definite propertyvalues, 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 solutionof what sub-components to use. Thus it is useful for the assembly to haverelationships that indicate if it is an alternative or is selected as a solution, if itmeets requirements, and what its regularization function value may be as thebasis of selecting a particular solution from among the alternatives.
Cont Emergent Properties
26
CarWeight, WcTime to Accelerate 0 to 60 mph, Ta
BodyWeight, WbDrag Coefficient, Dg
Chassis Weight, Wch
TiresWeight, WbFriction, Tf
Drive TrainWeight, WdtPower, Pdt
ElectricalWeight, We
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
Engineering Equations
Ta is an emergent property of Car. Dg is an assembly property of BodyFigure 6.
C
Figure 6 Car Example
27
Example of Figure 6.
System Assembly
Physical Property Unit
Required Value
Model Parameter
Unit of measure
Default value
Parameter assignment
Analytical repr.
Analytical model
Representation Language
Car Weight Pounds3500 + -
100 Wc Kilograms3500 + -
100
Independent variable
equation 1Conservation of
mass
Conservation of mass; see
equation Math-ML
Car
Time to accelerate 0 - 60 mph Seconds > 6.5 Ta Seconds 6.5
time variable equation 2,3
Force equation with drag coefficient
Version 1: Constant
traction; see equation Math-ML
Version 2: traction vs. RPM; see equation Math-ML
The Table below is a crude map of the equations in Figure 6. Into the conceptmodel defined in Figure 4 for the car example. Only the properties of car havebeen mapped. Note there are two analytical models. One is very simple andassumes 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 enginedata, 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
28
Some definitions taken from the report of Frisch and Thurman are capturedon 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.
Frisch Thurman comments
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 theParameter_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_representation is the association of specific properties of specific System Assemblies with an Analytical_model inorder 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 shallbe 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_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_representationmodel_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.
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_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.
36
Normal Log-normalBernouli Negative BinomialBeta PoissonBinomial TChi Squared TriangularDiscrete Uniformed UniformErlang WeibullExponentialFGammaGeometricLaplace
Probability Distributions
Probabilities are applied to the values of physical properties, and to theperformance requirement time duration assigned to functions. A list followsof representative probability distributions used in systems engineering tools.
37
Allocation of Requirements
Depending upon their content, requirements are allocated to differentparts of the information model. Requirements describing functions areallocated to functions, etc. This is a useful way of classifying requirementsfor the purpose of creating a logically consistent model or description of asystem.
Within systems engineering there is no single standardized way of classifyingrequirements and many different classifications for different purposes arein use. The classification given in Figure 6. Is defined as shown because itis useful for the purpose allocating or assigning requirements.
It is not possible to enforce any process with an information model and AP233is intended to support both pest practices and other practices in use. Hence, anycollection of requirements may contain compound requirements, contradictoryrequirements, and non-feasible requirements. Consequently thegeneralization/specialization of Figure 6. Is non-exhaustive and inclusive.
Allocation of Requirement
38
System Requirement
FunctionalRequirement
PerformanceRequirement
PhysicalProperty
Requirement
Imposed DesignRequirement Reference
Requirement
InterfaceRequirement
based on content and allocation
A Requirement Classification,needed to show how requirements are
allocated to Behavior & System Structure
EffectivenessMeasure
User Defined
non-exhaustiveinclusive
Classification of Requirements for the Purpose of Allocation, Figure 7.
(10)
(35) (36)
(37)
(38)
(39)(40)
(42)
Figure 7 requirement Classification for allocation
39
Property
PhysicalProperty
Behavior System Static Structure
I/O FunctionFunctionOrdering
consumegenerate order Part Interface
SpecificationPort
Requirement_S
FunctionalRequirement
PerformanceRequirement
PhysicalProperty
Requirement
Imposed DesignEffectivenessMeasures
InterfaceRequirement
based on allocation
Regularization Function
used in
assigned to
assi
gned
to
assigned to
assigned to
Requirement Allocations, Figure 8.
allocated to
bound to
ReferenceRequirement
ReferenceSource
points to
optimizesWeightOptimization
Direction
hashas
used in
non-exhaustiveinclusive
CC
C
C
C assigned to
assigned to(28)
(43) (44)
(45)
assigned to
Figure 8 Requirement Allocation
40
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
Summary of Allocation
41
Physical Property and Time
Figure 9. Shows draft models for Physical Property and Time. Physical Propertyand Part are under study by a team member and improved modelsare 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
42
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. Currentaccuracy of measurement is about one part in 10 -13. Research underway mayextend this to 10 -17. Many properties now have primary standards based inpart on time.
Physical Property & Time
43
Refined Decomposition for Physical Property and Time, Figure 9.
TimeUnitMean ValueVarianceProbability Distribution
ContinuousTime
PresentTime
DiscreteTime
Physical Property NameUnitMean ValueVarianceProbability DistributionValue Range
MeasurementInfrastructure
MeasurementMethod
(13)
measures
uses
StopTime
StartTime
TimeInterval
44
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 needdiscussion.
The model for Risk was discussed with the Risk Working Group atthe INCOSE 2002 symposium. AP233 is waiting for there correctionsand changes. The existing model is based on information from therisk working group, NASA Goddard Risk Attributes in SLATE‘GPM’ Data Base March 7,2002 (Dave Everett), and from NASAJPL Risk Process Diagram
System Engineering Management
45
SystemRequirement
VerificationRequirement
Issue
Organization
VerificationPlan
VerificationEvent
VerificationProcedure
VerificationConfiguration
Risk
traces to
satisfied by performed with
uses
specified by
specified by
generates
assigned to
Category
causescauses
causescauses
scheduled by
categorized by categorized by
(10)
(46)
(47) (48)
(49)
(50)
(53)
(52)
(51)
VerificationRequirement
Status(54)
has
Verification Requirement Variation Event
Figure 10. Verification
46
SystemRequirement
ValidationRequirement
Issue
Organization
ValidationPlan
ValidationEvent
ValidationProcedure
ValidationInfrastructure
Risk
traces to
satisfied by performed with
uses
specifies
specifies
generates
assigned to
Category
causescauses
causescauses
schedules
categorized by categorized by
Stakeholder Need
Stakeholder
has
(7)(8)
derived from
(10)
represented by involves
(59)(58)
(57)(56)(55)
ValidationRequirement
Status
has(60)
Validation Procedure
Figure 11. Validation
47
Individual RiskRisk TitleRisk IDContextRisk OwnerOriginatorDate foundDate updated
Related RiskR-R TitleR-R IDRisk TitleRisk IDSelect RuleCategory Name
StatusStatus TitleStatus IDRisk IDRisk TitleStatus Names: Submitted Retired Approved
LikelihoodRisk TitleRisk IDType: a (%),b,cProbability Distribution: Name Mean Variance
ConsequenceRisk TitleRisk IDType: a,b,cConsequence numberProbability_ Distribution
combine to
likelihood of
implieshas
ImpactRisk TitleRisk IDAffected_Thing_TitleAffected_Thing_IDSeverity
has
n
Risk Window_openWindow_closedRisk_HandlingTime Frame Priority
Approach Strategy Strategy IDDescription/Assumptions Approach: None assigned Accept Watch Mitigate Prevent Transfer
Contingency Plan Plan IDTriggersDate AppliedDate ClosedClosed byClosing_RationaleMitigation_Effects _Description
resolves
implements
AP233 Draft ConceptModel for RiskMarch 20, 2002
Lessons Learned Lesson TitleLesson IDLesson DateLesson DescriptionLesson Category
Inputs TechnologyProgram PlanSchedule/Cost ConstraintsRisk Management Plan
incorporate
drive
drive
Risk digaram
48
The decomposition tree for Part is more than a simple partstree. At any node one may introduce a category of parts. For example, anautomobile may have several different engines that can be used in theautomobile, each providing a different level of economy and performance.
Categories are a grouping of elements into a set based on defined propertiesthat serve as selection criteria for which elements of all those in the universebelong in that set Explanation: It is categorization that enables us to definealternatives and create taxonomies for libraries. This is one of the forms of generalization/specialization. Note that this is NOT INHERITANCE as found inobject-oriented software languages. Physical elements, matter and energy, donot inherit their properties. Rather they posses the properties of themselves andcan be identified by measurement of those properties. For a discussion of theseissues in computer science see the work of Barbara Liskov and her CLUlanguage.
Note: the subcategories may be exclusive or inclusive and the subcategories may exhaust the super category or not there are four such possibilitiesCategory is the basic concept in the physical world to support specialization - generalization.
Category
49
Domainof Interest
(1)
(3)
C
(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
System Engineering Definitions for pigeon UML
MDSD Workshop 5 Feb 2003