Download SCADA Systems, RTOS

SCADA Systems
While creating working place of the operator of Automatic Control
System of Technological Process we need control bodies of different types
similar to conventionally used: buttons, switches, shifting and rotating
regulators. We need also screen forms process parameters indicators of
different types: arrows-based, shift-based, digital indicators, and also
alerting tables of different form and contents. Also, we need possibility of
creation of archives of events and keep track of variables behavior with time
run. It is necessary also to have real-time kernel providing predictable
response times on external events. Also, drivers responsible for interactions
with low-level devices of the system are necessary. Usually, systems work in
distributed environment, and network facilities are necessary: authorization
of access, maintenance of network protocols. Also, we need multi-windows
graphical interface, rich library of control algorithms, objects, there must be
built-in language for simple programming.
SCADA GENIE BY ADVANTECH
All these features are provided by Supervisor Control and Data
Acquisition (SCADA) systems, for example, system Genie provided by
Advantech company:
SCADA GENIE BY ADVANTECH (CONT 1)
This is what can be seen by user. Respective project is given below:
A tool set for usage in project development is represented at the left.
SCADA GENIE BY ADVANTECH (CONT 2)
Contents of programmed unit PRG1 follows:
Next figure shows that bar indicator on the user’s screen displays
outputs provided by PRG1 unit:
SCADA GENIE BY ADVANTECH (CONT 3)
Well-known SCADA systems are Genesis32 by Iconics, products of
Advantech company, Russian SCADA system TraceMode by AdAstra
company:
REAL-TIME OPERATING SYSTEMS (RTOS)
RTOS should be modular and extensible. Usually operating system is
represented by the following levels:
User interface – Shell – Operating system executives
File and disk support - Extended and Basic I/O executives
Inter-task synchronization and communication – Kernel
Task scheduling – micro-kernel
Tread/task control, block management – nano-kernel
All 3 lower levels may be realized by kernel, but these functions may be
split on different levels.
When threads are created, Thread Control Blocks are associated with them.
In addition to commonly used here such data as Thread ID, starting address,
context, synchronization information, for RTOS there may be used Task
Type (periodic, sporadic), phase, period, relative deadline, number of
instances, event list.
Clock devices are very important for RTOS, they issue interrupts each tick,
for most RTOS, this tick size is 10 milliseconds. At each clock interrupt, the
kernel does following:
1. Processes timer events: A clock device has a timer queue, and kernel
finds out what events has occurred now, and carries out respective
actions (for example, activation of some tasks).
2. Updates execution budget: Decrements the budget of a thread to find
out, whether to preempt it or continue its execution.
3. Updates the ready queue and returns control: If current thread is to be
preempted, it makes rescheduling, and gives control to the thread at
the head of the highest priority queue.
REAL-TIME OPERATING SYSTEMS (CONT 1)
RTOS usually provide opportunity for applications to create their own
software timers, either periodic, either one-shot.
In the case of external interrupts, for example, message came from the
network, handler must understand to what thread it is addressed, and
deliver it to the address space of the respective thread, perform
handshakes protocol with sender, and so on. Such actions may require up
to tens of milliseconds to complete. So, most RTOS divide such
interrupts handling in two parts: Immediate interrupt service, which is
executed at an interrupt priority level, and Scheduled interrupt
service, which is executed at a suitable priority level. First step
prepares all necessary information for the further processing in the
normal way, as for usual tasks.
For the sake of scheduling RTOS use usually up to 256 priority levels.
Priorities are usually assigned using Rate Monotonic and Deadline
Monotonic strategies, which execute in the first turn tasks with higher
frequency and earlier deadlines.
Threads may ask for non-preemptable mode of working with critical
resources, it must be provided by RTOS. RTOS usually maintain priority
inheritance protocols (when application uses high priority resource, it
runs on the high priority level).
In the case of multiprocessor systems RTOS must have a mask of
processors for each task, showing on what processors it is allowed to
launch this task.
In the case of using virtual memory RTOS provide possibility for
application to pin used by it pages.
REAL-TIME OPERATING SYSTEMS (CONT 2)
For increasing efficiency, RTOS may have several schedulers, for each
group of tasks: non-real-time, real-time periodic, real-time aperiodic,
communication tasks, and general scheduler, which decides, what task to
take next from provided by partial schedulers.
Commercial RTOS (LynxOs, pSOS, QNX, VRTX, vxWorks) have
the following features conforming to standard – Real-Time POSIX
(Portable OS Interface).
Let’s consider some of them.
QNX/Neutrino – QNX Software Systems, USA
Is
multiprocessor
operating
system.
Uses
Symmetrical
Multiprocessors with gigabytes of physical memory. Its microkernel
provides essential thread and real-time services. Other operating system
services are provided by optional components called resource managers.
In QNX 4.x microkernel is 12 K bytes in size.
QNX is a message-passing system. Messages are delivered according
to priorities and the service provider executes at the priority of the
highest priority clients waiting for service. QNX messages are transferred
via channels. QNX’s message send and receive functions are blocking (in
POSIX sender is not blocked). Neutrino (recent version of QNX)
provides atomic operations for adding and subtracting value, setting and
clearing bit, complementing bit.
Provides 32 priority levels, uses FIFO, Round Robin, preemptive.
Uses semaphores, mutexes, conditional variables.
VxWorks – WindRiver System, USA
Was used in Mars Pathfinder which NASA sent to Mars in 1997 (and is used
now in Mars rovers Spirit and Opportunity). After landing on Mars it has
problems with repeatedly reseting of the computer. It was due to priority
inversion which lead to not acceptable delay of important tasks, and system
reset itself. Nowadays there were also problems with rebooting due to
“Spirit attempted to allocate more files than the RAM-based directory structure could
accommodate. That caused an exception, which caused the task that had attempted
the allocation to be suspended. That in turn led to a reboot, which attempted to
mount the flash file system. But the utility software was unable to allocate enough
memory for the directory structure in RAM, causing it to terminate, and so on.”
http://www.embedded.com/showArticle.jhtml?articleID=17800188
It uses cross-development C/C++ environment Tornado. Provides 256
priority levels. Can work in multiprocessor systems. Uses priority
preemptive scheduling. For synchronization uses semaphores, queues,
signals.
It is used in Spirit and Opportunity being on Mars now. They use
radiation-hardened R6000 CPU from Lockheed-Martin Federal Systems
with 120 RAM and 256 Mb flash. They use Wind River Systems
VxWorks 5.3.1 with its flash file system extension. In operation, the
RTOS and other exe are RAM resident. About 230 M are used to
implement flash file system that stores ‘data product’ for transmission to
Earth.
Spirit attempted to allocate more files than ROM-based directory
structure could accommodate. That caused exception, which caused the
task that had attempted allocation to suspended, that in turn led to a
reboot, which attempted to mount the flash file system. That utility
software was unable to allocate enough memory for the directory
structure in RAM, causing it to terminate, and so on.