bluuebunny/crossref_metadata_2025_split huggingface dataset:
8.3.2 Systems Engineering meets Knowledge Management: Introducing a ‘System of Knowledge Management Approaches’
Authors: Brown Samantha F , Ragsdell Gillian 
Published: November 2014

AbstractThis paper highlights the complementarity between systems engineering (SE) and knowledge management (KM); in doing so, it offers a platform from which the development of both disciplines could be accelerated. By drawing attention to some of the challenges in the practice of SE and, in keeping with Martin (2002), the authors suggest that embedding relevant KM practice within SE practice may assist ‘traditional’ SE in meeting the demands of engineering current and future systems. Specific attention is paid to the importance of creating a knowledge sharing culture in SE practice and guidance is offered as to knowledge sharing methods which might be used effectively in particular SE settings.The paper begins by identifying some of the challenges that SE faces in contemporary practice. The focus then moves on to knowledge and its management. After an introduction to the distinctions between data, information and knowledge, and to a representative cycle of KM, emphasis is placed on the process of knowledge sharing and the characteristics of a knowledge sharing culture. Discussion moves on from the cultural dimension of knowledge sharing and into the contexts and environments of SE practice. Jackson and Keys' (1984) System of Systems Methodologies (SofSM) is introduced to trigger a taxonomical theme for the rest of the paper. In a similar way that Flood and Jackson (1991) link the SofSM to problem contexts, the authors overlay their taxonomy of SE contexts with knowledge sharing methods so as to guide the SE practitioner in an effective matching of method with context. The paper closes with reflections on the potential reciprocal relationship between SE and KM.
9.1.3 Development of a Framework of Research Topics in Systems Engineering
Authors: Ferris Timothy L.J. 
Published: November 2014

AbstractThis paper describes the method and result of developing a framework of research topics in systems engineering. The framework of research topics was developed as part of a project to develop a vision for research in systems engineering for use by INCOSE. This paper also describes the relationship of the framework of research topics and the description of the future of systems engineering presented in the INCOSE document: Systems Engineering Vision 2020. This paper shows significant agreement between the structure of systems engineering described in the Vision 2020 document and the framework developed in the vision for research in systems engineering. The processes used to develop both structures of ideas were conducted independently and were quite different. The agreement between them demonstrates the strength of the conclusion.
10.2.1 Implementing and Standardising Systems Engineering Practices within a Global Corporation
Authors: Berglund Fredrik , Böckmann Carsten , Cuklev Sasko 
Published: November 2014

AbstractDeveloping new products is in many respects the process of identifying and envisaging user needs and bringing those needs into life in a cost‐efficient manner, either utilizing existing technologies and solutions, or developing new ones. Product developing organisations are constantly challenged since new products must exceed expectations on quality standards in form, fit, and function – and that they must stand out from competition. This requires people with knowledge in many areas. Consequently, it is a multi‐disciplinary process involving many parallel activities, such as product planning, design, production, marketing and after‐sale.Systems Engineering (SE) has become increasingly important in these organizations in order to manage the shear complexity of managing large scale development projects and secure the quality standards for all emergent properties of a system. The main driver for introducing SE is that the complexity and interconnectedness of systems continues to grow and the growing shift of focus to the complete offer rather than the product itself. However, there exist little research summarizing experiences of implementing SE, and there remain uncertainties as to how SE should be tailored to specific settings in order to add value to a development organization. Especially, focus needs to be put on managing the complexity of creating product variety.This paper summarises our experiences from the continuous work to implement and standardise Systems Engineering practices within a global corporation in the transport solution industry. This includes a review of reports on SE implementations, a short description of the Volvo Group, and a summary of our experiences when implementing SE at various units and organisational levels.
Agent‐Based Modeling the Emergent Behavior of A System‐of‐Systems
Authors: Hsu John C. , Clymer John R. , Garcia Jose , Gonzalez Efrain 
Published: November 2014

AbstractNet‐Centric Operations (NCO) is operated on a System‐of‐Systems (SoS) communication environment. Emergent behavior is one of the five SoS characteristics. Layered SoS architectures start from the top SoS‐level containing emergent behavior. Conceptual agent‐based modeling was presented to simulate the four principles of emergence. The simulations covered the condition of emergence, non‐linear behavior and coupling relationship between agents. The four principles are interrelated. The emergent behavior has impacts on traditional systems engineering process. Neural network artificial intelligence may be needed to assist the understanding of emergent behaviors for architectural model development. Agent‐based modeling needs further development and should be integrated with neural network and SysML.
10.4.1 Architected Agile Solutions for Software‐Reliant Systems
Authors: Boehm Barry , Lane Jo Ann , Koolmanojwong Supannika , Turner Richard 
Published: November 2014

