bluuebunny/crossref_metadata_2025_split huggingface dataset:
5.2.2 Normative and Descriptive Models for Test & Evaluation of Unmanned and Autonomous Systems of Systems
Authors: Hess John , Agarwal Gaurav , Cowart Karl K. , Deonandan Indira , Kenley C. Robert , Mikaelian Tsoline , Valerdi Ricardo 
Published: November 2014

AbstractThe United States Department of Defense (DoD) has purchased and deployed many unmanned autonomous systems and is expected to do so at an ever‐increasing rate in the years to come. These autonomous systems are often expected to operate in system of systems environments. Our research aims to address a number of questions posed by members of DoD's acquisition workforce regarding test and evaluation of these systems.In this paper we present a small set of normative (ideal) and descriptive (actual) models for test and evaluation. We describe test strategies used in the DARPA Grand Challenge competition and the SPHERES test bed, and extract lessons learned from each case study. We will use these models as a step toward identifying prescriptive models for testing unmanned and autonomous systems of systems. The prescriptive models will be implemented within PATFrame (Prescriptive and Adaptive Testing Framework), the decision support system that we are developing.
5.5.1 An Overview of the SysML‐Modelica Transformation Specification
Authors: Paredis Christiaan J.J. , Bernard Yves , Burkhart Roger M , de Koning Hans‐Peter , Friedenthal Sanford , Fritzson Peter , Rouquette Nicolas F , Schamai Wladimir 
Published: November 2014

AbstractThis paper provides an overview of the formal transformation between the two complementary languages: OMG SysML™ and Modelica. SysML is a standardized general purpose graphical modeling language for capturing complex system descriptions in terms of their structure, behavior, properties, and requirements. Modelica is a standardized general purpose systems modeling language for analyzing the continuous and discrete time dynamics of complex systems in terms of differential algebraic equations. Integrating the descriptive power of SysML models with the analytic and computational power of Modelica models provides a capability that is significantly greater than provided by SysML or Modelica individually. A standardized bi‐directional transformation between the two modeling languages is being developed that will support implementations to transfer efficiently and automatically the modeling information between SysML and Modelica models without ambiguity. In addition to an overview of this bi‐directional transformation approach, the paper provides a simple example to clarify the transformation principles and to illustrate the important synergies resulting from the integration between these two languages.
6.1.1 Applying Systems Thinking via Systemigrams™ for Defining the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) Project
Authors: Squires Alice , Pyster Art , Sauser Brian , Olwell David , Enck Stephanie , Gelosh Don , Anthony Jim 
Published: November 2014

AbstractSystems thinking is commonly accepted as the backbone of a successful systems engineering approach. As such, the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) team chose to leverage a systems thinking based tool, called Systemitool, to describe our project to the vast audience that would potentially become involved directly or indirectly in the success of the project. This paper describes the process and steps used by the authors and the BKCASE team to develop the project's systemic diagram, or Systemigram™, and the story behind the project, the products, and the vision of the BKCASE project. The goal of the paper is to provide guidance so that readers can leverage the lessons learned from this effort to successfully develop their own project definitions and stories.
6.1.2 Understanding the Implementation of System Architectures in the Context of Distributed Cognition
Authors: Watkins Christopher B , Dagli Cihan H 
Published: November 2014

AbstractCurrent system architectures are typically attributed to the technical leader that holds the formal title of “System Architect” and for larger projects there may be a team of system architects. There is no question that this person (or team) is responsible for the development and management of the system architecture. However, a theory in cognitive science known as “Distributed Cognition” challenges the notion that a single person or a single team can entirely understand the implemented architecture. This theory can aid in our understanding of system architectures and thus improve the probability of a successful implementation of an architecture. When applied to the domain of systems engineering, distributed cognition theory suggests that a system architecture can only be fully understood through the collective minds of the group that develops and implements the architecture. In fact, the group's understanding likely diverges from the understanding of any single individual. This helps explain why architectures implemented by a large group commonly deviate from the vision held by the lead system architect(s). After system architectures are understood as a distributed “system of knowledge”, a systems engineer can actively manage the interfaces between distributed units of knowledge. The goal is to ensure that the collective system of understanding is a healthy system, and thereby increase the probability of success that the implemented architecture will meet the needs in the problem space. This paper summarizes current research in distributed cognition and applies that research to form heuristics that can be leveraged when developing and implementing an architecture.
6.3.1 Evaluating Competitive Advantage of a New Product for Designing Successful Product Differentiation
Authors: MINATO Nobuaki 
Published: November 2014

