bluuebunny/crossref_metadata_2025 huggingface dataset:
4.1.0 Motor Sports Accelerates SySTEM Learning
Authors: Ring Jack , Settles Stan , George Al , Mackey William , Hylton Peter , Martin Richard , Berg Ken
Published: November 2014

The Motor Sports WG is developing ways to leverage the excitement and enthusiasm in motor sports to accelerate education, especially SySTEM education. Each panellist will address a pro and con for each of four claims:

Claim 1:The real payoff from revitalizing science, technology, engineering and mathematics, STEM, education will come from learning to meld these and other disciplines/technologies into whole systems solutions, SySTEM.

Claim 2: SySTEM learning can be accelerated by experiences that are meaningful to the learner, notably, intellectual and visceral immersion in real world, rewarding, reflective, learning environments.

Claim 3: Because meaningful learning sessions about systems are difficult to create in a campus‐only setting this panel will address ways that motor sports can augment campus‐centered SE education

Claim 4: A ‘laboratory on many wheels’ has been and can be used to accelerate SySTEM learning.
4.2.1 Multi‐scale performance evaluation in Naval Combat Systems domain
Authors: Squarcia Elvio , Gaeta Vito , Ciambra Francesco
Published: November 2014

Performance evaluation of modern and future combat systems in complex operating scenarios is strictly related to modeling and simulation techniques. A “multi‐scale” methodology is employed to evaluate performances of naval combat systems in multi‐platform operating scenarios (e.g. naval fleet, border control, homeland defence and security) through numerical simulation tools, named ICS‐Sim (Integrated Combat Systems Simulation). ICS‐Sim allows integration of software simulations models with high degree of accuracy to analyse and evaluate systems performances for studying innovative algorithms (e.g. asymmetrical threats contrast) integrated in a systems of systems simulation environment.
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

The 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

This 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

Systems 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

Current 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

Market 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.4.2 Applying Technical Readiness Levels to Software: New Thoughts and Examples
Authors: Armstrong James R.
Published: November 2014

The concept of Technical Readiness Levels has been applied to software. However, the criteria for levels are more related to design maturity of a specific product than to software technologies. This paper reviews the current work and addresses areas that are more technology related including examples.
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

The 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.
8.3.2 Practical Approach to Increasing State Space Coverage for System Testing
Authors: Trela Michael D. , Maximoff Joshua
Published: November 2014

This paper presents a practical solution to improving system level Verification and Validation (V&V) tests, those tests which exercise end‐to‐end functionality of a physical system, for complex hardware/software systems. The proposed method to improve system level testing is to increase the total number of system configurations that are tested in a way such that the state space coverage is explored in a systematic and evenly‐distributed fashion. We describe a method for adapting the combinatorial software test strategy known as t‐wise testing to complex hardware/software systems V&V testing. Practical requirements and potential test selection architecture are provided to demonstrate the utility of the proposed t‐wise testing method. Some methods for test selection and prioritization are outlined for instances when complete t‐wise testing is impractical.
9.4.2 System and Context Modeling; Visualizations of Where, When, and How1
Authors: Muller Gerrit
Published: November 2014

Modeling 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

Processes 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

Architecture 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 discussed

Several 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

A 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

Requirements 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

Orbital 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

Functional 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

This 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

The 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

The 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

The 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

We 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

The 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.”1

The 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.
4.1.3 Expert‐Based Single Point Failure Analysis
Authors: Baladi Jean Y. , Hendrix James L.
Published: November 2014

A 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

Development 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

Requirements 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

Previous 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

Sandia 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

The 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

Opinions 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

Model‐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

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

All 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

Systems 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

Premature 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

The 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

Systems 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

– 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

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

This 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

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