ПО современных СКУД

Журнал ТЗ №5 2008

Известно, что программное обеспечение – самое слабое место системы. Это утверждение верно, пожалуй, для любой системы, и ТСБ здесь, сами понимаете, никак не может быть исключением. Всё, что работает на обычных ПК, особенно под управлением Windows, однозначно недостаточно надежно, подвержено сбоям, зависаниям, ошибкам. Поэтому и принято в современных системах весь основной функционал, обеспечивающий работу системы, переносить на аппаратные устройства.

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

Многие современные контроллеры работают на своей операционной системе, как правило, на Unix (Linux), и, по сути, представляют собой компьютеры на базе промышленных ПК. Для них пишутся прикладные задачи, которые реализуют функционал возможностей контроллера. С точки зрения развития техники и технологий охотно это допускаю. С точки зрения здравого смысла возникают вполне закономерные, на мой взгляд, вопросы. Понятно, что современная элементная база позволяет сделать практически всё, что угодно. Но возможно ли обеспечить конкурентоспособную цену такого оборудования? Ведь очевидно, что, например, размеры памяти контроллера, которому предстоит работать под операционной системой типа Linux, нужно увеличить на порядки по сравнению с контроллерами, не использующими ОС общего назначения. Минимум, что требуется для работы самой Linux, это мегабайт программной памяти и мегабайт – оперативной. Между тем, самый серьезный и многофункциональный контроллер СКУД, построенный на базе микроконтроллера, требует не более 64 кбайт программной памяти и не более – 32 кбайт оперативной памяти. А еще нужно учитывать, что Linux, как правило, привносит все проблемы доступных операционных систем. Например, может существенно увеличиться время реакции на некоторые события. Согласитесь, если контроллер ищет в базе данных пользователя не 0,2 секунды, а секунду или более, это ни в коем случае не свидетельствует о хорошей работе системы.

С одной стороны, понятно стремление разработчиков использовать такую операционную систему как Linux, потому что упрощается процесс создания самого ПО контроллера, - операционная система обеспечивает весь базовый функционал ввода/вывода, файловую систему, Ethernet стеки TСP/IP, - всё это является встроенными функциями любой нормальной операционной системы, в том числе и Linux. С другой стороны, для систем реального времени, с учетом потока событий долгая реакция системы вряд ли допустима. У многих заказчиков сегодня уже есть определенное мнение о том, как должна работать СКУД, и не нужно его ухудшать.

