Сименс сообщает: https://support.industry.siemens.com/cs ... 1.0_en.pdf
В рамках стандарта Ethernet IEEE 802.1 появилась тема Time-Sensitive Networking (IEEE802.1 TSN), это развитие темы Quality of Service (QoS).
Потребительский смысл:
1. TSN - это незаконченный протокол (базис для других протоколов, также как TCP-протокол).
2. TSN работает на уровне Layer 2 OSI и не основывается на "тормознутом" TCP.
3. TSN определяет резервы и ограничения полосы пропускания для обеспечения передачи данных в настоящем реальном времени.
4. TSN в отличие от PROFINET обеспечивает несколько соединений и законченных протоколов реального времени по одному кабелю.
Вопросы и ответы:
1. Нужно ли специализированное железо? Да, нужны свитчи со специализированными Ethernet-процессорами и т.п. Но в будущем все свитчи и устройства будут поддерживать TSN.
2. Что будет с PROFINET? Сименс будет портировать PROFINET на TSN. С точки зрения пользователя PROFINET IO, RT, IRT, а также пользователей профилей PROFIsafe и PROFIdrive ничего не поменяется, кроме того, что в будущем можно будет применять стандартное Ethernet-TSN-железо.
3. Потребуются новые кабели для TSN? Нет, будут применяться стандартные существующие типы кабелей.
4. Будут новые TSN-устройства совместимы с с существующими? Будут, но надо понимать, что волшебные свойства Ethernet TSN будут заканчиваться как раз в том месте, где установлено старое железо.
5. Могут ли старые устройства перепрошиты на программном уровне, чтобы стать TSN-способными? Если некоторые аппаратные требования TSN реализованы в устройстве, то оно может быть перепрошито для поддержки TSN.
Ethernet реального времени (TSN)
Re: Ethernet реального времени (TSN)
Из этого документа заявлены ещё другие стратегические темы Сименса:
1. На нижнем уровне (на полевом уровне) должен быть PROFINET.
2. На верхнем уровне должен господствовать OPC UA.
3. Нужно отказываться от OPC в пользу OPC UA, чтобы не зависеть от Windows.
4. Нужно отказываться от клиент-серверной реализации OPC UA в пользу публично-подписной (Publish/Subscribe, PubSub) реализации OPC UA. В рамках PubSub публикатор (типа сервер) передаёт данные посреднику, называемому Message Oriented Middleware, не заморачиваясь, какие из подписчиков (типа клиенты) получат эти данные. (Естественно ЦРУ будет скрытым подписчиком. )
5. При работе с облачными сервисами Amazon, Google, Microsoft, IBM, Oracle и т.д. следует применять облачные протоколы MQTT и AMQP (последний только Microsoft).
1. На нижнем уровне (на полевом уровне) должен быть PROFINET.
2. На верхнем уровне должен господствовать OPC UA.
3. Нужно отказываться от OPC в пользу OPC UA, чтобы не зависеть от Windows.
4. Нужно отказываться от клиент-серверной реализации OPC UA в пользу публично-подписной (Publish/Subscribe, PubSub) реализации OPC UA. В рамках PubSub публикатор (типа сервер) передаёт данные посреднику, называемому Message Oriented Middleware, не заморачиваясь, какие из подписчиков (типа клиенты) получат эти данные. (Естественно ЦРУ будет скрытым подписчиком. )
5. При работе с облачными сервисами Amazon, Google, Microsoft, IBM, Oracle и т.д. следует применять облачные протоколы MQTT и AMQP (последний только Microsoft).