ну что же, попытаюсь и я сформулировать свою пародию на ТЗ, потому что внешние индикаторы мне действительно хотелось бы видеть.

общая схема взаимодействия:
игра каким либо интерфейсом взаимодействует с драйвером внешних индикаторов, пересылая независимые потоки данных, каждый из потоков определяет один изменяемый параметр, например скорость, высота, положение закрылков, etc.

чтобы не перегружать процесс неприрывной пересылкой данных признак пересылки очередного нового значения параметра должен быть настраиваемым:
1) пересылка по таймеру (например каждые 0.5 сек),
2) пересылка по изменению на заранее заданную величину (например "скорость" на каждые 5км\час),
3) пересылка по требованию драйвера

так же должны быть настраимаемы единицы пересылки: метры, километры, мили, etc.

для конфигурации драйвера устройства индикации придется написать отдельную программу типа "микшер", с помощью которой можно будет правильно связать исходящий поток данных от игры с нужным иникатором.

само устройство индикации должно работать с одним из популярных PC интерфейсов: например Serial (COM1,etc)(как более легкий) или USB (как более сложный)

организации канала передачи данных:
способов межпроцессорного взаимодействия в среде MS Windows существует много (от фалов, как наиболее простой, до виртальных портов, SharedMemory, Semaphores), но не все из них оптимальны для нашей задачи, например общение на уровне файловой системы, даже виртуальной, сразу отразится на взаимодействии.
не имея информации о внутреннем обмене данными в LO сложно что-то конкретизировать, да и не нужно на данном этапе.
если разработчики поделятся идеей, то, как пример, можно использовать существующее взаимодействие LO c TrackIR.

Вся задача разбивается на несколько этапов и групп занятых людей:
группа 1 (железячная): пишет драйвер устройства, работающего через serial port (для начала), и создающая пару индикаторов разных типов (например типа "будильник" и числовой ), 2-3 человека
этап 1: создание индикатора с принципиальной возможностью чтения данных заданного формата из COM порта
этап 2: согласовав с группой 2 форматы создаются ТЗ на конкретные индикаторы (скорость, высота, закрылки, шасси, etc)

группа 2 (софтверная): вместе с человеком из ED договаривается о конкретном внешнем програмном интерфейсе, описываются форматы и константы, 1+1 или 2+1 человек.

этап 1:: группа выполняет тест задачу по принципиальной возможности получения данных, исследуется вопрос оптимального по скорости и удобству механизма
этап 2: описываются форматы и интерфейсы, создаётся спецификация, пишутся приложение настройщик "микшер" и драйвер.

дальнейшие эпапы подскажет уровень успеха обоих групп.

Valery, интересно услышать идеи-возражения-предложения по данному вопросу.