Система диспетчеризации и автоматизации, Идея проекта Опции

[Owl Electronics]

Всем доброго времени суток. Пришла идея для реализации небольшого проекта по удаленному измерению и диспетчеризации через Интернет. В качестве первого опыта есть мысль запустить в производство такое устройство (дабы не давать внешних ссылок, приложил в виде скриншота).



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

Буду благодарен за любые советы.

Спасибо.



Сообщение отредактировал Owl Electronics - Jul 19 2018, 20:40

[Owl Electronics]

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

Софт будет организован как некий dashboard - рабочий стол оператора, на который можно добавить любое количество устройств по их IP-адресам, читать в реальном времени показания и выводить их куда-либо.
Кроме того, рассматривается интеграция с сервисами, к примеру, freeboard.

Опытный образец уже есть и работает, правда, выглядит не очень. Софт тоже в первой минимальной версии имеется.

По функционалу - в данный момент взято всего по минимуму для упрощения и удешевления. Изначальный вариант предполагал еще и четыре аналоговых канала управления (была идея сделать некий регулятор с несколькими характеристиками выходных напряжений на выбор). Есть еще желание и, наверное, необходимость добавить несколько цифровых каналов I2C/SPI, но как их организовать - не совсем понятно. Добавлять драйверы на все возможные существующие датчики разве что.

[mantech]

Софт будет организован как некий dashboard - рабочий стол оператора, на который можно добавить любое количество устройств по их IP-адресам, читать в реальном времени показания и выводить их куда-либо.
Кроме того, рассматривается интеграция с сервисами, к примеру, freeboard.

Будете свою SCADA делать??
Ваше устройство - это просто периферийный блок сбора данных, собственно поэтому, такие протоколы, как MODBUS (TCP) должны быть обязательно. Всякие вебморды - это уже вторичное дело...
Причем для модбаса желательно иметь гальваноразвязанный RS-485, тогда это уже будет выглядеть более профессионально.

Сообщение отредактировал mantech - Jul 23 2018, 10:42

[Owl Electronics]

Будете свою SCADA делать??
Ваше устройство - это просто периферийный блок сбора данных, собственно поэтому, такие протоколы, как MODBUS (TCP) должны быть обязательно. Всякие вебморды - это уже вторичное дело...
Причем для модбаса желательно иметь гальваноразвязанный RS-485, тогда это уже будет выглядеть более профессионально.

Спасибо, принято.

[vldmr86]

Спасибо, принято.

Внесу свои 5 копеек. Нам часто попадается требование в тендерах - это GSM канал и источник резервного питания на несколько минут. Смысл этой опции в том что мониторинг удаленного объекта часто отваливается и причина неизвестна. Туда идут ногами и чаще всего или включают рубильник или устраняют другую аварию с питанием. Так вот этот резервный источник позволяет отправить последнюю SMS типа питание пропало. Я сейчас тоже отвалюсь. Аккумуляторы не приветствуются ввиду необходимости обслуживания. Предпочитают суперконденсаторы.

[Owl Electronics]

Внесу свои 5 копеек. Нам часто попадается требование в тендерах - это GSM канал и источник резервного питания на несколько минут. Смысл этой опции в том что мониторинг удаленного объекта часто отваливается и причина неизвестна. Туда идут ногами и чаще всего или включают рубильник или устраняют другую аварию с питанием. Так вот этот резервный источник позволяет отправить последнюю SMS типа питание пропало. Я сейчас тоже отвалюсь. Аккумуляторы не приветствуются ввиду необходимости обслуживания. Предпочитают суперконденсаторы.

Это только там, где GSM уже имеется как канал обмена, или в любых?

[mantech]

Это только там, где GSM уже имеется как канал обмена, или в любых?

Желательно, чтоб у клиента была возможность недорогого апгрейда модемом, если ему это нужно. Во все контроллеры я бы ставить модемы не стал...

[AlexandrY]

Желательно, чтоб у клиента была возможность недорогого апгрейда модемом, если ему это нужно. Во все контроллеры я бы ставить модемы не стал...

