xml2opc

Первоначально опубликовано serg-deev 1) I-7188E - XML - Internet Exlorer; 2) CPU686E - RTOS - XML - Web client/server; Формат XML позволяет легко обмениваться с БД. А для связи со SCADA-системами есть свой OPC/XML.

Ваше видение этого вопроса в такой постановке кажется несколько упрощенным.
Вообще это конечно здорово - договорится всем о едином формате XML для передачи данных между контроллерами и верхним уровнем. Но вот именно - во первых нужно договорится. Без этого любой XML - всего лишь решение одного из разработчиков, с которым остальные необходимы будут находить точки соприкосновения. В этом отношении это ничуть не лучше протокола Модбас.

То, что для просмотра данных можно сразу использовать браузер - не думаю, что в серьезных применениях это можно посчитать плюсом. Быстро промониторить модуль в лаборатории - может быть. Даже что-то настроить в модуле - тоже может быть. Но не для реальной работы и сбора данных с этого модуля в условиях применения в реальном проекте.

Для генерации XML требуется большие ресурсы, чем для реализации протокола а-ля Модбас. В случае малых контроллеров их может оказаться маловато, особенно если контроллер и без того забит задачами под завязку. И при обмене на скоростях до 9600 бод - радиомодемы, GSM-модемы - хочется иметь как можно более оптимизированный траффик, и XML тут явно проигрывает на порядок.

То есть в общем XML - это хорошо. Но все наработанные технологии еще будут очень долго использоваться, и отказываться от них смысла нет. И еще не скоро наличие поддержки XML будет считаться обязательным требованием для элементов автоматизации.

Первоначально опубликовано sergew Как я понял говорилось об использовании контроллеров с Ethernet интерфесом, тогда причём тут последовательная связь и  реализация протоколов под последовательную связь?

Говорилось просто о использовании XML. Обычно это подразумевает передачу данных через TCP/IP, согласен. Но ничто не мешает использовть конвертеры, GPRS-модемы, промежуточные мосты и т.п.

Первоначально опубликовано sergew На счёт избыточности трафика XML тоже не совсем понятно, также как в  MODBUS/TCP в XML используется заголовке используется служебная информация только и всего.

Пакет с данными в формате XML должен быть самодостаточным, иначе зачем он нужен? То есть у него полностью будет описано, какие данные он передает. По моему - это будет заведомо больший размер, чем пакет бинарных данных.

Первоначально опубликовано sergew Т.к. у того же I-7188E памяти 512Кб (это целая прорва памяти), то сформировать ответ в памяти контроллера и передать его клиенту задача тривиальная.

Если все, что делать с этим контроллером, это читать его встроенные входа - тогда памяти достаточно. А вот если нагрузить его полноценной исполнительной системой, содержащей библиотеку алгоритмов, драйвера опроса разнотипных удаленных модулей ввода-вывода, счетчиков, добавить функции ведения архивов, связь по модему - тогда этой памяти остается совсем не много.

Я не противник XML. Наоборот - это здорово! Но без стандартизации - не нужно. Просто для отображения в браузере - тоже не нужно. Для интеграции со своей системой нам будет без разницы, что расшифровывать - самопальный бинарный протокол, или XML. А вот как будет стандарт XML - тогда да.

Господа !

Давайте сначала разберёмся что такое XML:

""XML (Extensible Markup Language) - это стандарт, формат и язык обмена структурированными данными. Для чего он придуман? Дело в том, что по мере развития информационных технологий встала проблема взаимодействия программ, создаваемых разными компаниями и работающими в разных областях. Например, бухгалтерских, банковских, складских, Интернет-магазинов и др.

Именно для решения этой проблемы и предназначен новый стандарт XML, позволяющий по единым правилам записывать данные вместе с информацией об их структуре.""

Так, что XML это больше всё таки верхний уровень - АСУП и то, что OPC Foundation выпустит спецификацию OPC/XML, это как раз для ещё более плотной интеграции АСУП и АСУТП. "Кидать" данные из Скады в 1с или в базу или интернет-портал, тогда намного упростится, то есть, если СКАДА подерживает спецификацию OPC/XML, то с контроллера она получает данные по ОРС,а в 1с или какую то MES систему передаёт по XML.

Если для контроллера разрабатывать свой OPC/XML драйвер, то тогда проще передавать данные в MES систему или 1с минуя СКАДу, но тогда сам контроллер должен преобразовывать, масштабировать и т.д. конкретный сигнал с датчика или это должен делать драйвер ? А если обрабатывать сигнал в приложении верхнего уровня, например в 1с или интернет экспловером, не получится ли это попыткой превратить 1с или интернет экспловер в СКАДА систему? 

C OPC/XML все конечно же будет проще, но не решит одной проблемы- архивация в режиме РВ. В данный момент просто в MES нарямую закидывать данные негуманно для самой MES (точнее, для ее реляционной БД), т.к. скорость архивации с частотой 1 с или 100 мс....

В общем, лучший вариант - сервер БДРВ. И MESoм забирать данные уже посредством стандартных методов (их много, в т.ч. ОРС) Только MES должна поддерживать этот стандарт (ОРС который).

 

Только при чем здесь 1С - не пойму

http://v8.1c.ru/overview/ObmenMain.htm?printversion=1