Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System-wide Mode Change architecture matching TASTE implementation for CloudView-1 mission / IAC23 diagrams #61

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

chgio
Copy link
Member

@chgio chgio commented Jan 25, 2024

The architecture specified in #41, when implemented as per guorbit/obc-firmware/#4, introduced the async bug described in guorbit/obc-firmware/#9. As an architectural issue, this bug was fixed in TASTE by refactoring the topology of the System and Subsystem Mode Management components as detailed in guorbit/obc-firmware/#11.

The IAC work An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project mainly revolved around showing that a semantic mirroring between Capella and TASTE is possible and helpful, so these refactorings have been backpropagated to the Capella model in the outstanding commits below.
After confirmation of the functionality and reliability of this system through the successful CloudView-1 sounding balloon launch (guorbit/obc-firmware Release), the deployed TASTE architecture shall be frozen in the Capella model as a significant flight-proven element, so a merge is required.

The work on Watchdog Monitoring previously merged in #36 only conflicts with this branch in Git because of the lack of integration with Capella's underlying XML semantics; however, there should be no conflict between that and the features proposed in this MR, as they simply pertain to distinct sections of the OBC.
As it is smaller in architectural scope and diagram impact, my recommendation would be to pick that as the target of our manual re-modelling, rather than the work described in the commits below. Feel free to use whatever kind Diff/Merge tools you can get to work, just please make sure the work done in this branch is not impacted as it is the one that got flight-proven.
By the way, thank you @xszymonzur for all the great work, I'll spare you from doing more boring Capella work for nothing but we'll still ask you to review this request just to make sure everything is as you intended before merging it 😄

