В статье рассматривается открытый стандарт DDS (Data Distribution Service) консорциума OMG (Object Management Group) на связующее ПО распределенных систем реального времени. Будут рассмотрены движущие факторы его появления и примеры его применения в оборонных системах, в частности, беспилотных аппаратах и комплексах. Задача этой статьи не глубокое погружение в стандарт, а его основные особенности и преимущества.
Сложные системы реального времени обычно являются «распределенными», т.е. состоят из некоторого числа компьютеров, которые не только сами работают в режиме реального времени, но и обмениваются между собой данными. Также в режиме реального времени. Типичные распределенные системы реального времени – это корабельная система управления, система управления воздушным движением, тренажер (симулятор) и сложная АСУТП. Беспилотные комплексы также относятся к типичным распределенным системам реального времени, в которых есть несколько бортовых подсистем беспилотного аппарата, взаимодействующих между собой, несколько приложений на операторской станции, также взаимодействующих между собой, а, кроме того, существует связь между приложениями аппарата и станции и, возможно, связь с другими пилотируемыми аппаратами и командными пунктами.
Типичные распределенные системы реального времени
Исторически коммуникационные протоколы в таких системах были специализированными под каждое конкретное применение и использовали модель взаимодействия «точка-точка» (point-to-point), в которой каждый узел-источник информации был связан с каждым узлом-приемником информации прямыми связями, реализованными через сетевой стек операционной системы (Рисунок 2). Поскольку сетевые стеки ОС предоставляют только низкоуровневые средства коммуникации, каждый разработчик распределенного приложения был вынужден для упрощения программирования надстраивать над сетевым стеком свое собственное связующее ПО (middleware). При этом затраты на разработку и поддержание коммуникационной инфраструктуры между приложениями были сравнимы с затратами на разработку самих приложений. Проблема частично решалась применением связующего ПО коммерческих производителей (COTS middleware), но отсутствие открытого стандарта на такое программное обеспечение не позволяло интегрировать в одной системе связующее ПО различных производителей.
Модель взаимодействия «точка-точка»
И вот два основных поставщика связующего программного обеспечения для оборонных применений - Real-Time Innovations и Thales, - которые на тот момент уже имели достаточно большое количество экземпляров своих продуктов NDDS (RTI) и Splice (Thales), работающих в боевых условиях, приняли решение о совместной работе. Они образовали в 2001 году рабочую группу в рамках консорциума OMG, который на тот момент уже имел стандарт связующего ПО CORBA (Common Object Request Broker Architecture), предназначенный для корпоративных информационных систем, и пытался его приспособить к системам реального времени. Далее «клиент-серверную» архитектуру CORBA приспосабливать не стали, а занялись новым стандартом DDS с архитектурой «издатель-подписчик», в результате чего в 2004 году появилась спецификация стандарта DDS, который был принят в качестве обязательного в МО США, в частности, в программах ВМС OACE (Open Architecture Computing Environment) и Армии – FCS – Future Combat Systems (Рисунок 3).
Визуальная модель FCS
Модели «клиент-сервер» (client-server) (Рисунок 4) присущи два недостатка при использовании в системах реального времени. Во-первых, трудно обеспечить детерминированное время доставки информации, поскольку производительность «сервера» зависит от нагрузки. А, во-вторых, «сервер» является централизованной точкой отказа (single point of failure), что влияет на надежность коммуникационной инфраструктуры. Кроме этого, если архитектура корпоративных информационных систем хорошо «ложится» в модель «клиент-сервер», то системы реального времени, как правило, одноранговые (peer-to-peer) и «серверов» в них нет.
Модель «клиент-сервер»
Можно, конечно, продолжать использовать и модель «точка-точка», которая и надежна (нет централизованной точки отказа) и детерминирована (отправитель и получатель связаны напрямую), но у нее существуют большие проблемы с маштабируемостью – любое добавление или удаление узла требует модификации связующего ПО, и, как уже было сказано выше, затраты на разработку и поддержание коммуникационной инфраструктуры между приложениями могут стать сравнимыми с затратами на разработку самих приложений.
Почему же модель взаимодействия «издатель-подписчик», а именно ее реализация в стандарте DDS, является и надежной, и детерминированной, и масштабируемой? Суть модели отражена в ее названии: есть производители информации (publishers - издатели), которые публикуют ее, и потребители информации (subscribers - подписчики), которые ее получают (Рисунок 5). Прямо как в обычной жизни: газеты, радио, телевидение и мы - читатели, слушатели и зрители. В отличие от других моделей взаимодействия, в которых в явном виде надо указывать, что, кому и когда послать, модель «издатель-подписчик» анонимная: «издатели» не знают, какие узлы распределенной системы подписаны на их информацию, а «подписчики» не знают, какие узлы являются источниками информации, на которую они подписаны. Это анонимность является основой масштабируемости модели «издатель-подписчик»: реконфигурация узлов не приводит к необходимости переписывать связующее ПО.
Модель взаимодействия «издатель-подписчик»
Надежность и детерминированность информационного обмена обеспечивается наличием в стандарте DDS набора параметров Качества Обслуживания (QoS – Quality of Service), c помощью которых «издатели» и «подписчики» договариваются между собой о наилучшем балансе интересов «подписчика» с возможностями «издателя» по временным и надежностным характеристикам информационного потока между данной парой «издатель-подписчик». Модель «издатель-подписчик» - одноранговая (peer-to-peer) и ее реализация в стандарте DDS не содержит информационных серверов или брокеров, которые являются централизованной точкой отказа (single point of failure). RTI DDS работает в среде операционных систем VxWorks, VxWorks 653, VxWorks MILS, Integrity, LynxOS, QNX, Windows, Linux, Solaris и может использовать в качестве транспортной среды IPv4, IPv6, WAN, разделяемую память (shared memory), шину и коммутируемую структуру (switched fabric). RTI DDS имеет вариант RTI DDS Safety Critical Edition, сертифицируемый по DO-178B. Фирме Real-Time Innovations (RTI) – инициатору и основному автору стандарта DDS –принадлежит более 70% рынка связующего программного обеспечения для распределенных систем реального времени. Связующее ПО RTI DDS имеет множество примеров применения в системах управления морских, авиационных и беспилотных платформ. Наиболее известные из морских применений RTI DDS – Lockheed Martin Sea SLICE и Aegis, Samsung-Thales FFX-I и Raytheon DDG-1000 (Рисунок 6).
Наиболее известные из морских применений RTI DDS
Из авиационных – самолеты дальнего радиолокационного обнаружения E-2C Hawkeye и E-3 Sentry и истребитель F-35 JSF (Рисунок 7).
Наиболее известные из авиационных применений RTI DDS
Вот как выглядела архитектура ПО E-2C Hawkeye до применения DDS (архитектура точка-точка) и после (Рисунок 8).
архитектура ПО E-2C Hawkeye
Связующее ПО RTI DDS имеет ряд успешных применений в области беспилотной техники (Рисунок 9). Это БЛА Predator (General Atomics) и ScanEagle (Insitu), наземный робот RoboScout (BaseTen Systems) и подводный беспилотный аппарат Bluefin 9 (Bluefin Robotics).
Ряд успешных применений RTI DDS в области беспилотной техники
RTI DDS работает в среде операционных систем VxWorks, VxWorks 653, VxWorks MILS, Integrity, LynxOS, QNX, Windows, Linux, Solaris и может использовать в качестве транспортной среды IPv4, IPv6, WAN, разделяемую память (shared memory), шину и коммутируемую структуру (switched fabric). RTI DDS имеет вариант RTI DDS Safety Critical Edition, сертифицируемый по DO-178B.
Демьянов А.В, АВД Системы. Статья с uav.ru.