System architecting and design space characterization

Abstract

This article provides a process for system architecting that incorporates a holistic approach for architecture design space characterization by integrating decision alternatives in functional, physical, and allocational design spaces and accounting for interactions. System architects are faced with numerous decisions for system form, functions, and operations when defining a system architecture. Systems designers are tasked with selecting design options which provide the necessary functionality in support of the architecture. Since modern systems, especially system-of-systems, are composed of interacting and interwoven functions and elements, it is imperative to holistically evaluate variations in the system architecture and system design, and discover interactions among and between architecture decisions and design decisions. In this article, this design space characterization is made an integral part of the system architecting process and a set-theoretic framework is developed for managing an extensive design space. The design space characterization problem is formulated as identification of the significant decisions variables and quantification of their impact on the system objectives. A Design of Experiments framework-utilizing Analysis of Variation (ANOVA) and Range Tests-is presented to holistically characterize system architecture design space including the interactions between system form, function, operations, and design decisions. K E Y W O R D Sdesign of experiments, design space exploration, system architecting, system-of-systems architecting, trade-off analysis Systems Engineering.

Systems Engineering Approach to Food Loss Reduction in Norwegian Farmed Salmon Post-Harvest Processing

“…The system's interacting functions and elements require a holistic evaluation of the variations in the system's structure [27]. Systems are a collection of hardware, software, people, facilities, and procedures organized to accomplish some common objectives that stakeholders of the system are interested in [28,29].…”

An Approach to Analyze Vulnerability of Information Flow in Software Architecture

“…Service S 0 2.4 Service S 1 4 Service S 2 4 Service S 3 4 Service S 4 4 Service S 5 4 Service S 6 4 Service S 7 4 Service S 8 5 Service S 9 5 Service S 10 5 Service S 11 5 Table 9. Service invocation elements in network reception and dispatch module.…”

“…Service S 0 4.5 Service S 1 3 Service S 2 2.4 Service S 3 2.4 Service S 4 2.4 Service S 5 2.4 Service S 6 2.4 Service S 7 2.4 Service S 8 2.4 Service S 9 2.4 Service S 10 2 Service S 11 1 Service S 12 1 Step 3. Based on the obtained service invocation information above, the service invocation diagram was constructed.…”

“…It is a high-level abstraction of a software system [8]. The architecture defines functional, allocated, and product baselines of a system [9]. It can also be used to track current and future descriptions of a system composed of components and their interconnections, the actions or activities those components perform, and the rules or constraints for those activities [10].…”

Modeling and structuring design rationale to enable knowledge reuse

“…Instead, we propose a compositional model that integrates different views of a system together. Such a model should include the exhaustive set of design variables and their options; these allow verification of the system's structure, behavior, and performance to directly assess its value . (p227) Complexity, as characterized by the number of variables and relationships, pose a challenge to propose a model of safety assessment .…”