update book

images/satrs-example-dataflow/satrs-example-dataflowe.graphml

@@ -1,21 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:java="http://www.yworks.com/xml/yfiles-common/1.0/java" xmlns:sys="http://www.yworks.com/xml/yfiles-common/markup/primitives/2.0" xmlns:x="http://www.yworks.com/xml/yfiles-common/markup/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.yworks.com/xml/graphml" xmlns:yed="http://www.yworks.com/xml/yed/3" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns http://www.yworks.com/xml/schema/graphml/1.1/ygraphml.xsd">
-  <!--Created by yEd 3.23.2-->
-  <key attr.name="Description" attr.type="string" for="graph" id="d0"/>
-  <key for="port" id="d1" yfiles.type="portgraphics"/>
-  <key for="port" id="d2" yfiles.type="portgeometry"/>
-  <key for="port" id="d3" yfiles.type="portuserdata"/>
-  <key attr.name="url" attr.type="string" for="node" id="d4"/>
-  <key attr.name="description" attr.type="string" for="node" id="d5"/>
-  <key for="node" id="d6" yfiles.type="nodegraphics"/>
-  <key for="graphml" id="d7" yfiles.type="resources"/>
-  <key attr.name="url" attr.type="string" for="edge" id="d8"/>
-  <key attr.name="description" attr.type="string" for="edge" id="d9"/>
-  <key for="edge" id="d10" yfiles.type="edgegraphics"/>
-  <graph edgedefault="directed" id="G">
-    <data key="d0"/>
-  </graph>
-  <data key="d7">
-    <y:Resources/>
-  </data>
-</graphml>

satrs-book/src/example.md

@@ -9,22 +9,54 @@ software application.
 ## Structure of the example project
 
 The example project contains components which could also be expected to be part of a production
-On-Board Software.
+On-Board Software. A structural diagram of the example application is given to provide
+a brief high-level view of the components used inside the example application:
 
-1. A UDP and TCP server to receive telecommands and poll telemetry from. This might be an optional
-   component for an OBSW which is only used during the development phase on ground. The TCP
-   server parses space packets by using the CCSDS space packet ID as the packet start delimiter.
-2. A PUS service stack which exposes some functionality conformant with the ECSS PUS service. This
-   currently includes the following services:
-   - Service 1 for telecommand verification.
-   - Service 3 for housekeeping telemetry handling.
-   - Service 5 for management and downlink of on-board events.
-   - Service 8 for handling on-board actions.
-   - Service 11 for scheduling telecommands to be released at a specific time.
-   - Service 17 for test purposes (pings)
-3. An event manager component which handles the event IPC mechanism.
-4. A TC source component which demultiplexes and routes telecommands based on parameters like
-   packet APID or PUS service and subservice type.
-5. A TM sink sink component which is the target of all sent telemetry and sends it to downlink
+![satrs-example component structure](images/satrs-example/satrs-example-structure.png)
+
+Some additional explanation is provided for the various components:
+
+### TCP/IP server components
+
+The example includes a UDP and TCP server to receive telecommands and poll telemetry from. This
+might be an optional component for an OBSW which is only used during the development phase on
+ground. The TCP server parses space packets by using the CCSDS space packet ID as the packet
+start delimiter.
+
+### PUS Service Components
+
+A PUS service stack is provided which exposes some functionality conformant with the ECSS PUS
+service. This currently includes the following services:
+
+- Service 1 for telecommand verification.
+- Service 3 for housekeeping telemetry handling.
+- Service 5 for management and downlink of on-board events.
+- Service 8 for handling on-board actions.
+- Service 11 for scheduling telecommands to be released at a specific time.
+- Service 17 for test purposes (pings)
+
+### Event Management Component
+
+An event manager is provided to handle the event IPC and FDIR mechanism.
+
+### TMTC Infrastructure
+
+The most important components of the TMTC infrastructure include the following components:
+
+- A TC source component which demultiplexes and routes telecommands based on parameters like
+  packet APID or PUS service and subservice type.
+- A TM sink sink component which is the target of all sent telemetry and sends it to downlink
    handlers like the UDP and TCP server.
-6. An AOCS example task which can also process some PUS commands.
+
+### Sample Application Components
+
+These components are example mission specific. They provide an idea how mission specific modules
+would look like the sat-rs context. It currently includes the following components:
+
+- An Attitute and Orbit Control (AOCS) example task which can also process some PUS commands.
+
+## Dataflow
+
+The interaction of the various components is provided in the following diagram:
+
+![satrs-example dataflow diagram](images/satrs-example/satrs-example-dataflow.png)