Transcript Diapozitiv 1 - University of Ljubljana

Operacijski sistemi
za delo v realnem času
Sistemi za delo v realnem času
• A system is said to be Real Time if it is
required to complete it’s work & deliver it’s
services on time.
• Example – Flight Control System
– All tasks in that system must execute on time.
• Non Example – PC system
Mehki in trdi sistemi za delo v realnem času
• Hard Real Time System
– Failure to meet deadlines is fatal
– example : Flight Control System
• Soft Real Time System
– Late completion of jobs is undesirable but not fatal.
– System performance degrades as more & more jobs miss
deadlines
– Online Databases
• Qualitative Definition.
Mehki in trdi sistemi za delo v realnem času
• Hard Real Time System
– Validation by provably correct procedures or extensive
simulation that the system always meets the timings
constraints
• Soft Real Time System
– Demonstration of jobs meeting some statistical constraints
suffices.
• Example – Multimedia System
– 25 frames per second on an average
Example: Fly-by-wire Avionics
• Hard real-time system with multirate behavior
Sensors
Signal
Conditioning
gyros,
accel.
INU
1kHz
GPS
GPS
20 Hz
Sensor
Air data
1 kHz
Stick
Joystick
500 Hz
Control laws
Pitch control
500 Hz
Lateral Control
250 Hz
Throttle Control
250 Hz
Actuating
Actuators
Aileron 1
1 kHz
Aileron
Aileron 2
1 kHz
Aileron
Elevator
1 kHz
Elevator
Rudder
1 kHz
Rudder
Peripheral devices and protocols
• Interfacing
Serial/parallel ports, USB, I2C, PCMCIA, IDE
• Communication
Serial, Ethernet, Low bandwidth radio, IrDA,
802.11b based devices
• User Interface
LCD, Keyboard, Touch sensors, Sound, Digital
pads, Webcams
• Sensors
A variety of sensors using fire, temperature,
pressure, water level, seismic, sound, vision
Trdi RTOS…
• Thread priorities can be set by the client
• Threads always run according to priority
• Kernel must be preemptible or bounded
• Interrupts must be bounded
• No virtual memory
Mehki RTOS…
• Like a hard RTOS:
–
–
–
–
Priority scheduling, with no degradation
Low dispatch latency
Preemptible system calls
No virtual memory (or allow pages to be locked)
• Linux: guarantees about relative timing of
tasks, no guarantees about syscalls
Vloga OS v sistemih realnega časa
• Standalone Applications
– Often no OS involved
– Micro controller based Embedded Systems
• Some Real Time Applications are huge & complex
–
–
–
–
Multiple threads
Complicated Synchronization Requirements
Filesystem / Network / Windowing support
OS primitives reduce the software design time
Ali za RT potrebujem operacijski sistem?
• Ne vedno
• Preprost pristop: cikličen izvajalnik
loop
do part of task 1
do part of task 2
do part of task 3
end loop
Cikličen izvajalnik
• Prednosti
– Preprosta implementacija
– Nizek "overhead"
– Visoka predvidljivost
• Slabosti
– Se ne more odzivati na sporadične dogodke
– Vse se izvaja v zanki
– Kodo razvrščamo ročno
Prekinitve
• Nekateri dogodki ne morajo čakati na naslednjo
iteracijo zanke
– Komunikacijski kanali
– Prehodni dogodki
• Rešitev: Cilkičen izvajalnik + prekinitvene rutine
Ciklični izvajalnik + prekinitve
• Primeren za aplikacije za procesiranje signalov
• Cenen, predvidljiv rokovalnik prekinitev:
– When interrupt occurs, execute a single user-specified
instruction
– This typically copies peripheral data into a circular buffer
– No context switch, no environment save, no delay
• Slabosti
–
–
–
–
Main loop still running in lockstep
Programmer responsible for scheduling
Scheduling static
Sporadic events handled slowly
Cooperative Multitasking
•
•
•
•
•
A cheap alternative
Non-preemptive
Processes responsible for relinquishing control
Examples: Original Windows, Macintosh
A process had to periodically call get_next_event() to let other
processes proceed
• Drawbacks:
– Programmer had to ensure this was called frequently
– An errant program would lock up the whole system
• Alternative: preemptive multitasking
Konkurenčnost zagotavlja OS
• Basic philosophy:
Let the operating system handle scheduling, and let the
programmer handle function
• Scheduling and function usually orthogonal
• Changing the algorithm would require a change in
scheduling
Značilnosti RTOS
•
•
•
•
Razvrščanje.
alokacija resursov.
Rokovanje prekinitev.
Velikost jedra itd.
Inter Process Communication
• Primary ones: Shared Memory, Pipes, sockets,
message queues
• Important characteristics to be taken care of:
 Non-blocking communication
 Bounded latency
 Asynchronous communication
Memory Management
• Most RTOS allow restricted use of dynamic memory
allocation- in soft RT systems
- to avoid garbage collection.
• Providing support for Virtual Memory is a big decision to
make.
• Movement of data between disk and RAM is a slow process.
How slow?? Leads to non-determinism
• Not providing VM, means not using MMU in processor.
• VM provided with minimum capabilities, Process “Locked”
in memory and hence no swapping has to be done- could be
used for soft real-time.
Comparison of some RTOS
Synchronization
IPC
Memory
Management
QNX
Constructs: Semaphores,
message passing, signals
Protocol: PIP
Message queues,
pipes, soclkets
(similar to sockets)
Virtual Memory: Yes
Dynamic Allocation:
Yes
VxWorks
Constructs: Interrupt Locks,
Preemptive Locks,
semaphores
Protocol: PCP(HLP)
Message queues,
pipes, sockets,
RPC (for distributed
implementation)
Virtual Memory: Yes
Dynamic Allocation:
Yes (optional addon)
LynxOS
Constructs: signals,
semaphores, condition
variables
Protocol: PCP(HLP)
Message queues,
pipes, sockets,
shared memory
Virtual Memory: Yes
Dynamic Allocation:
Yes
Obvezne zahteve za RTOS
• an RTOS has to be multithreaded and preemptible.
• the notion of thread priority has to exist.
• the OS has to support predictable thread synchronisation
mechanisms
• a system of priority inheritance has to exist.
• OS Behaviour should be known
Vgrajeni OS: Zahteva:konfigurabilnost
•
No single RTOS will fit all needs, no overhead for
unused functions tolerated  configurability needed.
–
–
–
–
–
simplest form: remove unused functions (by linker ?).
Conditional compilation (using #if and #ifdef commands).
Dynamic data might be replaced by static data.
Advanced compile-time evaluation useful.
Object-orientation could lead to a derivation subclasses.
•Verification a potential problem of systems
with a large number of derived OSs:
– Each derived OS must be tested thoroughly;
Vgrajeni OS: zahteva:Disk in omrežje naj upravljajo
posli(tasks)
– Disc & network handled by tasks instead of integrated drivers.
Relatively slow discs & networks can be handled by tasks.
– Many ES without disc, a keyboard, a screen or a mouse.
– Effectively no device that needs to be supported by all
versions of the OS, except maybe the system timer.
Embedded OS
kernel
Standard OS
Vgrajeni OS: opcija: zaščita
•Protection mechanisms not always necessary:
ES typically designed for a single purpose,
untested programs rarely loaded, SW considered
reliable.
Privileged I/O instructions
not necessary
and
(However,
protection
mechanisms
may be needed
tasks can do their own I/O.
forExample:
safety
security
reasons).
Letand
switch
be the address
of some switch
Simply use
load register,switch
instead of OS call.
Vgrajeni OS:zahteva: prekinitve niso omejene na OS
•Interrupts can be employed by any process
For standard OS: serious source of unreliability.
Since
–
–
–
–
embedded programs can be considered to be tested,
since protection is not necessary and
since efficient control over a variety of devices is required,
it is possible to let interrupts directly start or stop tasks (by
storing the tasks start address in the interrupt table).
– More efficient than going through OS services.
– Reduced composability: if a task is connected to an interrupt, it
may be difficult to add another task which also needs to be
started by an event.
Vgrajeni OS:zahteva zmožnost realnega časa
•Many embedded systems are real-time (RT)
systems and, hence, the OS used in these systems
must be real-time operating systems (RTOSes).
Operacijski sistemi za delo v realnem času: RTOS
•
Def.: (A) real-time operating system is an operating system that
supports the construction of real-time systems
•
Ključne zahteve so:
1. The timing behavior of the OS must be predictable.
 services of the OS: Upper bound on the execution time!
RTOSs must be deterministic:
–
unlike standard Java,
–
short times during which interrupts are disabled,
–
contiguous files to avoid unpredictable head movements.
Operacijski sistemi za delo v realnem času: RTOS
2. OS must manage the timing and scheduling
– OS possibly has to be aware of task deadlines;
(unless scheduling is done off-line).
– OS must provide precise time services with high resolution.
Razvrščanje v RTOS
• More information about the tasks are known
–
–
–
–
–
No of tasks
Resource Requirements
Release Time
Execution time
Deadlines
• Being a more deterministic system better scheduling
algorithms can be devised.
Typical RTOS Task Model
• Each task a triplet: (execution time, period, deadline)
• Usually, deadline = period
• Can be initiated any time during the period
Initiation
Execution time
Deadline
Time
Period
Real-Time Is Not Fair
• Main goal of an RTOS scheduler: meeting deadlines
• If you have five homework assignments and only one
is due in an hour, you work on that one
• Fairness does not help you meet deadlines
Algoritmi razvrščanja pri RTOS
• Clock Driven Scheduling
• Weighted Round Robin Scheduling
• Priority Scheduling
(Greedy / List / Event Driven)
Clock Driven scheduling
• All parameters about jobs (release time/
execution time/deadline) known in advance.
• Schedule can be computed offline or at some
regular time instances.
• Minimal runtime overhead.
• Not suitable for many applications.
Weighted Round-Robin Approach
• Different jobs given different weights
– weight is fraction of processor time allocated
to job
• Size of time slice given to job depends on
weight
• Proposed for scheduling real-time traffic in
high-speed switched networks built on
round-robin scheme.
Weighted Round Robin
• Jobs scheduled in FIFO manner
• Time quantum given to jobs is proportional to it’s
weight
• Example use : High speed switching network
– QOS guarantee.
• Not suitable for precedence constrained jobs.
– Job A can run only after Job B. No point in giving time
quantum to Job B before Job A.
Priority-based Scheduling
• Typical RTOS based on fixed-priority preemptive
scheduler
• Assign each process a priority
• At any time, scheduler runs highest priority process
ready to run
• Process runs to completion unless preempted
Priority-based Preemptive Scheduling
• Always run the highest-priority runnable process
1
2
3
Priority Scheduling
• Processor never left idle when there are ready tasks
• Processor allocated to processes according to
priorities
• Priorities
– static - at design time
– Dynamic - at runtime
Priority Scheduling
• Earliest Deadline First (EDF)
– Process with earliest deadline given highest priority
• Least Slack Time First (LSF)
– slack = relative deadline – execution left
• Rate Monotonic Scheduling (RMS)
– For periodic tasks
– Tasks priority inversely proportional to it’s period
Priority-Based Preempting Scheduling
• Multiple processes at the same priority level?
• A few solutions
– Simply prohibit: Each process has unique priority
– Time-slice processes at the same priority
• Extra context-switch overhead
• No starvation dangers at that level
– Processes at the same priority never preempt the other
• More efficient
• Still meets deadlines if possible
Priority Inversion
• RMS and EDF assume no process interaction
• Often a gross oversimplification
• Consider the following scenario:
1
2
Process 1 tries to acquire lock for resource
Process 1 preempts Process 2
Process 2 acquires lock on resource
Process 2 begins running
Priority Inversion
• Lower-priority process effectively blocks a higherpriority one
• Lower-priority process’s ownership of lock prevents
higher-priority process from running
• Nasty: makes high-priority process runtime
unpredictable
Nastier Example
• Higher priority process blocked indefinitely
Process 2 delays process 3’s release of lock
1
2
3
Process 1 tries to acquire lock and is blocked
Process 1 preempts Process 2
Process 2 preempts Process 3
Process 3 acquires lock on resource
Process 3 begins running
Inverzija prioritete
Priority Inheritance
• Solution to priority inversion
• Temporarily increase process’s priority when it
acquires a lock
• Level to increase: highest priority of any process that
might want to acquire same lock
– I.e., high enough to prevent it from being preempted
• Danger: Low-priority process acquires lock, gets high
priority and hogs the processor
– So much for RMS
Priority Inheritance
• Basic rule: low-priority processes should acquire
high-priority locks only briefly
• An example of why concurrent systems are so hard
to analyze
• RMS gives a strong result
• No equivalent result when locks and priority
inheritance is used
Rešitev inverzije prioritete
• Non Blocking Critical Section
– Higher priority Thread may get blocked by unrelated low
priority thread
• Priority Ceiling
– Each resource has an assigned priority
– Priority of thread is the highest of all priorities of the
resources it’s holding
• Priority Inheritance
– The thread holding a resource inherits the priority of the
thread blocked on that resource
Drugi vidiki RTOS
• Interrupt Latency should be very small
– Kernel has to respond to real time events
– Interrupts should be disabled for minimum possible time
• For embedded applications Kernel Size should be
small
– Should fit in ROM
• Sophisticated features can be removed
– No Virtual Memory
– No Protection
Rate-Monotonic Scheduling
• Common way to assign priorities
• Simple to understand and implement:
Processes with shorter period given
higher priority
• E.g.,
Period Priority
10
1
12
2
15
3
20
4
(highest)
(lowest)
RMS Missing a Deadline
• p1 = (10,20,20) p2 = (15,30,30) utilization is 100%
1
2
Would have met the deadline if p2 =
(10,30,30), utilization reduced 83%
P2 misses first deadline
When Is There an RMS Schedule?
• Key metric is processor utilization: sum of compute
time divided by period for each process:
U =  ci / pi
• No schedule can possibly exist if U > 1
– No processor can be running 110% of the time
• Fundamental result:
– RMS schedule always exists if U < n (2 1/n – 1)
– Proof based on case analysis (P1 finishes before P2)
When Is There an RMS Schedule?
• Asymptotic result:
If the required processor utilization is under 69%,
RMS will give a valid schedule
• Converse is not true. Instead:
If the required processor utilization is over 69%, RMS
might still give a valid schedule, but there is no
guarantee
EDF Scheduling
• RMS assumes fixed priorities
• Can you do better with dynamically-chosen
priorities?
• Earliest deadline first:
Processes with soonest deadline
given highest priority
EDF Meeting a Deadline
• p1 = (10,20,20) p2 = (15,30,30) utilization is 100%
1
2
P2 takes priority because its deadline is
sooner
Key EDF Result
• Earliest deadline first scheduling is optimal:
If a dynamic priority schedule exists, EDF
will produce a feasible schedule
• Earliest deadline first scheduling is efficient:
A dynamic priority schedule exists if and only if
utilization is no greater than 100%
Static Scheduling More Prevalent
• RMA only guarantees feasibility at 69% utilization,
EDF guarantees it at 100%
• EDF is complicated enough to have unacceptable
overhead
• More complicated than RMA: harder to analyze
• Less predictable: can’t guarantee which process runs
when
Summary
• Cyclic executive
– Way to avoid an RTOS
– Adding interrupts helps somewhat
• Interrupt handlers
– Gather data, acknowledge interrupt as quickly as possible
• Cooperative multitasking
– But programs don’t like to cooperate
Summary
• Preemptive Priority-Based Multitasking
– Deadlines, not fairness, the goal of RTOSes
• Rate-monotonic analysis
– Shorter periods get higher priorities
– Guaranteed at 69% utilization, may work higher
• Earliest deadline first scheduling
– Dynamic priority scheme
– Optimal, guaranteed when utilization 100% or less
Summary
• Priority Inversion
– Low-priority process acquires lock, blocks higher-priority
process
– Priority inheritance temporarily raises process priority
– Difficult to analyze
RTOS-Kernels
•Distinction between
– real-time kernels and modified kernels of standard
OSes.
Distinction between
 general RTOSes and RTOSes for specific domains,
 standard APIs (e.g. POSIX RT-Extension of Unix, ITRON, OSEK) or
proprietary APIs.
Functionality of RTOS-Kernels
•Includes
– processor management,
– memory management,
resource management
– and timer management;
– task management (resume, wait etc),
– inter-task communication and synchronization.
Classes of RTOSes
1. Fast proprietary kernels
•Fast proprietary kernels
For complex systems, these kernels are
inadequate, because they are designed to be fast,
rather than to be predictable in every respect
Examples include
QNX, PDOS, VCOS, VTRX32, VxWORKS.
Classes of RTOSes
2. Real-time extensions to standard OSs
•Real-time extensions to standard OSes:
Attempt to exploit comfortable main stream OSes.
RT-kernel running all RT-tasks.
Standard-OS executed as one task.
+ Crash of standard-OS does not affect RT-tasks;
- RT-tasks cannot use Standard-OS services;
less comfortable than expected
Primeri RTOS
• Micrium c-OS II
http://www.ucos-ii.com/
• AvrX
http://www.barello.net/avrx/
• RTLinux
http://fsmlabs.com/developers/man_pages/
• QNX Neutrino
http://www.qnx.com/
Linux for Real Time Applications?
• Scheduling
– Priority Driven Approach
• Optimize average case response time
– Interactive Processes Given Highest Priority
• Aim to reduce response times of processes
– Real Time Processes
• Processes with high priority
• No notion of deadlines
• Resource Allocation
– No support for handling priority inversion
Linux Scheduling
• Real-time scheduling class
• Scheduled based on fixed priority
• Scheduling threads with the same priority
• SCHED_FIFO: First-In-First-Out
• SCHED_RR: Round-Robin
• Non-real-time scheduling class (SCHED_OTHER)
• Priority is adjusted dynamically to favor I/O bound threads
• Default
• Real-time: 0 – 99
• Non-real-time: 100 – 139
Interrupt Handling in Linux
• Interrupts are disabled in ISR/critical sections of the
kernel
• No worst case bound on interrupt latency avaliable
– eg: Disk Drivers may disable interrupt for few hundred
milliseconds
• Not suitable for Real Time Applications
– Interrupts may be missed
Other Problems with Linux
• Processes are non preemtible in Kernel Mode
– System calls like fork take a lot of time
– High priority thread might wait for a low priority thread to
complete it’s system call
• Processes are heavy weight
– Context switch takes several hundred microseconds
Why Linux
• Coexistence of Real Time Applications with non Real
Time Ones
– Example http server
• Device Driver Base
• Stability
Example: RT-Linux
Init
Bash
Mozilla
scheduler
Linux-Kernel
•RT-tasks cannot use standard
OS calls.
Commercially available from
fsmlabs (www.fsmlabs.com)
RT-Task
RT-Task
driver
interrupts
RT-Linux
RT-Scheduler
I/O
interrupts
Hardware
interrupts
•RTLinux
Linux
Process
Linux
Process
UserLevel
KernelLevel
Real-Time
Task
Real-Time
Task
Real-Time
Task
Linux Kernel
Real-Time Kernel (RT-Linux or RTAI)
Hardware
•RTLinux tasks are written and packaged as loadable
kernel modules
Example: Posix 1.b RT-extensions to Linux
•Standard scheduler can be replaced by POSIX
scheduler implementing priorities for RT tasks
RT-Task
RT-Task
Init
Bash
POSIX 1.b scheduler
Linux-Kernel
driver
I/O, interrupts
Hardware
Mozilla
Special RT-calls and
standard OS calls available.
Easy programming, no
guarantee for meeting
deadline
•More about RTLinux
• RTLinux strictly use services of RTLinux core and Linux processes
cannot access RTLinux services.
• Communication between real-time and non-real-time tasks is possible
through special queues and a shared memory interface.
• To provide deterministic response in the presence of interrupts
destined for standard Linux device drivers (which are notorious for
long disabled-preemption intervals),RTLinux provides a software
emulation layer that queues and suspends interrupts while higher
priority real-time tasks run.
• Effective use of RTLinux requires:
• fixed task set.
• Clean partition of real-time and non-real-time tasks.
Concerns with Real-Time Linux Variant
• Linux changes so fast, how can a real-time variant
keep up?
• A real-time OS requires all developers to be mindful of
designing their algorithms so that they block
interrupts minimally. How can we maintain this
discipline in the open source community?
• Linux is too complex to be a real-time operating
system.
Real-time Linux
• Compliant kernels: Modified native RTOS
• Linux binaries can run without modifications
• e.g., LynxOS
• Dual kernels: Hard real-time kernel sits below Linux
• Real-time kernel traps all interrupts and schedules all processes
• Linux runs as a low-priority process
• Real-time applications cannot take advantage of Linux calls
• No memory protection between duel kernels
• e.g., RT-Linux (FSLabs)
• Core kernel modifications: patches
• Require modifications to Linux kernel
• e.g., Linux/RK, Monta Vista Linux
RT LINUX
RT-Linux: Example
• Tech Sunrayce car
control/monitoring system:
– A workstation, which collects
data from 70 sensors with total
sampling rate of 80Hz. The
needed response times ranged
from 200 to 300 ms
– Solution: One RT tasks executing
on a computer running RT-Linux.
– Tasks:
• RT Tasks: communicating
with sensors
• Linux processes: analyzer,
GUI (Based on QT widget)
Humanoid Robots
 Univ.
of
Tokyo/Kawanda Ind.
 RT-Linux
 Height: 53 inches
 Weight: 121 lbs.
• Isamu
RTLinux Framework
RTLinux
• Real Time Kernel at the lowest level
• Linux Kernel is a low priority thread
– Executed only when no real time tasks
• Interrupts trapped by the Real Time Kernel
and passed onto Linux Kernel
– Software emulation to hardware interrupts
• Interrupts are queued by RTLinux
• Software emulation to disable_interrupt()
RTLinux (contd)
• Real Time Tasks
– Statically allocate memory
– No address space protection
• Non Real Time Tasks are developed in Linux
• Communication
– Queues
– Shared memory
RT-Linux: Scheduling
• Priority-based scheduler
– A simple preemptive fixed priority based
scheduler
– Earliest Deadline First (EDF)
– Rate Monotonic (RM)
• Can support more thru Linux kernel module
Primer "lastnega" RTOS: rtker
• Motivation
– Our own OS
• Full grasp over source code – Easily modifiable, portable
• Features
– Modular Design
• Isolation of Architecture/CPU dependent and independent code –
Easy to Port
–
–
–
–
Pluggable Scheduler
Two level Interrupt Handling
Small footprint
Oskit’s Device Driver Framework
Pluggable Scheduler
• Scheduler - part of the Application
• Kernel interacts with the scheduler through an
API
• Application developer needs to implement the
scheduler API
– Can optimize on Data Structures & Algorithms for
implementing the scheduler
rtker – Block Diagram
Two Level Interrupt Handling
• Two level Interrupt Handling
– Top Half Interrupt Handler
• Called Immediately – Kernel never disables interrupts
• Cannot invoke thread library functions - Race Conditions
– Bottom Half Interrupt Handler
• Invoked when kernel not in Critical Section
• Can invoke thread library functions
• Very Low Response time (as compared to Linux)
Two Level Interrupt Handling
Other Features
• Footprint
– Small footprint (~50kb)
• Oskit’s Device Driver Framework
– Allows direct porting of existing drivers from
Linux.
– Example – Ethernet Driver of Linux
Šenekaj RTOS
• LynxOS
– Microkernel Architecture
• Kernel provides scheduling/interrupt handling
– Additional features through Kernel Plug Ins(KPIs)
• TCP/IP stack , Filesystem
• KPI’s are multithreaded
– Memory Protection/ Demand Paging Optional
– Development and Deployment on the same host
• OS support for compilers/debuggers
Other RTOS’s (contd)
• VxWorks
– Monolithic Architecture
– Real Time Posix compliant
– Cross development System
• pSOS
– Object Oriented OS
Še enkrat:obvezne zahteve za RTOS
• an RTOS has to be multithreaded and preemptible.
• the notion of thread priority has to exist.
• the OS has to support predictable thread
synchronisation mechanisms
• a system of priority inheritance has to exist.
• OS Behaviour should be known
Ali Windows NT izpolnjuje te zahteve?
• Windows NT is multi-threaded and
preemptible
• Thread priorities
• Priority inversion
• Interrupt Management
Hard Real-Time Windows XP Environment
following the logic of the Windows XP environment, you
have decided to implement a hard real-time subsystem;
your real-time environment should be able to:
•
Preempt Windows XP anywhere, at least outside
critical Windows XP interrupt-processing code.
• Defer Windows XP interrupts and faults while running
real-time tasks.
• Process real-time interrupts while running real-time
tasks.
Functional needs of the real-time
subsystem
• interprocess communication (IPC) with the Microsoft
Win32 subsystem
• access to the Windows XP kernel functionality (interrupt
management, port I/O, shutdown/crash handlers),
• compatibility with Win32 at the source code level.
RTX Structure
RTX is implemented as a collection of libraries (both static and
dynamic), a real-time subsystem (RTSS) realized as a Windows XP
kernel device driver, and an extended HAL
The libraries provide access to the subsystem through a realtime API, known as RtWinAPI
the RtWinAPI is callable from the standard Win32 environment and
from within RTSS. Although using RtWinAPI from Win32 does not
provide the determinism available within RTSS, it does allow much
of the application development to be done in the more user-friendly
Win32 programming environment
HyperKernel – Real-time Extensions for
Windows NT/2000