Häufig gestellte Fragen zu RTX64 und MaxRT eRTOS

Hard real-time requires that a response be logically correct and occur before a specific deadline. Otherwise, the result is incorrect and holds no value.

Soft real-time requires that a response be logically correct and occur before a specific deadline, or the result becomes increasingly inaccurate. That is, the result can still hold some value even though it occurred after the required deadline.

Determinism is defined as the ability to rationally predict, with a degree of precision, when an event will happen. Determinism, combined with a real-time environment, guarantees that an event will occur within a short response time and that its performance is repeatable.

A real-time operating system provides determinism and predictability when it responds to a given event through a specialized scheduler.

Windows is usually considered a general-purpose operating system because it does not allow applications or kernel-level drivers to completely mask interrupts and gain control of the operating system. Depending on the hardware, interrupt latencies under Windows can be very low, averaging in the microsecond range. However, worst-case interrupt latencies are unbounded and can exceed hundreds of milliseconds. Because of these unbound latencies, deterministic response time is not guaranteed, making standard Windows Desktop and Server operating systems unacceptable for real-time use.

MaxRT supports Symmetrical Multiprocessor Systems (SMP), a computer architecture that allows operating system tasks and user threads to be scheduled to run on any available processor. With this model, multiple processors can be configured for real-time activities. RTSS threads can be assigned to run on dedicated RTSS processors and can run concurrently.

When running MaxRT on an SMP-enabled system, you configure how many processors are dedicated to Windows and how many to the MaxRT Real-time Subsystem (RTSS). MaxRT supports SMP systems with up to 64 processors. Of those 64, up to 63 can be dedicated to MaxRT (depending on the licensed edition).

The overall design of MaxRT wRTOS™ affords developers the “best of both worlds” by enabling them to use all the features and technologies that Windows offers, in addition to “hard” real-time behavior within an isolated, controlled subsystem. MaxRT wRTOS™ includes a real-time-enabled Hardware Abstraction Layer (HAL) extension. MaxRT wRTOS™ does not replace the existing Windows HAL. This extension maintains interrupt isolation between RTSS and Windows while providing inter-processor interrupt (IPI) communication between them. The real-time subsystem schedules its RTSS tasks to execute on separate processors, without any interference from the Windows operating system or Windows processes.

The MaxRT wRTOS™ Runtime enables general-purpose Windows processing and high-performance real-time processing and control on commercial-off-the-shelf (COTS) machines. The MaxRT wRTOS™ Runtime can be configured to take part in Windows mini-dumps or to take control and safely shut down real-time processes if Windows encounters a failure.

The MaxRT wRTOS™ SDK provides developers with a rich set of inter-process communication and synchronization capabilities, allowing RTSS applications to communicate and share data with Windows applications (32-bit and 64-bit). Additionally, MaxRT wRTOS™ allows developers to directly access the I/O port address space and physical memory, or hardware, without imposing a driver model on the user.

MaxRT wRTOS™ leverages 64-bit registers and compilers, enabling real-time developers to do the same.

Using MaxRT wRTOS™ on an SMP system provides significant benefits, including:

• Performance Boost – You can have multiple processors dedicated to critical, real-time tasks. You can concurrently run up to 63 real-time threads on a 64-processor system.
• Performance Scalability – Performance scaling doesn’t require code rewrites. You can adjust the balance between real-time and non-real-time performance by changing the number of RTSS processors and Windows processors.
• High Availability – Critical tasks can be scheduled to run across multiple RTSS processors.
• IRQ Affinity – You can specify a dedicated RTSS processor for handling the input and output of individual hardware devices.
• System Fault Handling – Real-time tasks survive over system crashes.

MaxRT wRTOS™ Runtime is available in several editions, allowing you to license as many processors as your solution requires. MaxRT wRTOS™ Runtime is available in these editions:

All MaxRT wRTOS™ Runtime editions include the same features. Applications created with the SDK will run on any edition that runs the same version of MaxRT wRTOS™. This allows developers the freedom to build scalable applications.

MaxRT wRTOS™ is part of a new family of products based on RTX64 and KINGSTAR.  RTX64 was originally released in 2013 and evolved from the 32bit RTX product.  KINGSTAR was originally released in 2014. 

The latest version is MaxRT wRTOS™ 1.0, released in 2026.

MaxRT wRTOS™ is used in a wide variety of products and vertical markets. Anyone designing an application that requires system control, determinism, or real-time performance on Windows can benefit from incorporating MaxRT wRTOS™ into their product design.

MaxRT wRTOS™ is used in some of the following markets:

• Industrial Automation
• Digital Audio
• Test & Measurement
• Medical
• Military Aerospace

IntervalZero provides six editions of the MaxRT wRTOS™ Runtime product:

The Runtime also has optional purchasable features: 

• Basic Networking
• GigE Vision
• Fieldbus
  – E-CAT High Speed Timer
  – Multiple MainDevices
  – Hot Connect
  – Cable Redundancy 

MaxRT wRTOS™ Runtime is available in these installer packages: 

• MaxRT wRTOS™ Runtime Install – MaxRT wRTOS™ can be installed silently. The installation can be invoked from the command line or used within your product installation, so it does not require user interaction. 

• Merge Modules for MaxRT wRTOS™ Runtime Features – The MaxRT wRTOS™ components are available as merge modules for inclusion in an OEM product installation.

MaxRT wRTOS™ Runtime includes these features: 

• Support real-time control and isolation of interrupts 

• Scheduler that schedules across multiple cores 

• Deterministic memory allocation through configurable process MSpaces 

• Network Link Layer (NL2)  provides real-time applications with abstract APIs to access network services at Layer 2 of the OSI model, independent of the underlying hardware 

• Virtual Network provides a virtual point-to-point connection between Windows and wRTOS that emulates a local area network connection between Windows and the Real-time Subsystem with no additional hardware required 

• Network Relay establishes a communication channel between Windows and RTSS, enabling Windows applications to send and receive Ethernet frames via NICs owned by wRTOS 

• TCP/IP protocol stack 

• EtherCAT protocol stack 

• GeniCAM and GigE Vision support 

• A Settings tool to configure the Real-time Environment 

• A Control Panel to start and stop components 

• Display console for real-time process output  

• A Task Manager utility for viewing real-time processes (.rtss) and Windows processes linked to wRTOS (.exe). You can start new tasks and terminate running tasks using the Task Manager. You can also schedule tasks to start with the Subsystem, and view CPU Usage data for all processors assigned to either Windows or wRTOS 

• Monitoring infrastructure allows developers to profile the behavior of real-time applications across all RTSS processors. Also included is a simple utility that outputs a readable text file. 

• Message Viewer allows you to view debug/log messages generated during the execution of real-time applications 

• E-CAT Configuration Tool allows you to control the EtherCAT devices (SubDevices) connected to the E-CAT MainDevice within an E-CAT component instance 

• E-CAT ESI Import  allows you to import EtherCAT SubDevice Information (ESI) files for your EtherCAT hardware devices and save the ESI data into the E-CAT component database 

• A Latency View tool to view timer latency on Windows and RTSS cores. 

• Command line utilities to view CPU usage, Memory usage, and object states. 

• Comprehensive Help files and User Guides 

MaxRT wRTOS™ SDK includes these components: 

• Header files and libraries 

• Support for Visual Studio 2022 and 2019 

• Microsoft C Runtime support 

• Templates for creating applications and DLLs 

• API code snippets 

• wRTOS WinDbg Extension extends Microsoft’s 64-bit version of WinDbg and provides a way to analyze and interpret the state of RTSS processes, as well as the wRTOS Subsystem. 

• Symbols to key wRTOS Runtime components 

• Comprehensive Help files and MiniTutorials 

• Source code samples to help explain more advanced development topics 

MaxRT wRTOS™ components must be activated with a valid license before they can be used. You can use the wRTOS Settings tool, which appears immediately after program installation, to activate and lock your product to a specific machine or to an IntervalZero-provided small form factor dongle. For information on first activation, see the MaxRT wRTOS™ Installation Guide for your product, or see the MaxRT wRTOS™ Deployment Guide. Both are available from the Customer Center.

The method you use to activate your copy of MaxRT wRTOS™ will depend on whether you are connected to the Internet. See the MaxRT wRTOS™ Product Activation video for more information: https://www.intervalzero.com/en-resources/en-videos/.

No, x2APIC systems are not supported. Only systems that allow for x2APIC to be turned off are supported. The MaxRT wRTOS™ installation will disable x2APIC when possible.

MaxRT wRTOS™ can be used on hyper-threading systems. MaxRT wRTOS™ treats the logical processor created by Intel Hyper-Threading as a separate processor. Because both logical processors share the same physical processor, one logical processor can adversely affect the other’s performance. It is recommended that you use even numbers of windows processes so a Windows logical processor and an RTSS logical processor do not share the same physical processor. You should also evaluate MaxRT wRTOS™ performance to ensure that when hyper-threading is enabled, your real-time requirements are still achieved.

MaxRT wRTOS™ Runtime can be run alongside 3rd party antivirus software if MaxRT wRTOS™ is granted access to the system folders and directories it requires. If MaxRT wRTOS™ does not work correctly on a system with a 3rd-party antivirus, we recommend adding exceptions to the antivirus rules/policies. For instance, you can instruct the antivirus software to ignore the MaxRT wRTOS™ components wRTOS_RTSS, wRTOS_HALEXT, etc., or to ignore the MaxRT wRTOS™ install folder entirely. Sometimes, you may need to ignore the folder from which your binaries are being run.

See the TechNote MaxRT wRTOS™ Compatibility with Microsoft Security Features, available on the Support Site, for information on which Microsoft Security Features can run on the same system as the MaxRT wRTOS™ Runtime.

Virtual Machines (VMs) should not be used to deploy MaxRT wRTOS™ Runtime products, as the Real-time Subsystem cannot guarantee determinism in a virtual environment. However, virtual machines can be used for development and testing. See the TechNote „Virtual Machines Tested with MaxRT wRTOS™,“ available from the Support Site, for information on Virtual Machines used internally by IntervalZero and known to work with MaxRT wRTOS™.

NOTE: A dongle is required when licensing MaxRT wRTOS™ Runtime on a VM. The SDK does not require dongle activation on a VM.

NOTE: There is a known issue in which the RTX64 Runtime and TCP/IP components fail to activate when Hyper-V or Intel Virtualization is enabled. For more information, see the TechNote MaxRT wRTOS™ Runtime and TCP/IP Components Fail to Activate when Hyper-V or Intel Virtualization is Enabled, available from the Support Site.

IntervalZero provides a silent command-line installation option for MaxRT wRTOS™, allowing an OEM to wrap the MaxRT wRTOS™ installation and hide it within another installation. The MaxRT wRTOS™ Runtime components are also available as merge modules for inclusion in an OEM product’s installation.

IntervalZero provides Managed Code and Native Frameworks to programmatically configure the MaxRT wRTOS™ Subsystem. This allows customers to set up their software’s subsystem requirements without requiring anything from their end users.

MaxRT wRTOS™ provides local and remote launch and attach debugging capabilities for Real-time applications with Visual Studio 2022 and 2019. 

MaxRT wRTOS™ also provides excellent flexibility for processing exceptions. You can configure MaxRT wRTOS™ to handle exceptions with a structured exception handler, generate a debug break, or stop the process and dump memory. 

MaxRT wRTOS™ provides a WinDbg Extension for postmortem debugging of a Windows memory dump file. 

MaxRT wRTOS™ also provides monitoring functionality that allows you to trace application behavior without modifying your real-time application’s code.  

Yes. Once MaxRT wRTOS™ has been successfully installed, all authenticated users who log on to the system can control, configure, and run the MaxRT wRTOS™ Subsystem and RTSS applications, even if they are not computer or domain administrators. System administrators can control access to MaxRT wRTOS™ resources by configuring membership in the wRTOSAdministrators and wRTOSUsers groups. For more information, see the MaxRT wRTOS™ Runtime Install Guide, available from the Customer Center.

No. RTSS applications are developed with Microsoft Visual Studio. The MaxRT wRTOS™ SDK provides a wizard for easy project creation and templates to help you get started. Visual Studio Debugger support lets you debug RTSS applications in a familiar environment. MaxRT wRTOS™ supports local and remote debugging through launch and local attach in Visual Studio 2022 and 2019. A WinDbg Extension is also available for postmortem debugging of Windows memory dump files.

MaxRT wRTOS™ supports a subset of over 50 Windows-compatible API calls tailored for real-time environments. By aligning closely with the Windows API, wRTOS enables developers to leverage existing code base, development tools, and experience—accelerating the development of real-time applications. 

Applications can be developed in the Windows environment (32-bit or 64-bit) using familiar development tools, then re-linked to run deterministically within the Real-Time Subsystem (RTSS). This flexible approach allows code to be shared or moved between environments, though performance and timing characteristics may vary. 

In addition to supporting a subset of Windows APIs, MaxRT wRTOS™ offers proprietary real-time extensions that deliver the deterministic behavior required by real-time systems. These APIs are accessible from both the Windows and RTSS environments, giving developers the flexibility to design, test, and deploy. 

The MaxRT wRTOS™ APIs are included in the following sets, each serving specific functionality within the real-time system: 

• Real-Time API (RTAPI)  

• Windows Driver IPC API (RTKAPI)  

• NL2 API  

• TCP/IP API  

• Debug Message API 

• E-CAT Fieldbus API  

• Variable Database API  

• Vision API  

• Windows-Supported API  

• Winsock API  

• C Runtime Library-Supported API  

• C++ Library-Supported API

MaxRT wRTOS™ was designed to enable developers to build applications as RTSS or Windows applications. When built as a Windows application, developers can take advantage of features such as user-mode memory protection and third-party debugging tools specific to user-mode applications. After an application is working as desired, recompile it as an RTSS application that runs in the real-time subsystem on dedicated processors with no code changes required.

