bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.1.3 Expert‐Based Single Point Failure Analysis
Authors: Baladi Jean Y. , Hendrix James L. 
Published: November 2014

AbstractA single point failure analysis was performed on major equipment of four facilities of the Accelerated Transuranic Waste Remediation Program at the DOE Savannah River Site. The objective was to identify critical equipment whose failure can stop work and result in unacceptable schedule delay and repair cost and to recommend pre‐emptive actions to reduce these impacts. It was an expert based analysis performed by teams of subject matter experts following a systematic process to ensure that all major equipment is included and cost effective recommendations are developed and prioritized. Eighty five systems were analyzed, and two were found to present a potential for single point failure. Acquiring replacement parts for the three most critical components of each system would considerably reduce failure impacts and, therefore, was recommended. This study demonstrates the power of utilizing collective professional judgment of teams of subject matter experts in a systematic process to promptly identify failure vulnerability and reduce its impacts.
4.3.3 Satellites to Supply Chains, Energy to Finance —SLIM for Model‐Based Systems Engineering
Authors: Bajaj Manas , Zwemer Dirk , Peak Russell , Phung Alex , Scott Andrew , Wilson Miyako 
Published: November 2014

AbstractDevelopment of complex systems is a collaborative effort spanning disciplines, teams, processes, software tools, and modeling formalisms. Increasing system complexity, reduction in available resources, globalized and competitive supply chains, and volatile market forces necessitate that a unified model‐based systems engineering environment replace ad‐hoc, document‐centric and point‐to‐point environments in organizations developing complex systems.To address this challenge, we envision SLIM—a collaborative, model‐based systems engineering workspace for realizing next‐generation complex systems. SLIM uses SysML to represent the front‐end conceptual abstraction of a system that can “co‐evolve” with the underlying fine‐grained connections to models in discipline‐specific tools and standards. With SLIM, system engineers can drive automated requirements verification, system simulations, trade studies and optimization, risk analyses, design reviews, system verification and validation, and other key systems engineering tasks from the earliest stages of development directly from the SysML‐based system model. SLIM provides analysis tools that are independent of any systems engineering methodology, and integration tools that connect SysML with a wide variety of COTS and in‐house design and simulation tools.We are presenting SLIM and its applications in two papers. In Part 1 paper—Motivation and Concept of SLIM—we presented the motivation and challenges that led to SLIM, the conceptual architecture of SLIM, and SLIM tools available for production and evaluation usage. In Part 2 (this paper), we present the applications of SLIM tools to a variety of domains, both in traditional as well as non‐traditional domains of systems engineering. Representative SysML models and results of trade studies, risk analysis, and other system engineering tasks performed using SLIM tools are presented for the following domains—space systems, energy systems, infrastructure systems, manufacturing and supply chain systems, military operations, and bank systems.
5.1.2 Triple Your Chances of Project Success Risk and Requirements
Authors: Wheatcraft Louis S. 
Published: November 2014

AbstractRequirements have a big impact on project success. Studies show the importance of having a good set of requirements that are clear, complete, correct, and consistent as well as the consequences of not having a good set of requirements. Having poor requirements places projects at risk of significant cost overruns, schedule delays, and performance shortfalls. In fact, recent studies have shown that projects who fail to take effective actions to ensure a good set of requirements triple their chances of project failure. The emphasis of this paper is to identify common requirement development and management risks that can have an impact on a project's success, possible consequences of these risks, and strategies to mitigate the risks and avoid the consequences of those risks. Recognizing the fact that poor requirements represent a significant risk to your project and mitigating these risks can triple your chances of project success.
5.2.2 Examining Survivability of Systems of Systems
Authors: Mekdeci Brian , Ross Adam M. , Rhodes Donna H. , Hastings Daniel E. 
Published: November 2014

AbstractPrevious research has identified design principles that enable survivability for systems, but it is unclear if these principles are appropriate and sufficient for systems of systems as well. This paper presents a preliminary examination of how some of the characteristic properties of systems of systems may enable or hinder survivability, based on existing design principles and a newly proposed taxonomy of disturbances. Two new design principles, defensive posture and adaptation, are introduced. The next phase of research will be to conduct empirical studies to validate the design principles against some of the characteristic properties of systems of systems, and test hypotheses about how survivability will be affected.
5.3.2 Integrating the Life‐cycle Process Utilizing SysML
Authors: Artery Georgia , De Spain Mark 
Published: November 2014

