RTX64 RTOS，即時作業系統的常見問題

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.1, 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 offers a silent command-line installation 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 提供幾項優勢:

• 獨立於Windows，可在多達64個x64核心上執行而無需依賴任何其他作業系統。
• 與RTX64應用程式的原始碼相容，方便移轉。
• 適合HMI在不同裝置上執行且具備Web或OPC UA介面的遠端存取應用。

主要差異如下：

• MaxRT eRTOS是獨立的RTOS且不使用任何Windows功能。
• 支援多達64個處理器，而RTX64最多支援63個處理器。
• MaxRT eRTOS是專為遠端存取的嵌入式應用程式而設計，而RTX64則是擴充Windows以提供即時功能。

有，會提供完整的支援與文件，幫助使用者將應用程式從RTX64移轉至MaxRT eRTOS。

如果您的應用程式不需要在同一台電腦上同時運行HMI和即時系統，那麼MaxRT eRTOS就是在提升效能或提升安全性上比RTX64更好的選擇。

MaxRT eRTOS適用於各種產業，包括工業控制系統、自動化，以及任何需要穩健、獨立RTOS進行遠端存取的應用。許多無頭即時嵌入式系統都能從eRTOS中受益。

是，MaxRT eRTOS支援最多到64個核心的對稱多處理系統 (SMP)。在執行MaxRT eRTOS時，可以自行配置有多少個核心指派給MaxRT eRTOS (數量會根據所授權的版本而不同)。

MaxRT eRTOS Runtime支援高效能的即時行程和對商用現成 (COTS) 設備的控制。

MaxRT eRTOS SDK提供開發者豐富的行程間通訊以及同步的能力，允許MaxRT eRTOS應用程式溝通並分享資料。除此之外，MaxRT eRTOS提供開發者直接存取I/O位址空間、實體記憶體或硬體的能力，並且不需強制執行驅動程式。

MaxRT eRTOS完全善用64位元的暫存器與編譯器，讓即時開發者做到同樣的事。

在SMP系統上使用MaxRT eRTOS能夠提供非常顯著的好處，包含了：

• 效能提升 – 可以指派多個核心給重要、即時的工作。可以在64個核心的系統上同時跑最多64個即時執行緒。
• 效能擴充 – 擴充效能不需要重新寫程式，只要改變即時核心的數量就可以調整即時效能平衡。
• 可用性高 – 重要的工作可以排程給一個以上的即時核心。
• IRQ Affinity – 可以指定一個專用核心給硬體的每個部件處理輸入輸出。

MaxRT是以英特蒙2013年推出的RTX64產品為基礎所開發的新產品系列。

最新版本是2025年發布的MaxRT eRTOS 1.0。

MaxRT eRTOS可用在各式各樣不同的產品以及垂直整合的市場:

• 工業自動化
• 數位音訊
• 測試及測量
• 醫療
• 軍事航空

MaxRT eRTOS有開發即時應用程式的軟體開發套件 (SDK)，和部署應用程式的執行目標作業系統 (Runtime Target OS)。

英特蒙提供五種版本的MaxRT eRTOS Runtime：

MaxRT eRTOS Runtime有下列功能：

• 跨多個核心的行程與執行緒排程器。
• 經由可配置的MSpaces工具，提供準確性的本機記憶體。
• 藉由網路連結層 (NAL2) 及選用的RT-TCP/IP協定堆疊所得到的處理與網路能力。
• 支援鍵盤和滑鼠互動的USB堆疊。
• 用於配置即時核心與選用元件的INI檔案。
• 能夠在控制台顯示行程輸出。
• 用於觀測CPU使用與物件狀態的指令工具。
• 完整產品說明及使用手冊。

MaxRT eRTOS SDK包含下列元件：

• 標頭檔和函式庫。
• 支援Visual Studio 2022和2019。
• 支援微軟C Runtime。
• 建立應用程式和動態連結資料庫 (DLL) 的範本。
• 完整使用說明以及精簡教學指南。
• 幫助解釋更多進階開發主題的原始碼樣本。

必須要有效的授權才能啟動MaxRT eRTOS元件。使用者可用MaxRT eRTOS的啟動及配置命令列工具，將SDK產品啟用並鎖定在特定的設備或英特蒙提供的小型外接加密隨身碟 (dongle) 上。至於Runtime，使用者會收到與SDK綁定的授權檔案，其中包含購買的功能授權。關於首次啟動的資訊，請參閱對應產品的MaxRT eRTOS安裝指南。

啟動MaxRT eRTOS的方法會根據是否連接到網路而不同。另外還有連接網路和不連網路的啟動步驟影片，可以在這裡看到：https://www.intervalzero.com/tw/tw-resources/tw-videos/。

MaxRT eRTOS可以用在行動x64處理器系統。但是因為行動處理器在閒置的時候會以節能科技來降低處理器速度和保存能源，所以當速度轉換無法存取處理器時，延遲時間就有可能會變長。

MaxRT eRTOS可以在超執行緒系統上使用。MaxRT eRTOS把英特爾超執行緒 (Intel Hyper-Threading) 的邏輯處理器當作一個獨立的處理器。因為兩個邏輯處理器分享同一個實體處理器，其中一個邏輯處理器可能會影響到另一個的效能。建議評估MaxRT eRTOS效能以確保開啟超執行緒功能的時候，也能達到即時需求。

MaxRT eRTOS 不支援在虛擬機 (VM) 上執行。

MaxRT eRTOS對使用Visual Studio 2022和2019的MaxRT eRTOS應用程式提供遠端啟動與附加除錯功能。

MaxRT eRTOS也能完美靈活地處理例外狀況。可使用結構化例外處理器配置MaxRT eRTOS、產生除錯中斷、或停止行程。

不需要。可使用微軟的Visual Studio開發應用程式。MaxRT eRTOS SDK提供了簡單專案的開發精靈和幫助開始的範本。Visual Studio Debugger支援在熟悉的環境中除錯RTSS應用程式。MaxRT eRTOS支援透過Visual Studio 2022和2019的執行和本地附加進行遠端除錯。

MaxRT eRTOS支援超過50種在即時環境中有用的Windows API呼叫。

另外，MaxRT eRTOS還提供大量的即時API呼叫讓開發者存取即時和系統資源。即時API (RTAPI) 是由一組獨特的API呼叫和Windows-based API呼叫所共同組成。

獨特的即時API呼叫是提供即時應用程式所需基本程式能力的Windows-modeled呼叫，同時還能存取即時和系統資源。這些獨特的RTAPI呼叫和Windows呼叫是不同的。

MaxRT eRTOS所支援的Windows API呼叫在Windows環境中具有類似的功能，但為了滿足 MaxRT eRTOS的即時需求，這些呼叫的執行方式與Windows的對應版本不同。所有Windows-based呼叫都和Windows的程式介面語法相容，使得原本熟悉Windows API的開發者工作起來更簡單。

