Решение задачи повышения БФС определяется, в частности, степенью предсказуемости их поведения в условиях неадекватно-го поведения составляющих элементов. В ряде действующих нормативных документов сформули-рованы требования, близкие к понятию предсказуемости поведе-ния.
Так, в ГОСТ 28195-89 «Оценка качества программных средств» [57] определены требования по оценке качества на всех этапах жизненного цикла программного средства (ПС). В частно-сти, в п.1.3. данного стандарта указано, что оценку качества про-водят, в том числе, на этапе разработки ПС. При этом, одним из показателей качества выступает группа показателей надежности ПС, характеризующие «…способность ПС в конкретных облас-тях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклоне-ний в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями».
В рамках этой группы показателей надежности выделяют критерий качества 2-го уровня Н1 - «1.1. Устойчивость функцио-нирования», определяющий «…способность обеспечивать про-должение работы программы после возникновения отклонений, вызванных сбоями технических средств, ошибками во входных данных и ошибками обслуживания». Данный критерий качества применяется практически для всех подклассов (групп) ПС.
В качестве примера можно привести положения, действую-щего в настоящее время ГОСТ 24.701-86 «ЕСС АСУ. Надеж-ность автоматизированных систем управления.
Основные поло-жения» [15], в п.2.1. которого в качестве одного из показателей надежности АСУ используют показатель, характеризующий опасность возникновения в системе аварийных ситуаций. Этот показатель имеет две составляющие:
- опасность возникновения аварийной ситуации в течение некоторого заданного интервала времени нормального функцио-нирования системы;
- опасность возникновения аварийной ситуации в результате воздействия на систему внешнего экстремального фактора.
Для описания надежности АСУ по аварийным ситуациям могут быть использованы следующие показатели:
- средняя наработка системы до возникновения в ней ава-рийной ситуации при нормальных условиях функционирования АСУ;
- вероятность возникновения в системе аварийной ситуации в течение заданного времени при нормальных условиях функ-ционирования АСУ;
- вероятность возникновения в системе аварийной ситуации в течение заданного времени от одного из рассматриваемых экс-тремальных воздействующих факторов; - а также ряд других факторов.
Пункт 4.1 стандарта [15] определяет, что оценку надежно-сти АСУ по аварийным ситуациям проводят при разработке сис-темы с целью прогноза ожидаемого уровня надежности АСУ, а также при вводе системы в эксплуатацию с целью определения фактически достигнутого уровня надежности.
Проектную оценку надежности АСУ допускается проводить следующими методами [15]:
- аналитическими;
- вероятностного моделирования;
- комбинированными, представляющими собой сочетание аналитических методов и методов моделирования;
- экспертными.
Стандарт также определяет, что к обязательным работам по обеспечению надежности АСУ относят:
- анализ состава и содержания разрабатываемой (модерни-зируемой) АСУ, определение конкретного содержания понятия «отказ» и критериев отказа по каждому виду отказов для всех функций системы; анализ, при необходимости, аварийных ситуа-ций в АСУ, определение конкретного содержания понятия «ава-рийная ситуация» для данной АСУ и критериев аварийной ситуа-ции по каждой из рассматриваемых ситуаций;
- выбор состава показателей надежности по всем функциям АСУ, указанным в ТЗ на АСУ и, при необходимости, по всем аварийным ситуациям, и определение требований к уровню их значений;
- выбор методов оценки надежности АСУ при разработке технического проекта системы;
- определение режимов и параметров технической эксплуа-тации АСУ [15].
Программу обеспечения надежности конкретной АСУ со-ставляют при разработке ТЗ на АСУ и оформляют в виде отдель-ного организационно-распорядительного документа, являющего-ся приложением к ТЗ на АСУ [15].
Можно видеть, что сущность показателя, характеризующего опасность возникновения в системе аварийных ситуаций, являет-ся вероятностно-статистической и не выявляет источников и причин отказа, а также, не определяет характер его последствий на функционирование ЭС. Иными словами, фиксируется факт наличия отказа и определяются вероятностные характеристики его возникновения.
Существуют и другие подходы по обеспечению безопасно-сти функционирования программных средств (ПС) [35, 40]. При этом используется понятие функциональной безопасности (ФуБ) и рассматриваются вопросы ее обеспечения на всех стадиях жиз-ненного цикла (ЖЦ) ПС. При этом, требование обеспечения ФуБ представляется как составная часть системной эффективности применения программных средств, которая в ряде стандартов от-ражается основной, обобщенной характеристикой качества - функциональной пригодностью ПС.
Использование понятия «функциональная безопасность» в качестве характеристики качества необходимо только для крити-ческих ПС (в соответствии со стандартом ISO 12182 [41]), со-ставляющих достаточно узкий класс базовых и прикладных про-граммных средств, которому соответствуют около 10 — 15% от общего числа. Такие ПС применяются при управлении движу-щимися объектами на транспорте и в авиации, в атомной энерге-тике, в автоматизированных производствах, во встроенных ком-пьютерных системах и программируемых электронных системах безопасности.
Согласно ГОСТ Р ИСО/МЭК 9126-93 [42], характеристики качества ПС различаются по степени влияния на системную эф-фективность применения комплексов программ по прямому на-значению. Проектирование эффективных ПС должно быть на-правлено на обеспечение их высокой функциональной пригодно-сти «путем сбалансированного улучшения остальных конструк-тивных характеристик качества (и безопасности) в условиях ог-раниченных ресурсов на ЖЦ» [43], поэтому на стадиях подготов-ки технического задания и требований спецификаций, значения различных факторов, определяющих характеристики качества и безопасности должны выбираться с учетом их влияния на функ-циональную пригодность.
В ГОСТ Р 51904 [44] вводятся следующие категории отка-зовых ситуаций в системах и ПС исходя из опасности отказовых ситуаций и возможного при этом ущерба для программ, системы и потребителя:
- категория А — катастрофическая: отказовая ситуация, которая препятствует полной работоспособности и функциони-рованию системы или ПС в соответствии с требованиями и спо-собна нанести недопустимый по последствиям и величине ущерб системе или пользователям;
- категория B — опасная/критическая: отказовая ситуа-ция, которая приводит к значительному снижению работоспо-собности, возможностей применения и функционирования сис-темы или к отсутствию способности персонала справиться с не-благоприятными эксплуатационными режимами, при которых возникают:
- крайне тяжелые ситуации или перегрузки системы, кото-рые могут вызвать неточное или неполное выполнение основных, функциональных задач с большим ущербом;
- недопустимо большое снижение характеристик функцио-нальной пригодности, реализуемых функций и конструктивных характеристик качества системы или ПС;
- неблагоприятные или потенциально фатальные воздейст-вия системы или ПС для окружающей внешней среды;
- категория C — существенная: отказовая ситуация, кото-рая приводит к снижению возможностей применения и функцио-нальной пригодности системы или к сокращению способности персонала справиться с неблагоприятными эксплуатационными режимами, при продолжении которых может возникать, напри-мер, большое искажение информационных ресурсов или сокра-щение функциональных возможностей, перегрузки или условия, вызывающие существенное ухудшение работоспособности сис-темы или персонала;
- категория D — несущественная: отказовая ситуация, не-значительно уменьшающая безопасность функционирования и применения объекта, но отражающаяся на его надежности или требующая действий персонала, которые осуществимы в преде-лах их возможностей для восстановления нормальной работоспо-собности, такая ситуация может включать в себя, например, не-которое увеличение рабочей нагрузки, неудобство применения или задержки информации для персонала;
- категория Е — невлияющая: отказовая ситуация, которая практически не воздействует на работоспособность, эксплуата-ционные характеристики и возможности объекта или не увеличи-вает рабочую нагрузку персонала.
В стандарте ISO 13335-1…5-1996 (1998) [45] приводятся основные подходы по проектированию равнопрочных систем обеспечения безопасности информационных систем от угроз раз-личных видов, предусматривающие разработку проекта защиты системы для последующей разработки конкретной комплексной системы обеспечения ФуБ ИС. Введено понятие риска от любых негативных воздействий на ИС, представлены функции средств защиты и необходимые действия по их реализации, модели уяз-вимости и взаимодействие средств защиты, а также предложена и развивается концепция и модель управления и планирования по-строения системы обеспечения безопасности.
В стандарте МЭК 60880 [46] приводятся требования и реко-мендации по ФуБ программного обеспечения компьютеров в сис-темах безопасности атомных электростанций. В нем сконцентри-рованы рекомендации по методам и процедурам, обеспечиваю-щих и гарантирующих высокое качество и безопасность функ-ционирования программ на всех этапах их жизненного цикла, предотвращающих ошибки и отказы системы.
В частности, рекомендуется тщательно разрабатывать тре-бования к ПС и подробно отражать в них функции, конфигура-цию системы, взаимодействие с внешней средой, ограничения характеристик аппаратуры и комплекса программ, необходи-мость непрерывного контроля программных и аппаратных средств, самоконтроля логики и данных программ, на декомпози-цию и модульное построение ПС, на стройность и простоту структуры программ для сокращения дефектов и ошибок. Реко-мендуется создавать систему защитных барьеров и самоконтроля исполнения программ для обеспечения гарантированной работо-способности и безопасности систем управления на базе ПС. Предлагается совокупность методов предотвращения ошибок в ЖЦ ПС путем: создания разнообразия условий функционирова-ния, N-версионного программирования, дублирования специфи-каций компонентов при одинаковых функциях, доказательства формальной корректности программ.
Стандарт ISO 15408 [35] для обеспечения заданных характе-ристик ПС, в том числе и для обеспечения необходимого уровня безопасности функционирования, предлагает методологию обес-печения качества сложных программных средств на основе СММ (Capability Maturity Model) модели оценки зрелости комплекса применяемых технологических процессов. Модель основана на использовании пяти уровней зрелости технологий поддержки ЖЦ ПС, которые определяют потенциально возможное качество и безопасность создаваемых комплексов программ (табл. 1. 1.).
Из табл.1.1. видно, что для определенного уровня сложности проек-та и уровня предъявляемых требований, возникает необходи-мость осуществления активных мер и мероприятий по выявле-нию дефектов и повышению качества разработки, и, в том числе, функциональной безопасности ПС.
Обеспечение качества и функциональной безопасности ПС с учетом специфики жизненного цикла программных средств встроенных систем реального времени высокого качества, пре-имущественно для авиационных, космических и транспортных систем, представлены в стандарте ГОСТ Р 51904-2002 [44]. В стандарте ISO 17799 [47] рассмотрена инфраструктура безопасности систем. Рекомендуются организационные, методи-ческие и технические мероприятия по обеспечению информаци-онной безопасности. При этом разделены понятия «физическая безопасность системы» и «безопасность окружающей среды, про-граммных средств разработки и рабочих программ».
Стандарт MIL-STD-1629A [48] устанавливает требования и процедуры для выполнения FMECA (failure mode, effects and criti-cality analysis) анализа. Оценивается потенциальное влияние ка-ждого функционального отказа и отказа оборудования на функ-ционирование системы, ее безопасность по отношению к окру-жающей среде, системную производительность и требования по эксплуатации.
Анализ выполняется на всех этапах проектирования и вклю-чает 5 типовых задач: анализ последствий, критический анализ, информацию по обслуживанию, анализ последствий разруше-ния, планирование анализа. В качестве представления архитекту-ры системы используются блок-диаграммы.
В целом, для построения перспективных устройств и систем с предсказуемым поведением в условиях возникновения нештат-ной ситуации необходимо исключить все возможные действия устройства (системы) (неадекватные действия) в этих условиях, не относящиеся к выполнению основных и вспомогательных за-ранее оговоренных функций.
