Deadline monitor implementation #41

pawelrutkaq · 2026-01-20T09:50:14Z

No protected memory implementation yet, but a small infrastructure has been prepared
#![allow(dead_code)] needed until there is no consumer of API

Closes #12

github-actions · 2026-01-20T09:51:14Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
2026/01/22 12:42:08 Downloading https://releases.bazel.build/8.4.2/release/bazel-8.4.2-linux-x86_64...
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 6b93d569-9b2c-43c4-811f-15dc5afff256
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'rust_qnx8_toolchain+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-eQOopREOYCL5vtTb6c1cwZrql4GVrJ1FqgxarQRe1xs="
DEBUG: Repository rust_qnx8_toolchain+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 2 packages loaded
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)

Analyzing: target //:license-check (33 packages loaded, 10 targets configured)

Analyzing: target //:license-check (89 packages loaded, 10 targets configured)

Analyzing: target //:license-check (139 packages loaded, 2489 targets configured)

Analyzing: target //:license-check (148 packages loaded, 4389 targets configured)

Analyzing: target //:license-check (152 packages loaded, 7396 targets configured)

Analyzing: target //:license-check (152 packages loaded, 7396 targets configured)

Analyzing: target //:license-check (152 packages loaded, 7396 targets configured)

Analyzing: target //:license-check (162 packages loaded, 13688 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 13697 targets configured).
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 25.623s, Critical Path: 0.37s
INFO: 13 processes: 4 disk cache hit, 9 internal.
INFO: Build completed successfully, 13 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

github-actions · 2026-01-20T09:52:48Z

The created documentation from the pull request is available at: docu-html

NicolasFussberger · 2026-01-20T14:43:22Z

src/health_monitoring_lib/src/deadline/deadline_monitor.rs

