ЖУРНАЛ СТА 4/2014

строятся базовые понятия функцио- нальной безопасности) появился не так давно. При этом традиционным прове- ренным аппаратом оценки качества всегда была классическая теория на- дёжности, и это даёт соблазн распро- странить привычные методики на ин- дустриюПО. Однако на поверку оказы- вается, что не всё так просто. Согласно ГОСТ Р 27.002-2009, на- дёжность сама по себе не является ко- личественным показателем и опреде- ляется готовностью , которая, в свою очередь, зависит от безотказности и ре- монтопригодности : ● Надёжность (dependability) – свойство готовности и влияющие на него свой- ства безотказности и ремонтопригод- ности и поддержка технического об- служивания. • Готовность (availability) – способ- ность изделия выполнить требуе- муюфункцию при данных условиях в предположении, что необходимые внешние ресурсы обеспечены. • Безотказность (reliability) – способ- ность изделия выполнить требуе- мую функцию в заданном интерва- ле времени при данных условиях. • Ремонтопригодность (maintainabi- lity) – способность изделия при данных условиях использования и технического обслуживания к под- держанию или восстановлению со- стояния, в котором оно может вы- полнить требуемую функцию (ГОСТ Р 27.002-2009). Выражение «при данных условиях» в определении готовности подчёркнуто не зря – здесь таится один важный подвод- ный камень. Классическая теория надёж- ности относится к отказу как к случайно- му событию и поэтому использует мате- матический аппарат теории вероятно- стей. Однако, кроме случайных отказов, бывают ещё отказы систематические , то есть гарантированно повторяющиеся при определённой (зачастую очень сложной и поэтому редкой) комбинации условий (см. тот же ГОСТ Р 27.002-2009). Такие отказы нельзя описывать количествен- ными статистическими показателями (по крайней мере, пока Нассим Талеб [1] не добрался до теории надёжности), так как при одних условиях они не возникают во- обще, а при других возникают всегда. Та- ким образом, при внесении в рассмотре- ние систематических отказов показатели надёжности перестают быть однозначны- ми, и к статистическому анализу добав- ляется необходимость тестирования в различных условиях. Хорошимпримером систематического отказа является авиационное происше- ствие с рейсом № 38 компании British Airways 17 января 2008 года, когда абсо- лютно исправный Boeing 777, успешно преодолев дистанцию в 8100 км между Пекином и Лондоном, при заходе на по- лосу аэропорта Хитроу внезапно потерял тягу обоих двигателей и совершил ава- рийную посадку в 270 метрах от взлётно- посадочной полосы. Расследование по- казало, что к происшествию привела сложная причинно-следственная цепоч- ка: сначала длительный крейсерский по- лёт на большой высоте над холодной тер- риторией (температура топлива упала до –30°C, и в нём образовалась взвесь ле- дяных кристаллов), потом резкое сниже- ние (топливо «прогрелось» до –20°C, ад- гезивность ледяной взвеси резко возрос- ла, и лёд нарос на стенках топливопрово- дов), а затем–попадание в турбулентный поток (автомат тяги резко увеличил по- дачу топлива, и перепад давления в топ- ливопроводах единовременно смыл лёд со стенок, ледяная пробка закупорила топливо-масляный теплообменник, и двигатели лишились топлива на высоте 200 метров над землёй). Как описать та- кое в терминах теории вероятностей? Ситуация усугубляется тем, что клас- сический метод борьбы со случайными отказами – резервирование – от систе- матических отказов не только не спасает, но и ухудшает ситуацию, приводя к так называемым отказам по общей причине (common cause failures). Такие отказы проявляются во всей резервированной схеме одновременно, потому что если нагруженные и резервные модули реа- лизованы одинаково, они будут подвер- жены действию одних и тех же событий- инициаторов – trigger events. (В описан- ном случае с рейсом № 38 резервирова- ние топливо-масляного теплообменни- ка, очевидно, не спасло бы ситуацию.) Вероятность таких отказов можно сни- зить, реализуя разные модули резерви- рованных схем разными коллективами разработчиков и на основе различных принципов, методов и технологий, что- бы исключить совпадение событий- инициаторов. Это, впрочем, не отменяет необходимости тестирования. Пример с системным отказом оборудо- вания приведён здесь не случайно – си- туация с «надёжностью»ПОпредставляет собой ещё более полярный случай. Дело в том, чтоПО–это алгоритм , а в работе ал- горитма вообще не бывает случайных со- бытий, он детерминирован. Поэтому ис- пользование термина «надёжность» при- менительно к ПО (например, ГОСТ 28806-90 хоть и признаёт особуюприроду отказовПО, но всё равно применяет к не- му термин «надёжность») зачастую толь- ко вносит путаницу и создаёт соблазн спросить про численные показатели, ко- торые к характерным для ПО системати- ческим отказам неприменимы. Качество алгоритма определяется де- тальностью его проработки, а значит, степенью понимания исходной задачи и корректностью донесения этого понима- ния до реализации. Процессы/потоки и примитивы синхронизации в многоза- дачной операционной системе (ОС) не меняют своё состояние под воздействи- ем случайных факторов, значения пере- менных не изменяются сами собой (при условии исправности аппаратуры, разу- меется) и т.д. Как результат вероятност- ный анализ может быть применим толь- ко к аппаратуре, на которой выполняет- ся ПО, но не к самому ПО. Все отказы ПО являются систематическими , и для борьбы с ними годятся только системные средства; множество хороших иллюстра- ций к этому утверждению приводится в статье Нэнси Левесон «О роли ПО в ка- тастрофах космических аппаратов» [2], опубликованной в 2004 году. Статья не- двусмысленно демонстрирует, как недо- статки в системной культуре безопасно- сти привели к критическим отказам про- граммного обеспечения и, как следствие, провалу пяти космических миссий NASA/ESA в период с 1996 по 1999 годы. Н О ЕСЛИ НЕ « НАДЁЖНОСТЬ », ТО ЧТО ТОГДА ? В последнее время в англоязычной ли- тературе часто употребляется словосоче- тание «функционально безопасное ПО» (safe software). При этом в ответ на пря- мой вопрос эксперты обычно признают, что этот термин не совсем корректен, по- скольку функционирование программ- ных компонентов явного риска в себе не несёт, и поэтому они не могут быть опас- ными или безопасными. Однако, будучи некорректно реализованным или некор- ректно применённым , программный ком- понент (как и любой другой) может стать причиной (или звеном в цепочке при- чин) опасного отказа системы с соответ- ствующими последствиями. Это важныймомент, так как он отвеча- ет на вопрос, почему «функционально безопасное» ПО не всегда является сер- тифицированным. Функциональная без- опасность определена только для объ- ектов, функционирование которых несёт в себе риск, а риск обретает конкретные ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ 33 СТА 4/2014 www.cta.ru