Systems Engineering Life Cycle Research Articles

Enabling FuSE Security Objectives by Leveraging Cyber Survivability Methods

AbstractThe importance of system security continues to grow as systems become more complex, more connected, and more vulnerable. The INCOSE Vision 2035 sets goals for systems engineering (SE) as a discipline in enabling engineering solutions for a better world: “By 2035, cybersecurity will be as foundational a perspective in systems design as system performance and safety are today” (INCOSE, 2024). A key objective of the INCOSE Future of Systems Engineering (FuSE) Security Foundations Roadmap is to recognize system security as a fundamental part of the mission, integrated into the system architecture, and not “bolted‐on” as a separate subsystem or set of features in the detailed design. To achieve this, systems engineering must address system security early in the system lifecycle, during the mission analysis and concept development phase and ensure it is addressed as a functional requirement throughout the systems engineering lifecycle. System security needs must be treated as fundamental system capability.The INCOSE FuSE Security foundations roadmap identifies six (6) objectives and eleven (11) foundational concepts necessary to achieve the FuSE vision for system security (Dove, et al., 2021). Five of the objectives and five of the foundational concepts are directly related to systems acquisition and engineering lifecycle processes. The five key foundational concepts are: Stakeholder Alignment, Security as a Capability, Security as a Functional Requirement, Loss Driven Engineering and Modeled Trustworthiness.The Operational Test and Evaluation (OT&E) community has extensive cyber assessment and execution processes mandated through numerous Department of Defense (DoD) and individual service policies, directives and guidebooks. This paper studies several of the cybersecurity assessment and process guidebooks, analyzing the processes and methods to identify areas where systems engineering should be responsible, and which SE activities and outputs are needed to enable the requirements of each guidebook.This paper examines six OT&E cyber security guidebooks, and the methods and processes they describe to achieve system security in relation to the five foundation concepts. In addition to their test and evaluation processes, each describes systems engineering processes, activities and outputs that could be used to form the initial foundation of a system security technical process.While the original INCOSE vision statement uses the term “cybersecurity,” the FuSE Security initiative is adopting the term “system security” to emphasize that this is a system engineering responsibility as opposed to software engineering or information technology task. As a result, the analysis of the cybersecurity guidebooks will be in the context of “system security.”

Agile Processes Applied to Los Alamos National Laboratory SE approach: The Agile Processes and Technology (APT) Team

AbstractA myriad of industries is investigating and applying new technologies, approaches, and software to improve the systems engineering life cycle status quo, by reducing the time duration and lowering the cost incurred in the systems engineering process. One effort undertaken, and described herein, is pairing an Agile‐Lean framework with models‐based systems engineering (MBSE) to achieve time saving and cost efficiencies quickly within systems engineering concepts to production systems phases. This is being done by the Agile Processes and technologies (APT) team who are tasked to deliver a weapon prototype in three years. For this purpose, APT has adopted practices currently used in industry to speed up the conventional processes and practices within Los Alamos National Laboratory and partners, particularly by implementing Agile‐Lean within MBSE. APT has demonstrated agility by implementing changes at the organizational scale; given that most of the work done at the facilities is heavily based on design and hardware performance. In addition, MBSE is used to support verification and validation activities to drive acquisition of necessary evidence to establish traceability and compliance needed for qualification and certification, as per stakeholders' requirements. This paper describes the current efforts towards implementing MBSE in an Agile‐lean framework to represent a complex system —weapon prototype—, in a rapidly moving and changing environment to enable informed decisions through the identification and capture of useful decision criteria.

A survey on what users think about SysML