AbstractSandia National Laboratories is developing and applying an Integrated Phase Gate (IPG) project structure to execute critical programs such as nuclear weapon Life Extension Projects (LEP) that require the utmost attention to reliability, function and other stakeholder requirements including safety and security. This emphasis on project rigor reflects a new directive from the Department of Energy's National Nuclear Security Agency (NNSA) to develop robust processes in order to ensure that the nation's nuclear deterrence will be effective and available for decades to come. To this end, Sandia's Advanced and Exploratory Systems Department is developing a SysML model of an integrated Product Lifecycle Management (PLM) environment with the intent of providing project teams with direct access to program templates, requirements, tools (both program and technical) and related databases. This paper will describe the current state and future direction of the integrated PLM environment SysML model.
5.4.1 Would the real systems engineer please stand up?
Authors: Kemp Duncan , Mollett Jennifer 
Published: November 2014

AbstractThe conventional systems engineering process (as defined in ISO 15288 or the INCOSE SE handbook) assumes that projects start with a defined requirement or problem statement and end with contract acceptance or in‐service validation. This has led to a belief by some in industry that the role of systems engineers within client organisations is kicking‐off and accepting well formed programmes for industry to deliver. Whilst this is an important role, it is not the only part of the client side systems engineer's job.This paper describes the activities that systems engineers do when working for the client such as government, a transport service company or an information services company. Far from just playing a peripheral role in product systems engineering, the client side systems engineer is involved in:
Capability systems engineering ‐ identifying, developing and integrating systems and services to realise operational capability
Service systems engineering – integrating existing and newly delivered systems to deliver operational services
Enterprise systems engineering – redesigning their organisations to improve organisational performance or reduce costs
This paper describes these different systems engineering disciplines and draws comparisons between the types of systems engineering needed to deliver capabilities, services and enterprises and the more familiar approaches needed to deliver products (included at Annex A). The paper examines the different tools, processes, people and relationships needed to undertake these different types of systems engineering, in particular comparing them to conventional product systems engineering. Additionally, the paper introduces a framework within which the different types of systems engineering can be evaluated.
5.5.0 Undergraduate SE Programs
Authors: Good Mary , McCarthy Dan , Nowlin Scott 
Published: November 2014

AbstractOpinions differ widely on the merits of offering an undergraduate program in systems engineering. This session will present a panel discussion of the benefits and challenges of offering such a program from three schools that currently do. The objectives and outcomes for an undergraduate program differ substantially from graduate programs, and understanding these differences goes a long way towards reconciling opinions about undergraduate programs. A few other topics will be discussed to support that theme, including different approaches to the senior capstone project, the particular challenges of integrating with other engineering programs on campus, and securing appropriate resources. The audience will be invited to participate in an extended floor discussion.
5.6.2 Attribute‐Oriented Modeling Approach and Its Application to Modeling of Spacecraft Functions
Authors: Yamada Takahiro 
Published: November 2014

AbstractModel‐Based Systems Engineering (MBSE) uses models as a central and governing role in the specification, design, integration, validation, and operation of a system. If models are used in the development of a system, it can reduce ambiguity of information that exists in the document‐based methodology and facilitate sharing of engineering information among different participants involved in the development of the system. There are standard languages like the Unified Modeling Language (UML) or the Systems Modeling Language (SysML) and software tools that facilitate developing of models.One of the problems in MBSE is that it is usually the case that different engineers come up with different models even if the same system is modeled and a standard language like UML or SysML is used. This is because there is no standard that specifies what kinds of components in the system should be represented with what kinds of standard modeling elements defined in UML or SysML.In order to solve this problem, this paper proposes a new approach to modeling of systems. This approach is called the “Attribute‐Oriented Modeling (AOM)” approach. The AOM should be used with a standard modeling language like UML or SysML, not instead of them. The central concept of AOM is that types of model elements used in models of systems should be defined with a set of attributes that the system components to be modeled possess. By using this approach, a system is always modeled in the same way no matter who models the system. Furthermore, by using the fact that systems in a particular domain are always modeled in the same way, we can develop generic application programs that can process any model in that domain. This will further promote the utilization of MBSE.
6.2.2 A Framework for Considering Cost Uncertainty for Complex Interdependent Systems Based on Weighted Nodal Analysis
Authors: Healy Barry , Mazzuchi Thomas A. , Sarkani Shahram 
Published: November 2014

