bluuebunny/crossref_metadata_2025_split huggingface dataset:
9.2.1 Developing Product Lines in Engine Control Systems: Systems Engineering Challenges
Authors: Atherton Malvern J. , Collins Shawn T. 
Published: November 2014

AbstractRolls‐Royce is developing a Full Authority Digital Electronic Control (FADEC) product line for helicopter and light turboprop applications. This is driven by market demand to reduce the proportional cost of control systems relative to the engine, and to field applications in timescales that preclude traditional clone‐and‐own approaches. The goal is to develop reusable control system architectures, requirements, and verification evidence, which can be used on a variety of applications. Key challenges include addressing military and commercial constraints with the same architecture, designing in flexibility for future applications, and leveraging global company capability in processes, tools, and supply chain strategy. This paper describes Rolls‐Royce's experience adapting existing software product line principles to apply at the control system (hardware and embedded software) level in light of certification guidelines from DO‐178B and ARP4574A. Lessons learned from moving through the “V” life cycle provide insight into how Systems Engineering adds value in this context.
8.2.1 Integrating System Models around Decisions
Authors: Mendonza Pradeep , Fitch John 
Published: November 2014

AbstractDecisions are the primary future‐creating human thinking process. Every system or product in existence today is the direct result of a network of interdependent decisions that have been framed, analyzed, made and implemented. As such, a decision model is ideally suited to serve as the integrative framework for Systems Engineering knowledge, processes and practitioners.The U.S. Army Tank Automotive Research Development and Engineering Command (TARDEC) has developed an Advanced Systems Engineering Capability (ASEC) framework that leverages a decision model as the integrative mechanism to provide the context for all other system models. These models, known collectively as the “5‐M Model” of integrated systems knowledge, include:
SE Process (Vee) model
Math/Physics models
Lifecycle models
Architecture models (e.g. SysML)
Roadmap models

This paper will describe the relationships between these models as implemented within the ASEC framework. The role of each model in informing decisions to improve decision confidence, speed, quality, leverage and implementation will be explained. A metrics strategy to confirm these benefits will be proposed.
6.1.1 A Framework for Harmonizing Systems Engineering and Off‐The‐Shelf Procurement Processes
Authors: Saunders Steven J. 
Published: November 2014

AbstractSystems engineering, as a discipline, has been utilized since the middle of the twentieth century to successfully execute numerous complex system developments. Many of the practices and standards utilized are perceived as being biased towards new development systems. With the changing imperative to deliver “to market” quicker and cheaper, many programs are placing a higher reliance on the use of Off‐The‐Shelf (OTS) components in the final system solution. Integrating this strategy into traditional systems engineering practices has led to challenges in the past.This paper describes a framework successfully utilized on the Royal Australian Navy (RAN) Air Warfare Destroyer (AWD) Program to integrate an OTS procurement strategy into a System Architecting and System Engineering environment. The framework highlights the benefits of integrating the stakeholder, System Architect, Systems Engineering and Program Management communities to form a “collaboration” to jointly work to rapidly ameliorate risk in the early phases of the program. Latent gaps between input needs and the emergent OTS capabilities are concurrently analyzed and the Technical Integrity Risk successively estimated. System architecting methodologies are employed to help hide unnecessary detail in the early concept definition phase to help support rapid alternate “trial” architectures to be effectively analyzed from a total risk point of view. The use of this risk based strategy from early program inception provides the mechanism to manage and minimize risk and in addition, predict the confidence in program success.
3.3.1 An Improved Taxonomy for Major Needs and Requirements Artifacts
Authors: Ryan Michael J. 
Published: November 2014

AbstractEach of the major systems engineering standards and guides has a different focus, uses slightly different terms for the various needs and requirements artifacts, and reflects a different emphasis on each of the activities from the enterprise level down to the system level. While there is a lack of consistency among documents with the use of terms and artifacts (and all are internally inconsistent to some degree), the differences are not significant and mostly reflect the different emphases on particular levels or specific parts of the overall process. None‐the‐less, the disparate views result in considerable obscuration of the underlying process which can only be resolved after considerable study and deliberation. Worse, the lack of a common taxonomy in the early part of system/requirements engineering process adds confusion at a very critical time in the definition of the system of interest. This paper reviews the early processes and the needs and requirements artifacts described in the major systems engineering standards and guides. An improved (synthesized) taxonomy is proposed that clarifies the language used to describe the major processes and artifacts in the early portion of the system life cycle.
10.4.2 On an Appropriate Set of Characteristics for the Structure of Upper‐level Standards When Used to Establish Business Environments
Authors: Jones Bronwyn L. , Ryan Michael J. 
Published: November 2014

