Миграция производства в облако

Развивать или не развивать

На самом деле сейчас вопрос уже не в том, нужен или не нужен «Интернет вещей» — он стал частью нашей жизни. Вопрос скорее в том, в каких направлениях и как двигаться дальше.

Сегодня в рамках концепции «Интернета вещей» представлено множество мелких решений. Большинство таких устройств предназначено для массового потребителя — нас с вами. В первую очередь это смартфоны, которые служат и средством голосовой связи или видео­общения, и переводчиком, и приспособлением для платежей. Есть ли место мелким решениям в производственной сфере? Конечно. Сейчас каждый производитель стремится добавить в описание своего изделия слово CLOUD. Понятно, что наличие порта Ethernet или SIM-карты у устройства дает техническую возможность для подключения к сети Интернет. Но «вещью» в Интернете это устройство станет только после того, как появится возможность использовать его без физического доступа.

Мы теперь очень удивляемся, встречая людей, не пользующихся сервисом заказа такси или оплатой покупок через NCF. Использование этих услуг вошло в привычку и потребителям даже кажется бесплатным. Применение облачных офисных и бухгалтерских приложений, виртуальных АТС тоже стало повседневной практикой. Облака предлагают и сложные системы — например, системы бизнес-аналитики (BI). Но если объем рынка виртуальных АТС, которые использует большое число мелких компаний, составил за 2016 год 5,26 млрд руб., то облачных систем BI (а их и далеко не все крупные компании готовы применять) — всего 0,43 млрд руб. [1]. Одна из причин непопулярности облачных систем: настроить виртуальную АТС может любой системный администратор за 1–2 дня, а для подготовки системы бизнес-аналитики нужны месяцы работы группы высоко­квалифицированных специалистов. Таким образом, чтобы облачный сервис активно использовался, его настройка должна быть предельно простой.

Шаг в облака

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

Однако такие препятствия не так уж сложно преодолеть. Для этого нужно выбрать программную платформу, которая легко (в идеале без участия производителя ПО) способна понять любое оборудование с открытым (имеющим открытое описание) протоколом и свободно перемещается с локального компьютера на сетевой сервер или даже в публичное облако без изменения кода программ [2]. Требования к такой платформе можно сформулировать следующим образом:

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

В качестве примера рассмотрим структуру системы, инсталлированной на вычислительные ресурсы предприятия (рис. 1).

Рис. 1. Структура информационной системы сварочного цеха «Ростсельмаш» (проект на стадии внедрения)

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

Задачи у системы следующие:

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

Все эти задачи насущные. Даже один мониторинг (автоматический, точный и достоверный) позволяет улучшить качество любого процесса. Интеграция же всех поставленных задач друг с другом (зарплата и кадры; MES — сменное задание; ERP — количество годных деталей) приводит к наилучшим результатам, но видится третьим препятствием на пути к «умному» производству.

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

Как правило, сегодня сервисные службы могут располагаться не только за границей квадрата «предприятие», но и в другой стране. Возможность изменения места исполнения задач рассмотрена в статье [2]. Там рассмотрены особенности системы, которые позволяют перейти от схемы на рис. 1 к структуре с облачным сервисом (рис. 2). В случае MasterSCADA для этого в первую очередь потребуется традиционное отделение логической структуры от физической.

Рис. 2. Структура информационной системы сварочного цеха «Ростсельмаш» (связь с облачным сервисом)

На следующем этапе сервер данных выносится в облако. В этот момент он перестает быть связанным с «железным» сервером. Сейчас провайдеры предлагают не только виртуальные машины, но и другие способы размещения приложений (например, контейнеры). Провайдер облачных услуг может рассказать, что при использовании IaaS не будет расходов на модернизацию и поддержку инфраструктуры. Но все мы знаем, что если кто-то получает прибыль (провайдер), то кто-то платит (потребитель услуг). Задача человека, принимающего решение о переходе в облако, — посчитать. Например, сравнить стоимость простоя от несвое­временного ремонта со стоимостью регулярной оплаты сервиса.

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

Пять отличий

Если откладывать изменения — обгонят, но стоит ли спешить? Лучше, чтобы модернизация стала запланированным переходом. Какое количество шагов для перехода от одной структуры к более новой следует считать приемлемым? Исходя из нашего опыта, можно уложиться всего в пять шагов, если начинать внедрять решения для «умного» производства локально (провайдеры называют это частным, или гибридным, облаком).

Рассмотрим два варианта структуры, представленные на рис. 1 и рис. 2. Сколько нашлось отличий? Первое — исчез контроллер. Второе: исполнительная система вместе с приложением переместилась в облако. На самом деле произошли еще два изменения: исполнение программы назначено на другое устройство и задан его адрес (рис. 3).

Рис. 3. Изменение места исполнения программы

И еще одно отличие: в классической системе опроса есть Мастер, который опрашивает все подчиненные устройства по заданным в них адресам. Перемещение сервера опроса в облако могло бы стать крайне затратным, если бы пришлось оплачивать десятки и сотни «белых» IP разных устройств. В данном случае необходимо перестраивать систему так, чтобы подчиненные устройства сами обращались по известному адресу к Мастеру.

Возможности

Сейчас потребитель уже в силу сложившейся привычки ждет готовых решений. Купил смартфон, загрузил приложение — получил новое качество жизни. В случае сложных производств это пока невозможно. Проприетарные приложения еще не могут справиться с подключением разнообразного оборудования. Но такая потребность уже назрела. Например, мы регулярно получаем запросы на полноценную систему «умного дома» (управление дверьми/окнами, электроэнергией, отоплением, вентиляцией, имитацией присутствия, освещением, дизель-генератором, АВР, ИБП, СКУД, ОПС, видеонаблюдением и мультимедийными устройствами). Действительно хотелось бы иметь такие возможности. Но есть два усложняющих обстоятельства, и требование иметь все это в одном контроллере, в общем-то, не самое страшное из них. Главная проблема в том, что в доме стоит различное оборудование. Протоколы (и физические, и логические) тоже, соответственно, разные. Для решения задачи «купил, что захотел — подключил к тому, что было» время еще не пришло.

С каким физическим интерфейсом и логическим протоколом выбирать «умное» оборудование, чтобы не ошибиться? Какой логический протокол обмена поддерживать в прикладном решении? Об унифицированных протоколах еще не договорились. В таких обстоятельствах правильный выбор платформы позволяет быстро обеспечивать поддержку любого нового протокола — например, MasterSCADA 4D уже поддерживает MQTT и OPC UA, сегодняшних лидеров.

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