Systems Engineering: A Data-Centric Perspective

This is part 3a of the blog series “Integrated Data as the Foundation of Systems Engineering.

In Part 2, The Need for Systems Engineering I addressed the need for SE, challenges associated with increasingly complex systems, and the benefits of adopting SE from a data-centric perspective.

In this part 3, I introduce and define the concept of practicing SE from a data-centric perspecitve. In the first section I discuss the Systems Engineering work products and underlying data and information that are generated as part of each of the SE lifecycle activities.  I then address the questions: “What is a model?” and “What is model-based SE (MBSE)?” from a data-centric perspective.  In the second section I discuss what the concept of integrated data as the foundation of SE is and provide a revised defintion of Systems Engineering from a data-centric perspective.

Systems Engineering Work products

Work products and their underlying data and information are generated as part of the activities conducted during each of the SE development lifecycle processes.  These work products may be represented in a “hard copy” printed form (documents, drawings, diagrams, etc.) or in an electronic form (documents, drawings, diagrams, databases, models, spreadsheets, etc.). In some cases, the electronic form may be a file without any underlying data or may be represented by underlying data and information stored in a database.  Moving toward practicing SE from a data-centric perspective with the goal of integrating all the work products and their underlying data and information requires the electronic form of work products be such that they can be integrated together into a common project dataset. When using analytical models, many work products are visualizations of the underlying data and information representing the model.

Table 1 provides example work products generated during each of the six lifecycle processes defined in ISO/IEC/IEEE 15288:2015.   A more detailed list of work products can be found in chapters 4, 5, 6, & 7 of the INCOSE SE Handbook (HB) (INCOSE 2015). (A similar list of work products can be generated from a program/project management perspective.   Both sets of work products are dependent and need to be integrated for maximum management effectiveness.)

Table 1: Examples of SE lifecycle activities and work products
(Derived from INCOSE SE HB Chapters 3, 4, & 5).

The focus in the concept stage is to define the system of interest and investigate the extent of the effort, time, and cost to provide that system of interest.  Most of the work in the concept stage is conducted for three main purposes:

*  facilitate a common understanding of the problem being solved and definition of the system of interest needed to address that problem;

* evaluate the risks associated with candidate concepts by performing feasibility analyses (cost, schedule, technical, political, environmental, ethical, etc.) and trade studies, and

* baseline a feasible concept and corresponding system level requirements.

The development stage starts with the results from the concept stage efforts. The work products shown in Table 1 representing the system under development have been defined.  If the work products have been created using SE tools that support increasing granularity, work products and their underlying data and information developed during the concept stage can continue to be used in the development stage with added information and refinement.  During development, the concept is transformed into a design, and in that transformation, design and technical issues are resolved as an integral part of the SE lifecycle process.

As a system progresses from one lifecycle stage to the next, the number of work products and their underlying data and information increase rapidly.  The data and information from the concept stage serve as input to the later stages and help to identify areas where deeper analysis is necessary.  Feedback from these analyses is used to update the various work products and their underlying data, information, and the concept, if needed.  Traceability between data and information from the previous stage and the subsequent stages is established and maintained as is rationale for all changes.  Linking the data and information within and between lifecycle stages, is fundamental to establishing a common, integrated dataset.

Within many organizations, these processes are frequently executed by different disciplines and organizations across the various SE lifecycles, often resulting in “stovepipes” or “silos” within the developing organization and especially between external organizations.  A primary outcome of implementing SE from a data-centric perspective within an organization is to breakdown the stovepipes and integrate these work products and their underlying data, into a common, integrated dataset.

What is a Model?

All the SE work products and underlying data and information discussed in the previous section are represented within this integrated dataset.  These work products include various types of models.   A primary focus of the MBSE Initiative is the use of models as a part of the SE lifecycle process activities.  In the context of SE, the INCOSE 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.”

Because of this, it is instructive to understand what a model is.  Definitions of “model” include:

*  A physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process (DoD 1998).

*  A representation of one or more concepts that may be realized in the physical world (Friedenthal, Moore, and Steiner 2009).

*  A simplified representation of a system at some particular point in time or space intended to promote understanding of the real system (Bellinger 2004).

*  An abstraction of a system, aimed at understanding, communicating, explaining, or designing aspects of interest of that system (Dori 2002).

