bluuebunny/crossref_metadata_2025 huggingface dataset:
5.2.1 Effecting Quality of Service Across Systems of Systems
Authors: Naga Vinod D. , Grimaila Michael R. , Colombi John , Hopkinson Kenneth
Published: November 2014

The ability for diverse communication networks to adapt to changing mission characteristics, such as priority, have been a recognized challenge across Systems of Systems. Within the Department of Defense, mechanisms do not exist to extract dynamic mission features for use in defining Service Level Agreements (SLA) and for use within Quality of Service (QoS) provisioning. These mechanisms, were they to exist, would also serve a wide range of non‐defense enterprises. This paper provides background on QoS and SLAs within the current military context. We then offer a research approach to improve on the network‐focused, QoS mechanics. Using OpNet, early simulations reproduce the competing cross‐mission information environment and serve as the foundation for continued “mission‐aware” QoS research.
5.4.1 Simulation and Verification of [Dys]functional Behavior Models: Model Checking for SE
Authors: Seidner Charlotte , Lerat Jean‐Philippe , Roux Olivier H.
Published: November 2014

Verification is a key process in the dependability engineering of complex systems. As we have shown in earlier works, formal verification techniques such as model checking can be efficiently used in a Systems Engineering (SE) context, despite their inherent complexity. Considering the widely used Enhanced Function Flow Block Diagrams (EFFBDs), we have indeed developed a formal simulation and verification tool for these functional behavior models. Moreover, great care has been taken to conceal the processing complexity from the tool end‐user.

In this paper, we present our latest developments as well as an extension of both method and tool to the case of dysfunctional models, to take into account failures affecting the model elements. By addressing both fault removal and fault forecasting problems with formal methods, we thus hope to improve the dependability analysis practice in SE.
5.5.2 Three Reasons why Document‐based SE (usually) works better than (most of) MBSE
Authors: LERAT Jean‐Philippe
Published: November 2014

Under this provocative title, this paper warns the reader against a common belief: MBSE is the key to success. This statement is not wrong but terribly reductionist since the success of MBSE requires good SE practices to begin with. However in real life, most of MBSE efforts are just reflecting the bad SE practices that it pretends to correct. This mirroring does not help to solve the problems nor to implement better SE practices. In general, it just bastardizes what was already hardly working, based on document exchanges.

As a way to support this demonstration, the paper highlights a number of problems that, if not addressed, ruins any MBSE implementation.

Successful implementation of MBSE is a crucial factor of survivability for most of companies and agencies in today's world. This silver‐bullet is, in many cases, the last ammunition of the projet managers: that's why it is worth to pay a bit of attention to the target, before shooting.
7.3.1 A Complexity Typology for Systems Engineering
Authors: Sheard Sarah A. , Mostashari Ali
Published: November 2014

This paper shows how the literature on complexity is related to complex systems and to systems engineering. A framework for types of complexity is proposed that includes three types of structural complexity (size, connectivity, and architecture), two types of dynamic complexity (short‐term and long‐term), and one additional type, socio‐political complexity. These types cover most of the characteristics of complexity mentioned in the reviewed literature; omissions are noted.

It would be advantageous to identify specific measures of complexity so that the complexity of systems or development programs could be compared and tracked, and risks could be identified and mitigated. To this end an overview of systems engineering measurement is provided, followed by a discussion of how complexity types might be able to be measured. At this point, however, a composite measurement of the six types of complexity is not recommended.
7.3.3 Preliminary Validation of Scenario‐based Design for Amorphous Systems
Authors: Kim Sun K. , Haruyama Shinichiro , Maeno Takashi , Toma Tetsuya , Ohkami Yoshiaki
Published: November 2014

Designing amorphous systems is challenging because of the broad scope of the task. The design team must integrate various solution elements, such as hardware, software, service, and infrastructure, while resolving the communication challenges among different domain‐experts. Scenario‐based Design for Amorphous Systems enables design teams to effectively deal with ambiguity and to communicate their ideas among team members and managers, as well as with customers through a common language. We validated its effectiveness in both academia and industry. This paper describes the process and the preliminary results of the validation based on three approaches: Statistical, voting and interviews.
9.2.2 Everything you wanted to know about interfaces, but were afraid to ask
Authors: Wheatcraft Louis S.
Published: November 2014

Some of the biggest problems in developing a system are at an interface. Some of the most critical requirements for every system that we build are interface requirements. Interface requirements cannot be written in a vacuum, both sides must participate. Yet how to write interface requirements is barely covered in the literature – and what is in the literature is not consistent. This paper will address some things you can do to get better interface requirements. Topics covered include: Understanding what constitutes an interface, how to identify interfaces, how to define and document interface definitions, what constitutes a good interface requirement, and where and how to document interface requirements.
9.3.1 A Vector Approach to Assessing Modularity
Authors: Stryker Amie C. , Jacques David R. , Long David S.
Published: November 2014

A method to assess product modularity using a vector approach is presented and demonstrated using two precision guided munitions. Modularity has several fundamental benefits agreed upon by industry including reusability, flexibility, reconfigurability and extensibility. Current modularity measures focus on interfaces within or between modules in provide/depend relationships. A new method that assesses the module interfaces as well as captures and addresses each of the recognized modularity benefits is presented in a Vector Modularity Measure (VMM). Components of the VMM include terms for degree of coupling, reusability, and flexibility. Flexibility is assessed in terms of reconfigurability and extensibility. The overall evaluation method is then summarized, followed by an application using two similar precision guided munitions in the U.S. Air Force inventory: the Guided Bomb Unit‐24 (GBU‐24), referred to as the laser guided bomb (LGB); and the Guided Bomb Unit‐31 (GBU‐31), referred to as the Joint Direct Attack Munition (JDAM).
9.3.2 Agile Aircraft Installation Architecture In a Quick Reaction Capability Environment
Authors: Boss Jason , Dove Rick
Published: November 2014

Military mission systems are continuously upgrading equipment to keep pace with rapidly changing technology refresh rates and evolving global threats. Many of the programs that demand extensive changes are also demanding quick reaction capability, or QRC. It is increasingly challenging to quickly accommodate a mix of equipment without standardized physical interfaces, a wide range of cooling needs, and multiple power types. This paper focuses on a combined architecture for secondary power distribution, structural support, and environmental control that directly supports a mission system installation in a military acquisition context. An aircraft installation architecture that has the flexibility to rapidly adjust to changing power, weight, heat load, and space allocations could lower modification cost, reduce schedule, and lower risk.
10.2.2 Architecture Framework for Spacecraft Computer Control Safety System
Authors: Shirasaka Seiko
Published: November 2014

We have a strong demand to design computer control safety system because crew stats to stay the international space station continuously, but there is no design framework for spacecraft computer control safety system. In this paper, we propose the architecture framework for spacecraft computer control safety system to guide a safety systems engineer to design computer controlled safety system. This framework is based on the general safety design process and NASA's computer safety requirements. The architecture framework can be proposed in accordance with the coming new IEEE1471 standard. This architecture framework can cover all design processes which are mandatory to be conducted to design system safety architecture. From this result, we suppose that this architecture framework reaches at least mandatory level.
10.4.2 Al‐Qaeda as an Adaptive Organization: a Case Study
Authors: Powell Trina , Hutchison Nicole , Pyster Art
Published: November 2014

Since September 11, 2001, al‐Qaeda has proven itself to be an organization capable of surviving in a hostile environment where they are consistently targeted by the U.S. in political and military actions. Their survival is due, in large part, to their ability to adapt to the environment in which they operate. This level of adaptability—or agility—makes them an excellent target for a case study on adaptability. In ongoing research, the authors explain that by studying the organization and identifying elements which make them agile, some recommendation can be made for strategies to increase agility in similar, open organizations. Some potential implications for other types of organizations are also discussed.
11.2.1 Getting Started on the Right Foot: Developing Requirements for Constellation's Next Generation Space Suit
Authors: Wheatcraft Louis S. , Hill Terry R.
Published: November 2014

A major challenge identified by the General Accounting Office and NASA's Inspector General is a project's inability to fully define project requirements prior to entering into contractual arrangements, placing projects at risk of significant cost overruns, schedule delays, and performance shortfalls. In 2007, the Constellation Space Suit Element (CSSE) was tasked to produce their Level IV Element Requirements Document (ERD) and baseline it within a 3‐month period. Aware of the consequences resulting from a poor set of requirements, NASA's Space Suit Project instituted a continuous requirement validation process that would allow the project team to develop a correct, consistent, and complete requirement set within tight schedule constraints. The result was an order of magnitude reduction of review comments against the ERD compared to the number of comments against the parent Level III System Requirements Document (SRD).
11.4.2 Systems Engineering Return on Investment
Authors: Honour Eric
Published: November 2014

Research work continues into Systems Engineering Return on Investment (SE‐ROI) following prior work on Value of Systems Engineering and Systems Engineering Effectiveness. This paper presents major results in the form of statistically proven relationships between systems engineering (SE) activities and the technical, schedule and cost success of programs. It has been found that all defined SE activities correlate positively with program success as measured in three of four success metrics used (cost overrun, schedule overrun and perceptive success). When the effect of program characterization parameters is included, the correlation is strong with optimum levels of SE activities as much as 25% of a program cost. The paper presents quantified values for the relationships, indicating appropriate levels of each SE activity that correlate to optimum levels of success. Results show a surprising lack of correlation between SE activities and the technical quality of the product system, for which some possible explanations are provided.
Prepare for SE Certification with an INCOSE Tutorial
Authors: Clark John O.
Published: November 2014

Interested in Systems Engineering certification? John O. Clark will present a 2‐day tutorial immediately preceding the IS10 Conference. This tutorial provides an overview of the INCOSE SE Handbook to help you prepare for the INCOSE SE Certification exam. The tutorial covers the Certified Systems Engineering Professional (CSEP) process as well as the sections and appendices of the SE Handbook, Version 3.1 (the basis for the certification exam), in a study group format. It also provides example exam questions and tips on filling out your CSEP application. The tutorial consists of 16 sections from Saturday, July 10 through Sunday, Sunday July 11, from 8:00 a.m. ‐ 5:00 p.m. each day. The tutorial hardcopies, certificate of completion, and refreshments are included. For more information on the CSEP application process see http://www.incose.org/educationcareers/certification/, and to apply on‐line in advance of the tutorial see the IS10 Registration site, or contact John Clark at (tjohn.clark@incose.org). Registrants are encouraged, but not required, to attend the IS10.
Why Johnny Still Cannot Write Requirements
Authors: Hooks Ivy
Published: November 2014

In 1990, the Why Johnny Can't Write Requirements paper was published by IEEE and also presented to a Data Processing Management Association Symposium. During that year INCOSE was formed, Hubble Space Telescope was launched, Iraq invaded Kuwait, Alan Davis published a book on writing software requirements, several requirement management tools were marketed and a few classes existed. A lot has happened in 20 years. Our view of the universe has changed because of Hubble, our understanding of how wars will be fought in the future has changed because of what happened in Iraq and Kuwait, and many more people are on the requirements and system engineering band wagon than even knew it existed in 1990.

We'll explore how things were 20 years ago with updates for the intervening years, to understand where we have been and what has happened in the world, to INCOSE, to SEs and to requirements processes, practices, use of tools and other changes. We'll share your feedback on where you think today's requirements problems lie, for you and for your organization.

We'll look at where you are now by having you take a short quiz on requirements and grade yourself. This will help you understand if you need to learn more of the basics or move on to other topics and give you some ideas to take back to your own organization.

We'll explore what still needs to be done now and how you can go about causing more changes to improve requirements processes and practices to help your organization or company, much more efficiently and effectively, develop or acquire the products that are needed for your success and the success of your customers and users.
Modeling with SysML
Authors: Friedenthal Sanford , Wolfrom Joseph A
Published: November 2014

The OMG Systems Modeling Language (OMG SysML™) is a general‐purpose, graphical, modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities. In particular, it provides graphical representations with a semantic foundation for modeling system requirements, behavior, structure, and parametric equations that can integrate with a broad range of engineering analysis. SysML represents a subset of UML 2.0 with extensions to satisfy the requirements of the UML™ for Systems Engineering RFP. The OMG SysML™ Specification was adopted in May 2006. For more information on SysML, including articles, tool vendor and related links, and the specification, go to http://www.omgsysml.org/.

This tutorial provides an introduction to how SysML can address your systems engineering needs, including: background and motivation, an overview of the SysML diagram types and language concepts, a demonstration of how the language can be used throughout a Model‐based Systems Engineering (MBSE) process. A class exercise is included to help solidify the student's understanding of the language. The course will also include a brief introduction to a typical SysML tool.

Attendees should gain appreciation of the value of model‐based Systems Engineering versus legacy, document‐centric methods; awareness of the graphical notation; and a high level understanding of when and how a Systems Engineer can exploit the various diagrams and models as part of their systems engineering process.
Reuse of requirements in the context of product lines of a complex system
Authors: Fanmuy Gauthier , Djebbi Olfa
Published: November 2014

this paper is about Product lines. A product line is the development of products that have commonalities. It is based on reusing engineering artifacts (requirements, architecture, tests…) and on managing variants of products. The development of a set of products rather than developing single products independently, which minimizes costs and completion time. This paper is about reusing a set of common requirements. It describes the different techniques for requirements reuse and a panorama of the different tools. It presents an implementation in DOORS.
A Systems Engineer's Approach to Understanding Waldenstrom's Macroglobulinemia and Idiopathic Thrombocytopenia Purpura
Authors: Paasch John Howard
Published: November 2014

This paper describes the process followed by the author in attempting to understand the body/disease/treatment complex for the diseases he has, Idiopathic Thrombocytopenia Purpura (ITP) and Waldenstrom's Macroglobulinemia (WM) and the development of models and simulations to represent that complex. While little was known by the author about platelets and ITP, and IgM and WM at the time of diagnosis, a tops‐down approach was taken to learn the physiology and biology of each. Starting out at the most abstract level, the complete body system, research was performed to understand the processes from an organ/physiological perspective and put it into the context of the separate functional boxes that the author learned during his career as a system engineer working on complex aerospace systems. The models and simulations can become tools to create an interchange vehicle between the modeler and the medical person to further the understanding of this very complicated complex.
1.2.2 How applying models in work group sessions can help to retrieve information for making FTA and FMECA analysis
Authors: Vigdal Levi Andrè Berg , Muller Gerrit , Pennotti Mike
Published: November 2014

Dresser‐Rand Kongsberg is a company with a long history of building radial gas turbines in the 2MW range. Since the first gas turbine was developed at Kongsberg, the turbine has been subject to several upgrades, the latest being called KG2‐3E. To compete with radial gas turbines with newer technology, a decision was made to develop a completely new engine, (KG2–3G), based on the experience from the previous KG2 turbines. A gas turbine is a complex system; it is therefore challenging to prevent as many of the high risk failure modes as possible during the test and integration.

To identify high‐risk failure modes a combination of Failure Mode Effect Criticality Analysis (FMECA) and Fault Tree Analysis (FTA) was applied. For the analysis, it was important to get input based on experience and knowledge within the company. Five senior engineers, who have been working with Gas Turbines for over 40 years, were the source of this knowledge. Work sessions were arranged to create discussions and extract as much “know‐how” as possible. The challenge during these sessions was to enforce engagement, creativity and discussion around the theme of concern. Methods such as applying different annotated diagrams representing the current theme and different methods of capturing the information were used to accomplish this.

A comparison between central facilitation by electronic documents and active engagement of all participants by low‐tech means was performed. The low‐tech means of applying Post‐It and flip charts seemed to be the superior method that made participants more engaged. Different models, such as FTA graphs, technical drawings, and simpler block diagrams were applied and compared. It was discovered that it is important that the models displayed something the participants could recognize. It was also clear that applying models that represented the theme of concern helped to improve engagement and creativity around that theme.
1.3.1 Increase Requirements Understanding by Playing Cooperative Games
Authors: Gelperin David
Published: November 2014

Serious games are games whose primary purpose is not entertainment. Cooperative games structure communication (e.g. contract bridge) and cooperation (e.g. soccer) between players in the same group.

Using serious, cooperative games improves Requirements Understanding (RU). This paper defines six RU games, maps them into ‘initial understanding space‘, and shows how to use a special Ouija board to choose the games to play on your project. An example of RU game selection is included.
1.3.3 Technical Baseline Repair
Authors: Kipp Jeremy
Published: November 2014

Text books provide guidance on how Systems Engineering should be done. Multiple papers and reports provide statistics and dissections of Systems Engineering related program failures. Few papers discuss how to bring programs back from a self perpetuating Systems Engineering downward spiral. This paper provides real world examples of how major legacy programs facing schedule slips, funding overruns and customer dissatisfaction, choose not to become a failure statistic and instead developed fiscally realistic solutions to successfully repair fractured, neglected, contested, and inconsistent technical requirement baselines.
1.5.0 DARPA and NSF Advances in Systems Engineering: META and Value‐Driven Design
Authors: Miller Bill
Published: November 2014

INCOSE's objective to be the preeminent authority on systems engineering is being challenged by the US Defense Advanced Research Projects Agency (DARPA) META program and the National Science Foundation (NSF) Value‐Driven Design (VDD) initiative.

The goal of the DARPA META program is to dramatically shorten by a factor of five the design, integration, and verification timeline for defense systems. DARPA hypothesizes that a major cause of failed and challenged defense programs is the failure to update the systems engineering, integration and test process that has its roots in the defense programs of the 1960s. The progression from MIL‐STD‐499 to current EIA, IEEE and ISO systems engineering standards are evolutionary steps that are insufficient because of the complexity of current systems. DARPAs approach through META is to innovate model‐based composition to better manage complexity by proving correct‐by‐construction models using a proof of principle demonstration of a complex air or ground vehicle. META is the upfront portion of the Adaptive Vehicle Make (AVM) portfolio.

The hypothesis of the NSF VDD Initiative is that the systems engineering approach to flow‐down and allocation of requirements results in systems that do not meet their system level requirements. The underlying cause is the nature of the human condition regarding risk taking and risk aversion. The VDD initiative is tapping into relevant fields in the social sciences and the use of objective functions in order to reinvigorate research into systems engineering and engineering design.
2.2.1 When is Enough Enough? Tailoring Processes in Systems Engineering
Authors: Pickard Andrew C , Nolan Andrew J
Published: November 2014

Systems Engineering Processes are usually written to be applied to the development of a complex system, starting from a blank sheet of paper. The mindset is that the processes have to be followed with 100% compliance to even stand a chance of developing a successful system.

In practice, many System Engineering activities involve the development of small, less complex systems, often by modification of a pre‐existing system. Even large, complex systems will be subject to incremental or spiral development where the increments are deliberately chosen to avoid complex interactions with the rest of the system. In addition, the full suite of systems engineering practices are designed to address all types of risks but not all projects will need such techniques. For example, stakeholder analysis and requirements elicitation will not be critical if the system is undergoing a refresh to address component obsolescence. One size fits all is a wasteful approach when you consider the processes are designed for all possible systems.

Under these circumstances, is it appropriate to apply the full weight of the Systems Engineering processes used for the initial development of a complex system to these incremental developments or to less complex systems? If not, what parts of the process should be simplified or omitted, and why?

It is said that “Processes are guidance for wise people” ‐ but if you don't follow the process, are you wise or otherwise? The focus of this paper is to present a “wise” approach to selecting which processes to follow, and to what level of rigor. It describes an approach grounded in Technical Risk Management and Probability Calculus to decide how to tailor Systems Engineering processes when developing less complex systems or introducing incremental developments or modifications to a complex system.
2.3.0 Is Requirements Engineering Really Necessary?
Authors: Berenbach Brian , Smiley Karen , Beatty Joy , Solomon Paul , Sampson Mark
Published: November 2014

This panel discussion will explore aspects of systems engineering where some engineers fear to tread. Some of the topics explored will include:

Should there be requirements engineers at all on systems development projects?

Can any systems engineer do requirements engineering (RE) well? If not, what additional training would be most useful?

Is RE really necessary (after all, big systems were built for hundreds of years without it)?

If RE is really necessary, should it be done by junior or senior staff?

Do we really need heavyweight RE processes and tools (ever, always, or never)?

The panelists are all senior engineers or project management professionals who have “seen it all” and do not necessarily share the same views. Perhaps through dialogue, some of the above questions can be answered; whether or not they are, everyone attending the panel will hopefully gain some new insights on the applicability of the field of requirements engineering to systems work.
2.4.1 Combining Lean and Sustainable Concepts with Systems Engineering for Manufacturing Enterprises
Authors: Nakano Masaru
Published: November 2014

The field of lean systems engineering (LSE) has recently emerged in systems engineering (SE). This concept applies the lean concept, which originally comes from the Toyota production system (TPS), to one‐off applications, such as large complex development projects for aerospace and the military. Some lean principles are generally used in Japanese manufacturing companies and are not unique to Toyota Motor Co.; the concept referred to as the Japanese production system (JPS), is an important factor in making an enterprise sustainable through continuous and endless improvement activities for marketing and quality management. TPS has been extended from production systems to product system development and enterprise management for repetitive manufacturing industries, and is called enterprise TPS (E‐TPS) in this paper.

This paper decomposes the E‐TPS concept into three components from the original TPS, JPS, and SE, and proposes the idea of a lean and sustainable enterprise. This is yet another interpretation of LSE based not on lean concepts, but TPS.
3.1.1 A Look at the U.S. Energy System –A Strategic Impact Model (2050 SIM)
Authors: Pincock Layne F. , Collins John W.
Published: November 2014

Although the United States (U.S.) energy infrastructure is reliable and accessible, it is also excessively reliant on foreign energy sources, experiences high volatility in energy prices, does not always practice good stewardship of finite indigenous energy resources, and emits significant quantities of greenhouse gases. The U.S. Department of Energy is conducting research and development on advanced nuclear reactor concepts and technologies, including High Temperature Gas Reactor (HTGR) technologies, directed at helping the United States meet its current and future energy challenges.

This paper discusses the systematic approach used to develop the 2050 Strategic Impact Model (2050 SIM), which allows the user to analyze and depict the benefits of various energy sources in meeting the energy demand. It also provides an overall systems understanding of the tradeoffs between building and using HTGRs versus other existing technologies for providing energy (heat and electricity) to various energy‐use sectors in the United States. This paper also provides the assumptions used in the model, the rational for the methodology, and the references for the source documentation and source data used in developing 2050 SIM.
3.3.2 X‐driven development: finding the right combination of approaches for systems engineering
Authors: Woodcock Hazel , Chard Jonathon
Published: November 2014

This paper explores the relationship between requirements‐driven, model‐driven and test‐driven development, the value that each technique can provide and the circumstances under which each is appropriate. We propose that there is no one technique that represents the ‘right’ answer, rather that they are complementary techniques which can be combined to reduce risk within the development process—what we're calling X‐driven development.

We further propose that the precise combination of techniques that should be applied is not constant between different development projects. Project and product characteristics influence the approach that should be taken, and different industries are aligned with particular combinations of characteristics.
3.4.0 Integrating MBSE into a Multi‐Disciplinary Engineering Environment
Authors: Friedenthal Sanford , Williamson Don , Jimenez Alex , Hoffman Mark , Liberto Nicholas Di , De Koning Hans Peter
Published: November 2014

Model‐based systems engineering (MBSE) formalizes the practice of systems engineering through the use of models. This panel is intended to address considerations for incorporating MBSE into a broader multi‐disciplinary engineering environment. Engineering disciplines use multiple languages and tools whose results are not always easily integrated. The lack of integration is a source of design discrepancies and errors. The potential for MBSE is that it provides a means to integrate multi‐disciplinary engineering including systems, hardware, software, analysis, and test throughout the development life cycle.

This panel will include representatives from other engineering disciplines to address questions such as: 1) What should other engineering disciplines expect from MBSE, and what should systems engineering expect from other disciplines to enable MBSE? 2) What can MBSE learn from model‐based approaches used in other engineering disciplines? 3) How should the practices and tools be integrated/coupled across disciplines? 4) How are the system, hardware, and software models managed to ensure an integrated technical baseline? 5) How should a program be organized to achieve more effective utilization and application of model‐based engineering? These are some of the questions that must be answered to more fully reap the benefits of MBSE.
4.1.1 Diogenes, a Process for Finding Unintended Consequences
Authors: Bahill A. Terry
Published: November 2014

Companies, governments and individuals often create products, processes and procedures that solve a particular problem, only to discover that their solution has created a second problem, worse than the first. These secondary problems are often unintended consequences. Finding unintended consequences, as a part of the development process, will likely increase safety, reduce financial risk and improve customer satisfaction. This paper contains the design for a new process, named Diogenes, that will help systems engineers predict unintended, but foreseeable, consequences of a new system that is being designed. This paper contains the use cases, design diagrams, test procedure, validation and verification for Diogenes.
4.3.1 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 (this paper), we present the motivation and challenges that led to SLIM. We describe the conceptual architecture (section 1) and use cases (section 2) of SLIM followed by tools available for production and evaluation usage (section 3). In Part 2 paper—SLIM Applications—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 examples from space, energy, infrastructure, manufacturing and supply chain, military operations, and bank systems are presented.
4.3.2 Systematic Approach to the Development, Evolution, and Effectiveness of Integrated Product Development Teams (IPDTs)
Authors: Jeffs Margie , Hamelin R. Douglas
Published: November 2014

Integrated Product Development Teams (IPDT) are a key component of any systems engineering (SE) application, but since they are formed primarily from technical considerations, many IPDTs are far less productive than they otherwise could be. By recognizing specific personality types and skill sets, a random group of “technical” individuals can be structured to become a highly effective team capable of delivering much more than the sum of its members.
5.2.1 Understanding “System‐of‐Systems” in the Defense Context
Authors: Hiang TEO Siow , Ngah NG Chu
Published: November 2014

The concept and scope of Systems Engineeing (SE), System‐of‐Systems Engineering (SoSE) and Systems Architecting (SA) are subject to various interpretations from subject matter experts across different subject domains. Alongside, there appear to be a wide array of terms describing systems, including, but not limited to, System‐of‐Systems (SoS), complex systems, engineering systems, and large‐scale systems. Reconciliation of the terminologies would facilitate discussions among practitioners and engineers new to the field.

The first section of this literature review is therefore an attempt to examine relevant papers and effort in the field of SoS to distil the key concerns and motivations stakeholders have when they refer to the term “SoS”, particularly in the context of defense where its application is in Network‐Centric Warfare. Characteristics that connect the seemingly different terminologies for systems will also be highlighted. The second section reviews the practice of SE/SoSE/SA on defense SoS, and highlights particular challenges that SoSE/SA communities seek to address for this renewed sense of complexity and abstraction.
5.4.2 Competencies Required for Successful Acquisition of Large, Highly Complex Systems of Systems
Authors: Armstrong James R , Kepchar Kenneth , Henry Devanandham , Pyster Arthur
Published: November 2014

A generic competency model for acquiring large, highly complex Systems of Systems is presented. The model combines competencies of systems engineering, systems integration, and software engineering. The model is applied to the U.S. Federal Aviation Administration's (FAA) Next Generation Air Transportation System (NextGen). The FAA is facing the challenge of significant increases in workload for the air traffic control system. NextGen efforts are aimed at providing the changes to the system needed to meet that challenge. In order to be prepared, the FAA is looking at the competencies needed to develop and deploy those improvements.
5.6.1 Model‐Based Standards Authoring: This research is supported by EU FP7 VISIONAIR ‐ A World‐class infrastructure for Advanced 3D visualization‐based research
Authors: Blekhman Alex , Dori Dov , Martin Richard
Published: November 2014

We present a methodology for model‐based authoring of standards based on Object‐Process Methodology (OPM). This general systems‐engineering approach to authoring of specifications is supported by an OPM framework and a procedure for model‐to‐text translation. This methodology, developed as part of the ISO TC 184/SC 5 OPM Study Group activities, is expected to become the basis of an emerging ISO Standard for Model‐Based Standards Authoring.
6.3.1 Process Patterns for Agile Capability Engineering Methodology: The PACEM Project
Authors: Nécaille Christophe
Published: November 2014

This paper presents the approach used to investigate the potential of process patterns to increase the level of agility of engineering processes applied to military capabilities or system of systems. This effort is a follow‐up of the Canadian Capability Engineering Process (CEP) defined during the Collaborative, Capability, Definition, Engineering and Management (CapDEM) technology demonstration project. The challenges surrounding process assessment are investigated.
6.4.2 A Systems Assurance Perspective Towards Generic Systems Engineering
Authors: Joyce g Pek Foong , Hin Oh Sin , Seng Yap Kwee , Chan Samuel
Published: November 2014

A previous paper (ref.1) was published to describe a generic system‐of‐systems (SoS) requirements model, which was constructed to guide systems engineering process for future Rail Transit Systems (RTS) in Singapore. In that publication, guidelines for detailed analysis of each requirements breakdown in the areas of operational, functional and physical requirements were explained.

This paper elaborates on the systems assurance aspect, as part of the generic systems engineering and generic requirements model to guide development of non‐functional requirements. In particular, management of safety and reliability is explained. The systems assurance process described in this paper is derived from valuable experience gained through management of several highly integrated driverless RTS with different procurement strategies. The new systems engineering process will be cascaded to future transit projects for improvements of requirements management, verification and validation, and optimization of available resources.
6.5.0 Integrating Systems Engineering into Engineering Curricula Through Capstone Projects
Authors: McGrath Beth , Nemes James , Umphress David , Whitcomb Cliff
Published: November 2014

With funding from the Department of Defense, a research effort is underway to understand the methods through which systems engineering learning and career interest may be increased among undergraduate and graduate engineering students. This research is being conducted in the context of 14 “capstone” projects, in most cases as an integrative culminating, project‐based course, and in one case involving an entire SE graduate curriculum, involving teams of students working together on the development of a product or prototype that addresses a real Department of Defense need. Implemented as pilot projects in eight civilian and six military universities, these 14 institutions are piloting methods, materials, and approaches to create new courses, enhance existing courses, and adapt curricula, to embed, infuse, and augment systems engineering knowledge, skills, abilities, and behaviors, as defined by the SPRDE‐SE/PSE Competency Model. This session will present an overview of the overall Systems Engineering Capstone research and findings to date, along with an overview and discussion of three different approaches to course design and preliminary student impacts.
7.1.1 Modeling Pilot Workload for Multi‐Aircraft Control of an Unmanned Aircraft System
Authors: Schneider Michael , McGrogan Jason , Colombi John M. , Miller Michael E. , Long David S.
Published: November 2014

A demand for increased use of Unmanned Aircraft Systems (UASs) without commensurate increases in pilot manpower has created proposals for the concept of Multiple Aircraft Control (MAC). To understand the potential effect of such proposals, a workload model was developed from pedigreed system architecture which permits the prediction of the effects of MAC on individual pilot workload levels. Results indicate multiple critical factors that affect the implementation of MAC. Although the model suggests that pilots may experience relatively low workload when operating a single UAS during benign operations, workload builds rapidly when the pilot is required to operate three or more aircraft. The results of this model indicate the need for techniques and technology to reduce task and communications demands on UAS pilots to effectively implement MAC.
7.1.2 System of Systems Engineering Facilitates Integration of Large Scale Complex Systems
Authors: Mazzuchi Thomas , Albakri Ghazi
Published: November 2014

Systems of Systems Engineering, SOSE, is a new field and opens a wide challenge for Systems Engineering researchers who are dealing with large scale complex systems. Integration is one of many tasks required by Systems Engineers who are involved in the process of acquiring a working system that fulfills the main mission of the large scale system. Generally, there are three large scale complex systems cases that need to be integrated: 1) new systems with new systems, 2) old systems with new systems, and 3) old systems with old systems. In the literature, the main focus of the research is on Systems Engineering integration processes for systems which are still under design and before their final phase‐out. This research presents a contribution to define the System of Systems Engineering (SOSE) science through facilitating the integration of two existing large scale complex systems “old system to old system” into one using a simple and clear new process model for integration. One of the reasons for selecting this case is the significant need to integrate “old systems with other old systems”.

The integration process has many approaches and models, i.e. V‐Model which is mostly used during the life cycle of building a system. What makes this research unique is the introduction of the “M‐model” that facilitates integration of “existing / old” large scale complex systems with each other. The M‐Model starts with defining the “Problem statement,” then the sequence of building‐up documents and plans leads to a master plan documented called “SOSE Master Plan (SOSEMP).” Some case studies will be discussed.
7.5.1 Capacity for Engineering Systems Thinking (CEST) and Project Success
Authors: Frank Moti , Sadeh Arik , Ashkenasi Sharon
Published: November 2014

Despite the vast amount of literature available on systems engineering and project management, about two‐thirds of all projects still fail. A review of both project management and systems engineering publications reveals that most of these works focus on processes. We suggest focusing on people – project managers and systems engineers. One of our previous studies dealt with project managers; the current paper focuses on systems engineers. The paper presents findings of a study aimed at exploring the relationship between systems engineers' capacity for engineering systems thinking (CEST), project types and project success. The study findings show that there is a significant correlation between CEST and project success. The extent of the project's novelty is a moderator variable that affects this correlation. The more innovative the project is, the higher the correlation between the subjects' CEST and project success.
8.3.2 Using FMEAs to Improve Healthcare Study Design
Authors: Baird Pat
Published: November 2014

There is an intense focus in the United States on ways to improve Healthcare Quality. However, the process of measuring quality improvements can be difficult. This paper proposes the use of traditional FMEA techniques on study design, with a goal of improving the quality of the studies themselves. An example study is examined and a FMEA is performed.
8.6.1 Energy Conservation in Cloud Infrastructures
Authors: Mehta Avinash , Menaria Mukesh , Dangi Sanket , Rao Shrisha
Published: November 2014

—With the growth of cloud computing, large scale data centers have become common in the computing industry, and there has been a significant increase in energy consumption at these data centers, which thus becomes a key issue to address. As most of the time a data center remains underutilized, a significant amount of energy can be conserved by migrating virtual machines (VM) running on underutilized machines to other machines and hibernating such underutilized machines. This paper aims to design such a strategy for energy‐efficient cloud data centers. It makes use of historical traffic data from data centers and uses a service request prediction model which enables the identification of the number of active servers required at a given moment, thus making possible the hibernation of underutilized servers. The simulation results indicate that this approach brings about a significant amount of energy conservation.
9.2.1 Transforming systems engineering from a cargocult to a rigorous evidence‐based profession: Empirical research into the foundations of ISO 15288 and ISO 26702
Authors: Sparrius Ad
Published: November 2014

System engineering is becoming a standards‐driven profession, with an increasing number of ISO standards de facto documenting the body of system engineering knowledge. However, the hard evidence to back up those standardization efforts is lacking. Few, if any, controlled experiments have been conducted. For instance, if a new aircraft were to use a novel new material, it would be reasonable to assume that the strength of that material had been carefully determined by rigorous experiments. System engineering has not been subjected to similar engineering practices.

System engineering needs robust research to provide a solid foundation for it, but unfortunately such research is sadly lacking. This paper will identify the foundation of system engineering and determine whether or not it is evidence‐based and backed up by serious research. It will also identify some outlines for system engineering research.