Assignment 4 - 2014

Due date(s):	28 February 2014, in class
(PDF)	Assignment questions
(PDF)	Assignment solutions

<rst> <rst-options: 'toc' = False/> <rst-options: 'reset-figures' = False/> .. rubric:: Assignment objectives: using MATLAB to simulate and test control systems; self-learning new concepts from the simulation.

.. question:: :grading: 15

#. What is the following MATLAB/Simulink simulation a representation of?

.. image:: ../figures/process-control/assignments/simulink-base-flowsheet.png :scale: 90 :width: 700px

#. Attach a copy of the ``Scope`` output for a step input of unit magnitude, occurring at a time of 2 units into the simulation. Your simulation should run until the process reaches steady state.

#. What is the final value of the ``Scope`` output variable when simulated until it reaches steady state?

Demonstrate/show/prove theoretically (i.e. without using Simulink) that this value is correct.

#. Add a time delay to the process of 2 units (as shown below) and resimulate the response to a point in time so that it reaches steady state.

.. image:: ../figures/process-control/assignments/simulink-base-flowsheet-time-delay.png :scale: 90 :width: 700px

Show the ``Scope`` output and describe what you notice.

Explain why it takes longer to reach steady state as compared to your answer in part 1.

#. Next, simulate the process with a time delay

a) of 5 units and b) of 10 units.

Attach the ``Scope`` output for these simulations, and explain why you observe the behaviour noticed.

#. In general, what do you conclude about time delays in a process?

.. answer::

#. The MATLAB/Simulink simulation is a representation of a **closed-loop** feedback **control** system with **proportional** control only of a **first-order** process. It consists of a set-point, controller, a transfer function representing the first-order process, and the output (controlled variable).

#. Please see below.

.. image:: ../figures/process-control/assignments/fig_Q2-eps-converted-to.png :scale: 80 :width: 700px

#. The final value of the output variable when simulated until it reaches steady state is 0.6 units. The overall transfer function for the system is:

.. math::

G(s) &= \dfrac{CV(s)}{SP(s)} \\ G(s) &= \dfrac{G_c G_p}{1 + G_c G_p} \\ G(s) &= \dfrac{(0.5) \dfrac{3}{2.5s+1}}{1 + (0.5) \dfrac{3}{2.5s+1}} \\ CV(s) &= \dfrac{(0.5) \dfrac{3}{2.5s+1}}{1 + (0.5) \dfrac{3}{2.5s+1}} \cdot {SP(s)} \\ CV(s) &= \dfrac{(0.5) \dfrac{3}{2.5s+1}}{1 + (0.5) \dfrac{3}{2.5s+1}} \cdot \dfrac{e^{-2s}}{s}

The above uses that the step input of unit magnitude occurs at a time of 2 units into the simulation (however you can use any time for the step to occur). Then, applying the Final Value Theorem (FVT):

.. math::

\lim_{t \to \infty} CV(t) &= \lim_{s \to 0} s CV(s) \\ &= \lim_{s \to 0} s \dfrac{(0.5) \dfrac{3}{2.5s+1}}{1 + (0.5) \dfrac{3}{2.5s+1}} \cdot \dfrac{e^{-2s}}{s} \\ &= \lim_{s \to 0} \dfrac{(0.5)(3)}{2.5s+1 + (0.5)(3)} \cdot e^{-2s} \\ &= 0.6

Note that the delay in the step input does not affect the final value.

#. The time delay simply reduces the ability of the system to react. See the graph below: at time :math:`t=2` we make the set point change of 1 unit. So immediately the error is 1 unit (blue curve). The controller takes action (yellow curve is half the values of the blue curve), but because of the time delay in the process the controller sees the error is still 1 unit. So the controller keeps supplying this 1 unit increase to the process (which was more input than was required).

After an additional 2 units of time (now we are :math:`t=4`), the system starts to react (purple curve). As CV approaches the set point, the error starts to get smaller, and so the MV also decreases (around :math:`t=7`). This reduction is later reflected in the purple CV, so it decreases. There is a bit of oscillation while it settles down.

.. image:: ../figures/process-control/assignments/fig_Q4-eps-converted-to.png :scale: 80 :width: 700px

#. If the time delay is increased to 5 units of time we observe stronger oscillations, because now there is a longer delay of 5 units (it oscillates for the reason described in the prior part). Unfortunately now the controller has to counteract that oscillation, so it starts to close the valve. Again the 2 units of delay take a while to take an effect on the process, so the controller repeats the same issue, just in the opposite direction. This leads to the oscillation you observed in the output here.

.. image:: ../figures/process-control/assignments/fig_Q5a-eps-converted-to.png :scale: 80 :width: 700px

The above is with 5 units of delay.

Once the delay exceeds some critical value we actually have made the system unstable. The controller input to the process is so strong (as it waits and waits for the system to react), that it is has changed the valve position too much. When it tries to undo the previous input, it overcompensates yet again. The amount of overcompensation is so great it destabilizes the entire system, as shown below.

.. image:: ../figures/process-control/assignments/fig_Q5b-eps-converted-to.png :scale: 80 :width: 700px

#. In general, time delays in process can reduce the stability of a closed-loop system and make it more challenging for the controller to bring the output to the steady state. Therefore, the controller may take longer to stabilize the process or system may even become unstable. When designing control systems for processes, time delays should be taken into account to achieve desired controller performance.

In fact, any control engineering will focus on how to reduce the delay by as much as possible. Delays always prevent us from taking good control action; we say "time delays are a limitation for good process performance". There is no controller that can counteract a delay (because you cannot counteract something you don't know about).

</rst>