Сервис-ориентированные системы реального времени

Урок с монолитными системами управления крейсеров «Тикондерога» не прошел для их разработчиков даром. Следующая модификация боевой информационно-управляющей системы (БИУС) «Иджис» (Aegis) была реализована в соответствии с принципами сервис-ориентированных архитектур. Такой подход позволил не только создать самую эффективную корабельную систему управления оружием[20], но и адаптировать ее под разные типы кораблей (система установлена на ста с лишним кораблях семи типов), а также проводить ее модификации.

Разработанное фирмой Real-Time Innovations (RTI) промежуточное программное обеспечение успешно использовано не только в БИУС «Иджис», но и на множестве морских, авиационных и беспилотных платформ (см. рис. 22). Всего RTI принадлежит более 70% рынка связующего программного обеспечения для распределенных систем реального времени[21].

Удачные технические решения, отработанные на множестве приложений, в 2004 году были специфицированы в виде открытого стандарта DDS[22] (Data Distribution Service), который принят Министерством обороны США в качестве обязательного для программ ВМС OACE (Open Architecture Computing Environment), Армии – FCS (Future Combat Systems) и др. Упомянутые программы предусматривают тесное информационное взаимодействие практически всех боевых единиц посредством цифровой сети.

Эсминец Raytheon DDG-1000 БИУС Aegis Экспериментальное судно Sea SLICE

Самолет ДРЛО E-2C Hawkeye Самолет ДРЛО E-3 Sentry Истребитель F-35 JSF

БПЛА Predator Робот RoboScout Подводный аппарат Bluefin 9

Какие же причины способствовали столь успешной реализации и применению DDS?

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

Не менее важны архитектурные решения, заложенные в стандарт. В DDS использована децентрализованная сервис-ориентированная архитектура, обеспечивающая слабую связность между компонентами. Децентрализация и слабая связность повышает живучесть и устойчивость системы в случае выхода из строя отдельных ее компонент. В таких случаях переконфигурация производится автоматически непосредственно во время работы. Кроме того, децентрализация снимает ограничения по пропускной способности центрального сервера (его просто нет в отличие, например, от рассмотренной выше ESB), что позволяет эффективно масштабировать систему.

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

Ключевое допущение состоит в том, что система строится в соответствии с информационно-центрическим (data-centric) дизайном, в отличие от традиционных технологий типа «удаленный объект» или «клиент-сервер»[23]. Фундаментальным понятием DDS является информационная модель системы. В соответствии с данной моделью, единицы циркулирующей в системе информации (т.н. topics) строго типизированы (специфицируются в виде структур данных с помощью языка интерфейсов IDL) и имеют уникальные имена[24].

Все компоненты распределенной системы взаимодействуют друг с другом посредством заранее зарегистрированных в системе единиц информации. Взаимодействующие компоненты разделяются на поставщиков и потребителей информации (шаблон «издатель/подписчики»). Формат информации должен быть известен компонентам заранее, а параметры обмена могут изменяться и уточняться позже – на этапе эксплуатации.

Принципиально, что ни потребители информации, ни ее поставщики не должны знать ничего друг о друге. Наиболее подходящего поставщика для конкретного потребителя DDS подбирает автоматически во время функционирования. Похожее взаимодействие происходит в системах спутниковой навигации. Спутники предоставляют свою информацию в одностороннем порядке, не зная, кто и как будет ее потреблять. В свою очередь навигационные приемники используют в качестве поставщиков информации те спутники, которые в данный момент находятся в зоне их видимости. Разница состоит в том, что в случае DDS подбор наиболее подходящих поставщиков производит не потребитель, а связующее ПО. Для подбора конкретного поставщика DDS использует дополнительную информацию – т. н. параметры качества обслуживания (QoS – Quality of Service), которые потребители и поставщики указывают системе заранее. В системе предусмотрено более 20 параметры QoS: темп поступления информации, приоритетность, допустимые задержки, возможность (или невозможность) пропуска некоторых данных и т. п.

Эффективность рассмотренного способа взаимодействия позволяет обеспечивать минимально возможные задержки поступления информации и удовлетворять очень жестким требованиям реального времени (микросекунды, десятки микросекунд); автоматизировать взаимодействие сотни приложений; масштабировать систему до тысячи компьютеров.