MaxRT eRTOS應用程式支援結構化例外處理。MaxRT eRTOS讓開發者在應用程式內呼叫結構化例外處理功能例如try、catch、和throw。舉例來說，如果一個應用程式參照了NULL指標，應用程式就可以終止或凍結造成錯誤的應用程式，而不需要關閉整個系統。

MaxRT eRTOS支援能從MaxRT eRTOS應用程式呼叫的微軟C Runtime呼叫子集，也支援微軟 Visual Studio 2022和2019的C Runtime。

是的。只要硬體支援，MaxRT eRTOS支援並儲存以下的狀態資訊：AVX/AVX2 (YMM0~YMM15)、AVX512 (ZMM0~ZMM31)、AMX、SSE (SSE/SSE2/SSE3/SSE4)、和MMX暫存器。

MaxRT eRTOS SDK包含各種支援功能的詳盡API參考指南以及用來解釋複雜觀念的簡短程式片段。

MaxRT eRTOS SDK也提供幾個範例應用程式的原始碼，其中有些是MaxRT eRTOS的測量工具。這些範例可以被編譯和執行，也展示了重要的概念和應用程式的互動。對於購買技術支援的客戶，英特蒙支援網站也包含了許多MaxRT eRTOS範例程式和工具。

MaxRT eRTOS在支援網站或客戶中心提供許多幫助開發者測量系統回應和時間延遲的工具以及API:

• 系統回應時間測量 (SRTM, System Response Timer Measurement) 是一個指令應用程式，用來測量時間延遲並且以報告和直方圖的方式呈現結果。
• RtPerfMonitor是一個指令程式，用來顯示系統資訊包括處理器的速度及種類、硬體抽象層類型、CPU的使用率和其他可檢測RTSS應用程式負載的資訊。
• 數種用來側寫處理器的API，包含有:
  • RtGetThreadTimes會擷取一個執行緒的執行時間。
  • RtGetProcessTimes會擷取一個RTSS行程的時間資訊。
  • QueryPerformanceCounter和QueryPerformanceFrequency提供在多個處理器之間的精確時間追蹤。

MaxRT eRTOS讓應用程式經由數個行程間通訊 (Inter-Process Communication, IPC) 物件相互溝通。如同Windows的行程間通訊，應用程式建立或打開控制代碼到已命名物件或記憶體區域上，並允許簡單和標準的通訊與同步。共享記憶體區域 (shared memory) 允許應用程式檢視同樣的實體記憶體，而不需要傳送額外的訊息或資料。

標準物件:

• 事件 (Event) – 事件是一個同步物件，對於傳送訊號給執行緒很有用，可以表明一個特定的動作已經發生了。
• 互斥鎖 (Mutex) – 互斥鎖是一個同步物件，當不被任何執行緒擁有的時候，狀態為有訊號 (signaled)；反之當被執行緒擁有時，狀態為無訊號 (not signaled)。互斥鎖可評斷一個共享資源是否被獨佔。
• 號誌 (Semaphore) – 號誌是一個同步物件，維持一個0到特定最大數字的計數。當執行緒完成一個號誌物件的等待，計數值就會減1。號誌被釋放的時候，計數值就會增加一個變數。當計數值變為0時，號誌物件的狀態就變成無訊號，也表示沒有執行緒能完成號誌物件等待，直到有別的執行緒增加了計數值。
• 共享記憶體 (Shared Memory) – 共享記憶體物件是一個非分頁實體記憶體的區塊，可以被對映到行程的虛擬位置空間。當一個共享記憶體物件有名字的時候，額外的行程就可以對映到這個記憶體區塊。控制代碼和虛擬位置都可存取共享記憶體。 如果行程想完全終止對共享記憶體的存取，就必須關閉所有開啟的控制代碼。

MaxRT eRTO支援MSI和MSI-X裝置，提供除了line-based中斷之外的另一個選擇。這個功能在所有MaxRT支援的作業系統中都可使用。

Windows有一組從0到63的64個優先權層級，這些層級再更進一步的被定義為4種優先權類別，而「即時」優先權是分類中最高的等級。

「即時」優先權分類裡又有7個層級。MaxRT eRTOS則使用128個優先權層級的扁平優先權規則。

當高優先權執行緒等待被低優先權執行緒限制的互斥鎖時，MaxRT eRTOS提供設定下列其中一種優先權反轉協定的選項：

• 分層降級 (Tiered Demotion) 的優先權提升，會提高一個低優先權執行緒的等級到正在等待共享互斥鎖的最高優先權執行緒，直到釋放更高優先權執行緒所要求的互斥鎖。
• 停用 – 當高優先權執行緒等待被低優先權執行緒限制的互斥鎖時，不提升優先權。

英特蒙MaxRT eRTOS是一款專為工業自動化、醫療裝置及其他關鍵應用所重新打造的即時作業系統 (RTOS)。與其他RTOS不同的關鍵特色包括:

• 以開放標準為基礎：英特蒙致力於支援開放標準與工具 (如Visual Studio、C、C++、TSN) 以保護客戶的投資心力，同時支援IoT以確保設備製造商能因應未來任何雲端連線的需求。RTOS平台本身也是一個整合環境，模組化與客製化能力降低了整合多個控制器的負擔。一些具前瞻性的設備製造商甚至已經將多個控制器整合到單一PC上。
• 硬即時能力: MaxRT eRTOS是一款硬即時作業系統，這表示即使在高負載的情況下也能對事件保證準確性的回應時間。
• 進階的除錯能力: 英特蒙MaxRT eRTOS支援進階除錯功能，可使用熟悉的Windows除錯技術包括核心感知 (kernel-aware) 除錯，這使得開發者能在核心層級除錯即時應用程式，更容易找出與修正問題。

所謂「硬即時」是指要求其回應是邏輯上正確的，且必須在某個截止期限或結果不正確之前發生，要是失敗了就無法得到任何數值。

所謂「軟即時」是要求其回應也是邏輯上正確的，但必須在某個截止期限或結果漸漸變得不精確之前發生，也就是即使回應發生在所要求的截止期限之後，仍然可以保有某些數值。

決定性被定義為能夠理性預測一個事件一定會發生的能力，並且伴隨一定程度的精確性。決定性加上即時環境，保證事件一定會在很小的回應時間內發生，而且這個事件的效能是可以重複的。

一個經由特定排程器向特定事件回應時，可提供決定性與可預測性的即時作業系統。

Windows通常被認為是一般用途的作業系統，因為它不允許應用程式或核心等級的驅動程式屏蔽中斷和控制整個作業系統。隨著硬體的不同，Windows的中斷延遲可能展現出很好的數值，平均可以在幾微秒內；但在最壞的情況下，中斷延遲有可能是不回應或超過數百毫秒。因為有可能不回應延遲，就無法確保決定性的回應時間，因此標準的Windows桌上型或伺服器的作業系統便無法當作即時使用。

英特蒙的RTX64軟體將微軟的Windows轉變成一個即時作業系統 (RTOS)。

