Making the Case: MBSE versus Spreadsheets and Documents

Making the Case: MBSE versus Spreadsheets and Documents

We have the pleasure to share this article written by Chad Jackson, as guest author. Chad is Chief Analyst and CEO at Lifecycle Insights.

Introduction

Traditional mechanical products are no longer traditional, nor are they strictly mechanical. Because modern products include a mix of electronics, electrical systems, software, and internet-of-things connectivity, engineers in different disciplines commonly work together on design. But collaboration doesn’t always go as planned. When engineers who are charged with different aspects of design don’t have a means of working together, costs increase and problems arise: problems like failed hardware tests, change orders, and manufacturing scrap.

The good news is that a set of practices called systems engineering addresses these communication problems. Systems engineering coordinates design across engineering disciplines, which leads to far fewer problems downstream.

While these practices are a boon to cross-disciplinary collaboration, technology has been slow to catch up. Without a new way to collaborate, engineers use tools familiar to them—spreadsheets and documents—to track things like the decomposition and allocation of requirements and definitions of functions. But they no longer need to rely on those outdated tools. In recent years, a new approach for working together and the technology to support it have sprouted. With model-based system engineering (MBSE), engineers can track system engineering requirements for the entire product and house them all in one place.

So which approach is best for system engineering—MBSE or spreadsheets and documents? This article will answer that question by defining MBSE, comparing it to the traditional approach to systems engineering, and looking at how it addresses systems engineering needs.

The Enabling Technology Needed for Systems Engineering

Before comparing and contrasting the technologies that enable systems engineering, it makes sense to step back and acknowledge systems engineering’s inherent needs.

Systems engineering gets all engineering disciplines involved with product design on the same page. Mechanical, electronic, electrical, software, and systems engineers themselves all need access to one single source of truth that defines a system. For collaboration, the technology that drives systems engineering must let all engineers access the design in real time. When many engineers are responsible for different aspects of product design, they can’t afford to get in line to access requirements, definitions, and allocations. For systems engineering to work, simultaneous, multi-user support is a must.

So is version management. With this many users, the definition of the system changes frequently. Version management tracks who changed what, when, within the systems management technology. Defining the product as a single monolithic whole doesn’t support version management.

Relationships between all the parts of the system and their engineering needs is key to systems engineering. The technology that enables systems engineering must be able to handle these many relationships. For example, high-level requirements are broken down into smaller, granular, specific requirements. Those requirements are then allocated to functions. Those functions are then assigned to items. Each of these things must be tied to the others. This linkage allows engineers who need to change a requirement to see immediately what items and functions the changes will affect. Likewise, they can see how changing a function changes all granular aspects of the requirements.

Spreadsheets and Documents: Desktop and Cloud

Let’s be clear: file-based spreadsheets and documents offer many benefits to knowledge works across a range of industries. Yet, they have some serious drawbacks when it comes to supporting multi-user collaboration and granular version control. The most obvious shortcoming is that each spreadsheet or document is a single file that can be opened by only one person at a time. Although, newer cloud-based spreadsheet and document solutions help address this problem.

But whether cloud-based or file-based, spreadsheets have another drawback: lack of granular version control. Each change is made to the entire design, not to specific functions or items or other granular aspects of the design. This means that engineers can’t go back and make a change to a single requirement but maintain all their other changes. The entire system is treated as a monolithic whole when a company uses spreadsheets and documents for collaboration.

Also, spreadsheet and document solutions are generic tools; they can’t encompass systems engineering approaches or processes. They don’t understand that a requirement is fundamentally different from a function. And yes, they can be programmed to include a limited form of traceability, but traceability programming is easily fractured and leaves a mess behind for engineers to fix.

Overall, spreadsheets and documents are poor solutions for supporting an organization’s systems engineering efforts.

MBSE Solutions

An MBSE approach places emphasis on both the whole system and the complexity in the interactions between its parts. MBSE tools create a digital model of the system that all engineers across disciplines can use, as can other persons within an organization. An MBSE model can also be used to simulate a system’s performance so engineers can understand how it satisfies requirements.

