bluuebunny/crossref_metadata_2025 huggingface dataset:
2.1.2 Systems Engineering Provides Successful High Temperature Steam Electrolysis Project
Authors: Park Charles V. , Opare Emmanuel Ohene
Published: November 2014

This paper describes two Systems Engineering Studies completed at the Idaho National Laboratory (INL) to support development of the High Temperature Stream Electrolysis (HTSE) process. HTSE produces hydrogen from water using nuclear power and was selected by the Department of Energy (DOE) for integration with the Next Generation Nuclear Plant (NGNP). The first study was a reliability, availability and maintainability (RAM) analysis to identify critical areas for technology development based on available information regarding expected component performance. An HTSE process baseline flowsheet at commercial scale was used as a basis. The NGNP project also established a process and capability to perform future RAM analyses. The analysis identified which components had the greatest impact on HTSE process availability and indicated that the HTSE process could achieve over 90% availability. The second study developed a series of life‐cycle cost estimates for the various scale‐ups required to demonstrate the HTSE process. Both studies were useful in identifying near‐ and long‐term efforts necessary for successful HTSE process deployment. The size of demonstrations to support scale‐up was refined, which is essential to estimate near‐ and long‐term cost and schedule. The life‐cycle funding profile, with high‐level allocations, was identified as the program transitions from experiment scale R&D to engineering scale demonstration.
2.2.2 What is Technical Integrity and How to Measure It?
Authors: Edwards Michael
Published: November 2014

The impact of formal technical regulation and certification frameworks on the technical integrity of complex systems is poorly understood. In researching this problem the author is seeking a means by which to measure technical integrity. Technical integrity is defined and discussed, in both the context of complex systems for the Australian Defence Force and in wider civilian and military contexts. Technical integrity is defined as being composed of two separable attributes that reflect the intended, desired emergent properties of a system and the minimisation of unintended, undesired emergent properties. An approach for formulating a composite measure of technical integrity is developed from this definition and is presented for critical review.
2.4.2 A Framework for Supporting the Transition to Lean Systems Engineering
Authors: Grünwaldt Steffen , Hofstetter Wilfried K. , Palm Herbert
Published: November 2014

Lean Thinking has long been recognized as an important approach to sustainable and comprehensive improvement of products as well as business processes. In the area of systems, the Lean approach is particularly attractive because of its joint improvement of systems engineering effectiveness and efficiency. Yet, to date no comprehensive framework has been put forth for managing the transition to lean systems engineering in a real‐world product development organization engaged in day‐to‐day business. This paper presents a novel 3‐stage framework for managing the transition to Lean Systems Engineering, with special focus on aspects such as lean awareness and target definition as well as active participation of employees and for capability build‐up during the transition phase in order to ensure top‐to‐bottom buy‐in. The framework is based on actual consulting experience of the authors; for three recent example transitions the application of the framework is discussed. Based on these application experiences, a number of significant conclusions with regard to the proposed framework can be drawn covering the effectiveness of people‐related measures, value stream analysis and design activities. Significant opportunities for further work remain, in particular in the areas of further application of the framework, correlation of current and future state scenarios and associated transition strategies with standard management consulting case scenarios as well as further development of lean training exercises for systems engineering methods as applied to product development.
3.1.2 System Verification and Validation through Reliability, Availability, Maintainability (RAM) Analysis & Technology Readiness Levels (TRLs)
Authors: Opare Emmanuel Ohene , Park Charles
Published: November 2014

The Next Generation Nuclear Plant (NGNP) Project, managed by the Idaho National Laboratory (INL), is authored by the Energy Policy Act of 2005, to research, develop, design, construct, and operate a prototype fourth generation nuclear reactor to meet the needs of the 21st Century. A section in this document proposes that the NGNP will provide heat for process heat applications. As with all large projects developing and deploying new technologies, the NGNP is expected to meet high performance and availability targets relative to current state of the art systems and technology. One requirement for the NGNP is to provide heat for the generation of hydrogen for large scale productions and this process heat application is required to be at least 90% or more available relative to other technologies currently on the market.

To reach this goal a RAM Roadmap was developed highlighting the actions to be taken to ensure that various milestones in system development and maturation concurrently meet required availability requirements. Integral to the RAM Roadmap was the use of a RAM analytical/simulation tool which was used to estimate the availability of the system when deployed based on current design configuration and the maturation level of the system.
Organization of 147 Lean Enablers for Systems Engineering into the 26 INCOSE Systems Engineering Processes
Authors: Oppenheim Bohdan , Secor Deborah
Published: November 2014

