Dynamic Reconfiguration

Real-time code generated for a model is managed on the target by a management system called the QUARC Target Manager. It is the QUARC Target Manager that allows generated real-time code to be seamlessly downloaded and run on the target from Simulink. One of the advanced features of this management system is the support for dynamic reconfiguration. Dynamic reconfiguration refers to dynamically switching models on the target machine. A model may be replaced with another model while it is running with no interruptions.

Furthermore, you can transfer data from one model to another model at the time of switch. In other words, the states of the model switching out can be transferred to the model switching in at the sampling instant when the switch occurs. This transition is very useful since you might want to manipulate the data from the model switching out in the new model in place. Consider the following situation; there are two control models responsible for controlling a robot and they cannot be running at the same time. One controller model is for normal operation of the robot (normal controller). The other one is for emergency situations such as the robot going unstable (emergency controller). The normal controller would always be running unless an emergency situation occurs. In these situations, you want to switch in the emergency controller transferring states from the normal controller and manipulate them before taking any actions. This is made possible with the state transition capability of QUARC when using dynamic reconfiguration feature.

You can also sort the models into different reconfiguration groups and specify from which group you want to switch out a model. Consider the following example; there are four models responsible for one type of normal operation (type 0) of an Unmanned Arial Vehicle (UAV) and they can be running one at a time. There are also another 4 models for another type of normal operation (type 1) of the UAV and they can also be running one at a time. There is another model for emergency situations such as a wing falling apart or a motor not functioning. In an emergency situation, you want to switch in the emergency model and switch out any of the models responsible for normal operation. The only information you have about the model to switch out is the type of the normal operation it is responsible for (type 0 or type 1). What you can do is to put type 0 models in reconfiguration group 0 and type 1 models in reconfiguration group 1. This grouping allows you to specify the reconfiguration group from which you want to switch out a model, having known the type of normal operation prior to the emergency situation. As you can see, with the reconfiguration groups, you do not need to worry about knowing which model to switch out, but the reconfiguration group it belongs to.

When sorting models into reconfiguration groups, always make sure that no more than one model is going to be running at one time in a reconfiguration group. This is due to the fact that if more than one model are running simultaneously and they all belong to the same reconfiguration group, QUARC randomly chooses a model to switch out. Now if QUARC chooses the wrong model to switch out, your system might become unstable and stop responding.

All the blocks used for dynamic reconfiguration can be found under the QUARC Targets/Advanced/Dynamic Reconfiguration library in the Simulink Library Browser. You can use these blocks to perform dynamic reconfiguration of your models with the capabilities mentioned above. For information on these blocks, please refer to the Dynamic Reconfiguration Blocks reference page and choose from the list of blocks.

You should include the blocks mentioned above in your models in order to be able to use different features of dynamic reconfiguration. For example, in order to trigger a Function Call Subsystem at the time of switching out of a model, you need to include the Switching Out block in that model. This block would trigger the subsystem at the time of switch and you can perform different tasks in that subsystem prior to switching in to a new model. For data transitions, as another example, you need to include the State Output and State Input blocks in your models. After creating the models, you need to modify two configuration parameters to enable the support for dynamic reconfiguration. The last step would be to perform dynamic reconfiguration using either a MATLAB command or a supervisory model.

Use the following list to refer to each one of the topics discussed above.

• Creating Models to Support Dynamic Reconfiguration
• Simulating Dynamic Reconfiguration
• Dynamic Reconfiguration Using the MATLAB Command Window
• Dynamic Reconfiguration Using a Supervisory Model

Creating Models to Support Dynamic Reconfiguration

This section provides details on how to create models that support different capabilities of dynamic reconfiguration using the dynamic reconfiguration blocks in addition to the two configuration parameters' modifications needed to enable this feature.

Two example models are described in this section to demonstrate how to use dynamic reconfiguration blocks in your models in order to use all the capabilities of this feature. These two models are also used in the later sections to demonstrate how to perform dynamic reconfiguration. Please refer to the QUARC Dynamic Reconfiguration Demo reference page in the MATLAB Demo section to open these models.

The first example model which is the model being switched out is depicted in the following figure.

This model is called "quarc_dynamic_reconfiguration_demo_model_1" and contains a Switching Out block since it would be the model being switched out. However, in case you want to switch back to this model at a later time and trigger a Function Call Subsystem block, you could also include a Switching In block. Notice that a Function Call Subsystem block is attached to the output of this block. Every time the switch occurs, the Switching Out block triggers the subsystem. Figure below depicts the contents of the subsystem.

