Introduction:
This tutorial, prepared by ESA, will guide you through the creation of ECSS-E-ST-70-41C PUS C compliant system using ESA’s TASTE MBSE toolchain and the integrated OPUS2 tool developed by N7 Space. At the end of this video series, you will have two Linux applications, one simulation Ground Segment with a Graphical User Interface, and one simulating Space Segment, communicating with each other using PUS C over an UDP socket.
Prerequisites:
- Debian 13 (recommended) or another Debian based Linux environment,
- TASTE installation (see https://taste.tuxfamily.org/wiki/index.php?title=Manual_installation_on_a_native_platform)
- OPUS2 tool (TASTE add-on, installed via add-ons/install-opus2.sh script)
A detailed User Manual for the OPUS2 tool is provided here:https://taste.tuxfamily.org/wiki/index.php?title=Opus2_User_Manual
Description:
ECSS-E-ST-70-41C Telecommand and Telemetry Packet Utilization Standard version C (PUS C) addresses both the interface (how packets are encoded) and system (how system should behave) requirements for TC/TM exchanges with space segment elements.
TASTE is ESA’s Model Based System/Software Engineering toolchain for end-to-end design and implementation of heterogeneous distributed embedded systems. It supports targeting various embedded platforms, such as GR712RC, SAMV71 and MSP430, as well as standard Linux x86/x86-64 systems. OPUS2 is a supplementary tool that provides the following capabilities:
- drafting PUS C Service Types (ST), in compliance with ECSS-E-ST-70-41C standard,
- generating documentation of system and interface level requirements, replicating the format of the standard,
- tailoring of Service Types for the given deployment,
- generating standalone ASN.1/ACN for packet transcoding that can be integrated with manually developed embedded code,
- generating TASTE PUS C Frontend that is capable of both transcoding the PUS C packets, as well as orchestrating their execution, in-line with PUS C system requirements.
This tutorial focuses on tailoring of the Service Types and generating the Frontend.
The generated PUS C Frontend requires a user-provided, mission/HW-specific implementation of utilities e.g., for memory access or on-board file-system handling. This can be either implemented manually or sourced from the currently developed library of re-usable components.
OPUS2 is provided with models covering:
- all standard (as of the first release of PUS C) Service Types on the interface requirements level and most of the system requirements level,
- behaviours for most of the commonly used Capability Types, including all that are needed to create a typical CubeSat or Payload system.
In particular, OPUS2 can be used to tailor and instantiate a system that provides (including, but not limited to):
- ST[1] for telecommand acceptance, verification and status reporting,
- ST[3] for housekeeping telemetry,
- ST[5] for event reporting,
- ST[6] for memory access (requires a user-provided backend for performing actual memory reads/writes),
- ST[17] for connectivity testing,
- ST[12] and ST[19] for on-board monitoring and action invocation, which can be used for simple FDIR,
- ST[20] for managing on-board parameters, with a basic implementation of a Data Pool.

OPUS2 has been developed by N7 Space in the scope of TASTE Model Checker Continuation (Contract 4000133440/20/NL/CRS), and further extended in the scope of Model Based Execution Platform (Contract 4000146882/24/NL/KK) activities financed by the European Space Agency.