bluuebunny/crossref_metadata_2025 huggingface dataset:
Model‐Based Systems Engineering For Project Success: The Complete Process
Authors: Long James
Published: November 2014

This basic tutorial identifies the elements and benefits of a complete, proven model‐based system engineering process, and demonstrates its tailorability and value for project success using vignettes from an information management system and a sample System of Systems (SoS) application. The tutorial illustrates how the model‐based system engineering process supports both document‐driven and model‐based paradigms, whether in top‐down, middle‐out, or reverse engineering environments. It discusses how to know when each element of the process has been completed, and how to develop and validate functional and physical architectures using executable architectures. The requirement for concurrent engineering, the onion model, and synchronization of models and data are presented.

The participants will be introduced to a flexible system engineering process suitable for system development tasks across the complexity spectrum. In addition to the process description, the tutorial will include a sample solution to illustrate the recommended techniques, views, completion conditions, and products of an MBSE system development methodology. It will also include examples of the development of graphical views commonly used by practitioners of DoDAF and SysML approaches.

This tutorial is focused on highlighting how the use of model‐based systems engineering can meet the government requirements for delivering architecture framework products while allowing the engineering organizations (industry and government) to successfully perform the systems engineering required to develop an executable design.
Architecting the Enterprise: Using a Standards Approach
Authors: Martin Richard A.
Published: November 2014

Enterprise architecture has taken on many meanings as practitioners and scholars attempt to understand and apply the principles of design and construction necessary for today's highly complicated enterprise scale systems.

This tutorial presents an overview of enterprise architecture concerns and then uses International Standards as a means to frame the disparate approaches relative to those concerns, offers some insight into the relationships among approaches that result from applying the standards, and identifies opportunities for an innovative architecting discipline to facilitate sustainable enterprise operation. International communities for Information technology (ISO JTC1) and Automation systems and integration (ISO TC184) have produced International Standards with requirements related to enterprise architecture. These methodology independent International Standards provide a means to assess methodological approaches and offer guidance for the creation and articulation of enterprise architecture. INCOSE, as a liaison partner, has been instrumental in assuring that systems engineering remains an essential contributor to these efforts.
Requirements Engineering for Large and Very Large Scale Systems Part I ‐ Processes and Tooling
Authors: Berenbach Brian , Cleland‐Huang Jane
Published: November 2014

Requirements engineering processes in the large are very different from those on small to medium size systems. Most texts on requirements engineering, for example tend to describe small or medium scale systems (up to about 5K requirements), or if the systems are large, describe the processes associated with product development and product lines. Industrial projects, however, start at 20K requirements and up. The creation of scalable processes that will support a large infrastructure project of the kind we are reading about in the headlines today (e.g. “shovel ready”) can be a daunting prospect. This tutorial will present some of the challenges associated with the requirements engineering of such large and very large projects, and describe how to setup processes and tooling to support such projects.

This is part one of a two part tutorial. The morning session describes how to set up processes and tooling for very large industrial projects, typically dealing with 50 thousand or more requirements. The afternoon session describes the unique nature of requirements engineering processes for contract based projects. Either session may be taken independently, but the attendee will get the most out of the tutorial by attending both sessions.
Systems and Software Architecting: A Unified Approach
Authors: Eisner Howard
Published: November 2014

Formulating a sound architecture has become one of the most important elements in systems engineering, software engineering and systems integration. Significant work has been done in the architecting of systems and, mostly as a separate matter, the architecting of software. This paper focuses upon the issue of a unified approach to both systems and software architecting. A specific procedure for a unified method is suggested and illustrated.
Requirements Engineering in the bio medical industry: GAMP 5 and tooling
Authors: Fanmuy Gauthier , Szczepaniak Richard
Published: November 2014

The principles of systems engineering are applicable to all types of systems including computerized systems. They are particularly effective for these systems because the computer is still new technology, they can better understand the development and life cycle of these systems by erasing the image of “black boxes”. It is now essential for computer systems to carry more and more critical actions especially in highly regulated industries such as pharmaceuticals or medical devices industries. These industries has established a repository, the GAMP (see reference [1]), in order to define the correct principles to be established for computerized systems. This paper presents the principles of systems engineering defined in GAMP and how they were developed by the company ADN and CORTIM for the pharmaceutical and medical devices industries.
1.4.1 Practical SysML Applications: A Method to Describe the Problem Space
Authors: Lempia David , Jorgensen Ray
Published: November 2014

