Annex F
(informative)
Application module implementation and usage guide
A discussion ready level of EXPRESS modeling is provided herein. This collects AP233 team work with
AP239 and AP210 work presented in a form that passes the EXPRESS error checker.
We think that it contains most of the pieces of necessary content. Associated interfacing, harmonization and
modularization work is to-be-done
David Oliver's 2003 Visio EXPRESS-G Draft 4 file of proposed system structure modules
can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/System_structure_Draft_4_visio.vsd?rev=1.1.
This supersedes his Draft #3 which can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/System_structure_Draft_3_visio.vsd?rev=1.1.
From this discussion ready EXPRESS-G work associated EXPRESS code was hand derived.
The EXPRESS-G's shown in Clause C are derived from the hand coded EXPRESS defined Clause E.
The following notes and associated derived requirments are paraphrased from the AP233
Structure SOW and the Concept Model + Dictionary
The AP233 Structure SOW can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/SOW_structue.doc?rev=1.1.
The Concept Model + Dictionary can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/Concept_Model.ppt?rev=1.1.
and
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/Concept_Model_Semantic_Dictionary.xls?rev=1.1.and
These requirements for the Structure Module Set(SMS) reflect both what the
AP233 team has learned over the past several years and from their interaction with
the SysML team on the joint development of the Concept Model and Semantic
Dictionary, see http://www.sysml.org/ for an overview and
http://www.sysml.org/artifacts.htm for available downloads.
Most of the nomenclature in this document is taken from the Concept
Model. Readers should be cautioned that semantics for the same concept
differs in ISO/SC4 modules, in the Concept Model, in general Systems Engineering Standards,
and in SysML. There is no common or standard nomenclature at this time. This is totally due
to the disconnected development history of these sources.
Harry Frisch is leading the effort to harvest AP239 modules to support the AP233
Project Management Module sets. These module sets provide for management control. To do
a vestigial product breakdown is needed. Scheduling required needs
to support the allocation of time duration to activities or tasks. Product
breakdown is closely related to a part breakdown in the SMS. Similarly the time
duration is a physical property that will appear in the SMS. At present these
entities need to exist in the Project Management collection of module sets so
that this collection will be testable stand alone. As the SMS is completed it
will be essential to examine exactly how part hierarchy and product breakdown
interrelate in the schema, and where time duration is defined and interrelated
to activities and tasks in the Schedule Module Set. This issue of compatibility
across the total schema may affect the exact layout of the requirements stated below.
Roger Burkhart is leading a John Deer supported effort to compare SysML defined
structure with what is available in the AP239 modules. At present there appears to
be parts of the SMS schema missing from the AP239 modules. This is work in progress.
Within the AP233 concept model - Structure, the description of how a system decomposes
into its parts and how the parts assemble to make the whole is shown as:
Figure 1 —
Requirement:shall create an arm consistent with both the AP233 Concept
Model and with SysML Structure and Parametrics
Requirement:shall support the information unit concept of Structure
NOTE
Definition - Structure: the description of how a system decomposes
into its parts and how the parts assemble to make the whole.
- Structure is built from Part, Port, and Interface Specification. Structure
decomposes hierarchically. These relationships force Part and Port to also decompose hierarchically.
- Structure provides the decomposition, interconnection and other static relationships
among the parts of the system.
- Physical properties are budgeted to structure using analysis methods, and the
emergent performance is calculated using the same methods.
- Behavior is allocated to the structure. Form and function are separated
conceptually so that the design can be optimized by considering several different
structures that can provide the desired emergent behavior and properties.
- Example: In a real example of design optimization the engineer does
not just look for some local cost function maximum or minimum, but looks at the
trend in data to find that region in the design space where the solution is
robust; i.e., the solution is both near a cost function min/max point and does
not degrade rapidly with variances in variables under design control.
Requirement:shall create an entity for the information unit concept of Part
NOTE
Definition - Part: The static parts of the system including their
interconnection and interconnection descriptions.
- The Part is simply a part of a component list
- A Part does not represent an actual physical object that is or was existing
in the real world.
- A Part is a type of Product that collects the definitional information of
the versions of either a part or of a non-countable material.
- Physical Property is assigned to part.
- Many persons think of parts as components, but manufacturing thinks of them
as assemblies because they build assemblies.
- Assembly is a standard ISO naming convention. It may be desirable to alias this name.
- The name used herein 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.
- To support verification and validation work there is the need to distinguish
between part design and part realized.
Requirement:shall create a hierarchy for Part.
Requirement:shall create the ability to distinguish between part (build
as designed) and part realized (built as designed); as needed to support system
verification and validation work.
stepmod module - Part_and_version_identification_arm - Introduction
- data that identify parts and their versions
stepmod module - Part_and_version_identification_arm - In scope
- identification of a part;
- identification of a non-countable material;
- identification of a version of a part or of a non-countable material.
stepmod module - Part_view_definition_arm - Introduction
- representation of characterization views of a version of a part
stepmod module - Part_view_definition_arm - In scope
- identification of a characterization of a version of a part, relevant
in one or more application domains and one or more life-cycle stages.
stepmod module - Part_definition_relationship_arm - Introduction
- representation of relationships between definitions of parts.
stepmod module - Part_definition_relationship_arm - In scope
- representation of the fact that a part version results from the
transformation of another.
stepmod module - Product_as_individual_arm - Introduction
- representation of data that records the identification of an existing
or potential future artefact
- an actual product whose properties can only be known by observation or
by derivation from observations.
stepmod module - Product_as_individual_arm - In scope
- representation of the information to identify an actual product;
stepmod module - Assembly_structure_arm - Introduction
- epresentation of assembly relationships.
stepmod module - Assembly_structure_arm - In scope
- specification of the use of a product version as a component of an assembly;
- specification of a parent-child assembly relationship;
- identification of a component of an assembly with respect to an upper level in
the assembly structure.
Concerns, Observations and comments (Radack/Baker exchange)
- The problem with the concept of assembly is that some user's "part" is
another user's assembly. For example, microchips are single parts to
most users, but clearly have a bill of materials if you manufacture
them. In the aircraft industry, a carbon fibre composite can be viewed
as a single part for most purposes (it certainly cannot be disassembled)
but has a complex, careful defined structure for its own manufacturing
process.
- From the STEP viewpoint, saying something is an assembly is equivalent
to saying you have the breakdown into smaller physical components.
"assembly" is not a classification of the thing in itself, but an
observation on whether your organization thinks about it in terms of
components. In that sense, a pilot's log book treats an aircraft as a
single part, since he does not record a list of component parts.
- In a PDM context, an assembly is something that is in itself
configuration controlled (in a configuration context), and is made from
configuration controlled parts. Here, an assembly is a convenient holder
for "a collection of parts". It would not affect the end product if a
different collection of assemblies were used, as long as the same
collection of parts in the same position is the result. The old 'Product
Manager' explicitly supported the restructuring of the design assembly
breakdown into a manufacturing assembly breakdown. There are also often
differences between the assembly structure used in manufacture and the
assemblies provided as spares.
- Which all goes top reinforce that "assembly" is as much a description of
the user organization as the product. Since STEP does not transfer
business processes, it is probably best to treat "assembly" as a
placeholder for a family of concepts that need further specification.
- If you are saying that it does not make sense to say that an Assembly is
a kind of Product or Part I agree. Assembly should be treated as a
relationship which is part of a structure. We should be able to say "A
is assembled from B, C and D within structure X" but not "A is an
assembly". Different structures are needed to account for different
activities or purposes, e.g., manufacture, maintenance, and disposal.
- Well put.
Concerns, Observations and comments
- Part stuff appears to service - for design, build as
- Product_as_individual stuff appears to service - individual instance, built as
- DWO - During the Asheville meting it became apparent that the SC4 approaches
all distinguish between the design of a thing and the actual manufactured thing itself.
SysML will likely follow that approach as well. Currently the the concept model makes
no such distinction.
- DWO - Issue: Distinguish between design and the manufactured things based
on those design
- DWO - Possible approach: The current entity Part can be a superclass with
a subclass for design and a subclass for the manufactured things based on that design.
Keep the interface relationship at the superclass level so that interfaces and
interconnection apply to both subclasses and the interfaces may be preserved
between design and manufactured thing. Generate names and definitions for the
superclass and the two subclasses. Generate the relationship between the design
and the manufactured thing. Check on any changes that need to be made to the
validation and verification parts of the model. These may be minimal because
design and manufactured things are validated and verified in a similar manner.
The particular analysis/measurement technique and infrastructure may differ, but
thosse models allow for prescription of analysis, measurement, and infrastructure
for each verification and validation.
- Jozsef Bedocs - built vs. design: Subclassing the manufactured thing from
the designed thing has potential issues. Fundamentally, the manufactured thing
is not necessarily the same as the designed thing. It would be better to have the
manufactured thing subclass to Part and associate unidirectionally the manufactured
thing and the designed thing.
Requirement:shall create an entity for the information unit concept of
Link related to part
NOTE
Definition - Link: A particular kind of Part that is used when it is
helpful not to model or specify its details.
- Link must be provided in the concept model because a number of application tools
use the concept.
- Links ultimately are fully specified and become system-assembly.
- Example: In a pumping system it may be useful to define the pumps and tanks
while representing the piping as links without detail. At some point in the design
detail like diameter, flow impedence, pressure rating, and corrosion resistance
must be defined. At his point the link becomes a part.
Requirement:shall create an entity for the information unit concept of
Port related to part
NOTE
Definition - Port: A connection point on a Part in the Part
decomposition hierarchy.
- Each Part (part or component) attaches to others at particular locations.
These locations are called Ports.
- Example: 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.
- Systems interconnect with one another port-to-port. Ports couple to desired
things in the environment and also to the ports of things that cause failure,
threaten security or safety.
- Note that when a system interacts with its environment that the boundary
between the system and the environment is the collection of all interacting ports.
- Example: Consider a ultrasonic transmitting transducer coupled to a water
tank and a receiver transducer coupled to the tank. The transmitter port connects
to a water port and couples sound energy into the water. The intensity at any
point is a result of the impedance match between the two ports, the radiation
pattern of the transducer, and the attenuation and dispersion in the water. The
receiving transducer is attached to another port of the water. The received
signal is dependant on the relative impedance of the two ports, the sound
distribution in the water, and the radiation pattern of the receiving transducer.
- Example: This example is often oversimplified as "broadcast" neglecting the
port to port conditions and the properties of the medium and neglecting the ports.
- The alias for Port is Interface_connection, the term that is used in AP239.
Requirement:shall create a hierarchy for port.
Requirement:shall create the ability to provide for both information
templates and information instances for the information concept units of part and port.
Requirement:shall create an entity for the information unit concept of
Interconnection
NOTE
Definition - Interconnection:A listing of the ports that interconnect with one
another.
- 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.
- The interconnection may exist for structural reasons without any flow from port to
port. The interconnection may exist because functions are assigned to particular
assemblies, and the output from one function is an input to the other function. In
this case the ports and their interconnection must exist to support flow.
- The alias for interconnection is Interface_connection, the term used in AP239.
Requirement:shall support various classes of port to port interface
representational complexity.
- Simple property: A scalar property is needed to characterize port to port
connectivity; e.g., the thermal conductivity of a thermal insulation plate.
- Complex property: A property with complex dependencies is needed to characterizes
port to port connectivity; e.g., the characterization of the welding together of
two Alaska pipleine pipes.
- Simple part: A simple part characterizes port to port connectivity; e.g.,
international electric plug adapter.
- Complex part: A complex part characterizes port to port connectivity; e.g.,
Alaska pipeline support structure with its embedded heat pipe to prevent
permafrost melt. Alaska pipeline U joints designed for earthquake failure protection.
- Other examples from Asheville: Tire tread for on and off road vehicles;
Suspension system for a land operated vehicle, Also sort of electrical cabling
and harnesses, all sorts of mechanical hinges with 1,2,3,4,5,6 degrees of freedom
including flexibility, joint slop, damping, etc.
Requirement:shall create an entity for the information unit concept of
Interface Specification
NOTE
Definition - Interface Specification: A description of a Port of a
Part that includes the geometric description, I/O description, protocols that
must be met, assemblies of parts required to join two ports, allowable defect
characteristics, etc. The interface_description includes the emergent properties
of the interface that is the result of the two ports interacting, and is not
associated with either.
- 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.
- The interface specification describes emergent properties and behaviors of the
interface.
- The interface specification allows for an interface that consists of multiple parts.
- Parts interact physically through direct physical contact, exchange of Elements,
and through forces they exert such as gravity, compression or torque. Thus I/O is
bound to ports and described by interfaces. The interface may consist of more than
the two ports and may involve an assembly of parts as in the case of two flanges
that are assembled with six bolts and an O-ring. The interface may also require
detailed description to define what occurs there or how it is maintained.
- Example: For two ports to connect, their interfaces must be compatible.
The current carrying capacity of a plug and a socket is a result of the surface area
of contact, the contact force, the wiping action on plugging them together, and
the surface conductivity of both. This is an emergent property that is not assignable
to either port individually.
stepmod module - Interface_arm - Introduction
- representation of interfaces between products
- interaction between co-functioning products, or a product and its environment,
- the product attributes that are necessary to exist at a common boundary
stepmod module - Interface_arm - In scope
- the identification of the interface specification;
- the identification of a version of an interface specification;
- the representation of an interaction or connection between two or more products;
- the identification of the interface connector, the part of a product with
which one or more other products or the environment will interact.
Concerns, Observations and comments
- Extensions may be needed to service full range of AP233 needs
Figure 2 —
Requirement:shall create allocation relationships between Part
and Text Requirement subclasses Physical Property Requirement and Imposed
Design Requirement
Requirement:shall create allocation relationships between Interface
Specification and Text Requirement subclass Interface Requirement
Physical Property, its relationship to the Structure hierarchy and to
analysis is shown in Figure 5. 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.
Figure 3 —
Requirement:shall create an entity for the information unit concept
of Physical Property
NOTE
Definition - Physical Property: What an Element exhibits or does not
exhibit in response to excitation and stimulation from auxiliary measurement entities
that are not part of its context.
- This is the subclass of property that encompasses measurable characteristics that
require additional instrumentation to measure them. They cannot be established from
responses to the enviropnment alone. All of the "properties" used in analysis with
differential equations fall into this category.
- Example: Responses of an Element like mass, power consumption, MTBF, etc.
are critically important and appear in requirements. They are not measured by responses
to excitation from their environment.
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.
Figure 4 —
Requirement:shall create an entity for the information unit concept of
Unit, value, version of value, tolerance and version of tolerance.
NOTE
Definition - Unit:Establishes the standard of measure against which
he values of physical_properties shall be stated.
NOTE
Definition - Property value: A numeric value assigned to a physical_property
- Required_budgeted_property_value: A property value aloocated to a part by a
requirement, or budgeted to that part by analysis.
- Calculated_property_value: A property value of a whole calculated or
estimated from the values of the parts that assemble to make the whole.
- Target_budget_property_value: A temporary property value used by a
designer as the design work proceeds and different design alternatives are considered.
- Measured_property_value: A property_value established by measurement
of an actual part.
Requirement:shall create relationships among physical property, unit,
value, and tolerance
Requirement:shall create an allocation relationship between Part and Property
Requirement:shall create allocation relationship between Part and Function
Requirement:shall create an allocation relationship between Part and State
Requirement:shall create entities for the information unit concept of
Alternative Parts
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.
Requirement:shall create an entity for the information unit concept of
Analytical Representation
NOTE
Definition - 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
Requirement:shall create an entity for the information unit concept of
Analytical Model
NOTE
Definition - analytical_model:Provides a mathematical description of the
properties of a system.
stepmod module - Analytical_model_arm - Introduction
- for the representation of information needed to properly interface to
and exchange the source code contents of an externally defined computer-interpretable
model of a particular behaviour. This model allows a behaviour to be described
using a mathematical form (e.g., algorithm, table). A model is independent of any
particular product. A model is not directly executable to return a result until
application data have been applied.
stepmod module - Analytical_model_arm - In scope
- identification of externally defined analytical and computer-interpretable
models and their versions;
- identification of the parameters of an analytical model;
- the application of an analytical model to a real or imaginary object together
with the needed parameter assignments;
Concerns, Observations and comments
- Concept of "Ports" within Analytical_model_arm carries the implicit assumption of
analog/discrete input/output signals. This is a ee-domain specific concept. Need to
remove all "port" stuff.
- model_parameter_type and signal_flow _direction types not needed. Not general enough
- How does this map to input and output data files of arbitrary complexity?
- What does analog and discrete map to?
- Vector-tensor physical property type needs reference frame
- Cast in the language of EE-ize, can't see the mapping to multi-disciplinary
analytical models
- Significant alteration may be needed to service full range of AP233 needs
- Reason: This arm is designed to service a lower level of data abstraction than
needed by AP233.
- Maybe: a "lite" version of this module work service needs?
- From TT What in Analytical_model is specific to electrical/mechanical domain?
We have spent a lot of extra time in that module to make things flexible yet very
concrete so there could be little confusion by a data extractor and a data receiver.
Is it the digital and analog port stuff? I added that specifically so that we could
identify quantities on the ports that have through and across variables. Mike
Loeffler had a look at it and agreed it is good stuff, so I am a little confused.
Requirement:shall create entities to support the information unit concept of
Rules
NOTE
Definition - rules: rules are defined by a constraint relating two elements based
upon characteristics of a design;
stepmod module - Production_rule_arm - In scope
- rules that define a constraint by relating two elements based
upon characteristics of a design
- management of rules;
- items within the scope of application module Model parameter, ISO/CD-TS 10303-1703;
- items within the scope of application module Software, ISO/CD-TS 10303-1746;
- items within the scope of application module Specification document, ISO/CD-TS 10303-1747.
stepmod module - Production_rule_arm - Introduction
- This module provides for the representation of the information needed to describe design constraints,
commonly referred to as rules. The information describes the rule's relationship to product
characteristics, formal description of the functions that embody the rule, in addition to the
configuration management aspects applied to the rule. The configuration management information
supports rule version control and supports a formal process to making changes to an existing rule.
Concerns, Observations and comments
- Rules need to service every aspect of systems engineering from high level institutional
rules for product development to low level rules that insure product manufacturability
- This module is from AP210 - It still needs to be interface with AP233
Requirement:shall create entities for the information unit concept of
Parameters with units, values and tolerances
NOTE
Definition - model_parameter: a formally declared variable of the
analytical model provided for an external application to populate at execution
time in a computing environment
stepmod module - Model_parameter_arm - Introduction
- representation of information needed to describe model parameters, mechanism
for overriding them and their assignments to products. Model parameters can be
classified.
stepmod module - Model_parameter_arm - In scope
- identification of a parameter for a model;
- assignment of values to a model parameter;
- assignment of a parameter to a model;
- overriding of a parameter assignment;
- assignment of a parameter value to a product;
Concerns, Observations and comments
- Model parameters can be vector-tensors with reference frames
- What to do about input/output files for multidisciplinary problems.
- Need to wrestle down "parameter" vs. May-2002 Lambda calculus thoughts
- Reference material can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Parameter_property_and_Lambda_calculus.doc?rev=1.1 and
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Parameter_and_Lambda_calculus.doc?rev=1.1
Requirement:shall create provide Parameters with Units
Requirement:shall create an entity for the information unit concepts of
Parameter Value, Tolerance and Assignment.
Concerns, Observations and comments (Erik Herzog)
- Please find attached a more detailed description on what I believe is missing
from the system structure modules as proposed. This document, from Erik, can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Erik_system_structure_1.doc?rev=1.1
- To Erik: I reviewed your proposal and am requesting more information:
How does a conceptual_part differ from a system? Tom
- Good question Tom: Do I need both a system entity and a conceptual product entity?
I do ask the same question at regular intervals, have intense debates with myself and
tend to come up with justifications each time. I will put together a justification document,
- Erik: As you are putting together the justification document, the central thing
(from my perspective) is to capture what explicit mechanisms are used for
identification. Tom
- To Eric From David:
I always like what you do and it leads to interesting discussions. I have just scanned
your comments on structure. Let me add some thoughts that may not have been clear in the information
you have seen so far. Your diagrams appear to be correct. However, we have planned to include a
breakdown for real physical manufactured things. after all, verification is done against the real
stuff, not just against designs (Parts in STEP).
So I would add breakdowns for real stuff to the pictures you have drawn.
In real work sometimes one sets up conceptual or logical parts and then the actual designs.
Sometimes it is done with two or more alternative designs and a trade study to select the best approach.
When we did a real time ultrasonic cardiac imager in the 80's we considerd large wobble transducers,
fresnel lenses, and phased arays. Trade studies showed only phased arrays would work. For the front
end signal processing we did a trade study of standard digital circuits vs. CCD's. this took
experimental work to sort out the best design approach. My only point is that there may be more
design alternatives than just two, and the number you get may vary with where you are in the decomposition
hierarchy. I think this can all be handled through use of Part for design and the generous version capability
that includes defining the context for the version and the part view definition. Most often the work is
upgrading where 90% or more of the system is predetermined and it is being enhanced for the market.
As stated above we need not just Part, but also real manufactured stuff. Here too there may be more
than one version of real things to represent. For example, there is the first product built - like first
car to track or first engine to test. These often contain parts that are hand crafted and not manufactured
with the regular assembly line. Next there is often pre-production that is used for test marketing but built
on an assembly line that is not the final one for full scale manufacture. There is also spare parts manufacture,
spare part refurbishing, and a part hierarchy particular for maintenance that emphasizes line replaceable units.
As with design, I believe that one can use a single real thing breakdown, and use versions to handle the several
related but different breakdowns for specific purposes. In accord with this Asheville decision we sent an Issue
to Julian, who is working on the concept model, to add to that model the distinction between design and the real
stuff manufactured from design that may have part numbers.
When we went into the Asheville meeting the .vsd model used System Breakdown for System. During that meeting
a consensus was reached with the help of the more EXPRESS expert contributors like Spiby and Price, that we make
System equal Product. The Product decomposition then becomes the System Breakdown. Part, as a subclass of Product,
represents design. It seems logical to use Product_as_Individual for real physical manufactured stuff that is
tested and verified against requirements.
If we do this, there seems to be no need for several PLCS modules - Product Breakdown, System Breakdown,
Physical Breakdown, and Functional Breakdown. We set this up as a crtitical issue - not to use these. We set
up as a critical issue what these breakdowns are because the documentation is ambiguous and shows a lot of cut
and paste such that different modules share nearly identical descriptions. Unfortunately the documentation does
not provide examples. We hope team members or Rob Boddington will help clarify concepts these modules support.
The most mysterious of these breakdowns is Functional Breakdown with Functional Instance. Examples of functional
instances and how they differ from requirements would be helpful.
If this makes sense to you, it would add to your figures a breakdown for real physical manufactured things
currently associated with the Product_as_Individual module. This could be modified in Valencia if we find convincing
reasons to do so. I welcome any comments on this.
- To Eric from David:
I have attached a schematic (a little like the ones in your recent communication) to
show what we have had in mind for AP233. It is a bit different than the diagram you drew for the AP233 approach.
Perhaps it satisfies some of what you perceived to be needed. Please let me know how much it satisfies or does not
satisfy your concerns. David's attachment can be dowloaded from
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/David_system_structure_1.ppt?rev=1.1
What you meant by conceptual parts was not clear to me and I have interpreted it as alternative designs.
There is a whole process step with its own set of tools used at a higher level of decomposition to do concept
analysis or strategic planning. We expect to have a vendor of these tools and an expert in the field working
with us on strategic planning in the near future but not in time for WD-1. Some of this can be found in my book
and in the book on strategic planning by Gale, cited in my book. This book can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_engineering/Engineering%20Complex%20Systems%20%28book%29.pdf?rev=1.1. Much of
what is needed for strategic planning
can be accomplished by modeling the business developing its strategic plan for a product as a system. The
context model at that level then includes competitors, competitive products, and markets (customers), etc.
We will need to work through examples with a tool designed for this to isolate the additional entities and
relationships that are needed in AP233.
Note that at the beginning of the Asheville meeting System was identified with the System Breakdown Module.
At that meeting the collective wisdom of the team was to identify System directly with Product, and we changed
the Structure module to accomplish this after the meeting. The assignment of application entities to modules
in the schematic charts is based on that decision at Asheville; System = Product.
- To All from Erik:
The attached document
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Erik_system_structure_2.pdf?rev=1.1
is produced to justify whe AP-233 WD5 included separate physical architecture and system architecture
structures. The document is produced in response to the statements by Tom T. Tom has seen earlier
versions of this document and he now has a good understanding of the AP233 WD5 model, Whether he
accepts it or not is a completely different issue. So, the rationale is provided and the debate is
open!
Notes extracted from Valencia and Rochester meetings summer 2005
Figure 5 — System identification and version (Attic copy)
- Phil recalled the existance in the stepmod attic of Ian's module system_identification and version
- This module will enable system = product to be removed
- It will enable system to be made a subtype of product
- Phil to clean up the (Attic copy) version as shown above.
- Phil to verify that type extensions exist for system and requirements.
- A USE FROM placeholder for system_identification_and_version is to be placed in WD#2
- Results to be reviewed at PDES fall off-site.
- Re. Interconnection - Interface
- Extensive discussion on this subject with a detail walk through AP239 interface_arm example population by Phil see
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Phil_PLCS_Interface_example_4.pdf?rev=1.1
- The arm.exp segment within AP233 WD#1 module system_structure tagged as "Product_interface" is
effectiviely a copy of what is in AP210. (To be removed.)
- After the detail walk through it appears that stepmod AP239 module "interface_arm" will service AP233 needs.
- A few open issues remain, to be clarified via further population of example in time for PDES fall off-site review.
- This work will be done by Phil Spiby, Joe Bedocs and Harald Eisenmann
- Population will be to clarify multiple usage and emergent properties concerns
- Populate SysML interface model with same example.
- Detail review by AP210 + AP239 + SysML gang necessary
- Lothar has interconnection concerns:
At occurrence level (Several levels of hubs and ports, Package connectors), Reference designator
- WD#2 decision was to remove "Product_interface" segments from WD#1 system_structure and replace with USE FROM Interface_arm;
- Extensive discussion on the WD#1 proposed breakdown approach vs. AP239 stepmod breakdown modules
- A lack of detail understanding during WD#1 development exposed. It now appears that the AP239 breakdown modules will work.
- Breakdowns allow you to take different cuts at the system allowing you to point to associated parts.
Are pointers to parts.
- Assembly provides another view of problem from the realized/realizable "as is" perspective.
Its a relationship that holds the semanitics of connection, the "as is" view.
- Decision - Remove WD#1 segments of AP233 system_stucture module tagged "System_engineering_system_breakdown".
- Replace with USE FROMs to stepmod breakdown modules
- No need for hybrid breakdown
- Lothar still has some issues associated with the stepmod breakdown modules.
These require detail PDES offsite discussion.
- Phil/EuroSTEP gang to check out animate object support
- Questions arose with respect to the modeling of people (operators)
- Use Part for design, product_as_realized for individual, links to
alternatives needed to support trade-off studies.
- Make sure that we can do alternative design trade-off studies
- Valencia agreement with AP210 was to remove all AP210 module_lite segments of WD#1
- Replace these with USE FROMs to unabridged AP210 modules
- Note that in the stepmod/etc/AP210 folder several fixes are defined for stepmod
modules used by the AP210 modules
- There was sufficient discussion on analysis to reveal that many analysis views exist with no
common agreement as to where the interface between Systems engineering and domain
engineering is to be placed.
- Harry to attempt to lay the puzzle pieces on the table.
- Need to create some example populations that expose/clarify the need for all views
- How to satisfy all. What's really different about the different views of analysis need?
- AP233 FBB and SBB Behavior analysis view, linear analysis, AP210 analysis view,
AP209 analysis view, AP239 (verification) analysis view, decision making [rules of thumb,
peer reviews, negotiations, politics], etc.
- To be discussed at the PDES offsite
- Valencia agreement with AP210 was to remove all AP210 module_lite segments of WD#1
- No discussion on Rules at Rochester
Change Log from base line AP233 WD#1:
- WD#2 - Removed "Product_inteface" segment from arm.exp
- WD#2 - Added placeholder comment line "USE FROM System_identification_and_version_arm;
- WD#2 - Removed "System_engineering_system_breakdown" segment from arm.exp
- WD#2 - Added USE FROM physical_breakdown, system_breakdown, zonal_breakdown,
- WD#2 - Removed all _lite versions of AP210 analysis and rules modules.
- WD#2 - Added USE FROM Analytical_model, Characteristic, Model_parameter, Software
- WD#2 - Added USE FROM Production_rule
© ISO — All rights reserved