Русский
Русский
English
Статистика
Реклама

Bms

Мониторинг в ЦОДе как мы меняли старую BMS на новую. Часть 4

20.04.2021 16:13:49 | Автор: admin

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

Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной?

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

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

В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.

Немного теории

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

А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например 220 Вольт или 10 Ампер.

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

Аварии по показателю приоритетности обычно делятся на три основных типа: Красная, Желтая и Голубая. Красные аварии требуют немедленных действий сотрудников, Желтые о чем-то их предупреждают, Голубые чаще всего сообщают о каких-то некритичных событиях. Например, мы вывели Голубые аварии из сводки, которую видят дежурные, и используем их для мониторинга различных коммерческих параметров (превышение заказанной мощности). Отчеты по этим авариям направляются только менеджерам и не отвлекают дежурных.

Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, OutputCurrent) имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте она меняется везде.


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

Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии Overload Alarm. И это совсем другая переменная, не связанная с переменной OutputCurrent, настроенной в BMS.

Пример заводских настроек уставок внутри PDU:


Итак, мы перечислили основной функционал для настройки системы мониторинга.

Как же правильно настроить это пианино? Давайте рассмотрим задачи по порядку.

Чего мы хотим добиться

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

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

Этап 1. Определение нужных и ненужных переменных у каждого устройства

Обычно к каждому устройству идет так называемая карта переменных, на основании которой инженером-наладчиком создается драйвер. Его задача указать системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя System_on_fun, а в регистре 2 о режиме работы компрессора Compressor_1.

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

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

  • Лишние переменные загружают оперативную задачу системы мониторинга и увеличивают размер архива, система вынуждена обрабатывать и сохранять ненужные данные.

  • Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний нет данных (Н/Д) или обрыв связи, то есть фактически устройство периодически выпадает из мониторинга.

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

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



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

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

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

Этап 2. Минимизация ложных и неинформативных сообщений

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

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

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

Неинформативные аварии чаще всего возникают при переходных процессах. Их нельзя назвать ложными они на самом деле есть, но они нормальны при каком-то конкретном режиме работы оборудования. Самый очевидный пример переход на ДГУ.

В этом случае часть оборудования, запитанного без ИБП, штатно обесточивается и выдает ошибку обрыв связи, а сами ИБП выдают целый букет сообщений нет питания на вводе, нет питания на байпасе, питание от АКБ и т. п. Персонал сразу получает десятки сообщений.

Для оптимизации количества сообщений при переходе на ДГУ следует:

  • настроить на штатно появляющиеся во время перехода аварийные сигналы более длительные временные задержки, чем время появления питания от ДГУ. Например, установить задержку на сигнал обрыв связи щита вентиляции 300 секунд при штатном времени перехода на ДГУ 200 секунд.

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

  • проанализировать сообщения от ИБП при переходе на ДГУ и разделить их на нормальные с присвоением им желтого типа (например, констатация факта нет питания на вводе) и ненормальные (отключение батарейного автомата, которого быть не должно в любом режиме работы), с присвоением им красного типа.

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

За один раз, полагаясь только на теорию, настроить уставки для этого переходного процесса очень сложно. Для успешной настройки надо несколько раз наблюдать за переходами на ДГУ в реальном времени.

Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.

Этап 3. Дополнительные советы из нашего опыта

1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений.

Пример из реальной практики. Один ЦОД заказал карту температурных потоков в серверной. Это 3D модель потоков воздуха с множеством температурных данных с датчиков. Получился вид северной с потоками воздуха где-то воздух был выделен зеленым, где-то желтым и красным (от самого холодного к самому горячему). При этом температуры воздуха везде в пределах нормы, а цвета применены только для наглядности отображения разницы температур в разных точках.

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

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

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

2. С осторожностью используйте SMS-оповещения.

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

3. Настраивайте дублирование сообщений об авариях через мессенджер.

Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер).

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

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

4. Группируйте сообщения в мессенджерах.

Во время перехода на ДГУ или из-за комплексной аварии у вас будут запущены десятки активных аварийных ситуаций, телефон будет постоянно вибрировать от поступающих в мессенджер сообщений, не давая сделать важный звонок или открыть окно системы мониторинга.

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

5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.

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

На скриншоте пример индикации о пропадании связи с сервером BMS, при этом отображаются неактуальные параметры работы оборудования.


