Requirements by Geometry | Part 2

In Part 1 of this series, we described a multi-arm robot or unmanned ground vehicle (UGV) and the use of Syndeia, the MBSE interoperability platform from Intercax, to transform text-based requirements from a Jama repository into a SysML model in Cameo Systems Modeler (No Magic).  In this part, we will create an alternate model-based representation in SysML of some of those requirements and use Syndeia again to transform them into a native CAD file. We call this process “Requirements by Geometry”.

Figure 1 Structure of arm requirements as geometric primitives (Cameo)

Syndeia enables model transform of a SysML block structure to a Siemens NX CAD file in a very specific way, which we can use to define requirements by geometry. Figure 1 shows such a structure. The top-level block, Arm_Reqts, has been given the <NX_Part> SysML stereotype.  Its part properties are usages of a limited set of geometric primitives, e.g. Cuboid, Sphere, that Syndeia recognizes and can create as part features in an NX CAD file.  These have the <NX_Part_Feature> stereotype and a set of characteristic value properties that define the origin, orientation and size of the element.  The part property names represent the role that element plays in the requirement.

For example, the part property ugv_body represents a cuboid robot body with a length of 800 mm, width of 600 mm, and height of 200 mm. The origin coordinates (0, 0, 0) for the assembly are located on the front left corner of the top surface of the UGV body. The units, mm, are defined by a tag value in the <NX_Part> stereotype. The arm_1_locus:Sphere part property represents the required range of motion of the front arm, with an origin at (150, 400, 50) and a diameter of 500 mm, representing a maximum extension of 250 mm from the mounting point.

Clearly, the UGV body is a region the arms cannot penetrate. Similarly, keepout_1:Cuboid represents a region between the two arms that neither of the arms is allowed to encroach upon, to prevent interference between the arms and with the antenna and battery compartment access. Its position is clearly defined with respect to the rest of the assembly and affects both the static and dynamical aspects of the mechanical design.

Figure 2 Diagram in Cameo showing <<satisfy>> relationships between requirements and geometric primitives

The NX_Part_Features in Figure 1 can be linked to the text requirements in Figure 3, Part 1 of this series by the SysML <Satisfy> dependency. Several examples of this are shown in Figure 2. At this time, there is no simple way to connect these at the attribute level, i.e. to update the part feature dimensions from values in the requirements text. However, improvements in property-based requirements and SysML parametrics should make this readily available in future SysML tools.

Figure 3 Syndeia dashboard Connection Manager with Cameo SysML model in left column and local file system on right

Syndeia can now be used to create the CAD file in NX. The Syndeia dashboard in Figure 3 shows the Connection Manager tab arranged to display the Cameo SysML model in the left column, a local file system folder structure on the right, and Model Transform selected in the center. A drag-and-drop operation dragging the Arm_Reqts block from the left and dropping it on an empty package on the right gives the user a choice of creating an Excel, Simulink or NX file. Note that the user must have access to an NX license in order for Syndeia to create an NX file.

Figure 4 Arm_Reqts, wire-frame view

Figure 5, Arm_Reqts, shaded view

The resulting 3D parameterized CAD file is shown in two views in Figure 4 and Figure 5, with labels added for clarity.  Note that the spheres representing arm extension overlap with the keepout zone as well as the UGV body, requiring either a mechanical or control solution to arm movement to prevent interference. This CAD model becomes the starting point for the mechanical designer’s work, defining the size and relative position of critical structural constraints.

In the third and final post of this series, we will repeat the process for a second set of geometric constraints governing the transportation configuration, and then use graph database technology and pattern-matching query language to explore a section of the Digital Thread that we have built.

For another example of the “Requirements by Geometry” approach, check out a publication from NASA JPL and Intercax at Architecture to Geometry   Integrating System Models with Mechanical Design, Bajaj, M., Cole, B., Zwemer, D. , AIAA Space 2016 Conference, Long Beach, CA, USA, Sep 13-16, 2016.

Related Posts:

• Requirements by Geometry – Part 1
• Requirements by Geometry – Part 2 (this post)
• Requirements by Geometry – Part 3
• Requirements by Geometry – Part 4