Full Integration of MATLAB/Simulink with Control
Application Development using OPC Unified
Architecture
Haitham Elfaham, Florian Palm, Sten Grüner, Ulrich Epple
Chair of Process Control Engineering
RWTH Aachen University, Germany
Email: {h.elfahaam, f.palm, s.gruener, epple}@plt.rwth-aachen.de
Abstract—Integrating control development phases requires a
consolidated communication architecture. Currently, different
communication protocols are used at the different development
stages preventing a fully integrated solution to exist. We propose
an approach using a unified communication protocol to jointly
integrate the control development stages. MATLAB and Simulink
were connected to a programmable logic controller successfully
resulting in a fully integrated control development chain and
opening the doors for further development in other potential
areas.
I. INTRODUCTION
Recently, a German initiative has emerged and has been
a hot topic in the last five years. The initiative is based on
an idea that is actively discussed in almost every engineering
field, as it is mainly built on cooperation between the different
engineering disciplines. The initiative is called ”Industrie 4.0”
(I40). As the name states, this initiative is working as a catalyst
to speed up the so called ”fourth industrial revolution” [1].
I40 adopts OPC Unified Architecture (OPC UA), a Machine
to Machine (M2M) communication protocol, as its standard
communication protocol [2]. Using a common communication
channel to access different powerful softwares tools will
further extend the progress of establishing a unified archi-
tecture where different fields can be connected. Moreover,
having widely used numerical computing environments and
engineering tools like MATLAB and Simulink connected
to the communication layer will expand the possibilities of
merging different applications in I40. This paper proposes a
full integration of the control development phases of a fuel cell
using MATLAB/Simulink and open62541 [3], an open source
implementation of OPC UA.
The rest of the paper is structured as follows: A state of the
art section that mentions previous work and implementations
is shown in Section II. Section III explains the communication
protocol used in our contribution and argues the advantages
of migrating to OPC UA. In Section IV and V, MATLAB and
Simulink implementations are discussed respectively. Section
VI explains the proposed fuel cell use case. The use case
is partially implemented. The identification stage showed
successful results, while other stages Implementation is in
progress. Section VII concludes the paper.
978-1-5090-2870-2/16/$31.00 ©2016 IEEE 371
II. STATE OF THE ART
Many control systems require OPC (also referred to as
OPC classic, a telecommunication standard) based connections
for regulation and stabilization purposes. OPC is popular in
process automation as it offers an easy access to the Pro-
grammable Logic Controller (PLC) variables and input/output
terminals. An approach to implement a fuzzy self-adaptive PID
controller for a boiler drum is presented in [4]. The approach
aims to control water level using Simulink and OPC based
connection.
A European Union supported project in [5] shows an OPC
UA model for public transportation systems. The model imple-
mentation is described throughout the paper and concludes that
the problems presented cannot be solved unless simulated. The
simulations were not conducted as -at that time- the connection
between OPC UA and MATLAB was still a missing link.
A pressure control station model identification and PID-
tuning is shown in [6]. This work tries to combine both stages
as well as to establish a digital implementation of the PID-
tuning using an OPC connection.
A partially automated Hardware-In-the-Loop (HIL) test
environment that uses Simulink and OPC classic is presented
in [7]. An OPC toolbox (see Subsection IV-B) is used to link
Simulink and the hardware used. One of the work aims men-
tioned is to increase the flexibility in the design enhancement
process.
Another example is identification and failure detection
using MATLAB/Simulink and an OPC based connection is
demonstrated in [8]. The proposed failure detection is done
using an application running a Supervisory Control And Data
Acquisition (SCADA) WinCC system that communicates with
MATLAB.
It can be shown that an OPC UA connection with MAT-
LAB/Simulink is an important tool that will benefit many
use cases. In fact, it will enhance the flexibility and integrate
a wider scope of control applications than the previously
mentioned use cases.
III. THE COMMUNICATION PROTOCOL
A. OPC Unified Architecture
OPC UA is an OPC Foundation protocol that is developed
for M2M communications. It provides the communication
layer in I40 [2]. It plays a main role in the I40 initiative as
it helps getting one step closer to establishing a robust model
based communication protocol between machines. Playing a
main role in I40 obliges OPC UA to have two important factors
which are standardization and availability. While the former
factor shows good indications as it is properly standardized and
developers must comply with the IEC 62541 standard [9], the
availability has not been the best for OPC UA. Attempts to
find means to connect OPC UA to MATLAB and Simulink did
not yield fruitful results. The only toolkit that we were able
to find was the MATLAB OPC toolbox which supports OPC
and not OPC UA. Only recently, in the latest release (R2015b),
OPC toolbox supports OPC UA communication. However, it
is not open source nor free of charge. Moreover, only systems
with 64 bits architecture are supported. Furthermore, the
methodology presented here extends to other alternative open
source computing environments like Octave and Scilab. The
OPC toolbox is discussed further in Subsection IV-B. Since
MATLAB and Simulink are considered to be two important
tools that many engineering applications rely on nowadays, ef-
forts have been exerted to establish a connection between OPC
UA and the MATLAB/Simulink platforms which are discussed
in this paper. The implementation explained here connects
open62541 with MATLAB and Simulink. Open62541 is a free
open source OPC UA implementation written in C that is
introduced by a joint collaboration work between the Chair
of Process Control Engineering, RWTH Aachen University;
Chair of Process Control Systems Engineering, TU Dresden;
and Fraunhofer IOSB institute.
B. OPC UA in a Nutshell
In this subsection, the most important features that concern
our implementation are discussed. OPC UA is a standardized
service oriented protocol that is shaped to fit in the intended
purpose of industrial communication. The communication
protocol complies with the IEC 62541 standard [9]. A meta
model is defined to provide the infrastructure of OPC UA. This
meta model presents nodes and references as its fundamental
elements. Exploring and modifying the writable attributes in
the address space can be done using standard services. OPC
UA has its own defined security mechanism, thus an extra
encryption layer implantation is not needed. Further details
and more description of OPC UA can be found in [10] and
[11].
1) Services: OPC UA defines 34 services [10]. The services
are described in full details along with the parameters, service
results, and their Status codes in IEC 62541/4 [9].
2) Meta Model: A node class comprises other nodes.
Depending on the node class, different attributes are defined
in which some of them are mandatory and some are optional.
References realize the relationships between the different
nodes. Each OPC UA server has an address space where all the
nodes are created. Each node has different attributes and each
attribute has a value entry. Furthermore, an attribute could be
a structure that has more attributes linked to it.
372
3) Data Modeling: OPC UA supports 26 built in data types
in which some of them are abstract types and others that are
defined in IEC 62541/6 [9].
C. OPC Classic vs OPC UA
Open Platform Communications (OPC), an OLE, COM,
and DCOM based specifications and standards are widely
used nowadays in industrial communication. OPC is respon-
sible and is the communication standard for real-time data
transfer between control devices in automation technology
[12]. However, the OPC protocol has its own constraints and
drawbacks which are surpassed by its proceeding evolved
protocol OPC UA. OPC UA outperforms its predecessor
OPC in terms of operating systems compatibility. Contrary
to OPC, OPC UA can run on platforms other than Microsoft
Windows. OPC UA has an already implemented security layer
which on the other hand, in the case of OPC protocol, a
security layer implementation is required. Moreover, OPC UA
is IEC standardized [9]. Finally, OPC UA provides much more
sophisticated data models than OPC along with more services
and functionalities. It can be deduced that OPC UA is much
more flexible and has more features than OPC [11]. Along
with a design goal to facilitate the migration from OPC and
integrate its products in OPC UA, OPC UA makes a better
and a more reliable communication protocol choice. As a
quantitative comparison, a performance comparative study in
[13] is conducted between OPC Data Access (OPC DA), a
common OPC specification and OPC UA. The study aims to
measure both protocol performances in which a button press
sets a starting flag that has a value ”false” as its default
setting. This flag triggers a function that updates a set of
variables. Once all the variables are updated the flag falls
again to its default value. The number of changed elements
and the time measured till the flag toggles twice constitute the
testing parameters. Two interesting findings were observed in
the results, OPC DA progressively became unstable starting
at the 15,000 items mark, while OPC UA showed a higher
performance and more robust results as it needed less time to
update the variables and very little variance in performance
with the increase of number of elements. The results and the
source files that were used to conduct the test are available
at [13] for reproducing purposes. A summarized comparison
between OPC and OPC UA is shown in Table I.
The platform independence makes a direct communication
possible, thus a smaller number of components involved in
the message transmission is needed. This has a time and an
economic advantage for industrial applications. Fig. 1 shows
an example of the alternative communication infrastructure
offered by OPC UA. The alternative infrastructure provides
a direct communication between MATLAB and PLC without
having to go through an intermediate SCADA. A SCADA
system must be run on a Windows operating system, which
will technically force the user to be using non open source
environments before reaching the PLC by the use of a fieldbus,
an industrial network that links PLCs to field components (e.g.,
sensors or actuators) [14].
 TABLE I drawbacks. A Heterogeneous system is always harder to
