Module Definition and Data Flow for GARCASIM GARCA

Module Definition and Data Flow for GARCASIM GARCA Project Team, IEEC/UPC 24/11/2014

Communication • For WP 20 and the followers, it is important to define the GARCA-SIM Module from the beginning, especially data flow (Input/Output). • Each module can be define/design/implemented somehow independently by the assigned team, which means that the inside of module is relatively flexible to modify. • However, for integration the whole system, the link and I/O between (or among) the modules are non-flexible compared with the module itself. • Therefore, as the first work, it is better to define the MODULE-level specification, including I/O, link, functionality. • Here I suggest the Module Specification Table approach. • So, I want to suggest that individual team makes the Module Spec Tables and iterate them to consolidate.

Define the Simulation Modules (1) Considering the GARCA WBS, the GARCA-SIM Modules are defined as follows. Each module corresponds the WP from 21(31) to 26(36). ※ Here, the term of module means the part of the GARCA-SIM program, to be independently developed, before linking them. Module could consist of sub-modules / building blocks / sub-building blocks/ functions, etc. M 1: Orb/Spec Module M 2: Ins. To. L 1 Module M 3: L 1 To. L 2 Alt Module M 4: Ph. Dl. Alt Module M 5: L 1 To. L 2 Scat Module M 6: Sys. Eff Module

Define the Simulation Modules (2) From the beginning, it is important to clarify the DATA FLOW among the MODUES. So, it is good to introduce the Module Specification Table M 3: L 1 To. L 2 Alt Module M 2: Ins. To. L 1 Module M 1: Orb/Spec Module ? M 6: Sys. Eff Module ? ? ? Temp Data ? User Interface (I/O) M 4: Ph. Dl. Alt Module ? ? M 5: L 1 To. L 2 Scat Module

Define the Simulation Modules (3): Using Module Specification Table General Information Module Name: Write the Module name here Description: Include a short description of the Module Specification Version: Version Scope of Application and Limitations: Include details of under which conditions is the Module valid (e. g. type of scene, type of instrument, etc. ). Inputs (include parameters that come from other Modules or from external data sets) Name Units/Format Description From Name [Units]/Format Description Module Name / External Outputs (include parameters that go into other BBs or can be used for performance evaluation ) Name Units/Format Description To Performance Name [Units]/Format Description BB Name Implementation Composing Children: List the sub-Modules, building blocks, sub-building blocks, functions in which the present Module is decomposed. Name Description Algorithms: Give an overview of the different algorithms that could be used for the implementation of the Module, and how different algorithms would make the Module valid under certain conditions or with a higher level of performance at the sake of complexity. If applicable, list any limitations in the input/output data derived from the specific algorithm. Existing Libraries or Implementations: Refer to any existing libraries that could be used for the implementation of the Module, or to other existing implementations/E 2 E simulators from where the Module could be entirely or partially reused.

Define the Simulation Modules (4): Example Module Spec. Table As now, more important thing is to define the Input/Ouput and their link (from where to where). So, Plz, concentrate and focus the Inputs / Outputs items. Module Specification General Information Module Name: M 1. Orb/Spec Module Version/Date: 1. 0 / 30 -11 -2014 Description: As given scenario, find the ISS (Rx) and GNSS (Tx) satellites’ states (position and velocity) and the corresponding specular reflection point. Scope of Application and Limitations: Based on WGS 84, EGM 96, Inputs (include parameters that come from other Modules or from external data sets) Name Units/Format Description From Sim. Epoch [s]/ UTC time Simulation Epochs User scenario inputs string Outputs (include parameters that go into other BBs or can be used for performance evaluation ) Name Units/Format Description To SCpos_EC [m]/ (x, y, z) ISS (Rx) position in ECEF frame at epoch M 2 GNSSpos_EC [m]/ (x, y, z) GNSS (Tx) Position in ECEC fram at epoch M 2 Implementation Composing Children: Name Description Spec_Find BB to find the specular reflection point Geoid. Height Function to find the geoid height of given specular position. Algorithms: … To be described. Existing Libraries or Implementations: Using GAT (v 2) ground coverage tool PE Y N

Define the Simulation Modules (5): Guide to Module Spec. Table • Please, concentrate and focus the Inputs / Outputs items. Especially, so specify where the INPUT from. • This Spec. Table approach is aiming to communicate and consolidate the MODULE level definition among the GARCA developing team members. Each module is required to be linked to the other module developed by the other member. • The table contents would improve by internal iteration, • For some items, if you do not know exactly or not clear, leave the as empty and marking. • This table would directly be utilized for WP 20 level. Actually, the work filling the table is quite similar to conduct the TASKS in the WP definition. • It would be good to make the Module Spec Table using simultaneously “Top-down and Bottom-up” together, i. e. , the MODULE level definition will generate the Module routines such as ‘sub-module / BB (building block) / sub-BB’, and the assembling Module routine will generate the MODULE definition. In this case, you can generate the “sub-Module” or “BB” spec table, in the same way. • Once the MODULE Spec. Tables are consolidated, the Module level Data flow Diagram would be clarified. • More specific detailed template for “Module / sub-module / BB” spec table is discussed later on.