1.2 Интероперабельность и управление

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

В этой главе описаны принципы управления взаимодействием систем в вашем ландшафте (ERP, MES, SCADA). Эти правила служат важными архитектурными ограничениями для обеспечения стабильности и масштабируемости.

Правила архитектурной топологии

Не создавайте хрупких связей. Обеспечьте разделение систем.

Правило 1: Избегайте интеграции типа «база данных — база данных».

Рекомендация: Не допускайте, чтобы внешняя система выполняла операции INSERT, UPDATE или DELETE напрямую в SQL-базе данных другой системы.
Причина: Эта практика обходит проверку бизнес-логики (например, проверку существования номера детали перед созданием рабочего заказа) и может привести к появлению некорректных или «сиротских» записей.
Решение: Всю интеграцию проводите через уровень абстракции, такой как API, брокер сообщений или сервисная шина предприятия (ESB).

Правило 2: Архитектура «звезда» против «полносвязной сети».

Ограничение: Избегайте прямых соединений между всеми системами (A↔B, A↔C, B↔C), так как этот подход масштабируется с избыточной сложностью (N(N-1)/2 соединений).
Рекомендация: Реализуйте шаблон «звезда» (Hub-and-Spoke) или используйте единое пространство имен. Системы должны публиковать события в центральный брокер (например, MQTT или Kafka) или обращаться к центральному API-шлюзу.
Преимущество: При замене основной системы, такой как ERP, потребуется обновить только один коннектор в центре, а не множество отдельных скриптов точка-точка.

Документ управления интерфейсом (ICD)

ICD служит формальным соглашением между двумя архитектурными блоками. Не приступайте к написанию кода интеграции, пока ICD не будет рассмотрен и утвержден.

Ключевые компоненты документа управления интерфейсом:

Транспортный протокол: (например, HTTPS REST, MQTT, TCP Socket).
Направленность: Кто инициирует обмен? (Отправитель (Push) или получатель (Pull)).
Аутентификация: API-ключ, OAuth или сертификат.
Определение схемы: Точная структура тела сообщения (JSON/XML).
- Строгая типизация: Количество должно определяться как целое число, а не строка.
- Единица измерения: Температура должна определяться в градусах Цельсия, а не просто числом 240.
Состояния ошибок: Как система сигнализирует о сбое? (HTTP 400 против 500).

Семантическое управление: Наименования и идентификаторы

Без возможности уникально идентифицировать объект эффективное управление невозможно.

Стратегия наименования: Иерархия ISA-95

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

Формат: Площадка/Участок/Линия/Ячейка/Устройство
Пример: MEX01/SMT/Line04/Pick&Place02/Feeder12
Причина: Это позволяет логически агрегировать данные. Запрос для MEX01/SMT/* возвращает все данные по производительности участка SMT на площадке.

Стратегия идентификации: Неизменяемый уникальный идентификатор (UID)

Проблема: Серийные номера поставщиков не уникальны глобально. Катушка резистора от поставщика A может иметь тот же идентификатор, что и катушка конденсатора от поставщика B.
Рекомендация: Генерируйте внутренний UID в точке входа (например, на участке приемки).
Реализация: Используйте UUID (например, 550e8400-e29b…) или префиксированное целое число (UID-999999). Этот внутренний UID должен использоваться в качестве первичного ключа во всех связанных таблицах базы данных.

Управление временем: Синхронизация

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

Устойчивость сообщений и версионирование

Исходите из того, что сеть будет выходить из строя, а API — изменяться.

Политика версионирования

Правило: Не нарушайте существующий контракт.
Реализация: Используйте семантическое версионирование в конечных точках API.
- “POST /api/v1/work-order” (Устаревшая)
- “POST /api/v2/work-order” (Новая функциональность)
Устаревание: Поддерживайте версию “v1” как минимум в течение 6 месяцев после выпуска “v2”.

Обработка ошибок и идемпотентность

Сценарий: MES отправляет сообщение о «потреблении» в ERP. ERP успешно обрабатывает его, но подтверждение теряется. MES, предполагая сбой, отправляет сообщение повторно.
Риск: ERP может дважды списать материалы, создав в системе ложную нехватку.
Требование: Принимающая система должна быть идемпотентной. Она должна проверять «Идентификатор сообщения». Если система распознает, что уже обработала конкретное сообщение (например, “Msg-101”), она должна вернуть подтверждение «Успех», не выполняя транзакцию повторно.

Хранение и пересылка (буферизация)

Ограничение: Разрывы сети и кратковременные отключения систем возможны.
Рекомендация: Оснастите все периферийные шлюзы и интерфейсы MES возможностью локальной буферизации сообщений (на диск или в очередь) при потере связи с вышестоящей системой.
Восстановление: После восстановления соединения очищайте буфер в порядке FIFO (первым пришел — первым ушел), чтобы сохранить исходную последовательность событий.

Резюме: Управление интероперабельностью

Параметр	Требование	Значение / Формат	Документ
Транспортный протокол	Интеграция через уровень абстракции	API, ESB, брокер сообщений (MQTT, Kafka)	ICD
Схема сообщения	Строгая типизация и единицы измерения	JSON/XML с типами (int, float) и единицами (град. Цельсия)	ICD
Идентификатор объекта	Внутренний неизменяемый UID	UUID или префиксное целое число (UID-999999)	Стратегия идентификации
Временная метка	Хранение в UTC, синхронизация NTP	ISO 8601, отклонение ≤ ±500 мс	Рекомендация NTP
Обработка сообщений	Идемпотентность принимающей системы	Проверка уникального ID сообщения	Политика обработки ошибок