Unlike other applications running in kernel mode, RTSS applications support structured exception handling. MaxRT wRTOS™ lets developers call structured exception-handling functions such as try, catch, and throw within their RTSS applications. For example, if an application references a NULL pointer, it can handle the error by terminating or freezing the application that caused the fault, without bringing down the system.

MaxRT wRTOS™ supports a subset of Microsoft C Runtime calls that you can call from your RTSS application. MaxRT wRTOS™ provides Microsoft C Runtime Support for Microsoft Visual Studio 2022 and 2019.

Yes. MaxRT wRTOS™ supports and saves state information for AVX/AVX2 (YMM0~YMM15), AVX-512, SSE (SSE/SSE2/SSE3/SSE4), MMX, and AMX registers, if the hardware supports it.

MaxRT wRTOS™ SDK includes a complete API reference guide for all supported functions, along with short code segments that explain more complex concepts.

MaxRT wRTOS™ SDK also provides source code for several sample applications, including the MaxRT wRTOS™ measurement tools. These samples can be compiled and run to show essential concepts and application interaction. For customers with support, the IntervalZero Support Site contains several samples and tools for use with MaxRT wRTOS™.

MaxRT wRTOS™ provides these tools (available from the Support Site and/or Customer Center), and APIs that help Developers measure system response and timer latency:

• SRTM (System Response Timer Measurement) is a command-line application that measures timer latencies and displays results in reports and histograms.
• KSRTM (Kernel System Response Timer Measurement) is a measurement tool that measures HAL-level timer latencies to the Interrupt Service Routine (ISR) and provides reports and histograms of the results.
• Latency View is a tool that displays a visual comparison of latency between Windows and MaxRT wRTOS™ cores.
• RtPerfMonitor is a command-line program that displays system information, including processor speed and type, MaxRT wRTOS™ HAL type, CPU utilization, and other metrics that can help measure RTSS application load.
• WinSmiTrace is a Windows utility that can detect and quantify SMI activity. It runs a Windows driver and can be run with or without the Real-time Subsystem.
• Several APIs for profiling across processors, including the following:
  • RtGetThreadTimes retrieves the execution time of a given thread.
  • RtGetProcessTimes retrieves timing information for a given RTSS process.
  • QueryPerformanceCounter and QueryPerformanceFrequency provide accurate time tracing between multiple processors.

MaxRT wRTOS™ enables Windows and RTSS applications to communicate via several Inter-Process Communication (IPC) objects. Use the RTAPI functions to create objects that Windows processes (32- and 64-bit) can view and use. Like Windows inter-process communication, RTSS, and Windows applications, create or open handles to named objects or memory regions, enabling simple, standard communication and synchronization between real-time (RTSS) and non-real-time (Windows) applications. Shared memory regions allow Windows and RTSS applications to view the same physical memory without passing additional messages or data between environments.

Standard objects:

• Event – The event object is a synchronization object. It is useful for signaling a thread that a particular action has occurred.
• Mutex – The mutex object is a synchronization object whose state is signaled when it is not owned by any thread and not signaled when the mutex is owned by a thread. The mutex object arbitrates exclusive access to a shared resource.
• Semaphore – The semaphore object is a synchronization object that maintains a count between zero and a specified maximum value. The count is decremented by 1 each time a thread completes a wait on the semaphore object; the count is incremented by a variable amount at the semaphore release. When the count reaches zero, the semaphore object’s state is no longer signaled, and no more threads can complete a wait on the semaphore object until some thread increases the count.
• Shared Memory – A shared memory object is a region of non-paged physical memory that can be mapped into a process’s virtual address space. When a shared memory object has a name, additional processes may map the region of memory. A shared memory object is accessed with both a handle and a virtual address. For a process to completely end its access to a shared memory object, it must close any open handles.

MaxRT wRTOS™ acquires the resources the device needs from the Windows Plug and Play Manager. To make this possible, a device’s driver must be updated to point to the MaxRT wRTOS™ plug-and-play stub driver. After the device is controlled by MaxRT wRTOS™, its resources must be updated to request a unique interrupt that is not already in use by Windows. (Sharing interrupts with Windows would cause determinism to be lost.) Note that a unique interrupt is only needed for devices that use line-based interrupts. Once the device is set up, any RTSS application can access and use the device.

MaxRT wRTOS™ supports MSI and MSI-X-capable devices, providing an alternative to line-based interrupts. This functionality is available on all MaxRT wRTOS™-supported operating systems.

Windows has a set of 64 priority levels, ranging from 0–63. They are further defined into 4 priority classes, with the “real-time” class the highest.

The „real-time“ priority class, in turn, has 7 levels. MaxRT wRTOS™ uses a flat priority scheme of 127 priority levels.

MaxRT wRTOS™ provides the option to set one of two priority inversion protocols to handle cases where a higher priority thread is waiting on a mutex held by a lower priority thread:

• Priority Promotion with Tiered Demotion elevates a low-priority thread to the level of the highest-priority thread that is waiting for the shared mutex until it has released the mutex requested by a higher-priority thread.
• Disable – Does not elevate priorities in cases where a higher priority thread is waiting on a mutex held by a lower priority thread.

MaxRT wRTOS™ includes a real-time-enabled Hardware Abstraction Layer (HAL) extension; this extension does not replace the existing Windows HAL. The extension maintains interrupt isolation between RTSS and Windows. Windows cannot mask (at the interrupt controller level) interrupts managed by RTSS. Windows interrupts are masked on RTSS processors/cores. The real-time HAL extension supports high-resolution clocks and timers for RTSS, while it also supports non-real-time clocks and timers for Windows. Other real-time HAL extension features include a software interrupt mechanism between RTSS and Windows, basic exception handling, and determinism enhancements. The HAL timer values can be changed via a predefined value table to as low as 1 µs, or assigned a custom value using the SDK.

MaxRT wRTOS™ supports Intel^® Resource Director Technology (RDT), which provides a set of resource allocation (or control) capabilities that govern how shared resources such as last-level cache (LLC) and memory bandwidth are used by applications. These capabilities include Cache Allocation Technology (CAT) and Memory Bandwidth Allocation (MBA).

As a primary setup for Intel^® RDT, MaxRT wRTOS™ separates L3/L2 cache spaces between Windows cores and RTSS cores, thereby removing cache contention from Windows or other system activities. RTX64 sets Windows cores with maximum memory throttle and RTSS cores with zero memory throttle. To further differentiate performance among parallel RTSS threads, MaxRT wRTOS™ introduces two RDT modes for CAT and MBA: Flat performance mode and Priority-based CLOS performance mode.

Windows STOPs, or Bug Checks, occur when kernel-level drivers or operating system components fail safety checks, bringing Windows to a controlled stop. These Windows STOPs are designed to minimize data corruption and help developers determine what went wrong.

Since RTSS can continue running after Windows issues a STOP, developers can build safe shutdown handling into RTSS applications. MaxRT wRTOS™ calls the shutdown handlers when Windows issues a STOP, allowing real-time system components to shut down safely. Once all shutdown handlers have finished running, MaxRT wRTOS™ allows the Windows shutdown process to continue.

If the RTSS determines that Windows needs to be shut down, MaxRT wRTOS™ issues a STOP, but instead of displaying the traditional Windows blue screen, MaxRT wRTOS™ displays the MaxRT wRTOS™ green screen, which contains information about the state of MaxRT wRTOS™ at the time of the STOP.

No states are saved when Windows crashes.

wRTOS is a real-time operating system (RTOS) built from the ground up to run on and take full advantage of the Windows general-purpose operating system and is designed for use in industrial automation, medical devices, and other critical applications.  The key features that set it apart from other RTOSs include:  

1. Windows compatibility: One of the key features of wRTOS is its compatibility with Windows. It allows developers to use the familiar Windows development environment to build real-time applications, helping reduce development time and costs.  
2. Windows Application Ecosystem: wRTOS is uniquely designed to enable third-party Windows applications to run on the same Industrial PC that hosts the wRTOS machine, thereby controlling real-time applications.  This means that machines require only one PC, whereas most RTOSs require one PC for machine control and another for the Operator console or other local applications.  
3. Support for multiple programming languages: wRTOS supports C, C++, and .NET languages, including C#, VB.NET, and others. This makes it easier for developers to build real-time applications using the language they are most comfortable with. 
4. Open standards-based: IntervalZero is committed to open standards and tools (Windows, Visual Studio, C++, EtherCAT, TSN, OPC UA), which protect our customers’ investment and ensure IoT readiness, ensuring the machine builder can support any future cloud connectivity demands. The RTOS Platform serves as an integration environment. The modularity and customizability ease the burden of integrating multiple controllers.  Some forward-thinking machine builders are even consolidating multiple controllers onto a single PC. 
5. Hard real-time capabilities: Like all RTOSs, wRTOS is a hard real-time operating system, which means it can guarantee a deterministic response time to events, even under heavy loads.  But the benefit of wRTOS is that it directly shares the same memory with the non-RTOS application, which eases integration and shortens time to market. Advanced debugging capabilities: wRTOS provides advanced debugging  using familiar Windows debugging techniques, including kernel-aware debugging, enabling developers to debug real-time applications at the kernel level. This makes it easier to identify and fix issues in real-time applications.  

The E-CAT component uses CANopen over EtherCAT (CoE) as its command protocol, enabling communication via standard CANopen objects (PDOs and SDOs) within EtherCAT frames. Support for other protocols, such as SERCOS over EtherCAT (SoE), may be added in the future. 

MaxRT eRTOS bietet mehrere Vorteile:

• Unabhängigkeit von Windows, sodass es auf bis zu 64 Prozessoren ohne weiteres Betriebssystem ausgeführt werden kann.
• Kompatibilität mit Quellcode von RTX64-Anwendungen, sodass eine einfache Migration möglich ist.
• Ideal für Fernzugriffsanwendungen mit Web- oder OPC UA-Schnittstellen, bei denen die HMI auf einem separaten Gerät ausgeführt wird.

Die Hauptunterschiede sind:

• MaxRT eRTOS ist ein eigenständiges RTOS und verwendet keine Windows-Funktionen.
• Es unterstützt bis zu 64 Prozessoren, im Vergleich zur Unterstützung von RTX64 für bis zu 63 Prozessoren.
• MaxRT eRTOS ist für eingebettete Anwendungen konzipiert, während RTX64 Windows erweitert, um Echtzeitfunktionen bereitzustellen.

Ja, es wird umfassender Support und Dokumentation zur Verfügung stehen, um Benutzer bei der Migration ihrer Anwendungen von RTX64 zu MaxRT eRTOS zu unterstützen.

Wenn Ihre Anwendung nicht sowohl ein HMI als auch das Echtzeitsystem zusammen auf demselben PC ausführen muss, ist MaxRT eRTOS gegenüber RTX64 die bessere Wahl, um die Leistung zu optimieren oder die Sicherheit zu erhöhen.

MaxRT eRTOS eignet sich für eine Vielzahl von Branchen, darunter industrielle Steuerungssysteme, Automatisierung und alle Anwendungen, die ein robustes, eigenständiges RTOS für den Fernzugriff erfordern. Es gibt viele Klassen von Headless-Echtzeit-Embedded-Systemen, die von der Verwendung von MaxRT eRTOS profitieren könnten.

Ja, MaxRT eRTOS unterstützt Systeme mit bis zu 64 Kernen. Wenn Sie MaxRT eRTOS ausführen, konfigurieren Sie, wie viele Kerne MaxRT eRTOS zugewiesen werden sollen. Dies hängt von der lizenzierten Edition ab.

Die MaxRT eRTOS Runtime ermöglicht leistungsstarke Echtzeitverarbeitung und -steuerung auf handelsüblichen Maschinen (COTS).

Das MaxRT eRTOS SDK bietet Entwicklern eine Vielzahl von Interprozesskommunikations- und Synchronisierungsfunktionen, sodass MaxRT eRTOS-Anwendungen kommunizieren und Daten austauschen können. Darüber hinaus ermöglicht MaxRT eRTOS Entwicklern den direkten Zugriff auf den Adressraum der E/A-Ports, den physischen Speicher oder die Hardware, ohne dem Benutzer ein Treibermodell aufzuzwingen.

MaxRT eRTOS nutzt 64-Bit-Register und -Compiler und ermöglicht dies auch Echtzeitentwicklern.

Die Verwendung von MaxRT eRTOS auf einem SMP-System bietet erhebliche Vorteile, darunter:

• Leistungssteigerung – Sie können mehrere Kerne für kritische Echtzeitaufgaben verwenden. Sie können bis zu 64 Echtzeit-Threads gleichzeitig auf einem 64-Kern-System ausführen.
• Leistungsskalierbarkeit – Für die Leistungsskalierung ist kein Umschreiben von Code erforderlich. Sie können die Echtzeit-Leistungsbalance anpassen, indem Sie die Anzahl der Echtzeitkerne ändern.
• Hohe Verfügbarkeit – Kritische Aufgaben können so geplant werden, dass sie auf mehr als einem Echtzeitkern ausgeführt werden.
• IRQ-Affinität – Sie können einen dedizierten Kern für die Verarbeitung der Eingabe und Ausgabe einzelner Hardwareteile angeben.

MaxRT ist eine neue Produktfamilie, die auf dem 2013 veröffentlichten Produkt IntervalZero RTX64 basiert.

Die neueste Version ist MaxRT eRTOS 1.0, veröffentlicht im Jahr 2025.

MaxRT eRTOS kann in einer Vielzahl von Produkten und vertikalen Märkten verwendet werden:

