В прошлом создание систем было довольно простым делом. С источниками разобрались, интеграторы поставили их в стойку. Для тех немногих, кто не мог оказаться в стойке, несколько расширителей для передачи сигнала на процессор. Затем еще несколько расширителей для передачи сигналов на наши дисплеи и вуаля! Проект был выполнен. Ладно, не все так просто, но общая идея верна.
В наше время все не так просто. Физические входы уступили место все большему количеству виртуальных входов. Наших клиентов больше не волнует, где находятся вещи, им просто нужно иметь к ним доступ! Это началось с камер видеонаблюдения. Раньше системы требовали, чтобы аппаратное устройство принимало эту веб-страницу / канал с камеры безопасности и превращало его в HDMI, а затем подключало его к системе. Это было хорошо, когда веб-разработка была новой… но со временем нам стало нужно все больше и больше этих источников. И со временем они во многих случаях затмевают количество физических входов в системе. Как будто этого было недостаточно, рост числа программных платформ и информационных панелей для анализа данных вызвал все большую потребность в большем количестве виртуальных входов. В конце концов, зачем выделять 12 компьютеров под разные информационные панели, если это просто веб-страница в сети.
В целом, движущим фактором была гибкость. Гибкость входных данных, гибкость местоположения / расстояния и гибкость систем. В системе, основанной на физических входах, если вдруг мы захотим добавить несколько входов в систему, которая уже была заполнена, или даже добавить вход на операторской станции, которая ранее не была подключена к одному (или, возможно, была находится на другом континенте!)… потом нужно добавить оборудование, протянуть новые кабели, установить коробки. Ничего из этого нежелательно. Но в прошлом это было необходимо.
В настоящее время с системой, которая имеет возможность добавлять виртуальные входы, мы просто загружаем программный клиент, позволяем клиенту управлять им, как и любым другим сетевым ресурсом, и в считанные минуты у нас есть этот новый «источник», доступный в качестве вход в систему. Ни оборудования, ни кабелей для прокладки, ни коробок для установки. Невозможно свести к минимуму, насколько это выгодно для строительных систем. Это не только проще, но и надежнее, безопаснее, а в плане масштабируемости ваши возможности безграничны. Мы уже упоминали, что источники могут быть где угодно, но это не единственное большое преимущество. Раньше, если у нас была информационная панель, которая питалась от ПК, нам также требовалась резервная машина на случай, если основная выйдет из строя… или потребовалось обслуживание / исправление / обновление системы. Это означало больше оборудования, больше места в стойке и т. Д. Если мы обращаемся к источнику виртуально, ничего из этого не играет роли. Независимо от того, открывает ли он приложение для установки этой приборной панели непосредственно в процессор и, таким образом, в стену, или просто захватывает видеопоток H.264, чтобы гарантировать, что у нас есть поток с камеры, отсутствие оборудования означает меньше точек отказа, и если исходная камера есть проблема, переключение на другую камеру - это всего лишь вопрос сценария для перехода к другому IP-потоку. Общее бремя поддержки виртуальных источников в сети переходит от системного интегратора к конечному потребителю, больше нет обвинений в отказе оборудования или источниках, которые недоступны в данный момент.
Хотя это может показаться простым, это привело к совершенно иному типу системного планирования. Требуется отслеживание всех этих приложений и источников. И поскольку большинство сетей используют DHCP для управления устройствами, одни только IP-адреса не всегда могут нам помочь. В результате системе необходимо гораздо более подробно отслеживать имена устройств и IP-адреса, чтобы гарантировать, что мы ничего не потеряем после периода обслуживания сети. Кроме того, нам необходимо отслеживать учетные данные для входа в эти виртуальные входы. Также может иметь решающее значение более глубокое использование API для входа в систему и связи с устройствами. И, наконец, переход к сети привел к резкому скачку требований к пропускной способности. Производители и системные интеграторы не могут сами проектировать эти системы, мы должны тесно сотрудничать с несколькими различными группами со стороны клиентов. И что еще более важно, производители ДОЛЖНЫ иметь опыт в этой сфере и ресурсы, чтобы помочь вам работать с клиентами.
Другая большая проблема - это остерегайтесь компаний, которые используют «AV-ориентированные» решения. Несмотря на то, что индустрия AV - это то, чем мы являемся, эти решения существуют в мире ИТ. Заказчики не будут раскручивать новые VLAN, чтобы избежать «странных» мер безопасности или операций, специфичных для производителя. Будь то используемые методы аутентификации или порты. На уровне предприятия ЕДИНСТВЕННО приемлемые решения - это решения корпоративного уровня, соответствующие существующим отраслевым практикам. Интеграция в политики, рабочие процессы и системы ИТ является обязательным требованием, потому что это облегчает их жизнь.
Более широкое использование виртуальных входов радикально изменит возможности решений, которые вы создаете для своих клиентов. Если вы потратите время на работу с такими компаниями, как Jupiter Systems, это упростит задачу и поможет вам продать ее своим клиентам. Юпитер был в авангарде этой эволюции на протяжении всей своей жизни. У них есть непревзойденный опыт и ноу-хау в этой области. И по мере того, как мы продолжаем развиваться как индустрия в сторону все большего и большего числа виртуальных, они могут помочь вам представить своим клиентам варианты, о которых вы, возможно, даже не догадывались.