AbstractNetworks, which are formed due to interdependencies between actors, have become a critical component of United States (U.S.) Department of Defense (DoD) programs. “We are no longer network enabled. We are now network dependent” (Report of the Defense Science Board Task Force on Achieving Interoperability in a Net‐Centric Environment, 2009). U.S. DoD would significantly benefit from quantitative research that supports implementing improvements on establishing cost estimates and improved risk management analysis of these systems. This study defines a methodology for objectively assessing program interdependencies in a way that enables analyzers an improved method to more accurately estimate uncertainties associated with complex DoD interoperability cost assessments.
6.4.1 Tailoring the Systems Engineering Life Cycles: Goal Oriented Engineering Phasing
Authors: Bosch ir. R.M. , Brouwer ir. P. 
Published: November 2014

AbstractAll too often engineering products are created ‘because we always do so’. Projects phases are introduced without questioning the utility, designs are being detailed without connecting to the decision process, or the preliminary research is badly matching the designers' needs. So, a big part of the systems engineers role is not only the engineering itself, but matching the engineering process with the project at hand and the goals that must be fulfilled at each design stage. In this paper, we will discuss the tailoring of the typical System Engineering life cycle and project stages onto the life cycle processes of a project at ProRail, the Dutch railway infrastructure provider. ProRail is a major government procurement organization, with revenues of over € 2,000,000,000. Typical projects range from € 100,000 to over € 100,000,000. ProRail has a large legacy system deployed, dating back over 150 years to the first railways in The Netherlands.
7.3.1 A Model for Consumer Product Development from a Systems Perspective
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractSystems engineering, as a field of practice, has been confronting the issue of extension into the commercial sector. Systems engineering is routinely used in some sectors, notably defense, aerospace and other government acquisition domains. Commercial industry, particularly in consumer products, which values rapid development of products and the minimization of any activity which is perceived as “overhead”, has not expressed much interest in systems engineering as a product development methodology. “Innovation” is a concept commonly associated with the interests of commercial industry. The focus in innovation is to develop new product systems of new kinds in order to generate and exploit market opportunities. Innovation is an activity which has been studied in its own right. One particular model of innovation is the W‐model which has similar form to the V‐model of systems engineering. This paper explores the similarities of the W‐model of innovation and V‐model of systems engineering to expose the synergy of systems engineering and the core interest of commercial industry in innovation.
7.3.2 Assessment of Readiness for Internal Technology Transfer – A Case Study
Authors: Stig Daniel Corin , Högman Ulf , Bergsjö Dag 
Published: November 2014

AbstractPremature introduction of new technologies in product development is likely to lead to both budget and schedule overruns. The assessment of when a technology is ready to be transferred from technology development to product development and production is critical for striking the right balance of short time‐to‐market and low risk. Previous research on internal technology transfer has mainly focused on the development of methods and tools for assessing technology readiness for major development programs in governmental agencies, revealing few cases of such implementations in technology driven industrial companies. This paper aims to provide description of experiences from using such tools at a case company and prescription on how to manage the identified challenges. The study is based on 22 semi‐structured interviews, primarily with personnel from the technology and product development departments. The results indicate that the readiness assessments suggested in literature can support decisions also in industrial companies. However, adapting the tools to the internal differences between technologies is important for minimizing administrative workload and ensuring implementation readiness as opposed to just technology readiness. The strategy for their adaptation could benefit from more research on the practices of companies dealing with internal technology transfer and from the development of a framework for how to adapt the assessment process to different contexts.
7.3.3 ‘That wasn't meant to happen!‘ Managing the hidden risks of system novelty
Authors: Holt Jonathan E. , Beasley Richard 
Published: November 2014

