bluuebunny/crossref_metadata_2025_split huggingface dataset:
Enhancing the Academic Portfolio – Systems Engineering Research & Teaching for Universities
Authors: Kossmann Mario 
Published: August 2018

AbstractMany universities across the globe have well established Systems Engineering (SE) courses and academic degrees, covering continuous professional studies for both the industry and the public sectors, undergraduate and postgraduate programs including research degrees at master and doctorate levels. Some universities even have world‐class reputation for the excellence they demonstrate in SE research & teaching. However, there are still many universities worldwide that offer courses in traditional fields of Engineering but not yet in SE, let alone specific SE degrees or qualifications. Given that SE is essential for the development and in‐life support of systems, even more so with the increasing levels of complexity of today's and tomorrow's systems and Systems of Systems (SoS), it seems urgent and important for such universities to consider an extension of their academic portfolio.This paper briefly discusses the justifications for explicitly including SE in the curriculum of Engineering focused universities, and provides insight into one possible way of enhancing the successful establishment of SE as part of the academic portfolio – via developing and maintaining an SE domain ontology. The generic ontology ‘SERaT4Ac’ (SE Research and Teaching for Academia) that is specified in the ‘ontology web language’ (OWL) is presented and specific aspects of the ontology are explained using typical examples. This proposed domain ontology represents an integrated model of what a university should consider and manage over time regarding their SE related activities. It could (and would have to) be instantiated for the context of a given university to directly help them extend their academic portfolio; but it may also be useful for universities with a well‐established SE curriculum.
“Changing the Acquisition Game” Alleviating Unreasonable PM‐SE Constraint Risks
Authors: Wasson Charles , Hahn Heidi , Neill Colin J. , Weigel Allison , Lindeman Tony 
Published: August 2018

AbstractPoor project performance is often attributed erroneously to PMs and SEs that must perform in an environment characterized by:
Inadequate proposal preparation and analytical due diligence in understanding the user's problem space and operational needs.
Unrealistic proposal assumptions and contract constraints – such as overly aggressive schedules and inadequate funding.
A Source Selection Evaluation Process that is overshadowed by a highly competitive “Acquisition Game” of perceptions, influence, persuasion, and potential conflicts of interest.
Project Management and Engineering “stovepipes” that limit understanding of each other's roles, accountabilities, and their respective contributions.
Contract “requirements creep” by the Acquirer with an expectation or Developer accommodation without appropriate contract cost modification.
Deficiencies in Engineering and Systems Engineering due to outdated educational and competency paradigms.
As a result of unreasonable and unrealistic constraints by the “game” conditions, no one really wins ‐ the User, the Acquirer, the Developer, or supporting subcontractors and vendors. Indeed, upon contract award, the project conundrum becomes: “Good news! We won the contract … Bad news. We won the contract!” Project Managers and Systems Engineers are then burdened with the impossible task of achieving contract financial, technical, and schedule “stretch” objectives in which they may have had little opportunity for input.This paper explores each of these conditions, through illustrative examples from a range of business domains and industries perspectives, along with potential opportunities for improvement so that, fundamentally, the game itself is changed – changed to one that can be won.
The Importance of Project Management in the System Integration, Verification and Validation Process
Authors: Røsegg Christoffer Jimmy , Falk Kristin 
Published: August 2018

AbstractSuppliers to the oil and gas industry are experiencing an increased pressure from customers to deliver products at a lower cost and shorter schedule. One of the most costly single activity in packaging a Complex System is the process of system integration testing, verification and validation (test phase). In the researched Company this process has also proven to be a bottleneck. Symptoms are accumulated units ready for test, projects that are not put through, and delayed completion of projects.This paper analyzes the testing process. The initial objective was to identify what impacts the testing schedule. We analyzed the testing process using root cause analysis methods. Our research identified that several issues occurred, both prior to and in the test phase. However, only a few of the issues have a significant impact on the test schedule. This project shows how crucial project management is for complex systems. It also gives an insight to how the company can successfully manage the system integration, verification and validation phase.
Experience from Introducing Systems Engineering in an Academic Environment Using an Industry Training Course
Authors: Herzog Erik , Larsson Åsa Nordling , El‐Khoury Jad , Törngren Martin 
Published: August 2018

