Tags and keywords
A "staging" BDD for defining some flows and ports, and a context IBD for a very simple port-based light flow model for a
SimpleOpticalTelescope in eyepiece mode:
In this example, regular Ports are used together with InterfaceBlocks (which IS allowed):
The flow of
Light out of InterfaceBlock
F_Light and into ~InterfaceBlock
~F_Light is defined using flow properties, then these interface blocks are used to type output and input Ports.
OpticalElement is given both an
iLight:~F_Light Port, so these are available to the
objective and inherited by
OpticalTelescope (which is still distinct from
OpticalElement) is also given both an
iLight:~F_Light Port, and these are inherited by
Object can act like a source so is given an
As per Webel Best Practice for BDDs:
These are then "wired up" using Connectors in an IBD for block
SimpleOpticalTelescopeContext. For brevity, the types of the Ports are not shown.
In fact, the Connector to the Port
~iLight of the
objective and the Connector from the Port
^oLight of the
eyepiece are both owned by
OpticalTelescope, whereas the Connector between the Port
^oLight of the
objective and the port
iLight of the
eyepiece is owned by
SimpleOpticalTelescope, because it may not apply to every telescope (such as reflectors with secondary mirrors).
Concerning naming: when there is only a flow of one kind, names like 'i', 'o', and 'io' are perfectly sufficient for ports with simply flow properties. When, however, there is more than possible flow, names like
iLight help distinguish them from, say,
The passage of light is indicated using an ItemFlow on each Connector, always here with the same conveyed Classifier
Light, it does not yet show any transformation of the light (which one could do with a specific SysML itemProperty on each Connector).
Although an eye is not responsive to some of the wavelengths included under «optical»
Light, the flow into
:Eye is not restricted here to
VisibleLight, because one may wish, for example, to include an image sensor that is sensitive to infrared. The response of an
Light is solely determined by
Note how each of the elements in the final IBD corresponds to a physical zone/extent in space. The diagram does not represent a physical geometry or optical layout, but it does represent a light flow topology, with clear boundaries between zones.
We see next how a SysML itemProperty can be assigned to the ItemFlow on each Connector to create a simple port-based image flow model showing transformation of the image of the distant observed object.