Difference between pages "Submarine Warfare Federated Tactical Systems" and "Systems Engineering and Management"

From SEBoK
Jump to navigation Jump to search
 
 
Line 1: Line 1:
−
This article describes the transformation of the systems engineering and integration program that produces the common combat system used across the United States Navy (USN) submarine fleet from traditional document-based systems engineering (DBSE) to [[Transitioning Systems Engineering to a Model-based Discipline|model-based systems engineering]] ({{Term|Model-Based Systems Engineering (MBSE) (glossary)|MBSE}}). The topic may be of particular interest to those dealing with programs in the sustainment and evolution phase of their life cycle. For additional information, refer to the links provided in Section V: Lessons Learned below.
+
----
−
 
+
'''''Lead Authors:''''' ''Bud Lawson, Alan Faisandier,'' '''''Contributing Authors:''''' ''Rick Adcock, Dick Fairley, Garry Roedler, Ray Madachy, Deva Henry, Sanford Friedenthal''
−
==Background==
+
----
−
Modern submarines are typically in service for 20 - 40 years. Submarines and their internal systems are typically state-of-the-practice at launch, but most navies find it necessary to upgrade the ship’s combat system at least once during the operational lifetime. The evolution of threats, technology and interoperability drives the USN to upgrade their submarine combat systems and key components including the sonar (Fages 1998) (Ford and Dillard 2009) and tactical control systems continuously (Jacobus and Barrett 2002).
+
Part 3 of the Guide to the SE Body of Knowledge (SEBoK) focuses on the general knowledge of ''how'' systems are engineered.  
−
 
+
[[File:SEBoK Navigation Management.PNG|centre|thumb|743x743px|'''Figure 1 SEBoK Part 3 in context (SEBoK Original).''' For more detail see [[Structure of the SEBoK]]]]
−
Over the last three decades, submarine combat systems have evolved from multiple independent systems (sonar, combat control, imaging, electronic warfare, weapon control, etc.) with manual or point-to-point interfaces into networked [[Architecting Approaches for Systems of Systems|federations of systems]] (FoS). Confusingly, these component systems are often referred to as subsystems in the literature. Typically, each new class of submarines has been equipped with a new combat system, with a corresponding logistics and sustainment tail unique to that class.
 
−
[[File:AN BSY-1 Submarine Combat System.png|centre|thumb|1000x1000px|'''Figure 1. SysML Block Definition Diagram of 1985 era submarine combat system composed from independent component systems with point-to-point interfaces''' (SEBoK Original)]]
 
−
 
 
−
In the USN, each of these component systems has its own acquisition program, customer, and contractor team. Starting as legacy military systems hosted on traditional military-unique computational platforms, these systems have evolved to utilize Commercial Off-The-Shelf (COTS) computational and networking platforms, and leverage large amounts of COTS software.
 
−
 
 
−
As the component systems became more tightly interconnected, the acquisition customers established and collaboratively funded a systems engineering and integration (SE&I) program to manage the interfaces between systems, manage technology insertion and the obsolescence of common COTS hardware, and to integrate and test the production systems (Cooper, Sienkiewicz and Oliver 2006). Starting with the Virginia class, this SE&I program was expanded to encompass both new-production and in-service submarine modernization efforts. Over time, the combat systems of the various submarine classes were converged into variants of a single product line (Zingarelli et al. 2010). In addition, the independent system-to-system interfaces were rationalized where practical into common interfaces shared between multiple systems.
 
−
 
 
−
== Purpose ==
 