AbstractThe introduction of new technology is a major challenge ‐ probably the major challenge ‐ for organisations such as Rolls‐Royce whose business is developing and maintaining complex systems. In competitive market conditions, an organisation which takes a too conservative approach will fall behind in the introduction of new technology and quickly lose market share. On the other hand an organisation which fails to understand and manage the risks associated with the introduction of new technology can face ballooning development costs, significant delays and major customer dissatisfaction.The TRL scale is now widely used, but if ‘new technology’ is viewed only at a component level, the risks engendered in integrating novel systems, perhaps combining mature components for novel purposes, will be underestimated.This paper describes recent progress within Rolls‐Royce in applying systems thinking to the integration of system level innovation into products, explaining that thinking, describing some process improvements and illustrating by way of two examples.
7.5.3 Unifying systems engineering: Seven principles for systems engineered solution systems
Authors: Kasser Joseph , Hitchins Derek K. 
Published: November 2014

AbstractSystems engineering is presently demonstrating the characteristics of being in the emerging stages of a discipline. A discipline generally matures when an overriding axiom is presented and accepted by the majority of practitioners. This paper presents one such high level underpinning axiom for systems engineering that has the potential to unite the disparate camps within systems engineering and enable the practice of systems engineering in all application domains to achieve successes similar to those it achieved in the National Aeronautical and Aerospace (NASA) environment in the 1960's and 1970's. The axiom does this by focusing on the solution system rather than on systems engineering.
7.6.1 Monitoring and Management Approach for Cyber Security Events over Complex Systems
Authors: Hershey Paul C. , Silio Charles B. 
Published: November 2014

Abstract– DoD, agency and commercial operations centers that manage complex enterprise systems face the problem of protecting both the systems and the data they carry against cyber attacks while, at the same time, providing high quality end‐to‐end services that meet service level agreements and help ensure mission success. Presently there exists no comprehensive tool suite that encompasses the procedures, methods, and policies to provide an effective enterprise cyber security monitoring and management solution. This paper provides a basis from which to fill that void by introducing a new framework for monitoring and managing cyber security events in complex systems. We demonstrate application of this framework using several realistic scenarios.
7.6.2 Computing the Impact of Cyber Attacks on Complex Missions
Authors: Musman Scott , Tanner Mike , Temin Aaron , Elsaesser Evan , Loren Lewis 
Published: November 2014

Abstract—This paper describes how to evaluate the impact of a cyber attack on a mission. We accomplish this by computing impact as the changes to mission measures of effectiveness, based on the reported effects of a known or suspected attack on one or more parts of the information technology (IT) supporting the mission. Our previous papers have described our goals for computing mission impact and the choices of the techniques we use for modeling missions, IT, and cyber attacks. This paper focuses on how we compute the impact of cyber attacks on IT processes and information. These computations will improve decision‐making when under cyber attack by providing accurate and detailed assessments of the impact of those attacks. Although the focus of our work has been on the calculation of cyber mission impacts during mission execution, we have also demonstrated how our representations and computations can be used for performing cyber risk analysis and crown jewels analysis.
7.6.3 Architecting a Secure Enterprise Data Sharing Environment to the Edge
Authors: Farroha Bassam S. , Farroha Deborah L. 
Published: November 2014

1.0 ABSTRACTThis paper analyzes secure data sharing outside the security domain. There is a high demand for accessing multiple levels of sensitive data at the edge; however the threat at that location is higher compared to the core enterprise environment. This paper investigates the requirements, technologies and risk mitigation techniques for securely sharing information with the tactical user while protecting the data and the information systems from intruders and malware. The new Enterprise Architecture needs to eliminate the stovepipe architectures and open the doors to share information across traditional and non‐traditional domain boundaries.
8.1.1 Enhancing the Usability of Human Machine Interface on the Handheld Interagency Identification Detection Equipment (HIIDE™)
Authors: Faddis Kelly N. , Howard John J. , Stracener Jerrell T. 
Published: November 2014

AbstractAn essential element of a biometric system is the human machine interface (HMI), both from the user (administrator) and subject perspectives. The HMI has a significant impact on the performance of the system, as it is a key factor in the quality of the biometric sample collected. This paper will consider the implications of the HMI from the user perspective, analyzing the results of user experiences and training with the Handheld Interagency Identity Detection Equipment (HIIDE) Series 4, a device used by the Department of Defense in Iraq and Afghanistan. Results of this task analysis will be in the form of recommendations and considerations for the development of future collection systems. The paper will also provide a preliminary review of the recently released HIIDE Series 5 device and conclude by presenting the Systems Engineering (SE) based process used in this analysis as well as recommendations for including select SE practices in future biometric system design and development.