Статья: MIDI в деталях. MIDI Show Control.

MIDI     в    деталях    .  MIDI Show  Control.  Часть 1 Справочные данные,  Теория музыки » Всё о MIDI Седьмая часть цикла статей, подробно  рассказывающих о протоколе MIDI.  С некоторых пор слово "шоу" прочно  закрепилось в нашем языке для  обозначения всего того, что раньше  называлось представлением.  Спектакль, мюзикл, концерт — то есть некое массовое мероприятие, где  задействованы артисты, звук, свет,  видео, спецэффекты. На западе "шоу"  трактуется и в более широком смысле, начиная от мультимедийной лекции  или семинара и заканчивая парками  развлечений по типу Диснейленда. А если говорят о "живом" выступлении,  то есть когда на сцене работают  артисты, используется более  конкретное Live Show.  Техническое обеспечение  современного шоу может включать в  себя весьма сложный комплекс  оборудования: звуковые и световые  системы, видеопроекторы, механику  сцены, пиротехнику, динамические  пневмофигуры, трансформируемые  декорации, спецэффекты разного  калибра. Многое из перечисленного  (например, акустические системы и  световые приборы) зрители видят  непосредственно. Но есть еще и  подводная часть айсберга —  вспомогательное оборудование,  начиная от простейших механических  переключателей и заканчивая  интеллектуальными устройствами и  робототехникой, а также  компьютерными программами,  обеспечивающими согласованную  работу всех систем.  Технология управления шоу  зародилась еще в 60­е годы, в развлекательных парках. Все началось, конечно, с ручного управления, когда  стейдж­менеджер подавал команды  голосом, а оператор конкретного  устройства (например, электрического подъемника) их исполнял. Один из  американских стейдж­менеджеров  вспоминает, как ставились мюзиклы на Бродвее: "В шоу было занято от 40 до  50 техников, бегающих за сценой как  сумасшедшие. Я использовал вспышки  света, чтобы дать команду на запуск  определенной сцены, давал команды  операторам через головные гарнитуры  и работал по сценарию, записанному на листке бумаги".  Сегодня технология управления шоу  — это целая индустрия со своими  стандартами и протоколами. Приборы  одного типа объединены в системы:  управления светом, звуком,  машинерией (механикой сцены),  проекцией, пиротехникой. Каждая  система состоит из контроллера и  конечных приборов, которыми  контроллер управляет посредством  определенных сигналов. Например,  световой пульт может управлять диммерами и сканерами посредством  цифрового протокола DMX­512 по  интерфейсу RS485. Эти устройства  совместно с пультом образуют  самостоятельную шоу­систему, внутри которой все взаимодействие  происходит с помощью протоколов  класса "контроллер­прибор".  Термин Show Control означает нечто  большее — соединение  самостоятельных шоу­систем в одну  большую управляемую систему. Так,  компьютер, подключенный к дым­ машине и регулирующий количество  тумана в декорации морской гавани — это еще не система Show Control, как,  впрочем, и звуковая система,  воспроизводящая шум прибоя сама по  себе. Только объединение этих систем  в одну, управляемую от главного  контроллера, является полноценной  системой управления шоу.  По отношению ко времени все шоу  можно разбить на два типа:  асинхронные и синхронные. Пример  асинхронного шоу — "дом с  сюрпризами" в парке развлечений. Здесь посетители, бродя по дому,  задевают разные датчики, запуская  сопоставленные с датчиками сцены (то есть последовательности каких­либо  механических процессов, звуковых и  световых сигналов). Все сцены могут  происходить в разных частях "дома"  одновременно и независимо друг от  друга, без привязки к единой шкале  времени.  В синхронном шоу, как следует из  названия, используется некий способ  синхронизации событий. Каждое  событие привязано к определенному  моменту времени, а шкала времени  формируется мастер­устройством на  основе, например, видеофрагмента или саундтрека. Мастер­устройство  генерирует таймкод, который  поступает в подчиненные контроллеры или непосредственно в конечные  приборы. Возможен и более простой  вариант, при котором устройства  только стартуют одновременно, по  команде с главного контроллера, а  долговременная постоянная  синхронизация отсутствует. Пример  синхронного шоу — концерт или спектакль, где световые сцены и  другие элементы шоу  синхронизированы со звуком.  Появление MIDI Show Control В конце 80­х годов прошлого века  протокол MIDI стал привлекать  внимание театральных инженеров и  специалистов по концертному свету в  качестве альтернативы  существовавшим на тот момент  протоколам управления. И хотя MIDI­ секвенсоры и средства ввода  (контроллеры) не очень подходили для задач театральной автоматизации, сам  протокол подходил вполне, как по  возможностям, так и из­за невысокой  стоимости и широкой  распространенности.  Основная задача состояла в вызове  сцены, запрограммированной в  световом пульте. На всякий случай  уточню, что сцена — это  фиксированное состояние функций  осветительных приборов. Сцена могла  быть сколь угодной сложной (с  закольцовками, связанными макросами, подпрограммами и т. п.),  но для ее вызова требовалось нажатие  всего пары кнопок светового пульта:  LOAD (загрузить) и GO (запустить).  Очевидно, MIDI здесь вполне мог  заменить оператора пульта. Все, что  нужно передавать в сообщении, — это  номер сцены и саму команду. А  данные, связанные со сценой,  находились бы в памяти светового  пульта.  Постепенно производители светового  оборудования стали использовать  MIDI в своей продукции. Но, как это  часто бывает, возникла проблема  совместимости. Компании,  занимающиеся театральным светом,  производили системы, в которых  сцены менялись MIDI­сообщением  Program Change, а компании,  производящие концертное световое  оборудование, использовали команды  Note On.  В 1989 году Andy Meldrum, сотрудник  фирмы Vari­Lite, предложил  разработать открытый протокол,  который позволял бы соединять шоу­ системы разного назначения и разных  производителей, и управлять ими с  помощью любого MIDI­контроллера. К концу 1989 года Charlie Richmond из  компании Richmond Sound Design  организовал рабочую группу в составе  MMA (MIDI Manufactures Association)  и открыл форум на электронной доске  объявлений. Созданный в результате  проект стандарта был утвержден  MMA и JMSC (Japanese MIDI Standard Committee) и 25 июля 1991 года  превратился в "Рекомендованную  практику RP­002", или, иначе, в MIDI  Show Control версии 1.0.  Основные принципы Протокол MIDI Show Control (MSC)  предназначен для объединения  интеллектуальных систем управления  шоу­техникой (контроллеров) в  единую сеть. MSC напрямую не  управляет конечными приборами и не  заменяет такие протоколы класса  "контроллер­прибор", как DMX­512  или Strand. Это очень похоже на  соединение MIDI­секвенсора и  синтезатора. Секвенсор посылает синтезатору высокоуровневую  команду "взять ноту", а синтезатор в  ответ запускает заложенную в его  недрах программу формирования  звука, то есть целый набор  низкоуровневых операций.  В спецификации MSC используются  термины Controller и Controlled Device. Обычно MSC­система состоит из  одного, главного контроллера — им  чаще всего является обычный  компьютер (PC или Mac) с  соответствующей программой  управления и MIDI­интерфейсом.  Этот компьютер и называется в  спецификации словом Controller. А  световой пульт в данном случае  является управляемым устройством  (Controlled Device), которое выполняет команды главного контроллера,  переводя их в команды типа  "контроллер­прибор" и посылая  последние к световым приборам по  своим коммутационным каналам,  независящим от MIDI (в случае DMX­ 512 — это витая пара с земляным  проводом в оплетке). Схожим образом к главному  контроллеру подключаются по MIDI  остальные шоу­системы (механика  сцены, пиротехника и тому подобное).  Набор команд MSC основан на  структуре команд существовавших в  то время шоу­систем.  Управляемое устройство (например,  световой пульт) может также  передавать команды MSC через свой  MIDI­выход. Это позволяет  записывать действия, производимые  оператором на пульте — примерно так же, как происходит запись в секвенсор с MIDI­клавиатуры. Только в данном  случае используется программа,  оперирующая не треками, а списками  сцен (Cue List). При записи она  фиксирует все события, приходящие  от управляемых устройств, и  размещает их в списке сцен со своей  позицией на шкале времени.  Таким образом, можно заранее  прописать нужную последовательность событий с каждого пульта управления, используемого в шоу, отредактировать полученные данные, а во время шоу запустить список на воспроизведение.  В MSC используется таймкод MTC, а  это значит, что управляемые  устройства можно синхронизировать с  главным контроллером. Свет со  звуком, изображение со светом, и всю  систему в целом. При этом точность  выдачи команд по времени равна  одному кадру (то есть около 1/30  секунды).  Кроме того, по MSC можно связать  несколько контроллеров одного типа.  Так, например, если две световые  консоли соединены по MIDI, то  нажатие кнопки GO на одной из них  приведет к тому, что вторая консоль  отработает ту же команду GO, но уже  без оператора. Здесь все довольно  очевидно и напоминает  первоначальное предназначение MIDI  — управлять с одной клавиатуры  несколькими синтезаторами  одновременно.  Важный принцип управления "живым"  шоу состоит в том, что сбой одного  управляемого устройства не должен  привести к сбою в управлении другими устройствами. Этот принцип может  быть реализован с помощью открытой  или закрытой петли.  В системе "открытая петля"  подтверждение команд от  управляемого устройства к  контроллеру не требуется.  Используется однонаправленная  передача данных и, соответственно,  одностороння коммутация. То есть,  MIDI­выход главного контроллера  соединяется с MIDI­входом  управляемого шоу­устройства, и  только. Этот экономичный способ был  выбран в MSC в качестве основного.  В системе "закрытая петля"  используется взаимная коммутация  устройств и ожидается  стандартизированный ответ от  управляемого устройства. Такая  система требует более  интеллектуальных контроллеров и  занимает большую полосу  пропускания, но при этом достигается  большая точность во взаимодействии  устройств, обнаружение, коррекция  ошибок и прочие прелести. Метод закрытой петли предложен в версии  MSC 1.1, появившейся в феврале 1996  года (документ RP­014). Для работы в  режиме закрытой петли используется  двухэтапный протокол подтверждения (2 Phase Commit), о котором  поговорим в следующей статье.  Предосторожности и ограничения В шоу­системе нередко используется  опасное оборудование (в том числе  представляющее угрозу для жизни),  например, пиротехника или механика.  Но это не значит, что такое  оборудование управляется MSC  непосредственно, и сбой или ошибка в  программе приведут к неприятным  последствиям. Спецификация  крупными буквами предупреждает:  "[Протокол MSC] никоим образом не  отменяет обычные меры безопасности,  какие должны соблюдаться при  использовании потенциально опасного  оборудования. Для максимальной  безопасности должны применяться  такие ручные элементы управления,  как аварийные выключатели,  блокираторы, ограничители, системы подтверждения команд и прочее. Из  автоматических устройств —  запирающие переключатели, датчики  близости, детекторы газа,  инфракрасные камеры, датчики  движения и давления. Протокол MSC  не предназначен для отдачи команд  опасному оборудованию. MSC лишь  подает сигнал о действии, которое  желательно выполнить, если все  требования и условия безопасности  соблюдены. Только соответствующим  образом спроектированные системы и  подготовленный обслуживающий  персонал могут определить, насколько эти требования выполняются в  конкретной ситуации. Метод  двухэтапного подтверждения 2PC  исключительно надежен и может  использоваться для обеспечения  дополнительной безопасности в шоу­ системах. Однако 2PC должен быть  реализован в соответствии с  требованиями этой спецификации и  только в дополнение к  вышеперечисленным мерам".  MIDI Show Control не является  единственно возможным решением для управления шоу­системами. Он не  лишен некоторых недостатков,  присущих технологии MIDI в целом.  Первый недостаток — невысокая  скорость передачи данных, а,  следовательно, не всегда адекватное  время отклика приборов. Иногда эта  проблема устраняется простой  разгрузкой линии, то есть соединением приборов не цепочкой, а "звездой" из  распределительной коробки (MIDI  Thru Box) или многоканального MIDI­ интерфейса/маршрутизатора.  Для большинства же задач управления  шоу, скорость MSC вполне приемлема  и даже избыточна. Например,  стандартная команда "Свет­Сцена  36.1­Пуск" займет 10 байт, которые  будут переданы примерно за 3 мс  (подробности смотрите в предыдущих  статьях цикла). Это время примерно в  сто раз меньше среднестатистической  скорости реакции оператора пульта.  Второй очевидный недостаток —  максимальная длина MIDI­кабеля,  которая не должна превышать 15  метров. Он может быть устранен применением усилителей на линии  ("бустеров"), в результате чего длина  линии может быть доведена до трехсот и более метров. Кроме того, есть и  другие варианты передачи MIDI­ сообщений (FireWire или  беспроводные системы).  Формат сообщений Сообщения MIDI Show Control  относятся к категории универсальных  эксклюзивных сообщений реального  времени (Universal Real Time System  Exclusive) и используют Sub­ID#1 =  0x02 (подробнее о системных  сообщениях и Sub­ID см. в третьей  статье цикла).  Шаблон сообщения MSC показан на  рис. 1. Начинается сообщение байтом  0xF0, признаком SysEx. Затем идет  байт 0x7F, определяющий категорию  реального времени, затем передается  номер прибора, которому адресовано  сообщение. Далее — Sub­ID 0x02,  признак MSC. Байт формата команды  показывает, к какой категории  оборудования относится сообщение: к звуку, свету, механике и т. п. Далее  следует сама команда. Как правило,  это одно действие, например, "пуск"  или "стоп". Затем передаются  дополнительные данные — параметры  команды. Чаще всего это номер сцены  и данные времени. Завершается SysEx­ сообщение, как обычно, байтом 0xF7.  Общее число байт в сообщении MSC  не должно превышать 128.  Как правило, команды адресуются  одновременно только одному  устройству. Например, для  выполнения команды GO на двух  световых пультах нужно передать от  главного контроллера сообщения,  показанные на рис. 2.  Номера с 0x00 по 0x6F соответствуют  индивидуальным устройствам. Номер  устройства, как правило, задается  пользователем в настройках (как  главного контроллера, так и управляемого). Возможно также  создание групп устройств, для чего  используются групповые  идентификаторы (с 0x70 по 0x7E, то  есть всего до 15 групп). Это удобно,  если одни и те же сообщения  необходимо постоянно посылать  нескольким устройствам. Не все  устройства обязаны отвечать на  групповые номера.  Наконец, есть специальный  широковещательный номер 0x7F,  который используется для передачи  сообщений всем устройствам сети,  независимо от того, на какой номер  они настроены. Один управляемый  контроллер может отвечать на  несколько номеров, как  индивидуальных, так и групповых. И  наоборот, несколько управляемых  контроллеров могут отвечать на один  и тот же номер, что позволяет  обойтись для них одним сообщением.  Формат команды Название "формат команды"  (command_format), на мой взгляд, несколько неудачно, поскольку не  отражает сути вопроса; к тому же, его  можно перепутать со следующим  байтом — самой командой. Формат  команды в терминологии MSC — это  просто­напросто категория  оборудования, для которой  предназначено сообщение.  Стандарт определяет несколько общих категорий, внутри них — несколько  более конкретных, и особую  категорию All­types. К общим  категориям относятся свет, звук,  машинерия, видео, проекция,  спецэффекты и пиротехника. Номера  этих категорий содержат в младшем  полубайте ноль, за исключением  категории "свет". Номера более  конкретных категорий заключены  внутри общих и имеют тот же старший полубайт, что и общая категория (рис.  3). MIDI     в    деталях . MIDI  Show  Control. Часть 2 Справочные данные, Статьи о музыке » Теория музыки » Всё о MIDI Двухэтапное подтверждение (2PC, Two  Phase Commit) — это особый метод  взаимодействия устройств, при котором все команды подтверждаются и до выполнения, и по завершении. Технически — это набор  команд, расширяющих базовую версию  протокола MIDI Show Control. Этот набор  появился в 1996 году и описан в документе  RP­014, выпущенном организацией MMA.  Вместе с исходной спецификацией MSC  (документ RP­002) он образует новую  версию протокола (MIDI Show Control 1.1). При разработке метода 2PC стояла  непростая задача — обеспечить связь  нескольких устройств закрытой  архитектуры друг с другом, при которой  все они работают согласованно либо не  работают совсем, независимо от наличия  ошибок в коммутационных каналах. Задача  была решена с использованием двух фаз  (этапов) в коммуникации. На первом этапе  все стороны соглашаются о том, что должно быть сделано. На втором этапе стороны  реализуют это соглашение и сообщают о  результатах.  Метод двухэтапного подтверждения  напоминает метод сценической  координации, применяемый при  взаимодействии стейдж­менеджера и  оператора устройства. Первая фаза —  ожидания (STANDBY), соответствует  команде "приготовиться". Вторая фаза —  "выполнить" или "пошел" (GO).  Метод 2PС предлагается использовать для  тщательно спланированных шоу и тогда,  когда в целях безопасности требуются  дополнительные проверки и избыточность в  механизмах управления (например, при работе с машинерией или пиротехникой).  При этом обеспечиваются проверка данных  и обнаружение ошибок в коммутационных  каналах.  2PC требует взаимной коммутации  устройств. Это значит, что, кроме  соединения главного контроллера с  контролируемым устройством, требуется и  обратное, то есть MIDI­выход пульта  управления прибором соединяется с MIDI­ входом главного контроллера. Команды  2PC образуют четвертый рекомендованный  набор (о первых трех см. предыдущую  статью), он приведен в таблице на рис. 1.  Спецификация предполагает, что в системе  2PC около каждого контроллера и  контролируемого устройства присутствует  человек­оператор, который называется в  данном случае "локальный оператор".  Локальный оператор может просто  наблюдать за процессом, либо выполнять дополнительную проверку безопасности и  ручное вмешательство в управление при  сбое оборудования. Предполагается, что  локальный оператор выполняет свои  функции через специальную панель  управления (пульт или схожий интерфейс),  который называется "интерфейс локального оператора".  Сообщения 2PC В отсутствие сбойных ситуаций для  выполнения одной сцены в протоколе 2PC  используются четыре сообщения. Они  показаны в таблице на рис. 2 с указанием  порядка следования и стороны­ отправителя.  Сначала главный контроллер посылает  подчиненному устройству сообщение  STANDBY ("приготовиться"). Это  сообщение "разогревает" прибор и  уведомляет его о том, что скоро должна быть выполнена заданная сцена. В ответ на  это устройство отвечает контроллеру  сообщением STANDING_BY ("наготове"),  показывая свою готовность выполнить  данную сцену. Для выполнения сцены  главный контроллер посылает сообщение  GO_2PC. Последнее сообщение серии,  COMPLETE ("выполнено"), посылается  прибором главному контроллеру и  сообщает о том, что выполнение сцены  завершено успешно.  Предусмотрены также три сообщения на  случай, если произошел сбой: ABORT,  CANCEL и CANCELLED.  Если контролируемое устройство  обнаруживает сбойную (исключительную)  ситуацию, то есть ситуацию, когда  нормальное выполнение сцены невозможно,  оно уведомляет об этом главный  контроллер посредством сообщения  ABORT. Для указания причины сбоя в это  сообщение помещается код состояния, на  основании которого главный контроллер  может выбрать дальнейший вариант  действий.  Сообщение CANCEL посылается от контроллера к прибору и говорит о том, что предыдущее сообщение (STANDBY и/или  GO_2PC) нужно отменить. В ответ на это  прибор может ответить сообщением  CANCELLED ("отменено"), подтверждая  отмену предыдущих команд.  Сообщения 2PC имеют несколько общих  элементов, таких как номер секвенции (nn  nn), контрольная сумма (сс), код состояния  (s1 s2) и данные сцены (d1 d2 d3 d4). Эти  элементы описаны далее, в  соответствующих разделах. На рисунках 3­9 показана структура сообщений 2PC. Номер секвенции Нумерация сцен в сообщениях от  контроллера к контролируемому  устройству происходит в протоколе 2PC  так же, как и в обычных сообщениях MSC  (то есть с помощью полей Q_number, Q_list  или Q_path, см. предыдущую статью). Кроме того, для каждого из сообщений  STANDBY, GO_2PC и CANCEL главный  контроллер генерирует уникальный номер  (от 1 до 16383), который называется  номером секвенции. Этот же номер  передается в обратных сообщениях  (STANDING_BY, COMLETE,  CANCELLED и ABORT), и по нему  главный контроллер определяет, к какой  сцене относится сообщение. Таким образом, в обратных сообщениях достаточно  использовать только номер секвенции,  полный номер сцены передавать не нужно. Номера секвенций позволяют работать по  методу 2PC простым устройствам, таким  как различные детекторы и датчики.  Например, детектор газа может не понимать концепцию сцен. При получении сообщения  STANDBY он просто проверяет наличие  газа. Если газ не обнаружен, детектор  отвечает сообщением ABORT, если  обнаружен — сообщением STANDING_BY. Детектор игнорирует поля типа Q_number и просто копирует номер секвенции из  входящего сообщения в исходящее. Кроме  того, номера секвенций облегчают  отслеживание ответных сообщений от  контролируемых устройств оператору  главного контроллера.  Контрольные суммы Каждое сообщение 2PC содержит  контрольную сумму, состоящую из двух  MIDI­байт (14 бит). При расчете  контрольной суммы поля command_format,  command и data сообщения  рассматриваются как массив двухбайтовых  значений. Если число байт в этих полях  нечетное, для расчета суммы в конец  добавляется один нулевой байт. Перед расчетом те байты, которые занимает  контрольная сумма, обнуляются.  Контрольная сумма рассчитывается путем  простого сложения элементов полученного  массива, при этом переполнения  игнорируются. После чего к полученному  результату прибавляется номер устройства. В завершении над полученным числом и  константой 0x7F7F (32639) выполняется  логическая операция AND (см. статью  цикла "Передача данных.").  Сторона, принимающая сообщение,  проверяет его правильность, заново  рассчитывая контрольную сумму и сверяя  ее с полученным значением в сообщении.  Если контрольная сумма отличается на  стороне контролируемого устройства, оно  посылает контроллеру сообщение ABORT с кодом состояния "ошибка контрольной  суммы". Если сумма отличается на стороне  контроллера, он реагирует на это так, будто было получено сообщение ABORT.  Коды состояния Коды состояния используются в  сообщениях ABORT и CANCELLED и отражают причину ошибки или состояние  отмененной сцены. Код состояния  представляет собой беззнаковое  двухбайтовое целое число. Чтобы оно  могло быть передано по MIDI, два младших бита числа должны быть нулевыми.  Соответственно, наименьший код состояния будет равен 4, наибольший 0xFFFC (65532).  В описании сообщений статус­код выглядит как "s1 s2". Метод преобразования кода  состояния в значения s1 и s2, и наоборот,  показан на рис. 10.  Есть три числовых диапазона кодов  состояния. Первый диапазон — общий для  всех форматов команд, коды состояния в  нем применимы для любых типов  контроллеров. Характерная особенность  этих кодов в том, что все они являются  отрицательными числами, если  рассматривать код как целое число со  знаком (подробнее о представлении целых  отрицательных чисел см. четвертую статью  цикла). Все коды, возвращаемые в сообщениях CANCELLED, попадают в этот первый диапазон.  Второй диапазон зависит от формата  команды, то есть специфичен для устройств определенного типа. Например, код  состояния 0x1008 означает "низкое  давление воды", если получен от устройства типа "спецэффект" (формат команды от  0x50 до 0x5F). Но когда тот же код получен от устройства управления звуком (формат  команды от 0x10 до 0x1F), он означает  "неполадки в усилителе".  Третий диапазон зависит как от формата  команды, так и от производителя. То есть,  производители используют коды состояния  в третьем диапазоне по своему усмотрению. Информация об этих кодах обязательно  должна быть опубликована. Естественно,  наибольшая совместимость систем  достигается в том случае, если коды из  этого диапазона используются как можно  реже. Спецификация 2PC рекомендует  всегда, когда это возможно, использовать  коды состояния из второго диапазона.  Код состояния 0 зарезервирован на случай  неизвестной ошибки или ошибки, для обозначения которой другие коды не  подходят. Таблица на рис. 11 подытоживает вышесказанное.  В таблицах на рис. 12 и 13 приведены все  коды состояния, не зависящие от формата  команды. Буквы в столбце "Сообщения"  показывают, какие сообщения могут  привести к получению ответа от устройства с данным кодом состояния (S=STANDBY,  G=GO_2PC, C=CANCEL). Первая таблица  содержит коды состояния, используемые в  сообщении CANCELLED, вторая — в  сообщении ABORT. Обратите внимание,  что сообщение ABORT, посланное  прибором в результате обработки  сообщения CANCEL, может иметь только  два кода состояния:  "неизвестная/неопределенная ошибка" и  "ошибка контрольной суммы". Код  состояния "тайм­аут" никогда не  появляется в реально передаваемых  сообщениях, он включен для упрощения внутреннего устройства контроллера.  В таблице на рис. 14 перечислены коды  состояния из второго диапазона, то есть коды, которые зависят от формата  команды, но применимы ко всем  производителям устройств.  Данные сцены В сообщениях STANDBY и GO_2PC используются четыре семибитных байта  данных. Эти байты должны присутствовать  обязательно, независимо от того,  используются ли они контролируемым  устройством или нет. Если корректные  значения d1­d4 для данной сцены (или для  данного прибора) неизвестны, на их месте  должны быть переданы нули.  Байты данных позволяют сопоставить со  сценой дополнительную информацию.  Например, в световых пультах, работающих по принципу "Go On, Go Off", используется  величина "Go Level", или gl, которая  задается выражением gl = d1 + (d2*128).  Последовательность команд STANDBY­ GO_2PC со значением gl=255 эквивалентна  команде Go On. Та же последовательность  со значением gl=0 эквивалентна команде Go Off. Допустимы и промежуточные значения  gl от 0 до 255. Например, значение gl=128  эквивалентно команде "Go Cue To 50%".  Любое значение gl вне диапазона 0­255 в  настоящее время является некорректным, а  при его получении прибор должен  отправить сообщение ABORT со статус­ кодом "некорректное значение данных  сцены d1". Значения gl=256 и выше  зарезервированы для возможных будущих расширений.  В других типах устройств использование  байтов d1­d4 определяется производителем  и должно быть описано в документации.  Если устройство получает некорректные  данные d1­d4, оно должно ответить  сообщением ABORT с одним из кодов  состояния "некорректное значение данных  сцены dx". Например, некорректное  значение d1 должно привести к сообщению  ABORT с кодом "некорректное значение  данных сцены d1". В тех случаях, когда  ошибка данных касается более чем одного  байта d1­d4, сообщение ABORT должно  содержать код состояния, соответствующий наименьшему ошибочному байту.  Устройства, которые понимают только  часть байтов данных, например, d1 и d3,  должны игнорировать значения остальных  байт.  Взаимодействие устройств Итак, выполнение сцены начинается с  команды "приготовиться" (STANDBY),  которую главный контролер посылает  контролируемому устройству. Главный  контроллер ожидает ответного сообщения STANDING_BY в течение двух секунд.  Если за это время оно не приходит, главный контроллер считает, что прибор ответил  сообщением ABORT. Если по любой из  причин прибор не может подготовить  данную сцену к выполнению, то он отвечает  сообщением ABORT явно.  Ответное сообщение STANDING_BY  посылается только в том случае, если  запрошенная сцена известна прибору,  находится в его памяти и готова к  немедленному выполнению. В сообщении  STANDING_BY прибор передает также  максимальное время, требуемое для  выполнения сцены. Позже контроллер  использует это время, чтобы определить, не произошел ли сбой в контролируемом  устройстве. Максимальное время может  быть значительно больше реально  требуемого для сцены, но никак не меньше.  Если для выполнения сцены требуется  вмешательство оператора, то время  ожидания действий оператора также  должно учитываться.  После успешного обмена STANDBY­ STANDING_BY главный контроллер  посылает сообщение GO_2PC, которое приводит к выполнению заданной сцены. По завершении сцены прибор отправляет в  главный контроллер сообщение  COMPLETE. Если во время выполнения  сцены происходит сбой, прибор немедленно передает сообщение ABORT с  соответствующим кодом состояния. Если  сообщение GO_2PC пришло с тем номером  сцены, для которого еще не поступало  сообщения STANDBY (вероятно, из­за  ошибки в главном контроллере), то прибор  должен ответить сообщением ABORT с  кодом состояния "не в режиме ожидания".  Контролируемое устройство не обязано  помнить акт обмена STANDBY­ STANDING_BY для какой­либо сцены  продолжительное время. Например, если  сцена была успешно согласована, а главный  контроллер послал сообщение GO_2PC  только через час после согласования,  прибор может просто­напросто забыть, "о  чем идет речь", и ответить сообщением  ABORT с кодом состояния "не в режиме  ожидания".  Возможен также случай предварительного  согласования STANDBY­STANDING_BY  для нескольких сцен с одним и тем же прибором до того, как будет передана  первая команда GO_2PC. В этом случае  устройству нужно помнить несколько сцен,  находящихся в режиме ожидания.  Производители должны публиковать  максимальное число таких сцен. Хранимый  в памяти акт обмена STANDBY­ STANDING_BY очищается по получении  сообщения GO_2PC. Чтобы выполнить  сцену повторно, требуется новое  согласование.  Тайм­ауты Основной метод обнаружения ошибок по  методу 2PC состоит в отслеживании  временного интервала между отправкой  сообщения прибору и получением от него  ответа. Если этот интервал превышает  максимально допустимый, наступает тайм­ аут. Главный контроллер расценивает тайм­ аут так, будто прибор передал сообщение  ABORT с кодом состояния "тайм­аут".  Этот "искусственный" код (поскольку он  никогда не посылается прибором явно)  говорит контроллеру о том, что  контролируемое устройство перешло в  неуправляемый режим (по крайней мере, по  протоколу 2PC). Для сообщений STANDBY и CANCEL  тайм­аут равен двум секундам. Поэтому,  например, сообщения STANDBY должны  посылаться как минимум за две секунды до  предполагаемого времени отправки  сообщения GO_2PC.  Тайм­аут на сообщение GO_2PC (то есть  время между отправкой этого сообщения и  прихода ответного COMPLETE) не  является величиной постоянной и зависит  от продолжительности сцены, переданной  прибором в сообщении STANDING_BY.  Если после запуска сцены сообщение  COMPLETE не пришло в течение 125% от  указанной продолжительности, то  контроллер расценивает это как тайм­аут.  Дополнительные 25% нужны для учета  "разброса часов" в контроллере и  контролируемом устройстве.  Ожидание сообщений Метод 2PC был разработан так, чтобы  контролируемые устройства никогда не  ожидали сообщений от главного  контроллера. Прибор просто принимает  сообщение, выполняет предписанные им действия и возвращает ответное сообщение. Даже в состоянии "наготове" прибор лишь  помнит обмен STANDBY­STANDING_BY,  который был произведен в недавнем  времени, но не находится в постоянном  ожидании команды GO_2PC.  Преимущество такого способа работы  очевидно. Так как контролируемое  устройство никогда не ждет сообщений, оно всегда готово принять команды ручного  управления от локального оператора.  Следовательно, если даже главный  контроллер даст сбой, шоу может  продолжаться с использованием ручного  управления на каждом из устройств.  Главный контроллер по определению  должен ожидать сообщений  STANDING_BY, COMPLETE и  CANCELLED в течение определенного  времени. Более того, он должен  одновременно ожидать многочисленные  сообщения, чей порядок отправки не  определен. Поэтому в контроллере  применяется некий алгоритм обнаружения  тайм­аутов для множества сообщений от  множества приборов.  Обработка исключительных ситуаций Подобная обработка основана в методе 2PC на простом принципе. Если на очередную  команду главного контроллера какой­либо  прибор отвечает сообщением ABORT, то  вся система переходит в специальную фазу  восстановления. Главный контроллер  посылает всем приборам системы  сообщения CANCEL, информируя их об  отклонении от безошибочной  последовательности сцен. Это сообщение  посылается для тех сцен, которые  находятся в состоянии "наготове" или уже  выполняются.  Если отменяемая сцена находится в  состоянии "наготове", то акт согласования  STANDBY­STANDING_BY просто  забывается. Если сцена уже исполняется,  прибор может выполнить одно из действий:  1) завершить сцену как обычно;  2) приостановить сцену, ожидая  дальнейшего ее выполнения;  3) прекратить сцену без возможности  дальнейшего ее выполнения;  4) вернуться к состоянию, которое было до  начала выполнения команды GO_2PC;  5) выполнить сцену в обратном порядке. Кроме того, в процесс может вмешаться  локальный оператор и перевести прибор в  режим ручного управления.  Какое из этих действий будет выполнено,  зависит от оборудования и обстоятельств,  при которых получено сообщение CANCEL. Если выполняемая сцена приводит к  какому­либо вреду, вероятно, лучший  выбор в данном случае — завершить сцену.  Если сцена приводит к неопределенной,  ненадежной ситуации, ее следует  приостановить, сбросить или выполнить в  обратном порядке. Конечное решение  зависит от оборудования и ситуации в шоу.  Некоторые приборы всегда выполняют одно из перечисленных восстановительных  действий, другие позволяют это действие  запрограммировать. Поведение прибора при получении сообщения CANCEL должно  быть документировано производителем.  Если устройство решит завершить сцену в  обычном порядке, оно должно послать как  сообщение CANCELLED с кодом "в  процессе завершения", так и сообщение  COMPLETE. Первое из них посылается в ответ на сообщение CANCEL немедленно,  второе — после фактического завершения  сцены. Сцены, приостановленные  сообщением CANCEL, могут продолжить  выполнение после обмена STANDBY­ STANDING_BY­GO_2PC.  В любом случае, на сообщение CANCEL  прибор должен ответить либо сообщением  CANCELLED, либо сообщением ABORT.  Последнее допустимо только в том случае,  если в сообщении CANCEL обнаружена  ошибка контрольной суммы. Если на  сообщение CANCEL не получен ответ в  течение двух секунд, контроллер  обработает ситуацию так, будто было  передано сообщение ABORT.  Сообщение ABORT, как говорилось ранее,  посылается контролируемым устройством в случае сбоя при выполнении команд  STANDBY, GO_2PC или CANCEL. Номер  секвенции в этом сообщении говорит  контроллеру о том, какое из сообщений  STANDBY, GO_2PC или CANCEL вызвало  сбой. Код состояния показывает наиболее  значимую причину сбоя, однако могут быть  и дополнительные, менее важные причины.  Поэтому исправления сбойной ситуации на основе одного кода состояния может быть  недостаточно.  Значимость кода состояния  пропорциональна легкости, с которой  сбойная ситуация может быть исправлена.  Например, код "блокирующий  переключатель не установлен" менее  значим, чем "сбой в моторе". Первый сбой  может быть исправлен немедленным  вмешательством человека; второй,  возможно, удастся исправить, только  разобрав мотор.  Код состояния "manual overriding in  progress" ("сцена в процессе ручного  управления") показывает, что локальный  оператор контролируемого устройства взял  на себя контроль за выполнением сцены.  Некоторые устройства могут игнорировать  все сообщения 2PC, пока локальный  оператор использует ручное управление.  Иногда сообщение ABORT не означает сбой устройства, а просто говорит о том, что  ожидаемое событие все еще не произошло.  Подобное поведение характерно для  всевозможных датчиков и детекторов. Для  таких приборов главный контроллер не