Для сравнения рассмотрим традиционные модели взаимодействия компонент системы «удаленный объект» или «клиент-сервер». В этих моделях связи клиенты устанавливают связь непосредственно с серверами и взаимодействуют с ними по типу «точка-точка». Взаимосвязи в подобных системах продемонстрированы на примере самолета ДРЛО E-2C Hawkeye[25] (см. рис. 23).

Структура системы напоминает антипаттерн «Спагетти». Кроме того, данная структура должна быть статичной, серверы всегда доступны, клиенты должны знать, где располагаются серверы, когда и в какой последовательности можно посылать им запросы, взаимодействие компонент синхронно (запрос/ответ). Подобный «серверо-центрический» дизайн делает систему сильносвязанной, монолитной. Добавление новых потоков данных (красные линии) или локальные изменения могут привести к неработоспособности всей системы.

Традиционная объектно-ориентированная концепция скрывает состояние объекта (удаленного объекта, сервера) за его функциональным интерфейсом. Хотя состояние скрыто, но оно неявно подразумевается. Нужно как-то узнать инициализирован объект или нет, в каком режиме он функционирует и пр. В зависимости от режима нужно правильно сформировать запрос. Именно такой стиль навязывают технологии RPC, CORBA, EJB и пр. Ситуация существенно усложняется, когда в подобном стиле взаимодействуют несколько объектов.

В информационно-центрических системах наоборот – данные выносятся во главу угла, а объекты и их методы скрываются. Компоненты взаимодействуют не между собой, а со связующим ПО. Добавление новых компонент и/или связей практически не влияет на соседние компоненты (см. рис. 1). С применением DDS структура программного обеспечения самолета E-2C Hawkeye упорядочилась следующим образом (см. рис. 24).

Преимущество информацинно-ориентированной системы рассмотрим на упрощенном примере зенитно-ракетного комплекса (рис. 25). Пусть комплекс оснащен несколькими радиолокационными станциями (РЛС) и несколькими батареями зенитных управляемых ракет (ЗУР). Их координацию традиционно обеспечивает командный пункт (КП).

Выход из строя батареи ЗУР или одной из РЛС несколько снижает эффективность комплекса, но не сводит ее к нулю, поскольку командный пункт адаптируется под ситуацию. Если же будет выведен из строя командный пункт, то весь комплекс перестанет функционировать. Другими словами, централизованная система более уязвима. Кроме того, пропускная способность командного пункта ограничена некоторым максимальным числом ЗУР и РЛС.

Перечисленных недостатков лишен комплекс ПВО, построенный по правилам DDS (см. рис. 26).

РЛС (поставщики информации) предоставляют свои измерения во всеобщее использование, не зная, кому они предназначаются. Батареи ЗУР (потребители) используют наиболее подходящие из доступных измерений РЛС. Выход из строя любого компонента не приводит к потере боеспособности комплекса. Инфраструктура также трудноуязвима в силу своей децентрализованости (могут использоваться также обходные, дублированные, резервные каналы обмена и т.п.).

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

Оперативную информацию могут поставлять не только РЛС комплекса, но и другие источники: разведывательные аппараты, корабли, спутники и пр. Аналогично могут выбираться наиболее подходящие системы поражения для уничтожения обнаруженных целей: авиация, артиллерия и т.д. Подобное сетевое взаимодействие всевозможных боевых компонентов является главной особенностью разрабатываемой в США «сетецентрической» боевой системы будущего (рис. 27).

Для реализации подобной глобальной системы необходимо интегрировать не только отдельные компоненты, но и целые системы (система систем). Для этой цели DDS предусматривает простые и эффективные инструменты. Например, чтобы воспользоваться информацией соседней системы нужно «подписаться» на нее в качестве одного из потребителей и распространить эту информацию в своей системе в качестве поставщика данных. Имеются также возможности автоматического преобразования данных в нужный формат (например, перевод из одной системы координат в другую и пр.).

Хотя DDS и предоставляет важные средства для подобных систем, но этих средств явно недостаточно. Разработка систем подобного масштаба требует привлечения множества технологий и стандартов. На рис. 28 продемонстрирована многоуровневая архитектура глобальной информационной инфраструктуры армии США.