Model-Based System Engineering Archives

Tag Archive for: Model-Based System Engineering

In this blog, we recap the “Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?” webinar.

As products grow increasingly complex, many teams are asking themselves if they have become complacent in how we approach requirements management and the value it delivers.

Regardless of the industry, requirements are critical to a shared understanding of the solution. They provide the foundation for traceability and regulatory compliance across the product or software’s lifecycle. Many companies are finding that using IBM® DOORS® for requirements management limits their ability to lay that common foundation.

In this webinar, experts from Persistent Systems and Jama Software® will discuss issues and challenges around the continued use of IBM® DOORS® and show how adopting a model-based requirements approach enables best practices to realize greater value from your engineering initiatives.

In this session, we will cover:

An overview of why requirements management is critical
Common challenges and pitfalls companies face
Best practices enabled by a model-based engineering approach
The path to successful adoption, reducing migration uncertainty and risk
How to start your migration journey

Below is an abbreviated transcript and a recording of our webinar.

Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?

Richard Watson: Hi folks, my name is Richard Watson. I work with Jama Software. I’m a practice director with Jama. My history is around systems engineering. I’ve been a systems engineer, I guess, for about 30 odd years, mostly with DOORS and DOORS Next. So my previous role was the product manager of DOORS before I moved into Jama Software. I’m thrilled today to be joined by Kathryn Fryer. Kathryn works for Persistent Systems and she too has got about 30 years of systems engineering experience. And she and I worked for a long time together inside of IBM, working on both DOORS and DOORS Next Generation. We’re here today to talk about data model consistency, and perhaps migrating your data to a consistent data model. So we’re going to start with Kathryn. So Kathryn, over to you.

Related: Jama Connect® Solution for IBM® DOORS®

Kathryn Fryer: Okay. Thanks, Richard. So I just wanted to start, for those of you who might not be familiar with Persistent Systems, we are a global company, been around for actually about 30 years, over 700 million in revenue and that was a huge increase year over year. And if you move to the next slide, we cover many different industries and solutions, and we partner with many different companies, everyone from Salesforce to Microsoft, to IBM and Jama.

So with that brief introduction, let’s move on to the topic at hand and talk about requirements management and model-based engineering. So these quotes might be familiar to you, certainly, the sentiment that they convey is familiar, requirements management is key to the success of software and systems projects, and poor requirements management is the single largest reason for project failure. And the costs of failure can be billions of dollars or pounds or euros, the cost of product recalls, of missing regulatory compliance, and never mind as we get into some of these industries, the cost affecting human life. So I know you’re all familiar with that and you know how important requirements management is, or you wouldn’t be here today. So if we move to the next slide, Richard?

Related: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering (MBSE)

Kathryn Fryer: So what makes it hard? Why are we still talking about it? And there’s four CS here, I think I refer to them in the past as well. And I don’t think these are new, this list is familiar. This has been true for a number of years now, and it continues to be true. Solutions become increasingly complex. We have more components, more moving pieces, more integrations, more dependencies. We have more contributors involved in delivering the solutions. So we need to collaborate, not even just within your organization, across the teams in your organization, but across different suppliers and then their suppliers. We have these diverse engineering teams, diverse tools, diverse processes, and we need that collaboration, the handshakes, the clear handoffs, and the understanding of the context, there’s another C I didn’t put on the slide, and how all the things must work together.

We need to manage change. Change is the only constant, right? So we need to stay on top, not just of changes in our project, but also changes in technologies and changes in standards and compliance. Compliance seems to be growing and evolving all the time. The specifics are going to vary by your industry and by your geography, but compliance is necessary in almost every industry now, I think, and that’s only going to grow with things like AI and autonomous capabilities and all that fun stuff. So there’s lots of things that we need to deal with.

Watch the full webinar to learn more: Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?

With the trend of organizations practicing Systems Engineering to move towards what is referred to as “Model-based Systems Engineering” (MBSE), there are various perspectives as to just what is meant by MBSE. Similar to the old story of the blind men and the elephant, MBSE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice MBSE, wise systems engineers recognize and use each perspective as appropriate to their specific needs. Based on these needs, they choose the appropriate capabilities, tools, and visualizations that will meet their needs. One size doesn’t fit all.

The degree to which the data and information is captured and managed is driven by the needs of the organization and projects from a business and technical perspective based on the size and complexity of their systems, their product line, culture, processes, workforce, their diversity and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.

SysML and other language-based modeling tools

MBSE is a concept that is maturing and means different things to different people. To some practitioners, MBSE is equated to the use of SysML and other language-based modeling tools. With these tools, practitioners can develop detailed analytical, behavior, and architectural models of a system, with a primary focus of functionality, performance, and interactions between various entities defined to be part of the system being modeled. These types of models are useful tools for system analysis, developing simulations, and creating what is referred to as a “digital twin”.

To others, what they are calling MBSE is really Model-based Design (MBD). MBD design starts with a set of requirements and using various language-based modeling tools to architect and design a system, develop simulations to assess the behavior of the system, and then develop a set of design output specifications to which the system is built or coded. Often the MBD activities are completed in a silo separate from the other SE lifecycle process activities.

MBSE is much more than SysML!

The above language-based modeling approaches do not address the true intent of MBSE. While these capabilities can be useful, MBSE is much more than using language-based modeling tool to develop analytical, logical, behavioral, and architectural models.

The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) so as to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system life cycle process activities, resulting artifacts, and their underlying data and information.

MBSE is not really about any particular type of model or visualization of data and information – whether that be a model, diagram, report, document, sets of needs, or sets of requirements – but is about the underlying data and information model that enables consistency across the data and information that represents the various models and visualizations.

