Search
Write a publication
Pull to refresh
3
0
Андрей Зыков @RedPine

Пользователь

Send message
Чтобы помочь с поиском, я могу сделать для вас выжимку из предложенных статей, которая позволит ответить на вопрос, «как мы пришли к нашему решению и что перед этим делали»:

При поиске решения для себя (собственный арендный парк более 250 ДГУ), мы пробовали различные системы мониторинга. Но находили системы, которые либо требовали больших затрат, либо обладали ограничениями, которые нас не устраивали. Мы хотели найти систему, которая бы обеспечила:

  • Гибкое ПО, чтобы мы могли сами добавлять любые новые функции и расширять возможности мониторинга. Ограничения, которые предлагались закрытой средой программирования от производителей систем мониторинга не давали нам нужной гибкости. Например, нам нужно было сделать так, чтобы данные преобразовывались в наш формат, который бы не занимал много места и мог маленькими пакетами передаваться по слабым сигналам связи, а для этого нам нужна была возможность самим писать софт.
  • Простота установки. Любой инженер электрик должен легко установить систему мониторинга на ДГУ без каких-то специальных обучений и сертификатов.
  • Стабильная связь. Поскольку ДГУ работают в труднодоступных районах, связь должна осуществляться надежно даже при плохом уровне связи. Никакие статические IP нам не подходили.
  • Универсальность. Система должна работать со всеми ДГУ любого производителя и с любой панелью управления. Цифровой интерфейс или аналоговый — все должно мониториться одинаково.


Мы более года искали подобный вариант, но найти не могли, поэтому решили создавать свой. Если грубо то вот по какой логике:

  • Данные с панели управления собираются ПЛК. Если панель аналоговая, то должны быть доп.модули и датчики. ПЛК должен иметь те интерфейсы и модули, которые нам нужны без каких-то доработок с нашей стороны.
  • На ПЛК должна стоять ОС Linux с открытым кодом для возможности написания собственного софта.
  • Связь должна осуществляться как по LAN, так и по обычному мобильному интернет-соединению (SIM карта без требований статического IP).
  • Данные в ПЛК при помощи нашего софта должны преобразовываться в наш собственный формат, который занимал бы минимум места и мог передаваться пакетно по очень слабым каналам связи (при плохом сигнале сотовой сети) на верхний уровень.
  • Также ПЛК должен уметь самостоятельно принимать различные решения в соответствии с уставками. Т.е. если связь с верхним уровнем пропала, а с ДГУ что-то пошло не так, то контроллер должен сам отреагировать на какие-то критические моменты, а потом дать отчет о событии и принятых мерах.
  • На верхнем уровне должно быть наше ПО и наши сервера. Там происходит расшифровка, анализ и хранение данных. Также на ПО верхнего уровня происходит администрирование системы и располагается пользовательский веб-интерфейс, доступ к которому пользователь может получить хоть с телефона, хоть с планшета, хоть с компьютера.
  • Пользовательский интерфейс должен работать быстро и иметь графическую оболочку с мнемосхемами оборудования, органами управлений и настройки, иметь возможность построения отчетов, графиков, трендов и пр. Также должна отображаться карта с метоположением ДГУ для удобства отслеживания и навигации по большому парку оборудования.


Пообщавшись с различными производителями ПЛК (отечественными и заграничными), мы остановились на Wiren Board, которые были готовы были произвести контроллеры именно по нашему ТЗ по приемлемой стоимости и в приемлемые сроки. Далее на С++ мы написали софт, отвечающий нашим пожеланиям, создан графический интерфейс, заработал сервер верхнего уровня.

Потом были многочисленные тестирования на нашем оборудовании, а потом и проекты с нашими клиентами (мониторинг RedPine успешно используют Сбербанк, Росморпорт, РТРС и прочие компании с распределенными объектами). В результате наработанного опыта, было создано универсальное коробочное решение RedPine ДГУ, которое можно достаточно просто установить на ДГУ своими силами, подключить и пользоваться. А главное — это готовый продукт у которого может быть однозначная цена.

