Технологии разработки критического по безопасности
программного обеспечения

Д.В. Иванов,

первый вице - президент,

Е.А. Казанкин,

главн. констр.,
ОАО «Корпорация «Русские системы», г. Москва,

В.П. Иванников,
зав. каф., акад. РАН,
МФТИ, г. Москва

Настоящая работа посвящена некоторым элементам комплексной технологии, применяемой при разработке критического по безопасности программного обеспечения. Использование данной технологии позволяет значительно снизить временные и финансовые затраты при удовлетворении необходимых требований, связанных с обеспечением заданного уровня безопасности системы.

 

This paper presents some elements of complex technology, which is utilized to support the life-cycle of safety-critical software. Use of such technology allows for dramatic reduction of time and cost of development processes while fulfilling all requirements corresponding to the respective category of the system that is being developed.

Введение

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

Опыт эксплуатации современных систем подобного рода показывает, что до 90% отказных ситуаций связаны с нештатным функционированием программного обеспечения (классические примеры ошибок в ПО, повлекших катастрофические последствия, приведены в [1]), поэтому на фоне естественного повышения объема функциональных требований и степени ответственности таких систем вопросы обеспечения безопасности программного обеспечения являются крайне актуальными.

С учетом определяющего вклада прикладного ПО в уровень надежности рассматриваемого класса систем, порядок его разработки относительно хорошо регламентирован в государственных и отраслевых нормативных документах, как зарубежных (DO-178B, IEC 60880, Def Stan 00-55 и др.), так и российских (ГОСТ Р 51904-2002, МАК КТ-178В и др.). Однако, выполнение работ в соответствии с указанными стандартами приводит к радикальному (в несколько раз) увеличению трудоемкости в сравнении с разработкой некритического ПО, что влечет значительные финансовые затраты и удлиняет срок разработки и выпуска конечного продукта.

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

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

·      Как правило, разработка систем рассматриваемого класса, в том числе, и программного обеспечения, носит закрытый характер, поэтому, на практике отсутствует возможность повторного использования создаваемого научно-технического задела на отраслевых и межотраслевых уровнях.

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

Таким образом, обеспечение необходимого уровня надежности и безопасности критических по безопасности технических систем при минимизации финансовых и временных затрат, требует особых подходов при разработке, испытаниях и эксплуатации соответствующего программного обеспечения. С учетом изложенного, технологии производства программного обеспечения отнесены Президентом (Приказ № Пр-842 от 21.05.2006) и Правительством (Распоряжение № 1243-р от 25.08.2008) к критическим технологиям Российской Федерации.

1. Типовые процессы разработки критического по безопасности ПО

В Российской Федерации основным нормативным документом, регламентирующим порядок выполнения работ по разработке программного обеспечения встроенных систем и требования к результатам таких работ, является ГОСТ Р 51904-2002. В данном стандарте определены основные процессы (приведены на рисунке 1), выполняемые при разработке программного обеспечения, распределенные по трем группам: процессы планирования, процессы разработки и интегральные процессы.

Кроме того, ГОСТ Р 51904-2002 определяет 5 уровней программного обеспечения в зависимости от категории отказной ситуации, которая может быть следствием ошибок, допущенных в ПО. Перечень категорий отказных ситуаций приведен в таблице 1.

 



рис. 1 Основные процессы жизненного цикла ПО встроенных систем

Таблица 1

Категории отказных ситуаций и уровни программного обеспечения

Категория

Краткая характеристика

А: Катастрофическая

Препятствует безопасному функционированию объекта управления

 

В: Критическая

Приводит к критическому уменьшению возможностей объекта управления или способности персонала справиться с неблагоприятными режимами

С: Существенная

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

D: Несущественная

Незначительно уменьшает безопасность объекта и требует действий персонала, которые осуществимы в пределах их возможностей

E: Невлияющая

Не воздействует на эксплуатационные возможности объекта управления и не увеличивает рабочую нагрузку персонала

 

