SWD Software Ltd. - официальный дистрибьютор QNX на территории России и стран бывшего СССР Операционная система реального времени QNX
Инструменты для создания надёжных встраиваемых систем и
интеллектуальных устройств любой сложности
QNX Software Systems - разработчик встраиваемой операционной системы QNX
Информационные брошюры
Статьи и публикации
Обзоры
Операционные системы
Графические интерфейсы
Средства разработки
Прикладные системы на базе ОС QNX
Разное
Конкурсные статьи
Техническая литература
Материалы конференций QNX-Россия
Полезные ссылки
Блог QNX
Главная страница > Материалы > Статьи и публикации > Операционные системы > Коммерческие, свободно-распространяемые и "доморощенные" ОС реального времени: мифология эффективности Сделать страницу стартовой Послать ссылку коллеге Версия для печати

Коммерческие, свободно-распространяемые и "доморощенные" ОС реального времени: мифология эффективности

Применять или не применять ОС реального времени (ОСРВ) во встраиваемом проекте - вопрос уже почти риторический. И у одного, и у другого подхода есть свои сторонники и противники, и у каждого из них свои, казалось бы, неоспоримые аргументы. В данной статье предпринимается попытка взглянуть на вопрос "сверху" и указать на некоторые наиболее распространенные мифы.

Допустим, что у вас назревает новый проект, и вы выбираете для него программную платформу. В зависимости от степени привлечения стороннего интеллектуального потенциала вариантов существует четыре:

  • обойтись вообще без ОСРВ;
  • разработать ОСРВ самостоятельно;
  • приспособить под свои нужды свободно-распространяемую ОС общего назначения;
  • использовать готовую коммерческую ОСРВ.

Зачастую из-за нехватки информации и недостатка понимания вопроса решения подобного рода принимаются "по понятиям", а значит, в изрядной степени подвержены предрассудкам. Остановимся на наиболее популярных из них.

Мифы...

"Не любому приложению нужна ОС." В разумных пределах (читай - для небольших одиночных проектов) эта мысль способна творить чудеса; однако, будучи доведенной до абсурда ("зачем мне молоток, мне и нужно-то всего один гвоздь вбить"), она может очень сильно навредить. Если проект со временем будет расти и развиваться (а для предприятия, которое на рынке всерьез и надолго, это естественный порядок вещей), количество кода, которое придется поддерживать и дорабатывать, очень скоро вырастет до таких объемов, что размер издержек поставит окупаемость проекта под серьезный вопрос. При этом затраты на перенос проекта на другую платформу - как прямые (стоимость самой платформы, стоимость обучения персонала, стоимость работ по переносу кода и т.п.), так и косвенные (например, потеря доли на рынке из-за отставания от конкурентов, вызванного временными затратами на перенос кода) - могут быть таковы, что перенос уже не сможет себя окупить, и хороший проект будет загублен навсегда.

"Разработать свою ОСРВ - вопрос пары месяцев." Это достаточно распространенное заблуждение берет свое начало из теории управления проектами: мол, оценку ресурсов, необходимых на разработку своей ОС, можно получить делением средней стоимости коммерческой ОС данного класса на стоимость человеко-часа среднего программиста. Здесь, однако, следует четко уяснить, что программирование - процесс итерационный. Помните шутку из старых времен: "ремонт нельзя закончить, его можно только прекратить." С программными проектами та же самая история. Ситуация на рынке постоянно меняется, и любой проект - всегда проект "живой". А значит, однажды взявшись за разработку, вы будете вынуждены заниматься ей все время, и отведенные на нее ресурсы не освободятся никогда.

"Коммерческая ОСРВ - сложный продукт, который придется долго осваивать." Этот аргумент встречается достаточно часто, и как раз по этой самой причине к коммерческим ОСРВ он, в отличие от ОС общего назначения, в большинстве случаев неприменим. Большинство коммерческих ОСРВ разрабатываются изначально с учетом этого момента, поскольку их основное стратегическое предназначение - сократить время выхода новых продуктов на рынок, в том числе за счет сокращения кривой обучения. Если же продукт будет сложен в освоении, его просто никто не купит.

"Коммерческая ОСРВ перегружена ненужной функциональностью." Любой универсальный продукт всегда содержит некоторую избыточность, которая может быть и не нужна в каждом конкретном случае. Однако, встраиваемые среды зачастую просто не оставляют ресурсов для избыточного ПО, и разработчики вынуждены приспосабливаться. Как следствие, все современные коммерческие ОСРВ являются масштабируемыми и позволяют исключать из целевой конфигурации ненужную функциональность.

"Своя ОСРВ хорошо знакома и поэтому может быть качественно документирована." Документирование проекта всегда имеет под собой одну цель - облегчить его изучение. Причем как для заказчиков, так и для новых участников проекта. Однако, если проект делается для внутреннего использования, всегда найдется тысяча более важных дел, чем документировать то, по чему всегда под рукой есть специалист. Разработчики также охотно принимают эту точку зрения, поскольку терпеть не могут писать документацию. Что бывает потом - об этом см. ниже.