AbstractSystems are becoming increasingly reliant on software due to needs for rapid fielding of “70%” capabilities, interoperability, net‐centricity, and rapid adaptation to change. The latter need has led to increased interest in agile methods of software development, in which teams rely on shared tacit interpersonal knowledge rather than explicit documented knowledge. However, such capabilities often need to be scaled up to higher level of performance and assurance, requiring stronger architectural support. Several organizations have recently transformed themselves by developing successful combinations of agility and architecture that scale up to projects of up to 100 personnel. This paper identifies a set of key principles for such architected agile solutions for software‐reliant systems, and illustrates them with several case studies.
1.4.3 Simple SE Methods Deployed in Revitalizing the Nuclear Post‐ Irradiation Examination Capability for the Idaho National Laboratory
Authors: Zirker Larry R. , Hamelin R. Douglas , Braase Lori 
Published: November 2014

AbstractThe “crown jewels” of nuclear energy research facilities (i.e., hot cells, analysis systems, and scientists) have been centered at the Idaho National Laboratory for over 40 years, but in recent years, emphasis and funding for nuclear fuel research and development have declined to adversely affect the readiness and effectiveness of research facilities and equipment. Conversely, the current national nuclear renaissance forces the need for immediate enhancements in facilities, equipment, capabilities, and staff for the postirradiation examination (PIE) of nuclear fuel. PIE characterizes the “burn‐up” and structural integrity of fuel elements and defines the effectiveness of new fuels/alloys in search for optimum fuel burn‐up and alloys for current and next generation nuclear reactors. This paper details how a team of system engineers adapted simple system engineering tools and techniques for a customer unfamiliar with the power and effectiveness of system engineering, to achieve project success.
2.3.2 An Enterprise Systems Engineering Framework
Authors: Martin James N 
Published: November 2014

AbstractTraditional systems engineering (SE) is performed on a development project with only one or a few related systems being developed. Enterprise SE, on the other hand, must deal with deciding among many enterprise opportunities that the enterprise projects will work on. This entails several processes that are not provided for in traditional SE practice. An Enterprise SE Framework was developed to characterize the full scope of SE at the enterprise level.1 This framework was used to evaluate several case studies as part of my doctoral dissertation. This evaluation focused on how they used knowledge modeling techniques identified in my dissertation for development of an enterprise architecture.2
3.3.2 Polymorphic System Architecture
Authors: Bryson Jeff 
Published: November 2014

AbstractThe complexity of tomorrows problems will be far greater then problems we face today. This complexity will only increase the importance of systems engineering and systems architecture activities. As the value of the activities rise, the cost of the activities must fall. Neither a Multi‐year analysis and development schedule nor a short term schedule with a high risk of failure will be acceptable solutions. The solution for solving these complex problems will be to move systems engineering and architecture artifacts from the Non‐Recurring Engineering cost over head to reusable company assets. A Polymorphic System Architecture (PSA) is one way of achieving this goal.Run‐Time polymorphism (RTP) has been used in the software community for over 20 years to satisfy dynamic reconfiguration, plug‐n‐play, extensibility, and system redundancy requirements. RTP is also used to construct software Systems of Systems. Systems engineers now have the same requirements applied to system architecture. A PSA utilizes the same software technology but applies it to the system architecture (Bryson 2009). The goals of using a PSA are:
Reduce the complexity of the system architecture
Satisfy functional requirements within the system architecture
Define an architecture that has the potential to mature over time
Move the system architecture from cost overhead artifacts to company assets
Create an architecture library of reusable artifacts that can be reused to solve new problems
4.4.3 A Study of the Effects of Professional Society Development on the Advancement of the Profession: The Systems Engineering Example
Authors: Valerdi Ricardo , Deonandan Indira 
Published: November 2014

AbstractThe advancement of professions depends on global collaborations. Professional societies are enablers to this growth in a multitude of ways. Publication outlets to disseminate new ideas, collaboration mechanisms to form communities of interest and conferences to enable networking and recognition all play critical roles in defining and advancing disciplines. In response to this, INCOSE has made a conscious decision to hold its flagship event, the annual Symposium, at strategic locations around the world. At the moment, the majority of INCOSE members, approximately sixty percent, are based in the U.S. although the diversity of membership has increased over time. In this paper, we seek to analyze the impact of hosting a symposium in a particular location through the use of six retrospective case studies to determine how a professional society such as INCOSE can impact the systems engineering profession. We investigate the consequences of hosting a symposium in a specific region and analyze the impact of the symposium on the advancement of the profession of Systems Engineering
5.1.0 The Future of Knowledge Management in INCOSE
Authors: Forsberg Kevin , Roedler Garry , Ring Jack , Hodgson Ralph , Sillitto Hillary , Jorgensen Raymond 
Published: November 2014