Customers are looking for solutions to problems that they are having. The problem description methodology starts with the group of customers called the stakeholders and ends with a set of functions that need to be implemented to satisfy the needs of each of the stakeholders. Building the wrong feature or building features that are not used are costly forms of waste in engineering development. Likewise, building exactly what the customer wants and delivering the most valuable functions early is the key to project success. There are a number of SysML and UML methodologies published. These methodologies generally lead the engineer from requirements to analysis to structural design and back to behaviors. Because of the methodology, it is easy to mix the solution ideas in with the problem definition. Adding solution ideas too early constrains the possible solutions that can be utilized when the set of problems is investigated. Also, these existing methodologies yield poor traceability and throw‐away diagrams. This problem description methodology describes a logical evolution of thought, a reduced simplified set of diagrams, traceable requirements, and diagrams that easily evolve into implementation or test.
1.4.2 What Is the Smallest Model of a System?
Authors: Schindel William D.
Published: November 2014

How werepresentsystems is fundamental to the history of mathematics, science, and engineering. Model‐based engineering methods shift thenatureof representation of systems from historical prose forms to explicit data structures more directly comparable to those of science and mathematics. However, using models does not guaranteesimplerrepresentation–indeed a typical fear voiced about models is that they may be too complex.

Minimalityof system representations is of both theoretical and practical interest. The mathematical and scientific interest is that the size of a system's “minimal representation” is one definition of its complexity. The practical engineering interest is that the size and redundancy of engineering specifications challenge the effectiveness of systems engineering processes. INCOSE thought leaders have asked how systems work can be made 10:1 simpler to attract a 10:1 larger global community of practitioners. And so, we ask: What is the smallest model of a system?
3.2.1 A Study of Systems Engineering Effectiveness: Building a Business Case for SE
Authors: Elm Joseph P.
Published: November 2014

Understanding the value of Systems Engineering (SE) is necessary to justify a project's investment in SE resources and activities. To identify the value of SE, the Systems Engineering Effectiveness Committee (SEEC) of the National Defense Industrial Association (NDIA), in collaboration with the Software Engineering Institute (SEI), developed and executed a survey of defense industrial contractors. The survey analyzed the relationships between the SE activities applied to individual projects, and performance of those projects. Results of this survey, published in 2007 and 2008[1], indicated strong relationships between many SE efforts applied early in the project and the overall success of the project. Today, NDIA, in collaboration with the Institute of Electrical and Electronics Engineers Aerospace and Electronic Systems Society (IEEE‐AESS) and SEI, is engaged in extending that study to build a stronger business case for the application of effective SE to product development projects.
4.6.1 A historical perspective of MBSE with a view to the future
Authors: Haskins Cecilia
Published: November 2014

Model‐based engineering has been a topic of discussion for over twenty years; Model‐based systems engineering (MBSE) has been an INCOSE initiative since 2006. For the third international conference on MBSE held September 2010, the author researched the background of MBSE from a historical perspective to identify the emergent timeline and to recognize the work that has lead to the current situation. This perspective can be used to understand the barriers to adoption, the research that remains, and to establish a reasonable expectation of the path ahead for realizing the full potential of MBSE.
6.2.1 Complexity Types: From Science to Systems Engineering
Authors: Sheard Sarah A. , Mostashari Ali
Published: November 2014

How to measure complexity for systems engineering is currently receiving great attention, including such efforts as DARPA's META program. However, complexity is a highly varying concept with many different views. This paper discusses some of those varieties of meaning, types of complexities, and entities which may be measured for complexity (qualitatively or quantitatively). First discussed are attributes that make a system complex and difficulties in dealing with the system because of the complexity (i.e. complexity causes and effects). Next types of complexity are reviewed from previous work. Finally those types of complexity are applied to four types of systems engineering entity: a project building a technological system, that system itself, the environment into which the system will be inserted, and the cognitive load on humans involved in the system. Ongoing and future work is also described.
6.3.2 Capability Engineering – An Analysis of Perspectives
Authors: Henshaw Michael J de C. , Lister Peter , Harding Alan D , Kemp Duncan , Daw Andrew J , Farncombe Andrew , Touchin Malcolm
Published: November 2014

The terms ‘capability’ and ‘capability engineering’ are now widely used across industry and in government procurement, but it is clear that different communities use the terms with similar, but distinctly different meanings. Using a soft systems methodological approach, an INCOSE UK working group has identified eight perspectives of capability, which have been related to Ring's value cycle and the Hitchins' five layer model of systems engineering. It is asserted that capability is the ability to do something and that capability engineering is the overarching approach that links value, purpose, and solution of a systems problem. It is equivalent to layers 1–4 of Hitchins' Five Layer Model and is equivalent to an holistic perspective of systems engineering. There are significant practice and examples of capability engineering from (at least) the UK rail provision, defence, and Information Services and it is the view of the working group that further INCOSE guidance may be needed to ensure engineers are properly equipped to deal with capability and capability engineering.
6.6.1 Using MBSE with SysML Parametrics to Perform Requirements Analysis
Authors: Bijan Yvonne , Yu Junfang , Graves Henson , Stracener Jerrell , Woods Timothy
Published: November 2014