The data and information model that must be developed should represent SE artifacts generated during the product development process activities across all lifecycle stages. Information associated with the elicitation of stakeholder needs and requirements, lifecycle concepts definition, analysis, and maturation, deriving an integrated set of textual needs, transforming those needs into sets of textual design input requirements, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages, prove compliance with standards and regulations, as well as help assess the impact of changes made to any of the data items across all lifecycle stages.

Can my organization adopt MBSE without using SysML or other language-based tools?

Sadly, there are many organizations that have a misconception concerning what the true intent of MBSE is – as a result they think that MBSE is not for them.

In a recent conversation with a system engineer, I was told that her organization was not going to adopt MBSE because they don’t see the utility of developing complex SysML models of their products. In addition, she noted that to do so would require a change in how their managers and engineers think based on the SysML standard as to how to construct models and the specific terminology used. To them SysML modeling is not intuitive, has a large learning curve, and has little apparent utility and return on investment – for their organization, especially for their product line that has a minimum amount of software and complexity.

My response to her was: MBSE is not SysML!

I told her what the true intent of MBSE is to practice systems engineering with a data-centric perspective, establishing the capability to capture, manage, access data, and manage the interrelationships between SE work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map/index) of disparate data sources.

The resulting data and information model can be captured using a variety of SE tools and applications. To effectively manage our ever increasing complex, systems there are benefits to managing this underlying data and information in such a way it can be shared across the system life cycle process activities, shared between the various SE tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex systems as well as enable collaboration between not only the project team members, but also external stakeholders involved in the development of the system.

Parting Thoughts

The answer to the question: “Can my organization adopt MBSE without using SysML or other language-based tools?” is YES!

Since one size doesn’t fit all, an organization must assess their needs and produce an MBSE solution that best fits its domain, product line (degree of complexity), and culture. As a minimum, they need to establish a capability to define and manage needs, requirements, verification, and validation across the system lifecycle. These capabilities will allow the organization to build a data and information model of their products and systems engineering process activities and artifacts.

Based on these needs and desired capabilities, the organization can choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.

Stay tuned for more to come from Lou Wheatcraft in the coming months.

In January 2020, NASA reported that Model-Based System Engineering (MBSE), “has been increasingly embraced by both industry and government as a means to keep track of system complexity.”

And in order to help facilitate accelerated adoption of MBSE, we’re proud to introduce Jama Connect® for Companion MBSE.

Jama Connect for Companion MBSE is a single platform that combines requirements, architectures, behaviors, and V&V into a single model of the system by applying: structure for the data; rules for the data; and a consistent interface language between parts of the system. A Jama Connect model provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness.

Accelerate Your Systems Development

Jama Connect for Companion MBSE provides a path to companies embracing MBSE where the application of collaboration, modeling, and methods reduces time and effort across the lifecycle.

With this solution, you’ll get:

Framework aligned to industry best practices from INCOSE and SEBoK
MBSE Quick Start Guide
Document export templates and reports aligned with systems development
Standard features of Jama Connect including requirements management, test management, live traceability, review center, realtime collaboration, reuse & baseline management, workflow & configuration management, diagramming
Consulting and training customized to your teams’ MBSE processes

Download the solution overview to learn more about Jama Connect for Companion MBSE.

An organizational paradigm shift from document centric to model-based systems engineering can be daunting. The learning curve for systems engineers can be steep and the return on investment is often not immediately apparent.

In a recent workshop on MBSE adoption, we walked through how Jama Software for Companion MBSE can be used to eliminate common MBSE challenges and provide tactics to help teams eliminate the barriers to broader adoption. We will demonstrate how Jama Connect’s Companion MBSE can be used to streamline a collaborative, data-driven approach and provide more immediate systems engineering value to larger numbers of stakeholders.

In this demonstration, we cover:

Using Jama Connect to facilitate implementation of MBSE
Benefits of Companion MBSE to the broader stakeholder community
Keys to eliminating documents
Leverage OSLC and REST for Cross Tool linking

Below is an abbreviated transcript and a recording of the workshop.

In today’s hyper-connected world, we’re not only seeing increasing complexity of systems that are being built, but also experiencing increasing technological and sociological challenges in the work setting to develop those systems. Jama Connect helps address these challenges. Organizations can execute their MBSE journey without the headache of modeling languages or the licensing and rolling out of complex systems modeling tools.

Jama Connect for Companion MBSE is a completely web-based application that is designed to make it easy for any stakeholder technical or non-technical to create models, consume data and participate in a collaborative systems engineering process. The Companion MBSE template comes with data types to capture and segregate different types of requirements, behaviors, architecture, interfaces, and V & V data. It also has a structural template already laid out to organize the data and help users get started quickly.

We’re going to cover using Jama to facilitate that implementation of MBSE, then we’re going to talk about keys to eliminating documents. We’ll look at how you can leverage OSSE and rest for cross tool linking. And we’ll talk about the benefits of Companion MBSE to the broader stakeholder community model based systems. Engineering is more than a modeling tool. It is not simply a tool but a process that demands change to take place, not only at the systems level, but at the project and program levels.

RELATED: Getting Started with Model-Based Systems Engineering (MBSE)

Document centered thinking and business practices needs to change at all levels in order to not only deal with system complexity, but to also become more agile organizationally, but leaping to a purely SysML tool is not a leap every organization is mature enough to tackle. MBSE is not all only about moving from document centric to a model. It’s also about being able to communicate the clarity that the modeled information gives to the stakeholders on other teams, whether that be at the implementation level or the program or customer level.

The first step every organization can take is to become more information centric. Our Companion MBSE is designed to do just that. Under the hood, Jama Software’s Companion MBSE is composed of an easy to navigate structure for the data. Automatic version control of the data and baselining, a model language, a diagram editor, a workflow engine, a collaboration engine, document import and export and model integration with wide varieties of tools in your ecosystem like other SysML tools, test execution and more.

