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

формы только на уровне либо системы в целом (например, химического про- изводства или летательного аппарата), либо законченного функционального блока (например, двигателя). Поэтому сертифицируется либо вся система, либо законченный функциональный блок (и то последняя практика существует только в авиации), а компоненты (вклю- чая ПО) подготавливаются к сертифика- ции , то есть разрабатываются в соответ- ствии с нормативными требованиями, позволяющими применять их в системах с заданным уровнем функциональной безопасности, и снабжаются соответ- ствующимпакетомподтверждающих до- кументов (так называемым сертифика- ционнымпакетом– certification evidence). Последнее утверждение может вы- звать справедливый скепсис – множе- ство современных производителей обо- рудования и ПО заявляют свои продук- ты как безопасные и в подтверждение этому демонстрируют официальные сертификаты (скажем, по МЭК 61508 SIL 4). Казалось бы, собрал систему из компонентов, имеющих сертификат, и вуаля. Однако здесь есть нюанс: уровень безопасности, по которому сертифици- руется компонент, определяется по фор- мальной методике для «сферического компонента в вакууме», то есть физиче- скому смыслу интегрального уровня безопасности (SIL – Safety Integrity Le- vel) на самом деле не соответствует. Это как со средним временем наработки между отказами (MTBF) – знание его значений для каждого из компонентов ещё ничего не гарантирует, так как ко- нечные характеристики результирую- щей системы будут определяться тем, как именно она из этих компонентов будет составлена. Поэтому сам по себе сертификат говорит только о факте со- блюдения производителем методологии , предусмотренной стандартом, вопросы же интеграции раскрываются в прила- гаемом к сертификату «Руководстве по безопасности» (Safety Manual), описы- вающем, как именно этот компонент обязан интегрироваться в систему, что- бы она оставалась безопасной. Чтобы подчеркнуть разницу между компонентами, имеющими сертификат (это, повторюсь, допускается не любым стандартом), и компонентами, пригодны- ми для сертификации , для их обозначения используют разные термины– « сертифи- цированный » (certified) и « сертифицируе- мый » (certifiable) соответственно. (По- следнее, кстати, является подмножеством первого, так как чтобы сертифицировать компонент, сертификационный пакет к нему разрабатывать в любом случае при- дётся.) В целом вопрос о том, имеет ли смысл сертификат безопасности, выдан- ный на компонент (как аппаратный, так и программный) вне контекста системы, до сих пор является предметом «священ- ных войн»: с одной стороны, использова- ние сертифицированных компонентов призвано сократить стоимость сертифи- кации всей системы, с другой, –какмож- но учесть все возможные сценарии ин- теграции в «Руководстве по безопасно- сти», не совсем понятно. Как бы там ни было, с сертификатом или без, сам по себе подход к качеству ПО, с точки зрения аппарата функцио- нальной безопасности позволяет решить сразу две проблемы. Во-первых, прове- дение анализа рисков (см., например, РД 03-418-01 «Методические указания по проведению анализа риска опасных про- изводственных объектов») означает мо- делирование всех возможных причинно- следственных связей, способных приве- сти к отказу. В результате фактически получаются «антитребования» – в отли- чие от требований, описывающих, что и как система должна делать, анализ рис- ков даёт информацию о том, что и как она делать не должна и что произойдёт в противном случае. Будучи детализиро- ванными до уровня компонентов систе- мы, эти «антитребования» дают необхо- димую основу для проектирования и те- стирования. На более поздних этапах жизненного цикла могут выявляться до- полнительные нюансы, не учтённые в изначальном анализе рисков, но при корректно поставленном процессе раз- работки это даёт необходимую обратную связь, и качество компонентов со време- нем повышается. Во-вторых, анализ рисков автомати- чески даёт ранжирование возможных от- казов по степени критичности, а значит, и адекватно распределяет усилия по си- стемному противодействию. Очевидно, что избежать всех возможных отказов нельзя, а избыточные меры контроля сделают процесс разработки нерента- бельным; ранжирование отказов позво- ляет сосредоточить усилия на обеспече- нии корректности наиболее критичных программных модулей и тем самым соб- люсти баланс между корректностью программного кода и операционными затратами. Разумеется, чтобы всё это работало, необходима соответствующая инфра- структура. Необходимо, чтобы требова- ния были задокументированы, доступны и проверяемы, а неизбежные изменения в них отрабатывались корректно. Не- обходимо, чтобы требования корректно и своевременно отображались в про- граммный код и соответствующие тесто- вые сценарии. Все проектные докумен- ты (не только код) должны архивиро- ваться в системе управления версиями, чтобы ничего не потерялось и всегда можно было обратиться к любой версии любого документа. В процессе кодирова- ния необходимо соблюдать «правила ги- гиены», помогающие сделать код тести- руемым, сопровождаемым и избежать скрытых ошибок (например, связанных с интерпретацией синтаксиса языка или использованием спорных техник про- граммирования). Всему этому необходи- мо обучать персонал. И так далее. Всё это входит в понятие «культура безопасно- сти» и реализует комплексный подход к обеспечению качества ПО; конкретные требования могут отличаться в зависи- мости от целевой индустрии и приводят- ся в соответствующей отраслевой норма- тивной базе (об этом см. далее). Некоторые производители ПО для безопасных применений идут ещё даль- ше и добавляют в свои продукты допол- нительные средства обеспечения отказо- устойчивости (например, подсистемы Error Detection &Reporting в ОС VxWorks и High Availability Framework в ОС QNX Neutrino), что позволяет дополнительно упростить реализацию функций без- опасности, в частности, обнаружение и обработку отказов. Подробнейший терминологический и методологический разбор темы функ- циональной безопасности приводится в [3], к сожалению, правда, в данной (пре- красной, к слову) работе теме ПО уделе- но непропорционально мало внимания. О ДНО НЕ МОЖЕТ БЕЗ ДРУГОГО Инцидент с иранской ядерной про- граммой и «червём» Stuxnet наглядно продемонстрировал, что проблемыфунк- циональной и информационной безопас- ности нельзя рассматривать в изоляции друг от друга, так как в современном ми- ре тесно связанных информационных си- стем брешь в информационной безопас- ности легко способна привести к нару- шению безопасности функциональной. Например, в случае с тем же Stuxnet уязвимость в системе информационной безопасности завода по обогащению ура- на привела к тому, что вредоносный код проник в цеховой контроллер АСУ ТП, а оттуда – в программируемый логический контроллер (ПЛК), управлявший цен- 34 СТА 4/2014 ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ www.cta.ru