Именно о том, что у нас появился коробочный продукт с калькулятором стоимости, я и написал статью. В комментариях к предыдущим статьям неоднократно просили сообщить цену и показать пример окупаемости, но это тогда было невозможно — т.к. это было проектное решение, а не определенный продукт с определенной ценой.
Не совсем понимаю, почему меня постоянно спрашивают про наш контроллер, хотя мы не производим и не продаем контроллеры. Контроллер, который для нас производит Wiren Board является лишь частью системы мониторинга и стоит он не дороже контроллера от Овен. Wiren Board осуществляет для нас контрактную сборку контроллеров по нашему ТЗ и мы эти контроллеры уже используем для производства нашей системы мониторинга. Сам контроллер – лишь небольшая часть системы (около 20% по стоимости и функционалу).

Но я все же отвечу на Ваш вопрос, чтобы меня не обвиняли в отсутствии конкретики. Контроллер, является основой железа нижнего уровня и на для был написан специальный софт, который заточен именно под ДГУ (на языке С++). Вместе они являются программно-аппаратной составляющей нижнего уровня решения. В случае простого мониторинга, нижний уровень (контроллер + софт) снимает данные с различного оборудования, преобразует различные протоколы в собственный, сохраняет, пакетирует и отправляет данные с той частотой, с которой это угодно пользователю (пользователь настраивает это через личный кабинет в ПО верхнего уровня). При этом софт, который был написан нами для контроллера (на С++)собирает данные в зашифрованные пакеты и передает их на верхний уровень по LAN или при помощи встроенного 3G модема. Если у панели управления нет цифрового интерфейса, то придется использовать версию RedPine для аналоговых панелей, которая на 15-20% дороже за счет

На всякий случай еще раз повторю — контроллер является лишь частью программно-аппаратной части нижнего уровня (20% от функционала и цены). Мы рассматривали контроллеры Овен в качестве одного из вариантов железа нижнего уровня, но по соотношению цена/функционал выбрали wiren board. Овен не был дешевле и имел существенное ограничение в плане ПО нижнего уровня – собственная закрытая среда программирования с недостаточными для нас возможностями по обработке и передаче данных. Wiren Board несет на борту обычный Linux и дает любые возможности по разработке собственного софта.

Зачем гадать по ценам, если есть калькулятор, ссылку на который я давал, и где можно все за минуту посмотреть. Простое решение по удаленному мониторингу для ДГУ с панелью с цифровым интерфейсом будет стоить 65 тыс. руб. А если панель аналоговая, то 78 тыс. руб. (+20% в случае с обычным мониторингом). Извините за ссылку на внешний ресурс, но в рамках статьи на Geektimes невозможно разместить интерактивный калькулятор.

Еще раз повторюсь – цены, которые выдает наш калькулятор, не являются ценой контроллера, а являются ценой всего решения, т.е. контроллер + ПО нижнего уровня + монтажный комплект + ПО верхнего уровня + облачный web-интерфейс + хранение данных на наших серверах 1 год.

На наше изделие есть декларация о соответствии ТР ТС «О безопасности низковольтного оборудования» и ТР ТС «Электромагнитная совместимость технических средств». ПО RedPine также прошло проверку Минкомсвязи и внесено в единый реестр российских программ для ЭВМ и БД.
Я, наверное, не очень понятно написал, попробую исправиться. RedPine ДГУ — это не вариация WB, а система, лишь малой частью которой является ПЛК (WB модифицированный под нас). Т.е. если RedPine ДГУ принять за условный автомобиль, то ПЛК — ее двигатель (без обвязки, подвески, кузова, колес, тормозной и топливной системы, органов управления и пр.). Поэтому сравнивать RedPine ДГУ и WB бессмысленно.

