#1.4 Проблемы заказчиков
и интеграторов при проектировании проектов

Ситуационные центры и диспетчерские - взгляд изнутри
Рассмотрим те же 7 вопросов, на которые нужно обратить внимание при проектировании ситуационных центров, в контексте бренда TnTv:

1. Финансовые возможности заказчика.

Любой проект требует финансирования. Основная проблема известных брендов заключается в том, что у них обычно есть две линейки оборудования: крутая и очень крутая. Классные железки, великолепные параметры, но ценник космический.

На самом деле космический ценник для интегратора — только плюс, потому что чем больше стоит оборудование, тем больше интегратор на нем зарабатывает. Действительно, дорогие железки нужны, но рынок состоит не только из богатых заказчиков. Многим нужно, чтобы решение просто работало качественно. Когда к интегратору приходит средней руки компания и просит рассчитать небольшой проект, например, маленький ситуационный центр на 5 операторов с небольшой видеостеной, а ему дают дорогое решение, оно просто не помещается в бюджет. Это не значит, что крутой интегратор должен от таких заказчиков отказываться. Сейчас рынок сузился, все работают со всеми.

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

Чтобы было понятно, самый простой и банальный проект ситуационного центра или центра мониторинга — это комната охраны, как это ни странно звучит. Там стандартно стоят 4 монитора, сидит охранник и наблюдает за ними.

2. Инфраструктурные возможности заказчика.

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

Другая ситуация. Представим завод, который уже 20 лет работает, и начальство решает в одном из цехов сделать центр мониторинга, который будет следить за технологическим процессом. У них есть станки и технологические линии, за данными которых нужно наблюдать, то есть нужно взять сигналы от компьютеров, которые стоят в ЧПУ станках и производственных линиях, подключить к передатчикам и передать в ситуационный центр. Другими словами, нужно сделать надстройку над тем, что есть, не убирая то, что есть, и даже не добавляя ничего нового, потому что в цехе сложно протянуть дополнительные линии связи. А у крупных заказчиков есть и другие проблемы, например, надо согласовывать с IT-департаментом параметры сети: «Мне нужен интернет 1Гб» — «Нет, тебе сотки хватит».

Получается, что многие решения не могут быть реализованы, потому что заказчик не захочет заново создавать инфраструктуру по разным причинам — физическим, технологическим, IT-департамент не разрешает. Нюансов может быть много, и все их надо учитывать. Плюс, далеко не все оборудование позволяет встроиться в существующую сеть. Многие решения могут работать только в отдельной выделенной инфраструктуре — поставили коммутатор, включили, все работает, а в общей сети уже нет.

Решение TnTv как раз позволяет встраиваться в существующую инфраструктуру. На эту тему у нас есть большое количество роликов, например, как в реальной рабочей сетке передавать сигналы, или как по 10 Мб транслировать 4К изображение. Да, это не реальное онлайн видео, а слайд-шоу, но оно работает. Если у вас обычные SCADA-изображения (статические картинки с меняющейся иногда динамикой), это вполне нормально.

3. Требования к безопасности и отказоустойчивости.

Здесь есть сразу несколько тем. Как мы говорили, безопасность связана с доступом к ресурсам. Например, редко системы умеют делать так, чтобы операторы со своих рабочих мест имели доступ к тем или иным ресурсам. TnTv это позволяет делать, причем в привязке не только к рабочему месту конкретного оператора, но и где на каком устройстве можно изображение показывать — этот сигнал можно на стене отобразить, а этот нельзя, или этому оператору можно туда транслировать, а этому нельзя.

На многих предприятиях крайне негативно относятся к тому, что основное ядро системы построено в виде компьютера (с Windows или с Linux), все хотят «железячное» решение. Обычно если ядро выходит из строя, все вообще перестает работать. Это тоже надо учитывать. Система TnTv вообще не имеет ядра. Все устройства живут независимо, вся информация для работы находится в них самих. При выходе из строя любого устройства все остальные работают.

Рассмотрим устройство TnTv с точки зрения резервирования и обеспечения надежности.

Компания Colan — это сервисный центр компании Aten уже 20 лет. Мы на собственном опыте знаем, что самое отказоНЕустойчивое устройство в любом приборе — это блок питания, неважно, встроенный или внешний. Поэтому при проектировании СЦ крайне желательно, чтобы устройства имели резервный блок питания или возможность подключения блока резервного питания, а они далеко не всегда есть. В TnTv для своих решений разработали специализированный блок питания, который подключается к устройствам.

Но прелесть даже не в нем, а в двухканальном коммутаторе питания. К нему подключаются 2 блока питания, и уже его выход подключается к устройству. По сути, это горячая замена блока питания. При выходе из строя одного блока питания автоматически подключается второй блок питания. Причем не происходит никакого разрыва соединения, устройство не чувствует, что у него пропало питание, и просто работает дальше. Когда у коммутатора все хорошо, горят два зеленых светодиода, как только параметры напряжения выходят за нормы ГОСТа, происходит инцидент, одна из лампочек начинает мигать. Инженер понимает, что пора менять блок питания, и меняет его прямо на ходу. Так мы уходим от того, что в какой-то момент времени умер блок питания, потом второй, и устройство выходит из строя. Система всегда остается работоспособной.