對那些需要Windows使用者經驗和硬即時或決定性的專案而言，RTX64 RTOS 平台可讓OEM製造商和終端用戶善用Windows、X64多核多處理器科技、對稱多處理 (SMP)、以及即時乙太網路 – 所有的功能都整合在同一個開發環境中。

• 降低 25% – 50% 物料清單 (BOM) 成本
• 提升品質與效能
• 快速擴展並縮短產品週期
• 有效減少對專用硬體，例如DSP的依賴

RTX64支援對稱多處理系統 (SMP)。SMP是一種讓作業系統工作和排程使用者執行緒交給可用處理器的電腦架構。依循這個模式，多處理器就可以配置作為即時活動而用， RTSS 執行緒也可以被指派在 RTSS 處理器上執行，並同時運行。

在啟動SMP功能的系統上執行RTX64時，可以自行配置有多少個CPU內核指派給Windows，和多少個CPU內核給RTX64 即時子系統 (Real-time Subsystem, RTSS)。RTX64最多可支援SMP系統到63個CPU內核 (數量會根據所授權的版本而不同)。

RTX64 Runtime支援一般用途的Windows行程、高效能的即時行程和對商用現成 (COTS) 機器的控制。RTX64 Runtime可配置加入Windows小型傾印檔案，或如果Windows發生錯誤時，可以控制和安全地關閉即時行程。

RTX64 SDK提供開發者豐富的行程間通訊以及同步的能力，允許RTSS應用程式和Windows應用程式 (32位元與64位元) 溝通並分享資料。除此之外，RTX64提供開發者直接存取I/O位址空間、實體記憶體或硬體的能力，並且不需強制執行驅動程式。

RTX64完全善用64位元的暫存器與編譯器，讓即時開發者做到同樣的事。

在SMP系統上使用RTX64能夠提供非常顯著的好處，包含了：

• 效能提升 – 可以指派多個CPU內核給重要、即時的工作。可以在有64個CPU內核的系統上同時最多跑63個即時執行緒。
• 效能擴展 – 擴展效能不需要重新寫程式。只要改變RTSS和Windows兩邊處理器的數量，就可以調整即時和非即時的效能平衡。
• 可用性高 – 重要的工作可以排程給一個以上的RTSS處理器。
• IRQ Affinity – 可以指定一個專用RTSS處理器給硬體每個部件處理輸入輸出。
• 系統錯誤處理 – 即時工作在系統當機的時候仍可運行。

RTX64 Runtime有幾個不同版本，並針對解決方案授權給所需要的處理器數量。RTX64產品的版本有：

RTX64啟動及設置工具能指派可用的處理器給Windows或RTX64。RTX64啟動工具會自動偵測系統中處理器的數量。想知道更多訊息，請看RTX64使用說明「Configuring your System」。

所有Runtime的版本都包含同樣的功能。經由SDK所開發的應用程式，可以在同一種RTX64的任何一個版本上執行。這樣做讓開發者在開發應用程式的時候有更大的自由。

RTX64在2013年發布，為Windows 7提供一個即時子系統。持續進化的RTX64現在已能支援多處理器運行在下列64位元作業系統：

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

最新版本是2025年發布的RTX64 4.5.4。

RTX64用在各式各樣不同的產品以及垂直整合的市場。任何人想要需要設計系統控制、決定性與Windows即時效能的應用程式，都可以藉由導入RTX64到產品設計而得到助益。

RTX64會被用到下列市場中：

• 工業自動化
• 數位音訊
• 測試及測量
• 醫療
• 軍事航空

英特蒙提供六種版本的RTX64 Runtime：

可用下列幾種方法安裝RTX64 Runtime：

• RTX64 Runtime安裝 – RTX64可使用靜默安裝、指令執行安裝程式或者在自己的產品安裝中啟動，因此安裝過程中不需跟使用者互動。
• RTX64 Runtime的合併模組功能 – RTX64元件可被視為合併模組，包含在OEM產品的安裝程式中。另外的安裝程式會將合併模組放置於系統以供使用。

想了解更多資訊，請看RTX64部署指南。

RTX64 Runtime有下列功能：

• 擴充Windows HAL以支援即時控制與中斷獨立
• 可在專用設定下處理多核心的排程器
• 經由可設置的MSpaces工具，提供決定性的本機記憶體
• 於RTSS環境中藉由網路抽象層 (NAL) 及可選配的RT-TCP/IP協定堆疊所得到的處理與網路能力。
• 可配置RTX64子系統的控制台
• 展示RTSS行程並輸出到控制台視窗，可設定為展示每一個即時應用程式或集結所有應用程式的單一事例。
• 工作管理員可檢視和RTX64(.exe)連接的即時行程(.rtss)及Windows行程。可使用工作管理員開啟新工作和結束正在運行的工作。可從子系統開始排程工作，還有檢視所有處理器指派給Windows或RTX64的CPU使用資訊。
• 監視架構允許開發者側寫所有RTSS處理器的RTSS應用程式行為。其中也包含一個簡單的小程式，可將資料輸出成可讀取的文字檔。
• Latency View工具可用來檢視Windows和RTSS核心的時間延遲。
• 指令工具用來觀測CPU的使用與物件的狀態。
• 完整使用說明及用戶指南

想知道更多RTX64和RTX之間的差別，請看RTX與RTX64的比較指南在客戶中心

RTX64 SDK包含下列元件：

• 標頭檔和函式庫
• 支援Visual Studio 2022, 2019 2017和2015 (不建議使用)
• 支援微軟C Runtime
• 建立應用程式和動態連結資料庫 (DLL) 的模板
• API程式碼片段
• RTX64 WinDbg Extension能擴充WinDbg的微軟64位元版本，也提供分析和解讀RTSS行程與RTX64子系統狀態的方法。
• Tracealyzer for RTX64 – Percepio公司的診斷工具，用來查看監視區間資料
• RTX64 Runtime的主要元件符號
• 完整使用說明以及精簡教學指南
• 幫助解釋更多進階開發主題的原始碼樣本

必須要有效的授權才能啟動 RTX64 元件。用戶可使用RTX 64啟動及配置工具，這個程式會在主程式安裝之後馬上出現，並啟動和鎖定產品在特定的機器或英特蒙提供的dongle上。關於第一次啟動訊息，請看RTX64安裝指南或RTX64部署指南。

啟動RTX64的方法會根據是否連接到網路而不同。另外還有連接網路和不連網路的啟動程序影片，可以在這裡看到：https://www.intervalzero.com/tw/tw-resources/tw-videos/.

RTX64能夠運行在最多64個處理器的系統上，其中最多有63個處理器內核可以指派給RTX64。

RTX64可以用在行動處理器系統。但是因為行動處理器在Windows閒置的時候特別會以節能科技來降低處理器速度和保存能源，所以當速度轉換無法存取處理器時，延遲時間有可能會變長。RTX64會控制Windows電源管理選項並取消其功能，使得處理器無法被存取。如果使用者的應用程式可以接受這種程度的延遲，使用者可以重新開啟Windows的閒置偵測。

不行，RTX64不支援x2APIC系統，只支援能夠關閉x2APIC的系統。當可行的時候，RTX64安裝程式會關閉x2APIC。

RTX64可以在超執行緒系統上使用。RTX64把英特爾超執行緒 (Intel Hyper-Threading) 的邏輯處理器當作一個獨立的處理器。因為兩個邏輯處理器分享同一個實體處理器，其中一個邏輯處理器可能會影響到另一個的效能。建議使用偶數Windows處理程序，這樣Windows邏輯處理器和RTSS邏輯處理器就不會共用一個實體處理器了。建議評估RTX64效能以確保開啟超執行緒功能的時候，也能達到即時需求。

只要RTX64能存取所需的系統資料夾和目錄，RTX64 Runtime就可以和第三方防毒軟體一起使用。如果RTX64沒辦法正常的在第三方防毒軟體系統下運行，建議將RTX64加入防毒軟體規則的例外區。舉例來說，可以指示防毒軟體忽略RTX64的元件RTX_RTSS和RTX_HALEXT等，或忽略RTX64整個安裝資料夾。在某些情況下可能需要忽略二元執行碼所在的資料夾。更多微軟資安功能和RTX64 Runtime在同一個系統上運作的資訊，請參考支援網站的「RTX64 Compatibility with Microsoft Security Features」。

採用RTX64 Runtime不建議使用虛擬機器，因為即時子系統在虛擬環境中無法保證決定性。然而虛擬機器可以使用在開發和測試階段。更多訊息請參考技術文件「 Virtual Machines Tested with RTX64/RTX」，裡面有英特蒙內部已使用過並可以和RTX64一起運行的虛擬機器。

注意: 當授權RTX64到一台虛擬機器時，會需要一個dongle。

英特蒙提供靜默指令安裝RTX64選項，讓OEM廠商打包RTX64安裝程式並隱藏在另一個安裝程式裡。RTX64 Runtime元件也可當作合併模組包含在OEM產品的安裝程式裡。

英特蒙提供託管程式碼及原生架構來程式設定RTX64子系統。這可以讓客戶配置自己的軟體子系統需求，而不需要終端用戶的幫忙。

在Visual Studio裡，RTX64對使用Visual Studio 2022, 2019, 2017 和2015 (不建議使用) 的RTSS應用程式提供本地及遠端執行和附加的除錯能力。

RTX64也能完美靈活地處理例外狀況。可使用結構化例外處理器配置RTX64、生成除錯中斷或停止行程和傾印記憶體。

RTX64提供WinDbg擴充套件，使用在Windows記憶體傾印檔的postmortem 除錯上。

RTX64也提供了監看功能，不需改變即時應用程式碼即可追蹤應用程式行為。所提供的Tracealyzer是用來分析監看區間資料的圖形化工具。

可以。一旦RTX64安裝成功，所有登入系統的授權使用者，即使不是電腦或網域管理者，都可控制、配置、並且運行RTX64子系統和RTSS應用程式。系統管理者可藉由設置RTX64Administrators和RTX64Users群組的成員來控制及存取RTX64資源。想知道更多訊息，請參考「RTX64 Runtime Install Guide」。

不需要。可使用微軟的Visual Studio開發RTSS應用程式。RTX64 SDK提供了簡單專案的開發精靈和幫助開始的模板。Visual Studio Debugger支援在熟悉的環境中除錯RTSS應用程式。RTX64藉由在Visual Studio 2022, 2019, 2017, 和2015 (不建議使用) 的執行和本地夾帶，支援本地與遠端除錯，也提供Windows記憶體傾印檔的postmortem除錯 WinDbg擴充套件。

RTX64也支援在Visual Studio IDE使用Intel C++編譯器。

RTX64支援超過50種在即時環境中有用的Windows API呼叫。

另外，RTX64還提供大量的即時API呼叫讓開發者存取RTSS和系統資源。即時API (RTAPI) 是由一組獨特的API呼叫和Windows-based API呼叫所共同組成。

獨特的即時API呼叫是提供即時應用程式所需基本程式能力的Windows-modelled呼叫，同時還能存取RTSS和系統資源。這些獨特的RTAPI呼叫和Windows 呼叫是不同的。

RTX64支援的Windows-based API呼叫不像是前述的獨特RTAPI呼叫，雖然兩者在Windows環境下有類似的功能，但需要以不同的執行方式來支援RTSS的即時需求。所有Windows-based呼叫都和Windows的程式介面語法相容，使得原本熟悉Windows API的開發者工作起來更簡單。

RTX64是為了讓開發者能夠研發RTSS或Windows應用程式而設計的。當建立Windows應用程式時，開發者就可利用例如用戶模式記憶體保護，和其他第三方特別給用戶模式應用程式的除錯工具。應用程式按照預期的運行之後，可以在不改變程式碼的情況下重新編譯，使其變成可以在專用處理器的即時子系統裡運行的RTSS應用程式。

不像其他運行在核心模式的應用程式，RTSS應用程式支援結構化例外處理。RTX64讓開發者在RTSS應用程式內呼叫結構化例外處理功能例如try、catch、和throw。舉例來說，如果一個應用程式參照了NULL指標，RTSS 應用程式就可以終止或凍結造成錯誤的應用程式，而不需要關閉整個系統。

可以。RTX64支援能從RTSS應用程式呼叫的微軟C Runtime呼叫子集，也支援微軟 Visual Studio 2022, 2019, 2017, 和2015 (不建議使用) 的C Runtime。

是的。只要硬體支援，RTX64支援並儲存以下的狀態資訊：AVX/AVX2 (YMM0~YMM15)、AVX-512、SSE (SSE/SSE2/SSE3/SSE4)、和MMX暫存器。

RTX64 SDK包含各種支援功能的詳盡API參考指南以及用來解釋複雜觀念的簡短程式片段。

RTX64 SDK也提供範例程式的原始碼，其中有些是RTX64的測量工具。這些範例可以被編譯和執行，也可以展示重要的概念和應用程式的互動。對於購買技術支援的客戶，英特蒙支援網站也包含了許多RTX64範例程式和工具。

RTX64提供許多幫助開發者測量系統回應和時間延遲的工具以及API:

• 系統回應時間測量 (SRTM, System Response Timer Measurement) 是一個指令應用程式，用來測量時間延遲並且以報告和直方圖的方式呈現結果。
• 核心系統回應時間測量 (KSRTM, Kernel System Response Timer Measurement) 是一個測量工具，用來測量硬體抽象層等級的時間延遲和中斷服務常式 (ISR)，並且以報告和直方圖的方式呈現結果
• Latency View是一個用視覺來比較Windows和RTX64核心時間延遲的工具
• RtPerfMonitor是一個指令程式，用來顯示系統資訊包括RTX64處理器的速度及種類、硬體抽象層類型、CPU的使用率和其他可檢測RTSS應用程式負載的資訊
• 數種用來側寫處理器的API，包含有：
  • RtGetThreadTimes會擷取一個執行緒的執行時間
  • RtGetProcessTimes會擷取一個RTSS行程的時間資訊
  • QueryPerformanceCounter 和 QueryPerformanceFrequency提供在多個處理器之間的精確時間追蹤。

RTX64讓Windows和RTSS應用程式經由許多行程間通訊 (Inter-Process Communication, IPC) 物件相互溝通。使用RTAPI功能建立可被Windows行程 (32位元和64位元) 檢視和使用的物件。如同Windows的行程間通訊，RTSS和Windows應用程式在即時 (RTSS) 和非即時 (Windows) 應用程式之間，建立或打開控制代碼到已命名物件或記憶體區域上，並允許簡單和標準的通訊與同步。共享記憶體區域 (Shared Memory) 允許Windows和RTSS應用程式檢視同樣的實體記憶體，而不需要在兩個環境間傳送額外的訊息或資料。

標準物件：

• 事件 (Event) – 事件是一個同步物件，對於傳送訊號給執行緒很有用，可以表明一個特定的動作已經發生了。
• 互斥鎖 (Mutex) – 互斥鎖是一個同步物件，當不被任何執行緒擁有的時候，狀態為有訊號 (signaled)；反之當被執行緒擁有時，狀態為無訊號 (not signaled)。互斥鎖可評斷一個共享資源是否被獨佔。
• 號誌 (Semaphore) – 號誌是一個同步物件，維持一個0到特定最大數字的計數。當執行緒完成一個號誌物件的等待，計數值就會減1。號誌被釋放的時候，計數值就會增加一個變數。當計數值變為0時，號誌物件的狀態就變成無訊號，也表示沒有執行緒能完成號誌物件等待，直到有別的執行緒增加了計數值。
• 共享記憶體 (Shared Memory) – 共享記憶體物件是一個非分頁實體記憶體的區塊，可以被對映到行程的虛擬位置空間。當一個共享記憶體物件有名字的時候，額外的行程就可以對映到這個記憶體區塊。控制代碼和虛擬位置都可存取共享記憶體。 如果行程想完全終止對共享記憶體的存取，就必須關閉所有開啟的控制代碼。

RTX64是從Windows的隨插即用管理員獲取裝置所需的資源。要做到這一點，裝置的驅動模組必須更新並指向RTX64的隨插即用樁模組 (stub driver)。當裝置被RTX64控制之後，裝置的資源必須更新並要求一個不被Windows使用的獨特中斷。(共享中斷可能會喪失決定性)。請注意只有使用line-based中斷的裝置需要這個獨特中斷。一旦裝置設定好了，任何RTSS應用程式都可存取和使用這個裝置。

RTX64支援MSI 和 MSI-X裝置，提供除了line-based中斷之外的另一個選擇。 這個功能在所有RTX64支援的作業系統中都可使用。

Windows有一組從0到63的64個優先權層級，這些層級再更進一步的被定義為4種優先權類別，而「即時」優先權是分類中最高的等級。

「即時」優先權分類裡又有7個層級。RTX64則使用127個優先權層級的扁平優先權規則。

當高優先權執行緒等待被低優先權執行緒限制的互斥鎖時，RTX64提供設定下列其中一種優先權反轉協定的選項：

• 分層降級 (Tiered Demotion) 的優先權提升，會提高一個低優先權執行緒的等級到正在等待共享互斥鎖的最高優先權執行緒，直到釋放更高優先權執行緒所要求的互斥鎖。
• 停用 – 當高優先權執行緒等待被低優先權執行緒限制的互斥鎖時，不提升優先權。

RTX64包含了一個即時的硬體抽象層 (HAL) 擴充套件。這個擴充套件不會取代原本的Windows硬體抽象層。這個擴充套件會維持RTSS和Windows之間的中斷獨立。Windows不能夠 (在中斷控制層級) 屏蔽這些由RTSS所管理的中斷。Windows中斷在RTSS的處理器/核心裡是被屏蔽的。即時硬體抽象層擴充套件支援高解析度的RTSS時鐘和計時器，同時也支援非即時的Windows時鐘和計時器。其他的即時硬體抽象層擴充套件功能包含了RTSS和Windows之間的軟體中斷機制、基本的例外管理、以及決定性的加強。硬體抽象層計時器的數值可經由一個事先定義好的數值表來改變，最小可到1微秒，或是可以由SDK指定為一個特定的值。

RTX64支援英特爾的資源控管技術 (Resource Director Technology , RDT)，提供一組資源分配 (或控制) 的能力，以控制例如末級快取記憶體 (LLC) 和記憶體頻寬的共享資源如何被應用程式使用。這些能力包含了快取配置技術 (Cache Allocation Technology, CAT) 和記憶體頻寬配置 (Memory Bandwidth Allocation, MBA)。

在英特爾RDT的主要設定中，RTX64在Windows和RTSS核心間分離了L3/L2的快取空間，藉此排除Windows或其他系統活動造成的的快取記憶體競爭。RTX64將Windows核心設定為最大記憶體節流，而RTSS核心的記憶體節流則為零。為了更進一步區分同時運行的RTSS執行緒效能，RTX64針對CAT和MBA引進了兩種RDT模式： Flat效能模式和Priority-based CLOS效能模式。

更多資訊請參照 「RTX64 Help」。

Windows的STOP或Bug Check來自於核心級驅動程式或作業系統元件在安全測試時失敗的結果，目的是引導Windows到一個可控的停止狀態。Windows STOP設計用來使資料損毀降到最低和幫助開發者找到出錯的地方。

既然RTSS能在Windows STOP之後繼續運行，開發者可以在RTSS應用程式裡建立一個安全的關機程序。當Windows發布STOP訊號時，RTX64會呼叫關機控制代碼，讓系統即時元件安全的關機。一旦所有的關機代碼都結束執行，RTX64就會讓Windows的關機行程繼續進行。

如果RTSS決定Windows需要關機，RTX64就會發布STOP訊號；此時不會出現傳統的Windows藍色當機畫面，而是出現RTX64的綠色畫面和STOP發生時RTX64的相關狀態資訊。

當Windows當機的時候，系統不會儲存任何狀態。

所謂「硬即時」是指要求其回應是邏輯上正確的，且必須在某個截止期限或結果不正確之前發生，要是失敗了就無法得到任何數值。

所謂「軟即時」是要求其回應也是邏輯上正確的，但必須在某個截止期限或結果漸漸變得不精確之前發生，也就是即使回應發生在所要求的截止期限之後，仍然可以保有某些數值。

決定性被定義為能夠理性預測一個事件一定會發生的能力，並且伴隨一定程度的精確性。決定性加上即時環境，保證事件一定會在很小的回應時間內發生，而且這個事件的效能是可以重複的。

一個經由特定排程器向特定事件回應時，可提供決定性與可預測性的即時作業系統。

