bluuebunny/crossref_metadata_2025_split huggingface dataset:
The Origin, Development, Application, Lessons Learned, and Future Regarding the Bayesian Network Relative Risk Model for Ecological Risk Assessment
Authors: Landis Wayne G 
Published: September 2020

Abstract
In 2012, a regional risk assessment was published that applied Bayesian networks (BN) to the structure of the relative risk model. The original structure of the relative risk model (RRM) was published in the late 1990s and developed during the next decade. The RRM coupled with a Monte Carlo analysis was applied to calculating risk to a number of sites and a variety of questions. The sites included watersheds, terrestrial systems, and marine environments and included stressors such as nonindigenous species, effluents, pesticides, nutrients, and management options. However, it became apparent that there were limits to the original approach. In 2009, the relative risk model was transitioned into the structure of a BN. Bayesian networks had several clear advantages. First, BNs innately incorporated categories and, as in the case of the relative risk model, ranks to describe systems. Second, interactions between multiple stressors can be combined using several pathways and the conditional probability tables (CPT) to calculate outcomes. Entropy analysis was the method used to document model sensitivity. As with the RRM, the method has now been applied to a wide series of sites and questions, from forestry management, to invasive species, to disease, the interaction of ecological and human health endpoints, the flows of large rivers, and now the efficacy and risks of synthetic biology. The application of both methods have pointed to the incompleteness of the fields of environmental chemistry, toxicology, and risk assessment. The low frequency of exposure-response experiments and proper analysis have limited the available outputs for building appropriate CPTs. Interactions between multiple chemicals, landscape characteristics, population dynamics and community structure have been poorly characterized even for critical environments. A better strategy might have been to first look at the requirements of modern risk assessment approaches and then set research priorities. Integr Environ Assess Manag 2021;17:79–94. © 2020 SETAC
KEY POINTS
The paper reviews the development of the relative risk model (RRM) and the follow on Bayesian network relative risk model (BN-RRM) from the late 1990s to 2020. The RRM and BN-RRM have been demonstrated to describe risk due to chemicals, disease, land use change, and nonindigenous species to a variety of biotic and abiotic endpoints including human wellbeing at sites across the world. Adaptive management in collaboration with diverse stakeholders and incorporating ecological risk assessment is applicable to long-term restoration and conservation. Contrary to many claims, much research in the field of environmental toxicology is not done in a manner appropriate to the quantitative risk assessment. Risk assessment depends on understanding exposure-response relationships as curves and distributions, not point estimates, and p values.
Mind your meat: Religious differences in the social perception of animals
Authors: Manokara Kunalan , Lee Albert , Kamble Shanmukh V. , Krumhuber Eva G. 
Published: September 2020

While previous work demonstrated that animals are categorised based on their edibility, little research has systematically evaluated the role of religion in the perception of animal edibility, particularly when specific animals are deemed sacred in a religion. In two studies, we explored a key psychological mechanism through which sacred animals are deemed inedible by members of a faith: mind attribution. In Study 1, non‐vegetarian Hindus in Singapore (N = 70) evaluated 19 animals that differed in terms of their sacredness and edibility. Results showed that participants categorised animals into three groups: holy animals (high sacredness but low edibility), food animals (low sacredness but high edibility) and neutral animals (low sacredness and low edibility). Holy animals were deemed to possess greater mental life compared to other animal categories. In Study 2, we replicated this key finding with Hindus in India (N = 100), and further demonstrated that the observed pattern of results was specific to Hindus but not Muslims (N = 90). In both studies, mind attribution mediated the negative association between sacredness and edibility. Our findings illustrate how religious groups diverge in animal perception, thereby highlighting the role of mind attribution as a crucial link between sacredness and edibility.
Enabling systems engineering in a new product development process via a tailored A3 architecture overview approach
Authors: Hooft Daniel 't , de Kroon Jan , van Omme David , Bonnema G. Maarten 
Published: September 2020

AbstractThis paper describes the development of a systems engineering (SE) approach to enable the application of SE and systems thinking in a new product development (NPD) process in an organization that is unfamiliar with the application of SE. The application of SE is enabled by using a tailored A3 architecture overview (A3AO) template. By using this template, a mechanism is presented to start the application of systems engineering in an organization that has limited experience with SE. By using A3AOs directly a way to capture and communicate the system architecture among stakeholders is provided. This approach is implemented and evaluated in a small‐scale case‐study.
Using your BRAIN to get beyond “It Depends…”
Authors: Gibson Ian 
Published: September 2020

AbstractThis paper describes an approach for framing a problem where the potential operational scope is large and diverse, and for quickly evaluating potential points in the solution‐space in a manner which is easy for non‐technical stakeholders to digest and interact with. The two aspects of scenario framing and concept assessment work well together but can easily be decoupled depending on the needs of the task at hand. It has been used so far on series of tasks exploring concept and pre‐concept phase options in the UK Defence environment, but has wider applicability to any situation that shares similar characteristics.The scenario framing approach addresses the familiar problem of getting past stakeholder responses of “it depends” when they are asked to validate processes or behavioural models. The concept assessment approach, based upon the acronym BRAIN, is intended to be quick and easy to apply, supporting rapid iteration. Two case studies are used to illustrate the combined approach.
Implementing Systems Engineering in Early Stage Research and Development (ESR&D) Engineering Projects
Authors: Hahn Heidi Ann , Lombardo Nick , Hodges Ann , Kerman Mitchell , Autran Frédéric 
Published: September 2020

AbstractEarly Stage Research and Development (ESR&D) is one of the most crucial phases in the design process. It is of interest to Federally Funded Research and Development Centers (FFRDCs), university affiliated Research and Development (R&D) centers, government entities, and public and private commercial enterprises. This paper explores the topics of whether and when to apply systems engineering (SE) in ESR&D projects, how much SE to apply and how to make that determination, and barriers to implementation with advice on how to overcome them. The authors conclude that applying SE in the early stages of R&D projects is a necessary element of the overall risk management strategy, but that the SE effort must be appropriately tailored to balance investment with value while supporting scalability for future growth.
Do Product Lines have Sweet Spots?
Authors: Harper Keith G , Pickard Andrew C 
Published: September 2020

AbstractCreating a Product Line should not be undertaken lightly. There are many complexities to consider relative to development of individual products or cloning of existing designs. However, in today's business environment, development of multiple, similar products as individual or clone projects is unsustainable, both from the viewpoint of cost and of availability of suitably skilled engineers.This paper considers approaches to development of Product Lines in the context of gas turbine engine full authority digital electronic control systems. The Product Line in this paper was created for an existing engine, with new Applications and a new control system for multiple helicopters.The paper explores the challenges with developing the Product Line and the benefits relative to development of individual products. The benefits are illustrated by an investigation of software cost and schedule metrics for Product Line builds, Application Builds and non‐Product Line builds.
What's the Problem? Issue Investigation and Engineering Change on Legacy Products
Authors: Dunford Charlotte N , Pickard Andrew C 
Published: September 2020

AbstractSystems Engineering best practice has changed greatly over the past 10 to 20 years. Aero‐engines are normally in service for over 30 years (an example is included in this paper of a recent modification to a WWII engine) and so many still in service were not designed using current systems engineering best practice. When changes need to be introduced into these products the pre‐work required to get the product information dataset to the point that current best practice can be employed is often not worth the benefit (Bahill & Briggs 2001). The challenge is to decide what level of systems engineering rigor is of value to apply when making changes to these legacy products. This paper describes the authors’ work tackling this issue focusing on understanding the change needed. It proposes a generic approach for tailoring systems engineering to understand the change needed on a legacy product.
Achieving System‐of‐Systems Interoperability Levels Using Linked Data and Ontologies
Authors: Axelsson Jakob 
Published: September 2020

AbstractInteroperability is a key concern in systems‐of‐systems (SoS). Numerous frameworks have been proposed to deal with this, but they are generally on a high level and do not provide specific guidance for technical implementation. However, in the context of simulation, the Levels of Conceptual Interoperability Model (LCIM) has been proposed. Also, the semantic web initiative has been introduced to provide description logic information to web pages. This paper investigates how these two concepts can be combined into a general approach for SoS interoperability. It also expands on the LCIM model by providing more details about the world models of a system and its content on the higher levels of interoperability. The combination is illustrated using an example of autonomous vehicles, and experiences from other applications are also discussed.
Case Study: Achieving System Integration through Interoperability in a large System of Systems (SoS)
Authors: Hoehne Oliver 
Published: September 2020

