finishing up
Some checks failed
Rust/sat-rs/pipeline/pr-main There was a failure building this commit
Some checks failed
Rust/sat-rs/pipeline/pr-main There was a failure building this commit
This commit is contained in:
parent
1bbb37479a
commit
9d3b7ab8af
GPG Key ID:
A649FB78196E3849
@ -601,7 +601,7 @@ Components<y:LabelModel><y:SmartNodeLabelModel distance="5.0"/></y:LabelModel><y
|
||||
<node id="n7">
|
||||
<data key="d6">
|
||||
<y:ShapeNode>
|
||||
<y:Geometry height="40.0" width="120.0" x="896.8787000000008" y="629.3055312499998"/>
|
||||
<y:Geometry height="40.0" width="120.0" x="896.8787000000008" y="621.6432750000002"/>
|
||||
<y:Fill hasColor="false" transparent="false"/>
|
||||
<y:BorderStyle color="#000000" raised="false" type="dashed" width="1.0"/>
|
||||
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="14" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="36.59375" horizontalTextPosition="center" iconTextGap="4" modelName="custom" textColor="#000000" verticalTextPosition="bottom" visible="true" width="84.1650390625" x="17.91748046875" xml:space="preserve" y="1.703125">Shared
|
||||
@ -671,7 +671,7 @@ Diagram<y:LabelModel><y:SmartNodeLabelModel distance="4.0"/></y:LabelModel><y:Mo
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
|
||||
<y:LineStyle color="#008000" type="line" width="2.0"/>
|
||||
<y:Arrows source="standard" target="standard"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:EdgeLabel alignment="center" configuration="AutoFlippingLabel" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" horizontalTextPosition="center" iconTextGap="4" modelName="custom" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" verticalTextPosition="bottom" visible="true" width="4.0" x="27.999983203125566" y="-22.719979003906246">
|
||||
<y:LabelModel>
|
||||
<y:SmartEdgeLabelModel autoRotationEnabled="false" defaultAngle="0.0" defaultDistance="10.0"/>
|
||||
@ -690,7 +690,7 @@ Diagram<y:LabelModel><y:SmartNodeLabelModel distance="4.0"/></y:LabelModel><y:Mo
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="5.000000000000227" sy="0.0" tx="0.0" ty="0.0"/>
|
||||
<y:LineStyle color="#008000" type="line" width="2.0"/>
|
||||
<y:Arrows source="standard" target="standard"/>
|
||||
<y:Arrows source="standard" target="none"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
</y:PolyLineEdge>
|
||||
</data>
|
||||
@ -698,12 +698,12 @@ Diagram<y:LabelModel><y:SmartNodeLabelModel distance="4.0"/></y:LabelModel><y:Mo
|
||||
<edge id="n4::e2" source="n4::n0" target="n4::n1">
|
||||
<data key="d10">
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="1.470468750000009">
|
||||
<y:Point x="1112.3347000000008" y="839.58553125"/>
|
||||
<y:Point x="962.3347000000007" y="839.58553125"/>
|
||||
<y:Path sx="0.0" sy="0.0" tx="27.85279999999989" ty="1.470468750000009">
|
||||
<y:Point x="1112.3347000000008" y="829.09977125"/>
|
||||
<y:Point x="990.1875000000006" y="829.09977125"/>
|
||||
</y:Path>
|
||||
<y:LineStyle color="#008000" type="line" width="2.0"/>
|
||||
<y:Arrows source="standard" target="standard"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
</y:PolyLineEdge>
|
||||
</data>
|
||||
@ -711,12 +711,12 @@ Diagram<y:LabelModel><y:SmartNodeLabelModel distance="4.0"/></y:LabelModel><y:Mo
|
||||
<edge id="n4::e3" source="n4::n3" target="n4::n2">
|
||||
<data key="d10">
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="0.0" sy="0.0" tx="5.000000000000227" ty="3.7001374999999825">
|
||||
<y:Path sx="0.0" sy="0.0" tx="-16.954559999999674" ty="3.7001374999999825">
|
||||
<y:Point x="962.3347000000007" y="839.58553125"/>
|
||||
<y:Point x="1112.3347000000008" y="839.58553125"/>
|
||||
<y:Point x="1090.380140000001" y="839.58553125"/>
|
||||
</y:Path>
|
||||
<y:LineStyle color="#008000" type="line" width="2.0"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:Arrows source="standard" target="none"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
</y:PolyLineEdge>
|
||||
</data>
|
||||
@ -803,7 +803,7 @@ Interface<y:LabelModel><y:SmartEdgeLabelModel autoRotationEnabled="false" defaul
|
||||
<edge id="e4" source="n4::n4" target="n2">
|
||||
<data key="d10">
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="0.0" sy="-5.049743750000289" tx="-82.89626674268379" ty="-29.959999999999923"/>
|
||||
<y:Path sx="0.0" sy="-0.049743750000288856" tx="-82.89626674268379" ty="-24.959999999999923"/>
|
||||
<y:LineStyle color="#008000" type="line" width="2.0"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
@ -851,7 +851,7 @@ Interface<y:LabelModel><y:SmartEdgeLabelModel autoRotationEnabled="false" defaul
|
||||
<y:Path sx="39.02668799999979" sy="0.0" tx="0.0" ty="-8.276800000000094">
|
||||
<y:Point x="1133.0173880000004" y="750.2109874999995"/>
|
||||
</y:Path>
|
||||
<y:LineStyle color="#008000" type="line" width="2.0"/>
|
||||
<y:LineStyle color="#993300" type="line" width="2.0"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
</y:PolyLineEdge>
|
||||
@ -860,7 +860,7 @@ Interface<y:LabelModel><y:SmartEdgeLabelModel autoRotationEnabled="false" defaul
|
||||
<edge id="e8" source="n3" target="n7">
|
||||
<data key="d10">
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="0.0" sy="-30.590468750000355" tx="0.0" ty="5.414096874999586"/>
|
||||
<y:Path sx="0.0" sy="-38.78246875000036" tx="0.0" ty="4.884353124999166"/>
|
||||
<y:LineStyle color="#FF6600" type="line" width="2.0"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
@ -959,6 +959,31 @@ Messages<y:LabelModel><y:SmartEdgeLabelModel autoRotationEnabled="false" default
|
||||
</y:PolyLineEdge>
|
||||
</data>
|
||||
</edge>
|
||||
<edge id="e15" source="n4::n4" target="n2::n5">
|
||||
<data key="d9"/>
|
||||
<data key="d10">
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="0.0" sy="-7.129743750000216" tx="0.0" ty="-0.10225624999964111">
|
||||
<y:Point x="1112.3347000000008" y="731.4077874999997"/>
|
||||
<y:Point x="1112.3347000000008" y="675.7055312499999"/>
|
||||
</y:Path>
|
||||
<y:LineStyle color="#FF6600" type="line" width="2.0"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
</y:PolyLineEdge>
|
||||
</data>
|
||||
</edge>
|
||||
<edge id="e16" source="n4" target="n7">
|
||||
<data key="d9"/>
|
||||
<data key="d10">
|
||||
<y:PolyLineEdge>
|
||||
<y:Path sx="-80.61839999999995" sy="0.0" tx="0.0" ty="0.0"/>
|
||||
<y:LineStyle color="#FF6600" type="line" width="2.0"/>
|
||||
<y:Arrows source="none" target="standard"/>
|
||||
<y:BendStyle smoothed="false"/>
|
||||
</y:PolyLineEdge>
|
||||
</data>
|
||||
</edge>
|
||||
</graph>
|
||||
<data key="d7">
|
||||
<y:Resources/>
|
||||
|
||||
@ -5,4 +5,5 @@ multilingual = false
|
||||
src = "src"
|
||||
title = "The sat-rs book"
|
||||
|
||||
[output.html]
|
||||
[output.linkcheck]
|
||||
|
||||
@ -18,7 +18,7 @@ running out of memory (something even Rust can not protect from) or heap fragmen
|
||||
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<u8>` until it is dropped. `sat-rs` provides
|
||||
another solution to avoid run-time allocations by offering and recommendng pre-allocated static
|
||||
another solution to avoid run-time allocations by offering pre-allocated static
|
||||
pools.
|
||||
|
||||
These pools are split into subpools where each subpool can have different page sizes.
|
||||
|
||||
@ -14,7 +14,9 @@ a brief high-level view of the components used inside the example application:
|
||||
|
||||
|
||||
|
||||
Some additional explanation is provided for the various components:
|
||||
The dotted lines are used to denote optional components. In this case, the static pool components
|
||||
are optional because the heap can be used as a simpler mechanism to store TMTC packets as well.
|
||||
Some additional explanation is provided for the various components.
|
||||
|
||||
### TCP/IP server components
|
||||
|
||||
@ -40,12 +42,12 @@ The most important components of the TMTC infrastructure include the following c
|
||||
handlers like the UDP and TCP server.
|
||||
|
||||
You can read the [Communications chapter](./communication.md) for more
|
||||
background information on the chose TMTC infrastructure approach.
|
||||
background information on the chosen TMTC infrastructure approach.
|
||||
|
||||
### 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:
|
||||
services. This currently includes the following services:
|
||||
|
||||
- Service 1 for telecommand verification. The verification handling is handled locally: Each
|
||||
component which generates verification telemetry in some shape or form receives a
|
||||
@ -57,7 +59,7 @@ service. This currently includes the following services:
|
||||
- Service 11 for scheduling telecommands to be released at a specific time. This component
|
||||
uses the [PUS scheduler class](https://docs.rs/satrs-core/0.1.0-alpha.1/satrs_core/pus/scheduler/alloc_mod/struct.PusScheduler.html)
|
||||
which performs the core logic of scheduling telecommands. All telecommands released by the
|
||||
scheduler are sent to the central TC source via a message.
|
||||
scheduler are sent to the central TC source using a message.
|
||||
- Service 17 for test purposes like pings.
|
||||
|
||||
### Event Management Component
|
||||
@ -68,7 +70,7 @@ is provided to handle the event IPC and FDIR mechanism. The event message are co
|
||||
telemetry by the
|
||||
[PUS event dispatcher](https://docs.rs/satrs-core/0.1.0-alpha.1/satrs_core/pus/event_man/alloc_mod/struct.PusEventDispatcher.html).
|
||||
|
||||
You can read the [events](#events) chapter for more in-depth information about event management.
|
||||
You can read the [events](./events.md) chapter for more in-depth information about event management.
|
||||
|
||||
### Sample Application Components
|
||||
|
||||
@ -83,7 +85,8 @@ The interaction of the various components is provided in the following diagram:
|
||||
|
||||
|
||||
|
||||
An explanation for important component groups will be given
|
||||
It should be noted that an arrow coming out of a component group refers to multiple components
|
||||
in that group. An explanation for important component groups will be given.
|
||||
|
||||
#### TMTC component group
|
||||
|
||||
@ -94,17 +97,56 @@ In the future, this might be extended with the
|
||||
[CCSDS File Delivery Protocol](https://public.ccsds.org/Pubs/727x0b5.pdf).
|
||||
|
||||
A client can connect to the UDP or TCP server to send these PUS packets to the on-board software.
|
||||
These servers then forwards the telecommads to a centralized TC source component using a PUS TC
|
||||
message.
|
||||
These servers then forward the telecommads to a centralized TC source component using a dedicated
|
||||
message abstraction.
|
||||
|
||||
This TC source component then demultiplexes the message and forwards it to the relevant component.
|
||||
Right now, it forwards all PUS requests to the respective PUS service handlers, which run in a
|
||||
separate thread. In the future, additional forwarding to components like a CFDP handler might be
|
||||
added as well.
|
||||
This TC source component then demultiplexes the message and forwards it to the relevant components.
|
||||
Right now, it forwards all PUS requests to the respective PUS service handlers using the PUS
|
||||
receiver component. The individual PUS services are running in a separate thread. In the future,
|
||||
additional forwarding to components like a CFDP handler might be added as well. It should be noted
|
||||
that PUS11 commands might contain other PUS commands which should be scheduled in the future.
|
||||
These wrapped commands are forwarded to the PUS11 handler. When the schedule releases those
|
||||
commands, it forwards the released commands to the TC source again. This allows the scheduler
|
||||
and the TC source to run in separate threads and keeps them cleanly separated.
|
||||
|
||||
All telemetry generated by the on-board software is sent to a centralized TM funnel. This component
|
||||
also performs a demultiplexing step to forward all telemetry to the relevant TM recipients.
|
||||
In the example case, this is the last UDP client, or a connected TCP client. In the future,
|
||||
a forwarding to a persistent telemetry store and a simulated communication component might be
|
||||
forwarding to a persistent telemetry store and a simulated communication component might be
|
||||
added here as well. The centralized TM funnel also takes care of some packet processing steps which
|
||||
need to be applied for each ECSS PUS packet.
|
||||
need to be applied for each ECSS PUS packet, for example CCSDS specific APID incrementation and
|
||||
PUS specific message counter incrementation.
|
||||
|
||||
#### Application Group
|
||||
|
||||
The application components generally do not receive raw PUS packets directly, even though
|
||||
this is certainly possible. Instead, they receive internalized messages from the PUS service
|
||||
handlers. For example, instead of receiving a PUS 8 Action Telecommand directly, an application
|
||||
component will receive a special `ActionRequest` message type reduced to the basic important
|
||||
information required to execute a request. These special requests are denoted by the blue arrow
|
||||
in the diagram.
|
||||
|
||||
It should be noted that the arrow pointing towards the event manager points in both directions.
|
||||
This is because the application components might be interested in events generated by other
|
||||
components as well. This mechanism is oftentimes used to implement the FDIR functionality on system
|
||||
and component level.
|
||||
|
||||
#### Shared components and functional interfaces
|
||||
|
||||
It should be noted that sometimes, a functional interface is used instead of a message. This
|
||||
is used for the generation of verification telemetry. The verification reporter is a clonable
|
||||
component which generates and sends PUS1 verification telemetry directly to the TM funnel. This
|
||||
introduces a loose coupling to the PUS standard but was considered the easiest solution for
|
||||
a project which utilizes PUS as the main communication protocol. In the future, a generic
|
||||
verification abstraction might be introduced to completely decouple the application layer from
|
||||
PUS.
|
||||
|
||||
The same concept is applied if the backing store of TMTC packets are shared pools. Every
|
||||
component which needs to read telecommands inside that shared pool or generate new telemetry
|
||||
into that shared pool will received a clonable shared handle to that pool.
|
||||
|
||||
The same concept could be extended to power or thermal handling. For example, a shared power helper
|
||||
component might be used to retrieve power state information and send power switch commands through
|
||||
a functional interface. The actual implementation of the functional interface might still use
|
||||
shared memory and/or messages, but the functional interface makes using and testing the interaction
|
||||
with these components easier.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 250 KiB After Width: | Height: | Size: 254 KiB |
Loading…
Reference in New Issue
Block a user