Олег Березин, председатель российской секции SMPTE, директор Высшей школы киноинженеров, генеральный директор «Невафильм», выступил c докладом «Десятиминутка SMPTE Олега Березина — «Моделирование данных профиля SMPTE ST 2059-2 на языке YANG для мониторинга PTP-устройств в профессиональном вещании. Проект практических рекомендаций SMPTE RP 2059-15» на Online круглом столе «Broadcasting 2021. Системы мониторинга и управления».
Мероприятие состоялось 30 ноября 2021 года на платформе zoom. Модератор — Тимур Кулгарин, технический директор «СТС Медиа».
Олег Березин: Сегодня мы поговорим о моделировании данных профиля SMPTEST2059-2 на языке YANG для мониторинга PTP-устройств в профессиональном вещании. На самом деле это пока ещё проект рекомендаций SMPTERP2059-15, а не финальный документ.
Существует очень много задач, которые стоят перед системами мониторинга и измерения. Всем хочется, чтобы оборудование работало идеально, где надо – резервировалось, а если что-то случилось, то сразу же раздавался звонок, и можно было предпринять какие-то меры. Поэтому мотивация автоматизировать, алгоритмизировать методы измерения и мониторинга очевидна и понятна.
РТР
РТР – это протокол точного времени, разработанный в документе IEEE-1588. В 2019 году была уже третья итерация этого документа, и самое важное внешнее изменение последнего времени – это то, что теперь, вместо термина Ведомые часы-генератор Slaveмы используем термин часы-генераторы Follower. А вместо Ведущего генератора-часов Master– используем часы-генераторы Leader. Терминология, конечно, далеко не все изменения версий стандарта IEEE-1855, но это тема отдельной дискуссии.
В развитие применения стандарта IEEE-1588 в медиаиндустрии, SMPTE выпускает свой профиль IEEE-1588 протокола передачи точного времени в сфере телевидения, в сфере ОТТ, описанный в стандарте ST2059-2.
Вообще стандарт РТР используется очень широко в многих отраслях народного хозяйства. Например, в сетях передачи электроэнергии, в умных сетях, в ЦЕРНе. Это широко применяемый и хорошо описанный протокол, но определяющий общие подходы к механизму передачи данных точного времени, поэтому для каждой конкретной отрасли народного хозяйства, отраслевые стандартизирующие организации выпускают тот или иной профиль с какими-то ограничениями, с какими-то нюансами, которые свойственны именно этой индустрии.
Зачем мы вообще говорим о РТР и что пытаемся измерить? Сегодня в IT-инфраструктуре медиавещания мы используем разные типы устройств от простых микрофонов до облачных сервисов и хранения, кодирования и передачи медиаданных. Задействуем разнообразные технологии вещания, которые становятся гибридными. Такое многообразие сегодняшних решений просто поражает.
IP-сети по своей логике «немножко» отличаются от привычных нам сетей передачи медиасигналов, потому что, как только у вас в одном месте что-то начинает в IP-сети «сыпаться», это может повлечь за собой лавинообразное развитие процессов в другой части вашей медиасети. Поэтому за всем надо следить, всё надо контролировать, всё надо мониторить.
По мониторингу в области РТР есть много параметров для контроля. Начиная от времени, которое система выбирает: само время РТР, координированное время, местное время или собственное время медиаузла, потому что он потерял связь с внешним генератором Grandmaster. РТР – достаточно своеобразный механизм передачи данных: данные могут идти, условно говоря, «с неба на землю и от земли обратно на небо» (то есть из локальных систем в облачные и обратно) с разным временем задержки. И для точности измерения времени РТР очень важный момент –это симметрия пути. То есть сигнал приходит одним путём, обратно ответ уходит другим путём, что порождает ошибки в измерении передаваемых значений времени. Соответственно, каждый медиаузел, а это каждое устройство, которое у нас есть в IP-сети, определяется своей определенной стабильностью, каждый из них выбирает свой Leader, он может потеряться и не выбратьLeader, поэтому все надо контролировать.
Какая мотивация?
Все устройства в нашей IP-медиасети в логике ST2110 должны работать с РТР-синхронизацией. Но при этом, уже сегодня у нас есть большое количество устройств, и все они реализуются разными способами, поэтому очень хочется какой-то определенности в этой системе.
Какое решение может здесь быть? Решение найдено в создании некой унифицированной модели мониторинга РТР. Все хотят определенного однообразия: общепринятого описания данных, общепринятого представления этих данных, возможности сравнивать и валидировать эти данные, чтобы данные, полученные от одной медиасистемы были сравнимы с данными другой медиасистемы, а они могут быть разнообразными. Поэтому и важна унификация разнообразия различных методов получения данных и информации о РТР-устройствах и PTP-соединениях.
Объединение моделей мониторинга
Каким образом эта унифицированная модель может быть реализована? В рамках рабочей группы SMPTE была предложена идея объединить три составных части моделей мониторинга.
- Во-первых, это использование Баз Управляющей Информации MIB, которые на сегодняшний день есть у каждого «приличного» устройства.
- Во-вторых, использовать стандарт интернета RFC 8575 по моделированию данных протокола РТР на языке YANF. Так как протокол РТР используется во многих областях, то это не изобретение велосипеда, а использование общепринятых на сегодняшний день в интернет-сообществе стандартов и решений.
- Третье – использование еще одного инструмента, так называемого «демона GPS» (GPSd). Демон позволяет системе взаимодействовать непосредственно с приемниками GPS-сигналов, так как они имеют определённую особенность. Это уже давно используемая мини-исполняемая программа с определёнными протоколами, которая позволяет работать с GPS-приёмником. Она используется в авиационной и автомобильной навигации, например, когда мы пользуемся Яндекс-картами.
База Управляющей Информации MIB
База Управляющей Информации достаточно проста в своей логике. Это иерархичное хранение внутри самого устройства информации о нём. И можно запросить у этого устройства определенным образом тот или иной объект базы MIB. В итоге мы получим информацию, относящуюся:
– к общему типу устройства
– к интерфейсам, которые есть у этого устройства
– специализированным особенностям.
То есть всю информацию, которую устройство готово о себе рассказать, мы можем получить с помощью доступа к базе MIB устройства. Доступ осуществляется достаточно простыми протоколами типа SNMP, и сегодня это тоже стандартизировано. Отмечу, что именно IEEE взяло на себя стандартизацию всего, что касается интернета и сетевых устройств.
Язык YANG
Язык YANG (Yet Another Next Generation – «ещё одно поколение» языка моделирования) – широко применяется сегодня, например, в протоколах NETCONF и RESTCONF. Этот язык – достаточно формализованное иерархическое описание форматов параметров, которые мы хотим получить от устройства или передать в устройство. Язык определяет сами форматы, типы, способы общения между клиентом и тем или иным устройством. Он поддерживает разные языки, можно формат текста передавать в JSON, можно в XML. NETCONF и RESTCONF широко применяются для автоматической настройки сетевых устройств, для сбора информации обо всех устройствах нашей IP-сети.
В принципе, задача языка моделирования заключается в том, чтобы задать структуру, каркас. Например, мы хотим получать данные с телекамер, которые стоят в студии. И мы понимаем, что один телеканал принял нумерацию камер «1, 2, 3, 4,…», на другом телеканале все камеры помечены римскими буквами, а на третьем канале вообще словами подписаны все камеры. Если мы хотим мониторить системы и как-то сравнивать данные, и понимаем, что используются разные типы названий, то задача языка моделирования – оговорить, что, например, номером камеры является некое целое число, и оно не должно повторяться. Тогда система будет понимать, что нужно отдать данные о камере в виде числа, и все системы будут эти данные одинаково получать и одинаково их интерпретировать.
Демон GPS
«Демон GPS» – третья составная часть проекта по унификации мониторинга. Это микропрограмма, которая позволяет с помощью определенных запросов получать от приемника GPS те или иные данные. Мы можем запросить:
- время
- наши координаты и скорость движения
- направление движения
- список видимых спутников
- координаты
- получить оценку точности этих координат в зависимости от сигнала спутника.
«Демон GPS» — это микропрограмма, которая общается со всеми приёмниками GNSS (GPS, ГЛОНАСС и др.), которые у нас есть.
Повторюсь, что модель данных обеспечивает набор данных, которые в данном случае относятся к РТР, и обеспечивает общий язык описания форматов и параметров. Мы можем задать минимальные и максимальные параметры, параметры по умолчанию, и нам нужен некий стандарт этих параметров. Затем мы можем использовать эту модель в других инструментах измерения, она может использоваться производителями оборудования, чтобы все оборудование разговаривало на одном языке, чтобы данные, которые мы получаем с этого оборудования, были однотипны и сравнимы. К тому же мы все формализуем, какие данные мы собираем, с каких устройств и как мы их собираем.
RP 2059-15
Это проект рекомендованной практики SMPTERP 2059-15, который сегодня находится в стадии разработки и публичного обсуждения специалистами медиаиндустрии. Документ предлагает описать на базе языка моделирования YANG стандартизированную модель, которая будет описывать все типы данных, все форматы, которые мы можем получить с различных устройств, которые используют РТР, в нашей медиасфере.
Еще раз отмечу, что это пока еще проект документа, который находится в стадии обсуждения, он не может использоваться публично как финальный документ. Возможно, что после дискуссий его еще и не примут в том виде, как он сформулирован сейчас, но, в принципе, все идет к тому, что примут.
Тимур Кулгарин: Этот профиль данных предлагается использовать в любых системах мониторинга, чтобы мониторить системы синхронизации РТР для медиакомпаний?
Олег Березин: Да. В этом и идея, чтобы все производители оборудования, все производители программных решений и все потребители приняли такой формат получения данных. Понятно, что разные устройства передают не все данные, но если мы передаём какой-то параметр, то все должны принимать его единообразно, например, в одинаковых единицах времени. Вы можете взять другую систему мониторинга, подключить ее к другому оборудованию, и она тоже должна понимать, что с чем общается, какие параметры запрашиваются и передаются в каких форматах и в каких единицах измерения. В конечном итоге, реализация рекомендованной практики SMPTERP 2059-15 позволить еще больше автоматизировать технологические процессы медиавещания и упростить нашу жизнь.
