Admin

Безопасность программного обеспечения систем ЖАТ

О.А. НАСЕДКИН, руководитель ИЦ ЖАТ ПГУПС
А.М. БЕЛОУС, инженер

Сейчас во всех высокотехнологичных отраслях наметилась тенденция преобладания программного обеспечения над аппаратной составляющей. Не стала исключением и железнодорожная отрасль, где активно внедряется микропроцессорная техника, а следовательно, и новое программное обеспечение (ПО), с которым можно ознакомиться на специальном сайте в каталоге https://torrentigruha.ru/soft/. В статье рассматриваются некоторые аспекты повышения качества проектирования программного обеспечения, которые не в полной мере отражены в нормативных документах отрасли.

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

С целью минимизации влияния всех отрицательных факторов необходимо с помощью нормативной базы отрасли регламентировать основные аспекты, связанные с разработкой, экспертизой, сертификацией, внедрением и сопровождением ПО в процессе его жизненного цикла.

СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

• Технические средства ЖАТ существенно разнятся с точки зрения сложности, характера решаемых задач и требований, которые к ним предъявляются. Среди них можно выделить устройства с локальными функциями - например, микропроцессорные аналоги кодовых генераторов, дешифраторов и приёмников в некоторых устройствах автоблокировки. Как правило, одноуровневое программное обеспечение таких устройств непосредственно взаимодействует с аппаратными средствами. Это так называемое «встраиваемое» ПО, оно имеет относительно малый размер.

Наиболее сложными системами управления сточки зрения применяющегося в них ПО являются микропроцессорные системы ЭЦ. В их программном обеспечении
можно выделить четыре уровня абстракции:

уровень системного ПО, предназначенного для управления аппаратным обеспечением и выступающего в качестве менеджера ресурсов (памяти, центрального процессора и устройств ввода/ вывода);

уровень базового ПО, которое взаимодействует с системным ПО и реализует алгоритмы системы ЖАТ, связанные с безопасными вычислениями, независимо от области применения;

уровень технологического ПО, которое специализирует управляющий вычислительный комплекс (УВК) под решение конкретных технологических задач. Это могут быть задачи управления и обеспечения безопасности движения поездов на станции или перегоне, реализации функций управления локомотивом или устройствами переездной сигнализации;

уровень конфигурационных данных, призванных настраивать технологическое ПО в соответствии с конкретными требованиями полигона применения.

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

Первая - определение состояния системы во время ее работы с учётом влияния негативных факторов. К ним, например, могут относиться отказы и сбои в работе технических средств, некорректные действия персонала, целенаправленное вмешательство в процесс функционирования технических средств.

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

Уровни системного и базового ПО являются основой программно-аппаратных средств безопасного управляющего вычислительного комплекса (УВК). Его специализация задается характером исполнения аппаратных средств, решаемыми задачами и двумя другими уровнями ПО. В идеале, однажды разработанные системное и базовое ПО не должны изменяться, если не меняются условия применения программно-технических средств. Перечень решаемых задач определяется структурой технических средств, классом рассматриваемых отказов и режимами функционирования. Как правило, разработка ПО таких уровней проводится без привлечения средств автоматизированного проектирования.

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

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

Такие свойства ПО закладываются на стадии разработки. Без комплекса мероприятий, направленных на правильную постановку задач, решаемых системой в части реализации базового и технологического ПО, добиться их реализации невозможно.

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

БАЗОВЫЕ ТРЕБОВАНИЯ ПО БЕЗОПАСНОСТИ

• Любая разработка ПО должна начинаться с постановки задачи в таких документах, как «Техниче-
ское задание», «Предложение разработки» и др. Далее требования к ПО формализуются в соответствующем документе, на основании которого ПО реализуется как в части алгоритмических аспектов его работы по прямому назначению, так и в части обеспечения безопасности функционирования.

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

Для разных типов ПО должны разрабатываться свои основные требования в части безопасности и надёжности функционирования. Например, встраиваемое (работающее непосредственно с объектом управления) и прикладное(исполь-зующее интерфейс прикладного программирования операционной системы и работающее в ее составе) ПО изначально различаются по своей сути и цели. Кроме того, их архитектурные отличия ещё больше отдаляют эти два типа друг от друга. Очевидно, что и требования к реализации данных видов ПО должны разниться между собой.

В то же время операционные системы (системное ПО) нужно причислить к виду ПО, непосредственно управляющего периферийным оборудованием и вычислительными ресурсами. Оно не должно отвечать за безопасность и надёжность функционирования всей системы, которая может быть как многоканальной, так и однока-напьной. В этом случае все функции по реализации безопасности берет на себя прикладное ПО.

Кроме реализации каких-либо технологических алгоритмов в соответствии со строгой последовательностью операций и контролем их исполнения, к функциям безопасности относятся также и функции самодиагностики вычислительных ресурсов канала/ каналов системы или устройства ЖАТ. Под самодиагностикой вычислительных ресурсов понимается контроль целостности оперативного запоминающего устройства (ОЗУ) и постоянного запоминающего устройства (ПЗУ), а также целостности и адекватно-
сти информации, получаемой по каналам связи (внешним и/или внутренним).

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

И встраиваемое ПО, и системное ПО должны быть оформлены и написаны в соответствии с достаточно строгими внутренними или международными стандартами кодирования, исключающими опасные или неоднозначные конструкции языков высокого уровня.

При этом встраиваемое ПО призвано минимизировать объём кода на языках низкого уровня. Реализовывать его нужно строго в соответствии с алгоритмическими требованиями, сформулированными в документе «Требования к программному обеспечению». В дальнейшем это позволит проверять ПО на корректность реализации. Кроме того, необходим контроль целостности исполняемого кода и носителя данных, на котором он располагается, а также контроль ОЗУ и соответствия данных конкретной технологической ситуации. Контролировать целостность и адекватность данных при многоканальном исполнении следует во всех вычислительных каналах.

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

Базовое ПО призвано реализовывать все алгоритмы работы системы ЖАТ, связанные с безопасностью ее функционирования, независимо от решаемой задачи. К его функциям относятся обеспечение многоканальных вычислений и периодический контроль вычислительных каналов, а также сравнение результатов вычислений, обнаружение и безопасная блокировка отказавшего канала. За исключением процесса конфигурирования и настройки при начале функционирования, базовое ПО должно исключать динамическое выделение памяти. Его следует создавать строго в соответствии с алгоритмическими требованиями, сформулированными в документе «Требования к программному обеспечению», что позволит в дальнейшем выполнить проверки на корректность реализации. Оно должно контролировать целостность исполняемого кода и данных, а в многоканальном исполнении - целостность и адекватность данных во всех вычислительных каналах.

Технологическое ПО предназначено для корректной реализации всех технологических алгоритмов системы ЖАТ в соответствии с предъявляемыми к нему требованиями. Оно должно минимально зависеть от операционной системы или компилятора, что обеспечивает переносимость на другие платформы. Его следует разрабатывать с учетом возможности проведения испытаний, в том числе отдельно от аппаратных средств системы ЖАТ (с применением имитаторов). Для технологического ПО должна быть выбрана, использована и задокументирована стратегия управления ресурсами, в том числе оперативной памятью, а также предусмотрен механизм самопроверки с целью выявления возможных некорректных состояний данных. Нужно строго соблюдать временные характеристики функционирования технологического ПО. В частности, в худшем случае длительность выполнения одного цикла вычислений не должна превышать допустимых для данной системы ЖАТ значений. Использование сторонних программных компонентов в технологическом ПО следует свести к минимуму и документально обосновать.

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

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

__________________
Телеграм-канал ЖЕЛЕЗНОДОРОЖНИК

Если у вас возникли вопросы по работе сайте - пишите на почту admin@scbist.com

СЦБот

Эта тема была перенесена из раздела Журнал "Автоматика, связь, информатика".

Перенес: Admin