bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.5.1 Extracting Value from Uncertainty: A Methodology for Engineering Systems Design
Authors: Cardin Michel‐Alexandre , Nuttall William J. , de Neufville Richard , Dahlgren John 
Published: November 2014

AbstractDesigners and managers of new investments in engineering systems look for ways to add value to their programs. One fundamental way to do this is by taking advantage of uncertainty. Although uncertainty is usually seen as negative in most investment projects, it can also increase performance if flexibility is incorporated into the system to capture upside opportunities, and reduce losses in case of downside events. This paper introduces a design methodology that adds value to engineering systems by considering flexibility at an early conceptual stage. It provides screening tools to find areas where flexibility can be incorporated at the engineering, operational, and management decision levels. In engineering and operations, technical modifications need to be done within the system to acquire the flexibility exercisable by managers. One example is the ability to expand or contract product output as demand fluctuates. At the management decision level, no explicit modification is needed, such as the ability to abandon the project altogether. The methodology incorporates screening tools based both on qualitative historical studies (GPS, B‐52, etc.) and quantitative Design Structure Matrices representing the engineering system (Bartolomei et al. 2006; Kalligeros 2006; Kalligeros, de Neufville 2006). The design process also provides a set of quantitative tools to assess the financial value of flexibility based on Real Options Analysis and simulation models (de Neufville et al. 2006; Kalligeros 2006; Kalligeros, de Neufville 2006). These give managers and designers discriminating tools with which to choose the most valuable flexibilities to implement in the engineering system. The methodology represents a practical procedure for understanding where flexibility can be found and incorporated into all areas of engineering system design. We present a case application to the design of a new hydrogen production and storage system: Fusion Island (Cardin 2006; Nuttall, et al. 2005).
4.5.3 Defining Military Pilot Training Requirements for 2015+ through the Application of Systems Approaches
Authors: Woodhead M A , Cleveley J W 
Published: November 2014

The current military pilot training system in the UK is struggling to train the required number of pilots economically and to the standard needed by military operations. Several factors are crippling the training including unrealistic training aircraft and a fragmented training structure.Currently there has only been limited structured analysis into pilot training, the current system has blindly evolved from cold war tactics/aircraft and is struggling to adapt to a changing worldThis paper presents a fresh approach to military training by understanding the base requirements and the effect of the changing environment over the medium term (10‐20 years).
4.6.3 A Self‐assessment Scheme and an Evaluation of its Reliability based on ISO 9004:2000
Authors: Hwang Young‐ha , Kim Sang‐hyun , Kim Dong‐young 
Published: November 2014

AbstractThe self‐assessment based on ISO 9004:2000 in quality management system is an important process for the organization that continually improves its performance considering the effectiveness and efficiency of a quality management system. The scheme and process of the internal audit and self‐assessment based on ISO 9001:2000 and ISO 9004:2000 is an issue that continues to demand the attention of researchers in this field. Also, the reliability of self‐assessment results is a remarkable issue. One element of reliability is the extent to which different teams assessing the same project produce similar ratings when presented with the same evidence. This paper presents a self‐assessment scheme conducted during internal audits based on ISO 9004:2000 in Electronics and Telecommunications Research Institute in Korea. Furthermore, this paper evaluates the reliability of a self‐assessment scheme analyzing some results from two assessments between two teams in self‐assessment using Cohen's Kappa coefficient (Cohen 1960, Cohen 1968) and the observed agreement index (Jung 2003). The results indicate that the extent of agreement between the two teams is substantial and the self‐assessment scheme is reliable.
4.6.4 Evolution of Assessment in a Hierarchical Team Project at Final Year Undergraduate Level
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractIn a paper published in an earlier INCOSE symposium the author described a final year undergraduate course in systems engineering from the viewpoint of educational rationale. In this paper the various issues confronted in the teaching of this course are described and the changes made to the course and assessment processes in order to promote the outcomes intended by the lecturer are described. Emphasis is placed on changes implemented in 2006 because of some features of these changes which are interesting with respect to the process of developing the concept of writing a coherent description of an intended system by a large class of undergraduate students. The paper discusses difficulties confronted in the assessment processes, and the link between the assessment processes and the student effort in the teaching of this course.
5.1.1 System Evolution in the Intelligent Enterprise: An Historical Case Study of VISA's Transaction Processing Systems
Authors: Cokus Michael S. , Dahlgren John W. 
Published: November 2014

