Tag Archive for: MBSE

MBSE

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.


RELATED: How to Realign Engineering Teams for Remote Work with Minimal Disruption


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

Digital Engineering

Digital engineering is an integrated approach that uses authoritative sources of system data and models 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. This integrated approach means that the data from the digital models such as CAD models, electrical circuit models, system models, and software models as well as the domain discipline processes are orchestrated tightly. Hardware, systems, and software engineers are now working much more closely to design and develop systems. 

Digital engineering is a 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. The U.S. Department of Defense (DoD) has a poor track record of fielding new systems on time and within budget. Acquisition teams are mired in antiquated processes and are risk averse to attempt improvements if it causes too much organizational friction.  

The DoD has recognized its deficiency and has identified the following challenges with their current acquisition engineering process: 

  • It has a linear acquisition process that is not agile or resilient 
  • Stakeholders use stove-piped infrastructures, environments, and data sources to support various activities throughout the lifecycle 
  • Communication, collaboration, and decisions happen through static disconnected documents and subject to interpretation 
  • The existing practices are unable to deliver technology fast enough 

The Drive for Evolution in Engineering Practices 

Kristin BaldwinActing Deputy Assistant Secretary of Defense for Systems Engineering, wrote that, “In this era of rapid growth in technology, information, and complexity, we need to evolve our engineering practices. This evolution incorporates advancements in our engineering methodologies (methods, processes, and tools) to enable data-driven decision-making throughout the acquisition lifecycle.” 

In 2018 the US Secretary of Defense encouraged everyone to adopt new practices in order to modernize delivered systems and prioritize the speed of delivery. This encouragement was backed by a Digital Engineering Strategy which aims to allow the DoD and industry partners to work more collaboratively at the engineering level. 

DoD’s Expected Benefits of Digital Engineering 

Expected benefits of digital engineering include betterinformed decision making, enhanced communication, increased understanding of and confidence in the system design, and a more efficient engineering process 

The Top Five Goals of DoD’s Digital Engineering Strategy 

  1. Formalize the development, integration, and use of models to inform enterprise and program decision making
  2. Provide an enduring, authoritative source of truth
  3. Incorporate technological innovation to improve the engineering practice
  4. Establish a supporting infrastructure and environments to perform activities, collaborate, and communicate across stakeholders
  5. Transform the culture and workforce to adopt and support digital engineering across the lifecycle

There is a dire need to reduce the red tape without compromising the federal laws of oversight.  

Smart Systems Engineers 

A systems engineerprimary job is to work with the end users who are paying for the product. They have “operational requirements” that must be satisfied so that they can meet their mission needs.  

The current vision for the past decade has been to leverage Model Based Systems Engineering (MBSE) and use models to analyze and manage those requirements to ensure they are met at the end of the product development.  

The systems engineer becomes the translator from the electrical engineers to the mechanical engineers to the computer scientists to the operator of the system to the maintainer of the system to the buyer of the system. Each of these teams speaks a different language.  

The idea of using models was a means to provide communication in a simple, graphical form yet, only a tiny percentage of programs have demonstrated MBSE’s utility to achieve this vision. Smart systems engineers today recognize that models need to be expressed in more consumable formats to the broader stakeholder community so that communication and collaboration can take place. 

Jama Software’s Digital Engineering Bridge 

Jama Connect helps satisfy the DoD Digital Engineering Strategy’s first goal (formalize the development, integration, and use of models to inform enterprise and program decision making) by acting as a digital engineering bridge that connects the model world with the document world.  

Time consuming and error prone methods of data consumption via documents, spreadsheets, and legacy requirements tools introduces program risk and increases cycle time to the program timeline.  

Jama Connect’s unique user interface (UI) allows non-technical stakeholders to visualize a model of the system of interest and interact with the requirements in familiar views like documents and spreadsheets.  

The Benefits 

Whether Jama Connect is used in conjunction with MBSE SysML models or used as a standalone digital engineering platform, the system provides: 

  • Visualization of the shared system model and the status of its artifacts in the development lifecycle 
  • System and behavioral diagrams 
  • Faster requirements development 
  • Verification and validation of requirements developed in the model 
  • Mechanisms for broader audience communication and participation – tool specialists are not needed 
  • Baselining of requirements 
  • Requirements attribute management and workflow 
  • Requirements decomposition and tracing 
  • Specialized document generation and data reporting 

 Using Jama Connect in the application of MBSE to create models is supported by a series of pre-defined views and its underlying relationship ontology which enforces the rigor and consistency demanded by the framework. 