The organization of 147 Lean Enablers for Systems Engineering into the 26 INCOSE Systems Engineering processes in the INCOSE Handbook will be described. The methodology used will be presented. The organization has been approved by the Lean SE Working Group during the IW meeting. A draft of the new Appendix for the Handbook submitted to the Handbook Working group will be illustrated.
4.2.0 Systems of systems: trends and challenges
Authors: Luzeaux
Published: November 2014

We introduce systems of systems (SoS) with illustrations from various applicative domains (military, space, transportation…).

We discuss the challenges arising in the engineering of such large‐scale complex systems and focus on the specific system engineering issues and the necessary methods and tools.
4.5.2 Next Generation Systems Engineering: Expansion, Foundation, Unification
Authors: Hybertson Duane
Published: November 2014

The field of Systems Engineering (SE) is expanding into new more complex application domains. This paper argues that this expansion needs to be done in a systematic way that requires expansion of the science foundation of SE to provide adequate support of SE expansion and to achieve unification with traditional SE. The paper first discusses the vision of and motivation for next‐generation SE in terms of the characteristics of expansion, foundation, and unification. The remainder of the paper provides a sketch of a proposed approach to achieving the vision, based primarily on model‐orientation. The focus of the sketch is a model‐oriented science of SE.
4.5.3 Niteworks: Systems thinking and methods within a collaboration paradigm
Authors: Wilkinson M K , Evans D E
Published: November 2014

Like many complex enterprises, UK Defence is struggling with a series of frustrating organisational, system and technology problems, including: increasing scale and complexity, increasing need for continuous capability evolution and increasing need to optimise at the system of systems level. Within this context, Niteworks provides flexible decision support to address three priority areas: support to current operations; support to decision making by the Joint Capabilities Board (JCB), and; support to complex acquisition. This paper describes Niteworks' unique collaborative partnership construct that allows UK Ministry of Defence (MOD) and industry engagement in a neutral, consensus‐based, yet agile manner to address a wide range of complex decision support activities. It details the enabling commercial arrangements, the underlying principles for success and a generic decision model. This approach, the ‘Niteworks Way‘, has been designed by applying systems engineering thinking and methods to the Defence Enterprise and Niteworks within it. The approach has been demonstrated to be flexible and responsive by addressing issues across the range of the UK Defence Enterprise. It has also delivered sizeable value to both UK MOD and industry, demonstrating that collaborations can work effectively and that both industry and the MOD can benefit from embracing new concepts and commercial arrangements.
4.6.2 “Are we there yet?” Assessing Quality in Model Based Systems Engineering
Authors: Hause Matthew
Published: November 2014

How do I know that my model is of good quality?“ This question is frequently asked when developing models. This is true whether developing Yourdon, IDEF0, UML, SysML, UPDM, or Lego models. The purpose of the model is to fulfill a need or to answer questions. Consequently, before starting the modeling exercise, one has to determine the questions that need to be answered and assessment criteria. Possibilities include requirements traceability, performance modeling, simulation, behavioral modeling, human factors, etc. Other factors will also affect the scope of the model. Does the model need to capture the complete development lifecycle or product lifecycle? This paper will first examine the concept of quality in general and as applied to modeling. Next we will look at the different reasons for modeling, and some of the corresponding characteristics of quality that can be applied to ensure that the model is of ”good quality“.
5.1.1 A Comparison of Correlation in Technical and Programmatic Risk and Cost Risk
Authors: Krupa Joseph F.
Published: November 2014

Correlation has long been a part of cost risk analysis. Although some risk management guides have indicated that correlations should be considered in technical and programmatic risk analysis, neither a method to include correlation nor an expected impact has been presented. This paper compares and contrasts the impact of correlation on cost risk and technical and programmatic risk, and presents a proposed methodology for implementation and expected results.
5.3.1 Evolution of a Unique Systems Engineering Capability
Authors: Caliva Robert M. , Murphy James A. , Oswald Kyle B.
Published: November 2014