Windows通常被認為是一般用途的作業系統，因為它不允許應用程式或核心等級的驅動程式屏蔽中斷和控制整個作業系統。隨著硬體的不同，Windows的中斷延遲可能展現出很好的數值，平均可以在幾微秒內；但在最壞的情況下，中斷延遲有可能是不回應或超過數百毫秒。因為有可能不回應延遲，就無法確保決定性的回應時間，因此標準的Windows桌上型或伺服器的作業系統便無法當作即時使用。

英特蒙的RTX軟體將微軟的Windows轉變成一個即時作業系統 (RTOS)。

對那些需要Windows使用者經驗和硬即時或決定性的專案而言，RTX RTOS 平台可讓OEM製造商和終端用戶善用Windows、X86多核多處理器科技、對稱多處理 (SMP)、以及即時乙太網路 – 所有的功能都整合在同一個開發環境中。

• 降低 25% – 50% 物料清單 (BOM) 成本
• 提升品質與效能
• 快速擴展並縮短產品週期
• 有效減少對專用硬體，例如DSP和MCU的依賴

英特蒙的RTX是一個已被認可且可靠的科技，取得了Saftey Integrity Level 3 (SIL3) 的工業自動化認證，並與許多醫療設備的製造商一同取得FDA Class II認證。

RTX支援對稱多處理系統 (SMP)。SMP是一種讓作業系統工作和排程使用者執行緒交給可用處理器的電腦架構。依循這個模式，多處理器就可以配置作為即時活動而用， RTSS 執行緒也可以被指派在 RTSS 處理器上執行，並同時運行。

在啟動SMP功能的系統上執行RTX時，可以自行配置有多少個CPU內核指派給Windows，和多少個CPU內核給RTX即時子系統 (Real-time Subsystem, RTSS)。RTX最多可支援SMP系統到31個CPU內核 (數量會根據所授權的版本而不同)。

RTX Runtime支援一般用途的Windows行程、高效能的即時行程和對商用現成 (COTS) 機器的控制。RTX Runtime可配置加入Windows小型傾印檔案，或如果Windows發生錯誤時，可以控制和安全地關閉即時行程。

RTX SDK提供開發者豐富的行程間通訊以及同步的能力，允許RTSS應用程式和Windows應用程式溝通並分享資料。除此之外，RTX提供開發者直接存取I/O位址空間、實體記憶體或硬體的能力，並且不需強制執行驅動程式。

在SMP系統上使用RTX能夠提供非常顯著的好處，包含了：

• 效能提升 – 可以指派多個CPU內核給重要、即時的工作。可以在有32個CPU內核的系統上同時跑31個即時執行緒。
• 效能擴展 – 擴展效能不需要重新寫程式。只要改變RTSS和Windows兩邊處理器的數量，就可以調整即時和非即時的效能平衡。
• 可用性高 – 重要的工作可以排程給一個以上的RTSS處理器。
• IRQ Affinity – 可以指定一個專用RTSS處理器給硬體每個部件處理輸入輸出。
• 系統錯誤處理 – 即時工作在系統當機的時候仍可運行。

RTX Runtime有幾個不同版本，並針對解決方案授權給所需要的處理器數量。RTX產品的版本有：

有Runtime的版本都包含同樣的功能。經由SDK所開發的應用程式，可以在同一種RTX的任何一個版本上執行。這樣做讓開發者在開發應用程式的時候有更大的自由。

RTX在1955年發布，為Windows NT提供一個即時子系統。持續進化的RTX對所有專業版的微軟作業系統提供即時支援。RTX 2016支援多處理器，可在32位元的Windows 7 和Windows Embedded Standard 7上執行。

最新版本是2019年發布的RTX 2016 with Update 3。

RTX用在各式各樣不同的產品以及垂直整合的市場。任何人想要需要設計系統控制、決定性與Windows即時效能的應用程式，都可以藉由導入RTX到產品設計而得到助益。

RTX會被用到下列市場中：

• 工業自動化
• 數位音訊
• 測試及測量
• 醫療
• 軍事航空

英特蒙提供六種版本的RTX Runtime：

可用下列幾種方法安裝RTX 2016 Runtime：

• RTX安裝 – RTX 2016可使用靜默安裝、指令執行安裝程式或者在自己的產品安裝中啟動，因此安裝過程中不需跟使用者互動。也可使用Windows Embedded Standard 7 Image Configuration Editor (ICE) 把RTX 安裝程式當作一個Distribution Share元件。靜默安裝是由OEM/Site授權並且包含在試用版中。
• RTX Runtime的合併模組功能 – RTX元件可被視為合併模組，包含在OEM產品的安裝程式中並且由OEM/Site授權。另外的安裝程式會將合併模組放置於系統以供使用。試用版本也提供合併模組。

想了解更多資訊，請看RTX部署指南。

RTX Runtime有下列功能：

• 擴充Windows HAL以支援即時控制與中斷獨立
• 可以在共享配置或多核心專用配置裡將所有RTSS執行緒排程在Windows執行緒之前的排程器
• 支援Windows應用程式和RTSS應用程式之間的通訊
• 支援Windows核心驅動程式和RTSS應用程式之間的通訊
• 支援RTSS行程與socket level雙向通訊的網路
• 可配置RTX子系統的控制台
• 展示RTSS行程並輸出到控制台視窗
• 指令工具用來控制RTSS應用程式的開始與結束
• 可以展示物件和執行應用程式側寫的有用工具
• 完整使用說明及用戶指南

想知道更多RTX和RTX64之間的差別，請看RTX與RTX64的比較指南在客戶中心

RTX SDK包含下列元件：

• 標頭檔和函式庫
• 支援Visual Studio 2015和 2013
• 支援微軟C Runtime
• 開發精靈
• 即時除錯程式
• 微軟 WinDbg的Debugger Data Extension
• 完整使用說明以及精簡教學指南
• 幫助解釋更多進階開發主題的原始碼樣本

必須要有效的授權才能啟動 RTX元件。用戶可使用RTX 啟動及配置工具，這個程式會在主程式安裝之後馬上出現，並啟動和鎖定產品在特定的機器或英特蒙提供的dongle上。關於第一次啟動訊息，請看RTX安裝指南或RTX部署指南。

啟動RTX的方法會根據是否連接到網路而不同。另外還有連接網路和不連網路的啟動程序影片，可以在這裡看到：https://www.intervalzero.com/tw/tw-resources/tw-videos/.

RTX能夠運行在最多32個處理器的系統上。

• 硬體不強制處理器叢集並包含8個或8個以內處理器的系統，可以把1到7個處理器指派給Windows系統，其餘的指派給RTX。
• 超過8個處理器(但不超過32個)、或低於8個且硬體會強制處理器叢集的系統，可以以Dedicated (Cluster) 模式運行。在這些系統中，最多可指派4個處理器給Windows，31個處理器給RTX。

可經由RTX啟動及配置工具指派可用的處理器給Windows或RTX。RTX啟動工具會自動偵測系統上有多少個處理器。更多訊息請參考 RTX Help的「Configuring your System」。

RTX可以用在行動處理器系統。但是因為行動處理器在Windows閒置的時候會以英特爾的 SpeedStep®科技來降低處理器速度和保存能源，所以當速度轉換無法存取處理器時，延遲時間有可能會變長。RTX可藉由禁止處理器變動速度，排除這些有可能的延遲。

RTX可以在超執行緒系統上使用。RTX把英特爾超執行緒 (Intel Hyper-Threading) 的邏輯處理器當作一個獨立的處理器，因此可設置RTX以支援共享或專用多處理器。也因為兩個邏輯處理器分享同一個實體處理器，其中一個邏輯處理器可能會影響到另一個的效能。建議評估RTX效能以確保開啟超執行緒功能的時候，也能達到即時需求。

RTX支援所有支援PAE的Windows版本。在RTX 2009 SP1之前，只有在共享配置上才能支援PAE。因為RTX仰賴Windows管理記憶體分頁(把虛擬位址轉換成實體位址)，因此RTX無法存取沒有分頁表項的實體記憶體。為了讓64位元和32位元Windows的主要實體記憶體被限制在最多4GB，系統開機時也會啟用PAE。

想知道更多資訊，請看微軟PAE的文章 http://technet.microsoft.com/en-us/library/cc736309.

是的，RTX支援DEP。

RTX SDK包含了Platform Evaluator工具，可執行許多延遲測量的測試以決定平台是否符合即時和控制需求。

英特蒙提供靜默指令安裝RTX選項，讓OEM廠商打包RTX安裝程式並隱藏在另一個安裝程式裡。RTX Runtime元件也可當作合併模組包含在OEM產品的安裝程式裡。同時也提供試用版。

英特蒙提供專用API來程式設定RTX子系統。這可以讓客戶配置自己的軟體子系統需求，而不需要終端用戶的幫忙。

在Visual Studio裡，RTX對使用Visual Studio 2015和2013的RTSS應用程式提供遠端除錯能力。

RTX也能完美靈活地處理例外狀況。可使用結構化例外處理器配置RTX、生成除錯中斷或停止行程和傾印記憶體。

追蹤API允許開發者在子系統追蹤中建立客製化的追蹤事件，以查明有問題的區域。

RTX可被配置並增加主動RTSS行程資訊到Windows的minidump檔，以提供給微軟WinDbg分析。WinDbg 的RTX Debugger Data Extension可幫助了解RTSS的狀態和所有在當機時的RTSS行程- 不管是現場核心除錯時發生的或來自於客戶系統的kernel dump。

可以。一旦RTX安裝成功，所有登入系統的授權使用者，即使不是電腦或網域管理者，都可控制、配置、並且運行RTX子系統和RTSS應用程式。系統管理者可藉由設置RTXAdministrators和RTXUsers群組的成員來控制及存取RTX資源。想知道更多訊息，請參考「RTX Install Guide」。

RTX 2016 與RTX 2012 Update 1或以上的版本二進位相容。

不需要。可使用微軟的Visual Studio開發RTSS應用程式。RTX SDK提供了簡單專案的開發精靈和幫助開始的模板。Visual Studio Debugger外掛支援在熟悉的環境中除錯RTSS應用程式。RTX支援Visual Studio 2015和2013 。

因為RTSS應用程式以核心模式運行，所以能夠使用核心等級的除錯器像是微軟WinDbg。RTX SDK包含WinDbg的RTX Debugger Data Extension，可以檢視正在進行的RTSS行程和物件。

RTX支援超過50種在即時環境中有用的Win32 API呼叫。

另外，RTX還提供大量的即時API呼叫讓開發者存取RTSS和系統資源。即時API (RTAPI) 是由一組獨特的API呼叫和Win32-based API呼叫所共同組成。

獨特的即時API呼叫是提供即時應用程式所需基本程式能力的Win32-modelled呼叫，同時還能存取RTSS和系統資源。這些獨特的RTAPI呼叫和Win32 呼叫是不同的。

RTX支援的Win32-based API呼叫不像是前述的獨特RTAPI呼叫，雖然兩者在Win32環境下有類似的功能，但需要以不同的執行方式來支援RTSS的即時需求。所有Win32-based呼叫都和Win32的程式介面語法相容，使得原本熟悉 Win32 API的開發者工作起來更簡單。

RTX是為了讓開發者能夠研發RTSS或Win32應用程式而設計的。當建立Win32應用程式時，開發者就可利用例如用戶模式記憶體保護，和其他第三方特別給用戶模式應用程式的除錯工具。應用程式按照預期的運行之後，可以在不改變程式碼的情況下重新編譯，使其變成可以在核心模式裡運行的RTSS應用程式。

不像其他運行在核心模式的應用程式，RTSS應用程式支援結構化例外處理。RTX讓開發者在RTSS應用程式內呼叫結構化例外處理功能例如try、catch、和throw。舉例來說，如果一個應用程式參照了NULL指標，RTSS 應用程式就可以終止或凍結造成錯誤的應用程式，而不需要關閉整個系統。

可以。RTX支援能從RTSS應用程式呼叫的微軟C Runtime呼叫子集，也支援微軟 Visual Studio 2015和2013 的C Runtime。

RTX 8.1以及之後的版本支援虛擬IPv4位址。可以指派最多32個虛擬IP位址給單一一個網路卡。

是的。只要硬體支援，RTX支援並儲存以下的狀態資訊：AVX/AVX2 (YMM/YMM8)、SSE (SSE/SSE2/SSE3/SSE4)、和MMX暫存器。

不一定要使用核心除錯器來除錯RTSS應用程式。RTX SDK包含了Visual Studio除錯外掛程式，允許開發者在熟悉的Visual Studio開發環境下為以核心模式運行的即時或控制應用程式除錯。Visual Studio 2015 和 Visual Studio 2013的除錯外掛程式也支援遠端除錯，因此開發者可以遠端在有特定硬體需求的目標系統上除錯RTSS應用程式。

但如果想使用微軟WinDbg，RTX SDK即可提供符號以幫助RTSS應用程式除錯，和Debugger Data Extension讓使用者查看RTSS行程、執行緒、以及物件的資訊。請注意WinDbg不能夠在一個專用配置上使用break in 和 step through 程式碼。

RTX SDK 提供了一個TimeView工具可設置系統追蹤。這些系統能追蹤時間戳記和紀錄一群可配置的系統與行程事件，允許開發者追蹤在對系統即時效能最小的影響下，即時應用程式的行為。RTAPI也提供了在RTSS應用程式中的儀器追蹤功能。

RTX SDK包含各種支援功能的詳盡API參考指南以及用來解釋複雜觀念的簡短程式片段。

RTX SDK也提供範例程式的原始碼，其中有些是RTX的測量工具。這些範例可以被編譯和執行，也可以展示重要的概念和應用程式的互動。

RTX提供許多幫助開發者測量系統回應和時間延遲的工具以及API:

