Надежность и отказобезопасность программного обеспечения 

Перед тем как мы перечислим задачи для анализа надежности и отказобезопасности программного обеспечения, важно понять, что подразумевается под таким отказом. В отказы программного обеспечения не входят случайные отказы или отказы, связанные с износом, которые можно наблюдать в оборудовании. Программное обеспечение всегда будет работать одинаково, если входные данные и состояние компьютера не меняются. Программное обеспечение может привести к отказам системы из-за ошибок проектирования или реализации. Ошибки проектирования часто являются последствием неправильного понимания функционирования системы, например, за входными данными A всегда следуют входные данные B. Типичные ошибки реализации вызваны тем, что существует путаница в символах, например, 'g' вместо 'G'. Ошибки программного обеспечения могут вызвать отказы только в том случае, если ошибки встречаются во время использования. Следовательно, существующие ошибки в часто используемом коде приводят к отказам гораздо чаще, чем ошибки в редко используемом коде, хотя и эти ошибки так же являются достаточно серьезными. В критически важных приложениях и в приложениях с особыми требованиями к безопасности крайне важно периодически проверять и тестировать редко используемые коды.

 

Надежность программного обеспечения

 

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

 

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

• Постоянного пересмотра требований на протяжении всего жизненного цикла, в частности для работы в особых ситуациях. Если требования неполные, то тестирование работы в особых ситуациях не состоится.

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

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

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

 

Инженеры компании ALD по надежности программного обеспечения обладают опытом и знаниями для всех этапов и задач, необходимых для эффективной программы надежности программного обеспечения.

Мы можем помочь в выполнении или полностью взять на себя такие задачи по программе надежности, как:

 

• Распределение надежности

• Определение и анализ функциональных разрезов

• Подготовка и планирование тестирования

• Модели надежности программного обеспечения

 

Распределение надежности

 

Распределение надежности – это задача, которая определяет необходимую надежность того или иного элемента программного обеспечения. Элемент может быть частью интегрированного оборудования/программного обеспечения системы, а также более или менее независимым приложением или реже отдельной программой. В любых других случаях нашей целью является привести надежность системы либо в соответствии с жесткими требованиями заказчика либо с интуитивно понятным уровнем готовности, или же оптимизировать надежность в соответствии со сроками и затратами.

 

Компания ALD поможет Вашей организации в выполнении следующих задач:

 

• Выводить требования надежности программного обеспечения из требований надежности ко всей системе
• Когда возможно, в зависимости от этапа жизненного цикла и динамики изменений, оценить зависимость сроков и затрат от целей надежности программного обеспечения 
• Оптимизировать надежность/сроки/затрат в зависимости от ограничений и требований Вашего заказчика

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

 

Определение и анализ функциональных разрезов

 

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

 

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

 

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

 

Подготовка тестирования и планирование

 

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

 

• Оценка количества новых тестовых сценариев, необходимых для текущего выпуска
• Распределение новых тестовых сценариев по системам (если систем много)
• Распределение новых тестовых сценариев для каждой системы согласно новым операциям каждой системы
• Спецификация новых тестовых сценариев
• Добавление новых тестовых сценариев к уже существующим из прошлых выпусков

Модели надежности программного обеспечения

 

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

• График тестирования
• Распределение ресурсов тестирования
• Срок от начала разработки до выпуска на рынок
• Распределение средств ТОиР

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

 

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

 

Отказобезопасность программного обеспечения

 

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

 

А что если программное обеспечение не работает?

 

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

 

Критически важное для безопасности программное обеспечение

 

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

 

Что такое виды отказов программного обеспечения?

 

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

 

Некорректные входные данные могут быть вызваны:

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

 

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

 

Критически важное для безопасности программное обеспечение обычно тестируется на предмет отсутствия новых критических отказов. Конечно, это не значит, что в программном обеспечении абсолютно отсутствуют какие-либо ошибки, это означает, что ошибки не были обнаружены во время тестирования. Почему же ошибки, которые ведут к такого рода отказам, наблюдаются в тестировании? Эти ошибки могут не подвергаться тестированию по следующим причинам:

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

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

  

Как избежать таких ошибок, когда программное обеспечение уже выпущено?

 

Современные инструкции и стандарты программного обеспечения, если их сравнить с инструкциями и стандартами к оборудованию, не являются такими же понятными и подробными. Например, наиболее известный документ RTCA/DO-178B, документ Радиотехнической комиссии по аэронавтике по вопросам программного обеспечения бортовых систем и сертификации оборудования, последняя версия которого была выпущена в 1992, является главной инструкцией для разработки программного обеспечения с особыми требованиями по технической безопасности, но не рассматривает в частности типы отказов и как их избежать. Данный документ представляет в основном контроль процесса, что, конечно, только укрепит хорошее программное обеспечение. Однако этот документ не уточняет, как проверить, что процесс проходит достаточно хорошо для требований по той или иной системе. Долгожданное обновление к этому документу, DO-178C, было выпущено в 2011 году. В нем были предложены более регламентированные инструкции для сертификации критически важного для безопасности программного обеспечения. Они основываются не только на более точных расчетных условиях, таких как объектно-ориентированное проектирование, но и в общем на программом обеспечении на основе моделей и более современных формальных методах верификации.

 

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

 

