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



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

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

Спасибо.

Чисто теоретически - зачем может быть нужно такое устройство?

Аналогичные системы делают все кому не лень. И наши и буржуи. Овен, пульсар, эско, ABB, WAGO - это навскидку. Единственное - они по-разному организованы: у кого-то большие блоки, у кого-то распределенная структура, у кого-то серваки на малинках и пр. встраиваемых системах, у кого-то серваки мощные. Есть еще и различие по назначению, требующее свои особенности: например пульсар для ЖКХ - работает несколько лет на батарейках, системы, которые ставятся на подстанции - требуют серьезных защит по входу и по эфиру, системы управления зданиями - требуют симпатичную мордочку и лампочки на лицевой панели шкафа, ну и так далее...
Если у вас есть конечный потребитель - лучше на первых порах использовать чужое оборудование. А уж потом - заморачиваться с собственной разработкой.

P.S. кстати, у меня есть парочка блоков с примерно аналогичным функционалом.

И кстати, не использование LAN имеет свой смысл: это соединение точка-точка, а RS-485, CAN и др. - это цепочка.

В вашем дивайсе критически мало функций и полная неясность с софтом.
Чтобы успешно конкурировать с промышленными линейками контроллеров и модулей IO вы должны добиться максимального количества функций на единицу объема
И должны иметь четкий и ясный каркас и шаблоны для создания софта с продвинутым семейством микроконтроллеров.
Нужны протоколы IoT, беспроводные интерфейсы, гибкая разъемная система.

Железо не так актуально. Вот плата как на фотке ниже делается за пару недель.
Нажмите для просмотра прикрепленного файла
Секрет в многофункциональном софте и способности гибко модифицировать платы.
Т.е. презентовать такие дивайсы сейчас имело бы смысл с описания ресурсов микроконтроллера,
и софтовой экосистемы к которой они принадлежат (Arduino, mbed, Android Things , FreeRTOS, zephyrproject, CODESYS...), а лучше к нескольким.
Таким образом ваши возможности превзойдут предложение любых брендов с их жесткой линейкой продукции.

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

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

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

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

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

Для умного дома и прочего себе делал такое http://picping.lg.ua/eth_pic_basic/index.htm , http://www.picping.lg.ua/eth_pic_basic/index1.htm
На борту интерпритатор BASIC, WEB сервер, RS485, MODBUS и другое . Freeware.

Как я слышал такие мелкие сервисы как freeboard тусуются в облаках амазона или гугле.
И чуть какие разборки типа разборок с телеграмом сразу попадают в бан под горячую руку.
Перво-наперво надо делать нативные приложение под Android.
А WEB приложения эт уже для админа.

Спасибо! Ценная информация.

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

Вопрос скорее к ТС но если кто знает ответьте. Исключительно в познавательных целях интересуюсь: а какие внешние датчики или источники сигналов вы собираетесь подключать к своим аналоговым входам? Просто модель или описание интересны. Нам попадались в основном датчики с токовой петлей - 4-20 mA. У них масса особенностей, но с ними все понятно. Попадались резистивные 3 и 4 проводные датчики. С ними тоже все понятно. Или ваши аналоговые входы можно сконфигурировать для работы с ними?

Тут уже говорили, что делают такие устройства все, кому не лень. А не лень - почти всем...
Но сделать нечто универсальное, "на все случаи жизни", пока не получается ни у кого. И не потому, что невозможно, а потому,
что универсальное решение будет слишком дорогом для многих применений. Что сразу сужает рынок потенциальных покупателей...
Вам нужно найти "золотую середину" между универсальностью и уникальностью применения. Самый простой способ - выбрать какую-то специализацию,
какую-то конкретную область применения вашего устройства, или несколько близких областей. На них и ориентироваться...

Есть множество датчиков с линейным выходом вроде манометров (напр. MPX5700AP), термометров, сенсоров Холла (к примеру, SS494). Ну а токовые датчики можно снабдить резисторами, вставив их прямо в контактные гнезда.




Собственно, в этом и заключается маркетинговое, с позволения сказать, исследование. Изучаю, чем интересуется потребитель.

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

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

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

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