+        match possible_err {
+            PossibleError::None => {},
+            PossibleError::TooEarly => {
+                error!("Deadline {:?} stopped too early", self.tag);


I think it might be helpful if we can also log here by who much the deadline was missed.
Something like:

Deadline xy stopped 5ms too early
Deadline xy stopped 5ms too late

This would be very useful when investigating why supervision failed.

NicolasFussberger · 2026-01-20T14:45:46Z

src/health_monitoring_lib/src/deadline/deadline_state.rs

+        (self.0 & DEADLINE_STATE_FINISHED_TOO_EARLY) != 0
+    }
+
+    pub(super) fn timestamp(&self) -> u32 {


I think it would be helpful to include somewhere the unit of this timestamp. Either in documentation or in naming of the variable/method itself (e.g. timestamp_ms or similar).
Reading the code I am not really sure is this a timestamp in ms or ns.

Similarly, only from other code I can infer that this is actually the absolute timestamp of the max deadline. But from the naming this does not become clear to me.

NicolasFussberger · 2026-01-20T14:48:18Z

src/health_monitoring_lib/src/deadline/deadline_state.rs

+const DEADLINE_STATE_RUNNING: u64 = 0b0000_0010;
+const DEADLINE_STATE_STOPPED: u64 = 0b0000_0001;
+const DEADLINE_STATE_FINISHED_TOO_EARLY: u64 = 0b0000_1000;
+


Out of curiosity, what is the motivation for these bitmasks compared to using for example regular attributes for timestamp and state (e.g. running, stopped, etc)?
Is it about concurrency to only need to update single value or about saving a few bytes?

I was also wondering what is the motivation for constraining the timestamp to u32

To make a simple algorithm lock-free, we have to fit into 64bits. Then value and state are consistent, and doing it with spsc fashion is simple. Can also be done differently, but this pattern normally works well, and the whole code uses abstraction on top of it so you don't see all this nesty bit manipulation at the end.

For timestamp being u32 as written in code, it will cover ~~49days (we use offsetting and not real unix timestamp). I don't expect we need to support longer power cycles. The motivation is the same, you need to make room in 64bit value. However, we can always increase since there are still a few bits left.

I suppose 49days would be enough, but it might be worth validating that with the other members of the group. Maybe there could be some use case were the system is only going into a low-power mode but never really shut off completely.

Would it be possible to use u128 for the state instead, so we could use u64 for the timestamp? That should be enough for all use cases

It may be used, but i woud still tend to keep it 64 and just instead 32 bytes use 50 bytes which would till end of the world (35k years?). I would say we can check this in CFT and i can update i follow ups if its okey.

NicolasFussberger · 2026-01-20T14:57:30Z

src/health_monitoring_lib/src/deadline/deadline_monitor.rs

+        u32::try_from(duration.as_millis()).expect("Monitor running for too long")
+    }
+
+    fn evaluate(&self, mut on_failed: impl FnMut(&IdentTag, bool)) {


I wonder if code readability would be improved by encoding the failure modes too early / too late as an enum or similar instead of encoding this as true/false when calling on_failed

NicolasFussberger

I did a first review. Though it might be better to get another review from someone with deeper Rust experience.

Cargo.toml

src/health_monitoring_lib/src/deadline/common.rs

arkjedrz · 2026-01-21T10:37:44Z

src/health_monitoring_lib/src/protected_memory.rs

+//
+// SPDX-License-Identifier: Apache-2.0
+//
+#![allow(dead_code)]


Move allow to ProtectedMemoryAllocator? I mean - make it struct-wide, not module-wide.

I will leave it, soon there will be examples and i will remove it

arkjedrz · 2026-01-21T10:39:57Z

src/health_monitoring_lib/src/log.rs

+pub(crate) use {debug, error, fatal, info, trace, warning as warn};
+
+// Re-export symbols from `score_log`.
+pub(crate) use score_log::fmt::Error;


Weird formatting:

pub(crate) use score_log::fmt::{Error, FormatSpec, ScoreDebug, Writer, DebugStruct}; pub(crate) use score_log::ScoreDebug;

auto formatted but fixed

arkjedrz · 2026-01-21T11:19:09Z

src/health_monitoring_lib/src/deadline/deadline_monitor.rs

+
+/// Errors that can occur when working with Deadline instances
+#[derive(Debug, PartialEq, ScoreDebug, Eq, Clone, Copy, Hash)]
+pub enum DeadlineErrors {


Consistency -> DeadlineError.
BTW I'd merge all errors of this component into shared type.

The problem is that then you have to match cases that do not exist. In this particular usecase I tihnk its better to have them separate.

- Deadline API in Rust - usage fo score_log

pawelrutkaq · 2026-01-21T13:38:11Z

@NicolasFussberger @arkjedrz done

arkjedrz · 2026-01-21T13:52:13Z

src/launch_manager_daemon/health_monitor_lib/src/score/lcm/saf/daemon/PhmDaemon.cpp

 PhmDaemon::PhmDaemon(score::lcm::saf::timers::OsClockInterface& f_osClock, logging::PhmLogger& f_logger_r,
                     std::unique_ptr<watchdog::IWatchdogIf> f_watchdog, std::unique_ptr<score::lcm::IProcessStateReceiver> f_process_state_receiver) :
-    osClock{f_osClock}, cycleTimer{&osClock}, logger_r{f_logger_r}, swClusterHandlers{}, watchdog(std::move(f_watchdog)), processStateReader{std::move(f_process_state_receiver)}
+    osClock{f_osClock}, cycleTimer{&osClock}, logger_r{f_logger_r}, swClusterHandlers{}, processStateReader{std::move(f_process_state_receiver)}, watchdog(std::move(f_watchdog))


Rebase leftover?

No, fixes issues introduced on master ;]

eelcoem · 2026-01-21T08:43:20Z

src/health_monitoring_lib/src/deadline/deadline_state.rs

+    /// The closure receives the current state snapshot and should return
+    /// an Option with the new state snapshot. If None is returned, the state
+    /// is not updated.
+    pub(super) fn update<F: FnMut(DeadlineStateSnapshot) -> Option<DeadlineStateSnapshot>>(


Could you add a test for this function?

eelcoem · 2026-01-22T07:43:17Z

src/health_monitoring_lib/src/deadline/deadline_state.rs

+const DEADLINE_STATE_RUNNING: u64 = 0b0000_0010;
+const DEADLINE_STATE_STOPPED: u64 = 0b0000_0001;
+const DEADLINE_STATE_FINISHED_TOO_EARLY: u64 = 0b0000_1000;
+


Would it be possible to use u128 for the state instead, so we could use u64 for the timestamp? That should be enough for all use cases

pawelrutkaq temporarily deployed to workflow-approval January 20, 2026 09:50 — with GitHub Actions Inactive

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor branch from 5027d80 to 9d36a69 Compare January 20, 2026 10:03

pawelrutkaq temporarily deployed to workflow-approval January 20, 2026 10:03 — with GitHub Actions Inactive

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor branch from 9d36a69 to d48a7c6 Compare January 20, 2026 10:07

pawelrutkaq temporarily deployed to workflow-approval January 20, 2026 10:08 — with GitHub Actions Inactive

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor branch from d48a7c6 to c10992a Compare January 20, 2026 11:28

pawelrutkaq temporarily deployed to workflow-approval January 20, 2026 11:28 — with GitHub Actions Inactive

NicolasFussberger reviewed Jan 20, 2026

View reviewed changes

NicolasFussberger suggested changes Jan 21, 2026

View reviewed changes

arkjedrz reviewed Jan 21, 2026

View reviewed changes

pawelrutkaq temporarily deployed to workflow-approval January 21, 2026 12:47 — with GitHub Actions Inactive

pawelrutkaq added 2 commits January 21, 2026 13:48

Initial version

c421b3b

DeadlineMonitor: Introduce impl for DeadlineMonitoring

3ffe3d2

- Deadline API in Rust - usage fo score_log

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor branch from 912137d to 6868928 Compare January 21, 2026 12:49

pawelrutkaq temporarily deployed to workflow-approval January 21, 2026 12:49 — with GitHub Actions Inactive

Apply review comments

f1c0de9

pawelrutkaq force-pushed the pawelrutkaq_deadline_monitor branch from 6868928 to f1c0de9 Compare January 21, 2026 12:58

pawelrutkaq temporarily deployed to workflow-approval January 21, 2026 12:58 — with GitHub Actions Inactive

Fix PhmDaemon init list order issue

feded75

pawelrutkaq temporarily deployed to workflow-approval January 21, 2026 13:06 — with GitHub Actions Inactive

pawelrutkaq requested review from NicolasFussberger and arkjedrz January 21, 2026 13:37

arkjedrz reviewed Jan 21, 2026

View reviewed changes

NicolasFussberger approved these changes Jan 21, 2026

View reviewed changes

eelcoem reviewed Jan 22, 2026

View reviewed changes

arkjedrz approved these changes Jan 22, 2026

View reviewed changes

Add DeadlineState UT

27461da

pawelrutkaq temporarily deployed to workflow-approval January 22, 2026 12:41 — with GitHub Actions Inactive

pawelrutkaq requested a review from eelcoem January 22, 2026 12:41

eelcoem approved these changes Jan 22, 2026

View reviewed changes

PiotrKorkus approved these changes Jan 22, 2026

View reviewed changes

pawelrutkaq merged commit 8a7b418 into eclipse-score:main Jan 22, 2026
11 checks passed

Deadline monitor implementation #41

Deadline monitor implementation #41

Uh oh!

Conversation

pawelrutkaq commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

github-actions bot commented Jan 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NicolasFussberger left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

pawelrutkaq commented Jan 20, 2026 •

edited

Loading

github-actions bot commented Jan 20, 2026 •

edited

Loading