Стандарт OPC UA дает возможность создать внутри источника данных (например контроллера) модель прикладных данных, с которой может взаимодействовать другое ПО (например SCADA) по стандартному для OPC UA протоколу. Протоколы могут быть разные, обычно используется бинарный на базе TCP/IP.
В простейшем случае под моделью данных OPC UA можно рассматривать дерево тегов разного типа, разложенные по группам - как это было в старом OPC DA на базе технологии СОМ. Но в общем случае модель данных OPC UA может быть сложнее, чем в OPC DA.
Про конкретную предметную область OPC UA конечно ничего не знает - эта задача уже решается инженером, который, например, настраивает контроллер. И смысл тут в том, что тот, кто будет принимать данные - сможет это сделать, потому что тоже поддерживает стандарт OPC UA.
Сравнивать OPC UA и MQTT нет никакого смысла - это протоколы разного уровня. Для формата MQTT нет никакой стандартизованной прикладной модели для передачи телеметрии - он есть просто передача бинарного пакета произвольного формата. Есть решения, в которых для передачи сообщений OPC UA используется протокол MQTT как транспорт.
Было бы полезно узнать про особенности конкретных серверов OPC UA, вдруг встретятся в проектах. Примеры скриншотов из UaExpert про то как разные сервера представляют свое адресное пространство - уж точно было бы полезнее и интереснее, чем представленные картинки сейчас. Про медленность работы с 2000 переменными, например - ну тут уж точно надо было бы привести описание что это за сервер OPC UA, компьютер или контроллер, с какой мощностью, какой возникал поток изменений от сервера.
Я бы ожидал инженерную статью, с иллюстрациями всего описанного, хотя бы частично. А сейчас - нет ни одной картинки по существу, и пока текст изложения напоминает беседу в курилке. Хотя потенциал проглядывается, и можно было бы усилить все изложенное реальными примерами.
Согласен с другими комментариями - ценность статьи практически нулевая, потому что нет ничего конкретного, одни общие слова. А можно было бы сделать гораздо насыщеннее, привести список серверов, клиентов, скриншоты.
Информация
В рейтинге
6 042-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Архитектор программного обеспечения, Разработка SCADA & SoftLogic
Стандарт OPC UA дает возможность создать внутри источника данных (например контроллера) модель прикладных данных, с которой может взаимодействовать другое ПО (например SCADA) по стандартному для OPC UA протоколу. Протоколы могут быть разные, обычно используется бинарный на базе TCP/IP.
В простейшем случае под моделью данных OPC UA можно рассматривать дерево тегов разного типа, разложенные по группам - как это было в старом OPC DA на базе технологии СОМ. Но в общем случае модель данных OPC UA может быть сложнее, чем в OPC DA.
Про конкретную предметную область OPC UA конечно ничего не знает - эта задача уже решается инженером, который, например, настраивает контроллер. И смысл тут в том, что тот, кто будет принимать данные - сможет это сделать, потому что тоже поддерживает стандарт OPC UA.
Сравнивать OPC UA и MQTT нет никакого смысла - это протоколы разного уровня. Для формата MQTT нет никакой стандартизованной прикладной модели для передачи телеметрии - он есть просто передача бинарного пакета произвольного формата. Есть решения, в которых для передачи сообщений OPC UA используется протокол MQTT как транспорт.
Было бы полезно узнать про особенности конкретных серверов OPC UA, вдруг встретятся в проектах. Примеры скриншотов из UaExpert про то как разные сервера представляют свое адресное пространство - уж точно было бы полезнее и интереснее, чем представленные картинки сейчас. Про медленность работы с 2000 переменными, например - ну тут уж точно надо было бы привести описание что это за сервер OPC UA, компьютер или контроллер, с какой мощностью, какой возникал поток изменений от сервера.
Я бы ожидал инженерную статью, с иллюстрациями всего описанного, хотя бы частично. А сейчас - нет ни одной картинки по существу, и пока текст изложения напоминает беседу в курилке. Хотя потенциал проглядывается, и можно было бы усилить все изложенное реальными примерами.
Согласен с другими комментариями - ценность статьи практически нулевая, потому что нет ничего конкретного, одни общие слова. А можно было бы сделать гораздо насыщеннее, привести список серверов, клиентов, скриншоты.