Разумней было бы в дивайсах иметь только Bluetooth LE с IPV6.
А уж шлюз беспроводной BLE в GSM/3G/LTE/WiFI/Ethernet найти не проблема.

[mantech]

Разумней было бы в дивайсах иметь только Bluetooth LE с IPV6.
А уж шлюз беспроводной BLE в GSM/3G/LTE/WiFI/Ethernet найти не проблема.

Это ваше мнение, а мне вот оно не нравится, ибо чем меньше всяких "мостов и туннелей" тем надежнее система, раз уж о промавтоматике идет речь.
Простой пример - нет связи с сетью, преинициализирую модем, связи нет - выключу и включу питание встроенным ключем - связь появилась, просто завис модем, а это бывает почем зря... А теперь ваш мост, завис модем в нем или он сам, и что делать, звать мастера чтоб нажал ресет?

Сообщение отредактировал mantech - Jul 24 2018, 17:04

[Atridies]

Это ваше мнение, а мне вот оно не нравится, ибо чем меньше всяких "мостов и туннелей" тем надежнее система, раз уж о промавтоматике идет речь.
Простой пример - нет связи с сетью, преинициализирую модем, связи нет - выключу и включу питание встроенным ключем - связь появилась, просто завис модем, а это бывает почем зря... А теперь ваш мост, завис модем в нем или он сам, и что делать, звать мастера чтоб нажал ресет?

И это одна из причин, почему следует 10 раз подумать прежде чем лезть в тему.

В смысле - у двух одинаковых заказчиков, занимающимися одним и тем же - может быть принципиально разный подход: одним вынь да положь - GSM, другие будут с упорством барана требовать сбор всех данных на локальный сервак, который будет подключаться к LAN. Одним - нужен Modbus нерезервируемый, другим - МЭК101 да с резервом, третьим - MЭК104. Кому-то надо свой протокол своей скады, а кто-то прикроется OPC UA. Ну и как Вы понимаете, разные протоколы и функции - требуют разного железа. И помножьте это на количество систем: АСУЗ, АСУ ТП, ЖКХ, ССПИ, просто телемеханика...

Как результат - либо надо что-то ОЧЕНЬ гибкое (по железу и ПО), либо придется городить зоопарк, который просто будет тяжело поддерживать.
Притом что функционал подключения железок - вроде бы одинаковый: дискретные и аналоговые входы и выход.
Ну или - делать под конкретного заказчика.

P.S. Хотя может я и сгущаю краски... Просто сам за 10 лет наелся этого от души и больше (надеюсь) не буду этим заниматься.

[AlexandrY]

P.S. Хотя может я и сгущаю краски... Просто сам за 10 лет наелся этого от души и больше (надеюсь) не буду этим заниматься.

Не просто сгущаете, но вообще не в тему написали.
Какие еще скады в умном доме или в интернете вещей?
Скадовые протоколы, как я посмотрю, это просто детский лепет по сравнению с тем что нынче делают стеки протоколов IoT.

[mantech]

Скадовые протоколы, как я посмотрю, это просто детский лепет по сравнению с тем что нынче делают стеки протоколов IoT.

И тем не менее эти протоколы прекрасно работают в промавтоматике до сих пор, а про эти "стеки протоколов IoT" такого даже близко не скажешь, это больше напоминает, как люди любят сначала сделать себе трудности, а потом героически их преодолевать

Как результат - либо надо что-то ОЧЕНЬ гибкое (по железу и ПО), либо придется городить зоопарк, который просто будет тяжело поддерживать.

Вот как раз это и тупик, ибо очень гибкое будет стоить очень дорого, да и всех задач не перекроешь, да и не надо, всегда есть ниша недорогих, простых и надежных контроллеров, вот ее и надо закрывать...

[AlexandrY]

И тем не менее эти протоколы прекрасно работают в промавтоматике до сих пор, а про эти "стеки протоколов IoT" такого даже близко не скажешь, это больше напоминает, как люди любят сначала сделать себе трудности, а потом героически их преодолевать

Вот как раз это и тупик, ибо очень гибкое будет стоить очень дорого, да и всех задач не перекроешь, да и не надо, всегда есть ниша недорогих, простых и надежных контроллеров, вот ее и надо закрывать...