На удаленных объектах как я понимаю без резервного канала GSM/GPRS/LTE вообще делать нечего. Если вам за серверной комнатой проследить или еще за чем где Ethernet никогда не умирает то наверное пролезете со своей железкой. А в ЖКХ, энергетику и в прочий съем показаний вход вам заказан.

У нас по этому поводу отдельная тема была. В спальных районах Москвы съем идет только через 2G и совсем немного где LTE, потому как население возвращаясь с работы наглухо кладет 3G/4G несмотря на то что у всех дома WI-FI и оптика. В результате имеем весь спектр дочерних плат.

На данном этапе нет задачи потеснить Моху или Овен. Хочется предложить дешевое решение для широкого потребителя (может, кому-то надо мониторить климат в теплице или уровень воды в бассейне).

Обидеть вас не имею ни малейшего желания, но вижу что маркетинговое исследование ваше в самом начале. Предложенные применения - теплица и бассейн кажутся мне мягко говоря высосанными из пальца. Там где теплицы промышленные - там и оборудование соответствующее. А дачника с маленькой теплицей и своим контроллером вы можете представить? Однозначно баран и ворота - вид сбоку. С бассейном та же история. Тот кто на даче вырыл котлован, положил пленку и налил воды из колодца тот про вас даже не вспомнит. А тот кто на групповое джакузи разорился у того Крестрон за всем следит. Есть в вашем изделии еще один неозвученный параметр - производительность процессора. Если там STM32 с Ethernet (ну или что то соизмеримое по возможностям) это одна история. Если Cortex А (какой то) то совсем другая. И там следует Linux и OPC UA

И кстати в тех же ЖКХ Моксы давно перевелись. Они дорогие и негибкие. Все давно на самостийных построено, причем в каждом крупном региона царствует свой локальный производитель руководством региона продвигаемый обычно. Так что если совсем честно то предлагаю начать с другого конца - поискать заказчика который этой темой интересуется. Найти и сказать ему что то что есть сейчас это прототип, но для вас я сделаю все что захотите, только скажи что надо. Как то так.

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

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

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

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

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

Это если мастер за вас играет. А если этот мастер потерял доход из-за того что теперь показания снимает бездушная система и его услуги по снятию Z-отчетов больше не нужны??!! Он придет, вырубит автомат и быстренько сбежит - дожидаясь что его вызовут на обслуживание этого объекта. Для этого как раз та фича с которой я начал. Потом эти вредители стали заходить на объект и отстегивать шнуры - и опять бегом. Потребовался детектор отстегнутого кабеля. с RS232 легко разобрались а вот с RS485 дешевого решения пока не нашли. Но это ужасы из ЖКХ - пока мимо вас

Пользую несколько лет WiFi-GSM роутер и он ни разу не зависал.
Но проблемы были. И были они из-за базовой станции провайдера.
Так что если кого волнует надежность, то надо просто ставить два роутера от разных провайдеров.

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

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

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

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

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

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



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

Интернет вещей - это не умный дом. Это другая область. Для АСУЗ - надо иметь скаду. Если Вы называете умным домом - умные холодильники, выключатели света в комнатах, автокормилки для животных и пр. - тогда Вы правы: все подключается к облаку.
Хотя... эти вещи уже пересекаются.

Повторюсь (и соглашусь с mantech): надо четко выбрать свою нишу. Иначе будете разрабатывать без особой отдачи.

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

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

Если хотите продавать всякие игрушки, и пр шняги для "блондинок" и тех, у кого интеллект опустился до уровня бабуина, что имеет место быть в сегодняшних реалиях, и поднять бабок на этом с каждым годом можно все больше и больше, тут я не спорю, но ТС и его контроллеры нацелены на несколько иную аудиторию, ближе к промавтоматике, и тут ваш подход не сработает...

А я что, спорю?
Я и говорю, автор хотел бытовую шнягу, а получилось как всегда - промавтоматика.

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

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