AbstractTraining and educating Systems Engineers is a key activity for any organization developing complex heterogeneous systems. Ideally, the regional/national academic community will provide courses and education programs facilitating for the needs of industry and society. However, Systems Engineering is not a traditional academic subject and despite the growing academic interest in the subject there are many regions with no dedicated academic courses and programs in the subject.This paper presents experience from introducing Systems Engineering via a capstone project course in a mechatronics master's program at the Royal Institute of Technology (KTH) in Sweden. System engineers from industry give an industry‐developed Systems Engineering course, as part of a capstone course. We believe that the approach is novel and can serve as a mechanism for introducing Systems Engineering to both students and lecturers in the academic world, who have no previous exposure to the subject. Moreover, student feedback indicate that having lecturers with industrial experience was highly appreciated, making the activity a worthwhile branding investment for industry as well.
An Empirical Case Study of Problem Structuring in the Use of Generic Architectures
Authors: McLean James , Gilbert Dawn 
Published: August 2018

AbstractAn empirical case study is presented which details a problem structuring activity facilitated by the United Kingdom (UK) Ministry of Defence (MOD) Internal Technical Support ‐ Systems Engineering Team with the UK MOD Generic Vehicle Architecture (GVA) team. The body of literature reviewed identified an absence of specific guidance, or description of practical experience, in applying generic architectures to manage system change. The problem structuring activity allowed the GVA team to better understand the nature of the problem they faced, and to identify a means to effectively progress the issue. This case study is offered for consideration as the description of the problem situation may resonate with the reader, and to provoke thought on the methods used in selecting systems engineering methods to use in practice.
Technology Readiness Assessment for the Nuclear Weapons Program
Authors: Bell R. Glenn , Venkatesh Srini , Bruns Caroline W. 
Published: August 2018

AbstractTechnology development is typically the process of developing and demonstrating new or unproven technology, the application of existing technology to new or different uses, or the combination of existing and proven technology to achieve a specific goal. Technology development associated with a specific acquisition project for nuclear weapon typically should be identified early in the project life cycle and its maturity level should evolve to a confidence level that allows the project to establish a credible technical scope, schedule, and cost baseline. Projects that perform concurrent technology development and design implementation may run the risk of proceeding with an ill‐defined project baseline.In the climate of declining federal budgets and increased budget scrutiny, it is prudent to determine—as early as possible within a program schedule—the viability of technologies, and the ability of those technologies to support a specific project as well as the overall U.S. nuclear deterrent mission.This paper describes the approach and tools used within the nuclear weapons programs for assessing the maturity of technologies and their readiness for insertion into the project design and execution schedule.
Synchronizing Systems Engineering and Implementation in Lean‐Agile Programs
Authors: Maione Robert , Wilson Mark A. 
Published: August 2018

AbstractIn traditional system development programs, high‐level statements of capability and mission needs are elaborated and functionally decomposed, and then systematically allocated to discrete program segments or subsystems. Functional decomposition continues to be a classic systems engineering technique to define and manage the development of large systems, but this approach can create issues in systems that are being developed using Lean‐Agile methods. Lean‐Agile developers typically adopt a “time box” perspective, where the goal is incremental delivery of system capability on a predictable schedule. In other words, Lean‐Agile developers may adopt a development rhythm with increments of rapidly evolving capability delivered every 10–12 weeks, while the SE team stays focused on the progress of the overall system as it was originally planned and defined. This divergence of both pace and perspective can lead to misunderstandings between systems engineers and developers or worse, disconnects between what the systems engineers think the developers are building and what developers are actually building.Communication suffers when Lean‐Agile developers and program systems engineers operate in separate organizational “silos” instead of working together as a cohesive team. Day‐to‐day implementation decisions with potential impact to overall system capability can become buried within lower level engineering and development documents that are hard to synthesize to support timely program decisions. In our work with large programs employing Lean‐Agile development strategies, we discovered an approach that maintains systematic collaboration between developers and the SE team. In our approach, we explicitly measure and communicate incremental delivery of value using a new level of abstraction that we call Mission Value Threads (MVTs). MVTs directly link system requirements and their associated SE artifacts to Lean‐Agile development team backlogs and design documentation. This paper describes how to use MVTs to manage value delivery while fostering better collaboration between developers and systems engineers.
The Cynefin Framework and Technical Competencies: a New Guideline to Act in the Complexity
Authors: Fierro Davide , Putino Stefano , Tirone Lucio 
Published: August 2018

AbstractThe current socio‐economical context is affected by extremely challenging factors such as the macro‐economic crisis, the globalization of markets, the exponential growth in the complexity of systems, the continuous evolution of technologies and the criticality of requirements subject to rapid and sometimes uncontrollable evolution.In such a competitive landscape the role of the future leaders gets essential. They shall be able, by means of a holistic, methodologically structured and flexible approach, to drive their programs through the implementation of the complex changes which are strategic to preserve the competitiveness. Such new leaders must be endowed with both strong technical skills, continuously trained in the key reference standards, and soft skills, useful for the strategic understanding of the evolutionary processes expressed by the markets and for the improvement of the complex relationships efficiency with the relevant stakeholders.The development and implementation of optimized technical‐managerial solutions is therefore essential, vital for the “feasibility” and competitiveness of front‐running projects, and cannot succeed without a contextual analysis of the reference scenarios.In this context the Cynefin Framework, an interpretative model of the different levels of the systems complexity, ranging from order to disorder, can provide a very effective support.The goal of this paper is to develop a multi‐faceted and comprehensive vision of the problems in the various domains of complexity, “contextualizing” the most effective management approaches and “soft and hard” skills of the leader.The paper benefits of the input received during various sessions of the second Cohort of the INCOSE Technical Leadership Institute, where precious insight and feedback has been collected, especially from the TLI coaches, Patrick Godfrey, Michael Pennotti and Don Gelosh.
Creating Decision Guidance for Applying Agile System Engineering
Authors: Lyells Ron , Angier Rock , Epps Bob 
Published: August 2018

AbstractSystems teams, development projects, and organizations, who are involved in product development, are often faced with the question as to whether they should adapt agile systems practices into their programs and processes. In trying to answer this question these groups are almost immediately confronted with the problem of determining what is motivating the decision, where should agile principles be applied, and how much agility is necessary. There are several interrelated systems involved in this inquiry and the development of a proper understanding around these considerations is not a trivial exercise. A method of inquiry and decision making that is in itself agile and that can produce actionable results needs to guide the development of this understanding. The purpose of this paper is to present work accomplished to date on the definition, prototyping, and evaluation of a decision guidance system to help a development team or organization achieve a necessary understanding that can lead to useful actionable decisions regarding agile adoption.
A Framework for Testability Analysis from System Architecture Perspective
Authors: Efatmaneshnik Mahmoud , Ryan Michael J , Shoval Shraga 
Published: August 2018

AbstractIn this paper, we study the effects of system architecture on testability. We present a probabilistic model of testability that enables us to study the relationships between system architecture and testability. A Markov Chain model is used to obtain the quality of system after test as a function of its quality before test and the test quality. In particular, we focus on the costs and benefits associated with the modularization for testability. We show that choosing the appropriate testing architecture through careful modularization can greatly enhance efficiency and effectiveness of system testing. The model is based on repetitive testing that means the test will be repeated after a fail test outcome.
Using the Cognition Cockpit Platform for the Systems Engineering of a Local Health Care System in Cameroon
Authors: Kossmann Mario 
Published: August 2018

AbstractAll projects that are concerned with developing complex systems are potentially very challenging; yet charitable, i.e. not for profit, international development projects often have additional obstacles to overcome due to the geographical distance between the various stakeholders of the project; cultural, national and legal boundaries including multiple languages; uncertainty regarding the available budget and resources throughout the project life cycle, including the availability of needed volunteers; as well as a lack of the necessary infrastructure in terms of electricity, roads or telecommunications, if the focus of the project lies in developing countries. This is true not only for the Project Management activities of such projects but also for the related Systems Engineering activities.Using the example of a charity project that is concerned with the development of a local health care system in a deprived region of Cameroon, this article illustrates and reports on the use of the ‘Cockpit’ platform of the US based Cognition Corporation to enable key Systems Engineering activities of the project. The aim of this paper is to share the experience made with the applied Systems Engineering approach and the supporting platform; and thereby offer relevant insights to practitioners who are involved in similar development projects.
SE Management is Not SE Core Competency: Time to Shift this Outdated, 60‐Year‐Old Paradigm
Authors: Wasson Charles 
Published: August 2018

AbstractIn the early 1950's the development of large, complex systems encountered two major challenges: (1) traditional Engineering methods were inadequate for coordinating and communicating designs and changes across multiple disciplines; and (2) projects were incurring unmanageable technical failures, cost overruns, and schedule slips. Exacerbating these challenges were growing conflicts between management and the engineers and scientists performing the engineering. These two challenges manifested themselves in the form of a “management gap,” which emerged due to management frustrations with engineers and scientists’ inability to articulate how the engineering process was performed, and (2) a “technology gap,” which emerged due to engineers and scientists’ frustrations with management's inability to understand how engineering was performed and the new technologies being implemented.Central to these issues was the threat to the prevalent 1950's management paradigm of exercising authoritative control over subordinates by planning, organizing, staffing, directing, and controlling the tasks engineers and scientists performed. Corrective action solutions were urgently needed. Rather than solving the challenges, government as the acquirer of large, complex systems, decided to regain authoritative control over its contractors. As a result, the concept of Systems Management was introduced and mandated via a series of Systems, SE, and Engineering Management process standards.Over the past 60+ years, the emerging field of Systems Engineering (SE), which originally focused on answering a key engineering question “Will the system work – i.e., ‘be fit for purpose’ when realized? (Ring, 2017) shifted to “did we follow our processes?” Projects corrected a “management” problem while neglecting the “engineering” question. As a result, projects continue to exhibit systemic performance issues. It is time to shift this outdated Systems Management paradigm and reestablish SE core competency as the “engine” for correcting SE contributions to project performance issues that seem so intractable.
Systems Interface Management with MBSE: from Theory to Modeling to Reality
Authors: Hause Matthew 
Published: August 2018

