ЖУРНАЛ СТА 3/2015

5. По мере разработки тестовых сцена- риев они привязываются к требова- ниям, реализацию которых призваны демонстрировать, и коду, который их реализует. Это формирует матрицу трассировки. 6. Результаты выполнения процедур контроля качества и матрица трасси- ровки экспортируются в форматиро- ванный отчёт. 7. Отчёт вставляется в шаблон соответ- ствующего сертификационного доку- мента. 8. Заполненные шаблоны сертифика- ционной документации сохраняются в системе контроля версий, откуда их впоследствии сможет забрать система управления взаимодействием с оцен- щиком. В роли системы управления требова- ниями может выступать, например, DOORS, в роли системы контроля вер- сий – Perforce или Subversion (SVN), в роли инструментария V&V – LDRA Tool Suite, а в роли системы управления взаимодействием с оценщиком – LDRA Certification Management System (LCMS). Шаблоны сертификационной документации входят в поставку LCMS, поэтому вопрос в этом случае решается автоматически. Требуемая конфигура- ция LDRA Tool Suite будет определять- ся тем, по какому стандарту и на какой уровень проводится сертификация. В реальном мире начальные условия могут, мягко выражаясь, отличаться от представленных (всем, наверное, дово- дилось восстанавливать спецификации по коду), как результат, первой реакци- ей на план работ по сертификации ча- сто является безотчётное желание один раз сделать всё вручную и забыть, как страшный сон. Однако первые две-три ручные итерации, как правило, ставят всё на свои места и убеждают в том, что принятая методология разработки без- опасного ПО – не прихоть полубога, а ценный способ при внесении очеред- ного изменения не забыть одну какую- нибудь небольшую, но критическую деталь. Ч ТО ДАЛЬШЕ ? Инновационность и безопасность всегда находятся в противовесе – без инноваций невозможно двигаться впе- рёд, но без безопасности инновации были бы колоссом на глиняных ногах. За последние годы маятник техниче- ского прогресса ощутимо качнулся в сторону инноваций, и технологии без- опасности изо всех сил стараются не от- ставать, чтобы сохранить баланс. По- пробуем, суммировав всё сказанное, вкратце обрисовать текущее положение и возможную перспективу. Во-первых, то, что требования совре- менных стандартов функциональной и информационной безопасности к каче- ству ПО на текущий момент фактиче- ски аналогичны и привязаны к управ- лению рисками, говорит о том, что ме- тодики контроля качества наконец-то не только устоялись, но и вышли на си- стемный уровень. Одновременно с этим развитие сетевых технологий и увеличе- ние степени связности устройств (в том числе составляющих элементы крити- ческой инфраструктуры) привело к то- му, что задачи функциональной и ин- формационной безопасности переста- ли рассматриваться по отдельности. Та- ким образом, сейчас уже есть все пред- посылки для выработки единой систе- мы приоритетов между задачами функ- циональной и информационной без- опасности и создания объединённого подхода к управлению рисками. На ба- зе этого подхода может быть разработа- на единая нормативно-техническая ба- за, которая бы позволила производить интегральную оценку функциональной и информационной безопасности по единой системе методик и в рамках еди- ной системы профилей. Во-вторых, растущий объём кодовой базы критичных систем заставляет ис- кать способы снижения трудозатрат на обеспечение качества кода, в частности, разделять приложения по уровням без- опасности и вкладывать усилия про- порционально жёсткости требований. Это невозможно сделать без соответ- ствующей поддержки со стороны ОС, и производители ОС отвечают на этот вы- зов: число проектов интегрированной модульной авионики на базе совмести- мых с ARINC 653 ОС сегодня в мире ис- числяется сотнями, и проекты MILS- систем на базе соответствующих ОС то- же набирают обороты. По мере того как требования функциональной и инфор- мационной безопасности будут объеди- няться, следует ожидать появления ОС для систем смешанной критичности, способных удовлетворить объединён- ным требованиям. Пол Паркинсон [3] считает, что в борьбе за это место у ОС с MILS-архитектурой шансов больше, так как совместимые с ARINC 653 IMA- ориентированные ОС допускают реали- зацию драйверов в пространстве ядра, да и размер кода их ядра слишком ве- лик. В подтверждение этих слов, кста- ти, компания Wind River недавно анон- сировала для своей ОС VxWorks MILS 3.0.0.1 сертификационные пакеты по МЭК 15408 (профиль защиты SKPP [4] и DO-178C одновременно). В-третьих, в то время как наступле- ние многоядерных процессоров уже происходит по всем фронтам, не все аспекты их безопасности на настоящий момент достаточно изучены (как ре- зультат, все существующие на текущий момент безопасные проекты на базе многоядерных процессоров либо содер- жат существенные оговорки, либо ис- пользуют только одно ядро). Исследо- вания на эту тему активно ведутся, и по мере получения результатов будут по- являться нормативно закреплённые ре- комендации по архитектуре как самих многоядерных процессоров для без- опасных применений, так и ОС для них. Тот же Пол Паркинсон считает, что с точки зрения ОС наибольшим потен- циалом для развития в этом направле- нии обладают MILS-ориентированные архитектуры на основе гипервизора, ис- пользующие вычислительные ядра в ре- жиме AMP. Это, в свою очередь, от- кроет путь для активного развития мас- штабируемых систем смешанной кри- тичности с объединёнными требова- ниями к функциональной и информа- ционной безопасности. З АКЛЮЧЕНИЕ Фантасты не ошибаются. В то время как мы смотрим в кино «Терминатора» и «Матрицу» и думаем, что это не про нас, количество программного обес- печения, которое ведёт себя не совсем так, как от него ожидается, непрерывно растёт, в том числе и в ответственных приложениях. По мере того как вычис- лительные технологии всё глубже про- никают в нашу повседневную жизнь, всё больше когда-то простых и понят- ных вещей начинают зависеть от каче- ства программного кода. Учитывая, ка- кими темпами в последние десятилетия растёт объем этого кода [5], не стоит удивляться, что твоему сотовому теле- фону однажды могут понадобиться твоя одежда и мотоцикл. Шутки шутками, но в упомянутой статье Нэнси Левесон [6] есть одна тре- вожная фраза: «Программные техноло- гии открывают путь к созданию систем настолько сложных, что их поведение становится невозможно контролиро- вать». Это было написано в 2004 году; за прошедшее с того момента время объём кода встраиваемых приложе- 40 СТА 3/2015 ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ www.cta.ru