Также немаловажно в критических ситуационных центрах иметь возможность защиты от проблем с сетью. Для этого предусматривается либо два сетевых интерфейса (основной и резервный), либо использование SFP-модулей. В случае выхода из строя меняется не целиком устройство, а просто SFP-модуль вынимается, вставляется новый. Замена занимает 2 минуты. Это условный расходник. В TnTv есть оба варианта (два интерфейса, SFP- модули).

4. Требования к секретности при работе с данными.

Во многих организаций есть доступ к закрытым секретным документам, и необходимо учитывать, как там с ними работают. В большинстве систем происходит простая авторизация: «Я Петров», и тебе дали права. Но где ты авторизуешься, на каком рабочем месте, непонятно. В TnTv есть привязка именно к рабочему месту. У других брендов мы не встречали такой возможности. Они чаще предлагают завести 5 учеток для каждого рабочего места — Иванов 1, Иванов 2 и т.д. Понятно, что люди будут пользоваться учеткой, которая обладает большим количеством прав. Плюс, есть вероятность, что человек банально ошибется, а в некоторых организациях это смерти подобно. Поэтому все эти учетки люди часто хранят под клавиатурой на листочке.

В TnTv настраивается именно рабочее место. Это относится даже к администратору, он может авторизовываться не со всех рабочих мест. Это же относится и к устройствам отображения. Например, мы хотим отправить секретное изображение в фойе, и система скажет — нет, нельзя, можно только туда. Привязка к местам трансляции и работы также является защитой от дурака.

5. Организационная структура заказчика.

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

Из практики построения ситуационных центров мы выделяем 4 иерархии пользователей:

· Простой пользователь;

· Привилегированный пользователь;

· Начальник;

· Администратор.


Каждый следующий уровень выше предыдущего и имеет приоритет.

Например, оператор (обычный пользователь) работает с ресурсом. Если на этот же ресурс зайдет начальник, у оператора пропадет возможность управления. Видеть картинку он будет, но управлять не сможет. Если на этот же ресурс зайдет администратор, начальник потеряет управление, потому что администратор по иерархии выше.

6. Требования к разделению ресурсов.

На случай подключения двух пользователей с одинаковыми правами в системе TnTv предусмотрено разделение ресурсов по типу доступа:

· Поочередный, когда два равноправных оператора работают по очереди;

· Параллельный, когда операторы могут работать одновременно;


Как это возможно, ведь мышка одна? Если просто подключить две мышки к одному компьютеру, одну тянуть вправо, другую влево, она будет стоять на месте. В системе TnTv на такой случай есть специальная фича. Например, один оператор начал делать движение мышкой вправо, второй влево, но первый начал раньше. Ему система даст доделать движение. Как только он встал больше, чем на 0,3 мс, действие переходит ко второму оператору. То же самое с клавиатурой. Первый оператор набирает текст, как только остановился, управление клавиатурой переходит второму оператору. Такие сценарии позволяют людям, когда они конфликтуют за один и тот же ресурс (мышка с клавиатурой), продолжать работу.

· Автоматический;

Это поочередный режим, но переключение происходит не вручную, а автоматически.

· Эксклюзивный.

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

Это как раз сценарии отработки конфликтных ситуаций. Они настраиваются на уровне администратора системы. Именно он определяет, как с конкретным ресурсом работать.

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

Комбинируя уровни пользователей и режимы разделения ресурсов, можно гибко настроить необходимые правила совместной работы пользователей.

7. Работа с многомониторными источниками и рабочими местами.

Цитата из реального ТЗ:

«...произвольный выбор экрана на многомониторном источнике и управление им.»


Когда у компьютера одна мышь, одна клавиатура, один монитор, все просто и хорошо — один оператор работает, никаких вопросов нет. Как только у компьютера появляется несколько видеовыходов, уже начинаются проблемы.

Например, видеовыходов 3, а клавиатура/мышь одна. Пока человек работает один, вроде бы проблем нет — он подключился к компьютеру и один с ним работает. Но что происходит если я работаю с первым экраном, где запущено ПО, которое управляет вентиляцией, а ты хочешь поработать с третьим экраном, на котором отопление? Я работаю, в какой-то момент ты подключаешься к третьему экрану и начинаешь шевелить мышкой, а она у нас одна. На моем экране начинает шевелиться мышка, хотя я ее даже не трогаю. Потом мышка уезжает, и я начинаю искать — где моя мышка? Верните мышку обратно! С клавиатурой вообще бред — сам собой набирается текст.

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

Возникает вопрос — а что с этим делать?

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

Другой вариант решения — установка приоритета.

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

Очень важно эти фишки понимать. Позже подробно про них расскажем и покажем прямо на примерах, как это работает.

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


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

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

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

Компания TnTv предлагает немножко другое решение — а-ля FreeFlow, но оно сделано на «железячном» уровне. Это специальное устройство, которое переключается при помощи клавиатуры. Оператор выбирает экран, с которым хочет работать, снизу под экраном загорается специальный диодик, который показывает, какой текущий монитор активный. Диод можно закрепить в любом месте, как удобно (под столом, на мониторе). Как показывает практика, в принципе операторам даже больше это решение нравится. У них не бывает случайных переключений. В принципе, обе схемы имеют право на жизнь, но при грамотном подходе.

Мы рассказали сейчас основы, на которые надо обращать внимание.

Дальше подробно рассмотрим все основные элементы со всеми подробностями.