Заглянем на пару секунд в прошлое — в предыдущих статьях мы говорили о базовой философии и ключевых особенностях платформы RedPine. Мы старались выяснить «что это?» и «зачем это?». Ну а теперь пришло время начать приглядываться к деталям продукта и приступать к погружению на более глубокие уровни.
И на следующем уровне у нас с вами расположился обзор базовых элементов платформы, и особенностей их взаимодействия — мы поговорим о священном союзе софта и железа.
В основе таких продуктов, как RedPine должно лежать правильное взаимодействие между программной и аппаратной частями — не простая совместимость друг с другом, а крепкая дружба между железом, софтом и человеком. Иначе проблем может получиться больше, чем пользы.
Ранее мы уже касались некоторых программных и аппаратных моментов, но тематика систем мониторинга весьма многогранна, и рассказать сразу обо всем практически нереально. Поэтому мы постепенно погружаемся глубже в эту историю, последовательно приближаясь к полной ясности.
И теперь мы разберем систему мониторинга RedPine на составляющие, и попробуем рассмотреть каждую часть в отдельности — ее функции, ее особенности, ее место в общей картине. В качестве примера, я предлагаю вашему вниманию вот такую иллюстрацию:
Базовые части системы RedPine (пример)
На этом своеобразном параде планет видно, что все решение делится не просто на программную и аппаратную части (софт и железо), но и сами эти части имеют разные уровни и отвечают за разные функции. Это действительно важный момент, т.к. правильное распределение функций напрямую влияет на общую производительность системы. Шестеренки на картинке призваны символизировать связь между уровнями и элементами — это тоже очень важный момент, о котором ниже скажу подробнее.
С вашего позволения, в дальнейшем программную часть я иногда буду называть «софтом» или «ПО», а аппаратную часть — «железом». Думаю, что так всем будет проще.
Естественно, каждый элемент важен и вносит свой вклад в работу всей системы. Но одинаков ли их вклад? Нет, не одинаков, и оценить его в каких-либо единицах весьма проблематично. Это можно сделать лишь условно, и если мы придумаем некую процентную шкалу весомости вклада в систему, то увидим такую картину:
Долевое участие основных элементов системы в общем решении
Эта иллюстрация показывает лишь приблизительное распределение значимости базовых элементов системы RedPine, но улучшает понимание основного принципа — программное обеспечение верхнего уровня является центром и основой решения, а находится оно не на удаленном объекте, а в условном центре управления.
Под железом верхнего уровня мы имеем в виду компьютерную технику различного форм-фактора, серверное оборудование и устройства, обеспечивающие связь между верхним и нижним уровнями. Это железо может быть не только частью решения RedPine, но и может параллельно выполнять какие-то другие функции (офисные дела, просмотр youtube, пасьянс), требование лишь одно — техника должна соответствовать минимальным требованиям выбранного типа решения.
Мы пока не будем подробно останавливаться не деталях, чтобы не рушить структуру сегодняшнего материала. Если любопытно, то типичные виды решений можно посмотреть в специальном разделе на официальном сайте RedPine.
С точки зрения реализации систем мониторинга, учета и управления, на верхнем уровне с железом все несколько проще, чем на уровне нижнем, ведь — тут нет ограничения по производителям и форм-фактору, а существующая компьютерная техника легко справляется со многими задачами. Например, в случае работы с онлайн-интерфейсом ПО верхнего уровня, Вам понадобится самый простой ноутбук, планшет или смартфон и выход в сеть – больше никаких требований нет.
А вот с железом нижнего уровня все сложнее. Тут нет готового оборудования на рынке, которое без проблем подошло бы для наших целей, а значит требуется разработка и производство такого оборудования.
В наших планах не значилось налаживание производства контроллеров своими силами, поэтому задача сводилась к поиску подходящего производителя, и мы достаточно долго подбирали того, кто смог бы не просто создать и производить устройство по нашей спецификации, но и осуществлять адекватную поддержку своей продукции. Рассматривались и европейские, и китайские, и российские производители.
Ко всем мы обращались с одними и теми же исходными данными:
Повторюсь, нам нужно было не готовое решение, а производство нашего собственного, но на элементной базе производителя.
В результате отбора победило решение от Wiren Board. Отмечу, что прочие кандидаты оказались не только хуже в выполнении наших требований — они просто не смогли их все выполнить, поэтому и выбор для нас был очевиден.
Я не буду заниматься антирекламой и называть тех, кто был отсеян, т.к. для других задач их решение может оказаться даже более пригодным, а не подошли они только нам. К тому же, мы никого не вычеркнули из списка потенциальных партнеров и вполне можем когда-нибудь с ними посотрудничать, ведь все очень быстро меняется в современном мире.
Но сегодня мы выбираем Wiren Board. И функционал, и форм-фактор, и гибкость, и хорошая поддержка нас полностью устроили. Нельзя сказать, что цена этого варианта низка, но и требования у нас были не низкими. Мы понимаем, что все хорошее стоит денег, и на данном этапе соотношение цены и результата нас устраивает.
Отрадно, что многие из читателей Geektimes в нашей прошлой статье сразу же узнали платформу Wiren Board — это было приятным моментом и подтвердило популярность данного производителя промышленных микрокомпьютеров. Со своей стороны мы пока можем дать только положительные отзывы об их продукте, и надеемся, что так будет всегда.
Даже если все элементы верхних и нижних уровней работают, как часы (не в том смысле, что время показывают, а в смысле точности), они должны работать еще и сообща друг с другом, как хорошая команда.
Коммуникация — это очень важная часть любого взаимодействия, и ее качество напрямую влияет на качество всего решения. На сторонних решениях мы часто видели, что вопросам связи уделяется ничтожно мало внимания, что сильно сужало область применения, и это досадное упущение было одним из главных импульсов для разработки нашей платформы RedPine.
В своем продукте мы подошли к вопросам коммуникаций со всей серьезностью — это касается как самих способов передачи информации, так и правильного сжатия и пакетирования данных для избежания потерь и проблем с недостаточной пропускной способностью канала связи.
Устройство нижнего уровня с коммуникационными портами
На железе нижнего уровня есть все необходимые интерфейсы для передачи данных: GSM, 3G RS 485, 232, TCP/IP. Они могут функционировать по отдельности или одновременно и без проблем работают со слабыми каналами связи. Даже если оборудование находится в тундре или тайге, оно будет на связи. При необходимости (или по желанию заказчика), система может быть дооборудована другими коммуникационными интерфейсами.
За безопасность информации отвечает собственный протокол передачи данных RPL, объединяющий в себе протокол шифрования, проверку контрольных сумм потока данных, резервное хранение данных в собственной памяти до момента получения от сервера подтверждения о получении. Ничего не пропадет и не потеряется в пути.
RedPine можно легко интегрировать в существующие информационные системы при помощи протоколов Modbus и SNMP, а железо нижнего уровня можно использовать в качестве дополнительного шлюза.
Главная задача ПО верхнего уровня – быть неким хабом, связующим звеном между железом верхнего уровня, софтом нижнего уровня и человеком.
То есть софт верхнего уровня должен обеспечить необходимое взаимодействие пользователя со всеми элементами системы мониторинга и диспетчеризации. Он является одновременно мозгом и лицом RedPine, а значит должен быть одновременно умным, удобным и симпатичным.
Сначала о мозге, который скрыт от пользователя. Тут мы не использовали готовых решений, и все пришлось писать с чистого листа. Это ПО отвечает за хранение, обработку, анализ и передачу данных между различными элементами верхнего и нижнего уровней и, кроме прочего, нам было критически важно, чтобы все это было оптимизировано и быстро работало на различном «железе». Плохая оптимизация может одним махом загубить даже самый лучший функционал, т.к. этим богатым функционалом нельзя будет воспользоваться.
Интерфейс системы мониторинга и управления дизель-генераторной установкой (Мнемосхема)
Теперь обратимся к лицу системы. Тут внешний вид важен, и он нужен не только для красоты – все должно быть понятно и удобно для ежедневного использования людьми без особой подготовки. Непонятный интерфейс, по сути, играет против пользователя, заставляя делать ошибки, которые иногда могут оказаться фатальными и вылиться в крупные финансовые потери. Именно из этого понимания и исходили наши разработчики при проектировании визуальной части ПО верхнего уровня. О пользовательском интерфейсе RedPine я как-нибудь еще расскажу, не будем сейчас уходить в сторону от главной темы. Впрочем, можете сами прямо сейчас посмотреть его на демо-версии (ссылка) – ее интрефейс ничем не отличается от базовых реальных версий.
Поскольку ПО нижнего уровня работает на железе нижнего уровня, то оно должно общаться с ним на одном языке. Как раз поэтому у нас и были требования к производителю контроллера, которые касались используемой операционной системы и внутренних алгоритмов работы устройства.
Этот софт отвечает за получение команд от ПО верхнего уровня, их обработку и передачу на исполнительные устройства аппаратной части нижнего уровня, такие как контроллер, модули расширения и дополнительное навесное оборудования (датчики, управляющие элементы и пр.). А также и за обратный путь – данные, получаемые от железа нижнего уровня нужно обработать и передать на верхний уровень.
Тут необходимо особо подчеркнуть одну из важных функцию софта нижнего уровня — он преобразует всевозможные сигналы с различного оборудования (по типу, по производителю, по логике работы, по году выпуска) в единый формат данных, позволяющих контролировать и управлять таким «разношерстным» оборудованием из единого центра. Это одна из ключевых функций, которую мы не нашли в других системах мониторинга, что и подтолкнуло нас к созданию собственной.
Пользовательский интерфейс тут отсутствует, т.к. это внутренняя кухня платформы, а управление происходит через интерфейс верхнего уровня. Получить непосредственный доступ к ПО нижнего уровня может только авторизованный персонал.
…
Когда мы говорим о комплексном решении RedPine, мы всегда имеем в виду несколько уровней аппаратных и несколько уровней программных составляющих. Это никогда не бывает какая-то простая волшебная коробочка, которая работает сама по себе и может все – это всегда несколько систем, соединенных между собой проводной или беспроводной связью. Наша платформа является достаточно гибкой для построения узкоспециализированных решений. Причем эта гибкость касается и используемых систем связи, и применяемого оборудования всех уровней, и даже пользовательского интерфейса — все можно кастомизировать и настроить под особые задачи.
Как все это работает на реальном объекте? Об этом уже в следующем материале.
И на следующем уровне у нас с вами расположился обзор базовых элементов платформы, и особенностей их взаимодействия — мы поговорим о священном союзе софта и железа.
В основе таких продуктов, как RedPine должно лежать правильное взаимодействие между программной и аппаратной частями — не простая совместимость друг с другом, а крепкая дружба между железом, софтом и человеком. Иначе проблем может получиться больше, чем пользы.
Состав программно-аппаратного комплекса
Ранее мы уже касались некоторых программных и аппаратных моментов, но тематика систем мониторинга весьма многогранна, и рассказать сразу обо всем практически нереально. Поэтому мы постепенно погружаемся глубже в эту историю, последовательно приближаясь к полной ясности.
И теперь мы разберем систему мониторинга RedPine на составляющие, и попробуем рассмотреть каждую часть в отдельности — ее функции, ее особенности, ее место в общей картине. В качестве примера, я предлагаю вашему вниманию вот такую иллюстрацию:
Базовые части системы RedPine (пример)
На этом своеобразном параде планет видно, что все решение делится не просто на программную и аппаратную части (софт и железо), но и сами эти части имеют разные уровни и отвечают за разные функции. Это действительно важный момент, т.к. правильное распределение функций напрямую влияет на общую производительность системы. Шестеренки на картинке призваны символизировать связь между уровнями и элементами — это тоже очень важный момент, о котором ниже скажу подробнее.
С вашего позволения, в дальнейшем программную часть я иногда буду называть «софтом» или «ПО», а аппаратную часть — «железом». Думаю, что так всем будет проще.
Естественно, каждый элемент важен и вносит свой вклад в работу всей системы. Но одинаков ли их вклад? Нет, не одинаков, и оценить его в каких-либо единицах весьма проблематично. Это можно сделать лишь условно, и если мы придумаем некую процентную шкалу весомости вклада в систему, то увидим такую картину:
Долевое участие основных элементов системы в общем решении
Эта иллюстрация показывает лишь приблизительное распределение значимости базовых элементов системы RedPine, но улучшает понимание основного принципа — программное обеспечение верхнего уровня является центром и основой решения, а находится оно не на удаленном объекте, а в условном центре управления.
«Железо» верхнего уровня
Под железом верхнего уровня мы имеем в виду компьютерную технику различного форм-фактора, серверное оборудование и устройства, обеспечивающие связь между верхним и нижним уровнями. Это железо может быть не только частью решения RedPine, но и может параллельно выполнять какие-то другие функции (офисные дела, просмотр youtube, пасьянс), требование лишь одно — техника должна соответствовать минимальным требованиям выбранного типа решения.
Мы пока не будем подробно останавливаться не деталях, чтобы не рушить структуру сегодняшнего материала. Если любопытно, то типичные виды решений можно посмотреть в специальном разделе на официальном сайте RedPine.
С точки зрения реализации систем мониторинга, учета и управления, на верхнем уровне с железом все несколько проще, чем на уровне нижнем, ведь — тут нет ограничения по производителям и форм-фактору, а существующая компьютерная техника легко справляется со многими задачами. Например, в случае работы с онлайн-интерфейсом ПО верхнего уровня, Вам понадобится самый простой ноутбук, планшет или смартфон и выход в сеть – больше никаких требований нет.
«Железо» нижнего уровня
А вот с железом нижнего уровня все сложнее. Тут нет готового оборудования на рынке, которое без проблем подошло бы для наших целей, а значит требуется разработка и производство такого оборудования.
В наших планах не значилось налаживание производства контроллеров своими силами, поэтому задача сводилась к поиску подходящего производителя, и мы достаточно долго подбирали того, кто смог бы не просто создать и производить устройство по нашей спецификации, но и осуществлять адекватную поддержку своей продукции. Рассматривались и европейские, и китайские, и российские производители.
Ко всем мы обращались с одними и теми же исходными данными:
- Необходима разработка контроллера под наши нужды и требования
- ПО верхнего и нижнего уровня нашей разработки
- Операционная система контроллера на базе linux
- Наладить выпуск контроллеров по нашей спецификации в мелкосерийном режиме
- Быстрые сроки производства
- Быстрая реакция техподдержки
- Гибкость – готовность к изменениям в продукте
- Удобный форм-фактор в плане монтажа и использования
Повторюсь, нам нужно было не готовое решение, а производство нашего собственного, но на элементной базе производителя.
В результате отбора победило решение от Wiren Board. Отмечу, что прочие кандидаты оказались не только хуже в выполнении наших требований — они просто не смогли их все выполнить, поэтому и выбор для нас был очевиден.
Я не буду заниматься антирекламой и называть тех, кто был отсеян, т.к. для других задач их решение может оказаться даже более пригодным, а не подошли они только нам. К тому же, мы никого не вычеркнули из списка потенциальных партнеров и вполне можем когда-нибудь с ними посотрудничать, ведь все очень быстро меняется в современном мире.
Но сегодня мы выбираем Wiren Board. И функционал, и форм-фактор, и гибкость, и хорошая поддержка нас полностью устроили. Нельзя сказать, что цена этого варианта низка, но и требования у нас были не низкими. Мы понимаем, что все хорошее стоит денег, и на данном этапе соотношение цены и результата нас устраивает.
Отрадно, что многие из читателей Geektimes в нашей прошлой статье сразу же узнали платформу Wiren Board — это было приятным моментом и подтвердило популярность данного производителя промышленных микрокомпьютеров. Со своей стороны мы пока можем дать только положительные отзывы об их продукте, и надеемся, что так будет всегда.
Связь между нижним и верхним уровнями
Даже если все элементы верхних и нижних уровней работают, как часы (не в том смысле, что время показывают, а в смысле точности), они должны работать еще и сообща друг с другом, как хорошая команда.
Коммуникация — это очень важная часть любого взаимодействия, и ее качество напрямую влияет на качество всего решения. На сторонних решениях мы часто видели, что вопросам связи уделяется ничтожно мало внимания, что сильно сужало область применения, и это досадное упущение было одним из главных импульсов для разработки нашей платформы RedPine.
В своем продукте мы подошли к вопросам коммуникаций со всей серьезностью — это касается как самих способов передачи информации, так и правильного сжатия и пакетирования данных для избежания потерь и проблем с недостаточной пропускной способностью канала связи.
Устройство нижнего уровня с коммуникационными портами
На железе нижнего уровня есть все необходимые интерфейсы для передачи данных: GSM, 3G RS 485, 232, TCP/IP. Они могут функционировать по отдельности или одновременно и без проблем работают со слабыми каналами связи. Даже если оборудование находится в тундре или тайге, оно будет на связи. При необходимости (или по желанию заказчика), система может быть дооборудована другими коммуникационными интерфейсами.
За безопасность информации отвечает собственный протокол передачи данных RPL, объединяющий в себе протокол шифрования, проверку контрольных сумм потока данных, резервное хранение данных в собственной памяти до момента получения от сервера подтверждения о получении. Ничего не пропадет и не потеряется в пути.
RedPine можно легко интегрировать в существующие информационные системы при помощи протоколов Modbus и SNMP, а железо нижнего уровня можно использовать в качестве дополнительного шлюза.
«Софт» верхнего уровня
Главная задача ПО верхнего уровня – быть неким хабом, связующим звеном между железом верхнего уровня, софтом нижнего уровня и человеком.
То есть софт верхнего уровня должен обеспечить необходимое взаимодействие пользователя со всеми элементами системы мониторинга и диспетчеризации. Он является одновременно мозгом и лицом RedPine, а значит должен быть одновременно умным, удобным и симпатичным.
Сначала о мозге, который скрыт от пользователя. Тут мы не использовали готовых решений, и все пришлось писать с чистого листа. Это ПО отвечает за хранение, обработку, анализ и передачу данных между различными элементами верхнего и нижнего уровней и, кроме прочего, нам было критически важно, чтобы все это было оптимизировано и быстро работало на различном «железе». Плохая оптимизация может одним махом загубить даже самый лучший функционал, т.к. этим богатым функционалом нельзя будет воспользоваться.
Интерфейс системы мониторинга и управления дизель-генераторной установкой (Мнемосхема)
Теперь обратимся к лицу системы. Тут внешний вид важен, и он нужен не только для красоты – все должно быть понятно и удобно для ежедневного использования людьми без особой подготовки. Непонятный интерфейс, по сути, играет против пользователя, заставляя делать ошибки, которые иногда могут оказаться фатальными и вылиться в крупные финансовые потери. Именно из этого понимания и исходили наши разработчики при проектировании визуальной части ПО верхнего уровня. О пользовательском интерфейсе RedPine я как-нибудь еще расскажу, не будем сейчас уходить в сторону от главной темы. Впрочем, можете сами прямо сейчас посмотреть его на демо-версии (ссылка) – ее интрефейс ничем не отличается от базовых реальных версий.
«Софт» нижнего уровня
Поскольку ПО нижнего уровня работает на железе нижнего уровня, то оно должно общаться с ним на одном языке. Как раз поэтому у нас и были требования к производителю контроллера, которые касались используемой операционной системы и внутренних алгоритмов работы устройства.
Этот софт отвечает за получение команд от ПО верхнего уровня, их обработку и передачу на исполнительные устройства аппаратной части нижнего уровня, такие как контроллер, модули расширения и дополнительное навесное оборудования (датчики, управляющие элементы и пр.). А также и за обратный путь – данные, получаемые от железа нижнего уровня нужно обработать и передать на верхний уровень.
Тут необходимо особо подчеркнуть одну из важных функцию софта нижнего уровня — он преобразует всевозможные сигналы с различного оборудования (по типу, по производителю, по логике работы, по году выпуска) в единый формат данных, позволяющих контролировать и управлять таким «разношерстным» оборудованием из единого центра. Это одна из ключевых функций, которую мы не нашли в других системах мониторинга, что и подтолкнуло нас к созданию собственной.
Пользовательский интерфейс тут отсутствует, т.к. это внутренняя кухня платформы, а управление происходит через интерфейс верхнего уровня. Получить непосредственный доступ к ПО нижнего уровня может только авторизованный персонал.
…
Продолжение следует...
Когда мы говорим о комплексном решении RedPine, мы всегда имеем в виду несколько уровней аппаратных и несколько уровней программных составляющих. Это никогда не бывает какая-то простая волшебная коробочка, которая работает сама по себе и может все – это всегда несколько систем, соединенных между собой проводной или беспроводной связью. Наша платформа является достаточно гибкой для построения узкоспециализированных решений. Причем эта гибкость касается и используемых систем связи, и применяемого оборудования всех уровней, и даже пользовательского интерфейса — все можно кастомизировать и настроить под особые задачи.
Как все это работает на реальном объекте? Об этом уже в следующем материале.