В повседневной жизни, услышав термин «реальное время», человек представляет себе что-то очень быстрое или передаваемое в режиме «онлайн», однако это означает лишь гарантированную своевременность выполнения каких-либо действий. Такая гарантия нужна, когда задержка при получении результата вычислений может привести к катастрофическим последствиям. Очень важно помнить, что компьютер, вместе с управляющей им операционной системой, — лишь один из элементов системы реального времени. Давайте рассмотрим представленную на рис. 1 схему некоторой абстрактной системы реального времени. Датчик считывает параметры объекта управления (ОУ: ABS автомобиля, газотурбинный двигатель, конвейер завода и т.п.) и передает на контроллер соответствующий электрический сигнал, который преобразуется в цифровую форму и через некоторое устройство ввода/вывода (например, последовательный порт RS-232) поступает в компьютер. Программное обеспечение считывает полученную информацию и на ее основе, используя или не используя дополнительные сведения (таблицы данных, указания оператора и т.п.), выполняет необходимые расчеты и через устройство ввода/вывода передает команду на устройство управления (УУ: шаговые двигатели, электромагнитные задвижки и т.п.), воздействующее на ОУ.
ОУ может быть весьма сложным и по структуре, и по выполняемым функциям. Датчиков может быть много, они могут измерять параметры ОУ, параметры окружающей среды, в которой работает ОУ, а также параметры предметов, на которые воздействует ОУ. Скажем, контроллеру системы вентиляции и кондиционирования воздуха необходимо знать наружную температуру, а контроллеру станка могут понабиться данные о результатах обработки детали станком. И конечно, команда, поступающая на УУ, должна быть не только корректной, но и своевременной — правильный, но полученный с опозданием результат вычислений может быть уже никому не нужным, например, в контроллере ABS автомобиля. Поэтому архитектура и все поведение операционных систем реального времени нацелены на достижение таких основных целей:
-
как можно быстрее отреагировать на событие (аппаратное прерывание от внешнего устройства, срабатывание таймера, получение асинхронного уведомления);
-
критичные вычисления всегда должны выполняться не дольше, чем это допустимо для корректного функционирования ОУ.
Закономерен вопрос: а какая связь между информационной безопасностью и ОС жесткого реального времени? Дело в том, что компьютерный модуль принятия решений может быть весьма сложным — это не один компьютер, а вычислительный кластер, включающий в себя автоматизированные рабочие места операторов, хранящий необходимые параметры и исходные данные в базах данных, обеспечивающий гарантированную степень надежности с помощью компьютеров «горячего» резерва и т.д. Мало того, среди разработок последних лет сложно отыскать системы реального времени, которые работали бы автономно и не входили бы в состав других информационных систем.
Увеличение сложности вычислительных систем жесткого реального времени подняло на новый уровень проблему обеспечения их информационной безопасности. Еще лет семь-десять назад на рынке программного обеспечения выпускалось и проходило сертификацию значительное количество специальных продуктов, повышающих защищенность ОС, а сегодня требования к механизмам информационной безопасности стали обязательными функциональными требованиями, предъявляемыми к ОС реального времени еще на этапе постановки задачи по их проектированию. При этом для систем жесткого реального времени всегда были и остаются особо актуальными вопросы функциональной безопасности — способности вычислительной системы не создавать угрозы жизни и здоровью людей или сохранности материальных активов.
Каким же образом при создании сложных вычислительных комплексов жесткого реального времени можно одновременно учитывать требования информационной и функциональной безопасности? При этом следует учесть, что одно и то же программное обеспечение необходимо сертифицировать в абсолютно разных системах сертификации.
«Общие критерии». Функциональные требования
Основным международным стандартом, определяющим технические требования к информационной безопасности, является ГОСТ Р ИСО/МЭК 15408 «Безопасность информационных технологий. Критерии оценки безопасности информационных технологий». Этот документ известен под названием «Общие критерии» (Common Criteria) и представляет собой систему понятий в области информационной безопасности, систематизированные каталоги функциональных требований и требований доверия. Среди предлагаемых «Общими критериями» функциональных требований есть такие, которые особенно актуальны для вычислительных систем жесткого реального времени. Эти требования входят в семейства «Приоритет обслуживания» и «Распределение ресурсов» класса «Использование ресурсов».
«Приоритет обслуживания»
Требования этого семейства предусматривают наличие у выполняющихся в компьютере программ приоритетов. Надо заметить, что в отличие от систем общего назначения в операционных системах жесткого реального времени приоритет — единственный критерий, который используется ядром для выбора из списка готовых к выполнению программ. Необходимо знать о принципиальной разнице между приоритетом и так называемым nice-числом. Приоритет — это жесткое указание ядру ОС на важность программы, а nice-число, или фактор уступчивости, — это пожелание, которое ядро должно бы учитывать при принятии решения. Наряду с nice-числом ядро многих ОС учитывает такие параметры, как, например, время, в течение которого программа уже выполнялась. Как работает планировщик конкретной ОС, должно быть указано в базовом документе — в описании системной архитектуры.
«Распределение ресурсов»
Требования семейства «Распределение ресурсов» предусматривают возможность такого управления использованием вычислительных ресурсов, чтобы не происходило несанкционированной монополизации ресурсов компьютера (оперативной памяти и процессора), которая, как правило, возникает из-за логических ошибок в программном обеспечении. Например, высокоприоритетная программа начала выполнять какие-то расчеты в бесконечном цикле — произойдет эффект «зависания», хотя с точки зрения ОС никакого сбоя нет и программы выполняются корректно. Защита от монополизации ресурсов обеспечивается с помощью механизмов максимальных и минимальных квот: максимальные квоты определяют верхний предел использования ресурса (задачей, процессом, пользователем), а минимальные квоты определяют ресурсы, минимально доступные даже в условиях предельных нагрузок.
«Общие критерии». Требования доверия
Кроме функциональных требований «Общие критерии» содержат важный для разработчиков систем реального времени класс требований доверия под названием «Тестирование». Этот класс включает в себя четыре семейства требований доверия: «Покрытие», «Глубина», «Функциональное тестирование» и «Независимое тестирование». Первые три семейства, как указано в «Общих критериях», должны применяться совместно, и разделены лишь для удобства и гибкости классификации требований доверия. Четвертое семейство содержит требования, удовлетворение которых необходимо для обеспечения независимости оценщика от разработчика.
Надо отметить, что тестирование — это одна из задач, решаемых в процессе верификации программного обеспечения. По сути дела тестирование не может гарантировать ни отсутствия в программном обеспечении ошибок, ни корректного поведения системы во всех режимах ее работы. Такие гарантии может предоставить только формальная верификация, однако тестирование позволяет повысить доверие к разработанной системе путем демонстрации двух обстоятельств:
-
программное обеспечение удовлетворяет заданным требованиям;
-
отсутствуют ошибки, которые могли бы привести к возникновению фатальных отказов ОУ.
Однако вопрос тестирования проработан в «Общих критериях» не настолько глубоко, как это необходимо для оценки функциональной безопасности критичных систем — эту задачу решает стандарт DO-178B.
ГОСТ Р 51904-2002: классификация категорий отказов
Стандарт DO-178B разработан для систем авионики, однако установленная им классификация категорий отказов, а также вытекающие из нее классификация уровней программного обеспечения и требования к тестированию программного обеспечения оказались настолько удачными, что стали широко использоваться разработчиками систем реального времени и в других отраслях. Так появился перевод стандарта DO-178B на русский язык — ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию». Классификация категорий отказов ОУ, установленная стандартом DO-178B, представлена в таблице 1.
Отказы категории А — это ситуации, препятствующие безопасному функционированию ОУ. Примером может служить отключение двигателей самолета или прекращение подачи кислорода членам экипажа.
Отказы категории B включают ситуации:
-
большое снижение функциональных возможностей или гарантийных резервов ОУ;
-
крайне тяжелое положение или перегрузки, которые могут вызвать неточное или неполное выполнение задачи;
-
опасные воздействия на окружающую среду.
В качестве примера отказа категории B можно привести неисправность аппаратуры, определяющей положение самолета в пространстве.
К отказам категории C относятся ситуации, аналогичные ситуациям категории B, но менее опасные — допускается заметное снижение функциональных возможностей ОУ или ухудшение работоспособности персонала.
К отказам категории D относят сбои, нейтрализация которых требует некоторых усилий персонала в пределах их возможностей, при этом может наблюдаться незначительное снижение функциональности ОУ или некоторое неудобство для персонала.
Отказы категории E не влияют на эксплуатационные характеристики ОУ или на рабочую нагрузку персонала, поэтому DO-178B не регламентирует требований к программному обеспечению, относящемуся к этому уровню.
Требования к тестам
В зависимости от того, к отказу какой категории может привести некорректное поведение программного обеспечения, стандарт DO-178B устанавливает требования к тестам (таблица 2).
Анализ покрытия требований (Demand Coverage) должен показывать, что для каждого требования технического задания существует хотя бы один тест, демонстрирующий выполнение требования. При анализе структурного покрытия (Statement Coverage, SC) проверяют, какие операторы программы были вызваны в ходе тестирования. Это позволяет обнаруживать неиспользованные секции кода, которые могут появляться в результате некорректного проектирования программы («мертвый» код), либо могут быть созданы специально для использования только в некоторых конфигурациях программы (отключаемый код). Мертвый код обычно удаляют с последующей проверкой эффекта удаления. Когда говорят о покрытии кода (Code Coverage), обычно имеют в виду именно SC. Надо сказать, что современные инструментальные средства позволяют визуализировать результаты анализа покрытия кода.
На рис. 2 представлен снимок окна одной из типичных интегрированных сред разработки программного обеспечения реального времени. В окне виден фрагмент исходного кода приложения, написанный на языке Си. После прогона тестов в режиме анализа кода в левой части окна мы можем увидеть отметки о прохождении кода для каждой из строк. При этом зеленая «галочка» означает, что строка была выполнена при прогоне теста, а красный «крестик» означает, что строка не была выполнена.
Анализ покрытия ветвей (Decision Coverage, DC) требует, чтобы в ходе тестирования каждая точка входа и выхода программы была использована не менее одного раза. Это означает, что если в тексте программы где-либо по какому-либо условию выполняется завершение программы, то должен быть разработан вариант тестирования, воссоздающий ситуацию, когда условие завершения будет выполняться и программа завершится.
Во фрагменте исходного кода, представленного на рис. 2, мы видим проверку условия chid<0 (ИСТИНА — если chid имеет отрицательное значение, ЛОЖЬ — нулевое или положительное значение). Если логическое условие примет значение ИСТИНА, то будет выполнен код в фигурных скобках, содержащий точку выхода из программы — функцию exit().
Таким образом, для осуществления анализа DC программы, фрагмент которой представлен на рис. 2, потребуется не менее двух тестовых прогонов, в ходе выполнения одного из которых условие chid<0 должно принимать значение ИСТИНА. Это означает, что должен быть дополнительно разработан такой тест-кейс, при котором chid обязательно принимает отрицательное значение.
И наконец, анализ покрытия условий и ветвей (Modified Condition/Decision Coverage, MC/DC) требует, чтобы в ходе тестирования каждое решение в программе принимало все возможные значения. То есть при тестировании программы необходимо обеспечить ее выполнение по каждой из возможных ветвей для всех возможных комбинаций значений ИСТИНА и ЛОЖЬ. При этом должно быть показано, какое влияние оказывает на решение каждое условие независимо от остальных условий. Для сложных логических конструкций это потребует разработки таблиц истинности. Следует отметить, что существует неофициальное, основанное на практике правило, согласно которому стоимость тест-кейсов для проведения анализа MC/DC для программного обеспечения может достигать 400% стоимости разработки собственно программного обеспечения.
Будущий стандарт DO-178C
Сложность и дороговизна тестирования MC/DC, а также анализа его результатов, привели к созданию дорогостоящих и наукоемких специализированных инструментальных средств тестирования. Наиболее известны среди них Cantata++ английской компании IPL и Rhapsody ATG корпорации IBM. По той же причине сложности и дороговизны анализа программное обеспечение, имеющее сертификат DO-178B по уровню A, имеет функционал, значительно сокращенный по сравнению с обычными версиями этих же продуктов.
Особую сложность представляет собой сертификация по уровню A программного обеспечения, разработанного с применением объектно-ориентированного подхода, включая визуальную модельно-управляемую разработку на основе языка UML: создавать современные прикладные системы и программные средства промежуточного cлоя из-за растущей сложности только структурным методом становится невозможно. Чтобы современное прикладное и промежуточное программное обеспечение можно было сертифицировать по уровню A, ведущие производители авионики и объектно-ориентированных инструментальных средств разрабатывают стандарт DO-178C, учитывающий особенности объектно-ориентированного программирования.
В заключение вспомним, что информационная безопасность включает в себя три аспекта: конфиденциальность, целостность и доступность. По сути дела функциональная безопасность основана на двух из них — целостности и доступности. Можно сказать, что для компьютерных систем реального времени информационная и функциональная безопасность являются во многом взаимопроникающими. Однако две эти области безопасности регламентируются разными нормативными документами — «Общими критериями» (ГОСТ Р ИСО/МЭК 15408) и DO-178B (ГОСТ Р 51904), и отечественные разработчики программного обеспечения должны учитывать положения обоих стандартов. Игнорирование требований одного из этих стандартов приведет к тому, что будут по-прежнему создаваться отказоустойчивые системы, беззащитные перед злоумышленниками, или системы, хорошо защищенные от злоумышленников, но на удивление ненадежные.
Сергей Зыль (s.zyl@kpda.ru) — технический директор компании «СВД Встраиваемые системы» (Санкт-Петербург).
Рис. 1. Схема системы реального времени