−
The submarine combat system SE&I program delivers an updated production baseline annually, along with product line variants for each submarine class or subclass being built or upgraded that year. Production systems implementing this baseline are delivered to new-build submarines, and to in-service submarines being upgraded on a roughly six-year cycle. The common combat system product line is referred to as the Submarine Warfare Federated Tactical Systems (SWFTS). SWFTS is deployed by the USN on submarines of the Los Angeles (SSN 688), Ohio (SSGN 726, SSBN 730), Seawolf (SSN 21), and Virginia (SSN 774) classes, and by the Royal Australian Navy on the Collins (SSG 73) class. SWFTS is also planned for the next-generation USN Columbia (SSBN) and RAN Future Submarine classes. Compared to the submarine combat systems that it replaced, SWFTS significantly reduces development, maintenance and training costs while delivering enhanced combat capabilities and facilitating the rapid insertion of new or improved capabilities (Zingarelli, et al. 2010).
 
−
[[File:VA combat system architecture.png|centre|thumb|700x700px|'''Figure 2. Contemporary submarine combat systems are networked with converged data interfaces''' (Produced by Lockheed Martin for US Navy. Approved for Public Release by US Navy, #16-348, June 2016)
 
−
]]
 
−
 
 
−
==Challenges==
 
−
The USN submarine fleet encompasses substantial platform variability between classes, sub-classes, and even individual ships within a sub-class. The RAN Collins class contributes additional variability. Platform variability drives combat system variability.
 
−
 
 
−
SWFTS is a Federation of Systems (FoS), with each platform hosting a subset of 40 systems produced by 20 different program offices. As is common with System of Systems (SoS) and FoS, there is no central program office that can command the compliance of all of the component system programs. Instead, the evolution of SWFTS is executed through negotiation and consensus.
 
−
 
 
−
Many baselines must be produced each year; new common hardware baselines are introduced in odd years, while new common software baselines are introduced in even years (Jacobus, Yan and Barrett 2002). In addition, multiple incremental developmental baselines are established each year. Once the annual production baseline for the product line is defined, variants must be developed for each submarine class or subclass built or upgraded that year (Mitchell 2012).
 
−
 
−
Like most other defense programs, the SWFTS SE&I program is under constant pressure to accomplish more with decreasing resources. There has been steady increase in SE scope despite decreasing budgets. Program leadership has responded in part through continuous SE process improvement. Improvements have included test automation, changes in the requirements management processes and tools (spreadsheets to IBM® Rational® DOORS® to OMG® SysML®), refined tooling for change management, and the DBSE to MBSE transition that is the focus of this case study. Substantial Return on Investment (ROI) has been achieved with each major SE process or tooling improvement (Mitchell 2014).
 
−
 
 
−
==Systems Engineering Practices==
 
−
During 2009 the SWFTS SE&I program conducted a Model Driven Architecture (MDA) study to determine if MDA should be the next step in the program’s continuous SE process improvement. The MDA study predicted a positive Return on Investment (ROI) from converting to MBSE. In January 2010, the SWFTS SE&I program office initiated a three-year effort to develop and validate a SWFTS FoS model and MBSE process. In 2013, a SWFTS baseline was developed using both DBSE and MBSE in parallel. The DBSE products were used to validate the MBSE products. Based on that successful validation, the SWFTS SE&I program transitioned to MBSE for all ongoing work.
 
−
 
−
Until the transition in 2013, SWFTS SE was performed using traditional DBSE.  Requirements were managed in DOORS, and reviewed and used by engineers in the form of massive spreadsheets with hundreds of columns and thousands of rows. The design of each variant was documented in Microsoft Office files. Baseline change requests (BCR) were documented in briefings and analyzed by all component system programs in parallel for potential impact. Approved BCRs were manually merged into DOORS and into revised baseline documents for each effected variant.
 
−
 
 
−
Starting in 2010, the customer community invested in a three-year MBSE transformation effort. The engineering team performed an in-depth tool trade study to select and set up the MBSE environment. That trade study resulted in the selection of MagicDraw™ for system modeling, using Teamwork™ as the model repository.
 
−
 
 
−
Once the modeling environment was installed, the MBSE transformation team architected, developed and populated a SysML-based model of the SWFTS FoS interfaces. The team updated the SWFTS SE process to take advantage of the new MBSE environment, with the constraint that the MBSE process produced SE products that were effectively identical to those produced by the DBSE process.
 
−
 
 
−
In 2013, the new MBSE environment and process was used to produce a set of SWFTS baseline SE products. In parallel, the DBSE process produced equivalent products. The two sets of baseline products were compared in detail, with all differences traced back to root causes.
 
−
 
 
−
This analysis identified a significant number of minor differences that were all traced to errors in the DBSE products. This validated the MBSE process and demonstrated that while those initial MBSE baseline products were more labor-intensive than the DBSE baseline products, the new MBSE process produced higher quality products. After this validation, the SWFTS SE&I program switched over to MBSE as their basic process.
 
−
 
 
−
Since that transformation, SE process improvement has continued apace. Requirements management has moved from DOORS to the system model in MagicDraw. As of 2016, the system model is the baseline for requirements, architecture and the FoS design. BCR impact analysis is now performed in model, leveraging capabilities of the toolset for automated assistance. Variants are documented in the system model as system configurations. Most SE products are generated from system model on demand.
 
  
−
While the initial scope of MBSE was limited to managing the interfaces between component systems, once the transition was successful, MBSE started expanding out to encompass additional SWFTS SE&I tasks. MBSE is now beginning to spread into the component system programs as well as the overall submarine combat system SE&I program.
+
This part builds upon Part 2: [[Foundations of Systems Engineering]], which discusses the need for a {{Term|Systems Approach (glossary)}} applied to one or more {{Term|Engineered System (glossary)}} contexts as a part of managed interventions into {{Term|Complexity (glossary)|complex}} real world problems. Part 3 provides an overview of the common uses of [[Life Cycle Models|life cycle models]] to organize the technical and non-technical aspects of SE and discusses [[Systems Engineering Management]] activities. Part 3 also discusses the most commonly used SE technical processes and provides additional references to the common methods, tools, and techniques used in these processes.
  
−
==Lessons Learned==
+
The commonly recognized definition of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) used across the SEBoK (INCOSE 2015) defines SE as an interdisciplinary approach which applies across the complete life cycle of an identified {{Term|System-of-Interest (glossary)|System-of-Interest}}.  The definition states that systems engineering “'''integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation'''”. Thus, SE is an engineering discipline concerned with all aspects of an engineered systems life, including how we organize to do the engineering, what is produced by that engineering and how the resulting systems are used and sustained to meet stakeholder needs.
−
Seven learning principles (LPs) (Friedman and Sage 2005) were derived that address the more broadly applicable areas of systems engineering knowledge and inform the areas of the SEBoK that are most strongly related to the case study. They are:
 
