 |
Too many Rt's around? That's
how it should be in a real-time environment.
Here you find short technical descriptions of all the Rt* components
that constitute RTA:
|
|
a network-wide, distributed, active, real-time database
that provides high speed data distribution via the TCP/IP network.
In contrast to conventional real-time capable database systems, RtDB
represents a combination of an active, real-time and a relational
database. Thus RtDB provides on the one hand an interface to the active,
real-time database for high-speed data processing and a SQL interface
to the relational database for standardized data access. The integrity
of the data between the real-time database and the relational database
is assured by a synchronization mechanism, which automatically keeps
track of changes in either of the databases. It provides for distribution
of changed data between the two databases as well as providing for
distribution of data changes between different nodes in a distributed
or redundant system. RtDB uses RtIpC to distribute data to other nodes.
Thus real-time database tables can be distributed in a network. |
| |
back to top |
|
|
a network-wide inter-process communication mechanism
(queue based) that allows high data transmission rates between applications.
Data transmission can be done between applications within single nodes
as well as between applications on different nodes in a network (TCP/IP).
On local nodes shared memory is used which makes the communication
very fast. It also incorporates RtRM which enables
it to selectively communicate with applications on e.g. the MASTER
node or STANDBY node only. |
| |
back to top |
|
|
a supervisor function that has network-wide control
over RTA nodes and RTA applications in redundant systems to allow
real-time MASTER - STANDBY switching (software switching) in case
of system malfunctions. The real time redundancy manager is not only
required for the implementation of redundant configurations, it has
also control over all important applications on single nodes. Its
job is to watch over all RTA components and applications and, in case
a component or program fails, to activate specific routines like system
restart or node switching (MASTER-STANDBY switching). |
| |
back to top |
|
|
RtVars are Real Time Variables that can be accessed using RtPL
as well as Visual Studio program languages (like Visual Basic, Visual-C).
RtVars provide access to all necessary components in the system
like RtDB tables, Oracle tables, operating system information (environment,
timers etc.). An RtVar can be active or passive. Active RtVars allow
external triggers to be activated whenever the value of the RtVar
changes. Due to that a system based on RTA is very much event-driven.
At the first glimpse Real Time Variables (RtVars) look like and
behave like normal variables in BASIC or C programs and as such
they are very simple to handle. But compared to regular variables
RtVars provide some tremendous advantages:
- Events: whenever the value of a RtVar is changed the RtVar
generates an event, programs can install triggers to catch such
events and immediately launch specific processing depending on
the new value of the changed RtVar
- Complex Data Types: beside the elementary data types like INTEGER,
STRING, DOUBLE, ADDRESS (for pointer usage) and BINARY (for blobs)
RtVars implement a wide range of complex data types. Complex data
types provide access to a big number of different data sources
(read access) and data destinations (write access) in a very simple
way. Hence access to the operating system date and time functions,
to operation system environment variables, to SQL database tables
and many other data sources and destinations, is established through
RtVars in quite the same simple way like e.g. for an INTEGER or
for a STRING RtVar.
- Extended Scope: an elementary RtVar can have a LOCAL scope
(it is known in the local procedure), a MODULE scope (it is known
in a certain module), a GLOBAL scope (it is known in the current
task/program), a COMMON scope (it is known on the current node/computer)
or a NETWORK scope (it is known on all nodes/computers in the
network). The scope of a Complex RtVar depends on the type of
the RtVar, e.g. a date/time RtVar has a COMMON scope because the
system date and time provided by the operating system is valid
for the whole node/computer.
- C-API: this allows C programs to make full use of all RtVar
features via an API. Although existing RtVars can be defined and
used via this API, the main purpose of this API is to allow for
the implementation of additional RtVar types (new complex data
types). Such a new RtVar type could e.g. be a graphical object
with all its attributes. In case of a graphical input object the
RtVar may be readable and write-able (source and destination),
in all other cases it may only be write-able (destination) to
allow changes on the attributes of the graph.
|
| |
back to top |
|
|
Is a BASIC like programming language that was primarily
developed to take full advantage of RtVars in a simple and efficient
way. RtPL programs are simple ASCII files that are automatically 'compiled'
into memory at load time. No separate compiling and linking is necessary.
Although RtPL files are plain ASCII files, the fact that they are
'compiled' into memory makes them extremely fast. The fact that they
are just ASCII files that don't require compilation and linking, makes
them most suitable for Rapid Application Development and Prototyping.
RtPL files are used for implementation of the core of real-time process
control applications. The RtPL language provides constructors to implement
loops and conditions and to define and use RtPL functions and procedures
and, most off all, to use RtVars. The Real Time Application Programming
Language (RtPL) provides a mechanism to specify ECA Rules (Event Condition
Action Rules) using RtVars. The condition is specified as RtVar expression
which is triggered whenever e.g. the value of the RtVar changes. If
the condition is met the action is executed. The action may be any
C or RtPL function or procedure or just a plain PL statement. ECA
Rules extend the functionality of RtPL far beyond the functionality
of most existing programming languages. |
| |
back to top |
|