6.Подключайте к мониторингу как можно больше систем.

Например, традиционно система пожарной сигнализации работает автономно, а ее панель висит на посту охраны.

Да, по сигналу ПОЖАР срабатывают автоматические алгоритмы работы систем, запускается система оповещения, но о появлении сигналов Неисправность или Внимание сотрудник охраны сообщает дежурным голосом.

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

Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала ПОЖАР в системе BMS ЦОДа, подключенного через сухие контакты.


Подведем итоги нашей 4-серийной истории

Система мониторинга дата-центра это не просто глаза и уши для наблюдения за инженерными системами ЦОДа. Ее правильная работа позволяет достигать высочайшего уровня надежности через непрерывность работы площадки, а, значит, обеспечивает компании дополнительное конкурентное преимущество.

Пройдя довольно трудный и длинный путь, мы получили:

  • быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2500 устройств и обсчитывает около 10000 виртуальных датчиков;
  • резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве;
  • доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты;
  • ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей;
  • надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам гибко настраиваемую и масштабируемую систему мониторинга.
Подробнее..

Что не так с интерфейсами SCADA-систем

08.11.2020 16:19:40 | Автор: admin

В этой статье хочу рассказать и поделиться своим мнением насчет пользовательских интерфейсов scada-систем и систем диспетчеризации в целом.

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

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

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

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

Пример интерфейса, собранного из готовых библиотекПример интерфейса, собранного из готовых библиотекПример интерфейса диспетчеризации теплового пунктаПример интерфейса диспетчеризации теплового пункта

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

Это моя любимаяЭто моя любимая

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

Для начала посмотрим, какие интерфейсы наши коллеги делают для умных домов:

Пример интерфейса, с сайта iridiummobileПример интерфейса, с сайта iridiummobile

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

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

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

Анализатор качества электроэнергии, фото из интернетаАнализатор качества электроэнергии, фото из интернета

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

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

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

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

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

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

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

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

В конце концов, сейчас у всех в руках смартфоны с современными ОС и приложениями люди давно уже привыкли к хорошим качественным интерфейсам, а мы заставляем их возвращаться в прошлое во времена Windows 98.

Немного резюмируя

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

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

Что будем делать?

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

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

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

Панель оператора системы приточно-вытяжной вентиляции. 2017 год. 7 дюймов разрешение 800 х 480Панель оператора системы приточно-вытяжной вентиляции. 2017 год. 7 дюймов разрешение 800 х 480

Цвета подобрали из палитры material design, отрисовали заново все иконки, сделали ровные и кратные отступы, подобрали шрифт и его размер. Тогда мы еще использовали трехмерные картинки и анимацию.

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

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

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

Та же панель, но уже в актуальном дизайне, 2020г годТа же панель, но уже в актуальном дизайне, 2020г год

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

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

Рабочее место инженера, монитор 27 дюймов, разрешение 1920 х 1080Рабочее место инженера, монитор 27 дюймов, разрешение 1920 х 1080Развернутое окно с настройками системы вентиляцииРазвернутое окно с настройками системы вентиляции

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

Подробнее о создании интерфейса диспетчеризации

Еще один очень значимый проект для меня мы реализовали в 2018 году это крупный ТРЦ в Московской области. На примере этого проекта поделюсь своим опытом и знаниями, надеюсь, кому-то это будет полезно.

Главное окно системы диспетчеризации вентиляцииГлавное окно системы диспетчеризации вентиляции

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

Топология

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

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

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

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

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

Цвета и темы

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

Да и в целом темная тема проще для восприятия и меньше нагружает глаза, тем более при длительном использовании, тем более в темном помещение.

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

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

Шрифты и отступы

Тут все проще, используем GothamPro, только двух размеров: для подписей и статики 14 рх Medium, а для переменных 18 рх Bold.

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

Еще несколько окон с этого объекта.

Некоторые свежие наработки конца 2020 года.

Заключение

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

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

Подробнее..

Моя эволюция интерфейсов систем диспетчеризации

30.05.2021 20:12:29 | Автор: admin

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

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

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

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

Лонгрид!

2014

