ISO 10303 is an International Standard for the computer-interpretable
representation of product information and for the exchange of product data.
The objective is to provide a neutral mechanism capable of describing
products throughout their life cycle. This mechanism is suitable not only
for neutral file exchange, but also as a basis for implementing and
sharing product databases, and as a basis
for archiving.
This part of ISO 10303 specifies an application module for the representation
of the generic elements of the input and output associated with function based
behavior paradigm views of response to excitation analysis.
Concerns and inputs from Erik Herzog
- There is no provision for capturing typing data (value range) for simulation
- does not support reading the value of the items (ios) exchanged/communicated
across functions
Inputs from David Oliver
- The AP233 term for an abstraction representing the information flow between
systems in a systems of systems architecture description is Input/Output. It
encompases any I/O: information, energy, or matter. The major relationships are as
follows.:
- I/O is coupled to function (transformation) through the appropriate function
ports and queues.
- Function is allocated to structure (system, parts, realizations)
and
- I/O is bound to ports of these structure pieces.
- The I/O then flows across the boundary, the interface. It is not, however an observable
characteristic of the interface (the boundary)
- It would instructive for us all to revisit Julian's torch model (flashlight).
This report can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Julian-s_torch.doc?rev=1.1
In this report Julian
populates this model using words as??we have described above and in the concept model.
He shows all the pieces and their boundaries. One can then apply physical properties
to the batteries and bulb, extending Julian's model to include??voltage and internal
impedence of the battreries, impedence of the bulb when lit. One can then solve the
implied ohms law equation for that circuit and calculate the current that flows. This
current, I/O, flows at every boundary in the circuit. There are four such boundaries
for the two batteries and one for the bulb. They all experience the same current flow.
- One can check analytically that this current results in the bulb filament reaching
the appropriate temperature to generate light and that the impedence assumed for the
hot filament is consistent with the current. If one has sized the batteries so that
their stored charge is known, one can compute the life of the torch with one set
of batteries.
- Important properties at each boundary in the circuit are things like the pressure
holding them together, contact impedence, and resistance to environmental conditions
like corrosion or water invasion.
- Note that there is a clear distinction here between a flow of information, energy
or matter, and the properties that exist at a boundary. They are not the same concept.
But when several of us talk about this we wind up using the same words in very different
ways because they got defined differently over the years by different disciplines..
- Consider assembly. In manufacturing it typically means a set of physical components
joined together (welded perhaps) to make a whole. In??STEP it is a relationship between
products, and in SysML it is a class of design. The rest of the world only uses
instances that SysML calls part.
- We just are not going to make progress until we jointly work through a simple example
like the torch, agree on the concepts, and decide what we want to call things. What we
call them will be inconsistent with the rest of the world because the rest of the world
is very inconsistnet in naming. We checked this for interface and interconnection with
AP239 several years ago and found we had the same concepts with differrent names. This
naming problem??is why we spent a couple of years developing the concept model. We can
revisit that model, rename stuff - whatever we wish to do. But we must pin down the
concepts through examples so we can talk with one another without being Sophists.
Clause 1 defines the scope of the
application module and summarizes the functionality and data covered.
Clause 3 lists the words defined in
this part of ISO 10303 and gives pointers to words defined elsewhere.
The information requirements of the application are specified in Clause
4 using terminology appropriate to
the application.
A graphical representation of the information requirements, referred to
as the application reference model, is given in Annex
C.
Resource constructs are interpreted to meet the information
requirements.
This interpretation produces the module interpreted model (MIM).
This interpretation, given in 5.1,
shows the correspondence between the information requirements and the
MIM. The short listing of the MIM specifies the interface to the
resources and is given in 5.2.
A graphical representation of the short listing of the MIM is given
in Annex D.
In this International Standard, the same English language words may be
used to refer to an object in the real world or concept, and as the
name of an EXPRESS data type that represents this object or concept.
The following typographical convention is used to distinguish between
these. If a word or phrase occurs in the same typeface as narrative
text, the referent is the object or concept. If the word or phrase
occurs in a bold typeface or as a hyperlink, the referent is the
EXPRESS data type.
The name of an EXPRESS data type may be used to refer to the data type
itself, or to an instance of the data type. The distinction between
these uses is normally clear from the context. If there is a likelihood
of ambiguity, either the phrase "entity data type" or "instance(s) of" is
included in the text.
Double quotation marks " " denote quoted text. Single quotation marks ' '
denote particular text string values.
© ISO — All rights reserved