AbstractIntelligent enterprises need systems which evolve well. Systems will increasingly be expected to evolve to meet users' changing needs, and predicting user demand is becoming more inexact. System engineers need to understand why some systems evolve well and put this knowledge into practice. Lessons learned from the evolution of actual systems should be incorporated into system design and development processes to equip the system engineer to meet this challenge.This paper discusses a case study of the technological evolution of VISA's credit card transaction processing systems. It identifies key principles which were successfully applied to enhance system evolution. The paper discusses observations concerning how generic properties (the illities) relate to one another and how they were achieved in VISA's system design. Related issues of system platforms and component coupling which affect system evolution are also addressed.
5.4.1 The Continued Evolution of Validation: Issues and Answers
Authors: Armstrong James R. 
Published: November 2014

AbstractA case can be made that the most significant change in systems engineering over the last several decades has been the growth of validation along with significant changes in its meaning. Validation has come from nonexistence to being one of the major elements of the discipline. However, this has not happened without issues and challenges that continue today. This paper addresses the changes in the way various standards have reflected the use of validation, how organizations have approached it, and what is currently happening in its practice. This paper identifies several issues and provides approaches to deal with them.
6.1.2 Better use of Design Descriptions to embrace complexity and creativity in Systems Engineering
Authors: Strengers George 
Published: November 2014

AbstractMost Systems Engineering practitioners now have access to Computer Aided Systems Engineering (CASE) tools that greatly assist with the engineering of complex problems. However, the productivity of these tools is often offset by the inability to effectively manage the large amounts of data associated with the system models offered by these engineering tools. As well as better CASE tools to improve productivity and success, we must not forget the role of innovation and creativity as a means of progressing solutions to engineering problems. This paper examines the use of the long standing practice of using ‘design descriptions’ and advocates that we formalize this approach by using Systems Engineering Design Descriptions to manage the engineering complexity and to embrace engineering creativity.
7.5.3 Cultural Models of Organizational Risk in Product Development
Authors: Collins Shawn T 
Published: November 2014

AbstractThis paper uses cognitive domain elicitation methods to explore taxonomies of risk in engineering product development. The paper places typical technologies of risk control within a context of theories that emphasize system‐focused risk identification. Two case studies identify weaknesses in this approach: operator errors in a chemical plant, and pilot error classification on P‐3 aircraft. Shifting the emphasis to user‐focused rather than system‐focused risk identification reveals several key concepts that are missing from the formal theories of risk mitigation. Using numerical analysis from a survey at a small engineering company, the paper explores cognitive anthropology insights regarding the distinction between folk and scientific taxonomies. The results present four significant findings: People who think they disagree with each other don't; experts and non‐experts view risky things differently; despite this difference, non‐experts have a systematic understanding of risky things; and there are verifiable ways to elicit the structure of this understanding.
7.5.4 Controlling Project Risk by Design
Authors: Malotaux Niels 
Published: November 2014

AbstractA lot of risks that plague projects have a high probability to occur: e.g. the risk that we don't deliver the right things or deliver late, and the underlying causes of these problems. This calls for proactively anticipating potential problems and organizing our projects in such a way that the probability of the impact is minimized. The Evolutionary Project Management (Evo) approach is just doing that, constantly being aware of what could go wrong and preventing it going wrong, by design. In stead of assuming a theoretical model of how humans “should” behave, Evo studies actual human behavior and strives to make optimum use of how humans actually behave. Opposing what's in our genes is a lost battle.In this paper we will first investigate prevailing risk management. Then we show how Evo practices are designed to successfully mitigate typical risks in projects. Finally, we spend a few words on how Evo relates to Enterprise Intelligence. The techniques discussed are not merely theoretical ideas, but have been tested, honed and proved by the author in the practice of more than 50 projects in various environments and cultures.
8.1.1 Get Smart
Authors: Hamman Christopher , Mackertich Neal 
Published: November 2014

AbstractIt is becoming evident that in order to effectively compete in an increasingly challenging global marketplace, organizations are going to need to both extend and leverage their established Systems Engineering principles and practices across the entire enterprise. Early returns from an emerging Systems Engineering best practice, Critical Parameter Management, has proven itself highly effective in this regard. Critical Parameter Management is a set of tools, enablers, and best practices for managing, analyzing, and reporting technical product performance by unifying and integrating systems, engineering design, and manufacturing activities. Specifically, the use of a Critical Parameter Management has enabled Enterprise Systems intelligence and decision‐making through: real‐time, sensitivity analyses at the system, subsystem and component levels; efficiently shared technical product documentation and analyses; performance design margins that are statistically managed over the System product lifecycle for their customer and business benefit; and the capturing and leveraging of invested intellectual capital for future business reuse.
8.4.1 Intelligent Operational Scenarios – a Strategy for Cost‐Saving Scenario Selection
Authors: Dam Steven H. 
Published: November 2014

