Difference between pages "Denver Airport Baggage Handling System" and "Systems Engineering and Management"

From SEBoK
(Difference between pages)
Jump to navigation Jump to search
(Robot improving glossary links)
 
 
Line 1: Line 1:
This example was developed as a SE example for the SEBoK. It describes systems engineering (SE) issues related to the development of the automated baggage handling system for the Denver International Airport (DIA) from 1990 to 1995. The computer controlled, electrical-mechanical system was part of a larger airport system.
+
----
 +
'''''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.
 +
[[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]]]]
 +
 
 +
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.
 +
 
 +
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.
 +
 
 +
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.
 +
 
 +
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.
  
==Description==
+
==Knowledge Areas in Part 3==
In February 1995, DIA was opened 16 months later than originally anticipated with a delay cost of $500 million (Calleam Consulting Ltd. 2008). A key schedule and cost problem—the integrated automated baggage handling system—was a unique feature of the airport. The baggage system was designed to distribute all baggage automatically between check-in and pick-up on arrival. The delivery mechanism consisted of 17 miles of track on which 4,000 individual, radio-controlled carts would circulate. The $238 million system consisted of over 100 computers networked together, 5,000 electric eyes, 400 radio receivers, and 56 bar-code scanners. The purpose of the system was to ensure the safe and timely arrival of every piece of baggage. Significant management, mechanical, and software problems plagued the automated baggage handling system. In August 2005, the automated system was abandoned and replaced with a manual one.
+
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.
  
The automated baggage system was far more complex than previous systems. As planned, it would have been ten times larger than any other automated system, developed on an ambitious schedule, utilized novel technology, and required shorter-than-average baggage delivery times. As such, the system involved a very high level of SE {{Term|Risk (glossary)|risk}}. A fixed {{Term|Scope (glossary)|scope}}, schedule, and budget arrangement precluded extensive simulation or physical testing of the full design. System design began late as it did not begin until well after construction of the airport was underway. The change management system allowed acceptance of change requests that required significant redesigns to portions of work already completed. The design did not include a meaningful backup system; for a system that required very high mechanical and computer reliability, this increased failure risks. The system had an insufficient number of tugs and carts to cope with the volume of baggage expected and this, along with severely limited timing requirements, caused baggage carts to jam in the tracks and for them to misalign with the conveyor belts feeding the bags. This resulted in mutilated and lost bags (Neufville 1994; Gibbs 1994). 
+
==Value of Ontology Concepts for Systems Engineering==
  
The baggage system problems could be associated with the non-use or misuse of a number of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) concepts and practices: [[Logical Architecture Model Development |system architecture complexity,]] [[Planning|project scheduling]], [[Risk Management|risk management]], [[Configuration Management|change management]], [[System Analysis|system analysis and design]], [[Reliability, Availability, and Maintainability|system reliability]], [[System Integration|systems integration]], [[System Verification|system verification]] and [[System Validation|validation/testing]], and [[Enabling Systems Engineering|insufficient management oversight]].
+
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.
  
==Summary==
+
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).
The initial planning decisions, such as the decision to implement one airport-wide integrated system, the contractual commitments to scope, schedule, and cost, as well as the lack of adequate project management (PM) procedures and processes, led to a failed system. Attention to SE principles and practices might have avoided the system’s failure.
 
  
==References==
+
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:
  
===Works Cited===
+
*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
Calleam Consulting Ltd. 2008. ''Case Study – Denver International Airport Baggage Handling System – An illustration of ineffectual decision making''. Accessed on September 11, 2011. Available at http://calleam.com/WTPF/?page_id=2086.
+
*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.
  
Neufville, R. de. 1994.  "The Baggage System at Denver: Prospects and Lessons."  ''Journal of Air Transport Management''. 1(4): 229-236.
+
Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.
  
Gibbs, W.W1994.  "Software’s Chronic Crisis."  ''Scientific American''. September 1994: p. 72-81.
+
==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.
 +
[[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)]]
 +
 
 +
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 beforeIt 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===
 
===Primary References===
None.
+
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.
 +
 
 +
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===
DOT. 1994. "New Denver Airport: Impact of the Delayed Baggage System." US Department of Transportation (DOT), Research Innovation Technology Administration. GAO/RCED-95-35BR. Available at http://ntl.bts.gov/DOCS/rc9535br.html
+
Bell Telephone Laboratories. 1982. ''Engineering and Operations in the Bell System''. Murray Hill, NJ, USA: Bell Telephone Laboratories.
  
Donaldson, A.J.M. 2002. "A Case Narrative of the Project Problems with the Denver Airport Baggage Handling Systems (DABHS)," Software Forensics Center technical Report TR 2002-01. Middlesex University, School of Computer Sciences. Available at http://www.eis.mdx.ac.uk/research/SFC/Reports/TR2002-01.pdf
+
Fortescue, P.W., J. Stark, and G. Swinerd. 2003. ''Spacecraft Systems Engineering''. New York, NY, USA: J. Wiley.
  
 
----
 
----
<center>[[Complex Adaptive Taxi Service Scheduler|< Previous Article]] | [[Implementation Examples|Parent Article]] | [[Global Positioning System|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>
  
[[Category:Part 7]][[Category:Example]]
+
[[Category: Part 3]][[Category:Part]]
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 

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