ПЛК Wiren Board действительно умеет прекрасно читать огромный зоопарк разных устройств — именно поэтому мы и выбрали этого производителя для наших ПЛК. А еще потому, что на контроллере стоит практически чистый linux и можно написать полностью свой софт, а также постоянно модифицировать и обучать ПЛК новым возможностям. Мы не вносили изменения в конструкцию WB, а в рамках контрактной сборки совместно с WB разработали собственную комплектацию, которая по железу практически такая же, но мы отказались от элементов, которые нам не нужны (типа Wi-Fi, GPS) и добавив нужные: дополнительный интерфейс RS-485 (теперь их 2), 3G модуль, заменили тип клемм для более простого монтажа. Но главное изменение – это не железо, а собственный софт, написанный на С++, который позволяет преобразовывать данные с зоопарка устройств именно в нужный нам формат данных (по структуре и объему), чтобы их можно было легко и безопасно хранить в памяти контроллера и гарантированно отправлять по сотовой связи низкого качества на верхний уровень, где и происходит основная работа системы мониторинга.

Про локальный сервер. Да, если пользователь не хочет хранить данные в облаке и на наших серверах (например, по причине секретности объекта), то он может использовать свой собственный сервер. В этом случае он получает специальную версию RedPine ДГУ с открытым функционалом и ее интеграцию в собственную систему пользователя по его желанию. Подключение осуществляется по протоколам Modbus TCP, RTU, SNMP. Стоит это дороже, чем облачная версия, т.к. подразумевает бессрочную передачу нашей интеллектуальной собственности, а также усложняет как саму процедуру подключения и настройки, так и поддержку решения, т.к. у каждого будет свой софт верхнего уровня со своими особенностями.
Под скриншотом, о котором вы говорите, есть ссылка, которая ведет на сам калькулятор и лучше там смотреть точные цены, т.к. они будут зависеть от нескольких параметров, которые нужно выбрать. Кроме того, там все элементы пояснены при помощи всплывающих подсказок, что может также дать ответы на ряд вопросов. Извините, что приходится Вас переадресовывать на другой сайт, то возможности GeekTimes не позволяют продемонстрировать работу прямо в статье.

Работа с данными. На нижнем уровне данные после обработки могут храниться в среднем 2-3 месяца, но это средние значения для резервной ДГУ, а реальная цифра будет зависеть от количества событий. Но чаще всего данные долго и не требуется хранить – с нужной частотой, например, раз в 5 секунд (настраивается пользователем), софт нижнего уровня пакетами отправляет данные на верхний уровень, и как только нижний уровень получает подтверждение об удачном получении данных, они удаляются с хранилища нижнего уровня. Данные на верхнем уровне хранятся по умолчанию 1 год, а потом уходят в архив. При желании пользователя, можно увеличить хранение оперативных данных с 1 года до 2, 3 и т.д. лет, но это потребует от него доп.затрат (либо доп.оплата хранения на наших серверах, либо выделение доп.памяти на собственном сервере, если выбран собственный локальный сервер).

Относительно NetBiter – давайте я попрошу коллег сделать сравнение для Вас. Пока не могу ответить сходу, т.к. нас отпугивала именно цена, низкая гибкость и тот факт, что в их решениях на нижнем уровне не происходит никаких вычислений, т.к. там у них стоит не ПЛК, а скорее УСПД, т.е. он просто собирает и передает данные без какой-либо обработки, что в нашем случае было неприемлемо (сравнительно большой объем передаваемых данных, для которого требовалась хорошая и устойчивая связь). Но опять повторюсь – это будет не сравнение железа NetBiter с WB, а сравнение решения NetBiter (железо + все антенны и кабели + подписка на их облачный сервис Manage and Analyse) и решения RedPine (железо + все антенны и кабели + наш облачный сервис RedPine). Попробую также сравнить функции облачных сервисов, чтобы осталось меньше вопросов.

Тут часто появляются комментарии о том, что нет конкретики, но от меня почему-то ждут конкретику по работе контроллеров, хотя мы не производим и не продаем контроллеры, а производим готовую коробочную систему мониторинга и управления, в состав которой хоть и входит контроллер, но он не является центром или основой системы, а служит лишь модулем, который по цене и функциям составляет лишь около 20% от всей системы. Этот контроллер можно заменить другим, если в этом будет необходимость, и поэтому я никогда не даю больше конкретики о нем — это уводит обсуждение нашего продукта, в сторону продуктов, которые мы не производим и не продаем, но нас почему-то с ними сравнивают. Согласитесь, как-то странно было бы убеждать кого-то в том, например, что системный блок с видеокартой radeon лучше или хуже, чем просто отдельная видеокарта nvidia. Отдельная карта всегда будет дешевле целого системного блока с подобной по производительности видеокартой, материнкой, процессором, БП, оперативкой, жестким диском и корпусом.

Хоть это и воспринимается, как попытки уйти от ответа, на самом деле я всего лишь стараюсь вернуть диалог к нашему продукту – к системе мониторинга, а не выяснять особенности ПЛК, которые мы и не производим вовсе. Я пытаюсь учесть критику, но не планирую полностью переключаться на другие темы и писать про то, к чему мы относимся лишь косвенно. Но это вызывает лишь негатив – в прошлые разы просили дать цены, т.к. это главное, и мы делаем калькулятор на сайте, где можно все посчитать, и поиграть с вариантами, даем ссылку в статье прямо под скриншотом, чтобы проще было найти, но по комментариям я вижу, что люди не захотели воспользоваться возможностью, а предпочли что-то додумать и начать критиковать эти домыслы. Я пишу это в ответ на ваш комментарий не потому, что имею в виду Вас, просто вы требуете конкретики, задавая действительно конкретные вопросы, что позволяет мне надеяться на адекватную реакцию.
С удовольствием расскажу:
geektimes.ru/company/redpine/blog/288846
geektimes.ru/company/redpine/blog/290805
geektimes.ru/company/redpine/blog/291957

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

Wirenboard — это контроллер, а не решение. В RedPine этот контроллер играет роль железа нижнего уровня и производится компанией WB по нашему ТЗ (внесли ряд изменений, например, заменены клеммы, добавлены новые и убраны лишние интерфейсы и т.п.). Кстати, они сами делают и лицевую и все торцевые наклейки. Далее для этого контроллера был написан софт нижнего уровня, основной задачей которого было преобразование разноформатных данных с целого зоопарка различного оборудования в единый формат и подготовка этих данных для гарантированной отправки по низкоскоростным каналам мобильной связи (и все то же самое в обратную сторону — для получения сигналов, перекодированию и передачи на оборудование). Но это еще не все — это лишь нижний уровень, т.е. половина решения. А еще софт и железо верхнего уровня.
Софт верхнего уровня отвечает за передачу, обработку и хранение данных, а также за работу графического интерфейса пользователя (чтобы мониторить, управлять, строить отчеты, графики и т.п.), который должен легко перевариваться любым железом пользователя, даже из 20 века. Ну и железо верхнего уровня — это в основном серверное оборудование и устройства обмена данных между нижним и верхним уровнями.

Это если очень кратко отвечать на вопрос, чем решение отличается от контроллера (в том числе и по цене). Если оценивать процентно, то контроллер — это 20-25% решения. Если вам интересно почитать подробнее, то об этом есть отдельная статья: geektimes.ru/company/redpine/blog/291957
Часть данных снимается с панели управления, часть посредством доп. модулей и датчиков. Работает с DEIF, ComAp, SmartGen, DSE, Bernini, Datacom и многими другими. Используется modbus. Количество и состав снимаемых с ДГУ может варьироваться — сначала можно поставить только контроль температуры и моточасов, а потом добавить еще, например, уровень топлива или заряд АКБ. Часть параметров могут конфигурироваться пользователем через личный кабинет. Ориентация скорее наоборот — на много разных ДГУ с разными панелями управления, находящихся в разным местах. Работа с синхронизированными ДГУ, резервирование сети — тоже все есть. На одиночные ДГУ мы скорее ориентируемся в случаях, когда это контейнерное исполнение с кучей систем, которые нужно постоянно контролировать издалека. Просто одиночная ДГУ, стоящая в городе — совсем не наш ориентир.
Сложнее — это связать в единую сеть ДГУ разных производителей и разной нормальности и разумности (плюс связанные с ними другие инженерные системы). Как раз основная проблема в том, что из единого центра надо мониторить и советскую ДГУ на Камчатке, и новенький FG Wilson в Казани, и какую-нибудь AKSA в Краснодаре. Они друг с другом никак не дружат без очень длительных танцев с бубнами.