AbstractThe establishment of business environments has been greatly enhanced through the development of upper‐level standards that provide ‘strategic tools and guidelines…They ensure that business operations are as efficient as possible, increase productivity and help companies access new markets‘. (ISO 2012). Once a suitable upper‐level standard is adopted by an organisation, its processes, activities, and tasks must be mapped (or allocated) into the organisation's life cycle stages, procedures, and roles so that subsequent planning can occur, resources can be allocated, and work conducted. Organisations may also wish to claim (or will often be obliged to show) conformance to a particular standard. In many cases, however, this mapping is only able to be demonstrated in general terms, so that upper‐level standards are not always used as comprehensively as they are intended. In order to facilitate the establishment of business environments, this paper addresses what is required for an upper‐level standard to be mappable and then proposes characteristics for the structure of such standards that would enable them to be more readily mappable into a business environment. The Stakeholder Requirements Definition process of ISO/IEC 15288 is used as an example to illustrate how structuring a standard against such characteristics might improve the ability to establish business environments.
9.5.2 New Opportunities for Architecture Measurement
Authors: Carson Ronald S. , Kohl Paul V. 
Published: November 2014

AbstractRecent industry progress in architecture definition, architecting tools, model‐based systems engineering, and customer policy has created both a nexus of demand and opportunities to advance the state of architecture measurement. In this paper we describe recent industry working group results and propose architecture measures intended to meet the needs of systems engineers and their program managers as leading indicators of system development health. The measures are documented using the PSM (Practical Software and Systems Measurement) methodology. General techniques are proposed that take advantage of the opportunities afforded by the current architecture modeling environment to provide a basic measurement plan for architecture, including leveraging existing measurement concepts found within the Systems Engineering Leading Indicators. The result is a comprehensive and tailorable suite of measures that can provide decision‐making data to program managers and technical program leaders.
10.1.1 Managing the Project Team as a Special Class of Stakeholder for Enterprise Transformation Projects
Authors: Hahn Heidi Ann 
Published: November 2014

AbstractThe Los Alamos National Laboratory's (LANL's) Enterprise Project – the implementation of a commercial off‐the‐shelf (COTS) enterprise resource planning (ERP) system to replace the home‐grown business computing systems in use since the early 1980's – provides a provocative case study regarding the management of project teams in which team members are, themselves, stakeholders. This paper describes the project's approach to stakeholder management for the project team, which had mixed success, discusses the theoretical underpinnings of the approaches used, and provides lessons learned for handling project team members as a special class of stakeholders who have special needs. Specifically, it is noted that project team members may be either system advocates or system critics or adversaries. It is recommended that transition management tactics be developed in anticipation of both types of stakeholders being present on the project team.
Product Owner Agile Systems Engineering Strategies
Authors: Palmer Kent 
Published: November 2014

AbstractIn the Scrum Agile approach there is an important role defined for the Product Owner who is the proxy for the Customer and who is supposed to be engaged in laying out the work to be performed by the team by prioritizing the product Backlog. It turns out that this is a neglected role in the literature with only a few books dedicated just to this role, the most interesting of which is by Pichler1, while there are many books dedicated to the Scrum Master role. Of course the role is mentioned in many other of the basic books on Scrum, but we would expect more explicit refinement of the role based on the fact it is essential in driving the process. Also in larger organizations this role becomes conflated with that of the Product Manager, and Leffingwell suggests that the Product Owner is a transformation of that role and that Product Owners probably work for the Product Manager on large projects. What is called Product Manager in commercial firms is the Systems Engineer role in aerospace. The Systems Engineer is the person responsible for the whole product working as advertised when delivered to the customer. The techniques that the Product Owner should draw from are those developed in Systems Engineering as a discipline. However, we need to make those techniques of Systems Engineering more agile in keeping with its spirit of increased efficiency and effectiveness in product development. Here we will apply what we learned about the essential structure of the product and its lifecycle in terms of traceability in the paper “The Essential Nature of Product Traceability and its relation to Agile Approaches” in order to explore the nature of this role, along with the idea of Pichler not mentioned in his book but developed later about multidimensional backlogs.
6.4.2 System Verification by Automatic Testing
Authors: Øvergaard Asgeir , Muller Gerrit 
Published: November 2014

AbstractThis study elaborates the application of automated testing on an integrated software intensive system. We have been able to research the topic using a Kongsberg Maritime (KM) system, K‐Master, as data provider. We have integrated an automated test framework into the test environment. The test team can use this framework to perform testing automatically.The test team can use the effort released by automation to increase the amount of tests run. The test team can also choose to spend the released effort on other impending test activities. If we increase the amount of tests run, it can result in uncovering a higher number of problems in an earlier phase of the project.This study shows that spending resources on automatic testing, resources, and save cost throughout the development project, while increasing coverage and frequency of testing. The result of this study will help justifying such decision.
Enterprise Scheduling for Large‐Scale Integrators (LSIs)
Authors: Sobolewski Chris 
Published: November 2014

