INtime® 3.1 Software - tenAsys

Chapter 1: Overview
• Remote configurations: INtime software keeps RT processes in separate
segments. Keeping them separate from the RT kernel isolates and protects
addresses between complex RT processes.
• Paging: (used in both INtime and RT nodes) The RT kernel uses the processor’s
paging mode for virtual address translation, but does not implement demand
paging. Each RT process loads into its own virtual address space, defined by a 32-
bit virtual segment. Because code, data, and stack are automatically placed in noncontiguous
areas of the application’s virtual memory, memory overruns are trapped
as page faults.
• Virtual addressing: (used in both INtime and RT nodes) Since each RT process
resides in a separate memory space defined by a virtual segment created by the RT
Application Loader, RT processes cannot address beyond the virtual segment. This
effectively partitions every RT process into its own address space.
Blue screen protection
On an INtime node, the RT kernel enables successful execution of RT threads even in
the event of a total Windows failure, also known as a “blue screen crash.”
• Failure diversion: HAL modifications capture Windows failures. Once captured,
control transfers to the RT kernel, Windows operation suspends, and RT threads
continue to run, unaffected by the failure.
• Application-specific recovery: (used only in local INtime system configurations)
In the event of a Windows failure, your crash recovery RT threads run and you can
execute an orderly shutdown of the hardware your INtime application controls.
Note
Remote INtime configurations do not require blue-screen protection because RT processes
execute on dedicated hardware, separately from Windows. This means a crash, reboot, or
restart of the Windows system does not interrupt execution of remote RT processes.
In the event of a Windows blue screen crash, INtime software keeps running until a
graceful shutdown occurs. To start INtime software again, you must first restart
Windows.
13