AbstractUse of scenarios or “use cases” is all the rage these days. However, the approach most often used for scenario selection is ad hoc. As a result the list of scenarios can be largely overlapping and can leave gaps in needed capabilities. In this paper we demonstrate an approach to intelligently selecting a series of scenarios that build one upon the other to reach the mission objectives.
9.1.3 Organizational Strategies for Systems Engineering Capability Improvement
Authors: So Maria M. , Andary James F. , Caldwell Melissa 
Published: November 2014

AbstractThere is an increased focus on systems engineering as the key to mission success within the National Aeronautics and Space Administration (NASA). The agency has embraced a systems engineering excellence initiative to enhance the capabilities of systems engineering across the agency. This paper addresses some of the organizational steps that are being taken at the Goddard Space Flight Center to improve the systems engineering capability in support of the Center's programs and projects.
9.3.2 Simulation‐Based Design Using SysML Part 1: A Parametrics Primer
Authors: Peak Russell S. , Burkhart Roger M. , Friedenthal Sanford A. , Wilson Miyako W. , Bajaj Manas , Kim Injoong 
Published: November 2014

AbstractOMG SysML™ is a modeling language for specifying, analyzing, designing, and verifying complex systems. It is a general‐purpose graphical modeling language with computer‐sensible semantics. This Part 1 paper and its Part 2 companion show how SysML supports simulation‐based design (SBD) via tutorial‐like examples. Our target audience is end users wanting to learn about SysML parametrics in general and its applications to engineering design and analysis in particular. We include background on the development of SysML parametrics that may also be useful for other stakeholders (e.g, vendors and researchers).In Part 1 we walk through models of simple objects that progressively introduce SysML parametrics concepts. To enhance understanding by comparison and contrast, we present corresponding models based on composable objects (COBs). The COB knowledge representation has provided a conceptual foundation for SysML parametrics, including executability and validation. We end with sample analysis building blocks (ABBs) from mechanics of materials showing how SysML captures engineering knowledge in a reusable form. Part 2 employs these ABBs in a high diversity mechanical example that integrates computer‐aided design and engineering analysis (CAD/CAE).The object and constraint graph concepts embodied in SysML parametrics and COBs provide modular analysis capabilities based on multi‐directional constraints. These concepts and capabilities provide a semantically rich way to organize and reuse the complex relations and properties that characterize SBD models. Representing relations as non‐causal constraints, which generally accept any valid combination of inputs and outputs, enhances modeling flexibility and expressiveness. We envision SysML becoming a unifying representation of domain‐specific engineering analysis models that include fine‐grain associativity with other domain‐ and system‐level models, ultimately providing fundamental capabilities for next‐generation systems lifecycle management.
9.3.3 Simulation‐Based Design Using SysML Part 2: Celebrating Diversity by Example
Authors: Peak Russell S. , Burkhart Roger M. , Friedenthal Sanford A. , Wilson Miyako W. , Bajaj Manas , Kim Injoong 
Published: November 2014

AbstractThese two companion papers present foundational principles of parametrics in OMG SysML™ and their application to simulation‐based design. Parametrics capabilities have been included in SysML to support integrating engineering analysis with system requirements, behavior, and structure models. This Part 2 paper walks through SysML models for a benchmark tutorial on analysis templates utilizing an airframe system component called a flap linkage. This example highlights how engineering analysis models, such as stress models, are captured in SysML, and then executed by external tools including math solvers and finite element analysis solvers.We summarize the multi‐representation architecture (MRA) method and how its simulation knowledge patterns support computing environments having a diversity of analysis fidelities, physical behaviors, solution methods, and CAD/CAE tools. SysML and composable object (COB) techniques described in Part 1 together provide the MRA with graphical modeling languages, executable parametrics, and reusable, modular, multi‐directional capabilities.We also demonstrate additional SysML modeling concepts, including packages, building block libraries, and requirements‐verification‐simulation interrelationships. Results indicate that SysML offers significant promise as a unifying language for a variety of models—from top‐level system models to discipline‐specific leaf‐level models.
9.4.2 Incorporating Security and Survivability into the System of Systems Architecting
Authors: Singh Atmika , Dagli Cihan 
Published: November 2014

