Telecommand-based, System-wide Mission Mode Management

[chgio]

As per #4, this MR introduces the implemented management of mission modes (idle, imaging, processing) across all* subsystems from a single, small telecommand transmission.

This feature has been thoroughly, though relatively coarsely, tested across a multitude of architectures and implementations, motivating its final shape.

* the Deployer and ADCS subsystems are included in architecture, but not in logic. As these two subsystems are not impacted by mission mode changes (see Capella [LAB]/[PAB] views of this feature), I opted against writing purposefully uncovered logic.

1. Distributed, Asynchronous

Originally (b44bbf3), the feature was implemented as architected in Capella (model version of PR #41), with a central System Mode Manager only enforcing the order of subsystem mode changes, and one Subsystem Mode Tracker per subsystem, each enforcing the validity of the requested subsystem mode transition. For simplicity, all interfaces were made sporadic (asynchronous).

This approach was adopted so that the OBC could track other subsystem modes as SDL states, mainly for the purpose of verifying SDL code by comparing the resulting State Chart View with the subsystem FSM specified in Capella.

It worked (kinda; source), but this architecture relied too heavily on sporadic interfaces, implementing synchronous behaviour through waiting states. This exposed its two main flaws:

1. unreliable behaviour, resulting in Rare mismatch between mode and last operation in subsystem mode status reports #9
2. excessive memory footprint, preventing it from fitting on the MSP430 -- even using the full 64KB afforded by the large memory model powered by the C code generation backend

2. Hybrid, Synchronous

To fix both flaws pointed out above, the feature was refactored to use protected/unprotected (synchronous) interfaces for all links except for the forced-async G/S -- OBC serial. Due to TASTE/SDL limitations, this also required centralising the subsystem mode transition validation logic from the Subsystem Mode Trackers to the System Mode Manager (8c48c42).

This was successful in achieving its targets:

1. Rare mismatch between mode and last operation in subsystem mode status reports #9 was fixed to very high confidence ($\geq 99.9 \, \%$, source), as tested on x86 deployment
2. memory footprint was reduced enough to fit all subsystems on the MSP430, demonstrating full round-trip communication and full logic execution (68a0f30)

However, this architecture also had some shortcomings:

1. not scalable to distributed deployment: as TASTE requires that any interface allocated to an inter-device link is strictly sporadic, supporting communication with actual subsystems deployed on separate hardware nodes would have re-introduced nearly all the sporadic interfaces removed with the refactoring, and with them also their memory footprint
2. not very elegant, and nullifying the original point of the distributed architecture: due to TASTE/SDL limitations when dealing with synchronous interfaces, a separate interface was required for each target subsystem mode; the centralisation mentioned above left the Subsystem Mode Trackers basically without logic, so meaningful State Chart Views of their implementations could no longer be obtained

3. Centralised, Asynchronous

To address both shortcomings pointed out above, the feature was once again reverted to using asynchronous interfaces, but now refactored to adopt a much more centralised architecture: the System Mode Manager includes all the logic of enforcing the order of the subsystem mode changes and validating the subsystem mode transitions (d66bba28); Subsystem Mode Trackers are to be considered Subsystem Mode Managers themselves (and eventually deployed with the rest of the subsystem on a separate hardware node), and duplicate the latter logic as a redundancy measure (92c454a). This duplicate logic is never nominally exercised, so a new System Mode Manager implementation was written only including the subsystem mode change order enforcement logic, so that the subsystem mode change validation logic in the Subsystem Mode Managers can be tested. Successful tests and coverage reports give credibility to this back-up logic (source).

Again, this has been successful in achieving its targets:

1. sporadic interfaces enable the deployment of separate subsystems on separate hardware nodes
2. meaningful State Chart Views can once again be generated from the Subsystem Mode Managers, enabling comparison with Capella -- and on the subsystem itself, where it actually matters
   ... and did not introduce any regression, as Rare mismatch between mode and last operation in subsystem mode status reports #9 is still fixed to the original confidence (source)

Critically, however, this introduces extremely significant paradigm shifts in our approach to both software and hardware:

1. just like the "OBC Model" repository is evolving to encompass the entire CubeSat system, this "OBC Firmware" repository is also evolving to encompass the firmware of all (or at least most) subsystems of the CubeSat
2. as there really does not seem to be any way to avoid high-memory-footprint sporadic interfaces for convenient distributed deployment, the MSP430 is to be phased out in favour of more modern chips with larger memory banks (most likely STM32). However, the MSP430 can still be used for simpler projects, such as CloudView launches with significant subsystem cuts -- such as the one coming up soon! (source)

[xszymonzur]

Good job, the PR comment is very thorough, the division into 3 separate design ideas and the references to the commit comments are especially good, it’s way easier to find them now. One can really see how and why the feature evolved over time. When it comes to the content of the PR itself, it seems to be fine and working, also it’s definitely been well tested and reviewed multiple times by now. Thanks for including the test_subsystem_mode_change_validation, it might just turn out to be useful in the future.

About the last paragraph, yes ofc the MSP430 is not going to last long term as discussed, but it still might be debatable whether OBC Firmware repo covering other subsystems of the CubeSat in the future is a good thing or not.

Solid work:fire:, good to go.