Traditional process documentation often describes what should happen. A model-based process architecture can go further by representing how the process works as a connected system: who performs the activities, which artefacts are produced or consumed, what information is exchanged, and where review or update loops occur.

However, once the process has been modelled, another question naturally appears: what toolchain or enabling system supports this process?

This is where the modelling can be extended. The process model captures the stakeholder roles expected way of working, the toolchain model captures the resources, repositories, platforms and system functions that enable that way of working.

This article shows how the same “Prepare for Modelling” process can be extended to capture a toolchain view using Arcadia/Capella. Other modelling languages can be used.

From process modelling to enabling resources

The initial process model described what are the stakeholder (aka roles) needs:

• the Server Admin prepares the model database;
• the Systems Engineering Manager defines the system engineering scope;
• the System Architect defines the modelling scope;
• the Subject Matter Expert reviews and agrees the scope;
• the System Architect updates the modelling scope if required.

This process view is useful as it clarifies responsibilities and interactions. However, it does not yet fully explain the toolchain that supports these activities.

For example, the process raises questions such as:

• Where is the model created?
• Where is the modelling scope captured?
• Which resource supports the project database?
• Which platform supports collaboration?
• Which exchanges are performed by people and which are enabled by tools?
• Which functions should the toolchain provide?
• Which repositories or resources support the flow of information?

These questions move the modelling from the process itself toward the system that enables the process.

Extending the process

In Arcadia, System Analysis helps define what the system must do and how it interacts with external actors or entities.

In this context, the “system” is not necessarily the product being engineered. It can be the enabling system or toolchain that supports the engineering process.

This is a useful modelling step because it allows us to ask:

• What capabilities must the toolchain provide?
• What interactions are required between roles and tool resources?
• Which information exchanges must be supported?
• Which parts of the process require repository, server or collaboration support?
• Which activities remain human responsibilities, and which are enabled by tools?

The System Analysis view can therefore be used to connect roles and activities, and enabling tools.

This view is valuable because it starts to make the enabling system visible. The process is no longer just about roles and activities, but now about the resources needed to support the process of those activities.

For more background on this Arcadia layer, see System Analysis

Understanding the digital thread behind the process

The next step is to understand the flow of information across the toolchain.

In the example, exchanges include:

• Login Request;
• Successful Login;
• Create Models;
• Acknowledges Model Database Ready;
• Requests Modelling Scope Definition;
• System Modelling Scope;
• Request Modelling Scope Update.

These exchanges represent the digital thread behind the process.

They show how information moves between activities, roles and resources. This is important because process gaps often appear where information exchanges are weak, implicit or manually managed.

For example:

the model database may be prepared, but the acknowledgement may not be formally communicated;

• the modelling scope may be defined, but not captured in a shared repository;
• the Subject Matter Expert may review the scope, but the update request may not be clearly linked to the artefact being updated;
• the toolchain may support model creation but not clearly support governance of the modelling scope.

By modelling these exchanges, the organisation can see where the process depends on tool support, communication, repositories or integration.

Moving into Logical Architecture

After identifying the required functions and exchanges, the next step is to organise them into logical resources.

The Logical Architecture layer helps answer:

• What logical resources are needed?
• Which logical resource performs which function?
• Where should information be captured?
• Which resource supports model creation?
• Which resource supports database login?
• Which resource supports collaboration around the modelling scope?

In the example, logical resources include:

• Project Database;
• Model Server.

The functions are then associated with these resources. For example:

• the Model Server supports creating the model and database login;
• the Project Database supports capturing the modelling scope;

At the logical level, the concern is not necessarily the vendor, product name or deployment configuration. The concern is the structure of the enabling resources and the functions they must perform.

This view helps define the architecture of the toolchain independently from specific physical products. It can support tool selection, integration planning, process improvement and digital engineering roadmap definition.

For more background on this Arcadia layer, see Logical Architecture

Moving into Physical Architecture

The Physical Architecture layer then represents the physical resources or real-world implementation choices that realise the logical architecture.

In the example, the physical view introduces resources such as:

• Tool Vendor Model Server;
• Web-based collaboration platform;

This view is useful because it connects the abstract process and logical toolchain to the actual environment used by the organisation.

For example:

• The Model Server may be realised by a vendor-provided model server;
• The physical implementation may reveal integration risks, access-control issues or repository ownership questions.

This is where process architecture becomes directly relevant to digital engineering implementation.

The model can help clarify not only what the process is, but also what resources are required to execute it consistently.

For more background on this Arcadia layer, see Physical Architecture

Why modelling processes and tools

Many organisations describe their processes in documents, while their toolchains evolve separately.

This can create a gap between:

• the defined process;
• the tools actually used;
• the artefacts produced;
• the repositories where information is stored;
• the roles responsible for creating, reviewing or maintaining that information.

A model-based approach can help close this gap.

By modelling both the process and the enabling toolchain, it becomes possible to understand:

• which tools support which process activities;
• which artefacts are produced or consumed;
• where information is stored;
• which exchanges are required;
• which handovers depend on tool support;
• which activities could be automated;
• where governance or review loops occur;
• where integration gaps may exist.

This is particularly useful for organisations adopting MBSE, because the effectiveness of MBSE does not depend only on modelling skills. It also depends on the way the modelling process is governed, supported, reviewed and connected to the wider engineering environment.

From process documentation to process and toolchain architecture

The previous article introduced the idea of moving from process documentation to process architecture.

This article extends that idea further.

The process architecture captures:

• roles;
• activities;
• responsibilities;
• artefacts;
• reviews;
• information exchanges.

The toolchain architecture captures:

• tool resources;
• logical and physical implementation structures.

Together, they provide a more complete view of how engineering work is performed and supported.

This is not only useful for documentation. It can support practical decision-making.

For example:

• Does the toolchain support the process we expect people to follow?
• Are the right artefacts captured in the right place?
• Are responsibilities clear across roles and tools?
• Is the same information being duplicated across multiple systems?
• Are review loops supported by the toolchain or handled informally?
• Can the process be reused across projects?
• Can the toolchain scale with the engineering process?

These are important questions for engineering governance, MBSE deployment and digital engineering transformation.

The value of modelling the enabling system

A toolchain is often described as a list of tools. However, a list of tools does not explain how the toolchain enables the process.

A model-based view can show:

• what each tool resource is expected to do;
• which process activity it supports;
• which information exchanges it enables;
• which artefacts it stores or manages;
• which roles interact with it;
• where integration is required.

This turns the toolchain into an enabling system.

That is the main value.

Conclusion

Engineering processes are often documented separately from the tools that support them. This can make it difficult to understand how the way of working is actually enabled by the engineering environment.

Using a modelling language, it is possible to model not only the process itself, but also the toolchain that supports it.

The “Prepare for Modelling” example shows how a process can be extended from roles, activities and artefacts into supporting functions, tool resources, logical architecture and physical implementation.

This provides a clearer view of the relationship between:

• the process being followed;
• the roles involved;
• the artefacts produced and consumed;
• the information exchanged;
• the tools and repositories required;
• the physical resources that realise the toolchain.

The value is building a connected representation of how engineering work is performed, supported and governed. That is the next step from process documentation to process and toolchain architecture.

The post From Process Architecture to Toolchain Architecture: Modelling the Resources that Enable Engineering Work first appeared on Hélder Castro.

• activities are described in one place;
• roles and responsibilities are described somewhere else;
• artefacts are stored as separate templates;
• review flows are understood informally;
• dependencies between teams are not always visible;
• updates to one part of the process are not consistently reflected elsewhere.

This can create ambiguity in delivery.

• Who is responsible for producing a specific artefact?
• Which activity consumes it?
• Which stakeholder reviews it?
• Which role requests an update?
• Which step depends on the completion of another activity?

These are not only documentation questions. They are architecture questions.
A model-based approach allows these relationships to be represented explicitly.

Treating the process as an operational system

In the example shown below, I used Capella to represent a modelling process as an operational system. The intent was not to describe the technical architecture of a product, but to describe how people, activities and artefacts interact during an engineering process.
The model captures several complementary views:

• a breakdown of process activities;
• the roles involved in the process;
• the exchanges between those roles;
• the artefacts produced or consumed;
• the behavioural scenario showing the sequence of interactions.

This is important because no single diagram can communicate the full process. A process has multiple dimensions. It has structure, behaviour, ownership and information flow.
The value of MBSE is that these views are not isolated drawings. They are different views of the same underlying model.

Modelling the roles involved in the process

A process is performed by people or organisational roles.
In the example, the stakeholder structure includes roles such as:

• Server Admin;
• Systems Engineering Manager;
• System Architect;
• Subject Matter Expert;
• MBSE Lead;
• Data Modeller.

This makes the process more explicit because it separates the work from the people or roles responsible for participating in it.

This view is valuable because many process issues are actually role-clarity issues. The process may define what needs to happen, but not always who initiates, performs, reviews or approves each step. By modelling roles explicitly, we can later connect them to activities and exchanges.

