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

[Owl Electronics]

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



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

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

Спасибо.



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

[gerber]

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

[Atridies]

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

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

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

[AlexandrY]

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

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

Железо не так актуально. Вот плата как на фотке ниже делается за пару недель.
 PLC.JPG ( 73.62 килобайт ) Кол-во скачиваний: 82

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

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

[Owl Electronics]

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

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

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

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

[Driver_GV]

Вопрос такой - имеют ли подобные устройства свою нишу в потребительской сфере? К примеру, в области умного дома.

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

[AlexandrY]

Кроме того, рассматривается интеграция с сервисами, к примеру, freeboard.

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

[Owl Electronics]

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

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

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

[vldmr86]

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

[@Ark]

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

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

[Owl Electronics]

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

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

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

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

[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 уже имеется как канал обмена, или в любых?

[vldmr86]

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

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

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

[Owl Electronics]

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

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

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

[vldmr86]

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

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

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

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

Сообщение отредактировал vldmr86 - Jul 24 2018, 10:43

[mantech]

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

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

[AlexandrY]

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

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

[Owl Electronics]

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

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

[mantech]

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

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

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

[vldmr86]

.... и что делать, звать мастера чтоб нажал ресет?

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

[AlexandrY]

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

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

[Atridies]

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

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

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

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

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

[AlexandrY]

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

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

[mantech]

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

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

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

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

[Atridies]

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

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

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

[AlexandrY]

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

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

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

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

[mantech]

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

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

[AlexandrY]

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

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

[Owl Electronics]

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

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

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

Сообщение отредактировал Owl Electronics - Jul 25 2018, 12:02

[syoma]

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

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

[mantech]

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

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

[syoma]

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

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

[mantech]

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

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

[syoma]

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

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

[mantech]

Какая там будет CANopen либа мне до лампочки, если оно зависнет, то тоже ничего критичного с моим проектом не произойдет.

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

[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 для связи микроконтроллеров по полевой шине.

[mantech]

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

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

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

Сообщение отредактировал mantech - Jul 26 2018, 07:19

[AlexandrY]

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

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

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

[syoma]

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

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

[AlexandrY]

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

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

[syoma]

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

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

[a123-flex]

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

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

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

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

[AlexandrY]

Советую - обращайтесь к AlexandrY.

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

[Atridies]

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

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

[AlexandrY]

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

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

[mantech]

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

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

[AlexandrY]

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

Не думаю.
Вы скорее всего не имеете никакого API к своей мышке для загрузки в нее сторонних приложений.
А так в принципе да, мышка тоже IoT.

[ReturnX]

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

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

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

[turnon]

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

И мне, пожалуйста.