CC BY
30
2. Устройства СЦБ. Технология обслуживания. - М.: Транспорт. 1999.
3. Автоматика i комп'ютерш системи на станцiях. Частина 2. Датчики та виконавчi пристро!. О.Ф.Демченко i iншi. - Харкiв, «Регюн - iн форм». 1999.
4. 1нструкщя з технiчного обслуговування пристро!в сигналiзащi, централiзащi та блокування (СЦБ). - Ки!в. 1998.
5. Сапожников В.В., Сапожников Вл.В., Шаманов В.И. Надежность систем железнодорожной автоматики, телемеханики и связи - М.: Маршрут, 2003.
6. Дмитренко И.Е. Устинский А. А., Цыганков В.И. Измерения в устройствах автоматики, телемеханики, и связи на железнодорожном транспорте. - М.: Транспорт, 1975.
7. Техническая эксплуатация устройств и систем железнодорожной автоматики и телемеханики. Вл.В.Сапожников. - М.: Маршрут, 2003.
УДК 656.25:656.2.08
Чепцов М.Н., к.т.н., доцент, проректор по научной работе (ДонИЖТ)
МОДЕЛЬ СРЕДЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ДОКАЗАТЕЛЬСТВЕ ФУНКЦИОНАЛЬНОЙ БЕЗОПАСНОСТИ СИСТЕМ УПРАВЛЕНИЯ ДВИЖЕНИЕМ ПОЕЗДОВ
Введение. Перспектива развития средств железнодорожной автоматики определена однозначно - поэтапный переход с релейной на микропроцессорную (МП) элементную базу. Начальные этапы этого процесса затронули информационные функции систем управления движением поездов, такие как диспетчерский контроль, техническая диагностика и др. В последующем и управляющие, непосредственно не связанные с безопасностью движения поездов (например, диспетчерская централизация). Современный этап характеризуется интенсивным поиском оптимальных, в первую очередь с позиции безопасности, схемных и программных решений с целью внедрения средств МП техники на всех уровнях системы управления движением поездов. При этом одной из проблем, сдерживающих этот процесс, является отсутствие эффективных
методов доказательства функциональной безопасности, в первую очередь программного обеспечения.
Постановка проблемы, анализ последних исследований и публикаций. В большинстве действующих международных стандартов для получения необходимых требований функциональной безопасности основное внимание уделяется технологическому процессу создания безопасных систем и программных средств, без выделения и описания процессов и измерения достигаемых при этом критериев безопасности программных продуктов. Эти принципы регламентируются, например, в стандарте IEC 61508 (третья и шестая часть), где требования процессов обеспечения безопасности ПО структурирована схемой этапов и работ, компонентов и объектов, а также снабжена рекомендациями по выбору и реализации методов создания безопасного ПО. Третья часть стандарта ISO 15408 почти целиком посвящена детальным требованиям по обеспечению гарантий качества при создании и применении систем информационной безопасности комплексов. Технологии и типовые процессы создания безопасных систем и программных средств отражены также в стандартах ISO 13335 и ГЕС 60880. Совокупность этих требований отражает методы технологической поддержки жизненного цикла сложных программных средств с акцентом на особенности реализации функций безопасности, но не позволяют получить численные значения для конкретного программного продукта.
Однако, ввод в постоянную эксплуатацию новой техники на железнодорожном транспорте Украины невозможен без выполнения требований ДСТУ 4178-2003, в соответствии с которым для комплексов технических средств (КТС), применяемых в системах управления и регулирования движения поездов, необходимо производить доказательство и экспертизу функциональной безопасности. Причем доказательство необходимо строить на основе количественных показателей, которые должны быть получены и подтверждены до серийного изготовления КТС.
В свою очередь, безопасность микропроцессорных средств зависит от двух составляющих: программной и аппаратной. Аналитическое расчетное выражение вероятности безопасной работы МП устройства за
интервал времени t, при условии независимости отказов программного и аппаратного обеспечения выглядит следующим образом [1]:
P (t ) = Рба (t ) РБП (t ),
где первый множитель - вероятность безопасной работы аппаратного обеспечения, второй - программного. Следовательно, получение численных характеристик безопасности МП устройства невозможно без оценки значений как РБА (7), так и РБП (7).
Следует отметить, что теория создания надежных и безопасных технических устройств и систем управления на железнодорожном транспорте достаточна для практических целей (например, [2-5]). Однако проблема доказательства безопасности программного обеспечения не нашла должного отражения в теории и практике железнодорожного транспорта.
Так, традиционные методы анализа ПО связаны с доказательством правильности программ (верификация программ). Начало этому направлению было положено работами П. Наура и Р. Флойда, в которых сформулирована идея приписывания точке программы так называемого индуктивного или промежуточного утверждения, и указана возможность доказательства частичной правильности программы (то есть соответствия друг другу ее предусловия и постусловия), построенного на установлении согласованности индуктивных утверждений [6]. Кроме этого, фундаментальный вклад в теорию верификации внес Ч. Хоор, высказавший идеи проведения доказательства частичной правильности программы в виде вывода в некоторой логической системе, а Э. Дейкстра ввел понятие слабейшего предусловия, позволяющее поставить в соответствие друг другу предусловие и постусловие, и исследовать завершимость программы.
Данные методы позволяют оценить надежность полученных результатов и проследить последовательность путем обратных рассуждений их получения только в небольших программах или отдельных функциях. Однако значительная сложность программного обеспечения, множество взаимосвязей между функциональными узлами, применение ПО различных фирм производителей (например, операционная система, драйвера устройств, и т.п.), сводят на нет возможности анализа и оценки надежности и безопасности ПО в современных системах управления движением поездов.
Кроме того, следует отметить особенности, обусловленные процессом возникновения и обнаружения опасных ошибок программного обеспечения и опасных отказов аппаратных средств. Так, при применении контрольно-испытательных методов оценки ПО на надежность и функциональную безопасность [7, 8], получают данные об обнаруженных, а не об оставшихся ошибках. Это коренным образом отличается от
технических средств, где получают значения, которые могут непосредственно использоваться для оценки безопасности. Еще одна особенность состоит в том, что опасные ошибки делаются программистами в процессе создания программ, а отказы аппаратуры возникают в процессе функционирования в результате физических и химических процессов, происходящих в элементах [9, 10].
Таким образом, следует отметить, что в общем виде проблема оценки функциональной безопасности программного обеспечения не решена, однако частное решение для системы управления движением поездов может быть получено. Это связано с тем, что ПО проектируется под конкретный участок железной дороги, следовательно, значительная часть входных сигналов априорно известна или может быть смоделирована. В этом случае, для оценки безопасности возможно применение контрольно-испытательного метода (тестирования ПО), в соответствии с принципом форсирования быстродействия [11]. Естественно, что эффективность данного метода будет напрямую зависеть от адекватности технологическому процессу модели виртуальной среды тестирования ПО.
Цель статьи. Целью данной работы является синтез модели среды тестирования на функциональную безопасность программного обеспечения, входящего в состав микропроцессорной системы управления движением поездов.
Основной материал. Классический подход проведения контрольных испытаний на надежность и безопасность предполагает моделирование такой среды функционирования исследуемого объекта, которая теоретически может возникнуть после ввода его в постоянную эксплуатацию. В случае проведения испытаний технических средств имитируется физическая среда функционирования, при испытаниях программных продуктов - виртуальная, создаваемая программно-аппаратными средствами испытательного макета. Следует отметить, что для последнего случая модель среды функционирования, как правило, строится на основе стохастических закономерностей.
В связи с тем, что программное обеспечение системы управления движением поездов создается для полигона железной дороги, то основной его функцией является обработка входящего поездопотока в соответствии с определенным алгоритмом работы. Кроме этого, система управления подвержена воздействию ряда случайных факторов, таких как, климатические воздействия, электромагнитные, физические и др. С учетом
вышесказанного, рассмотрим структуру модели виртуальной среды тестирования программного обеспечения, состоящую из (рисунок 1):
- тестируемого ПО (Тест ПО);
- генераторов псевдослучайных событий Рп (7) и Ру (7);
- обработчика логики работы исследуемого устройства М (7);
- логического фиксатора наличия опасного отказа Qo (7).
Как отмечено в работе [12], условия безопасного функционирования программного обеспечения определяются множеством предикатов Р = {£.(а1,а2,...ап)| / = 1,2,...,Щ, зависящих от множества аргументов А = {а} | ] = 1,2,...,М}. В процессе тестирования исследуемое ПО формирует в
каждый дискретный момент времени 7 управляющий сигнал, совокупность которых является множеством векторов X = {х1, х2,..., хп}. Логическое устройство фиксации опасного отказа Qo (7) выявляет, во-первых, такие комбинации выходов, которые являются подмножеством аргументов А ; во-вторых, на основе множества предикатов Р выявляет
комбинации выходов X, приводящие к опасному отказу. Естественно, при этом выполняется условие X е X. Тогда, с учетом независимости возникновения опасных состояний на выходе исследуемого ПО, вероятность возникновения опасного отказа, можно представить как сумму вероятностей принадлежности выходного вектора к множеству X:
Qo (х е X) = £ д,. (1)
Считая промежуток времени 7 достаточно малой величиной (определяется тактовой частотой процессора), выражение вероятности возникновения опасного отказа можно представить в виде функции времени:
Qo(tl) = ЦЧо(7г) , (2)
где до (7,) - вероятность возникновения опасного отказа ПО в момент
времени . С учетом того, что контрольные испытания прекращаются при возникновении хотя бы одного опасного отказа, выражение (2) можно представить как
а а)=), (3)
где - вероятность возникновения опасного отказа при
фиксации одного из множества комбинаций выходов X.
Рисунок 1 - Структура модели виртуальной среды тестирования программного обеспечения
Как правило, при автоматизации процесса проведения контрольных испытаний, на вход исследуемого программного обеспечения подают последовательность случайных событий от генератора, имеющего определенную техническими условиями функцию распределения. Естественно, что для системы управления движением поездов такая функция должна быть адекватна условиям эксплуатации разрабатываемого ПО. В рассматриваемой среде тестирования предполагается применение двух генераторов псевдослучайных событий Рп(1)и Py(t) (рисунок 1).
Первый генерирует события в соответствии с функцией распределения поездопотока, второй - имитирует возникновение случайных событий, связанных с условиями функционирования на реальном полигоне железной дороги (климатические воздействия и другие случайные факторы). По данным ряда авторов (например, [5, 13]), функция Ру(?) имеет нормальное распределение. С учетом дискретного времени ^ виртуальной среды тестирования имеем:
((,-а)2
Ру(7,) =1 -12=\ е 2° , (4)
л/2пт 0
где - параметры распределения;
Т - время тестирования.
Как рассмотрено в работе [14], выбор закона распределения событий поездопотока Рп(7) является неоднозначной задачей, для которой в настоящее время не существует устоявшихся решений. В связи с этим предлагается метод, основанный на аппроксимации статистических данных, отражающих движение поездов на участке железной дороги. Естественно, что такой массив данных должен быть представлен в электронном виде за достаточно большой промежуток времени.
В настоящее время существует несколько систем, в которых ведется база данных по всем поездам участка:
1) Система АСОУП и аналогичные, создаваемые в рамках АСК ВП
УЗ.
2) Микропроцессорные системы диспетчерской централизации (МПДЦ).
Следует отметить, что в первом случае, информация о поездах вводится в систему оператором, во втором - автоматически, по факту занятия/освобождения участков пути, открытию светофора и т.д. В связи с этим, предлагается следующий подход. Если эксплуатация проектируемой системы управления предполагается на участке, оборудованном МПДЦ, то функция распределения промежутка времени между проследованием поездов аппроксимируются согласно выражению:
Рп(Ч) = ё*Л (5)
по двум свободным членам ё и Л [14]. В противном случае, в качестве данных о поездопотоке используется массив системы АСОУП, и аппроксимация производится по выражению:
ё 1-^77^еЛ ;0 < < М [р '()]
к1! ' (6)
Р () = \
п V I '
ё2(Л2,7;) 2 е-Л2'■;М [Р•()]< <«
К 2 ;
где к1, к2 - порядок распределения первой и второй функций соответственно; g1, g2, , я2 - рассчитываемые в процессе обработки статистических данных коэффициенты; М [Р(г)] - математическое ожидание исходной выборки.
В свою очередь блок структурной схемы М(^) (рисунок 1) реализует логику работы устройства управления при воздействии входящего события в момент времени . Например, для централизации это будет реакция на возникновение события «прием поезда», «отправление» - имитация нажатия маршрутных кнопок, перевода стрелок, открытия светофора и т.д. Функции блока М(г1) детерминированы и формализуются в виде таблиц, графов состояний, сетей Петри (например, [15]).
Таким образом, виртуальная модель среды тестирования воссоздает условия функционирования программного обеспечения на реальном полигоне железной дороги, причем адекватность модели определяется точностью аппроксимации выражений (5) и (6).
Следует отметить, что при проведении контрольных испытаний в форсированном режиме длительность тестирования значительно сокращается. В работе [12] приводится пример, где теоретическое время тестирования сокращается в 200 раз. Для этих условий оценим ограничения модели по длительности процесса тестирования для получения значений вероятности опасного отказа на одну ответственную функцию, согласно нормативным значениям ДСТУ 4178-2003.
Как правило, окончательные контрольные испытания проводятся при условии устранения всех ошибок ПО, следовательно, в процессе тестирования отказов не возникает. Однако, для этого случая и получение численных значений безопасности не возможно, т.к. Qo(ti) = 0, следовательно, максимальное значение вероятности опасного отказа должно рассчитываться для гипотетического случая возникновения хотя бы одного опасного отказа.
Так, допустим, что тестирование в форсированном режиме проводится в течение месяца реального времени, с учетом форсирования быстродействия: гИ = 720 • 200 = 1,44 • 105(ч). По известному выражению (например, [13]) интенсивность опасных отказов
Л0 = 1 441 ю5 = 6,9 -10"6(1/ ч). Тогда, считая, что закон распределения
экспоненциальный, вероятность опасных отказов за час работы для реального масштаба времени: Q0 (г = 1ч) е]0;6,9 • 10 "6[.
Выводы и практические рекомендации. Таким образом, в работе предложена модель среды тестирования на функциональную безопасность программного обеспечения, входящего в состав микропроцессорной системы управления движением поездов. Доказана адекватность, рассмотрены условия функционирования и ограничения.
Следует отметить, что для рассмотренного примера, полученное значение верхнего предела интенсивности опасных отказов на два порядка меньше уровня требований ДСТУ 4178-2003. В связи с этим, практические рекомендации для доказательства функциональной безопасности следующие:
- увеличение времени тестирования ПО;
- увеличение коэффициента быстродействия;
- одновременное тестирование нескольких копий программного обеспечения.
Список литературы
1. Чепцов М.Н. Безопасность программного обеспечения микропроцессорных тональных рельсовых цепей // Збiрник наукових праць Дон1ЗТ, 2005. - №4 - с. 54 - 61.
2. Сертификация и доказательство безопасности систем железнодорожной автоматики. Под ред. Сапожникова Вл.В. М: Транспорт, 1997. - 288 с.
3. Методы построения безопасных микроэлектронных систем железнодорожной автоматики и телемеханики. Под ред. Сапожникова Вл.В. М: Транспорт, 1995. - 272 с.
4. Соболев Ю.В., Кустов В.Ф. Обеспечению безопасности микроэлектронных технических средств железнодорожного транспорта - особое внимание // Залiзничний транспорт Украши, 1999. №3. С. 22-25.
5. Меньшиков Н.Я., Королев А.И., Ягудин Р.Ш. Надежность железнодорожных систем автоматики и телемеханики. М., «Транспорт», 1976. 215 с.
6. Казарин О.В. Безопасность программного обеспечения компьютерных систем. Монография. - М.: МГУЛ, 2003. - 212 с.
7. Зегжда Д.П., Шмаков Э.М. Проблема анализа безопасности программного обеспечения// Безопасность информационных технологий. - 1995.- №2.- С.28-33.
8. Проблемы безопасности программного обеспечения. Под ред. П.Д. Зегжда. -СПб.: Издательство СПбГТУ, 1995.
9. Лисенков В. М. Статистическая теория безопасности движения поездов: Учеб. для вузов. - М.: ВИНИТИ РАН, 1999. - 332 с., ил.
10. Липаев В.В. Надежность программного обеспечения АСУ. - М.: Энергоиздат, 1984. - 240с.
11. Смагин В.А. Техническая синергетика. Вып.1. Вероятностные модели элементов сложных систем. - СПб.: ВИКУ им. А.Ф. Можайского, 2000. - 63 с.
12. Чепцов М.Н. Метод определения параметров безопасности программного обеспечения в микропроцессорных системах управления движением поездов // Збiрник наукових праць Дон1ЗТ, 2005. - №2 - с. 39 - 46.
13. Сапожников В.В., Сапожников Вл.В., Шаманов В.И. Надежность систем железнодорожной автоматики, телемеханики и связи: Учебное пособие для вузов ж.д. трансп./ Под ред. Вл.В. Сапожникова. - М.: Маршрут, 2003. - 263 с.
14. Чепцов М.Н. Аппроксимация статистических данных входящего станционного поездопотока // Збiрник наукових праць Дон1ЗТ, 2005. - №5 - с. 103 - 110.
15. Моделирование состояний объектов систем железнодорожной автоматики / В.И. Мойсеенко, В.И. Поддубняк, В.М. Бутенко, С.А. Радковский // 1нформ. - керуючi системи на залiзн. трансп. - 2001. - №4. - С . 40 - 43.
