Союз софта и железа. Удаленный мониторинг и управление RedPine

    Заглянем на пару секунд в прошлое — в предыдущих статьях мы говорили о базовой философии и ключевых особенностях платформы RedPine. Мы старались выяснить «что это?» и «зачем это?». Ну а теперь пришло время начать приглядываться к деталям продукта и приступать к погружению на более глубокие уровни.

    И на следующем уровне у нас с вами расположился обзор базовых элементов платформы, и особенностей их взаимодействия — мы поговорим о священном союзе софта и железа.



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



    Состав программно-аппаратного комплекса


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

    И теперь мы разберем систему мониторинга RedPine на составляющие, и попробуем рассмотреть каждую часть в отдельности — ее функции, ее особенности, ее место в общей картине. В качестве примера, я предлагаю вашему вниманию вот такую иллюстрацию:


    Базовые части системы RedPine (пример)

    На этом своеобразном параде планет видно, что все решение делится не просто на программную и аппаратную части (софт и железо), но и сами эти части имеют разные уровни и отвечают за разные функции. Это действительно важный момент, т.к. правильное распределение функций напрямую влияет на общую производительность системы. Шестеренки на картинке призваны символизировать связь между уровнями и элементами — это тоже очень важный момент, о котором ниже скажу подробнее.

    С вашего позволения, в дальнейшем программную часть я иногда буду называть «софтом» или «ПО», а аппаратную часть — «железом». Думаю, что так всем будет проще.

    Естественно, каждый элемент важен и вносит свой вклад в работу всей системы. Но одинаков ли их вклад? Нет, не одинаков, и оценить его в каких-либо единицах весьма проблематично. Это можно сделать лишь условно, и если мы придумаем некую процентную шкалу весомости вклада в систему, то увидим такую картину:


    Долевое участие основных элементов системы в общем решении

    Эта иллюстрация показывает лишь приблизительное распределение значимости базовых элементов системы RedPine, но улучшает понимание основного принципа — программное обеспечение верхнего уровня является центром и основой решения, а находится оно не на удаленном объекте, а в условном центре управления.

    «Железо» верхнего уровня


    Под железом верхнего уровня мы имеем в виду компьютерную технику различного форм-фактора, серверное оборудование и устройства, обеспечивающие связь между верхним и нижним уровнями. Это железо может быть не только частью решения RedPine, но и может параллельно выполнять какие-то другие функции (офисные дела, просмотр youtube, пасьянс), требование лишь одно — техника должна соответствовать минимальным требованиям выбранного типа решения.
    image
    Мы пока не будем подробно останавливаться не деталях, чтобы не рушить структуру сегодняшнего материала. Если любопытно, то типичные виды решений можно посмотреть в специальном разделе на официальном сайте RedPine.

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

    «Железо» нижнего уровня


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

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

    Ко всем мы обращались с одними и теми же исходными данными:

    • Необходима разработка контроллера под наши нужды и требования
    • ПО верхнего и нижнего уровня нашей разработки
    • Операционная система контроллера на базе linux
    • Наладить выпуск контроллеров по нашей спецификации в мелкосерийном режиме
    • Быстрые сроки производства
    • Быстрая реакция техподдержки
    • Гибкость – готовность к изменениям в продукте
    • Удобный форм-фактор в плане монтажа и использования

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

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

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



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

    Отрадно, что многие из читателей Geektimes в нашей прошлой статье сразу же узнали платформу Wiren Board — это было приятным моментом и подтвердило популярность данного производителя промышленных микрокомпьютеров. Со своей стороны мы пока можем дать только положительные отзывы об их продукте, и надеемся, что так будет всегда.

    Связь между нижним и верхним уровнями


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

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

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


    Устройство нижнего уровня с коммуникационными портами

    На железе нижнего уровня есть все необходимые интерфейсы для передачи данных: GSM, 3G RS 485, 232, TCP/IP. Они могут функционировать по отдельности или одновременно и без проблем работают со слабыми каналами связи. Даже если оборудование находится в тундре или тайге, оно будет на связи. При необходимости (или по желанию заказчика), система может быть дооборудована другими коммуникационными интерфейсами.

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

    RedPine можно легко интегрировать в существующие информационные системы при помощи протоколов Modbus и SNMP, а железо нижнего уровня можно использовать в качестве дополнительного шлюза.

    «Софт» верхнего уровня


    Главная задача ПО верхнего уровня – быть неким хабом, связующим звеном между железом верхнего уровня, софтом нижнего уровня и человеком.

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

    Сначала о мозге, который скрыт от пользователя. Тут мы не использовали готовых решений, и все пришлось писать с чистого листа. Это ПО отвечает за хранение, обработку, анализ и передачу данных между различными элементами верхнего и нижнего уровней и, кроме прочего, нам было критически важно, чтобы все это было оптимизировано и быстро работало на различном «железе». Плохая оптимизация может одним махом загубить даже самый лучший функционал, т.к. этим богатым функционалом нельзя будет воспользоваться.


    Интерфейс системы мониторинга и управления дизель-генераторной установкой (Мнемосхема)

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

    «Софт» нижнего уровня


    Поскольку ПО нижнего уровня работает на железе нижнего уровня, то оно должно общаться с ним на одном языке. Как раз поэтому у нас и были требования к производителю контроллера, которые касались используемой операционной системы и внутренних алгоритмов работы устройства.

    Этот софт отвечает за получение команд от ПО верхнего уровня, их обработку и передачу на исполнительные устройства аппаратной части нижнего уровня, такие как контроллер, модули расширения и дополнительное навесное оборудования (датчики, управляющие элементы и пр.). А также и за обратный путь – данные, получаемые от железа нижнего уровня нужно обработать и передать на верхний уровень.

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

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

    image


    Продолжение следует...


    Когда мы говорим о комплексном решении RedPine, мы всегда имеем в виду несколько уровней аппаратных и несколько уровней программных составляющих. Это никогда не бывает какая-то простая волшебная коробочка, которая работает сама по себе и может все – это всегда несколько систем, соединенных между собой проводной или беспроводной связью. Наша платформа является достаточно гибкой для построения узкоспециализированных решений. Причем эта гибкость касается и используемых систем связи, и применяемого оборудования всех уровней, и даже пользовательского интерфейса — все можно кастомизировать и настроить под особые задачи.

    Как все это работает на реальном объекте? Об этом уже в следующем материале.
    RedPine
    8,50
    Системы мониторинга, диспетчеризации и учета
    Поделиться публикацией

    Комментарии 12

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

        Я уточню, какую информацию мы можем раскрыть по протоколу RPL и дам комментарий на следующей неделе.
          +4
          Без технических подробностей это просто реклама, её читать не интересно.
            –4
            Кроме технических подробностей у любого продукта есть еще очень много свойств, например его потребительские свойства, принцип работы, состав оборудования (комплектность) и многое другое. Технические подробности важны и интересны (в основном только разработчикам), но, как я уже пояснил, их раскрытие делает нас беззащитными перед конкурентами. Даже продавая подобные комплексные решения, мы можем подписать с клиентом договор о неразглашении, чтобы избежать нежелательных утечек. И, согласитесь, было бы глупо при этом устраивать утечки самостоятельно на страницах блога.

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

            Интересно читать или нет — это вопрос сугубо субъективный. Ваше мнение мне понятно.
              +3
              Это вы не понимаете. ) Вы пишите на ресурсе для технарей и технарь открывает вашу статью в надежде получить\узнать, что то новое и интересное, а в итоге вы пихаете нам свои потребительские характеристики и пол тонны маркетинга, подобная статья вызывает скорее раздражение и явно не вызовет желание купить\заказать.

              Мне кажется это и не понимают все те компании которые платят за блог на хабре\гиктайме. Без смысленная трата времени.

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

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

              Самое читаемое