RTC Component¶
As already explained in the design document, RTC Components are software applications that adhere to specific communication, computation and composition principles defined in the RTC Tk Component Model.
The RTC Tk component infrastructure provides libraries that support the simple creation of such RTC Components.
Supported Functionality¶
Currently the following functionality is supported for RTC Components:
Functionality |
Description |
|---|---|
Component Identity |
Component instance name and component version |
Customisation Mechanism |
Mechanism to create and select custom component life-cycles |
Basic Life-Cycle |
RtcComponent with interface towards business logic |
Life-Cycle Extensions |
Runnable, Measurable, Optimisable, Loopaware and Suspendable |
Command Reception |
CII MAL command interfaces STDIF, UCIF, FCIF, OCIF, MCIF, LCIF, LSIF |
State Publication |
State updates are automatically published to OLDB and CII MAL |
Logging is initialised, configured and a default logger is created |
|
Service Adapter to access the Runtime Configuration Repository |
|
Service Adapter to access the Online Database |
|
Service Adapter to access the Service Registry |
|
Service allowing components to add runtime metrics for monitoring |
|
Facility that provides important event observability via alerts. |
Custom Component Life-cycles¶
The RTC Tk provides a composition-based mechanism for component life-cycle customisation. Application developers select the desired component life-cycle by providing an expression that defines the abilities to be added to the basic RTC Component functionality. Depending on the selected life-cycle expression new functionality is added that supports new commands, changes the state machine, or adds new virtual methods to the business logic interface.
The life-cycle expression for a RTC component that uses the runnable state machine is
Runnable<RtcComponent>.
The RTC Tk provides built-in life-cycle extensions that can be used on demand. Currently the following extensions are supported:
Runnable - For components that have the notion of Idle and Running. Adds commands Run, Idle and Recover, states Idle, Running, GoingRunning, GoingIdle, Error, Recovering and activities GoingRunning, GoingIdle, Running and Recovering.
Optimisable - Adds command Optimise, states OptimiseIdle and OptimiseBusy and activity Optimising with guard OptimisingAllowed.
Measurable - Adds command Measure, states MeasureIdle and MeasureBusy and activity Measuring with guard MeasuringAllowed.
Loopaware - For components that are aware of control loops. Adds commands Run, Idle, Recover, Open and Close, as well as states Idle, GoingRunning, GoingIdle, Error, Recovering, Opened, Closed, Opening, Closing and activities GoingRunning, GoingIdle, Recovering, Opening, Closing, Opened and Closed.
Suspendable - For loopaware components that are also suspendable. Adds commands Suspend and Resume, as well as states and activities Suspended, Suspending, Resuming.
The extensions can be used by including the specific header file and by adding the extension to
the life-cycle expression. E.g. expression Optimisable<Runnable<RtcComponent>> adds optimise
functionality to a component that is using the runnable state machine.
The component life-cycle can be customised in an open and stepwise manner by specifying a life-cycle expression that chains together as many life-cycle extensions as needed. In addition, application developers can also write their own life-cycle extensions.
API Usage¶
Tutorial Creating a Simple RTC Component explains how to make use of the provided libraries in order to create a simple RTC Component application that runs a user-provided business logic.
Tutorial Creating a Custom RTC Component explains how to combine both framework provided and instrument specific life-cycle extensions to create custom RTC Component applications.
Limitations and Known Issues¶
Event interfaces with subscription functionality are not supported yet, this feature will be added in a subsequent release.
Other functionality such as the support of user-defined command line arguments was omitted on purpose to discourage its use for now. This will be revisited later when the CII Config Service is available and some experience is gained how it can be best integrated.