Requirements are attributed as a common cause of failure in system development. Not only are text requirements ambiguous, the domain conditions under which they are to be satisfied are vague. Until operating conditions and requirements are formally captured, they will continue to be vague with ill‐defined verification criteria. SysML used in a Model‐Based Systems Engineering (MBSE) development process can enable mitigation of this primary source of error. By representing the system under design and its operating environment as a composite SysML model with parametric diagrams, requirements can be formalized in a precise manner. Formalization of requirements and constraints with parametric diagrams enables them to be verified and flowed down during the development process. An example will be used to illustrate how parametric diagrams can be used to develop requirements and constraints.
7.1.3 Architectural Patterns for Self‐Organizing Systems‐of‐Systems
Authors: Nichols Craig , Dove Rick
Published: November 2014

Contemporary threats exhibit unique characteristics that challenge classical security systems. In response to these threats, the DoD has an increased focus on applying proven SE techniques to SoS, which provide more functionality and performance than the sum of the constituent systems. Tools and techniques are necessary to facilitate evolution of today's systems. One major need is the ability to develop agile SoS architectures that respond to contemporary threats. This paper focuses on one characteristic of contemporary threats, self‐organization. Different SoS are reviewed for the driving forces that support their self‐organizing architecture. Necessary characteristics are identified and general constructs are put forward as candidate architectural patterns. These candidate patterns are now available for evaluation and employment consideration. They can be applied when problems common to the pattern manifest in new environments. They also add to the body of knowledge for SoS SE.
9.3.1 Adaptive Systems Engineering: A Medical Paradigm for Practicing Systems Engineering
Authors: Hamelin R. Douglas , Klingler Ron D. , Dieckmann Christopher
Published: November 2014

From its inception in the defense and aerospace industries, SE has applied holistic, interdisciplinary tools and work‐process to improve the design and management of “large, complex engineering projects.” The traditional scope of engineering embraces the design, development, production, and operation of structural, hardware, and software systems, and SE, as originally conceived, falls within that scope.

While this “traditional” view has expanded over the years to embrace wider, more holistic applications, much of the literature and training currently available is still directed almost entirely at addressing the large, complex, NASA, defense, and other industry systems wherein the “ideal” practice of SE provides the cradle‐to‐grave foundation for system development and deployment. Under such scenarios, systems engineers are generally viewed as an integral part of the system and project life‐cycle from conception to decommissioning. In smaller, less complex, and far less “ideal” applications, SE principles are equally if not more applicable to a growing number of systems and projects that need to be “rescued” from overwhelming challenges that threaten imminent failure.

The medical profession provides a unique analogy for this latter concept and offers a useful paradigm for tailoring our “practice” of SE to address the unexpected dynamics of applying SE in the real world. In short, we can be much more effective as systems engineers as we change some of the paradigms under which we teach and “practice” SE.
Considerations for a Generalized Reuse Framework for System Development
Authors: Wang Gan , Rice Jeff
Published: November 2014

Reuse has been gaining ever increasing focus in all stages of the system development process as the prospects of leveraging prior investments to save costs, shorten delivery schedule, and possibly improve product quality are appealing to system developers. However, the concept of reuse at the system level is often poorly understood and the practice has not been effectively documented and practiced, particularly from the systems engineering point of view. This paper conceptualizes a generalized reuse framework for system development using an activity‐based modelling approach. It examines reuse from both the producer's and consumer's points of view and links the essential reuse activities for the production and consumption processes through reusable resources. A classification schema is proposed to evaluate reuse from the two perspectives, i.e., development with reuse and development for reuse. The interface between the two strategies is discussed and notional scenarios to apply this framework are also presented. The framework proposed lays down a foundation for quantitative evaluation of the effect of reuse in an on‐going effort assessing such an impact through parametric modelling.
1.4.2 Systems engineering education for confirmed engineers:experience feedback
Authors: Hammami Omar , Ruault Jean‐René
Published: November 2014

System engineering evolution and adoption around the world have been unevenly supported by education programs. The current strong emergence of system engineering needs in several industries combined with inappropriate education support in the past resulted in strong demands for lilelong education programs. Most mid career engineers with very significant technical project experience in major french companies graduated in engineering programs with no education in system engineering beyond short trainings. Often, they have been exposed to system engineering processes through participation in large programs but only in a partial manner. This is typical of a general transition period inside companies with internal struggles on the exact role and scope of system engineering. In this paper we report the feedback of a system engineering program targeted to this audience.
1.6.2 Generic Approach for Systems Design Optimization in MBSE1
Authors: Broodney Henry , Dotan Dolev , Greenberg Lev , Masin Michael
Published: November 2014