Defining the process activity structure

In this example, the process is structured around activities such as:

• Prepare for Architecture;
• Prepare Models Database;
• Define System Engineering Scope;
• Define Modelling Scope;
• Review and Agree Scope;
• Update Modelling Scope;
• Capture Architecture;
• Perform Model Review;
• Pre-release Model;
• Release Model.

This type of activity breakdown helps establish the scope of the process before adding detail.

This diagram is useful early in the article because it gives the reader a simple entry point. It says: “this is the process I am modelling.”
However, the activity hierarchy alone is not enough. A list of activities does not explain who performs them, how they interact, or what information is exchanged.
That requires additional views.

Connecting roles, activities and exchanges

The next step is to represent how the process behaves across roles. The operational activity view shows the interaction between the Server Admin, Systems Engineering Manager, System Architect and Subject Matter Expert.

For example:

• the Server Admin prepares the model database;
• the Systems Engineering Manager defines the system engineering scope;
• the System Architect defines the modelling scope;
• the Subject Matter Expert reviews and agrees the scope;
• the System Architect updates the modelling scope when required.

The important point is not only that these activities exist. The important point is that they are connected through exchanges such as:

• Acknowledges Model Database Ready;
• Requests Modelling Scope Definition;
• System Modelling Scope;
• Request Modelling Scope Update.

It shows the real value of modelling the process: relationships become visible. Instead of saying “the system architect defines the modelling scope,” the model shows the context around that activity:

• what triggers it;
• who requests it;
• who receives the output;
• who reviews it;
• what happens if an update is required.

This is where a model-based approach becomes more powerful than a conventional process flowchart.

Capturing the behavioural scenario

A process also has a sequence.
The scenario view shows the order in which activities or roles interact. This is useful because an activity breakdown may show structure, but it does not always show the execution logic.
In the scenario, the process begins with the model database being prepared. Once ready, the Systems Engineering Manager receives acknowledgement that the model database is available. The manager then requests the modelling scope definition from the System Architect. The System Architect provides the modelling scope to the Subject Matter Expert, who may request an update.

This diagram is useful for explaining process logic.
It helps answer questions such as:

• what happens first?
• who sends information to whom?
• when does review occur?
• when is an update requested?
• where are the handovers?

This matters because many project inefficiencies occur at handover points.

Modelling artefacts as structured information

In many organisations, artefacts are treated as static files: documents, templates, exports, spreadsheets or model files. However, in a model-based process view, artefacts can be represented as part of the system of work.
In the example, artefacts include:

• Model;
• Model File;
• HTML Model Export;
• Work Modelling Framework;
• Model Review Template;
• Model Scope.

This view is important because activities do not exist in isolation. They produce, consume, review and update artefacts.
For example:

• “Prepare Models Database” may create or enable the model file;
• “Define Modelling Scope” produces the model scope;
• “Review and Agree Scope” consumes the model scope and may trigger an update;
• “Release Model” may generate or depend on the HTML model export.

When artefacts are represented in the model, it becomes easier to maintain consistency between process steps and expected outputs.

Model-based process modelling

The value is not the diagram — it is the connected model. A key distinction must be made; the value of this approach is not simply that diagrams are produced, many organisations already have diagrams, the value is that the process information is captured in a structured model where relationships can be reused across views.
For example, the same activity can appear in:

• an activity breakdown;
• an interaction view;
• a scenario:
• a responsibility view;
• an artefact traceability view.

The same role can appear in:

• the stakeholder breakdown;
• the operational activity view;
• the scenario;
• the responsibility allocation.

The same artefact can be linked to:

• the activity that produces it;
• the role that owns it;
• the role that reviews it;
• the downstream activity that consumes it.

This is where model-based process modelling becomes different from traditional process documentation.
The model becomes a single source of structured process knowledge.

What problems does this solve?
This approach can help organisations address several common issues.

1. Ambiguous responsibilities
   • When activities and roles are disconnected, people may interpret responsibilities differently. A model-based process view makes it easier to show who is responsible for which activity and where handovers occur.
2. Disconnected artefacts
   • Templates and deliverables often exist separately from the process that uses them. By modelling artefacts as part of the process, it becomes clearer why each artefact exists, who produces it and how it is used.
3. Weak review logic
   • Reviews are often described as governance steps, but the inputs, outputs and update loops are not always visible. The model can show the review flow explicitly, including when updates are requested and which role performs them.
4. Poor process reuse
   • When process knowledge is captured only in documents, reuse between projects is difficult.
     A model allows the same structure to be tailored, extended or reused for different project contexts.
