Determining the Usability of Embedded

Devices Based on Raspberry Pi

and Programmed with CODESYS
as Nodes in Networked Control Systems

Jacek Stój(B) , Ireneusz Smolka, and Michal Maćkowski

Institute of Informatics, Silesian University of Technology,

Akademicka 16, 44-100 Gliwice, Poland
{jacek.stoj,ireneusz.smolka,michal.mackowski}@polsl.pl

Abstract. Since introduction of the Raspberry Pi embedded comput-

ers to the market, its popularity is constantly growing. More and more
both hardware and software modules are available for that device. One
of the later ones is CODESYS development environment, which make
it possible to program Raspberry Pi like a regular Programmable Logic
Controllers PLC. Using its network interfaces and industrial protocols
like Ethercat or Profinet available in CODESYS, too, one could con-
sider using Raspberry as a node in Networked Control System. Posts
and opinions shared on Internet forums proofs it. However, one thing
should not be ignored – Raspberry has been never intended to be imple-
mented in industrial environment and was not designed as a real-time
device. Therefore before practical application of Raspberry Pi, its tem-
poral characteristics should be analyzed. It is the main concern in the
following chapter.

Keywords: Raspberry PI · Real-time · Industrial system

Networked control system · CoDeSys · Arduino · LabView
Embedded devices

1 Introduction
In recent years it could be observed that more and more various embedded
devices are available on the market. They are supplied by many vendors in
numerous configurations referring to their hardware components – integrated or
available as options. As a result embedded devices are implemented in many
areas in great range of different applications like building automation [1,2], data
processing [3], image acquisition processing [4], distributed computer systems
[5] or Internet Of Things [6] to name only few. Generally speaking, embedded
devices are most often used in Cyber-Physical Systems.
The above examples refer to one of the most recognizable embedded devices –
Raspberry Pi. That specific device is unique and worth mentioning also because
c Springer International Publishing AG, part of Springer Nature 2018
P. Gaj et al. (Eds.): CN 2018, CCIS 860, pp. 193–205, 2018.
https://doi.org/10.1007/978-3-319-92459-5_16
194 J. Stój et al.

of the possible ways of programming it. The Raspberry Pi programmer can use
basic programming languages like Python or C. Independent companies (e.g.
Microsoft, Google, Ubuntu) offer their own operating systems and let create
programs in languages like Java or C#. Another option of Raspberry Pi pro-
gramming is CODESYS - Controller Development System.
CODESYS development environment is dedicated to automation applications
for industrial controllers. It is the base of many other development environments,
which are used for programming Programmable Logic Controllers, e.g. TwinCAT
by Beckhoff, Easy Soft by Eaton (formerly Moeller). Using CODESYS for pro-
gramming Raspberry Pi makes it operates like regular PLC. The program is
being realized in a never ending loop. Each program realization is called cycle.
It is preceded by inputs acquisition and followed by outputs update. Imple-
mentation of the user program is possible according to international standard
IEC 61131 which, among other things, defines programming languages dedi-
cated to PLCs (LD, FBC, ST, IL, SFC [7,8]). Finally, Raspberry Pi together
with CODESYS is not only about programming and operation. Many industrial
communication protocols are available: EtherCAT, Profinet, Modbus TCP, OPC
UA for creation of Networked Control Systems NCS [9]. It makes Raspberry Pi
worth considering for real applications.
However, the question arises - if Raspberry Pi may operate like a PLC,
couldn’t it be used like one? Can we implement Raspberry in Networked Con-
trol Systems? At this point another feature of NCS node should be pointed out,
which is temporal determinism [10,11]. Most of the NCS nodes operate with
real-time requirements. Their proper operation depends not only on right calcu-
lation results, but also on the time when the results are obtained. Can Raspberry
Pi keep this requirement? In the paper authors will try to give an answer to that
question.
This paper is structured as follows: the next section presents the related work.
Section 3 includes other Raspberry Pi applicability considerations not associated
in its operation in the time domain. In Sect. 4 the testbed is described, followed
by experimental research results in Sect. 5. The last section contains conclusions
and final remarks.

