bluuebunny/crossref_metadata_2025_split huggingface dataset:
7.4.1 Towards a Value‐Driven Design Methodology – Enhancing Traditional Requirements Management Within the Extended Enterprise
Authors: Monceaux Anne , Kossmann Mario 
Published: November 2014

AbstractDuring the initial phases of a new aircraft program, many conceptual decisions are made, concerning primarily the early product positioning with regard to competitors, the definition of the program's high level objectives, the architectural design choices and the selection of the preliminary design solutions. All these decisions are made on the basis of their assumed “Value”, i.e. each choice is expected to generate value for the customer and/or other stakeholders. Although many methods and tools are used to support the necessary analyses and trade‐off activities, plus the subsequent decision‐making; value related information such as concrete value drivers that allow for early conceptual orientation at different development levels are not usually shared explicitly within the extended enterprise between the concerned organisations.Current Systems Engineering (SE) standards do not address ‘Value’ in much detail. Yet, understanding what drives the generation of stakeholder value in a given business context, is fundamental to promoting a common and clear vision throughout the extended enterprise, of what should be the focus of their early, conceptual work at all levels of development. In light of increasing pressures to reduce development cycles and times‐to‐market, companies at several levels within the extended enterprise have to start working ever earlier in a programme context, long before their input requirements will have been cascaded down to them.This paper introduces a novel and iterative approach to address this problem – by making available business context related ‘Value Creation Strategies' including ‘Value Drivers' that can be cascaded down within the extended enterprise very early in a new aircraft development program. This will allow companies at any level to start their early, conceptual work on a much more relevant basis than would otherwise be the case. This Value‐Driven Design (VDD) methodology has been developed, and will be validated in the context of the CRESCENDO (Collaborative and Robust Engineering using Simulation Capability Enabling Next Design Optimisation) research project1. It does not introduce new value measurement methods, but rather aims at articulating a generic process, making use of Value representation and Value cascading as a complement to “traditional” requirements cascading.
7.5.2 APPLYING SYSTEMS ENGINEERING PRINCIPLES TOWARDS DEVELOPING DEFENCE CAPABILITIES
Authors: Smith C.J. , Oosthuizen R. 
Published: November 2014

AbstractDue to high cost of defence systems and the advent of multi‐role military platforms, defence forces can no longer replace old systems with similar newer systems, but need to effectively and continually re‐evaluate their defence capability requirements to optimise the utilisation of current and future systems. The “cradle‐to‐grave” System Life Cycle (SLC) process underpinning the Department of Defence (DOD) Acquisition Policy is based on four consecutive phases, namely Planning, Acquisition, Deployment and Disposal. This programme‐centric approach is prone to disjunction between capability requirements, present systems and future systems, and often neglects sufficient emphasis on the requirements definition activity. This paper suggests that System of Systems Engineering (SoSE) combined with a “cradle‐to‐cradle” Capability Life Cycle (CLC) process can provide junction between current systems in operation and future systems by taking an integrative, capability‐centric approach toward the phasing out and renewal of systems. The SLC and CLC processes are unified by four Systems of Systems (SoS) functions, namely Joint Concept Development and Experimentation, Joint Architecture Management, Joint Knowledge Management and Joint Operational Force Employment. Through this approach it is observed that the SLC Disposal phase does not necessarily follow on the Deployment Phase, but in actual fact becomes part of the Planning Phase. It is contended that sound Systems Engineering (SE) principles combined with SoSE and the CLC process offer a superior approach toward capability development and sustainment, resulting in a more cost‐effective (smaller and optimised) defence capability.
7.7.2 A survey on Industrial Practices in Requirements Engineering
Authors: Fanmuy Gauthier , Foughali Ghassen 
Published: November 2014

AbstractRequirement Analysis and Modeling Process (RAMP) is a project born in 2009 in France from a joint initiative between 3 major industrial companies belonging to different domains (Aerospace, Automotive, Energy), 2 SMEs (Service consulting, Tool supplier) and 4 Research Lab & Universities in order to improve the efficiency and quality of requirements expressed in natural language during the development of complex systems.Starting from a common view of the problem from industrial partners and the state of art in Requirement Engineering and Modeling, this project intends to deliver short & mid term solutions based on existing tool as well as promising research tracks in this field though a singular partnership organisation under the umbrella of AFIS (French Chapter of INCOSE).This paper presents the results of a survey made in 2010 in the framework of the RAMP project on industrial practices in requirements engineering. This survey was made by interviews and on line questionnaires on over 22 industrials.
8.2.2 Infrastructure Control Modeling Language (ICML)
Authors: Aslaksen Erik W. 
Published: November 2014

AbstractThe purpose of the model is to provide a consistent means of presenting the evaluation of options for upgrading the control systems of infrastructure, such as railways, power grids, water supply schemes, road networks, etc. The infrastructure typically has a design life of 100 years, whereas the control systems have a design life of 20 years or less, resulting in several upgrades during the life of the infrastructure. Such upgrades are generally justified on the basis of a Business Case that evaluates a number of options, including the “do nothing” option, and that meets the requirements on format and level of detail of the funding body. This paper describes a framework, or meta‐model, for the development of executable evaluation models suitable for meeting such requirements.
8.3.1 Towards Integrating Assurance Cases into Risk‐Based Requirements Management
Authors: Feng David , Eyster Curt 
Published: November 2014

AbstractIn the medical device industry, the FDA has seen an increase in number of recalls of medical devices due to the ever‐increasing complexity in recent years. Several high profile recalls involving infusion pumps have prompted the FDA to reconsider how device safety should be managed, reviewed and approved. An assurance case has been cited as a promising tool to address this growing concern. An assurance case is a resource‐intensive endeavor that requires additional effort and documentation from device manufacturers. Without a well‐organized requirement infrastructure in place, such “additional effort” can be substantial, to the point where the cost of adoption outweighs the benefit of adoption. In this paper, we present a Risk‐Based Requirements and Assurance Management (RBRAM) system. The RBRAM is an integrated framework that combines Risk‐Based Requirements Management (RBRM) with the assurance case methodologies. Such an integrated system can help manufacturers leverage an existing risk management framework to present a comprehensive assurance case report with minimal ongoing efforts while providing a supplementary approach to reexamine the integrity of the system design in terms of the mission objective, with which device manufacturers intend to assure.
8.3.2 Generated Risk Event Effect Neutralization: Identifying and Evaluating Risk Mitigation Strategies During Conceptual Design
Authors: Krus Daniel , Grantham Katie , Murray Susan 
Published: November 2014

AbstractIn the design of new products and systems, the mitigation of potential failures is very important. The sooner potential mitigation strategies can be employed, the lower the cost of those changes will be. Still, there needs to be a means to generate and evaluate mitigation strategies to supplement the existing expertise of the designer. By combining a mitigation strategy taxonomy with various rating strategies, a means to quickly select strategies and demonstrate their effect on the risk of failure can be obtained. This paper explains the risk mitigation selection and evaluation methods, including the mapping calculations used to evaluate strategies and their use in a method to move from a functional model of a new product to a selection of mitigation strategies that can be compared, and select the best strategy for the product.
8.7.1 Comprehensive Requirement Traceability Information, and Relations in Project Life‐Cycle
Authors: Shukla Vikas , Auriol Guillaume , Baron Claude , Zhang Xinwei 
Published: November 2014