Главное окно с мнемосхемой на сенсорной панеле управления 7 дюймовГлавное окно с мнемосхемой на сенсорной панеле управления 7 дюймовОсновное меню с настройками на сенсорной панеле управления 7 дюймовОсновное меню с настройками на сенсорной панеле управления 7 дюймовОкно диспетчеризации, можно открыть на любом устройстве под управлением WindowsОкно диспетчеризации, можно открыть на любом устройстве под управлением Windows

Это индивидуальный тепловой пункт одного из павильонов ВДНХ в Москве, первый самостоятельный объект, где можно было проявить творческий подход. В помещении ИТП на шкафу управления установлена 7 дюймовая сенсорная панель для локального управления и облачная система диспетчеризации. Несмотря на то, что в этом интерфейсе довольно все криво и сыро, здесь есть много элементов и правил, которым мы придерживаемся до сих пор.

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

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

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

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

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

2015

Приточно-вытяжная установка с гликолевым рекуператором. Панель оператора 10 дюймов.Приточно-вытяжная установка с гликолевым рекуператором. Панель оператора 10 дюймов.

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

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

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

2016

Станция ВЗУ коттеджного поселка. Панель оператора 10 дюймов.Станция ВЗУ коттеджного поселка. Панель оператора 10 дюймов.

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

На объектах, где есть технология, возникают проблемы в отрисовке из-за использования трехмерной графики. Одно дело показать насосы, клапан, фильтры и заслонки, другое дело показать технологическое оборудование. Найти в интернете подходящие картинки ультрафиолетовых ламп и фильтров очистки крайне сложно, не говоря уже о более сложном оборудовании: флотаторы, жироловки, обезвоживатели и так далее. Это одна из причин, почему мы отказались от 3Д в дальнейшем.

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

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

2017

Производственно-складской комплекс, МО, обзорная схема, 27 дюймовПроизводственно-складской комплекс, МО, обзорная схема, 27 дюймовПроизводственно-складской комплекс, МО, под экран планшета и ноутбукаПроизводственно-складской комплекс, МО, под экран планшета и ноутбука

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

2018

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

Основное отличие подхода к разработке этого интерфейса от предыдущих, это то, как рисуется вся статика. До этого интерфейс собирался по частям в среде разработки для панелей и в Scada системе, это очень усложняет процесс, особенно, выравнивание объектов. Здесь же вся статика делается в графическом редакторе и подгружается одной картинкой PNG на экран. Сверху накладываются только переменные и анимация. Это сразу убивает несколько зайцев: выравнивать и делать отступы можно с большой точностью, скорость загрузки страниц увеличивается, так как нужно меньше информации подгружать из памяти, уменьшается нагрузка на процессор.

С точки зрения дизайна, тут появилось много нового. Появился не стандартный шрифт GothamPro, цвета теперь не рандомные, а подобраны из палитр Material Design, появились кратные отступы и сетка. Объекты теперь выровнены все относительны друг друга. Поля индикации и ввода значения уже стали существенно различаться, к этому быстро привыкаешь и пользоваться становится удобно.

Что осталось от прежних интерфейсов? Структура меню, она не поменялась, иконки стали меньше и аккуратнее, теперь они гармонично вписались в общую стилистику. Иконки на главном окне с мнемосхемой остались прежние, но сама мнемосхема слегка упростилась и стала чуть более плоской. Это был последний год использования этих иконок и 3Д элементов в целом.

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

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

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

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

Что касается главного экрана, то здесь реализован "карточный" интерфейс. Смысл его в том, чтобы структурировать информацию по системам, на каждую сделать свою карточку и разместить ее на схеме здания. Если систем много, можно разделить их по нескольким экранам, если не много, то можно все показать на одном экране и отделить разные схемы цветами. На карточке нужно отображать только самые основные параметры, которые влияют на работоспособность установки и которые можно сравнивать между собой. Для вентиляции наиболее важными параметрами являются: статус работы, наличие аварий, режим зима/лето, температура канала, помещения и обратной воды. Дополнительно стараемся отображать обороты вентилятора, процент открытия клапана и задание уставки температуры. Эти значения позволяют быстро оценить стабильность работы вентсистем и теплоснабжения установок, не переходя к схемам каждой системы отдельно. Очень удобно на одном экране сравнивать параметры работы разных систем. Если, например, наблюдается недогрев по многим системам, значит есть проблемы с теплоснабжением из котельной.