AbstractLarge scale integrators (LSIs) are concerned with the assembly of multiple systems into a “system of systems.” Architecting an Enterprise schedule solution that supports LSI systems engineers requires examining tool commonality with the individual systems, total solution cost, schedule visualization, and cross‐schedule integration techniques. Examined are concepts for Enterprise schedule management unique to this level for configuration management, adherence to systems engineering control gate policy, and data trending.
6.5.2 Modeling and Analysis Framework for Risk‐Informed Decision Making for FAA NextGen
Authors: Blackburn Mark R. , Pyster Art , Zigh Teresa , Turner Richard , Dillon‐Merrill Robin 
Published: November 2014

AbstractThis paper discusses an analysis and modeling framework that is being developed to support risk‐informed decision‐making for the Federal Aviation Administration Next Generation Air Transportation System (NextGen). Discussions with over 60 stakeholders identified challenges for those responsible for planning, developing, and deploying NextGen capabilities. There are a confluence of technical and non‐technical factors that are important to effectively roll out capabilities. People's internal knowledge is much greater than what is captured externally or formally. Additionally, this knowledge and the causal relationships to program factors are not formalized in a way to support this complex decision‐making process. The paper describes a Bayesian network‐based analysis and modeling framework with usage scenarios for calculating cost, schedule and benefit risks to support collaborative decision‐making throughout the phases of the FAA's acquisition lifecycle process.
4.2.3 Aircraft Agile Integration‐Design for Quick Reaction Capability Programs
Authors: Anderson Steven , Dove Rick 
Published: November 2014

AbstractMilitary Quick Reaction Capability (QRC) programs are becoming more typical; with miracles expected. Higher performance and quality are demanded in less time with reduced cost. Aircraft platforms are continually modified for the latest mission system technology, which often requires a unique balance of secondary aircraft systems (structure, environmental control, and electrical). This paper investigates an agile integration‐design architecture that is capable of reducing time and cost to the customer, while increasing mission performance and quality. A successful implementation would include increased risk mitigation for the program, as well as flexibility for future system evolution or even mission repurposing. With commercial aircraft as the platform for QRC mission systems integration, this paper shows how to create mission system modifications on a much shorter time scale then currently possible, by identifying and exploiting aircraft features that exist across multiple platforms, or exist in reoccurring patterns on the same platform.
6.3.1 COSYSMO Calibration Steps and Results
Authors: Valerdi Ricardo , Christopherson Timothy L. 
Published: November 2014

AbstractThis paper provides insight into calibrating a systems engineering cost model (COSYSMO) by providing a process that organizations can follow to improve their estimation accuracy. A specific example is provided from Raytheon Missile Systems to illustrate how data are collected and how they influence the cost estimating relationship. The results from this specific case are generalized to other organizations who wish to improve their cost estimation capabilities in systems engineering.
Behavioral Economics and the Design of Systems Engineering Measures
Authors: Brown Barclay 
Published: November 2014

AbstractThe design of measures is an art and a science. Taking a systems thinking perspective in designing a measure requires considering how the measure will be used, what it means, what kind of behavior it will produce, and the results of that behavior. Treating the implementation of a measure as a move in a game can give new insights into what will happen when the measure is introduced. Measures may be ignored if it is not clear what they mean, or if there are no standards or goals for the measure. Measures that are published, evaluated and used to determine performance levels of people and groups, and which have standards, norms and goals, in turn affect behavior and are subject to gaming. It is these measures which must be analyzed for unintended, or worse yet, adverse consequences. Short of finding perfect measures, the practice of balancing measures can be used to mitigate such consequences.In theory there is no difference between theory and practice. In practice there is. (Yogi Berra)In pursuing a comprehensive approach to the measurement of systems engineering and systems development work, we must face difficulties in both theory and practice. The central questions we must answer are,
What should we measure?
How should we measure it?
What does it mean?
How will measuring this affect behavior?

