Currently Implemented in SoloHI MAPPS/EPS Model

SoloHI is modelled as an 'experiment' called SHI in the planning software MAPPS/EPS. It consists of an experiment with different modules (i.e. instrument units) that consume power and can generate data, depending on the module state they are in. The experiment SHI has different 'modes' which are a combination of module states, so in each mode SoloHI will use an amount of power and generate data at a certain rate that is calculated by the software based on the resource usage of each module.

SoloHI modelling is special in the sense that the commanding timelines that the SoloHI team will send to SOC (the IORs) consist of a timeline of instrument-level file transfers, tagged with times of transfer rates rather than execution time. These timelines will not be useful for resource modelling and will therefore be ignored by the SOC planning simulator, and just be passed on to MOC to be executed as part of the mission timeline. 
The SOC resource check will be based on resource profiles that SoloHI will include in the IOR: each IOR will contain a specific sequence call that include resource data points for both power and data generation (see IOR-ICD SOL-SGS-ICD-0003 v0_6.pdf for implementation details). These power and data generation profiles will be ingested by the planning engine and used in overall resource checking of the MTP and STP plans.

Nonetheless, SOC will still need a SoloHI observation model to be run at high level, for mission level planning and Long Term Planning when IOR are not yet available. For this purpose, SOC models high level 'observations' for the SHI experiment , that are associated to one of the defined power modes and each generate data at a predefined (average) data rate. The datarate can be made variable (to be updated when scheduling the observation) if necessary.

Below is described how the SoloHI instrument is built up in MAPPS/EPS and which observations are available.

Modules

Due to file-based commanding approach of SoloHI, SOC will not interpret commanding switching subunits on/off but rather model the high level power modes SoloHI can operate in. Therefore we have simplified the power model to include only (a) the SoloHI Power System (SPS), (b) the optical unit, i.e. Camera electronics SCE + FPA, (c) the operational heaters and (d) the door mechanism . 
These units and their different states corresponding to different power usage, and different data streams, are modelled as modules and module states resp. (see sol_solohi_model.edf). 

• SHI_SPS: SPS_SURV, SPS_IDLE, SPS_OPS
• SHI_OPTICAL:OPT_SURV, OPT_IDLE, OPT_OPS
• SHI_OPS-HTRS: OHTR_OFF, OHTR_FAR, OHTR_PERIH, OHTR_ANN, OHTR_CLOSED, OHTR_DOOR
• SHI_DOOR: DOOR_OPEN, DOOR_CLOSED, DOOR_MOVING
• SHI_LL: LL_OFF, LL_ON

 Note that the split between (a) and (b) is necessary to be able to distinguish between HK data flowing to HK store (modelled as part of the SPS) and science data flowing to SHI science store (modelled as part of SHI_OPTICAL).

Modes

All power modes are modelled as SHI 'modes', and linked to their associated modules (see sol_solohi_modes.edf and sol_solohi.edf). Each of the 'mode' switches are modelled as EPS 'actions' with a 1 to 1 correspondence to EPS 'activities' (see sol_solohi_activities.edf). 

• OPS_PERIH: SPS_OPS, OPT_OPS, OHTR_PERIH, DOOR_OPEN, LL_ON (to be used during perihelion RSW)
• OPS_OUTECLIPTIC: SPS_OPS, OPT_OPS, OHTR_FAR, DOOR_OPEN, LL_ON (to be used during other 2 RSWs)
• IDLE_OPEN: SPS_IDLE, OPT_IDLE, OHTR_FAR, DOOR_OPEN, LL_OFF (to be used outside RSWs)
• SURVIVAL: SPS_SURV, OPT_SURV, OHTR_OFF, LL_OFF, door can be open or closed   (to be used during low power availability)
• ANNEALING: SPS_IDLE, OPT_IDLE, OHTR_ANN, DOOR_OPEN, LL_OFF (to be used during annealing)
• IDLE_CLOSED: SPS_IDLE, OPT_IDLE, OHTR_CLOSED, DOOR_CLOSED, LL_OFF (to be used before door opening)
• DOOR_DEPLOY: SPS_IDLE, OPT_IDLE, OHTR_DOOR, DOOR_MOVING, LL_OFF (during door opening) 

The science observing modes are modelled as SHI 'observations' that are run within one of the OPS modes: (see sol_solohi_observations.def )
It is TBD how to best model SoloHI observations for long term planning purposes. One proposal is defined below, another could be to define an average data rate for each RSwindow or each distance range from the Sun (e.g. perihelion, near, far) and make this datarate a parameter in case it needs updating on the fly. 

