Заглянем на пару секунд в прошлое — в предыдущих статьях мы говорили о базовой философии и ключевых особенностях платформы 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, мы всегда имеем в виду несколько уровней аппаратных и несколько уровней программных составляющих. Это никогда не бывает какая-то простая волшебная коробочка, которая работает сама по себе и может все – это всегда несколько систем, соединенных между собой проводной или беспроводной связью. Наша платформа является достаточно гибкой для построения узкоспециализированных решений. Причем эта гибкость касается и используемых систем связи, и применяемого оборудования всех уровней, и даже пользовательского интерфейса — все можно кастомизировать и настроить под особые задачи.

Как все это работает на реальном объекте? Об этом уже в следующем материале.

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