5. Difficult onboarding
   • New team members often need to understand not only what the process is, but how roles, activities and outputs relate to each other. A model-based representation gives them multiple views depending on what they need to understand.

Why this matters for MBSE adoption

Many organisations try to adopt MBSE by focusing immediately on tools, languages and modelling standards. That is understandable, but it can also create resistance.
Stakeholders may ask:

• Why do we need another tool?
• How does this help delivery?
• What does this improve compared with our current process documents?
• Will this create additional modelling overhead?

One way to address this is to use MBSE to model something stakeholders already understand: their own process, this makes MBSE less abstract. Instead of presenting MBSE as a technical modelling discipline only, it can be positioned as a way to make engineering work more explicit, consistent and reusable. The process itself becomes the demonstration.

From process documentation to process architecture

The approach can be summarised as a shift from process documentation to process architecture.

This does not mean that documents disappear. Documents, reports, templates and exports are still needed.
The difference is that they can be supported by a model that maintains the relationships behind them.

A practical consulting proposition

For organisations, this does not need to start as a large transformation programme. A practical starting point could be a focused process modelling pilot. For example, select one engineering process, review workflow or model governance activity and represent it using a model-based approach.

The pilot could deliver:

• a process activity breakdown;
• a role and stakeholder structure;
• an interaction view between roles and activities;
• a scenario showing the sequence of exchanges;
• an artefact structure
• a responsibility and traceability matrix;
• a short process architecture report.

This would allow stakeholders to see whether the approach provides value before committing to wider adoption. The goal is not to force an organisation to adopt a specific tool or notation. The goal is to demonstrate that complex engineering work can be represented more clearly when the relationships between activities, roles and artefacts are modelled explicitly.

Conclusion

Engineering processes are often treated as documents. But in practice, they behave like systems.

They contain roles, activities, artefacts, dependencies, decisions, exchanges and feedback loops. When these elements are disconnected, ambiguity increases. When they are modelled, the process becomes easier to understand, review, improve and reuse.
Using a model-based approach, it is possible to represent not only the architecture of a product, but also the architecture of the work required to produce, review and maintain engineering outputs.
The value is not in creating more diagrams, the value is in creating a connected representation of how engineering work actually happens.

The post From Process Documentation to Process Modelling: A Model-Based Approach first appeared on Hélder Castro.

The MBSE roadmap described below provides a lightweight, tool-compatible structure to:

• Define modelling scope early
• Prepare architecture work for formal and informal reviews
• Support efficient navigation of model artefacts
• Enable architects to defend architecture intent, not spend time searching for diagrams

The roadmap is intentionally pragmatic. It does not introduce heavy governance, nor does it prescribe a single method. Instead, it provides a shared reference for what will be looked at during a review, which modelling activities and artefacts are expected, and which stakeholder roles are involved at each stage.

System architecture activities and artefacts template

This template captures a catalogue of system architecture activities and artefacts that may be considered during a system architecture development.

It is not a checklist to be completed in full. Instead, it acts as a reusable baseline from which project-specific scope can be defined.

Purpose:

• Provide a common vocabulary of activities and artefacts
• Support reuse across projects and programmes
• Avoid re-inventing architecture scope for each development

Key characteristics:

• Covers activities across system definition, analysis, and architecture reasoning
• Tool-agnostic, but easily mapped to Capella or Cameo
• Designed to be sub-setted and reordered per project

Role involved:

• MBSE Lead: defines, captures, and maintains the template

MBSE Arcadia step-by-step quick guide

This document includes:

• MBSE Arcadia matrix in one slide
• MBSE with Arcadia steps and diagrams with description
• References to the MBSE with Arcadia step-by-step guide online

Download PDF867 Downloads

Tool development template

From the system architecture activities and artefacts template it is then possible to create templates for tools and promote consistency when instantiating a new model within a team/project.

Diagrams validation rules

Diagram validation rules define project-specific conventions that complements a modelling language validation rules.

These rules are not intended to gate progress or enforce bureaucracy. Their purpose is to improve clarity, consistency, and review efficiency.

Purpose:

• Improve diagram readability and consistency
• Reduce review noise caused by stylistic or structural ambiguity
• Enable reviewers to focus on architecture decisions, not notation issues

Examples:

• Naming conventions
• Allowed diagram purposes per view
• Minimal content expectations for review-ready diagrams

Role involved:

• MBSE Lead: defines, captures, and maintains the rules

Modelling activities and artefacts planning