"Свою ОСРВ можно довести до ума за конечное время и больше об этом не думать." Этот вопрос уже частично обсуждался выше (см. "Разработать свою ОСРВ - дело нескольких недель"), стоит лишь добавить, что в программировании очень неблагоприятным фактором является "текучка кадров". Рынок непрерывно развивается, меняются требования к продуктам, и даже для самой удачной ОСРВ однажды наступает момент, когда в нее нужно внести изменения. К этому моменту специалисты, разработавшие ее, в лучшем случае уже забыли, что они делали два года назад, а в худшем - перешли на работу в другую компанию. Как результат, новая версия если и выходит, то с большим запозданием и большим количеством ошибок.

"Использование собственной или свободно-распространяемой ОСРВ позволяет существенно сэкономить." Здесь следует помнить, что себестоимость проекта складывается не только из стоимости инструментария и комплектующих. В общем случае она включает в себя как минимум:

  • стоимость инструментария;
  • стоимость обучения;
  • ресурсы на разработку (время, персонал, рабочие места, поддержка, консалтинг и т.п.);
  • стоимость комплектующих и сборки;
  • стоимость сопровождения.

И здесь, как и везде, работает "золотое правило механики": выигрывая в одном, проигрываешь в другом. Продукт продуктом, но значимость пакета сопутствующих услуг (обучение, поддержка, консалтинг, заказные разработки) как средства сокращения выхода продукта на рынок отрицать нельзя. Здесь есть три варианта:

  • отказаться от услуг вообще;
  • заказать их у производителя продукта;
  • заказать их у сторонней консалтинговой компании.

Первый вариант, очевидно, позволяет сэкономить деньги "здесь и сейчас", но проигрывает по времени и трудозатратам, потому что все приходится делать самим, и никто не поможет. Это чревато серьезными задержками, а они на рынке с жесткой конкуренцией могут стоить очень дорого.

Второй и третий варианты очень похожи и отличаются только тем, какую долю прибыли приносят компаниям их продукты и услуги. Компания-производитель получает прибыль как от своих продуктов, так и от услуг, причем в каком именно соотношении - это вопрос индивидуальный. Консалтинговая компания продукта не производит и получает прибыль только от услуг, поэтому зачастую стоимость ее пакета услуг соизмерима, а то и превосходит стоимость коммерческого продукта. Иными словами, если перед вами бутерброд с бесплатным сыром, то есть все основания предполагать, что либо это мышеловка, либо есть смысл задуматься, сколько стоит хлеб.

Из вышеизложенного следует один простой вывод: ни один из указанных подходов не является оптимальным по своей сути, и перед принятием решения необходимо проанализировать все возможные варианты индивидуально с точки зрения совокупной стоимости владения (TCO), то есть затрат на длительном промежутке времени.

"То, что у нас есть, - это тоже ОС реального времени." Трактовка термина "реальное время" сильно зависит от приложения, и недобросовестные производители этим часто пользуются. Здесь необходимо знать две вещи. Во-первых, ОСРВ делятся на два класса - ОС "жесткого" и "мягкого" реального времени. Первые гарантируют четко определенное время реакции на событие (это свойство обеспечивается специально спроектированной архитектурой ОС), вторые - как правило успевают обработать событие за указанный временной интервал. Соответственно, ОС "мягкого" реального времени для реализации детерминированной системы (скажем, контура управления) не подходит по определению.

Во-вторых, время, за которое ОСРВ обрабатывает событие, в определении ОСРВ не обговорено. Иными словами, если ОСРВ гарантированно обрабатывает событие, скажем, за 1 сутки, то формально ее вполне можно считать ОС жесткого реального времени. Вывод: перед выбором инструмента необходимо четко представлять себе требования поставленной задачи. Кстати, все ОС жесткого реального времени, обеспечивающие реакцию на событие в пределах единиц микросекунд, являются коммерческими. Что, впрочем, неудивительно: для серьезной задачи нужен серьезный инструмент.

"Свободно-распространяемая ОС исключает проблемы с авторскими правами." А вот это неправда. Любой код почти всегда подпадает под какую-либо лицензию; мало того, зачастую эти лицензии конфликтуют между собой, в результате чего физически совместимые между собой компоненты, например, по закону бывает нельзя включать в один и тот же дистрибутив. Здесь общее правило такое: любая лицензия накладывает определенные ограничения, и их надо четко себе представлять, иначе могут возникнуть проблемы с приемкой. Заказчику всегда нужен лицензионно чистый продукт - хотя бы потому что это явно укажет, кто будет отвечать, если что-то пойдет не так. А за продукт, никому не принадлежащий, не отвечает никто.

...и немного фактов

