Standards Available for Modeling Systems
Most systems engineers are familiar with modeling languages such as Integrated Definition (IDEF), Business Process Model and Notation (BPMN), Unified...
14 min read
Lou Wheatcraft : 5/9/23 11:15 AM
Guest Blog by Lou Wheatcraft of Wheatland Consulting, LLC
Today’s systems are becoming increasingly complex and software-intensive. Yesterday’s electro-mechanical systems had fewer interactions both internally and externally - interfaces could be shown on drawings. For these complex, software-intensive systems, internal and external interactions have increased several orders of magnitude as have the threats and vulnerabilities. Critical functions are carried out by the software - electro-mechanical parts of a system are “enablers” for the software.
This presents major challenges for organizations being able to effectively manage all the data, information, and artifacts across the lifecycle for these types of systems.
Historically, organizations defined and recorded the data and information associated with the various artifacts in the form of “documents”. As systems become more complex and regulated, the sheer volume of documentation has become overwhelming; especially in terms of configuration management, change control, completeness, correctness, and consistency. Because of the complexity, there are more people involved in the development of these systems spread over different geographical locations. This results in many of the documents being developed and managed within silos with limited collaboration.
Because of these issues, it is nearly impossible to keep all the data and information contained within the various documents in sync, current, correct, and consistent resulting in no real single source of truth (SSoT). For highly regulated systems, the amount of documentation that must be developed, maintained, and supplied to regulators to show compliance has become overwhelming. Inconsistencies in these documents can result in a system that fails system validation and that is not approved for use.
The cost and time overhead associated with managing a large number of documents consumes a large part of development costs. The time overhead results in longer development times and time to market for many systems, making a company less competitive and less profitable. Additionally, quality suffers resulting in post-system launch costs associated with increases in returns, recalls, warranty work, and company image degradation associated with negative social media comments – all of which also eat into profits. A highly regulated system that is not approved for use can result in a company’s stock price plummeting and, in some cases, the company going bankrupt. The old, 20th-century, document-centric approach is no longer effective for many of today’s systems of the 21st century. As a result, many organizations are seeking approaches to address these challenges.
An organization that is leading the move towards a better way is the International Council of Systems Engineering (INCOSE) of which I am an active member. As stated in INCOSE Vision 2025, “a constant theme throughout the evolution of systems engineering is the ever-increasing complexity of systems which can be observed in terms of the number of system functions, components, and interfaces and their non-linear interactions and emergent properties. Each of these indicators of complexity has
increased dramatically over the last fifty years and will continue to increase due to the capabilities that stakeholders are demanding and the advancement in technologies that enable these capabilities. This complexity presents organizations with challenges that need to be addressed. Failures can result in tremendous loss."
These challenges are a result of increases in:
To address these challenges, we must find a better way how we practice systems engineering.
Key areas that need to be addressed in meeting these challenges include:
Out of this search for a better way, an approach referred to as Model-based Systems Engineering (MBSE) has emerged.
When introduced to MBSE, many organizations have several key questions: “Why should I move my organization towards MBSE?”, “Just what is MBSE?”, and “What is the real intent of MBSE?”
Why Should I Move My Organization Towards MBSE? A quick and simple answer is “To avoid the issues discussed above!” Less overhead, decreased time to market, higher quality, decreases in post-launch issues, fewer issues associated with a system being approved for use, increased profits, higher stock prices, and a growing company should be reason enough. However, there are several other fundamental reasons for adopting MBSE from a business strategic perspective: competitiveness and relevancy.
MBSE can be considered a technology. Like all innovative technologies, there is a spectrum concerning the rate of adoption. There are innovators, early adopters, early majority, late majority, and laggards. The late majority and laggards generally get left behind.
John Maudlin is an economist, venture capitalist, and investment advisor. He is extremely interested in investment opportunities concerning companies that are innovators and early adopters. In a recent article “Technology Rules” he states:
“….it’s remarkable how many industries and government agencies are still operating on ancient (as in the 1990s) technology, [just] muddling through.”
“... what happens when those organizations take off their old-tech handcuffs? They will run better and develop new capabilities they never had before. Customers, workers, and investors will all benefit.”
“Humans have a comparative advantage at higher levels of abstraction: creativity, intuition, and holistic judgments. Each is necessary. The best technologies do not automate complex problems, as many assume; they equip people to solve them faster and more effectively.”
With this perspective, it is hard to understand that given we are 22 years into the 21st Century, why do so many organizations continue to practice system engineering based on outdated 20th Century document-centric methodologies?
Another issue is relevancy. In a paper [3] presented at INCOSE’s 2021 International Symposium, the authors provided a quote attributed to Jack Welch of GE, “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.” This quote supports the idea that organizations' “rate of change must increase to match the rate of change in industry and the rapidly evolving technology universe.” In the increasingly competitive business world of today, the late majority and laggards face the prospect of becoming irrelevant. Hopefully, you now have a better understanding of why you need to adopt MBSE within your organization. But there is still the question “What exactly is MBSE?”
What exactly is MBSE? When asked to define MBSE, ask 20 people and you will get 20 different answers! There are several different perspectives: To some, MBSE is equated to the use of SysML and other language-based modeling tools to develop analytical, logical, behavioral, and architectural models to:
It is important to understand that MBSE is NOT SysML! MBSE is much more than just using language-based modeling tools to develop analytical, logical, behavioral, and architectural models. At the core of confusion is the word “model."
The INCOSE Systems Engineering Handbook (SE HB) states that “a model that represents a system and its environment is of particular importance to the systems engineer who must analyze, specify, design, and verify systems, as well as share information with other stakeholders. Different types of models are used to represent systems for different modeling purposes.”
In the INCOSE SE HB v4, the word “model” shows up over 680 times! The term is used to refer to the various visualizations of the data and information including analytical, logical, behavioral, and architectural models, textual descriptions, as well as documents, functional flow diagrams, data flow diagrams, interface diagrams, architectural diagrams, or drawings. In this context, a “model” can be any representation or abstraction of the system of interest (SOI) that best suits the purpose for which it was created. Thus, there are various kinds of models.
The common denominator of all these representations is that they are all visualizations of the underlying data and information that is used to construct and represent the system under development. Again, referring to the INCOSE SE HB:
“MBSE is often contrasted with a traditional document‐based approach to SE. In a document‐based SE approach, there is often considerable information generated about the system that is contained in documents and other artifacts such as specifications, interface control documents, system description documents, trade studies, analysis reports, and verification plans, procedures, and reports. The information contained within these documents is often difficult to maintain and synchronize, and difficult to assess in terms of its quality (correctness, completeness, and consistency).”
“In an MBSE approach, much of this information is captured [electronically] in a system model or set of models. The system model is a primary artifact of the SE process. MBSE formalizes the application of SE through the use of models. The degree to which this information is captured in models and maintained throughout the life cycle depends on the scope of the MBSE effort. Leveraging an MBSE approach to SE is intended to result in significant improvements in system requirements, architecture, and design quality; lower the risk and cost of system development by surfacing issues early in the system definition; enhance productivity through reuse of system artifacts; and improve communications among the system development team.”
Given there can be multiple types of models, and visualizations of the data and information in those models generated while progressing through the system life cycle processes, a 10,000-foot level view of systems engineering from a data-centric perspective is needed to help understand the context in which various artifacts and their underlying data and information are generated and used. An MBSE approach to system engineering uses various types of models and visualizations of the data and information in those models to help stakeholders better understand the context in which various artifacts and their underlying data and information are generated and used while progressing through the system lifecycle.
What is the Real Intent of MBSE? MBSE is not really about any particular type of model or visualization of data and information – whether that be a model, diagram, report, or document – but is about the underlying data and information. MBSE enables system engineers to establish consistency, completeness, and correctness of the underlying data and information that represents the various models and visualizations.
The data and information model that must be developed must represent all the SE artifacts generated during the system development process activities across all lifecycle stages. Thus, information associated with the elicitation of stakeholder needs and requirements, lifecycle concept definition, analysis, and maturation, deriving an integrated set of needs, and transforming those needs into sets of 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 as well as help assess the impact of changes made to any of the data items. Design inputs must be traceable to design outputs.
The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of systems engineering so as to realize the real intent of MBSE. From this perspective, the true intent of MBSE is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system lifecycle process activities, resulting artifacts, and their underlying data and information.
“MBSE, from a data-centric perspective, involves the formalized application of shareable sets of data to represent the systems engineering work products and underlying data and information generated to support lifecycle concept maturation, needs and requirements definition, design, analysis, and verification and validation activities throughout the system lifecycle, from conceptual design to retirement.” [1]
With this data-centric perspective of MBSE, the capability to capture, manage, access data, and manage the interrelationships between systems engineering 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. This data and information is captured using a variety of systems engineering tools and applications.
INCOSE INCOSE-TP-2018-001-01, 2018, Integrated Data as a Foundation of Systems Engineering, prepared by the Requirements Working Group
To effectively manage our ever-increasing complex, software-intensive systems, there are benefits to managing this underlying data and information in such a way it can be shared across the system lifecycle process activities, shared between the various systems engineering 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, software-intensive systems as well as enable collaboration between not only the project team members but also external stakeholders involved in the development of the system.
The practice of systems engineering is often viewed from many perspectives. Similar to the old story of the blind men and the elephant, systems engineering cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry-specific application, etc.). To successfully practice systems engineering, wise systems engineers recognize and use each perspective as appropriate to the activity they are performing. Based on their needs they choose the appropriate tool and visualization that will meet their needs.
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 programs, product line, culture, processes, workforce, diversity, and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.
Benefits of Implementing Systems Engineering from a Data-Centric Perspective [1]
A data-centric perspective of systems engineering complements the system lifecycle process activities by enabling the opportunity for system development with increased quality, lower cost, lower risk, and shorter development times. Adopting MBSE and implementing a data-centric perspective enables organizations to realize the following benefits:
Systems Engineering Toolset
Choosing the appropriate systems engineering tool set is critical for organizations to move to a data-centric practice of systems engineering. This toolset and associated processes enable:
Key Features of the Systems Engineering Toolset
In order to do these things and realize the benefits of moving to a data-centric practice of SE, the SE toolset should have the following capabilities.
Parting Thoughts
In order to effectively develop today’s increasingly complex and software-intensive systems and avoid the many negative consequences of the outdated document-centric practice of systems engineering, organizations must move to a data-centric practice of systems engineering which is the real intent of MBSE. Organizations need to develop a level of organizational systems engineering capability that will enable them to realize the benefits listed above.
Since one size doesn’t fit all, an organization needs to assess the systems engineering capabilities that best fit its domain, system line (degree of complexity), and culture. The level of systems engineering capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects.
Based on the needs of the organization and the level of systems engineering capability they choose, organizations need to choose the appropriate systems engineering toolset, update their processes, and train their people in these tools and processes
References
[1] INCOSE INCOSE-TP-2018-001-01, 2018, Integrated Data as a Foundation of Systems Engineering, prepared by the Requirements Working Group, INCOSE.
[2] INCOSE-TP-2010-006-03, 2019, Guide to Writing Requirements, prepared by the Requirements Working Group, INCOSE.
[3] S. Sheard, M. Bouyaud, M. Osaisai, J. Siviy, K. E. Nidiffer; A Guide for Systems Engineers to Finding Your Role in 21st-Century Software-Dominant Organizations, Technical Paper presented at IS2021
[4] Wheatcraft, L., Ryan, M., Dick, J., Llorens, J., 2019. “The Need for an Information-based Approach to Requirement Development and Management”, paper and poster presentation at INCOSE IS 2019.
Biography
Lou Wheatcraft is a senior consultant and managing member of Wheatland Consulting, LLC. Lou is an expert in systems engineering with a focus on needs and requirements development, management, verification, & validation. Lou provides consulting and mentoring services to clients on the importance of well-formed needs & requirements helping them implement needs & requirement development and management processes, reviewing and providing comments on their needs and requirements, and helping clients write well-formed needs & requirements.
Specialties include: Understanding and documenting the problem; defining project & system scope; defining and maturing system concepts; assessing, mitigating, &
managing risk; documenting stakeholder needs; transforming needs into well-formed design input requirements; allocation, budgeting, and traceability; interface management, requirement management; & verification and validation.
Lou’s goal is to help clients practice better systems engineering from a needs & requirements perspective across all life cycle stages of system/system development. Getting the needs & requirements right upfront is key to a successful project. Poor needs & requirements can triple the chances of project failure.
Lou has over 50 years of experience in systems engineering, including 22 years in the United States Air Force. Lou has taught over 200 requirement seminars over the last 21 years.
Lou supports clients from all industries involved in developing and managing systems and systems including aerospace, defense, medical devices, consumer goods, transportation, and energy.
Lou has spoken at Project Management Institute (PMI) chapter meetings and INCOSE conferences and chapter meetings. Lou has published and presented many papers concerning needs and requirements for NASA’s PM Challenge, INCOSE, INCOSE INSIGHT Magazine, and Crosstalk Magazine. Lou is a member of INCOSE, past Chair and current Co-Chair of the INCOSE Requirements Working Group (RWG), a member of the Project Management Institute (PMI), the Software Engineering Institute (SEI), the World Futures Society, and the National Honor Society of Pi Alpha Alpha. Lou has a BS degree in Electrical Engineering from Oklahoma State University; an MA degree in Computer Information Systems; an MS degree in Environmental Management; and has completed the course work for an MS degree in Studies of the Future from the University of Houston – Clear Lake
Most systems engineers are familiar with modeling languages such as Integrated Definition (IDEF), Business Process Model and Notation (BPMN), Unified...
1 min read
Guest Blog by Lou Wheatcraft of Wheatland Consulting, LLC In my previous paper, “MBSE: Moving to a Data-Centric Practice of Systems Engineering,” key...