Влияние распределенной архитектуры IoT-систем на операционные и инфраструктурные издержки предприятия

Введение

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

Интерес к экономике интернета вещей в отечественной литературе устойчив. М. С. Токарева, К. О. Вишневский и Л. П. Чихун, обобщив оценки международных консалтинговых компаний, приводят для промышленности снижение затрат на техническое обслуживание заводского оборудования на 40% и сокращение времени его простоя на 50% [7, с. 67]. Близкую величину называют В. П. Куприяновский, Д. Е. Намиот и С. А. Синягов: переход от плановых ремонтов к ремонтам по состоянию сокращает ремонтные затраты на 40% [4, с. 23]. Н. В. Городнова связывает развитие индустриального интернета вещей в России с существенным снижением текущих и эксплуатационных затрат и с сокращением срока окупаемости вложений [1, с. 1503]. Все эти оценки описывают выгоду от применения технологии в целом. Во что обходится сама IoT-инфраструктура и как ее стоимость зависит от архитектурных решений, в этих работах не рассматривается.

Технические публикации по распределенным вычислениям, напротив, подробно описывают архитектуру, но редко доводят анализ до денежных показателей. Концепция туманных вычислений, при которой часть обработки выполняется на узлах между конечными устройствами и облаком, была предложена исследователями компании Cisco [8, с. 13-14], а ее трехуровневую архитектуру в отечественной литературе разбирали Д. Ю. Проферансов и И. Е. Сафонова [6, с. 31-32]. Выигрыш в задержке, нагрузке на сеть и энергопотреблении подтвержден рядом моделей и экспериментов [9, 10, 11], однако дополнительные расходы на периферийное оборудование, персонал и защиту большого числа узлов учитываются в них лишь частично.

Терминология в этой области пока не устоялась. А. А. Кирсанова и соавторы разграничивают понятия так: туманные узлы размещаются на границе локальной сети, а граничные вычисления выполняются еще ближе к конечным устройствам [2, с. 40]. Ф. Бономи и соавторы отнесли к признакам туманных вычислений, помимо малой задержки, широкое географическое распределение, очень большое число узлов и неоднородность оборудования [8, с. 13-14]. Последние два признака прямо касаются издержек: чем больше разнородных узлов, тем дороже их сопровождение. В статье распределенной называется архитектура, в которой задействованы оба уровня, граничный и туманный, а за облаком остаются долгосрочное хранение и аналитика. Такая архитектура возвращает на баланс предприятия оборудование, которое нужно покупать и обслуживать, поэтому сравнивать ее с облачной по одним только счетам за облачные ресурсы некорректно: сравнение имеет смысл по совокупной стоимости владения за весь срок службы системы.

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

Объекты и методы исследования

Объектом исследования выступают издержки предприятия на создание и эксплуатацию IoT-системы, предметом – зависимость этих издержек от того, где выполняется обработка данных. Сравнивались два варианта архитектуры. В централизованном датчики и контроллеры через шлюзы передают данные в облако, где выполняются обработка, хранение, аналитика и логика реагирования на события. В распределенном первичная обработка, фильтрация и критичные сценарии управления выполняются на граничных шлюзах рядом с оборудованием и на туманных серверах в пределах площадки. В облако при этом уходят агрегированные показатели, события и фрагменты исходных данных, нужные для разбора инцидентов. Такое распределение функций соответствует трехуровневой схеме «устройства – туманный уровень – облако» [6, с. 31].

Исследование проводилось в два этапа. На первом по материалам публикаций была составлена классификация издержек IoT-системы и для каждой статьи определено, как она меняется при переносе обработки на периферию. На втором этапе построена модель совокупной стоимости владения (total cost of ownership, TCO) для условного машиностроительного предприятия с тремя производственными корпусами. Рассматривались два сценария. В сценарии А система собирает только низкочастотную телеметрию: температуру, давление, токи двигателей, показания счетчиков энергоресурсов. В сценарии Б к телеметрии добавлены вибродиагностика 40 агрегатов и видеоконтроль качества продукции с помощью восьми камер. Исходные допущения модели приведены в таблице 1.

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

Таблица 1

Исходные допущения модели