AbstractProper management of requirement traceability information is vital for the project success. Often, it is debatable what to trace and how, without burdening the engineer with useless information. Requirement engineering in context of hardware intensive systems employs different techniques for traceability recovery, and management. In this paper, we have tried to address the problem of requirement traceability in context of hardware intensive systems' requirement engineering. We have classified the information, which needs to be traced in eight categories, and distinguished their usage in various systems engineering activities throughout the project lifecycle. We have tried to specify the degree of granularity of information at various levels, and their relationships between various levels. We used SysML to present our approach through an example.
9.2.1 The One‐eyed Systems Engineer – Pirate or Prophet?: An analysis of the effectiveness of different systems engineering leadership styles
Authors: Kemp Duncan , Elphick Jon 
Published: November 2014

Abstract‘In the land of the blind, the one‐eyed man is king‘. This is particularly true in leading the introduction of Systems Engineering in a new domain. This could be in a sector new to Systems Engineering, such as transportation or biomedical. It could also be a new application in a traditional sector, such as system of systems or service engineering in defence. The challenges are many: there are few case studies; immature processes; limited tools and best practice; and data and information are missing. Yet in sectors such as transportation and infrastructure there is a strong demand to do something that will improve value for money – and a one‐eyed systems engineer can make a persuasive case for investing in Systems Engineering.So is the one‐eyed systems engineer a prophet – leading their organisation through the wilderness to the Promised Land? Are they a pragmatist, supporting the prophet and making sure that they deliver what the prophet has promised? Are they a perfectionist, who knows that if the Systems Engineering process is followed diligently it will deliver significant benefits? Or are they a pirate, selling shoddy Systems Engineering practice to desperate customers?This paper employs Checkland's Soft Systems Methodology to explore the different types of Systems Engineering leadership that the authors have seen across multiple sectors. It examines the associated mindset, approaches, values and personality types of the leaders. The paper illustrates the applicability of the different types of leadership to different situations using examples from the UK rail and defence industries. The analysis demonstrates the importance of deploying the right type of Systems Engineering leadership, illustrating the potential pitfalls of mismatching organisational context and Systems Engineering leadership style, and highlighting the non‐Systems Engineering skills and competencies that are essential to realising real value through Systems Engineering.
9.5.1 Characterizing the Accuracy of DoD Operating & Support Cost Estimates
Authors: Ryan Erin T. , Jacques David R. , Ritschel Jonathan D. , Schubert Christine M. 
Published: November 2014

AbstractFor decades, the DoD has employed numerous reporting and monitoring tools for characterizing the acquisition cost estimates of its major programs. These tools have resulted in dozens of studies thoroughly documenting the magnitude and extent of DoD acquisition cost growth. However, little attention has been paid to the behavior of the larger cost component of a system's life cycle cost: Operating and Support (O&S) costs. Consequently, the DoD has little knowledge of how O&S cost estimates behave over time, and virtually no insights regarding their accuracy. In a previous paper, the authors describe an analytical methodology for remedying this deficiency via a study to characterize the historical accuracy of O&S cost estimates. The results of this study are presented here, and indicate there tend to be large errors in DoD O&S cost estimates, and that the accuracy of the estimates improves little over time. However, the results also suggest the possibility of improving the accuracy of these estimates via a stochastically‐based predictive cost model.
9.7.1 Model Based Tool for Planning Optimal Integration Processes Under Severe Uncertainty
Authors: Tahan Meir , Benish Roy 
Published: November 2014

AbstractThe preparing of an integration plan is usually done intuitively by experienced engineers based on their previous experience and the project constraints. Since the plan is intuitive, it may be not optimal. The integration process involves severe uncertainties, such as units not being available on time, integration increment duration, and testing costs. Many times such uncertainties cause changes in the project plan. The integration team may find that they are not prepared for these changes –again, because the integration plan is not optimal.This work offers a model‐based software tool for finding an optimal path for system integration. The tool finds the optimum path assuming deterministic integration parameters or parameters with inherent uncertainties.The tool is designed for project managers, integration teams and academic integration research. It has a built‐in flexibility in order to serve a variety of organizations and different users.
10.1.1 A Commonsense‐Driven Architecture Framework. Part 1: A Car Manufacturer's (naïve) Take on MBSE
Authors: Góngora Hugo G. Chalé , Dauron Alain , Gaudré Thierry 
Published: November 2014