AbstractThis paper provides a case study on system of systems engineering (SoSE) being performed in a multi‐billion‐dollar program – the California High‐Speed Rail System – viewed from the systems integration perspective. The paper discusses why the subject program of projects (PoP) can be viewed as a system of systems (SoS), identifies the SoSE challenges faced, describes the SoSE activities performed, and summarizes the achieved outcomes and conclusions as of today.Specific SoSE challenges discussed include SoS authority, leadership, architecting, collaboration, integration, and emergence. The paper reviews how decision‐making in independently operated and managed constituent systems (projects) resulted in unanticipated SoS emergent behavior, which is one of the key challenges in the engineering of SoS.The paper further discusses the performed SoSE activities, including an international best practice review, the tailoring of SoSE to the specific SoSE challenges, and provides examples where SoSE principles are being applied to perform successful SoS integration.
An Approach to Architect using Spaces and Flows
Authors: Kumar Anand , Natarajan Swaminathan , Lokku Doji Samson 
Published: September 2020

AbstractToday, architecture as a discipline is gaining prominence for addressing the increasing complexity associated with enterprises, systems, software, software intensive systems and other entities. This is evident by the increasing architecture related activities that are performed as part of many of these endeavors. Many architecture frameworks, that have been found useful by communities of practice, are increasingly found applicable in different situations requiring architectural interventions. However, it is often the case that there is no foundational basis for many of these practices other than the fact that they are found to be useful. In this paper, spaces and flows are introduced as the foundational concepts for architecting any entity. An approach that utilizes these concepts is proposed. The underlying rationale for the approach and the foundational concepts is also discussed. Further, the usefulness of these concepts and approach is illustrated by means of an exemplar.
Electing User Needs Related to Human Values through Illustrative ConOps ‐ a new‐energy case study
Authors: Aarsheim Runar Tunheim , Falk Kristin , Kjenner Svein 
Published: September 2020

AbstractThis paper investigates how to better understand end users’ human values at an early phase of system design in an innovative new‐energy project. By early involvement of end‐user, companies can avoid making costly design mistakes that reduce the usability of the system. For the innovative system there were no end‐users from where to directly obtain the operational knowledge. The paper has adopted research methods from the Design Thinking process, and uses industry‐as‐laboratory, conducting in‐depth interviews with end‐users from related applications. The research focuses on needs that originate from “human values” defined as an expressed emotional feeling addressing how the users perceive the system. The interviews resulted in 105 user needs translated into 17 relevant stakeholder requirements. The results showed that conducting interviews showing an illustrative ConOps gave 17% more chance of finding needs originating from human values compared to not using this attribute. This research proposes a process for integrating the human values into the early phase of systems engineering.
Systems and Software Interface Survey
Authors: Muscarella Sally , Osaisai Macaulay , Sheard Sarah 
Published: September 2020

AbstractINCOSE formed the Systems and Software Interface Working Group (SaSIWG) in 2017, in response to Corporate Advisory Board interest in software, and problems identified in the systems and software interface (physical, logical, data and human). This third SaSIWG paper presents the results of a survey of systems engineers, software engineers, and project managers as to what are best practices and what are the priority challenges related to the interface between systems and software. The best practices mentioned by the 31 interviewees are grouped and summarized, followed by information on priority challenges and problems. Systems engineering must be done well, and that includes an ever‐increasing amount of Model‐Based Systems Engineering. It also includes developing and holding to a vision, addressing data, ensuring interdisciplinary work, planning systematic verification, and ensuring modularity. Systems Engineering must evolve to meet new challenges and most important, the expertise of systems engineers must include software engineering.
Systems Engineering Evidence in Commercial Kitchens
Authors: Armstrong James R. 
Published: September 2020

AbstractINCOSE has expressed interest in the application of systems engineering principles and practices in industries outside of the classic aerospace, communications, and other large system developments commonly related to the discipline. In this case, a visit to the kitchen at the Inn at Little Washington triggered thinking about how and why it was so different from other commercial kitchens. The resulting analysis of how systems engineering has significant relationship to the design of a wide variety of commercial kitchens is provided in this paper. The objective is to learn how we can see systems engineering in places it isn't normally found to both find other ways it can be applied and to help others improve their results by using systems engineering discipline.SummaryThis discussion was initiated by observing something quite unexpected and realizing that it had a lot of the earmarks of systems engineering thinking. This turns out to be the case for the specific instance of the Inn at Little Washington kitchen. However, in expanding the question to include commercial kitchens of various types, we find that the core concerns of systems engineering are the principal factors in the variety of applications and designs that exist. When hearing the term commercial kitchen, the stainless steel approach in Figure 5 probably comes to mind along with some nominal set of hardware. However, as we go through the list of types, we find that each design starts with the specific operational concept of what is being prepared, for whom, how much, where, in what environment, and what the business purpose is. These all drive the requirements along with various local restrictions and regulations. The functionality has to be understood and there may be alternatives that will drive the design. There are architectural and design options for trade analysis. Modeling may be more based on drawings and mental models but still exists and actual prototypes and exercises have been used. There is a lot of integration involved with both the internal and external elements and human interfaces are important. The final product must work as advertised and, in the truest sense of validation, must support a successful business. There are several areas where specialty engineering is involved such as safety, reliability, and maintainability. In summary, we see a significant relationship to the classic world of systems engineering even if it doesn't use the same vocabulary.So what should we gain from this discussion? Its aim is to help systems engineers to recognize the discipline in other places where it is not normally talked about and be able to learn from those applications. Also, it can help in recognizing that we can better tailor our explanation of our best practices for others who could benefit from more discipline in their work. It is up to the systems engineering community to use this discussion to aid such a two‐way flow of ideas for the benefit of all.
Delivering Change
Authors: Stolzar Lauren , Mooney Carolyn , de Lucena Paul , Ferraioli Patrick , Koufopoulos Michelle , Misek Nicole , Simone Ashley , Whitt Signy 
Published: September 2020