AbstractSystems Modeling Language (SysML) has been applied in the past years to a variety of software and systems engineering projects, by hundreds of researchers, engineers, and other systems and software professionals. Thus, it is expected that all this experience has been described in research articles. Therefore, we propose a survey describing what practitioners and researchers think about this modeling language, the actual use of SysML, and how SysML is used in the software and system engineering life cycle. This article describes a survey on SysML, answering questions such as the most used diagrams for each phase of the development of a system, the most common domains, and other data about the participants. The survey was answered by 343 participants from 38 countries, mostly systems engineers, software and systems architects, and researchers. Industry and academia can use our results (i) for assisting researchers and engineers to select appropriate diagrams for each software and systems development phase, (ii) for a better understanding of which industry domains SysML is most commonly applied, (iii) as a reference for identifying which types of systems are modeled with SysML, (iv) for knowing which software tools are most used, and (v) which other modeling languages are most commonly integrated with SysML for software and systems development.

Leveraging the Systems Engineering Life Cycle Process for Reverse Engineering

AbstractSystems kept in service for extended periods may experience issues caused by changes to the original requirements. This can manifest as parts obsolescence issues caused by changes in mission scope, industry regulations, or technology used to support the system. This paper discusses best practices for using a systems engineering life cycle methodology to support reverse engineering processes in structural‐mechanical aerospace/defense products. The concepts herein compare systems engineering methodologies to determine the best approach to identify changes in system requirements in the modern environment. The availability of operational data to inform the process is explored through three case studies of legacy components with requirements changes. Systems engineers that reverse engineer by beginning with existing requirements will fail to resolve complications that contributed to the original issue. Reverse engineering of aging subsystems and components to resolve a parts obsolescence issue warrants a full systems engineering approach beginning with requirements review.

Towards Sustainable Systems Reconfiguration by an IoT-driven System of Systems Engineering Lifecycle Approach

By the ever-progressing smartization of products, their embedded environment systems are getting more and more crossed, and so-called System of Systems (SoS) are arising from this to deliver overreaching and new innovative services and functionalities, especially for the customer of those systems. In the future, it will be more and more beneficial to implement these services and product-based functionality under pertinent aspects of sustainability (e.g. carbon footprint or other critical resources along the product engineering process). In this context, this contribution presents a System of Systems Engineering Lifecycle Concept for the dynamic reconfiguration of systems within a smart Product-based System of Systems to ensure certain sustainability aspects during the system of systems operation using an Internet of Things (IoT) based platform. Part of the concept is, on the one hand, the integration of relevant data from the usage of several systems into the early model-based development phases (like Model-based Systems Engineering (MBSE)) by using the so-called IoT-driven smart Product-based System of Systems Reconfiguration Approach to ensure different sustainability aspects in future development phases of a system or a system of systems. To meet compliance and promotion of sustainability aspects in the operation of a smart product-based system of systems, on the other hand, the approach shows under consideration of the current operating data of the participating systems and their corresponding dynamic adaptation using the example of a sustainable autonomous construction site scenario and an appropriate IoT-based platform.

SYSTEM OF SYSTEMS LIFECYCLE ENGINEERING APPROACH INTEGRATING SMART PRODUCT AND SERVICE ECOSYSTEMS

AbstractDue to the increasing smartization of products and the ecosystems in which they are typically embedded, holistic considerations of future value-added systems are becoming increasingly important. This also determines fundamentally new challenges for the engineering of the future's smart Products. In order to be able to address the increasingly fuzzy system boundaries associated with this, this contribution introduces a System of Systems Engineering Lifecycle Concept considering smart products and services as core components of connected System of Systems ecosystems. Main characteristics of smart products and system of systems are discussed and in a real existing scenario of a sustainable landfill the presented System of Systems Engineering Lifecycle Concept is used as a System of Systems Framework for the given Use-Case.

Model‐Based Systems Product Line Engineering of Physical Protection Systems

