Aerospace and Electronic Systems Magazine May 2018 - 62

Flexible CubeSat-Based System for Data Broadcasting

Figure 5.

Alert messages broadcasting system architecture.

ing, and reception is shown in Figure 5. From the left to the right
side, the main components are:
C

Alert Issuer, an alert authority responsible for generating the
alert messages to be delivered.
MAMES Alert Provider, the network entity responsible for
encapsulating the alert messages into the MAMES ones as
defined in [27].
Satellite Component, a Satellite Mission Control Center
(MCC) for the upload of MAMES messages and the satellite subsystems management and a 3-Unit CubeSat (D-SAT)
in charge of processing and broadcasting the MAMES messages.
Portable SDR User Terminal, a low complexity network entity for the reception of MAMES Messages and the decapsulation of alert ones.

The functioning of the overall system envisages the exchange
of alert information among the involved entities.
The Alert Issuer provides the MAMES Alert Provider with the
alert related information which includes both the AM (formatted
according to the Alert Issuer most convenient format) and the additional information (such as validity, priority, event category, etc.)
that is used for the MAMES Header definition. The MAMES Alert
Provider encapsulates the received message into a MAMES Message and makes it available for the satellite communication network. The Satellite MCC periodically queries the MAMES Alert
Provider for a new MAMES Message and uploads it to the D-SAT.
After MAMES message on-board processing (validity and priority checks), the D-SAT broadcasts the received message back to
62

Earth. The MAMES Message is then directly received by an SDR
receiver, which acts as satellite terminal and MAMES Receiver
(Alert Message decapsulation).
The Alert and MAMES message exchange between the MAMES Provider and the Alert Issuer (Interface I1) and Satellite MCC
(Interface I2), respectively, relies on M2M Communication mechanisms based on Web Services paradigm.
In detail, the easy automation of the entire process of Alert
Message provision and MAMES Message generation is obtained
by the use of a high-level Python Web framework at the MAMES Provider and a python script at the Alert Issuer. As depicted
in Figure 6 (Interface I1), as the Alert Issuer launches the script,
the alert related information is submitted to the MAMES Alert
Provider and the corresponding MAMES Message generation and
storage in the local Data Base are triggered on the MAMES Provider side. The Satellite MCC periodically queries the MAMES
Alert Provider for new MAMES Messages stored in the MAMES
Provider Local Data Base (Interface I2). A python script is used by
the Satellite MCC for managing the query and the MAMES Message download and formatting into a binary file for the consecutive
upload to D-SAT.
It is worth highlighting that the D-SAT logical operations of the
MAMES communication protocol and message validation, relies
on the SatAlert Experiment task (SAE) and the Interface SatAlert
Experiment task (ISAE), which are the two main functions of the
on-board satellite operating system. The SAE logical functions include:
C

Time validity check. Upon reception of a trigger command
for transmission, the validity of the MAMES message previously stored in the transmission queue is verified (Case 1).

IEEE A&E SYSTEMS MAGAZINE

MAY - JUNE 2018

Table of Contents for the Digital Edition of Aerospace and Electronic Systems Magazine May 2018