Using the activities and artefacts template as a baseline, a project-specific modelling plan is defined using a project adopted tool.

This step explicitly answers:

• What modelling activities will be performed?
• What artefacts will be produced?
• In what sequence?

Purpose:

• Make modelling intent explicit
• Align expectations before modelling starts
• Avoid late surprises during reviews

The plan typically represents a reordered and reduced subset of the full template, adapted to the project context.

Roles involved:

• System Architect (supporting role)
• Team Lead

System architecture modelling implementation

Architecture modelling is then performed following the agreed plan and the selected framework or method, for example:

• Arcadia method step-by-step
• A lightweight process using the MagicGrid framework

This step is where architecture intent is captured, analysed, and refined through modelling.

Purpose:

• Implement architecture decisions coherently
• Maintain traceability between activities and artefacts
• Prepare the model for structured navigation and review

Roles involved:

• Subject-Matter Experts (SMEs)
• System Architect

Model development with template

When implemented using dedicated templates for Capella or Cameo, the roadmap enables a structured and predictable way to find diagrams.

Rather than relying solely on the project explorer, diagrams are grouped and organised according to architecture intent and review needs, not file structure.

Purpose:

• Reduce time spent searching for diagrams
• Support demos and reviews
• Enable non-authors to navigate the model confidently

Role involved:

• System Architect

MBSE Arcadia matrix and diagrams

In this document you will find:

• MBSE Arcadia matrix with references to online content
• Comprehensive list of Arcadia diagrams
• References content and resources

Download Arcadia matrix for Capella394 Downloads

Simple Process for Architecture Development with MagicGrid

This document contains:

• Simple Process for Architecture Development with MagicGrid focused on the solution architecture.
• References to content and resources

Download SPAD with MagicGrid432 Downloads

Sharing the model for review

The modelling tool can generate an HTML model export containing all relevant diagrams, ready for review by non-system engineers using the template index.

This allows reviewers to focus on rather than navigation mechanics.:

• Architecture reasoning
• Trade-offs and decisions
• Gaps and risks

Purpose:

• Enable wider stakeholder participation
• Reduce dependency on the modelling tool
• Improve review effectiveness

Roles involved:

• System Architect
• SMEs
• Data Manager (when shared libraries are used)

Try the VCCS HTML export

Modelling review and progress analysis

To support review preparation and progress awareness, the architecture owner can export structured tables (for example from Cameo) and analyse them externally.

This enables:

• Visibility of modelling status
• Awareness of review readiness
• Identification of gaps and priorities

Graphs and simple metrics can support decision-making, not compliance.

Roles involved:

• System Architect
• Peer System Architect Reviewers

When to use templates to define an MBSE roadmap

Projects and programmes that:

• Care about repeatability
• Care about review quality
• Care about consistency across teams
• Care about reducing delivery and review risk

Individuals who want to:

• Focus on architecture decisions, not artefact hunting
• Avoid unnecessary rework
• Avoid late review surprises
• Reduce personal exposure during reviews

Conclusions

Using structured templates and a lightweight roadmap provides a repeatable way to prepare, structure, navigate, and defend system architecture work at reviews and milestone checkpoints.

The value is not in the templates themselves, but in the clarity they create:

• What is expected
• What exists
• What will be reviewed

The post A practical MBSE development built on templates for clear architecture decisions first appeared on Hélder Castro.

Whether it is an advanced military aircraft, a hybrid vehicle, a cell phone, or a distributed information system, today’s systems are expected to perform at levels that were unimaginable a generation ago. Competitive pressures demand that these systems utilize technological advancements to provide continually increasing capabilities at lower costs and within shorter delivery cycles. The enhanced capability often necessitates increased functionality, interoperability, performance, and reliability, frequently within smaller and smaller devices.

The interconnectivity among systems also imposes greater demands on them. Systems can no longer be treated as isolated entities. They function as part of a larger whole that includes other systems, devices, and humans. This interconnected system of systems (SoS) is dynamic, evolving over time as systems are added or removed and as their uses change. These changes lead to evolving requirements for the constituent systems that may not have been anticipated during their initial development. For example, a mobile device that originally provided e-mail communication has evolved to offer Internet functionality, including access to video, global positioning services, and social media. Systems like automobiles, airplanes, and financial systems are also continuously subject to changing requirements, particularly as they become more interconnected.

Systems engineering is a widely accepted approach in the aerospace and defense industries for providing solutions to technologically challenging and mission-critical problems. These solutions often encompass hardware and equipment, software, data, people, and facilities. The potential value of systems engineering for managing complexity and risk and for improving productivity and quality is increasingly being recognized and accepted in other industries, such as automotive, telecommunications, and medical equipment, among others.