The complexity of contemporary systems causes Systems Engineers great pains during early architectural design phases. Model‐Based Systems Engineering (MBSE) proposes methodologies to deal with complexity and streamline design processes, but the penetration of the new approach is slow. This paper proposes a generic SysML based methodology for improving the Architectural Design phase of Systems and mitigate the barriers for MBSE adoption. The proposed methodology suggests an alternative way to formalize requirements, define design alternatives, automate design space exploration and examine optimization results in the original modeling format. A representative example is provided. A glossary is included at the end of the paper.
2.1.2 A novel approach to Large System Performance Prediction via Markov analysis
Authors: Petrucci Roberto , Vigilante Domenico
Published: November 2014

This paper provides a preliminary answer to the rising needs for performance prediction in the Large System (LS) area. Specifically, it was required by the Selex‐SI OIL Camp Protection IPT, in order to support the Technical Proposal generation.

LS performance prediction is a whole new field of interest, fuelled by its huge potential in the homeland security and homeland defense applications; a lot of research is being conducted by the main private companies and national agencies; however, a standard approach to assess the performance of a Large System has not been defined yet.

The outcomes of our work have been the following: a technical report, describing the approach, the mathematics and some examples; an analysis tool, coded in matlab, supporting the numerical evaluations.
3.1.1 The Impact of IT on Product Architecture and Project Outcomes
Authors: Marion Tucker J. , Barczak Gloria , Meyer Marc H. , Brown Greg
Published: November 2014

Product Architecture and scalable product platforms are primary assets in leveraging R&D resources for continued firm growth. This study explores the impact of information technology (IT) on the development of robust, scalable architecture and their shared product platforms. Over the past twenty years, the implementation of information technology infrastructure and associated tools has transformed how firms approach new product development (NPD). IT solutions have migrated from a focus on detailed engineering design and associated production and launch (i.e. 3D computer‐aided ‐design (CAD) and product lifecycle management systems), to up‐front activities like architecture planning and development. Given the expanding role of IT and digital design tools further up‐front in the NPD process, we investigate their impact on developing robust product architecture. Through an empirical study of 122 firms and follow‐up interviews, we study the impact of IT (ie. digital design tools, IT infrastructure, IT embeddedness) and team collaboration on the efficiency and effectiveness of product architecture and overall project outcomes. The results indicate that a firm's IT infrastructure and team collaboration have strong, significant relationships with the development of an efficient and effective product architecture. The findings also show a strong, positive relationship between product architecture and project outcomes. Specifically, efficient and effective product architecture results in meeting project performance goals.
3.2.1 Systems Engineering Decision Making May Be More Emotional Than Rational!
Authors: White B E.
Published: November 2014

Many subscribe to the hypothesis or generally accepted premise that professionals, e.g., systems engineers, make work‐related decisions rationally, considering all the facts, while being objective, impersonal, and unemotional. A contrarian view would be that many, if not most, of our professional decisions are based primarily on emotion rather than reason, i.e., gut instincts about what would be best considering our own self‐interests. The results of a simple survey are presented and discussed in an attempt to shed light on this issue. Despite the author's hypothesis and the thrust of the paper's title, the conclusion (based upon the five dozen responses received) is that most work‐related decisions are indeed made rationally but many are made more emotionally than otherwise might be surmised.
3.2.2 Enhancing the System Development Process Performance: a Value‐Based Approach
Authors: Mastrofini Manuel , Cantone Giovanni , Seaman Carolyn , Shull Forrest , Diep Madeline , Falessi Davide
Published: November 2014

When planning or controlling the system development process, a project leader needs to make decisions which take into account a number of aspects, including: availability of assets and competences, previously enacted processes in the organization, certifications the system is required to obtain, standards to comply with, interactions among process activities, contextual factors and constraints, and allocated budget and schedule.

In this paper we propose a value‐based approach for supporting decision making. The aim is to provide supportive information for decisions related to the system verification process. This would in turn enhance the performance of system development process by supporting the decision making process for complex systems. We report both academic and industrial empirical evaluations, which demonstrate the feasibility and effectiveness of our proposal, and thus prompt us to refine and extend our approach to sub‐processes other than verification.
4.2.2 Application of Systems Engineering to Improve Extracorporeal Membrane Oxygenation (ECMO) Therapy
Authors: Pihera L. Drew , Ender Tommer , Taylor Brian , Bollweg Nick R , Lopez Andrew , Paden Matthew L. , King Scott
Published: November 2014