IoT протоколы это просто более высокий прикладной уровень. Выше HTTP.
Могут показаться искусственными только если быть не в курсе их приложений и условий работы.

И о каких "всех задачах" речь? Задача - чисто инженерная заморочка.
Если взглянуть на себя как на обывателя, то у меня нет задач.
Если дивайс простой как IKEA-вская лампочка то беру, если это SCADA хоть и в виде WEB страницы, то нафиг не надо.
Критерии просты - минимум времени, отсутствие сопутствующих затрат (например проводов), геймификация, структурирование деятельности без умственного напряжения (нет нужды читать инструкции).
Подумав немного как это сделать вы придете к выводу, что дивайс должен быть нереально универсальным.

[Atridies]

IoT протоколы это просто более высокий прикладной уровень. Выше HTTP.
Могут показаться искусственными только если быть не в курсе их приложений и условий работы.

И о каких "всех задачах" речь? Задача - чисто инженерная заморочка.
Если взглянуть на себя как на обывателя, то у меня нет задач.
Если дивайс простой как IKEA-вская лампочка то беру, если это SCADA хоть и в виде WEB страницы, то нафиг не надо.
Критерии просты - минимум времени, отсутствие сопутствующих затрат (например проводов), геймификация, структурирование деятельности без умственного напряжения (нет нужды читать инструкции).
Подумав немного как это сделать вы придете к выводу, что дивайс должен быть нереально универсальным.

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

[AlexandrY]

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

Я себе IoT представляю как интернет, т.е. сеть сетей.
Выход в публичный интернет не обязателен.
И каждый дивайс может работать и как клиент и как сервер.
Вот у меня часы и смартфон. И тот и другой собирают данные, и сами по себе, и друг у друга.
Они вероятно будут "серваки" на вашем слэнге.

Ну вот, апологеты кана засветились, вот чем рс485 с модбасом не подошли?

А чё, есть уже на 485 экcпандеры типа таких - https://www.microchip.com/ParamChartSearch/...x?branchID=1941?
Миф как раз в том что 485 c модбасом проще CAN-а.
На самом деле трудно найти что-то более простое чем CAN для связи микроконтроллеров по полевой шине.

[Atridies]

Я себе IoT представляю как интернет, т.е. сеть сетей.
Выход в публичный интернет не обязателен.
И каждый дивайс может работать и как клиент и как сервер.
Вот у меня часы и смартфон. И тот и другой собирают данные, и сами по себе, и друг у друга.
Они вероятно будут "серваки" на вашем слэнге.

Ну часы и телефон - это не IoT: это часы, которые коннектятся к смартфону и умеют двусторонее обмениваться информацией. И даже шагомеры, трекеры и фитнесс-браслеты - тоже немного не то.
А сможет ли Ваш телефон подключиться к холодильнику или лампочке освещения? А фитнесс-браслет? Идея IoT (если я правильно понимаю эту технологию) состоит именно в том, чтобы к любому тупому девайсу подключиться хоть от чего: например к кофемашине, чтобы сделать кофе .

[AlexandrY]

Ну часы и телефон - это не IoT: это часы, которые коннектятся к смартфону и умеют двусторонее обмениваться информацией. И даже шагомеры, трекеры и фитнесс-браслеты - тоже немного не то.
А сможет ли Ваш телефон подключиться к холодильнику или лампочке освещения? А фитнесс-браслет? Идея IoT (если я правильно понимаю эту технологию) состоит именно в том, чтобы к любому тупому девайсу подключиться хоть от чего: например к кофемашине, чтобы сделать кофе .

Часы у меня - samsung gear sport. Они и шаги, и пульс, и температуру, и давление, и количество ступенек и даже настроение мерят.
Если это не IoT вещь, то тогда IoT не существует или мы просто в разных религиозных конфессиях.
IoT произрастает из M2M, а там как известно даже протокол IP не был главным.
И да, эти часы могут управлять чем угодно, дайте только подходящий шлюз.

[mantech]

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

С таким подходом и моя радиомышка может управлять кофеваркой, вот только шлюз поискать надо