В зависимости от назначенного уровня программного обеспечения определяется количество задач (целей), которые обязательны для выполнения или могут выполняться на усмотрения заказчика. При этом, некоторые из таких задач необходимо выполнять с обеспечением независимости, что подразумевает, что исполнитель соответствующих работ не вовлечен в процессы разработки ПО. К примерам определенных в стандарте целей относятся «Разработать архитектуру ПО», «Убедиться, что алгоритмы точны и корректны», «Убедиться, что исходный код согласуется с архитектурой ПО» и т.п. Общее количество определенных целей в зависимости от уровня программного обеспечения приведено в таблице 2.

Таблица 2

Количество обязательных для достижения целей в зависимости от уровня ПО

Уровень ПО

(категория отказной ситуации)

Целей, удовлетворяемых с обеспечением независимости

Целей, удовлетворяемых обязательно

Целей, удовлетворяемых на усмотрение заказчика

A: Катастрофическая

25

41

1

B: Критическая

14

51

2

C: Существенная

2

55

10

D: Несущественная

2

28

37

E: Невлияющая

 

 

67

 

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

2. Базовая архитектура прикладного ПО

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

·      Открытая архитектура, допускающая эффективное наращивание функционала программного комплекса, гибкую компоновку системы под конкретное назначение;

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

·      Контроль потоков данных и управления с обеспечением четкого планирования ресурсов, в том числе, режима исполнения в «жестком» реальном времени, а также обеспечение детерминизма (предсказуемости) исполнения ПО, что принципиально важно для критических по безопасности систем;

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

·      Гибкость конфигурирования, обеспечивающая возможность изменения параметров функционирования программного комплекса, в том числе, в эксплуатации (при необходимости), без изменения текста программы;

·      Многоверсионное ПО, предусматривающее создание двух или более компонентов ПО для реализации одной и той же функции способами, исключающими источник общих ошибок в нескольких компонентах;

·      Мониторинг безопасности, предусматривающий прямой независимый мониторинг функций, которые могут привести к отказной ситуации, как программными, так и аппаратными средствами.

В целях эффективной реализации указанных выше архитектурных подходов, ОАО «Корпорация «Русские системы» была разработана базовая архитектура открытого кросс-платформенного программного комплекса (шифр «РСДА»), приведенная на рисунке 2, и успешно применяемая в широком спектре программно-аппаратных средств как наземного, так и бортового применения. Некоторые особенности указанной архитектуры приведены в [2,3].

рис. 2 Архитектура открытого кросс-платформенного программного комплекса (шифр «РСДА»)

3. Инструментальные средства автоматизированного проектирования ПО

Типовой цикл разработки встроенного программного обеспечения – так называемый V-цикл, приведенный на рисунке 3 слева, предполагает, что разработку функциональных требований к программному обеспечению выполняет специалист (инженер), разбирающийся в предметной области и, как правило, оперирующий такими понятиями, как измеренное значение физической величины, сигнал, циклограмма и т.п. При этом, реализация таких требований в форме исходного текста программы осуществляется программистом на выбранном языке программирования. При этом, в большинстве случаев программирование специализированных встроенных систем ограничивает выбор языка программирования до ANSI С или С++, которые являются языками общего назначения, предоставляющими разработчику широкие возможности по работе с ресурсами, переменными, системными функциями. Терминологическое несоответствие областей деятельности инженера и программиста, а также широкие возможности языка программирования, обуславливают высокий риск внесения программистом ошибок при разработке текста программы, а также высокий риск пропуска таких ошибок при тестировании. На практике, отмеченная специфика приводит к большому количеству итераций в цикле «уточнение требований»-«реализация»-«тестирование», что сопровождается значительными временными и, как следствие, финансовыми, затратами.

              

рис. 3  V-цикл (слева) иY-цикл (справа) разработки встроенного программного обеспечения