• Industrielle Automatisierung
• Digitales Audio
• Test & Messung
• Medizin
• Militärische Luft- und Raumfahrt

MaxRT eRTOS verfügt über ein Software Development Kit für die Entwicklung von Echtzeitanwendungen und ein Runtime-Zielbetriebssystem für die Bereitstellung Ihrer Anwendungen.

IntervalZero bietet fünf Editionen des MaxRT eRTOS Runtime-Produkts:

MaxRT eRTOS Runtime umfasst diese Funktionen:

• Scheduler für Prozesse und Threads über mehrere Kerne hinweg
• Deterministischer lokaler Speicher durch konfigurierbare Prozess-MSpaces.
• Verarbeitungs- und Netzwerkfähigkeit durch eine Network Link Layer (NL2) und einen optionalen RT-TCP/IP-Protokollstapel.
• Ein USB-Stapel zur Unterstützung von Tastatur- und Mausinteraktionen.
• INI-Dateien zur Konfiguration des Echtzeitkernels und optionaler Komponenten.
• Die Möglichkeit, Prozessausgaben auf einer Konsole anzuzeigen.
• Befehlszeilenprogramme zur Anzeige der CPU-Auslastung und der Objektzustände.
• Umfassende Hilfedateien und Benutzerhandbücher

Das MaxRT eRTOS SDK enthält diese Komponenten:

• Headerdateien und Bibliotheken
• Unterstützung für Visual Studio 2022 und 2019
• Unterstützung für Microsoft C Runtime
• Vorlagen zum Erstellen von Anwendungen und DLLs
• Umfassende Hilfedateien und Mini-Tutorials
• Quellcodebeispiele zur Erläuterung fortgeschrittener Entwicklungskonzepte

MaxRT eRTOS-Komponenten müssen mit einer gültigen Lizenz aktiviert werden, bevor sie verwendet werden können. Sie können das Befehlszeilenprogramm MaxRT eRTOS Aktivierung und Konfiguration verwenden, um Ihr SDK-Produkt entweder an eine bestimmte Maschine oder an einen von IntervalZero bereitgestellten Dongle mit kleinem Formfaktor zu aktivieren und zu sperren. Für die Runtime erhalten Sie eine Lizenzdatei, die an Ihr SDK gebunden ist und Lizenzen für die von Ihnen erworbenen Funktionen enthält. Informationen zur ersten Aktivierung finden Sie im MaxRT eRTOS-Installationshandbuch für Ihr Produkt.

Die Methode, mit der Sie Ihre Kopie von MaxRT eRTOS SDK aktivieren, hängt davon ab, ob Sie mit dem Internet verbunden sind oder nicht. Es stehen Videos zur Verfügung, die den Aktivierungsprozess mit und ohne Internetverbindung durchgehen. Sie können die Videos unter: https://www.intervalzero.com/en-resources/en-videos/ ansehen.

MaxRT eRTOS kann auf mobilen x64-Prozessorsystemen verwendet werden. Da mobile Prozessoren jedoch Energierichtlinientechnologie verwenden, um die Prozessorgeschwindigkeit während der Leerlaufzeit zu senken und so Energie zu sparen, können lange Latenzen auftreten, wenn der Prozessor während der Geschwindigkeitsänderung nicht verfügbar ist.

MaxRT eRTOS kann auf Systemen mit aktiviertem Hyper-Threading verwendet werden. MaxRT eRTOS behandelt den von Intel Hyper-Threading erstellten logischen Prozessor als separaten Prozessor. Da beide logischen Prozessoren denselben physischen Prozessor gemeinsam nutzen, kann ein logischer Prozessor die Leistung des anderen beeinträchtigen. Sie sollten auch die Leistung von MaxRT eRTOS bewerten, um sicherzustellen, dass Ihre Echtzeitanforderungen bei aktiviertem Hyper-Threading weiterhin erfüllt werden.

MaxRT eRTOS unterstützt nicht die Ausführung auf virtuellen Maschinen (VMs).

MaxRT eRTOS bietet Remote-Start- und Anfüge-Debugging-Funktionen für MaxRT eRTOS-Anwendungen mit Visual Studio 2022 und 2019.

MaxRT eRTOS bietet außerdem hervorragende Flexibilität bei der Verarbeitung von Ausnahmen. Sie können MaxRT eRTOS so konfigurieren, dass Ausnahmen mit einem strukturierten Ausnahmehandler behandelt werden, eine Debug-Unterbrechung generiert oder der Prozess gestoppt wird.

Nein, Anwendungen werden mit Microsoft Visual Studio entwickelt. Das MaxRT eRTOS SDK bietet einen Assistenten zur einfachen Projekterstellung und Vorlagen, die Ihnen den Einstieg erleichtern. Dank der Visual Studio Debugger-Unterstützung können Sie RTSS-Anwendungen in einer vertrauten Umgebung debuggen. MaxRT eRTOS unterstützt Remote-Debugging durch Start und lokales Anhängen in Visual Studio 2022 und 2019.

MaxRT eRTOS unterstützt eine Teilmenge von über 50 Windows-API-Aufrufen, die in einer Echtzeitumgebung sinnvoll sind.

Darüber hinaus bietet MaxRT eRTOS eine große Auswahl an Echtzeit-API-Aufrufen, mit denen Entwickler auf die Echtzeit- und Systemressourcen zugreifen können. Diese Echtzeit-API (RTAPI) besteht aus einer Reihe einzigartiger API-Aufrufe und Windows-basierter API-Aufrufe.

Die einzigartigen Echtzeit-API-Aufrufe sind Windows-modellierte Aufrufe, die wichtige Programmierfunktionen für Echtzeitanwendungen sowie Zugriff auf die Echtzeit- und Systemressourcen bieten. Diese einzigartigen RTAPI-Aufrufe haben keine entsprechenden Windows-Aufrufe.

Die von MaxRT eRTOS unterstützten Windows-basierten API-Aufrufe haben in der Windows-Umgebung ähnliche Funktionen. Allerdings erfordern diese Aufrufe eine andere Implementierung als ihre Windows-Gegenstücke, um die Echtzeitanforderungen von MaxRT eRTOS zu unterstützen. Alle Windows-basierten Aufrufe sind mit der Semantik der Windows-Programmierschnittstelle kompatibel, was es Entwicklern, die bereits mit der Windows-API vertraut sind, leicht macht.

MaxRT eRTOS-Anwendungen unterstützen die strukturierte Ausnahmebehandlung. Mit MaxRT eRTOS können Entwickler strukturierte Ausnahmebehandlungsfunktionen wie try, catch und throw innerhalb ihrer MaxRT eRTOS-Anwendung aufrufen. Wenn eine Anwendung beispielsweise auf einen NULL-Zeiger verweist, kann die Anwendung den Fehler behandeln, indem sie die Anwendung, die den Fehler verursacht hat, beendet oder einfriert, ohne das System zum Absturz zu bringen.

MaxRT eRTOS unterstützt eine Teilmenge von Microsoft C Runtime-Aufrufen, die Sie von Ihrer MaxRT eRTOS-Anwendung aus aufrufen können. MaxRT eRTOS bietet Microsoft C Runtime-Unterstützung für Microsoft Visual Studio 2022 und 2019.

Ja. MaxRT eRTOS unterstützt und speichert Statusinformationen für Advanced Vector Extensions (AVX) AVX/AVX2 (YMM0~YMM15), AVX512 (ZMM0-ZMM31), Advanced Matrix Extensions (AMX), Streaming SIM Extensions (SSE) SSE/SSE2/SSE3/SSE4 und MultiMedia Extensions (MMX)-Register, sofern die Hardware dies unterstützt.

MaxRT eRTOS SDK enthält ein vollständiges API-Referenzhandbuch für alle unterstützten Funktionen sowie kleine Codesegmente, die komplexere Konzepte erklären.

MaxRT eRTOS SDK bietet auch Quellcode für mehrere Beispielanwendungen, von denen einige MaxRT eRTOS-Messtools sind. Diese Beispiele können kompiliert und ausgeführt werden und zeigen grundlegende Konzepte und Anwendungsinteraktionen. Für Kunden mit Support enthält die IntervalZero-Support-Site mehrere Beispiele und Tools zur Verwendung mit MaxRT eRTOS.

MaxRT eRTOS bietet Werkzeuge (verfügbar auf der Support-Site und/oder im Kundencenter) und APIs, mit denen Entwickler die Systemreaktion und die Timerlatenz messen können:

• SRTM (System Response Timer Measurement) ist eine Befehlszeilenanwendung, die Timerlatenzen misst und Ergebnisse in Berichten und Histogrammen anzeigt.
• RtPerfMonitor ist ein Befehlszeilenprogramm, das Systeminformationen anzeigt, darunter Geschwindigkeit und Prozessortyp, HAL-Typ, CPU-Auslastung und andere Informationen, die zur Messung der RTSS-Anwendungslast verwendet werden können.
• Mehrere APIs zur Profilerstellung über Prozessoren hinweg, darunter die folgenden:
• RtGetThreadTimes ruft die Ausführungszeit eines bestimmten Threads ab.
• RtGetProcessTimes ruft Zeitinformationen für einen bestimmten RTSS-Prozess ab.
• QueryPerformanceCounter und QueryPerformanceFrequency bieten eine genaue Zeitverfolgung zwischen mehreren Prozessoren.

MaxRT eRTOS ermöglicht Anwendungen die Kommunikation über mehrere Inter-Process Communication (IPC)-Objekte. Wie bei der Inter-Process Communication von Windows erstellen oder öffnen Anwendungen Handles für benannte Objekte oder Speicherbereiche, was eine einfache und standardmäßige Kommunikation und Synchronisierung zwischen Anwendungen ermöglicht. Gemeinsam genutzte Speicherbereiche ermöglichen Anwendungen, denselben physischen Speicher anzuzeigen, ohne zusätzliche Nachrichten oder Daten zu übermitteln.

Standardobjekte:

• Ereignis – Das Ereignisobjekt ist ein Synchronisierungsobjekt. Es ist nützlich, um einem Thread ein Signal zu senden, das anzeigt, dass eine bestimmte Aktion stattgefunden hat.
• Mutex – Das Mutex-Objekt ist ein Synchronisierungsobjekt, dessen Status signalisiert wird, wenn es keinem Thread gehört, und nicht signalisiert wird, wenn das Mutex einem Thread gehört. Das Mutex-Objekt vermittelt den exklusiven Zugriff auf eine gemeinsam genutzte Ressource.
• Semaphor – Das Semaphor-Objekt ist ein Synchronisierungsobjekt, das einen Zähler zwischen null und einem angegebenen Maximalwert aufrechterhält. Der Zähler wird jedes Mal um eins verringert, wenn ein Thread eine Wartezeit auf das Semaphor-Objekt abschließt; der Zähler wird bei der Semaphor-Freigabe um einen variablen Betrag erhöht. Wenn der Zähler null erreicht, wird der Status des Semaphor-Objekts nicht mehr signalisiert und kein weiterer Thread kann eine Wartezeit auf das Semaphor-Objekt abschließen, bis ein anderer Thread den Zähler erhöht.
• Gemeinsam genutzter Speicher – Das gemeinsam genutzte Speicherobjekt ist ein Bereich des nicht ausgelagerten physischen Speichers, der in den virtuellen Adressraum eines Prozesses abgebildet werden kann. Wenn ein gemeinsam genutztes Speicherobjekt einen Namen hat, können zusätzliche Prozesse den Speicherbereich zuordnen. Auf ein gemeinsam genutztes Speicherobjekt wird sowohl mit einem Handle als auch mit einer virtuellen Adresse zugegriffen. Damit ein Prozess seinen Zugriff auf ein gemeinsam genutztes Speicherobjekt vollständig beenden kann, muss er alle offenen Handles schließen.

MaxRT eRTOS unterstützt MSI- und MSI-X-fähige Geräte und bietet damit eine Alternative zu leitungsbasierten Interrupts. Diese Funktionalität ist auf allen von MaxRT unterstützten Betriebssystemen verfügbar.

In welcher Beziehung stehen die threadbasierten Prioritäten von MaxRT eRTOS zu den Threadprioritäten von Windows?

Windows verfügt über einen Satz von 64 Prioritätsstufen im Bereich von 0–63. Sie sind weiter in 4 Prioritätsklassen unterteilt, von denen die Prioritätsklasse „Echtzeit“ die höchste Prioritätsklasse ist.

Die Prioritätsklasse „Echtzeit“ hat wiederum 7 Stufen innerhalb der Klasse. MaxRT eRTOS verwendet ein flaches Prioritätsschema mit 128 Prioritätsstufen.

MaxRT eRTOS bietet die Möglichkeit, Prioritätsumkehrprotokolle festzulegen, um Fälle zu behandeln, in denen ein Thread mit höherer Priorität auf einen Mutex wartet, der von einem Thread mit niedrigerer Priorität gehalten wird:

• Prioritätserhöhung mit abgestufter Herabstufung hebt einen Thread mit niedriger Priorität auf die Ebene des Threads mit höchster Priorität, der auf den gemeinsamen Mutex wartet, bis er den von einem Thread mit höherer Priorität angeforderten Mutex freigegeben hat.
• Deaktivieren – Erhöht die Prioritäten nicht in Fällen, in denen ein Thread mit höherer Priorität auf einen Mutex wartet, der von einem Thread mit niedrigerer Priorität gehalten wird.

IntervalZero MaxRT eRTOS ist ein von Grund auf neu entwickeltes Echtzeitbetriebssystem (RTOS), das für den Einsatz in der industriellen Automatisierung, medizinischen Geräten und anderen kritischen Anwendungen konzipiert ist. Die wichtigsten Merkmale, die es von anderen RTOSs unterscheiden, sind:

