01-01-2013, 04:30 PM
Open and Flexible Embedded System Applied to Positioning and Telecontrol
[attachment=46051]
Abstract
This paper presents the development and testing of
an open and flexible embedded system applied to positioning and
telecontrol (OFESAPO) for outdoor applications. The system is
composed of a control center (CC) and a set of remote terminal
units (RTUs); the International Electrotechnical Commission
(IEC) 60870-5 series has been chosen for communication among
them. This is a standard protocol of real-time telecontrol applications.
The CC is a personal computer, and the RTUs are
based on open hardware and software. The RTU hardware is an
embedded system, i.e., a system-on-chip-type design using fieldprogrammable
gate array that has been programmed with the
open-core LEON running Linux operating system. For prototyping,
the GR-XC3S-1500 board has been used. As there is no open
source code available for the IEC standard protocols, an open
source code has also been implemented. Hence, both the hardware
and the software are open source in OFESAPO. Several tests have
been made to show the system’s limitations and the suitability for
real-time applications. A prototype has also been tested in a real
environment, where the real position of two moving RTUs was
shown by a CC using Google Map.
INTRODUCTION
POSITIONING technology and mobile communication
provide the right environment to make location-based services
(LBS) closer to daily life. There are many applications
of LBS that make people’s or business life easier because of
the ability to send positioning information in real time, for
instance, the waiting time for a bus in a bus stop. Another
application is surveillance, for example, in forest fire fights, not
only of firefighters but also of vehicles, or in rescue operations.
These kinds of applications use mobile devices (personal digital
assistant (PDA), cell telephone, etc.), controlled devices, a
controller device (a computer, a PDA, etc.), and a real-time
geographic information system (GIS). The controlled devices
are equipped with both a positioning technology and a mobile
communication.
SYSTEM DESIGN
OFESAPO is composed of “remote terminal units” (RTUs)
and a “control center” (CC). The CC is a PC-based system,
where the GIS to map in real time is placed. The RTU is an
embedded system used to acquire position data to send them to
the CC.
The RTU can also send data obtained from the environment
via sensors attached to the RTU or receives commands from the
CC due to the design criterion flexibility of OFESAPO. That
criterion makes OFESAPO similar to a supervisory control and
data acquisition (SCADA) one.
The field of SCADA systems has a series of standards
specified by the IEC called “IEC 60870-5” for telecontrol
equipment and systems. These standards define specific requirements
and conditions for data transmission in telecontrol
systems, showing the ways to meet those requirements to ensure
compatibility between devices from different suppliers. The
positioning system presented in this paper complies with these
standards, so this makes OFESAPO flexible and adaptable to
multiple environments.
To determine the RTU position, the GPS technology is used
as it is more flexible than other outdoor positioning systems, so
it is both not dependent of the cellular telephony operator and
more precise.
IEC 60870-5 Series Overview
The telecontrol protocol stack usually implements the specifications
provided by the IEC called “IEC 60870-5” [9]. This
series follows the enhanced protocol architecture model, not the
ISO standard (open system interconnection (OSI) model). This
model only requires three of the seven OSI layers, i.e., application
layer, data link layer, and physical layer. The standard is
divided into six parts and specifies a suite of protocols for both
application and data link layers.
In a typical telecontrol scenario, one station (primary station)
called “CC” controls communication with other stations (secondary
stations) called “RTUs,” so the IEC 60870-5 specification
allows real-time telecontrol applications to function. In this
sense, the series defines a set of functions called “profiles” that
performs standard procedures for telecontrol systems. Not all
the implementations perform the same functions, so an application
profile must be described depending on the telecontrol
system functionality.
System Architecture
The OFESAPO architecture is shown in Fig. 4. The GPS
module and the mobile communication modules are connected
to the RTU via RS-232 ports. The RTU is configurable, so it is
also possible to include other kinds of measurements made, for
instance, from a temperature sensor or others. The OS installed
in the RTU is Linux, as explained before, so it is easy to develop
high-level open software.
Acquisition Process
The GPS module is connected to the RTU via an RS-232
port, as shown in Fig. 4. The transmission speed of the RS-232
port is set at 9600 b/s, which is the maximum speed that can be
configured, as data are lost at lower speeds.
The GPS position data are sent from the GPS as a text string
of 13 lines. Each line represents different kinds of data, some
defined by The National Marine Electronics Association and
others by the GPS manufacture; in the case of OFESAPO, it is
Garmin [23]. Each string line is labeled to interpret correctly
the data that are received by the GPS.
The GPS receives a new position data, i.e., the thirteen lines,
every second, and they are saved in a buffer because one RTU
only sends data to the CC when it is polled. Therefore, the
transmission control process has to read this buffer when the
CC polls the RTU to get the information required in the position
ASDU. As it is well known, there is a problem when two or
more processes share a variable. One process can be writing
the variable when the other is reading it, and then the read
variable is incorrect. In the literature, there are some solutions
to this problem. The typical one is using semaphores, but in this
case, they are not a solution because the acquisition process is
blocked when the transmission control process is reading the
variable, so the acquisition process could not write.
Transmission Control Process
This process sets the general configuration parameters as the
working directories, the number of RTUs to be controlled, and
the connection parameters (IP address, TCP port, and physical
medium) of each RTU as well as others. It also boots and
allocates memory for the different resources (log files, data
structured, ASDUs, etc.).
Depending on the configuration parameters, the CC checks
that all the configured RTUs are able to establish a TCP
connection—each RTU is always previously initialized in listening
passive mode; once the connection is established, the
initialization process ends.
Another task made in this process is getting position data
from RTU, for doing so, each configured RTU is polled periodically
by the CC, as described in the IEC standard.
SYSTEM TESTING
A set of tests has been made to check that OFESAPO works
correctly and can be adapted to different scenarios. Some tests
have been made in a real environment, where there were some
moving RTUs sending their position data to the CC that showed
them in Google Map in real time. Others have been made in a
simulation environment to determine the system limitations.
As OFESAPO is intended to be applied in surveillance
applications, the time requirements for real time are from 5 to
10 s, but if the system could guarantee a time from 1 to 5 s, then
it could be applied in control applications, as shown in [5].
The following sections describe the two sets of tests.
CONCLUSION
This paper has traced the OFESAPO development through
real-time positioning and telecontrol systems. Although realtime
positioning and telecontrol systems are also shown in [5]
and [6], OFESAPO differs from them in that it is based on both
open hardware and software, and it allows more RTUs to be
controlled. The hardware in OFESAPO RTU is an embedded
system, i.e., an SoC-type design using FPGA that has been
programmed with the open core LEON with a Linux OS
running over it. For communication and control between a CC
and RTUs, the IEC 60870-5 standard over TCP/IP has been
used. All the software has been developed and tested in a PC
with Linux OS using standard tools, so there is no requirement
to use specific software design tools for embedded systems,
as shown in [19] and [20]. This software has run without any
problem in the RTU based in LEON.
[attachment=46051]
Abstract
This paper presents the development and testing of
an open and flexible embedded system applied to positioning and
telecontrol (OFESAPO) for outdoor applications. The system is
composed of a control center (CC) and a set of remote terminal
units (RTUs); the International Electrotechnical Commission
(IEC) 60870-5 series has been chosen for communication among
them. This is a standard protocol of real-time telecontrol applications.
The CC is a personal computer, and the RTUs are
based on open hardware and software. The RTU hardware is an
embedded system, i.e., a system-on-chip-type design using fieldprogrammable
gate array that has been programmed with the
open-core LEON running Linux operating system. For prototyping,
the GR-XC3S-1500 board has been used. As there is no open
source code available for the IEC standard protocols, an open
source code has also been implemented. Hence, both the hardware
and the software are open source in OFESAPO. Several tests have
been made to show the system’s limitations and the suitability for
real-time applications. A prototype has also been tested in a real
environment, where the real position of two moving RTUs was
shown by a CC using Google Map.
INTRODUCTION
POSITIONING technology and mobile communication
provide the right environment to make location-based services
(LBS) closer to daily life. There are many applications
of LBS that make people’s or business life easier because of
the ability to send positioning information in real time, for
instance, the waiting time for a bus in a bus stop. Another
application is surveillance, for example, in forest fire fights, not
only of firefighters but also of vehicles, or in rescue operations.
These kinds of applications use mobile devices (personal digital
assistant (PDA), cell telephone, etc.), controlled devices, a
controller device (a computer, a PDA, etc.), and a real-time
geographic information system (GIS). The controlled devices
are equipped with both a positioning technology and a mobile
communication.
SYSTEM DESIGN
OFESAPO is composed of “remote terminal units” (RTUs)
and a “control center” (CC). The CC is a PC-based system,
where the GIS to map in real time is placed. The RTU is an
embedded system used to acquire position data to send them to
the CC.
The RTU can also send data obtained from the environment
via sensors attached to the RTU or receives commands from the
CC due to the design criterion flexibility of OFESAPO. That
criterion makes OFESAPO similar to a supervisory control and
data acquisition (SCADA) one.
The field of SCADA systems has a series of standards
specified by the IEC called “IEC 60870-5” for telecontrol
equipment and systems. These standards define specific requirements
and conditions for data transmission in telecontrol
systems, showing the ways to meet those requirements to ensure
compatibility between devices from different suppliers. The
positioning system presented in this paper complies with these
standards, so this makes OFESAPO flexible and adaptable to
multiple environments.
To determine the RTU position, the GPS technology is used
as it is more flexible than other outdoor positioning systems, so
it is both not dependent of the cellular telephony operator and
more precise.
IEC 60870-5 Series Overview
The telecontrol protocol stack usually implements the specifications
provided by the IEC called “IEC 60870-5” [9]. This
series follows the enhanced protocol architecture model, not the
ISO standard (open system interconnection (OSI) model). This
model only requires three of the seven OSI layers, i.e., application
layer, data link layer, and physical layer. The standard is
divided into six parts and specifies a suite of protocols for both
application and data link layers.
In a typical telecontrol scenario, one station (primary station)
called “CC” controls communication with other stations (secondary
stations) called “RTUs,” so the IEC 60870-5 specification
allows real-time telecontrol applications to function. In this
sense, the series defines a set of functions called “profiles” that
performs standard procedures for telecontrol systems. Not all
the implementations perform the same functions, so an application
profile must be described depending on the telecontrol
system functionality.
System Architecture
The OFESAPO architecture is shown in Fig. 4. The GPS
module and the mobile communication modules are connected
to the RTU via RS-232 ports. The RTU is configurable, so it is
also possible to include other kinds of measurements made, for
instance, from a temperature sensor or others. The OS installed
in the RTU is Linux, as explained before, so it is easy to develop
high-level open software.
Acquisition Process
The GPS module is connected to the RTU via an RS-232
port, as shown in Fig. 4. The transmission speed of the RS-232
port is set at 9600 b/s, which is the maximum speed that can be
configured, as data are lost at lower speeds.
The GPS position data are sent from the GPS as a text string
of 13 lines. Each line represents different kinds of data, some
defined by The National Marine Electronics Association and
others by the GPS manufacture; in the case of OFESAPO, it is
Garmin [23]. Each string line is labeled to interpret correctly
the data that are received by the GPS.
The GPS receives a new position data, i.e., the thirteen lines,
every second, and they are saved in a buffer because one RTU
only sends data to the CC when it is polled. Therefore, the
transmission control process has to read this buffer when the
CC polls the RTU to get the information required in the position
ASDU. As it is well known, there is a problem when two or
more processes share a variable. One process can be writing
the variable when the other is reading it, and then the read
variable is incorrect. In the literature, there are some solutions
to this problem. The typical one is using semaphores, but in this
case, they are not a solution because the acquisition process is
blocked when the transmission control process is reading the
variable, so the acquisition process could not write.
Transmission Control Process
This process sets the general configuration parameters as the
working directories, the number of RTUs to be controlled, and
the connection parameters (IP address, TCP port, and physical
medium) of each RTU as well as others. It also boots and
allocates memory for the different resources (log files, data
structured, ASDUs, etc.).
Depending on the configuration parameters, the CC checks
that all the configured RTUs are able to establish a TCP
connection—each RTU is always previously initialized in listening
passive mode; once the connection is established, the
initialization process ends.
Another task made in this process is getting position data
from RTU, for doing so, each configured RTU is polled periodically
by the CC, as described in the IEC standard.
SYSTEM TESTING
A set of tests has been made to check that OFESAPO works
correctly and can be adapted to different scenarios. Some tests
have been made in a real environment, where there were some
moving RTUs sending their position data to the CC that showed
them in Google Map in real time. Others have been made in a
simulation environment to determine the system limitations.
As OFESAPO is intended to be applied in surveillance
applications, the time requirements for real time are from 5 to
10 s, but if the system could guarantee a time from 1 to 5 s, then
it could be applied in control applications, as shown in [5].
The following sections describe the two sets of tests.
CONCLUSION
This paper has traced the OFESAPO development through
real-time positioning and telecontrol systems. Although realtime
positioning and telecontrol systems are also shown in [5]
and [6], OFESAPO differs from them in that it is based on both
open hardware and software, and it allows more RTUs to be
controlled. The hardware in OFESAPO RTU is an embedded
system, i.e., an SoC-type design using FPGA that has been
programmed with the open core LEON with a Linux OS
running over it. For communication and control between a CC
and RTUs, the IEC 60870-5 standard over TCP/IP has been
used. All the software has been developed and tested in a PC
with Linux OS using standard tools, so there is no requirement
to use specific software design tools for embedded systems,
as shown in [19] and [20]. This software has run without any
problem in the RTU based in LEON.