*  A selective representation of some system whose form and content are chosen based on a specific set of concerns; the model is related to the system by an explicit or implicit mapping (Object Management Group 2010).

*  An approximation, representation, or idealization of selected aspects of the structure, behavior, operation, or other characteristics of a real-world process, concept, or system. (IEEE 610.12-1990).

In the INCOSE SE HB, the word “model” shows up over 680 times!  The term is used to refer the various kinds of models, visualizations of the data and information contained in an analytical model, as well as documents, diagrams, drawings, or any other representation of a system.  Examples include: lifecycle model, modeling and simulation, SysML or other language based models, SE Vee model, spiral model, event model, modeling artifacts, model taxonomy, mental models, competency models, engineering model, development model, system model, product model, graphical models, mathematical models, physical models, operational analysis models, logical models, functional models, architectural models, behavioral models, meta-models, cost models, process models, rule models, ontological models, belief models, project models, capability models, data models, structural models, analytical models, business models, representation models, temporal models, mass models, probabilistic models, parametric models, layout models, network models, concept models, information models, maturity models, SE process model, reference model, domain models, and T-shaped model.

In order to practice SE from a data-centric perspective, each of these types of model are represented by data and information that must be integrated into a common project dataset.

Note: the above list of the various types of models exceeds the set of models that any one project will need or use.  Each model type is generated for a specific purpose or need the project wishes to address.  Projects need to decide, and document in their Systems Engineering Management Plan (SEMP) which types of modeling work products are needed to meet their needs.  Those models will then be leveraged for a particular SE effort.

Because of the usefulness and value of models in SE, the MBSE Initiative was formed.

What is Model-Based Systems Engineering (MBSE)?

INCOSE SE HB, Section 9.2 (INCOSE 2015) defines MBSE as stated in the INCOSE Systems Engineering vision 2020 (2007) as: “the formalized application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout the development and later life cycle phases.”

The INCOSE SE HB goes on to say that: “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.”

The artifacts discussed above are the work products and their underlying data and information.  It is important to understand that not all work products are models and not all models have to be analytical. In addition, it is helpful to understand that various views or visualizations of the data and information are not the same as the model which these views represent.  Analytical models include a series of diagrams or other work products represented by underlying data and information stored in a common database.  Example diagrams include: package diagram, requirement diagram, activity diagram, sequence diagram, state machine diagram, use case diagram, block definition diagram, internal block diagram, parametric diagram (Novel 2016).  Each of the diagrams or other work products is a visualization of the common data and information in the database from whatever perspective is needed by the user to communicate a specific message or address a specific need.

In Vitech’s blog (ZSCOTT 2016), Models and Views, Zane Scott addresses this confusion by making a distinction between models and views. The paper states: ““Model” and “view” are terms that are used somewhat loosely in the world of systems engineering. Often they are used interchangeably. Frequently, the imprecision of their usage causes confusion. Views, which might be pictures, diagrams, or textual descriptions of various aspects of the reality, can easily be considered models [based on the definitions above]. But doing so can lead to a loss of some of the power available in a system where models and views are understood differently. There is a strong value-add to be had from understanding documents and views in relation to models rather than seeing them as interchangeable concepts. A better approach involves a model that offers different views in order to serve different purposes. The documents/views flow from the model as structured answers to particular queries of the model.”

Given there can be multiple types of models, and visualizations of the data and information in those models generated while progressing through the SE lifecycle processes, a 10,000-foot level view of SE from a data-centric perspective is needed to help understand the context in which work products and their underlying data and information are generated and used.   Thus when a model needs to be shared, it is the dataset representing the model that needs to be shared rather than the artifacts which are visualizations of the data and information in the dataset. (Malone et al 2016)

MBSE is not really about any particular type of model or visualization of data and information – whether that be a diagram, report, or document – but is about the underlying integrated information model that enables consistency across such models and visualizations. Hence the “Model” in Model-Based Systems Engineering” refers to the information model, not a specific type of model, diagram, or other visualization of the data in the model. This information model is represented by a common, integrated dataset that is the foundation of SE.  This dataset is the model, work products and artifacts which are visualizations of the dataset are not the model.  (Malone et al 2016).

I finish up part 3b of this blog series by discussing the concept of Integrated Data as the foundation of SE and provide alternate definitions of Systems Engineering from a data-centric perspective.

Comments to this blog are welcome