There is a State Output block inside the subsystem. This block would write the state of its input to a memory location (in this case called sine_wave) at the time of switch. This memory location would then be used by the State Input block in the model being switched in to read the state from the switched out model. The reason this block is put in the Function Call Subsystem block is due to the fact that we want it to execute only at the time of switch. If you put this block at your top level diagram, it would get executed at the start of the model and continuously write the state of its input at every sampling instant which is unnecessary unless the sampling instant is actually the one in which the switch occurs. The input of this block is the input to the Function Call Subsystem block which in turn is the sine wave itself. This means that the state of the sine wave would get written to the specified memory location at the time the switch occurs.

The second model which is the one being switched in is depicted in the figure below.

This model is called "quarc_dynamic_reconfiguration_demo_model_2" and contains a Switching In block since it would be the model being switched in. However, in case you want to switch out of this model at a later time and trigger a Function Call Subsystem block, you could also include a Switching Out block. Notice that a Function Call Subsystem block is attached to the output of this block. Every time the switch occurs, the Switching In block triggers the subsystem. Figure below depicts the contents of the subsystem.

There is a State Input block inside the subsystem. This block would read the state of its input from a memory location which, in this case, is called sine_wave to correspond to the memory location used by the State Output block of "quarc_dynamic_reconfiguration_demo_model_1" at the time of switch. Specifying the same name for both State Output and State Input blocks would cause these two blocks to comprise a shared associative memory. For each state you want to read/write, you should have one pair of these blocks with the same name specified for the state. The reason the State Input block is put in the Function Call Subsystem block is due to the fact that we want it to execute only at the time of switch. If you put this block at your top level diagram, it would get executed at the start of the model and continuously read the state of its input at every sampling instant which is unnecessary unless the sampling instant is actually the one in which the switch occurs. The output of this block would get amplified by a gain of 10 using a Gain block. This amplification is to demonstrate the fact that you could manipulate the transferred state at the time of switch before actually using it in the model being switched in. This amplified signal becomes the output of the Function Call Subsystem block which is the state of the sine wave at the time the switch occurs amplified by a factor of 10.

In order to divide your models into different reconfiguration groups, all you need to do is to insert one Reconfiguration Group block in to each one of your models and specify the Group identifier parameter. This parameter is the reconfiguration group number for that model. If the model does not have this block, QUARC assumes that it belongs to the reconfiguration group 0. For example, the "quarc_dynamic_reconfiguration_demo_model_1" and "quarc_dynamic_reconfiguration_demo_model_2" models both belong to the reconfiguration group 0. To change "quarc_dynamic_reconfiguration_demo_model_1" reconfiguration group to 1, you need to insert the mentioned block and change its Group identifier to the value 1 as shown below in the figure.

Note: Not including the dynamic reconfiguration blocks would not disable the support for this feature. You can still perform the switch between your models. The only effect it would have is that you cannot use different capabilities of the feature such as data transition.

Once the models are created, it is time to go through the setup needed to enable dynamic reconfiguration. There are two configuration parameters that need to be set in order to enable dynamic reconfiguration for your models. These two parameters are the following; Support dynamic reconfiguration and MEX-file arguments.

Use any of the methods mentioned in the Configuring a Model section to open the Configuration Parameters dialog box. Under the Code Generation/QUARC pane, enable the Support dynamic reconfiguration parameter by clicking on the check box besides it as shown in the figure below.

This option would enable dynamic reconfiguration support for your model. You have to enable this option for all your models using dynamic reconfiguration.

The next parameter you need to modify is the MEX-file arguments parameter found under the Code Generation/Interface pane. For information on this parameter, you can refer to the MEX-File Arguments reference section. For the model arguments, one of the default options included is the "-w" option. Including this option causes real-time code to wait until host connects to it before starting. Delete this option from the model arguments as marked in the figure below.

Excluding this option causes the real-time code to start immediately after it is loaded on the target. It is necessary to exclude this option since you want the model switching in to start right after it has been switched in on the target. If you do not delete this option, QUARC loads the real-time code for the model switching in trying to start it while the real-time code itself is waiting for the user to start it. The switching would not take effect unless the user connects to the real-time code of the model to switch in and starts it (you always need to connect to the code before being able to start it). This behavior is undesirable since you want the switched in model to automatically start.

You have to modify these two parameters for all the models involved in dynamic reconfiguration process. Once the changes have been made, click on Apply and then OK and finally build your models using one of the methods mentioned in the External Mode Operation section of the QUARC documentation.

Simulating Dynamic Reconfiguration

