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.