The Idaho National Laboratory (INL) is a science‐based, applied engineering laboratory dedicated to supporting U.S. Department of Energy missions in nuclear and energy research, science, and national security. The INL's Systems Engineering organization supports all of the various programs under this wide array of missions. As with any multifaceted organization, strategic planning is essential to establishing a consistent culture and a value discipline throughout all levels of the enterprise. While an organization can pursue operational excellence, product leadership or customer intimacy, it is extremely difficult to excel or achieve best‐in‐class at all three. In fact, trying to do so has resulted in the demise of a number of organizations given the very intricate balancing act that is necessary. The INL's Systems Engineering Department has chosen to focus on customer intimacy where the customer's needs are first and foremost and a more total solution is the goal. Frequently a total solution requires the employment of specialized tools to manage system complexity. However, it is only after understanding customer needs that tool selection and use would be pursued. This results in using both commercial‐off‐the‐shelf (COTS) tools and, in some cases, requires internal development of specialized tools. This paper describes how a unique systems engineering capability, through the development of customized tools, evolved as a result of this customer‐focused culture. It also addresses the need for a common information model or analysis framework and presents an overview of the tools developed to manage and display relationships between entities, support trade studies through the application of utility theory, and facilitate the development of a technology roadmap to manage system risk and uncertainty.
6.1.0 Is System Security Engineering Failing? If So, What Can System Engineering Do About It?
Authors: Dove Rick , Rhodes Donna , Snoderly John , Baldwin Kristen , Bayuk Jennifer
Published: November 2014

Security for systems of all kinds has become an urgent global concern in the face of increasing attack effectiveness and decreasing security effectiveness – measured simply by increasing losses and penetrations unchecked by increasing security expenditures. Is this a problem with security engineering, systems engineering, or the customer? Is system security strategy broken? Where does remedial action need be taken, and what would that be? Some say it is an economic tradeoff imposed by the customer. Some say it is reliance on ineffective security standards, technologies, and strategies. And some say it is a shortfall of system engineering process, knowledge, and priority. Regardless, systems engineering is responsible for life cycle effectiveness and must recognize, address, and solve this problem in some way—‐ by doing something different. Where is the gap and how does Systems Engineering begin to close it?
7.5.2 Unraveling Systems Engineers from Systems Engineering: frameworks for describing the extent, variety and ambiguity of systems engineering and systems engineers
Authors: Sillitto Hillary
Published: November 2014

This paper addresses a number of long‐running debates about the scope and boundaries of systems engineering, and about competency, specialisation and differentiation of “systems engineers” within these boundaries. Many authors have proposed segmentation of systems engineering based on one or multiple axes of differentiation. Some emphasise the need for “T‐shaped people”, expert in one area of engineering but able to work across many. This paper builds on the existing literature to set out an integrated framework for understanding the internal “flavours” and specialisations of systems engineering, within the overall scope and boundary of systems engineering as defined by the BKCASE SEBOK. The paper is intended to inform senior leaders in systems engineering organisations responsible for organisational and workforce development.
8.1.2 Linking Cognitive Data to Design In Navy Command and Control
Authors: Dominguez Cynthia , Grome Anna , Strouse Robert , Crandall Beth , Nemeth Christopher , O'Connor Matthew
Published: November 2014

While military command and control (C2) systems are intended to support operator cognitive work, current US Navy system engineering processes only capture behavioral‐level tasks. Deployed forces in high threat settings need support for cognitive and macrocognitive work including planning, replanning, sensemaking and situation awareness. We describe a project on behalf of the Navy Expeditionary Combat Command (NECC) to create an approach to system development that reveals and supports cognitive work. Cognitive systems engineering methods, including cognitive task analysis (CTA), have been used to capture operational requirements and translate them into decision and display requirements. Quality critieria for accomplishing this work are presented. The project team has produced initial prototype displays that are suited to two of eleven NECC commands, those with the highest operations tempo and tactical mission requirements.
8.3.1 Psychological Health in the United States Military: Making Sense of What We Know
Authors: Hess John , Kamin Cody , Kenley C. Robert
Published: November 2014

Hundreds of thousands of members of the United States military service are suffering from post‐traumatic stress and other psychological health conditions as a result of their wartime service. A myriad of possible system interventions and resource allocation schemas have been researched and proposed, but finite budgets and personnel levels dictate a careful allocation of resources to optimize outcomes. We describe a stock‐and‐flow model of psychological health treatment tailored to the unique context of the US military's healthcare system. Our model, implemented as a management flight simulator, reports the impact of system interventions on areas of stakeholder concern and is designed to communicate complex systemic behaviors to those without domain‐specific knowledge.
8.6.2 Local Energy Storage as a Decoupling Mechanism for Interdependent Infrastructures
Authors: Kwasinski Alexis
Published: November 2014