−
* [[System Requirements|Requirements traceability]] (LP1);
 
−
* [[Systems Engineering Core Concepts|Communications]] (LP2);
 
−
* [[Transitioning Systems Engineering to a Model-based Discipline|Productivity]] (LP3);
 
−
* [[Quality Management|Quality]] (LP4);
 
−
* {{Term|Engineering Change Management (glossary)|Managing Change}}''' '''(LP5);
 
−
* [[Transitioning Systems Engineering to a Model-based Discipline|Managing variants]] (LP6); and
 
−
* [[Life Cycle Models|Life cycle]] (LP7).
 
  
−
'''Requirements traceability''' LP1: MBSE improves traceability in multiple dimensions but maintaining requirements traceability between a traditional database and the MBSE system model can be challenging. While DOORS, MagicDraw and Teamwork can interoperate to provide requirements management and traceability, the combination is fragile. Without careful configuration management, synchronization can lead to database corruption.  If DOORS and Teamwork are on separate servers, maintaining the connection can run afoul of ever-evolving corporate information assurance (IA) policies.
+
Part 3 provides only an overview of how systems are engineered in a generic sense. [[Applications of Systems Engineering|Part 4]] provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of  {{Term|Product System (glossary)|product systems}},  {{Term|Service System (glossary)|service systems}}, {{Term|Enterprise System (glossary)|enterprise systems}}, and {{Term|System of Systems (SoS) (glossary)|systems of systems}} (SoS) contexts. [[Enabling Systems Engineering|Part 5]] explains how people and organizations may approach utilizing these principles as part of a holistic systems approach. [[Related Disciplines|Part 6]] contains references to other engineering and management disciplines, which work with the SE processes within a systems life cycle, but do not fall under the umbrella of SE.
  