Безусловно, нельзя сравнивать ПО контроллеров и ПО верхнего уровня. Но необходимо учитывать, что эти программы всегда работают вместе. Только вместе, причем взаимно дополняют друг друга.
Понятно, что задача создать на компьютере отчет за месяц по компании, в которой работают 50 тысяч человек, для него абсолютно естественна. Поэтому он может быть ею занят напрямую и ни на что не отвлекаться. У контроллера совсем другая задача – обеспечить молниеносную реакцию на любое событие, которое происходит. Поэтому они и строятся принципиально по-разному.
Многие мои коллеги проходили через это: переносили на компьютер, который «большой и всё может», функционал реального времени. И непременно имели проблемы, потому что компьютер, не побоюсь повториться, – штука ненадежная. А если на него охранник еще и игрушку какую-нибудь поставит... Поэтому базовый функционал, обеспечивающий работоспособность и живучесть системы, должен быть не на компьютере, а только в контроллере. Базовые функции контроллера – это обслуживание всего, что происходит в режиме реального времени. Вне реального времени есть две вещи: программирование и мониторинг. Отчеты, которые по большому счету, тоже относятся к мониторингу, но являются ретроспективой событий, я бы выделил в отдельную категорию. Эти функции очень важны, без них сегодня немыслима современная СКУД, но они не обуславливают живучесть системы.
А весь функционал, который обеспечивает живучесть системы, должен быть в замкнутом контроллере. То, что внутри, повредить достаточно сложно. Контроллер будет работать, если его отключить от розетки, от компьютера. Понятно, что если отключить от датчика, он охранять уже не будет. Но тревожный сигнал о том, что его лишили датчика, подаст. Контроллер, повторяю, - в любом случае тот же компьютер со своим ПО, причем, достаточно сложным. С чем его можно сравнить? Пожалуй, с современным автомобилем. То, что в обиходе автомобилисты называют «мозгами», на самом деле, микропроцессорные блоки, каждый из которых управляет «своей» системой: двигателем, освещением, подушками безопасности, тормозной системой и т.д. При этом они взаимодействуют друг с другом.
При этом абы какой микропроцессор в автомобиль не поставишь. На чем попало программу для него не напишешь, потому что такое ПО не пройдет тесты. Требования к надежности и живучести микропроцессоров и ПО в автомобилестроении жесточайшие. Например, микропроцессор должен быть двухядерным. Одно ядро реально выполняет основную задачу, например, контроль и управление тормозной системой, а второе проводит постоянную диагностику и резервирует первое. Потому что тормоза автомобиля не должны отказывать ни при каких обстоятельствах.
Прогнать в современной программе по всем веткам алгоритма в процессе тестирования, - на это могут уйти если не годы, то месяцы. Для того чтобы процедуру тестирования упростить, существуют специализированные средства разработки, которые позволяют максимально возможно избежать человеческих ошибок.
В системах безопасности требования не такие жесткие, но в конечном итоге – то же самое. Отказало ПО контроллера, заблокированной оказалась дверь, - может произойти непоправимое, если, например, на объекте возник пожар.
Каково будущее систем, работающих под Windows? Убежден, они были, есть и будут. Но – только обслуживающая часть системы, не участвующая в ее реальной жизни.
Собственно, в большинстве систем так было всегда. Даже в самых первых системах, функционал которых был весьма ограниченным. Если посмотреть безнадежно устаревший, но пока еще действующий ГОСТ по системам контроля и управления доступом, то, скажем, требуемый им объем буфера событий исчисляется цифрой, которая сегодня кажется смешной. Такого сейчас даже в детских игрушках нет.
Таким образом, еще раз подчеркнем, что есть «аппаратный» софт, который управляет аппаратными устройствами, и есть программы верхнего уровня, предназначенные для мониторинга, программирования, создания отчетов, интеграции с другими системами, не относящимися к безопасности, например 1С.
Если говорить о софте компьютера, то надо вспомнить, что первые системы безопасности не были интегрированными. Была СКУД в чистом виде, была охранная система, CCTV. Каждая из них – абсолютно замкнутая система. Сегодня же, например, «чистой» системы контроля и управления доступом, пожалуй, и не встретишь. У любых нормальных производителей СКУД интегрирован с CCTV, ОПС.

В связи с этим достаточно серьезно поменялись подходы к построению ПО верхнего уровня. Дело в том, что производство всего спектра оборудования для одной компании – дело весьма накладное. Поэтому создаются программные комплексы, которые позволяют расширять возможности систем и подключать оборудование сторонних производителей. И это смело можно назвать тенденцией. Самый яркий пример SCADA-системы.
Стоит отметить, что на российском рынке ТСБ уже появились компании, которые ничего, кроме интегрирующего софта, не делают. Им, конечно, непросто работать, поскольку с открытыми стандартами воз, как говорится, и ныне там, но они договариваются с производителями и достаточно успешно продвигают свою продукцию.

Это, на мой взгляд, очень перспективный путь. Нам бы только как можно быстрее решить имеющиеся проблемы. Проблемы давние, но от этого, увы, не менее актуальные, чем несколько лет назад. Главная из них – стандартизация. Об этом много говорят, и не только в публикациях отраслевых изданий, но реально ничего не меняется. Тому, конечно, есть объективные причины, например, недостаточная развитость нашего сегмента рынка, его чрезмерная и не всегда обоснованная закрытость. Опять же, нельзя не учитывать, что в СКУД настолько широк диапазон понятий и величин, не говоря уже о протоколах, что даже в первом приближении понятно, какой большой объем работы предстоит выполнить. И здесь мы неизбежно натыкаемся на главную субъективную причину – человеческий фактор. Мне кажется, что зачастую людям мешает инертность, нежелание делать лишнюю работу. И еще многие, прекрасно просчитывая сегодняшнюю выгоду, почему-то не понимают, что возможность выбора из большого многообразия – это коммерческое преимущество. Действительно качественный продукт не перестанут покупать, даже если у заказчика будет возможность заменить отдельные не подходящие ему компоненты чем-то другим. Возможность выбора комплектации для своей системы или, наоборот, производство комплектации под систему другого производителя, которая будет пользоваться спросом - это абсолютно выгодно. Для всех серьезных игроков рынка ТСБ.