Миграция с AVEVA на Альфа платформу в нефтедобыче: как мы это делали

Что стояло и что ставили

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

Компонент AVEVA	Что поставили	Почему именно это
InTouch / System Platform	Alpha.HMI 2.0	Единый дизайнер + визуализатор, скрипты на Alpha.Om и JS
AVEVA Historian	Alpha.Historian 4.0	800 000 записей/с на запись, LZMA-сжатие, работает на Linux
OI Server / DAServer	Alpha.Server 6.4	Встроенные IEC 104, Modbus — без OPC-прослойки
Alarm Provider	Alpha.HMI.Alarms 3.3	Квитирование, подавление, агрегатор по веткам
AVEVA Reports	Alpha.Reports 1.1	Конструктор + планировщик + веб-интерфейс
Galaxy (объектная модель)	Alpha.DevStudio 4.1	Типизация, CLI для массовых операций, SVN/Git
InTouch Web	Alpha.HMI.WebViewer 2.0	Браузер, WebSocket, без клиентского ПО

Ключевое архитектурное отличие (см. также статью об автоматизации НПЗ), которое мы оценили только в процессе: в AVEVA каждый компонент — отдельный продукт с отдельной историей. InTouch и Historian — разные кодовые базы. Альфа платформа — единая среда с общим протоколом Alpha.Link. На практике это значит меньше точек интеграции и меньше мест, где что-то может сломаться.

Аудит: 2–3 недели, которые экономят месяцы

На одном из первых проектов мы пропустили детальный аудит скриптов InTouch. Думали — «мнемосхемы простые, скриптов немного». Оказалось, что в QuickScript было зашито 40% логики сигнализации. На переписывание ушло три лишние недели.

С тех пор аудит — обязательный первый этап:

Сигналы. Выгружаем полный реестр из Galaxy Repository (aaDumpData) или из InTouch (CSV через WindowMaker). Типовой промысел — 10 000–30 000 тегов: 60–70% дискретных, 25–35% аналоговых, остальное — служебные.

Коммуникации. Документируем каналы: IEC 104 с кустов, Modbus TCP к локальным ПЛК, OPC DA к сторонним системам. Фиксируем адреса, циклы опроса, тайм-ауты. И тут первый приятный момент: Alpha.Server 6.4 имеет встроенные модули IEC-104 Master и Modbus TCP Master (полный список — в статье о промышленных протоколах). Сторонние OPC-серверы (MatrikonOPC, KEPServerEX) — больше не нужны. Цепочка «RTU → OPC-сервер → SCADA» сокращается до «RTU → Alpha.Server».

Скрипты и мнемосхемы. Считаем экраны, оцениваем объём QuickScript. Автоконвертация из InTouch невозможна — форматы несовместимы. Но это не страшно: это возможность переделать мнемосхемы нормально.

Проектирование: типизация решает

Вот где Альфа платформа по-настоящему экономит время. В DevStudio мы строили иерархию объектов промысла и создавали типы — аналог ArchestrA Templates в Galaxy, но проще.

Тип «Скважина ЭЦН» — это объект с 42 сигналами, формулами, привязками к IEC 104 и уставками тревог. Создаётся один раз. Для 200 скважин — 200 экземпляров одного типа с разными адресами. Тиражирование занимает минуты.

Разница с AVEVA: в Galaxy шаблон привязан к конкретному типу объекта (AppEngine, Area, DIO). В DevStudio все объекты равноправны — нет деления на «платформенные» и «пользовательские».

Историан: не потерять данные и не потерять голову

Alpha.Historian 4.0 — собственный NoSQL TSDB, не требующий внешних СУБД. Вот что нас впечатлило:

	AVEVA Historian	Alpha.Historian 4.0
Скорость записи	Зависит от конфигурации	800 000 записей/с
Скорость чтения	Зависит от конфигурации	1 600 000 записей/с
Сжатие	Swinging Door (lossy)	LZMA (lossless, коэфф. 0.2–0.5)
ОС	Только Windows	Windows + Linux

Важный нюанс: AVEVA Historian теряет точки уже при записи (Swinging Door — lossy-сжатие). Alpha.Historian хранит всё и сжимает на уровне файлов. Мы пересматривали deadband для каждого проекта: для промысловых сигналов 0.5–1% от диапазона и интервал 1–5 секунд — оптимальный баланс.

Что делать со старыми архивами? Мы оставляли AVEVA Historian в режиме «только чтение» на 6–12 месяцев, параллельно записывая новые данные в Alpha.Historian. Для критичных сигналов потом перегоняли историю через OPC HDA Client.