OPC AND OPC UA C OMPARISON . maintain and manage. As when it comes to security, this
could possibly be offering a better chance for attackers
Criterion OPC OPC UA to exploit the security weaknesses as there are many
security issues existing in the web services and the COM
Operating System Microsoft Windows Platform components [10].
Independent
Security Requires Implementa- Already
tion Implemented IV. MATLAB IMPLEMENTATION
Data Modeling Limited More Functionalities As mentioned previously in Section III, open62541 is
and Services
implemented in ANSI C. MATLAB offers the MEX file
IEC Standardized ✗ IEC 62541
implementation that works as a gateway between C code and
Performance — +
regular MATLAB functions. However, a drawback of the MEX
implementation is that the produced binary files cannot be used
on other platforms than the one they were compiled on.
MATLAB
MATLAB A. Foreign Programming Languages Interfacing in MATLAB
OPC Classic MATLAB allows the execution of different programming
languages through implemented interfaces. MATLAB can call
SCADA OPC UA
(Windows) libraries written in Java, Python, ActiveX, .NET, Fortran, and
C [16]. In this section the C language interface in MATLAB
Fieldbus is discussed since the featured OPC UA implementation pre-
PLC
sented here uses C. In order to interface C library functions,
PLC there exist two approaches that are offered by MATLAB.
The first approach uses Dynamic Linked Libraries (DLL), or
shared objects under Linux and OS X operating systems. Upon
compiling the OPC UA routines, DLL files can be generated
Fig. 1. Example of communication architectures offered by OPC classic and
OPC UA.
and used directly in MATLAB. The second approach can be
done using MEX-files, an interface introduced by MathWorks
that gives MATLAB access to foreign programming languages
D. Migration execution. The DLL outperforms the MEX approach in terms
of ease of generation and robustness as these libraries can be
One of the design goals of OPC UA is facilitating the OPC
used in other engineering tools or mathematical environments.
to OPC UA migration process protecting the investments that
However, it does not provide an inner access for the user to
are already established as well as allowing further expansions
modify files and introduce tailored functions as one prefers
to the installed base [15]. In this section, different migration
unless the source files are changed before generating the
scenarios from OPC classic to its successor OPC UA are
DLLs which is not desired. Another drawback using the DLL
discussed. There exist three migration paths [15]:
approach is the limitations to shared libraries support. The
• Full migration: A complete and comprehensive replace- MATLAB documentation [17] lists all the limitations to shared
ment of OPC classic is performed. However, currently library support in which some are found in the open62541
this is only possible for small architectures for the OPC implementation. The following items are not supported when
UA solution availability is small. This migration path pro- using the DLL approach:
vides a more secured management systems connectivity
• Unions,
and a homogenous system compared to the preliminary
• Function pointers,
migration that is discussed later [10].
• Return by value (a pointer to structures must be returned
• Partial migration (soft migration): A step by step migra-
instead),
tion according to the user needs. A solution that has a
• Nested structures,
great advantage of reducing the work load configuring
• Structures that contain structure pointers.
old OPC servers.
• Preliminary migration: A fully functional OPC classic
B. Previously Implemented Tools
compatible migration that its solutions rely only on the
OPC classic specifications. But additionally, it supports MathWorks offers OPC toolbox, a product that enables
OPC UA functions. This scenario is useful when a busi- the users to establish a connection to OPC DA and OPC
ness is relying fully on OPC classic and wants to be also HDA (OPC specifications) servers. The toolbox provides live
OPC UA compatible for future purposes. This solution and historical access to OPC data from MATLAB and also
could shorten development time, however it has many Simulink. The toolkit has the following key features:

