Compatibility Model

The shaded items are provided by the OBS Framework. The packet router must instead be provided externally. From the point of view of the application process the packet router has two functions. It must make available the PUS telecommand packets that have the application process as their destination and it must receive the PUS telemetry packets that the application process generates. The interfaces between the packet router and the application process are theTelecommandLoader and the TelemetryStream classes. Note that these are abstract classes. Applications will have to instantiate them to take account of the exact interface of the packet router. The telecommand loader interprets the PUS packet and uses its content to build a component of typeTelecommand that encapsulates the telecommand. This is then executed by theCC_TelecommandManager component. In a symmetric process, telemetry packets are represented inside the application process by components of typeTelemetryPacket. The content of the telemetry items is written to the telemetry stream by theCC_TelemetryManager component. The task of the telemetry stream is to transfer the telemetry data to the packet router.

The general idea is that, at the highest level of abstraction, the framework provides classes that are not PUS-specific but which are PUS-compatible in the sense that they can be subclassed to become PUS-specific. Thus, application developers who do not have to be PUS-compliant can use the top-level classes as the base from which to derive their application-specific classes whereas developers who need to be PUS-compliant can use the PUS-specific versions of the same classes. As explained below, the OBS Framework provides default implementations of the PUS classes implementing the more common PUS services.

PUS Telecommands

PUS Telemetry Packets

PUS Services Implementation

Contact Us | The OBS Framework Project