−
Requirements can be managed using the SysML language inside the system model quite effectively. This approach can reduce the resources needed to keep the system model in sync with a traditional requirements database system and increase overall SE productivity.
+
Systems engineering, like many other engineering disciplines, is transitioning to a model-based approach, {{Term|Model-Based Systems Engineering (MBSE) (glossary)|model-based systems engineering (MBSE)}}.  The aim is to enhance productivity and quality, and to cope with the design of increasingly complex systems.  Although models have always been used by systems engineering to create information about engineered systems, that information has been translated and managed through document based artifacts. In a model-based approach, the information about the system is captured in a shared system model, made up of a set of integrated models appropriate to the life cycle stages. This model is managed and controlled throughout the system life cycle as noted in Part 2 under [[Representing Systems with Models|Representing Systems with Models]]. This provides the ability to maintain more consistent, precise, and traceable information about the system. The system model provides an authoritative source of information that can be communicated across the development team and other stakeholders, used to generate views of the system relevant to particular stakeholders, and used to generate documentation about  the system similar to more traditional systems engineering documentation. The model can also be analyzed to assess the integrity of the system specification and design. A model also captures knowledge in a way that can be more readily reused than traditional document-based approaches. In a model-based systems engineering approach, the processes referred to in this and other Parts of the SEBoK remain fundamentally the same, but the artifacts produced are model-based. Some examples of MBSE methods are highlighted in [[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]] (Estefan 2008). It is anticipated that as the transition to model-based practices occurs, the SEBoK will be updated to reflect the body of current and emerging practice.
  
−
'''Communications''' LP2: Tailored SE products generated from the system model can substantially enhance communications both within the technical team and between customer stakeholders. Graphical depictions of the system model often communicate better to human stakeholders than massive spreadsheets and textual documents. Further, the enhanced precision driven by modeling can reduce miscommunications between both technical and programmatic stakeholders.
+
==Knowledge Areas in Part 3==
 +
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 3 contains the following knowledge areas:
 +
*[[Introduction to Life Cycle Processes]]
 +
*[[Life Cycle Models]]
 +
*[[Concept Definition]]
 +
*[[System Definition]]
 +
*[[System Realization]]
 +
*[[System Deployment and Use]]
 +
*[[Systems Engineering Management]]
 +
*[[Product and Service Life Management]]
 +
*[[Systems Engineering Standards]]
 +
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
  
−
Having the architecture and design in a system model makes it affordable to generate specialized SE products on demand for particular communications needs while keeping all SE products in concordance. Even technical stakeholders who thought they understood the design can find new insights by looking at it in different representations.
+
==Value of Ontology Concepts for Systems Engineering==
  
−
'''Productivity''' LP3: MBSE increases productivity by enhancing communications within the team, automation of routine tasks, and cost avoidance. Processes used in DBSE often require substantial revision to achieve the potential productivity gains of MBSE. In particular, review processes must be modified to take advantage of the tooling.
+
Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). Systems engineering, and system development in particular, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path.
  
