A fundamental challenge for system engineers is to capture a problem with an effective model or framework and then facilitate transferring the information of that captured problem to practical systems engineering tools and methods. The early problem definition phase requires an application of systems thinking with adequate modeling tools and methods. Then, the later problem definition phase and early system architecting phase requires transferring the captured problem to systems engineering tools and methods through emerging techniques such as model-based systems engineering (MBSE) using SysML (MBSE is the practice of using a modeling tools to capture systems engineering diagrams). This paper presents a method for capturing a problem through systemigrams and the Boardman soft systems methodology and then directly translating the systemigrams into SysML diagrams. With MBSE increasing in usage, this method could provide a time savings opportunity during model development along with the possibility of lowering information distortion or loss that can occur during transformation of systems thinking to systems engineering activities. This paper includes a case study which demonstrates how the proposed approach was applied on a problem being considered by the U.S. Army-Contingency Basing for Small Combat Units. Finally, this paper will provide the conclusion on the development of the method and describe future research directions that can allow systems thinking and MBSE to function in a congruent methodology.
In order to understand how we may engineer system of systems (SoS), we will have to rely significantly on our abilities in modeling and simulation. While there are some models of non-specific SoS, few attempts have been made to demonstrate these models with simulation. Simulations of SoS are usually specific cases. Likewise, in the description of a SoS, most of the approaches have focused on their characterization, yet this characterization has not been greatly utilized as an underlying feature in the modeling and simulation of SoS. We review different modeling techniques and use two converse techniques, i.e. agent-based and event-based modeling, to run a simulation of hypothetical systems collaborating into a SoS. The results of the empirical comparison indicate an agent-based modeling approach would achieve a characterization model better with validation achieved through an event-based approach
Digital twin (DT) is a technology that promises great benefits for the manufacturing industry. Nevertheless, DT implementation presents many challenges. This article looks to understand and study the problems associated with the implementation of DT models in a manufacturing domain. It applies systems thinking techniques to analyze and refine these problems. Systems thinking presents several methods and tools that help in studying a problem space and a solution space. The conceptagon framework describes the DT model as a system with several attributes and analyzes it in detail. A systemigram shows the relationship of manufacturing systems and the DT model. It maps the processes and components for DT implementation. The TRIZ method analyzes, and forecasts problems related to DT development and provides solutions based on patterns of invention. The CATWOE analysis allows identification of stakeholders and the study of the DT model from their perspectives. It provides a root definition of the DT model to refine a problem and the problem’s contradiction. The 9 windows tool helps to delimit the DT implementation problem, based on time and space. It gives eight more perspectives to solve the DT problem. Finally, the ideal final result (IFR) method provides the ideal DT model concept for manufacturing systems.
The need to perform faster systems integration of complex systems require the architect and design team to understand how the selected architecture and design components will impact the systems integration processes complexity (or difficulty). Systems integration process complexity is an outcome of the interaction between degree of feasibility and level of effort required to understand, describe, implement, manage, and document the systems integration process for a given system development and operational environment. This paper analyzes the cause-and-effect relationships between the system requirements, architecture and the systems integration processes complexity. In order to address systems integration issues upfront in the design phase it is necessary to determine if the architecture and design of components, subsystems, processes, and interfaces impacts (and to what extent) systems integration process complexity. This paper also defines and analyzes the impact of the different system architecture and requirements factors on systems integration process complexity. A research framework is developed to understand the cause-and-effect relationships between system requirements, architecture, and integration process. Finally, the paper proposes recommendations based on the causality results. These conclusions are based on research undertaken by the authors on eight development projects in the government sector.