OPAL research reactor

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.

Port-based systems engineering of block models for control and simulation of Neutron Beam Instruments of the OPAL research reactor using UML/SysML

The content or the technology discussed here is HISTORICAL or ARCHIVAL
Authors: 
Kelly, D. R. C.
Year: 
2007
Publication type: 
Journal

The OPAL research reactor serves as a neutron source for diverse Neutron Beam Instruments
(NBIs) undergoing commissioning throughout 2007 by The Bragg Institute of the Australian Nuclear Science
and Technology Organisation (ANSTO) [1]. Port-based Systems Engineering (PBSE) using UML2.1.1[2] -
and more recently SysML [3] with explicit physical flowport support - has been employed to support Model-
Based Systems Engineering (MBSE) of NBIs, including reverse- and forward-engineering of Java
components, and development of XML schemas for NBI hardware components and sensor-actuator device
networks. Electronic systems, neutron flows, and vacuum systems are modelled as UML2 ports with custom
notation and SysML flowports. The NBI models thus engineered are incorporated into a ModelServer system
(implemented in Java+XML), which acts as a distributed, multi-client, control system façade that integrates
low-level, logical device interactions (via a real or simulated control system) into high-level, physical
instrument block models that support recursive control [4] and derived, controllable, physical system values.

Syndicate content
randomness