У нас есть объекты, которые имеют один этаж и там удобно все карточки систем размещать на планировке здания, привязывая к их реальному местоположению на плане. Есть объекты в 4-5 этажей, и здесь становится сложнее структурировать карточки. Можно разделить экран на 4 равных части и на каждом отобразить свой этаж с системами. Можно сделать 4 экрана, на каждом свой этаж с нанесенным на нем системами, но здесь могут быть нюансы, как правило, большая часть систем располагается на -1 этаже и на последнем или кровле, что приводит к сильному дисбалансу. Мы пробовали разные варианты, расскажу об этом чуть дальше в статье.

2019

Приточно-вытяжная установка, панель оператора 7 дюймовПриточно-вытяжная установка, панель оператора 7 дюймовМенюшка, панель 7 дюймовМенюшка, панель 7 дюймов

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

Здесь мы опять решили пересмотреть дизайн интерфейса и внести что-то новое. Наконец-то полностью ушли от 3Д, теперь у нас все плоское. Идея была уйти от 3Д, тем самым убрать лишние не информативные элементы со схемы, освободить ценное место и структурировать информацию не по графическим элементам, а по карточкам. Раньше, чтобы показать информацию о теплоснабжение установки (работа насоса, клапана, температура обратной воды) нужно было нарисовать целый узел с трубами, насосом, перемычками и прочим, это занимает много места и несет мало информации. Теперь вся эта информация находится в карточке "нагрев", точно так же структурированы и другие карточки систем. Такая структура дает унификацию интерфейса, если появится система, например, с дополнительным увлажнением или ступенью нагрева, то мы просто добавим новую карточку с нужной информацией, при этом интерфейс будет выглядеть одинаково преемственно на разных устройствах и разрешениях. Точно так же легко унифицируются и различные системы, вентиляция, отопление, освещение, энергетика, водоснабжение и так далее, все это легко приводится к одному стандарту и упрощает взаимодействие пользователя.

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

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

  1. Освобождаем интерфейс от всего лишнего, уменьшаем количество статических элементов, убираем все 3Д. Структурируем содержание по карточкам или вкладкам, оставляем больше места для динамических значение.

  2. Наводим порядок в цветах для удобства взаимодействия пользователя с интерфейсом. Оттенки темного цвета используются для фона, полей и заголовков, серым обозначаются подписи и весь текст в целом. Белый это переменные и все динамические значения. Яркий синий это цвет акцента, им обозначаются все элементы, с которыми пользователь может взаимодействовать, кнопки и уставки. И стандартные цвета: зеленый, желтый и красный, отвечают за состояние и индикацию.

Диспетчеризация торгово-развлекательного центра, окно вентустановки, монитор 32 дюймаДиспетчеризация торгово-развлекательного центра, окно вентустановки, монитор 32 дюймаСводное окно венткамеры, монитор 32 дюймаСводное окно венткамеры, монитор 32 дюймаГлавный экран с обзорной схемой вентустановок, монитор 32 дюйма.Главный экран с обзорной схемой вентустановок, монитор 32 дюйма.

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

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

Здесь очень удачно планировка ТЦ вписалась в разрешение Scada системы примерно 1920 х 980 рх., это позволило расположить максимум полезной информации с привязкой к физическому местоположению. Так как систем много (около 150 штук) то лучший вариант разбить их по венткамерам, где находятся щиты управления, отобразить системы как название и подкрашивать его в зависимости от состояния. Серый выведен из эксплуатации, белый стоянка, зеленая работает, желтая требует обслуживания, красный авария. Дальше архитектура строится так: при клике на венткамеру открывается табличный вид связанных систем с их основными параметрами. При клике на название системы уже откроется мнемосхема со всеми доступными параметрами и настройками.

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

2020

Приточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовПриточно-вытяжная установка с увлажнением, монитор 25 дюймовОбзорная схема системы диспетчеризации, медицинский центр, монитор 23 дюймаОбзорная схема системы диспетчеризации, медицинский центр, монитор 23 дюймаОбзорная схема системы диспетчеризации ТРЦ Рассвет, Москва, монитор 23 дюймаОбзорная схема системы диспетчеризации ТРЦ Рассвет, Москва, монитор 23 дюймаМнемосхема приточно-вытяжной установки.Мнемосхема приточно-вытяжной установки.

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

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

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