• To be run in OPS_PERIH:
  • HI_TURB_PER (SCI_DATARATE = 26500)
  • HI_SHOCK_PER (SCI_DATARATE = 30300)
  • HI_SYN_PER (SCI_DATARATE = 20300)
  • HI_TURB_NEAR (SCI_DATARATE = 23200)
  • HI_SHOCK_NEAR (SCI_DATARATE = 29300)
• To be run in OPS_OUTECLIPTIC:
  • HI_SYN_NEAR (SCI_DATARATE = 19700)
  • HI_SYN_FAR (SCI_DATARATE = 10300)

These science modes can be called with parameters SHI_DATARATE from the observations timeline, and its value updated on-the-fly if necessary.

An example timeline calling most observations and activities currently defined is given below. Complete tests are documented in Tests run on SoloHI model.

01-MAY-2022_00:00:00 SHI ACTIVITY SHI_SURVIVAL # is also initial state of solohi
02-MAY-2022_00:00:00 SHI ACTIVITY SHI_IDLE_CLOSED
03-MAY-2022_00:00:00 SHI ACTIVITY SHI_DOOR_DEPLOY
03-MAY-2022_00:10:00 SHI ACTIVITY SHI_IDLE_OPEN
05-MAY-2022_00:00:00 SHI ACTIVITY SHI_ANNEALING

06-MAY-2022_00:00:00 SHI ACTIVITY SHI_IDLE_OPEN
07-MAY-2022_00:00:00 SHI ACTIVITY SHI_OPS_PERIH
08-MAY-2022_00:00:00 SHI ACTIVITY SHI_IDLE_OPEN
09-MAY-2022_00:00:00 SHI ACTIVITY SHI_OPS_OUTECLIPTIC
10-MAY-2022_00:00:00 SHI ACTIVITY SHI_IDLE_OPEN

11-MAY-2022_00:00:00 SHI ACTIVITY SHI_SURVIVAL

RS_WINDOW_START_MIN 000_00:00:00 SHI OBS_START    HI_OUTECLIPTIC (SCI_DATARATE = 19700)

RS_WINDOW_END_MIN     000_00:00:00 SHI OBS_END        HI_OUTECLIPTIC

RS_WINDOW_START_PER 000_00:00:00 SHI OBS_START    HI_TURB_PER (SCI_DATARATE = 26500)
RS_WINDOW_END_PER     000_00:00:00 SHI OBS_END        HI_TURB_PER 

RS_WINDOW_START_MAX 000_00:00:00 SHI OBS_START    HI_SYN_FAR (SCI_DATARATE = 19700)
RS_WINDOW_END_MAX     000_00:00:00 SHI OBS_END        HI_SYN_FAR

SoloHI power modes with corresponding resource usage

The following (power and science) modes/activities have been modelled, with corresponding data rate and power consumption as follows:

• Power (nominal+CDR margin) associated to each module state according to EID-B Sect. 4.7.2 and Table 4-10.
• HK data rates are modelled as 50 or 500bps, see User Manual Table 2-7 and Sect 4.3.2. It is not absolutely clear from the documentation in which of the modes below SoloHI will generate 50 vs 500bps HK data. SoloHI team to review the table below.
• Science data rates are not included in this table, but in the following table.

(*) It is documented in the User Manual that SoloHI will produce 1MB LowLatency data per day. This is currently modelled as a continuous data stream of 93bps.

(**) Peak power documented as 12.34 but this would include peak heater power of 0W, smaller than nominal power 0.31W. In model, we take 0.31W as nominal and peak power.

(***) Slight difference with modelled peak power because to simplify the model, the same peak heater power is taken for IDLE_OPEN as for OPS_ECLIPTIC.

SoloHI can be switched to the modes above by calling the associated activity with name 'SHI_'+<mode name>.

SoloHI science observations 

Below are listed some typical SoloHI science observations, as document in SoloHI UM Table 4-7. They are modelled in MAPPS/EPS as SHI 'observations'. 

In each science mode, SoloHI also generates 500bps HK data and LL data. The latter has been modelled as a continuous stream of 93bps. 

Link to source documents: 

• Power: EID-B Iss. 4.1 Sect. 4.7.2 and Table 4-10

• Data: SoloHI User Manual Rev B draft 5

Tests run on SoloHI model

To be implemented

• extra mode SURVIVAL_CLOSED if necessary
• Door opening is currently very crudely modelled. It assumes a door deployment that takes 1 hour (higher heater power and door mechanism active) and then switches automatically to IDLE_OPEN mode. To be refined.