В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Во избежание недоразумений сразу же поясню, что речь пойдет не об усилении государственного контроля над СМИ, а об усилении вашего контроля над вашим же оборудованием.
Так сложилось, что при разработке проектов вопрос создания системы контроля (или вопрос достижения совместимости с уже действующей схемой), как правило, оказывается где-то на последнем месте. Возможно, из-за расхожего мнения: контроль - это из разряда того, что само собой разумеется. А порой проектировщики надеются на традиционный русский "авось", рассчитывая, что "и так работать будет". Мысль о пользе и удобстве дистанционного контроля любого прибора, добавленного в тракт, нередко приходит уже после возникновения каких-либо проблем, связанных с его "независимым стилем поведения"
Что должна "знать" система контроля
Для начала совсем немного теории. Предположим, что весь технологический тракт телекомпании есть некий "черный ящик" с набором различных входных и выходных сигналов. В нормальной ситуации выходные сигналы "ящика" зависят некоторым образом от набора входных; их взаимосвязь абсолютно предсказуема, включая время задержки изменения сигналов на выходе в зависимости от изменения сигналов на входе.
Фактически наш "черный ящик" идеально вписывается в определение систем реального времени: "Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, затраченным на получение нужного результата. Если требования по времени не выполняются, то считается, что произошел отказ системы" (Donald Gillies). Исходя из этого определения, несложно составить общий набор требований к системе управления и мониторинга состояния технологического тракта (далее в тексте будет использоваться словосочетание "система контроля"):
Идеальная система контроля должна также "знать", как поступать в случае критических событий, или, по крайней мере, "уметь подсказать" техническому персоналу варианты решения проблемы. Существующие системы контроля в разной степени удовлетворяют упомянутым требованиям, о чем и пойдет речь ниже.
От теории - к практике
Заглянув внутрь "черного ящика", мы обнаружим огромное количество различных интерфейсов и протоколов управления. Каждое устройство может "общаться" с системой контроля на своем языке, абсолютно непонятном для других элементов. Например:
Помимо множества протоколов общее "столпотворение" пополняют их комбинации с различными интерфейсами: GPI, RS-232, RS-422, RS-485, USB, Ethernet и т.д.
Бойцы невидимого фронта
В любой студии непременно имеется целый класс "незаметных" устройств - АЦП/ЦАП, кодеры/декодеры, синхронизаторы, распределители и т.п., которые условно можно назвать периферийным оборудованием. Без этих инструментов построение тракта практически невозможно - несмотря на свою незаметность, они решают чрезвычайно важные задачи. Настройка их параметров выполняется однократно (изменения вносятся достаточно редко), но постоянный мониторинг состояния очень желателен. Решения для контроля периферийного оборудования характеризуются двумя принципиально разными подходами:
Оба подхода применяются примерно одинаково широко, оба имеют свои преимущества и недостатки. Специализированные протоколы, как правило, допускают самые широкие возможности управления, более или менее удовлетворяют требованиям, предъявляемым к системам реального времени (Snell&Wilcox RollCall, Tandberg nCompass). Но общей проблемой при реализации подобного рода решений остается "уникальность" протоколов - ни одна фирма-производитель не заинтересована в поддержке протокола, разработанного конкурентами и не принятого в качестве международного стандарта.
SNMP
Альтернативный подход - использование стандартного SNMP (Simple Network Management Protocol). Протокол SNMP изначально разрабатывался для управления сетевыми маршрутизаторами и т.п., но благодаря своей гибкости подходит для работы с самым разнообразным оборудованием, в том числе аудио/видеооборудованием (системы Leitch CSS, Miranda iControl и др.).
Формат сообщений не имеет каких-то жестких рамок. В общем случае это некий "многословный" текст, содержащий информацию о произошедшем событии, который генерируется из шаблонов, "прошитых" в само устройство. Интерпретация сообщения системой контроля зависит от настройки ее реакции на каждое конкретное сообщение: система должна "замечать" некие ключевые слова, коды и фразы в сообщениях, и в результате сделать вывод о том, что произошла какая-то ошибка, изменение и т.п.
Достоинства SNMP заключаются в его "стандартности", отлаженности и широкой поддержке большим количеством фирм-производителей самого различного оборудования. Протокол существует порядка 10 лет, на данный момент стандартизована 3-я версия этого протокола.
Нет в мире совершенства
Отметив выше плюсы, теперь следует сказать, что существуют еще и некоторые "досадные" изъяны, которые ощутимо урезают возможности SNMP. Вот их примерный перечень:
На практике зачастую оба упомянутых выше подхода применяются одновременно: например, оборудование управляется с использованием специализированных протоколов, а мониторинг осуществляется с помощью SNMP. Допускается также использование аппаратно/программных решений: они выступают в качестве "переводчика" между различными протоколами и интерфейсами, преследуя цель привести все возможные протоколы к "общему знаменателю".
Как найти "общий язык"
На рынке систем контроля также существует немногочисленный ряд универсальных решений, позволяющих внутри одной системы контроля объединять оборудование различных производителей с различными протоколами управления и физическими интерфейсами в одно целое (Broadcast Solution VSM, ILC MaxView, Harris Broadcast Manager). Общий смысл работы подобных систем сводится к преобразованию протоколов и сообщений в некий внутренний формат. Для каждого протокола/прибора используется "драйвер", занятый преобразованием протоколов/интерфейсов. С точки зрения конечного пользователя, управление и мониторинг существенно упрощаются, но эта легкость достигается путем создания драйверов для всех устройств, используемых в технологическом тракте.
Аналогичный вариант также находит применение в системах автоматизации эфира. На мой взгляд, использование подобных универсальных решений хотя и продуктивная, но вынужденная мера.
Поиски продолжаются
Естественно, подобная ситуация вовсе не "на руку" конечным пользователям и приводит к росту расходов на внедрение систем контроля. Влияние IT вносит свои коррективы - все больше компаний производят оборудование, допускающее сетевое управление и мониторинг. В некоторых случаях, чтобы сделать управление более наглядным и удобным, устройства оснащаются встроенным Web-сервером. Общая тенденция - применение сетевых систем контроля, высокоуровневых протоколов (HTTP/SOAP) и гибких способов представления данных (XML и его производные). Например, в октябре 2004 года ведущие IT-компании -AMD, Dell, Intel, Microsoft и Sun - объявили о создании протокола WS-Management, использующего Web-сервисы для удаленного контроля устройствами. Предполагается, что новый протокол должен вытеснить устаревший SNMP, он является более совершенным компонентом систем контроля.
Тем не менее, несмотря на существующие общие рекомендации SMPTE (Advanced System Control Architecture S22.02), пока что нет какого-то идеального общепринятого способа сетевого управления, к тому же полностью удовлетворяющего нужды телевещания. Как и в жизни, приходится существовать в режиме сотен языков, каждый из которых может быть хорош в своем случае.
Практика показывает: недальновидная политика в выборе оборудования приводит к тому, что любая более или менее крупная телекомпания превращается в своего рода зоопарк, в котором "каждой твари по паре". Расплачиваться за последствия подобной политики приходится эксплуатационным службам, круглосуточно озадаченным лишь одним вопросом: "Господи, а как же всем этим рулить?"
Главный специалист Snell&Wilcox
Дмитрий Иванов
Опубликовано: Журнал "Broadcasting. Телевидение и радиовещание" #4, 2005
Посещений: 12567
Автор
| |||
В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
