Обновление ПО IP-KVM TNTv для MMS-9520 и MMS-9525

Что изменилось в ПО текущей серии MMS-9520 и MMS-9525

Новая версия программного обеспечения для IP-KVM устройств TNTv MMS-9520 и MMS-9525 обновляет текущую линейку без замены аппаратной базы. Эти устройства уже много лет используются в проектах удаленных рабочих мест, диспетчерских, ситуационных центров и мультимедийных систем. В новой версии переработано ядро, добавлены функции, которые раньше приходилось решать внешней логикой, и расширены возможности операторского интерфейса.

Главная идея обновления - сделать IP-KVM систему более удобной для сложных проектов. Если раньше передатчик и приемник чаще работали как единая связка каналов, то теперь отдельные каналы можно маршрутизировать независимо. Если раньше экранное меню было алфавитно-цифровым и жестко ограниченным по отображению названий, то теперь оно стало графическим, поддерживает русские имена объектов и пригодно для эксплуатации на объектах с русскоязычными названиями источников, зон и рабочих мест.

Контекст линейки MMS-9520 и MMS-9525

Серия MMS-9520/MMS-9525 остается действующей линейкой IP-KVM оборудования TNTv. Она выпускается в России, а программное обеспечение развивается как отдельный продукт: есть базовая версия и расширенная версия с авторизацией пользователей. Новая прошивка относится именно к этой программной части. Для существующих проектов это важно, так как обновление можно учитывать при модернизации уже поставленных систем, без немедленного перехода на другую аппаратную платформу.

Обновление особенно полезно для объектов, где IP-KVM уже перестал быть простой схемой «один источник - одно рабочее место». В театральных, диспетчерских, производственных и ситуационных решениях часто нужно отдельно управлять видео, USB, аудио, RS-232 или ИК. В таких проектах цена ошибки выше: оператор должен быстро получить нужный источник, система управления должна видеть состояние устройств, а резервирование и замена оборудования не должны превращаться в длительную ручную перенастройку.

Раздельная коммутация видео, USB, аудио и управления

Базовое изменение - раздельная коммутация каналов. В стандартной схеме от KVM-передатчика (TX) к KVM-приемнику (RX) вместе переключаются видеоканал, клавиатура и мышь, USB, линейный звук, RS-232 и ИК. Такой вариант подходит для типового подключения к одному источнику. Новая логика позволяет собирать рабочее подключение из нескольких источников: видео и KM можно взять от одного передатчика, аудио - от второго, USB - от третьего, а управляющий последовательный канал - от четвертого.

Эта функция не нужна в каждом проекте, но она критична там, где источник видеосигнала и источник звука физически или организационно разделены. Например, в театральных и концертных системах звук может идти через отдельный тракт, а изображение - через другой. В мультимедийной комнате оператор может работать с видеорядом одного компьютера, но временно подмешивать звук с другого источника. Раздельная маршрутизация убирает необходимость строить внешние обходные схемы и позволяет сохранить управление внутри IP-KVM системы.

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

Новое графическое меню вместо текстового OSD

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

Для оператора это снижает количество ошибок. В реальной диспетчерской или аппаратной комнате человек работает не с условными номерами TX-01 и RX-02, а с понятными именами: сервер архива, рабочее место инженера, видеостена, источник технологической схемы, резервный ПК оператора. Чем ближе интерфейс к терминологии объекта, тем меньше нужно держать в памяти и тем быстрее выполняются штатные операции.

Русские названия объектов и сообщения поверх изображения

Поддержка русских букв в именах объектов - отдельное конкурентное преимущество. У многих производителей русифицировано само меню, но названия источников, групп и шаблонов часто остаются на латинице или в сокращениях. В обновленной версии TNTv русские имена можно использовать для устройств, групп, шаблонов и других сущностей IP-KVM системы. Это важно для производственных объектов, государственных заказчиков и служб эксплуатации, где названия технологических узлов должны совпадать с внутренней документацией.

Та же логика распространяется на информационные сообщения поверх изображения. IP-KVM система может выводить оператору текстовое предупреждение или пояснение на текущем видеосигнале. Раньше такие сообщения были ограничены английским языком, теперь их можно делать на русском. В производственной среде это не косметика: аварийное сообщение, статус источника или напоминание о режиме доступа должно быть прочитано сразу, без расшифровки условных обозначений.

Сохранение и перенос конфигурации

Новая версия добавляет функцию сохранения и загрузки конфигурации. Она нужна в двух типовых ситуациях. Первая - оперативная замена устройства. Если передатчик или приемник выходит из строя, его конфигурацию можно загрузить на новое устройство и получить функциональный аналог прежнего узла. После этого замена выполняется без длительного ручного ввода параметров.

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

SNMP-мониторинг состояния устройств

Еще одно инженерное изменение - SNMP-мониторинг. Устройство может отправлять SNMP-пакет при изменении состояния: подключение к новому источнику, пропадание видеосигнала, подключение USB-устройства и другие события. Эти сообщения можно обрабатывать стандартными средствами мониторинга или специализированной системой управления объектом.