Кроме вышеперечисленных мифов, также существует ряд неопровержимых фактов, относящихся к коммерческим ОСРВ; однако, они часто либо остаются в тени, либо значение их недооценивается. Перечислим некоторые наиболее важные из них с небольшими комментариями.

Подробная документация. Документация - неотъемлемая часть продукта. Разработчики, использующие ОСРВ, не могут себе позволить тратить много времени на изучение ее устройства, поэтому даже самый хороший продукт теряет свою ценность, если по нему нет качественной подробной документации. К тому же, мощности служб технической поддержки всегда ограничены, и написать документацию всегда выгоднее, чем многократно отвечать на одни и те же вопросы. Поэтому коммерческие ОСРВ всегда хорошо документированы.

Проверенный код. Количество клиентов компании-разработчика коммерческой ОСРВ может измеряться сотнями. Это означает, что код этой ОСРВ будет проходить непрерывное тестирование в множестве мест одновременно, в разных конфигурациях и режимах. Такую эффективность тестирования не может обеспечить ни одно локальное подразделение тестеров. Соответственно, коммерческие ОСРВ всегда содержат меньше ошибок, чем "доморощенные".

Специализированный инструментарий. Приложения реального времени обладают определенной спецификой (например, механизмы планирования и синхронизации задач в ОСРВ отличаются от таковых в ОС общего назначения), и их отладка требует наличия специализированного инструментария. Обычным отладчиком в этом случае зачастую не обойтись, да и стандартных средств диагностики обычно бывает недостаточно. К тому же, все современные ОСРВ расчитаны на встраиваемые конфигурации, поэтому разработчику для эффективной работы нужны не просто компилятор и отладчик, а интегрированная линейка инструментов, способная провести его от написания кода до формирования и оптимизации образа ПЗУ. Таким инструментарием обладают только коммерческие ОСРВ.

Дополнительные компоненты. Сама по себе операционная система - это еще не все. Кроме базовой функциональности, предоставляемой операционной системой, вашему проекту могут быть нужны дополнительные программные компоненты - стеки протоколов, графика, средства работы с базами данных и т.п. Если вы разрабатываете ОСРВ самостоятельно, то будьте готовы, что вам придется разрабатывать самостоятельно и все остальное. Такой вариант как портирование готовых компонентов в вашу собственную ОСРВ можно исключить сразу, потому что для этого необходимо, чтобы ваша ОСРВ в полной мере поддерживала некий универсальный API (например, для большинства свободно-распространяемого ПО это POSIX), а это для "доморощенных" ОСРВ часто считается ненужным излишеством.

Профессиональные сервисы. И, пожалуй, последнее - как говорят, по счету, но не по значению. Даже самая качественная и подробная документация не решает всех проблем - хотя бы потому что учебник надо всегда читать полностью, а в справочнике надо уметь искать. И то, и другое для сложного продукта может занять очень много времени, потому что объем документации часто очень велик. Если же вы сталкиваетесь с проблемой, то вам, скорее всего, нужно решить ее быстро, а в этом вам может помочь только тот, кто знает систему "изнутри" - ее разработчик. В этом смысле свободно-распространяемые ОСРВ не дают никакой гарантии, потому что не ответив на вопрос в публичном форуме, никто своей репутацией не рискует, а значит, уверенности, что вы быстро получите ответ на любой вопрос, быть не может. Остается сравнить годовую стоимость содержания штата разработчиков со стоимостью годового плана технической поддержки коммерческой ОСРВ. В большинстве случаев выигрывает последний вариант. В дополнение к этому, как уже упоминалось, обычно пакеты профессиональных сервисов, предоставляемые производителями коммерческих ОСРВ, не ограничиваются технической поддержкой и включают в себя также обучение персонала, заказные разработки, сертификацию, проектный консалтинг и прочее - словом, все, что помогает сделать проект грамотно и вовремя.

Резюме

Выбор инструмента для серьезной работы, особенно в условиях жесткой конкуренции, - всегда ключевой момент. Инструмент - это вещь, которая выбирается всерьез и надолго; однако, приходится признать, что универсальных инструментов не существует. Каждой задаче соответствует свой оптимальный инструмент, и принять правильное решение можно только зная требования поставленной задачи, а также ее предысторию и перспективы.

В технике чудес не бывает, все они - не более чем неосознанные закономерности. Поэтому любая цель должна быть измерима, иначе будет невозможно оценить, достигнута она или нет. Аналогично, любая характеристика должна быть измерима, иначе будет невозможно сравнить то, что предлагается, с тем, что требуется. Единственное, что должно управлять вами при выборе программной платформы для проекта - это ваши цели и степень соответствия характеристик платформы требованиям проекта. А мифы, как бы правдоподобно они ни выглядели, способны дать лишь мифическую эффективность.

Николай Горбунов
marketing@swd.ru
SWD Software Ltd.

Рассказать друзьям:

Rambler's Top100           Рейтинг@Mail.ru