Про Овен я, конечно, знаю, но у них проектные решения, а не готовые коробочные. Т.е. если вы возьмете для своих ДГУ RedPine, то потребуется только установка и подключение, а если возьмете Овен, то придется писать ПО как низкого, так и высокого уровня, добавлять интерфейсы и делать прочие доработки индивидуально. Но в целом да — из Овна можно собрать себе систему мониторинга. Будет ли это дешевле, учитывая доработки? Это большой вопрос, ведь это будет индивидуальное решение и все будет зависеть от кучи нюансов. Будет ли это прощу и удобнее — однозначно не будет.
В ДГУ разных производителей разный интерфейс, и у них разные панели управления. В большинстве случаев мы сталкиваемся с разношерстным парком ДГУ у клиента. Вы тоже отчасти правы — если речь идет об одной ДГУ или о нескольких одинаковых ДГУ с одинаковыми панелями управления, то наше решение и не нужно — сам производитель ДГУ или панелей предлагает мониторинг, как опцию. Я об этом писал в прошлых публикациях, но, видимо, нужно постоянно на них ссылаться, чего я не сделал — у нас вся эпопея и началась с того, что мы приезжали к клиентам, а у них одна ДГУ — новенькая SDMO с возможностью мониторинга, а вторая — сарый CAT с аналоговой панелью, третья — еще что-то совсем другое. Вот для кого нам пришлось делать решение. Я вам как на духу говорю — мы перед этим перепробовали все варианты, иначе бы не выбрали этот путь. Повторюсь — RedPine ДГУ выгоден скорее для парков с совершенно разными машинами, разбросанными по разным уголкам страны с плохой связью. Это нефтянка, связь, заправки и т.п.
От получения минусов никто не застрахован, ибо люди, ставящие минусы не подчиняются правилам логики, а делают это лишь руководствуясь эмоциями. Среди читателей любой статьи найдется 1-2% недовольных, которые захотят воспользоваться властью ставить кому-то оценки, а уж тем более, если это коммерческая статья.
Да, вы в чем-то правы — я не раскрываю всех деталей, спецификаций и описаний. Раскрытие подобной технической информации не добавит продукту привлекательности. Но и сокрытие ее не скажется негативно. Для дела полезнее, когда продукт выполняет свои функции, а не когда известно в мельчайших подробностях, как он это делает.
Да, это верно — гораздо дешевле. Мы так же сначала думали и с этого начинали. Жаль, что это не работает, как надо, без изменений в ПЛК, без своего нижнего софта и прочих доработок.
Спасибо за оценку, хоть и негативную. Не могу согласиться с вашим пожеланием — я так понимаю, что у вас есть желание видеть статьи формата Хабрахабр. Если да, то, я полагаю, будет продуктивнее там их и искать — именно там технарями размещается подробная информация о технической реализации для других технарей. Я, кстати, практически цитирую руководство данных площадок.

Почему делаем аппаратную часть, а не берем готовое я писал в предыдущем материале. Если кратко ответить на вопрос — нам нужно было кое-что сильно посложнее управления светом в сортирах. И мы долго искали, много чего перепробовали, но не нашли. В самой первой статье я рассказал, что это решение мы создали для себя в первую очередь, поскольку «взять ПЛК и написать верхний софт» не помогало, а так хотелось… Если вы сможете привести в пример хотя бы 2-3 ардуинщиков, которые реализовали такое же решение (одновременный мониторинг десятков видов оборудования разных производителей, разбросанных по всей стране, их удаленное управление по сотовой связи низкого качества… хотя бы это), я буду безмерно благодарен и даже готов вас премировать. Пусть не реализовали, но хотя бы знают, как это сделать правильно, проще и дешевле.

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

