Hello, I’m looking at into tranistioning from document based to model based system engineering with Capella. We have a software product to monitor, automate and control railroad yard equipment, that is highly customizable for each customer installation. Imagine the sample in-flight entertainment system being integrated into different aircraft models for different airlines and part of a larger system of systems. What would be the best approach, a common model with unique variations or multiple unique models made up from a libray of common components? I’m new to this tool and method, but sense it could be beneficial over the current method of making modifications to copies of documents to describe projects. Thanks!
Based on the information you’ve provided it sounds like your product is, by intent, configurable. This is therefore a behaviour/function of the solution that I would personally define and explore within the SA and LA analyses. It isn’t clear from your description whether it is only the software that can be configured or if alternative software and physical products are required to create a deliverable solution, which might imply variant physical architectures. The question I would ask myself: is there actually a common physical architecture and PBS that can be defined that only needs to be instantiated in variant BoMs for non-functional reasons.
I would encourage you to model to abstractions as much as possible. This will result in a common-as-possible model that is easier to maintain and might reveal opportunities for invention and simplification. I would definitely discourage you from creating multiple unique models. If it is really necessary the idea of building distinct physical architectures from a library of components is probably the better option. However, there is no single “best approach”.
Apologies for the vagueness, but the forum would need to understand your problem and solution domains much better before offering more precise answers.
Thank You. That gives me some food for thought. We have a centralized traffic control software application that is configurable for each installation, controlling a mixture of hardware railway switches, signals, etc.; the physical and logical layout of which looks different for each customer. The underlying operations and protocols are common and adhere to industry standards, while the installations are in different configurations (i.e. number and location of switches, signals and sidings, etc.) I’m looking at MBSE to create design documents and requirements traceability from the model(s) instead of using document-based systems engineering. Thanks again for your thoughts.
IMO using Capella for modeling and a dedicated requirements management tool together would work best. RM tools offer better requirements traceability capabilities and they also support managing product variants or requirements reusability across multiple projects, e.g. ReqView does this using linked projects. A possible workflow could involve managing requirements in ReqView and using iterative updates via ReqIF to keep the Capella model in sync.