AbstractA physical protection system (PPS) aims to protect a system against adversarial attacks by deterrence, detection, delay, and response. PPSs have targeted the protection of various systems, each of which has its specific requirements. On the other hand, PPSs also share a large set of features that are implemented for each system. To reduce the development cost, reduce time‐to‐market, and increase the quality of systems, a large‐scale systematic reuse approach as defined by systems product line engineering (SPLE) can be applied. So far, PPS methods have mainly considered the systems engineering of single PPSs. In this paper, we report on our industrial experiences and lessons learned for adopting SPLE for PPSs. An explicit model‐based systems engineering approach is adopted in which the focus is on the formalized application of models in the overall systems engineering life cycle. Hereby, the presented approach adopts and integrates model‐based systems engineering, product line engineering, and the PPS method to provide a systematic large‐scale reuse approach for systems engineering of PPSs. We discuss the detailed steps of the approach and report on the lessons learned for adopting model‐based systems product line engineering for PPS.

Realizing the Role of Permissioned Blockchains in a Systems Engineering Lifecycle

A key requirement for an integrated digital tool chain is secure access and control of data assets. Not all stakeholders will have the same access to or control over the flow of information, some will be able to input or change data whilst others will only be able to read the data. Simply providing secure access protocols is not sufficient because copied data can quickly become disassociated and modified from its original instantiation, leading to its reuse elsewhere or later in the lifecycle but in an inappropriate way. Therefore, data management mechanisms are required that capture information about the data along with any decisions or modifications it has undergone during the course of its life, thus providing complete traceability for later validation purposes. This undertaking is essential across the systems engineering lifecycle. This pursuit involves controlling who can access and modify data within the lifecycle. This paper describes a solution to this by the introduction of blockchain technology, a relatively new technology that allows digital information to be distributed but not copied, making it an immutable set of time-stamped data managed by a network of connected systems and services. Though blockchain technology is not commonly referred to when discussing Industry 4.0, the technology’s capabilities should add value when applied in a context of data management and security within the lifecycle of a product or services and in conjunction with digital twins, big data, and IoT. This paper describes how permissioned blockchains can be implemented within a systems engineering lifecycle, providing example architecture patterns showing how data provenance can be maintained throughout.

Systems Architecture Design Pattern Catalogfor Developing Digital Twins.

A digital twin is a digital replica of a physical entity to which it is remotely connected. A digital twin can provide a rich representation of the corresponding physical entity and enables sophisticated control for various purposes. Although the concept of the digital twin is largely known, designing digital twins based systems has not yet been fully explored. In practice, digital twins can be applied in different ways leading to different architectural designs. To guide the architecture design process, we provide a pattern-oriented approach for architecting digital twin-based systems. To this end, we propose a catalog of digital twin architecture design patterns that can be reused in the broad context of systems engineering. The patterns support the various phases in the systems engineering life cycle process, and are described using a well-defined pattern documentation template. For illustrating the application of digital twin patterns, we adopt a multi-case study approach in the agriculture and food domain.

Agile Systems Engineering Life Cycle Model for Mixed Discipline Engineering

AbstractThis article focuses on six recent understandings that have crystalized from INCOSE's Agile Systems Engineering Life Cycle Model (ASELCM) discovery project. The ASELCM project analyzed effective agile systems engineering processes in 3‐day structured analysis workshops hosted by organizations that wanted deeper understandings of what works, why it works, and how to apply those understandings across a broader base. Four case studies arising from these workshops have been published. This article cannot cover everything of interest that was discovered, but will expose six key findings: a problem‐space characterization heuristic, an asynchronous/concurrent life cycle model framework, a set of nine systems engineering operating principles, an encompassing pattern of three concurrent behavioral systems operating simultaneously in agile systems engineering, the concept of information debt, and general agile systems engineering response requirements.

Системна інженерія та життєвий цикл систем

Системна інженерія та життєвий цикл систем

Managing Awareness in a CURVE‐y World: Agile Systems Engineering for Autonomous Vehicles

ABSTRACTAwareness is vital to agility. Based on an INCOSE agile systems engineering case study, this article illustrates different perspectives on enabling, exploiting, and balancing awareness, including issues of networks versus hierarchies, teaming and leadership, pattern exploitation, model uncertainty, and optimal estimation and control. The SPAWAR System Center Pacific (SSC‐Pac) in San Diego, US‐CA established capability to facilitate agile development of unmanned systems. As a case study in the INCOSE Agile Systems Engineering Life Cycle Model (ASELCM) Discovery Project, SSC‐Pac provided an example of agility challenges and issues of awareness in addressing them. The model‐based ASELCM Pattern helped us analyze this example beyond the context of agile software methods.

