OBC Watchdog Monitoring and Watchdog Timeout Scenario

[xszymonzur]

OBC Watchdog Timeout and OBC Watchdog Timeout Scenario from Systems Analysis to Physical Architecture with 2 Functional Data Flows and a Physical Architecture View.

Close #6, close #30, close #31

[chgio]

The System Analysis level is all good, very clean.
here's only an alternative to the Scenario: your ALT block doesn't have to be like an IF-ELSE statement, it could also be a simple IF statement. in this case specifically, you could also draw "Check MCU's Health" outside the ALT block, and then in the ALT block only draw the subsequent exchange. it's more DRY, but readability gains are debatable and marginal at best.

Logical Architecture is where your modelling really shines!
I love how you've already included checking both the OBC's own health as well as other subsystems' health under the same parent function, again this keeps the System level really clean, and expands the Logical level by just the right amount to prepare a "hook" for other capabilities which are obviously semantically related.
The current state is fine, but considering the upcoming Dumb Comms Refactoring, the functions "Check/Restore Communications Subsystem MCU's health" would have to be allocated to the OBC -- or removed altogether! -- which would also illustrate the health-checking service for other subsystems.
At any rate, great work in term of flexibility too.

Physical Architecture is just something else though.
Masterfully-sized breakdown, perfect allocation with new hardware and software nodes, extremely detailed scenarios even with comments! And I'm in absolute awe at your work with the Functional Chains and how you managed to get forks and loops through the Description diagrams!
The only feedback would be to not err on the side of awesomeness: don't get me wrong, these "virtuoso" representations are amazing, and they do a very thorough job at illustrating properties and requirements -- but this is a relatively simple feature, and there are already 3 instances of the same function in a single scenario and definitely non-trivial-to-read functional chain. Consider only including a smaller window of time in your scenarios (just enclose everything in a LOOP block) and being looser with your functional exchanges (maybe let an exchange begin from a certain entity just to get a linear functional chain, even though it should semantically be from another) -- but it's probably better to over-model than under-model.

All in all, excellent work!

Your punishment for committing all this beauty in a single chunk will be to manually re-model this directly on main whenever we get to use Team for Capella, so this will probably never get merged. It's that, or resolving the conflicts with Capella's diff/merge tool, and I know which one I'd pick.
Sorry about that 😅

[chgio]

Great work as in the last review!

Oversights

There's only one actual oversight since the last review:

• Include entities from [PAB] Health Monitoring into [PAB] Root: great work highlighting the health monitoring involvements within this diagram, but it should also appear in the Root Physical Architecture. The purpose of Root diagrams is to include everything about the whole system, so the same stuff that's in this subset should be in its superset. I know the Root is very messy, so good luck fitting your work in there! 😅

Improvements

The changes since the last review (#41) have also opened up an opportunity for a modelling improvement, which I'm incredibly excited about:

• Add watchdog timing requirements as Capella Requirements: your work is a perfect example of why we're using Capella and doing all this: specifying your Exchange Scenarios has successfully elicited some new requirements, which you've cleverly picked up and diligently noted down. Now that we're using the actual extension implementing Requirements as Capella objects, let's make it formal! 🤩
  • Add it to [RQT] OBC Subsystem Requirements; sounds like 05 FDIR/A01-OBC-FLT-P-XXX would be a good fit
  • See if you can substitute the relevant notes in [ES] diagrams with a reference to the actual requirement

Nitpicks

Finally, here are just some extremely nitpicky semantic points, which have also only become evident since specifying the CloudView architecture:

• Substitute "MCU" with generic entity references: this is a very interesting point, as this feature could very well be imagined to concern MCUs; however, conceptually, MCUs don't really exist at any level above Physical, and not even for all Subsystems at that level. Thinking about it, the OBC's function of acting as a software watchdog for other Subsystems holds regardless of their Physical-level allocation to Nodes -- only the applicable corrective actions do (System Analysis: Other S/S Soft Reset #1, System Analysis: Other S/S Hard Reset #2, System Analysis: S/S Bug-Squashing Firmware Reprogram #3), but that's a problem for those issues and for System Analysis: Multi-Tier Reset Policy #38. The following sounds better to me:
  • System level: "MCU" -> "System"
  • Logical level: "MCU" -> "Subsystem"
  • Physical level: "MCU" -> "Component"
• Remove "own" in functions allocated to the OBC: this couples the name of the function to its allocation; the fact that it's the OBC that checks and restores its own health is conveyed by the allocation of these functions to the OBC, but theoretically they should equally make sense if another Subsystem was responsible for that.
• Include parent functions from Logical level in [PDFB] Health Monitoring: since you got me started with Dataflow diagrams, I've struggled to see what sets them apart from just Architecture diagrams without components... I think one approach is highlighting the realisation of Functional Chains by inserting each involved function into its higher-level parent, which is not possible in any other diagram. This way, Architectures show the impact of FCs on the components allocating the involved functions, and Dataflows show the impact of FCs on the parents of the involved functions. Yes, it does get quite messy, but it's the Physical level, what diagram doesn't at that point?
• (Optional) Extend health checks to non-OBC Subsystems to all other Subsystems: we're in for a penny, let's be in for a pound! (I had to look up how to say this in English lol) If you want to get ahead and set the stage for System Analysis: Multi-Tier Reset Policy #38 in advance, please extend health-checking functions from just Comms to every other Subsystems; otherwise, you might as well remove the one involving Comms too, as its specification does lie outside of the scope of this PR 😄

All in all, this is some truly amazing modelling work! Let's make it even better ❤️

[xszymonzur]

Thank you for the review, I really do appreciate the feedback – your remarks are very useful and help me develop so please do point out when you see some space for improvement.

About the extension of health-checking and the #38, I’m currently away from home till 3rd April and am not sure whether I’ll be able to complete it before the 5th April, so let’s move it to some other PR if you don’t mind. I’d love to get onto it later though :).

[chgio]

Flawless; ready to merge.

All requested changes, even the more nitpicky ones, have been punctually addressed.
I've only added explicit level qualifiers to your scenario names for clarity, and atomised your requirements a little to make them more explicit about your original observations on relative timing: time between kicks shorter than reset period, time from boot to first kick shorter than reset period. So good!!

Give the CI its 10 minutes and then flex your deployment!