—This paper discusses the role of local energy storage in decoupling interdependent infrastructures within a system‐of‐systems. In order to quantify the effect that interdependencies have on a given infrastructure supporting a system that belongs to the system‐of‐systems, its availability is analyzed by dividing failure modes in those originated by system component failures and those caused by external influences to the system, i.e., from interdependencies. The effect that added energy storage has on availability is used in order to evaluate the degree of interdependencies among infrastructures. The analysis focuses on conventional communication sites infrastructure because it present an interesting case of interdependencies with two other infrastructures: roads and a power grid. In this system‐of‐systems, locally stored energy in the form of diesel for a generator set plays an important role in decoupling interdependencies among these three infrastructures. Influence of operational modes are also considered because different operational modes—e.g., continuous operation after a disaster or standby operation in normal conditions—affects the effect of interdependencies on system availability.
9.1.1 Validation: Losing its Differentiation from Verification?
Authors: Armstrong James R.
Published: November 2014

There has been a recent and large shift in the use and emphasis of the term validation in the practice of systems engineering. At the same time, the term has developed a wide variety of definitions and interpretations. As unintended consequence, it has lost some of the emphasis on the real world that it was intended to provide. Since a simple definition that covers all interpretations is not a likely outcome, systems engineers need to understand the breadth of the current usage and the actions to take to avoid missing key components.
9.1.2 An Ontology for Unmanned and Autonomous Systems of Systems Test and Evaluation
Authors: Ferreira Susan , Tejeda Jenny
Published: November 2014

With the advent of unmanned systems and the movement toward greater complexity, the test and evaluation community faces new challenges. This paper presents an ontology for the unmanned and autonomous systems of systems test and evaluation (UASoS T&E) domain that is intended to help support addressing these challenges in T&E. The development of a UASoS T&E ontology provides a means for those interested in the field of UASoS T&E to understand the entities, relationships, and terminology within the domain. The ontology provides a common language and basis of understanding for UASoS T&E that can be leveraged as a foundation for other efforts.
9.3.2 Assurance Cases: A New Form of Requirements Traceability Matrix for Medical Devices
Authors: Eubanks Fritz , Masters Melissa
Published: November 2014

Scientific and medical innovations have led to great improvements and advancements in the lives of people around the world. As technology has progressed so has the complexity of the medical devices that have been created. Not only has the technical complexity increased but additionally, the user interaction with the device has also become more complex and involved. Both of these intricacies have been identified as complicating factors in the safe and effective use of infusion pumps. To this end, the FDA identified an initiative in April of 2010 to address these concerns. One outcome that was identified is the requirement to perform an assurance case. This requirement presents several challenges to practicing medical systems engineers to ensure the assurance case report is complete and assures the device is arguably wholly safe and effective.
10.2.1 An Investigation on the Applicability of DDS Middleware as a Systems Integration Tool
Authors: Do Quoc , Franklin Stephen
Published: November 2014

This paper describes an investigation of the emerging Object Management Group's (OMG) Distributed Data Services (DDS) middleware as an open “infrastructure” solution, and proposes a DDS‐based “Vertical” systems integration approach to address system integration of complex systems. The paper commences with an introduction to the DDS middleware, which is intended to be the underlining communication framework for real‐time distributed mission critical systems. The paper then describes the proposed “vertical” systems integration approach and where it fits into the systems engineering lifecycle in the Australian defence context. The investigation extends to include a case study using an in‐house Systems Integration Sandpit (SIS) – Robotic Surveillance System. The case study aims to investigate the ease and efficiency of integrating the existing communication framework of the selected system into a DDS‐based communication architecture. The paper further discusses lessons learned and insights captured during the conduct of the study, and outlines further research and development.
11.1.1 SOA in Enterprise Architectures: Overlooked Misperceptions, Pitfalls and Tangible Benefits
Authors: Rallapalli Murthy V.
Published: November 2014

The SOA (Service Oriented Architecture) is an evolution of past platforms, leveraging the successful characteristics of traditional architectures over several decades. The contemporary and the evolving standards of SOA advocate an agile, flexible software architecture leveraging Web services. Enterprise software has long suffered from a mismatch between technical and business‐related concepts and priorities articulated by the people on both sides of the techno‐business domain. SOA provides a unique opportunity for the first time in IT terms to create artifacts that have lasting impact and value for both the business as well as the technology side. The SOA relies heavily on loose coupling in order to establish an abstraction of business logic and technology. Achieving a state of standardized SOA throughout an enterprise requires a planned transition. SOA offer benefits at several levels, ranging from agnostic technology to a simplification of the development process to an increase in agility of the business infrastructure. The ultimate goal of an SOA is to provide an Agile Enterprise, in which all processes and services are completely flexible and can be rapidly manipulated per the needs of business. However, the SOA is a journey and not a single “switch on” implementation. With each SOA implementation, there are several lessons learned that can be leveraged for future. This paper reviews the pitfalls and tangible benefits of SOA implementation in enterprise architectures. In addition, this paper addresses the common misperceptions about SOA that are commonly maintained in the market place and in some cases, even legitimizing them.
11.1.2 SpaceESB – A Proposal of an Enterprise Service Bus for Spacecraft Conceptual Design
Authors: De Souza Ariana C. Caetano , Santos Walter A. Dos
Published: November 2014