An architecture, system engineering, and acquisition approach for space system software resiliency

ContextSoftware-intensive space systems can harbor defects and vulnerabilities that may enable external adversaries or malicious insiders to disrupt or disable system functions, risking mission compromise or loss. Mitigating this risk demands a sustained focus on the security and resiliency of the system architecture including software, hardware, and other components. ObjectiveIn this paper we offer methodical approaches for improving space system resiliency through software architecture design, system engineering, and increased software security, thereby reducing the risk of latent software defects and vulnerabilities. MethodWe conducted a systematic review of existing architectural practices, standards, security and coding practices, various threats, defects, and vulnerabilities that impact space systems from hundreds of relevant publications and interviews of subject matter experts. We expanded on the system-level body of knowledge for resiliency and identified a new software architecture framework and acquisition methodology to improve the resiliency of space systems from a software perspective with an emphasis on the early phases of the systems engineering life cycle. This methodology involves seven steps: 1) Define technical resiliency requirements, 1a) Identify standards/policy for software resiliency, 2) Develop a request for proposal (RFP)/statement of work (SOW) for resilient space systems software, 3) Define software resiliency goals for space systems, 4) Establish software resiliency quality attributes, 5) Perform architectural tradeoffs and identify risks, 6) Conduct architecture assessments as part of the procurement process, and 7) Ascertain space system software architecture resiliency metrics. ResultsData illustrates that software vulnerabilities can lead to opportunities for malicious cyber activities, which could degrade the space mission capability for its user community. Reducing the number of vulnerabilities by improving architecture and software system engineering practices can contribute to making space systems more resilient. ConclusionSince cyber-attacks [1] are enabled by shortfalls in software, robust software engineering practices and an architectural design are foundational to resiliency, which is a quality that allows the system to take a hit to a critical component and recover in a known, bounded, and generally acceptable period of time. To achieve software resiliency for space systems, acquirers and suppliers must identify relevant factors and systems engineering practices to apply across the life cycle, in software requirements analysis, architecture development, design, implementation, verification and validation, and maintenance phases.

Service Computing System Engineering Life Cycle

The development of service computing technology has triggered the need for organizations to build a service computing system. This system is able to deliver IT services that can meet the challenges and needs of business services. An understanding of the service computing systems engineering life cycle is necessary to model and build the systems. This paper conducts the study of the service computing systems concepts and proposes the life cycle of service computing system engineering. First, some publications relevant to the service computing systems are reviewed systematically in order to develop fundamental concepts and elements of the systems. Second, a metamodel of service computing systems is built based on those concepts. Third, the life cycle model of service computing systems engineering is proposed based on the metamodel. Finally, the verification of the life cycle is conducted by comparing the proposed life cycle to the life cycle of software engineering, service engineering, and service system engineering. The contribution of this paper is to provide a coincise understanding of the components that are needed to build such systems and show the interaction and collaboration between the components in the service computing systems.

Integrated Data as the Foundation of Systems Engineering

AbstractThis paper was written from the perspective that requirements, along with all work products, models, designs, documents, diagrams, drawings, etc.) generated during the performance of System Engineering (SE) lifecycle process activities are represented by underlying data and information that must be linked together and integrated into a common, integrated dataset. Using this perspective, the common, integrated dataset can be viewed as the foundation of Systems Engineering.The authors feel this data‐centric perspective of SE provides a better lens through which to acquire a complete understanding of the SE lifecycle process activities and resulting work products and underlying data and information needed to manage the development of increasingly complex systems of the future. This perspective aids in acquiring a practical understanding of the SE lifecycle processes from the perspective of not only models, but all work products that are generated from activities conducted during each of the SE lifecycle processes and the underlying data and information used to represent these work products.Expanding on the concept of SE from a data‐centric perspective, the goal of this paper is to present a broader data‐centric perspective of SE that meets that will aid readers in successfully meeting the challenges associated with today's ever increasingly complex systems, meeting the intent of the MBSE Initiative, and helping organizations move toward INCOSE's Vision 2025.

