ЖУРНАЛ «СТА» №4/2007

новать прикладные программы одного поставщика, стеки протоколов — дру- гого, операционную систему реального времени — третьего и встраиваемую ба- зу данных — четвёртого. Затем интегра- тор должен объединить эти компонен- ты с многочисленными программными подсистемами внутренней разработки, которые написаны разными группами разработчиков. На рис. 1 показаны не- которые из многочисленных программ- ных компонентов, которые может включать в себя такая система. При использовании параллельных процессов проектирования неизбежно возникают проблемы с производитель- ностью на стадии интеграции, когда различные подсистемы впервые начи- нают конкурировать друг с другом за процессорное время и другие систем- ные ресурсы. Подсистемы, которые хо- рошо работали в отдельности, реагиру- ют медленно или не реагируют вообще. К сожалению, многие из таких проблем проявляются только во время интегра- ции и проверочных испытаний, когда затраты на повторное проектирование и кодирование программного обеспече- ния максимальны. Чтобы обеспечить безопасное функ- ционирование системы и успешную ин- теграцию её программных подсистем, интегратор должен реализовать архи- тектуру, которая не позволяет компо- нентам и подсистемам повреждать и монополизировать компьютерные ре- сурсы (например, память и процессор- ное время), необходимые другим под- системам. Теоретически интеграторы могли бы достичь этой цели с помощью технологии аппаратного объединения  подхода, в котором каждая программ- ная подсистема или группа подсистем работает на отдельной плате или узле. Такой подход способен локализовать сбои и снизить конкуренцию за сов- местно используемые ресурсы. Тем не менее в военных системах существует тенденция к увеличению объёма функ- циональности, интегрируемой в устрой- ство. Это не только снижает затраты («чем меньше устройств, тем дешевле»), но и сводит к минимуму вес и энергопо- требление системы. Б ЕЗОПАСНЫЕ РАЗДЕЛЫ Для того чтобы решить проблемы безо- пасности и интеграции, некоторые архи- тектуры помещают группы программных процессов в виртуальные разделы, или блоки , каждому из которых выделяется заранее определённое множество ресур- сов, в том числе процессорное время (рис. 2). Таким образом система не по- зволяет процессам, которые находятся в какомлибо блоке, непреднамеренно или злоумышленно монополизировать ре- сурсы, необходимые процессам в других блоках. Многие системы обороннокос- мической промышленности, использую- щие технологию объединения, соответ- ствуют спецификации ARINC 653, кото- рая обеспечивает хорошо известный, хо- тя и несколько жёсткий и неэффектив- ный подход к объединению ресурсов. Среди других возможностей блоков приложений — защита памяти в опера- ционных системах, которые управляют доступом ко всей памяти с помощью диспетчера памяти. Например, опера- ционная система на основе микроядра может разделить приложения, драйверы устройств, стеки протоколов и файло- вые системы на отдельные процессы с защищённой памятью. Если какойлибо процесс, такой как драйвер устройства, попытается осуществить доступ к памя- ти, находящейся за пределами своего контейнера, диспетчер памяти уведомит об этом операционную систему, которая затем сможет завершить процесс и пере- запустить его. Этот подход обеспечивает прямое и значительное улучшение надёжности системы: ● не позволяет ошибкам в коде одного процесса повреждать другие процес- сы и ядро операционной системы; ● даёт разработчику возможность быст- ро обнаруживать, диагностировать и исправлять нарушения, локализация которых другими методами может за- нимать несколько недель; ● значительно сокращает время после- аварийного восстановления: в случае нарушения памяти система может вме- сто перезагрузки просто перезапустить процесс, который вызвал сбой. Г АРАНТИЯ ДОСТУПНОСТИ РЕСУРСОВ Тем не менее для создания надёжной системы требуется не только распреде- лить функциональность по отдельным областям памяти. Для многих систем критически важно гарантировать до- ступность ресурсов. Если лишить клю- чевую подсистему процессорных цик- лов, то службы, которые она предостав- ляет, окажутся недоступными пользова- телям. Например, при атаке на отказ в обслуживании внешняя система может бомбардировать устройство запросами, которые должны обрабатываться высо- коприоритетным процессом. Затем этот процесс перегружает процессор и лиша- ет другие процессы процессорных цик- лов, делая систему непригодной для ис- пользования. Кроме того, во многих случаях добав- ление программной функциональности в систему способно «переполнить» её и отнять процессорное время у сущест- вующих приложений. Исторически единственным решением этой пробле- мы была модификация оборудования или перепроектирование программного обеспечения. П ЛАНИРОВЩИКИ С ФИКСИРОВАННЫМ ОБЪЕДИНЕНИЕМ Для разрешения описанных проблем в некоторых операционных системах ис- пользуется планировщик с фиксирован- ным объединением, который обычно ос- нован на спецификации ARINC 653 и позволяет системному разработчику объ- единять процессы в блоки и выделять до- лю процессорного времени каждому бло- ку. При таком подходе ни один процесс не может израсходовать больше процес- сорного времени, чем статически выде- лено его блоку (например, 20 процентов). Тем не менее планировщики с фикси- рованным объединением имеют свои недостатки. Поскольку алгоритм пла- нирования является фиксированным, блоки, которые не выполняют работу, простаивают в течение выделенных им процессорных циклов. В это время дру- гие блоки не могут получить доступ к П Р О Г РАММНО Е ОБ Е С П Е Ч Е НИ Е / СИС Т ЕМЫ Р Е АЛ Ь НО ГО В Р ЕМЕ НИ 73 СТА 4/2007 www.cta.ru Рис. 2. Группировка программных процессов в виртуальные разделы и передача управляющих воздействий от ядра по шине передачи сообщений