AbstractSystem of systems (SoS) security and survivability issues have found prominence in the wake of increased importance of such large scale interconnected systems. The threats and risks associated with SoS architectures present unique challenges to system architects. SoS security and survivability practices are needed to ensure the performance and survival of the system under an intrusion. Current security engineering activities are performed independent of the system architecting process, leading to ad hoc solutions and after‐the‐fact reactions to vulnerabilities as discussed in (Evans et al. 2005). Literature on security and survivability oriented system architecting activities is far and few in between. This paper studies the major classes of threats and risks associated with SoS and the response to such vulnerabilities. Existing works were researched to outline the key characteristics of an effective security and survivability process that can be integrated with systems engineering activities. Overviews of three survivability architectures are provided on the basis of the identified criteria. Comments on the currently available solutions and future areas of emphasis are presented.
10.1.3 Evaluating Product Development Task Interactions Using Network Analysis
Authors: Collins Shawn , Yassine Ali A. 
Published: November 2014

AbstractThis paper proposes the integration of two useful systems engineering analysis tools, the Design Structure Matrix (DSM) and Network Analysis (NA) to study task interactions in a Product Development Process (PDP) using a small engineering company as a case study. The DSM is a matrix‐based systems engineering tool that enables streamlining of the PDP through task sequencing and simulation of project execution. NA techniques such as key players, centrality, influence, and brokerage provide methods to identify critical product development tasks and interactions to focus PDP improvement. Collecting interactions between product development tasks in matrix form provides opportunities to use DSM and NA techniques to identify highly central tasks and identify patterns of cross‐coupling between tasks and the groups performing those tasks. One benefit is the ability to describe feedback characteristics of critical PDP tasks. This is valuable when evaluating the impact of omitting, combining, or re‐sequencing task execution based on program‐specific constraints.
10.1.4 Systems Engineering for the Intelligent Enterprise – more important than you may think
Authors: Kaffenberger Ruediger 
Published: November 2014

AbstractThe emergence of the intelligent enterprise is very important for all of us, because the classical enterprises that govern the way of our lives are not able to cope with the pace of change we experience. For many systems engineers like me the term “Intelligent Enterprise” is not part of the daily work. Nor do we have a clear idea why Systems Engineering would be the key enabler for the formation and survival of the intelligent enterprise. I will give a short characterization of the intelligent enterprise and the kind of systems engineering required to establish and maintain it.This is my interpretation in classical system engineering terms of some of the information collected in the “knowledge claims” compiled by the INCOSE Intelligent Enterprise Working Group (IEWG 06)
10.2.0 Panel 10.2.0: Integrating Systems Engineering with Program and Project Management
Authors: Ade R. , Mooz H. , Pyster A. , Van Gemert D. , Wartenberg M. 
Published: November 2014

AbstractProgram/project management and systems engineering teams must be tightly integrated or program risk skyrockets. Effective integration demands clarity of roles and underlying competencies, as well as mutually supportive processes, tools, and training. Generally, the best program/project managers have been systems engineers and the best systems engineers have been program/project managers. Career paths should encourage and enable that type of movement. The panel will highlight the diverse ways in which different organizations have approached integration between program/project management and systems engineering and will provide both an entertaining and informative discussion of the tradeoffs between those approaches. Give some thought to how you and your organization approach this topic today, then jot down some questions and bring them with you to the presentation for our panel to address. After you have heard the answers, you can decide how you will change the way you approach Systems Engineering and Project Management.
10.6.0 Panel 10.6.0: Is the Systems Engineering Profession Quantitative Enough?
Authors: Zonnenshain A. , Dori D. , Honour E. , Kasser J. , Malotaux N. 
Published: November 2014

AbstractSystems Engineering (SE) is engineering, and as such it is perceived as quantitative profession. Nonetheless, consider SE to be an art with qualitative methods and intuitive approaches based on little evidence and quantitative data. What is the reality, and what are the possibilities?We think that SE should be based on more quantitative methods, and would like to discuss ways to promote this direction by our discussion in this proposed panel. We will assess several SE aspects by assessing their quantitative/qualititative status. For each topic, we propose how to drive that aspect into more quantitative approaches & techniques. Each short presentation will be followed by participants discussion, to draw further ideas from the audience.We consider the following key topics:
System Architecting – Art or Engineering? –How can we quantify the quality of the architecture?
Modeling & Simulation – as a central quantitative tool for system analysis, but a tool with drawbacks – What are the bounds of M&S?
Quantifying Technical Management– How can we measure technical management? – How much SE is enough? – What is the return on investment?
Capabilities of the Systems Engineer – How can we measure the skill level? – Identifying the Masters from the Journeymen.
How can we measure the quality of the System Design?