neutron beam instrument

Figure 15: Simplified SysML version of the Platypus neutron reflectometer model.

Figure 15: Simplified SysML version of the Platypus neutron reflectometer model.

With SysML flowport notation for neutron beam and air flows, control ports in UML2 notation, rich values with physical units, and part-specific default values assigned according to the usage context. MagicDraw™ UML's SysML1.1beta plugin was used.

ERROR: it is known that (at least) some of the details of the vacuum systems are wrong.

Figure 14: SWT TableTree ModelClient showing an instance of the Platypus reflectometer model.

Figure 14: SWT TableTree ModelClient showing an instance of the Platypus reflectometer model.

Note Systems Modeling Language™ (SysML™)-like node groups: attributes, values, parts, ports. (Controlled values are not synched here with the live control system.)

Figure 13: Model: wrapped block class diagram (software engineering view) for the entire monochromation beam ("logical") stage.

Figure 13: Model: wrapped block class diagram (software engineering view) for the entire monochromation beam ("logical") stage.

Includes deeply nested motorised motion stages of the monochromator's goniometer. Only block «wrapper» Components throughout (no «part wrapper» Components are used), since all blocks are designed for this monochromation context only, no reuse in other assemblies is intended, except for the reused motion stage blocks, which are not yet separately wrapped here. To include content specific to each motion stage part they would need to be wrapped in individual «part wrapper» Component.

Figure 12: Model: UML2 composite structure diagram of the monochromator stage assembly with motorised goniometer rotation, tilt, and translation stages, which are driven by encoded devices.

Figure 12: Model: UML2 composite structure diagram of the monochromator stage assembly with motorised goniometer rotation, tilt, and translation stages, which are driven by encoded devices.

Although named after the motorised, controlled values, these are still only the physical blocks. In fact, the upper motion stages will move (they rotate) when the rotating device of the lowest stage (mom) is activated, even though the controlled variables of the upper stages are not even driven. This illustrates an important difference between a low-level logical device view and a physical block view with geometry and relative assembly.

Figure 10: Model: UML2 composite structure diagram for the monochromation beam stage of the neutron diffractometers of the OPAL NBIs.

Figure 10: Model: UML2 composite structure diagram for the monochromation beam stage of the neutron diffractometers of the OPAL NBIs.

Shows beam-centric organisation of the system dictated by neutron flow ports (as opposed to assembly-centric organisation). The monochromator shield assembly is screwed to a concrete floor, the monochromator assembly (including goniometer) rotates with a monochromator shield drum assembly (which is partly inside and partly outside of the fixed monochromator shield assembly), and the beam passes through both “fixed” and “moveable” parts. The use of flowports helps to organise the model according to the logic of the beam. Note the difficulty in reflecting the horizontal beam path concisely.

Note also the lack of direction on the typed 'rotates with' and 'is mounted inside' connections compared with the "directed" association names.

Figure 11: Model: UML2 composite structure diagram of the monochromator assembly

Figure 11: Model: UML2 composite structure diagram of the monochromator assembly

Corresponds roughly to the view from above (the UML diagram can only at best indicate topology, not geometry).

Note also the lack of direction on the typed 'rotates with' and 'is mounted inside' connections compared with the "directed" association names. Compare with the «fitted» and «mounted» Dependencies, which emphasise the time order of construction (assembly) of the components, i.e., that the supplier must exist before the client.

Figure 09: Model: bunker shield assembly for the Platypus reflectometer as "wrapped block" class diagram.

Figure 09: Model: bunker shield assembly for the Platypus reflectometer as "wrapped block" class diagram.

Many of the parts are used only once; their blocks are specifically designed for this one-off application, and so they do not require «part wrapper» Components, and their block «wrapper» Components are contained by their unique block wrappers. Other parts are typed by reusable generic blocks, and so they are given specific «part wrapper» Components.

Figure 08: Model: Bunker shield assembly for the the Platypus reflectometer as UML2 composite structure diagram with flowport notation.

Figure 08: Model: Bunker shield assembly for the the Platypus reflectometer as UML2 composite structure diagram with flowport notation.

The «block» class is wrapped by a block «wrapper» Component that is hyperlinked to a block wrapper class diagram for the block. Other «block» classes are shown to provide a usage context and alternative navigation points1. Physical values (part-specific defaults) are not easily shown on the parts2. The limits of the port-based modelling and assembly interpretations are challenged by a postbunker guide that is part inside and part outside the bunker.

  • 1. Since 2008 MagicDraw UML supports easier navigation to clients of a Class in a Composite Structure Diagram, so there is less need for this strategy now. Note also that it is not always wise to indicate the usage context explicitly, it can prevent modularisation !
  • 2. Since 2008 MagicDraw UML supports SysML-style property-specific value indicators on UML Property symbols in composite structure diagrams

Figure 07: Model: Top-level UML2 composite structure diagram (systems engineering view) for the Platypus Reflectometer

Figure 07: Model: Top-level UML2 composite structure diagram (systems engineering view) for the Platypus Reflectometer

Connections from the bunker vacuum port and chopper control port to the boundary are not shown, and some other vacuum and control ports are omitted. The «proposal» and «design» Comments are elicited from the actual documents for the instrument.

Such "binding" of text to Unified Modeling Language™ (UML™) models has been formalised by Dr Darren as the UML™ Parsing Analysis recipe.

Figure 06: Example: wrapped class diagram (software engineering view) of a fictitious neutron beam conditioning bunker

Figure 06: Example: wrapped class diagram (software engineering view) of a fictitious neutron beam conditioning bunker

Shows a top-level block «wrapper» Component for a conditioning bunker and its contained «part wrapper» Components, which graphically and logically organise the diagram and design comments within their respective block or part contexts (corresponding to part Properties).

Syndicate content