Some previous CI/CD work (#57, #58, #59, #60) has also been done to generate the HTML documentation directly from this unmerged branch (through the cloudview-1 tag) and deploy it on the model export website to facilitate its consultation. The exports can be found here for this unmerged branch, and here for the main branch including #36. For more punctual exports, you'll have to hope the artifacts from the Workflow Runs haven't expired 🤞

Notable exceptions to the aforementioned symmetry between Capella and TASTE are the few architectural "hacks" such as guorbit/pipeline-relay (cloudview-1 Release) or guorbit/camera-relay (cloudview-1 Release), which for simplicity have not been represented in the model and are therefore not included in this MR.
However, these hot-fixes were only required to integrate the TASTE software with the selected hardware within the time constraints of the project, and did not significantly alter the topology of the wider system.
Nevertheless, consideration should soon be given to further backpropagation of these solutions should they be deemed stable enough. (@Sajtospoga01, @bobtailcat00)

"cascade" architectural/functional changes informed by the TASTE
implementation back into the model (bottom-up):
- rename "Change system mode" to "Initiate mode change"
- add new "Update system mode" as a child of the Logical-level "Change
  system mode" function, and append it at the end of all (system-wide)
  mode change Functional Chains.

consequently, update the following diagrams:
- [PFBD]
- all composite [PFCD]
- all [PDFB]
- all [PAB]
- [ES] (physical)
"cascade" architectural/functional changes informed by the TASTE
implementation back into the model (bottom-up):
- in [PFBD]: add new functions as children of "Change system mode":
  - initialise mission-system mode mappings
  - map mission mode to system mode
  - relay system mode change report
- in [PCBD]: add new behaviour PC "Mode change telecommand handler"
  allocating the functions above
- in [PFCD] T/C Mode Change:
  - insert "map mission mode to system mode" between "receive mode
    change TC" and "initiate system mode change"
  - insert "relay system mode change report" between "flush system mode
    change report" and "send mode change report"

consequently also update the following diagrams:
- [PDFB] Mode Changes, T/Cs
- [PAB] Root, Mode Changes, T/Cs
- [ES] (Physical)
…D UPDATES (PHYSICAL)

"cascade" architectural/functional changes informed by the TASTE
implementation back into the model (bottom-up):
- in [PFBD]: add new functions as children of "Change system mode" (for
  every S/S):
  - "Validate S/S mode change"
  - "Update S/S mode"
- in [PCBD]: rename "S/S mode change notifier" components to "S/S mode
  tracker"
- in [PAB]:
  - allocate the functions above to "S/S mode tracker"
    components, and redraw for readability
  - also rename all mentions of "S/S mode change report" to "S/S mode
    status report"
- in [PFCD] S/S mode change, insert:
  - "Validate S/S mode change" at the beginning of the FC
  - "Update S/S mode" between "Send S/S mode status report" and "Relay
    S/S mode status report"

consequently also update the following diagrams:
- all composite [PFCD]
- all [PDFB]
- all [PAB]
- [ES] (Physical)
…(PHYSICAL)

"cascade" architectural/functional changes informed by the TASTE
implementation back into the model (bottom-up):
- in [PCBD]:
  - remove all "S/S mode tracker" components
- in [PAB]:
  - reallocate S/S mode change functions from "S/S mode tracker"
    components to "System mode manager"
- in [ES]:
  - move subsystem mode change sequences from "S/S mode tracker" to
    "System mode manager"
  - also add "Update S/S mode" to subsystem mode change sequences
  - also swap "Collate system mode change report" for either of its
    children ("Buffer ..." or "Flush ...")

note the absence of semantic changes to the functional model.
"cascade" architectural/functional changes informed by the TASTE
implementation (thick sys. m. mgr.; async. interf.s) back into the model
(bottom-up):
- in [PFBD]:
  - rename "Initiate system mode change" to "Validate ..."
  - rename all "Notify S/S of mode change" functions to "Send S/S mode
    change command"
  - rename all "Update S/S mode" function to "Parse S/S mode status
    report", and change their parent to "Receive S/S mode status report"
  - rename all "Relay S/S mode status report" functions to "Update S/S
    mode", and change their parent to "Change system mode"
  (weird renames and parenthood changes were made to minimise impact on
  other diagrams such as [PDFB], [PAB], and [ES])
- in [PCBD]:
  - remove "Mode change report collector" behaviour PC
  - remove "System mode management group" behaviour PC
  - change parent of physical actors to physical system
- in [PAB]:
  - reallocate "Buffer system mode status report" and "Flush system mode
    status report" to "System mode manager" behaviour PC
  - allocate all functional exchanges related to the T/C mode change FC
    to component exchanges between their allocating behaviour PCs, and
    component exchanges to physical links between their allocating node
    PCs

consequently, update the following diagrams:
- all [PDFB]
- all [PAB]
- [ES] (Physical)
and change scope of [PDFB] and [PAB] views of "Telecommands" to
"Stateless Telecommands" removing the T/C mode change FC.
thanks Szymon for the tip!

finally, to precisely and formally match TASTE implementations of the
T/C mode change feature, create the following diagrams:
- [CDB] TASTE Data View, specifying structures and types of data to be
  exchanged as part of interfaces
- [CII] TASTE Interface View, specifying interfaces to enable the
  crossing of component boundaries through component exchanges
- [PAB] TASTE Deployment View, by removing all functions from Root [PAB]
  to only represent the allocations of behaviour to node PCs, and of
  component to physical links
- [MSM] SDL Implementations of:
  - Mode Change Telecommand Handler
  - System Mode Manager
  ...specifying the states and transitions to implement the components'
  behaviour in SDL, allocating incoming functional exchanges as
  transition triggers and functions to perform as transition effects
- add (cursed) shortcut paths to [MSM] SDL Implementation of System Mode
  Manager
- fix interface provision of return-path CP for system mode change from
  "Change system mode" (IN/OUT) to "Relay system mode status report"
  (OUT)
- fix CP allocation for SW pipeline S/S
- add mission mode change report data type and fix allocation of
  return-path interfaces
post-CloudView, post-paper backpropagation of implemented TASTE model in
Capella:
- add "Area of Interest configuration" functional chain to [PDFB]
  Physical Functional Dataflow View of Stateless Telecommands
- propagate "Send Area of Interest config report" function to
  Logical Architecture level
- also create specific diagram clones for the paper -- tagged with (IAC)
add CloudView deployment to IAC branch
fix index for CloudView deployment on IAC branch
@chgio chgio added model-feature Functional modelling, at any level system Outside the scope of any single Subsystem labels Jan 25, 2024
@chgio
Copy link
Member Author

chgio commented Jan 31, 2024

can't remember if this strategy has already been detailed somewhere in another PR, but here it is for the convenience of @ZonaDashti and anyone else browsing in the future:

$ git checkout model/gio-mode-change-integrated
Switched to branch 'model/gio-mode-change-integrated'
Your branch is up to date with 'origin/model/gio-mode-change-integrated'.

$ git merge -X ours main
Auto-merging obc-model/obc-model.aird
Auto-merging obc-model/obc-model.capella
Merge made by the 'ort' strategy.
 .gitignore                  |    1 +
 obc-model/obc-model.aird    | 1920 +++++++++++++++++++++++++++++++++++++++----
 obc-model/obc-model.capella | 1430 +++++++++++++++++++++++++++++++-
 3 files changed, 3155 insertions(+), 196 deletions(-)

This leaves you with a Capella model that is valid, but missing any conflicting changes from main -- in this case, @xszymonzur's work merged in #36.
I would recommend committing the merge before copying over the missing work; the other changed files concern the CI/CD pipelines, and should be checked out from main:

  • .github/workflows/deploy.yml
  • entrypoint.sh
  • index_stub.html

[MCB] System Capabilities: added System health monitoring capability (parent) and Watchdog monitoring (child)
[SAB] Root system architecture
Added functions:
- Check system’s health
- Restore system’s health
Added functional exchange:
- System faulty. Restore health.
[SAB] Root system function breakdown
(automatically) Added functions
- Check system’s health
- Restore system’s health
Created new diagrams:
- [ES] OBC Watchdog Monitoring Scenario
- [SDFB] Functional Dataflow View of OBC Watchdog of OBC Watchdog Monitoring
- [SAB] System Architecture View of OBC Watchdog Monitoring
[MCB] System Capabilities:
- removed child Watchdog monitoring capability (too detailed for system level)
Deleted diagram:
- [ES] OBC Watchdog Monitoring Scenario
Created new diagram:
- [ES] System Health Monitoring Scenario
ref #6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
model-feature Functional modelling, at any level system Outside the scope of any single Subsystem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants