Журнал "Системы Безопасности" № 2‘2021

О Х Р А Н Н А Я И П О Ж А Р Н А Я С И Г Н А Л И З А Ц И И . П О Ж А Р Н А Я Б Е З О П А С Н О С Т Ь 63 бо в праве использования протоколов различ- ных изготовителей. Частным случаем такого решения является принцип использования аппаратных модулей, выпускаемых собствен- ником протокола в комплектах оборудования других производителей. Одним из удачных примеров реализации аппаратного сопряже- ния может выступать интеграция модуля, под- держивающего протокол П-166М, в оборудо- вание СГС-22МЕ. Второй способ – использование устройства сопряжения (конвертора протоколов). В каче- стве положительного опыта создания устрой- ства сопряжения можно отметить разработан- ный ЗАО "Научно-производственная фирма "Сигма" (Калуга) блок сопряжения П-161М РММ-8 БС. Данный блок прошел приемочные испытания в 2016 г. и был рекомендован для обеспечения программно-аппаратного сопря- жения между комплексами технических средств оповещения различных производителей. Вме- сте с тем высокая цена данного блока и, глав- ное, время, прошедшее с момента его выпуска, сделали его практически нереализуемым. Это объясняется тем, что многие производители, обновив линейку продукции и программного обеспечения, не уведомили об этом разработ- чиков П-161М РММ-8 БС, из-за чего при заказе блока сопряжения вместо серийно выпускае- мой продукции зачастую должен выпускаться индивидуальный продукт. Разрешение на использование протокола и вытекающие из этого сложности Имеется еще один способ сопряжения техниче- ских средств различных производителей. Как ранее уже упоминалось, технически не состав- ляет труда расшифровать и воспроизвести про- токол другого производителя, в связи с чем отдельные производители заявляют о возмож- ности поддержки протоколов сторонних про- изводителей, вводя тем самым в заблуждение конечных потребителей. Фактически, кроме незаконного использования чужого протокола и нарушения интеллектуальной собственности, данные действия могут вызвать и реальный риск выхода из строя системы оповещения не только объектового, но и муниципального и регионального уровней при внесении измене- ний производителем оборудования в протокол обмена. Здесь требуется более подробное пояснение. В случае осуществления разрешения на использование протокола одного произво- дителя другому (или нескольким) разрешив- ший использование своего протокола произво- дитель принимает на себя обязательства по его поддержке в работоспособном состоянии (например, путем сохранения или регулярного обновления). Поддержка также подразумевает согласованное и заблаговременное уведомле- ние партнеров о внесении в протокол измене- ний, затрагивающих работу средств оповеще- ния иных производителей. В случае отсутствия партнерских отношений собственник протокола вправе в любой момент времени изменить его структуру. Такое изменение может оказаться критическим для работы оборудования другого производителя, использующего данный прото- кол без разрешения собственника. Причем речь идет не о преднамеренном саботаже со сторо- ны собственника протокола, а о планомерном обновлении политик безопасности. Оцените, сколько раз за последние полгода происходило автоматическое обновление программного обеспечения вашего персонального компьюте- ра или смартфона! Регулярное, часто автомати- ческое, обновление программного обеспечения стало нормой во всех сегментах техники. Имен- но поэтому гораздо большим проступком, чем незаконный реверс-инжиниринг, является само использование протокола без разрешения и последующей поддержки правообладателя. Являются ли выходом устройства сопряжения для конвертации протоколов? Таким образом, любое использование устройств сопряжений, обеспечивающих конвертацию протоколов, не способно обеспечить полное соответствие прохождения полей команд/кви- танций в обе стороны. Если подходить формаль- но к вопросу сопряжения систем всех уровней, возникает коллизия следующего свойства: про- токол каждого производителя имеет определен- ное количество полей для записи команд и кви- танций о состоянии оборудования, и у каждого производителя этот набор команд/квитанций разный. Какой-то производитель ограничивает- ся набором из 30 полей записи, а протоколы некоторых производителей включают в себя до 150 полей. Таким образом, выполнение требо- вания о программном и техническом сопряже- нии формально невыполнимо ввиду несовпаде- ния количества команд/квитанций двух разных производителей. Опыт стандартизации в других областях применения электронной техники – выводы и рекомендации Проблема множественности протоколов харак- терна практически для всех сфер электронной и телекоммуникационной техники, где имеется информационный вакуум или недостаточное регулирование. Многие сферы уже прошли данный этап и успешно пожинают плоды стан- дартизации и кросс-платформенности. Так про- исходило и со стандартами хранения информа- ции, и с протоколами обмена в телекоммуни- кационной сфере и во многих других областях. Следовательно, если грамотно транспонировать опыт стандартизации обмена информацией из других областей в область систем оповещения населения, то появляется достаточно высокая вероятность получения положительного резуль- тата, обеспечивающего совместимость (аппа- ратно-программное сопряжение) оборудова- ния различных производителей. При проведе- нии стандартизации целесообразно избегать соблазна выбора протокола из числа уже при- меняющихся по мажоритарному принципу его применения. Не стоит также предпринимать попытки включить в состав универсального про- токола все параметры, участвующие в инфор- мационном обмене протоколов всех произво- дителей. Напротив, целесообразна разработка нового протокола с организацией как минимум двукратного запаса количества свободных полей. Это объясняется тем, что практически любой протокол обмена в системах оповеще- ния состоит из двух типов данных – самого сообщения и служебной информации. В свою очередь, сообщение может содержать аудио-, аудиовизуальную или буквенно-цифровую информацию, а служебная информация быть представленной как командами и квитанциями, обеспечивающими работу самого протокола, так и командами, и квитанциями состояния эле- ментов систем оповещения. Если попытаться классифицировать поля состояний каждого производителя, то условно их можно разделить на обязательные и вспомогательные. При этом к обязательным полям следует относить испол- нение базовых наборов команд и отчет об их исполнении, а также квитанции о состоянии критически важных параметров системы. Остальные поля состояний следует принять как вспомогательные и не предъявлять требований к их обязательному соответствию у различных производителей. Такое разделение – это один из подходов к созданию единого (универсаль- ного) протокола [2]. Разработанные требования к единому протоко- лу должны стать обязательными для поддержки оборудования оповещения каждого произво- дителя, что не отменяет поддержку производи- телем собственных проприетарных протоколов. Протоколы лицензируется каждым производи- телем на правах соблюдения им требований к их поддержке и к процессу производства обо- рудования. Такой подход также позволит обеспечить гаран- тированное прохождение сигналов оповещения и полное программное и техническое сопряже- ние по основному набору команд всех систем оповещения на всех уровнях. В случае невоз- можности осуществить поддержку требований нового протокола более старыми модифика- циями технических средств производителям оборудования целесообразно предложить замену устройств систем оповещения или уста- новку конвертера протокола. Заключение Как показывает мировая практика в области производства телекоммуникационного обору- дования, использование стандартных универ- сальных протоколов позволяет существенно повысить стабильность работы сетей и систем связи и обеспечить совместимость оборудова- ния различных производителей, что благопри- ятно сказывается не только на стоимости созда- ния, но и на оперативности поиска замены в случае выхода оборудования из строя, что, в свою очередь, повышает готовность и устой- чивость функционирования системы оповеще- ния населения. Список литературы: 1. ГОСТ Р 42.3.01–2014 "Гражданская оборона. Технические средства оповещения. Классифи- кация. Общие технические требования": http://docs.cntd.ru/document/1200110556, дата обращения 01.03.2021. 2. Совместный приказ МЧС России и Минцифры России от 31.07.2020№578/365 "Об утвержде- нии Положения о системе оповещения населе- ния": http://docs.cntd.ru/document/565649076, дата обращения 01.03.2021. n www.secuteck.ru апрель – май 2021 Ваше мнение и вопросы по статье направляйте на ss @groteck.ru