Skip to content

2 RTM Development

Graeme Bragg edited this page Jun 6, 2018 · 1 revision

This page is for runtime manager (RTM) developers to help them use the PRiME Framework with their runtime management algorithms.

The PRiME Framework manages the communication interfaces from the RTM to applications and the device. Interfaces are provided in the form of Unix Domain Sockets (UDS). The RTM, application and device run as separate processes, all on the target platform. The processes communicate asynchronously via the UDS with a message handler at both ends to parse messages. Understanding the internal operation of these interfaces is not necessary in order to implement RTM algorithms and control a system through the framework.

The RTM uses two APIs to interact with applications and devices. How to use these APIs is explained in the following sections:

Source code for the implementations of several published RTM algorithms is provided in the rtm/ folder, to illustrate how an RTM may be developed and operate within the PRiME Framework and use its API. For documentation on the function of each example RTM, as well as the applciaitons and device they are compatible with, refer to the specific wiki page:

See Application Development for information on the PRiME APP API.
See Device Development for information on the PRiME DEV API.

Application to RTM Interaction

Application processes run independently of the RTM process. API function calls made by applications are received by the RTM via a set of handler functions. These functions should be customised to set how the RTM responds to API calls.

Application Registration & Deregistration

Applications register themselves with the framework and are visible to the RTM after this point. When an application registers, its PID and a tracking ID number are passed to the RTM via the API call. This is the only information provided to identify an application. PIDs are guaranteed by Linux to be unique but may change if the application is restarted or between system boots. The tracking ID is a compile-time generated random number that is provided by the application to allow RTMs to recognise when the same application is being run again. This is of use to RTMs that use some form of learning as the learning carried out for an app can be saved and reused if the app is stopped and subsequently restarted. RTMs that support concurency may also benefit as they can identify if multiple copies of the same app are being run. As this is liable to change between different compilations of the application, it must not be used to specifically identify an application.

In the same way, applications deregister themselves with the framework and are invisible to the RTM after this point. Again, the PID is passed to the RTM via the API call in order for it to identify which application is deregistering.

Two handler functions are exposed to the RTM for these events:

Handler Function Inputs Description
app_reg_handler pid_t proc_id, unsigned long int ur_id An application registered with ID proc_id.
app_dereg_handler pid_t proc_id An application deregistered with ID proc_id.

Application knobs and monitors

Registration and Deregistration

A set of handler functions are exposed to the RTM for knob and monitor registration and deregistration events. The PID of the owning application is passed to the handler in addition to the knob itself.

Handler Function Inputs Description
knob_disc_reg_handler pid_t proc_id, knob_disc_t knob A discrete knob was registered by application with ID proc_id.
knob_cont_reg_handler pid_t proc_id, knob_cont_t knob A continuous knob was registered by application with ID proc_id.
knob_disc_dereg_handler knob_disc_t knob A discrete knob was deregistered.
knob_cont_dereg_handler knob_cont_t knob A continuous knob was deregistered.
mon_disc_reg_handler pid_t proc_id, mon_disc_t mon A discrete monitor was registered by application with ID proc_id.
mon_cont_reg_handler pid_t proc_id, mon_cont_t mon A continuous monitor was registered by application with ID proc_id.
mon_disc_dereg_handler mon_disc_t mon A discrete monitor was deregistered.
mon_cont_dereg_handler mon_cont_t mon A continuous monitor was deregistered.

Parameter Updates

A set of handler functions are exposed to the RTM for knob and monitor parameter update events. This includes updates to a knob's min, max and value parameters and updates to a monitor's min, max, value and weight parameters.

Handler Function Inputs Description
knob_disc_change_handler knob_disc_t knob A variable of this discrete knob was updated.
knob_cont_change_handler knob_cont_t knob A variable of this continuous knob was updated.
mon_disc_change_handler mon_disc_t mon A variable of this discrete monitor was updated.
mon_cont_change_handler mon_cont_t mon A variable of this continuous monitor was updated.

RTM to Device Interaction

The device process runs independently from the RTM process and it must be running for API calls to be made. The RTM acts as the master to the RTM and so the RTM instigates the API calls to the device. Functions calls are made in the standard way and can be grouped into registration & deregistration and parameter updates.

Device Registration and Deregistration

The entire platform is captured under a single device therefore there is no need for device registration or deregistration. Device knobs and monitors must still be registered and deregistered using the functions below.

Handler Function Inputs Return Description
knob_disc_reg void vector<knob_disc_t> knobs Register all discrete device knobs. Returns the address of the vector of knobs.
knob_cont_reg void vector<knob_cont_t> knobs Register all continuous device knobs. Returns the address of the vector of knobs.
knob_disc_dereg vector<knob_disc_t>& knobs void Deregister a set of discrete device knobs.
knob_cont_dereg vector<knob_cont_t>& knobs void Deregister a set of continuous device knobs.
mon_disc_reg void vector<mon_disc_t> Register all discrete device monitors. Returns the address of the vector of monitors.
mon_cont_reg void vector<mon_cont_t> Register all continuous device monitors. Returns the address of the vector of monitors.
mon_disc_dereg vector<mon_disc_t>& mons void Deregister a set of discrete device monitors.
mon_cont_dereg vector<mon_cont_t>& mons void Deregister a set of continuous device monitors.

In addition functions are provided to get the number of knobs or monitors that exist in the device.

Handler Function Return Description
knob_disc_size unsigned int Get the number of discrete device knobs
knob_cont_size unsigned int Get the number of continuous device knobs
mon_disc_size unsigned int Get the number of discrete device monitors
mon_cont_size unsigned int Get the number of continuous device monitors

Device knobs and monitors

The RTM can query the min, max, init and type parameters for a knob by calling the one of the following functions. Monitors do not have defined bounds or initial values therefore only a the type parameter can be queried.

Handler Function Inputs Return Description
knob_disc_min knob_disc_t knob disc_t
knob_disc_max knob_disc_t knob disc_t
knob_disc_init knob_disc_t knob disc_t
knob_disc_type knob_disc_t knob knob_type_t
knob_cont_min knob_cont_t knob cont_t
knob_cont_max knob_cont_t knob cont_t
knob_cont_init knob_cont_t knob cont_t
knob_cont_type knob_cont_t knob knob_type_t
mon_disc_type mon_disc_t mon mon_type_t
mon_cont_type mon_cont_t mon mon_type_t

The RTM can update the value for a knob by calling the knob_disc_set or knob_cont_set functions. The RTM can get the current value of a monitor by calling the mon_disc_get or mon_cont_get functions.

Handler Function Inputs Return Description
knob_disc_set knob_disc_t knob, disc_t val void Set the value of the discrete device knob.
knob_cont_set knob_cont_t knob, cont_t val void Set the value of the continuous device knob.
mon_disc_get mon_disc_t mon disc_t Get the value of the discrete device monitor.
mon_cont_get mon_cont_t mon cont_t Get the value of the continuous device monitor.

Clone this wiki locally