AbstractMarket oriented product differentiation is a critical issue for a business success today. This paper proposes a relatively simple but effective analytical tool to design successful product differentiation especially in conceptualization phase. The author calls the tool as “Competitive Advantage Matrix (CAM)”. The tool utilizes a matrix‐based approach to evaluate relative competitiveness of a new product in a market oriented context, focusing on 1) technical excellence, 2) marketing strength and 3) social acceptance. It enables to provide various insights on whether a new product is likely to acquire competitive advantage in a market, not only against competing products, but also in a segment and in a whole market as well. The tool is also functioned as an easy measure to simulate future state of a new product's competitiveness, considering both actions and reactions from competitors. In this paper, a general concept of the CAM analysis is firstly explained with its development process. Secondly, a practical application of the CAM analysis is illustrated with an example of aircraft manufacturing industry. Finally, benefits and improvements of the CAM analysis are discussed in the conclusion.
6.5.2 Human Factors Issues in a Model Based Systems Engineering Perspective
Authors: Frisoni Daniele , Tocci Andrea , Ciambra Francesco , Nardini Manuela 
Published: November 2014

AbstractThe objective of this paper is the description of design results in the application fields of Human Factors Engineering through an innovative model based systems engineering approach.Human Factors analyze the system with a human‐based approach, looking at the system by the users' perspective, designing interaction with the system according to operator profiles. Operator's interaction with the system is performed through the use of Human Machine Interface mechanism by inserting information to setup system capabilities and checking operational results to monitor system behavior.The Model Based System Engineering approach allows to build a design structure of system logics through functional and operational chains, focusing on exchanges among system modules. Human Factors studies include also the operator as active part of the functional chains and can therefore be considered as a “module” of the System Model, where all data catalogue is codified in SysML.This Papers also shows the applications of this concepts in design and modeling of Naval Combat System.
9.4.2 System and Context Modeling; Visualizations of Where, When, and How1
Authors: Muller Gerrit 
Published: November 2014

AbstractModeling of systems and their context is done to support communication with stakeholders, to facilitate reasoning about system requirements and design, to support decision making, and in general to create and maintain understanding, insight, and overview. One of the challenges in modeling is to find appropriate representations that are understandable for relevant stakeholders and that contain sufficient information.In this paper, we discuss how to visualize space, time and process flow of systems, both internal as well as in their context. We argue that visualizations must connect to the stakeholders' world. We observe that architects tend to create abstract diagrams, alienating their stakeholders by abstraction, the use of jargon, and the presence of lots of (irrelevant) details.We will illustrate the visualization techniques with some models made as part of the Darwin project. The Darwin project researches evolvability of systems and architectures, using Magnetic Resonance Imaging scanners at Philips Healthcare as case.
10.1.2 Failure Analysis: Insights from Model‐Based Systems Engineering
Authors: Schindel William D. 
Published: November 2014

AbstractProcesses for system failure analysis (e.g., FMEA) are structured, well‐documented, and supported by tools. Nevertheless, we hear complaints that FMEA work feels (1) too labor intensive to encourage engagement, (2) somewhat arbitrary in identifying issues, (3) overly sensitive to the skills and background of the performing team, and (4) not building enough confidence of fully identifying the risks of system failure. In fairness to experts in the process, perhaps such complaints come from those less experienced—but even so, we should care how to describe this process to encourage better technical and experience outcomes. This paper shows how Model‐Based Systems Engineering (MBSE) answers these challenges by deeper and novel integration with requirements and design. Just as MBSE powered the requirements discovery process past its earlier, more subjective performance, so also can MBSE accelerate understanding and performance of failure risk analysis–as a discipline deeply connected within the SE process.
Architecture Frameworks & Modeling
Authors: Martin James N 
Published: November 2014