A system comprises a set of elements that interact with one another and can be viewed as a whole interacting with its external environment to achieve a specific objective. Systems engineering is a multidisciplinary approach to developing balanced solutions in response to diverse stakeholder needs.

This approach includes both management and technical processes to achieve this balance and mitigate risks that could impact the project’s success. The systems engineering management process aims to ensure that development cost, schedule, and technical performance objectives are met. Typical management activities involve planning the technical effort, monitoring technical performance, managing risk, and controlling the system’s technical baseline.

The technical processes in systems engineering are used to analyse, specify, design, and verify the system to ensure all components work together to achieve the overall objectives. The practice of systems engineering is dynamic and evolves to address the increasing demands previously mentioned.

The System Specification and Design process includes the following activities to provide a balanced system solution that addresses the diverse stakeholders’ needs:

• Elicit and analyse stakeholder needs to understand the problem to be solved, the goals the system is intended to support, and the effectiveness measures needed to evaluate how well the system supports these goals and satisfies the stakeholder needs.
• Specify the required system functionality, interfaces, physical and performance characteristics, and other quality characteristics to support the goals and effectiveness measures.
• Synthesize alternative system solutions by partitioning the system design into components that can satisfy the system requirements.
• Perform analysis to evaluate and select a preferred system solution that satisfies the system requirements and maximizes the effectiveness measures.
• Maintain traceability from the system goals to the system and component requirements and verification results to ensure that requirements and stakeholder needs are addressed.

Model-Based System engineering approach

Projects have traditionally employed a document-based systems engineering approach to carry out system engineering activities. This method involves creating textual specifications and design documents, either in hard copy or electronic formats, which are then shared among customers, users, developers, and testers. System requirements and design information are conveyed through these documents using text descriptions, graphical representations generated with drawing tools, and tabular data and plots derived from analysis models or databases. A document-based systems engineering approach focuses on managing the documentation, ensuring its validity, completeness, and consistency, and verifying that the developed system aligns with the documented specifications.

The document-based approach can be thorough but has some inherent limitations. Assessing the completeness, consistency, and relationships between requirements, design, engineering analysis, and test information is challenging because the information is dispersed across multiple documents. This makes understanding specific aspects of the system and performing traceability and change impact assessments difficult. Consequently, there can be poor synchronization between requirements, system-level design, and lower-level detailed designs, such as software, electrical, and mechanical design.

Furthermore, it complicates the maintenance or reuse of system requirements and design information for evolving or variant system designs. Additionally, the progress of the systems engineering effort is gauged by the status of the documentation, which is hard to maintain and does not accurately reflect the quality of the system requirements and design. These limitations can lead to inefficiencies that affect cost and schedule and can result in quality issues that often emerge during integration and testing, or worse, after the system has been delivered to the customer.

A model-based approach has long been standard practice in fields like electrical and mechanical design. In the 1980s, mechanical engineering shifted from traditional drawing boards to advanced two-dimensional and then three-dimensional computer-aided design tools. Similarly, electrical engineering moved from manual circuit design to automated schematic capture and circuit analysis around the same time. Computer-aided software engineering also gained traction in the 1980s, utilizing graphic models to represent software at abstraction levels above the programming language. Since the introduction of the Unified Modelling Language in the 1990s, modelling for software development has become increasingly popular.

Now, the model-based approach is gaining traction in systems engineering. Advances in computer processing, storage, and network technology, combined with a growing emphasis on systems engineering standards, have created an opportunity to significantly enhance MBSE practices. It is anticipated that MBSE will become as standard in systems engineering as it has in other engineering disciplines and will be fully integrated into a broader model-based engineering framework.

Model-based systems engineering (MBSE) uses systems modelling within the systems engineering process, to support the analysis, specification, design, and verification of the system under development. The main outcome of MBSE is a comprehensive model of the system being developed. This methodology improves the quality of specifications and design, facilitates the reuse of system specifications and design artefacts, and enhances communication among the development team.

Model-Based System Engineering (MBSE) is the formalized 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. MBSE with Arcadia method provides a guided step-by-step to all that are looking to develop systems that meet stakeholder needs aiming at reducing cost and risk.

Value of a model

The system model is generally created using a modelling tool and stored in a model repository. The system model includes system specifications, design, analysis, and verification information. The model consists of model elements that represent requirements, design, test cases, design rationale, and their interrelationships.