Если вы дочитали до этого места, то скорее всего обратили внимание, что впервые появился светлый интерфейс =). Появилась очень интересная идея сделать универсальный интерфейс с темной и светлой темой и переключать его либо автоматически от времени суток, либо вручную. Реализовали эту идею так: подложки на 95 процентов прозрачные с небольшим оттенком серого, статические элементы имеют цвета не сильно контрастирующие на темном и светлом фоне, переменные имеют подобранный серый цвет, больше контрастирующий на темном и светлом фоне. По сути, мы только меняем цвет фона с белого на темно серый, а все элементы остаются без изменения. С точки зрения работы Scada системы процесс максимально простой, подмена одного фона на другой, без замены других элементов, это не перегружает процесс работы и отрисовки. У такого решения есть минус, сложно подобрать цвета одинаково правильно отображающиеся тут и там, от этого переменные немного теряются на общем фоне. Есть вариант вместе с фоном менять скриптами и цвета переменных и других элементов, но не понятно насколько это может загрузить процесс отрисовки.

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

2021

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

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

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

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

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

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

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

2022

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

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

Подробнее..

Кейс аналитика системы освещения в логистическом центре

17.06.2021 20:21:19 | Автор: admin

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

Клиент: крупный логистический центр в Московской Области, с которым мы работаем с 2016 года. За это время мы провели уже много работ по диспетчеризации инженерных систем, вывели в единую BMS вентиляцию, котельную, энергетику, отопление, энергоучет и много чего еще. А в этом году решили добавить еще и диспетчеризацию освещения в общую систему.

Что имеем? Установлен силовой шкаф управления освещением на 45 линий: складские ряды, коридоры, мезонин. На каждой линии установлен автомат защиты и модульный контактор. Помимо силового щита есть щит управления с ручным и автоматическим управлением. Автоматическое управление подразумевает включение и выключение линии по датчику движения, которые установлены в рядах, где двигается техника. Некоторые линии находятся в ручной режиме и постоянно включены, а некоторые, наоборот выключены. Задачу нам поставили следующую: отслеживать работу каждой линии, отслеживать залипание контакторов, оповещать о неисправностях и получать аналитику по наработке. Можно было бы полностью заменить шкафы, сделать дистанционное управление, расписание и много чего еще, но это было бы очень сильное удорожание проекта, а нас попросили именно вписаться в небольшой бюджет не меняя того, что и так работает стабильно.

Задача поставлена, начинаем реализацию. Есть несколько способов отследить работу линии освещения. Самый простой способ это использовать свободный или дополнительный контакт модульного контактора. Но конкретно в нашем случае эта схема не сработает, так как питание катушки контактора идет от общего автомата и возможна ситуация, когда на линии освещения контактор будет замкнут, а автомат выключен и питания на линии не будет. Этот способ будет работать только если питание катушки контактора идет из под автомата этого же контактора. Можно было бы поставить дополнительные контакты положения и сработки к автоматам, это даст более полную картину, но в нашем случае места в шкафу не было от слова совсем и раздвинуть автоматы для дополнительных контактов просто не было возможности. Решили пойти самым надежным путем, взять непосредственно фазу, идущую на питание линии и завести ее на контроллер. Так как у нас большая часть автоматики на объекте сделана на отечественных Контарах, то мы просто взяли модули расширения, которые воспринимают 220 вольт на входе. Это не частая опция у контроллеров, поэтому, если бы стоял другой производитель, пришлось бы ставить 45 промежуточных реле. Получился аккуратный и не большой шкаф диспетчеризации, мы повесили его рядом с силовым шкафом и обвязали все аккуратно многожильным кабелем. Расключение шкафа и отключение света согласовали заранее, а на все работы ушло около 1,5 часов.

Подключаем сигнальные линииПодключаем сигнальные линии

С физикой все просто и понятно, после всех работ мы имеем 45 булевых переменных, которые мы добавили в скаду, настроили им архивацию и оставили это все работать на неделю.

Силовой шкаф до расключенияСиловой шкаф до расключения

Дальше разрабатываем интерфейс пользователя.

Основное окно секции освещения Основное окно секции освещения

Здесь 46 линий разбитые на 2 экрана. Порядковый номер, состояние линии (включена, выключена, неисправна) и комментарий. Внизу есть оперативный график, можно посмотреть, как менялось состояние линии за последний час. Линии можно переключать, на скриншоте выбрана 16 линия.

На этом экране можно получить оперативную информацию о состоянии освещения. Есть отдельные окна трендов и настроек.

Окно с настройкамиОкно с настройками

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

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

Временные трендыВременные тренды

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

Отчет за выбранное времяОтчет за выбранное время

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

Отчет за выбранное времяОтчет за выбранное время

Вторая страница отчета выводит ту же информацию, но в виде диаграмм.

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

Подробнее..

Из песочницы Старый строительный бизнес и новые технологии, или история одного стартапа

25.08.2020 14:18:31 | Автор: admin


Введение


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

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

  • Учет всех приборов квартир
  • Управление подачей теплового носителя по принципу термостата
  • Аналитика потребления
  • Аварии и предупреждения
  • Интерфейс для управляющей компании со всеми объектами
  • Интерфейс для жильцов

Дома строили большие по 20-25 этажей в среднем по 280-300 квартир в секции. Таких домов у застройщика на тот момент было порядка 10.

Приступив к работе, первым делом, я стал разбираться как же работают две системы, уже реализованные на строительных площадках заказчика. Это были две абсолютно разные системы: от протоколов передачи между сервером и полевым оборудованием (у одних CAN-bus, у вторых Modbus RTU и TCP), до самой архитектурой приложений (у одних самописное ПО раскатанное в облаке, у вторых СКАДА для каждого объекта с локальными компьютерами).

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

Апргрейд приложения в области функционала, был невозможен и не потому что очень высокая цена, а потому что они не могли / хотели / знали как посчитать стоимость доработки, да им этого и не надо было. У них был построен бизнес на обслуживании и замене своих устройств.
Мы постоянно платим за ПО, но, что за ПО? Лицензия, покупка ПО по договору, разработка ПО? На все вопросы ответ один ПО наше, пишите письма.

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

Первые решения и договоренности


И так пришел я договариваться со своим руководством директором 1. Предложил сколотить команду для разработки продукта полного цикла разработка проектирование монтаж пуск эксплуатация. Для начала сошлись на том, что берем на работу одного разраба бэка Леху и на аутсорсинг команду веб разработчиков и дизайнеров. Зарплата моя и Лёхи была настолько мала, что стыдно даже думать об этом, но я рискнул по пяти причинам:

  1. Меня никто не знал, и никто толком не могу понять мои способности, я для них был вроде умный малый, но не самостоятельный и очень активный.
  2. Если проект выгорает то я и разраб бэка и его собака в шоколаде! Все будет, как говорил мне директор 1.
  3. Классная возможность попробовать свои силы.
  4. Спасти Леху, он тогда гнил охранником на промышленном объекте.
  5. У нас горели глаза от одной мысли, что мы можем создать нечто подобное.

Первый MVP


На радостях мы покупаем первый контроллер Siemens Modicon MT221 с ModBus TCP на борту, дня четыре писали на него программу на языке Ladder Diagram, в которой при замыкании контактов регистр меняется с 0 на 1, протестили с помощью программки Modbus Poll (грубо говоря Modbus TCP клиент), и тут Леха говорит:
На кафедре нас учили, что такие задачи решаются с помощью SCADA систем
На что я в ответ:
Леха, ты должен был бороться со злом, а не примкнуть к нему.
Мы решили сделать так Леха пробует найти СКАДУ и вытаскивать данные с контроллера и хранить их где то, а я попробую написать программу на Java, я как раз в тот момент проходил курсы Java Elementary (знал бы мой препод с курсов, что я буду пробовать кодить).

И по итогу Леха получил данные с контроллера по ModBus TCP первым, но сложил свой комп с синим экраном из за 4-6 СКАД на компе. А я при помощи Java и 5 строчек кода вытянул данные, Леше понравилось это и он погрузился в мир Java и я с гордостью могу сказать, что он стал очень хорошим специалистом.

Как сейчас помню, 10 марта 2018 года, мы приступили к первому объекту. У нас было 6 месяцев для написания программы, создания дизайна, выпуска проектной документации, монтажа и пуска.

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

Многие не верили в наш успех и не ставили нам конкретных задач, звучало это примерно так:

  • вытащите данные из счётчиков
  • отобразите где-нибудь

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

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

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

  • нету аутентификации с разделением прав
  • отсутствует возможность создать защищенный API к собранным данным
  • дизайн из 90-х
  • низкая производительность
  • низкий уровень кастомизации backend логики
  • неприемлемое ценообразование для решения выбранной задачи

Внутреннее чутьё подсказывало, что если мы будем использовать одну из этих систем, то мы будем ничем не лучше наших конкурентов. Что повело нас по другому пути, прекрасному пути. Мы пошли по пути написания своей системы и продукта на лучшем языке в мире Java и либы EasyModbus. А когда мы немного модифицировали код и заставили консоль сообщать о нажатии кнопки нашим радостям тогда просто не было предела. По дороге домой мы не могли успокоится и обсуждали, сколько нам это может дать возможностей! Мы создадим свою СКАДУ с красивым вэб приложением и умным домом. В тот вечер, мы нарисовали себе планов на год вперед. Но всё было еще впереди

Мы начали с малого, и месяц спустя у нас было готово ПО для контроллера управляющего температурой написанное на FBD. Нашим backend стэком были Java 8 + MySQL. Вскоре, были готовы классы для работы с нашими свободно программируемыми контроллерами. Еще через месяц мы успешно обкатали связку нашего backend'а и шлюза, который опрашивал тепловые счётчики по протоколу M-BUS. Научились работать с MySQL. Начали писать все полученные данные в базу. Для считывания показаний с электросчётчиков по RS-485 интерфейсу (PLC нам не подошел) мы сделали реверс-инжиниринг протокол из исходных данных с монитора USB порта.

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

Для того, чтобы показать начальству серьёзность наших намерений мы собрали стенд, который продемонстрировал работу нашей системы в масштабах всего дома. У нас было 20 контроллеров управления температурой, 150 датчиков температур, 60 тепловых счётчиков (сколько смогли раздобыть), 2 шлюза MBus, роутер и 16 маршрутизаторов. Мы 2 дня только обжимали FTP кабеля. В итоге стенд собран, ПО сконфигурировано, mock вебинтерфейса запущен директор едет к нам смотреть работу.


Первый стенд

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

В итоге нам понадобилось пол года чтобы у нас были интегрированы в систему 144 квартиры и первые пользователи, которым мы лично вручили QR-коды регистрации. Но на этом мы не хотели останавливаться, наша конечная задача была создание IoT платформы заточенную под BMS, а в последующем расширится до интегрирования технических объектов (котельных, тепловых пунктов, задовов и производств) и умных домов.

Следующий год мы провели за рефакторингом нашего MVP и добавлением различных фич. В этот раз у нас был план, архитектура, еще большие амбиции и свежая кровь взяли на работу 2-ух студентов. Первый студент, Ярик, работал над backend'ом нашего продукта, а второй, Сашка, занимался наработками на Arduino и прочих одноплатных компьютеров для умного дома.

Мы активно шерстили рынок УД и BMS: общались с потенциальными заказчиками, ездили на выставки, сравнивали себя с конкурентами. В какой-то момент мы поняли что то, что мы создали является феноменом для украинского рынка, и никто из потенциальных конкурентов не может ничего подобного что можем предложить мы. У нас масштабируемая и кастомизируемая система BMS, с мощной системой квитирования аварий и администрирования, с API, с драйверами на самые популярные устройства учета в Украине, можем подстроится под любого заказчика. Мы хотели вырваться из под нашей компании и идти самостоятельно.

Первый успех и сразу кастрюлей по лицу


Итак на первых парах успеха, уже реализуем 3 объект (на данный момент в системе крутится 2 котельные, 4 тепловых пункта, 4452 ед. различных приборов учета, данные с 1164 квартир), все хорошо, приложения не валяться, оборудование ведет себя очень хорошо, монтаж на высоте все круто, я и команда ждем премий и бонусовно, вместо этого просто Эгегей парни, молодцы, СПАСИБО!.


Пожал мне руку директор, сел в свой новый Х5 и уехал

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

В итоге директор 1 уходит с компании застройщика, я с командой ухожу тоже, наш продукт остался на старых объектах, новых объектов нет, но куда идти? Что делать? Мы так завязли в рутине разработки, что я упустил момент правого поля (кому, что принадлежит, чье ПО, какие права использования ПО), продвижения и прочих моментов так необходимых для успешного существования продукта. Я бросаю все моменты связанные с разработкой и кидаюсь в исследования рынка, пытаюсь найти заказчиков, и понимаю, что наш продукт очень специфичен для застройщиков, не всем он нужен у всех застройщиков один слоган, за меньшие деньги построил больше денег получил.

Тут появляется мой директор, и предлагает создать компанию учредители которой будет он и его компаньон, но при этом якобы я и моя команда находятся в его половине компании (50%), по договоренностям М (он, я и команда) будем решать все что касается дольнейшего развитие продукта, принимать как и куда нам двигаться (ну так между нами девочками нигде это не фигурирует в бумагах). Я в отчаянии соглашаюсь, команде говорю ребята мы нашли инвестора, бла-бла, но мы не входим в состав учредителей, и первое время получаем крошечные ЗП (ну типо стартап как они мне сказали), максимально сокращаем издержки (ну стартап который длится уже два года, ничего так себе стартапчик). Ребята с команды сказали: Может не надо, пахнет странно это все., но я горю (у меня долги по фонду ЗП, второй ребенок и прочие издержки), я понимаю, что надо продолжать любой ценой.

Знакомлюсь с директором 2, и понимаю, что что-то не то, ну как могло быть по другому. Пару проведенных встреч и я понял, что директор 2 в 90-ые был программистом в армии и очень хотел реализоваться в этой области, он начинает нам рисовать схемы с местом диспетчера, с сервером 1С, кидать красивые слова, везде вставлять слово API, заказывать так необходимые в этот момент брендинги и бренд буки.

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

Продержались мы так месяц, точнее я продержался. Общался с директорами 1,2 только я, потому что моя цель была оградить мою команду от их постоянных встреч, постоянных попыток накидать каких то задач и прочей бюрократии. Вечно я слышал от директора 2: Чем занимаетесь? Что делаете?, мы в ответ: доменную модель пилим, тестим LoRa Wan, исследуем рынок в части лидеров мнений и канал реализации продуктов, делаем дизайн дашбордов для аварий и предупреждений, никаких конструктивных вопросов в ответ далее не поступало. Вечное недоверие и чувство дискомфорта, ну как тут продолжать создавать классный продукт.

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

Чувства и остаток


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

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

Выводы и советы


Выводы которые я сделал:

  • Не зная броду не лезь в воду, особенно когда вопрос денежный. Все проверь, посчитай, прикинь cash flow, не ошибись в объеме работы и самое главное в технологии и целесообразности ее применения. Как бы не странно говори с командой, и не забывай про стратегию, пусть она будет сырая, не объемная, но она нужна.
  • Страх неудачи постоянен, даже когда ты попробовал и у ты получил положительный результат. Нужно просто научится жить с ним, топить его чем то. Но всегда надо помнить, земля круглая, сегодня прет, завтра может быть картина другая.
  • Семья это главное. Верьте своей семье.
  • Не будет у вас на пути честных искренних людей, особенно в вопросах денежных. Ну хорошо будут, но мало.
  • Если у вас есть возможность собираться в крутые команды и делать, что то что кому то нужно и вам это нравится, то делайте это, веселясь, радуясь, эмоционально споря, только так рождаются лучшие продукты.
  • Учитесь работать с людьми бизнеса, нужно учится говорить с ними, понимать их, чувствовать их. Успех в деле зависит на 90% от отношений.
  • Весь старый бизнес работает по каскадной методологии развития продукта, взять даже директоров 1 и 2, они строители и для них была дикость быстрее зарелизится с сайтом без нового брендинга, собрать фидбэк, аналитику и потом быстро внести правки в сайт. Нет, они давили, что сначала все надо проработать, точное ТЗ, и сидим потом кодим на протяжении 5 лет, как в СССР. Они не понимали, что время был тот фактор, который решал все (как раз в тот момент при общении с многими застройщиками я слышал, что они сами приступали разрабатывать свое ПО). Строители программисты это хуже скайнета из терминатора.
  • Сразу договаривайтесь и оговаривайте все условия.

Что же дальше


Сейчас мы пилим новую платформу, расширяем функционал (добавляем домократию и сервисы для жильцов, инструменты аналитики и более проработанный интерфейс управления и котельной), добавляем новые приборов учета и устройства.

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

Всем мира и успехов!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru