To achieve ever-more realistic performance, whilst still maintaining real-time response, simulator systems adopt techniques such as multiprocessor systems, high-performance graphics cards, and distributed sensors and actuators to boost speed and flexibility. Increasingly, such systems consist of many different high-performance processing subsystem units that need to communicate in real time. Thus, as systems get larger and more distributed, the performance issues of latency, determinism, and system bottlenecks become even more critical in maintaining the simulation experience.
One primary issue is that, although use of COTS-based open-standard hardware such as VME and Unix/PC systems is common, until recently the only way to provide software connectivity between applications was via proprietary systems solutions. Another now-emerging issue is the need to ensure that investment in application software can be reused effectively across multiple projects.
These two vital but difficult factors are driving the need for more formalised software structures, as well as carving a path toward a COTS middleware solution. These issues must be tackled at two levels: both inside (between the simulator’s system components) and outside (for distributed simulator-to-simulator connectivity) such systems.
High Level Architecture (HLA) has emerged as a widely adopted middleware standard for simulator- to-simulator connectivity and data sharing, especially in the defence system market. But until recently, there was no viable open-standard middleware solution able to effectively address the even more demanding requirements of real-time data distribution within the individual simulator.
One key step in achieving the best performance for a simulator design is to optimise the “man-inthe-loop” function. This control loop must respond in real time to the changing environment and operator input, possibly within a network of simulators. Demands on the network throughput will vary, whether it’s a dynamics model running at up to 1000Hz exchanging information with a 100Hz I/O device (with a potential network throughput requirement of 10ms per data packet), or an image display device that needs data input at anything up to 60-80Hz to match the screen refresh. If data appears outside of this time interval, it will have to be ignored. A common response is to reduce the simulation fidelity to allow state recovery, a situation that simulator developers always seek to avoid.
As just mentioned, the issue of simulator-to-simulator data sharing has already been addressed by the HLA open standard middleware, promoted by the U.S. Department of Defense and implemented by the Simulation Interoperability Standards Organisation (SISO). The HLA Run Time Infrastructure (HLA-RTI) is most commonly used to link simulator systems together in a wide-area network, and in some cases it’s even being seen as a way to link the processing elements within individual simulators.
With this approach, there’s no need to translate the data from one format to another. Unfortunately, the HLA-RTI doesn’t have the speed and detailed control of real-time performance required by systems that need consistently low latencies and deterministic responses. As a result, simulator developers often end up creating proprietary protocols and methodologies so that there’s adequate real-time data distribution within the simulator.
However, another open standard with a publish/subscribe architecture offers a much better fit for our real-time requirements. Data Distribution Service (DDS) is open-standard, data-oriented middleware optimised for hard realtime systems. DDS features the low-latency and quality-of-service capabilities to provide the required speed and level of control of built-in real-time performance. This commercial-off-the-shelf (COTS) middleware is already widely used in aerospace, military, and industrial applications (see “What is DDS?”).
Better still, DDS’s structure allows it to work very well alongside, and in cooperation with, the existing HLA standard. DDS builds on the definition of HLA to add support for object modeling and ownership management. It addresses a number of performance- related issues not dealt with by HLA, such as a rich set of quality-of-service (QoS) policies, a strongly typed data model, and support for state propagation (including coherent and ordered data distribution). In particular, the QoS capability of DDS allows designers to maintain levels of priority for data, promising a fine level of control that ensures that the minimum latency requirements are met across the distributed system.
Real Time Innovations (RTI) implemented an enhanced version of DDS, designed to maximise benefits of the deterministic data environment supplied by the standard. The latest version, NDDS4.0, provides pluggable transports that support any media, from wireless to switched fabrics with programmable parameters, programmable QoS, and customisable data types (see the figure). The pluggable transports are unique to RTI’s implementation of the DDS standard. And, when combined with the QoS mechanisms of DDS, they provide performance “tunability” of data paths to the underlying simulator connectivity fabric. This also means that any transport medium can be used, from the widely used TCP/IP protocols to a switched fabric for higher-performance applications.
NDDS4.0 also uses direct end-to-end messaging, which eliminates context-switch delays. Combined with the support for message prioritisation, this ensures a predictable and low level of data latency. Meanwhile, pre-allocated memory prevents allocation and fragmentation delays that would otherwise contribute to a lack of deterministic operation in the subsystems’ responsiveness. Another advantage of NDDS 4.0 for the simulator developer is that there’s no server process to crash. Also, applications don’t share address space through the middleware. Therefore, operating-system processes can be isolated, which fully protects all applications.
This open-standards approach is already in use by several simulator developers, including CAE for flight simulators. NDDS is used to link subsystems via highspeed IEEE1394 Firewire links in its SimXXI product line. It opted for NDDS as an open standard that’s available off the shelf, rather than having to develop a proprietary technology.