• 系統回應時間測量 (SRTM, System Response Timer Measurement) – 指令應用程式，用來測量時間延遲並且以報告和直方圖的方式呈現結果。
• 核心系統回應時間測量 (KSRTM, Kernel System Response Timer Measurement) –  驅動程式和Win32的工具，用來測量硬體抽象層等級的時間延遲，並且以報告和直方圖的方式呈現結果
• RTX Demo – 展示時間延遲的SRTM圖形版本
• PerformanceView – 是一個圖像的工具，顯示藉由即時應用程式、Windows行程、以及系統閒置時間的CPU使用率。PerformanceView還可展示在共享系統中RTX佔有CPU的最大時間。
• ObjectViewer – 一種圖形化工具，用來展示RTSS環境中所有正在進行的物件，包含執行緒建立日期、時間、和期間。
• 數種用來側寫處理器的API，包含有：
  • RtGetThreadTimes會擷取一個執行緒的執行時間
  • QueryPerformanceCounter 和 QueryPerformanceFrequency提供在多個處理器之間的精確時間追蹤。

RTX讓Windows和RTSS應用程式經由許多行程間通訊 (Inter-Process Communication, IPC) 物件相互溝通。使用RTAPI功能建立可被Windows行程檢視和使用的物件。如同Windows的行程間通訊，RTSS和Windows應用程式在即時 (RTSS) 和非即時(Windows) 應用程式之間，建立或打開控制代碼到已命名物件或記憶體區域上，並允許簡單和標準的通訊與同步。共享記憶體區域 (Shared Memory) 允許Windows和RTSS應用程式檢視同樣的實體記憶體，而不需要在兩個環境間傳送額外的訊息或資料。

標準物件：

• 事件 (Event) – 事件是一個同步物件，對於傳送訊號給執行緒很有用，可以表明一個特定的動作已經發生了。
• 互斥鎖 (Mutex) – 互斥鎖是一個同步物件，當不被任何執行緒擁有的時候，狀態為有訊號 (signaled)；反之當被執行緒擁有時，狀態為無訊號 (not signaled)。互斥鎖可評斷一個共享資源是否被獨佔。
• 號誌 (Semaphore) – 號誌是一個同步物件，維持一個0到特定最大數字的計數。當執行緒完成一個號誌物件的等待，計數值就會減1。號誌被釋放的時候，計數值就會增加一個變數。當計數值變為0時，號誌物件的狀態就變成無訊號，也表示沒有執行緒能完成號誌物件等待，直到有別的執行緒增加了計數值。
• 共享記憶體 (Shared Memory) – 共享記憶體物件是一個非分頁實體記憶體的區塊，可以被對映到行程的虛擬位置空間。當一個共享記憶體物件有名字的時候，額外的行程就可以對映到這個記憶體區塊。控制代碼和虛擬位置都可存取共享記憶體。 如果行程想完全終止對共享記憶體的存取，就必須關閉所有開啟的控制代碼。

RTX提供一組即時核心API (RTKAPI) 呼叫，允許Windows驅動程式從Windows核心裝置驅動程式存取RTX的行程間通訊物件。這些RTKAPI呼叫和其RTAPI副本是類似的。舉例來說，RtkOpenSemaphore類似於RtOpenSemaphore。

RTKAPI和 RTAPI功能的使用方法是一樣的，但RTKAPI功能專門使用在Windows核心環境中。

RTX是從Windows的隨插即用管理員獲取裝置所需的資源。要做到這一點，裝置的驅動模組必須更新並指向RTX的隨插即用樁模組 (stub driver)。當裝置被RTX控制之後，裝置的資源必須更新並要求一個不被Windows使用的獨特中斷。(共享中斷可能會喪失決定性)。一旦裝置設定好了，任何RTSS應用程式都可存取和使用這個裝置。

RTX支援MSI 和 MSI-X裝置，提供除了line-based中斷之外的另一個選擇。 這個功能在所有RTX支援的作業系統中都可使用。

Windows有一組從0到31的32個優先權層級，這些層級再更進一步的被定義為4種優先權類別，而「即時」優先權是分類中最高的等級。

「即時」優先權分類裡又有7個層級。RTX則使用127個優先權層級的扁平優先權規則。不管Windows執行緒所獲得的優先層級為何，當有任何RTX任務或執行緒準備要運行時，RTX都會得到系統資源的所有控制權。

所有RTX的優先權都高於Windows的最高優先權。

Windows優先權規則只有在一種時候才可以與RTX優先權相提並論，就是在RTX應用程式以Win32應用程式而不是RTSS應用程式來編譯的時候。這個時候RTX的優先權就會對映到Windows優先權層級。這樣的對映是固定的，並且是設計來保留執行緒優先權的相對順序。

當高優先權執行緒等待被低優先權執行緒限制的互斥鎖時，RTX提供設定下列其中一種優先權反轉協定的選項：

• 分層降級 (Tiered Demotion) 的優先權提升 – 會提高一個低優先權執行緒的等級到正在等待共享互斥鎖的最高優先權執行緒，直到釋放更高優先權執行緒所要求的互斥鎖。
• 有限降級(Limited Demotion)的優先權提升 – 提升一個低優先權執行緒到一個正等待共享互斥鎖的最高優先權執行緒等級，直到釋放出所擁有的互斥鎖為止。
• 停用 – 當高優先權執行緒等待被低優先權執行緒限制的互斥鎖時，不提升優先權。

RTX包含了一個即時的硬體抽象層 (HAL) 擴充套件。這個擴充套件不會取代原本的Windows硬體抽象層。這個擴充套件會維持RTSS和Windows之間的中斷獨立。Windows不能夠 (在中斷控制層級) 屏蔽這些由RTSS所管理的中斷。Windows中斷在RTSS行程時是被屏蔽的。即時硬體抽象層擴充套件支援高解析度的RTSS時鐘和計時器，同時也支援非即時的Windows時鐘和計時器。其他的即時硬體抽象層擴充套件功能包含了RTSS和Windows之間的軟體中斷機制、基本的例外管理、以及決定性的加強。硬體抽象層計時器的數值可經由一個事先定義好的數值表來改變，最小可到1微秒，或是可以由SDK指定為一個特定的值。

Windows的STOP或Bug Check來自於核心級驅動程式或作業系統元件在安全測試時失敗的結果，目的是引導Windows到一個可控的停止狀態。Windows STOP設計用來使資料損毀降到最低和幫助開發者找到出錯的地方。

既然RTSS能在Windows STOP之後繼續運行，開發者可以在RTSS應用程式裡建立一個安全的關機程序。當Windows發布STOP訊號時，RTX會呼叫關機控制代碼，讓系統即時元件安全的關機。一旦所有的關機代碼都結束執行，RTX就會讓Windows的關機行程繼續進行。

如果RTSS決定Windows需要關機，RTX就會發布STOP訊號；此時不會出現傳統的Windows藍色當機畫面，而是出現RTX的綠色畫面和STOP發生時RTX6的相關狀態資訊。

當Windows當機的時候，系統不會儲存任何狀態。