Isolating real-time and non-real-time processes

The key to delivering hard real-time control alongside Windows is in INtime software’s unique virtual machine architecture. Separate hardware tasks isolate and protect the INtime real-time operating system (RTOS) and real-time applications from Windows and its associated processes.

The INtime kernel and its real-time processes always have higher priority than any Windows process. The INtime operating system features a proprietary OS Encapsulation Mechanism (OSEM) that creates and separates the two virtual machines: one for the Windows operating system and one for the INtime RTOS. Once encapsulated, Windows (with all its processes and threads) executes as a single, low priority, real-time thread in the context of the real-time root process. As a result, real-time threads always preempt running Windows threads, guaranteeing determinism for real-time activities within the Windows system.

When running on a multi-core platform, INtime can be configured to use all the resources of one CPU core. Multi-core INtime platforms exhibit the very lowest real time system jitter, with worst case interrupt latency measured as low as three microseconds!

Memory protection for real-time processes

INtime provides complete protection for real-time processes. All real-time threads run in user-mode (ring 3) within the memory address space of their INtime process. That means that they can only access memory associated with their real-time process. Attempts to access memory outside their address space will cause a page fault, that will be trapped by the processor and managed by the INtime OS. This results in the suspension of the thread that caused the fault. In this way, one real-time process cannot affect other real-time processes or other Windows processes. Likewise, Windows processes cannot affect real-time processes.

With the INtime real-time fault manager enabled, a faulted thread is trapped and immediately suspended, and the INtime OS is notified of the event while all the rest of the real-time system continues to run. A fault notification box is opened on the Windows desktop giving the developer the option of debugging the thread, profiling the event, or canceling the thread. Selecting the debug option loads your INtime application source code, with a breakpoint set at the location where the fault occurred, with all variables initialized and ready to address the problem.

Despite running in user-mode, the INtime architecture provides direct access to the full I/O space, allowing DOS-like port I/O (IN/OUT) access to hardware without any performance penalty. The ability to handle interrupts from the application is also provided. No other competing solutions afford your real-time applications the protection and robustness of executing from user-mode. In addition, the developer avoids the complexities of debugging in kernel-mode (ring 0), a place intended for drivers and the OS, not applications.

Services available to real-time applications

INtime real-time applications have direct access to a TCP/IP stack without requiring Windows as an intermediary. Applications use a standard sockets API that interfaces to dedicated, real-time Ethernet hardware. INtime also supports access to dedicated USB interfaces.

The INtime API includes calls to transparently move data between a real-time application and its Windows host file system. These standard file I/O calls apply to any file system supported by Windows that uses UNC filenames. In addition, other services provide real-time process access to the Windows registry and Windows event log.