Developing A Systems Engineering Capability That Meets the Needs of Your Organization

AbstractThis paper was written from the perspective that requirements, along with all work products (models, designs, documents, diagrams, drawings, etc.) generated during the performance of System Engineering (SE) lifecycle process activities are represented by underlying data and information that must be integrated into a common, integrated dataset. From this data‐centric perspective, the common, integrated dataset can be viewed as the foundation of Systems Engineering. Based on this perspective, this paper discusses what it means to practice SE from a data‐centric perspective and provides the reader guidance that can be used to understand and successfully create and manage an integrated dataset within their organization.

NASA's Robotic Mining Competition Provides Undergraduates Full Life Cycle Systems Engineering Experience

AbstractNASA has held an annual robotic mining competition for teams of university/college students since 2010. This competition is yearlong, suitable for a senior university engineering capstone project. It encompasses the full project life cycle from ideation of a robot design, through tele‐operation of the robot collecting regolith in simulated Mars conditions, to disposal of the robot systems after the competition. A major required element for this competition is a Systems Engineering Paper in which each team describes the systems engineering approaches used on their project. The score for the Systems Engineering Paper contributes 25% towards the team's score for the competition's grand prize. The required use of systems engineering on the project by this competition introduces the students to an intense practical application of systems engineering throughout a full project life cycle.

The Identification and Application of Human System Integration Software Tools to Support the Systems Engineering Lifecycle and the Acquisition Process

This paper discusses the challenges associated with ensuring Human System Integration (HSI) efforts are performed throughout long-duration projects, including the systems engineering lifecycle and the acquisition process. It describes an approach to support this process by identifying relevant software tools that can be used across the lifecycle. The paper also discusses a project to develop a catalog of relevant HSI software tools and to map these tools to the acquisition process and systems engineering lifecycle at the Department of Homeland Security.

A framework for integrating reliability and systems engineering: proof‐of‐concept experiences

AbstractReliability plays a significant role in systems engineering. Adopting the reliability and systems engineering in the early system lifecycle may lead to better quality of the final product as well as more efficient usage of the resources use to launch the product. However, there is presently no concrete framework illustrating how reliability engineering can be integrated into the systems engineering life cycle. This article discusses the development of a new, integrated reliability and systems engineering framework. The approach has been applied in a case study in the form of a student project, including a multi‐disciplinary student team aiming to design, develop, build and validate the energy efficiency of a concept vehicle. Integrating traditional systems engineering strategies with reliability engineering best‐practices was found to significantly enhance not only the quality of the final product, but also to reduce the budget and time due to less late engineering changes and subsequent design iterations.

Introduction to the Agile Systems Engineering Life Cycle MBSE Pattern

AbstractEngineered and other systems are under pressure to adapt, from opportunities or competition, predators, changing environment, and physical or cyberattack. Ability to adapt well enough as conditions change, especially in presence of uncertainty, is valued. Systems (including developmental and life cycle management) that adapt well enough, in time, cost, and effectiveness, are sometimes called “agile”. As environmental change or uncertainty increase, agility can mean survival. Agile systems and agile systems engineering are subjects of an INCOSE 2015‐16 discovery project, described elsewhere. This paper introduces the underlying MBSE‐based Agile Systems Engineering Life Cycle Pattern being used to capture, analyze, and communicate key aspects of systems being studied. More than an ontology, this model helps us understand necessary and sufficient conditions for agility, different approaches to it, and underlying relationships, performance couplings, and principles. This paper introduces the framework, while specific findings about methods and practicing enterprises studied will be reported separately.