Вставлю свое ИМХО, как потенциальный заказчик. Мне в систему нужен какой-то блочек на дин рейку, который бы добавлял удаленный доступ к моей системе управления. В саму систему вводить удаленный доступ не хочу и часто она прекрасно работает и без него, но заказчикам иногда хочется добавить удаленную диагностику и мониторинг. Грубо говоря хочется такой функционал (в порядке убывания приоритетов)
- Подключение к контроллерной шине по CANopen и запись всего, что происходит в локальный лог с автоматической выгрузкой на сервер. Запись должна вестись и при отсутствии интернета. Возможность инициировать SDO трафик для чтения/записи параметров контроллера (т.е. обычный CANopen стек на Linux)
- Ессно часы реального времени для логов с автоматической синхронизацией через NTP
- Пара релюшек, чтобы дергать питание системы удаленно
- Режим HMI - встроенный настраиваемый Вебсервер с возможностью доступа как по сети, так и локально через Wi-Fi/Bluetooth, например с телефона/планшета.
- соответствие промышленным EMC стандартам, работа от -20 до +50°C.
- размер - примерно с 2 коробки сигарет, питание +24В или ~220В.
- Возможность дублирования интернет канала - RJ485/Wi-Fi/3G.
- Возможно, но не факт, что для интернет-части понадобятся и другие протоколы - Modbus TCP, MQTT и т.д. , так, чтобы можно было присобачить эту коробочку и под другие системы мониторинга, а не только вашу.

Честно говоря думал под это дело тупо взять Малину, да приспособить ее под данные нужды, но с софтом заморачиваться не хочется.

Ну вот, апологеты кана засветились, вот чем рс485 с модбасом не подошли? Это используется в машине, "модно, стильно молодежно" или в чем фишка? Объясню, не понимаю зачем усложнять задачу моструозным стеком, или просто аля "в малине уже было, дак что и не использовать"

Ну CiA 417, например. Довольно популярный публичный стандарт, почему бы не использовать?

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

Ну вот для меня данное устройство, предложенное автором и удовлетворяющее моим требованиям и есть тот черный ящик, который я бы с удовольствием прикрутил к своему проекту. Какая там будет CANopen либа мне до лампочки, если оно зависнет, то тоже ничего критичного с моим проектом не произойдет.
А возможные проблемы с интеграцией монструозного стека на Линуксе оказываются и не такими уж проблемными, если учесть, что этот же самый стек уже работает не в одном десятке проектов и баги достаточно хорошо вылизаны либо известны. Но это не относится к данной теме.

С таким подходом покупаете любую китайскую шнягу или самый дешевый роутер, пишете чего-нить на питоне или что там еще модно и оно как-то будет работать

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

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


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

Ну и чем они лучше вот этих - https://www.microchip.com/wwwproducts/en/MCP23008

Кроме того, что в 2 раза дешевле, и во много раз проще в программировании хоста...
А вообще "тупые" экспандеры мало кто использует, ибо трафик на шине от них ужасный.

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

Но начиная с пары метров обычный I2C не тянет линию по емкости и по помехоустойчивости. И уже надо городить для согласования I2C нечто более дорогое чем у CAN-а.
CAN экспандеры я применял и сейчас думаю снова к ним вернутся. Это надежное, универсальное и технологичное решение.
Многоканальный аналоговый измеритель лучше было бы делать распределенным и на CAN расширителях.

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

Что станет главным по большей части зависит от личных навыков разработчика.
Но по логике труднее делать то, что сильнее ограничено в ресурсах, т.е. встраиваемую систему.

Но в конце концов мне нужно готовое изделие, которое я могу воткнуть в свое без всяких танцев с питоном, как говорится "plug-and-play". Что-нибудь есть из подходящего на рынке?

сема, ваша простота поражает...но если взялись, уж будьте честным до конца: в конце концов ведь вам даже деньги не нужны, а лишь то что вы на них хотите купить - понтовое электроведро на колесах и новую цепь для велосипеда)))

Советую - обращайтесь к AlexandrY. У вас с ним явно должна наладиться синергия - есть в вас чтото общее - любовь к новым названиям, чтоле.
Зная его, можно быть уверенным, что он вам как обычно сделает что-нибудь готовое за пару недель задаром.

Ну по крайней мере пообещает)))

CANopen мне не интересен. Его спецификации уровня приложений не дают развернуться фантазии.
Поэтому мы применяем свои протоколы на CAN-е.
И да, все мои девайсы способны логить обмен по CAN-у.
Отладка у меня на первом месте, ради нее я могу поставить в 10 раз более мощный процессор чем нужно для приложения.
Это всегда оправдывается.
Такой мой совет.

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

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

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