Companion MBSE is pre-configured with a meta-model that govern which elements were allowed to be connected together. And which type of TraceLink names are used when elements are connected. For instance, a need can be related to a validation test and its relationship name is validate. A system requirement can be related to a system architecture block and its relationship name is satisfies. Jama Connect automatically chooses the correct relationship name for the user. Users do not need to know any syntax or language.

They just associate one element with another and connect a prize applies the pre-configured trace rules to those elements. You can also easily extend these data element types and relationship names by creating your own. There are distinct benefits from moving away from a document centric to information centric paradigm. Discrete item types, and link names, make it easy to analyze and query the model. Teams using documents, wikis or legacy tools often go through a manual process to relate all that data together, which can be error prone, introduced inconsistent data, or when performed after the fact yield stale inaccurate data.

RELATED: MBSE Tool Maturity – Where does your organization stand?

Jama Connect lets you surface in real time data and display it on the model dashboard. Dashboards can be a central place for any stakeholder technical or nontechnical to come away with an understanding of the current status of the systems engineering effort. Let’s take a look at Jama in action. So I’ve opened up my model, my model essentially is just a Jama Connect project. We have the building blocks of a structure. So on the left, you see the structure of the model, all the different types of data types that we’re collecting in this model.

The thing important data types that we have that come out of the box with Companion MBSE are our needs. So a need item type, that’s where you would capture, you would use this type of element to capture a stakeholder need or an expectation or a requirement. Some regulatory requirements or things like that. Then we have a system requirements. So we’re segregating different types of requirements. System requirement has its own object. So you can demonstrate traceability between the need. So if you have customer requirements that are coming in as need as a need, you can really easily demonstrate that traceability.

We have a third requirement item type is a subsystem requirement. You are not constrained to use our specific nomenclature. You can extend these item types. You can rename them as well. We also then have a use case type. So, this particular use item type in Jama Connect is used to capture textural based more traditional use case flows in a more verbal textural. We also have that the capability to more granularly define the elements within a use case. So if you have actors, if you have different states or activities and you need to granularly break those out of a textual use case so that you can trace them in some way you can do that.

We also have a part. A part is more like a SysML 2.0 construct where a part might be used to capture structural elements, such as system architecture elements, or function blocks or physical objects or abstract objects. We have the capability to capture an interface as well as various different verification validation objects. So we had Jama segregate, verifications and validations. So it’s really easy to demonstrate that you have done both verification and validation of the objects. The model and the other types are extensible. So while the Companion MBSE comes with just a handful out of the box, the ones on the top, you can create your own additional ones to add to your model and extend it for your specific needs. And you can also rename things.

So if you don’t call something a subsystem requirement, maybe you call it a component requirement, or maybe you call it a software requirement, or maybe you even call it a user story. You can rename things as well. Now, Jama Connect does come with a method, we call it our Companion MBSE method. It’s a top-down approach top down where you have at the most abstract within my model, I have my needs but it supports analysis, design and specification. And it starts off with a needs analysis. So, when I want to look at my needs analysis I can click on something in the tree and then it shows in context in the main area of the system.

Now my needs analysis I’m capturing each need as an individual item, typically like you would in a spreadsheet. So I could look at the different views of the needs, whether I have a spreadsheet view or a rich text view. Our diagramming capability is built right in as well. So, when you want to communicate more clearly to your audience a diagrammatic expression of your needs users don’t have to go to external tools. You don’t have to go to a modeling tool per se, but you can build those diagrams right here in Jama.

You want a Companion MBSE is designed for anyone to get started with your MBSE journey and then bringing in and marrying up diagrams right here in the context of the needs is a really powerful thing. You don’t need to be an expert to know how to draw boxes and lines and add textual information to communicate the information that you need to your audience. You also have the ability to do the collaboration that Jama is really famous for. So, if I need to bring people in to look at this particular diagram, we have the capability to add that comment even use at mentioning. So, if I wanted to add, mention a coworker, I can just mention their name.

Can you verify whether we need the X, Y, Z and the act that the comments within Jama are actionable? So it’s not a static comment but I can tell Alex, Hey, I need you to answer this question specifically, or maybe I’m just a read only user of this Jama model, and I’m looking at something and I want to raise an issue, or they be an engineer and I need someone to make a decision about something I’m unclear. I need some direction, just help me make a decision about that. Under the covers comments go into people’s email, they can reply back through email. They can answer questions, or they could click on the link in that email that would essentially take them right to this context, and then they can answer back.

So now we can have that sort of a conversation live captured part of the auditable trail and bringing more people into participate. If I wanted to, I could have even had mentioned my customer by just putting in their email address, and then my customer could have replied back to the comment thread. Well, it’s all about having more people being able to participate in the MBSE process.

Watch the full training to learn more about overcoming barriers to MBSE adoption.

Have you ever heard the saying that a systems engineer is the chief cat herder? Have you as systems engineer ever been branded as the person who asks “Why?” all the time? A systems engineer often perceived as the person that says, “Why do you need that? No, that won’t work. No, that is out of scope.” All systems engineers want to say “yes” more often. Systems engineering is a reductionist discipline so saying yes is often difficult. But perhaps systems engineers get a bad reputation because stakeholders cannot “see” the same things as the systems engineer and information is not getting communicated clearly. If your organization is trying to adopt a model-based approach to systems engineering (MBSE), then a SysML model might be too intimidating for most to interpret and consume which could result in even worse communication with the broader stakeholder development team.

A transformative systems engineering practice lets the data do the talking to stakeholders. It enables its data to be easily consumed and understood. As a tool vendor I spend a lot of time talking to all kinds of customers that are in various stages of maturity. One common theme I hear from systems engineers is that they can’t get people to look at their data. They are always asked to provide a document or slide or walk them through the model. The systems engineer then ends up spending far more time working as a librarian and tech writer.

If you aren’t already doing good SE then MBSE with a SysML tool might not be the answer. The SERC study shows an overwhelming measure of lack of value and adoption of MBSE (check my previous blog here). It is my belief that organizations should not be using their SysML tool to perform the functions of requirements management, management of verification and validation, or change and configuration management of this data.

Jama Connect® for Companion MBSE is designed to make it easy for non-systems engineers to consume data and participate in a collaborative, systems engineering process. It provides familiar navigation and views of data along with an industrial-grade configuration management and a workflow engine at its heart. Actionable collaboration at the element level provides a thread of decision points and audit trail of who said what and changed what. It enables real-time collaboration, no waiting for publishing of a model file or meeting date for a design review. Actionable collaboration means comments on elements can be framed as questions, issues, or decision requests. Discussion for each comment is threaded and its status can be queried. Comments can optionally trigger notifications when @mentioning users or groups. Users don’t need to leave the element in the model they are working on and use an external email or collaboration tool get input from additional stakeholders since you can just add their email address to the comment.

RELATED: Getting Started with Model-Based Systems Engineering (MBSE)

When getting started with your system model, a Companion MBSE template can be used where systems engineers and stakeholders can begin entering data. The Companion MBSE model provides a starting point with pre-configured types to capture and segregate different types of requirements, architectures, behaviors, and V&V objects. The types can be tailored where you might add additional fields to capture various attribute information or even enable a workflow to display lifecycle state information.

The Companion MBSE template also comes with a structure laid out to organize the data. The structure is easy to navigate by opening the nested hierarchy. The highest level of abstraction is at the top of the tree and subsystem/component level data is nested below. This specific data organizational approach is not only an aid to users who want to understand the breadth of an entire system but is also present to facilitate reuse strategies for parallel development, variants, or product lines.

A Jama Connect model is like a chameleon. It can appear to users like a familiar document, or it can be browsed and consumed as just data to provide the best of both worlds. For those stakeholders who still need a document, the data can be easily annotated with textural information to capture relevant background information. The data can also be organized under section headings. This data driven approach makes it easy to segregate data from background information. Views of the information can easily be switched from a rich contextual view containing both background info, section headings, and data; to a view that just displays the data elements alone (i.e. requirement statements, block names…). These built-in views make it easy for any type of stakeholder to read and understand what they are looking at and saves the systems engineers lots of time doing that librarian/documentation work.

Jama Connect does not limit modeling to just creation of elements but provides these mechanisms for textural and section headings to be applied to architecture, interfaces, behaviors, and V&V elements. Model documentation is captured right here and does not need to span to other tools. The rich text editor lets the user format text, add tables, bullets, insert images, or enter formulas. The built-in diagram tool is where model diagrams can be constructed. Users aren’t required to know a modeling language and can add descriptive to and annotate the lines between the elements in any way they choose.

RELATED: MBSE Tool Maturity – Where does your organization stand?

For those that are used to capturing architectures in documents, it might seem attractive to use an issue tracker or wiki like Atlassian® Jira® and Confluence®. These tools are not model-based and offer only the most rudimentary of links. Connect lets you capture functions, blocks, behaviors, requirements, and individual elements in the Connect model. Each element can have a rich descriptive area and fields configured for commenting, relationships, and workflow. They can be viewed in list form, in the tree, or as documents.

Jama Connect for Companion MBSE provides easy ways to associate relationships between different objects. Companion MBSE is pre-configured with a schema and naming syntax that govern which elements are allowed to be connected together and which type of trace link name us used when elements are connects. For instance a Need can be related to a Validation test and its relationship name is “validates.” A system requirement can be related to a system architecture block and its relationship name is “satisfies.” Jama Connect automatically chooses the correct relationship name for the user. Users do not need to know any syntax or language; they just associate one element with another and Jama Connect applies the pre-configured trace rule constraint to those elements.

This data-driven approach using a combination of textural model elements and diagrams makes it easy for organizations to participate directly in MBSE activities; share systems engineering data with broader audiences; and report on progress. Discrete item types and link types make it easy to analyze and query the model. Teams using documents, wikis, or legacy tools often go through a manual process to relate all the data together which can be error prone, introduce inconsistent data, or when performed after the fact yield stale, inaccurate data. Connect lets you surface in real-time data and display it on the model dashboard. The model dashboard can be a central place for any stakeholder, technical or non-technical, to come away with an understanding of the current state of the systems engineering effort.

Award-winning ease of use and built-in collaboration mechanisms combined with our approach to MBSE give both MBSE mature teams and teams new to MBSE the ability to deliver high value systems engineering. Systems engineers will find it easier to say “yes” and cat herding will be more of a delight than an act of hide and seek.

For companies building complex systems whose stakeholders come from diverse engineering and business disciplines and need to have very precise and efficient communications, Jama Connect provides a collaborative, 100% web-based MBSE platform and a proven systems engineering approach to product development. Jama Connect provides a path to companies embracing MBSE where the application of collaboration, modeling, and methods reduces time and effort across the lifecycle. We call that path Jama Connect for Companion MBSE.

Jama Connect for Companion MBSE is a single platform that combines requirements, architectures, behaviors, and V&V into a single model of the system by applying structure for the data; rules for the data; and a consistent interface language between parts of the system. A Jama Connect model provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness.

MBSE Defined by Industry

The International Council on Systems Engineering (INCOSE) describes MBSE as the “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through-out development and later lifecycle phases.”

NASA says MBSE “involves applying software-based tools to capture systems engineering evidence—typically called “artifacts”—in a systematic, disciplined way that allows people to manage complexity while communicating effectively across the life cycle of a system.

What is a model? Don’t be fooled.

It is a myth that a system model can only be created in a UML or SysML tool. Models can be expressed texturally, mathematically, visually, or physically and are meant to assist in helping people look at problems from different directions. Jama Connect represents a model as a project containing textural data items, views, graphical diagrams, and collaboration content.

