WIP: Mode Tree #130

muellerr · 2024-02-21T17:47:55+01:00

muellerr commented

2024-02-21 17:47:55 +01:00

Issue: #15

The mode tree components generally consist of three abstraction/problem groups:

Mode Tree Specification and abstractions. It appears this is all about offering a good API for creating a network of mode messaging channels.
Mode Table abstraction. I will start simple here with a concrete implementation based on a HashMap, and work from there.
Mode Sequence abstraction. Same as 2, but with a different purpose. Probably the same data structure, that's how it was done in the FSFW.

Issue: https://egit.irs.uni-stuttgart.de/rust/sat-rs/issues/15 The mode tree components generally consist of three abstraction/problem groups: 1. Mode Tree Specification and abstractions. It appears this is all about offering a good API for creating a network of mode messaging channels. 2. Mode Table abstraction. I will start simple here with a concrete implementation based on a HashMap, and work from there. 3. Mode Sequence abstraction. Same as 2, but with a different purpose. Probably the same data structure, that's how it was done in the FSFW.

muellerr added 2 commits 2024-02-21 17:47:55 +01:00

as expected, this is hard

Rust/sat-rs/pipeline/head There was a failure building this commit

Details

bfedd9572e

lets just push through with one concrete example

Rust/sat-rs/pipeline/head There was a failure building this commit

Details

0bd492038d

and work from there

muellerr added 1 commit 2024-02-21 19:16:39 +01:00

slowly starting to understand this

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

28523e065f

muellerr added 1 commit 2024-02-21 19:17:19 +01:00

Merge branch 'main' into mode-tree-init

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

a3bae58ef3

muellerr added 4 commits 2024-02-22 17:20:49 +01:00

introducing more generics 69b441cd39

this is not easy 7967b95553

that was hard e7c0d33ccb

Merge branch 'mode-tree-init' of egit.irs.uni-stuttgart.de:rust/sat-rs into mode-tree-init a354f8a76c

muellerr added 1 commit 2024-02-22 17:31:24 +01:00

sync channel now works as well 508561d791

muellerr added 1 commit 2024-02-22 17:37:34 +01:00

move test code to dedicated integration test module f285095488

muellerr added 1 commit 2024-02-22 17:46:07 +01:00

this is okay for now

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

0331b04619

muellerr added 1 commit 2024-02-23 14:00:11 +01:00

cargo fmt

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

f088807652

muellerr added 1 commit 2024-02-23 14:32:20 +01:00

Merge remote-tracking branch 'origin/main' into mode-tree-init

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

2949280c20

muellerr added 1 commit 2024-02-23 14:38:34 +01:00

fix CI

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

fdcf1146ec

muellerr added this to the satrs-v0.2.0-rc.0 milestone 2024-02-23 14:39:12 +01:00

muellerr modified the milestone from satrs-v0.2.0-rc.0 to satrs-v0.2.0-rc.1

2024-02-23 14:39:57 +01:00

muellerr added 1 commit 2024-02-23 17:45:41 +01:00

cargo fmt

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

07cd370667

muellerr commented

2024-02-23 17:49:35 +01:00

Actually, some of the changes and new features introduced here should be applied to other problem domains like Actions or HK as well. This includes a reply scheme because now every request has to be one that is acknowledged and needs explicit generation of verification telemetry.

In that sense, we still require something similar to the commanding service base, where active requests are tracked and which performs the full verification completion so that the end consumers of these requests don't need to worry about that as well. Incidentally, we can probably decouple those end consumers from PUS1 completely, which is probably better from an architecture point of view. I'd like to still have some way to report step success/failures for actions specifically, but special consideration for the ActionRequest should do the job as well.

Actually, some of the changes and new features introduced here should be applied to other problem domains like Actions or HK as well. This includes a reply scheme because now every request has to be one that is acknowledged and needs explicit generation of verification telemetry. In that sense, we still require something similar to the commanding service base, where active requests are tracked and which performs the full verification completion so that the end consumers of these requests don't need to worry about that as well. Incidentally, we can probably decouple those end consumers from PUS1 completely, which is probably better from an architecture point of view. I'd like to still have some way to report step success/failures for actions specifically, but special consideration for the ActionRequest should do the job as well.

muellerr added 1 commit 2024-02-26 12:09:28 +01:00

Merge remote-tracking branch 'origin/main' into mode-tree-init

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

b706dec643

muellerr added 1 commit 2024-02-26 17:29:07 +01:00

Merge remote-tracking branch 'origin/main' into mode-tree-init

Rust/sat-rs/pipeline/pr-main There was a failure building this commit

Details

300bc660b1

muellerr added 7 commits 2024-02-28 11:05:52 +01:00

this is just REALLY annoying..