373
 • The toolkit supports the OPC foundation data access
and historical data access standards v2.05a and v1.20
respectively.
• Data logging, numerical processing, and connecting to
multiple OPC servers simultaneously.
• Historical data access for the analysis and statistical
processing purposes.
• Synchronous and asynchronous communication.
These key features define the scope in which OPC UA
support plays a big role to facilitate the migration process
(explained in Subsection III-D). As for the OPC UA services,
the methodology of how the OPC toolkit handles the data
access will define how great the migration expenditure will
be. The toolkit provides three different data access techniques
which are:
• The MATLAB command line execution of the OPC
toolbox functions,
• The graphical user interface,
• The toolbox Simulink blocks.
C. Overview of a MEX file
MEX interface allows bidirectional interfacing. MATLAB
functions can be called from inside the MEX file which
provides a flexible communication environment between MAT-
LAB and C. Each MEX file can support only one MEX
function. The MEX function is the gateway that connects
MATLAB and C code. Thus for each service, one must write
a MEX file and only one service can be performed by this file
(e.g., connect, read, etc.).
Using the C language data types within a MEX routine
is possible. However, using the MEX data types is preferred
as it would be more compatible and easier to transfer into
MATLAB workspace. There are pre-defined data-types in
MEX that cover almost all the required data types as both
share most of the basic data types [18].
D. MATLAB as an OPC UA Server
Since MATLAB can execute C code using the MEX in-
terface, MATLAB can be started as an OPC UA client or
as a server instance. However, starting as a server instance
can be problematic, as once a C code is started in the
MEX interface, the user can not interrupt or terminate the
process until the code execution reaches the end. During the
execution of a C code, MATLAB will not respond to any
command even if the user tried forcing exit commands or
process interrupt commands. This can be problematic when
MATLAB is running as a server instance, as the server code
does not have a terminating point causing MATLAB to freeze
and no longer respond to any command. However, this does
not impede the server functionalities. In our experiments, the
server responded perfectly and was able to communicate with
clients. A workaround that enables MATLAB to run OPC UA
server without encountering any non-responsive problems is
shown in Subsection IV-F.
374
E. MATLAB as an OPC UA Client
On the other hand, when MATLAB is executed as a client
instance, once the code execution is done (e.g., a success-
ful read), MATLAB returns the value and saves it in the
workspace and starts responding normally as it is no longer
stuck in a C routine execution. To optimize the execution time
of the code, the connect and disconnect routines are made
separate from all the other services. This enables information
retrieving from the different nodes and avoids a huge time
expenditure caused by calling the connect and disconnect
functions each time a service is executed. Services execution
requires two essential pieces of information to be able to
identify the target node: a client handle and a node ID. The
MEX interface showed full functionality executing the browse,
read, and write functions.
F. Multi-threading
In order to implement a subscription in MATLAB or to have
a continuous read function call running in the background, an
implementation with multi-threading execution is necessary.
Multi-threading enables a simultaneous execution of variable
updating functions (e.g., read) without blocking MATLAB in a
for loop or a C routine. This can also serve as a workaround to
enable MATLAB to run an OPC UA server. This is done using
a parallel cluster and attaching a job to it. The server code
execution as well as other functions can be attached to this
job. Thus starting and stopping the server and all the attached
components can be controlled via the job operation control.
A parallel pool can be opened on the cluster providing more
flexibility. The server implementation shows proper responsive
behavior using multi-threading.
V. SIMULINK
Connecting Simulink requires a different arrangement than
the one implemented in MEX files. Simulink does not allow
continuous execution of MEX-routines during a simulation.
Using S-Functions in Simulink, C code functions can be
continuously executed during a simulation.
A. S-Functions
S Functions are a MATLAB, C, C++, or Fortran description
of a Simulink block. Contrary to normal MEX files, the S-
Function routines can be dynamically linked to Simulink the
same way other blocks found in the Simulink library interact
with Simulink engine [19]. In the scope of this paper, the main
interest is to implement a MEX-S-Function.
B. Time Synchronization
Running a Simulink OPC UA client directly and estab-
lishing a connection with an OPC UA server will result in
redundant service requests. This is because the services are
called as frequent as the Simulink simulation execution time
step. As a result, the server as well as the client can be
overloaded with read requests which can potentially exhaust
the computational resources at both ends. The simulation exe-
cution time step should be adjusted according to the sampling
 Identification Prototyping
Phase Phase
Running
MATLAB Simulink Phase
OPC UA Client OPC UA Client MATLAB
GUI
Simulink OPC UA Client
OPC UA Client
OPC UA Server
IO IO IO IO PLC IO
Sensors
Fuel Cell
Fig. 2. Control development phases and the communication infrastructure.
rate needed. This can be done by adjusting the time step in
the solver configuration. Many libraries can also be found
online that give access for the user to the simulation time
step management, which can simply be added to the model.
VI. USE CASE
This section gives a further explanation of how the different
phases in the control application development process can
be fully integrated with the MATLAB/Simulink and OPC
UA coupling. On a more abstract level, the three described
phases in this section; ”Model identification”, ”Control Proto-
typing”, ”Operation (Running and; Data Logging, Archiving,
and Analysis)” can be linked together with the described
coupling enabling a state flow and continuous control stage
evolution. On the other hand, on a more detailed level, we
use the fuel cell use case here as a proof of concept. The
Simulink model should be able to tune the PID controller
parameters and actively communicate them by feeding them to
the simulated plant model. After finding the optimum values
for the controller, the values are sent to the PLC where the
real controller module is located. The plant is then tested and
the data are recorded and analyzed.
With the aforementioned objectives arise two main issues,
the communication between the PLC of the fuel cell and
Simulink blocks (PID tuning); and between the PLC and
the MATLAB workspace (history recording) which initi-
ated our need for the direct communication between MAT-
LAB/Simulink and PLC that was implemented using OPC
UA. Fig. 2 shows the phases of control development that our
use case passed through. There are four main elements that
are needed for testing and development: MATLAB, Simulink,
PLC, and the fuel cell. Each stage will require a different
arrangement. In the following subsections, each phase and the
roles of the participating elements are described in a more
detailed fashion.
a) Identification Phase: The first phase is concerned with
the model identification. This phase comprises two stages. The
first stage is modeling which requires MATLAB, PLC, and
Operation Phase %. $%!
Data Analysis $&'()*/01!" $&'()*+",-
& Archiving %8!0,2! 23#"
!"#
MATLAB 4%"56'"55
OPC UA Client
73-"5
Simulink
OPC UA Client
Fig. 3. Simulink model used for the model verification stage.
IO IO IO
the fuel cell to be active. The second stage is where Simulink
becomes active and is called the model verification stage.
Actuators
In the first stage, MATLAB parametrizes the model using
the received sensor data in order to establish an accurate
model. The communication in this phase is presented with
the vertical arrows shown in Fig. 2. The sensors located in the
fuel cell are actively sampling the physical values and sending
them to the PLC. MATLAB runs an OPC UA client in which
the values are retrieved directly from the OPC UA server that
is running on the PLC without the need for an intermediate
software.
In the second stage, the model verification takes place. This
stage is fairly similar to the Rapid Control Prototyping (RCP)
process, however, contrary to RCP, the model is being iterated
and tested; and not the control strategy. Fig. 3 shows the
model verification process. Simulink starts exciting both the
simulated model and the real model with a certain input type
(step or ramp inputs). In the given figure, a step response
is given and then the connections are branched out into two
sections. The upper section writes the given input to the PLC
using the OPC UA write block in order to excite the real fuel
cell plant. While in the lower section, the simulated model is
fed the exact same given step input. Both branches are merged
again with a subtract block. The subtract block compares the
responses of the simulated model and the response of the
fuel cell plant by reading the PLC sensor values using the
OPC UA read block. The results can then be shown on a
scope to validate the model identification stage. According to
the results, the modeling stage is either iterated to enhance
the current model or terminates the identification phase and
proceeds to the proceeding phase, the ”Prototyping Phase”.
b) Prototyping Phase: The prototyping phase founds the
second phase in the sequence of our arrangement. This phase
is executed on two different stages, PID tuning and RCP.
The only active element in the first stage is Simulink. The
model produced in the preceding phase is used and the PID
controller is tuned. The fuel cell at this point is switched
off and the parameters are tested on the model as a safety
precaution. Once the controller parameters are tuned, the RCP
stage begins. The active elements in this stage are: Simulink,
PLC, and the fuel cell. The PLC monitors this phase and
confines the fuel cell actuation for protection. Simulink fine
tunes the PID controller parameters and tests them with the
fuel cell to achieve an optimum controller for the process.
c) Operation Phase: The operation phase comprises two
other phases, ”Running” and ”Data Analysis and Archiving”
phases. The latter is optional and does not exist in every
375
 TABLE II
U SE C ASE E LEMENTS ACTIVITIES D URING THE D IFFERENT P HASES .
Element Identification Prototyping Running Archiving
Phase Phase Phase Phase
MATLAB parametrizing off GUI recording
Simulink verification PID-Tuning off recording
PLC sampling off/monitoring control sampling
Fuel Cell on off/on on on
system.
Running Phase: After the PID controller is tuned and the
optimum controller parameters are computed, the running
phase takes place. In this phase, MATLAB, PLC, and fuel cell
R and opc technology,” in Information, Communication
form the active elements. MATLAB is used here as a Graphical
User Interface (GUI) and runs as an OPC UA client. The user
R application via opc commu-
actively communicates with the fuel cell and manipulates the
R for integrated systems,” in Emerging Technologies
drive parameters using this interface.
Data Analysis and Archiving Phase: In this phase, the fuel
cell is running with an optimized controller on the PLC. The
active elements in this phase are: MATLAB, Simulink, PLC,
and fuel cell. The process values here are measured, sent, and
archived for maintenance and fault tracking as well as data
analysis purposes. The sensors send the measured values to
MATLAB via the PLC Inputs and Outputs. MATLAB and
Simliunk then record and save the values to workspace and
eventually to the hard drive. In case of troubleshooting or
unexpected failure tracking, these files are retrieved and the
data are analyzed. Both MATLAB and Simulink here run
separate OPC UA client instances.
Table II summarizes the engaged elements and their roles
during the described control development phases.
VII. CONCLUSION AND FUTURE WORK
In this paper, the importance of OPC UA protocol for
control engineers in the field of process control engineering is
discussed. Establishing a connection between OPC UA server
and a MATLAB/Simulink client was illustrated. A demonstra-
tion of how control development phases can be successfully
integrated was shown. As a future work suggestion, the imple-
mentation of an OPC UA server on MATLAB/Simulink that
can bidirectionally link the definition of MATLAB/Simulink
models to the OPC UA trees and nodes architecture. On the
one hand, the server should be able to cyclically iterate through
the MATLAB/Simulink workspace variables and create the
corresponding OPC UA trees and nodes. And on the other
hand, to translate OPC UA trees and nodes models into
a MATLAB/Simulink models. Furthermore, such an online
coupling can open the doors to establish a common ground
between the different modeling/simulation environments, e.g.,
Dymola, Octave, etc..
R EFERENCES
[1] Forschungsunion and acatech, “Recommendations for implementing the
strategic initiative INDUSTRIE 4.0,” 2013.
376
Powered by TCPDF (www.tcpdf.org)
[2] Status Report- Reference Architecture Model Industrie 4.0 (RAMI4.0).
VDI/VDE-Gesellschaft Mess- und Automatisierungtechnik, 2015.
[3] F. Palm, S. Grüner, J. Pfrommer, M. Graube, and L. Urbas, “Open Source
as Enabler for OPC UA in Industrial Automation,” in Proceedings of
the IEEE 20th International Conference on Emerging Technologies and
Factory Automation, IEEE 20th International Conference on Emerging
Technologies and Factory Automation, Luxemburg (Luxembourg). Pis-
cataway, NJ: IEEE, 2015.
[4] W. Mingliang, W. Mingyong, H. Jiankang, and S. Ling, “Intelligent
control system of water level for boiler drum based on opc and matlab,”
in Control Conference (CCC), 2011 30th Chinese. IEEE, 2011, pp.
4461–4464.
[5] OPC UA Object Oriented Model for Public Transportation System: A.
Maka, R. Cupek, J. Rosner. IEEE computer society, 2011.
[6] M. Manyari-Rivera and J. C. Basilio, “Integrated online auto-tuning and
digital implementation of pid controllers in industrial processes,” in Con-
trol and Automation (ICCA), 2011 9th IEEE International Conference
on. IEEE, 2011, pp. 550–555.
[7] W. Chaaban, M. Schwarz, B. Batchuluun, H. Sheng, and J. Börcsök, “A
partially automated hil test environment for model-based development
using simulink
and Automation Technologies (ICAT), 2011 XXIII International Sympo-
sium on. IEEE, 2011, pp. 1–6.
[8] D. S. Diaz and R. De Keyser, “Wincc
nication to matlab
& Factory Automation (ETFA), 2011 IEEE 16th Conference on. IEEE,
2011, pp. 1–7.
[9] OPC Unified Architecture Part 1-10, IEC Std. 62 541, Rev. 1.0, 2010.
[10] S.-H. Leitner and W. Mahnke, “Opc ua–service-oriented architecture for
industrial applications,” ABB Corporate Research Center, 2006.
[11] W. Mahnke, S.-H. Leitner, and M. Damm, OPC unified architecture.
Springer Science & Business Media, 2009.
[12] “What is opc? - opc foundation.” [Online]. Available:
https://opcfoundation.org/about/what-is-opc/
[13] Damian Abalo Miron, “Opc ua vs opc da performance comparative,”
ABB Corporate Research Center, 2014.
[14] J.-P. Thomesse, “Fieldbus technology in industrial automation,” Pro-
ceedings of the IEEE, vol. 93, no. 6, pp. 1073–1101, 2005.
[15] Jason Fletcher, “Making a smooth transition from opc classic to
opc ua,” Aug. 2014, online; accessed 23-September-2015. [Online].
Available: http://www.controlengeurope.com/article/80950/
[16] MathWorks, “Calling external functions: Documentation,” 2015.
[17] ——, “External interfaces: R2015a,” Mar. 2015.
[18] P. Getreuer, “Writing matlab c/mex code,” 2010.
[19] MathWorks, “Developing s-functions: R2015a,” Mar. 2015.