Skip to content

Svc::ComStub (Passive Component)

1. Introduction

Svc::ComStub is an example F´ component implementing the communication adapter interface required to work with F´ communication components. Projects would typically switch this component out for a radio manager component. The purpose of ComStub is to implement the communication adapter interface by delegating to a Drv.ByteStreamDriver (e.g. Drv.TcpClient or Drv.LinuxUartDriver) to send and receive data.

Projects and users may choose to replace this with a complete communication implementation (i.e. a component managing a specific radio) once ready. As long as any communication implementation implements the communication adapter interface it can drop in and work with the standard F´ uplink and downlink setup.

Svc::ComStub delegates to a Drv.ByteStreamDriver in order to send and receive data through the driver interface.

2. Assumptions

Using Svc::ComStub assumes that the driver layer (e.g. Drv::TcpClient) provides all capability needed to establish communications. For example, a project can communicate over raw tcp rather than requiring additional protocol on top of tcp.

3. Requirements

Requirement Description Rationale Verification Method
SVC-COMSTUB-001 Svc::ComStub shall accept Fw::Buffer for transmission and pass them to a Drv::ByteStreamSend port The comm interface must send Fw::Buffers through a driver Unit Test
SVC-COMSTUB-002 Svc::ComStub shall send a Fw::Success:SUCCESS signal via an Fw.SuccessCondition port on Drv::ByteStreamSend success Successful sends must notify any attached Svc::ComQueue Unit Test
SVC-COMSTUB-003 Svc::ComStub shall send a Fw::Success:FAILURE signal via an Fw.SuccessCondition port on Drv::ByteStreamSend failure Failed sends must notify any attached Svc::ComQueue Unit Test
SVC-COMSTUB-004 Svc::ComStub shall retry sending to Drv::ByteStreamSend on Drv::ByteStreamSend retry Sends indicating RETRY should be retried. Unit Test
SVC-COMSTUB-005 Svc::ComStub shall pass-through Fw::Buffer from a Drv::ByteStreamRead on Drv::ByteStreamSend success A Comm interface must receive Fw::Buffers from a driver Unit Test

4. Design

The diagram below shows the Svc::ComStub port interface. Svc::ComStub is a basic Communication Adapter and can be used alongside the other F´ communication components (Svc::Framer, Svc::Deframer, Svc::ComQueue).

Svc::ComStub Uplink and Downlink Interface

Svc::ComStub as Communication Adapter

Svc::ComStub implements the communication adapter interface by delegation to a Drv::ByteStreamDriverModel as a way to transmit data and receive data. Other communication adapter implementations may follow-suite.

Svc::ComStub to Drv::ByteStreamDriverModel

4.1. Ports

ComStub has the following ports. The first three ports are required for the communication adapter interface, the second three are because the implementation delegates to a Drv.ByteStreamDriverModel. Only the communication adapter interfaces ports are required for replacements to Svc::ComStub, however; a Drv.ByteStreamDriverModel ports may still be useful

Communication Adapter Interface Ports

Kind Name Port Type Usage
sync input dataIn Svc.ComDataWithContext Port receiving Fw::Buffers for transmission out drvSendOut
output comStatusOut Svc.ComStatus Port indicating success or failure to attached Svc::ComQueue
output dataOut Svc.ComDataWithContext Port providing received Fw::Buffers to the broader application (typically a Deframer)
output dataReturnOut Svc.ComDataWithContext Port returning ownership of data that came in on dataIn
sync input dataReturnIn Svc.ComDataWithContext Port receiving back ownership of buffer sent out on dataOut

Byte Stream Driver Model Ports

Kind Name Port Type Usage
sync input drvConnected Drv.ByteStreamReady Port called when the underlying driver has connected
sync input drvReceiveIn Drv.ByteStreamRecv Port receiving Fw::Buffers from underlying communications bus driver
output drvSendOut Drv.ByteStreamSend Port providing received Fw::Buffers to the underlying communications bus driver
sync input drvSendReturnIn Drv.ByteStreamData Port receiving status and ownership of buffer sent out on drvSendOut
output drvReceiveReturnOut Fw.BufferSend Port returning ownership of buffer that came in on drvReceiveIn

4.2. State, Configuration, and Runtime Setup

Svc::ComStub stores a boolean m_reinitialize indicating when it should send Fw::Success::SUCCESS in response to a driver reconnection event. This is to implement the Communication Adapter Protocol of a communication adapter interface. It also keeps track of a m_retry_count to limit the number of retries on an attempt to send data.

4.3. Port Handlers

4.3.1 dataIn

The dataIn port handler receives an Fw::Buffer from the F´ system for transmission to the ground. Typically, it is connected to the output of the Svc::Framer component. In this Svc::ComStub implementation, it passes this Fw::Buffer directly to the drvSendOut port. It will retry when that port responds with a RETRY request. Otherwise, the comStatusOut port will be invoked to indicate success or failure. Retries attempts are limited before the port asserts.

4.3.1 drvConnected

This port receives the connected signal from the driver and responds with exactly one READY invocation to the comStatusOut port. This starts downlink. This occurs each time the driver reconnects.

4.3.1 drvReceiveIn

The drvReceiveIn handler receives data read from the driver and supplies it out the dataOut port. It is usually connected to the Svc::Deframer component