NASA’s definition provides a good deal of information, but they don’t even use the word “model” in their description. Lenny Delligatti, one of the most respected MBSE experts in the world wrote that, “A modeling method is something like a road map; it’s a documented set of design tasks that a modeling team performs to create a system model. More precisely, it’s a documented set of design tasks that ensures that everyone on the team is building the system model consistently and working toward a common end point. Without such guidance, there will be wide variance in the breadth, depth, and fidelity that each member of the team builds into the system model.”

For example, a switch in a system is expecting the command “On” but for some reason receives the command “Start.” The switch will not function. The “On” and “Start” is the communication language and must be consistent.

What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system” and INCOSE defines a model as “a simplified version of a concept, phenomenon, relationship, structure or system.”

Before the invention of SysML, we used to use a document called an “Interface Control Document (ICD)” to describe the syntax of interfaces between different parts of a system, often physical. While essential, the ICD lacked the ability to describe scenarios which the interfaces would be used for. While a SysML model allows for communication of scenarios to be documented, it often lacks the ability to communicate the depth of requirement needed to describe the core workings of each part. This puts a heavy onus on the verification needed to ensure a part on its own was working as intended.

While SysML is a wonderful language to represent abstractions and there are some fine tools out there that let you do some powerful things (I want to say something different here); it is still immature in the core aspects of systems engineering as it relates to communication, cross-domain collaboration, project management including cost and schedule, and oversight of verification and validation activities to name a few.

RELATED: MBSE Made Easy – Overcoming the Organizational Challenges

Jama Connect for Companion MBSE – The Nuts and Bolts

MBSE in simplest terms is a framework for problem solving and system expression. In traditional systems engineering the domains of requirements, architectures, V&V and behavior are recorded and analyzed in a series of documents or data structures with loosely connected affiliations. Our Companion MBSE combines these four domains into a single model of the system by applying: structure for the data; rules for the data; and a consistent interface language between parts of the system, which in combination we at Jama Software call a “framework.” The framework provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness.

The Jama Connect for Companion MBSE framework takes requirements, architectures, behaviors, and V&V and forms their data into a query-able mesh. As development progresses the mesh becomes more stitched together. A built-in ruleset that uses a consistent language, constrains users to create the correct associations between the data elements. The framework’s ruleset eliminates risk that manual methods or tools lacking these constraints introduce. Jama Connect for Companion MBSE also supports leveling – representation of system decomposition within a model. Each successive level will follow the same consistent ruleset.

Visualization is an important part of Jama Connect for Companion MBSE and plays a major role in communication of information and ideas. Data is easily visualized in an easy to navigate hierarchal tree view. This view not only displays the content of the data but also how the elements are tied to each other. These structures can be represented visually as a series of diagrams within the model.

Requirements

Requirements are typically the first data elements to be worked on in the model. Jama Connect for Companion MBSE’s flexibility gives users the ability to define unlimited levels of requirements – even those considered outside the “system” level. A Need Requirement which is an input to the systems engineering process, might consist of multiple types such as: user needs, ConOPS, business requirements, mission objectives, goals, regulatory requirements, or even constraints to name a few. A needs analysis is performed to flesh out those requirements which are human-centric. Systems engineers will analyze all the broad and at times abstract needs and then refine them into system level requirements that are representative of the system and might describe all the functions that the system shall deliver as well as non-functional characteristics such as performance or reliability of the system.

In Jama Connect each need and system requirement is captured as a unique entity with its own ID. As a single entity it can then be managed, version controlled, and linked to other entities. When using Jama Connect for Companion MBSE framework, it provides mechanisms that keep needs and system requirements appropriately leveled and describe how they are linked to each other. This link itself also has a name and is called “derivedReq” which is similar terminology used in the SysML language.

Behaviors

Behaviors assist the systems engineer in identifying the functions, sub-functions, and interactions that the system performs. Behaviors can be elicited from needs and requirements through techniques such as use cases, activities, states, interactions, sequences and more. Behaviors are most often in the form of a verb (ex: regulate voltage, make deposit, heat water, charge controller, brake…). Capturing behaviors adds value because they help explain how the system will work and sometimes more importantly, what could go wrong. Behavior can assist in establishing the cost and complexity of the system. Functions can be analyzed and become a deciding factor for which requirements are then used to build the system.

In Jama Connect behaviors can be richly annotated so one can capture the full reasoning. This is extremely useful to stakeholders that are not necessarily modelers yet need this information to make informed decisions.

Architecture

Application of MBSE is not complete without tying in architectures and making them be a central point of data. Architectures can be defined to conceptually represent functions of the system, structure of the system to subsystems, physical components of the system, or even behaviors of the system. An architecture is organized so that its own structure conveys meaning and relationships between its members. In Jama Connect, architecture objects can be managed as discrete elements where relationships to other data such as requirements can be made. It is also possible to create diagram to illustrate the relationships between the elements.

V&V

The verification and validation of the model and its entities within it is the last major domain for MBSE. Any element defined within the model can be verified or validated through means of analysis alone, review, trace demonstration, or even by test execution collecting pass/fail status. An MBSE model

Jama Connect for Companion MBSE tests and validates system characteristics early with engineers and stakeholders for fast feedback on design decisions and phase it is believed that this will:

Predict performance
Verify design choices
Meet stakeholder expectations
Avoid failures
Reduce risk

Visualization

Visualizing the model is an integral part of MBSE. As maturity of stakeholder’s fluency in MBSE increases, reliance on heavy text in some areas will decline. Jama Connect facilitates the best of both worlds by providing fully textural representations of data as well as diagrams that can easily be annotated to describe the purpose behind the “line” the connection between two objects.

Why Jama Connect for Companion MBSE?