1. Basierend auf offenen Standards: IntervalZero setzt auf offene Standards und Tools (Visual Studio, C, C++, TSN), die die Investitionen unserer Kunden schützen, und auf IoT-Bereitschaft, die sicherstellt, dass der Maschinenbauer alle zukünftigen Anforderungen an die Cloud-Konnektivität erfüllen kann. Die RTOS-Plattform dient als Integrationsumgebung. Die Modularität und Anpassbarkeit erleichtern die Integration mehrerer Controller. Einige zukunftsorientierte Maschinenbauer konsolidieren sogar mehrere Controller auf einem einzigen PC.
2. Harte Echtzeitfunktionen: MaxRT eRTOS ist ein hartes Echtzeitbetriebssystem, was bedeutet, dass es auch bei hoher Belastung eine deterministische Reaktionszeit auf Ereignisse garantieren kann.
3. Erweiterte Debugging-Funktionen: IntervalZero MaxRT eRTOS bietet erweiterte Debugging-Funktionen unter Verwendung bekannter Windows-Debugging-Techniken, einschließlich kernelbasiertem Debugging, mit dem Entwickler Echtzeitanwendungen auf Kernelebene debuggen können. Dies erleichtert die Identifizierung und Behebung von Problemen in Echtzeitanwendungen.

Harte Echtzeit erfordert, dass eine Antwort logisch korrekt ist und vor einer bestimmten Ablauffrist eintritt, sonst ist das Ergebnis falsch und hat keinen Wert.

Weiche Echtzeit erfordert, dass eine Antwort logisch korrekt ist und vor einer bestimmten Deadline erfolgt oder das Ergebnis wird zunehmend ungenau, d. h. das Ergebnis kann noch einen gewissen Wert haben, obwohl es nach der erforderlichen Zeitspanne eingetreten ist.

Determinismus ist definiert als die Fähigkeit, rational und mit einem gewissen Grad an Präzision vorherzusagen, wann ein Ereignis eintreten wird. Determinismus, kombiniert mit einer Echtzeitumgebung, garantiert, dass ein Ereignis innerhalb einer kleinen Reaktionszeit eintritt und dass die Durchführung dieses Ereignisses wiederholbar ist.

Ein Echtzeitbetriebssystem bietet Determinismus und Vorhersagbarkeit, wenn es durch einen spezialisierten Scheduler auf ein bestimmtes Ereignis reagiert.

Windows wird üblicherweise als Allzweck-Betriebssystem bezeichnet, da es Anwendungen oder Treibern auf Kernel-Ebene nicht erlaubt, Interrupts vollständig zu verbergen und die Kontrolle über das Betriebssystem zu übernehmen. Je nach Hardware können die Interrupt-Latenzen unter Windows sehr gute Werte aufweisen, die im Durchschnitt im Mikrosekundenbereich liegen. Im schlimmsten Fall sind die Interrupt-Latenzen jedoch unbegrenzt und können Hunderte von Millisekunden überschreiten. Aufgrund dieser ungebundenen Latenzen ist eine deterministische Reaktionszeit nicht gewährleistet, was die Standard-Windows-Desktop- und -Server-Betriebssysteme für den Echtzeiteinsatz inakzeptabel macht.

IntervalZero’s RTX64-Software wandelt Microsoft Windows in ein Echtzeit-Betriebssystem (RTOS) um.

Für Projekte, die ein Windows-Benutzererlebnis verlangen und harte Echtzeit oder Determinismus erfordern, ermöglicht die RTX64 RTOS-Plattform OEMs und Endanwendern die Nutzung von Windows, x64-Multicore-Multiprozessortechnologie, symmetrischem Multiprocessing (SMP) und Echtzeit-Ethernet – alles in einer einzigen integrierten Entwicklungsumgebung.

• Verringerung der Materialkosten (BOM) um 25-50%
• Steigerung von Qualität und Leistung
• Rasche Skalierung und verkürzte Produktzyklenzeit
• Signifikante Reduzierung der Abhängigkeit von proprietärer Hardware wie DSPs

RTX64 unterstützt symmetrische Multiprozessorsysteme (SMP); eine Computerarchitektur, die es ermöglicht, Betriebssystem-Tasks und Benutzer-Threads so zu planen, dass sie auf jedem verfügbaren Prozessor ausgeführt werden können. Mit diesem Modell können mehrere Prozessoren für Echtzeitaktivitäten konfiguriert werden. RTSS-Threads können dedizierten RTSS-Prozessoren zur Ausführung zugewiesen werden, und sie können gleichzeitig laufen.

Wenn Sie RTX64 auf einem SMP-fähigen System betreiben, dann bestimmen Sie, wie viele der Prozessoren für Windows und wie viele für das RTX64 Echtzeit-Subsystem (RTSS) vorgesehen sind. RTX64 unterstützt SMP-Systeme, die bis zu 64 Prozessoren haben. Von diesen 64 können bis zu 63 für RTX64 reserviert werden (abhängig von der lizenzierten Edition).

Die RTX64 Runtime ermöglicht eine universelle Windows-Verarbeitung sowie eine leistungsstarke Echtzeitverarbeitung und -steuerung auf handelsüblichen (COTS-) Maschinen. Die RTX64 Runtime kann so konfiguriert werden, dass sie an Windows-Minidumps teilnimmt oder die Kontrolle übernimmt und Echtzeitprozesse sicher herunterfährt, wenn Windows einen Fehler feststellt.

Mit dem RTX64 SDK erhalten Entwickler ein umfangreiches Set an Interprozess-Kommunikations- und Synchronisationsfunktionen, die es RTSS-Anwendungen ermöglichen, mit Windows-Anwendungen (32-Bit und 64-Bit) zu kommunizieren und Daten mit ihnen auszutauschen. Darüber hinaus bietet RTX64 Entwicklern die Möglichkeit, direkt auf den Adressraum des I/O-Ports, den physischen Speicher oder die Hardware zuzugreifen, ohne dem Anwender ein Treibermodell aufzuzwingen.

RTX64 nutzt die Vorteile von 64-Bit-Registern und -Compilern voll aus, so dass Echtzeitentwickler dies ebenfalls tun können.

Die Verwendung von RTX64 auf einem SMP-System bietet erhebliche Vorteile, darunter:

• Leistungssteigerung – Sie können mehrere Prozessoren für kritische Echtzeitaufgaben bereitstellen. Sie können bis zu 63 Echtzeit-Threads auf einem 64-Prozessor-System gleichzeitig ausführen.
• Skalierung der Leistung – Für die Leistungsskalierung ist kein Neuschreiben von Code erforderlich. Sie können das Gleichgewicht zwischen Echtzeit- und Nicht-Echtzeit-Leistung anpassen, indem Sie die Anzahl der RTSS-Prozessoren und Windows-Prozessoren ändern.
• Hohe Verfügbarkeit – Kritische Tasks können für die Ausführung auf mehr als einem RTSS-Prozessor geplant werden.
• IRQ-Affinität – Sie können einen dedizierten RTSS-Prozessor für die Verarbeitung der Ein- und Ausgabe einzelner Hardwareteile festlegen.
• Behandlung von Systemfehlern – Echtzeit-Tasks überleben Systemabstürze.

Die Runtime ist in mehreren Editionen erhältlich, so dass Sie so viele Prozessoren lizenzieren können, wie für Ihre Lösung erforderlich sind. Die Editionen des Produkts RTX64 sind:

Sie können verfügbare Prozessoren über das RTX64-Aktivierungs- und Konfigurationsprogramm Windows oder RTX64 zuweisen. Das RTX64-Aktivierungsprogramm erkennt automatisch die Gesamtzahl der Prozessoren auf Ihrem System. Weitere Informationen finden Sie unter dem Thema Konfigurieren des Systems in der RTX64-Hilfe.

Alle Editionen der Runtime enthalten die gleichen Funktionen. Anwendungen, die mit dem SDK erstellt werden, können auf jeder Edition mit der gleichen Version von RTX64 ausgeführt werden. Dies gibt Entwicklern die Freiheit, Anwendungen zu entwickeln, die skalierbar sein können.

Das RTX64-Produkt wurde 2013 herausgebracht, um ein Echtzeit-Subsystem für Windows 7 bereitzustellen. RTX64 wurde kontinuierlich weiterentwickelt und unterstützt nun Multiprozessoren mit den folgenden 64-Bit-Betriebssystemen:

Windows 11

• Windows 11 (up to General Availability Channel Version 23H2)
• Windows 11 IoT Enterprise LTSC

RTX64 Support for Windows 11 Updates 

Windows 10

• Windows 10 (up to Semi-Annual Channel Version 22H2)
• Windows 10 IoT Enterprise LTSC (Long Term Servicing Channel Version 22H2)

RTX64 Support for Windows 10 Updates

Die letzte Version ist RTX64 4.5.4, herausgebracht im 2025.

RTX64 wird in einer Vielzahl von Produkten und vertikalen Märkten eingesetzt. Jeder, der eine Anwendung entwickelt, die Systemsteuerung, Determinismus oder Echtzeitleistung unter Windows erfordert, kann von der Einbeziehung von RTX64 in sein Produktdesign profitieren.

RTX64 wird in einigen der folgenden Märkte eingesetzt:

• Industrielle Automatisierung
• Digital Audio
• Test & Messtechnik
• Medizintechnik
• Wehrtechnik Luft- und Raumfahrt

IntervalZero bietet sechs Editionen des Produkts RTX64 Runtime an:

Die RTX64 Runtime-Installationen gibt es in mehreren Varianten:

• RTX64 Runtime Install – RTX64 kann per unbeaufsichtigter (silent) Installation erfolgen. Sie kann von der Kommandozeile aus aufgerufen oder innerhalb Ihrer eigenen Produktinstallation verwendet werden, so dass keine Benutzerinteraktion während des Installationsprozesses erforderlich ist.
• Merge Modules für RTX64-Laufzeitfunktionen – Die RTX64-Komponenten sind als Merge Modules verfügbar, die in die Installation eines OEM-Produkts eingebunden werden können. Bei einer separaten Installation werden die Merge Modules auf dem System zur Verfügung gestellt.

Weitere Informationen finden Sie im RTX64 Deployment Guide.

Die RTX64 Runtime wird mit den folgenden Funktionalitäten ausgeliefert:

• Erweiterung der Windows-HAL zur Unterstützung der Echtzeitsteuerung und Isolierung von Interrupts
• Scheduler, der über mehrere Kerne in einer dedizierten Konfiguration plant
• Deterministischer lokaler Speicher durch konfigurierbare Prozess-MSpaces
• Verarbeitungs- und Netzwerkfähigkeit durch eine Network Abstraction Layer (NAL) und einen optionalen RT-TCP/IP-Protokollstack innerhalb der RTSS-Umgebung
• Ein Control Panel zur Konfiguration des RTX64-Subsystems
• Die Möglichkeit, RTSS-Prozessausgaben in einem Konsolenfenster anzuzeigen, das so konfiguriert werden kann, dass es für jede Echtzeitanwendung oder als einzelne Instanz für alle Echtzeitanwendungen angezeigt wird.
• Ein Task-Manager-Dienstprogramm zur Anzeige von Echtzeitprozessen (.rtss) und mit RTX64 verknüpften Windows-Prozessen (.exe). Sie können mit dem Task-Manager neue Tasks starten und laufende Tasks beenden. Sie können auch Tasks planen, die mit dem Subsystem gestartet werden sollen, und CPU-Auslastungsdaten für alle Prozessoren anzeigen, die entweder Windows oder RTX64 zugewiesen sind
• Überwachungsinfrastruktur, die es Entwicklern ermöglicht, ein Profil des Verhaltens von RTSS-Anwendungen über alle RTSS-Prozessoren hinweg zu erstellen. Ebenfalls enthalten ist ein einfaches Dienstprogramm, das eine lesbare Textdatei ausgibt
• Latency View-Tool zur Anzeige der Timer-Latenz auf Windows- und RTSS-Cores
• Befehlszeilen-Utilities zur Anzeige der CPU-Auslastung und des Objektstatus
• Umfassende Hilfedateien und Benutzerhandbücher

Das RTX64-SDK wird mit den folgenden Komponenten geliefert:

• Header-Dateien und Bibliotheken
• Unterstützung für Visual Studio 2022, 2019, 2017 und 2015 (veraltet)
• Unterstützung für Microsoft C Runtime
• Vorlagen für die Erstellung von Anwendungen und DLLs
• API-Code-Schnipsel
• RTX64 WinDbg Extension, die Microsofts 64-Bit-Version von WinDbg erweitert und eine Möglichkeit bietet, den Zustand von RTSS-Prozessen sowie das RTX64-Subsystem zu analysieren und zu interpretieren
• Tracealyzer für RTX64, ein Diagnosewerkzeug von Percepio zum Betrachten von Überwachungssitzungsdaten
• Symbole zu Schlüsselkomponenten der RTX64 Runtime
• Umfassende Hilfedateien und MiniTutorials
• Quellcode-Beispiele, um fortgeschrittene Entwicklungsthemen zu erläutern

RTX64-Komponenten müssen mit einer gültigen Lizenz aktiviert werden, bevor sie verwendet werden können. Sie können das RTX64-Aktivierungs- und Konfigurationsprogramm, das unmittelbar nach der Programminstallation erscheint, verwenden, um Ihr Produkt zu aktivieren und an einen bestimmten Rechner oder an einen von IntervalZero bereitgestellten kompakten Dongle zu binden. Informationen zur Erstaktivierung finden Sie in der RTX64-Installationsanleitung für Ihr Produkt oder in der RTX64-Bereitstellungsanleitung.