Устранение риска внесения ошибок на этапе разработки текста программы возможно путем использования аттестованных инструментальных средств автоматизированного проектирования программного обеспечения (САПР), обеспечивающих автоматическую генерацию текста программы из разработанного инженером формального алгоритма, выраженного в какой-либо графической или текстовой нотации. При этом принятые в общей практике инструментальные средства проектирования программного обеспечения, например, основанные на стандартном языке UML, не учитывают специфику разработки программного обеспечения встроенных систем, в частности, связанной с гарантированным обеспечением детерминизма при выполнении программы, и, как следствие, имеют ограниченные возможности для применения [4]. Таким образом, для автоматизации разработки критического по безопасности ПО необходимы специализированные инструментальные средства, которые бы обеспечивали: (1) разработку алгоритма (модели) работы целевой системы в инженерных терминах в графической или текстовой форме; (2) автоматическое формирование по текста программы на стандартном языке программирования, например, ANSI C; (3) симуляцию исполнения разрабатываемого алгоритма с целью его верификации; (4) по возможности, формальное доказательство соответствия алгоритма и сформированного текста программы предъявленным к ним требованиям; (5) поддержку тестирования разработанных программных модулей на всех этапах; (6) поддержку трассируемости между текстом программы и объектным кодом, полученным на этапе компиляции, с целью предотвращения внесения каких-либо ошибок на этапе компиляции.

ОАО «Корпорация «Русские системы» в целях оптимизации процессов разработки встроенного программного обеспечения, разработало и с успехом применяет набор инструментальных средств автоматизированного проектирования программного обеспечения, в том числе, позволяющих инженеру без привлечения программиста разработать обособленные программные модули, встраиваемые в открытую архитектуру кросс-платформенного программного комплекса (рисунок 2), а также отработать данные модули как в среде тестирования на инструментальной ЭВМ (см. раздел 4), так и на целевой платформе. Аналогичные подходы применяют и другие компании, специализирующиеся на технологиях разработки критического по безопасности программного обеспечения [5].

Использование модельно-ориентированного подхода и специализированных инструментальных САПР при проектировании ПО встроенных систем обеспечивает автоматизацию ряда процессов, что позволяет перейти от V-цикла к Y-циклу разработки ПО (см. рисунок 3) со значительным сокращением трудозатрат и, как следствие, времени разработки.

4. Цикл отработки и тестирования программного обеспечения

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

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

Значительное преимущество при тестировании достигается за счет совместного использования принципов открытой модульной архитектуры и переносимости ПО между различными программно-аппаратным платформами. Используя указанные принципы, предварительное функциональное тестирование разработанных целевых программных модулей можно начинать с использованием инструментальной ЭВМ, например IBM-совместимой ПЭВМ с ОС типа Windows или Linux, на которой следует сформировать программную среду тестирования, включающую: (1) конфигуратор и ядро комплекса; (2) комплект целевых модулей, обеспечивающих необходимый объем функций назначения; (3) комплект модулей, обеспечивающих возможность моделирования входных воздействий; (4) комплект модулей, обеспечивающих мониторинг параметров системы, отображение соответствующей информации пользователю, а также регистрацию параметров, при необходимости. На рисунке 4 слева показана общая структурная схема такого ПО стенда программного комплексирования, где синим фоном отмечены инструментальные (технологические) программные модули, а желтым – целевые тестируемые модули, текст программы которых не изменяется при переносе между платформами.

                

рис. 4  ПО стенда программного комплексирования (слева) и программно-аппаратного  комплексирования (справа)

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

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

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


рис. 5 Стендовое обеспечение тестирования ПО и распределение работ

Заключение

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

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

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

Литература

1.   В.Аджиев. Мифы о безопасном ПО: уроки знаменитых катастроф. Открытые системы, http://www.osp.ru/os/1998/06/179592/.

2.   Д.Иванов. Технология разработки программного обеспечения встроенных системы. Труды международной конференции "Перспективы использования новых технологий и научно-технических решений в ракетно-космической и авиационной промышленности", ИПУ РАН. 2008.

3.   Д.Иванов. Современные принципы построения программного обеспечения бортовых и наземных программно-аппаратных комплексов обработки данных. Материалы научно-практической конференции "Проблемы и перспективы создания аварийных регистраторов". Курск, Россия, Июнь 2006.

4.   A.Geunnec, B.Dion. Bridging UML and Safety-Critical Software Development Environment. 3rd European Congress on Embedded Real Time Software, 2006.

5.   G.Berry. The Effectiveness of Synchronous Languages for the Development of Safety-Critical Systems. Esterel Technologies. 2003.