Abstract
To address the rising demand for MBSE use in industry, academia must first grasp the industry’s view of MBSE. To facilitate this process, we share quantitative and qualitative data from a survey of the current state of practice and perception of MBSE in the UK landscape. Our study provides a discourse on academia’s self-assessment of the extent to which academia can provide the graduating class with important MBSE abilities to tackle real-world problems. To this day, the most significant challenges to adoption include organisational opposition and structure, a shortage of qualified workers, and the availability of MBSE instruments. Respondents agreed that MBSE tasks such as behavioural modelling, verification, and validation should be included in the teaching curriculum. Based on these findings, we propose academic techniques for designing MBSE instruction within the aerospace engineering degree curriculum. Finally, we explore the obstacles and constraints that academia encounters in implementing MBSE in a curriculum, and some solutions are proposed.
Keywords
Introduction
Evidence for the benefits of MBSE is ample.1–4 According to a recent survey 5 on MBSE adoption in the industry, 97% of the top-performing companies have already adopted MBSE or plan to, and 99% of those who have adopted it are reaping the benefits. A survey by Tech-Clarity 6 on “Closing the Engineering Skills Gap for the Industry” found that systems knowledge is an evolving engineering skill set, where 40% of respondents reported it to be the leading engineering workforce challenge. Moreover, 40% of the respondents said that academia does not cultivate systems engineering skills in their students. Furthermore, the survey result states that top-performing companies believe that the industry should be more involved in curriculum design. The survey established that future revenue streams increasingly depend on the talents of the engineering team. Accordingly, top-performing companies exceed their competitors in developing innovative, high-quality products efficiently by consistently meeting their budgets. For this to happen, companies should double, at the minimum, their current involvement with academia to ensure a consistent flow of appropriately skilled individuals. According to the UK Space Sector Skills Survey 2023, 7 systems engineering is a highly sought-after field and the hardest to recruit (mean recruiting difficulty of 4.1/5 and median time to hire of 13 weeks, the second highest among disciplines). The poll found that the skills gap in the workforce did not change between 2021 and 2023, as indicated by employers. The UK Space Sector Skills Survey 2021 8 resonated with a similar theme and identified that 45% of businesses viewed systems engineering as an area where they felt skill gaps or limitations. Interestingly, the survey showed recruiting staff with new skills was a priority for 47% of employers, and upskilling or reskilling current staff stood at 46%. A survey by the Systems Engineering Research Center 9 also reported that both MBSE roles and skills are the least mature. But what is academia doing to supply graduate skills for the industry to exploit the benefits of MBSE with fresh talent? This paper is an attempt to answer this.
At an INCOSE UK MBSE Interest Group meeting, we found the motivation to conduct this study when we presented a use case of MBSE for early lifecycle design and analysis of aircraft wing landing gear systems represented by multibody kinematics. The system view was holistic to cover diverse MBSE activities of requirements entry, threshold and boundedness, and requirements verification through temporal and logical assessments. During this presentation, we spoke about traceability, functional analysis, unintended behaviour analysis, test coverage, and the landing gear computer’s digital controller stability analysis. The key motivational points that emerged from the discussion were the role of academia in developing MBSE skills in students who, upon arrival at the workplace, best represent the professional practice of model-based systems engineers handling design and analysis for complex multidomain systems. Following the meeting, we decided to seek insight into the stimulating discussion and find hard evidence into the various perceptions regarding the adoption of MBSE in the workplace, the learning curve, the complexity of the tools involved, and most importantly, how academia may supply the skills to prepare the future MBSE workforce who can bring about the adoption sooner. We chose a survey to help answer these questions.
To resolve the disparity between industry needs and the taught curriculum, the academic generally recognises problem-based learning,10–13 a notion reflected in education theory. The universities regularly seek insight into the needs of the industry from its advisory board on research activities, types of engagement, student projects, curriculum structure, and modernisation. However, even with this progressive framework, academics struggle to justify curriculum changes without quantifiable evidence of a need. The advocacy of teaching MBSE becomes further weakened due to the relatively unproven nature of MBSE, as the evidence points out that a majority of the benefits of MBSE are perceived rather than measured. 9
Highlights and contributions
To define the problem, we wanted to know the pace of MBSE adoption in the UK and what decelerates the adoption. Among the causes of MBSE emergence, the rise of complex systems, or System of Systems (SoS) and the lack of connectivity in lifecycle activities are often heard. As systems’ complexity increases non-linearly, frequent re-design decreases companies’ Measures of Effectiveness (MOE) in time, quality, and overall cost. This can notably be stated for large projects that involve multiple departments, as insufficient communications, outdated specifications, or the inability to detect minimal change can cause project failures. 14 As MBSE manifests as digital systems engineering, these issues can be individually isolated and addressed systematically. Even though the emergence of MBSE addresses industry matters of efficient design methodologies, it has resulted in the need to revise academic engineering curricula. This is supported by the 2021 survey 15 by the Institution of Engineering and Technology (IET), which acknowledged a mismatch between employers’ needs and the graduating talent fulfilling them. In the same survey of 1039 respondents, increasing productivity came out at 62%, cutting costs at 54%, and adopting new technologies were rated at 50% as engineering employers’ business priorities. The IET recommended that the industry work closely with academia to improve and shape the skills pipeline. This is done partly through accreditation by trusted third parties, such as the Royal Aeronautical Society (RAeS) for aerospace degree programmes. The industry and RAeS alignment can provide Engineering Analysis (EA) skills, where the learning outcome for EA4i requires the “ability to apply an integrated or systems approach to engineering problems”. 16
This article aims to collect data on industry expectations for the MBSE skills through a survey to assist academics in aligning their instruction to bridge the skills gap between academic training and industry requirements. We sought insight into the state of practice of MBSE lifecycle activities in the UK and the surrounding emerging digital engineering discipline. This insight is needed for industry and academia as MBSE and digital engineering grow and become more sought-after disciplines for the new graduates. It is often believed that good systems engineers are often grown in-house 17 through industrial practice. We contend that good systems engineers, or more accurately, model-based systems engineers, may be organically developed with formal higher education, starting with year-2 and year-3 modules. We share our experience of engrafting systems thinking into undergraduate instruction through multidisciplinary problems contextualised to early lifecycle activities.
Based on input from MBSE specialists, this study intends to close the engineering skills gap for the industry and emphasises the need for MBSE. A survey is used to gather input from the MBSE focus group. The survey’s questions were created with the industry’s possible expectations of academia in mind. Following the tabulation of the results, an academic response was generated to address how academia should change instruction to satisfy industrial demands for MBSE skills. The curricular space and accreditation criteria for engineering programs provide difficulties for this change. These issues have been thoroughly discussed, and then practical suggestions have been made.
Survey questions and motivation.
Mapping of professional body accreditation goals with MBSE lifecycle phases where teaching opportunities arise.
Related Work
Several surveys have been performed on MBSE-related subjects. Broadly, they fall into the following categories: benefits, impact, perceived value, and success stories,1–5 maturity, 9 perceptions, 18 tools and frameworks,19–21 adoption challenges and acceptability,22,23 implementation detail 24 and applicability in the specific industry.25,26 These surveys show some clarity on MBSE acceptability and use, but, on the whole, depict a complicated and confused situation. According to the survey by Adkur, 25 the majority of the model-driven engineering in the embedded software industry learned to model at the university, followed by self-learning, and finally, corporate training. There is usually some type of on-the-job training or formal training provided at the workplace, but a significant value to the investment may be achieved if the trainee is versed in the MBSE thought process and elementary skills from the undergraduate years. None of these surveys tackles how academia and industry should reconcile to bridge the gap for the needed MBSE skills for the future workforce. At best, some surveys point out that there is a skill gap. The NASA report 23 distinctly summed up that MBSE is the future, however, its benefits are still difficult to characterise, and tools and workforce skills issues are major hurdles in adoption.
Survey Setup and Context
Our survey is a social research study investigating the professional opinion of systems engineers on MBSE. With the collected data, we hope to aid the progression of MBSE in academia while considering industrial needs. We conducted this cross-sectional study with the focus population of the systems community and model-based systems engineers. The sample group of 50 responses comprises INCOSE UK members and practising engineers with MBSE knowledge. The participants belong to diverse industries, and a majority are aerospace or defence-related. Some participants belong to large companies. Some are MBSE consultants.
A Participant Information Sheet was circulated for consenting and signing to participate in this research. The participants had the freedom to withdraw at any time without giving a reason. All the responses were completely anonymised. Ethical approval was obtained from the university research ethics committee. Although no participants’ data were obtained, the research team adhered to the General Data Protection Regulation (GDPR) principles for data portability, processing, and security. The research was not funded. The survey was launched online using Qualtrics survey software and was widely distributed through LinkedIn and the INCOSE UK MBSE Interest Group.
The majority of the questions in the survey were quantitative, seeking the response in the form of a ternary reply (yes/no/undecided or partially) or a rating scale (1 to 5) such as the degree of agreement or disagreement, or a numeric figure such as the number of years or people. This is kept to determine the standing of the practitioners of MBSE in product development. value chain. Limited qualitative responses were sought as open-ended responses, where the participants had the opportunity to add a comment in their own words for context, following the recording of their quantitative reaction. The qualitative data was organised into themes. These themes were then scored, and the high trends were noted and reflected upon in this paper.
Eighteen questions spanning from personal to organisational aspects were asked. A majority of the questions were closed-ended. Table 1 displays each question with its rationale. Each question is highlighted in each subsection and aims to address the broad topics of MBSE growth, personal and industrial barriers, tool utilisation, use of MBSE in lifecycle phases, and the need to teach MBSE in academia. The selection of the questions came about from the lead author’s integrated master’s thesis, which focused on the design space exploration of energy harvesting in commercial aircraft landing gear during the touchdown and taxiing flight phases. 27 The lead author was interested in understanding how professional systems engineers approach real-world problems in the MBSE discipline and what their leading concerns were. The academic author was interested in how academia, through industry-relevant teaching, can facilitate the industry in resolving its difficulties surrounding the MBSE practice.
We took into account the psychological consequences of noesis and cognitive bias when developing the questions. While it is impossible to decipher the complete truth and reality from survey responses, common sense (nous) might help comprehend the perspectives. The responses show that the MBSE’s viewpoint is not shared by the industrial participants, and our perspective on applied systems engineering within academia, where we are fast to link abstract system views to physical systems, is not widely shared. Our bias reduction included the following steps: ○ The success or failure of conventional systems engineering will be a driving factor in accepting MBSE, influencing the responses. We recognise that the respondents may instinctively respond without a rational process (viewing MBSE through intuition, whether MBSE is good or bad). They could either neglect or reflect upon the facts, whether bitter experiences or victories of conventional systems engineering and may correspondingly over- or underemphasise MBSE. ○ It is assumed that forward-looking respondents keen on technological advancement may answer positively in favour of MBSE. The responses also can be offset by an old-school mindset that may be poised or exercise caution in espousing MBSE (Q2, Q3). ○ Stepping out of the present comfort zone may also influence responses. Embracing MBSE as an opposite or contradicting view of one’s current position may warrant changes in personal behaviours and upskilling that are difficult propositions for mature staff (Q4, Q5). ○ It is also recognised that curiosity about MBSE, hype and associating with the MBSE community may affect answers. Answer choices in Q5 and commentary in Q6 are intended to counter this bias. ○ Negative (Q7) and positive (Q8, Q9) words are used. The hypothesis is set on a positivist paradigm
28
that both conventional systems engineering and MBSE have value. Similarly, negative and positive characteristics of tools influence the response to value sought in tools (Q7). ○ Q8 purposely restricts the response to engineering design-centric MBSE toolchains like SCADE or those that use SysML as their base modelling language. SysML is also frequently discussed at the UK INCOSE WG. Hence, this bias is worthy of acceptance. We excluded system dynamics tools such as AnyLogic, Arena, FlexSim, Simio, and Vensim, which are favoured in the context of sociotechnical system analysis, planning, production and ConOp, but not commonly utilised in undergraduate engineering curricula. ○ Questions seek diverse perspectives. Q9 and Q10 seek insight into the left leg of the V-model for MBSE utilisation. Q11 considers the lower left leg and the bottom of the V lifecycle view, where MBSE can influence development. Q12 delves into domains in organisations where MBSE is used, without specifying to the respondents what the domains might be. ○ Q13 and Q14 intend to establish invalid, untrue and disconfirmation of evidence, if any, regarding digital connectivity on maintaining a reference source of truth. ○ Q12, Q15 and Q16 use entirely neutral statements. ○ Q17 and Q18 have a reasonable bias by the nature of the context of these questions, that is, academic, concerning teaching state-of-the-art.
Responses and Analysis
This section contains the responses and a brief analysis of the survey conducted during this research. These questions cover the broad topics of industrial MBSE growth, perceived barriers, tool utilisation, prevalence during the lifecycle and engineering domains, and finally, the adoption of MBSE suitability in the context of academia.
Current and future practitioners of MBSE
Q1. “What is the current number of MBSE practitioners in your organisation, and what was the number of MBSE practitioners in your organisation 5 years ago?” Q2. “Is your organisation transitioning towards MBSE?”
Figure 1(b) shows that the majority of participants believed their companies were in the process of transitioning to MBSE. Participants who voted yes stated that “MBSE has been rapidly expanding because of resource allocation on many aerospace and defence contracts”. Additionally, “the application of MBSE for enterprises is being realised as a strategy for the business and corporate sectors” as stated. One participant’s statement suggests that the industry is dealing with the push from multiple domains and needs further resource allocation among MBSE practitioners. This need is further visible as MBSE and digital transformation are often mentioned together and are seen as enabling each other.29,30 Q1-2: Critical mass of the MBSE practitioners in the UK organisations over 5 years and future rise.
Conversely, participants who voted no stated that their companies “struggle as system complexity continuously increases” and that there is a “symbiotic relationship between conventional DBSE and MBSE”. These answers hold weight, as even though MBSE does enable practitioners to deal with complexity, managing the complexity itself is complex. 31 The second comment highlights the capability of MBSE to integrate document-centric processes into a model-centric approach. The statement alludes to the MBSE capability index, where companies can estimate maturity based on capability levels.
From the responses, the critical mass of MBSE practitioners in UK organisations over the past 5 years and the future growth of the MBSE in the UK’s systems engineering landscape are shown in Figure 1(a). This growth may be due to a greater awareness of productivity attributed to MBSE, which supports diverse activities in unbounded and evolving systems. The increase is likely also due to the rise in heterogeneity in products encompassing multi-technology (electrical, electronics, electromechanical, information, and software) and multi-energy (electrical, mechanical, magnetic, hydraulic, thermal, and chemical) domains. Additionally, extended system boundaries and interactions with people, external processes, and regulation give rise to exponential interactions and add to the complexity, thus furthering the need for alternative SE-formalised approaches such as MBSE. Moreover, the growth in recent years is partly due to the Object Management Group’s (OMG) contribution to the development of Systems Modeling Language (SysML) and the incorporation of MBSE methods by the simulation tool vendors. Besides, the increased maturity of versatile MBSE tools and frameworks over the years has enabled MBSE practice both in industry and academia.
Time to transition
Q3. “How many years do you expect your organisation to fully transition from DBSE to MBSE?” Q3: Perceived timeline to fully transition to the MBSE-driven development cycle for UK organisations.
Learning curve
Q4. “Is there a significant learning curve for an engineering team to adopt MBSE?”
It is clear from Figure 3 that a vast majority of the participants agreed that there is a significant learning curve for an engineering team to adopt MBSE. This is well known in other MBSE landscapes, and it further supports the assumption regarding participants lacking confidence and technical skills in adopting MBSE. Q4: View on the learning difficulty of the MBSE.
Organisational and personal barriers to adoption of MBSE
Q5. “Rank these five prominent MBSE barriers (1 being the most prominent barrier and 5 being the least prominent barrier)”.
It was found that the ‘organisation resistance to change’ to MBSE was the most prominent barrier to implementing MBSE, Figure 4. However, a ‘lack of trained engineers’ received the second most votes for the most prominent barrier. It is noteworthy that this trend was also the same for the second most prominent barrier; however, ‘Lack of trained engineers’ was second with ‘organisational structure’. This result echoes well with the MBSE maturity survey
9
in which the skills attainment gap was the second-biggest impediment after the organisation’s culture. Q6. “What barriers have you personally encountered with MBSE that stop you from adopting a full MBSE approach?” Q5: Ranking of barriers to MBSE adoption at the organisational level.
It was found that the participants’ barriers correlated with organisational barriers. Some notable remarks were: “Non-specialists’ lack of understanding or trust of the case for transition and lack of ability by MBSE specialists to communicate that. Lack of awareness of the commitment required and the opportunity. The need to stop doing things that MBSE claims to negate.” “Entry into modelling requires skills that require external training as well as the cost of the modelling tool infrastructure, including licences.” “The initial effort to capture and set up models vs the cost-saving when managing change.” “Understanding where to start and how.” “Customer document-centric systems’ development methodology.” “My organisation has fully adopted MBSE. However, recruiting enough experienced engineers remains an ongoing challenge with a high level of marketplace demand and competition.”
At the individual level, the rate of learning MBSE towards full adoption depends on the level of competence with modelling, including languages, simulation technologies, or software toolchains. We notice this in teaching as well, where the students with expert knowledge of tools and languages outperform the rest. These students are also comfortable with the methodology, can reflect on the outcome of the process through simulation results, and have a sense of numbers 34 and number relationships.
Q5 and Q6 investigate capability and competence in MBSE adoption and upskilling. It is important to make a distinction between the two. Competence refers to personal aptitude and intellectual quality of being adequately or well knowledgeable and skilled. Capability is the ability of an organisation to achieve an objective and produce solutions in some problem domain. 35 Assessment of personal competence is typically overrated. People’s perception of their own competence is usually high for the less competent and low for the very competent. 36 Such misjudgment is susceptible to fluctuations caused by outliers and distorts the overall findings of the survey. At the organisational level, a formal appraisal 37 of the current capability rating and the next step toward transition to MBSE is imperative. For the assessment of individual competence or organisations’ capability, the INCOSE UK Systems Engineering Framework 38 can be applied.
This framework has been adopted in wider INCOSE communities in the Systems Engineering Competency Assessment Guide 39 and uses action verbs similar to Bloom’s taxonomy. 40 A strategy to achieve organisational capability is outlined by Davidz and Martin. 41 For the technical management aspect of systems engineering activities, the Chartered Institute of Personnel and Development (CIPD) provides a measurable competence framework. 42
Engineering disciplines and MBSE
Q7. “Do you find mechanical and aerospace engineers struggle with MBSE more than electrical, electronic, or software engineers?”
Moving on from the barriers, a further focus was put on what type of engineers struggled with MBSE. It was found that there was a relatively equal split on whether aerospace and mechanical engineers struggle more with MBSE when compared to electrical, electronic, and software engineers. Figure 5 reflects this trend. The participants were given the same questionnaire regardless of their first degree and discipline. Some participants may have related their struggle to MBSE tools and methods, requiring knowledge of software engineering paradigms such as meta-modelling or UML and SysML programming languages (a similar trend is noticeable in SystemC adoption, which received a favourable response from engineering communities comfortable with programming languages). Aerospace and mechanical engineers struggle with MBSE because core-discipline modules occupy the space on the curriculum, and MBSE may be either self-learned or acquired during a capstone project. Our experience is that graduates with sound core discipline backgrounds are preferred by MBSE and PLM companies. No and undecided responses were dominant. Q7: Struggle from the viewpoint of an engineering degree background or an engineering discipline of practice.
Preferred tool for MBSE
Q8. “What are the preferred MBSE tool suites at your organisation?”
The Q8 question was asked to assess the disparity between industrial and academic use of MBSE tools. As seen in Figure 6, Enterprise Architect was the most popular, whereas Cameo System Modeler came in second, and MATLAB and Simulink by MathWorks third. This is understandable because the majority of the industry follows SysML-based MBSE practice; however, several other languages can implement MBSE activities to varying degrees.43–47 Note that Ansys SCADE did not attract a single response. This may be because the tool is not based on SysML or any other widely used modelling language. Q8: Tool for MBSE exploitation.
Universities globally often train students on MathWorks tools, which come with MBSE 48 and supporting toolboxes. MATLAB and Simulink MBSE toolboxes are an appropriate means for transitioning year-2/3 and year-3/4 students to an MBSE mindset. This is because the traditional view of a design problem in MATLAB/Simulink from non-SE/MBSE modules that the students are used to remains preserved, and the learning curve remains focused on applying the MBSE methods to the design problem while staying in the confinement to a single tool. MATLAB and Simulink leverage both programming and visual modelling paradigms for the systematic management of complex design space through the algorithmic, block-level, component library, multibody, multi-technology, and multi-energy domains, as well as limited Physics-based abstractions that are often used in the engineering discipline’s core modules. We have applied this strategy, i.e jointly handling design and MBSE methods in a single tool (MATLAB/Simulink) to the aircraft fuel system and landing gear problems, where the students annotate requirements on the models, verify requirements, write test cases for bringing out any unintentional behaviour, and produce coverage reports. Our strategy is in line with the Tech-Clarity survey 6 that emphasised practical applications in academia to use software and apply the technology to solve problems (75%) rather than navigating through the menus (16%).
For newcomers to the MBSE realm, Khandoker 19 provides need-based criteria for tool selection for specific application domains. This may be exercised as a feasibility study; however, established design organisations maintain existing toolchains and support legacy product development through design and methodology reuse. In such cases, a desired criterion is how well the MBSE tool blends with the current toolchain to maximise the value chain. Integration of MATLAB and Simulink with the tools of several vendors is available directly from MathWorks or through third-party APIs. We have developed coursework requiring co-modelling and co-simulation where the integration is straightforward (e.g socket interface or COM objects), such as MATLAB and Simulink to AGI STK. For dissertation work, some students exercise codesign with SysML Cameo/Magic or Enterprise Architect in MATLAB and Simulink, although such an effort requires person-hours and meets with struggle due to a limited trial period of licence and a lack of documentation.
Effectiveness of MBSE in the early lifecycle
Q9. ”Do you agree that MBSE methodologies are more useful at the conceptual and preliminary design level rather than later at the operational level?”
Q9 aimed to determine in which phase of the lifecycle MBSE is most valuable. The majority of 43% viewed MBSE as more valuable at the conceptual and preliminary levels, as shown in Figure 7. The results suggest that the participants acknowledge that the most committed costs occurred at the idea of product or service formulation, its mission and concept of operation, trade studies, and high-level requirements development. We expected that the utility of MBSE would diminish beyond the early lifecycle phase; however, this did not turn out to be the case in Q9. It was found that the use of MBSE in the early lifecycle phase did show a weak response, but overall, there was no unanimity. Q9: Effectiveness of MBSE methodology in the early lifecycle phases.
MBSE as a driver from early lifecycle activities to critical design
Q10. “In preliminary design activities, do you see MBSE methodologies limited to requirements capture and architecture design, including trade studies and what-if analysis, when the product is just a concept?” Q11. “In your organisation, do you see MBSE methodologies or models driving critical design?”
Q10 specifically inquired whether MBSE was utilised for capturing requirements, designing architecture, performing trade studies, and what-if analyses in the early lifecycle. It is reasonable to assume that 13 respondents from Q9 who somewhat or strongly agreed contributed to the 10 Yeses in Q10 (see Figure 8(a)). The total responses received for this question were 49/50. Q10-11: Early lifecycle activities where MBSE is useful and MBSE driving the critical design phase.
Q11 investigated whether the early-phase MBSE activities have a substantial influence on making critical design choices. According to Figure 8(b), 33% of participants believe MBSE is a motivating factor in critical design. This shows that other methodologies (possibly DBSE or Physics-based SE) are still being used throughout the critical design phase. This could also be related to the difficulties in implementing MBSE and the weaker link between MBSE and preliminary design definition to key design details. Therefore, the most prevalent challenges due to human and technological factors 22 impact the lifecycle beyond the concept and preliminary design. Q9–11 calls to mind that MBSE in UK organisations finds diverse utilisation across the lifecycle phases. This further suggests the need for multidisciplinary practitioners to support MBSE exploitation throughout the core activities of system design and analysis and, thus, throughout the entire lifecycle. It is worth pointing out that in academia, the MBSE utilisation seems no different from the industry, i.e MBSE is limited to concept design, preliminary definition, a critical design where it is relatively easy to exploit MBSE in teaching, and assembly, integration, and testing phases such as for design prototyping, e.g additive manufacturing of a model and testing it in a wind tunnel.
MBSE in the tripartite engineering domains
Q12. “In your organisation, what domains are using MBSE?”
Further specific use of MBSE in system, design, and manufacturing engineering domains was inquired about in Q12. We wanted to see the industry’s split in these domains and the maturity of using MBSE, and inevitably digital twins, in the design and manufacturing processes. The response in Figure 9 shows that, presently, in the UK landscape, manufacturing processes have limited applicability of MBSE, again confirming a less mature use of MBSE that has yet to reach later lifecycle phases. Even though manufacturing had the minimum number of votes, it is essential to note that MBSE currently has a weak link to digital engineering, specifically digital manufacturing. Q12: Engineering domains for MBSE exploitation.
The digital thread is an enabler for the digitalisation of the MBSE lifecycle activities. In ISO 15288, the documentation produced during the systems engineering technical processes has limited traceability. MBSE formalises design infrastructure through traceable models and builds upon the technical processes by centralising the data in a shared model space where model refinements, transformations, views and viewpoints are traced down through relationships and linkage of data objects. Each model layer captured in technical processes directly traces the next transformation or model snapshot in the lifecycle phase, enabling a dynamic interrogative semantical layer of data with a digital thread through Stakeholder Needs, Use cases, Behaviour, Measure of Effectiveness, Requirements, Architecture and Design.
Although systems thinking and awareness are on the rise for lean principles and the first-time-right approach, a standardised digital thread for data exchange and supported format across CAD, CAM, and industrial robots is not mature or does not exist.49,50 The overwhelming response to the use of MBSE in the system’s domain suggests that this is the domain where the design space is largely unknown and where exploratory and non-linear interactions manifest, and the number of interactions is also large. So, naturally, MBSE, through its modelling and simulation capabilities, is handy in the exploration of concepts and design alternatives.
Digital thread Utilisation—the missing link
Q13. “Does MBSE help in seeking a single source of truth from the information pool available to an engineer?” Q14. “Do you see the digital thread as a form of data exchange across tools operating offline or in co-simulation or co-design?”
The participants saw that MBSE allows traceability across requirements and functional allocation, which maintains an up-to-date definition of the system across diverse teams, more commonly known as a single source of truth (see Figure 10(a)). Some participants believed that the MBSE only partially helped seek a single source of truth. This might be due to the lack of a standard for the digital thread data object that can be used to stitch the lifecycle phases, achieving full digitalisation of the model views. Therefore, multiple sources of truth need to be used for greater lifecycle coverage. A further ambiguity arises about where the authoritative sources of truth lie in the lifecycle, as for different teams, these authorities could be different. Moreover, since no consensual definition of the digital thread exists,51,52 insight into the data object of the digital thread and its purpose was sought in Q14 through its use in historic, static, or dynamic data exchange and co-simulation/co-design. The response was split, as seen in Figure 10(b), as assorted tools and manufacturing machine interfaces give rise to a heterogeneous digital thread. The heterogeneity of the digital thread further complicates the utilisation of the thread and a definition that should hold across the lifecycle, considering data objects and their flow within and across the lifecycle phases (more on this under Discussion). The total responses received for this question were 46/50. Q13-14: Effectiveness of the MBSE in leading to the authoritative rootage and the use cases of the digital thread in early lifecycle phases, i.e data exchange from offline sources or dynamic simulations and co-development.
Linking lifecycle activities
Q15. “What is the missing link between MBSE and PLM in your view?”
Q15 inquired about the view on the missing link between MBSE and Product Lifecycle Management (PLM). With the conclusion of the critical design phase, MBSE seems to take on a new terminology (PLM) as the views of the baseline 2-D models and architecture evolve and concretise into 3-D products, and PLM starts taking root. The shift to PLM comes into play when the supply chain teams update CAD/CAM models or interface with the baseline CAD/CAM models. In the lifecycle, this is the entry point for mistakes as products are subjected to requirement creep, whether newly derived or new requirements implemented late in the lifecycle, resulting in a discontinuity of information. From Q15 the key enabling links between MBSE and PLM were ‘Tool Commonality’, ‘Real-time metadata exchange’, ‘Uniform and traceable data formats’ and ‘User-friendly platforms.’
Q15 participants showed that interfacing multiple tools can cause common issues. Additionally, multiple participants said that software capabilities for real-time metadata exchange and aggregation are missing links. Others identified a lack of traceability format and unfriendly platforms as the bottlenecks. From the responses, it is clear that participants believe the leading cause is a lack of a digital thread and that digital discontinuity arises while connecting multiple tools. The industry has noticed this issue: Siemens and Dassault Systèmes provide connections between their MBSE and PLM software packages. Also, several third-party APIs exist for glueing tools.
MBSE focuses on the early start of production activities, while PLM focuses on activities related to the development of production specifications. The model-based definition of the system is currently the main emphasis of MBSE efforts. Problem discovery, problem analysis, user needs, system requirements, ConOp, system design, logical architecture, and the creation of design specifications for design realisation are among the primary activities for the MBSE work stream, which includes Phase 0, Phase A, and Phase B activities in lifecycle engineering. When the models are transformed into physical artefacts, CAD schematics and a physical candidate architecture are deduced from the system’s logical architecture, and the PLM activities begin to take root with the Phase C critical or detailed design phase. Connecting MBSE and PLM, both through-life activities, and bridging the gap between the system definition and the actual product is a natural demand to ensure traceability. PLM builds upon the MBSE workflow. PLM integrates CAD artefacts in a single, unified user environment. The industry need is in digitalisation or digital threading of MBSE artefacts to PLM artefacts, to enable a consistent model and design transformation is enabled and traceability across the design in various phases is maintained.
Parallel development of through-life systems thinking, MBSE, digital thread, and digital twin coupled with advancements in ECAD/MCAD design automation, and support of related technologies and standardisation of tool integration across multiple vendors, cosimulation APIs, data exchange interfaces, file formats, intellectual property protection, configuration management, advancements in IT infrastructure particularly a federated backbone, IoT, cloud computing, acceptance of shared models and design methodology, and enterprise connectivity have enabled PLM. A comprehensive introduction to the evolution of the PLM concept and its development history and relationship of MBSE with PLM are provided by Eigner, 53 while Gerhard et al 54 have outlined challenges with the MBSE/PLM integration. The integration of legacy methodology and designs into modern approaches is a major challenge.
In teaching, the missing link between MBSE and PLM is a topic of less concern due to both MBSE and PLM being vast subjects that are domain specialisations in their own right. Teaching PLM in academia is a matter of students’ professional practice and requires product design experience with CAD/CAM and configuration management knowledge. Tech-Clarity survey 6 cited that 51% of the respondents believe academia does not adequately prepare students in PLM. Ordinarily, PLM is likely to be neglected due to the discipline’s core content being seen as adding greater value. At the master’s level or in an undergraduate programme with a systems engineering or manufacturing focus, PLM may find a place in the curriculum as a full module or part of a module, and thus, the topic of MBSE and PLM linkage may arise.
Digital engineering
Q16. “What is the key enabler to digitalisation?”
Perspective on the newly developed digital landscape from the point of view of an MBSE practitioner was probed in Q16. The overall consensus was that demonstrating efficiency improvements, training, and experience with digital twins and displaying a single source of truth were the key enablers of digitalisation. In addition, business maturity, leadership, and vision were also crucial and noteworthy enablers. One participant concisely concluded that the most significant enabler was greater toolset integration and interfaces between requirements, project scheduling, system design, analytical models, and opportunities where the integration capability characteristics continue to persist.
From the top-performing pool of companies in the Tech-Clarity 2017 survey, 6 44% of the respondents reported that academia does not prepare students for the rapidly evolving digital twin subject. This reinforces participants’ comments regarding the training and experience with digital twins, which would be a key enabler of digitalisation. The COVID-19 pandemic left no option but to embrace digital transformation at the organisational and individual levels. During the lockdown in September 2020, Google Trends indicated a peak search in the UK for ‘MBSE’. Thus, a natural acceleration to achieve digital transformation in the workplace manifested. Likewise, academics and students had to adjust to the virtual learning environment, and creativity was needed to achieve informed learning. During COVID-19, the final-year individual capstone projects were purely simulation or digital twin-based.
Suitable MBSE activities in academic teaching and research
Q17. “Would you agree that requirements, verification, and validation should be common practices for academic teaching and research work?”
As might be expected, teaching the full scope of the lifecycle activities coupled with practical coursework to develop a deeper understanding of the MBSE methodology is academically ambitious, especially in keeping the cohort engaged, ensuring that learning is truly happening, and meeting the learning outcomes. Experience shows that MBSE teaching centred on early lifecycle activities is achievable. Moreover, this strategy provides a good connection to the core content that the students are used to and, therefore meets the professional and accreditation bodies’ learning outcomes. This sentiment was the motivation for Q17.
Figure 11 answers Q17 on the industry’s need for skilled workers in MBSE. The resounding majority of participants agreed that requirements and Verification and Validation (V&V) should be topics in the teaching and research spheres of activities in academia. We affirm this view, especially in group coursework and individual capstone projects, which students take on after acquiring skills in engineering analysis and are ready to learn and apply MBSE to a multidisciplinary problem. The Engineering Council of the UK, the regulatory body for the engineering profession
55
emphasises professional competencies such as “specialist engineering knowledge and understanding optimising the application of advanced and complex systems,” “technical solutions for novel problems or dealing with significant technical complexity” and “systematically reviewing the factors affecting the project implementation, including safety, sustainability, and disposal or decommissioning considerations.” Similarly, RAeS
56
learning outcomes are set for “designing products, systems, and processes to defined needs,” “digitally-driven design,” “systems integration,” and the “ability to work with uncertain or incomplete data or specifications”, and “by the appropriate innovation, use, or adaptation of engineering analytical methods.” The Institution of Mechanical Engineers (IMechE) accreditation requires the “ability to apply a systems approach to engineering problems through the know-how of the application of the relevant technologies” and “Understanding of and ability to apply a systems approach to engineering problems” and “Ability to generate an innovative design for systems, components, or processes to fulfil new needs.” The MBSE methodology provides rich opportunities and a breadth of scope for activities to meet such learning outcomes. Q17: Should requirements analysis, behavioural modelling and simulation-based V&V be common practices in teaching and dissertations.?
A small sample of participants stated they neither agreed nor disagreed, which may be due to the view that undergraduate studies should focus on assorted engineering analysis and the notion that engineering processes and methodologies are better suited for learning in real-world practice. In the absence of formal education in systems engineering, the idea of grooming hires from various engineering disciplines into systems engineers through on-the-job training is considered. 17 The total responses received for this question were 49/50.
Teaching MBSE at all
Q18. “Should MBSE be taught at universities?”
Lastly, to conclude the survey, the vital question of “should MBSE be taught at universities?” was posed. This was done to get an overall consensus on how universities should conduct themselves to better suit industry needs. The overwhelming response was in favour of 95% in Figure 12. Q18: Teaching MBSE at all.
As plausible as the response may seem, teaching MBSE requires trained academic staff, potentially with industrial experience in the conventional and model-based practice of systems engineering. To justify value for money, the other necessary skills sought are applied systems engineering or core engineering knowledge, i.e, the ability to teach other modules on the curriculum. The total responses received for this question were 49/50.
Challenges with teaching MBSE
In the industry, the MBSE adoption challenge has shifted from why I should model to how I should model, 22 while the learning curve, organisational attitude, 57 and initial investment remain constant. In academia, for a learner, why is not a problem as a bulk of the engineering education is around modelling and simulation; however, how requires an investment of personal effort and time. It is intuitive for a year 3/4 student to see the value of MBSE in a unified simulation model that embeds executable requirements. This need for MBSE becomes inherent from the gradual increase in the complexity of tasks with yearly progression. In the final year of education, students partake in several activities that require a thorough understanding of the design details of the core discipline modules. This can result in disconnected simulations and little concern about the requirements’ verification process, i.e the design detail dominating the design methodology. Teaching MBSE comes with its own set of challenges. Next, we briefly discuss a few experiences.
MBSE versus conventional systems engineering
MBSE makes little sense without understanding the weakness of DBSE. Therefore, in the systems engineering module, we introduce DBSE first, where verification of aircraft landing gear safety requirements through fault tree analysis 58 is studied. Significant limitations of the DBSE methodologies arise in documenting the results of all analytical analyses or simulations, compiling verification and compliance matrices, and manually tracing requirements. Furthermore, the work lacks the means of requirements validation due to the design being a static model and only the fault tree being simulateable. Next, the pre-modelled landing gear is simulated in an MBSE framework where requirements are digitally traced, decomposed into derived requirements, linked to implementation, and verified. By developing derived parameters, one can accurately size the system. The landing gear dynamics and correct operation in cruise and extension modes are simulated in a test harness. The up/downlock controllers are analysed for the right deploy/retract timing, stability, and ordering sequence of locking events. The controller code is emitted from the system model. To communicate change and identify minimal system change, all these activities are digitally linked in a single system model that also includes geometries. In the DBSE exercise, the landing gear deployment timing requirement is difficult to prove without dynamic simulation. For this, the static model is captured in Simulink Simscape, and deployment time is validated through timing allocation for sizing each actuator correctly and deriving subsystem/component-level requirements, e.g displacement pump rotation, hydraulic pressure, and pipe cross-section area. These determinations are possible in the model-based design. Overall, the mix of activities effectively compares DBSE and MBSE. From the teaching perspective, the challenge is to develop design problems to which DBSE and MBSE may be applied together. At the same time, the problems should be relevant to the core discipline and contribute to the learning outcomes.
Performing MBSE activities on a partial model
Modelling a complex system from scratch to encompass diverse lifecycle activities is a substantial activity for an exercise at the undergraduate level. A further dilemma arises on how to set the design problem in such a way that the focus lies on the MBSE methodology and activities rather than the modelling techniques or design details. For this, our approach has been to provide partially developed models so that the students do not bog down in the intricacies of modelling the design detail but rather modify, refine, or add to the existing model and bring it to fruition with diverse MBSE activities. This approach has been successful in developing an appreciation of MBSE in the fuel system, landing gear, aerospace vehicle control, and spacecraft design problems. Effectively, this is a reuse scenario in the industry, where there is usually some information or a model in existence that one can start with. An extra challenge provision is kept for aspiring students who extend the digital thread from the confinement of a single tool (MATLAB/Simulink) and drive simulation on a physical or realistic mock-up of a subsystem from the activity or parametric diagrams in SysML. The challenge is to develop partial models that can be completed.
MBSE module versus other modules
The limited number of credit hours in the 3- or 4-year degree programme is a constant source of struggle for the curriculum developers, who debate what to add and what to remove. The core modules of the discipline may be considered the strength of a programme and therefore take precedence. In an aerospace undergraduate program, the aero modules (aero-/nautics/dynamics/thermofluids/structures/acoustics/elasticity) are fundamental to the discipline and may be favoured by the accreditation body of the programme. Some programmes have the provision of elective modules where MBSE could be offered. We are of the view that MBSE should be embedded in modules and spread out in an undergraduate programme rather than taught as a separate module. For instance, the MBSE methodology may be applied in aircraft design or aerospace systems design modules, where coursework may focus on any suitable design problem that is handled with the MBSE methods. Our experience shows that MBSE activity requirements annotation on the aircraft fuel system and landing gear model showing implementation links, temporal and logical verification of requirements, developing test harnesses for investigating unintentional behaviour, and D0-178C compliance of processor code have been effective in meeting the learning outcomes stipulated by the accreditation body through the MBSE methodology. The advantage of embedding MBSE in core modules is that the students are immediately able to grasp the agility and value of the MBSE approach set in a practical aerospace design problem. A total MBSE module, perfect in every respect, is suitable for master’s level instruction, where in-depth treatment of advanced concepts and systems theories may be given, and all 12 weeks of teaching may be devoted to the theory of MBSE. The challenge for academics is to find opportunities where MBSE may be brought into the module without disrupting the flow of the module.
MBSE in final-year projects and group coursework
The final-year individual capstone project provides a rich opportunity for experimenting with the MBSE and the freedom to comprehensively explore a particular MBSE activity in a lifecycle phase. A student can set personal aims and objectives, as well as set the breadth and depth of self-motivated learning. From the accreditation perspective, the academic requirement for a final-year project is a complex engineering problem that is practice-based or involves industry, such as the type of CubeSat reference architecture development. 59 This level is sufficient for the breadth. However, for depth, a Physics-based aerospace-related design and simulation are expected, which is typically accomplished in fine-grain numerical simulators. An example is NASA HL-20 aero/space vehicle60,61 controllability regime exploration in a particular flight mode. From the supervisory aspect, the expectation is the student would develop an architecture in SysML and link requirements to it, and analyse the design for basic V&V. A project set in this way enables the full potential of achieving graduate attributes 62 in the compass of systems engineering (interdisciplinary scope, requirements engineering, top-down decomposition, function allocation, architecture synthesis, selection of a candidate solution, and effectiveness of technical results).
Innoslate 63 also recommends the capstone project approach for acquiring MBSE skills with a gradual build-up to the capstone project through MBSE theory in previous modules. However, their view is that analysis done in design tools (MATLAB, Ansys, and Autodesk) is not the task of a systems engineering team, and a systems engineer should be concerned with tasks requiring systems engineering tools (Innoslate and Cameo/Magic). This view can be held in a full degree programme in systems engineering. Our view is that systems engineering and design engineering tasks are highly integrated in core-discipline degree programmes. Typically, core-discipline engineering graduates, with sufficient background in systems, perform system engineering tasks. Moreover, the focus of many design houses is on applied systems engineering problems 64 where the design toolchain is an integral part of the systems engineering methodology. Our view holds merit as we witness vendors integrating MBSE tools in their design toolchain (Dassault Systèmes CATIA Cameo/Magic, Ansys SCADE, MATLAB/Simulink MBSE toolboxes (Requirements, Stateflow, System Composer, Simulink Design Verifier, Simulink Test, Simulink Check, Simulink Design Optimization, Simulink Coverage, Simulink Report Generator).
View of the lifecycle phases
The survey by IMechE 57 identified that the thrust of systems engineering activities in the oil and gas industry is on over-optimised solutions for a specific revenue stream. This generally happens when products or services are designed with space-based systems thinking rather than time-based thinking, which considers long-term effects and later lifecycle activities. Similar thinking holds in the aerospace sector, where the bulk of the systems engineering activities are on new product design with a focus on preliminary system definition. In general, many practitioners of the systems engineering profession limit the systems engineering methodology to preliminary and critical design. 65 The same thought prevails in academia, where it is convenient to introduce the discipline of systems engineering for early lifecycle phases. The commercial aircraft operation life may span over two decades, and therefore, maintenance and operations costs are significant compared to the original development cost. Many graduates will not work in the product design area but elsewhere in the lifecycle phases, where systems engineering will be important. In MBSE teaching, we integrate considerations for later lifecycle activities into the early design phases. An example 58 proves landing gear safety requirements for a standard overhaul period and determines the due maintenance of any components before the overhaul period. This activity takes into account the reconfiguration of landing gear architecture to meet the maintenance requirements. So, systems engineering principles are taught for predictive maintenance, a post-deployment activity, thus substantiating the value of MBSE in the later lifecycle phases.
Scoping MBSE for teaching—bridging programme learning
The learning outcomes of a degree programme are numerous and diverse. Developing course material and meaningful assessments to meet the learning outcomes that map to accreditation and quality requirements is a significant challenge. In the UK, the Engineering Council’s Standard for Professional Engineering Competence and Commitment (UK-SPEC) 55 is the competency framework that all engineering programmes follow for graduates to become registered as an Engineering Technician (EngTech), Incorporated Engineer (IEng), or Chartered Engineer (CEng). Different depositional MBSE paradigms are deeply rooted in the professional registration framework of the Engineering Council. The core discipline accreditation bodies may stipulate additional program-specific requirements and rely on the UK-SPEC. Table 2 shortlists relevant professional competencies and accreditation learning outcomes that MBSE teaching can achieve. This list has been compiled from UK-SPEC and RAeS program accreditation requirements. It is up to the academics to find opportunities in the curriculum where the program-specific objectives of the accreditation and MBSE learning outcomes may be collectively satisfied.
For postgraduate-level systems engineering education, a valuable framework is the Graduate Reference Curriculum for Systems Engineering (GRCSE)
66
jointly developed by the IEEE Systems Council, Stevens Institute of Technology and INCOSE. GRCSE aims to ensure consistency, quality, and relevance in systems engineering education globally. GRCSE guiding principles include : (1) Outcome-based structure: Emphasises competencies that graduates should achieve, such as systems engineering concepts, roles, practice and professionalism. (2) Core body of knowledge: Defines important systems engineering topics and knowledge areas, such as foundation principles of systems and systems engineering, lifecycle, technical management, and applications of systems engineering (3) Programme customisation: Allows adaptation based on academic goals, core concentration and student needs. (4) Alignment with standards: Consistency with ISO/IEC/IEEE systems engineering standards and the Systems Engineering Body of Knowledge (SEBoK).
Continuous Professional Development (CPD)
Lifelong learning and Continuous Professional Development (CPD) courses are a large market for ongoing commitment to on-the-job learning and upskilling for systems engineering capability development. Because these courses are industry-focused and the delegates are practising engineers, the curriculum design and delivery are simpler than a full degree course. NASA’s Academy of Program/Project & Engineering Leadership (APPEL) 67 program defines four levels of systems engineering courses: (1) Introductory Systems Engineering Courses (0-5 Years) (2) Foundational Systems Engineering Courses (5-7 Years) (3) Mid-career Systems Engineering Courses (7-10 Years) and (4) Advanced Systems Engineering Courses (10-15 Years+). INCOSE Systems Engineering Competency Framework 68 identifies four competencies (1) Core (2) Professional (3) Management and (4) Technical and outlines a demarcation of the competency levels (1) Awareness (2) Supervised Practitioner (3) Practitioner (4) Lead Practitioner and (5) Expert. At the undergraduate level, the focus of systems engineering activities is on core and technical competencies. At the graduate level, the focus is broadened to full spectrum with emphasis still on core and technical.
Discussion
Question design is a complex task. Care must be taken to avoid implying a correct answer, and flexibility must be honoured for diverse opinions. Biases such as the Hawthorne effect 69 and the social desirability effect 70 are difficult to avoid. Potential cases of such effects may have influenced responses to Q7, Q9, Q10, Q13, and Q17. The response options in these questions were kept to determine the standing of the practitioners when perceiving the value of MBSE in the value chain. Here, the hypothesis is that MBSE is either to be fully accepted or phased out with time. But how do these two extremes get dissected across the MBSE practitioners’ community? The cardinal responses (undecided, partially) denote quantity and why these perceptions manifest is a different discourse that is not within our present scope.
We now correlate the survey results to the context of teaching MBSE.
As stated in section MBSE versus Conventional Systems Engineering, in the undergraduate year-3 systems engineering module, both conventional and MBSE coursework streams were offered. The coursework encompasses converting static or analytical models to parametrised executable models, the use of multiple digitally threaded tools to perform coverage, and SysML to MATLAB/Simulink coupling. Building such capacity in the students mirrors the results found in Q1 and Q2, which tackle the growth of MBSE practitioners. We note a further interest due to the increased number of students opting for MBSE-centred dissertations or MBSE-based problems when given the option to select between DBSE and MBSE coursework. Q3 was asked to understand the industries’ opinions on the estimated time to transition to MBSE. In a vacuum, the highest voted time to transition from 5 to 10 years could be attributed to typical organisational barriers such as; lack of resources, modelling tool usability, and organisational structure. However, from Q4-6, we can see a clear consensus that organisational resistance to change, combined with a perceived significant learning curve and lack of trained engineer,s can be attributed to the long-term transition period. Other studies regularly confirm organisational resistance.
The barriers to adoption relate to the perceptions22,18,71 such as the true value of MBSE and the personal comfort of learning it. Both may be improved during the formal higher education years by exposing students to complex MBSE-centered problems. Q7 showed that the cultivation of MBSE is independent of a learner’s first-degree domain. From the result seen in Q8, a deeper conversation is needed regarding the right MBSE tool for academia. Ultimately, the answer to this question rests with the academics in selecting a tool that best fits the module, the rest of the toolchain, and how conversant they are with the tool. For instance, a tool-agnostic teaching approach could be suggested; however, this may result in a more theoretical understanding of MBSE methodology rather than practical knowledge of implementation that a graduating systems engineer can put to work for solving real problems. Even at the academic level, reaching across the lifecycle activities through interactions of model abstractions is becoming complex, and interdependence is on the rise. The notion of a system of systems often takes root, and co-simulation scenarios frequently arise. This phenomenon has created an intuitive push where student groups taking the MBSE stream have flourished more than the DBSE stream ones, where the various silo analyses require manual transferring of information across activities. In Q9-12, we asked for the context of the overall scope and uses of MBSE within the lifecycle and engineering domains. The responses in Q9-11 are inconclusive due to their split nature. The responses show that organisations are not limited to using MBSE in early lifecycle/system definition phases, and there does not appear to be sufficient merit to the belief that in some organisations, the system is declared accomplished upon V&V of the requirements. 72 Q12 results show no interest in MBSE from the manufacturing domain. This is consistent with our observation of the teaching streams offered to students (systems, design, and manufacturing). The industry Degree Apprentices from systems and design streams opt for MBSE-related capstone projects, and the manufacturing stream ones do not. The manufacturing stream Degree Apprentices are not allowed to register for the systems engineering module, a condition stipulated by their employer.
Concerning the notion of linking the lifecycle activities and the digital thread in Q13-14, the evolutionary nature of the digital thread 73 across lifecycle phases is often attributed to uncertainties entering the design, particularly during productisation and PLM views taking root in the lifecycle activities. In these activities, 3-D models are refined and overloaded with information to mirror the product being conceived, and real-life effects such as tolerances and physical constraints become authoritative. CAD and CAM communicate in different digital languages, so design and manufacturing stay decoupled. 49 The systems engineers working in such contrasting domains and holding orthogonal concerns would see different values of the digital thread in the lifecycle, and hence, the response to Q14 is split. The link between MBSE and PLM is still very much an open subject in the industry and is yet to be defined as a data object. The missing link between MBSE and PLM is less of a topic for academia since most MBSE activities remain limited to small studies and short-term projects that do not reach the scale or grandeur of the lifecycle of industrial projects. With this said, an ideal case of university and early Continuous Professional Development (CPD) would be to allow an individual exposure to multiple lifecycle phases all in a digital environment (concept and preliminary design, limited critical design, virtual testing of the system, airworthiness analysis of safety-critical code and perhaps virtual flight or certification). The main advantage of such a setup of multi-technology domains is that there exists a single digital workspace in shared memory containing data related to objects and variables of all models, effectively constituting a digital thread reaching out to multiple lifecycle activities virtually.
Q16 pointed to both technological and non-technological enablers related to the matters of the organisations. We shall focus on technological enablers that relate to the whole compass of connectivity of the modelling and simulation infrastructure and automation, i.e linking models, tools, or ideally passing data from one lifecycle phase to another. This is a rapidly expanding area, and it relates to virtually any means 74 that can link the models and data of the conceived system. The lack of open standards agreed on data or file formats and the security of data further complicates the technological enablers. The means may comprise connecting models in a shared workspace, linking tools through APIs, 75 whether on a single platform or distributed computing, 76 and even remotely accessing models or data through the cloud, 77 IoT, or cyber-physical systems. These technological barriers are a bottleneck to fully realising the potential of MBSE, which demands the connectivity of lifecycle phases. We have noted the advantage of a shared digital workspace of MATLAB/Simulink MBSE suite to link models, requirements, and test cases. This workspace can be expanded to models in external simulators, e.g AGI STK. Both of these approaches are in use in our coursework projects; however, they limit the development to strictly 2-D and 3-D modelling. To expand on Q16, the method of developing a digital twin of a factory 78 is considered a case study. The digital twin integrates the cloud platform to track parts as they leave the store database from worldwide sites. All parts in the bill of materials used are ensured. Any delays in the supply chain or being held up due to a part would be flagged immediately, and the location and nature of the problem can be evaluated quickly. Such work on integrating MBSE and digital twin serves as an accelerator and lends well to the principles of lean and concurrent engineering, which MBSE is expected to improve.
Without a contiguous digital thread, disconnects remain uncovered, a single source of truth is untraceable, and manufacturing remains decoupled, and this is the lifecycle phase where many organisations are inefficient. 79 This impression mirrors teaching, where we note the inefficiency of students, taking the DBSE stream with a discontinuous flow of information in conceptual and preliminary design 80 of coursework, over the MBSE students. Therefore, the better performance of the MBSE students justifies the responses in Q17-18.
Limitation of the study
The sample size was small despite the INCOSE UK MBSE Interest Group’s large membership.
As noted earlier, the response to Q10-11 and Q14 about utilisation, usage, and scope of MBSE did not diverge in one way. The split responses show the changeable nature of the MBSE methodology and that its perception in the industry is inconsistent. While the principles of MBSE are adhered to, the use and implementation of MBSE are likely to remain different across domains and industries due to organisational matters and perceptions. As the sample group was diverse, the result of MBSE usage, scope, and implementation can be expected to vary. This directly leads to the limitation of this study. Although the demography and industries of the participants varied, a majority were members of INCOSE UK or INCOSE UK MBSE Interest Group and had different depths of knowledge of the MBSE. Therefore, the responses varied according to the awareness of MBSE and the involvement of participants in the lifecycle phases, where the applicability of MBSE varied.
A further limitation may be due to many participants belonging to large aerospace and defence companies that are slow to transition to MBSE, as opposed to dynamic SMEs that are willing to venture with MBSE. So, inter-organisation success or failure to transform into a fully MBSE-centric workplace can swing the responses.
The study was limited to the UK landscape. It would be interesting if the study were to extend outside the UK, and perhaps academic practice on MBSE teaching from other countries is also weighed in.
Outlook
Further study is needed on how it might be possible to integrate MBSE tools into academia without prescribing a restrictive method or language. This is especially the case with the MBSE tripartite of the tools, languages, and methods often described as the three pillars of MBSE 81 when considering the fast evolution of methods, languages and perceived complexity of tools.
INCOSE Vision 2035 82 states “The future of systems engineering is model-based, leveraging next generation modeling, simulation, and visualization environments powered by the global digital transformation, to specify, analyze, design, and verify systems.” MBSE contributes to the wider digital engineering discipline. SysML v2 83 is widely regarded as an enabler to the evolving practice of MBSE. Once SysML v2 settles and is made available in the tools, a survey should be drawn to focus on the expressiveness and interoperability capabilities of the language to determine the target system solution while keeping in view the role of MBSE in digital engineering.
Companies compete with each other to find the most effective way of using Artificial Intelligence (AI) to increase efficiency and productivity gains, while maintaining design quality and decreasing time to market. The MBSE discipline is no exception in this arena and has found interesting synergies where there used to be obstacles. The MBSE environment is diverse; however, anyone reading up in the field will be anticipating the release of SysML v2 as it promises a revolutionary leap forward in the way model-based systems engineers create, review, and share system designs. Unlike previous MBSE languages (UML, SysML v1, SystemC), SysML v2 uses both graphical and textual notations for systems engineers to create system artefacts. The graphical representation has always bridged the gaps for engineers to understand and depict the definition of a system. However, this is simply not true for current AI models, as the preferred medium is in the processing and generation of text. Due to SysML v2’s textual notation, we predict an uptake in MBSE in companies as the added capability of AI and SysML v2 will drastically increase the rate of production of system models. We predict a greater need for skilled MBSE practitioners as developing models and realising and synthesising them into physical systems will be expected. AI can semantically build system models faster and with higher accuracy than humans. However, a growing need for humans to drive the production and verify the solution is functionally valid remains present. The domain of using, reviewing and iterating on system, subsystem, component and part models auto-generated by the model-based systems engineers is the future of MBSE.
Since the MBSE phenomenon is evolutionary in the industry and its connection to the digital twin 84 (which has no consistent definition) and PLM are shifty, new surveys on MBSE perception, acceptability, and experiences frequently emerge. As academia is under continuous pressure to deliver modern, relevant, and practice-led curricula, new surveys on checking the divergence or convergence of academia and the industry on teaching and practice of MBSE should be valuable to both. Such surveys coming from different geographic spreads may shed different light on the academic take on MBSE skill development based on academia-industry knowledge transfer experience. We suggest a 2–3 year sequential distribution of similar academic inquiry to allow engineers and academics to track the overall needs and progression of MBSE practitioners. The findings of such studies may be presented at conferences and academic workshops to widen the discussion and engage greater interest.
Recommendations for academia
We make the following recommendations to meet the learning outcomes: (1) An investment in academic licensing of an MBSE software package is critical for developing an MBSE workforce of the future. The package need not be SysML-based but should facilitate the learning of principles of MBSE and should link up to the existing toolchain used for teaching the core modules. The expected return on the investment is a positive learning experience for the students and a shorter time to work. (2) Adequate and appropriate training is needed for the academic staff with a focus on case studies for MBSE problems, which will be handled in the coursework. (3) If the curriculum has no room for a dedicated MBSE module, the learning outcomes should be met at more than one location in the curriculum. The incoherent approach achieves a fragmented understanding of MBSE.
Conclusion
Our study shows that interest in or utilisation of MBSE is growing in the UK. This growth is expected to continue as most MBSE practitioners predict a 5 to 10-year timeline to transition fully to an MBSE-driven development cycle. The results also showed that the learning curve for an engineering team to adopt MBSE exists. The survey participants agreed that organisational resistance to change and lack of trained engineers were the two most prominent barriers to adopting MBSE. Both barriers can be removed with a bottom-up approach to carefully modernising the curriculum by introducing MBSE as an overarching methodology that encapsulates core-discipline problems so that the discipline’s core learning outcomes are not compromised. This is the approach adopted and is a good compromise for the limited space in the aerospace curriculum without having a dedicated MBSE module. For ease of transition, Q7 responses show that mechanical, aerospace, electrical, and software engineers all have the same capability of adapting to an MBSE approach. Following this line of thought, implementing MBSE should not be restricted to preliminary design activities or driving the critical design.
Significant MBSE skills may be transferred in group coursework and capstone projects with a focus on early lifecycle activities. Both MBSE transferable skills and the programme and module-level learning outcomes would be met when the module content and assessment are set in a way that the objectives of MBSE methodologies and the core discipline’s accreditation requirements are adequately mapped. For an academic, the winning goals are to plant the seed for systems thinking in the multidisciplinary problem domain, instigate creativity, and show that the lifecycle activities strive for achieving correct design with limited iteration, and this theme is expected in a professional assessment of the engineering programmes. However, the challenge is to find space in the curriculum for MBSE content in competition with the engineering discipline’s core content. Another option is to scatter several MBSE exercises among the “systems” modules e.g avionics, aerospace systems, and space systems. The top-level scope of the MBSE lifecycle and the coherence of activities are not adequately represented by this approach, which only satisfies accreditation requirements for systems.
Footnotes
Author note
The survey was launched as part of Ewan Brown’s master’s degree dissertation. The work was performed while the academic author was affiliated with the University of the West of England, Bristol.
Acknowledgments
The authors are indebted to the anonymous participants of the survey. Thanks go to James Towers, INCOSE UK MBSE Interest Group ex-Chair, and Ian Clark, INCOSE UK MBSE Interest Group co-Chair, for facilitating the survey. Thanks also go to the anonymous reviewers who thoroughly reviewed the article to bring it to its present form.
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The authors received no financial support for the research, authorship, and/or publication of this article.
Disclaimer
The views expressed in this article do not represent those of Capgemini.
