В прошлой серии...
С год назад я писал про управление городским освещением в одном из наших городов. Там все было очень просто: по расписанию включали и выключали питание светильников через ШУНО (шкаф управления наружным освещением). В ШУНО стояло реле, по команде которого включалась цепочка фонарей. Из интересного, пожалуй, лишь то, что делалось это через LoRaWAN.
Как вы помните, изначально мы строились на модулях СИ-12 (рис. 1) от компании Вега. Еще на этапе пилота у нас сразу появились проблемы.
Рисунок 1. — Модуль СИ-12
И вот теперь…
На данный момент мы построили куда более продвинутый проект.
Он базируется на модулях IS-Industry (рис. 2). Железо разработано нашим аутсорсером, прошивку писали сами. Это очень умный модуль. В зависимости от прошивки, которая на него загружена, он может управлять освещением или опрашивать приборы учета с большим набором параметров. Например, теплосчетчики или трехфазные счетчики электроэнергии.
Несколько слов о том, что реализовано.
Рисунок 2. — Модуль IS-Industry
1. Отныне, IS-Industry имеет собственную память. С прошивкой для света в эту память удаленно загружаются так называемые стратегии. По сути — это график включения-выключения ШУНО на определенный период. Более мы не зависим от радиоканала при включении-выключении. Внутри модуля есть расписание по которому он отрабатывает независимо ни от чего. Каждая отработка обязательно сопровождается командой на сервер. Сервер должен знать, что у нас сменилось состояние.
2. Этот же модуль умеет опрашивать электросчетчик в ШУНО. Каждый час от него приходят пакеты с потреблением и целой кучей параметров, которые может выдавать прибор учета.
Но соль не в этом. Через две минуты после смены состояния отсылается внеочередная команда с мгновенными показаниями счетчика. По ним мы можем судить о том, что свет действительно включился или выключился. Или что-то пошло не так. В интерфейсе есть два индикатора. Переключатель показывает текущее состояние модуля. Лампочка завязана на отсутствие или наличие потребления. Если эти состояния противоречат друг другу (модуль выключен, но потребление идет и наоборот), то строка с ШУНО подсвечивается красным и создается авария (рис. 3). Осенью, такая система помогла нам найти заклинившее реле-пускатель. По сути проблема не у нас, наш модуль отработал корректно. Но мы работаем в интересах заказчика. Потому должны показывать ему любые аварии, из-за которых могут быть проблемы с освещением.
Рисунок 3. — Потребление противоречит состоянию реле. Потому, строка подсвечена красным
По часовым показаниям строятся графики.
Логика такая же, как и в прошлый раз. Отслеживаем факт включения ростом потребления электроэнергии. Отслеживаем медиану потребления. Потребление ниже медианы — перегорела часть фонарей, выше — крадут электроэнергию со столба.
3. Штатные пакеты с информацией о потреблении и о том, что модуль в порядке. Приходят в разное время и не создают толкучку в эфире.
4. Как и раньше, мы можем принудительно включить или выключить ШУНО в любое время. Необходимо, допустим, для поиска сгоревшего фонаря в цепочке аварийной бригадой.
Подобные улучшения в разы увеличивают отказоустойчивость.
Данная модель управления сейчас, пожалуй, самая востребованная в России.
А еще…
Мы ходили и дальше.
Дело в том, что можно вообще отойти от ШУНО в классическом понимании и управлять каждым фонарем в отдельности.
Для этого необходимо, чтобы фонарь поддерживал протокол диммирования (0-10, DALI или какой-то другой) и имел разъем Nemo-socket.
Nemo-socket – это стандартный 7-пиновый разъем (на рис 4), который часто используют в уличном освещении. Из фонаря на этот разъем выводится питание и интерфейсные контакты.
Рисунок 4. — Nemo-socket
0-10 — это многим известный протокол управления освещением. Уже не молодой, но хорошо себя зарекомендовавший. Благодаря командам по этому протоколу мы можем не просто включить-выключить светильник, но еще и перевести его в режим диммирования. Проще говоря, приглушить свет, не выключая его совсем. Приглушить можем на определенное значение в процентах. 30 или 70 или 43.
Работает это так. Сверху в Nemo-socket устанавливается наш модуль управления. Этот модуль поддерживает работу с протоколом 0-10. Команды приходят через LoRaWAN по радоканалу (рис. 5).
Рисунок 5. — Фонарь с модулем управления
Что может этот модуль?
Он умеет включать и выключать светильник, диммировать его на определенную величину. А еще он умеет отслеживать потребление светильника. В случае диммирования, наблюдается падение потребляемого тока.
Теперь мы отслеживаем не просто цепочку из фонарей, мы управляем и отслеживаем КАЖДЫЙ фонарь. И, разумеется, по каждому из фонарей можем получить определенную ошибку.
Кроме того, можно значительно усложнить логику стратегий.
К примеру. Мы сообщаем светильнику №5, что он должен включаться в 18-00, в 3-00 диммироваться на 50 процентов до 4-50, далее вновь включиться на сто процентов и выключиться в 9-20. Все это легко настраивается у нас в интерфейсе и формируется в понятную для светильника стратегию работы. Эта стратегия заливается на светильник и он работает по ней до поступления других команд..
Как и в случае с модулем для ШУНО, у нас нет проблем с пропаданием радиосвязи. Даже если с ней случится что-то критичное, освещение продолжит работать. Кроме того, нет толкучки в эфире в момент, когда надо зажечь, скажем, сто светильников. Мы можем спокойно обходить их по очереди снимая показания и корректируя стратегии. Кроме того, с определенной периодичностью настроены сигнальные пакеты о том, что устройство живо и готово выходить на связь.
Внеплановое обращение будет лишь в случае аварии. Благо, что в данном случае у нас есть такая роскошь, как постоянное питание и мы можем позволить себе класс С.
Важный вопрос, который я вновь подниму. Каждый раз, когда мы презентуем нашу систему, меня спрашивают — а фотореле? Фотореле можно туда прикрутить?
Чисто технически — проблем нет. Но все заказчики, с которыми мы сейчас общаемся, категорически отказываются брать информацию с фотодатчиков. Просят оперировать лишь расписанием и астрономическими формулами. Все-таки городское освещение — это критично и важно.
А теперь самое главное. Экономика.
Работа с ШУНО через радиомодуль имеет явные преимущества, относительно низкую стоимость. Повышает уровень контроля над светильниками и упрощает обслуживание. Тут все понятно и экономическая выгода очевидна.
А вот с управлением каждым светильником все сложнее.
В России есть несколько подобных реализованных проектов. Их интеграторы гордо сообщают, что за счет диммирования удалось достичь экономии электроэнергии и таким способом окупить проект.
Наш опыт показывает, что не все так однозначно.
Ниже я привожу таблицу с расчетом окупаемости от диммирования в рублях в год и в месяцах на один светильник (рис. 6).
Рисунок 6. — Расчет экономии от диммирования
В ней приведено, сколько часов в день горит освещение, усреднено по месяцам. Считаем, что примерно 30 процентов этого времени светильник светит на 50 процентов мощности и еще 30 процентов — на 30 процентов мощности. Остальное на полной мощности. Округлено до десятых.
Для простоты я считаю, что в режиме 50 процентов мощности светильник потребляет половину того, что потребляет на 100 процентах. Это тоже немного неверно, т. к. есть потребление драйвера, которое постоянно. Т.е. реальная экономия у нас выйдет меньше, чем в таблице. Но для простоты восприятия, пусть будет так.
Цену за киловатт электроэнергии возьмем в 5 рублей, средняя цена для юрлиц.
Итого, за год на одном светильнике реально сэкономить от 313 рублей до 1409 руб. Как видим, на устройствах малой мощности выгода совсем крошечная, с мощными осветителями поинтереснее.
Что с затратами?
Удорожание каждого фонаря, при добавлении к нему модуля LoRaWAN, составляет порядка 5500 руб. Там сам модуль около 3000, плюс стоимость Nemo-Socket на светильнике еще 1500 руб, плюс работы по установке и настройке. Это я еще не учитываю, что за такие светильники надо платить абонплату владельцу сети.
Получается, что окупаемость системы составляет в лучшем случае (при самом мощном светильнике) чуть меньше четырех лет. Окупаемость. Долго.
Но даже в этом случае, все на нет сведет абонплата. А без нее в стоимость еще придется закладывать поддержание сети LoRaWAN, что так же не дешево.
Есть еще небольшая экономия в работе аварийных бригад, которые теперь планируют работу куда оптимальней. Но она не спасет.
Получается, все зря?
Нет. На самом деле, правильный ответ здесь такой.
Управление каждым фонарем — это часть умного города. Та часть, которая впрямую не экономит, и за которую даже приходится немного доплачивать. Но взамен мы получаем важную вещь. В такой архитектуре у нас появляется постоянное гарантированное питание на каждом столбе круглые сутки. Не только ночью.
Почти каждый провайдер сталкивался с проблемой. Надо сделать wi-fi на главной площади. Или видеонаблюдение в парке. Администрация дает добро и выделяет опоры. Но вот беда — опоры осветительные и электроэнергия там есть только ночью. Приходится что-то мудрить, тянуть по опорам дополнительное питание, ставит аккумуляторы и прочие странные вещи.
В случае управления каждым фонарем мы на столб с фонарем спокойно можем повесить что-то еще и сделать его «умным».
И вот тут снова вопрос экономики и применимости. Где-то на задворках города ШУНО хватит за глаза. В центре имеет смысл построить что-то более сложное и управляемое.
Главное, чтобы в этих расчетах были указаны реальные цифры, а не мечты про Интернет Вещей.
P. S. За этот год мне удалось пообщаться со многими инженерами, занятыми в сфере освещения. И некоторые доказывали мне, что экономика в управлении каждым светильником все же есть. Я открыт к дискуссии, мои расчеты приведены. Если сможете доказать обратное, я обязательно об этом напишу.
С год назад я писал про управление городским освещением в одном из наших городов. Там все было очень просто: по расписанию включали и выключали питание светильников через ШУНО (шкаф управления наружным освещением). В ШУНО стояло реле, по команде которого включалась цепочка фонарей. Из интересного, пожалуй, лишь то, что делалось это через LoRaWAN.
Как вы помните, изначально мы строились на модулях СИ-12 (рис. 1) от компании Вега. Еще на этапе пилота у нас сразу появились проблемы.
Рисунок 1. — Модуль СИ-12
- Мы зависели от сети LoRaWAN. Серьезная помеха в эфире или падение сервера и у нас беда с городским освещением. Маловероятно, но возможно.
- СИ-12 имеет лишь импульсный вход. К нему можно подключить электросчетчик и считывать с него текущие показания. Но на коротком промежутке времени (5-10 минут) невозможно отследить скачок потребления, который происходит после включения фонарей. Ниже поясню, почему это важно.
- Беда посерьезнее. Модули СИ-12 стабильно зависали. Примерно один раз на 20 сработок. В связке с Вегой мы пытались устранить причину. За время пилота было выпущено две новые прошивки модуля и новая версия сервера, где пофиксили несколько серьезных проблем. Под конец, модули виснуть перестали. И все же от них мы отошли.
И вот теперь…
На данный момент мы построили куда более продвинутый проект.
Он базируется на модулях IS-Industry (рис. 2). Железо разработано нашим аутсорсером, прошивку писали сами. Это очень умный модуль. В зависимости от прошивки, которая на него загружена, он может управлять освещением или опрашивать приборы учета с большим набором параметров. Например, теплосчетчики или трехфазные счетчики электроэнергии.
Несколько слов о том, что реализовано.
Рисунок 2. — Модуль IS-Industry
1. Отныне, IS-Industry имеет собственную память. С прошивкой для света в эту память удаленно загружаются так называемые стратегии. По сути — это график включения-выключения ШУНО на определенный период. Более мы не зависим от радиоканала при включении-выключении. Внутри модуля есть расписание по которому он отрабатывает независимо ни от чего. Каждая отработка обязательно сопровождается командой на сервер. Сервер должен знать, что у нас сменилось состояние.
2. Этот же модуль умеет опрашивать электросчетчик в ШУНО. Каждый час от него приходят пакеты с потреблением и целой кучей параметров, которые может выдавать прибор учета.
Но соль не в этом. Через две минуты после смены состояния отсылается внеочередная команда с мгновенными показаниями счетчика. По ним мы можем судить о том, что свет действительно включился или выключился. Или что-то пошло не так. В интерфейсе есть два индикатора. Переключатель показывает текущее состояние модуля. Лампочка завязана на отсутствие или наличие потребления. Если эти состояния противоречат друг другу (модуль выключен, но потребление идет и наоборот), то строка с ШУНО подсвечивается красным и создается авария (рис. 3). Осенью, такая система помогла нам найти заклинившее реле-пускатель. По сути проблема не у нас, наш модуль отработал корректно. Но мы работаем в интересах заказчика. Потому должны показывать ему любые аварии, из-за которых могут быть проблемы с освещением.
Рисунок 3. — Потребление противоречит состоянию реле. Потому, строка подсвечена красным
По часовым показаниям строятся графики.
Логика такая же, как и в прошлый раз. Отслеживаем факт включения ростом потребления электроэнергии. Отслеживаем медиану потребления. Потребление ниже медианы — перегорела часть фонарей, выше — крадут электроэнергию со столба.
3. Штатные пакеты с информацией о потреблении и о том, что модуль в порядке. Приходят в разное время и не создают толкучку в эфире.
4. Как и раньше, мы можем принудительно включить или выключить ШУНО в любое время. Необходимо, допустим, для поиска сгоревшего фонаря в цепочке аварийной бригадой.
Подобные улучшения в разы увеличивают отказоустойчивость.
Данная модель управления сейчас, пожалуй, самая востребованная в России.
А еще…
Мы ходили и дальше.
Дело в том, что можно вообще отойти от ШУНО в классическом понимании и управлять каждым фонарем в отдельности.
Для этого необходимо, чтобы фонарь поддерживал протокол диммирования (0-10, DALI или какой-то другой) и имел разъем Nemo-socket.
Nemo-socket – это стандартный 7-пиновый разъем (на рис 4), который часто используют в уличном освещении. Из фонаря на этот разъем выводится питание и интерфейсные контакты.
Рисунок 4. — Nemo-socket
0-10 — это многим известный протокол управления освещением. Уже не молодой, но хорошо себя зарекомендовавший. Благодаря командам по этому протоколу мы можем не просто включить-выключить светильник, но еще и перевести его в режим диммирования. Проще говоря, приглушить свет, не выключая его совсем. Приглушить можем на определенное значение в процентах. 30 или 70 или 43.
Работает это так. Сверху в Nemo-socket устанавливается наш модуль управления. Этот модуль поддерживает работу с протоколом 0-10. Команды приходят через LoRaWAN по радоканалу (рис. 5).
Рисунок 5. — Фонарь с модулем управления
Что может этот модуль?
Он умеет включать и выключать светильник, диммировать его на определенную величину. А еще он умеет отслеживать потребление светильника. В случае диммирования, наблюдается падение потребляемого тока.
Теперь мы отслеживаем не просто цепочку из фонарей, мы управляем и отслеживаем КАЖДЫЙ фонарь. И, разумеется, по каждому из фонарей можем получить определенную ошибку.
Кроме того, можно значительно усложнить логику стратегий.
К примеру. Мы сообщаем светильнику №5, что он должен включаться в 18-00, в 3-00 диммироваться на 50 процентов до 4-50, далее вновь включиться на сто процентов и выключиться в 9-20. Все это легко настраивается у нас в интерфейсе и формируется в понятную для светильника стратегию работы. Эта стратегия заливается на светильник и он работает по ней до поступления других команд..
Как и в случае с модулем для ШУНО, у нас нет проблем с пропаданием радиосвязи. Даже если с ней случится что-то критичное, освещение продолжит работать. Кроме того, нет толкучки в эфире в момент, когда надо зажечь, скажем, сто светильников. Мы можем спокойно обходить их по очереди снимая показания и корректируя стратегии. Кроме того, с определенной периодичностью настроены сигнальные пакеты о том, что устройство живо и готово выходить на связь.
Внеплановое обращение будет лишь в случае аварии. Благо, что в данном случае у нас есть такая роскошь, как постоянное питание и мы можем позволить себе класс С.
Важный вопрос, который я вновь подниму. Каждый раз, когда мы презентуем нашу систему, меня спрашивают — а фотореле? Фотореле можно туда прикрутить?
Чисто технически — проблем нет. Но все заказчики, с которыми мы сейчас общаемся, категорически отказываются брать информацию с фотодатчиков. Просят оперировать лишь расписанием и астрономическими формулами. Все-таки городское освещение — это критично и важно.
А теперь самое главное. Экономика.
Работа с ШУНО через радиомодуль имеет явные преимущества, относительно низкую стоимость. Повышает уровень контроля над светильниками и упрощает обслуживание. Тут все понятно и экономическая выгода очевидна.
А вот с управлением каждым светильником все сложнее.
В России есть несколько подобных реализованных проектов. Их интеграторы гордо сообщают, что за счет диммирования удалось достичь экономии электроэнергии и таким способом окупить проект.
Наш опыт показывает, что не все так однозначно.
Ниже я привожу таблицу с расчетом окупаемости от диммирования в рублях в год и в месяцах на один светильник (рис. 6).
Рисунок 6. — Расчет экономии от диммирования
В ней приведено, сколько часов в день горит освещение, усреднено по месяцам. Считаем, что примерно 30 процентов этого времени светильник светит на 50 процентов мощности и еще 30 процентов — на 30 процентов мощности. Остальное на полной мощности. Округлено до десятых.
Для простоты я считаю, что в режиме 50 процентов мощности светильник потребляет половину того, что потребляет на 100 процентах. Это тоже немного неверно, т. к. есть потребление драйвера, которое постоянно. Т.е. реальная экономия у нас выйдет меньше, чем в таблице. Но для простоты восприятия, пусть будет так.
Цену за киловатт электроэнергии возьмем в 5 рублей, средняя цена для юрлиц.
Итого, за год на одном светильнике реально сэкономить от 313 рублей до 1409 руб. Как видим, на устройствах малой мощности выгода совсем крошечная, с мощными осветителями поинтереснее.
Что с затратами?
Удорожание каждого фонаря, при добавлении к нему модуля LoRaWAN, составляет порядка 5500 руб. Там сам модуль около 3000, плюс стоимость Nemo-Socket на светильнике еще 1500 руб, плюс работы по установке и настройке. Это я еще не учитываю, что за такие светильники надо платить абонплату владельцу сети.
Получается, что окупаемость системы составляет в лучшем случае (при самом мощном светильнике) чуть меньше четырех лет. Окупаемость. Долго.
Но даже в этом случае, все на нет сведет абонплата. А без нее в стоимость еще придется закладывать поддержание сети LoRaWAN, что так же не дешево.
Есть еще небольшая экономия в работе аварийных бригад, которые теперь планируют работу куда оптимальней. Но она не спасет.
Получается, все зря?
Нет. На самом деле, правильный ответ здесь такой.
Управление каждым фонарем — это часть умного города. Та часть, которая впрямую не экономит, и за которую даже приходится немного доплачивать. Но взамен мы получаем важную вещь. В такой архитектуре у нас появляется постоянное гарантированное питание на каждом столбе круглые сутки. Не только ночью.
Почти каждый провайдер сталкивался с проблемой. Надо сделать wi-fi на главной площади. Или видеонаблюдение в парке. Администрация дает добро и выделяет опоры. Но вот беда — опоры осветительные и электроэнергия там есть только ночью. Приходится что-то мудрить, тянуть по опорам дополнительное питание, ставит аккумуляторы и прочие странные вещи.
В случае управления каждым фонарем мы на столб с фонарем спокойно можем повесить что-то еще и сделать его «умным».
И вот тут снова вопрос экономики и применимости. Где-то на задворках города ШУНО хватит за глаза. В центре имеет смысл построить что-то более сложное и управляемое.
Главное, чтобы в этих расчетах были указаны реальные цифры, а не мечты про Интернет Вещей.
P. S. За этот год мне удалось пообщаться со многими инженерами, занятыми в сфере освещения. И некоторые доказывали мне, что экономика в управлении каждым светильником все же есть. Я открыт к дискуссии, мои расчеты приведены. Если сможете доказать обратное, я обязательно об этом напишу.
