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

Большинство встраиваемых систем предназначены для управления объектами или мониторинга параметров внешней среды, что накладывает жесткие ограничения на время реакции системы при обработке событий [1], поэтому одно из главных требований к встраиваемой ОС — обеспечение выполнения многозадачного приложения в условиях реального времени. Кроме того, немаловажными для встраиваемых систем являются компактность, автономность и безопасность, что означает минимизацию используемых для нужд ОС ресурсов, наличие режима энергосбережения, повышенные требования к скорости выполнения системных функций и высокую отказоустойчивость (обработку исключительных ситуаций и ошибок в приложении, контроль системного стека и стека задач). Когда речь идет о работе распределенной системы, состоящей из множества устройств, то дополнительно к требованиям для отдельных устройств возникает задача организации структуры этой системы, мониторинга состояния каждого устройства, обеспечения надежной связи между ними, резервирования оборудования и т. д.

Сегодня на рынке встраиваемых ОС есть как открытые (FreeRTOS, eCos, RTEMS, ChibiOS), так и проприетарные решения (µC/OS, VxWorks, ThreadX, VDK) [2]. Однако, несмотря на разнообразие предложений на рынке, при интеграции ОС в конкретный проект разработчики часто сталкиваются со множеством проблем, в числе которых ограниченный функционал, отсутствие доступа к исходным кодам, несовместимость с аппаратной платформой, скудная документация, отсутствие технической поддержки, сложность программного интерфейса и т. д. Для разработки встраиваемых распределенных систем, ориентированных на отечественную элементную базу, российским разработчикам и пользователям нужна ОС, позволяющая упростить процесс разработки ПО и устранить возможные ограничения, связанные с применением западных программно-аппаратных платформ.

Проект ОСРВ МАКС (Операционная Система Реального Времени для МультиАгентных Когерентных Систем) стартовал в 2015 году, и его результатом стало то, что сегодня на рынке появилась система, не только отвечающая стандартным требованиям к ОС реального времени, но и обладающая дополнительными возможностями по обеспечению взаимодействия между устройствами в распределенной среде. Система поставляется с комплектом русскоязычной документации, поддерживает работу с оборудованием отечественного производства (продукция «ПКК Миландр» — 32-разрядные микроконтроллеры серий 1986 и 1967), а ее техническая поддержка осуществляется российскими специалистами. Кроме того, к исходным кодам системы прилагаются шаблоны проектов для различных сред разработки и готовые программы, помогающие пользователям быстро освоить ОС, настраивать и создавать новые приложения.

В состав ядра системы (рис. 1), обеспечивающего работу многозадачного приложения, входят: планировщик (диспетчер), объекты синхронизации (семафоры, события и др.) и средства обеспечения взаимодействия задач (очереди сообщений). Планировщик поддерживает два режима многозадачности.

  • Кооперативная многозадачность снижает накладные расходы работы системы за счет исключения лишних переключений задач и использования объектов синхронизации. Режим позволяет заранее предопределить последовательность выполнения задач, возлагая, однако, на разработчика ответственность за установку точек передачи управления между задачами.
  • Вытесняющая многозадачность избавляет разработчика от необходимости планирования задач вручную (планирование с учетом точек и последовательности передачи управления между задачами) и обеспечивает оптимальную загрузку процессора.
Рис. 1. Архитектура ОСРВ МАКС
Рис. 1. Архитектура ОСРВ МАКС

 

При вытесняющей многозадачности планирование задач осуществляется на основании их приоритетов, что позволяет разработчику определить критичность каждой задачи в приложении — аппаратные ресурсы будут распределяться между задачами в зависимости от их критичности. В этом режиме поддерживается механизм предотвращения инверсии приоритетов (так называемое наследование приоритетов), исключающий возможность задержки выполнения высокоприоритетных задач при ожидании ресурса, захваченного задачей более низкого приоритета. Наконец, обеспечивается предсказуемое время выполнения системных функций: переключение и синхронизация задач, обработка прерываний и т. д. Это означает, что в коде, для которого критично время выполнения, исключаются алгоритмы с недетерминированным поведением, а все операции ожидания гарантированно ограничиваются тайм-аутами [3].

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

Сегодня все чаще возникают ситуации, когда задачу лучше решать с помощью совокупности устройств, поэтому, в отличие от классических ОС РВ, в основу МАКС были положены принципы организации взаимодействия между несколькими устройствами (агентами), призванные упростить решение таких типичных задач, возникающих в распределенных системах, как распараллеливание вычислений, доступ к разделяемым данным, диагностика и резервирование устройств и т. д. Обычно для организации подобного взаимодействия используются стандартные примитивы Send и Receive, обеспечивающие отправку и прием сообщений (адресных или широковещательных), что позволяет создавать высокопроизводительные системы. Однако их реализация сопряжена с большими трудностями [4], особенно в ситуациях, когда необходим обмен сложными структурами данных.

Для упрощения решения уже давно была предложена концепция RPC (remote procedure call) — вызов процедур, расположенных на удаленных машинах. Базируясь на Send и Receive, RPC скрывает сложность, предлагая разработчику удобные в использовании абстракции. Однако есть и другие механизмы — альтернативная концепция распределенной общей памяти [5], которая и была положена в основу ОСРВ МАКС.

Несколько независимых устройств могут обмениваться данными и синхронизировать их так, будто все они имеют физический доступ к общей памяти. Ключевым понятием здесь, в терминологии МАКС, является контекст — набор параметров, доступный из приложения на разных устройствах. Каждое из устройств может получать и обновлять данные контекста, не заботясь о наличии других устройств, что обеспечивает ряд преимуществ. Например, когерентность данных в контексте может быть использована для повышения надежности системы: имея доступ к контексту, в котором сохраняется текущий статус задачи, резервное устройство продолжит выполнение задачи именно с того состояния, на котором неисправное устройство прекратило свою работу. В случае, когда допускается параллельное выполнение задачи группой устройств, использование разделяемых контекстов позволяет увеличить производительность. Кроме того, синхронизация контекстов решает проблему распределения подзадач внутри группы — каждое из устройств может резервировать для себя подзадачу в общем контексте и выполнять свою часть работы одновременно с другими. В общем контексте могут сохраняться также результаты работы и другие данные отдельных устройств, которые могут быть использованы всеми устройствами группы. В синхронизируемом контексте могут содержаться данные о функциональных возможностях доступных устройств и потребностях имеющихся задач. В этом случае у распределенной системы появляется возможность самостоятельно определять оптимальную конфигурацию — новое подключенное устройство автоматически узнает свою роль и выбирает посильную для себя задачу.

Механизм работы с распределенной общей памятью позволяет группировке из нескольких устройств реализовать новый подход к выполнению задач. Представим, к примеру, группу роботов, убирающих большое промышленное помещение, — использование общего контекста позволит им совместно составлять карту здания, распределять рабочие зоны, обмениваться информацией о загрязненности различных участков и контролировать статус друг друга. В результате уборка будет выполняться быстрее и качественнее, чем при использовании нескольких независимых роботов, — минимизируется их простой и исключается появление неубранных участков. Оптимальное использование устройств достигается за счет автоматического перераспределения задач внутри группы в зависимости от их сложности (уровня загрязненности, топологии помещения и пр.) или при изменении состава устройств (подключение нового устройства и выход из строя существующего).

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

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

Рис. 2. Контроль доступа и обработка ошибок в ОСРВ МАКС
Рис. 2. Контроль доступа и обработка ошибок в ОСРВ МАКС

 

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

Одна из отличительных особенностей ОСРВ МАКС — объектно-ориентированный интерфейс, уже давно ставший нормой в разработке приложений для ПК, но еще не добравшийся до индустрии встраиваемых систем. В МАКС создана иерархия классов окружения системы, позволяющая структурировать приложения и упростить работу с системными сервисами. Для разработчиков, предпочитающих классический функциональный подход, в перспективе планируется обеспечить поддержку стандартных интерфейсов, не зависящих от конкретного оборудования CMSIS (Cortex Microcontroller Software Interface Standard) и подмножества POSIX (Pthreads). Среди других направлений развития системы можно отметить расширение списка поддерживаемых  платформ, включая ARM Cortex-M3/M4, ARM Cortex-M0/M0+/M1, TigerSHARC от Analog Devices, а также появление нового графического интерфейса. Кроме того, дальнейшее развитие получат механизмы организации взаимодействия между устройствами: поддержка сетей с ячеистой топологией (mesh) и реализация протоколов связи для Интернета вещей.

***

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

Литература

  1. Алексей Федосеев. Системы реального времени: от Linux к Java // Открытые системы.СУБД. — 2009. — № 3. — С. 10–12. URL: http://www.osp.ru/os/2009/03/8112510 (дата обращения: 18.03.2017).
  2. Леонид Акиншин, Анатолий Сысоев. Встраиваемые системы и патриотизм // Открытые системы.СУБД. — 2008. — № 8. — С. 68–71. URL: http://www.osp.ru/os/2008/08/5661718 (дата обращения: 18.03.2017).
  3. Vivek Halwan, Jim Krodel. Study of Commercial Off-The-Shelf (COTS) Real-Time Operating Systems (RTOS) in Aviation Applications // Federal Aviation Administration. Research Reports. — 2002. — DOT/FAA/AR-02/118. — С. 2–3. URL: https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-02-118_COTS.pdf (дата обращения: 10.03.2017).
  4. David R. Cheriton, Michael Stumm. The multi-satellite star: Structuring parallel computations for a workstation cluster. J. Distributed Comput. Memory Coherence in Shared Virtual Memory Systems l 359 (1988).
  5. Kai Li, Paul Hudak. Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems (TOCS) 7.4 (1989): 321–359.

Александр Кучеров (alexander.kucherov@astrosoft.ru) — руководитель проекта ОСРВ МАКС, «АстроСофт» (Санкт-Петербург).