Цены на облачные ресурсы, оборудование и труд заданы на уровне, характерном для российского рынка, и округлены. Модель не претендует на точность для конкретного предприятия: ее задача – показать, какие статьи затрат меняются при смене архитектуры. Капитальные вложения распределенного варианта включают в сценарии А шесть шлюзов и один туманный сервер, в сценарии Б – дополнительно второй туманный сервер, десять узлов вибродиагностики и два сервера видеоаналитики, во всех случаях с пусконаладкой. В централизованном варианте вложения ограничиваются шлюзами-концентраторами и подключением к облачной платформе (400 тыс. руб.), а в сценарии Б к ним добавляются модули сбора вибросигнала и оборудование выделенного канала (еще 880 тыс. руб.). Датчики, кабельные трассы и прикладное программное обеспечение одинаковы для обоих вариантов и в расчет не включались.

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

Затраты приводились к начальному моменту по ставке 16%, что соответствует ключевой ставке Банка России на 1 ноября 2026 г. (14% годовых) с надбавкой за риск 2 процентных пункта. Для проверки устойчивости выводов варьировались число камер видеоконтроля, продолжительность недоступности внешнего канала и стоимость часа простоя.

Результаты и их обсуждение

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

Таблица 2

Изменение статей издержек при переносе обработки данных на периферию

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

С расходами на связь и облачные ресурсы картина в целом ясна. Д. Ю. Проферансов и И. Е. Сафонова указывают, что обработка на месте сбора данных сокращает объем, передаваемый в облако, и тем самым снижает требования к пропускной способности каналов [6, с. 31]. В обзоре А. Юсефпура и соавторов передача всех данных в удаленный центр обработки названа нерациональной как раз из-за нагрузки на сеть и связанных с ней затрат [12, с. 289-290]. Количественную оценку дали С. Саркар, С. Чаттерджи и С. Мисра: в их модели при доле приложений реального времени 50% общая задержка обслуживания в туманной архитектуре снижалась на 50,09% [10, с. 46], а средняя потребляемая мощность при одном из рассмотренных соотношений трафика между туманным уровнем и облаком оказывалась на 42,2% ниже, чем в облачной [10, с. 56].

С электроэнергией дело обстоит сложнее. Ф. Джалали и соавторы показали, что небольшие центры обработки данных на стороне пользователя экономят энергию лишь при определенных условиях, и решающее значение имеют тип сети доступа и доля времени простоя узла [9, с. 1728]. Выгоднее всего оказались приложения с большим объемом выгрузки данных и редким их запросом [9, с. 1737], а промышленная телеметрия и видеоконтроль устроены именно так. Но электроэнергию облачного центра оплачивает провайдер, включая ее в тариф, а периферийные узлы питаются от сети завода, поэтому для предприятия эта статья растет.

Отдельно стоит сказать о скорости реакции. В. Ши и соавторы приводят эксперимент с распознаванием лиц: после переноса вычислений из облака на границу сети время отклика сократилось с 900 до 169 мс [11, с. 638]. Для цеха выигрыш в несколько сотен миллисекунд важен не всегда. Но в киберфизических системах, где процесс нужно непрерывно контролировать в реальном времени [4, с. 18], он позволяет выполнять аварийную остановку или отбраковку на месте, не дожидаясь ответа из облака. Схожая ситуация с обслуживанием оборудования по состоянию, которое, по имеющимся оценкам, сокращает ремонтные затраты на 40% [4, с. 23; 7, с. 67]. Износ подшипника или разбалансировка ротора видны по спектру вибрации, а для спектра нужен сигнал с высокой частотой дискретизации. Непрерывно передавать такой сигнал в облако слишком дорого, поэтому централизованная система получает лишь короткие выборки раз в несколько минут и может пропустить начало дефекта. Граничный узел обрабатывает сигнал целиком и отправляет наверх только признаки износа и предупреждения.

