Hi everyone,
I’m currently building a model bottom-up. The challenge is that the device architecture is modular, so certain components are reused multiple times across different hierarchy levels rather than being confined to a single level. The model will be quite large.
I’ve noticed that at the top level of my physical architecture where I’m currently working on, the links tend to cross extensively, which impacts readability and maintainability. I’ve experimented with REC and RPLs to manage repeated structures, but this quickly becomes complex since these references need to be applied across multiple levels. I got a lot of [REC][REC][REC].
What would be the recommended strategy or best practice to handle this scenario effectively, particularly for minimizing link crossings and improving control over repeated components in a multi-level modular design?
Hi @Christian
I would suggest that you consider whether modelling at the level of detail you are attempting is beneficial. Could you abstract away some of the detail for example? What I’m thinking about is whether simply modelling the composite element is sufficient for your needs. If it isn’t then I suspect there is no other option than to do what you are currently doing. Maybe with a bit of thought you can come up with some alternative strategies. Example, do you need the full details at all levels of the hierarchy?
As for the link clutter, there are two options I can see: either filter them out on the views or use the link categorization function to reduce the number of of discrete links you see on the canvas.
Keeping ontop and in control of multi-level RECs starts getting very difficult. Particularly when changes in the base level RECs are made, and particularly if the “ownership” in the model structure of components, functions, exchanges etc starts to change.
I always encourage my teams to only go one level deep if at all possible, and develop a modelling convention that allows this.
Hi @woodske & @JoshWedgwood, Thank you both for your ideas. They helped me find a good approach to achieve the goal of maintaining the necessary depth in the model while still managing the RECs and RPLs effectively. I decided to simplify the model so that only the REC is fully modeled. For the RPLs, I only include the interface. This way, the overall effort to handle the entire model remains small.