AP scope | AP module | AP contents | AP index | |
Application protocol: System engineering and design | ISO/WD 10303-233 |
Concept Model for Systems Engineering
This annex provides the concept model for systems engineering that was the foundation for developing this part of ISO 10303. Together with the terms defined in clause 3 of this part, this model defines the breath and scope of capability while also providing the semantic reference base and model based requirements that were used to drive development of this part of ISO 10303.
The definitions in clause 3 explain 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 patterned after UML 1, with indications of semantics that are missing from the language. Figure 1 is a guide for interpreting the models in this annex.
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 from UML 1.
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.
It is useful to distinguish among three kinds of properties.
These three kinds of properties are described separately and then interrelated. This principle supports the consideration of alternatives
Structure
Structure is built from Part, Port, and Interface Specification. Structure decomposes hierarchically. This forces Part and Port to also decompose hierarchically.
The Part is simply a part or component list. The name used follows the STEP manufacturing point of view of looking at a part or component and talking about it as an assembly because their job is to assemble it. This is a place where it may be advisable for clarity to use the words component or part as an alias for Part.
Each Part (part or component) attaches to others at particular locations. These locations are called Ports. This is a familiar idea when one thinks of the port on a power cord that plugs into a port on the wall to get electric power. It also applies to the surface of a bridge, a port, that interacts with wind, a port. In the second case the concept is less intuitive and more formal but it works. Ports connect to ports.
Interconnection specifies which ports attach to which other ports. Together Part, Port, and Interconnection specify how parts go together to constitute the whole. This description does not include Behavior or Physical Properties.
Each port has associated with it a description, an Interface Specification, that describes the geometry, forces, transferred material or energy or information, protocols, how to assemble to it, and tests that may be required of the port-to-port connection. For two ports to be interconnected their interfaces must be compatible.
Structure, Behavior and Physical Property
Structure, Behavior and Physical Properties are described separately. Behavior and Physical Properties are allocated or budgeted to Part to complete the description.
Behavior is built from Function, I/O (Input/Output), and Function Ordering as shown in Figure 3. Any 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.
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
Resource is:
EXAMPLE There exists some number of missiles available to a missile battery available for the function "Shoot".
EXAMPLE 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.
Function - Resource Relationships
Captures: Captures indicates the resource that 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 that this object requires (and destroys) during execution. Resources are consumed when the execution of the function begins.
Produces: Produces indicate the resource that is generated by the function. Resources are produced when the execution of the function completes.
Function Activation Rules
A representative set of activation rules follows:
Start Rule - A function is activated and begins its work if and only if all preceding functions and threads of functions have completed and all 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.
I/O Queuing Rules
A representative set of queuing rules follows:
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-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.
The Function Exit Construct
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.
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.
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.
Calculated Property Values - Analytical Modeling
Any one assembly is an interconnection of assemblies one tier down in the tree. The emergent properties of any assembly are a result of the properties, interconnection,and interaction of the sub-assemblies from which it is built. The relationships may be very non-linear in the physical world as observed with phenomena like combustion and friction.
The basic relationships for analytical modeling of emergent properties and budgeting of properties are shown in Figure 5. A set of engineering equations or estimates, analytical models, are used by systems engineers to budget properties to the interacting sub-assemblies as a guide to designers at the lower level. When designs for all of the sub-assemblies are available, their individual properties and interactions are better defined. The same equations are used to calculate the emergent properties of the complete assembly. The fidelity of the calculations increases as the work proceeds.
A Part, as a whole, may have a Calculated Property Value based on analysis of the properties, behaviors and interactions of its parts. This is accomplished by estimation or by an analysis that solves the relevant engineering equations. This makes it necessary to represent physical properties as parameters in the equations of the relevant analysis model. Model Parameter provides this parameterization. It has an attribute of its of the unit of measure applicable to the analysis. This may be different from the unit assigned to Physical Property. The reference_document attribute specifies the standard document that contains the reference for the Model_parameter. A default value and valid range can be specified when needed.
Parameter_assignment assigns parameters to 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.
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.
The Table below is a crude map of the equations in Figure 7. 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.
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.
Parameter_assignment
Parameter_assignment provides actual values for characteristics declared formally by the Model_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.
NOTE 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.
NOTE 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.
NOTE This part of ISO 10303 does not standardize qualification of Analytical_representations for an intended usage.
Analytical_model
Provides a mathematical description of the properties of a system. An Analytical_model may be a Library_model.
NOTE 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.
NOTE 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.
NOTE 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.
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.
NormalLog-normalBernouliNegative BinomialBetaPo
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 requirements, and non-feasible requirements. Consequently the generalization/specialization of Figure 6 is non-exhaustive and inclusive.
Summary of Allocation Relationships
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 ends.
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.
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
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.
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.
© ISO — All rights reserved