2 Related Work
As mentioned in the previous section, there are many application examples of
Raspberry in computer systems, and of great variety, too. However, the Rasp-
berry usually gives some non-critical functionality like in GPS module coupled
with a Raspberry PI as data logger in [12], detecting objects in surveillance area
[13] or assessing fishing vessel stability [14].
Some of them are also associated with real-time systems. In [15] a system is
described in which Raspberry Pi equipped with camera was used for obstacle
detection. The average image processing performed by Raspberry was measured.
However, the processing was not considered from the point of view of satisfying
real-time system constraints. Another example is the development of CAN bus
 Determining the Usability of Embedded Devices Based on Raspberry Pi 195

communication interface for Raspberry in order to monitor vehicle parameters

[16]. The project was finished successfully, but the conclusion was quite general
and said the CAN interface “works”. There were no real-time considerations,
either. It is similar in other works that were available to authors like [17–19].
There are pieces of information in the Internet about some measurements
performed on Raspberry Pi that were supposed to show how fast Raspberry
can react to requests, e.g. signals of what frequency could be generated on its
output. The issue of real-time capability of Raspberry is also raised on Internet
forums where its applicability in industry is considered. However, this paper, to
the best of our knowledge, is the first that describes the experimental results of
the response time of Raspberry Pi to incoming requests.

3 Other Applicability Considerations

Before using Raspberry Pi boards and related based hardware for the industrial
applications, it is necessary to consider the issue of its environmental character-
istics. One thing is the heat generated by the device during operation. Under
load the Raspberry PI may get hot and it should be considered whether it is
acceptable in given application, especially in industrial environments.
Another thing is the EMC issues. On one side, the system has to be resistant
to the electromagnetic disturbances occurring in the industrial environments,
and on the other it should not be the source of high level electromagnetic emis-
sion. According to the Raspberry Pi manufacturer, all models are tested for
CE compliance in a “typical configuration” and conform to various standards
harmonized with EU Directives such as: Radio Equipment 2014/53/EU, Electro-
magnetic Compatibility (EMC) 2014/30/EU. In cases when the apparatus can
take different configurations, the EMC assessment confirms that the apparatus
meets the protection requirements in all possible configurations identified by the
manufacturer as representative of its intended use. In practice, in such universal
product like Raspberry Pi, it is almost impossible to find the worst case of EMC
scenario. According to the EMC Directive [20] and Guide for the EMC Directive
[21], when a manufacturer assembles a final apparatus using components from
other company, the manufacturer must retain overall control.
Another issue is the impact of the application executed by the embedded sys-
tem to the level of conducted and radiated emissions. According to the research
results presented in papers [22–24] it can be notice that different program realiz-
ing the same functionality, clock sources, and programmable PLL (Phase Locked
Loop) settings can be the source of different EMI (Electromagnetic Interference)
level. The software can be also used to control the EMI level of the entire system
as in papers [25–27], where the authors focus on software-level technique EMI
optimization.
To summarize, each manufacturer which uses the Raspberry Pi as a part of the
system is responsible for the compliance of the product with EU Directives. This
is especially important when the board is used in industrial real time application,
and which the safety and correct operation of other devices may depend on.
196 J. Stój et al.

4 Testbed
The goal of the experimental research was to determine how much one could rely
on the Raspberry Pi operation considered from the point of view of its tempo-
ral characteristics. We used Raspberry Pi version 3 programmed with CodeSys
development environment so the user program implemented in the device was
being executed like in a typical Programmable Logic Controller PLC. The point
of interest was the time needed for the program execution.
The research was performed with original Raspberry Pi Foundation OS –
Raspbian. The OS was in the “lite” version, without classical desktop and appli-
cations which are by default installed in regular version. The CodeSys program is
implemented on a PC and then sent to Raspberry Pi to be executed in CodeSys
runtime environment.
The user program may be configured to be executed in a couple of operation
modes – cyclic, freewheeling, event triggered, status triggered. In this paper we
focus on first two, as they are also typical to PLCs. In the cyclic execution mode
the time between every execution of the user program is constant and may be
defined by the user. In freewheeling mode the program execution starts one after
another, i.e every execution starts after the previous execution is finished.
The research was performed in four different hardware configurations as
described in the following subsections. In some cases we were also changing the
length of the user program. Each time we measured the delay from one execution
of the user program to another. In industrial environments it is associated with
the response time of the device, which is crucial from the point of view of its
real-time characteristics.

