Tutorial 8: Exposing your temperature regulator as servant for other supervisors

Now let us come back to the concept of the notification proxy-model and configure our regulator so it can be used by supervisors (while still being a supervisor to its own servants). 

We will build this:

(note that the control mode and error state of the servants are rippling up to the supervisor)

The below illustration shows what you will build in this tutorial. The red dots indicate tutorial steps.

 

While you component has a built-in supervisor (marked in green on the drawing below), you need to establish an interface to it so that the component will display the functionality you have designed to its supervisor.

This interface is established via a proxy record.

The proxy record must contain the following elements:

Required
Actual 

It is possible to rename the record elements, but remember to document such changes carefully, so other programmers can use your component.

Actual should be defined as a record and  its first element must be of data type PD_7883 - Condition_def. This is used to communicate the condition of the component.

Actual can contain e.g. component state or component value

The data type of Required and the extra fields in Actual can be adapted to the application.

Step 1:  create supervisor data.

We will now modify our temperature regulator component, so that it receives a set point from the supervisor (i.e. "Required" holds the set point) and turns Output on if the actual temperature is lower than set point. We (still) want the regulation mechanism to run whenever the actual temperature has changed (ie. Actual.Actual_temperature contains the temperature read from the servant Temperature) or the set point has changed

Open your control component XX_Temperature_Regulator_Notification

Create a new volatile variable based on the data type PD 17514 XX_data_type_for_supervisor_for_temperature_regulator.

Note that we have renamed Required to "Set_Point".

Assign the variable to the Supervisor in your temperature control component.

Note that Set_point and Actual_rec.Actual_temperature are of type [Absolute temperature]. 

Step 2: Adjusting the regulating algorithm

Our regulation must run when

  1. the actual temperature (measured by the servant component "Temperature" changes, i.e. the same mechanism that we implemented in a previous tutorial.
  2. the set point changes. The set point will be provided by the supervisor via the register "Required" and the method "Required_changed".

We already implemented the first element (in calculate actual of the control component):

 

So we can move on to the second element.  Find the method "Required_changed" in XX_Temperature_Regulator_Notification. Right click and press "OVERRIDE". 

You need to read the new setpoint (ie. Required) into the local variable and then run the regulation (ie call method calculate actual).

Your code in "Required_changed" should look like this:

 

Calculating the condition

The condition of a component is calculated from the error state of the component and the condition of its servants.

The condition of an lower level servant is automatically rippling up to higher level supervisors.

Step 3: calculating the condition

Our temperature regulator has two servants i.e. temperature and output. For this tutorial we will assume that the control component itself cannot generate any errors, so the condition of the control component is calculated from the conditions of the two servants.

Open your control component "XX-Temperature_regulator_notification" Open method "Calculate actual".

Write your code so that the condition of the component is the larger of the two servant conditions.

code to add:

 

The method "Calculate_actual" needs to follow a specific format in order for the supervisor-servant methodology to work

We already handled step 1 (the regulation algorithm).  This step can be elaborated much more to take into account errors, control mode and servant information. But we will leave that for a later tutorial.

We also handled step 2 (assumed no errors) and step 3 (calculate the condition).

So all we need to do to finalise the format is step 4 where we update the Actual record (which inform the supervisor of the new data).

Step 4: Updating the Actual record.

Our Actual record contain two records: Condition and Actual_temperature.

 

We already sent the condition (via the SetCondition method) so all we need to do is update Actual. And recall that this value needs to be the actual temperature as read by the servant "Temperature".

Code to add:

 

 

Your total code in "calculate actual" needs to look something like this:

 

Having completed the changes to the component, we now need to make the updates to the visualisation.

Step 5: Update your visualisation.

Open the view "Button_for_XX_temperature_regulator_notification_assembly"

Right click on view list - add - view for control instance - find the supervisor of XX-temperature_regulator_notification- actual rec- condition, double click and select "PD_15375 - Show_Condition_without_auto_state".  Set "Disable hit test". This will avoid the opening of the default window for this data type.

Launch the graphical editor and drag the condition visualisation to a suitable position. 

Your visualisation should look something like this:

We have now prepared our temperature regulator component to be controlled by a supervisor, but it can (of course) still run on its own. And now the component can display its condition (that we calculated in step 3), so let us explore this before moving on.

Step 6: Save, build and run your project.

Open your project ""XX_Temperature_Regulator_notification_project". Save, build project, start project downloader (make sure your test bed is still connected and that the PC device is started) and config all modules.

Open the different views, change control mode of temperature and output and notice how the control mode of our temperature regulator changes accordingly.

In our next tutorial we will build a supervisor that can control our temperature regulator.