Поддерживается и обратный сценарий: система управления может отправить SNMP-запрос и получить текущее состояние устройства. Для диспетчерских и ситуационных центров это особенно полезно, так как операторский интерфейс должен знать, что происходит в KVM-инфраструктуре. Если приемник потерял видеосигнал, переключился на другой источник или изменил USB-состояние, управляющая система может отреагировать без ручной проверки.

В проектах с большим количеством устройств SNMP снижает зависимость от нестандартной интеграции. Веб-интерфейс и API остаются полезными, но SNMP проще встраивается в существующие системы мониторинга. Это особенно заметно там, где KVM является частью общей инфраструктуры: сеть, питание, рабочие места, видеостена и управление должны контролироваться в единой панели.

Шаблоны трансляции и раскладок видеостен

Обновление добавляет шаблоны трансляции и раскладок видеостен. Их можно хранить и активировать средствами самой IP-KVM системы, без обязательного внешнего контроллера. Для каждого шаблона можно задавать права доступа, поэтому оператор видит и запускает только разрешенные сценарии.

Архитектурно это важно из-за распределенной структуры IP-KVM TNTv. В системе нет единого аппаратного или программного центра, отказ которого остановит все шаблоны. Шаблоны хранятся внутри инфраструктуры IP-KVM, а не только во внешнем процессоре управления. Максимально можно сохранить 32 шаблона. При необходимости их все равно можно активировать из внешней системы управления, но базовая отказоустойчивая логика остается внутри KVM-уровня.

Условия обновления и выбор версии

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

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

Как применять обновление в существующей системе

Для уже установленной IP-KVM системы обновление нужно рассматривать как инженерную операцию, а не как простую замену файла прошивки. В первую очередь стоит определить, какая версия программного обеспечения используется на каждом устройстве: базовая или расширенная с авторизацией. Это влияет на доступный набор функций, порядок обновления и коммерческую часть, если заказчик хочет перейти с базового уровня на расширенный.

Перед обновлением полезно сохранить текущие конфигурации передатчиков и приемников. Новая функция экспорта и импорта настроек как раз снижает риск при обслуживании, но ее нужно включить в регламент. Для каждого устройства желательно иметь актуальный файл конфигурации, таблицу соответствия физического расположения, имени в системе, IP-адреса, роли TX/RX и подключенного источника или рабочего места. Тогда восстановление после отказа не зависит от памяти конкретного инженера.

После установки новой версии стоит проверить не только факт загрузки устройства, но и пользовательские сценарии. Раздельная коммутация каналов должна быть протестирована на реальных источниках: отдельно видео и KM, отдельно USB, отдельно аудио, отдельно RS-232 или ИК, если эти каналы используются. Если объект не применяет все каналы, их все равно нужно описать в документации как доступные возможности, чтобы при будущей модернизации команда эксплуатации понимала, что функция уже есть в системе.

Изменения для службы эксплуатации

Для эксплуатации самое заметное изменение - понятные имена и статусы. В старых системах часто появляются внутренние таблицы соответствия: TX-17 означает такой-то сервер, RX-04 стоит на таком-то столе, группа G-3 относится к конкретной зоне. Когда названия можно писать на русском, часть этой расшифровки переносится прямо в интерфейс. Это не отменяет проектную документацию, но уменьшает число ошибок при переключении.

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

Третий эффект - мониторинг. SNMP-события можно завести в уже существующую систему диспетчеризации. Тогда KVM перестает быть «черным ящиком» рядом с сетью и питанием. Служба эксплуатации получает события о потере видеосигнала, подключении USB-устройства, смене источника или другом изменении состояния, а дежурный инженер может видеть проблему в общей панели, а не ждать жалобы от оператора.

Что нужно заложить в проектную документацию

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

Для шаблонов трансляции стоит заранее определить имена, назначение и права доступа. Если шаблон включает видеостену, несколько источников и рабочие места, его нужно проверить в нормальном режиме и в аварийном. Шаблон не должен существовать только как удобная кнопка, он должен быть частью сценария эксплуатации: утренний запуск, смена дежурства, аварийный режим, обслуживание, демонстрация, передача управления.

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

Практический смысл обновления

Новая версия ПО делает текущую линейку MMS-9520/MMS-9525 более пригодной для сложных объектов. Раздельная коммутация каналов расширяет сценарии интеграции, графическое меню снижает нагрузку на оператора, русские названия делают систему понятной для эксплуатации, сохранение конфигурации ускоряет замену устройств, SNMP упрощает мониторинг, а шаблоны трансляции помогают строить отказоустойчивые сценарии без обязательного центрального контроллера.

Для заказчика это обновление стоит описывать как повышение управляемости уже знакомой платформы. Оно не требует менять подход к IP-KVM, но добавляет функции, которые раньше приходилось компенсировать регламентами, внешними контроллерами или ручной работой инженера. Поэтому перед внедрением полезно провести короткую демонстрацию для операторов и службы эксплуатации: показать новые имена объектов, статусы, шаблоны, сохранение конфигурации и SNMP-события.

Главный вывод: обновление не превращает текущую серию в новую аппаратную платформу, но существенно увеличивает ее проектную ценность. Для существующих систем это путь модернизации, для новых проектов - аргумент в пользу российской IP-KVM архитектуры, где программные функции развиваются вместе с требованиями заказчиков.