4.1 Generator and Oscilloscope

The first method which we proposed was based on a generator and oscilloscope
– G&O method (see: Fig. 1). The generator was configured to generate a 1 kHz
square wave. This signal was connected to the input of Raspberry Pi. Program
in Raspberry Pi reacted to the change of the state of the input by toggling one of
its outputs. As a result, from the Raspberry Pi we got a signal like the generated
one, but with some delay. The length of the delay depended on the duration of
the Raspberry Pi user program execution, which was configured to cyclic with
100 µs cycle time. The same experiment for the cycle time of the Raspberry Pi
equal 1 ms was performed, too. The results were analogous. The measured delay
was between 1 ms and 2 ms.
The consecutive durations of the time shifts between the generated square
wave and the signal received from the Raspberry was measured by an oscilloscope
and the results were stored in a CSV file. All of the measured values were in
the range from 100 µs to 200 µs, which corresponds to our expectations – the
minimum response time of devices operating in cyclic mode is equal one cycle
time, while the maximum response time is not more than two cycles duration [28].
 Determining the Usability of Embedded Devices Based on Raspberry Pi 197

Fig. 1. Testbed based on a square wave generator and oscilloscope.

The results are shown in Fig. 2. On the x-axis the measured time is given. The
y-axis shows the number of measurements (samples) with the given time. For
example, there were about 500 samples with the measured time in the range 180
to 200 µs, over 600 samples (the highest bar on the graph) with the measured
time in the range 160–180 µs, etc. There were also some samples with the time
slightly below 100 µs, but we considered them as a measurement error.

Fig. 2. Experiment results queried with generator and oscilloscope

In this experiment we got results corresponding to ours expectations. How-

ever, this method was used only as a way of validation of the following experi-
ments. It gave reliable results, but in small quantity. To get the above results,
the experiment had to be repeated many times. We performed 18 experiments
with together about 3000 measurements (samples). To increase the number of
measurements we prepared second method based on Data Acquisition Module
DAQ by National Instruments.

4.2 Data Acquisition Module

In the second method, National Instruments Data Acquisition Module DAQ was
used. The DAQ module connected by USB interface with PC computer, gave
us the possibility to generate a square wave of configured frequency straight
from PC, while performing the experiment just like the one described above. In
this case however, the results could be stored on the PC without actual data size
restrictions. We hoped that it could give us the possibility to perform long lasting
experiments during which we could spot all deviations (if any were present) in
the Raspberry Pi operation.
Unfortunately, using this method we got accuracy of 30 ms in comparison
to G&O method (see: Fig. 4) because we didn’t use LabView Real Time add-on
198 J. Stój et al.

which we had no access to. In our research we wanted to have the accuracy of 1
ms so we decided to change measurement method again.

Fig. 3. Testbed based on a national instruments acquisition module

Fig. 4. Experiment results queried with NI acquisition module

4.3 ATmega Based Experiments – Request-Response Principle

Third method is similar to the G&O method, but instead of a generator and
oscilloscope an ATmega microcontroller was used. It generated high level state
signal on its output connected to the Raspberry Pi input. The Raspberry user
program copied the state of that input onto its output, which was connected back
to the ATmega input. This way the ATmega could determine the time needed
for data processing by the Raspberry. After recording this measurement ATmega
again changed the state of its output to low level starting another measurement.
The acquired results were not as expected. It was caused by “synchroniza-
tion” of the ATmega and Raspberry Pi devices while performing the request-
response transaction. It caused the response time to be irregular in the acquired
time span. In Fig. 6 an example of those irregularities is shown. It was similar
to the observations described in [29] and a result of convolution of the operation
cycles of ATmega and Raspberry Pi devices. In the end, we modified the testbed
once again as described in the following subsection.

4.4 ATmega Based Experiments – Square Wave Generator

In the last method described here, the Raspberry was changing the logical state
of one of its outputs. The duration of low or high level of the output signal
 Determining the Usability of Embedded Devices Based on Raspberry Pi 199

