Developing an approach for analyzing and verifying system communication

Abstract

Prominent characteristics of systems in the aerospace domain are that they are inherently complex, they must operate under tight resource constraints, and are often parts of a larger system of systems that must be reliable. These systems communicate with each other to exchange data and control information to together fulfill a larger task. In such a setup, the reliability of the communication channel plays a central role in the reliability of the entire system of systems and thus determines the success of fulfilling the larger task. Ensuring such a reliable communication is difficult due to several reasons: (1) the systems are developed independently by different teams at different locations, (2) the specification of the expected communication behavior is ambiguous, and (3) issues in the communication are often subtle and remain uncovered for a long time with the effect that bandwidth and other precious resources are wasted. We are proposing an approach called Dynamic S oftware Architecture Visualization and Evaluation (DynSAVE) to detect problems in the communication between systems by analyzing their communication behavior. The approach is divided into three main steps. The first step is the non-intrusive monitoring and recording of low level network traffic, the second step converts these raw communication records into meaningful messages, and the third step visualizes this abstracted information in such a way that issues can be detected. In this paper we discuss how the approach was applied to the Consultative Committee for Space Data Systems (CCSDS) File Delivery Protocol (CFDP), which is used for satellite communication by the JHU/APL Common Ground System. The approach has proven to be useful for understanding the communication behavior and uncovering subtle issues due to emerging system behaviors

Evaluation of Systems-of-Systems Software Architectures: State of the Art and Future Perspectives

“…For SoS, this possibility is important due to their evolutionary development. SoS architectures continue to evolve after implementation and, therefore, architectural evaluation should be performed during the entire SoS life cycle towards an appropriate management of architectural decisions and assurance of SoS quality requirements [114]. On the other hand, no study in our SLR has focused on only Late Application, i.e., evaluation methods destined only to architectures already implemented.…”

“…• Challenge 3: Production of appropriate architecture documentation: The evolutionary nature of SoS and emergence of quality concerns along the SoS life cycle hamper the production of detailed SoS software architecture documentation specifying quality requirements, mainly in the early phases of the SoS life cycle, when software architectures should be evaluated [66,114]. Such poor-quality documentation afects the scenario-based architectural evaluation, since such documentation is the main vehicle of communication of the architecture for reviewers and stakeholders [24,75,78,95].…”

Quality Evaluation Model for Crisis and Emergency Management Systems-of-Systems

“…The reliability of the communication among constituent systems is an important factor to the success of SoS (Urwin et al, 2010). According to Stratton et al (2009b), it is APPENDIX B. EVALUATION OF SYSTEMS-OF-SYSTEMS SOFTWARE ARCHITECTURES: SYSTEMATIC LITERATURE REVIEW difficult to ensure reliable communication through an architecture evaluation for several reasons: (i) constituent systems are usually developed independently by different teams at different places; (ii) specification of communication requirements is ambiguous; and (iii) communication issues are often subtle and remain hidden for a long time.…”