Jama Connect can be used in conjunction with dedicated SysML tools or as a standalone system. In fact, the data in Jama Connect is organized much in the same fashion as that in a modeling tool and performs many of the same functions. This is what makes it very attractive to organizations that do not have enough staff trained to use dedicated SysML graphical modeling tools. 

What Are Requirements in Jama Connect? 

From a big picture perspective, requirements themselves are the digital thread that connects the stakeholders stated needs and constraints to the system, hardware and software design that articulate to developers what must be developed. The notion that a “document” needs to exist for requirements to be captured and managed is a paradigm that the Digital Engineering Strategy is meant to eliminate. Jama Connect and modeling tools maintain requirements as atomic, individual objects that can then be consumed by all engineering disciplines in their own fashion. The overhead of maintaining documents just so they can be communicated to non-technical stakeholders is eliminated.  

There is also misconception that requirements engineering is performed only by systems engineers. A more agile approach to requirements engineering is when all stakeholders are validating requirements as they are being written (or as close to real time as possible). But this is difficult since a SysML model requires a specialist with many months of technical training to be able to read and understand. By using Jama Connect instead of documents or legacy requirements tools, the primary means for communication moves away from static and disconnected documents and shifts the paradigm to models and data serving as the basis for connecting traditionally siloed elements  providing an integrated information exchange throughout the lifecycle. 

Authoritative Source of Truth? 

The DoD has used the phrase single source of truth for decades, so much so that it has become the butt of ridicule. Misaligned tools and processes foster data to be stored in documents since that is the only medium that can be shared across vast varieties of stakeholders. This practice has led to: outright errors in data since it is difficult to keep track of the versions of documents; increases to the development timelines in order to just produce “documents” that are polished in formatting more suitable for print purposes; and increases to the overall cost since contractors have to charge for the additional document production time and publishing expertise. It is common for engineers to complain more of their time is spent producing pretty documents than doing engineering work. 

The Digital Engineering Strategy is attempting to combat the “where’s the latest document” question by describing in their second goal an authoritative source of truth. “The authoritative source of truth facilitates a sharing process across the boundaries of engineering disciplines, distributed teams, and other functional areas. It will provide the structure for organizing and integrating disparate models and data across the lifecycle. In addition, the authoritative source of truth will provide the technical elements for creating, updating, retrieving, and integrating models and data.”  

The Jama Connect platform is purpose-built to facilitate data sharing across various stakeholder disciplines and location boundaries. An easy to use web UI is used to capture and work with both data as well as the real-time decisions and feedback taking place around that data which keeps all stakeholders informed when change occurs and makes sure everyone gets the content they need—right when they need it. The result is that stakeholders can now access the most recent versions of data that engineers are working on without having to rely on document exports – the root of all waste. 

Fitting Within the Infrastructure 

No one tool alone will fulfill the new Digital Engineering Strategy and so to avoid the same problem of stovepipes that documents bring, the infrastructure and the tools used must become more consolidated and collaborative. Tools whether it is a MBSE tool, software engineering tool, testing tool, or CAD tool needs to have its data easily integrated with the rest of the tools within the infrastructure.  The “DoD’s strategy is to focus on standards, data, formats, and interfaces between tools rather than being constrained to particular tools.” This is probably the most difficult of all goals to achieve, not because of the lack of data exchange standards or capabilities provided by the vendors, but simply because of the distributed nature of the development teams themselves.  

In a contractor supply chain model, customers and their contractors perform their work on their own networks which are disconnected from each other. And even when working solely at a government site, classification levels force segregation of data onto different networks. Strategies to deal with integrating the data in the complex environment must be planned for.  

Jama Connect’s foundational architecture eases integration within the tool ecosystem. It has a built-in RESTful API and supports the industry standards OSLC and ReqIF formats for exchanging data. These important capabilities mean that when organizations go to integrate their digital engineering tools, numerous readily available 3rd party integration platforms are available; and in many cases already have templates to connect the endpoints in place.  

Parting Words 

There isn’t a single silver bullet to digital engineering, but I hope you leave this post with some ideas, some encouragement, and maybe some new determination to start your digital engineering journey. 


To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.

 SEE MORE RESOURCES

 

2020s predictions: MBSE, model-based systems engineering, Intercax

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.