Предварительный анализ опасностей/анализ функциональных опасностей программного обеспечения (PHA/FHA)

 

Распространенным препятствием для включения программного обеспечения в количественный анализ является недостаток данных об интенсивности отказов для его компонентов. Программное обеспечение может быть разработано таким образом, что допускается только определенное количество отказов. Если система имеет критическое значение для безопасности, то она будет допущена до эксплуатации только после обязательного тестирования, которое должно показать, что не осталось никаких дефектов в коде программного обеспечения (тем не менее, это не означает 100% надежности!). Любые оставшиеся источники отказов, связанных с программным обеспечением, могут быть результатом неполного определения требований, в частности, требований по редким и аномальным условиям, таким как отказы оборудования, редкие условия окружающей среды, условия эксплуатации и непредвиденные действия эксплуатантов. Зачастую сочетание множества редких событий может привести к условиям, к которым программное обеспечение не готово. Приблизительный уровень для таких событий может быть вычислен из количества и качества требований, но не может быть полностью проверен.

 

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

 

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

 

Компания ALD выполняет анализы FMEA программного обеспечения (и анализы FMEA системы, которая включает программное обеспечение), основой для которой является объектно-ориентированное проектирование. Чтобы выполнить данный анализ, ALD требуются следующие данные о разработке:

 

• Архитектура системы
• Документ с требованиями к системе
• Анализ опасностей системы и/или анализ деревьев отказов (может быть сгенерирован компанией ALD)
• Программа в объектно-ориентированной среде проектирования: может быть в форме UML, Matlab Simulink, или же кода в любом объектно-ориентированном языке (например, C++, .NET и др.)
• Данные по отказам оборудования
• Данные по ошибкам, которые вызваны человеческим фактором/эксплуатантом

 

Процесс FMEA в объектно-ориентированной среде обеспечивает исчерпывающее определение инициаторов исключительных ситуаций и гарантию того, что защита от ошибок в обработке исключительных ситуаций эффективна!

 

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

FMEA программного обеспечения - Как?

 

Одной из главных причин, почему анализ FMEA не вошел в состав требований к сертификации программного обеспечения, критически важного для безопасности, это сложность в его использовании для больших фрагментов кода. Компания ALD разработала методологию, которая преодолевает эту проблему с помощью использования объектного представления программы. Независимо от того, разработана ли модель UML или Matlab Simulink, или же имеется ли кодирование объектно-ориентированным языком, таким как C++, .Net или Java, мы применяем нашу методологию FMEA на объектном уровне.
Наряду с документами, содержащими требования, и документами по разработке мы можем создать анализ FMEA программного обеспечения, который будет удивительным образом походить на анализ FMEA оборудования, так как "методы объекта" программного обеспечения являются эквивалентами "компонентов" оборудования. Более того, когда потребуется, мы разработаем и создадим FMEA системы, который включает оборудование и программы, а также любые виды отказов их интерфейсов.
Наш метод борется и с другой характерной проблемой FMEA программного обеспечения, которой не могут избежать многие профессионалы – субъективность процесса. Большинство специалистов по отказобезопасности программного обеспечения применяют анализ FMEA на "функциональном" уровне. Данное применение не только проблематично в том, что оно может оставить без оценки целые секции кода исключения, но также привносит субъективность в процесс, что позволяет проигнорировать больше видов отказов. Наш объектно-ориентированный метод избавляется от этой субъективности, так как в нем используются классы, определенные при проектировании.

 

Автоматизированные анализы FMEA программного обеспечения

 

Анализы FMEA, которые используются для программного обеспечения или оборудования, представляют собой серьезную задачу. Анализы FMEA для оборудования автоматизированы через подробное иерархическое дерево системы, или же перечень материалов. Компания ALD разработала автоматизированные инструменты и методы для создания анализов FMEA программного обеспечения, которые основаны на предметно-ориентированных моделях. Наши инструменты способны автоматически создавать структуру FMEA для моделей на базе UML (универсальный язык моделирования) или в среде Matlab Simulink. Преимущества использования автоматизированных инструментов включают:
• Значительное снижение рабочей нагрузки (на несколько порядков)
• Уверенность в завершенности задачи (не будет пропущен ни один вид отказа)
• Библиотеки для будущего использования, которые еще больше сократят рабочую нагрузку (компоненты программного обеспечения и интерфейса, виды отказов, последствия более высокого порядка, методы обнаружения, методы и средства парирования)

Чего ожидать от услуг и инструментария FMEA программного обеспечения ALD?