Serhioormano, мы понимаем о чем Вы говорите, но пока не видим причин (и подходящей реализации) по которым пользователи сейчас стали бы использовать MQTT средствами скада. Давайте для лучшего понимания рассмотрим следующую ситуацию... Допустим мы внедряем в Simple-Scada поддержку MQTT и у Вас появляется возможность подключиться к любому MQTT серверу, подписаться на любое количество тем, а также публиковать данные в любую тему средствами скада. После того как Вы подписались на тему скада начнёт принимать все данные, которые публикуются в этой теме. Мы для этого можем выделить, например, отдельный скрипт, который будет вызываться, когда в теме появились новые данные. Например кто-то опубликовал в теме сообщение "Привет мир!" и в скаде тут же будет вызван скрипт следующего вида:
procedure OnPublish(ATopic, AData: string);
begin
// здесь Вы можете как угодно обработать данные
end.
, где ATopic это название темы с которой пришли данные, а AData это сами данные. А если кто-то публикует в тему значение Температуры и Давления в виде такой JSON-строки:
'{ "temperature": 27, "pressure": 1 }';
, то нужно будет выполнить парсинг этой строки и полученную температуру вывести в поле температуры, а давление в поле давления. Т.е. обработка данных ложится на разработчика SCADA-проекта. Мы считаем, что по этой причине большинство пользователей откажутся от использования MQTT, особенно в больших проектах.
Тогда можно рассмотреть второй вариант: публиковать значение каждой отдельной переменной в отдельную тему. И мы будем знать, что в теме просто публикуются значения, например 5, 12, 2, 34 и т.д., их можно сразу использовать, без необходимости уникальной обработки, причем это можно реализовать на уровне скады. Пришло новое значение значение в тему, а скада взяла его и отобразила там где нужно. Но если для Вас такой подход подойдёт, то что скажут другие пользователи? Одним нужно будет получать не только значение, а "значение + отметка времени". Другим нужно будет "значение + качество переменной" и т.д.. А кто-то захочет то же самое, но в другой последовательности "качество переменной + значение". Такие данные скада автоматически распознать не сможет и подойдет только первый способ с "ручной" обработкой данных. В результате в скаде будет какой-то стандартный формат, который она может принять и автоматически рассортировать и нужно будет либо подстраиваться под него и не публиковать данные в другом формате, либо использовать "ручную" обработку. В такой ситуации пользователи действительно продолжат использовать стандарт OPC, который содержит всё необходимое (каждый OPC-тег несет в себе большое количество данных. Помимо, значения, отметки времени и качества это: тип данных, права доступа, частота опроса, описание, единицы измерения, четыре граничных значения, мертвая зона и т.д.) и в котором всё это грубо говоря "обрабатывается" автоматически.
Ни понимаю почему не ввести новый тип данных JSON и просто парсить его и превращать в обхект. Допусти я подключился переменной sensor_1 к топику и там { "temperature": 27, "pressure": 1 }
Все можно сделать средствами СКАДА. Добавил переменную JSON, и потом добавил под-переменные или свойства и определил их типы. Или можно сделать мета-JSON для такой переменной. Например.
[{
"name": "temperature",
"type": "float",
"sign": "C",
"minimum": "30.2"
},{
"name": "pressure",
"type": "int",
"sign": "Pa",
"minimum": "120"
}]
JSON сам по себе уже стандарт. Свойсвто : Значение. Ведь не важно их очередность в документе. И потом если я отправляю данные в тему, то я не буду использовать JSON а просто отправлю чистые данные. JSON нужен для того что бы получать данные с устройств готовых уже сделаных производителям и там уже не поменяешь что ты хочешь получить. Он просто выдет тебе что прописано. В этом случае от все равно фиксированый.
Короче выход можно найти.
Эмм... можете прикинуть здесь содержимое типичного топика которое должна "увидеть" скада, для системы газонополива в 10 зон, которые должны запускаться в определенное время, на х минут, в определенный день недели.
О чем вы говорите? При чем тут 10 зон и ден недели? Это решает программа. MQTT это просто альтернатива передачи данных. И потом для ответа нужно понять кто, что передает. Зачем вообще ей что то видеть? Просто запустите полив на 10 зон раз в неделю, зачем вам что то принимать? Если вы хотите учитывать текущую влажность например, берете датчик влажности, подключаете к контроллеру, и с контроллера шлете эти данные в топик МКТТ а в скаде принимаете, и берете эти данные в расчет.
Бонусом для самого протокола учтите, что кроме скады еще есть визуализация контроллера и 2 панели, с которых могут задаваться те-же параметры одновременно.
Ну в этом и прелесь МКТТ. Если есть контроллер который например получает данные от датчика влажности, применяет фильтра, делает предварительно обсчет, и публикует в топик МКТТ, то и визуализиции, и скады, все смогут подписаться на этот топик, и если нужно изменить то и постить в этот топик.
А еще мне кажется что вы так и не поняли что такое ОРС вообще. ОРС, изначально, вовсе не протокол СВЯЗИ. Это внутренний протокол виндового DDE.
Как в не поймете. Мне все равно что это с технической точки зрения, протокол, буфер, поток, сокет или еще что. Мне вообще нет до этого дела с той перспективы с которой я говорю. Как ОПС решает технически совю задачу это не суть. Суть в том что МКТТ и ОПС решают одну и туже задачу. Они совершенно разные, но сделаны для одного и тогоже и занчит могут друг друга заменить. Это как поезд и самолет. Они вообще по разным средам передвигаются, по земле и по воздуху, разные технические решения, но решают оду и туже задачу, перемещать объекты в пространстве.
И я не спорю что и у того и у другого есть свои приимущества и недостатки, один быстрей, но требует больше ресуров, качественней запчастей, другой дольше но проще в ослуживании и т.д.
По этому ОБА имеют право на существование.
Я не говорю что нужно убрать ОПС. Да пользуйтесь вы ей на здоровье сколько хотите.
Моя идею в том что бы ДОБАВИТЬ МКТТ к тому что уже есть. Надесь моя позиция стала понятней. Пожалйста, не надо мне больше расказывать о том какой ОПС хороший. Я это знаю. Я согласен. Я им сам пользуюсь. Но сегодня мне этого мало. Мне нужно поддержка МКТТ.
Двайте я привиде пример почему. МКТТ кроме устрйоств еще можно использовать в приложениях. Например у меня вебсайт, я на сайте нажал кнопочку и отправил данные в тему, а тема взяла и выключила выход на контроллере. Как такое сделать с ОПС? Как мне из приложения, отправлять данные в ОПС Серевер если мое приложение размещено в облаке вообще? Ипользовать HTTP не всегда безопастно да и не всегда вобще допустимо по тойже причине.
Тоже самое и обратно. Допустим мой ПЛК, получил данные с термодатчика и оправил в топик, мой сайт сможет это прочесть и отобразить а так же скада, визуализация, другой контроллер или несколько конроллеров. Не только сайт. Например я пишу мобильное приложение, для умного дома.
Ни понимаю почему не ввести новый тип данных JSON и просто парсить его и превращать в обхект.
Теперь мы с Вами, наконец, подошли к самой сути. Хоть тип, хоть процедуру для любой ручной обработки JSON строки, всё можем добавить. Представьте, что это все есть. Что дальше с этими данными нужно делать? Расставлять каждое значение по полям? Так, например:
begin
Field1.Text := sensor_1.temerature;
Filed2.Text := sensor_1.pressure;
Field3.Text := sensor_1.timestamp;
end.
Может быть это подойдёт для проектов на 200 тегов, но если тегов 1000 и больше, то разработка проекта превратится в написание таких расстановок. Без этого можно обойтись только если в каждую тему публиковать значение переменной и ничего лишнего (т.е. не использовать ту самую гибкость MQTT, а наоборот избавиться от неё) и сразу выводить это значение в связанные поля. Вы, возможно, так и сделаете. А остальные пользователи, у которых в тему данные публикуются в своём формате (а таких случаев, судя по всему, большинство), они должны использовать ручную расстановку?
А в редакторе нам ничего неизвестно о структуре JSON-строки, мы даже не подключены к MQTT-серверу. Чтобы узнать структуру нужно подключиться к MQTT серверу из редактора и дальше как-то получить информацию о тегах и структуре JSON-запросов.
Да нет же!
Я же говорю, можно сделать отдельный праметер переменной для JSON это описание структуры можно пока просто в текстовом формате.
[{
"name": "temperature",
"type": "float",
"sign": "C",
"minimum": "30.2"
},{
"name": "pressure",
"type": "int",
"sign": "Pa",
"minimum": "120"
}]
Допустим у меня есть кнопка AWS. Я знаю что она шлет в свой топик такой JSON.
{
"click": "SINGLE",
"battery": "3654mv",
"DSN": "GFD45J7GWE54K8"
}
Ну тогда мы создаем переменную aws_button, которая подключается к топику. Ведь с МКТТ одна переменная = один топик. Я знаю что мне придет вот такой JSON.
Теперь когда я привязываю переменную к объету я могу сам дописать свойство например aws_button.click тоже в скриптах.
Или можно разрешить выбор доступных свойств. В настроках этих переменных я вписываю в параметре структуры переменных
[{
"name": "click"
},{
"name": "DSN",
"type" : "string"
}]
И все а battery я не пиши потому что не буду это использовать. Теперь у меня будут доступны дополнительный выбор, выбрал свойство объекта переменная, раскрыл список, выбрал переменную, и новое это вышел подсписок с двумя свойствами click и DSN.