Qraizer: Есть большая железяка. Точнее, две, полнократное дублирование, как бы. Она большая не по размерам, внутри она состоит из 8-ми пар различных вычислителей, занимающихся каждый своей частью задачи. Для неё был создан испытательный стенд на базе ПК под виндой. Он обвешан железом с проприетарными дровами, через которые ПК "командует" этой железкой и принимает от неё результаты. Задействованы все мыслимые каналы передачи, от банального UART до отраслевого ARINC. ПК по сети связан с другим ПК, где крутится модель. Модель с точностью двух сигм имитирует поведение борта, по сути в реальном времени интегрирует несколько десятков диффур. От неё по сети приходят данные для железки и в неё же отправляются результаты от железки. В обмене информацией задействованы в общей сложности не одна тысяча сигналов. В итоге железка пребывает в полной уверенности, что она на борту, а борт в режиме эксплуатации.
Есть тестовое окружения на базе среды RTRT. Модульные тесты покрывают весь функционал железки, их нынче несколько тысяч и это ещё не конец. Моя задача (увы, далеко не единственная, и не всегда самая приоритетная) с осени и по сей день заключается в том, чтобы обеспечить возможность на этом тестовом окружении в условиях отсутствия модели имитировать её, чтобы закрыть пункт интеграционного тестирования железки. Точности не требуется от слова вообще, она должна лишь прикинуться моделью, чтобы тесты могли подавать тестовые воздействия согласно требованиям и оценивать их итоги согласно требованиям же. Тестовое окружение универсально и тоже полагается на сетевое взаимодействие. Только это совершенно другие протоколы. И к тому же работающие совсем в другой сети, в другом городе с доступом к стенду по VPN. У нас нет лицензий на их проприетарные железяки с дровами, у них есть. У них нет лицензий на RTRT, у нас есть. В общем, всё сложно.
Их сетевой протокол простой: обмен датаграммами по UDP максимально часто. Наш сетевой протокол сложнее: простой динамический аналог DNS без привязки адресов и маршрутизация между узлами сети пакетов данных, а уже на пакетах можно реализовать любой протокол. Т.е. фактически можно использовать среду RTRT как транспорт. Формально это просто маршрутизация трафика с адресацией по имени узла. Ну и да, там TCP. Формально, такие маршрутизаторы могут регистрироваться друг у друга и тоже выступать как потребители услуг транспортного протокола, т.с. строя сложные топологии, включая даже работу через разные физические среды приёма/передачи, но пока этого не требовалось.
В итоге математика примерно такая. В нашей сети есть ПК, на котором поднят VPN и работает сервер транспорта. Наш инженер где-то в нашей сети запускает тест на исполнение. Стартует виртуальный тестер, ищет сервер транспорта, регистрируется у него и т.о. получает возможность взаимодействовать с любым другим зарегистрировавшимся узлом. Одним из таковых является транслятор протоколов, который запущен на той стороне VPN и тоже зарегистрировавшийся как некий виртуальный тестер. Тест упаковывает (точнее это делают комона, у тестов простой и удобный API для этого) протокол взаимодействия с железкой в пакеты и посредством транспорта отправляет транслятору протоколов. Тот посредством маршрутизации через сервер проходит через VPN и принимается транслятором уже в той сети. Транслятор его... внезапно... транслирует из нашего протокола в протокол модели со стендом, ну, UDP который, и т.с. осуществляет воздействие на стенд. Как оно там дальше, нам уже не интересно, однозначно лишь, что результаты от железки проходят весь этот путь в обратном порядке до теста. Все лицензии по порядке, реал-тайм где надо выдержан, никто под несвоё ничего не адаптирует, все счастливы.
https://forum.sources.ru/index.php?showtopic=421430&view=findpost&p=3847305