The conceptual design of space systems may become extremely complex and usually demand a multidisciplinary team working together in order to effectively coalesce into a successful architectural design. However, due to pressure on cost and time, many space projects nowadays demand a cloud enabled environment as they undergo their development divided among several project partners, sometimes temporally and geographically separated hampering the information exchange and causing adding risks to its conception. This paper proposes an enterprise bus service (ESB), named SpaceESB, to realize this distributed environment by exposing the various processes of space mission conceptual phase using a Service‐Oriented Architecture (SOA) paradigm. As an example, a simple service related to propellant mass estimation is characterized by using BPMN (Business Process Modeling Notation) and Business Process Execution Language (BPEL). Its SOA materialization is implemented via a Java Web Service and its WSDL (Web Service Definition Language) provided as an interface to the SpaceESB.
11.2.1 Project Validation “The New Way to Secure Target Fulfilment in Project”
Authors: Cuklev Sasko , Lindgren Carsten , Johnsson Ronny
Published: November 2014

Over the years a lot of projects have failed when it comes to deliver products in cost, time, and quality and according to customer needs. To solve this Volvo introduced a new process called Project Validation. It contributes to a better target fulfilment and a more effective project management. Focus is on the early phases of the project, to set the scope of the project properly and that all involved have the same view of what the project is about. For the project planning and project follow‐up focus is on deliverables connected to the requirements and not the more traditional activities done at a specific time.

The effects that we have experienced from Project Validation is that there is a stronger focus to deliver the product that the customers want and that we identify problem areas early in the project and by that eliminate late costly and time consuming changes. We also get a holistic view of the project and a better transparency and commitment within the organization.

It is a simple tool, easy to learn and for us a way to get more effective.
11.2.2 Reducing the Gap Between Formal and Informal Worlds in Automotive Safety‐Critical Systems
Authors: Chalé HugoG. , Taofifenua Ofaina , Gaudré Thierry , Topa Alexandra , Lévy Nicole , Boulanger Jean‐Louis
Published: November 2014

The upcoming ISO26262 standard, which deals with the functional safety of road vehicles, will induce car manufacturers to adapt the way in which vehicle systems are usually developed. To achieve this, more rigorous development processes along with new tools and techniques will most certainly be necessary. This paper presents an overview of current initiatives at Renault dealing with the improvement of development processes for mechatronic systems to comply with ISO 26262. It focuses on introducing more formalization in the systems engineering design process via the definition of an ontology to formalize the concepts and knowledge of the systems engineering, functional safety and automotive specialty domains (e.g. braking, energy management). The ontology is at the heart of our improvement initiatives since it allows establishing logical consistency of the whole design process. A regenerative hybrid braking system integrated into a full electrical vehicle will serve as the case study for the evaluation of the improvements made possible by the approach.
11.4.0 PEOPLE OR PROCESS: WHICH IS MORE IMPORTANT?
Authors: Zonnenshain Avigdor , Sillitto Hillary , Kasser Joseph
Published: November 2014

Usually, systems engineering is perceived as process oriented.

Systems engineering standards (ISO 15288, ANSI/EIA‐632, IEEE‐120, MIL‐STD 499C & CMMi) are all focused on processes.

The implied claim is that by implementing effective SE processes, it is possible to create good system designs even with mediocre systems engineers.

Yet INCOSE also supports a top‐notch certification program to identify the highly‐qualified systems engineers as CSEP and ESEP.

The implied claim of certification is that effective systems engineering can be gained only by having effective people, the experienced systems engineers. This panel discusses the important and sensitive dilemma: to be people oriented? Or to be process oriented?

The proposed questions to be discussed by the panelists are:

Can we achieve successful system design by applying only effective systems engineering processes?

Can we achieve successful systems design by effective systems engineers even though the systems engineering in situation when processes are poor?

How can effective systems engineers be used in organizations where the processes are well developed and well documented?

Do well defined systems engineering processes suppress the creativity & innovation of the systems engineers?

How to select, recruit, educate & develop effective systems engineers?

Is there a “golden rule” how to integrate systems engineers with processes for successful systems design & engineering?
On Principles of Complex Systems Engineering—Complex Systems Made Simple
Authors: White Brian E.
Published: November 2014