The system model defines the components of the system, with the component specifications used as inputs for procuring or designing each component. Component design models can be represented using domain-specific modelling languages, such as UML for software design, or through computer-aided design and computer-aided engineering (CAD/CAE) models for hardware design.

A model helps to understand the growing systems complexity by breaking down systems into simpler constructs that can be understood.

Tackle the lack of understanding of the initial needs not fully analysed in different contexts.

Removes communication problems by using of a common language (i.e., modelling language) to address communication problems, across spoken language barriers and backgrounds.

Encourages and improves interaction with project stakeholders and all engineering disciplines.

Improves quality as it implements:

• Rigorous requirements traceability.
• Facilitates the system design integrity; enhanced design changes detection and update across different areas.
• Improved requirements specification and allocation to subsystems.
• Early identification of requirements issues.
• Consistent documentation, both within and across projects.

Ability to detect defects earlier in the system development cycle with:

• On-going requirements validation through design verification and the use of simulation and automatic verification, increases confidence, reduces risk and costs.
• Helps to verify the system correctness (e.g., interfaces captured and defined, data flow type is correct).
• Helps to verify system completeness (e.g., all modes and states identified and defined), consistency and correctness with fewer changes.

Improves productivity:

• Reuse of existing models to support design and technology evolution.
• Automated generation of documentation.

A model can be defined as a simplified representation of a real system (i.e., product or service).

Different types of models

Different types of models (not extensive list) ca be defined:
Mathematical models, which allow reasoning about the System to be performed. It can represent equations.
Physical models, such as mock-ups, which provide a picture of what a final system may look like.
Visual model, such as drawings and plans.
MBSE models, capture the architecture design definition of a system, for example an In-flight entertainment system.

How the MBSE model can increase the quality of System design?

An MBSE model provides (not extensive list):
Visualization: MBSE provides visual models that represent the system’s structure, behaviour, and interactions, making it easier for stakeholders to understand and discuss the design.
Common Language: It offers a standardized way to describe the system, which helps bridge the gap between different disciplines, such as engineering, software development, and business analysis. From concept to final design.
Interface Definition: MBSE clearly defines the interfaces and interactions between system components, which helps in integrating different subsystems and ensures they work together seamlessly.
Risk Identification: By providing a detailed view of the system and its interactions, MBSE helps identify potential risks and vulnerabilities early in the design process.
Scenario Analysis: It allows for the analysis of different scenarios, including worst-case situations, to prepare mitigation strategies.
Different Perspectives: Independent views allow the system to be represented from multiple perspectives, such as structural, behavioural, functional, and physical views. This multi-faceted approach ensures that all aspects of the system are considered and accurately represented.
Targeted Communication: Different stakeholders (engineers, managers, clients) often need different information. Independent views allow for the presentation of relevant details tailored to specific stakeholder needs, facilitating clearer and more effective communication.
Focus on Relevant Concerns: Each view can highlight particular concerns, such as security, performance, or usability, enabling stakeholders to focus on the areas most pertinent to their roles.

By addressing all the above, a model reduces complexity, facilitates communication and reduces lake of understanding. That drives to increase system design quality, hence:
Reduce costs.
Reduce time to market
Reduce the amount of rework and fixes

System aspects that can be modelled

When a model activity is undertaking two aspects of the System can be captured:

• Structural aspect: the ‘what’ of the System; it captures what elements a system is made of (e.g., it helps to define the product breakdown structure – PBS) and the relationships between the elements.
• Behavioural aspect: the ‘how’ of the System; how the system elements behave, how elements interact with one another and under what conditions.

A good modelling approach must always consider both the ‘what’ and the ‘how’ regardless of the System, even if we are considering a system such as a database, there is the need to consider how the various stakeholder behave towards it.

When should be considered to model

Modelling can be applied at any product or service stage development. Some examples are captured below (not an extensive list):

• Modelling can be applied whenever there is the need to understand a system or something.
• Modelling can be applied within a small-medium enterprise (SME), start-up or big organisations.
• Modelling can be applied at any point in the Life Cycle, for example, stakeholder needs elicitation by doing “quick and dirty” iterations and scenarios explorations or at later and more detailed development stages.
• Modelling efforts should be applied when only adding value.

Considerations when preparing for MBSE modelling

There are aspects that need to be considered when doing modelling activities: tools, language or notation and people. All this aspects need also to consider planning and scope of a modelling effort as described in the Planning for success with MBSE Arcadia.

Tools

As a model is not merely a collection of representations, but an integrated repository of project knowledge, one or more tools are typically required. These tools must not only provide the necessary capability in terms of language support but should also integrate with each other to ensure completeness, correctness, and consistency across the project.