Резервирование: журнал транзакций

Для нефтедобычи резервирование сервера — не опция, а требование. Мы были приятно удивлены тем, как это реализовано в Альфа платформе.

Master-Slave репликация построена на журнале транзакций — центральном тракте, через который проходят все события Alpha.Server. Журнал непрерывно реплицируется с Master на Slave. Slave не дублирует вычисления — только принимает результаты. Это экономит ресурсы и исключает расхождение состояний.

При штатном переходе новый Master продолжает с позиции, следующей за последней обработанной старым. Инициализация на типовых конфигурациях (десятки тысяч сигналов) — доли секунды. За всё время эксплуатации мы ни разу не наблюдали потери данных при штатных переходах.

Дополнительно — файловая буферизация между узлами. При разрыве связи между Alpha.Server и Historian данные копятся в локальном буфере на диске и отправляются после восстановления. На промыслах с нестабильными каналами (радиорелейка, спутник) этот механизм спасал многочасовые архивы.

Тревоги: гибче, чем в AVEVA

Alpha.HMI.Alarms 3.3 оказался серьёзным шагом вперёд. Помимо стандартных уставок HiHi/Hi/Lo/LoLo, мы использовали:

• Логические условия на Alpha.Om — «давление на выходе насоса < давления на входе + 0.5 МПа И насос в работе». В AVEVA для этого пришлось бы городить расчётный тег + alarm limit.
• Подавление (shelving) — при ремонте куста одной кнопкой убираем десятки тревог от отключённого оборудования. С логированием: кто, когда, на какой срок.
• Агрегатор — на общем плане промысла каждый куст = один индикатор: зелёный / жёлтый / красный. Диспетчер видит картину целиком, не листая экраны.

Параллельная работа и переключение

Переключение «в один день» на промысловом объекте — неприемлемый риск. Наш алгоритм:

1. Alpha.Server подключается к тем же RTU параллельно — IEC 104 допускает несколько Master.
2. Данные пишутся в оба историана 2–4 недели.
3. Диспетчеры обучаются на второй станции (Alpha.Imitator с реальными данными).
4. Переключение после подтверждения корректности.

Для Modbus — сложнее: протокол не предусматривает двух Master на одной шине. Мы использовали OPC-сервер как промежуточный слой на переходный период.

Развёртывание через CLI:

devstudio.cli.exe build --solution "Промысел.asln" --config Release
devstudio.cli.exe deploy --target 192.168.1.10 --config Release
devstudio.cli.exe deploy-commit --target 192.168.1.10
# Откат при проблемах:
devstudio.cli.exe deploy-rollback --target 192.168.1.10

Linux и КИИ: два зайца одним выстрелом

Нефтедобывающие объекты — КИИ по ФЗ-187. Переход на Альфа платформу позволяет одновременно решить две задачи импортозамещения:

• SCADA: AVEVA → Альфа платформа (в реестре российского ПО)
• ОС: Windows → Astra Linux / РЕД ОС / Альт

AVEVA на Linux не работает. Alpha.Server и Alpha.Historian — работают. Плюс отсутствие зависимости от COM/DCOM: Alpha.Link — чистый TCP, проще настраивать межсетевые экраны, нет DCOM-портов как вектора атаки.

Сроки и команда

Наша оценка для типового объекта (20 000 сигналов, 150 кустов, ДНС, УПН):

Этап	Длительность	Люди
Аудит	2–3 недели	1–2 инженера
Проектирование	4–6 недель	2 инженера + проектировщик
Мнемосхемы	6–8 недель	2–3 HMI-разработчика
Historian + Reports	2–3 недели	1 инженер
Тестирование	3–4 недели	2 инженера + тестировщик
Параллельная работа	2–4 недели	1 инженер на объекте
Итого	5–7 месяцев	4–6 человек

Каждый следующий ДП мигрировал быстрее предыдущего — типовые решения из первого проекта тиражировались.

Что вынесли из опыта

• Аудит — не формальность. 2–3 недели на инвентаризацию экономят месяцы.
• Типизация — главный ускоритель. Один тип «Кустовая площадка» на 200 экземпляров.
• Не копировать, а проектировать. Миграция — шанс упростить архитектуру.
• Параллельная работа обязательна. IEC 104 позволяет два Master — используйте.
• Начинайте с пилота. Один ДП (10–20 кустов), полный цикл, потом тиражирование.