Skip to content

Beyond the Bus

Architecting High-Performance Modular Systems with the Generic Information Interface (GII)

Executive Summary

In the late 1990s, while the industry was pivoting toward heavy-weight distributed models, a different philosophy emerged for high-speed data acquisition: The Generic Information Interface (GII). Built to handle raw ADC (Analog-to-Digital) measurements on systems with as little as 64MB of RAM, the GII architecture decouples data production from consumption using a "signaling" layer that manages memory-mapped segments and system parameters.

Today, this architecture lives on in the Scanframe sf-mod-app repository, providing a blueprint for modern C++ developers building resource-constrained, modular applications.

1. The Core Duality: Variables vs. Results

The GII splits the world into two distinct classes of information. This separation is key to its efficiency.

sf::Variable: The Control Plane

Variables handle "System State"—parameters that change relatively slowly but require immediate synchronization across modules.

  • Sync Logic: When a module updates a variable, the GII ensures all subscribers are notified.
  • Persistence: To maintain a lightweight core, the GII does not perform its own disk I/O for settings. Instead, a dedicated Settings Subscriber handles the saving and loading of configuration to and from files.
  • Code Reference: sf::Variable Source

sf::ResultData: The Data Plane

This is where the "heavy lifting" happens. sf::ResultData is designed for vast arrays of raw measurements (e.g., ADC buffers) that cannot fit in standard memory.

  • Philosophy: Instead of passing the data, the GII passes knowledge of the data's location.
  • Range Resolution: Ranges are defined strictly by raw indices, bypassing the overhead of timestamp-based calculations in the hot path.
  • Code Reference: sf::ResultData Source

2. The Engine Room: RangeManager and Memory Mapping

The secret sauce of the GII's performance is the RangeManager. Unlike standard message brokers that treat data as discrete packets, the GII treats it as a continuous, addressable timeline.

By using Memory-Mapped Files (filemaps), the GII offloads memory management to the OS kernel. The RangeManager performs "Bookkeeping," tracking which segments of the data are currently available in RAM and which are still "Cold" on the disk.

Dual-Mode Acquisition Strategy

The system intelligently manages data segments based on the acquisition state:

  • RUN Mode (Monitoring): The application reuses existing segments to provide a "Live View" without infinite disk growth.
  • RECORD Mode (Storage): The system continuously creates new segments until a STOP command is issued, ensuring gapless data capture for later analysis.
  • Coalescing Requests: If multiple modules request overlapping data ranges, the RangeManager merges them into a single optimized I/O operation.
  • Reference Counting: Data segments are only unmapped when the last module (Subscriber) releases its lock.
  • Code Reference: RangeManager.h

3. Asynchronous Signaling: The Post-2000 Evolution

Originally built on Borland C++ using Win32 PostMessage loops, the modern GII implementation utilizes POSIX Mutexes, Condition Variables, and Qt's Event Loop.

The architecture employs a Blocking Cross-Thread Proxy. This allows a high-priority background thread (the Data Publisher) to perform decompression and I/O, while safely notifying the Main Thread (the UI/Analysis) only when the data is "locked and loaded" in the filemap.

4. Conclusion: Lessons for the IoT Era

While modern protocols like MQTT are excellent for networked telemetry, the GII shows that for intra-process, high-bandwidth data, an internal "Zero-Copy" interface is unbeatable.

By separating the Metadata (GII signals) from the Payload (Memory-mapped segments), the Scanframe architecture achieves a level of performance that many modern "bloated" frameworks struggle to match.

Deep Dive into the Source

To see the GII in action, explore the unittests. These tests provide a practical look at how the RangeManager logic and sf::ResultData handle high-speed data state and synchronization.