MBSE & SysML Applied to the Development of EGSE for Sattelites Assembly, Integration and Testing (AIT) - A Practical Case

— This paper targets to present a proposal for the use of MBSE and SysML applied to a case study of the analysis in a component of a typical Electrical Ground Support Equipment (EGSE) used in Satellite Assembly, Integration and Testing (AIT). The approach aims to describe the process flow used in the analysis, providing a methodological background for the practical application of SysML notation for EGSE's development.


I. INTRODUCTION
Although SysML, in recent years, has become the de facto standard for MBSE, a supporting methodological basis is still needed, as SysML is just a graphical language and defines a set of diagrams, modeling elements, syntax and semantics. Like any language (formal or informal), it can be used in many different ways, including inappropriate ones. Most notably, it is possible to misuse the language for creating unrepresentative or even incorrect models.
The flow of the analysis processes used in this paper seeks to implement, as much as possible, the sequence presented in the GSE Integrated Development Guide proposed by Vintecinque (2017), respecting the limitations imposed by the SysML notation language and the modeling tool used. (Cameo Systems Modeller).
The added value of the methodology with the MBSE approach consists of:  To select a suitable subset of SysML diagrams and artifacts to be generated conveniently and pragmatically;  To define semantics to ensure meaningful diagrams and rules to check the model for consistency;  To define an obvious sequence of diagrams that ensures modeling efficiency in relation to organizational processes, and is well understood by all stakeholders throughout the life cycle;

II. METHODOLOGY -MBSE APPROACH TO THE GSE INTEGRATED DEVELOPMENT GUIDE
The process flow that will be used seeks to follow the major process phases of the Total Vision Framework proposed by Loureiro (2010), as shown below, as well as the SysML diagrams that will be used:

III. CASE STUDY -UMB SCOE ANALYSIS
As proposed by Vintecinque (2017) UMB SCOE is an element of EGSE proposed for future PMM platform satellite missions, which allows use during both the AIT and the Satellite launch phases, and aims to reduce the amount and volume of equipment to be transported to the launch base. The mission of UMB SCOE can be stated as: "To be the only satellite-connected element of EGSE that allows to power up, operate and monitor its vital signs during the AIT and launch phases" Vintecinque (2017)".
The approach in the analysis and modeling to obtain UMB SCOE will be presented next.

a. Mission Analysis
Starting from the mission statement, the possible concepts of operation, as exemplified in Fig. 1, are analyzed for one of the situations.

c. UMB SCOE life-cycle scenarios
The UMB SCO life cycle scenarios are shown in Fig. 3. The activity diagram was used, with the inputs or controls of the old IDEF0 being replaced by SysML "Accept Event Action" or "Time Event" type elements.

ii. UMB SCOE stakeholders concerns
Product and process stakeholder concerns raised previously are analyzed together with the System or Organization of Interest in various scenarios.
The result is described through Use Case diagrams stereotyped as "Concern". Fig. 5 illustrates an example of how this will be done.

International Journal of Advanced Engineering Research and Science (IJAERS)
[ iii. UMB SCOE stakeholder requirements Stakeholder requirements derived from the concerns raised before are analyzed and the outcome is described through requirements diagrams or requirements table as exemplified in Fig. 6. Dependency or trace-ability relationships between requirements and stakeholder concerns can be made explicit in this kind of diagram. Additional attributes can be added to the requirements by the use of Tagged Values provided by the SysML notation. Measures of Performance (MoP) are measures that characterize physical or functional attributes relating to system operation, measured or estimated under specified testing and/or operational environment conditions. Technical Performance Measures (TPM) measure attributes of a system element to determine how well that element is satisfying, or expected to satisfy, a technical requirement.
The SysML parametric diagrams will be used for the MoEs, MoPs and TpMs. It is desired that the measures could be quantitatively assessed, in a form that could be estimated or even simulated in supporting tools, integrated with the modeling tool. In order to allow this, the default SysML meta-model needs to be extended in order to allow then to be expressed in Value Types, but also in a textual description, which can be traced back to the Stakeholders Concerns and Requirements. This can be achieved by a Custom Profile which extends the SysML meta-model, with MoEs, MoPs and TpMs Specification elements, as shown in Fig. 7.

Fig. 7 -MoEs, MoPs and TpMs Specification Meta-
Model. The MoE, MoP and TpM specifications can be traced back to its source as the example shown in Fig. 8.

Fig. 8 -Deriving Specification for MoEs Example.
Finally, the Moe, MoP or TpM quantitative metrics can be expressed by Value Types (Properties), as shown in Fig. 9.

Fig. 9 -Parametric Diagram for MoEs of interest. e. UMB SCOE Requirements Analysis
From the stakeholder requirements and MoEs defined before, as well as the assumptions that emerged during their analysis, the technical requirements (both for product and organization) are derived, but now from the UMB SCOE point of view. Similarly, requirements analysis is described through requirements diagrams or requirements table, as exemplified in Fig. 10. Scenarios and circumstances for the product and organization of interest will then be described as blocks and their interfaces with the environment by using internal block diagram (IBD), as illustrated in Fig. 11.
From the analysis of circumstances, it is possible to identify the events and expected responses of the system, as well as the associated measures of effectiveness. ii. UMB SCOE functions definition For each scenario and circumstance identified, all flows of energy, material and information are gathered and, from them, the system's external functions are identified, which can then be listed in a generic SysML table, as exemplified below: Table 2 -Example of definition list of functions identified  for UMB SCOE (generic SysML table) iii. Scope analysis of UMB SCOE functions Scope analysis of each function helps to identify inputs and outputs and scope limits for previously identified functions, as shown in Fig. 12. Normally, this is represented through an N 2 chart (a.k.a N 2 diagram) which are not part of the SysML standard. But the main idea can be achieved through the use of internal block diagrams (IBD), in a matrix form, with te same rules of an N2 chart:

v. UMB SCOE states and modes definition
From the functions identification, it is possible to identify states and modes of each function external to UMB SCOE. The definition is made by State Machine diagrams, for the purposes of tracing the states and modes to the functions defined before. The final representation is made by using a generic SysML table, as the example shown in Table 3.  SysML Table) vi. UMB SCOE functional behavior analysis After identifying the states and modes of operation, they are then refined using SysML state machine diagrams for each function external to the UMB SCOE. The Fig. 14 shows an example of that. . After that, it will be possible to map how functions interact, and perform functional partitioning that will provide an "allocable" generic functional architecture, allowing architectural decisions to be taken, for the product and organization of interest. In the guide proposed by Vintecinque (2017) DFD diagram is used. With SysML, the use case diagram will be used, with some restrictions, use of stereotypes and minor implementation differences, as illustrated in Fig. 15. i. UMB SCOE physical architecture establishment At this stage, from the functional architecture, through the two types of block diagrams from SysML (BDD and IBD), it is possible to propose a viable generic architecture that seeks to satisfy all that has been raised before, and Fig. 16 represents this step. In the Guide proposed by Vintecinque (2017), the physical architecture for UMB SCOE was not proposed, which will then be done from now on.

Fig. 16 -UMB SCOE Generic Physical Architecture
Example (Use Case Diagram). ii. UMB SCOE physical architecture's functions allocation Function allocation can be done through "allocate" SysML connectors, in block definition diagrams, which do not necessarily need to be documented (they can be temporary). From the relationships made between the functions and blocks of the physical architecture, the allocation matrix can be generated directly from the modeling tool, as illustrated by Table 4. iii. Trade-off analysis This type of analysis is still open in the ongoing study. At first, the intention is to make the trade-off analyzes for "product" by using several block definition diagrams with different practical solutions (Product BreakDown Structures) for the same physical architecture, with estimates and simulations for different vendors / data acquisition solutions, protection systems, etc.
The approach most appropriate in this case seems to be taking advantage of the characteristics of SysML parametric diagrams, as well as external tools integration and simulation, in order to simulate various scenarios of cost, ease of implementation, material availability, technical performance, etc., besides of morphological charts with adequate criteria and weights for each component in order to achieve a balanced Product Specific Physical Architecture, but this issue is beyond the scope of this study effort.
IV. CONCLUSION The use of MBSE through the notation language SysML, supported by the use of appropriate modeling tools, allows to cover virtually the entire product and organization systems engineering life-cycle, obviously while respecting the limitations of the notation itself and maturity of its utilization, as well as the different methodological implementations that make use of it.
There are still difficulties in applying the notation fluidly with respect to the non MBSE approaches used in previous working frameworks, but future versions of the notation itself, such as SysML V2, as well as its future adoption by vendor modeling tools can simplify and better tailor their use more widely.