Once models have been configured to support dynamic reconfiguration, it is obviously advantageous to be able to simulate the process of switching between models, to ensure that the transition from one model to the next is going to occur smoothly, with states properly transformed from one model to the next. Fortunately, QUARC provides the ability to simulate the process of dynamically switching between models using the qc_simulate_switch_to_model command. Suppose a model called "quarc_dynamic_reconfiguration_demo_model_1" is currently running in normal simulation and is assigned to reconfiguration group 0 (no Reconfiguration Group block is present in the diagram). To switch from "quarc_dynamic_reconfiguration_demo_model_1" to a model called "quarc_dynamic_reconfiguration_demo_model_2" (which is not running at present), enter the following command at the MATLAB command prompt:

qc_simulate_switch_to_model('quarc_dynamic_reconfiguration_demo_model_2');

If "quarc_dynamic_reconfiguration_demo_model_1" belonged to reconfiguration group 2, by adding a Reconfiguration Group block to the diagram assigned to group 2, then the command to switch models would be:

qc_simulate_switch_to_model('quarc_dynamic_reconfiguration_demo_model_2', 2);

QUARC will stop the "quarc_dynamic_reconfiguration_demo_model_1" simulation, and open "quarc_dynamic_reconfiguration_demo_model_2" and begin running it in simulation. The states will be transferred between the two models and the Switching In and Switching Out subsystems executed as appropriate. The states are passed from one model to the next through the MATLAB workspace as variables so that you can examine the values of the states during the transition.

When simulating dynamic reconfiguration, it may be useful to slow down the simulation to real-time in order to view the progress of the simulation. If a hardware timebase is not being used, then the System Timebase may be added to the model to make it run in "real-time". See the System Timebase block reference page for details.

If a hardware timebase is being used, then check the Active during normal simulation option of the HIL Initialize block so that the hardware timebase is used to slow down the simulation to "real-time".

For more information about simulating dynamic reconfiguration, refer to the reference page for the qc_simulate_switch_to_model function.

Dynamic Reconfiguration Using the MATLAB Command Window

One of the methods to perform dynamic reconfiguration (switch between models) is to use a specific QUARC MATLAB function called qc_switch_to_model. For information about this function, you can refer to qc_switch_to_model function reference page. This section provides details on how to use this function to switch between models. The models used as examples in this section are "quarc_dynamic_reconfiguration_demo_model_1" and "quarc_dynamic_reconfiguration_demo_model_2" from the Creating Models to Support Dynamic Reconfiguration section above.

Once the two models are built, connect to the real-time code for the model to be switched out ("quarc_dynamic_reconfiguration_demo_model_1") and run it. Since you do not want the model being switched in ("quarc_dynamic_reconfiguration_demo_model_2") to start until the switch occurs, do not run "quarc_dynamic_reconfiguration_demo_model_2". You can now type the following line in the MATLAB command window in order to switch out "quarc_dynamic_reconfiguration_demo_model_1" and switch in "quarc_dynamic_reconfiguration_demo_model_2":

qc_switch_to_model('quarc_dynamic_reconfiguration_demo_model_2');

Notice that "quarc_dynamic_reconfiguration_demo_model_1" model is stopped and the scope does not trace the sine wave anymore. You would also notice that "quarc_dynamic_reconfiguration_demo_model_2" model window indicates that the model has not started running yet. This is due to the fact that you are not connected to the real-time code yet. It does not mean that the code itself has not started running. In fact, if you connect to the real-time code, you will notice that the model has started running and if you check the scope for the Function Call Subsystem block output (which is the transferred state), it will indicate the value of the sine wave at the time of switch (you might want to Autoscale the scope since the transferred value has been multiplied by 10). You can verify that the value of the transferred state is indeed correct by looking at the scope for "quarc_dynamic_reconfiguration_demo_model_1" and read the value at the time it has stopped tracing. This value should be the same as the one shown on the scope for the transferred state in "quarc_dynamic_reconfiguration_demo_model_2". Figures below correspond to "quarc_dynamic_reconfiguration_demo_model_1" model scope and "quarc_dynamic_reconfiguration_demo_model_2" model's transferred state scope respectively after a switch has occurred.

As you can see, the first scope indicates a value of close to 1 at the time the switch occurred. The second scope shows the same value multiplied by 10.

When using the qc_switch_to_model function, only passing the name of the model you want to switch in would cause QUARC to assume that the model to be switched out is from reconfiguration group 0 by default. In order to specify another reconfiguration group such as group 2 to switch out a model from, you should type the following in the MATLAB command window:

qc_switch_to_model(modelname,2);   %modelname is the name of the model

As mentioned earlier, if two models from the same reconfiguration group are running and you want to switch in a new model, QUARC picks one of the models randomly and switches it out while the other one would still be running. Now if the wrong model is picked, the system might stop responding and become unstable. Therefore, you always have to make sure that no more than one model is going to be running at one time in a reconfiguration group, when sorting models into reconfiguration groups.

