Speaker
Description
ISTsat-1 is a CubeSat currently under development by students and faculty from Instituto Superior Te ́cnico (IST) along with amateur radio experts from AMRAD. As with any spacecraft, it will need to be monitored, controlled and results from scientific experiments have to be retrieved. How these tasks are communicated between the ground and the spacecraft is the domain of the ISTsat-1 Control Protocol (INCP) which was designed to serve as the high level protocol for telemetry retrieval and overall control of the ISTsat-1.
The INCP follows a client-server approach with asynchronous message-passing. In this approach, the Ground Segment is the client and the spacecraft is the server, namely the subsystems that com- pose the spacecraft, which are computationally independent. Additionally, INCP is also used for inter- subsystems communication inside the spacecraft.
Overall, there are four groups of operations covered by INCP: data retrieval, event reporting (such as errors), command execution and diagnostic execution.
Data retrieval is used for transferring produced data from the satellite’s subsystems to the ground. Each data type is unique and can be either periodic or singular. Most of the data is periodic, such as the scientific telemetry while for some housekeeping information only the instantaneous values are relevant.
Event reporting is, for the most part, used to report the occurrence of some predetermined events, typically errors. These are produced infrequently and most can have no value at all. The most important information is that they occurred.
Each subsystem has a set of commands which can be executed if so instructed by the ground. Each command is identified by a unique opcode and has input/output values. These arguments and values, are specified by the subsystem and have well defined types. Furthermore, commands as well as diagnostics are only executed by the spacecraft if properly authenticated. Critical messages carry a HMAC (Hash Message Authentication Code) to ward of against unauthorised use of the satellite. Data and event reports don’t have any such mechanism since they don’t perform any significant or critical operation on the satellite.
The goal of diagnostics is to actively test a component and verify its status. Once issued, the resulting test can take a while to be performed and may even finish after the connection window with the ground station has closed. In such occasions, the results are retrieved on the next window. These results are similar to command results but also include the start and end timestamps of the diagnostic execution.
The protocol was designed with a few core concepts in mind in order to best fit the context of the ISTsat-1 mission.
Firstly, all messages can be interpreted in isolation. In other words, one must not have to know what messages were previously exchange in order to “understand” a received message.
Secondly, it’s assumed that the underlying protocol stack guarantees several properties. Specifically, message loss recovery, duplicate message repudiation, ordering and integrity.
Finally, due to the bandwidth requirements Type-Length-Value type formats such as ASN-1 were avoided, especially text based ones such as XML. Thus, a binary static format was chosen were the type of the message is deduced from it’s opcode, unique per type of message.
The protocol’s core is already implemented with much of it’s components tested individually. How- ever, and in the context of the ISTsat-1 project, the modules which describe the various commands, data, etc of the spacecraft subsystems still need to be completed. Furthermore, the protocol and its implementation are yet to be tested in a live environment.
