В чем разница между DDS и SOME/IP?

Question

SOME/IP - это промежуточное автомобильное решение, которое можно использовать для управляющих сообщений. DDS также является автомобильным промежуточным программным обеспечением для связи. Я хочу знать, в чем разница между ними? и почему и когда я должен выбрать один из них?

Answer 1

И SOME/IP, и DDS позволяют распределенным приложениям обмениваться данными, используя как шаблон публикации / подписки, так и шаблон запроса / ответа на обслуживание (RPC). Но есть и существенные различия.

НЕКОТОРЫЕ / IP были специально разработаны для автомобильной промышленности. SOME/IP - это набор спецификаций, разработанных в рамках AUTOSAR, которые описывают протокол сериализации, обнаружение службы и преобразователь для интеграции с Classic AUTOSAR.

DDS (служба распространения данных) предназначена для более широкого промышленного домена IoT. Это семейство открытых стандартов, опубликованных Группой управления объектами (OMG). Он был специально разработан для распределенных систем реального времени и используется во многих отраслях, включая транспорт, энергетику, медицинские системы, промышленную автоматизацию, аэрокосмическую и оборонную промышленность и т. Д. Существует много независимых реализаций, как коммерческих, так и с открытым исходным кодом. Первая спецификация в семействе DDS была выпущена в 2004 году и с тех пор выросла до набора из 12 стандартов DDS, которые включают в себя стандартный проводной протокол (DDS-RTPS), API-интерфейсы (DDS-PSM-CXX, DDS-PSM-JAVA). и отображения из IDL в C, Ada и т. д.) система типов (DDS-XTYPES), шаблоны доставки данных (DDS для ориентированной на данные публикации-подписки и DDS-RPC для запроса-ответа), безопасность (DDS-SECURITY) описание системы (DDS-XML), моделирование данных (IDL) и шлюзы к другим коммуникационным инфраструктурам (DDS-WEB, DDS-OPCUA и DDS-XRCE).

Технически и концептуально есть много различий, поэтому я разделил их на отдельные категории:

• Шаблоны общения
• Интерфейсы прикладного программирования (API)
• Сетевые Транспорты
• Подход к безопасности
• QoS
• Использование из других спецификаций

Шаблоны общения

НЕКОТОРЫЕ / IP можно рассматривать как объектно-ориентированную сервис-ориентированную архитектуру. Информация предоставляется системе путем создания экземпляров сервисных объектов, к ним обращаются клиентские приложения, которые создают соответствующие "прокси-объекты" для каждого экземпляра сервиса, к которому они хотят получить доступ. Клиентские приложения подписываются на информацию, присоединяя прокси-объект к объекту службы и используя его для мониторинга событий и изменений полей. Они также могут вызывать операции над объектом службы для выполнения удаленных вызовов процедур или чтения / записи определенных полей.

DDS в основном предоставляет несвязанную, ориентированную на данные модель публикации подписки. Также называется шаблоном "данных". Приложения участвуют в DataBus peers и могут публиковать / подписывать любые данные (идентифицированные по имени DDS-темы), а также вызывать или реализовывать любую операцию сервиса (идентифицированную по имени DDS-Service). DDS полностью одноранговый - он не требует посредников в середине. Существует механизм обнаружения, который постоянно работает для обнаружения совместимых приложений издателя и подписчика, которые ссылаются на одно и то же имя Темы; как только они обнаружены, они начинают напрямую обмениваться информацией. Приложения подписчиков могут указывать фильтры (контентные или на основе времени) для указания информации, которую они хотят получить. Фолтинг может происходить на стороне издателя, чтобы уменьшить объем информации, передаваемой по проводам.

Существенная разница между DDS и SOME/IP заключается в том, что с DDS приложение не должно привязываться к конкретным реализациям сервисов. Он просто ссылается на Темы и Сервисы и может полностью прозрачно общаться один на один или один ко многим без каких-либо изменений в коде приложения. Он должен отслеживать наличие отдельных пиров или управлять новыми объектами в ответ на присоединение или отъезд пиров. Все это обрабатывается автоматически. В этом смысле он намного более динамичен, чем SOME/IP.

Интерфейсы прикладного программирования