Dynamic Reconfiguration Using a Supervisory Model

One of the methods to switch out running models and switch in new models to be run is to use a supervisory model that always runs at background, responsible for dynamic reconfiguration of the models available. The target blocks found under the QUARC Targets/Advanced/Dynamic Reconfiguration are to be used to perform dynamic reconfiguration using a supervisory model. The target blocks include Target Download Model, Target Load Model, Switch to Model and Target Connect.

The Target Connect block should always be included in a supervisory model. It connects to a target specified in the block parameters from the supervisory model. Connecting to a target using this block is similar to connecting to a real-time code from a Simulink diagram. The difference is the fact that you only connect to a particular model's real-time code running on a target when connecting from the model window, while Target Connect connects to a target itself from a model. Target Switch Model performs the same operation as the qc_switch_to_model function. It switches any model running on the target connected to by a Target Connect block from a specific reconfiguration group with a new model specified in the block parameters. Target Download Model and Target Load Model blocks are for downloading and loading a real-time code to the target connected to by a Target Connect block. For more information about these blocks, please refer to their reference pages by right clicking on each block in the model window and choosing the Help menu item.

An example model is used in this section to demonstrate how to use the above mentioned blocks in order to create a supervisory model. Please refer to the QUARC Dynamic Reconfiguration Demo reference page in the MATLAB Demo section to open this model.

The following figure depicts the example supervisory model called "quarc_dynamic_reconfiguration_demo_supervisor".

The model contains a Target Connect block that connects to the local target using shared memory protocol. The following figure shows this block's parameters dialog.

The important parameter in this dialog is the Connection name which is used by other target blocks to perform tasks on the specified target. For information about other parameters, please refer to the Target Connect block reference page.

Notice there is a Triggered Subsystem block in our supervisory model. The switch takes place inside this subsystem every time you click on the "Manual Switch". The Triggered Subsystem block gets triggered by either falling or rising edge of its trigger input. Therefore, every time you switch from constant 0 to constant 1 or the other way around, the subsystem gets triggered. Figure below depicts the contents of this subsystem.

There is a Target Switch Model block inside this subsystem in addition to the trigger input. The Target Switch Model block, as mentioned earlier, performs the switch (dynamic reconfiguration) using its parameters specified by the user. Figure below depicts the block parameters dialog.

The Connection name parameter corresponds to the connection name specified by the Target Connect block in the model. It tells the block that the target on which to perform the switch is the one connected to by the Target Connect block. The Name of model to switch in parameter is the name of the model you want to switch in (in our case, it is "quarc_dynamic_reconfiguration_demo_model_2"). Reconfiguration Group corresponds to the group you want to switch out a model from. For other parameters' descriptions, please refer to the Target Switch Model block reference page.

The reason for having a Triggered Subsystem block and performing the switch inside that subsystem is that if the Target Switch Model block is put at the top level, the switch would occur the moment you start the supervisory model. But what we want is to control the time of switch manually. Therefore, the block is put inside a triggered subsystem in order to make it possible for the user to perform dynamic reconfiguration by clicking on the "Manual Switch" (this is a good method to make the switch operation manual, although not the only way to do it).

From the above sections, we know that the first model belongs to reconfiguration group 1 while the second model has value of 0 as its reconfiguration group. Note that the supervisory model also belongs to reconfiguration group 0. This way, switching out the first model and switching in the second one does not produce any errors. However, if the grouping was the other way around for the two test models (not the supervisory model), you would get errors attempting to perform the switch. The reason is that the first model would be in group 0 along with the supervisory model. While both models would be running, QUARC would pick one of these models randomly to switch out. It might in fact pick the supervisory model to switch out which is not desired. Thus, it is very important to take extra care when sorting models into different reconfiguration groups.

Once you have created the supervisory model along with your actual models to perform dynamic reconfiguration on, build them and run your supervisory model along with the model to be switched out later on. By clicking on the "Manual Switch" in the supervisory model, you can now switch to a new model. If the models that are being used are "quarc_dynamic_reconfiguration_demo_model_1" and "quarc_dynamic_reconfiguration_demo_model_2", you can verify the validity of switch by following the steps discussed in the Dynamic Reconfiguration Using the MATLAB Command Window section.

As mentioned earlier, if two models from the same reconfiguration group are running and you want to switch in a new model, QUARC picks one of the models randomly and switches it out while the other one would still be running. Now if the wrong model is picked, the system might stop responding and become unstable. Therefore, you always have to make sure that no more than one model is going to be running at one time in a reconfiguration group, when sorting models into reconfiguration groups.

Copyright ©2024 Quanser Inc. This page was generated 2024-04-16. Submit feedback to Quanser about this page.

Link to this page.