You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 14, 2025. It is now read-only.
As shown in 3cb6756 on bug/szy-enforce-false-assumptions-mode-change, trying to implement #13 exclusively through enforcement only moves the assumption to before the initialisation sequence, but doesn't get rid of it.
As cleverly suggested by @ZonaDashti, this could be achieved by simply requesting a *-Mode-Status-Report-T from a subsystem without commanding a change to a *-Mode-T first.
Off the top of my head, this would require adding a new request * mode status interface from the OBC's system_mode_manager to each subsystem's *_mode_tracker to just request the current mode status, which could be simply delivered through the existing report * mode status interface.
Internally, the system_mode_manager should be fine just going into the Wait_* state after the request, but some extra logic should be added at the "output stage" because we probably wouldn't want to try downlinking a whole report every time.
These requests would be triggered at the beginning of the initialisation procedure as elicited by #13; additional interesting possibilities could also be upon request from the ground station, and cyclically to generate and store telemetry data. #15 follows up about the first addition.
As shown in 3cb6756 on
bug/szy-enforce-false-assumptions-mode-change, trying to implement #13 exclusively through enforcement only moves the assumption to before the initialisation sequence, but doesn't get rid of it.As cleverly suggested by @ZonaDashti, this could be achieved by simply requesting a
*-Mode-Status-Report-Tfrom a subsystem without commanding a change to a*-Mode-Tfirst.Off the top of my head, this would require adding a new
request * mode statusinterface from the OBC'ssystem_mode_managerto each subsystem's*_mode_trackerto just request the current mode status, which could be simply delivered through the existingreport * mode statusinterface.Internally, the
system_mode_managershould be fine just going into theWait_*state after the request, but some extra logic should be added at the "output stage" because we probably wouldn't want to try downlinking a whole report every time.These requests would be triggered at the beginning of the initialisation procedure as elicited by #13; additional interesting possibilities could also be upon request from the ground station, and cyclically to generate and store telemetry data.
#15 follows up about the first addition.