Fig. 5. ATmega based experiment based on the request-response principle

Fig. 6. Results acquired with the request-response method

showed the duration of the user program. The output was connected to an input
of the ATmega which measured the time of changing of the logical signal level
(Fig. 7).

Fig. 7. ATmega and square wave generated by Raspberry Pi

The results were recorded in the ATmega internal memory. Comparison with
the G&O results showed that they are reliable. That method was used for final
experimental research described in the following section.

5 Results

In our research we tested how Raspberry Pi operates in cyclic mode and free-
wheelin mode. We compared the temporal characteristics of updated of the
Raspberry outputs which showed us how the user program was being executed.
Additionally, we built a networked system based on the Modbus TCP protocol.
The other network devices were five Arduino development boards with Ethernet
shields. The Raspberry Pi was exchanging packets of 125 bytes data with the
Arduinos every 100 ms.
200 J. Stój et al.

5.1 Single Node System

First of all, we considered operation of Raspberry PI as a single node system.

The user program implemented in Raspberry PI needed about 0.3 ms for single
execution. We measured the Raspberry Pi cycle time RCP, i.e. the time from
one user program execution to another. Two operation modes were checked –
cyclic (with cycle time set to 0.5 ms) and freewheeling. The results are shown in
Fig. 8.

Fig. 8. Raspberry Pi cycle in single node system: (a) cyclic operation, (b) freewheeling
operation

The above additional 3 ms in freewheeling operation mode was quite surpris-

ing. That operation mode is expected to be more efficient than cyclic mode, as
in cyclic mode after every user program execution, the operating system waits
for the cycle time to elapse. Whereas in freewheeling mode, the consecutive exe-
cutions of the user program are to be realized on after another. Therefore, the
RCP with different user program lengths was checked, too (see: Fig. 9).
In the performed measurements we confirmed that in freewheeling mode
execution program is longer than the same program in cyclic mode. Additional
time in freewheeling mode is about 3 ms and does not depend on the duration
of the user program execution.

5.2 Networked System

To test the Raspberry Pi operation with active communication interface, Eth-

ernet interface was used with Modbus TCP protocol. The network included five
Arduino modules. With every Arduino one data exchange was being performed
every 100 ms for reading 125 bytes of data. In this configuration we took 10,000
measurements. The results are show in Figs. 10, 11 and 12 (the y axis is scaled
logarithmically).
 Determining the Usability of Embedded Devices Based on Raspberry Pi 201

Fig. 9. Raspberry PI cycle times in freewheeling operation mode with different user
program length: (a) 1 ms, (b) 2 ms, (c) 5 ms

Fig. 10. The Raspberry PI cycle times in freewheeling operation mode without using
the communication interface

Fig. 11. The Raspberry PI cycle times in freewheeling operation mode with active
Modbus TCP data exchange
202 J. Stój et al.

Fig. 12. The Raspberry Pi cycle times with active Modbus TCP data exchange

In case when Raspberry Pi run in freewheeling mode and is realizing Mod-

bus TCP communication, the cycle time increases by about 1 ms. Interestingly,
execution of the same user program in cyclic mode increases the cycle time to
value greater than 10 ms - by more than 2 ms comparing to freewheeling mode.

6 Conclusions and Future Work

The paper presents some analysis and experimental results on the temporal
aspect of Raspberry Pi operation programmed with CODESYS development
environment. Two operation modes were examined – cyclic and freewheeling
from the point of view of the user program execution time.
Working in freewheeling operating mode gives longer response times than in
the cyclic operation mode for a not networked device. It had greater jitter, too.
It is the behavior which is not intuitive. Skimming through Internet discussion
forums suggests, that CODESYS programmer use freewheeling operation mode
when want to achieve high responsiveness of the devices they program. The
experiments show that it may have the opposite result.
The above remark seems not to apply to the operation of networked devices.
When using communication interface (like the tested Modbus TCP), the Rasp-
berry Pi had shorter response times in freewheeling mode than in cyclic mode.
However, the difference in the response times is less significant.
The above considerations refer to the usage of Raspberry Pi programmed in
CODESYS and therefore operating like regular PLC devices. However, its possi-
ble actual usage depends not only on its operation and temporal characteristics,
but also on other issues like requirements for compliance testing as mentioned in
Sect. 3. Nevertheless, we claim that the Raspberry Pi could be used in industrial
environments for realization only non-critical task like system monitoring use
for example for detection of improper operation. The programmer should also
test every created configuration. Even little changes may have severe influence
on the device operation.
Programming Raspberry Pi with CODESYS does not make a real-time device
out of it. It is caused basically by the fact, that its operating systems is not of
the real-time type. It is worth noticing however, that on the market there are
embedded devices delivered by well-known vendors and used like regular PLC’s
which are also programmed with CODESYS and has non real-time operating
 Determining the Usability of Embedded Devices Based on Raspberry Pi 203

systems, either. Still, according to authors experience, they are used in industry
for realization of networked control systems.
The research on the operation of devices programmed with CODESYS is
planned to be continued. In future works the usage of another communication
protocols like EtherCAT, Profinet will be analyzed and tested from the point of
view of the influence on the device response time.

References
1. Jain, S., Vaibhav, A., Goyal, L.: Raspberry Pi based interactive home automation
system through E-mail. In: 2014 International Conference on Reliability Optimiza-
tion and Information Technology (ICROIT), pp. 277–280, February 2014
2. Vaidya, B., Patel, A., Panchal, A., Mehta, R., Mehta, K., Vaghasiya, P.: Smart
home automation with a unique door monitoring system for old age people using
python, opencv, android and raspberry Pi. In: 2017 International Conference on
Intelligent Computing and Control Systems (ICICCS), pp. 82–86, June 2017
3. Frieslaar, I., Irwin, B.: Investigating the electromagnetic side channel leakage from
a raspberry Pi. In: 2017 Information Security for South Africa (ISSA), pp. 24–31,
August 2017
4. Sharma, J., Anbarasu, M., Chakraborty, C., Shanmugasundaram, M.: Iris move-
ment based wheel chair control using raspberry Pi - a state of art. In: 2017 Inno-
vations in Power and Advanced Computing Technologies (i-PACT), pp. 1–5, April
2017
5. Wardi, Achmad, A., Hasanuddin, Z.B., Asrun, D., Lutfi, M.S.: Portable IP-based
communication system using raspberry Pi as exchange. In: 2017 International Semi-
nar on Application for Technology of Information and Communication (iSemantic),
pp. 198–204, October 2017
6. Kadiyala, E., Meda, S., Basani, R., Muthulakshmi, S.: Global industrial process
monitoring through IoT using raspberry Pi. In: 2017 International Conference on
Nextgen Electronic Technologies: Silicon to Software (ICNETS2), pp. 260–262,
March 2017
7. IEC 61131–3 Programmable controllers - Part 3: Programming languages (2003)
8. Rzońca, D., Sadolewski, J., Stec, A., Świder, Z., Trybus, B., Trybus, L.: CPDev
engineering environment for control programming. In: Mitkowski, W., Kacprzyk,
J., Oprzedkiewicz,
 K., Skruch, P. (eds.) Trends in Advanced Intelligent Control,
Optimization and Automation. KKA 2017. Advances in Intelligent Systems and
Computing, vol. 577, pp. 303–314. Springer, Cham (2017). https://doi.org/10.
1007/978-3-319-60699-6 29
9. Rzasa,
 W., Rzonca, D.: Event-driven approach to modeling and performance esti-
mation of a distributed control system. In: Gaj, P., Kwiecień, A., Stera, P. (eds.)
CN 2016. CCIS, vol. 608, pp. 168–179. Springer, Cham (2016). https://doi.org/10.
1007/978-3-319-39207-3 15
10. Basile, F., Chiacchio, P., Gerbasio, D.: On the implementation of industrial
automation systems based on PLC. IEEE Trans. Autom. Sci. Eng. 10(4), 990–
1003 (2013)
11. Jamro, M., Rzonca, D.: Impact of communication timeouts on meeting functional
requirements for IEC 61131-3 distributed control systems. Automatika 56(4), 499–
507 (2015)
204 J. Stój et al.