Language or notation

Standard Techniques and Representations MBSE is most effective when standard techniques and representations are employed. The use of standards improves consistency and facilitates interoperability of tools, people, and process.

People

It is good practise to ensure the appropriate capabilities in modelling languages and tools does not have to be limited to project personnel. MBSE provides the maximum benefit when no translation of the model is required for the stakeholders, Training and support must be provided.

What MBSE is not

Quite common there are myths around MBSE. Hereafter, it will be presented what MBSE is not.

Arcadia / SysML

A representation should use the most appropriate notation for the project. Arcadia and SysML are a very powerful modelling language, however, other languages (e.g., textual, mathematical) also exist and should be chosen on their individual merits.

Simulation

A representation can be either static or dynamic (simulation). Simulation enhances and provides automated and early defects detection.

Part of Systems Engineering activities required on a project

MBSE is an integrated approach to Systems Engineering in which all activities should reference a single point of truth, the model, in order to realise the maximum benefits.

Drawing

A representation (whether graphical, textual, or other) should be connected to the underlying model in order to realise the maximum benefits of MBSE (correctness, completeness, and consistency).

Modelling is MBSE

Modelling forms the core of MBSE, but not all Models are MBSE Models. Modelling and Model-based Engineering (MBE) is extensively in engineering. MBE can be applied to other engineering areas, such as design, and use of bespoke modelling Notations (circuit diagrams, 3-D modelling, CAD, etc.). MBSE, is applied at a higher level and will often be used to harmonise the MBE activities to ensure that the overall System satisfies its original need.

MBSE myths

Model-Based Systems Engineering (MBSE) is an approach that uses models to support the specification, design, analysis, verification, and validation of complex systems. While MBSE offers many benefits, its adoption in organizations can be challenging due to various misconceptions and myths.

Some common myths about using and adopting MBSE:

Myth: MBSE is Only for Large, Complex Projects.
MBSE is only beneficial for large organizations or complex projects with extensive requirements.

Reality: While MBSE is particularly advantageous for complex systems, it can also improve clarity, consistency, and communication in smaller projects by providing a structured approach to system design and documentation.

Myth: MBSE is a Replacement for Traditional Engineering Practices.
Adopting MBSE means completely abandoning traditional engineering methods like document-based approaches.

Reality: MBSE complements traditional practices by providing additional tools and methodologies that enhance, rather than replace, conventional systems engineering approaches. It can be integrated into existing workflows to improve overall efficiency and coherence.

Myth: MBSE Requires All Engineers to be Experts in Modelling Tools.
Successful MBSE implementation requires all team members to become experts in specialized modelling tools.

Reality: While some level of tool proficiency is beneficial, not all team members need to be experts. Training and collaboration are key, with a core team skilled in MBSE tools and methodologies supporting others.

Myth: MBSE is Too Expensive and Resource-Intensive.
MBSE is cost-prohibitive and requires significant resources, making it accessible only to organizations with large budgets.

Reality: While there may be initial costs associated with training and tool acquisition (Capella modelling tool is FREE), MBSE can lead to cost savings by reducing errors, improving design efficiency, and enhancing system reliability. The long-term benefits often outweigh the initial investment.

Myth: MBSE Produces Too Much Documentation.
MBSE creates unnecessary complexity by generating excessive documentation.

Reality: MBSE focuses on creating necessary and valuable documentation that enhances understanding and communication. The documentation is often more coherent and integrated than traditional methods, emphasizing quality over quantity.

MBSE in small-scale/start-up environment

As mentioned above, MBSE is used in large project, but can also be used in many of the small-scale/start-up showing common “pain point” that can be addressed by MBSE.

Pain Point: Limited Resources and Expertise
Solution with MBSE: It can streamline the design and development process by providing a structured approach to systems engineering. This helps small teams manage complexity without needing extensive prior experience, reducing the learning curve and helping teams focus on innovation.

Pain Point: Rapid Development Cycles
Solution with MBSE: The model-based approach facilitates quick iterations and modifications, enabling start-ups to adapt swiftly to changing market demands or technology updates. This agility can be crucial for staying competitive.

Pain Point: Integration and Interoperability Issues
Solution with MBSE: It promotes a clear understanding of system components and their interactions, which is vital for integrating various technologies and ensuring they work seamlessly together. This reduces the risk of costly integration issues later in the development cycle.

The post An Introduction to Model-Based System Engineering (MBSE) and model value first appeared on Hélder Castro.