Обратная сторона распределенной архитектуры касается безопасности и сопровождения. А. В. Пименов и соавторы приводят данные Агентства Европейского союза по сетям и информационной безопасности (ENISA), согласно которым инциденты с устройствами интернета вещей входят в тройку угроз с наибольшим финансовым ущербом для компаний [5, с. 40]. Каждый шлюз и туманный сервер находится за пределами защищенного центра обработки данных, и его нужно обновлять и контролировать. Часть этих расходов зависит от выбора платформы. А. А. Кирсанова и соавторы делят платформы туманных вычислений на открытые и закрытые и выделяют три уровня по предоставляемым функциям, от простого развертывания до готовой экосистемы [2, с. 53-55]. Чем больше функций берет на себя платформа, тем меньше ручной работы у персонала, но тем сильнее привязка к поставщику. В. П. Куприяновский, Д. Е. Намиот и О. Н. Покусаев на примере логистики подчеркивают, что такая система должна быть открытой и опираться на стандартные интерфейсы и протоколы [3, с. 92]. Для IoT-системы это означает, что при открытых протоколах замену шлюза или туманного сервера можно провести без переделки всей системы.

Рост трудоемкости сопровождения сдерживают виртуализация, контейнеризация и оркестрация, которые А. А. Кирсанова и соавторы относят к базовым технологиям организации туманных вычислений [2, с. 35]. В модели принято, что при развертывании прикладных модулей на узлах в контейнерах и их обновлении из одного места для сопровождения распределенного варианта достаточно добавочной 0,4 ставки инженера.

Результаты расчета по модели приведены в таблице 3. В сценарии А предприятие передает в облако около 3,1 ГБ данных в сутки. Обработка на шлюзах сокращает этот поток до 0,8 ГБ, но экономия на облачных ресурсах составляет лишь около 220 тыс. руб. в год. Ее с избытком перекрывают дополнительные 0,4 ставки инженера сопровождения (936 тыс. руб. в год) и обслуживание шлюзов. Совокупная стоимость владения распределенным вариантом за пять лет оказалась на 51% выше, и дополнительные вложения в этом сценарии не окупаются.

Таблица 3

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

В сценарии Б суточный объем первичных данных составляет около 352 ГБ, из которых 346 ГБ приходится на видеопоток. В централизованном варианте для такого потока нужны выделенный канал с резервированием и облачные вычислительные ресурсы для видеоаналитики. После локальной обработки в облако уходит около 2,5 ГБ в сутки, то есть менее 1% исходного объема. Расходы на облачные ресурсы снижаются с 2,54 до 0,15 млн руб. в год, а потребность в выделенном канале отпадает. В распределенном варианте эти расходы почти не различаются между сценариями (146 и 147 тыс. руб. в год), поскольку в облаке остаются только долгосрочное хранение, аналитика и удаленный мониторинг: вычислительные ресурсы для них обходятся в 12 тыс. руб. в месяц в обоих случаях, а хранение агрегированного потока 0,8–2,5 ГБ в сутки – в несколько тысяч рублей в год. Распределенный вариант требует на 6,3 млн руб. больше капитальных вложений, но его годовые издержки ниже на 3,4 млн руб. Совокупная стоимость владения за пять лет снижается на 4,8 млн руб., или на 21%, а дисконтированный срок окупаемости дополнительных вложений составляет около 2,4 года.

Структура годовых издержек в таблице 3 показывает, откуда берется экономия. В централизованных вариантах преобладают внешние платежи за облачные ресурсы и канал связи, а также потери от простоев, в распределенных – расходы на персонал, на которые в сценарии Б приходится две трети годовых издержек. В сценарии Б почти треть годовых расходов централизованного варианта, 2,16 из 6,53 млн руб., составляют ожидаемые потери от недоступности облака. Если исключить простои из расчета, распределенный вариант окупается лишь за 7,9 года, то есть за пределами принятого горизонта (табл. 4). Одно только сокращение трафика едва покрывает дополнительные вложения и расходы на персонал, и окончательно решение определяют требования к надежности.

Таблица 4

Чувствительность результатов к основным параметрам

Анализ чувствительности (табл. 4) позволяет сформулировать условия, при которых перенос обработки на периферию оправдан. Первое из них – большой объем первичных данных при малой доле полезной информации в нем. Только с вибродиагностикой, без видеоконтроля, суточный поток составляет около 6 ГБ, и распределенный вариант остается дороже. Уже при двух камерах (около 92 ГБ в сутки) он становится выгоднее со сроком окупаемости 3,8 года. Второе условие – высокая цена простоя. При 24 ч недоступности канала в год срок окупаемости сокращается до 1,4 года, при 48 ч – до 0,8 года. Даже в сценарии А распределенный вариант окупается примерно за год, если час простоя обходится предприятию в 200 тыс. руб.

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

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

Заключение

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

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

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