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

ние целостности, в свою очередь, при- водит к тому, что требования, код и те- стовые сценарии «разъезжаются» на- столько, что ни самому понять, ни аудитору продемонстрировать. Грамот- но же поставленный и до возможной степени автоматизированный процесс управления изменениями обеспечит минимум усилий по формированию не- противоречивого пакета сертифика- ционных документов на каждой итера- ции. Одно это, по статистике компании LDRA [4], уже способно сократить тру- дозатраты в 10–15 раз. Подход с декомпозицией по уровням безопасности стал набирать вес в по- следнее время в свете растущей тенден- ции к объединению разнородных вы- числительных подсистем на единой ап- паратной платформе (с целью сокраще- ния массы, габаритов и потребляемой мощности). Поскольку к различным подсистемам при этом могут предъ- являться различные требования по без- опасности (как функциональной, так и информационной), в зарубежной тер- минологии для таких систем даже по- явился специальный термин – «систе- мы смешанной критичности» (mixed criticality systems). Казалось бы, решая одну аппаратную проблему, с точки зре- ния ПО такой подход создаёт другую: в общем случае объединение на одной аппаратной платформе нескольких программных приложений различного уровня безопасности потребовало бы сертификации по самому высокому из требуемых уровней. Однако на настоя- щий момент уже существуют техноло- гии, позволяющие разбить программ- ную систему на независимые разделы и сертифицировать ПО этих разделов по отдельности (мы к этому ещё вернём- ся). Как было показано ранее, с ростом требований к безопасности ПО объём необходимой сертификационной доку- ментации ощутимо растёт, но и критич- ного кода в системе обычно значитель- но меньше, чем некритичного, так что грамотное разбиение системы на разде- лы может дать существенную эконо- мию трудозатрат. Рассмотрим этот процесс подробнее, в частности, из чего состоит подлежа- щее сертификации ПО и где и как мож- но сэкономить. С ОСТАВ ПРОГРАММНОГО СТЕКА , И ЧТО ИЗ НЕГО СЛЕДУЕТ Программный стек в общем случае всегда выглядит одинаково (рис. 2). На самом верху располагается прикладное ПО, реализующее проектно-специ- фичную логику – это самая важная и самая изменчивая часть; всё остальное нужно, чтобы обеспечить её работу. Ниже прикладного ПО располагаются компоненты, обеспечивающие ему необходимые сервисы – аппаратно-не- зависимая часть ОС (или того, что иг- рает роль ОС) и так называемое свя- зующее ПО (СУБД, специфичные сте- ки протоколов и т.п.), реализующее сервисы, средствами ОС не предусмот- ренные. Связующее ПО использует сервисы ОС (распределение памяти, средства межзадачного взаимодействия и синхронизации, таймеры и т.п.) на- равне с прикладным. В самом низу рас- полагается аппаратно-зависимая часть ОС (так называемый пакет поддержки оборудования , board support package – BSP), которая отвечает за взаимодей- ствие ОС с аппаратными средствами (забегая вперёд, можно сказать, что между ОС и BSP в этой картине может располагаться ещё и гипервизор , но об этом чуть позже.) С точки зрения сертификации, самое главное в этой картинке – какие ком- поненты подвержены изменениям и с какой частотой, так как сертифика- ционную документацию для относи- тельно неизменных компонентов мож- но разработать один раз (а значит, не уделяя особого внимания автоматиза- ции), в то время как для изменчивых компонентов она будет постоянно кор- ректироваться – именно здесь и будет потрачено максимальное количество человеко-часов. Применительно к на- шей модели: ● прикладное ПО всегда специфично для конкретного проекта (хотя и мо- жет содержать унаследованный код), а также подвержено текучке требо- ваний, и поэтому меняется постоянно; ● пакет BSP всегда привязан к аппара- туре, и поэтому может быть специфи- чен для группы проектов, использую- щих одно и то же оборудование, то есть меняется редко; ● связующее ПО и аппаратно-незави- симая часть ОС могут применяться в различных проектах в коробочном ви- де, и поэтому в идеале не подвержены изменениям вообще (по крайней ме- ре, до выхода следующей версии, на которую имеет смысл переходить). Теперь посмотрим, какие есть вари- анты. «Р УЧНОЙ » ПОДХОД Самым распространённым подходом к разработке сертификационной доку- ментации (по крайней мере, в отече- ственной практике), к сожалению, яв- ляется разработка и сопровождение сертификационной документации для всего программного стека вручную. Этот подход способен дать значитель- ный выигрыш на первой итерации (осо- бенно притягательными для высшего менеджмента обычно кажутся нулевые подготовительные затраты), но, увы, только на первой, так как, что уже об- суждалось, программный проект никог- да не ограничивается одной итерацией. Каждое вносимое в проект изменение (особенно это касается уровня при- кладного ПО) будет требовать множе- ства связанных правок в пакете серти- фикационных документов. Это чревато не только катастрофическим разраста- нием трудозатрат по мере взросления проекта, но и нарушением целостности сертификационного пакета из-за на- копления человеческих ошибок, что не- избежно ведёт к проблемам в процессе подтверждения соответствия и в конеч- ном итоге к переделыванию всей рабо- ты заново. Единственная часть программного стека, где определённая доля ручной ра- боты не только оправданна, но и необходима, – это BSP. В частности, структурное тестирование BSP очень трудно поддаётся автоматизации, так как выполнение аппаратно-зависимого кода жёстко привязано к временныˆм характеристикам оборудования, и ин- струментирование такого кода в авто- матическом режиме может сделать его неработоспособным. К УПИТЬ НЕЛЬЗЯ ПОСТРОИТЬ : ПРИМЕНЕНИЕ СЕРТИФИЦИРОВАННЫХ И СЕРТИФИЦИРУЕМЫХ КОМПОНЕНТОВ Одним из способов сократить трудо- затраты по созданию и сопровождению сертификационной документации яв- ляется применение коммерческих (Com- ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ 61 СТА 2/2015 www.cta.ru Рис. 2. Структура программного стека в контексте сертификации Меняется постоянно Меняется редко Меняется периодически Прикладное ПО Связующее ПО ОС BSP Оборудование