В чем разница между DDS и SOME / IP? - PullRequest
0 голосов
/ 05 июля 2018

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

1 Ответ

0 голосов
/ 06 июля 2018

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

SOME / 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
  • Использование из других спецификаций

Шаблоны связи

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

DDS в основном обеспечивает разделенную, ориентированную на данные модель публикации подписки. Также называется шаблоном данных. Приложения участвуют в одноранговых узлах DataBus и могут публиковать / подписывать любые данные (идентифицированные по имени 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, так как транспорт должен реализовывать определенные функции (такие как надежность и фрагментация).

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

Вообще говоря, SOME / 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 от RTI Connext DDS ) .

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

SOME / IP в основном используется AUTOSAR для автомобильной промышленности.

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

...