«Тупой» способ строительства «Умных» городов

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

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

Проблема сегодняшнего дня

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

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

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

Выберите другой путь

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

Мы используем различные материалы и архитектуру для строительства зданий разного назначения (больницы, жилые дома, высотные здания), но даже в этих разных зданиях существует последовательность стандартных механических и инженерных коммуникаций. В проектах "умного города" может быть использована такая же схема проектирования. Это означает, что для проекта парковки город может выбрать наиболее подходящую технологию связи, но потребовать, чтобы система была построена на открытых стандартных протоколах, лежащих в основе Интернета (например, HTTP, IP, TCP и MQTT), использовала форматы данных, такие как JSON или XML, и имела открытые API.

Больше, чем сумма частей

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

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

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

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

Сдерживание поставщиков и защита будущего

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

Вместо этого открытые стандарты и API обеспечивают возможность внедрения и развития новых технологий и систем. Но, как и в случае с привязкой к поставщику, вы можете столкнуться с привязкой к технологии. Представьте, что вы построили проект "умного города", требующий использования видеопленки, а теперь не можете использовать потоковые технологии из-за их несовместимости. Технологии быстро меняются; всего за несколько лет мы перешли от 2G к 3G, а теперь и к 5G в сотовой связи. Использование открытых стандартов для разделения протоколов верхнего уровня и нижних уровней позволяет развивать технологии, и системы, использующие более старые технологии, могут легко соединяться между собой. Таким образом, система, развернутая сегодня с использованием 4G, может взаимодействовать с системами 5G завтра, а через несколько лет - с системами 6G и 7G.

Основа инноваций

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

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

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

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

Кто владеет данными - то есть, вашими данными

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

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

Выбор правильного проекта

Приняв открытые стандарты и API, вы теперь можете приступить к реализации проекта "умного города" без необходимости решать все другие городские проекты одновременно или ограничивать их выбором, сделанным сегодня. Но выбор "правильного" проекта очень важен. В некоторых случаях разумно выбрать небольшой, быстрый, малозатратный проект. Это позволит вам намочить ноги, протестировать поставщиков, выполнить проект за короткое время и, надеюсь, добиться успеха; но если вы потерпите неудачу, то потерпите быстро, научитесь и двигайтесь дальше. Однако иногда с такими проектами возникает проблема: они могут иметь незначительное влияние, и это может привести к тому, что другие будут смотреть на них как на "пустышку".

Альтернативный вариант - выбрать проект, который является большой "болевой точкой" для города. По определению, такие проекты имеют большую видимость и влияние, но могут иметь гораздо больший риск и требуют гораздо больше времени для завершения. Они, как правило, не соответствуют правилам lean-agile, но небольшие "безопасные" проекты могут не продемонстрировать истинные преимущества, которые может принести "умный город". Решите эту проблему, используя метод "разделяй и властвуй". Вместо того чтобы внедрять "умную" парковку во всем городе, сосредоточьтесь на особенно перегруженном участке города или отдельной парковочной структуре.

Успех в строительстве Умных Городов

Когда город становится умнее, инвестируя в проект "Умный город", используйте этот контрольный список для оценки проекта:

• Начинается ли он с малого и хорошо ли масштабируется? Это лучше, чем монолитное решение, требующее гигантских инвестиций.
• Не привязывает ли он город к технологиям или, что еще хуже, к поставщикам? Исключает ли он других поставщиков?
• Является ли оно открытым? Какие протоколы используются? Опубликованы ли и открыты ли API?
• Упоминает ли поставщик о шлюзах или требует их?
• Решает ли он проблему для города быстро, даже если это небольшая проблема?
• Чему город сможет научиться, взявшись за этот проект?
• Кому принадлежат данные?

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

Блокчейн в Умном Городе 

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

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