Overview

RCC workers are C/C++ language component implementations. They are hosted in an OpenCPI container, which is responsible for:

  • loading, executing, controlling, and configuring the worker

  • effecting data movement to and from the data ports of the worker

  • providing interfaces for the local services available to RCC workers.

RCC workers that are executing and collocated together in the same container can make use of local zero-copy approaches to move data between them. For connections between workers in different containers, the containers move data between each other using a common data transport mechanism. Containers make use of a default data transport between the two devices unless explicitly configured to do otherwise.

The OpenCPI Component Development Guide (CDG) contains sections for the general introduction to the control plane functionality of workers and containers, followed by the general execution model of software-based workers. The specifics of the RCC authoring model are included here, consisting of:

  • container-to-worker interfaces: how the container calls the worker’s entry points

  • worker-to-container interfaces: how the worker calls the container’s entry points

  • the local services: how the worker uses local services and which ones are available.

Creating a component implementation (a.k.a. authoring a worker), includes writing source code as well as specifying certain characteristics of the implementation in a separate XML file. This XML file is called the OpenCPI Worker Description (OWD). It refers to the OpenCPI Component Specification (OCS) being implemented, specifies the authoring model and language, and describes any non-default constraints or behavior of this particular component implementation. It includes attributes and information that are specific to the authoring model. RCC OWDs are initially generated using the ocpidev tool and then may be further customized. The ocpidev tool and the OWD aspects that are common to all authoring models are described in the OpenCPI Component Development Guide.

RCC workers can act as a proxy for other workers, which then act as slaves. Proxy workers provide a control interface via their properties and control operations that are translated into lower level controls for workers that are more primitive, usually device specific, and usually written using different more processor-specific authoring models.

Having a proxy for higher level, more generic control processing relieves the slave workers of the complexity and burden and footprint of adapting to common interfaces and control protocols. A common use-case for proxies is controlling device workers: they are fully described in the OpenCPI Platform Development Guide. In an application, a proxy is guaranteed to be configured and started before its slaves are started, allowing the proxy to privately configure the slave.