Projects
This is the course website for Håvard Kråkenes, student number 220888, in the course Systems and Control Laboratory - IIA4217 as part of the Online Master of Science in Industrial IT and Automation at the University of South-Eastern Norway.
The background for this report is to make an embedded Arduino PI controller with IoT connectivity for a physical airheater process. It will be developed and tested using hardware in the loop principles, and will be tested against a software simulator since the physical airheater is not available remotely.
In this report the task is to control the simulated/physical airheater using an embedded arduino PI controller. The simulated airheater is a “Black Box simulator” meaning we can not look at its inner workings or code. The physical system is not available at the time of this report, so that will be tested at a later date.
The simulator setup will communicate with the arduino controller over serial communication. The arduino will have two modes: Analog I/O and Serial I/O.
IoT will be implemented in the system in the form of Thingspeak, which is a platform where you can send and retrieve sensor data and do data analysis in the cloud. Since the Arduino in use does not have Wi-Fi capabilities, the communication to Thingspeak is done in LabVIEW on the simulator.
A overview of the system including communication can be seen in Figure 1 below.
Figure 1: Process drawing
The LabVIEW software has been adapted from the previous project. OPC functionality has been removed and replaced with serial communication and thingspeak. The simulator can chose between software and hardware regulator, as well as black box and model process.
When running in “Arduino” mode, it initializes serial communication with the Arduino at a baud rate of $4000000$ and a timeout of $250ms$. The values $y$, $Kp$, $Ti$ and $r$ are sent to the Arduino and output from the controller and $u$ is received back. Serial was chosen because no DAQ device was available.
Some hickups has been discovered when using Serial; it slows down the whole LabVIEW program. It waits until it receives the serial payload from the Arduino before continuing, so the 100ms loop time is greatly increased during simulation. Though the calculations is still valid because it in practice runs everything in $100ms$ sample time, the real time plotting and response seems much slower.
This means that using serial in this way is only usable towards software, and the physical process should not be implemented in the same solution. For testing and hardware in the loop against a simulator it works great.
See Figure 2 below for a “schematic” of the LabVIEW application.
Figure 2: LabVIEW schematics
The LabVIEW files can be found on the link at the bottom of this report.
The Arduino board used in this project is the standard Arduino UNO. It is programmed with two modes, Analog I/O and Serial I/O. This is chosen with a button with a LED showing the chosen mode. A OLED display is also attached to show the current mode, controller parameters and input/output values.
In analog mode it reads input voltage from a designated AI pin, runs the PI controller algorithm and outputs $0-5V$ analog. Analog output is implemented using two different methods; PWM and DAC. The PWM output is filtered with a lowpass filter to convert it to DC using a RC circuit with values $100µF$ and $1kΩ$ as these values was available and gave a good result. The DAC chip used is a MCP4921 12 bit dac which is connected using the SPI protocol.
The OLED display is connected to the Arduino using the I2C protocol.
Since the physical airheater is not available at the time of writing this report, the input in analog mode is simulated with a potmeter to the analog input pin, simulating a $1-5V$ input.
The mode selector is a simple if else selector, based on the value of the toggle state of the button. The code for the serial mode can be seen below:
else // ALL CODE FOR SERIAL HARDWARE IN THE LOOP GOES HERE
{
digitalWrite(ledPin, LOW);
analogWrite(outputPin, 0);
myDac.analogWrite(0);
// check serial
if ( Serial.available() ){
// Read serial string
readSerial = Serial.readString();
// Index string and get variables
ind1 = readSerial.indexOf(','); //finds location of first ,
y = readSerial.substring(0, ind1).toFloat(); //captures first data String
ind2 = readSerial.indexOf(',', ind1+1 ); //finds location of second ,
sp = readSerial.substring(ind1+1, ind2+1).toFloat(); //captures second data String
ind3 = readSerial.indexOf(',', ind2+1 ); //finds location of third ,
kp = readSerial.substring(ind2+1, ind3+1).toFloat(); //captures third data String
ind4 = readSerial.indexOf(',', ind3+1 ); //finds location of fourth ,
ti = readSerial.substring(ind3+1, ind4).toFloat(); //captures fourth data String
}
// PI Controller get new output
uk = pi.ctrl(y,sp);
// Send u over serial
Serial.println (uk);
// Update display mode
display.println(F("Mode: Serial"));
}
In serial mode the analog inputs and outputs are disabled and it instead sends and receives the data with serial over USB. As seen in the code above, the Arduino first sets the led light low, analog outputs to zero and then reads serial if available. Since the serial message is a string, the next part is to decompose the string and extract the different values from the string. The PI controller is then ran based on the values received over serial, and the output of the controller, $u$, is sent back over serial. Lastly the display mode is changed after the first iteration of the serial mode. The rest of the screen is updated on a general basis for both modes, and can be seen in the source code.
The controller is implemented as a arduino library with built in filter function. The source code for this library can be seen here: PI Controller Library
A sketch of the Arduino circuit can be seen in Figure 3 below.
Figure 3: Arduino circuit schematics
A picture of the actual Arduino circuit can be seen in Figure 4 below.
Figure 4: LabVIEW hardware in the loop plot
The Arduino source code can be seen here: Arduino Code
The Embedded controller is tested and controller parameters fine tuned using hardware in the loop principles. This means involving the hardware controller into a software simulator to test that the controller works as expected before using it on the actual process.
This was done using the serial communication described in the chapters above. Since the PI algorithm from a code standpoint is the same as the previous project, the same PI parameters is used. These are: $K_{p}=1.2, T_{i}=12s$
A plot of the control loop using hardware in the loop can be seen in Figure 5.
Figure 5: LabVIEW hardware in the loop plot
After hardware in the loop testing, the analog input and output was tested using a multimeter to measure output voltage, and using a potmeter to adjust the simulated input voltage. This can also be easier seen on the attached OLED display.
The test is done just to verify that the analog code works as expected before connecting it to the physical process later.
Thingspeak communication is implemented in the LabVIEW application. This is done since the only Arduino at hand was a UNO without ethernet or Wi-Fi. This also means that thingspeak only works in serial mode. As a proof of concept this works well, but for making a production embedded controller with IoT connectivity one would want to use an Arduino with on-board Wi-Fi and more memory.
Two different channels is made in Thingspeak, one for plotting and storing history, and one for updating the control parameters.
The first channel are updated by sending $y$, $u$, $r$, $Kp$ and $Ti$ from LabVIEW. The values are sent to Thingspeak using MQTT where it publishes all 5 values at once. There is a limit to thingspeak free plan that only supports updating the value every 15 seconds, so the data is of low resolution.
Figure 6: Thingspeak GUI of channel 1
The second channel are read by LabVIEW using HTTP with a GET request. It gets the last value of both $Kp$ and $Ti$ as CSV and updates the values in the running VI. On Thingspeak the values can be updated using a GET request in the web browser, so the parameters can be updated from anywhere in the world. There is a separate while loop in LabVIEW for reading from Thingspeak, this is because the HTTP requests take longer and slows down the VI, and so the separate while loop has a longer sampling time. Details can be seen in Figure 2 or in the source code. A screenshot of this channel on Thingspeak can be seen in Figure 7.
Figure 7: Thingspeak GUI of channel 2
MQTT was chosen for writing instead of HTTP because HTTP was not reliable for this use case. This was because the response time was too big compared to the 100ms loop timer, and thus slowed down the whole VI. MQTT solved this by being responsive and fast without hiccups.
All in all it works great. Using a premium plan would enable high frequency MQTT publishing which would help a lot.
The implementation which is done here can be said to be quite secure, especially when the Arduino is in stand alone mode. The serial protocol in use is not safe at all, especially since it is over USB. If anyone got physical access to the device or the serial cable, they could inject faulty values for the controller, or in worst case reprogram the device. This can however easily be avoided by having control of the physical location of the hardware.
As for Thingspeak there would be possible to hijack this traffic, but the attacker would then need the private write codes on Thingspeak. This can therefore be considered safe.
In this report we have implemented an IoT embedded controller as a proof of concept. This shows how easy it is to make small embedded circuits and IoT gadgets in modern times. Some problems occured by not having the right hardware and software licensing, but all in all it shows the general idea of how it should work.
All the files for this project can be seen here: Project files
The background for this report was to make a simple control and monitoring system for for a airheater using known industry 4.0 and IoT technology. The airheater is a physical system made for use in a lab environment, but in this case a simulator of the physical system was used. A schematic of the airheater system can be seen in Figure 1 below.
Figure 1: Air Heater System
In this report the task is to control the simulated airheater in Matlab Simulink using a PI controller. The simulated airheater is a “Black Box simulator” meaning we can not look at its inner workings or code. The simulator is however supplied with a mathematical model.
The step response method is used on the transfer function of the mathematical model to find a parametrized model which replicates the black box.
Frequency response analysis and Stability analysis is used to find optimal controller parameters for controlling the airheater. The controller is then implemented as C code inside Simulink.
The temperature output of the airheater model are be stored in a database and used for data analysis. This is accomplished by using modern IoT technologies including OPC UA, Azure SQL Server and a web application using .NET Core hosted on Azure App Services.
A flow of the applications can be seen in Figure 2 below.
Figure 2: Application system flow
The mathematic model for the airheater can be seen in equation 1.
\[\dot{T}_{out}=\frac{1}{\Theta_{t}}\left \{ -T_{out}+ \left [ K_{h}u\left ( t-\Theta _{d} \right ) +T_{env}\right ]\right \}\tag{1}\]The equation is then rearranged to a the transfer function shown in equation 2.
\[H\left ( s \right )=\frac{K_{h}}{\Theta _{t}s+1}e^{-\Theta _{d}s}\tag{2}\]The model parameters are found using the step response method on the black box model as shown to the left in Figure 3.
Figure 3: Step response of black box model (left) and final model fit (right)
The final model parameters are derived by trial and error. The final parameters are: $\Theta_{t}=22s, \Theta_{d}=2s, K_{h}=3.5$ and can be seen in use to the right in Figure 3.
The transfer function of the PI controller can be seen in equation 3.
\[h_{c}\left ( s \right )=\frac{K_{p}T_{i}s+K_{p}}{T_{i}s}\tag{3}\]Parameters for the PI controller is found using Ziegler Nichols method along with trial and error. Ziegler Nichols method is used on the combined transfer function of the system and controller. The ZN parameters is then found to be approximately: $K_{c}=5.12, T_{c}=\frac{2\pi}{\omega_{180}}=7.73s$ Thus, the parameters for the PI controller should become: $K_{p}=0.5K_{c}=2.56, T_{i}=\frac{T_{c}}{1.2}=6.44s$.
However, by testing and analysing this is not a very good fit as the system oscilates. The Gain Margin and Phase Margins is also at the edge of what is acceptable.
Trial and error reveals the best controller parameters to become: $K_{p}=1.2,T_{i}=12s$. Testing of the controller on the black box model can be seen in Figure 4.
Figure 4: Step response with tuned PI controller
A bode plot of the combined system can be seen in Figure 5 below. From the figure we can see that $\omega_{c}=0.202rad/s$, $\omega_{180}=0.761rad/s$, $GM=12dB$ and $PM=57.2°$.
Since $\omega_{c}<\omega_{180}$ the system is asymptotically stable.
The Gain Margin (GM) and Phase Margin (PM) are both within the “Golden Rules”, though the Gain Margin is at the edge of the range. $GM: 6dB<GM<12dB$, $PM: 30°<PM<60°$
Figure 5: Bode diagram of complete system, GM and PM within OK limits
The code for the bode plot can be seen below.
% Define Constants
t=22;
td=2;
Kh=3.5;
Ti=12;
Kp=1.2;
% Define Transfer functions
num1=[Kh];
den1=[t, 1];
Hp = tf(num1, den1, 'InputDelay', td);
num2=[Kp*Ti, Kp];
den2=[Ti, 0];
Hc = tf(num2, den2);
L = series(Hc, Hp);
% Frequency Response
margin(L);
grid on
There is a total of three LabVIEW programs used for this report. The main controller application which controls the air heater and sends log data to an OPC-UA server, the OPC-UA server and the OPC-UA client which reads from OPC-UA and transmits the data to an Azure SQL server.
Figure 6: GUI of controller application
An overview of the GUI of the controller application can be seen in *Figure 6. The different tabs allows the user to change settings of the application, including model parameters, controller parameters and opc connection details.
Figure 7: Code of controller application
The inner workings of the LabVIEW application can be seen in Figure 7 including the PI controller, the blackbox model, “simulator” of black box model and OPC-UA connection.
The C code for the controller can be seen below.
//PI algorithm
float error;
float integral;
float uk;
error = sp - y;
integral = integral1 + error * dt;
uk = Kp*error + Kp / Ti * integral;
if (uk > OutputMax)
{
uk = OutputMax;
}
if (uk < OutputMin)
{
uk = OutputMin;
In Figure 8 the OPC-UA server gui and code can be seen. This is just a OPC-UA server running locally on the same machine as the controller.
Figure 8: OPC-UA Server
In Figure 9 the OPC-UA and SQL client gui and code can be seen. The application reads the latest value from the local OPC-UA server and transmits it to the cloud based Azure SQL server.
Figure 9: OPC-UA and SQL client
The Azure SQL server has two tables, one view and one stored procedure. The SQL query used to initialize the database can be seen below:
The full code for initializing the database can be seen here: SQL Code
Monitoring of the stored data values is implemented in a ASP.NET Core web application hosted on Azure Web Services. The logging application can be accessed here: Labdata
Figure 10: ASP.NET Core monitoring web application
A screenshot of the web application can be seen in Figure 10. It receives the last 1000 values from the database and plots it. This is a basic single page application with basic features and some styling done with bootstrap. For this implementation it was concidered to be “good enough” for showing temperature data. A table showing all the 1000 data points can be opened by clicking the button on the page.
There are many applications, interfaces and technologies at work in this setup. They all speak with each other and fulfill its own task as a standalone application and talking with the other via known industry protocols. The usage of a cloud infrastructure such as Azure shows how easy it is to move applications from large local servers to the cloud, this also means that the applications can be scaled up almost infinitely. Industry 4.0 is definately the way to go for easy 24/7 online monitoring.
All the files for this project can be seen here: Project files