The inefficiency of non-integrated data leads to wrong decisions. When MBSE is done properly, the result is an overall reduction of development risks. Jama Connect for Companion MBSE provides a flexible framework that is 100% web browser based for capturing and communicating the model to all stakeholders. The model can be queried programmatically to surface up gaps in the model, display progress information, and be validated against the rules of the framework. These rules enforce users to create and relate data in a consistent way. Jama Connect for Companion MBSE gives users easy graphical and textural views of information in real time and is structurally SysML ready if mature organizations wish to integrate Jama with these specialized tools. Most importantly, users do not need lengthy indoctrination into the semantics of modeling which is required for modeling tools. Jama Connect as a data-centric tool, does not have this barrier and so is much easier for every stakeholder to adopt.

Last month we held a webinar on model-based systems engineering titled, “MBSE Easy, Overcoming Organizational Challenges.”

This webinar was well received by our customers, and we wanted to make sure nobody missed out on this great content. Below, you’ll find a recording of the webinar and an abbreviated transcript.

Shifting to MBSE is an Organizational Paradigm Shift

An organizational paradigm shift from document-centric to model-based systems engineering (MBSE) can be daunting. The learning curve for systems engineers can be steep and the return on value is not often immediately apparent. In this webinar, I will explore some of the most common MBSE challenges and tactics to help teams eliminate the barriers to broader adoption. I will also illustrate how Jama Connect can be used to streamline a collaborative data-driven approach and provide more immediate systems engineering value to larger numbers of stakeholders. The agenda topics that we’re going to go over today are benefits of MBSE to the broader stakeholder community, best practices for cultural adoption, the expected return on value, keys to eliminating documents and then using Jama Connect to facilitate the implementation of MBSE.

The Benefits of MBSE – Specifically Human Understanding

To help us understand the benefits of MBSE to a broader stakeholder community, let’s talk about what it is used for. MBSE in the words of industry leaders like INCOSE, NASA, or Gartner Research describe it as “facilitating understanding or providing aid to decision-making, connecting system relationships, controlling system configurations, providing communication of an overall system picture that’s accessible to all.”

It ensures everyone is working on the same up-to-date material at all times. I see a theme here. Many of these are very human-centric. MBSE is designed to take that complexity and allow it to be consumed and understandable by everyone. From a technical standpoint, configuration control, versioning, relationship management are some of the keys. Why MBSE? Human understanding, decision-making, relationship management, configuration and version complexity management are just not things you can easily achieve when you mire yourself in documents.

RELATED: Strategies for Remote Engineering Teams

The Limitations of a Document-Centric Approach

In a document-based world, engineers might be manually searching documents, manually managing a section number heading scheme in the document, it might be creating siloed trace information and spreadsheets. They might not know where the latest version of a particular document is or who might have even changed the document last. They might be relying on a single person who is the tool guru because the tool is old and too hard to learn how to use. They might be spending hours or days cross-referencing many data sources just to determine an impact change or consider a trade-off. Here we are in 2021 and still, so many of us are kind of swimming in the sea of documents. Mechanical engineering, electrical engineering, and even software engineering, these disciplines have been using models for decades, right. Now, having the best information at the system level is critical. What we need is a paradigm shift away from documents and a shift in the way you think.

The Benefits of MBSE for the Broader Stakeholder Community

The benefits of a paradigm shift from documents to data that MBSE brings is not merely for the systems engineer to reap. The new ways of thinking about the system being developed and the new structure of the data itself benefits everyone. I’d argue that the system view is the most important view of all. I think most of you are systems engineers out there and I think you tend to agree. MBSE allows engineers to work successfully at greater levels of complexity. It also improves the communication between the technical communities as well as the business and even the customer. It provides visibility of the gaps that you might have, errors, misalignments of the system design — those kinds of problems might result in defects in the system or cause design rework or cause missed requirements or even dropped requirements. Some of the MBSE challenges — there are challenges out there with adopting MBSE.

RELATED: MBSE and The Digital Thread

The Unique Challenges of MBSE – And Tips for How to Solve Them

The benefits that MBSE promises do present some of these unique challenges to those who are beginning their MBSE journey. The learning curve can be steep. Learning the language of SysML and maybe your chosen modeling tool takes a long time. This learning curve can’t be done in silos or via tutorials. The learnings need to be backed by your experience. Organizations need to adopt strategies for not just how their systems engineers are trained but how they will use MBSE and then how they need to adopt strategies for how the entire organization works and communicates in that paradigm.

Overcoming Organizational Resistance to Change

Organizational changes are often met with resistance to change. Change has to start at the executive sponsorship level. I think that goes without saying — any organization adopting any kind of change really needs an executive sponsor. That executive sponsor needs to demonstrate their leadership with their actions. MBSE lip service won’t work. They have to be involved and they have to demonstrate that they’re willing to make the changes themselves.

MBSE isn’t necessarily a one-size-fits-all either. The method and extension of the methods needs to be adapted to the actual system of interest that’s being developed. Systems also need to be developed with modularity and reusability.

RELATED: Jama Connect in the Digital Engineering Ecosystem

Misaligned Teams and Overcoming Boundaries

Many of the challenges to adoption are human factors and they might be the easiest to mitigate by perhaps simplifying your tools and your approach. Misaligned teams struggle to overcome those cultural boundaries to develop the services and products. MBSE is not something that just the systems engineering team does but it’s a technique. It’s similar to the Agile method, it’s something that the entire organization embodies. It requires that change in culture in order to adopt.

Moving from a documents-based approach to MBSE doesn’t have the be daunting. Start small. Put aside doing day-to-day work in the documents and have everyone across the team access data in your chosen MBSE solution. Even if you don’t have a dedicated SysML tools, you can perform MBSE by creating lists or drawings that capture architectures and behaviors.

