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, 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
• Time Sensitive Networking (TSN)
• 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 during the installation process. 

• Merge Modules for MaxRT wRTOS™ Runtime Features – The MaxRT wRTOS™ components are available as merge modules that can be included in an OEM product installation. A separate installation places merge modules on the system for your use. 

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)  

• 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 to 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 

• Configuration Tool 

• ESI Import  

• 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, 2019, and 2017 

• 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 the option of a silent command-line installation for MaxRT wRTOS®, which allows 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 that can be included in the installation of an OEM product.

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, 2019, and 2017. 

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, 2019, and 2017. A WinDbg Extension is also available for postmortem debugging of Windows memory dump files.

MaxRT wRTOS™ also supports the use of the Intel C++ Compiler within the Visual Studio IDE.

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, 2019, and 2017.

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产品启用并锁定在特定的设备或英特蒙提供的小型外接加密U盘 (dongle) 上。至于Runtime，用户会收到与SDK绑定的许可证文件，其中包含购买的功能授权。关于首次启动的信息，请参阅对应产品的MaxRT eRTOS安装指南。

启动MaxRT eRTOS的方法会根据是否连接到网络而不同。另外还有连接网络和不连网络的启动步骤影片，可以在这里看到：https://www.intervalzero.com/cn/cn-resources/cn-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/cn/cn-resources/cn-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 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是一个已被认可且可靠的科技，取得了Safety 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/cn/cn-resources/cn-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当机的时候，系统不会储存任何状态。