Complex-systems design methodology for systems-engineering collaborative environment

In the last decades man-made systems have gained in overall complexity and have become more articulated than before. From an engineering point of view, a complex system may be defined as one in which there are multiple interactions between many different elements of the system and many different disciplines concurring to its definition. However, the complexity seen from the system perspective is only partial. In more general terms complexity does not only regard the system per se, but it is also related to the whole life-cycle management of the system. This encompasses all the activities needed to support the program development from the requirements definition to the verification, validation and operation of the system in the presence of a large number of different stakeholders. These two interrelated views of complexity, being bottom-up in the first case and top-down in the second, both converge to the system defined as an entity formed by a set of interdependent functions and elements that complete one or more functions defined by requirements and specifications. Systems Engineering processes have been increasingly adopted and implemented by enterprise environments to face this increased complexity. The purpose is to pursue time and cost reduction by a parallelization of processes and activities, while at the same time maintaining high-quality standards. From the life-cycle management point of view the tendency has been to rely more and more on software tools to formally applying modelling techniques in support of all the activities involved in the system life-cycle from the beginning to the end. The transition from document-centric to model-centric systems engineering allows for an efficient management of the information flow across space and time by delivering the right information, in the right place, at the right time, and to the right people working in geographically-distributed multi-disciplinary teams. This standardized implementation of model-centric systems engineering, using virtual systems modelling standards, is usually called Model Based Systems Engineering, MBSE. On the other side, looking at the problem from the perspective of the system as a product, the management of complexity is also experiencing a radical modification. The former adopted approach of sequentially designing with separate discipline activities is now being replaced by a more integrated approach. In the Aerospace-Engineering domain, for instance, designing with highly integrated mathematical models has become the norm. Already from the preliminary design of a new system all its elements and the disciplines involved over the entire life-cycle are taken into account, with the objective of reducing risks and costs, and possibly optimizing the performance. When the right people all work as a team in a multi-disciplinary collaborative environment, the MBSE and the Concurrent Engineering finally converge to the definition of the system. The main concern of the engineering activities involved in system design is to predict the behavior of the physical phenomena typical of the system of interest. The development and utilization of mathematical models able to reproduce the future behavior of the system based on inputs, boundary conditions and constraints, is of paramount importance for these design activities. The basic idea is that before those decisions that are hard to undo are made, the alternatives should be carefully assessed and discussed. Despite the favorable environment created by MBSE and Concurrent Engineering for the discipline experts to work, discuss and share knowledge, a certain lack of engineering-tool interoperability and standardized design methodologies has been so far a significant inhibitor, (International Council on Systems Engineering [INCOSE], 2007). The systems mathematical models usually implemented in the collaborative environments provide exceptional engineering-data exchange between experts, but often lack in providing structured and common design approaches involving all the disciplines at the same time. In most of the cases the various stakeholders have full authority on design issues belonging to their inherent domain only. The interfaces are usually determined by the experts and manually fed to the integrated models. We believe that the enormous effort made to conceive, implement, and operate MBSE and Concurrent Engineering could be consolidated and brought to a more fundamental level, if also the more common design analytical methods and tools could be concurrently exploited. Design-space exploration and optimization, uncertainty and sensitivity analysis, and trade off analysis are certainly design activities that are common to all the disciplines, consistently implemented for design purposes at the discipline-domain level. Bringing fundamental analysis techniques from the discipline-domain level to the system-domain level, to exploit interactions and synergies and to enable an efficient trade-off management is the central topic discussed in this chapter. The methodologies presented in this chapter are designed for their implementation in collaborative environments to support the engineering team and the decision-makers in the activity of exploring the design space of complex-system, typically long-running, models. In Section 2 some basic definitions, terminology, and design settings of the class of problems of interest are discussed. In Section 3 a test case of an Earth-observation satellite mission is introduced. This satellite mission is used throughout the chapter to show the implementation of the methods step by step. Sampling the design space is the first design activity discussed in Section 4. Then in Section 5 and Section 6 a general approach to compute sensitivity and to support the engineering team and decision makers with standard visualization tools are discussed. In Section 7 we provide an overview on the utilization of a unified sampling method for uncertainty and robustness analysis. Finally, we conclude the chapter providing some recommendations and additional thoughts in Section 8.