###### tags: thèse master
# FWS frameworks
[TOC]
## cFS
Is an application developpment and run-time environment. Provides a set of core services including **Software Bus (messaging), Time, Event(Alerts), Exectutive (startup and runtime) and Table services**. It Defines an API for each services which serves as the basis.

The cFe Bus service provides a publish and subscribe messaging system that allows app to easily plug and play into the system. Application subscribe to cFE at runtime, making system modifications easy.

Each services comes complete with a build in application that allows users to interface with each service. The configuration parmeters allow the cFE to be tailored for each environment including desk-top and closed loop simulation envrionments. This provide the ability to run and test software application on developer's desktop and then deploy that same software without change to the embedded system.

In addition the cFE includes the following software development tools:

- Unite test Framework for unit testing application developed via the cFE
- Software Timing Analyzer that provides visibility into the realtime performane of embedded systems software
- Table Builder
- Commande and Telemetry utilities

cFE is one of the components of th cFs, a platform and project independent reusable software framework and set of reusable software applications.

There are 3 key aspect of cFs architecture.
- a dynamic run time envrionnment
- layered software
- component based design

Pivotal design structure, abstracting architecture from hardware component layering. Each layer of architectre "hides" its implementation and technologiy details from the other layers by defining and using standard APIs. The internals of layer can be changed without affecting other layers internals components

Layers:
- OSAL : OS Abstraction Layer, intergrated into cFE, Open source, intergated into cFE,
- PSP : Paltform Support Packet
- cFe : core flight Executive (on top of PSP and OSAL) comme with a build environment, deployement guide, API reference and provides a sample PSP
- Application layer

cFE allows embedded system software to be developed and tested on desktop wokstations and ported to the target platform without changing a single line of code.

## Architecture


From bottom to top :
- Operating system : it can be any OS that is compatible with OSAL. Linux for developpment and FreeRTOS for OBC. It must be compatible with OSAL
- OSAL : It's the layer that must be configured to make the bridge between FS and OS.
- cFE : describes above
- cFS : that's applications are already written and tested. Basics apps are provided by nasa [here](https://cfs.gsfc.nasa.gov/#:~:text=Overview,and%20a%20component%20based%20design.)
- User application/Libraries : it's there were we developpe mission specifics app.

### cFE services

Applications have access to the cFE through services. Each service is separate from the others and has its own functionalities.


Every service has :
- A API on a library that can be use by application
- An application to manage service by the ground

These services run as child threads on a non-real-time OS like Linux, and as tasks on a real-time OS such as VxWorks

#### Communication between apps

- Use CCSDS protocole to communicate
- Use Publish/Subscribe pattern
- Use a queue (FIFO) as Pipe
- Apps send messages that are enqueued. If an app is subscribed to this message the will recieve it when it's out of queue.
- Pipe used for application and data flow

#### Executive service (ES)
Es is the layer that incorporate OSAL. The OSAL API provide a common interface for applications regardless of wich OS OR RTOS where the application is running. OSAL can be implemented on a wide range of processors. ES creates an application run time environement.

#### Software Bus (SB)
Manages Communication between Apps (cf Communication between apps). SB route messages to all applications that are subscribed. It's connection less, then sender doesn't know who is subscribed. The routing messages can be added/removed at runtime. Reports the errors when detected durring the transferring messages. Can send statistics packet and informations. Messages uses CCSDS standards.

#### Time service (TS)
This service provides time correlation, distribution and synchronization services. Provides a user interface for correlation of spacecraft time to ground reference time. Provides a functionnal API for cFE application to query the time.

#### Event service (EVS)
Event service provides an interface for dending time-stamped text messages on the software bus.
- Considered asynchronous because they are not part of telemetry periodically generated by an application.
- Processor unique id
- Optionally logged to local event log
- Optionally output to a hartdware port
They are 4 events types defined
- Debug
- Information
- Error
- Critical
Apps can filter individual messages based on identifier.

