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

будет использоваться руками, потому что, как известно, чем круче джип, тем дольше идти за трактором. Иными сло вами, соблазн сделать выбор побыст рее, чтобы сразу приступить к делу, всегда чреват необходимостью иметь дело с последствиями этого выбора на протяжении всей жизни проекта. Рациональный выбор всегда слож нее, потому что чёрт, как известно, кроется в деталях, а деталей в техниче ских системах много. Но и это ещё не всё: чтобы оценить применимость про дукта в той или иной задаче, нужно не просто знать его характеристики, но и выразить их в терминах поставленного технического задания (ТЗ), потому что иначе получается «в огороде бузина, а в Киеве дядька». Настоящая статья под ходит к выбору ОС «от задачи», пред полагая, что в наличии имеются следу ющие исходные данные: ● требуемые характеристики систе мы/изделия; ● необходимые технологии; ● готовые наработки и опыт, имеющи еся у компании разработчика; ● выбранное оборудование; ● целевой рынок системы/изделия; ● экономические ограничения проекта. В каждой группе выделяются изме римые (а значит, позволяющие произ вести сравнение) характеристики ОС, влияющие на конечный выбор, и при водится несколько конкретных иллю страций. В качестве примеров встраи ваемых ОС, доступных для выбора, ис пользуются: ● VxWorks и Wind River Linux американ ской компании Wind River; ● QNX канадской компании QNX Software Systems; ● Windows Embedded Standard и Windows Embedded Compact амери канской корпорации Microsoft; ● RTOS 32 немецкой компании On Time Informatik. Итак, пойдем по порядку. В ЫБОР ОС И ТРЕБУЕМЫЕ ХАРАКТЕРИСТИКИ СИСТЕМЫ Для любой системы существуют кри терии качества, которым она должна соответствовать, чтобы успешно вы полнять свою задачу. Критерии эти в различных случаях индивидуальны и могут включать в себя пропускную способность, допустимое время вне планового простоя, параметры удобст ва интерфейса, скорость обработки внешнего события и т.п. Это измери мые величины, которые прописывают ся в ТЗ и контролируются на приёмо сдаточных испытаниях; возможность их обеспечить тесно связана с техни ческими характеристиками используе мой ОС. Со стороны ОС в число заяв ляемых производителями характерис тик обычно входят: ● архитектурные принципы (тип ядра и планировщика, модель многоза дачности и т.п.); ● временны6 е характеристики (время реакции на прерывание, время пе реключения контекста, время пере планирования и т.п.); ● поддержка реального времени («жёст кое», «мягкое» или отсутствует); ● показатели надёжности (например, среднее время восстановления после отказа); ● метрики производительности (на пример, пропускная способность файловой системы на заданном но сителе). Все эти показатели могут использо ваться для оценочных расчётов конеч ных свойств системы, причём полез ными здесь могут оказаться не только численные характеристики, но и об щие архитектурные принципы, потому что многие свойства ОС непосред ственно вытекают из её архитектуры (как принято говорить у химиков, строение определяет свойства). К примеру, чтобы оценить, справит ся ли система с расчётной нагрузкой, нужно обращать внимание на время реакции и метрики производительно сти ОС, а также на их детерминирован ность, поскольку обработать событие быстро – это одно дело, а обработать его вовремя – совсем другое. Если в ис ходной задаче жёстко регламентирова но максимальное время отработки внешнего события, то для решения за дачи необходима ОС «жёсткого» реаль ного времени, временны6 е характе ристики которой детерминированы; в противном случае можно обойтись ОС «мягкого» реального времени или ОС общего назначения. Примечатель но, что по результатам опросов в боль шинстве проектов от ОС требуется ли бо очень медленная (от единиц мс), ли бо, наоборот, очень быстрая (до десят ков мкс) реакция (рис. 2). Аналогично, когда речь идет об оценке надёжности, следует иметь в виду, что надёжность программной системы складывается из двух основ ных составляющих: ● безотказности; ● отказоустойчивости. Безотказность, в свою очередь, скла дывается из безотказности как самой ОС, так и прикладного кода, а значит, зависит не только от ОС, но и от при нятого для нее инструментария прик ладного программирования (чем со вершеннее инструментарий разработ ки, отладки и диагностики, тем больше у разработчика возможностей написать код с минимальным количеством де фектов). К факторам, определяющим безотказность, можно также отнести используемый в ОС механизм защиты от проблемы инверсии приоритетов, которой страдают все ОС с вытесняю щим планировщиком, – если ОС не умеет корректно обрабатывать ситуа цию инверсии приоритетов, то некор ректно спроектированное взаимодей ствие программных компонентов мо жет стать причиной потери детермини рованности, что в системах жёсткого реального времени зачастую ведёт к ка тастрофе. Что касается отказоустойчивости, то здесь большую роль играет архитектура ОС. В частности, ОС на основе микро ядра считаются более отказоустойчи выми за счёт того, что в кольце ядра (а значит, с расширенными привилеги ями) выполняется только критический системный код; аналогично, повышен ную отказоустойчивость обеспечивают защита памяти и другие механизмы ОБ ЗОР / В С Т РАИВ А ЕМЫЕ СИС Т ЕМЫ 23 СТА 2/2011 www.cta.ru Рис. 2. Технические требования к времени реакции на прерывание для текущего проекта (% респондентов, по данным опроса VDC за 2010 год) 0 10 20 30 Менее 10 мкс 11–49 мкс 51–99 мкс 101–249 мкс 251–499 мкс 501–999 мкс 1 и более мс Нет информации 17,3% 14,1% 9,4% 9,4% 3,9% 4,7% 25,5% 15,7% © СТА-ПРЕСС