−
The selected modeling tools constrain how you can practically re-engineer SE processes. Automation can replace a great deal of routine SE work (document generation, identifying potential impacts of changes, etc.).
+
SE provides engineers with an approach based on a set of concepts (i.e., stakeholder, requirement, function, scenario, system element, etc.) and generic processes. Each process is composed of a set of activities and tasks gathered logically around a theme or a purpose. A process describes “what to do” using the applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are composed themselves of elementary tasks; they describe the “how to do” of SE. The activities and tasks of SE are transformations of generic data using predefined concepts. Those generic data are called entities, classes, or types. Each ''entity'' is characterized by specific ''attributes'', and each attribute may have a different value. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical ''relationships''. These relationships allow the engineer to link the entities between themselves {{Term|Traceability (glossary)|(traceability)}} and to follow a logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum and maximum number of entities that are required in order to make the relationship valid. Additional information on this subject may be found in ''Engineering Complex Systems with Models and Objects'' (Oliver, Kelliher, and Keegan 1997).
  
−
Developing strong modeling style guidelines and specialized representations, along with training materials to indoctrinate new team members as they join the program, is worth the investment. MBSE does require a trained cadre of modelers, but not all systems engineers have to become skilled modelers.
+
The set of SE entities and their relationships form an ontology, which is also referred to as an "engineering meta-model". Such an approach is used and defined in the ISO 10303 standard (ISO 2007). There are many benefits to using an ontology. The ontology allows or forces:
  
−
To effectively quantify the benefits of MBSE, a program needs to plan metrics collection carefully, and then stick to the plan long enough to collect meaningful data.
+
*the use of a standardized vocabulary, with carefully chosen names, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
 +
*the reconciliation of the vocabulary used in different modeling techniques and methods
 +
*the automatic appearance of the traceability requirements when implemented in databases, SE tools or workbenches, and the quick identification of the impacts of modifications in the engineering data set
 +
*the continual observation of the consistency and completeness of engineering data; etc.
  
−
'''Quality''' LP4: Much of the ROI from the MBSE transition can be in improved quality. Improving the quality of SE products reduces latent defects in systems delivered to the customer, reducing maintenance costs and increasing customer satisfaction.
+
Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.
  
−
Models are less tolerant of imprecision than documents. The increased precision improves SE product quality, both in reduced defect generation and in reduced defect escape. The automation of product generation can make specialized SE products affordable, further enhancing system quality.
+
==Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes==
  
−
'''Managing change''' LP5: How a proposed system change is understood and executed is fundamentally different between a model- and a document-centric approach. In the document-centric approach, the focus is on “What should my final output look like?”  In the model-based approach, the focus is on “What does this change mean to the system? Which other parts of the system are impacted by this change?”
+
Figure 2, below, shows the relative position of the KA's of the SEBoK with respect to the processes outlined in the ISO/IEC/IEEE 15288 (ISO 2015) standard.  
−
 
−
Change management is hard.  When moving from DBSE to MBSE the approach must be carefully considered up front, and the system model must be designed to facilitate that approach.    Change management also impacts tool selection, since different tools align better with different approaches.
 
  
−
'''Managing variants''' LP6: The most common process for managing variants in DBSE is ‘clone and own’, where each new product family member takes the then-current baseline and ‘forks’ the baseline for evolution of the variant. This makes synchronizing changes to the core baseline across the product family a very labor-intensive process. Treating variants as deviations from a core baseline in a model greatly reduces the cost of managing variation in a product family.
+
As shown, all of the major processes described in ISO/IEC/IEE 15288:2015 are discussed within the SEBoK.
 +
[[File:Mapping_of_tech_topics_SEBoK_with_ISO_IEC_15288techPro_060612.jpg|thumb|center|600px|'''Figure 2. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC/IEEE 15288 Technical Processes.''' (SEBoK Original)]]
  
−
Variant management is difficult.  The planned approach must be considered up front, and the system model must be designed to accommodate it. The selected approach impacts tool selection and tailoring.
+
The ISO/IEC/IEEE 15288:2015 marked with an * are new or have been renamed and modified in scope for this revision of the standard.   
−
 
−
Design the system model to treat variants as deviations from the core baseline. Then changes to the core baseline are automatically shared among all variants, and impact to product family members is limited to any impact of core baseline change on specific variant deviations.  This also facilitates commonality between variants, a key customer goal as commonality reduces logistics and training costs.
 
  
−
'''Life cycle''' LP7: MBSE can be applied early or late in the product family life cycle. While most projects using MBSE start off model-based, a program can transition to MBSE late in the life cycle.
+
These changes and associated changes to the SEBoK now mean that the two are significantly more closely aligned than before.  It should also be noted that the latest update of the INCOSE SE Handbook (INCOSE 2015) is now fully aligned with the 2015 revision of the standard.
  
−
Getting from DBSE to MBSE requires serious engineering, careful thought, planning and implementation. The SWFTS MBSE transition required three years of investment by the customer. That time and budget was spent primarily in designing and developing the system model and in re-engineering the SE processes.
+
Any future evolution of Life Cycle Process knowledge in the SEBoK will be complementary to these standard descriptions of the generic SE process set.
  
−
Start the transition with carefully defined scope. Once that is accomplished, the scope of MBSE can be expanded from there.  
+
==References==
 +
Collins English Dictionary, s.v. "Ontology." 2011.
  
−
==References==
+
Estefan, J. 2008. ''A Survey of Model-Based Systems Engineering (MBSE) Methodologies'', rev, B. Seattle, WA: International Council on Systems Engineering.  INCOSE-TD-2007-003-02. Available at: http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf. Accessed April 13, 2015.
  
−
===Works Cited===
+
INCOSE. 2015. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
−
Cooper, D. J., J. Sienkiewicz, and M. Oliver, "System engineering and integration for submarine combat systems in the COTS environment", NDIA Systems Engineering Conference, San Diego, CA, 23-26 October 2006.
 
  
−
Fages, H I. ‘Submarine programs: A resource sponsor’s perspective," ''The Submarine Review'', July  pp. 53–59, 1998.
+
ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
  
−
Ford, D. N., and J. T. Dillard, "Modeling open architecture and evolutionary acquisition: implementation lessons from the ARCI program for the Rapid Capability Insertion process ", ''Proceedings of the Sixth Acquisition Research Symposium: Defense Acquisition in Transition'' 2 (Apr 2009): pp. 207- 235.
+
ISO. 2007. ''Systems Engineering and Design.'' Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.
  
−
Friedman, G.R. and A.P. Sage, “Case studies of systems engineering and management in systems acquisition." ''Systems Engineering,'' vol. 7, No. 1, pp. 84-97, 2004.
+
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering Complex Systems with Models and Objects''. New York, NY, USA: McGraw-Hill.
−
 
 
−
Jacobus, P., P. Yan, and J. Barrett, "Information management: The advanced processor build (tactical)", ''JOHNS HOPKINS APL TECHNICAL DIGEST'', vol. 23, No. 4 Jan, pp. 366-372, 2002.
 
−
 
 
−
Zingarelli, M.  A., S. R. Wright, R. J. Pallack, and K. C. Matto, “SWFTS - System engineering applied to submarine combat systems,” ''Engineering the Total Ship,'' Falls Church, VA, July 2010.
 
  
 
===Primary References===
 
===Primary References===
−
Mitchell, S. W., “Efficiently Managing Product Baseline Configurations in the Model-Based System Development of a Combat System Product Family," ''INCOSE International Symposium'', Rome, Italy, July 2012.
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
−
Mitchell, S. W., "Transitioning the SWFTS program combat system product family from traditional document-centric to model-based systems engineering", ''Journal of Systems Engineering'', Vol. 17, No. 2, Spring 2014.
+
ISO/IEC/IEEE. 2015. [[ISO/IEC/IEEE 15288| Systems and Software Engineering -- System Life Cycle Processes]]. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.
  
 
===Additional References===
 
===Additional References===
−
Gibson, B., S. W. Mitchell, and D. Robinson, "Bridging the gap: Modeling federated combat systems," ''Third International Conference on Model Based Systems Engineering'', Fairfax, VA, Sept 2010.
+
Bell Telephone Laboratories. 1982. ''Engineering and Operations in the Bell System''. Murray Hill, NJ, USA: Bell Telephone Laboratories.
−
 
 
−
Mitchell, S. W., “Model-based system development for managing the evolution of a common submarine combat system," ''A FCEA-GMU C4I Center Symposium on Critical Issues in C4I,'' 18-19 May 2010.
 
−
 
 
−
Mitchell, S. W., "Complex product family modeling for common submarine combat system MBSE," ''Third International Conference on Model Based Systems Engineering,'' Fairfax, VA, Sept 2010.
 
  
−
Mitchell, S. W., ”Efficient management of configurations in the model-based system development of a common submarine combat system," ''A FCEA-GMU C4I Center Symposium on Critical Issues in C4I,'' 24-25 May 2011.
+
Fortescue, P.W., J. Stark, and G. Swinerd. 2003. ''Spacecraft Systems Engineering''. New York, NY, USA: J. Wiley.
  
 
----
 
----
−
<center>[[Singapore Water Management|< Previous Article]] | [[Implementation Examples|Parent Article]] | [[UK West Coast Route Modernisation Project|Next Article>]]</center>
+
<center>[[Applying the Systems Approach|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Introduction to Life Cycle Processes|Next Article >]]</center>
  
 
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
 
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
  
−
[[Category:Part 7]] [[Category:Example]]
+
[[Category: Part 3]][[Category:Part]]

Revision as of 05:20, 18 January 2020

Lead Authors: Bud Lawson, Alan Faisandier, Contributing Authors: Rick Adcock, Dick Fairley, Garry Roedler, Ray Madachy, Deva Henry, Sanford Friedenthal

Part 3 of the Guide to the SE Body of Knowledge (SEBoK) focuses on the general knowledge of how systems are engineered.

Figure 1 SEBoK Part 3 in context (SEBoK Original). For more detail see Structure of the SEBoK

This part builds upon Part 2: Foundations of Systems Engineering, which discusses the need for a systems approachsystems approach applied to one or more engineered systemengineered system contexts as a part of managed interventions into complexcomplex real world problems. Part 3 provides an overview of the common uses of life cycle models to organize the technical and non-technical aspects of SE and discusses Systems Engineering Management activities. Part 3 also discusses the most commonly used SE technical processes and provides additional references to the common methods, tools, and techniques used in these processes.

The commonly recognized definition of systems engineeringsystems engineering (SE) used across the SEBoK (INCOSE 2015) defines SE as an interdisciplinary approach which applies across the complete life cycle of an identified System-of-InterestSystem-of-Interest. The definition states that systems engineering “integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation”. Thus, SE is an engineering discipline concerned with all aspects of an engineered systems life, including how we organize to do the engineering, what is produced by that engineering and how the resulting systems are used and sustained to meet stakeholder needs.

Part 3 provides only an overview of how systems are engineered in a generic sense. Part 4 provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of product systemsproduct systems, service systemsservice systems, enterprise systemsenterprise systems, and systems of systemssystems of systems (SoS) contexts. Part 5 explains how people and organizations may approach utilizing these principles as part of a holistic systems approach. Part 6 contains references to other engineering and management disciplines, which work with the SE processes within a systems life cycle, but do not fall under the umbrella of SE.

Systems engineering, like many other engineering disciplines, is transitioning to a model-based approach, model-based systems engineering (MBSE)model-based systems engineering (MBSE). The aim is to enhance productivity and quality, and to cope with the design of increasingly complex systems. Although models have always been used by systems engineering to create information about engineered systems, that information has been translated and managed through document based artifacts. In a model-based approach, the information about the system is captured in a shared system model, made up of a set of integrated models appropriate to the life cycle stages. This model is managed and controlled throughout the system life cycle as noted in Part 2 under Representing Systems with Models. This provides the ability to maintain more consistent, precise, and traceable information about the system. The system model provides an authoritative source of information that can be communicated across the development team and other stakeholders, used to generate views of the system relevant to particular stakeholders, and used to generate documentation about the system similar to more traditional systems engineering documentation. The model can also be analyzed to assess the integrity of the system specification and design. A model also captures knowledge in a way that can be more readily reused than traditional document-based approaches. In a model-based systems engineering approach, the processes referred to in this and other Parts of the SEBoK remain fundamentally the same, but the artifacts produced are model-based. Some examples of MBSE methods are highlighted in A Survey of Model-Based Systems Engineering (MBSE) Methodologies (Estefan 2008). It is anticipated that as the transition to model-based practices occurs, the SEBoK will be updated to reflect the body of current and emerging practice.

Knowledge Areas in Part 3

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 3 contains the following knowledge areas:

See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.

Value of Ontology Concepts for Systems Engineering

Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). Systems engineering, and system development in particular, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path.

SE provides engineers with an approach based on a set of concepts (i.e., stakeholder, requirement, function, scenario, system element, etc.) and generic processes. Each process is composed of a set of activities and tasks gathered logically around a theme or a purpose. A process describes “what to do” using the applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are composed themselves of elementary tasks; they describe the “how to do” of SE. The activities and tasks of SE are transformations of generic data using predefined concepts. Those generic data are called entities, classes, or types. Each entity is characterized by specific attributes, and each attribute may have a different value. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical relationships. These relationships allow the engineer to link the entities between themselves (traceability)(traceability) and to follow a logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum and maximum number of entities that are required in order to make the relationship valid. Additional information on this subject may be found in Engineering Complex Systems with Models and Objects (Oliver, Kelliher, and Keegan 1997).

The set of SE entities and their relationships form an ontology, which is also referred to as an "engineering meta-model". Such an approach is used and defined in the ISO 10303 standard (ISO 2007). There are many benefits to using an ontology. The ontology allows or forces:

  • the use of a standardized vocabulary, with carefully chosen names, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
  • the reconciliation of the vocabulary used in different modeling techniques and methods
  • the automatic appearance of the traceability requirements when implemented in databases, SE tools or workbenches, and the quick identification of the impacts of modifications in the engineering data set
  • the continual observation of the consistency and completeness of engineering data; etc.

Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.

Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes

Figure 2, below, shows the relative position of the KA's of the SEBoK with respect to the processes outlined in the ISO/IEC/IEEE 15288 (ISO 2015) standard.

As shown, all of the major processes described in ISO/IEC/IEE 15288:2015 are discussed within the SEBoK.

Figure 2. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC/IEEE 15288 Technical Processes. (SEBoK Original)

The ISO/IEC/IEEE 15288:2015 marked with an * are new or have been renamed and modified in scope for this revision of the standard.

These changes and associated changes to the SEBoK now mean that the two are significantly more closely aligned than before. It should also be noted that the latest update of the INCOSE SE Handbook (INCOSE 2015) is now fully aligned with the 2015 revision of the standard.

Any future evolution of Life Cycle Process knowledge in the SEBoK will be complementary to these standard descriptions of the generic SE process set.

References

Collins English Dictionary, s.v. "Ontology." 2011.

Estefan, J. 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, rev, B. Seattle, WA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at: http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf. Accessed April 13, 2015.

INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO. 2007. Systems Engineering and Design. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.

Primary References

INCOSE. 2015. Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.

Additional References

Bell Telephone Laboratories. 1982. Engineering and Operations in the Bell System. Murray Hill, NJ, USA: Bell Telephone Laboratories.

Fortescue, P.W., J. Stark, and G. Swinerd. 2003. Spacecraft Systems Engineering. New York, NY, USA: J. Wiley.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Submarine_Warfare_Federated_Tactical_Systems&oldid=57961"