AbstractSystems interoperate using interfaces. They exist between capabilities, organizations, people, systems, people and systems, systems and nature, systems of systems, and so forth. Interfaces are used to support both system to system communication as well as supporting the complete set of enterprise goals. Interfaces are where the most interesting things happen. And where most things go wrong. This paper addresses system interface‐management issues and the benefits of Model‐Based Systems Engineering (MBSE) approaches. An initial focus will be placed on interface information content that needs to be addressed at each level of system decomposition – from external stakeholders to system boundary to eventually, system component‐to‐component. The focus will then shift to interface management to model‐based and functional/logical design practice. It will also cover system interconnection and communications, how they change, operate and evolve over time to implement mission goals and to satisfy stakeholder needs. Finally it will look at physical systems and the connection to PLM/CAD domains.
Defining stakeholder goals and required capabilities
Interface definition with MBSE
Functional Architecture Interfaces
Logical Architecture Interfaces
Physical Architecture Interfaces
Allocation across cross cutting views
How behavior drives interfaces which drive behavior
Defining interaction requirements
Implementing effective and testable interface specifications
Traceability throughout the architecture
Service Oriented Architectures.
Modeling Cyber Threats with SysML
Authors: Curreri Matthew R. , Kam Ambrose , Hein Carl 
Published: August 2018

AbstractAdvanced Persistent Cyber Threats (APCT) jeopardize all seven layers in the Open System Interconnect (OSI). Scalable Modeled Based Engineering (MBE) methodologies can address APCT by leveraging industry standard SysML techniques by automating threat assessment for a multitude of operational scenarios. This paper provides a use case demonstrating how SysML can be combined with simulation to improve cyber defenses.
Design and prototype development of Dynamic Supply Chain Supporting (DSCS) system in Connected Smart Factory environment: focusing on architecture and data model
Authors: Park Jonghee , Jeon Byeongwoo , Hong Dae‐Geun , Suh Suk‐Hwan 
Published: August 2018

AbstractSCM (Supply Chain Management) is responsible for the construction and operation of supply chain based on supply chain information. SCM implemented in modern enterprise information system needs to increase speed, accuracy, efficiency in accordance with customized production paradigm. We design SCM support system technology that can dynamically and efficiently operate existing static and fixed supply chain under Connected Smart Factory environment that supports real‐time information exchange between supply chain members according to Industry 4.0 concept. We also validate the technology using our demonstration test bed and prototype.
A Game‐Theoretical Framework for Coordination in Requirement‐Based Engineering Design
Authors: Yazdani Soodabeh , Huang Edward 
Published: August 2018

AbstractRequirement‐based engineering design is a common practice that provides a definition of what is the desirable design solution. However, requirements define what constitutes the acceptable design from what is not, and provide a little guidance on the best design solution. Requirement‐based engineering with team coordination, on the other hand, allows design teams to exchange resources to best manage their resources. This may lead to the better design outcome. This paper investigates the benefits of coordination in requirement‐based engineering design. We apply game theory to formulate mathematical models of design problem with and without team coordination and demonstrate the mathematical framework on an illustrative example. The results indicate that we may not always get the system‐wide best performance in the requirement‐based engineering design while coordination among design teams can reduce the total cost of the system. Also, the numerical results capture the relation between team's effort level and system's cost coefficient.
A Systems Approach towards Developing a Diagnostic System for Complex Robots
Authors: Krishnan Rahul , Bhada Shamsnaz Virani 
Published: August 2018

AbstractPresent day robots are highly complex systems. Most robots perform tasks that are time‐critical in environments where human intervention may not be possible. When a failure occurs in such situations, diagnosing it can be a major challenge. To tackle this, a methodology to develop a diagnostic system using a systems approach is presented in this paper. The use of SysML diagrams as a tool to understand system behavior is highlighted. Finally, this methodology is used to build the diagnostic system of a complex humanoid robot.