bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.5.2 Next Generation Systems Engineering: Expansion, Foundation, Unification
Authors: Hybertson Duane 
Published: November 2014

AbstractThe 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

AbstractLike 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

AbstractHow 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

AbstractCorrelation 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

AbstractThe 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

AbstractSecurity 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

AbstractThis 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

AbstractWhile 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

AbstractHundreds 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

Abstract—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

AbstractThere 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

AbstractWith 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

AbstractScientific 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

AbstractThis 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

AbstractThe 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

AbstractThe 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

AbstractOver 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

AbstractThe 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

AbstractUsually, 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

AbstractIn 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.