AbstractArchitecture provides the unifying structure (or roadmap) for exploration of the problem space and for characterization of the solution space such that better decisions can be made. Architecture is an arrangement of feature and function that maximizes some objective. This tutorial will describe fundamental concepts used in architecture modeling that will assist you in developing and using your own architectures.The use of an architecture framework leads to a more model‐driven systems approach and allows you to “discover” the essential attributes of the problem space that must be addressed by the system solution. Architecture models are where these essential attributes are defined and evaluated. This approach to architecting will be described within the context of the DOD Architecture Framework (DODAF) and other frameworks like the Federal Enterprise Architecture Framework (FEAF) and the Zachman Framework.There can be a hierarchy of architectures that helps focus the architecture team on the right level of abstraction. One common hierarchy starts at the top with National level architectures and works down to the levels of Department/Federal, Service/Agency, Mission Area/Cross‐Mission Area, Program/Node, and so on. The architecture you develop will have impacts above and below you in the hierarchy. The notion of levels in a hierarchy will be discussed along with how to use this to structure your modeling and simulation activity. The differences between enterprise architectures and system architectures will also be discussedSeveral examples of architecture frameworks will be discussed along with application guidance for each: Zachman, Gartner Group, The Open Group, Reference Model of Open Distributed Processing, Federal Enterprise Architecture (US), and Department of Defense (US). The various modeling constructs within the DOD Architecture Framework will be described so that you can see how a framework can integrate the overall systems architecting and engineering activities.
Developing Verification Requirements to Assure Project Success
Authors: Powell Mark A. 
Published: November 2014

AbstractA well thought out and planned set of verification requirements can make all the difference between a happy customer and a dissatisfied customer. If you cannot provide confidence to the customer that you met their requirements, you won't have a happy customer. Yet few projects these days invest much effort in developing good verification requirements. Quite often, verification requirements are treated as an afterthought to the performance requirements. But, if we produce the verification requirements concurrently with the performance requirements, the verification requirements can expose problems in the performance requirements they are intended to verify. Of course, this not only leads to better verification requirements, but to better performance requirements, which leads to a happy customer.Why is it then that most requirements training courses just gloss over the development of verification requirements? Verification requirements are actually very different from the requirements they support. While they share the same syntax and basic requirements writing rules as performance requirements, you usually need many verification requirements to properly verify that a single performance requirement is satisfied.This tutorial will enlighten both the new SE as well as the grizzled veteran who needs a refresher about how to properly develop good verification requirements. We will go though a number of real world examples of good and bad verification requirements, and how they contributed to success and failure. We will establish the philosophical foundation for writing verification requirements, and present a simple process for developing verification requirements for broad classes of performance and functional requirements.
Requirements Engineering for Large and Very Large Scale Systems Part Two ‐Contract Based Systems
Authors: Berenbach Brian , Cleland‐Huang Jane 
Published: November 2014

AbstractRequirements elicitation and management for contract based projects is significantly more complex than for product or product line development. For example, many practitioners are unaware of the fact that the traditional “V” model for requirements tracing does not work where there is a legal contract describing project deliverables; nearly every aspect of requirements engineering is more challenging, from elicitation to risk analysis and compliance management.This half‐day tutorial will describe in some detail contract issues that are typically not discussed in requirements texts and courses.This is part two of a two part tutorial. The morning session described how to set up processes and tooling for very large industrial projects. This 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 tutorials by attending both sessions.
1.2.1 Recommended Verification Approach for Human Rated Systems Based on Lessons Learned on the Orion Launch Abort System
Authors: Pappageorge Charlotte , Filipi Darko , Vernon G. Fitz , Herbert Benjamin D. , Bocam Kenneth J. 
Published: November 2014

AbstractOrbital Sciences Corporation, under contract to Lockheed Martin, designed, built, and verified Orion Launch Abort System developmental flight test hardware intended for future use on human spaceflight missions. Human spaceflight necessitates increased scrutiny by the certifying government authority and customer in comparison to uncrewed space systems due to the risk to human life. This paper describes lessons learned and complications encountered with using a verification method based approach for the Pad Abort test. This paper recommends a comprehensive requirement based verification approach for human rated space systems based on this experience.
1.3.2 On the Use of a System Need Statement in Functional Decomposition
Authors: Ryan Michael J. 
Published: November 2014

AbstractFunctional decomposition is a useful tool in developing system requirements, particularly where the desired end result is a system functional hierarchy. When decomposition begins with statements taken from stakeholder requirements documents, however, the resultant system requirements will tend to take on a structure that flows from whatever structure has been given to the parent statements by the authors of the stakeholder documents. Unless the stakeholder documents are themselves hierarchically organized, the decomposed requirements must then be regrouped into a suitable system functional hierarchy. Since functional decomposition (and derivation, for that matter) requires a start point, the direct development of a cohesive system functional hierarchy by decomposition requires a single, system‐level start point. This paper proposes an iterative process for the development of a system need statement and its formal decomposition into goals and objectives (and subsequently into system requirements in a functional hierarchy).
2.1.1 Systems Practices for Sustainability
Authors: Sobkiw Walter 
Published: November 2014

AbstractThis year the Department of Defense released its Quadrennial Defense Review (QDR) Report. The report dedicates several pages to climate change and energy in a section entitled “Crafting a Strategic Approach to Climate and Energy”. This broadly falls into the sustainable development trends that have resurfaced in recent years. So what can systems engineering do to facilitate sustainable development and the policy and goals in this new report? This paper will offer some systems practices suggestions to address the QDR and the broad category of sustainable development.
2.5.0 MBSE
Authors: Friedenthal Sandy 
Published: November 2014

AbstractThe INCOSE MBSE Initiative was established to help enable the Systems Engineering Vision 2020. MBSE was one of 5 components of the SE Vision. This webinar will highlight the MBSE vision, along with the MBSE roadmap and some of the key challenge team and related MBSE activities that the MBSE Initiative has been pursuing. The webinar will also highlight other industry related MBSE efforts, and some general observations about the state of practice.
NDIA ROI
Authors: Elm Joseph , Honour Eric 
Published: November 2014

AbstractThe purpose of the SE Effectiveness Working Group (SEEWG) is to promote effective systems engineering by collecting and analyzing quantitative data on the impact of specific SE processes and practices on project performance. This data will contribute to the development of a stronger business case for systems engineering. The SEEWG is currently collaborating with the National Defense Industrial Association (NDIA), the IEEE Aerospace and Electronic Systems Society (IEEE‐AESS) and the Software Engineering Institute (SEI) on the “Business Case for SE (BCSE)” project. The BCSE project is conducting a survey of projects across multiple industries and multiple countries to Identify principles and practices PROVEN to provide benefit to projects and programs. The knowledge gained will be used to develop guidance, training, and tools to assist SE practitioners in applying these principles and practices and to assist system acquirers in ensuring that these principles and practices are applied to their projects.
3.2.2 A More Flexible Approach to Valuing Flexibility
Authors: Ryan Erin T. , Jacques David R. , Colombi John M. 
Published: November 2014

AbstractThe DOD routinely demonstrates its capability to develop phenomenal systems; however, these accomplishments are often tarnished by substantial cost and schedule overruns. While defense policies are continually being revised to address these problems, many believe that a more fundamental source of these overruns is the lack of flexibility in the systems being developed. But providing justification to invest in flexibility is a tough sell, as stakeholders struggle to quantitatively demonstrate the potential return on investment. Therefore, this paper introduces an alternative methodology for valuing the inherent ability of a system or design to accommodate change. The proposed methodology is essentially a modification of the current life cycle model and is premised on the notion that the need for capability changes in a program arise in a stochastic manner that can be incorporated into a continually updated, expected value model presented in terms of total program cost.
3.5.0 Systems Science
Authors: Martin James 
Published: November 2014

AbstractWe will provide reports on current projects of the Systems Science Working Group:
System Pathologies
Unified Systems Science Theory
Unified Ontology of Scientific Method & Systems
The purpose of this working group is to promote the advancement and understanding of Systems Science and its application to SE. Our are objectives are to: (1) Encourage advancement of Systems Science principles and concepts as they apply to Systems Engineering, (2) Promote awareness of Systems Science as a foundation for Systems Engineering, and (3) Highlight linkages between Systems Science theories and empirical practices of Systems Engineering.
4.1.2 Managing Risk in NASA's Deep Space Network
Authors: Witkowski Mona M. , Todd John , Dokken John 
Published: November 2014

AbstractThe National Aeronautics and Space Administration's (NASA) Deep Space Network (DSN) was established in the late 1950's, to provide specialized and continuous two‐way communications with NASA's deep space and planetary missions. Since then, the DSN has become a “world leader in the development of low‐noise receivers, tracking, telemetry and command systems, digital signal processing and deep space navigation.”1The global configuration of the DSN complexes, the collaboration with foreign government agencies, the complex management and reporting structure, combined with the uniqueness and criticality of the mission data being captured by the DSN antennas all contribute significant challenges to the operation of the network. One of a kind, mission critical science data must be preserved and thus a rigorous risk management approach is critical to ensuring mission success. This paper will describe the risk management process that has been developed and implemented for managing risk within the DSN.The research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.