Вам не нравится, как рассказано о продукте, но вас же не продукт интересует, судя по комментариям, а всего лишь техническое решение.
По поводу покупать или не покупать — это даже не тема для обсуждения, ведь мы тут ничего на Geektimes не продаем. Основная мысль — познакомить ближе людей с общей концепцией решений на базе нашей разработки. Да, это можно считать и рекламным материалом, и ничего постыдного я тут не вижу — разработки должны внедряться и работать. И я постоянно убеждаюсь, что дело это очень нужное — судя по некоторым комментариям к предыдущим статьям, даже местные технические специалисты могут, не понимая содержания статьи, требовать технических подробностей, которые они непонятно для чего собираются применять. Что уж говорить о менее подкованных в технических вопросах людях.
Спасибо, что поделились мнением. ASCII вариант был экспериментом, а в таких делах возможен как позитивный, так и негативный эффект. Подумаем над тем, чтобы уделять больше внимания красивым изображениям и захватывающим первым абзацам. С комментариями поделать ничего не могу, т.к. не собираюсь их как-то модерировать и удалять, поэтому тут изменений не обещаю — что написали, то написали.
Сергей, я жду ответа от наших разработчиков по поводу RPL — постараюсь углубиться в данный вопрос насколько это будет возможно. Но, повторюсь, в блоге я делаю больший уклон в сторону потребительских свойств платформы с небольшим углублением в технику (то, что важно скорее пользователю), нежели детальный процесс его функционирования, разработки и производства (то, что важно разработчику). Это, например, как с телефоном — 1. Можно просто написать, что в нем есть поддержка LTE; 2. Можно написать, что поддерживается LTE с такими-то частотами, с такими-то скоростями скачивания и загрузки; 3. А можно описать еще и сам модуль LTE, его энергопотребление и рабочую температуру, способ и место крепления в смартфоне. Так вот, я скорее выберу 2-й вариант, как интересный подавляющему большинству читателей.
Кроме технических подробностей у любого продукта есть еще очень много свойств, например его потребительские свойства, принцип работы, состав оборудования (комплектность) и многое другое. Технические подробности важны и интересны (в основном только разработчикам), но, как я уже пояснил, их раскрытие делает нас беззащитными перед конкурентами. Даже продавая подобные комплексные решения, мы можем подписать с клиентом договор о неразглашении, чтобы избежать нежелательных утечек. И, согласитесь, было бы глупо при этом устраивать утечки самостоятельно на страницах блога.

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

Интересно читать или нет — это вопрос сугубо субъективный. Ваше мнение мне понятно.
Добрый день! Да, я помню о вопросе к прошлой статье, и я его адресовал нашим разработчикам. Но, к сожалению, ответа я дать все еще не могу. Дело в том, что мы разрабатываем и реализуем реальные коммерческие проекты, и очень многие вещи относятся к разряду коммерческих тайн и прочих технических секретов. На Geektimes мы размещаемся в разделе «блог компании RedPine» и рассказываем о коммерческом продукте, немного раскрывая технические детали. В таких делах осторожностью пренебрегать крайне недальновидно — конкуренты не дремлют, и нам есть что терять. Да, отчасти, это может казаться паранойей, но мы предпочитаем перестраховаться, тем более, что негативный опыт утечек имеется. Кстати, именно понимание того, что мы не сможем делиться всей технической информацией было одной из причин, почему статьи выходят на Geektimes, рассчитанном на любой уровень техничности, а не на Хабре, рассчитанном больше именно на разработчиков, и где приветствуются технические статьи с максимальной детализацией, кодом, спецификациями и т.п.

Я уточню, какую информацию мы можем раскрыть по протоколу RPL и дам комментарий на следующей неделе.
Это не клон, а контроллер, контрактную разработку и производство которого осуществил Wiren Board. Сами мы не производим контроллеры.
Да, это разные компании. Wiren Board — производит контроллеры по нашей спецификации, используя свою элементную базу. Т.е. по сути, Wiren Board осуществляет для нас контрактную разработку.
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity