To MBSE or not to MBSE – is that the question?
I’m often faced with this question when first stepping into a new organisation. It arises from a common misconception regarding the deployment of Model Based Systems Engineering and my answer is always ‘it doesn’t have to be an all or nothing approach’.
Model Based Systems Engineering is described by INCOSE as ‘the formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases’. For me, the key phrase here is ‘to support’. What follows can be simply described as Systems Engineering, which then widens the scope beyond systems and the activities above.
Systems Engineering and Model Based Systems Engineering are not different in the principles applied, rather the method of analysing the situation and/or documenting the results.
A more valuable question
I have often found that large organisations looking to move to a model based approach are being advised, or have established a need to replace, their existing Systems Engineering process with a fully model based process. This then leads to the question in the title of this article. But the most important thing to consider when deploying a model based approach is ‘why?’.
Why should the organisation do it, what is the goal we want to achieve and what is the benefit? This should then be balanced against costs. Choosing a single project on which to ‘flip the switch’ is often not the right approach. By considering the lessons learnt from previous experiences, a need can be established, and once you have a need, you can develop a solution.
My approach to the deployment of Model Based Systems Engineering is to apply where needed. This doesn’t involve an overhaul of the full engineering lifecycle or systems process in an organisation, but instead a subtle approach stepped over several projects, with each step contributing to continuous improvement.
Making smart decisions
During a previous project, for which I was the lead, a need was identified to improve the integration of a number of supplier provided and in-house developed control units. Experience had shown us that a document-centric approach was leading to miscommunication of interfaces due to there being multiple sources of the same information.
The approach taken on previous projects was for the function of each system to be separately described in a dedicated document. This was then supplemented by an Interface Control Document, which detailed the interaction between that and other systems.
As you can imagine, describing a function in one place was quite difficult considering multiple systems would be involved. Whilst other methods were considered, it was determined that a Model Based Approach for integration would be applied. However, it was also determined that any approach would need to fit into the existing requirements management and safety assurance processes. There was no appetite to enforce a fully model based engineering approach across the full product.
So, by defining the interfaces to the existing process, it was established that a combination of a functional model and text-based requirements was the way forward. To ensure we achieved the goal, a robust structure text requirement ontology was defined and linked to the modelling activities. The requirements into and out of the functional domain were the process interface points.
The integration of the processes was not the only factor to be considered. There were other stakeholders that needed to be considered as part of this transition, not least the team performing the functional integration.
In the example that I call upon, the team was a mix of experienced functional integrators with extensive domain knowledge and experience, coupled with some younger aspiring engineers. However, none had experience in using SysML, the language chosen by the organisation.
Balancing the team and bringing them on the journey was imperative to its success. Isolating key domain experts would be a disaster, so the decision was taken to hire some SysML experience candidates to supplement the existing domain knowledge. The Functional Modellers would learn the domain from the Functional Integrators and vice versa.
This would deliver a complete team of Functional Architects with capabilities in both, but specialisms in one. The inefficiencies at the start of the project, due to learning, were soon outweighed by the capability to have a larger multi-skilled team.
Cost vs benefits
This is a single case based on my experience. However, this is an approach that should be considered when thinking about deploying MBSE in to any organisation or tackling any problem. There are further improvements that could be incrementally made, incorporating the use of the model created in the example above.
For example, Agreement of Context Interfaces with the customer and external stakeholders, Model Simulation to provide early validation of the specifications created, integration to the safety engineering process to support safety arguments to name but a few. The process could be further expanded to include mechanical domains and into product line engineering.
The key takeaway from this piece is that MBSE is not an all or nothing solution, it is another tool in the systems engineering toolbox. Learning how to apply and adapt MBSE to fit existing processes is where the greatest cost vs benefit arguments are made. It also allows slower integration, leading to less reliance on expert modelling engineers to deploy the tool whilst not isolating the domain experts, whom are so key to business success.
Ricky Clayton | Principal Consultant
Related Projects:
