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

ря – POSIX и Win32. (Естественно, поскольку не все тонкости программи рования удачно описаны в стандартах, везде существуют свои частнофирмен ные расширения, но основа почти всегда строится либо на POSIX, либо на Win32.) Соответственно, например, если большинство наработок предпри ятия написано с использованием POSIX API (скажем, в среде настоль ной Linux), то перенести кодовую базу на POSIX совместимую встраиваемую ОС (QNX, VxWorks, Wind River Linux) будет намного проще; аналогично дело обстоит с проектами, реализованными с использованием Win32 API. Кроме API, при выборе ОС будет также играть роль, хоть и меньшую, на бор поддерживаемых для неё средств разработки: компиляторов, отладчи ков, интегрированных сред, диагнос тического инструментария, средств ви зуального моделирования и т.п. Один и тот же инструмент может поддержи вать несколько целевых ОС, но ни один не поддерживает все сразу; из то го, какие средства разработки доступ ны, можно понять, как для данной ОС можно разрабатывать (или переносить) код. Большинство средств разработки для POSIX совместимых встраиваемых ОС базируется на линейке GCC и плат форме Eclipse; в Win32 разработка ве дётся преимущественно в Microsoft Visual Studio. Здесь, как и в случае с API, играет роль простой принцип: что привычнее, то не потребует длительно го переучивания, а значит, позволит быстрее начать продуктивную деятель ность, плюс, если кодовая база написа на не на С/С++ (эти языки наиболее популярны во встраиваемых приложе ниях и широко поддерживаются), нуж но иметь в виду наличие для выбирае мой встраиваемой ОС соответствую щего транслятора. Примеры выбора встраиваемой ОС с сохранением имеющихся наработок (табл. 1) Пример 5. Согласно ТЗ интерфейс оператора системы реализован в SCADA приложении GENESIS32 (без web компонентов). Необходимо обес печить работу этого интерфейса во встраиваемой среде. GENESIS32 суще ствует только для Windows; соответ ственно, во встраиваемом приложении ему будет необходима ОС Windows Embedded Standard. Пример 6. Алгоритмы, требуемые для работы изделия, были разработаны и отлажены в среде настольной Linux; необходимо пере нести их во встраи ваемую вычисли тельную систему. Применительно к выбору встраивае мой ОС это означа ет поддержку POSIX API с Linux специ фичными расшире ниями при минимальной ресурсоём кости; лучше всего в данном случае подходит ОС Wind River Linux. В ЫБОР ОС И ОБОРУДОВАНИЕ В большинстве проектов оборудова ние выбирается первым, поскольку именно от его характеристик зависит физическая возможность реализации поставленной задачи (это подтвержда ется результатами опросов – рис. 3). Таким образом, на момент принятия решения о выборе ОС список оборудо вания обычно уже известен, что позво ляет сразу оценить, во первых, требуе мую ресурсоёмкость ОС, а во вторых, объём работ по её адаптации (они мо гут включать в себя разработку драйве ров, BSP, а при необходимости и пор тирование ядра). Совместимость ОС с оборудованием складывается из трёх факторов: ● совместимость на уровне архитекту ры процессора; ● совместимость на уровне перифе рийных устройств; ● требуемый объём ресурсов (то есть необходимая вычислительная мощ ность и объём занимаемой памяти). Обеспечение совместимости на уровне процессора требует глубокой переработки ядра ОС, поэтому список поддерживаемых процессоров обычно заявляется производителем ОС как данность и меняется редко. Обеспече ние поддержки периферийных уст ройств сопряжено с гораздо меньшим количеством трудностей, и наряду с пакетом готовых драйверов и пакетом поддержки процессорных плат (Board Support Package – BSP), которые вхо дят в дистрибутив ОС, производители обычно в том или ином виде предо ставляют инструментарий для их само стоятельной разработки. Разумеется, поскольку у каждой ОС своя архитек тура, то и подход к разработке и отлад ке драйверов и BSP у каждой ОС будет разным; чем этот подход проще и про зрачнее, тем быстрее можно адаптиро вать ОС к требуемой аппаратуре. При этом, естественно, не надо забывать, что ОС должна «влезать» в предостав ленные ей объём памяти и вычисли тельную мощность, так как в условиях недостатка ресурсов совместимость не имеет смысла. Таким образом, при выборе встраи ваемой ОС для имеющегося оборудо вания нужно обращать внимание на следующие её характеристики: ● список поддерживаемых процессор ных архитектур; ● заявленную ресурсоёмкость; ● список поддерживаемых перифе рийных устройств и готовых BSP; ● архитектуру и методику разработки драйверов и BSP; ● наличие и состав предлагаемых комплектов разработки драйверов и BSP; ● доступность технической поддержки и сервисов разработки драйверов и BSP на заказ. Первые три пункта описывают сов местимость «из коробки», последние три – возможность произвести адапта цию ОС, если совместимость «из ко робки» окажется недостаточной. Примеры выбора встраиваемой ОС под заданное оборудование (табл. 1) Пример 7. Разрабатываемое устрой ство представляет собой беспроводную IP камеру видеонаблюдения; выбран ный процессор – Freescale MCF54455. Данный процессор относится к семей ству ColdFire и поддерживается только ОС VxWorks. Пример 8. Выбранное оборудование позволяет выделить программному обеспечению не более единиц Мбайт ОЗУ. Расчёт показал, что из них для ОС будет доступно порядка 300 кбайт. В та ких объёмах ОЗУ способны работать только ОС VxWorks или RTOS 32. В ЫБОР ОС И ЦЕЛЕВОЙ РЫНОК Про любое приложение всегда зара нее известно, для какого целевого рын ка оно предназначается; из этого авто матически следует, каким отрасле вым стандартам оно (и, возможно, его компоненты) должно соответствовать. 26 СТА 2/2011 ОБ ЗОР / В С Т РАИВ А ЕМЫЕ СИС Т ЕМЫ www.cta.ru Рис. 3. Продукты, выбираемые для проекта в первую очередь (% респондентов, по данным опроса VDC за 2010 год) Процессор Встраиваемая/мобильная ОС Средства разработки ПО Нет информации 0 20 40 60 80 62,7% 20% 11,8% 5,5% © СТА-ПРЕСС