Physical Architecture Gut Check

Arcadia
1

Hey Friends,

I’m looking for a gut check on a simple example physical architecture blank diagram that I’ve created.

The scenario is fairly simple. I have a controller which is commanding a drive to power a motor. The motor is providing feedback on its position to the drive, and the drive is providing status back to the controller.

My goal is to enable communication of the responsibility of each of the components of the machine and delineate which are executing functions and which are not. Additionally, I want to allocate a cost and maybe even a development status or make/buy decision to each of the system components/interfaces.

Areas of uncertainty for me…

  • I like the way the controller and drive node components contain software/firmware behavior components which are executing functions, but I’m not quite sure how to handle the motor. The motor has functions, but also has physical links that I want to show (cables and fasteners). I ended up just naming the node and behavior components the same, but this feels strange/redundant.
  • I have node components which are decomposed into other node components (Controller drawer, which contains the controller and the drive). I want to show how they are connected to eachother. Is the way I’ve shown them correct, or should I potentially show them outside of the controller drawer and leave the controller drawer empty?

Any other feedback or suggestions are much appreciated as well!

image
image1283×500 54.9 KB

2

I just want to bump this thread back to the top to see if anyone has thoughts on this. I’m still proceding on a similar path but I’m still not sure that it’s correct.

3

A few points that spring to mind:

For the motor;
Function - Should always be verb-noun pairs. E.g Convert electrical power to rotational power.
Behaviour - What sort of motor. AC, DC, 3 phase, singe phase. What sort of physics are you using? Hydraulic, electrical, gas?
Node PC - Do you have a part number? A specific model in mind.

Personally, im not a fan of physical links from a node pc to a sub-node pc. I wouldnt have the three lower fastener links. The controller draw is an entire sub-system/assembly. If it is useful to have the draw itself as a component within the sub-system/assembly you can do this. But seems a bit over the top.

Hope this helps, Josh

4

Thanks Josh, that’s very helpful!

Function - Should always be verb-noun pairs. E.g Convert electrical power to rotational power.

Good point! This needs an update.

Behaviour - What sort of motor. AC, DC, 3 phase, singe phase. What sort of physics are you using? Hydraulic, electrical, gas?
Node PC - Do you have a part number? A specific model in mind.

I kept my example generic, but I planned to name the Node PC something like “3 Phase AC Motor” with the MFG model and PN as attributes using the PVMT. I thought that it would be more appropriate on the Node PC rather than the Behavior PC=, since the Node PC represents the actual physical thing. I think your approach of putting those details on the behavior component could work for the motor, but I have some other objects that get into software deployed on physical hardware, which I think would result in me treating behavior components differently depending on type of component. For example, the controller NC has software BC, but the motor would have a PN/Model NC and a motor properties in the BC. Maybe that’s OK though.

Personally, im not a fan of physical links from a node pc to a sub-node pc. I wouldnt have the three lower fastener links. The controller draw is an entire sub-system/assembly. If it is useful to have the draw itself as a component within the sub-system/assembly you can do this. But seems a bit over the top.

I agree, I don’t like the physical link from a node pc to sub-node pc either. I think I was conflating the idea of decomposition vs. physical connection. The controller and drive are not components of a controller drawer, they are just connected to a controller drawer. So those parts should probably not be “in” the controller drawer. So NOT a decomposition.

Conversely, I have “decomposed” a spindle assembly into a motor mount and motor. The “Spindle Assembly” doesn’t get any physical connections, since they are going to the decomposed node PCs. Maybe this means I shouldn’t show the “spindle assembly” in a diagram like this at all (like decomposed functions).

I also agree that showing things like the controller drawer may be over the top… There are some physical connections that we will care about greatly and some we may care about very little due to the risk they pose. My goal (for now) is to model most of them, but then flag them as critical vs. non-critical in our models to help people understand where we need to consider additional specification/control. Unfortunately that means we may include many things in the model that are non-critical, but I don’t know a better place to document that decision/classification so far.

Here’s a slightly updated example.

image
image994×518 56.4 KB