SOME/IP не определяет стандартный API, реализации обычно предоставляют API C++, но они не переносимы между реализациями. Однако обычно SOME/IP используется как часть AUTOSAR, который определяет некоторые стандартные API.

DDS имеет стандартные API для нескольких языков. Для C++ и Java они включены в спецификации DDS-PSM-JAVA и DDS-PSM-CXX. Стандартные API C и ADA основаны на спецификациях IDL и C и ADA. Кроме того, существуют специфичные для производителя API-интерфейсы для C# и других языков. Поэтому обычно возможно портировать приложения DDS и переключаться между реализациями DDS.

Сетевые Транспорты

SOME/IP поддерживает как UDP, так и TCP для передачи данных. В AUTOSAR 4.3 появилась поддержка сегментации полезных данных размером более 1400 байт по UDP. Для надежной связи SOME/IP возвращается к TCP.

DDS использовал проводной протокол, называемый RTPS (публикация в реальном времени), который определен в независимой от платформы модели, которая может быть сопоставлена ​​с различными сетевыми транспортными протоколами. Большинство реализаций DDS (DDS-RTPS) поддерживают как минимум UDP, TCP и разделяемую память. RTPS реализует независимый от транспорта протокол надежности и фрагментации, который работает поверх любого транспорта, включая UDP с многоадресной передачей. Таким образом, с DDS можно делать большие данные и надежные данные по многоадресной UDP. НЕКОТОРЫЕ / IP не могут этого сделать.

Многие реализации DDS предоставляют SDK "пользовательский транспорт", поэтому можно запускать DDS через собственный пользовательский транспорт, не жертвуя ни одной из возможностей и QoS. Это невозможно с SOME/IP, так как транспорт должен реализовывать определенные функции (такие как надежность и фрагментация).

Подход к безопасности

Вообще говоря, НЕКОТОРЫЕ / IP также полагаются на транспорт для безопасности. Таким образом, для безопасного использования становится необходимым запускать по TLS или DTLS.

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

Качество обслуживания Поддержка

SOME/IP предлагает только один параметр Qos "надежность", используемый для выбора UDP по сравнению с TCP. Все остальное должно быть реализовано с помощью пользовательской логики приложения, которая, в зависимости от политики QoS, может быть очень сложной. Кроме того, код уровня приложений не так переносим и требует, чтобы все приложения включали этот код или, по крайней мере, связывали общую нестандартную библиотеку.

DDS предоставляет ряд политик QoS, которые позволяют пользователям декларативно указывать, как осуществляется обмен информацией между издателями и подписчиками. Стандарт DDS определяет более 20 отдельных политик. Эти политики контролируют не только надежность, но и другие аспекты, такие как использование ресурсов, расстановка приоритетов данных, доступность данных и отработка отказа. Например, настройки QoS предоставляют возможность устанавливать крайние сроки для предоставления уведомлений, если издателю или приложению-подписчику не удается отправить или доставить информацию с определенной скоростью; настроить надежность данных так, чтобы они могли быть повторно переданы абонентским приложениям, которые присоединяются после того, как информация была произведена и отправлена; настроить глубину истории приложений издателя и подписчика; развертывать избыточные системы, которые автоматически выбирают один источник из множества на основе уровня владения, настраивать автоматические сообщения о жизнеспособности, чтобы определить, все ли живые удаленные приложения, и выполнять автоматический переход на другой ресурс, когда приложения не реагируют. Вы можете получить намного больше подробностей из раздела 2.2.3 Спецификации DDS или из документации по различным реализациям (см., Например, этот Qos Cheat-Sheet от RTI Connext DDS).

Использование из других спецификаций

НЕКОТОРЫЕ / IP в основном используются AUTOSAR для автомобильной промышленности.

DDS имеет более горизонтальное использование. Это часто используется непосредственно как Платформа Связности. Фактически он был определен Индустриальным интернет-консорциумом (IIC) как одна из "базовых сред связности" для IIoT (см. Документ "Рамки связности промышленного интернета вещей"). Он также используется как часть других стандартов и сред, таких как OpenFMB, ROS2, MD PnP, FACE, и также включен в AUTOSAR Adaptive (начиная с версии 18.03).