Most work in the area of measures focuses on the first two questions. The field of data analytics and interpretation focuses on the third, and the field of behavioral economics is interested in the fourth. This paper will present some key ideas about how measures can be designed and conducted, applying some insights from these diverse fields.Part I will focus on current practice, as assessed in a series of informal interviews conducted by the author in 2011–2012 with several active, senior practitioners in systems engineering measurement, mostly in the aerospace and defense industry. The goal was to understand how systems engineering is measured in current practice and how those measures are used. Part II looks at the question of how measures are designed, their component parts and how meaning for measures can be determined. In Part III the focus is on unintended consequences of applying measures—the behavioral economics perspective. Some guidelines will be suggested for the successful design of measures that avoid or minimize unintended consequences. This paper aims at suggesting a new way of thinking about and designing measures and does not claim to present an explicit solution to any or all measurements needs. In fact, it is likely that the topic of measurement will appear more problematic after understanding what follows, than before.
11.4.1 SE approach to ubiquitous maintenance system design: Requirements development methodology
Authors: Jeong Suho , pil Kim Jun , Cha Jae‐Min , Suh Suk‐Hwan , Lee Joong‐Yoon 
Published: November 2014

AbstractU‐maintenance system means a supporting system for maintenance of production facility via ubiquitous technology, such as RFID (Radio Frequency Identification, USN (Ubiquitous Sensor Network), RTLS (Real Time Locating System), etc. Compared with conventional maintenance system including e‐maintenance system, u‐Maintenance system has high potentials in many respects. However, from the system design perspective, u‐maintenance system is a complex system where many aspects should be taken into consideration. We approach the problem by systems engineering. In this paper, we focused on a requirement development methodology. The usefulness of the proposed methodology was illustrated by a u‐maintenance system for industrial steel‐plant.
3.3.2 Bridging the Gap Between Human Thinking and Machine Processing in Developing and Maintaining Domain Knowledge
Authors: Zayed Rami , Kossmann Mario , Odeh Mohammed 
Published: November 2014

AbstractThis paper is concerned with the gap between human and machine thinking in the area of the development and maintenance of domain knowledge; and how the differences in the way humans and machines think or process information can be exploited for the benefit of the domains in question.Looking in turn at mind mapping as an effective human thinking technique and ontology as a machine readable standard, the paper will discuss the role of mind mapping in the Requirements Engineering (RE) process in general; and provide some insight into the development of the OntoREM‐MindMapper (OMM) tool that will serve to support the Ontology‐driven Requirements Engineering Methodology (OntoREM) by enabling controlled transfers of domain knowledge between mind maps and ontologies.
8.5.2 Structural Modeling in Biomedical and Product Engineering
Authors: Graves Henson 
Published: November 2014

AbstractStructural modeling is common for biomedical systems as well as manufactured products. Examples and experience from both fields clarify modeling issues applicable to each field. Modeling in both fields shares the commonality that a model describes one or more physical, or virtual, structures in terms of their components and connections between components. Modeling effectiveness depends on the relationship between the model and the systems which realize or conform to the model. The logic based approaches used for biomedical modeling can be adapted for engineering with the promise that automated reasoning can be integrated into product development and maintenance. Modeling languages such as SysML provide good graphical syntax and the concepts needed for representing product decompositions and interconnections in multiple domains. This paper illustrates the benefits of working within a logic‐based framework which incorporates the concepts of part decompositions and interconnections found in SysML. The concept of a model as an axiom set used in conceptual modeling languages such as OWL 2 is applied to SysML models. This discussion is intended for model practitioners in both fields.
7.2.1 Bricks for a Lean Systems Engineering Yellow Brick Road
Authors: Hodges Ann 
Published: November 2014

AbstractA Yellow Brick Road can be thought of as the fabled path to a “promised land” where achievement of hopes and dreams is highly probable. Yellow bricks highlight the appropriate road, and destination mileage and speed limit signs support progress assessment to the chosen objective. Similarly, a common systems engineering (SE) framework, properly implemented at the approproate level of rigor, facilitates monitoring and achievement of a quality product that supports the intended mission. Bricks for a lean SE Yellow Brick Road are described. The bricks include a) using a common framework that integrates SE, project management and quality management; b) right sizing project implementation of this framework using a graded approach; c) applying the framework as early as possible; d) tailoring and waiving as needed; e) using project archetypes; and f) providing a repository that contains reuseable processes, plans, templates, examples, training and associated subject matter experts.
11.4.2 Assessing the Impacts of Uncertainty Propagation to System Requirements by Evaluating Requirement Connectivity
Authors: Salado Alejandro , Nilchiani Roshanak 
Published: November 2014

AbstractAlthough theoretically independent, requirements within a decomposition level of a system architecture are not isolated elements. For an existing design, a change of a requirement may endanger or facilitate fulfillment of other requirements within the same level of the decomposition. The present research suggests a requirement connectivity metric to evaluate the potential consequences that changing a requirement may have on a system with respect to fulfillment of other requirements. A particular aspect of the present research is the assumption that connectivity accounts only for requirements within the same decomposition level of an architecture, not for those flowing up or down the decomposition. The metric is used to evaluate different cases in which requirements are changed due to triggering of uncertain events during a project life‐cycle.