Composition vs Reference for Shared Robot Joint Modules
A warehouse robot has two arm variants: a 4-joint picking arm and a 6-joint heavy-lift arm. The joint actuator module is identical across both arms and is maintained by a separate supplier. The current model uses composition: each arm block owns its own 'JointModule' parts, so the same actuator appears as two distinct block types in the library, and supplier updates are copied manually. An engineer proposes changing all joint parts to references to a single 'JointModule' block. The safety team objects because each joint has its own serial number, calibration data, and fault state at runtime. The model must show that the heavy-lift arm has two additional joints and that the module is interchangeable. The team uses SysML blocks, parts, ports, and associations. A design review is next week. The supplier will release a new actuator firmware that changes one port's flow direction.
1. Should the arm own joint modules by composition or reference them by association? Explain using lifecycle and runtime data.
Read the worked answer
Use composition for the arm-to-joint relationship, with the joint parts typed by a single shared JointModule block. Composition means the arm instance owns its joint part instances; when an arm is destroyed, its joints are destroyed with it. That matches the runtime facts: each joint has its own serial number, calibration data, and fault state, so two joints cannot be the same instance. The engineer's proposal to 'reference a single JointModule block' confuses type sharing with instance sharing. The type should be shared in a library; the parts should be composed. The current model's real defect is that it created two distinct block types for the same actuator (or copied the type), not that it used composition. Fix by moving JointModule to a shared library, giving it ports and value properties, and typing each arm's part properties with it. Use an association only for a genuinely shared external unit, such as a ground power cart, not for installed joints.
2. How should multiplicity and the two variants be modeled to show 4 vs 6 joints and interchangeability?
Read the worked answer
Model the shared type once and let each variant own the correct number of parts. A PickingArm block can have four part properties typed JointModule, and a HeavyLiftArm can have six; if the joints are identical roles, a single part with multiplicity [4] or [6] is acceptable, but explicit parts are clearer when mounting positions differ. If the variants share common properties, generalize both to an abstract Arm block for those properties, but do not put a fixed [4] multiplicity on the common part if HeavyLiftArm needs six. Interchangeability is expressed by the shared JointModule type and its port/interface contract, not by copying the block. The supplier's new firmware should change the interface block or port type once, and both arms inherit the change. Use a «substitute» only if you need to model an allowed replacement; otherwise same type plus same interface is enough.
3. What ports and interfaces belong on the joint module vs the arm, and how should the firmware change be handled?
Read the worked answer
Put on JointModule only the ports that are intrinsic to the actuator: power in, command/feedback signal ports, and mechanical mounting/load ports if modeled. Put on the arm the ports that aggregate or expose the arm's external interfaces, such as the arm-to-controller connection and the end-effector interface; do not put arm-specific ports on the shared module. Type proxy ports with interface blocks so flow direction and item types are explicit. For the firmware change that reverses one port's flow direction, update the interface block and the port type once, then validate both variants; if the change is not backward compatible, create a new interface block version and use a stereotype or variant property to record applicability. Do not handle it by adding a second port to one arm only, because that breaks interchangeability.