12. Masino, J., Frey, M., Gauterin, F., Sharma, R.: Development of a highly accu-
rate and low cost measurement device for field operational tests. In: 2016 IEEE
International Symposium on Inertial Sensors and Systems, pp. 74–77, February
2016
13. Menezes, V., Patchava, V., Gupta, M.S.D.: Surveillance and monitoring system
using raspberry Pi and simplecv. In: 2015 International Conference on Green Com-
puting and Internet of Things (ICGCIoT), pp. 1276–1278, October 2015
14. Abankwa, N., Squicciarini, G., Johnston, S., Scott, M., Cox, S.J.: An evaluation
of the use of low-cost accelerometers in assessing fishing vessel stability through
period of heave motion, October 2016
15. Mane, S.B., Vhanale, S.: Real time obstacle detection for mobile robot navigation
using stereo vision. In: 2016 International Conference on Computing, Analytics
and Security Trends (CAST), pp. 637–642, December 2016
16. Salunkhe, A.A., Kamble, P.P., Jadhav, R.: Design and implementation of can bus
protocol for monitoring vehicle parameters. In: 2016 IEEE International Confer-
ence on Recent Trends in Electronics, Information Communication Technology
(RTEICT), pp. 301–304, May 2016
17. Sahitya, S., Lokesha, H., Sudha, L.K.: Real time application of raspberry Pi in
compression of images. In: 2016 IEEE International Conference on Recent Trends
in Electronics, Information Communication Technology (RTEICT), pp. 1047–1050,
May 2016
18. Joardar, S., Chatterjee, A., Rakshit, A.: A real-time palm dorsa subcutaneous vein
pattern recognition system using collaborative representation-based classification.
IEEE Trans. Instrum. Measur. 64(4), 959–966 (2015)
19. Patruno, C., Marani, R., Nitti, M., D’Orazio, T., Stella, E.: An embedded vision
system for real-time autonomous localization using laser profilometry. IEEE Trans.
Intell. Transp. Syst. 16(6), 3482–3495 (2015)
20. Guide for the EMC directive 2004/108/EC - european commission (2004)
21. Electromagnetic compatibiliy directive 2014/30/EU (2014)
22. Yuan, S.Y., Chung, W.Y., Chen, C.C., Chen, C.K.: Software-related EMI behavior
of embedded microcontroller. In: 2014 IEEE International Symposium on Electro-
magnetic Compatibility (EMC), pp. 118–122, August 2014
23. Smys, S., Thara Prakash, J., Raj, J.S.: Conducted emission reduction by frequency
hopping spread spectrum techniques. Nat. Acad. Sci. Lett. 38(3), 197–201 (2015)
24. Kwiecień, A., Maćkowski, M., Skoroniak, K.: Reverse engineering of microprocessor
program code. In: Kwiecień, A., Gaj, P., Stera, P. (eds.) CN 2012. CCIS, vol.
291, pp. 191–197. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-642-
31217-5 21
25. Ma, W., Zhao, Z., Meng, J., Pan, Q., Zhang, L.: Precise methods for conducted emi
modeling, analysis, and prediction. Sci. China Ser. E Technol. Sci. 51(6), 641–655
(2008)
26. Yuan, S.Y., Su, W.B., Ho, H.P.: A software technique for EMI optimization, May
2012
27. Kreitlow, M., Garbe, H., Sabath, F.: Influence of software effects on the suscepti-
bility of Ethernet connections. In: 2014 IEEE International Symposium on Elec-
tromagnetic Compatibility (EMC), pp. 544–548, August 2014
28. Kwiecień, A., Stój, J.: The cost of redundancy in distributed real-time systems
in steady state. In: Kwiecień, A., Gaj, P., Stera, P. (eds.) CN 2010. CCIS, vol.
79, pp. 106–120. Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-
13861-4 11
 Determining the Usability of Embedded Devices Based on Raspberry Pi 205

29. Widel, S., Flak, J., Gaj, P.: Interpretation of dual peak time signal measured in
network systems. In: Kwiecień, A., Gaj, P., Stera, P. (eds.) CN 2010. CCIS, vol.
79, pp. 141–152. Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-
13861-4 14