cFS Basecamp App Design

Key Points

Basecamp apps are written in C using an object-based design.

An application framework library is used by all Basecamp apps.

The Unified Modeling Language is used to document app designs that includes structure and control flow models.

Design Notation

Basecamp uses a small subset of the Unified Modeling Language (UML) to document software designs. If you are new to UML do not let this intimidate you. The concepts are not hard to learn, and the models will be explained when they are introduced. In addition, a minimalist approach is taken with the UML diagrams, so they contain just enough detail to convey a particular design. For UML learning resources see the Curated Links section below.

App Architecture

Here’s the UML representation of the top-level app design structure:

Every app has an App Main object (rectangular box) that uses 1 instance of the Application Framework package (folder icon). The Application Framework is a cFS library called APP_C_FW that provides common app services. It is represented as an aggregate because App Main contains instances of the framework services it uses. An app is composed of 0 to N functional objects. Functional objects implement mission requirements. An app with no functional objects is the notorious “Hello World” app. It creates a Software Bus Pipe to receive commands, sends a periodic status telemetry message and responds to a No Operation (NOOP) command by sending an event message (Hello!”). You can create a Hello World app using Basecamp’s Create App tool.

App Main Object

Here’s an example of an app’s top-level control flow:

The control flow has three functional states:

Initialize App
- Register the app with the cFS Event Service
- Read the JSON initialization parameter file
- Initialize app functional objects
- Create a Software Bus command pipe (FIFO input queue)
- Subscribe to command messages
- Create a Command Manager object and register app’s command functions
- Send an event message indicating initialization complete
Runtime execution loop
- Verify Executive Service execution state
- Pend on Software Bus
- Process received messages
Terminate App
- Write a system log entry
- Send an event message

These functions are common to most apps; however, the control flow can vary depending on what drives the app’s execution. Pending for a Software Bus message, with or without a timeout, is a common mechanism for controlling an app’s main loop. There are many variations to this concept. The cFS Basecamp Application Developer’s Guide, https://github.com/cfs-tools/cfs-basecamp/blob/main/docs/basecamp-app-dev.pdf, contains a summary of control methods used by the NASA apps.

The “Sched?” diamond in the control flow diagram is checking for the arrival of a message from the Scheduler App. This app performs a critical systems role by sending periodic messages synchronized with the cFS time Service’s 1Hz tick. Apps commonly use a scheduler message to determine when to send their routine status telemetry (AKA Housekeeping).

Object Model

Apps typically have multiple functional objects, and each object can contain additional objects creating a tree-like structure. Here are two examples, File Manager (FILE_MGR) and Demo App (APP_C_DEMO):

Technically these are UML class diagrams. Since Basecamp apps are written C and only one instance of a class exists, they will be referred to as object diagrams. Each box represents an object with the object name in the top rectangle, data elements in the middle rectangle and public methods (functions) in the bottom rectangle. Only significant data elements and methods are shown.

A C header file is used to define an object’s data structure and public functions. A corresponding C source file declares a static pointer to the object’s data and defines all the object’s methods. The owner of an object declares an instance of the object’s data. A pointer to the data is passed to an object’s constructor where it is assigned to the object’s static data pointer. All the object’s functions use the pointer to operate on the data. This design is a variation of the Singleton design pattern. Only one instance of an object can exist. If more than one instance is required than the pattern can’t be used. Currently none of the more than 12 Basecamp apps have had to deviate from this design pattern.

Object control Flow

This UML sequence diagram shows the flow between File Manager objects for two scenarios: app initialization and a file copy command. Time flows from top to bottom.

Notice that the app framework services play a key role in an app’s structure and control flow. For example, an app’s initialization function registers command functions with the Command Manager service and the app’s main loop uses the Command Manager to verify command messages and call the command function.

Curated Links

UML Tutorial
https://www.tutorialspoint.com/uml/uml_quick_guide.htm
Singleton Design Pattern https://www.tutorialspoint.com/design_pattern/singleton_pattern.htm