In many cases, it takes time to fully adopt MBSE and engineers might feel insecure. Moreover, implementing MBSE is not about just using the tool, it’s about understanding what to model, why, and for which outputs. Again, that comes with experience. Don’t bite off more than you can chew. Don’t just roll out your SysML tool and expect to be doing MBSE. That just doesn’t work. Try to leverage web-based tools that provide more stakeholders a consumable view of the information that maybe they would regularly see in documents.

If tools are becoming your focal point, make sure that they are usable and do provide value across the teams. Communicate the MBSE return on value to them. Communicate the return on the value back to your leadership team. Systems engineering, unlike software or electrical or mechanical engineering doesn’t have that output that’s tangible to the customer. Leaders need reminding of the value that MBSE is delivering.

Download our new whitepaper, A Path to Model-Based Systems Engineering (MBSE) with Jama Connect, to learn more about digital engineering & MBSE benefits, obstacles, and success factors.

DOWNLOAD NOW

The Digital Engineering Transformation

In today’s age of digital transformation, most product development teams are experiencing an issue of burgeoning software content causing immense effort and complexity to understand, write, design and validate, and produce. Digital engineering (DE) is a broader movement that takes shape in many industry segments such as medical device development, automotive, defense, consumer electronics, and aerospace to reduce the pains of developing new products, systems, and software. But, differences in maturity and methods sometimes make understanding the true state of DE difficult.

DE is an integrated approach that uses authoritative sources of system data and models (instead of documents) as a continuum across disciplines to support lifecycle activities — from concept through disposal. In the simplest of terms, it is the act of creating, capturing, and integrating data using models and innovative technology in an orchestrated manner in order to unlock greater value and provide positive impacts on cost and schedule. It is the system model for which MBSE is useful.

When developing avionics weapons systems, a document-based systems engineering process is inefficient and lacks an authoritative source of truth. Meeting the demands of modern development allows more teams to be connected to the design and engineering process. This allows everyone to have a clear understanding of the big picture and leads to better informed decision making, enhanced communication, increased understanding of and confidence in the system design, and a more efficient engineering process.

Meeting Market Challenges and Managing Complexities with MBSE

Model-based systems engineering (MBSE) has been a popular topic in the systems engineering community for over a decade, but the level of movement or path towards implementation has not always been clear. Market forces are increasing the demand and urgency for organizations to implement the MBSE discipline across the enterprise.

Across industries including aerospace, transportation, industrial manufacturing, and healthcare, customer demand for new, complex, and interconnected products, systems, and software is ever-increasing — and these systems must now be smarter, safer, and more environmentally friendly — all while remaining affordable.

For teams using a cumbersome, and often disparate document-driven approach, facilitating a common understanding of complex systems across diverse stakeholders can often be problematic. To stay competitive, companies building these complex systems require a solution that reduces time and effort by providing an MBSE approach where the combination of collaboration, modeling, tools, and methods streamlines the end-to-end systems engineering process.

A good MBSE practice will prevent rework due to poorly developed requirements or lack of communication across engineering teams. It will help to eliminate risks by providing an architectural roadmap that makes it easier to visualize and provide validation checks.

Customers will be happy with the system delivered and report fewer complaints because the application of MBSE has enabled the teams to more easily perform requirements analysis and validation to ensure that what is being designed and built is solving the correct problems that the customer has.

To manage increasing complexity, engineers and stakeholders must use tools (like Jama Connect™) and techniques whose data is both human-readable and has the capability to integrate across the ecosystem. The challenge is having the ability to efficiently design and build as well as effectively collaborate across stakeholders with vastly different engineering disciplines (e.g., software, mechanical, materials, electrical, chemical, environmental). Each subsystem needs to interoperate with the others to achieve the expected system function, adhere to safety and/ or government regulations, and ultimately meet the customer’s requirements.

Download our new whitepaper, A Path to Model-Based Systems Engineering (MBSE) with Jama Connect, to learn more about digital engineering & MBSE benefits, obstacles, and success factors.

DOWNLOAD NOW

As we enter a new decade of technological advancements, Jama Software asked select thought leaders from various industries for the trends and events they foresee unfolding over the next 10 years.

In the second installment of our 2020s Predictions series, we’re featuring predictions from Dirk Zwemer, President at Intercax, a global innovator in the field of model-based systems engineering (MBSE).

Jama Software: What are the biggest trends you’re seeing in MBSE right now and how are they impacting product development?

Dirk Zwemer: The biggest trend we’re seeing is the growing realization that MBSE is not a function of any one software tool, not PLM, not SysML, not requirements. The goal is the Digital Thread, the complete set of domain models organized, connected and version-managed in a way that allows everyone on the development team to find the data they need to do their jobs. Each discipline and each organization have a seat at the MBSE table (Figure 1).

MBSE Model-based system engineering and the digital thread

Figure 1 Seats at the MBSE Table

Implementation of the Digital Thread is still incremental in every enterprise. Early adopters look for specific integrations that enhance collaboration between team members, speeding completion of tasks and reducing errors from domain model inconsistencies. As they implement the Digital Thread more fully, they realize even greater gains in model validation and verification, which allows deeper exploration of the system design space within project schedules.

JS: What are some continuing or new trends in MBSE you expect to see over the next decade?

DZ: First, the engineering software tools and the Digital Thread infrastructure that connects them are all becoming scalable enterprise applications, sharing services and data either in the cloud or in on-premises servers. Standard interfaces such as RESTful or OSLC APIs will help support this, but the great heterogeneity of data, models and use cases will handicap approaches that restrict themselves to these technologies.

Second, no single MBSE methodology will be universally adopted, so flexibility in searching, visualizing, and documenting the Digital Thread will become important. Tools with a “one size fits all” interface will be at a disadvantage relative to open source, open standard and third-party components that can give users the reports and metrics they need with minimal effort and cost.

Third, MBSE is moving downstream through the system lifecycle. The Digital Thread will cover:

Conceptual Design → Detailed Design → Manufacturing & Logistics

With respect to tool integration, this will initially involve:

SysML → PLM → MRP

And we can expect to see increasing activity on this bridge. The advantages of devops processes in the software world will be increasingly obtainable for cyber-physical systems, as well.

JS: What sorts of process adjustments do you think development teams will need to make to accommodate these changes?

DZ: Practicing good data governance will be the biggest adjustment for most development teams building the Digital Thread.

Cybersecurity will be an immediate concern. With the rollout of CMMC v0.6 (Cybersecurity Model Maturity Certification), DoD contractors, primes on down, will need audited cybersecurity practices to compete for government contracts starting in 2020. Information sharing will be particularly impacted.
While cybersecurity is nominally concerned with preventing access by bad actors, information access by collaborators is also an issue. Process teams will look for ways to selectively share data, e.g. between customer and supplier, that prevent the partner from accessing deeper levels of proprietary technology.
If the Digital Thread shares information between repositories, process teams will need to explicitly define data ownership, i.e. which repository is master, and processes for data comparison, notification, and update.
All these adjustments will be easier if the enterprise adopts standard, well-documented authentication mechanisms. In too many organizations, these have grown ad-hoc, different for each repository, and with no central management or knowledge base. Implementing the Digital Thread in such environments will prove frustrating, so common authentication protocols will be needed.

JS: What do you think will remain the same in MBSE throughout the 2020s?

DZ: While not absolutely necessary, architecture modeling will remain an important part of MBSE and SysML will remain the dominant architecture modeling language. The SysML v2 Submission Team is working under the auspices of the Object Management Group to keep SysML relevant, with a final submission target of June 2021. Proposed changes will make SysML more precise, intuitive, and reusable, especially in the area of modeling usages and variant designs. A new underlying metamodel and a companion standard for SysML API and Services will open new opportunities for model creation, management and visualization. Together, these new features should broaden the reach of SysML across the development team while reducing the barriers of learning new tools, terminology, and notation.

JS: Anything else you’d like to add?

As new MBSE adopters flood the market and existing users refine their processes, the “Voice of the Customer” will be heard louder than ever. Buyers will want tools that are easy to use, cost-effective, and customer-configurable rather than vendor-customized. There will be plenty of opportunities for newer vendors that can meet these needs.

To learn more about the growing number of organizations adopting product development solutions to manage the complexity of connect systems, download our eBook, Your Guide to Selecting the Right Product Development Platform.

Systems are getting more complex, from autonomous vehicles to smart energy grids to the Internet of Things, and systems engineering must keep pace.

Creating and testing physical prototypes is too expensive and time-consuming in many cases. Systems must rely on digital models until the final stages of development. But this raises a new challenge: with so many digital models in use, how do the systems developers keep them consistent and use them together effectively?

The requirements for a new class of digital frameworks for Model-Based System Engineering (MBSE) are becoming clear, and here are seven examples.

MBSE supports a single, digital model of the system, the Total System Model (TSM)

MBSE replaces document-based systems engineering, where communications between engineers and models in different disciplines are by emails, slides or spreadsheets.

Federation, not centralization, is the most practical strategy for building the TSM

Few organizations want to replace all their existing software tools for requirements, architecture, design, analysis and project management, or try to centralize all system data into a single database.

Federation calls for most of the system data and engineering efforts to remain invested in existing tools, but an MBSE Platform connects them. No single tool is indispensable or the hub for all connections.

The MBSE platform will be an enterprise application

Systems engineering isn’t just for systems engineers anymore. The functionality to create, use, query and visualize the connections between model elements in different tools should reside in the cloud or an on-premises server.

It should also be available to all the members of the project team, through a variety of portals: computers, tablets and even smart phones. It must also be scalable, with rapid response times, to the largest projects with millions of elements.

The MBSE platform supports the full system lifecycle

The platform must support the entire system lifecycle, creating a digital thread from design to manufacturing to operations.

Connecting design data to manufacturing, quality, logistics and field deployment data provides traceability and better diagnostics. It also requires that the TSM be configuration-managed, just as many of the individual domain models are.

The MBSE platform must be methodology-independent

The platform should not enforce a specific workflow, so it should support multiple use cases.

These include connections that link disparate elements in different tools, and model transformations that share information across domain boundaries. It also implies the ability to program the platform through user-written apps and scripts to support any particular organization’s engineering processes.

The MBSE platform should make the system engineer’s job easier

This includes the ability to make connections automatically under rule-based guidance.

It should also provide the ability to identify and evaluate the impact of extended chains of connection — the “line of dominos” effects that systems engineers are particularly responsible for. This requires powerful visualization and pattern-matching algorithms to pull the key factors out of the mass of data.

The MBSE platform should protect proprietary information

Sharing data across organizational boundaries is rarely just a technical problem. The platform should respect the access constraints of the individual repositories and control sharing through mechanisms like common models that show only the data that each side has decided to share, but are linked to, and updated by, the hidden models on both sides.

The adoptions of MBSE integration approaches like those described above have implications for individual engineering tools themselves. In this environment, success engineering software tools will be:

Enterprise applications with robust, standards-based APIs
Specialized, doing a few things with excellence rather than trying to do everything

Dirk Zwemer is President of Intercax, which is pursuing the vision discussed in this article with Syndeia — from the Greek roots for “the practice of bringing things together.” It connects model elements in a range of engineering software tools, including Jama Connect™, in a vendor-neutral framework and applies modern graph theory and technology to the challenge of visualizing and querying large systems models. Just released, Syndeia 3.2 takes important steps toward a robust server-based enterprise application and greatly expands the range of users and use cases supported. To learn more, visit www.intercax.com/syndeia for more detailed information and video demonstrations.