Ryan recently presented this topic at GSAW 2024. I thought I'd transcribe the talk and slides into a blog post because it's an interesting topic and helps to unpack the COSMOS architecture and philosophy.

The fundamental problem is how can we make it easy to communicate with any piece of hardware. The traditional answer is simply make everything conform to the same standard. However, xkcd summed up this approach in the following comic:

Engineers are constantly creating new standards and striving to make improvements. An optimized standard is inherently non-universal and standards that try to be universal are generally overly complex. All standards have design tradeoffs, e.g JSON is easy for humans to read and edit, it's self-describing and cross platform. However, it's not bandwidth efficient, has no built-in way to transfer binary, and has no comments. So what is the answer? 

The COSMOS solution is layers of abstraction that allow it to connect to any piece of hardware. The COSMOS philosophy is we will conform to your hardware, you don't have to conform to us. We achieve this through the following abstrations: Packets with Item Definitions and Accessors which know how to serialize the data to a buffer. That data gets written out by an Interface which using Protocols to massage the data before going out to the Device.

Let's dive into the Packet abstraction first. Packets form the set of information read from and written to Interfaces. Item Definitions provide all the metadata necessary for an Accessor to read or write data from the Buffer. This includes the name, bit offset, bit size, data type and XPath or JsonPath for complex structures like HTML or JSON. Accessors are what read and write values from the Buffer. It handles different serialization formats such as binary, JSON, CBOR, XML, HTML, web forms, and Protocol Buffers. The Buffer is what holds the actual bytes in the hardware's desired format.

The COSMOS configuration files define the Packets and Item Definitions and indicate which Accessor should be used. Here's an example JSON command configuration:

Simply removing the ACCESSOR, TEMPLATE and KEY lines turns this into a more traditional binary definition like CCSDS. That is because the BinaryAccessor is the default and doesn't require the TEMPLATE or KEY lines.

Interfaces are what send the packets to and receive packets from the hardware. Common interfaces include TCP/IP Client and Server, UDP, Serial, MQTT, HTTP, SNMP, messages buses (ActiveMQ, RabbitMQ, etc). Interfaces generally don't care about the data being transported.

Protocols take packets and convert them exactly into what is needed by the hardware. This is a useful abstraction because sometimes hardware needs the packet to be encrypted, encoded, broken up or combined. Protocols are also responsible for delineating packets in a stream of raw data.

By using the COSMOS abstraction system, the same command cmd("MYSAT TEST with ITEM1 42, ITEM2 1.41, ITEM3 'TEST'") can be translated into completed different data received by the device. In this example, we should the same command going through two different paths. The top one writes JSON to a HTTP client using an authorization protocol which is typical in modern test equipment. The bottom one writes binary to a TCPIP client using a length and CRC protocl which is typical in a CCSDS spacecraft application.

COSMOS uses the abstractions present in Packets, Item Definitions, Accessors, Buffers, Protocols and Interfaces to enable connecting to anything regardless of the standard (or non-standard) it speaks. Connect with us a sales@openc3.com if you want to learn more about how to integrate absolutely anything into a modern test and operations environment.