Receiver Message Writer Model

SWITCH TO API

Description

The Receiver Message Writer Model provides persistent storage capability for received communication messages. This model attaches to a Receiver component and automatically writes incoming messages to a Partitioned Data Storage system. It maintains a pointer-based indexing system that enables efficient retrieval of stored messages by key or timestamp, supporting both real-time access and post-processing export. This is essential for spacecraft applications requiring message logging, store-and-forward relay operations, or ground segment data archival.

---

Example Use Cases

• Message Logging: Record all received telemetry and command messages for post-pass analysis and anomaly investigation.
• Store-and-Forward Relay: Buffer received data from one spacecraft for later retransmission to another asset or ground station.
• Data Archival: Maintain a persistent record of received communications for mission history and compliance purposes.
• Time-Based Retrieval: Access historical messages closest to a specific time for correlation with other mission events.

---

Module Implementation

The Receiver Message Writer Model is a Universe Model that attaches to a Receiver component and manages the flow of received messages into persistent storage.

Message Capture

At each simulation update, the model queries the parent receiver for all ready message keys. For each available message:

1. The message is retrieved from the receiver buffer as JSON
2. The data is written to the configured storage system
3. A pointer to the stored data is saved for later retrieval

The total number of stored message pointers is tracked:

$$N_{\text{received}}=\sum _{k\in \mathcal{K}}|{\mathcal{P}}_k|$$

where $\mathcal{K}$ is the set of message keys and ${\mathcal{P}}_k$ is the set of pointers for key $k$.

Key Filtering

The model supports optional filtering to selectively store only specific message types. When filters are configured, only messages with keys in the filter list are written to storage:

$$\text{store}(k)=\{\begin{array}{ll}\text{true}& \text{if }|\mathcal{F}|=0\text{ or }k\in \mathcal{F}\\ \text{false}& \text{otherwise}\end{array}$$

where $\mathcal{F}$ is the set of configured key filters.

Pointer Management

Each stored message is referenced by a PartitionedDataPointer that records its location in storage. Pointers are organized by message key, enabling efficient retrieval:

Operation	Description
ReadLatestJSON	Retrieves the most recently stored message for a key
ReadLatestMessage	Deserializes the latest stored message into a message object
ReadClosestMessage	Finds the message closest to a specified timestamp

Time-Based Retrieval

The ReadClosestMessage method searches stored messages to find the one with timestamp closest to a target time $t_{\text{target}}$:

$$k^{\ast }=\underset{i}{\mathrm{argmin}}\left|t_i-t_{\text{target}}\right|$$

where $t_i$ is the timestamp of the $i$-th stored message. In case of ties, the earlier message is preferred.

Data Export

The model provides an export capability that writes all stored messages to CSV files organized by message key. Export options include:

Option	Description
formatTime	Convert timestamps to human-readable DateTime format
delete	Remove data from storage after export

The epoch message is used to convert simulation time to absolute Date Time when formatting is enabled.

Persistence

The model implements save and load functionality to preserve pointer metadata across simulation sessions. The pointer mapping is serialized to JSON format during save operations and restored during load operations, ensuring continuity of stored message references.

---

Assumptions/Limitations

• A valid Partitioned Data Storage reference must be configured for the model to function.
• Messages are stored in JSON format; binary message formats require JSON serialization.
• Pointer metadata is stored separately from message data; storage corruption may orphan pointers.
• The ReadClosestMessage method reads all messages for a key to find the closest timestamp, which may be slow for large datasets.
• Key filters must be configured before messages are received; retroactive filtering is not supported.
• Deleted messages cannot be recovered; the delete operation is permanent.
• CSV export uses a pipe delimiter to avoid conflicts with comma-containing data fields.