Though able to boost survival rates from below 25% to nearly 75% in patients that qualify for treatment, the complexity of the currently implemented Extracorporeal Membrane Oxygenation (ECMO) system of systems keeps it from being used across an even wider range of patients. Representatives from the Children's Healthcare of Atlanta asked a team from the Georgia Tech Professional Masters in Applied Systems Engineering for assistance in reducing the complexity of the current implementation as well as help provide a way forward for future improvement to the therapy. This paper examines the application of systems engineering methodologies as performed by the team, including Model Based Systems Engineering (MBSE), gap analysis of the system architecture and data visualization prototyping. Additionally the paper describes how the selection of tools and models fostered dialog between two groups of distinctly different backgrounds and provides a proposed roadmap for robust system design, development and future work.
4.2.3 A Systems Approach to Medical Device Compliance with IEC 60601–1:2005
Authors: Gibson Chad , Eubanks Fritz , Hobson Felicia
Published: November 2014

The development of electrical medical devices requires compliance with a host of regulations and standards to help ensure their safety and effectiveness. One of the most notable additions in recent years is the 3rd Edition of IEC 60601‐1 (IEC 60601–1, 2005), “Medical electrical equipment – General requirements for basic safety and essential performance.” Medical devices sold to the European Community and Canada must comply with the standard in 2012, and devices in the U.S. and other countries must follow shortly thereafter. This standard represents a sea change in the way medical devices are typically developed, and includes a heavy reliance on safety risk management and usability engineering processes. This paper presents the systems engineer as the ideal candidate to lead these activities and facilitate device development; the standard impacts many areas (e.g., engineering, regulatory, human factors, and project management) and requires a methodical approach to implement in a cost‐effective manner while ensuring safety and effectiveness of the device. This paper details techniques developed to efficiently comply with the standard, leveraging existing systems engineering practices and emerging methods such as Model Based Systems Engineering.
4.3.1 The Barriers to Systems Thinking
Authors: Beasley Richard
Published: November 2014

System Thinking is a pre‐requisite to effective Systems Engineering, and is one of the hardest elements to recognize, develop and use. This paper argues that this is because Systems Thinking is hard, and actually unnatural. There are barriers in the way the human brain is pre‐disposed to act, and the current state of engineering can also be a barrier to Systems Thinking. To deliver the value promised by Systems Engineering recognizing these difficulties, and overcoming them is essential.

Based on experience implementing effective and explicit Systems Engineering into Rolls‐Royce plc the author suggests some ideas on overcoming the barriers. Systems Engineering's greatest value comes from effective pre‐work in the early stages of projects. But the most effective place to learn the approach and quickly see the benefits is solving the problems (rework) created by its initial absence, as the scope is reduced. Systems Thinking needs to be integrated into the processes, the knowledge and the roles within the organisation. Effective leadership setting the expectation that Systems Thinking will be done is equally vital.
4.3.2 Integrating Systems Science, Systems Thinking, and Systems Engineering: understanding the differences and exploiting the synergies
Authors: Sillitto Hillary
Published: November 2014

There is a need to properly define the “intellectual foundations of systems engineering”; and we need to look beyond systems engineering to do this. This paper presents a new framework for understanding and integrating the distinct and complementary contributions of systems science, systems thinking, and systems engineering to create an “integrated systems approach”. The key step is to properly separate out and understand the relationship between the triad of: systems science as an objective “science of systems”; systems thinking as concerned with “understanding systems in a human context”; and systems engineering as “creating, adjusting and configuring systems for a purpose”. None of these is a subset of another; all have to be considered as distinct though interdependent subjects. A key conclusion of the paper is that the “correct” choice of system boundary for a particular purpose depends on the property of interest. The insights necessary to inform this choice belong in the domain of “systems thinking”, which thus provides a key input to “systems engineering”. In many systems businesses, the role of “systems architect” or “systems engineer” integrates the skills of systems science, systems thinking and systems engineering ‐ which are therefore all essential competencies for the role.
4.5.1 Systems Modeling with SysML – an experience report
Authors: Herzog Erik , Hallonquist Jessica , Naeser Johan
Published: November 2014

Model Based Systems Engineering has been presented as the future way of working for quite some time now. In this paper the practice of Model based systems engineering with SysML within SAAB Aeronautics is presented. Three different cases of different ambition and complexity are presented along with an analysis of the results. A number of modification proposals to SysML based on the experience made are also presented.
4.5.2 Model‐based automatic generation and selection of safe architectures
Authors: CONDAT Hélène , HEIN Andreas , STROBEL Carsten
Published: November 2014