Die Methode, mit der Sie Ihre Kopie von RTX64 aktivieren, hängt davon ab, ob Sie mit dem Internet verbunden sind. Es sind Videos verfügbar, die den Prozess der Aktivierung mit und ohne Internetverbindung zeigen. Sie können die Videos unter https://www.intervalzero.com/de/de-resources/de-videos/ ansehen.

RTX64 läuft auf Systemen mit bis 64 Prozessoren; bis 63 können RTX64 zugewiesen werden.

RTX64 kann auf Systemen mit mobilen x86 Prozessoren verwendet werden. Da mobile Prozessoren jedoch die Power-Policy-Technologie verwenden, um die Prozessorgeschwindigkeit während der Windows-Leerlaufzeit zu senken und somit Energie zu sparen, kann es zu langen Latenzzeiten kommen, wenn der Prozessor während der Geschwindigkeitsänderung nicht mehr verfügbar ist. RTX64 interagiert mit den Optionen der Windows-Energieverwaltung, um diese Funktionalität zu deaktivieren, was dazu führt, dass die Prozessoren nicht mehr verfügbar sind. Benutzer haben die Möglichkeit, die Windows-Leerlauferkennung wieder zu aktivieren, wenn ihre Anwendung mit der resultierenden Latenz arbeiten kann.

Nein, x2APIC-Systeme werden nicht unterstützt. Nur Systeme, die das Abschalten von x2APIC ermöglichen, werden unterstützt. Die RTX64-Installation wird, wenn möglich, x2APIC abschalten.

RTX64 kann auf Hyper-Threading-Systemen verwendet werden. RTX64 behandelt den von Intel Hyper-Threading erzeugten logischen Prozessor als separaten Prozessor. Da sich beide logischen Prozessoren denselben physischen Prozessor teilen, kann ein logischer Prozessor die Leistung des anderen beeinträchtigen. Es wird empfohlen, eine gerade Anzahl von Windows-Prozessen zu verwenden, damit sich ein logischer Windows-Prozessor und ein logischer RTSS-Prozessor nicht denselben physischen Prozessor teilen. Sie sollten auch die RTX64-Leistung bewerten, um sicherzustellen, dass bei aktiviertem Hyper-Threading Ihre Echtzeitanforderungen immer noch erreicht werden.

RTX64 Runtime kann neben Antivirensoftware von Drittanbietern betrieben werden, solange RTX64 Zugriff auf die benötigten Systemordner und Verzeichnisse erhält. Wenn RTX64 auf einem System mit einem 3rd-Party-Antivirus nicht korrekt funktioniert, ist es empfehlenswert, Ausnahmen in den Antivirus-Regeln/Policies einzutragen. So können Sie z.B. die Antivirensoftware anweisen, die RTX64-Komponenten RTX_RTSS, RTX_HALEXT, etc. zu ignorieren, oder den RTX64-Installationsordner ganz zu ignorieren. In manchen Fällen müssen Sie auch den Ordner ignorieren, aus dem Ihre Binärdateien ausgeführt werden.

Informationen darüber, welche Microsoft-Sicherheitsfunktionen auf demselben System wie RTX64 Runtime ausgeführt werden können, finden Sie in der TechNote RTX64 Compatibility with Microsoft Security Features, die auf der Support-Site verfügbar ist.

Virtuelle Maschinen sollten nicht für den Einsatz von RTX64-Laufzeitprodukten verwendet werden, da das Echtzeit-Subsystem keinen Determinismus in einer virtuellen Umgebung garantieren kann. Für die Entwicklung und den Test können jedoch virtuelle Maschinen verwendet werden. In der TechNote Virtual Machines Tested with RTX64/RTX finden Sie Informationen zu virtuellen Maschinen, die intern von IntervalZero verwendet wurden und von denen bekannt ist, dass sie mit RTX64 funktionieren.

HINWEIS: Für die Lizenzierung von RTX64 auf einer Virtuellen Maschine wird ein Dongle benötigt.

IntervalZero bietet die Möglichkeit einer unbeaufsichtigten (silent) Kommandozeilen-Installation für RTX64, die es einem OEM erlaubt, die RTX64-Installation zu verpacken und innerhalb einer anderen Installation zu verstecken. Die RTX64-Laufzeitkomponenten sind auch als Merge Modules verfügbar, die in die Installation eines OEM-Produkts eingebunden werden können.

IntervalZero stellt Managed Code und Native Frameworks zur Verfügung, die zur programmatischen Konfiguration des RTX64-Subsystems verwendet werden können. Dies ermöglicht es Kunden, die Anforderungen ihrer Software an das Subsystem einzurichten, ohne etwas von ihren Endbenutzern zu verlangen.

In Visual Studio bietet RTX64 lokale und Remote-Start- und Attach-Debugging-Funktionen für RTSS-Anwendungen mit Visual Studio 2019, 2017 und 2015 (veraltet).

RTX64 bietet auch eine hervorragende Flexibilität bei der Verarbeitung von Ausnahmen. Sie können RTX64 so konfigurieren, dass es Ausnahmen mit einem strukturierten Exception-Handler behandelt, einen Debug-Break generiert oder den Prozess anhält und den Speicher ausgibt.

RTX64 bietet eine WinDbg Erweiterung, die für das Post-Mortem Debugging einer Windows Speicherauszugsdatei verwendet werden kann.

RTX64 bietet auch Überwachungsfunktionen, die es ermöglichen, das Verhalten von Anwendungen zu verfolgen, ohne dass Änderungen am Code der Echtzeitanwendung erforderlich sind. Tracealyzer, ein grafisches Werkzeug zur Analyse von Monitor-Sitzungsdaten, wird ebenfalls bereitgestellt.

Ja. Sobald RTX64 erfolgreich installiert wurde, können alle authentifizierten Benutzer, die sich am System anmelden, das RTX64 Subsystem und die RTSS-Anwendungen steuern, konfigurieren und ausführen, auch wenn sie keine Computer- oder Domänenadministratoren sind. Systemadministratoren können den Zugriff auf die RTX64-Ressourcen steuern, indem sie Mitglieder der Gruppen RTX64Administrators und RTX64Users konfigurieren. Weitere Informationen finden Sie im RTX64 Runtime Install Guide.

Nein. RTSS-Anwendungen werden mit Microsoft Visual Studio entwickelt. Das RTX64 SDK bietet einen Assistenten zur einfachen Projekterstellung und Vorlagen, die Ihnen den Einstieg erleichtern. Mit der Unterstützung des Visual Studio Debugger können Sie RTSS-Anwendungen in einer vertrauten Umgebung debuggen. RTX64 unterstützt lokales und Remote-Debugging durch Launch und Local Attach in Visual Studio 2022, 2019, 2017 und 2015 (veraltet). Eine WinDbg-Erweiterung ist auch für das Post-Mortem-Debugging von Windows-Speicherabbilddateien verfügbar.

RTX64 unterstützt auch die Verwendung des Intel C++ Compilers innerhalb der Visual Studio IDE.

RTX64 unterstützt eine Teilmenge von über 50 Windows-API-Aufrufen, die in einer Echtzeitumgebung sinnvoll sind.

Zusätzlich bietet RTX64 eine große Auswahl an Echtzeit-API-Aufrufen, die Entwickler für den Zugriff auf das RTSS und die Systemressourcen verwenden. Diese Echtzeit-API (RTAPI) besteht aus einer Reihe von einzigartigen API-Aufrufen und Windows-basierten API-Aufrufen.

Die eindeutigen Echtzeit-API-Aufrufe sind von Windows modellierte Aufrufe, die wesentliche, für Echtzeitanwendungen erforderliche Programmierfunktionen sowie den Zugriff auf das RTSS und die Systemressourcen bereitstellen. Diese eindeutigen RTAPI-Aufrufe haben keine entsprechenden Windows-Aufrufe.

Die Windows-basierten API-Aufrufe, die von RTX64 unterstützt werden, unterscheiden sich von den einzigartigen RTAPI-Aufrufen dadurch, dass es in der Windows-Umgebung ähnliche Funktionen gibt; diese Aufrufe erfordern jedoch eine andere Implementierung als ihre Windows-Pendants, um die Echtzeitanforderungen des RTSS zu unterstützen. Alle Windows-basierten Aufrufe sind mit der Semantik der Windows-Programmierschnittstelle kompatibel, was es für Entwickler, die bereits mit der Windows-API vertraut sind, einfach macht.

RTX64 wurde so konzipiert, dass Entwickler Anwendungen als RTSS- oder Windows-Anwendungen entwerfen und entwickeln können. Wenn eine Anwendung als Windows-Anwendung entwickelt wird, können Entwickler die Vorteile von Funktionen wie dem User-Mode-Speicherschutz und anderen Debugging-Tools von Drittanbietern nutzen, die speziell für User-Mode-Anwendungen geeignet sind. Nachdem eine Anwendung wie gewünscht funktioniert, kann sie als RTSS-Anwendung neu kompiliert werden, die im Echtzeit-Subsystem auf dedizierten Prozessoren läuft, ohne dass Codeänderungen erforderlich sind.

Im Gegensatz zu anderen Anwendungen, die im Kernel-Modus laufen, unterstützen RTSS-Anwendungen das Structured Exception Handling. RTX64 ermöglicht Entwicklern den Aufruf von strukturierten Ausnahmebehandlungsfunktionen wie Try, Catch und Throw innerhalb ihrer RTSS-Anwendung. Wenn eine Anwendung zum Beispiel einen NULL-Zeiger referenziert, kann die Anwendung den Fehler behandeln, indem sie die Anwendung, die den Fehler verursacht hat, beendet oder einfriert, ohne das System herunterzufahren.

RTX64 unterstützt eine Teilmenge der Microsoft C Runtime-Calls, die Sie von Ihrer RTSS Anwendung aus aufrufen können. RTX64 bietet Microsoft C Runtime Support für Microsoft Visual Studio 2022, 2019, 2017 und 2015 (veraltet).

Ja. RTX64 unterstützt und speichert Statusinformationen für AVX/AVX2 (YMM0~YMM15), AVX-512, SSE (SSE/SSE2/SSE3/SSE4) und MMX-Register, sofern die Hardware dies unterstützt.

Das RTX64 SDK enthält eine vollständige API-Referenz für alle unterstützten Funktionen, zusätzlich zu kleinen Codesegmenten, die komplexere Konzepte erläutern.

Das RTX64 SDK bietet auch Quellcode für eine Reihe von Beispielanwendungen, darunter die RTX64-Messwerkzeuge. Diese Beispiele können kompiliert und ausgeführt werden und zeigen wichtige Konzepte und das Zusammenspiel der Anwendungen. Für Kunden mit Support enthält die IntervalZero Support Site mehrere Beispiele und Tools für die Verwendung mit RTX64.

RTX64 bietet Tools und APIs, die Entwicklern bei der Messung von Systemreaktions- und Timer-Latenz helfen:

• SRTM (System Response Timer Measurement) ist eine Kommandozeilenanwendung, die Timer-Latenzen misst und die Ergebnisse in Berichten und Histogrammen anzeigt.
• KSRTM (Kernel System Response Timer Measurement) ist ein Messwerkzeug, das Timer-Latenzen auf HAL-Ebene zur Interrupt Service Routine (ISR) misst und die Ergebnisse in Berichten und Histogrammen anzeigt.
• Latency View ist ein Tool, das einen visuellen Vergleich der Latenz zwischen Windows und RTX64-Cores anzeigt.
• RtPerfMonitor ist ein Befehlszeilenprogramm, das Systeminformationen anzeigt, einschließlich Geschwindigkeit und Typ des Prozessors, auf dem RTX64 läuft, HAL-Typ, CPU-Auslastung und andere Informationen, die zur Messung der RTSS-Anwendungslast verwendet werden können.
• Mehrere APIs für die Profilerstellung über Prozessoren hinweg, darunter die folgenden:
  • RtGetThreadTimes ruft die Ausführungszeit eines bestimmten Threads ab.
  • RtGetProcessTimes ruft die Zeitinformationen für einen bestimmten RTSS-Prozess ab.
  • QueryPerformanceCounter und QueryPerformanceFrequency ermöglichen eine genaue Zeitverfolgung zwischen mehreren Prozessoren.

RTX64 ermöglicht die Kommunikation zwischen Windows- und RTSS-Anwendungen über eine Reihe von Inter-Process Communication-(IPC-)Objekten. Verwenden Sie die RTAPI-Funktionen, um Objekte zu erstellen, die von Windows-Prozessen (32 und 64-Bit) eingesehen und verwendet werden können. Ähnlich wie bei der Inter-Prozess-Kommunikation unter Windows erstellen oder öffnen RTSS- und Windows-Anwendungen Handles zu benannten Objekten oder Speicherbereichen und ermöglichen so eine einfache und standardmäßige Kommunikation und Synchronisation zwischen Echtzeit-(RTSS-) und Nicht-Echtzeit-(Windows-)Anwendungen. Gemeinsame Speicherregionen ermöglichen es Windows- und RTSS-Anwendungen, denselben physischen Speicher zu sehen, ohne dass zusätzliche Nachrichten oder Daten zwischen den Umgebungen übergeben werden müsse

Standardobjekte:

• Event – Das Ereignisobjekt ist ein Synchronisationsobjekt. Es ist nützlich, um ein Signal an einen Thread zu senden, das anzeigt, dass eine bestimmte Aktion stattgefunden hat.
• Mutex – Das Mutex-Objekt ist ein Synchronisationsobjekt, dessen Zustand signalisiert wird, wenn es keinem Thread gehört, und nicht signalisiert wird, wenn das Mutex einem Thread gehört. Das Mutex-Objekt vermittelt den exklusiven Zugriff auf eine gemeinsam genutzte Ressource.
• Semaphor – Das Semaphor-Objekt ist ein Synchronisationsobjekt, das einen Zähler zwischen Null und einem festgelegten Maximalwert verwaltet. Der Zähler wird jedes Mal um eins verringert, wenn ein Thread eine Wartezeit auf das Semaphor-Objekt beendet; bei der Freigabe des Semaphors wird der Zähler um einen variablen Betrag erhöht. Wenn der Zähler Null erreicht, wird der Zustand des Semaphor-Objekts nicht mehr signalisiert und kein weiterer Thread kann ein Warten auf das Semaphor-Objekt abschließen, bis ein anderer Thread den Zähler erhöht.
• Shared Memory – Das gemeinsam genutzte Speicherobjekt ist ein Bereich des nicht ausgelagerten physischen Speichers, der in den virtuellen Adressraum eines Prozesses eingeblendet werden kann. Wenn ein Shared-Memory-Objekt einen Namen hat, können weitere Prozesse den Speicherbereich abbilden. Auf ein Shared-Memory-Objekt wird sowohl mit einem Handle als auch mit einer virtuellen Adresse zugegriffen. Damit ein Prozess seinen Zugriff auf ein gemeinsames Speicherobjekt vollständig beenden kann, muss er alle offenen Handles schließen.

RTX64 bezieht die Ressourcen, die das Gerät benötigt, vom Windows Plug and Play Manager. Um dies zu ermöglichen, muss der Treiber eines Geräts aktualisiert werden, um auf den RTX64-Plug-and-Play-Stub-Treiber zu verweisen. Nachdem das Gerät durch RTX64 gesteuert wird, müssen die Ressourcen des Geräts aktualisiert werden, um einen eindeutigen Interrupt anzufordern, der nicht bereits von Windows verwendet wird. (Die gemeinsame Nutzung von Interrupts mit Windows würde zu einem Verlust des Determinismus führen.) Beachten Sie, dass ein eindeutiger Interrupt nur für Geräte benötigt wird, die zeilenbasierte Interrupts verwenden. Sobald das Gerät eingerichtet ist, kann jede RTSS-Anwendung auf das Gerät zugreifen und es verwenden.

RTX64 unterstützt MSI- und MSI-X-fähige Geräte und bietet damit eine Alternative zu leitungsbasierten Interrupts. Diese Funktionalität ist auf allen von RTX64 unterstützten Betriebssystemen verfügbar.

Windows hat einen Satz von 64 Prioritätsstufen, die von 0-63 reichen. Sie sind weiter in 4 Prioritätsklassen definiert, von denen die „Echtzeit“-Prioritätsklasse die höchste Prioritätsklasse ist.

Die „Echtzeit“-Prioritätsklasse hat wiederum 7 Stufen innerhalb der Klasse. RTX64 verwendet ein flaches Prioritätsschema mit 127 Prioritätsstufen.

RTX64 bietet die Möglichkeit, eines von zwei Prioritätsinversionsprotokollen einzustellen, um Fälle zu behandeln, in denen ein Thread mit höherer Priorität auf ein Mutex wartet, das von einem Thread mit niedrigerer Priorität gehalten wird:

• Priority Promotion with Tiered Demotion hebt einen Thread mit niedriger Priorität auf das Niveau des Threads mit der höchsten Priorität, der auf das gemeinsame Mutex wartet, bis dieser das von einem Thread mit höherer Priorität angeforderte Mutex freigegeben hat.
• Deaktivieren – Erhöht die Prioritäten nicht in Fällen, in denen ein Thread mit höherer Priorität auf ein Mutex wartet, das von einem Thread mit niedriger Priorität gehalten wird.

RTX64 enthält eine echtzeitfähige Hardware Abstraction Layer-(HAL-)Erweiterung; diese Erweiterung ersetzt nicht die bestehende Windows HAL. Die Erweiterung erhält die Interrupt-Isolation zwischen RTSS und Windows aufrecht. Windows kann die von RTSS verwalteten Interrupts nicht maskieren (auf der Ebene des Interrupt-Controllers). Windows-Interrupts werden auf RTSS-Prozessoren/Kernen maskiert. Die Echtzeit-HAL-Erweiterung unterstützt hochauflösende Taktgeber und Timer für RTSS, während sie auch nicht-echtzeitfähige Taktgeber und Timer für Windows unterstützt. Zu den weiteren Funktionen der Echtzeit-HAL-Erweiterung gehören ein Software-Interrupt-Mechanismus zwischen RTSS und Windows, ein grundlegendes Exception-Management und Erweiterungen für den Determinismus. Die HAL-Timer-Werte können über eine vordefinierte Wertetabelle auf bis zu 1 µs geändert oder über das SDK mit einem eigenen Wert versehen werden.

RTX64 unterstützt die Intel® Resource Director Technology (RDT), die eine Reihe von Ressourcenzuweisungs-(oder Steuerungs-) Funktionen bietet, welche die Kontrolle darüber ermöglichen, wie gemeinsam genutzte Ressourcen wie der Last-Level-Cache (LLC) und die Speicherbandbreite von Anwendungen genutzt werden. Zu diesen Funktionen gehören Cache Allocation Technology (CAT) und Memory Bandwidth Allocation (MBA).

Als primäres Setup für Intel® RDT trennt RTX64 den L3/L2-Cachespeicherplatz zwischen Windows-Cores und RTSS-Cores, wodurch die Cache-Konkurrenz von Windows oder anderen Systemaktivitäten beseitigt wird. RTX64 setzt Windows-Cores mit maximalem Memory Throttle und RTSS-Cores mit Zero Memory Throttle. Um die Leistung zwischen den parallel laufenden RTSS-Threads weiter zu differenzieren, führt RTX64 zwei RDT-Modi für CAT und MBA ein: Flat-Performance-Modus und Prioritäts-basierter CLOS-Performance-Modus.

Weitere Informationen finden Sie in der RTX64-Hilfe.

Windows STOPs, oder Bug Checks, sind das Ergebnis von Kernel-Level-Treibern oder Betriebssystem-Komponenten, die Sicherheitsprüfungen nicht bestehen und Windows zu einem kontrollierten Halt bringen. Diese Windows-STOPs sollen die Datenbeschädigung auf ein Minimum beschränken und den Entwicklern helfen, herauszufinden, was falsch gelaufen ist.

Da der RTSS in der Lage ist, weiterzulaufen, nachdem Windows einen STOP ausgegeben hat, können Entwickler eine sichere Shutdown-Behandlung in RTSS-Anwendungen einbauen. RTX64 ruft die Shutdown-Handler auf, wenn Windows einen STOP ausgibt, so dass die Echtzeitkomponenten des Systems sicher heruntergefahren werden können. Sobald alle Shutdown Handler beendet sind, lässt RTX64 den Windows Shutdown-Prozess weiterlaufen.

Wenn das RTSS feststellt, dass Windows heruntergefahren werden muss, gibt RTX64 einen STOP aus, aber anstatt den traditionellen Windows Blue Screen anzuzeigen, zeigt RTX64 den RTX64 Green Screen an, der Informationen über den Zustand von RTX64 zum Zeitpunkt des STOP enthält.

Beim Absturz von Windows werden keine Zustände gespeichert.

Harte Echtzeit erfordert, dass eine Antwort logisch korrekt ist und vor einer bestimmten Ablauffrist eintritt, sonst ist das Ergebnis falsch und hat keinen Wert.

Weiche Echtzeit erfordert, dass eine Antwort logisch korrekt ist und vor einer bestimmten Deadline erfolgt oder das Ergebnis wird zunehmend ungenau, d. h. das Ergebnis kann noch einen gewissen Wert haben, obwohl es nach der erforderlichen Zeitspanne erfolgt ist.

Determinismus ist definiert als die Fähigkeit, rational und mit einem gewissen Grad an Präzision vorherzusagen, wann ein Ereignis eintreten wird. Determinismus, kombiniert mit einer Echtzeitumgebung, garantiert, dass ein Ereignis innerhalb einer kleinen Reaktionszeit eintritt und dass die Durchführung dieses Ereignisses wiederholbar ist.

Ein Echtzeitbetriebssystem bietet Determinismus und Vorhersagbarkeit, wenn es durch einen spezialisierten Scheduler auf ein bestimmtes Ereignis reagiert.

Windows wird üblicherweise als Allzweck-Betriebssystem bezeichnet, da es Anwendungen oder Treibern auf Kernel-Ebene nicht erlaubt, Interrupts vollständig zu verbergen und die Kontrolle über das Betriebssystem zu übernehmen. Je nach Hardware können die Interrupt-Latenzen unter Windows sehr gute Werte aufweisen, die im Durchschnitt im Mikrosekundenbereich liegen. Im schlimmsten Fall sind die Interrupt-Latenzen jedoch unbegrenzt und können Hunderte von Millisekunden überschreiten. Aufgrund dieser ungebundenen Latenzen ist eine deterministische Reaktionszeit nicht gewährleistet, was die Standard-Windows-Desktop- und -Server-Betriebssysteme für den Echtzeiteinsatz inakzeptabel macht.

IntervalZero’s RTX64-Software wandelt Microsoft Windows in ein Echtzeit-Betriebssystem (RTOS) um.

Für Projekte, die ein Windows-Benutzererlebnis verlangen und harte Echtzeit oder Determinismus erfordern, ermöglicht die RTX64 RTOS-Plattform OEMs und Endanwendern die Nutzung von Windows, x86-Multicore-Multiprozessortechnologie, symmetrischem Multiprocessing (SMP) und Echtzeit-Ethernet – alles in einer einzigen integrierten Entwicklungsumgebung.

• Verringerung der Materialkosten (BOM) um 25-50%
• Steigerung von Qualität und Leistung
• Rasche Skalierung und verkürzte Produktzyklenzeit
• Signifikante Reduzierung der Abhängigkeit von proprietärer Hardware wie DSPs

RTX von IntervalZero ist eine bewährte, zuverlässige Technologie, die Sicherheitsintegritätslevel 3 – (SIL-3-)Zertifizierungen in der Industrieautomatisierung und FDA Class II-Zertifizierungen bei zahlreichen Herstellern von medizinischen Geräten erreicht hat.

RTX unterstützt symmetrische Multiprozessorsysteme (SMP); eine Computerarchitektur, die es ermöglicht, Betriebssystem-Tasks und Benutzer-Threads so zu planen, dass sie auf jedem verfügbaren Prozessor ausgeführt werden können. Mit diesem Modell können mehrere Prozessoren für Echtzeitaktivitäten konfiguriert werden. RTSS-Threads können zur Ausführung auf dedizierten RTSS-Prozessoren zugewiesen werden, und sie können gleichzeitig laufen.

Wenn Sie RTX auf einem SMP-fähigen System betreiben, dann bestimmen Sie, wie viele der Prozessoren für Windows und wie viele für das RTX Echtzeit-Subsystem (RTSS) vorgesehen sind. RTX unterstützt SMP-Systeme, die bis zu 32 Prozessoren haben. Von diesen 32 können maximal 4 für Windows und bis zu 31 für RTX reserviert werden (abhängig von der lizenzierten Edition).

Die RTX Runtime ermöglicht eine universelle Windows-Verarbeitung und eine leistungsstarke Echtzeitverarbeitung und -steuerung auf handelsüblichen (COTS-)Maschinen. Die RTX Runtime kann so konfiguriert werden, dass sie an Windows-Minidumps teilnimmt oder die Kontrolle übernimmt und Echtzeitprozesse sicher herunterfährt, wenn Windows einen Fehler feststellt.

Das RTX SDK bietet Entwicklern ein umfangreiches Set an Interprozess-Kommunikations- und Synchronisationsfunktionen, die es RTSS-Anwendungen ermöglichen, mit Windows-Anwendungen zu kommunizieren und Daten mit ihnen auszutauschen. Darüber hinaus erhalten RTX64-Entwickler die Möglichkeit, direkt auf den Adressraum des I/O-Ports, den physischen Speicher oder die Hardware zuzugreifen, ohne dem Anwender ein Treibermodell aufzuzwingen.

Die Verwendung von RTX auf einem SMP-System bietet erhebliche Vorteile, darunter:

• Leistungssteigerung – Sie können mehrere Prozessoren für kritische Echtzeitaufgaben bereitstellen. Sie können bis zu 31 Echtzeit-Threads auf einem 32-Prozessor-System gleichzeitig ausführen.
• Skalierung der Leistung – Für die Leistungsskalierung ist kein Neuschreiben von Code erforderlich. Sie können das Gleichgewicht zwischen Echtzeit- und Nicht-Echtzeit-Leistung anpassen, indem Sie die Anzahl der RTSS-Prozessoren und Windows-Prozessoren ändern.
• Hohe Verfügbarkeit – Kritische Tasks können für die Ausführung auf mehr als einem RTSS-Prozessor geplant werden.
• IRQ-Affinität – Sie können einen dedizierten RTSS-Prozessor für die Verarbeitung der Ein- und Ausgabe einzelner Hardwareteile festlegen.
• Behandlung von Systemfehlern – Echtzeit-Tasks überleben Systemabstürze

Die Runtime ist in mehreren Editionen erhältlich, so dass Sie so viele Prozessoren lizenzieren können, wie für Ihre Lösung erforderlich sind. Die Editionen des Produkts RTX sind:

Alle Editionen der Runtime enthalten die gleichen Funktionen. Anwendungen, die mit dem SDK erstellt werden, können auf jeder Edition mit der gleichen Version von RTX64 ausgeführt werden. Dies gibt Entwicklern die Freiheit, Anwendungen zu entwickeln, die skalierbar sein können.

Das Produkt RTX wurde 1995 auf den Markt gebracht, um ein Echtzeit-Subsystem für Windows NT bereitzustellen. RTX hat sich kontinuierlich weiterentwickelt und bietet Echtzeitunterstützung für alle professionellen Betriebssysteme von Microsoft. RTX 2016 unterstützt Multiprozessoren mit 32-Bit-Windows 7 und Windows Embedded Standard 7.

Die derzeitige Version von RTX ist RTX 2016 with Update 3, freigegeben im Jahre 2019.

RTX wird in einer Vielzahl von Produkten und vertikalen Märkten eingesetzt. Jeder, der eine Anwendung entwickelt, die Systemsteuerung, Determinismus oder Echtzeitleistung unter Windows erfordert, kann von der Einbeziehung von RTX in sein Produktdesign profitieren.

RTX wird in einigen der folgenden Märkte eingesetzt:

• Industrielle Automatisierung
• Digital Audio
• Test & Messtechnik
• Medizintechnik
• Wehrtechnik Luft- und Raumfahrt

IntervalZero bietet sechs Editionen des RTX 2016 Runtime-Produkts an:

Die Installationen von RTX 2016 Runtime gibt es in mehreren Varianten:

• RTX Install – RTX 2016 kann unbeaufsichtigt (silent) installiert werden. Die Installation kann von der Kommandozeile aus aufgerufen oder innerhalb Ihrer eigenen Produktinstallation verwendet werden, um keine Benutzerinteraktion während des Installationsvorgangs zu erfordern. Der RTX Installer kann dem Windows Embedded Standard 7 Image Configuration Editor (ICE) auch als Distribution Share-Komponente hinzugefügt werden. Die unbeaufsichtigte Installation wird über eine OEM/Site-Lizenz lizenziert und ist auch als Evaluierungsversion erhältlich.
• Merge Modules für RTX-Laufzeitfunktionen – Die RTX 2016-Komponenten sind als Merge Modules verfügbar, die in die Installation eines OEM-Produkts aufgenommen werden können und über eine OEM/Site-Lizenz lizenziert werden. Bei einer separaten Installation werden die Merge Modules auf dem System für Ihre Verwendung platziert. Die Merge-Modules sind auch als Evaluierungsversion verfügbar.

Weitere Informationen finden Sie im RTX Deployment Guide.

Die RTX Runtime wird mit den folgenden Funktionalitäten ausgeliefert:

• Erweiterung der Windows-HAL zur Unterstützung der Echtzeitsteuerung und Isolierung von Interrupts
• Scheduler, der alle RTSS-Threads vor den Windows-Threads in einer gemeinsam genutzten Konfiguration oder über mehrere Kerne in einer dedizierten Konfiguration plant
• Unterstützung für die Kommunikation zwischen Windows-Anwendungen und RTSS-Anwendungen
• Unterstützung für die Kommunikation zwischen Windows-Kernel-Treibern und RTSS-Anwendungen
• Netzwerkunterstützung für die Socket-Level-Kommunikation zu und von RTSS-Prozessen
• Ein Bedienfeld, mit dem Sie das RTX-Subsystem konfigurieren können
• Die Möglichkeit, die Ausgabe von RTSS-Prozessen in einem Konsolenfenster anzuzeigen
• Befehlszeilen-Dienstprogramme zur Steuerung des Starts und Stopps von RTSS-Anwendungen
• Nützliche Werkzeuge zur Anzeige von Objekten und zur Durchführung von Anwendungsprofilen
• Umfassende Hilfedateien und Benutzerhandbücher

Das RTX SDK umfasst die RTX Runtime-Umgebung sowie die folgenden Komponenten:

• Header-Dateien und -Bibliotheken
• Unterstützung von Visual Studio
• Unterstützte Versionen:
  • Visual Studio 2015
  • Visual Studio 2013
• Unterstützung von Microsoft C Runtime
• Wizards
• Echtzeit-Debugger
• Debugger Datenerweiterung für Microsoft WinDbg
• Umfassende Hilfedateien und MiniTutorials
• Sourcecode-Muster, die fortschrittlichere Entwicklungsthemen erklären helfen

RTX-Komponenten müssen mit einer gültigen Lizenz aktiviert werden, bevor sie verwendet werden können. Sie können das RTX-Aktivierungs- und Konfigurationsprogramm, das unmittelbar nach der Programminstallation erscheint, verwenden, um Ihr Produkt zu aktivieren und an einen bestimmten Rechner oder an einen von IntervalZero bereitgestellten kompakten Dongle zu binden. Informationen zur Erstaktivierung finden Sie in dem RTX Install Guide für Ihr Produkt oder im RTX Deployment Guide.

Die Methode, mit der Sie Ihre Kopie von RTX aktivieren, hängt davon ab, ob Sie mit dem Internet verbunden sind. Es sind Videos verfügbar, die den Prozess der Aktivierung mit und ohne Internetverbindung zeigen. Sie können die Videos unter https://www.intervalzero.com/de/de-resources/de-videos/ ansehen.

RTX kann auf Systemen mit bis zu 32 Prozessoren ausgeführt werden.

• Systeme mit acht oder weniger Prozessoren, die nicht über hardwareerzwungenes Prozessor-Clustering verfügen, können mit einem bis sieben Prozessoren, die Windows zugewiesen sind, und den restlichen für RTX ausgeführt werden.
• Systeme mit mehr als acht Prozessoren (aber nicht mehr als 32) oder Systeme mit acht oder weniger Prozessoren, die über hardwareerzwungene Prozessorcluster verfügen, können nur im Modus „Dedicated (Cluster)“ ausgeführt werden. Auf diesen Systemen können maximal vier Prozessoren Windows und bis zu 31 Prozessoren RTX zugewiesen werden.

Sie können verfügbare Prozessoren über das RTX64-Aktivierungs- und Konfigurationsprogramm Windows oder RTX64 zuweisen. Das RTX64-Aktivierungsprogramm erkennt automatisch die Gesamtzahl der Prozessoren auf Ihrem System. Weitere Informationen finden Sie unter dem Thema Konfigurieren Ihres Systems in der RTX-Hilfe.

RTX kann auf Systemen mit mobilen Prozessoren verwendet werden. Da mobile Prozessoren jedoch die Intel´s SpeedStep®-Technologie verwenden, um die Prozessorgeschwindigkeit während der Windows-Leerlaufzeit zu senken und somit Energie zu sparen, kann es zu langen Latenzen kommen, wenn der Prozessor während der Geschwindigkeitsänderung nicht mehr verfügbar ist. RTX kann diese möglichen Latenzen vermeiden, wenn es keine Änderung der Prozessorgeschwindigkeit erlaubt.

RTX kann auf Hyper-Threading-Systemen verwendet werden. RTX behandelt den von Intel Hyper-Threading erstellten logischen Prozessor als separaten Prozessor, sodass Sie RTX entweder für die gemeinsame oder die dedizierte Multiprozessorunterstützung konfigurieren können. Da sich beide logischen Prozessoren denselben physischen Prozessor teilen, kann ein logischer Prozessor die Leistung des anderen beeinträchtigen. Es wird empfohlen, die RTX-Leistung zu evaluieren, um sicherzustellen, dass bei aktiviertem Hyper-Threading Ihre Echtzeitanforderungen weiterhin erfüllt werden.

RTX unterstützt PAE für alle Versionen von Windows, die PAE unterstützen. Vor RTX 2009 SP1 wurde PAE nur auf gemeinsam genutzten Konfigurationen unterstützt. Da RTX sich auf Windows verlässt, um das Speicher-Paging zu verwalten (die Übersetzung von der virtuellen Adresse zur physischen Adresse), kann RTX nicht auf die physischen Speicherbereiche zugreifen, für die Windows keine Page-Table-Einträge hat. Um 64-Bit-Windows zu forcieren, begrenzt 32-Bit-Windows den physischen Hauptspeicherbereich auf bis zu 4 GB, auch wenn das System mit aktiviertem PAE gebootet wird.

Weitere Informationen finden Sie in dem Microsoft-Artikel zu PAE unter http://technet.microsoft.com/en-us/library/cc736309.

Ja. Data Execution Prevention (DEP) wird unterstützt.

Das RTX SDK enthält ein Tool mit der Bezeichnung Platform Evaluator, mit dessen Hilfe Sie eine Reihe von Latenz-Messungen durchführen und bestimmen können, wie gut Plattformen Ihren Anforderungen an Echtzeit und Steuerung entsprechen.

IntervalZero bietet die Option einer unbeaufsichtigten (silent) Kommandozeileninstallation für RTX, die es einem OEM ermöglicht, die RTX-Installation zu verbergen und innerhalb einer anderen Installation auszuführen. Die RTX 2016 Runtime-Komponenten sind auch als Merge Modules verfügbar, die in die Installation eines OEM-Produkts eingebunden werden können. Zudem sind Evaluierungsversionen verfügbar.

IntervalZero bietet eine Eigenschaften-API, die zur programmatischen Konfiguration des RTX-Subsystems verwendet werden kann. Dies ermöglicht es Kunden, die Anforderungen ihrer Software an das Subsystem einzurichten, ohne dass ihre Endbenutzer etwas dafür tun müssen.

In Visual Studio bietet RTX Remote-Debugging-Funktionen für RTSS-Anwendungen mit Visual Studio 2015 und Visual Studio 2013.

RTX bietet zudem eine hervorragende Flexibilität bei der Verarbeitung von Ausnahmen. Sie können RTX so konfigurieren, dass es Ausnahmen mit einem strukturierten Exception-Handler behandelt, einen Debug-Break generiert oder den Prozess anhält und den Speicher ausgibt.

Eine Tracing-API ermöglicht es Entwicklern, benutzerdefinierte Trace-Ereignisse zu erstellen, die in Subsystem-Traces aufgenommen werden können, um Problembereiche zu lokalisieren.

RTX kann so konfiguriert werden, dass Informationen über aktive RTSS-Prozesse der Windows-Minidump-Datei hinzugefügt werden, die dann mit Microsoft WinDbg analysiert werden kann. Die RTX-Debugger-Datenerweiterung für WinDbg hilft Ihnen, den Zustand des RTSS und aller aktiven RTSS-Prozesse zum Zeitpunkt des Absturzes zu ermitteln, entweder mit Live-Kernel-Debugging oder anhand eines vollständigen Kernel-Dumps des Kundensystems.

Ja. Nach erfolgreicher Installation von RTX können alle authentifizierten Benutzer, die sich im System anmelden, das RTX-Subsystem und die RTSS-Anwendungen steuern, konfigurieren und ausführen, auch wenn sie keine Computer- oder Domänen-Administratoren sind. Systemadministratoren können den Zugriff auf die RTX-Ressourcen steuern, indem sie Mitglieder der Gruppen RTXAdministrators und RTXUsers konfigurieren. Weitere Informationen finden Sie im RTX Install Guide.

RTX 2016 ist binär-kompatibel mit RTX 2012 mit Update 1 und danach.

Nein. RTSS-Anwendungen werden mit Microsoft Visual Studio entwickelt. Das RTX-SDK bietet Assistenten zur einfachen Projekterstellung und Vorlagen, die Ihnen den Einstieg erleichtern. Mit einem Visual Studio Debugger-Add-in können Sie RTSS-Anwendungen in einer vertrauten Umgebung debuggen. RTX unterstützt Visual Studio 2015 und Visual Studio 2013.

Da RTSS-Anwendungen im Kernel-Modus laufen, können sie auch mit einem Kernel-Level-Debugger wie Microsoft WinDbg debuggt werden. Das RTX-SDK enthält eine RTX-Debugger-Datenerweiterung für WinDbg, mit der Sie aktive RTSS-Prozesse und Objekte anzeigen können.

RTX unterstützt eine Teilmenge von über 50 Win32-API-Aufrufen, die in einer Echtzeitumgebung sinnvoll sind.

Darüber hinaus bietet RTX eine große Auswahl an Echtzeit-API-Aufrufen, die Entwickler für den Zugriff auf das RTSS und die Systemressourcen verwenden. Diese Echtzeit-API (RTAPI) setzt sich aus einer Reihe von eindeutigen API-Aufrufen und Win32-basierten API-Aufrufen zusammen.

Die eindeutigen Echtzeit-API-Aufrufe sind Win32-modellierte Aufrufe, die wesentliche, für Echtzeitanwendungen erforderliche Programmierfunktionen sowie den Zugriff auf das RTSS und die Systemressourcen bereitstellen. Diese eindeutigen RTAPI-Aufrufe haben keine entsprechenden Win32-Aufrufe.

Die Win32-basierten API-Aufrufe, die von RTX unterstützt werden, unterscheiden sich von der RTAPI dadurch, dass es in der Win32-Umgebung ähnliche Funktionen gibt; diese Aufrufe erfordern jedoch eine andere Implementierung als ihre Win32-Gegenstücke, um die Echtzeitanforderungen des RTSS zu unterstützen. Alle Win32-basierten Aufrufe sind mit der Semantik der Win32-Programmierschnittstelle kompatibel, was es für Entwickler, die bereits mit der Windows-Win32-API vertraut sind, einfach macht.

RTX wurde so konzipiert, dass Entwickler Anwendungen als RTSS- oder Win32-Anwendungen entwerfen und entwickeln können. Wenn sie als Win32-Anwendung entwickelt werden, können Entwickler Funktionen wie den Benutzermodus-Speicherschutz und andere Debugging-Tools von Drittanbietern nutzen, die speziell für Benutzermodus-Anwendungen geeignet sind. Nachdem eine Anwendung wie gewünscht funktioniert, können Sie sie als RTSS-Anwendung neu kompilieren, die im Kernel-Modus läuft, ohne dass Codeänderungen erforderlich sind.

Im Gegensatz zu anderen Anwendungen, die im Kernel-Modus laufen, unterstützen RTSS-Anwendungen Structured Exception Handling. Mit RTX können Entwickler strukturierte Ausnahmebehandlungsfunktionen wie Try, Catch und Throw innerhalb ihrer RTSS-Anwendung aufrufen. Wenn eine Anwendung beispielsweise einen NULL-Zeiger referenziert, kann die Anwendung den Fehler behandeln, indem sie die Anwendung, die den Fehler verursacht hat, beendet oder einfriert, ohne das System herunterzufahren.