In systems engineering (SE) activity in System of Systems (SoS), Enterprise Systems Engineering (ESE), and Complex Systems Engineering (CSE) continues to increase. There is controversy as to how well conventional methods of SE are able to handle our most difficult complex systems problems, and whether new ways of systems thinking will help. This tutorial will: 1) explain and give examples of complex systems and CSE; 2) review related definitions and terminology; 3) present CSE principles to create mindsets that will accelerate progress in your application domains; 4) provide tools for characterizing SE environments and what is being doing about it; and 5) suggest a methodology for CSE. Teamed class exercises will stimulate creative thought and interactions among participants. The presentation materials and accompanying discussions should deepen our understanding of SE and better prepare us for future SE endeavors.
Systems Architecting: a Business Perspective
Authors: Muller Gerrit
Published: November 2014

System architects play an integrating role between many specialized engineers and other stakeholders during the creation of new systems. The role of system architect requires a broad set of skills. How do you cope with conflicting needs, opinions, and interests? How do you lead the design team effectively? How do you balance innovation and risk mitigation, installed base and new systems, short term and long term? How do you share vision and make pragmatic choices at the same time?

This tutorial focuses at the less technical aspects of systems architecting. The program is based on one of the basic working methods of an architect: viewpoint hopping. The tutorial addresses systems architecting from ten different viewpoints.

Objective of the tutorial is to teach system engineers and architects methods and techniques function effectively in multi‐disciplinary design environments with lots of stakeholders. It teaches project leaders and other close stakeholders of the architect what to expect from the architect and how to interact with architects.

All information (System Architecture articles, course material, curriculum vitae) can be found at: Gaudí systems architecting http://www.gaudisite.nl/
Simple Techniques for Applying Systems Engineering Principles When You're New to the Game
Authors: Hamelin R. Douglas , Caliva Robert M. , Park Charles , Braase Lori
Published: November 2014

Many SE practitioners, particularly those who are new to the discipline, can become overwhelmed by the high‐end tools and techniques often viewed as necessary for conducting “real” systems engineering. Even though such tools and techniques are common in our applications of systems engineering, INL systems engineers have a long history of using simple, tailored methods to achieve significant success on complex projects. This half‐day (4‐hour) tutorial is designed to introduce new‐comers and seasoned practitioners alike to the overall systems engineering process as it relates to typical project life‐cycle phases and to present a few of the “simple” tools (with practical examples) that we have found useful in conducting systems engineering work. Ultimately, attendees will learn how to use items as simple as a white board, pad of engineering paper, and standard desktop software to help a project get from concept to system design without the need for high‐end tools and technologies.
Requirements Engineering for Large Scale Systems: Processes and Tooling
Authors: Berenbach Brian , Worl John
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 projects, and describe how to setup processes and tooling to support them. This is part one of a two part tutorial. This session describes how to set up processes and tooling for very large industrial projects, typically dealing with 50 thousand or more requirements. The second 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.
What Forest? All I See are these SE Trees!
Authors: Powell Mark A.
Published: November 2014

Far too often we Systems Engineers work intensely in one single activity area of SE, usually for long periods. Perhaps we work requirements, or verification, or maybe even the engineering specialties, for months or maybe even years. It is easy to get consumed in the job. It is easy to lose sight of exactly why we do these specific jobs as SE's, and why we do them the way we do. We can lose sight of how our specific job contributes to the success of the project. SE then just becomes another job. But it is not just another job – it is the most important job for any project.

This half day tutorial is based on a 20 hour SE refresher course that has been taught to practicing SE's ranging from fresh college grads to grizzled and gray SE veterans. It addresses all of the major areas of SE, but with a twist – we focus on the “why” we do the things the way we do in SE, what was the lesson learned, and how it contributes to project success. For the fresh grad taking this tutorial, all of things we do in SE will make sense, fit together in a nice neat package, and will seem obvious. For the veteran, this tutorial will re‐ground and renew their spirit. Almost all SE veterans who have taken the refresher course report that they perform better in their jobs, and more importantly, they are a lot happier doing their SE job.
Scenario‐based requirements engineering facilitating interaction design
Authors: Kaindl Hermann
Published: November 2014

When the requirements and the interaction design of a system are separated, they will most likely not fit together, and the resulting system will be less than optimal. Even if all the real needs are covered in the requirements and also implemented, errors may be induced by human‐computer interaction through a bad interaction design and its resulting user interface. Such a system may even not be used at all. Alternatively, a great user interface of a system with features that are not required will not be very useful as well.

Therefore, the primary motivation of this tutorial is to improve system development in practice both regarding requirements engineering and interaction design, especially facilitating the latter. We argue for combined requirements engineering and interaction design, primarily based on usage scenarios in the sense of sequences of actions aimed at accomplishing some task goal. However, scenario‐based approaches vary especially with regard to their use, e.g., employing abstract use cases or integrating scenarios with functions and goals in a systematic design process. So, the key issue to be addressed is how to combine different approaches, e.g., in scenario‐based development, so that the result is an overall useful and useable system. In particular, scenarios are very helpful for purposes of usability as well.
Systems Architecting and Program Management with the Design Structure Matrix (DSM)
Authors: Browning Tyson R.
Published: November 2014

The design structure matrix (DSM) is a powerful tool for visualizing, analyzing, innovating, and improving systems, including product architectures, organizational structures, and process flows.

Akin to a traditional N2 chart and the System‐System matrix (SV‐3) in the DoD Architecture Framework (DoDAF), the DSM is a square matrix showing relationships between system elements. These elements can be product components, teams, activities, etc. By analyzing the DSM, one can prescribe a better (e.g., more modular) system architecture or organization. Adding a time‐basis enables one to prescribe a faster, lower‐risk process. Because the DSM highlights process feedbacks, it helps identify iterations and rework loops—key drivers of cost and schedule risk.

The DSM is concise, visually appealing, and used in many organizations across diverse industries. Users have found DSM extremely useful for fostering architectural innovation and enabling the situation awareness and empowerment that motivates the people executing complex processes. This tutorial introduces the DSM and three distinctive applications useful to product developers, systems engineers, and project and program managers. Real‐life examples are presented from the aerospace, automotive, semiconductor, and other industries. Participants will engage in hands‐on exercises (building DSM models) and come away with a clearer understanding of the drivers of critical, emergent behaviors in systems. The methods can be applied immediately to projects for quick results and insights.
Engineering Requirements in Product Lines
Authors: Mannion Mike , Kaindl Hermann
Published: November 2014

New product development is a usually a compromise between customer requirements, existing product architectural constraints and commercial needs. Many product innovations are cost‐effective extensions within a product line, and draw on a deep knowledge of existing processes, products or services. In this tutorial we describe how requirements for a product line can be modelled, selected and reused to engineer the requirements for innovative new products. Critical issues are the engineering of requirements commonality and variability across different products, the management of inter‐dependencies between reusable requirements during selection, the constraints placed upon these selections by existing architectures, and being able to manage each of these issues when the number of requirements is very large. We address these concerns, present results of using these techniques, and describe some software tools that can be used to support them.
Thinking Outside the Box ‐ In Systems Engineering and Integration
Authors: Eisner Howard
Published: November 2014

Building large and complex systems continues to be a significant challenge for today's systems engineers and integrators. This tutorial sets forth new ways of thinking that could lead to improvements in how systems engineering and integration are carried out. In particular, nine new perspectives are suggested for “thinking outside the box”. Examples are provided for each, along with a discussion of their potential benefits. In addition, thinking in groups as well as historical thinking suggestions are examined. A summary provides an overview of notions that represent departures from current mainstream approaches.
Systems Engineering for Advanced Manufacturing: Unit Op Insights from Model‐Based Methods
Authors: Schindel William D.
Published: November 2014

Innovative manufacturers, pursuing competitive advantage, increasingly push the envelope of production system complexity. Advanced manufacturing applies materials science, chemistry, thermodynamics, biology, information technologies, and engineering disciplines. Historically a pragmatic domain respecting intuition, experience, and judgment, manufacturing increasingly demands scientifically‐based mastery of the systemic properties of interacting processes, materials, and products. Stable and predictable performance is expected across technology transfers and changes in recipes. Customers, owners, and regulators press traditional process engineering and specialized disciplines to integrate more deeply, producing “Quality by Design” outcomes, faster, at lower costs.

This paper describes a novel model‐based method focused on unit manufacturing operations and their integration into production cells, lines, and facilities. Modeling what occurs during transformations, these science‐based descriptions move beyond Process Flow Diagram (PFDs) to represent, independent of equipment design, interdependencies of materials, processes, equipment, and control strategies—automated or human. This approach has improved integrating insight across diverse manufacturing processes.
Identifying Agile Security Patterns in Adversarial Stigmergic Systems
Authors: Lugosky Jena , Dove Rick
Published: November 2014

