Command And Control

Table of Contents

Command And Control

Architecture Overview

1  Daemon Process
2  +------------------------------------------------------------------------------------------+
3  | |
4  | |
5  | Kubos |
6  | +-----------------+ |
7  | +-----> | service1 | |
8  | | +-----------------+ |
9 +---------+ | +-------------------------+ +----------------------+ | +-----------------+ |
10 | Command | | | | | | +-----> | service2 | |
11 | Line | <----+ | | | | +-----------------+ |
12 | Client | | | | | | | +-----------------+ |
13 | +----> | Command Service +---> | Command Registry +--------> | service3 | |
14 | | | | | | (Directory) | | +-----------------+ |
15 | | | | | | | | +-----------------+ |
16 | | | | | | | +-----> | service4 | |
17 +---------+ | +-------------------------+ +----------------------+ | +-----------------+ |
18  | | +-----------------+ |
19  | +-----> | service5 | |
20  | +-----------------+ |
21  | +------------------------------+ |
22  | | Service Interface | |
23  | +------------------------------+ |
24  | | | |
25  | | + execute | |
26  | | | status | |
27  | | | help | |
28  | | + ... | |
29  | | | |
30  | +------------------------------+ |
31  | |
32  +------------------------------------------------------------------------------------------+

The command line client is a binary exposed to the KubOS Linux command line.

Commands entered into this client will be encoded into a CBOR Concise Binary Object Representation message format and packed into a CSP packet and sent to the command service.

Existing functionality in the Kubos platform will be exposed in groups in a series of libraries.

The command service will first parse and look for an action argument, a group (library) name, and a set of optional arguments. These will be used as follows:

  • Action argument - The corresponding member function of the service interface that will be called (ie. exec, status, help, output).
  • Group name - The base name of the library containing the desired functionality (Core, Telemetry, CSP, HAL, IPC, etc.).
  • Optional arguments - Passed through to the service implementation to perform more specific tasks.

The command service will look to load a corresponding library from a fixed path containing all of the Kubos and user defined libraries. Libraries will follow the lib<group_name>.so naming convention.

The appropriate function of the service interface will be called with the remaining arguments.

Once the API call returns, a CBOR-encoded message containing the execution time, the return code and any stdout messages from the command will be returned to the client.

Module Design

Modules will need to implement the service interface and be compiled into a shared library in order to be compatible with this command and control system.

These functions will need to accept and parse arguments and handle routing the arguments to the desired functionality in that library.

1 +--------------------------------------+
2 | Service Interface |
3 +--------------------------------------|
4 | |
5 | int execute(int argc, char **argv) |
6 | |
7 | int status(int argc, char **argv) |
8 | |
9 | int help(int argc, char **argv) |
10 | |
11 | int output(int argc, char **argv) |
12 | |
13 +--------------------------------------+

Library Implementation

Libraries exposed through the command and control framework will need to implement the Service Interface.

Note: Currently only the stdout from the library execution is returned to the client after running a command.

Currently only the core library (core commands for the "core" command and control commands) is implemented. Future releases will have further examples of shared libraries.

See the core library for an example of a library following this format.

Generated by   doxygen 1.8.11