Облачная SaaS-платформа и варианты развёртывания

Для малого и среднего бизнеса и быстрого запуска: общий (shared) SaaS. Для предприятий со строгими политиками безопасности или глубокой интеграцией ПЛК/VPN: выделенный однотенантный вариант или локальное развёртывание. Мы даём рекомендации на этапе пилотного проекта.

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

Да. Начните с общего варианта ради скорости запуска и переходите на выделенный или локальный вариант по мере роста. Платформа при этом остаётся идентичной.

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

Нет. Сервер сбора данных стоит внутри сети предприятия, опрашивает контроллеры и сам открывает исходящее соединение по TLS или через site-to-site VPN, так что порт в сторону завода на межсетевом экране не открывается. Но чётко определите, что этому серверу разрешено: это доверенный мост, и всё, что платформа может через него записать обратно в оборудование, становится тем же входящим каналом, только под другим названием. Сегментация уровня АСУ ТП остаётся вашей зоной ответственности, поэтому пусть ваши сетевики и безопасники до пилота посмотрят адреса назначения, порты и права на запись.

На вас серверы, операционные системы, контейнерная платформа, база данных, резервные копии и регулярная проверка восстановления из них, сертификаты и их продление, мониторинг и окна обновлений. Это значит выделенный человек с опытом Linux и контейнеров. Ответственность, размазанная по загруженному отделу, не сработает. Трудозатрат здесь больше, чем закладывает большинство заказчиков, и если такого человека в штате нет, on-premise вам не подходит.

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

Сначала решения по железу и сети: серверы под те модули, которые вы покупаете, ресурсы GPU, если берёте машинное зрение или ИИ, отдельный VLAN под уровень АСУ ТП, правила межсетевого экрана между ним и приложением, записи в DNS, сертификаты и хранилище резервных копий с ответственным за проверку восстановления. Плюс именованные учётные записи администраторов и согласованное окно техобслуживания. Именно недоделки на этом этапе срывают сроки запуска гораздо чаще, чем сам софт.

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

Да. Цеховые системы фиксируют, кто и на каком рабочем месте авторизовался и сколько времени заняла операция. Эксплуатировать такую платформу законно можно, но само по себе ваше развёртывание соответствия не даёт. Нужны соглашение об обработке данных, срок хранения и решение о том, кому доступны показатели по конкретному человеку, помимо агрегированных. Спросите, можно ли ограничить отчётность по отдельным сотрудникам ролевой моделью или отключить её совсем, и подключите юристов и HR заранее: представителей трудового коллектива нередко нужно уведомить до запуска.