Технология автоматизации
проектирования программного обеспечения встроенных систем
Д.В.Иванов,
Е.А.Казанкин
И.А.Невмянов,
ОАО «Корпорация «Русские системы», г. Москва
Аннотация
Настоящая
работа посвящена технологиям применения средств автоматизированного
проектирования программного обеспечения при разработке критических по безопасности
программно-аппаратных систем. Рассматриваемый подход позволяет значительно
снизить или, в ряде случаев, полностью исключить риск внесения в программное
обеспечение ошибок на этапе написания текста программы на соответствующем языке
программирования и, как следствие, значительно уменьшить или исключить затраты
времени и трудовых ресурсов на организацию тестирования объектного кода
программы.
Abstract
This paper presents a technology that allows
utilizing software algorithm modeling systems in the framework of the development
of safety-critical equipment. Presented approach allows for dramatic decrease
or complete removal of a risk of introducing error at the stage of software
code development and, therefore, reduce or completely avoid the necessity of
spending time and effort for object code testing.
Введение
Критические
по безопасности автоматизированные системы, применяемые в авиастроение,
энергетике, медицине и многих других отраслях промышленности, характеризуются
тем, что их отказ или нештатное функционирование может повлечь значительный
ущерб, в том числе, жизни и здоровью людей, а также окружающей среде.
Опыт
эксплуатации современных систем подобного рода показывает, что до 90% отказных
ситуаций связаны с нештатным функционированием программного обеспечения
(классические примеры ошибок в ПО, повлекших катастрофические последствия, приведены
в [1]), поэтому на фоне естественного повышения объема функциональных требований
и степени ответственности таких систем вопросы обеспечения безопасности
программного обеспечения являются крайне актуальными.
С
учетом определяющего вклада прикладного ПО в уровень надежности
рассматриваемого класса систем, порядок его разработки относительно хорошо
регламентирован в государственных и отраслевых нормативных документах, как
зарубежных (DO-178B, IEC 60880, Def Stan 00-55 и др.), так и российских (ГОСТ Р
51904-2002, МАК КТ-178В и др.). Однако, выполнение работ в соответствии с
указанными стандартами приводит к радикальному (в несколько раз) увеличению
трудоемкости в сравнении с разработкой некритического ПО, что влечет
значительные финансовые затраты и удлиняет срок разработки и выпуска конечного
продукта.
Помимо
повышенных финансовых и временных затрат, к основным проблемам, имеющим место
при организации процессов разработки критического по безопасности программного
обеспечения можно отнести следующее:
· Потребность внедрения
разрабатываемого изделия в требуемые, как правило, сжатые сроки (установленные
Заказчиком или конкурентным характером рыночных отношений) значительно увеличивает
риск возникновения аварий в связи с программными ошибками, не выявленных при
разработке и испытаниях системы.
· Как правило, разработка
систем рассматриваемого класса, в том числе, и программного обеспечения, носит
закрытый характер, поэтому, на практике отсутствует возможность повторного
использования создаваемого научно-технического задела на отраслевых и межотраслевых
уровнях;
· В целом наблюдается
недостаточная подготовленность и квалификация специалистов, занятых в процессах
разработки критического по безопасности программного обеспечения.
Таким
образом, обеспечение необходимого уровня надежности и безопасности критических
по безопасности технических систем при минимизации финансовых и временных
затрат, требует особых подходов при разработке, испытаниях и эксплуатации
соответствующего программного обеспечения [2,3].
Одним
из таких подходов является использование технологий автоматизированного
проектирования программного обеспечения с использованием инструментальных
средств, позволяющих представлять алгоритм работы программного обеспечения в
виде модели, осуществлять автоматизированный анализ свойств и поддержку
проверки соответствия данного алгоритма исходным (как правило, неформализованным)
требованиям, а также последующее автоматическое формирование текста программы,
полностью соответствующего разработанной модели.
В
настоящей статье рассматривается роль и место автоматизированных средств
проектирования программного обеспечения (далее, САПР) в типовом процессе
разработки критического по безопасности ПО, основные преимущества использования
САПР при разработке программного обеспечения, типовые требования к таким
инструментальным средствам и их аттестации, а именно, подтверждения возможности
их использования без необходимости отдельного тестирования объектного кода при
полноценном тестировании модели.
1. Место САПР в процессе разработки критического по безопасности ПО
В
Российской Федерации основным нормативным документом, регламентирующим порядок
выполнения работ по разработке программного обеспечения встроенных систем и
требования к результатам таких работ, является ГОСТ Р 51904-2002. В данном
стандарте определены основные процессы (приведены на рисунке 1), выполняемые
при разработке программного обеспечения, распределенные по трем группам: процессы
планирования, процессы разработки и интегральные процессы.
рис. 1. Основные процессы жизненного цикла ПО встроенных систем
Кроме
того, ГОСТ Р 51904-2002 определяет 5 уровней программного обеспечения в
зависимости от категории отказной ситуации, которая может быть следствием
ошибок, допущенных в ПО. Перечень категорий отказных ситуаций приведен в
таблице 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, с ростом уровня программного обеспечения, количество работ,
обязательных для выполнения при разработке программного обеспечения, многократно
возрастает, при этом, по очевидным причинам, чем выше уровень критичности ПО,
тем выше требования, предъявляемые к процессу тестирования. Вместе с тем, с
учетом сложности и объемности текста программы, написанном на языке программирования
(например, ANSI C/C++), организация
полноценного процесса тестирования с подтверждением соответствия данного текста
каждому требованию низкого уровня, а также оценкой покрытия кода и требований,
является крайне трудоемкой и технологически сложной задачей.
С
учетом изложенного, актуальным является использование САПР, которое позволяет
автоматизировать ряд работ процесса проектирования ПО (см. рисунок 1), за счет
автоматизированной генерации текста программы полностью избежать трудозатрат
этапа кодирования, а также значительно автоматизировать работы по верификации
программного обеспечения в части тестирования.
2. Преимущества использования САПР
Типовой
цикл разработки встроенного программного обеспечения – так называемый V-цикл,
приведенный на рисунке 2 сверху, предполагает, что разработку функциональных
требований к программному обеспечению выполняет специалист (инженер),
разбирающийся в предметной области и, как правило, оперирующий такими
понятиями, как измеренное значение физической величины, сигнал, циклограмма и
т.п. При этом, реализация таких требований в форме исходного текста программы
осуществляется программистом на выбранном языке программирования. При этом, в
большинстве случаев программирование специализированных встроенных систем
ограничивает выбор языка программирования до ANSI С или С++, которые
являются языками общего назначения, предоставляющими разработчику широкие возможности
по работе с ресурсами, переменными, системными функциями. Терминологическое
несоответствие областей деятельности инженера и программиста, а также широкие
возможности языка программирования, обуславливают высокий риск внесения
программистом ошибок при разработке текста программы, а также высокий риск
пропуска таких ошибок при тестировании. На практике, отмеченная специфика приводит
к большому количеству итераций в цикле «уточнение
требований»-«реализация»-«тестирование», что сопровождается значительными
временными и, как следствие, финансовыми, затратами.
рис. 2. V-цикл (сверху) иY-цикл (снизу) разработки
встроенного программного обеспечения
Устранение
риска внесения ошибок на этапе разработки текста программы возможно путем
использования аттестованных инструментальных средств автоматизированного
проектирования программного обеспечения (САПР), обеспечивающих автоматическую
генерацию текста программы из разработанного инженером формального алгоритма, выраженного
в какой-либо графической или текстовой нотации.
Использование
модельно-ориентированного подхода и специализированных инструментальных САПР
при проектировании ПО встроенных систем обеспечивает автоматизацию ряда
процессов, изложенных в разделе 1, что позволяет перейти от V-цикла
к Y-циклу разработки ПО (см. рисунок 2) со значительным сокращением
трудозатрат и, как следствие, времени разработки.
3. Основные требования к САПР
С
учётом отмеченных задач, возлагаемых на инструментальные средства
автоматизированного проектирования программного обеспечения критических по
безопасности технических систем, к основным требованиям, предъявляемым к таким
системам, можно отнести следующие требования.
1.
САПР должна обеспечивать разработку алгоритма (модели) работы программного
обеспечения целевой программно-аппаратной системы в инженерных терминах в графической
или текстовой форме (см., например, рисунок 3). При этом принятые в общей практике
инструментальные средства проектирования программного обеспечения, например,
основанные на стандартном языке UML, не учитывают специфику разработки
программного обеспечения встроенных систем, в частности, связанной с
гарантированным обеспечением детерминизма при выполнении программы, и, как
следствие, имеют ограниченные возможности для применения [4].
2.
САПР должна обеспечивать автоматическое формирование текста программы,
гарантированно соответствующего разработанному алгоритму (модели), на
стандартном языке программирования, например, ANSI C, при
этом, автоматически сформированный текст должен быть компилируем в объектный
код, исполняемый на соответствующей целевой программно-аппаратной платформе.
3.
САПР должна обеспечивать имитацию (моделирование) или, что более
предпочтительно, симуляцию исполнения разрабатываемого алгоритма на целевой
системе с целью его верификации (тестирования).
4.
САПР должна обеспечивать возможность организации полноценного тестирования
разработанного алгоритма (модели) в целях проверки его соответствия требования,
предъявляемым к программному обеспечению, в том числе, с оценкой покрытия и
т.п.
5.
По возможности, САПР должна обеспечивать автоматическую проверку выполнения
ряда требований к программному обеспечению, таких, как, например, отсутствие зацикливаний,
неисполняемых фрагментов кода и т.п.
6.
САПР должна обеспечивать поддержку трассируемости между требованиями верхнего
уровня (как правило, выраженным в текстовой форме) и алгоритмом, реализующим
данные требования, а также предъявление соответствия между алгоритмом и
автоматически сформированным текстом программы.
рис. 3. Пример графического
представления алгоритма работы встроенного программного обеспечения
7.
САПР должна обеспечивать возможность ее информационной интеграции с другими
инструментальными средствами, используемыми в процессе разработки программного
обеспечения, в том числе, средствами анализа требований, поддержки жизненного
цикла программного обеспечения и т.п.
8.
САПР должна быть удобна и интуитивна понятна при ее использовании по
назначению, позволять специалистам, не имеющим образования в области
кодирования программного обеспечения, осуществлять разработку сложных
алгоритмов (моделей) программ.
4. Особенности аттестации САПР
В
соответствии с ГОСТ Р 51904-2002, аттестация инструментальных средств,
используемых при разработке ПО критических по безопасности систем, необходима,
когда соответствующие процессы (процедуры) могут быть исключены, сокращены или
автоматизированы посредством использования данных инструментальных средств без
верификации (оценки соответствия установленным требованиям) их выходных данных.
Целью
процесса аттестации является предоставление гарантий того, что соответствующее
инструментальное средство обеспечивает доверие, по крайней мере, эквивалентное
доверию к тем процессам, которые будут исключены, сокращены или
автоматизированы. В связи с этим могут быть аттестованы только
детерминированные инструментальные средства, то есть такие средства, которые
выдают те же самые результаты для тех же самых входных данных при работе в той
же самой среде. Как правило, инструментальные средства аттестуются
исключительно в связи с их применением в конкретном проекте или типах проектов.
Критериями
аттестации САПР в общем случае являются следующие условия.
1.
Если САПР должна быть аттестована, то процессы разработки ПО для этого САПР
должны удовлетворять тем же самым целям, что и процессы разработки целевого ПО
критической по безопасности системы, при разработке которой предполагается
использование САПР.
2.
Уровень ПО (см. таблицу 1), назначенный САПР при ее разработке, должен как
правило быть такой же или выше уровня, назначенного целевому ПО. При этом
допускаются незначительные исключения, например, в случаях, если обосновано,
что результаты исключаемого применением САПР процесса разработки ПО носят
второстепенный характер. Например, проверки соблюдения требований по именованию
переменных в тексте программы менее важна, чем проверка соответствия текста
программы требования, предъявляемым к системе.
3.
Аттестуемая САПР, как правило, должна пройти этап опытной эксплуатации, когда
ее выходные результаты полноценно проверяются в соответствии с требованиями нормативной
документации, оцениваются возможные недостатки и осуществляется коррекция
самого САПР.
Отмеченные
выше критерии обуславливают тот факт, что только такие САПР, которые прошли аттестацию
установленным порядком, могут быть применены при разработке программного
обеспечения критических по безопасности систем для исключения или сокращения
объемов работ, связанных с тестированием на уровне объектного кода. Вместе с
тем следует отметить, что работы по аттестации самой САПР, как правило,
значительно более трудоемки по отношению к аналогичным работам по сертификации
целевого программного обеспечения в связи с тем, что требования (функции)
назначения САПР, как правило, достаточно широки и многогранны.
Заключение
Опыт
практических работ по разработке критических по безопасности систем
свидетельствует, что процессы разработки соответствующего программного обеспечения
требуют особых комплексных подходов на всех этапах выполнения работ. Рассмотренные
в настоящей работе принципы использования автоматизированных средств проектирования
программного обеспечения, являясь элементами комплексной технологии разработки
критического по безопасности прикладного программного обеспечения, позволяют
обеспечить выполнение работ в требуемые сроки и минимизировать финансовые
затраты при соблюдении необходимых требований нормативно-технической документации
и повышении уровня доверия к разрабатываемому ПО со стороны потребителей.
Литература
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.