По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Из предыдущих статей (тут и тут) мы узнали, что очень немногие механизмы, учитывают изменения в топологии. Большинство этих решений ориентированы на вычисления loop-free пути через очевидно стабильную сеть. Но что происходит при изменении топологии? Как сетевые устройства создают таблицы, необходимые для пересылки пакетов по loop-free путям в сети?
В этой серии статей мы рассмотрим очередную подзадачу этой всеобъемлющей проблемы и ответим на вопрос: Как плоскости управления обнаруживают изменения в сети и реагируют на них?
На этот вопрос мы ответим, рассмотрев две составляющие процесса конвергенции в плоскости управления. Процесс конвергенции в сети может быть описан в четыре этапа. Рисунок 1 используется для справки при описании этих четырех стадий. Как только связь [C,E] выходит из строя, должны произойти четыре этапа: обнаружение, распространение, вычисление и установка.
Обнаружение изменения: будь то включение нового устройства или линии связи, или удаление устройства или линии связи, независимо от причины, изменение должно быть обнаружено любыми подключенными устройствами. На рисунке 1 устройства C и E должны обнаруживать отказ канала [C, E]; когда линия восстанавливается, они также должны обнаружить включение этой (очевидно новой) линии связи в топологию.
Распространение информации об изменении: каждое устройство, участвующее в плоскости управления, должно каким-то образом узнавать об изменении топологии. На рисунке 1 устройства A, B и D должны каким-то образом уведомляться о сбое канала [C, E]; когда линия будет восстановлена, они должны быть снова уведомлены о включении этой (очевидно новой) линии связи в топологию.
Вычисление нового пути к пункту назначения без петель: на рисунке 1 B и C должны вычислить некоторый альтернативный путь, чтобы достичь пунктов назначения за пределы E (или, возможно, непосредственно самого E).
Установка новой информации о пересылке в соответствующие локальные таблицы: На рисунке 1 B и C должны установить вновь вычисленные loop-free пути к пунктам назначения за пределами E в свои локальные таблицы пересылки, чтобы трафик мог коммутироваться по новому пути.
Далее мы сосредоточимся на первых двух из четырех шагов, описанных в предыдущем списке, размышляя в начале об обнаружении изменений топологии. Будут рассмотрены некоторые примеры протоколов, специализирующихся на обнаружении изменений топологии. Распределение топологии и информации о достижимости будет рассмотрена в конце этой серии статей. Поскольку эта проблема, по сути, является проблемой распределенной базы данных, она будет решаться с этой точки зрения.
Обнаружение изменений топологии
Первым шагом в реакции на изменение топологии сети является обнаружение изменения. Вернемся к рисунку 1. Каким образом два устройства, подключенные к каналу, C и E, обнаруживают сбой канала? Решение этой проблемы не так просто, как может показаться на первый взгляд, по двум причинам: информационная перегрузка и ложные срабатывания.
Информационная перегрузка возникает, когда плоскость управления получает так много информации, что просто не может распространять информацию об изменениях топологии и/или вычислять и устанавливать альтернативные пути в соответствующие таблицы на каждом устройстве достаточно быстро, чтобы поддерживать согласованное состояние сети. В случае быстрых, постоянно происходящих изменений, таких как отключение связи и подключение каждые несколько миллисекунд, плоскость управления может быть перегружена информацией, в результате чего сама плоскость управления потребляет достаточно сетевых ресурсов, чтобы вызвать сбой сети. Также возможно, что серия отказов вызовет петлю положительной обратной связи, и в этом случае плоскость управления “сворачивается” сама по себе, либо реагируя очень медленно, либо вообще отказывая. Решение проблемы информационной перегрузки состоит в том, чтобы скрыть истинное состояние топологии от плоскости управления до тех пор, пока скорость изменения не окажется в пределах, которые может поддерживать плоскость управления.
Ложные срабатывания - это проблема второго типа. Если канал отбрасывает один пакет из каждых 100, и каждый раз отбрасывается единственный пакет, который оказывается пакетом плоскости управления, используемым для отслеживания состояния канала, будет казаться, что канал выходит из строя и довольно часто возобновляет работу - даже если другой трафик перенаправляется по каналу без проблем.
Существует два широких класса решений проблемы обнаружения событий:
Реализации могут периодически отправлять пакеты для определения состояния канала, устройства или системы. Это опрос (Polling).
Реализации могут вызвать реакцию на изменение состояния канала или устройства в некотором физическом или логическом состоянии внутри системы. Это обусловлено событиями.
Как всегда, есть разные компромиссы с этими двумя решениями и подкатегории каждого из них.
Опрос (Polling) для обнаружения сбоев.
Опрос может выполняться удаленно или вне диапазона, или локально, или в группе. Рисунок 2 демонстрирует это.
На рисунке 2 A и B периодически отправляют приветствие или какой-либо другой пакет опроса по тому же каналу, через который они подключены, и по тому же каналу, по которому они пересылают трафик. Это внутриполосный опрос, который имеет преимущество отслеживания состояния канала, по которому пересылается трафик, передается информация о доступности и т. д. С другой стороны, D запрашивает у A и B некоторую информацию о состоянии канала [A, B] из другого места в сети. Например, D может периодически проверять состояние двух интерфейсов на канале [A, B] или, возможно, периодически отправлять пакет по пути [C, A, B, C] и т. д. Преимущество заключается в том, что информация о состоянии большого количества каналов может быть централизована, что упрощает управление сетью и устранение неполадок. Оба типа опроса часто используются в реальных сетевых развертываниях.
Для работы механизмов опроса часто используются два отдельных таймера:
Таймер для определения частоты передачи опроса. Он часто называется интервалом опроса в случае внеполосного опроса и часто называется таймером приветствия в случае внутриполосного опроса.
Таймер, чтобы определить, как долго ждать, прежде чем объявить связь или устройство отключенным, или включить сигнал тревоги. Это часто называют мертвым интервалом или мертвым таймером в случае внутриполосного опроса.
Цели внутриполосного и внеполосного опроса часто различаются. Внеполосный опрос для обнаружения изменений в состоянии сети часто (но не всегда - особенно в случае централизованной плоскости управления) используется для мониторинга состояния сети и позволяет централизованно реагировать на изменения в состоянии. Внутриполосный опрос наиболее часто используется (как и следовало ожидать) для локального обнаружения изменений состояния, чтобы управлять реакцией распределенных плоскостей управления.
Обнаружение сбоев на основе событий
Обнаружение сбоев на основе событий основывается на некотором локальном, измеримом событии для определения состояния конкретного канала или устройства. Рисунок 3 демонстрирует это.
На рисунке 3, который показывает одну из возможных реализаций элементов архитектуры между физическим интерфейсом и протоколом маршрутизации, есть четыре шага:
Связь между двумя микросхемами физического интерфейса (phy), расположенными на обоих концах связи, не работает. Микросхемы физического интерфейса обычно являются оптическими для электрических передач обслуживания. Большинство микросхем физического интерфейса также выполняют некоторый уровень декодирования входящей информации, преобразуя отдельные биты в сети в пакеты (десериализация) и пакеты в биты (сериализация). Информация кодируется физическим интерфейсом на носителе, который предоставляется двумя физическими микросхемами, подключенными к физическому носителю. Если канал не работает или один из двух интерфейсов отключен по какой-либо причине, микросхема физического интерфейса на другом конце канала увидит падение несущей почти в реальном времени - обычно в зависимости от скорости света и длины физического носителя. Это состояние называется потерей носителя.
Микросхема физического интерфейса при обнаружении потери несущей отправляет уведомление в таблицу маршрутизации (RIB) на локальном устройстве. Это уведомление обычно запускается как прерывание, которое затем транслируется в некоторую форму вызова интерфейса прикладного программирования (API) в код RIB, что приводит к тому, что маршруты, доступные через интерфейс, и любая информация о следующем переходе через интерфейс помечаются как устаревшие или удаляются из таблицы маршрутизации. Этот сигнал может или не может проходить через базу пересылаемой информации (FIB) по пути, в зависимости от реализации.
RIB будет уведомлять протокол маршрутизации о маршрутах, которые он только что удалил из локальной таблицы, на основе события отключения интерфейса.
Протокол маршрутизации затем может удалить любых соседей, доступных через указанные интерфейсы (или, скорее, через подключенные маршруты).
На рисунке 3 нет места, в котором бы присутствовал периодический процесс, проверяющий состояние чего-либо, а также не было бы пакетов, перемещающихся по сети. Весь процесс основан на том, что микросхема физического интерфейса теряет носитель на подключенной среде, следовательно, этот процесс управляется событиями.
Часто бывает, что состояние, управляемое событиями, и статус опроса совмещаются. Например, на рисунке 3, если бы станция управления периодически опрашивала статус интерфейса в локальном RIB, процесс от набора микросхем физического интерфейса к RIB был бы управляемым событием, а процесс от RIB на станцию управления будет направлен опросом.
Сравнение обнаружения на основе событий и на основе опроса
Таблица 1 отображает преимущества и недостатки каждого механизма обнаружения событий.
Внеполосный опросВнутриполосный опросУправляемый событиямиРаспределение статусовСтатус управляется централизованной системой; централизованная система имеет более полное представление об общем состоянии сетиСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСвязь состояния пересылки со связью или состоянием устройстваСообщение о состоянии связи и / или устройства может быть ложным; не проверяет возможность пересылки напрямуюСостояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Состояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Скорость обнаруженияПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиНекоторый таймер перед сообщением о сбоях может быть желательным, чтобы уменьшить сообщение о ложных срабатываниях, но этот таймер может быть очень коротким и подкрепляться двойной проверкой состояния самой системы; как правило, гораздо быстрее при сообщении об изменениях сетиМасштабированиеДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахНебольшие объемы текущего локального состояния; имеет тенденцию масштабироваться лучше, чем механизмы опроса
Хотя может показаться, что обнаружение, управляемое событиями, всегда должно быть предпочтительным, есть некоторые конкретные ситуации, когда опрос может решить проблемы, которые не могут быть решены механизмами, управляемыми событиями. Например, одно из главных преимуществ систем, основанных на опросе, особенно при внутриполосном развертывании, заключается в том, чтобы «видеть» состояние невидимых блоков. Например, на рисунке 4 два маршрутизатора соединены через третье устройство, обозначенное на рисунке как ретранслятор.
На рисунке 4 устройство B представляет собой простой физический повторитель. Все, что он получает по каналу [A, B], он повторно передает, как и получил, по каналу [B, C]. На этом устройстве нет какой-либо плоскости управления (по крайней мере, о том, что известно A и C). Ни A, ни C не могут обнаружить это устройство, поскольку оно не изменяет сигнал каким-либо образом, который мог бы измерить A или C.
Что произойдет, если канал [A, B] выйдет из строя, если A и B используют управляемый событиями механизм для определения состояния канала? A потеряет несущую, конечно, потому что физический интерфейс в B больше не будет доступен. Однако C будет продолжать принимать несущую и, следовательно, вообще не обнаружит сбой соединения. Если A и C могут каким-то образом общаться с B, эту ситуацию можно разрешить. Например, если B отслеживает все запросы протокола разрешения адресов (ARP), которые он получает, он может, когда канал [A, B] разрывается, каким-то образом отправить «обратный ARP», уведомляющий B о том, что A больше недоступен. Другое решение, доступное в этой ситуации, - это своего рода опрос между A и C, который проверяет доступность по всему каналу, включая состояние B (даже если A и C не знают, что B существует).
С точки зрения сложности, управляемое событиями обнаружение увеличивает поверхности взаимодействия между системами в сети, в то время как опрос имеет тенденцию сохранять состояние внутри системы. На рисунке 3 должен быть какой-то интерфейс между чипсетом физического интерфейса, RIB и реализацией протокола маршрутизации. Каждый из этих интерфейсов представляет собой место, где информация, которая может быть лучше скрыта через абстракцию, передается между системами, и интерфейс, который должен поддерживаться и управляться. Опрос, с другой стороны, часто может проводиться в рамках одной системы, полностью игнорируя существующие механизмы и технологии.
Пример: обнаружение двунаправленной переадресации
В этом подразделе будет изучен пример протокола, разработанного специально для определения состояния канала в сети. Ни один из этих протоколов не является частью более крупной системы (например, протокола маршрутизации), а скорее взаимодействует с другими протоколами через программные интерфейсы и индикаторы состояния.
Обнаружение двунаправленной переадресации (Bidirectional Forwarding Detection - BFD) основано на одном наблюдении: на типичном сетевом устройстве работает множество плоскостей управления, каждая со своим собственным механизмом обнаружения сбоев. Было бы более эффективно использовать один общий механизм обнаружения для всех различных плоскостей управления. В большинстве приложений BFD не заменяет существующие протоколы приветствия, используемые в каждой плоскости управления, а скорее дополняет их. Рисунок 5 демонстрирует это.
В модели BFD, скорее всего, будет по крайней мере два различных процесса опроса, работающих по одному и тому же логическому каналу (их может быть больше, если есть логические каналы, наложенные поверх других логических каналов, поскольку BFD также может использоваться в различных технологиях сетевой виртуализации). Опрос плоскости управления будет использовать приветствия (hellos) для обнаружения соседних устройств, выполняющих один и тот же процесс плоскости управления, для обмена возможностями, определения максимального блока передачи (MTU) и, наконец, для того, чтобы убедиться, что процесс плоскости управления на соседнем устройстве все еще работает. Эти приветствия проходят через соединение плоскости управления на рисунке 5, которое можно рассматривать как своего рода «виртуальный канал», проходящий через физический канал.
Опрос BFD будет выполняться под соединением уровня управления, как показано на рисунке, проверяя работу физического соединения и плоскостей пересылки (переадресации) на двух подключенных устройствах. Этот двухуровневый подход позволяет BFD работать намного быстрее, даже в качестве механизма опроса, чем любой механизм обнаружения на основе протокола маршрутизации.
BFD может работать в четырех различных режимах:
Асинхронный режим: в этом режиме BFD действует как облегченный протокол приветствия. Процесс BFD в A, потенциально работающий в распределенном процессе (или даже в специализированной интегральной схеме [ASIC]), отправляет пакеты приветствия в C. Процесс BFD в C подтверждает эти пакеты приветствия. Это довольно традиционное использование опроса через hellos.
Асинхронный режим с эхом: в этом режиме процесс BFD в A будет отправлять пакеты приветствия в C, поэтому пакеты приветствия будут обрабатываться только через путь пересылки, что позволяет опрашивать только путь пересылки. Для этого A отправляет пакеты приветствия в C, сформированные таким образом, что они будут переадресованы обратно в A. Например, A может отправить пакет C с собственным адресом A в качестве пункта назначения. C может забрать этот пакет и переслать его обратно к A. В этом режиме приветствия, передаваемые A, полностью отличаются от приветствий, передаваемых C. Подтверждения нет, только две системы посылают независимые приветствия, которые проверяют связь в двух направлениях с каждого конца.
Режим запроса: В этом режиме два одноранговых узла BFD соглашаются отправлять приветствия только тогда, когда подключение должно быть проверено, а не периодически. Это полезно в том случае, когда существует какой-то другой способ определения состояния канала—например, если канал [A, C] является каналом Ethernet, что означает, что обнаружение несущей доступен для обнаружения сбоя канала, - но этот альтернативный метод не обязательно является надежным для обеспечения точного состояния соединения во всех ситуациях. Например, в случае «коммутатора посередине», где B отключен от A, но не C, C может послать BFD привет, отметив любую проблему с подключением, чтобы убедиться, что его соединение с A все еще есть. В режиме запроса некоторые события, такие как потерянный пакет, могут вызвать локальный процесс для запуска события обнаружения BFD.
Режим запроса с эхом: этот режим похож на режим запроса - обычные приветствия не передаются между двумя устройствами, на которых работает BFD. Когда пакет передается, он отправляется таким образом, чтобы другое устройство переадресовало пакет приветствия обратно отправителю. Это снижает нагрузку на процессор на обоих устройствах, позволяя использовать гораздо более быстрые таймеры для приветствий BFD.
Независимо от режима работы, BFD вычисляет различные таймеры опроса (hello) и обнаружения (dead) отдельно по каналу связи. Лучший способ объяснить этот процесс-на примере. Предположим, что A отправляет управляющий пакет BFD с предлагаемым интервалом опроса 500 мс, а C отправляет управляющий пакет BFD с предлагаемым интервалом опроса 700 мс. Для связи выбирается большее число или, скорее, более медленный интервал опроса. Объясняется это тем, что более медленная система должна быть в состоянии идти в ногу с интервалом опроса, чтобы предотвратить ложные срабатывания.
Частота опроса изменяется при фактическом использовании, чтобы предотвратить синхронизацию пакетов приветствия в нескольких системах на одном и том же проводе. Если было четыре или пять систем, развертывающих Border Gateway Protocol (BGP) на одном канале множественного доступа, и каждая система устанавливает свой таймер для отправки следующего пакета приветствия на основе получения последнего пакета, все пять систем могут синхронизировать их передачу приветствия, чтобы все приветствия по сети передавались в один и тот же момент. Поскольку BFD обычно работает с таймерами длиной менее одной секунды, это может привести к тому, что устройство будет получать приветствия от нескольких устройств одновременно и не сможет обрабатывать их достаточно быстро, чтобы предотвратить ложное срабатывание.
Конкретная используемая модификация заключается в джиттере пакетов. Каждый передатчик должен взять базовый таймер опроса и вычесть некоторое случайное количество времени, которое составляет от 0% до 25% от таймера опроса. Например, если таймер опроса составляет 700 мсек, как в приведенном примере, A и C будут передавать каждый пакет приветствия примерно между 562 и 750 мсек после передачи последнего приветствия.
Последний момент, который следует учитывать, - это количество времени, в течение которого A и C будут ждать перед объявлением соединения (или соседа) отключенным. В BFD каждое устройство может вычислить свой собственный таймер отключения, обычно выраженный как кратное таймеру опроса. Например, A может решить считать канал (или C) отключенным после пропуска двух приветствий BFD, в то время как C может решить дождаться пропуска трех приветствий BFD.
В данной статье будет рассмотрена настройка и подключение телефонного аппарата к АТС OpenScape Voice на примере телефонных аппаратов семейства Siemens OpenStage, работающих по протоколу SIP.
Для подключения нового абонента к системе требуются:
Префикс номера (Office Code) - префикс телефонного номера в системе, по которому осуществляется маршрутизация вызовов;
Полный внутренний номер (Home Directory Number) - состоит из префикса номера и внутреннего номера;
Внутренний номерной план (Private Numbering Plan) - определяет правила маршрутизации для группы абонентов;
Настойка параметров абонента (Subscriber);
Для конфигурации используется система управления - Common Management Portal. Она представлена в виде веб-портала.
Создание префикса номера
Для этого необходимо перейти в раздел Configuration → OpenScape Voice → Global Translation and Routing → Directory Numbers → Office Codes:
Номер телефона состоит из короткого внутреннего номера (Extension) и префикса - локального кода офиса (Local Office Code).
Нажимаем на кнопку Add… и поле Local Office Code указываем префикс, а ниже указываем диапазон внутренних номеров в полях Directory Number Start и Directory Number End. После нажимаем Save.
Создание внутреннего номера
Переходим в раздел Configuration → OpenScape Voice → Global Translation and Routing → Directory Numbers → Home Directory Numbers:
Нажимаем Add… и в поле Office Code указываем созданный префикс, а в полях Directory Number Start и Directory Number End указываем начальный и конченый диапазон номеров. Если необходимо добавить только один номер, то его нужно указать в поле Directory Number Start, а поле Directory Number End оставить пустым. Нажимаем Save, и номер появляется в списке.
Создание внутреннего номерного плана
Для этого в разделе Configuration → OpenScape Voice → Business Group → Private Numbering Plan List нажимаем на Add… и вводим название номерного плана. После этого в списке номерных планов можно нажать Set as Default для назначения планом по умолчанию.
Настойка параметров абонента
В разделе Configuration → OpenScape Voice → Business Group → Members → Subscribers нажимаем Add… и в открывшемся окне во вкладке General в поле Directory Number вводим полный номер абонента. Для корпоративной сети тип номера указываем Private.
Переходим на вкладку Displays и в поле Display Name вводе имя абонента, которое будет отображаться при звонках (для того чтобы отображалось имя на русском языке его нужно ввести в поле Unicode Display Name).
Далее во вкладке Connection в строке Type выставляем Dynamic, а в строке Transport Protocol - TCP и затем нажимаем на Save.
После первичной настройки для добавления новых абонентов используется только пункты создания внутреннего номера и настройки параметров, в которых указываются уже существующие префиксы и номерные планы.
Настройка параметров на телефоне
Перейдем к настройке самого телефонного аппарата. Телефон можно настроить либо через веб-интерфейс, набрав в адресной строке https://[ip адрес телефона], либо через меню самого аппарата.
Прежде всего необходимо проверить доступность телефона до OpenScape Voice. Это может сделать при помощи утилиты Ping, которая находится в меню Administrator → Diagnostics → Miscellaneous → IP tests. В этом же разделе можно произвести трассировку до необходимого адреса. Сетевые параметры можно изменить в разделе Network.
После проверки доступности необходимо перейти в раздел System → System Identity и в строке Terminal Number ввести полный номер абонента вместе с префиксом. В Display Identity можно указать номер, который будет высвечиваться на экране. После этого нажать Submit.
В соседнем разделе SIP interface нужно выбрать транспортный протокол, который мы ранее задавали в параметрах абонента (а данном случае TCP).
Далее в разделе Registration необходимо указать адреса интерфейса SIP системы OpenScape, в полях SIP server address и SIP registrar address. В поле server type выбираем OS Voice и нажимаем Submit.
После проведенных манипуляций на экране телефона высветится его номер.
Проверить регистрацию телефона можно через CMP в меню Configuration → OpenScape Voice → Business Group → Subscriber нажав на кнопку More и выпадающем меню выбрав пункт Registration Status. Далее в строке поиска выбрать критерий, ввести данные и нажать на Search. В результате будет показан статус регистрации телефона. Будет выведена информация о номере абонента, типе регистрации, статусе регистрации, IP адресе терминала и полном SIP адресе терминала.
Во всем мире умные города являются неотъемлемой частью устойчивого развитие общества.
Основные концепции системы "Умный город":
Контроль дорожного движения;
Управление муниципальным транспортом;
Управление общественным транспортом;
Управление парковками.
Умные города гарантируют, что их граждане доберутся от точки "А" до точки "Б" максимально безопасно и эффективно. Для достижения этой цели муниципалитеты обращаются к разработке IoT (Internet of Things) и внедрению интеллектуальных транспортных решений. Интеллектуальные дорожные решения используют различные типы датчиков, а также извлекают данные GPS из смартфонов водителей для определения количества, местоположения и скорости транспортных средств. В то же время интеллектуальные светофоры, подключенные к облачной платформе управления, позволяют отслеживать время работы "зеленого света" и автоматически изменять огни в зависимости от текущей дорожной ситуации для предотвращения заторов на дороге.
Примеры концепций системы "Умного города":
Смарт-паркинг
С помощью GPS-данных система автоматически определяет, заняты ли места для парковки или доступны, и создают карту парковки в режиме реального времени. Когда ближайшее парковочное место становится бесплатным, водители получают уведомление и используют карту на своем телефоне, чтобы найти место для парковки быстрее и проще, а не заниматься поиском парковочного места вслепую.
Служебные программы
Умные города позволяют гражданам экономить деньги, предоставляя им больше контроля над своими домашними коммунальными услугами. IoT обеспечивает различные подходы к использованию интеллектуальных утилит:
Смарт-счетчики и выставление счетов;
Выявление моделей потребления;
Удаленный мониторинг.
Искусственный интеллект
Искусственный интеллект становится ведущим драйвером в цифровой трансформации экономики и социальной жизни. Социальная организация производства и предоставления услуг меняются. Рутинные операции выполняются роботами. Решения принимаются на основе искусственного интеллекта. С помощью него можно предотвратить управленческие ошибки и облегчить принятие решений во всех сферах городского хозяйства и управления.
Преобладание цифровых документов над бумажными
Реализация этой концепции позволяет городу в полной мере использовать все преимущества цифровых технологий:
Оказание государственных услуг более прозрачное;
Оптимизация административных процедур;
Наиболее эффективное использование ресурсов.
Промышленность
Реализация проектов по комплексному онлайн-мониторингу промышленных объектов. Благодаря данной системе, можно контролировать состояние системы, управлять ей, а также получать статистику.
Транспорт
Данные от датчиков IoT могут помочь выявить закономерности того, как граждане используют транспорт. Чтобы провести более сложный анализ, интеллектуальные решения для общественного транспорта могут объединить несколько источников, таких как продажа билетов и информация о движении.
Благодаря реализации данного направления можно осуществлять мониторинг транспортной инфраструктуры и мониторинг транспортных средств. Современные решения способны существенно повысить эффективность грузоперевозок, а также оптимизировать работу железнодорожных путей и дорожного покрытия, следя за температурой и влажностью.
Известные уязвимости представленных систем
В настоящее время происходит рост технологических возможностей, а также рост разнообразия различных электронных устройств и оборудования, используемых в автоматизированных системах управления, всё это ведет к повышению количества уязвимостей к данным системам. В добавок ко всему, процесс введения в эксплуатацию различных решений не дает стопроцентной гарантии того, что не будут допущены различные ошибки в глобальном проектировании. Это создает вероятность появления дополнительных архитектурных уязвимостей.
Злоумышленники могут воспользоваться известными проблемами с безопасностью компонентов жизнеобеспечения в системах автоматизации и предпринять попытку реализации атаки. Такие действия злоумышленников могут прервать нормальную работу такого масштабного объекта, как, например, аэропорт, повлечь за собой вывод из нормальной работы системы жизнеобеспечения, блокируя систему безопасности. И, будучи незамеченными вовремя, способны привести к непоправимым последствиям.
Большинство систем не защищено от попыток внедрения. Обычно все решения в области защиты систем реализуются на уровне межсетевого экрана. Но в случае с попытками атаки на столь критичные системы этого оказывается недостаточно.
Роль информационной безопасности для экосистем
Информационная безопасность связана с внедрением защитных мер от реализации угрозы несанкционированного доступа, что является частью управления информационными рисками и включает предотвращение или уменьшение вероятности несанкционированного доступа.
Основной задачей информационной безопасности является защита конфиденциальности, целостности и доступности информации, поддержание продуктивности организации часто является важным фактором. Это привело к тому, что отрасль информационной безопасности предложила рекомендации, политики информационной безопасности и отраслевые стандарты в отношении паролей, антивирусного программного обеспечения, брандмауэров, программного обеспечения для шифрования, юридической ответственности и обеспечения безопасности, чтобы поделиться передовым опытом.
Информационная безопасность достигается через структурированный процесс управления рисками, который:
Определяет информацию, связанные активы и угрозы, уязвимости и последствия несанкционированного доступа;
Оценивает риски;
Принимает решения о том, как решать или рассматривать риски, т. е. избегать, смягчать, делиться или принимать;
Отслеживает действия и вносит коррективы для решения любых новых проблем, изменений или улучшений.
Типы протоколов для системы управления "Умным городом"
Протоколы и стандарты связи при организации Интернета вещей можно в широком смысле разделить на две отдельные категории.
Сетевые Протоколы Интернета Вещей
Сетевые протоколы Интернета вещей используются для подключения устройств по сети. Это набор коммуникационных протоколов, обычно используемых через Интернет. При использовании сетевых протоколов Интернета вещей допускается сквозная передача данных в пределах сети.
Рассмотрим различные сетевые протоколы:
NBIoT (Narrowband Internet of Things)
Узкополосный IoT или NB-IoT это стандарт беспроводной связи для Интернета вещей (IoT). NB-IoT относится к категории сетевых стандартов и протоколов маломощных глобальных сетей (LPWAN low power wide area network), позволяющих подключать устройства, которым требуются небольшие объемы данных, низкая пропускная способность и длительное время автономной работы.
LoRaWan (Long Range Wide Area Network) глобальная сеть дальнего радиуса действия
Это протокол для работы устройств дальнего действия с низким энергопотреблением, который обеспечивает обнаружение сигнала ниже уровня шума. LoRaWan подключает аккумуляторные устройства по беспроводной сети к интернету, как в частных, так и в глобальных сетях. Этот коммуникационный протокол в основном используется умными городами, где есть миллионы устройств, которые функционируют с малой вычислительной мощностью.
Интеллектуальное уличное освещение это практический пример использования протокола LoRaWan IoT. Уличные фонари могут быть подключены к шлюзу LoRa с помощью этого протокола. Шлюз, в свою очередь, подключается к облачному приложению, которое автоматически управляет интенсивностью лампочек на основе окружающего освещения, что помогает снизить потребление энергии в дневное время.
Bluetooth
Bluetooth один из наиболее широко используемых протоколов для связи на короткие расстояния. Это стандартный протокол IoT для беспроводной передачи данных. Этот протокол связи является безопасным и идеально подходит для передачи данных на короткие расстояния, малой мощности, низкой стоимости и беспроводной связи между электронными устройствами. BLE (Bluetooth Low Energy) это низкоэнергетическая версия протокола Bluetooth, которая снижает энергопотребление и играет важную роль в подключении устройств Интернета вещей.
ZigBee
ZigBee это протокол Интернета вещей, что позволяет смарт-объекты, чтобы работать вместе. Он широко используется в домашней автоматизации. Более известный для промышленных установок, ZigBee используется с приложениями, которые поддерживают низкоскоростную передачу данных на короткие расстояния.
Уличное освещение и электрические счетчики в городских районах, которые обеспечивают низкое энергопотребление, используют коммуникационный протокол ZigBee. Он также используется с системами безопасности и в умных домах и городах.
Протоколы передачи данных Интернета Вещей
Протоколы передачи данных IoT используются для подключения маломощных устройств Интернета вещей. Эти протоколы обеспечивают связь точка-точка с аппаратным обеспечением на стороне пользователя без какого-либо подключения к интернету. Подключение в протоколах передачи данных IoT осуществляется через проводную или сотовую сеть. К протоколам передачи данных Интернета вещей относятся:
MQTT (Message Queuing Telemetry Transport) телеметрический транспорт очереди сообщений
Один из наиболее предпочтительных протоколов для устройств Интернета вещей, MQTT собирает данные с различных электронных устройств и поддерживает удаленный мониторинг устройств. Это протокол подписки/публикации, который работает по протоколу TCP, что означает, что он поддерживает событийный обмен сообщениями через беспроводные сети.
CoAP (Constrained Application Protocol)
CoAP это протокол интернет-утилиты для функционально ограниченных гаджетов. Используя этот протокол, клиент может отправить запрос на сервер, а сервер может отправить ответ обратно клиенту по протоколу HTTP. Для облегченной реализации он использует протокол UDP (User Datagram Protocol) и сокращает использование пространства.
AMQP (Advanced Message Queuing Protocol) расширенный протокол очереди сообщений
AMQP это протокол уровня программного обеспечения для ориентированной на сообщения среды промежуточного программного обеспечения, обеспечивающий маршрутизацию и постановку в очередь. Он используется для надежного соединения точка-точка и поддерживает безопасный обмен данными между подключенными устройствами и облаком. AMQP состоит из трех отдельных компонентов, а именно: обмена, очереди сообщений и привязки. Все эти три компонента обеспечивают безопасный и успешный обмен сообщениями и их хранение. Это также помогает установить связь одного сообщения с другим.
Протокол AMQP в основном используется в банковской отрасли. Всякий раз, когда сообщение отправляется сервером, протокол отслеживает сообщение до тех пор, пока каждое сообщение не будет доставлено предполагаемым пользователям/адресатам без сбоев.
M2M (Machine-to-Machine) протокол связи между машинами
Это открытый отраслевой протокол, созданный для обеспечения удаленного управления приложениями устройств Интернета вещей. Коммуникационные протоколы М2М являются экономически эффективными и используют общедоступные сети. Он создает среду, в которой две машины взаимодействуют и обмениваются данными. Этот протокол поддерживает самоконтроль машин и позволяет системам адаптироваться к изменяющимся условиям окружающей среды.
Коммуникационные протоколы M2M используются для интеллектуальных домов, автоматизированной аутентификации транспортных средств, торговых автоматов и банкоматов.
XMPP (eXtensible Messaging and Presence Protocol) расширяемый протокол обмена сообщениями и информацией о присутствии
XMPP имеет уникальный дизайн. Он использует механизм для обмена сообщениями в режиме реального времени. XMPP является гибким и может легко интегрироваться с изменениями. XMPP работает как индикатор присутствия, показывающий состояние доступности серверов или устройств, передающих или принимающих сообщения.
Помимо приложений для обмена мгновенными сообщениями, таких как Google Talk и WhatsApp, XMPP также используется в онлайн-играх, новостных сайтах и голосовом стандарте (VoIP).
Протоколы Интернета вещей предлагают защищенную среду для обмена данными. Очень важно изучить потенциал таких протоколов и стандартов, так как они создают безопасную среду. Используя эти протоколы, локальные шлюзы и другие подключенные устройства могут взаимодействовать и обмениваться данными с облаком.