AbstractThis paper tells a short story on our journey in “Model‐based‐land” and on our quest of Systems Engineering maturity. It presents an overview of our impressions on the MBSE landscape and of the approach that we have adopted on MBSE, and gives a brief overview of the first results of this approach. This paper is the first part of a three‐fold communication on current initiatives at Renault aiming at improving the efficiency of product development and mastering the complexity of automotive systems. These initiatives concern the development of MBSE and, in particular, the definition of an automotive architecture framework.
10.2.2 Guide for Selecting an Appropriate Competency Assessment Instrument
Authors: Ring Jack 
Published: November 2014

AbstractA survey of INCOSE Fellows revealed near‐unanimous agreement that system engineering competency assessment must be improved. Based on the principle that prudent selection authorities first establish selection criteria the Fellows committee authorized a volunteer project to devise a selection guide for choosing among competency assessment instruments and/or highlighting improvement opportunities in current ones. This paper presents project results, notably, recommended criteria and method that will help choose an appropriate candidate competency instrument and several recommended fallibility tests that other interested parties are encouraged to perform in order to make this selection guide even more fit for purpose.
11.1.3 Engineering Clean Energy Systems
Authors: Pavlak Alex 
Published: November 2014

AbstractWhile new technology and innovation is important, Systems Engineering (SE) is essential for the development of clean energy systems. A main advantage of an SE approach is that it allows society to focus resources and avoid big mistakes. By comparing current clean energy development efforts with SE best practices, we identify strengths, weaknesses and novel SE challenges. This comparison will highlight the importance of: broadly accepted strategic goals; employing scenarios to establish direction and development priorities; evaluating performance of systems not components; phased development to respond to new knowledge; critical reviews to establish broadly accepted fact; disciplined value choices based on evidence rather than aspirations; and governance (roles and responsibilities). Truly novel challenges are accommodating the number and diversity of stakeholders and making broadly accepted value choices. The next step should be a trustworthy set of strategic systems scenario tradeoffs. An unanswered question is who best provides overall coordination? Clean energy development is a grand SE challenge. Society needs to do this right.
11.4.1 Systems of Systems (SoS) Engineering: a view from the inside looking out
Authors: Siemieniuch C.E. , Sinclair M.A. 
Published: November 2014

AbstractThe paper provides a human factors based perspective on System of Systems Engineering (SoSE), different to that usually encountered in the military and civilian arenas. This reflects the evident fact that the vast majority of System of Systems (SoS) are created, configured, controlled, supervised, maintained, upgraded and decommissioned by humans. The paper commences by outlining what an SoS feels like from the inside, and then goes on to outline a selection of issues of importance to SoS engineering and performance stated from a human factors perspective. These include tipping points, incomplete knowledge, SoS immortality, complexity, and the importance of trustworthy behaviour within the SoS. Some design approaches to address these issues are then outlined.
11.4.2 Measuring the Requirements Allocation Capacity within a System of Systems
Authors: Flanigan David , Brouse Peggy 
Published: November 2014

AbstractDuring the initial development of a System of Systems (SoS) capability, the developers and stakeholders may not be aware of all the options that are available to identify and allocate requirements at the system level. Traditional Systems Engineering techniques do not have the ability to construct and evaluate if these SoS requirements will be satisfied or not. This paper identifies a process in which to develop SoS requirements, trace them to their constituent systems, and evaluate whether the allocation was successful or not.
An Alenia Aermacchi study and experience on MBSE application
Authors: Luciana Lo Verde , Guido Pavan , Elena Valfrè , Marco Fioriti 
Published: November 2014

AbstractThis paper describes how traditional systems engineering activities conducted in Concept and Configuration Development phases of Aeronautical Product Life Cycle have evolved for the design of Unmanned Aerial System (UAS) for Intelligence Surveillance Reconnaissance mission, by applying Model Based System Engineering (MBSE) approach. This methodology will make easier the support to other phases of the process, like the Product Development. It has been considered the system modelling language (SysML) as reference model based language.The design process and the findings about the modelling and simulation that has been considered by Alenia Aermacchi are described in the paper.
Analyzing Human Machine Interaction and Interfaces through Model Based System Engineering Practices
Authors: Orellana Douglas , Madni Azad 
Published: November 2014

AbstractAs systems continue to grow in scale and complexity, human machine interactions and the human machine interface (HMI) become a crucial consideration in overall system design. In complex systems, humans are often part of the complex system as opposed to being just users of the system. The human mental model, work instructions, and procedures are key attributes that a system architect needs to analyze to ensure the success of the overall human‐machine system. Model Based System Engineering (MBSE) techniques potentially offer new ways for system architects and engineers to conceptualize and analyze HMI requirements and use the findings to specify its design.
Future Combat Systems Case Study for Analysis of System of Systems Approach
Authors: Srivastava Tina P. , Piper Victor L. , Arias Jose M. 
Published: November 2014

AbstractThe system of systems approach used in the Future Combat Systems (FCS) program is compared to the systems approach of the Army Brigade Combat Team Modernization (ABCTM) and Ground Combat Vehicle (GCV) projects. Several systems engineering tools are applied in order to assess the effectiveness of each method, covering the technical, scheduling and financial perspectives. System complexity and stakeholder relationships were determinant in the transition away from the system of systems approach.
Gaps in the Body of Knowledge of Systems Engineering
Authors: Squires Alice , Olwell David , Roedler Garry , Ekstrom Joseph J. 
Published: November 2014

AbstractThe boundaries of systems engineering are evolving as system related needs evolve. These ‘fuzzy’ boundaries result in gaps between what users in the systems engineering community need and what the body of knowledge of systems engineering provides. This paper covers various use cases of the body of knowledge of systems engineering and explores gaps in the existing knowledge base in two areas: 1) related disciplines, and 2) emerging systems engineering topics.
A model‐based method for the synthesis and optimization of systems architectures
Authors: ALBARELLO Nicolas , WELCOMME Jean‐Baptiste 
Published: November 2014

AbstractThe architecture design process requires to define several design alternatives and to compare them in order to choose the most relevant system architecture given a set of objectives. Nevertheless, designers are generally constraint to restrict their studies to a small set of alternatives due to time constraints and combinatorial aspects of the problem. The objective of our method is to assist them by automatically generating a larger number of design alternatives. The proposed algorithm will first generate alternatives by adding components to the architecture and allocate them to functions. The originality of our approach is that it takes into account two rules that ensure the viability (component–to‐component consistency) and the validity (function‐to‐component consistency) of the generated architectures. Once a set of consistent alternatives are generated, we use them as an input of a multi‐objective genetic algorithm to propose a set of Pareto‐optimal alternatives.
A Model‐based Reference Architecture for Medical Device Development
Authors: Corns Steven , Gibson Chad 
Published: November 2014

AbstractThe application of systems engineering within the medical device domain must adapt to its unique challenges such‐as the regulatory environment that these devices have to be designed within to ensure patient safety, and the nature of the interactions between the device and the patient. The sheer number of regulations imposed by government agencies such as the U.S. Food and Drug Administration and various international agencies adds to the complexity of designing these systems. This also presents an opportunity to implement a Model‐Based Systems Engineering (MBSE) approach to capture the regulatory environment and map those specialized requirements to components within the system that address those requirements. In this study, we present a model of a reference architecture that can be used as a starting point for the system design of medical devices. Although the state of the model has not been fully matured, this approach offers the potential to more efficiently address the complex regulatory requirements, and reduce the time to design medical devices.