AbstractThe goal of the Knowledge Management Working Group (KMWG) is to determine how technical INCOSE knowledge management needs are currently being met, and what the new state(s) should be. Input from the panel members, and most importantly from the audience for this panel discussion, will help shape the direction and future contributions of the INCOSE KMWG.One of our panelists, Jack Ring, says, “I claim that the Future Direction of Knowledge Management in INCOSE is grossly under‐conceptualized. Three concepts that may merit further dialogue are:
We could get on with developing and sharing knowledge about modeling stochastic systems, non‐deterministic systems, agent‐aided design and even generative/autocatalytic systems,
The engine for the G2SEBoK will be the next generation SE tool. Things like CORE, SysML‐oriented tools, OpEMCSS, etc., become plug‐ins,
The G2SEBoK should do more than talk ABOUT systems praxis. It should give examples of the work products. These should be real examples that are prompted by posing typical problems, then posting work products as proposed by participants.
Currently the final product from most INCOSE Working Groups is a printed document (which is also available in electronic form). Should this change?Another panelist, Raymond Jorgensen, says: “Wiki technologies have provided an excellent forum for encouraging improved communication and sharing across the community. At Rockwell Collins, a Wiki environment is being used to encourage sharing best practices across the enterprise. Instead of different business areas publishing unique practices in stale ”PDF“ files on local networks, one enterprise environment is being used to host the collective enterprise knowledge of best practices in engineering. Similar techniques could be applied at INCOSE.”If a Wiki is so good, why did the SEHv3.1 Wiki lay dormant on the INCOSE web site for over two years? Is a Wiki suitable for the INCOSE environment? If so, who will control it?
5.4.2 Ontology‐Enabled Traceability Mechanisms
Authors: Austin Mark , Wojcik Cari E. 
Published: November 2014

AbstractThis paper describes new models and mechanisms for ontology‐enabled traceability where design concepts are inserted between the already connected requirements and engineering objects Looking ahead, we envision that ontology‐enabled traceability will play an important role in the development of network‐enabled platforms for analysis, design, and early validation and verification of information‐age engineering systems.
7.2.1 Robust Decision Making
Authors: Dieckmann Christopher A 
Published: November 2014

AbstractThe Idaho National Laboratory is funded through the U.S. Department of Energy Office of Nuclear Energy and other customers who have direct contracts with the Laboratory. The people, equipment, facilities, and other infrastructure at the laboratory require continual investment to maintain and improve the laboratory's capabilities. With ever tightening federal and customer budgets, the ability to direct investments into the people, equipment, facilities, and other infrastructure that are most closely aligned with the laboratory's mission and customers' goals grows increasingly important. The ability to justify those investment decisions based on objective criteria that can withstand political, managerial, and technical criticism also becomes increasingly important. The Systems Engineering tools of decision analysis, risk management and roadmapping, when properly applied to such problems, can provide defensible decisions.
7.4.1 Contributions Towards Unifying System Semantics
Authors: Lawson Harold “Bud” , Persson Mats 
Published: November 2014

AbstractWhat is it that characterizes a system? Certainly as systems engineers this is a vital question to ask. While most will claim that it is a question of perspective (viewpoint and view), this does not help us in identifying key aspects that can lead to useful discipline independent semantics for systems. There have been several system experts that have expressed their perspectives in this regard. The current paper identifies and utilizes some of these contributions and then identifies a key set of concepts and principles as well as a unifying mental model collectively called the System Survival Kit. The survival kit generically identifies the relationship between situation systems, respondent systems and system assets in a manner that can be applied to any system related situation. These contributions are based upon experiences in teaching people from many disciplines to “think” and “act” in terms of systems.
7.4.3 Ontology‐driven Requirements Engineering —A case study of OntoREM in the aerospace context
Authors: Kossmann Mario , Odeh Mohammed 
Published: November 2014

AbstractOntoREM is an Ontology‐driven Requirements Engineering Methodology (process, methods and tools) that aims to improve the quality of requirements while also reducing the time and cost needed to develop, maintain and re‐use requirements. In order to evaluate the potential of such an ontology‐driven approach, OntoREM was applied to the aircraft operability (AO) domain and generic AO requirements for the wing design were developed. These requirements were subsequently compared to corresponding AO requirements that were developed for the wing design of two different development contexts for which a traditional requirements process was applied. Similarly, the elapsed process times to develop the requirements were compared, as measured for OntoREM and estimated for the traditional requirements process. The preliminary outcomes of this case study strongly suggest that the application of the OntoREM approach led to better quality requirements in considerably less time and hence at less cost per requirement. Further saving potential exists through increasing automation of OntoREM. In addition, there are several, additional advantages of applying this methodology that, for example, enable the reuse of domain ontologies including requirements in even less time i.e. at lower cost in the future, not to mention the advantages of explicitly capturing domain knowledge. An industrial scale pilot application of OntoREM has been proposed in order to mature the methodology and its underlying IT infrastructure for the anticipated global use in the context of entire aircraft development programmes in order to prepare for full integration into the Airbus Product Development Process (PDP).
8.3.1 Certainty, Risk and Gambling in the Development of Complex Systems
Authors: Pickard Andrew C , Nolan Andrew J , Beasley Richard 
Published: November 2014

AbstractOne of the few things certain about development of complex systems is the requirements for the system will remain uncertain late into the development program. Even though we recognize this, why do many programs assume that requirements will not change (gambling) or treat requirement change as a risk rather than a certainty? An analysis of gas turbine engine control systems requirements shows that typically 50% will change between Critical Design Review and Entry into Service. This requirements uncertainty manifests as technical risk to the programme. This paper evaluates the impact of not managing these uncertainties and describes how applying Systems Engineering principles can reduce this effect.Design iterations produce rework, and without technical risk management, ~50% of the effort will be wasted in producing unacceptable designs. In turn, correction of these errors will create more rework. This results in much iteration and cumulatively twice as much work is required to produce a mature design. With technical risk management, less than 10% of the design effort will result in rework, giving a mature product with far less iteration.Investigation into the source of the product development lifecycle problems indicates many escapes occur during requirements definition and review. Around twice as many changes are driven by errors in requirement definition by the developer, compared to customer‐driven requirements changes. In addition, many of these escapes are detected later in the product development lifecycle than they could have been found, resulting in further escalation of the cost of product development. This paper compares and contrasts the root causes for these escapes during system, software and hardware development and looks at the differences in consequences.The role of the Systems Engineer is critical in addressing these problems. In addition to effective elicitation of requirements from stakeholders, the Systems Engineer must manage volatility and apply robust design principles to protect against the impact of requirements changes. The Systems Engineer must flow requirements effectively from system to sub‐system, from sub‐systems to components and provide the “glue” that results in the integrated system being more than the sum of its parts.Some tools and techniques are presented to help Systems Engineers identify probable sources of uncertainty and provide effective mitigations. An approach is also presented for assessing the technical risk management “maturity” of a project, based upon ‘best practice’ approaches taken from those projects achieving low levels of engineering scrap and rework during their development phase.
10.3.2 A SYSTEMS APPROACH TO ARCHITECT COHERENT SYSTEM OF SYSTEMS CAPABILITIES
Authors: Weng Yeoh Lean , Seng Chia Ban 
Published: November 2014

AbstractArchitecting of coherent system‐of‐systems (SoS) capabilities is complex due factors such as the diverse range of stakeholders and evolving requirements. Left to themselves, these individual stakeholders at the system requirements definition and implementation stages may demand for optimization of individual systems of their interests. This would collectively result in local optimization at the system‐level at the expense of SoS‐level or even enterpriselevel effectiveness. This paper proposes an approach to coherently architect SoS capabilities. This approach is premised on the assumption that a “top‐down” leadership approach is applicable to establish the required reporting structures and relationships in the technical community. The approach attempts to weave in the considerations of limited shared resources and common technological solutions across the national defense enterprise into the process of architecting an SoS that would fulfil a large‐scale mission capability.
11.3.1 Systems Engineers' Perceptions on the Adequacy of Project Management Methods for Systems Engineering Management
Authors: Sharon Amira , Dori Dov , de Weck Olivier L. 
Published: November 2014

AbstractSystems Engineering Management (SEM) is being developed hand in hand with the maturation of systems engineering, emphasizing the management of the joint project‐product ensemble.Most SEM applications use traditional Project Management (PM) methods and tools, including Gantt chart, PERT, Critical Path Method, System Dynamics, Earned Value Method, and Design Structure Matrix. Object Process Methodology has also been recently studied as a vehicle for Project‐Product Lifecycle Management. We examine how systems engineers perceive the extent to which PM methods support SEM. We verified that project and product are viewed as two complementary facets of SEM, and that certain PM methods address both domains better than others with respect to particular examined factors.