diff --git a/satrs-book/src/SUMMARY.md b/satrs-book/src/SUMMARY.md index 3fbc9f6..995e8a9 100644 --- a/satrs-book/src/SUMMARY.md +++ b/satrs-book/src/SUMMARY.md @@ -15,5 +15,5 @@ - [Serialization of Data](./serialization.md) - [Logging](./logging.md) - [Modelling space systems](./modelling-space-systems.md) -- [Ground Systems](./ground.md) +- [Ground Segments](./ground-segments.md) diff --git a/satrs-book/src/actions.md b/satrs-book/src/actions.md index 6ad9c39..0e092d9 100644 --- a/satrs-book/src/actions.md +++ b/satrs-book/src/actions.md @@ -1,7 +1,7 @@ # Working with Actions Space systems generally need to be commanded regularly. This can include commands periodically -required to ensure a health system, or commands to reach the mission goals. +required to ensure a healthy system, or commands to reach the mission goals. These commands can be modelled using the concept of Actions. the ECSS PUS standard also provides the PUS service 8 for actions, but provides few concrete subservices and specification on how diff --git a/satrs-book/src/communication.md b/satrs-book/src/communication.md index bcda520..1bb66a5 100644 --- a/satrs-book/src/communication.md +++ b/satrs-book/src/communication.md @@ -1,8 +1,8 @@ # Communication with sat-rs based software -Communication is a huge topic for space systems. They are usually not (directly) connected -to the internet and only have 1-2 communication links during nominal operation. However, most -of these systems have internet access during development cycle. There are various standards +Communication is a huge topic for space systems. Remote systems are usually not (directly) +connected to the internet and only have 1-2 communication links during nominal operation. However, +most of these systems have internet access during development cycle. There are various standards provided by CCSDS and ECSS which can be useful to determine how to communicate with the satellite and the primary On-Board Software. @@ -12,7 +12,7 @@ Most communication with space systems is usually packet based. For example, the packet standard only specifies a 6 byte header with at least 1 byte payload. The PUS packet standard is a subset of the space packet standard, which adds some fields and a 16 bit CRC, but it is still centered around small packets. `sat-rs` provides support for these ECSS and CCSDS -standards to also attempts to fill the gap to the internet protocol by providing the following +standards and also attempts to fill the gap to the internet protocol by providing the following components. 1. UDP TMTC Server. UDP is already packet based which makes it an excellent fit for exchanging @@ -41,6 +41,6 @@ layer covered by the PUS standard or the CCSDS space packets standard. This ofte special hardware like dedicated FPGAs to handle forward error correction fast enough. `sat-rs` might provide components to handle standard like the Unified Space Data Link Standard (USLP) in software but most of the time the handling of communication is performed through custom -software and hardware. Still, connecting this custom software and hardware can mostly be done -by using the concept of TC sources and TM sinks mentioned previously. +software and hardware. Still, connecting this custom software and hardware to `sat-rs` can mostly +be done by using the concept of TC sources and TM sinks mentioned previously. diff --git a/satrs-book/src/constrained-systems.md b/satrs-book/src/constrained-systems.md index a10619d..4dbdb7a 100644 --- a/satrs-book/src/constrained-systems.md +++ b/satrs-book/src/constrained-systems.md @@ -7,18 +7,19 @@ For these systems, the computation power and the available heap are the most imp which are constrained. This might make completeley heap based memory management schemes which are oftentimes used on host and server based systems unfeasable. Still, completely forbidding heap allocations might make software development unnecessarilly difficult, especially in a -time where the OBSW might be running on Linux based systems with 500 MB RAM. +time where the OBSW might be running on Linux based systems with hundreds of MBs of RAM. A useful pattern used commonly in space systems is to limit heap allocations to program initialization time and avoid frequent run-time allocations. This prevents issues like -running out of memory (something event Rust can not protect from) or heap fragmentation. +running out of memory (something even Rust can not protect from) or heap fragmentation. # Using pre-allocated pool structures A huge candidate for heap allocations is the TMTC and handling. TC, TMs and IPC data are all candidates where the data size might vary greatly. The regular solution for host systems might be to send around this data as a `Vec` until it is dropped. `sat-rs` provides -another solution to avoid run-time allocations by pre-allocated static pools. +another solution to avoid run-time allocations by offering and recommendng pre-allocated static +pools. These pools are split into subpools where each subpool can have different page sizes. For example, a very small TC pool might look like this: @@ -34,7 +35,7 @@ Another common way to use the heap on host systems is using containers like `Str to work with data where the size is not known beforehand. The most common solution for embedded systems is to determine the maximum expected size and then use a pre-allocated `u8` buffer and a size variable. Alternatively, you can use the following crates for more convenience or a smart -behaviour which at least reduced heap allocations: +behaviour which at the very least reduce heap allocations: 1. [`smallvec`](https://docs.rs/smallvec/latest/smallvec/). 2. [`arrayvec`](https://docs.rs/arrayvec/latest/arrayvec/index.html) which also contains an @@ -50,7 +51,7 @@ thread might use up the remaining heap of a system, leading to undeterministic e The most common way to avoid this is to simply spawn all required threads at program initialization time. If a thread is done with its task, it can go back to sleeping regularly, only occasionally -checking for new jobs. If a system still needs to handle burst concurrent loads, another possible +checking for new jobs. If a system still needs to handle bursty concurrent loads, another possible way commonly used for host systems as well would be to use a threadpool, for example by using the [`threadpool`](https://crates.io/crates/threadpool) crate. diff --git a/satrs-book/src/events.md b/satrs-book/src/events.md index 1f187df..083e76a 100644 --- a/satrs-book/src/events.md +++ b/satrs-book/src/events.md @@ -1 +1,16 @@ # Events + +Events can be an extremely important mechanism used for remote systems to monitor unexpected +or expected anomalies and events occuring on these systems. They are oftentimes tied to +Fault Detection, Isolation and Recovery (FDIR) operations, which need to happen autonomously. + +Events can also be used as a convenient Inter-Process Communication (IPC) mechansism, which is +also observable for the Ground segment. The PUS Service 5 standardizes how the ground interface +for events might look like, but does not specify how other software components might react +to those events. There is the PUS Service 19, which might be used for that purpose, but the +event components recommended by this framework do not really need this service. + +The following images shows how the flow of events could look like in a system where components +can generate events, and where other system components might be interested in those events: + +![Event flow](images/event_man_arch.png) diff --git a/satrs-book/src/fdir.md b/satrs-book/src/fdir.md index e69de29..074b2ad 100644 --- a/satrs-book/src/fdir.md +++ b/satrs-book/src/fdir.md @@ -0,0 +1 @@ +# Fault Detecion, Isolation And Recovery (FDIR) diff --git a/satrs-book/src/ground-segments.md b/satrs-book/src/ground-segments.md new file mode 100644 index 0000000..58672b2 --- /dev/null +++ b/satrs-book/src/ground-segments.md @@ -0,0 +1 @@ +# Ground Segments diff --git a/satrs-book/src/ground.md b/satrs-book/src/ground.md deleted file mode 100644 index e69de29..0000000 diff --git a/satrs-book/src/housekeeping.md b/satrs-book/src/housekeeping.md index af23140..5a7d73b 100644 --- a/satrs-book/src/housekeeping.md +++ b/satrs-book/src/housekeeping.md @@ -1 +1,24 @@ # Housekeeping Data + +Remote systems like satellites and rovers oftentimes generate data autonomously and periodically. +The most common example for this is temperature or attitude data. Data like this is commonly +referred to as housekeeping data, and is usually one of the most important and most resource heavy +data sources received from a satellite. Standards like the PUS Service 3 make recommendation how to +expose housekeeping data, but the applicability of the interface offered by PUS 3 has proven to be +partially difficult and clunky for modular systems. + +First, we are going to list some assumption and requirements about Housekeeping (HK) data: + +1. HK data is generated periodically by various system components throughout the + systems. +2. An autonomous and periodic sampling of that HK data to be stored and sent to Ground is generally + required. A minimum interface consists of requesting a one-shot sample of HK, enabling and + disabling the periodic autonomous generation of samples and modifying the collection interval + of the periodic autonomous generation. +3. HK data often needs to be shared to other software components. For example, a thermal controller + wants to read the data samples of all sensor components. + +A commonly required way to model HK data in a clean way is also to group related HK data into sets, +which can then dumped via a similar interface. + +TODO: Write down `sat-rs` recommendations how to expose and work with HK data. diff --git a/satrs-book/src/images/event_man_arch.graphml b/satrs-book/src/images/event_man_arch.graphml new file mode 100644 index 0000000..1336793 --- /dev/null +++ b/satrs-book/src/images/event_man_arch.graphml @@ -0,0 +1,259 @@ + + + + + + + + + + + + + + + + + + + + + + + Example Event Flow + + + + + + + + + + + Event Manager + + + + + + + + + + + Event +Creator 0 + + + + + + + + + + + Event +Creator 2 + + + + + + + + + + + Event +Creator 1 + + + + + + + + + + + Event +Creator 3 + + + + + + + + + + + PUS Service 5 +Event Reporting + + + + + + + + + + + + PUS Service 19 +Event Action + + + + + + + + + + + Telemetry +Sink + + + + + + + + + + + Subscriptions + +1. Event Creator 0 subscribes + for event 0 +2. Event Creator 1 subscribes + for event group 2 +3. PUS Service 5 handler + subscribes for all events +4. PUS Service 19 handler + subscribes for all events + + + + + + + + + + + event 1 +(group 1) + + + + + + + + + + + + + event 0 +(group 0) + + + + + + + + + + + event 2 +(group 3) + + + + + + + + + + + + + event 3 (group 2) +event 4 (group 2) + + + + + + + + + + + <<all events>> + + + + + + + + + + + <<all events>> + + + + + + + + + + + + + event 1 +event 2 + + + + + + + + + + + group 2 + + + + + + + + + + + enabled Events +as PUS 5 TM + + + + + + + + + diff --git a/satrs-book/src/images/event_man_arch.png b/satrs-book/src/images/event_man_arch.png new file mode 100644 index 0000000..61c8d72 Binary files /dev/null and b/satrs-book/src/images/event_man_arch.png differ diff --git a/satrs-book/src/modelling-space-systems.md b/satrs-book/src/modelling-space-systems.md index e69de29..c42d084 100644 --- a/satrs-book/src/modelling-space-systems.md +++ b/satrs-book/src/modelling-space-systems.md @@ -0,0 +1 @@ +# Modelling Space Systems diff --git a/satrs-book/src/persistent-tm-storage.md b/satrs-book/src/persistent-tm-storage.md index 08b20d9..77d4f50 100644 --- a/satrs-book/src/persistent-tm-storage.md +++ b/satrs-book/src/persistent-tm-storage.md @@ -1 +1 @@ -# Persistent TM storage +# Persistent Telemetry (TM) Storage diff --git a/satrs-book/src/power.md b/satrs-book/src/power.md index e69de29..b1ae539 100644 --- a/satrs-book/src/power.md +++ b/satrs-book/src/power.md @@ -0,0 +1 @@ +# Power Components diff --git a/satrs-book/src/thermal.md b/satrs-book/src/thermal.md index e69de29..abcbb57 100644 --- a/satrs-book/src/thermal.md +++ b/satrs-book/src/thermal.md @@ -0,0 +1 @@ +# Thermal Components