Эталонная архитектура: автоматика, данные, ERP, MES, BI

Автоматика, данные, учёт и аналитика — четыре слоя, которые на большинстве объектов живут отдельно друг от друга. Эталонная архитектура нужна не для красоты схемы, а чтобы связать их осознанно: заранее решить, где проходят границы, кто источник истины по каждому показателю и что происходит с объектом, когда верхний уровень недоступен.

Четыре слоя

Нижний уровень. Датчики, исполнительные механизмы, ПЛК и локальные контроллеры. Работает в реальном времени и не зависит от внешних сервисов.
Управление объектом. Климат, полив, досветка, тепло, энергия. Здесь живёт технологическая логика объекта.
Данные и события. Исторические архивы, аварийные журналы, отчётность, аналитика ресурсов и урожая.
Управленческий контур. ERP, MES, BI: себестоимость, партии, склад, планирование, прослеживаемость.

Слой	Что входит	Режим работы	Поведение при потере внешнего канала
Нижний уровень	Датчики, приводы, ПЛК, модули ввода-вывода, шкафы, ИБП	Реальное время, жёсткие сроки реакции	Продолжает работу автономно
Управление объектом	Контуры климата, полива, досветки, тепла, энергетики	Реальное время и циклы смены	Работает по локальной логике и последним заданиям
Данные и события	Архивы, журналы отказов, отчётность, аналитика ресурсов	Периодический обмен, накопление	Копит данные локально, выгружает после восстановления
Управленческий контур	ERP, MES, BI, склад, лаборатория, весовая	Сменно-суточный и плановый цикл	Обходится без оперативных данных объекта

Главный вопрос: где проходят границы

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

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

Второе правило касается направления данных. Обмен проектируется не «в обе стороны по возможности», а по назначению: что именно поднимается наверх, с какой периодичностью, в каком виде и что возвращается вниз как задание.

Что проверить в интеграциях

Какие данные нужны управленческому контуру и в каком виде: агрегаты по зонам, партии, события, показатели качества.
Кто источник истины по каждому показателю — датчик, лаборатория, весовая, склад или ручной ввод, и как разрешается расхождение.
Что происходит при недоступности верхнего уровня: буферизация, отложенная выгрузка, повтор передачи, порядок разбора очереди.
Как обеспечивается сопоставимость данных между объектами: единые справочники, единицы измерения, правила округления и периодов.
Какие интерфейсы используются и документированы ли они — открытый протокол, выгрузка таблиц, программный интерфейс поставщика.
Кто отвечает за интеграцию на стороне предприятия и кто принимает результат: обмен без владельца живёт до первого изменения.

Автономность при потере связи

Отдельный пункт проектирования, который проверяется на объекте, а не описывается в презентации. До начала работ нужны ответы на четыре вопроса: сколько времени система работает без внешнего канала; какие данные хранятся локально и в каком объёме; что происходит с ранее выданными заданиями; как проходит синхронизация после восстановления связи.

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

Данные и права

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

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

Что остаётся у предприятия

Данные объекта в открытом формате: выгрузка таблиц, файл базы, документированный интерфейс.
Описание настроек, интеграций и алгоритмов — как рабочая документация, а не как приложение к договору подрядчика.
Административные и сервисные доступы, оформленные на предприятие, с реестром и ответственным.
Лицензии, домены, сертификаты и программные ключи оборудования на имя предприятия, с условиями переоформления.
Карта компетенций: по каждому критичному участку специалист и дублёр.

Автономные системы Архив параметров и конфигураций

Типовые ошибки, которые видно на схеме

Управление снизу вверх

Контур реального времени управляется из облака или из офиса через канал. Архитектура выглядит современно, но при обрыве связи объект теряет управление — а именно этот сценарий и должен быть штатным.

Один источник вместо двух

Показатель вводится вручную и одновременно собирается автоматически. Пока значения совпадают, вопрос не поднимается; при первом расхождении непонятно, какому источнику верить.

Интеграция без владельца

Обмен настроен, но никто не отвечает за его работоспособность и за разбор очереди после сбоя. Через несколько месяцев данные в отчёте и в архиве расходятся.

Документация у подрядчика

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

Частые вопросы

Обязательно ли поднимать данные в облако?

Нет. Облачный слой удобен для заданий, аналитики и мониторинга, но он не обязателен для работы объекта. Требование формулируется по-другому: контуры реального времени должны работать без него.

Что делать с оборудованием разных поколений?

Описывать его в одной схеме и приводить к единым справочникам на уровне данных, а не пытаться объединить на уровне протоколов управления. Разные поколения автоматики спокойно живут рядом, если границы слоёв соблюдены.

С чего начинать, если архитектуры нет?

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

Эталонная архитектура — описание принципов, а не типовой проект. Состав слоёв и глубина интеграции зависят от объекта: у промышленной теплицы, контейнерной фермы и северного автономного объекта наборы контуров, каналов связи и учётных систем разные.

Материал методический, версия 1.0, дата проверки 09.10.2026. Деление на четыре слоя и правило границ приведены как инженерный метод; перечень интеграций и требования к автономности определяются по конкретному объекту.