RTX unterstützt eine Teilmenge von Microsoft C Runtime-Aufrufen, die Sie von Ihrer RTSS-Anwendung aus aufrufen können. RTX bietet C Runtime-Unterstützung für Visual Studio 2015 und Visual Studio 2013.

RTX 8.1 und höher unterstützen „virtuelle“ IPv4-Adressen. Sie können einer einzelnen NIC bis zu 32 virtuelle IP-Adressen zuweisen.

Ja. RTX unterstützt und speichert Statusinformationen für AVX/AVX2 (YMM/YMM8), SSE (SSE/SSE2/SSE3/SSE4) und MMX-Register, solange die Hardware dies unterstützt.

Ein Kernel-Debugger ist zum Debuggen einer RTSS-Anwendung nicht erforderlich. Das RTX-SDK enthält Visual Studio-Debugger-Add-ins, mit denen Entwickler Echtzeit- oder Steuerungsanwendungen, die im Kernel-Modus ausgeführt werden, innerhalb der vertrauten Visual Studio-Entwicklungsumgebung debuggen können. Die Debugger-Add-ins für Visual Studio 2015 und Visual Studio 2013 unterstützen auch Remote-Debugging, sodass Entwickler eine RTSS-Anwendung auf einem Zielsystem mit speziellen Hardwareanforderungen remote debuggen können.

Wenn Sie jedoch die Verwendung von WinDbg von Microsoft bevorzugen, bietet das RTX-SDK Symbole, die beim Debuggen Ihrer RTSS-Anwendung helfen, zusammen mit einer Debugger-Datenerweiterung, mit der Benutzer Informationen über aktive RTSS-Prozesse, Threads und Objekte anzeigen können. Beachten Sie, dass WinDbg nicht auf dedizierten Konfigurationen verwendet werden kann, um in den Code einzubrechen und ihn schrittweise zu durchsuchen.

Das RTX SDK bietet ein Tool namens TimeView, mit dem Sie einen System-Trace einrichten können. Diese System-Traces setzen Zeitstempel und protokollieren einen konfigurierbaren Satz von System- und Prozessereignissen, so dass Entwickler das Verhalten ihrer Echtzeitanwendung mit minimalen Auswirkungen auf die Echtzeitleistung ihres Systems verfolgen können. Die RTAPI bietet auch Instrument Tracing-Funktionalität innerhalb der RTSS-Anwendung.

Das RTX SDK enthält ein vollständiges API-Referenzhandbuch für alle unterstützten Funktionen sowie kleine Codesegmente, die komplexere Konzepte erläutern.

Das RTX SDK bietet auch Quellcode für eine Reihe von Beispielanwendungen, darunter die RTX-Messwerkzeuge. Diese Beispiele können kompiliert und ausgeführt werden und zeigen wichtige Konzepte und Anwendungsinteraktionen.

RTX bietet eine Reihe von Tools und APIs, die Entwicklern bei der Messung von Systemreaktions- und Timer-Latenzzeiten helfen:

• SRTM (System Response Timer Measurement) – Ene Befehlszeilenanwendung, die Timer-Latenzen misst und die Ergebnisse in Berichten und Histogrammen anzeigt.
• KSRTM (Kernel System Response Timer Measurement) – Ein Treiber und ein Win32-Dienstprogramm, das Timer-Latenzen auf HAL-Ebene misst und die Ergebnisse in Berichten und Histogrammen anzeigt.
• RTX Demo – Eine grafische Version von SRTM, die Timer-Latenzen anzeigt.
• PerformanceView – Ein grafisches Dienstprogramm, das die CPU-Auslastung durch Echtzeitanwendungen, Windows-Prozesse und die Leerlaufzeit des Systems anzeigt. PerformanceView zeigt auch die maximale Zeit an, in der RTX die CPU auf gemeinsam genutzten Systemen gehalten hat.
• ObjectViewer – Ein grafisches Dienstprogramm, das Informationen für alle aktiven Objekte in der RTSS-Umgebung anzeigt, einschließlich Datum/Uhrzeit und Dauer der Thread-Erstellung.
• Mehrere APIs für die Profilerstellung über Prozessoren hinweg, darunter die folgenden:
  • RtGetThreadTimes ruft die Ausführungszeit eines bestimmten Threads ab.
  • QueryPerformanceCounter und QueryPerformanceFrequency ermöglichen eine genaue Zeitverfolgung zwischen mehreren Prozessoren.

RTX ermöglicht die Kommunikation zwischen Windows- und RTSS-Anwendungen über eine Reihe von Inter-Process Communication-(IPC-)Objekten. Verwenden Sie die RTAPI-Funktionen, um Objekte zu erstellen, die von Windows-Prozessen eingesehen und verwendet werden können. Ähnlich wie bei der Inter-Prozess-Kommunikation unter Windows erstellen oder öffnen RTSS- und Windows-Anwendungen Handles zu benannten Objekten oder Speicherbereichen und ermöglichen so eine einfache und standardmäßige Kommunikation und Synchronisation zwischen Echtzeit-(RTSS-) und Nicht-Echtzeit-(Windows-)Anwendungen. Gemeinsame Speicherregionen ermöglichen es Windows- und RTSS-Anwendungen, denselben physischen Speicher zu sehen, ohne dass zusätzliche Nachrichten oder Daten zwischen den Umgebungen übergeben werden müssen.

Standardobjekte:

• Event – Das Ereignisobjekt ist ein Synchronisationsobjekt. Es ist nützlich, um ein Signal an einen Thread zu senden, das anzeigt, dass eine bestimmte Aktion stattgefunden hat.
• Mutex – Das Mutex-Objekt ist ein Synchronisationsobjekt, dessen Zustand signalisiert wird, wenn es keinem Thread gehört, und nicht signalisiert wird, wenn das Mutex einem Thread gehört. Das Mutex-Objekt vermittelt den exklusiven Zugriff auf eine gemeinsam genutzte Ressource.
• Semaphor – Das Semaphor-Objekt ist ein Synchronisationsobjekt, das einen Zähler zwischen Null und einem festgelegten Maximalwert verwaltet. Der Zähler wird jedes Mal um eins verringert, wenn ein Thread eine Wartezeit auf das Semaphor-Objekt beendet; bei der Freigabe des Semaphors wird der Zähler um einen variablen Betrag erhöht. Wenn der Zähler Null erreicht, wird der Zustand des Semaphore-Objekts nicht mehr signalisiert und kein weiterer Thread kann ein Warten auf das Semaphore-Objekt abschließen, bis ein anderer Thread den Zähler erhöht.
• Shared Memory – Das gemeinsam genutzte Speicherobjekt ist ein Bereich des nicht ausgelagerten physischen Speichers, der in den virtuellen Adressraum eines Prozesses eingeblendet werden kann. Wenn ein Shared-Memory-Objekt einen Namen hat, können weitere Prozesse den Speicherbereich abbilden. Auf ein Shared-Memory-Objekt wird sowohl mit einem Handle als auch mit einer virtuellen Adresse zugegriffen. Damit ein Prozess seinen Zugriff auf ein gemeinsames Speicherobjekt vollständig beenden kann, muss er alle offenen Handler schließen.

RTX bietet eine Reihe von Echtzeit-Kernel-API-Aufrufen (RTKAPI), die es Windows-Treibern ermöglichen, aus einem Windows-Kernel-Gerätetreiber heraus auf RTX-Interprozess-Kommunikationsobjekte zuzugreifen. Diese RTKAPI-Aufrufe sind analog zu ihren RTAPI-Pendants. Zum Beispiel ist RtkOpenSemaphore analog zu RtOpenSemaphore.

Die RTKAPI-Funktionen und die RTAPI-Funktionen werden auf die gleiche Weise verwendet, aber RTKAPI-Funktionen werden ausschließlich in der Windows-Kernel-Umgebung verwendet.

RTX bezieht die Ressourcen, die das Gerät benötigt, vom Windows Plug and Play Manager. Um dies zu ermöglichen, muss der Treiber eines Geräts aktualisiert werden, um auf den RTX-Plug-and-Play-Stub-Treiber zu verweisen. Nachdem das Gerät durch RTX gesteuert wird, müssen die Ressourcen des Geräts aktualisiert werden, um einen eindeutigen Interrupt anzufordern, der nicht bereits von Windows verwendet wird. (Die gemeinsame Nutzung von Interrupts mit Windows würde zu einem Verlust des Determinismus führen.) Sobald das Gerät eingerichtet ist, kann jede RTSS-Anwendung auf das Gerät zugreifen und es verwenden.

RTX 8.1 und höher unterstützen MSI- und MSI-X-fähige Geräte und bieten damit eine Alternative zu zeilenbasierten Interrupts. Diese Funktionalität ist auf allen RTX-unterstützten Betriebssystemen verfügbar.

Windows verfügt über einen Satz von 32 Prioritätsstufen, die von 0 bis 31 reichen. Sie sind weiter in 4 Prioritätsklassen definiert, von denen die „Echtzeit“-Prioritätsklasse die höchste Prioritätsklasse ist.

Die „Echtzeit“-Prioritätsklasse hat wiederum 7 Stufen innerhalb der Klasse. RTX verwendet ein flaches Prioritätsschema mit 127 Prioritätsstufen. Wenn es RTX-Tasks oder RTX-Threads gibt, die zur Ausführung bereit sind, übernimmt RTX die vollständige Kontrolle über die Systemressourcen, unabhängig davon, welche Prioritätsstufe einem Windows-Thread gewährt wird.

Alle RTX-Prioritäten sind höher als die höchsten Windows-Prioritäten.

Der einzige Fall, in dem das Windows-Prioritätsschema relativ zum RTX-Schema ist, ist, wenn eine RTX-Anwendung als Win32-Anwendung und nicht als RTSS-Anwendung kompiliert wird. In diesem Fall werden die RTX-Prioritätsstufen auf die Windows-Prioritätsstufen abgebildet. Diese Zuordnungen sind fest und so konzipiert, dass die relative Reihenfolge der Thread-Prioritäten erhalten bleibt.

RTX bietet die Möglichkeit, eines von drei Prioritätsinversionsprotokollen einzustellen, um Fälle zu behandeln, in denen ein Thread mit höherer Priorität auf ein Mutex wartet, das von einem Thread mit niedriger Priorität gehalten wird:

• Priority Promotion with Tiered Demotion (Prioritäts-Promotion mit abgestufter Herabstufung) – Erhebt einen Thread mit niedriger Priorität auf die Ebene des Threads mit der höchsten Priorität, der auf das gemeinsame Mutex wartet, bis dieses den von einem Thread mit höherer Priorität angeforderten Mutex freigegeben hat.
• Priority Promotion with Limited Demotion – Erhebt einen Thread mit niedriger Priorität auf die Ebene des Threads mit der höchsten Priorität, der auf den gemeinsam genutzten Mutex wartet, bis er alle Mutexe freigegeben hat, die er besitzt
• Deaktivieren – Erhöht die Prioritäten nicht in Fällen, in denen ein Thread mit höherer Priorität auf einen Mutex wartet, der von einem Thread mit niedriger Priorität gehalten wird.

RTX enthält eine echtzeitfähige Hardware Abstraction Layer-(HAL-)Erweiterung; diese Erweiterung ersetzt nicht die bestehende Windows HAL. Die Erweiterung erhält die Interrupt-Isolation zwischen RTSS und Windows aufrecht. Windows kann die von RTSS verwalteten Interrupts nicht maskieren (auf der Ebene des Interrupt-Controllers). Windows-Interrupts werden auf RTSS-Prozessoren/Kernen maskiert. Die Echtzeit-HAL-Erweiterung unterstützt hochauflösende Taktgeber und Timer für RTSS, während sie auch nicht-echtzeitfähige Taktgeber und Timer für Windows unterstützt. Zu den weiteren Funktionen der Echtzeit-HAL-Erweiterung gehören ein Software-Interrupt-Mechanismus zwischen RTSS und Windows, ein grundlegendes Exception-Management und Erweiterungen für den Determinismus. Die HAL-Timer-Werte können über eine vordefinierte Wertetabelle auf bis zu 1 µs geändert oder über das SDK mit einem eigenen Wert versehen werden.

Windows STOPs, oder Bug Checks, sind das Ergebnis von Kernel-Level-Treibern oder Betriebssystem-Komponenten, die Sicherheitsprüfungen nicht bestehen und Windows zu einem kontrollierten Stopp bringen. Diese Windows-STOPs sollen die Datenbeschädigung auf ein Minimum beschränken und den Entwicklern helfen, herauszufinden, was falsch gelaufen ist.

Da der RTSS in der Lage ist, weiterzulaufen, nachdem Windows einen STOP ausgegeben hat, können Entwickler eine sichere Shutdown-Behandlung in RTSS-Anwendungen einbauen. RTX ruft die Shutdown-Handler auf, wenn Windows einen STOP ausgibt, so dass die Echtzeitkomponenten des Systems sicher heruntergefahren werden können. Sobald alle Shutdown Handler beendet sind, lässt RTX64 den Windows Shutdown Prozess weiterlaufen.

Wenn das RTSS feststellt, dass Windows heruntergefahren werden muss, gibt RTX64 einen STOP aus, aber anstatt den traditionellen Windows Blue Screen anzuzeigen, zeigt RTX64 den RTX64 Green Screen an, der Informationen über den Zustand von RTX64 zum Zeitpunkt des STOPP enthält.

Beim Absturz von Windows werden keine Zustände gespeichert.