MBSE solutions were specifically developed to address the problems encountered when using spreadsheets and documents for systems engineering.

They don’t treat the system as one monolithic whole. These tools know what a requirement is and have all the information that defines it. The same is true of functions, items, and so on. They know how each of these different parts of the whole relate to one another. They know that sub-requirements are connected to higher levels, for example. They know that functions can be allocated to physical items. In other words, models bring precise semantics to the system definition, enabling enhanced management of systems' complexity and avoiding communication pitfalls.  

Furthermore, MBSE tools track changes very differently than spreadsheets and documents do. Instead, they treat each requirement, function, or item as an individual piece of the whole allowing a large number of engineers to collaborate simultaneously.

Some MBSE solutions are even process-aware. Best practices and engineering processes are built into the tool to lead engineers through a step-by-step process that eases their transition to a systems engineering approach. Tool-embedded practices and processes give engineers the information they need to do their job effectively. They also identify and manage all the data needed for a project, including milestones and reviews, and they provide traceability to facilitate meeting them. This set of capabilities, including embedded best practices, is highly beneficial. It addresses one of the biggest stumbling blocks of all technology-led initiatives: cultural change. Tool-embedded practices reinforce the processes and procedures that fundamentally make systems engineering work. Your organization's engineering capabilities are improved, so is your business by delivering systems that better match customer’s needs and with fewer defects.

Recap

  • Today’s products include electronics, electrical systems, software, and possibly even internet-of-things connectivity, so engineers from different disciplines now regularly work together on design.
  • A set of practices called “systems engineering” coordinates design across engineering disciplines.
  • In recent years, a new method of working together and the technology to support it has emerged: model-based systems engineering (MBSE). An MBSE approach places emphasis on both the whole system and the complexity in the interactions between its parts. MBSE solutions were developed specifically to address the problems encountered when using spreadsheets and documents for systems engineering.
  • With MBSE technology, engineers can track systems engineering requirements for the entire product and house them all in one place. And traceability and version control are included.
  • An MBSE model can be used to evaluate a system’s performance so engineers can understand how it would function if manufactured.
  • Implementing MBSE software gives engineers tools needed for traceability and version control and allows multiple engineers to collaborate on the system at the same time.
  • Some MBSE solutions are process-aware. Things like best practices and engineering processes are built into the tool to lead engineers through a step-by-step process to ease their transition to a systems engineering approach.


Felisa Zhang

Lead Systems Engineer (Manager 2) at Archer

4 年

I think this article completely missed the industry practiced in-between solution of using requirements based tool (not spreadsheet and not single documents) where you can track individual changes, have process follow, and identify multi-level requirements to go top down or bottoms up. Using requirements tool baselines is a convenient way to track changes and configurations. The real world solution is often a mix of requirements tool, model-based engineering design, and MBSE.

回复
Carsten Pitz

Not promoting techniques failing constantly.

4 年

Even though I also prefer the visual approach and also learned to like Capella in a real world project, I have to state > But whether cloud-based or file-based, spreadsheets have another drawback: lack of granular version control. Boeing Calc -- at least the MVS implementation -- featured a fine grained version control. But it is history by now. But nevertheless this example shows it is not a principle lack. BTW, DOORS is also more or less a server-based, multi-user spreadsheet and also features fine grained version control, baselines and the like. On Capella: I worked with Melody (the Thales internal Capella distribution) with Teams extension. Versioning was done on database level. Every 2h a database snapshot was created and exported as backup. And IMHO Eclipse Papyrus and IBM Rational Rhapsody feature much better versioning features.

回复
Andy Howells

Director EE Systems B-ON Automotive

4 年

Really good article with which I can relate. There is still a role for documents, presentations and spreadsheets but they are not the solution if you really want to collaborate and fully understand your system. Check out some of my presentations on how I have implemented MBSE into different organisations.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了