#### Table service (TBL)
Table are logical groups of parameters that are managed as table entity. They change the behaviour of FS algo. Tables service provides ground commands to load a table from a file and dump a table to a file. The table load are synchronized with applications. Theay are binary file. This service is not primordial. cFE can be built without table support (cFE apps don't use tables).

##### CCSDS

The framework communicte with CCSDS packet : it's the protocol used by PUS.
: protocol defined in PUS documentation page 438...

### cFS

Each app has its own execution thread and appes can spawn child tasks. The app can be easily plug into FS. cFS framework gives already developped app. They need to be customised and configured. All developped apps must follow some rules to be reused by anybody. A lot of project provides already developped apps.

### PUS services

PUS services use CCSDS packet. To be compliant with PUS, the secondary header must fulfill PUS standard seondary header. Unfortunately cFS TC and TM secondary header is not compliant with PUS secondary header. Furthermore, Some TC in cFS are done by uplink of table files and not by TC only.

However, there are PUS services that can be achieved by cFS

source(publicacao.pdf)


### CCSDS SOIS (Onboard Interface services)
It's standard inspired by PUS.

source(publicacao.pdf)

## Fprime
Fprime is an free opensource framework developped at JPL(nasa). It's tailored for small-scale fligth systems such as CubeSat. Fprime is composed of the following :
1. An architecture that decomposes flight software into discrete components with structured communication based on ports
2. A C++ framework that provides core capabilities such as message queues and threads,
3. Tools for specifying components and connections and automaticakky generating code
4. A growing collection of ready-to-se components
5. Tools for testing flight software at the unit and integration levels.

Fprime as keys features :
- High modularity : component-based architecture enables a high modularity and reuse. The typed port connection provide storng compile-time guarantees of correctness.
- fprime can adapt to all kinds of missions and complexity for smallsat.
- Fprime provide a complete FSW developement ecosystem.
- Modeling tools
- testing tools
- ground data system
- Fprime can be run on a wide range of processors, from microcontrollers to multicore computers and several OS. Fprime is easy to adapt to new OS.

### Architecture
All Fprime app conformes fprime architecture. This architecture is a proven FSW architecture. It is based on 3 main concepts
1. components
2. ports
3. topologie

#### Components

An Fprime application is composed of multiple components. In analogy with programming, a composent is like a class. It defines collection of data and operations on the data. Every component is a state machine.

When started up, an instance of applications are constructed, Like an object in programing. The components perform its own local computation and communicate with each other.

A communication occurs via invocations from one comp to another. An invocation is a function call that either immediately does some work or puts a message on a queue for later dispatch.

There are 3 kind of component:
1. Active
2. Passive
3. Queued

##### Active component
Each instance of active comp has its own thread. It can reveive synchronous and asynchronous invocations. A synchronous invocations run a handler function immediately on the thread of the sender. Asynchonous invocations run a function on the sender thread that places a message on a queue. A dispatch loop running on the thread of active comp later removes the message form queue and dispatchs it by running a handler function.

Active comp can send synchronous and asynchronous invocations.

Uses:
- Performing background tasks with low priority.
- Driving the behaviour of queued components.

##### Passive component

It's like a an ordinary c++ class. Invocations must be synchronous. Synchronous invocation run a handler function immediately on the thread of the sender. Instance doesn't have thread of its own

Uses :
- Filtering or transforming data on the way from one component to another.
- Providing ports that other components can query (to get the current time).

##### Queued component
A queued component has an input queue. An instance can recieve synchronous and asynchronous inovcations. Queued instance has no thread of its own.

Uses :
- Periodic flight software behaviour.

**Rate groupe** : severak Queued components running at the same rate.

#### Port
The communication between components go through ports. It's extremely structured. Components instance do not directly access each other's data or methods. They send or receive invocations. The invocations occur over ports. When a component is designed, you need to specifie its ports. Every port has a type and a kind.

##### Port typs
Port type is like function signature. It specifies :
- What kind of data my be sent on a port
- If there is a return value
- Type of return value
Fprime define several port types but it's possible to define new port type.

##### Port kinds
There are 2 port kinds : Input port and Output port. Output port send invocations to input ports.

There are several types or input ports :

| Port kind | When Handler Runs | Execution Thread |
| -------- | -------- | -------- |
| Synchronous | Immediately | External |
| Asynchronous | Later | Internal |
| Guarded | After acqueriring a mutex lock | External |

- Synchronous Input ports : It's a direct function call. Need to ensure that port handler is concurrency dafe (Passive, Active, Queued comp)
- Asynchronous Input ports : It's a function call that put a message in a queue. The queue provides concurrency safety. (Active, Queued comp)
- Guarded Input ports : It's a direct function call but with a mutex lock. Ensures concurrency safety. (Passive, Active, Queued comp)

##### Return values
Synchronous and guarded input ports can retunr values. For example get the current time from time component.

#### Serialize port
Sending data between typed port provide a strong compile-time guarantee. But sometimes, we need to send severak unrelated types on the same port when communicating over network.

Component can have untyped ports named serialized port. These ports must follow rules :
1. It's possible to connect typed output port to serialize input port. Data are serialized into bytes before being sent. The bytes encode the type of the data
2. It's possible to connecto serialize output port to serialize input port. Data (bytes) are sent unchanged to input port.
3. It's possible to connect serialize output port to typed input port. Data are automatically deserialized to the type stored in the bytes.

Exemple of Fprime components

#### Topology and Deployments

A set of component instances and their connections forms a direct graph called a topology. A topology with supporting libraries specifies a FSW exectuable programm aslo called a deployment. With a single set of components instances, it's possible to create several different deployment. We can have deployment for different hardware or configurations or swap out hardware components for software simulators or to test different parts of the system.

#### C++ framework
##### C++ component
Fprime components are Composed of c++ classes. Each kind of componenent (active, passiv, queued) has its own base class. Each component in an fprime app is derived form one of these classes.

When a app is create from model 2 classes are generated
- CComponentBase derived form the approprioate base class
- CComponentImpl derived form CComponentBase. It's the class where we code the component.

CComponentBase is th ebase class for Component implementation. It contains generated code for receiving commands and for sendinf and receiving invocatrion on ports.

CComponenetImpl si a skeleton for implementation of Component. In this class we define Helper methods or local variables and fill the implementation of derived virtual methods. The framework and the auto-generated class take care of all the details of invocations handling. When writing handlers, it's easy to send data on output ports by calling member methods definded in CComponentBase.


##### OS Abstraction layer
Fprime includes c++ classes that provide abstractions of common OS features :
- Threads
- mutual exclusion locks
- message queues
- files
- timers
- clocks

The open-source framework provides OS layer for
- Linux (can work on windows with Cywing)
- Mac OS
- VxWorks : Internally to JPL

##### Optional Features
There are several optional features. If not needed, it's possible to disbale it by editing a configuration file. This can saves memory and/or CPU cycles.
Optional Features :
- Sending data on serualized ports
- Storing diagnostic information about component instances
- Converting events emitted by FSW to human readable text

#### Modeling and code generation
FPrime uses XML to design a component. It imposes a schema. This schema specifies the model of the application.
The model describes the application at a high level in terms of :
- Components
- Ports
- Topologies

Autocoder translates the model into c++ classes.

##### XML model
As part of the XML component specifications, it's possible to define :
- **The input/output ports** : define the port seen above
- **Commands** : Commands that the ground can send to component instances (commande name, arguments, type of arguements)
- **Telemetry channels** : Telemetry channels emitted by the component. Has an unique ID and a value type.
- **Events** : Report of FSW behaviour for notification or warning.
- **Parameters** : Constante value that may be updated by commande from ground like parameter for algorithm.

#### Reusable components

Fprime distribution includes a number of generic reusable components. These components includes design documentation and unit tests. They are self-contained ans easy to integrate into flight software project that use Fprime.

##### Rate Groups
Fprime provides 2 components to create rate groups
1. RateGroupDriver : Receives a periodic timing signal form hardware or software and sends invocations to instances do ActiveRateGroup
2. ActiveRateGroup : One for each rate group, provide thread for rate group.
##### Commands
###### CmdDispatcher
Receives data buffer containing serialized commands. commande dispatcher deserialized the commande and dispatches it to a single index in an array of output ports.

###### CmdSequencer
Loads binary command sequence files and run them.

##### Events and Telemetry
###### ActiveLogger
Accpets incomming events and apply filter to them based on event severity. Activelogger stores event in a circular buffer and emits the event on an output port.

###### PassiveTextLogger
Accpets events and converts them into a human readable text and writes the text to the console.

###### TlmChan
Receives chanelized telemetry points and stores them in a map. Each telemetry point consists of a channel ID and a serialized value. TlmChan instances can be used in one of two modes :
1. On resquest : provide the latest telemetry value associated with a given ID
2. Periodically send all telemetry points whose values have changed since the last period

###### ComLogger
This provides continous logging of events to the file system.

##### Ground Interface
###### BuffGndSockIf
Provide a socket-based interface between FSW and FPrime gorund data system. Supports uplink commands and files and downlink fo event, telemetry and files.

##### File system
###### FileUplink, DownLink
Provides file uplink and downlink capabilites.

###### FileManageur
Provide a ground interface to the on-board file system.

##### Memory Management
###### BufferManager
Manage memory buffers forn statically allocated store.
###### PolyDb
provides a map from numeric identifiers to values. PolyDB is useful for storing an collection of values, for example sensor reading received form hardware.

##### Parameters
###### PrmDb
Stores the current values of the FSW parameters. At initialization, PrmDB reads a parameters table out of file. Parameters can be changed by ground commands.

##### Time
The Time component has a guarded port to request the current spacecraft time.

##### Health
Health components ensures that no thread are spinning or stuck.

##### Assertion and Fatal Events
###### AssertFatalAdapter
Converts assrtions failures into fatal events

#### Testing

Fprime provides tools for testing FSW. Unit tests can classes can be automatically create with tools. Fprime provides many functions to test componenents an ensure their behaviour.

## CORDET