Если вы участвовали в закупке оборудования для диспетчерского центра в 2024-2025 годах, вопрос почти наверняка звучал так: какой AV-over-IP стандарт писать в ТЗ, чтобы через три года не оказаться в закрытой вендорской ловушке? ST 2110 слишком дорог для обычного ProAV, SDVoE быстрый, но привязан к конкретной экосистеме, NDI удобен, но не является формальным стандартом для тендеров.
В феврале 2026 года ситуация сдвинулась. AIMS объявил о первых 48 официально сертифицированных IPMX-продуктах, а на ISE 2026 показал первую волну решений, которые прошли тестирование на соответствие IPMX. Для российских диспетчерских это не новость из мира выставок. Это сигнал, что формулировки в ТЗ на видеостены, операционные центры и AV-инфраструктуру пора обновлять.
Что было до IPMX: три отдельных мира
Категория AV-over-IP долго жила как набор несовместимых миров.
**Broadcast** использовал SMPTE ST 2110. Это формальный стандарт для передачи несжатого видео, аудио и ancillary-данных по IP. Он дает гибкое маршрутирование, мультивендорную интеграцию и зрелую экосистему для эфирного производства. Цена тоже broadcast-уровня: 10/25 GbE, PTP, строгий QoS, дорогие коммутаторы и компетенции, которые есть далеко не у каждого интегратора.
**Корпоративный ProAV** часто выбирал SDVoE. Там низкая задержка, 4K60 поверх 10 GbE, удобный commissioning, USB и serial по той же линии. Но сильная сторона SDVoE одновременно является ограничением: архитектура завязана на конкретный кремний и собственную плоскость управления.
**Диспетчерские, ЦОДД, аэропорты, корпоративные ситуационные центры и переговорные** жили в промежутке. Им нужен был низколатентный AV-over-IP, но без broadcast-бюджета и без полного vendor lock-in. На практике использовали NDI, RTSP, KVM-over-IP или проприетарные решения. Для тендера это выглядело плохо: каждый поставщик называл "стандартом" свой стек.
Что IPMX меняет
IPMX построен вокруг той же логики открытого media-over-IP, что и ST 2110, но адаптирован под ProAV и диспетчерские внедрения. Важны три изменения.
**Первое - JPEG XS.** IPMX поддерживает профиль с JPEG XS, то есть сжатие с очень низкой задержкой и визуально прозрачным качеством. Для практики это означает, что 4K60 можно проектировать не только как "дорогой несжатый поток на 10/25 GbE", а как поток, который в типовом ProAV-сценарии укладывается в 1 GbE.
**Второе - более простая синхронизация.** ST 2110 обычно тянет за собой PTP как обязательный элемент всей площадки. В IPMX есть сценарии, где PTP не нужен для каждого endpoint и где система может работать проще. Если видеостена требует жесткой синхронности по всей плоскости, PTP остается полезным. Но требовать PTP-grandmaster в каждом ТЗ "на всякий случай" теперь нерационально.
**Третье - ProAV-возможности в стандартизированной рамке.** IPMX включает необходимые для ProAV темы: HDCP как capability, HDMI InfoFrame, USB extension, EDID, NMOS-управление. Это не значит, что каждое устройство обязано поддерживать все capabilities. Это значит, что тендер может требовать нужные capabilities явно, а не через название конкретного вендора.
Почему это важно именно для тендеров
До 2026 года фраза "нужен открытый AV-over-IP стандарт для диспетчерской" часто была слабой. Поставщик мог предложить ST 2110 и резко увеличить бюджет. Мог предложить SDVoE и закрыть проект в своей экосистеме. Мог предложить NDI и сказать, что "все так делают". Формально заказчик оставался без аккуратной середины.
IPMX дает эту середину. Он не отменяет ST 2110 для broadcast. Он не делает SDVoE плохим выбором для задач с жесткой KVM-латентностью. Но для диспетчерских, где источники смешанные, бюджет ограничен, а lifecycle 5-7 лет, IPMX становится нормальным baseline в ТЗ.
Side-by-side для проектировщика
Как читать "IPMX" в коммерческих предложениях
Главная ошибка в закупке 2026 года - принять слово "IPMX" в презентации за проверенную сертификацию. Рынок только выходит из фазы plugfest и early adoption, поэтому в КП будут встречаться разные формулировки: "IPMX-ready", "TR-10 compatible", "built on IPMX core", "supports NMOS", "future firmware update". Для тендера это не одно и то же.
Нормальная проверка должна идти от готового продукта, а не от чипа, SDK или референсного дизайна. Если производитель говорит, что "наш SoC прошел IPMX-тесты", это еще не значит, что конечный encoder, decoder или gateway можно считать IPMX Certified. Сертификация AIMS относится к конкретному продукту, версии прошивки, заявленным profiles и capabilities.
Минимальный набор вопросов поставщику:
- какая точная модель и firmware/software version прошли проверку;
- какой профиль заявлен: uncompressed, JPEG XS, audio, mixed;
- какие capabilities подтверждены: HDCP, USB, HDR, encryption, EDID;
- как реализованы discovery и connection management через NMOS;
- какие сетевые требования нужны в реальном проекте: 1 GbE, 10 GbE, multicast, IGMP, PTP;
- есть ли публичная запись в registry или официальное подтверждение от AIMS, когда registry будет опубликован.
Такой чек нужен не для бюрократии. Он защищает проект от ситуации, когда в ТЗ написали "IPMX", а на приемке получили устройство, которое умеет только часть TR-10, требует ручной маршрутизации или обещает нужный capability "в следующей прошивке".
Где IPMX выигрывает в российских проектах
Сценарий 1: ЦОДД и дорожные диспетчерские.
У многих центров управления дорожным движением уже есть 1 GbE-инфраструктура, камеры, аналитика, браузерные панели, карты и dashboards. Перестраивать площадку под полный ST 2110 часто экономически бессмысленно. IPMX позволяет требовать открытый AV-over-IP путь без автоматического перехода на broadcast-класс сети.
Сценарий 2: AOCC аэропортов и ЦУП железнодорожной инфраструктуры.
Там почти всегда смешаны CCTV, метео, HMI, браузерные интерфейсы, NDI/RTSP и отдельные low-latency источники. IPMX полезен как часть общей архитектуры: не все источники обязаны стать IPMX, но новые AV-over-IP компоненты можно закупать уже с проверяемой conformance-логикой.
Сценарий 3: ситуационные центры и ЦУКС.
Видеостена в таком центре редко является "чистым broadcast". Это операционный инструмент: карты, статусы, камеры, регламенты, брифинговые экраны. Если горизонт проекта 2027-2028, IPMX-готовность снижает риск, что новая стена устареет до конца жизненного цикла.
Где IPMX пока не лучший выбор
Trading desk, KVM и командные посты с жесткой реакцией.
Если задержка между действием оператора и визуальной реакцией должна быть минимальной даже под полной нагрузкой, SDVoE или специализированный KVM-over-IP могут быть рациональнее. IPMX с JPEG XS очень быстрый, но это не магический "ноль задержки".
Broadcast greenfield.
Если строится новая аппаратная с бюджетом на 10/25 GbE fabric, PTP, spine-leaf и зрелый ST 2110 workflow, IPMX не обязан заменять ST 2110. В таком проекте ST 2110 остается базовым broadcast-выбором.
Уже развернутый SDVoE.
Миграция работающей SDVoE-инфраструктуры на IPMX ради самого факта нового стандарта почти никогда не окупается. Логичный момент для перехода - lifecycle refresh, замена endpoints или новая очередь объекта.
Что писать в ТЗ в 2026 году
Если вы готовите ТЗ или ТТТ на новую диспетчерскую, операционный центр или видеостену, формулировки лучше делать проверяемыми.
1. **"IPMX conformance с подтверждением сертификации AIMS Alliance для готового продукта"** - не "совместимость с ST 2110" и не "IPMX-ready" без доказательства.
2. **"NMOS IS-04/IS-05 для discovery и connection management"** - чтобы исключить псевдо-IP решения с ручной маршрутизацией.
3. **"JPEG XS profile для 4K60 поверх 1 GbE там, где требуется экономия полосы"** - если проект действительно должен жить на существующей сети.
4. **"HDCP capability для защищенных HDMI-источников, если такие источники есть в сценарии"** - не требовать HDCP абстрактно, но фиксировать там, где он нужен.
5. **"Работа без обязательной облачной плоскости управления"** - для КИИ, air-gap и изолированных контуров.
И что лучше не писать без причины:
- "10 GbE end-to-end обязателен" - это может убить главный экономический смысл IPMX.
- "PTP-grandmaster обязателен для всех endpoints" - требование должно следовать из сценария синхронизации.
- "совместимость с конкретным брендом" - если нужна открытая архитектура, проверяйте стандарт и capabilities, а не бренд.
Что Craft Wall делает с IPMX
Честно: нативный IPMX-прием не является частью поставки Craft Wall на 2026 год. Текущий стек закрывает NDI, NDI HX, RTSP, HDMI-захват, IP-KVM и браузерные источники. Для проектов, где IPMX уже появляется в ТЗ, практичный путь сегодня - использовать сертифицированный upstream endpoint или gateway и подавать в Craft Wall NDI/HDMI/RTSP confidence feed как обычный tile.
Roadmap на 2026-2027: отслеживать каденс AIMS-сертификации, реальные product registry entries и спрос в российских ТЗ. Цель - добавлять IPMX не как маркетинговую галочку, а тогда, когда есть зрелая совместимость, понятные тесты и достаточный парк устройств.
Вывод
IPMX в 2026 году - это не "еще один стандарт ради стандарта". Это появление проверяемого AV-over-IP baseline для тех проектов, которые раньше выбирали между дорогим broadcast ST 2110, закрытым SDVoE и удобными, но менее формальными IP-видео стеками.
Если вы проектируете диспетчерскую с горизонтом 2027-2028, отсутствие IPMX-conformance в ТЗ уже выглядит как риск. Но специфицировать IPMX надо аккуратно: с привязкой к AIMS certification, NMOS, нужным profiles и capabilities, а не через общую фразу "поддержка IPMX".
Полный технический разбор IPMX vs ST 2110 vs SDVoE с таблицами и tender-чек-листом: https://craftwall.pro/ru/articles/ipmx-vs-st-2110-vs-sdvoe/
Кросс-секторная карта compliance для российских диспетчерских: https://craftwall.pro/ru/articles/video-wall-compliance-regulatory-guide/
Broadcast-контекст для MCR/PCR и видеостен: https://craftwall.pro/ru/articles/video-wall-for-broadcast-monitoring/
## Источники
- AIMS Alliance, 5 февраля 2026: [AIMS Announces Certification of First 48 IPMX Products](https://aimsalliance.org/2026/02/05/aims-announces-certification-of-first-48-ipmx-products/)
- AIMS Alliance, 22 января 2026: [AIMS to Officially Launch IPMX as a Fully Developed Standard at ISE 2026](https://aimsalliance.org/2026/01/26/aims-to-officially-launch-ipmx-as-a-fully-developed-standard-at-ise-2026/)
- IPMX: [What is IPMX / technical overview](https://ipmx.io/)
- IPMX Technical Information: [Product Qualification and Certification Requirements](https://ipmx.io/technical-information/)
- AMWA: [NMOS specifications](https://specs.amwa.tv/)