T EN A SYS ® IN TIME ™

52

53 4.4.1 Topology; Local and/or Remote Nodes

The most important features offered by INtime are the connection to the Microsoft Windows OS and the ability to run standalone.

INtime software supplies an NT Extension (NTX) library that provides real-time interface extensions for the Win32 API that allow Windows threads to communicate and exchange data with real-time threads within the application. NTX communicates between Windows and real-time portions of INtime applications, whether they reside on a single PC, on different cores, or on separate computers accessed via an Ethernet connection. NTX supports two transport mechanisms depending on the relationships of the nodes and whether they are local or remote nodes: Operating System Encapsulation Mechanism (OSEM) transport for the local node, and Ethernet transport for remote nodes. INtime can be installed to run together with Windows on one PC: this is called local INtime or the local node. Real-time application and non-real-time applications (Windows applications) can run and coexist on the same processor, or they can run on independent cores. Windows kernel and INtime kernel communicate via the NTX library and OSEM transport, which is nothing more than a device driver. In this configuration all threads (real-time and non-real-time) share the same memory so data exchange is very efficient, they can even share the same memory blocks.

A remote node runs INtime in a stand-alone configuration. Connection to the Windows host is till made via the NTX library locally or over Ethernet transport, utilizing the real-time TCP/IP stack for the connection.

Thanks to local and remote configurations there is the possibility for different real-time application topologies.

4.4.2 Windows and INtime Working Together

The interaction with Windows is a central design feature of INtime. Best of all, INtime uses services and communication driver to interact with Windows, thus Windows itself is not modified or changed in anyway. The Figure 4.4 shows both OSs put together in a local node, they will be described separately and then as a whole in their combination.

54

Figure 4.4 Windows/INtime Integration

The schema in Figure 4.4 shown the Windows stack on the left and the INtime real-time stack on the right.

Windows was designed to run on a variety of hardware architectures; thus, it sits on the Hardware Abstraction Layer (HAL) used to separate the hardware layers from the software. One of the key features of the HAL is to prevention of user mode application from directly interacting with the hardware. Kernel mode drivers are required to interact with the hardware and act as the interface to the hardware for user mode applications. Windows applications use the Win32 API, .NET runtime, or other runtimes to communicate with the system. Within Windows there is no support for real-time requirements.

INtime, on the other hand, was designed to be deterministic and support real-time requirements. INtime employs a layered architecture, where applications written with the real-time API’s interact with the kernel directly. The kernel, in turn, employs an object-structured architecture to handle all elements of a real-time application. INtime allows application to talk to the hardware directly. The INtime stack a Real-Time API set, based on the Win32 API, has been added to support real-time processes that directly access the real-time kernel. In addition, some library and driver additions were made to allow both Windows and INtime to run on a single processor. The HAL was modified to guarantee determinism, even from within Windows.

Concurrent operation of both Windows and the real-time kernel is done through a transport mechanism called OSEM on a local for a local node. This is the key component that allows INtime to fully integrate with the Windows architecture. An NTX API was developed to facilitate the interaction between real-time and non-real-time processes.

55

As shown in Figure 4.4, the result is a dual kernel solution that addresses both real-time and non-real-time applications. The combined architecture even allows to create Windows applications that call real-time threads.

The different elements of the combined architecture are:

▪ Real-Time kernel. Provides deterministic scheduling and execution of real-time threads within real-time processes.

▪ Real-Time API, C, and EC++ libraries. Gives direct access to the Real-Time kernel services for real-time threads.

▪ Transport Driver. A driver that converts information to the protocol needed by the specified transport mechanism.

▪ Transport mechanism. The communication protocol used by NTX to communicate between Windows and real-time threads.

▪ Windows HAL. INtime software intercepts some HAL calls to ensure real-time performance.

4.4.3 The INtime Real-Time Kernel

This section will focus on the INtime kernel to illustrate how real-time concepts have been implemented. As already discussed, processes, thread, scheduling, and priority handling all play a crucial role in the timing of a real-time application. The INtime Kernel employs several of these concepts, thus is important to know what the kernel supports in order to write real-time applications.

The INtime Real-Time Kernel provides features for Object Management to create, deleting, and work with object types defined by the kernel; for Time Management including a real-time clock, alarm that simulate timer interrupts, and the ability to put threads to sleep; for Thread Management including scheduling locks which protect the currently running thread from being preempted when required; and for Memory Management implementing memory pools from which it allocates memory in response to application requests.

All these different concepts have been integrated into an object-structured architecture.

That is, the Real-Time Kernel provides basic objects and maintains the data structures that define these objects and their related systema calls.

The objects available in INtime are:

56

▪ Process. Provides an environment for threads and is used to control the resources consumed by threads.

▪ Thread. Performs the work of the system and is the only executable object. Associated with each thread are code, data, and a stack.

▪ Mailbox. Used for passing information between threads. Both object and data mailbox are included.

▪ Semaphore. Used by threads to synchronize runtime operation.

▪ Region. Used by threads to provide mutual exclusion.

▪ Port. The mechanism to communicate with an INtime device driver. Used by threads to synchronize operations, pass messages, and access INtime services.

▪ Dynamic Memory. Addressable blocks of memory that threads can use for any purpose.

▪ Heap. Provides smaller memory units and has features for memory use with a port.

The heart if the kernel is the thread. The kernel’s main job is managing the threads using the different priority and scheduling schemes.

The most important thing to know about Windows and INtime combination is that the complete Windows environment with its Win32 processes and threads are embedded in a single real-time thread, running at the lowest real-time priority. This means that real-time threads will be given high priority and run before any Windows threads. As result, real-time threads always preempt running Windows threads, guaranteeing hard determinism for all real-time activities within the system.

Interrupt processing can happen for either kernel. The modified Windows HAL provides an intercept mechanism to trap attempts to modify the system clock rate so that the real-time kernel can control the system time base, to trap attempts to assign interrupt handlers to interrupts reserved for real-time kernel use, and to ensure that interrupts reserved for real-time kernel use are never masked by Windows software.

The modified HAL has also another very important responsibility, that is to provide protection against Windows’ crashes. In a real-time system, indeed, a stop caused by a software error is unacceptable not to say hazardous. When Windows crashes, usually as a result of a condition in a Windows device driver, it shows a blue screen with information and then halts the system. The modified HAL changes this behavior by intercepting the crash condition and allowing the INtime to continue with all its real-time threads. The occurrence of a Windows crash is reported via an event that a real-time thread can wait for it. It is then up to such a thread to decide on a continuation, shutdown, or recovery strategy.

57