Modern avionics systems are characterized by their increasing complexity and demanding safety requirements. The fulfillment of safety constraints is often only tested after the design of the systems, which leads to costly and time‐consuming design iterations. The complexity of avionics systems is still managed through a number of predominantly manual, paper‐based procedures.

Relying on systems engineering and operations research methods and tools, a methodology was developed to support the design process. This methodology should reduce the design duration through an earlier consideration of safety constraints. It should also contribute to the overall improvement of the design, through an automated approach of its complexity.

A generic meta‐model is created, suitable for various kinds of avionics systems, which contains requirements ‐ including safety requirements ‐ and design goals. From these formal requirements and goals an algorithm creates corresponding mathematical constraints and optimization criteria. All valid architectures fulfilling these constraints are automatically generated. Sets of efficient and diverse architectures among the generated solutions are selected by an algorithm.
4.5.3 Model‐Based Systems Engineering in an Integrated Environment
Authors: Pagnanelli Christi A. Gau , Carson Ronald S. , Palmer John R. , Crow Michael E. , Sheeley Barbara J.
Published: November 2014

Model‐based system engineering (MBSE) can be accomplished in a variety of ways to develop high quality integrated systems. Certain organizational and system development characteristics render different approaches to MBSE attractive when compared with using SysML. The paper outlines the key characteristics that contribute to successful MBSE project development, and uses those characteristics to contrast approaches based on (a) traditional methods without integrated modeling, (b) SysML using a UML tool such as IBM® Rational® Rhapsody®, and (c) traditional methods using an integrated data environment such as provided by Siemens Teamcenter® for System Engineering (TcSE). An integrated environment provides the opportunity to document the system definition consistently and aid in performing trades and analyses throughout the product lifecycle, starting with abstract ideas and concepts and continuing until detailed physical architecture elements are determined and verified. Such an approach enables consistency between left‐side‐of‐the‐V activities and right‐side‐of the‐V efforts, and also enables measuring the consistency and completeness of the data.
5.2.1 The Facility Location for Emergency Response –A Multi‐objective Approach
Authors: Hernandez Ivan , Ramirez‐Marquez Jose
Published: November 2014

In the event of a bio‐hazard break out in a city, response agencies will open Temporary Emergency Units (TEUs) in every affected neighborhood to vaccinate the population. Through evolutionary algorithms, this research shows how response agencies can choose the best locations for setting up TEUs when a set of competing objectives are considered. Based on the proposed approach, response agencies can obtain trade‐off solutions with respect to: a) setting up few TEUs, but with the drawback that processing the entire population might take a long time, or b) processing the entire population in time, by setting up a large number of facilities.
5.3.1 Emergence: All in the Minds
Authors: McConnell George R.
Published: November 2014

Model Based Systems Engineering (MBSE) rightly attracts much attention. However, when we start to consider models that are ‘beyond’ UML (or any similar language) we encounter one of the major challenges of systems thinking – that is that we each have different perspectives ‐ or models ‐ on what reality is. No two people approach a situation with exactly the same background, knowledge and objectives ‐ there will always therefore be differences between their personal understanding and view of the situation. Reconciling these differences ‐ indeed even recognising these differences ‐ presents a major challenge related to MBSE.
5.4.1 An Experimental Methodology to Evaluate Concept Generation Procedures Based on Quantitative Lifecycle Performance
Authors: Cardin Michel‐Alexandre , Kolfschoten Gwendolyn L. , Frey Daniel D. , de Neufville Richard , de Weck Olivier L. , Geltner David M.
Published: November 2014

This study presents an experimental methodology to measure how concept generation procedures can affect the anticipated lifecycle performance of engineering systems design concepts. The methodology is based on objective and quantitative measurements of anticipated lifecycle performance of the design concepts. It merges cognitive and computer‐aided techniques from the fields of collaboration engineering, creativity, and engineering design. It complements the body of existing techniques relying on subjective expert assessments, and other objective metrics not explicitly measuring anticipated lifecycle performance (e.g. development time and cost). Application of the methodology is demonstrated through evaluation of design procedures generating flexibility in engineering systems design. Experiments had ninety participants generate creative design alternatives to a simplified real estate development design problem. Thirty‐two teams of two to three participants performed the collaborative design exercise. An online Group‐Support System interface enabled efficient data collection and analysis. A computationally efficient mid‐fidelity model was used to evaluate flexible design concepts quantitatively based on real options analysis techniques.
7.2.1 UK Railway System Reliability ‐ Modelling the Future – a Case Study
Authors: Best Nigel , Hyland Bradley , Waters Suzanne
Published: November 2014

In the 15 years since privatisation, the British railway has undergone a major transformation: investment has increased 60% since 1996/97; ridership has increased by 60%; and reliability has grown to over 90% ‐ all this on one of the most complex and congested mixed traffic railways in the world.

Building on this success, the railway is now being challenged further to become even more reliable and to provide better value for money for both taxpayers and passengers. In response to this challenge, the national cross industry Technical Strategy Leadership Group has set strategic targets for doubling capacity, halving costs and carbon emissions and significantly improving the passenger experience over the next thirty years.

Capacity, Reliability and Cost in the railway are interrelated and represent the principal pressure factors in the UK Railways. It may be relatively easy to improve two, at the expense of the third, however improving all three factors at the same time is a major challenge.

This paper presents the results of a study whose main objective was to understand the implications of doubling capacity on the existing infrastructure. Whole system level modelling has been applied in order to study the relationship between capacity and reliability and thus further assist the research into practical solutions for the future railway development.

TRAIL, a system level modelling tool, has been used to simulate the southern end of the West Coast Main Line (WCML), one of the most congested parts of the GB rail network. The study comprises two phases:

Building the base case for the future railway – a double capacity railway with current operating approaches and asset reliabilities. This is a full network model that replicates the actual railway operation, including the signalling control logic.

Simulating a range of different incident prevention, control and mitigation measures to enable identification of ‘optimum’ asset reliability requirements beyond which any further asset reliability improvement ceases to have a significant impact on rail service performance

The results show significant deterioration from current performance levels with the implementation of the high capacity future timetable. System performance can be returned to an acceptable level if infrastructure and rolling stock reliability improvements, identified in the study were to be realised. The study also identifies several mitigation measures related to the operation of an ‘on‐time’ railway including boundary presentation, sub‐threshold lateness and timetable recovery.

A number of overall conclusions are drawn relating to the use of systems models generic to the analysis of performance within any industry characterised by the presence of a large volume of legacy assets and performance monitoring arrangements.
7.4.2 What's fundamentally wrong? Improving our approach towards capturing value in requirements specification
Authors: GILB TOM , BRODIE LINDSEY
Published: November 2014

We are all aware that many of our IT projects fail and disappoint: the poor state of requirements practice is frequently stated as a contributing factor. This article proposes a fundamental cause is that we think like programmers, not engineers and managers. We fail to concentrate on value delivery, and instead focus on functions, on use‐cases and on code delivery. Our requirements specification practices fail to adequately address capturing value‐related information. Compounding this problem, senior management is not taking its responsibility to make things better: managers are not effectively communicating about value and demanding value delivery. This article outlines some practical suggestions aimed at tackling these problems and improving the quality of requirements specification.
7.5.1 An incremental hybridisation of heterogeneous case studies to develop an ontology for capability engineering
Authors: Dogan Huseyin , de C. Henshaw Michael J , Johnson Julian
Published: November 2014

An analysis of perspectives for “capability engineering” has been conducted by the INCOSE UK Capability Working Group (CWG). This paper is a continuation of this study led by the CWG ontology work stream that aims to develop a single shared ontology for the concept of capability engineering to enable semantic interoperability and to support a formal and explicit specification of a shared conceptualisation. Case study material from the different domains of rail, defence and information services was used. The ontology development was executed in three phases; (1) pre‐analysis, (2) ontology modelling and (3) post‐analysis. The pre‐analysis involved literature reviews, requirements specification, systems engineering process utilisation; and resource identification i.e. examination of the case study material. The ontology modelling phase comprised information extraction and classification in addition to modelling and code representation using a mark‐up tool, MS Excel and Protégé. The post‐analysis involved validation workshops through using expert focus groups.
8.4.2 Measuring the Value of Adaptability of Fractionated Spacecrafts
Authors: Nilchiani Roshanak , Efatmaneshnik Mahmoud , Dalili Kia
Published: November 2014

In this paper, we introduce a new framework for quantitatively measuring the value of Adaptability in systems. A short review of literature is presented followed by the Adaptability Measurement Framework. Various stages of the Adaptability Framework including identifying system boundaries, various types of uncertainties and options analysis and modeling tools are discussed. The Framework is then applied to the case of measuring the value of adaptability of fractionated spacecrafts for several types of uncertain events and a brief discussion of results will follow.
8.7.2 On the Complexity of Requirements Flow‐down Structures
Authors: Dick Jeremy , Jones Brendan
Published: November 2014

The process of systematically decomposing and tracing requirements results in graphs in which the tracing diverges and converges as the requirements are re‐factored through the layers of design. This paper reports in work in progress to assess measures for the complexity of requirements decomposition graphs, including the use of the standard definition of cyclomatic complexity. It discusses what the complexity of requirements flow‐down means intuitively, and establishes some informal assessment criteria. A number of measures are motivated and defined, and then assessed against the criteria. Finally, the paper discusses the use of such measures as viable tools for assisting in the review of requirements development, and the future directions the on‐going work should take.
9.5.2 Aging Aircraft Fleet Viability
Authors: Bullard Randall C.
Published: November 2014

Systems engineering in the US Air Force looks at the entire life cycle of a weapon system. While a primary focus has been on accomplishing proper SE early on at concept development, it is equally important when the system reaches the end of its planned lifetime. When deciding whether to modernize or retire a particular fleet, the Air Force looks to the Fleet Viability Board to perform an assessment.
9.6.2 Developing Systems Engineering Competencies in Undergraduate Students for Industrial Placements
Authors: Hubbard Ella‐Mae
Published: November 2014

This paper reports on a project investigating the impact of industrial placements on the development of Systems Engineering competencies. It is widely acknowledged that engineering students can develop valuable transferable skills during industrial experience. This paper goes on to identify a set of Systems Engineering specific and transferable soft skills which students should develop before any industrial experience, in order to make the best out of the opportunities provided to them and also to improve return for the industrial organizations involved.
10.4.2 Enterprise Integration: A Framework for Connecting the Dots
Authors: Stroup Ronald L , Kepchar Kenneth J
Published: November 2014

Air Traffic Management (ATM) in the United States is handled by the Federal Aviation Administration (FAA) using the National Airspace System (NAS), which is part of the U.S. government critical infrastructure. It is comprised of systems that are ground‐based, airborne‐based, and space‐based. It is an interwoven group of systems that effectively work together to provide the navigation, communications, and surveillance necessary to safely and efficiently transit our airspace.

For more than 50 years, the FAA has been upgrading and modernizing the components and capabilities of the NAS, with activities ranging from simple updates to large‐scale replacement. The United States, as have other parts of the world, has embarked on an ambitious modernization of the Air traffic Management System – called NextGen (Next Generation Air Transportation System). We are introducing new technologies, policies, procedures, and systems to increase the capacity, effectiveness, and safety of the NAS in response to changing demands in air transportation. Development of NextGen, however, represents a marked increase in scope and complexity from these activities and, therefore, in the risk associated with the NextGen undertaking. Significant changes in the technologies employed, as well as consequent changes to air traffic procedures add to the potential for a many‐fold increase in both the number of risks to be encountered and the cost of encountering each risk, as well as an increasing possibility of actually missing the existence of some risks. These technology and procedure changes also add to the potential for new opportunities.

This paper discusses the NextGen integrated framework that has been developed as part of a broader Strategic Integration Environment to address the integration challenges that must be addressed to establish a viable Systems of Systems (SoS) management approach that satisfies the needs of a diverse aviation community involved in collaborating to develop, sponsor, operate, or use NextGen.
10.5.1 An MBSE Case Study and Research Challenges
Authors: Do Quoc , Cook Stephen
Published: November 2014

Model‐Based Systems Engineering (MBSE) is an emerging practice that provides major advantages over document‐based engineering design approaches: traceability and transparency of the evolving design, improved design completeness, and improved knowledge sharing. The paper opens with an introduction to contemporary systems engineering practice, its limitations and the need for MBSE. Then the paper describes an MBSE case study on the ground‐based air missile defence system, which includes SysML model design and development, lessons learnt and insights, and a set of derived research challenges for future research and development.
11.3.1 Set‐based design – the lean tool that eludes us; Pitfalls in implementing set‐based design in Kongsberg Automotive
Authors: Hansen Elisabeth , Muller Gerrit
Published: November 2014

This paper is based on a five month research project performed at the company Kongsberg Automotive (KA). It describes a study of the implementation of set‐based design in project processes in KA, results from the study, and evaluations of these results. The focus has been on knowledge gaps in relation to the implementation of set‐based design. Data has been gathered through observations, discussions with and feedback from employees, interviews and surveys, as well as literature research in order to evaluate the implementation of set‐based design. A set‐based approach has also been used in this research through the development of a set of theories that were investigated in an effort to disprove them or create a basis to support the probability of the theory being correct.

Through this project it has become clear that there are variations in the employees' knowledge on what set‐based design entails. Data show that there is far more agreement on potential goals and benefits of the implementation. This indicates that the employees know where they are going, but that there is some ambiguity as to how to get there. This could be resolved through clarification of the elements of the process and clarification of how the company wants to achieve its goals.