AbstractHow does systems thinking expand into new domains? As we move into INCOSE Vision 2025, this question becomes increasingly important to answer. Grubhub, a tech and logistics company in the United States focused on matching diners to restaurants, embarked on a journey to implement systems engineering, systems analysis, and systems thinking. This paper explores that journey, focusing on areas of success and failure that helped lay the groundwork for this capability to be developed within the company.
Systems of systems ontology in practice
Authors: Nilsson Robert , Viswanathan Shivaram , Mason Amanda , Jurland Per , Durgempudi Papi , Fischer Jake 
Published: September 2020

AbstractThis paper explores possibilities for collaboration between two companies that share interest in a System of Systems (SoS). Although traditional architectural frameworks and standards are applicable, there has been little work presented of how they can be used for collaboration by a practician. As a response to harmonize use of words for an SoS in relationship to standardized set of definitions an INCOSE Work Group project developed a proposal for an ontology that could support collaboration in the context of directed SoS and acknowledged SoS. This ontology is evaluated in the paper, first by a mapping of terms used in product development to test the ontology terms. Then the ontology is further explored with an example of how it could be used in architecture work in relation to directed SoS, specifically from a system safety aspect.
Techno‐Social Contracts for Security Orchestration in the Future of Systems Engineering
Authors: Dove Rick , Willett Keith D. 
Published: September 2020

AbstractSecurity orchestration is the command and control behind security operations. Command includes governance and adjudication logic and rules. Control includes the messaging infrastructure and message set for bidirectional communication between the orchestration engine and the constituent parts of its enclave. Open Command and Control (OpenC2)1 is one effort advancing the messaging infrastructure and message set. Automating the command portion of orchestration remains largely unexplored and will emerge as a symbiosis between people and technology. Technology will have some autonomy including the ability to establish and sustain relationships (argued in a social sense) with other technology. To help facilitate trust relationships and interactions that secure the respective systems and their environment, techno‐social contracts are explored as an approach to explicitly encode technology‐to‐technology rules of intra‐protection and inter‐protection as part of security orchestration.
Implementing MBSE – An Enterprise Approach to an Enterprise Problem
Authors: Papke Barry L. , Wang Gan , Kratzke Ron , Schreiber Chris 
Published: September 2020

AbstractModel Based Systems Engineering (MBSE) is now widely accepted throughout the industry, from commercial to aerospace and defense. However, while we understand and accept the principles of MBSE, successful adoption and implementation is still a challenge within the industry. The migration from document‐based systems engineering processes to MBSE requires more than purchasing tools and a one‐week course on Systems Modeling Language (SysML). MBSE does not change the practice of Systems Engineering as defined in the INCOSE SE Handbook or ISO/IEEE 15288, but it does affect the way in which systems engineering processes are implemented and supported within and across organizations. Organizations adopting MBSE must address issues such as new skill and competency requirements for systems engineers, model and data management over the lifecycle of the system, and integration with other engineering tools and processes, among others. It is not a tool problem or a modeler problem. It is an enterprise problem and requires an enterprise approach. The approach must be defined and guided by an enterprise architecture, which is broader than just the engineering tools and their interfaces. It includes the enterprise strategic vision, capabilities, operational concepts, organizations, and material solutions required to achieve MBSE adoption, how they relate to one another, and their evolution over time. This paper provides a broad overview of the fundamentals of MBSE adoption and the broader effort of digital engineering transformation, presenting the digital engineering environment as a system‐of‐systems. It presents the use of enterprise architecture as a roadmap for MBSE adoption within the industry.