System adversarial communities appear to exhibit characteristics of natural agile systems, and enjoy an advantage as a result over static systems that are the focus of their attacks. A project started in graduate courses at Stevens Institute of Technology and currently pursued by the International Council on Systems Engineering Working Group on Systems Security Engineering works under the premise that security strategy will benefit by architectural patterns that are equally self organizing. To that end a pattern cataloging project is in process, identifying fundamental self organizing patterns that can explain the adversary operational modes and inform next generation security strategy. This article advances that pattern project by exploring and capturing the stigmergic communication employed by system‐adversarial communities according to the pattern project guidelines. This article first identifies the unique stigmergic pattern, explores its nuances, and presents it in a format identified by the pattern project. Then the stigmergic pattern is applied as a mold to analyze a series of three systems in an effort to regard each within a familiar context. Three adversarial systems, the Iraqi Insurgency, IED Networks and Cybercrime, were selected as prominent opponents that provide significant consternation to security experts. They are first identified as agile systems, per characteristics defined by the pattern project, then studied in the context of the stigmergic pattern.
Stakeholder Approach to Better Understand the Psychological Health Services in the Military
Authors: Ippolito Andrea , Srinivasan Jayakanth
Published: November 2014

Ensuring the psychological well‐being of service members and their families has emerged as one of the principal challenges of today's armed services. Given that the system of care of psychological health services in the United States Military cannot be divorced from the large healthcare delivery system, an enterprise perspective is needed to truly understand the dynamics of care. This paper makes two key contributions: it identifies the key stakeholders of the military health enterprise with respect to psychological health, and analyzes the espoused senior leadership values over the last decade as seen in the stakeholder reports. This stakeholder analysis highlights the challenges faced in melding the constituent organizations into an enterprise, especially in the face of leadership turnover. The thematic analysis of senior leadership values shows an evolution of focus from managing execution of care to emphasizing healthy lifestyles and psychological health.
1.1.3 Need for Robust Systems Engineering in a Time of Budget Austerity
Authors: Rosenthal Rich , Sheard Sarah , Neuendorf William F.
Published: November 2014

Today's larger, more complex systems are riskier than before, with dire consequences if they fail. This paper makes the case that systems engineering is needed now more than in the past, and it would be a mistake to reduce funding for systems engineering at the same time that national security programs in general are being reduced.

Systems engineering helps improve decision making under conditions of uncertainty and complexity, using a combination of proven and new tools. Systems engineering orchestrates integration among disciplines and subsystems using collaborative tools such as integrative review. Systems engineering supports new acquisition models such as incremental commitment by implementing enterprise architecture roadmaps and recommending new technology to improve capability. Model‐based systems engineering leads to lower cost, improved capability, lower risks, and improved defenses against attack.

Systems engineers are learning techniques from complexity science such as hierarchical and modular design, prevention of failures from unintended consequences, and analysis of power law characteristics in complex systems. The paper discusses these concepts to show the importance of maintaining systems engineering in the face of budget austerity.
1.3.3 Systems of Innovation I: Summary Models of SOI Health and Pathologies
Authors: Beihoff Bruce C. , Schindel William D.
Published: November 2014

Innovation is critical to viability in changing environments. In living ecosystems, innovation adapts to changes by predators, prey, and the rest of the environment (e.g., geology). For engineered systems, innovation exploits market interests in new capabilities, creates new markets, develops competitive advantage, and adapts to changes in technologies, infrastructure, regulations, and commercial environment.

In all these domains, the process of innovation may itself be described as a system—the System of Innovation, and studied by natural scientists, engineers, and technologists. The relative effectiveness of different systems of innovation impacts the competitive viability of the resulting series of innovated systems.

Modeling pathologies improves understanding of healthy systems, assessment of effectiveness, and ability to prevent or correct pathologies. “System pathologists” are found in medicine, field support and maintenance organizations, agriculture, the natural sciences, and other domains. This work is concerned with modeling Systems of Innovation, including characterizing their pathologies and health.
1.4.1 Program Accreditation and the Graduate Reference Curriculum in Systems Engineering (GRCSE™)
Authors: Olwell David H. , Enck Stephanie , Hutchison Nicole , Pyster Art , Anthony James
Published: November 2014

This paper discusses the possible use of the Graduate Reference Curriculum for Systems Engineering (GRCSE) to inform engineering accreditation efforts. The paper is organized as follows: The first section provides background on the genesis of GRCSE. The second section discusses the status of accreditation of systems engineering in the United States and Europe. The third section discusses the objectives, outcomes, and core body of knowledge contained in GRCSE. The last section concludes with a discussion of how the GRCSE work might be expected to influence future accreditation.