Windows server система реального времени

Представьте себе такую ситуацию: в мире осталась всего одна «сверхуниверсальная» операционная система, удовлетворяющая требованиям абсолютно всех приложений — офисных, встраиваемых, ответственных, реального времени и т. д. При всей фантастичности подобного положения и его гипотетической бесперспективности для рынка в силу отсутствия конкуренции, ясно, что оно устроило бы всех. Тяга к идеальной операционной системе, охватывающей все приложения, заложена в самой человеческой природе: приобретя опыт работы с какой-то одной операционной системой в какой-то одной прикладной сфере, мы стараемся использовать этот опыт, а следовательно, и саму операционную систему, в других областях, включая те, на которые она изначально не рассчитана.

Продукт с неброским названием RTX (Real Time eXtension), позволяющий добавлять в стандартные офисные и встраиваемые операционные системы семейства Windows (кроме версии Windows CE) поддержку реального времени, есть не что иное, как попытка приблизиться к реализации мечты о «сверхуниверсальной» операционной системе, и попытка весьма удачная.

Эпоха Windows NT

Сама идея RTX родилась в незапамятные времена, однако реальная возможность для ее воплощения возникла лишь с появлением Windows NT. Эту идею можно сформулировать следующим образом: «сделать так, чтобы популярную недорогую операционную систему общего назначения было удобно использовать во встраиваемых системах и системах реального времени». Став, по сути, первой «профессиональной» операционной системой «с человеческим лицом», платформа Windows NT открыла новую страницу в истории корпорации Microsoft и в истории операционных систем вообще. А с легкой руки компании VenturCom, создавшей расширение RTX, — и в истории систем реального времени. Дополнительная информация о подсистеме RTX приведена во врезке «Расширяем Windows».

Для формирования и развития рынка встраиваемых компьютерных технологий роль Windows NT была весьма велика. В середине 90 годов прошлого века встраиваемые проекты на базе Windows NT стали появляться массово. Для комфортного использования Windows NT во встраиваемых системах и задачах реального времени разработчикам не хватало трех вещей:

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

Продукты компании VenturCom

Решение всех трех задач предложила компания VenturCom, выпустившая Component Integrator и RTX. Продукт Component Integrator предоставлял разработчику набор «кубиков» — отдельных компонентов Windows NT, из которых он мог легко собрать операционную систему с необходимой только ему функциональностью, а продукт RTX позволял добавлять в обычную «настольную» Windows NT поддержку работы в режиме реального времени.

Результатом применения инструмента Component Integrator являлось значительное (нередко в несколько раз) снижение требований к аппаратуре, а также дополнительное повышение надежности и производительности. Впоследствии технология Component Integrator была куплена корпорацией Microsoft и под именем Component Designer стала основой нового бизнес-направления Microsoft: производство и поставка встраиваемых операционных систем, семейства продуктов Windows Embedded.

Что касается RTX, то этот продукт компании VenturCom позволил и вовсе доселе немыслимое: использовать стандартные «настольные» операционные системы Microsoft в том числе для приложений реального времени.

Сегодня поставками расширения RTX занимается компания IntervalZero, штат которой почти полностью укомплектован бывшими сотрудниками VenturCom. Этому предшествовала следующая цепочка событий: в 2004 году компания VenturCom сменила название на Ardence, затем в 2006 году Ardence была куплена корпорацией Citrix, и, наконец, в 2008 году на основе подразделения корпорации Citrix, занимавшегося программным обеспечением реального времени, была создана отдельная компания, получившая название IntervalZero. Данное название призвано подчеркнуть, что своими продуктами компания IntervalZero стремится обеспечить минимальные задержки в работе системы. В результате всех этих пертурбаций сегодня решения серии RTX развивает и поддерживает та же команда, что и раньше, поскольку костяк технических специалистов и менеджеров компании VenturCom перешел во вновь образованную компанию IntervalZero практически в полном составе.

За 10 с лишним лет существования RTX удобство и эффективность этого продукта смогли оценить очень многие разработчики, реализовавшие на его основе сотни тысяч проектов. И все это время RTX успешно развивался, обрастал новыми функциями и возможностями. Посмотрим, что представляет собой с технической точки зрения RTX сегодня.

Внутреннее устройство RTX

Продукт RTX состоит из двух частей. Первая часть, пакет разработчика RTX SDK, предназначен для создания собственных приложений для работы в среде RTX. Вторая часть, подсистема исполнения RTX Runtime, представляет собой непосредственно подсистему реального времени для обслуживания приложений RTX. Подсистема RTX Runtime устанавливается на целевые системы, где предполагается запуск RTX-приложений. Пакет разработчика также включает в себя подсистему реального времени, поэтому разрабатываемые приложения RTX можно запускать и отлаживать непосредственно на локальном месте разработчика. Кроме того, очень ценным свойством SDK является его тесная интеграция со средой разработки Visual Studio от компании Microsoft.

На момент написания статьи последней версией RTX являлась RTX 2009. С этой версии нумерация слегка изменилась. Ранее версии имели номера (вплоть до 8.1.1), теперь вместо номеров используются годы выпуска. Компания IntervalZero обеспечивает 10-летний срок поддержки своих продуктов, поэтому можно приобрести системы исполнения для ранее купленной версии.

Каким образом можно создать на основе Windows систему реального времени? Стоит сразу отметить, что все предлагаемые на рынке решения не меняют функциональность и возможности самой Windows. Подсистема, реализующая функции системы реального времени, работает «рядом» с Windows. Обычные задачи Windows выполняются в недетерминированной среде, как и раньше. Один из вариантов реализации подобного механизма — разделение ресурсов между Windows и подсистемой реального времени. Подобный подход реализовала, например, компания TenAsys, предлагающая продукт INTime. При использовании INTime на одной аппаратной платформе запускаются две виртуальные машины — с Windows и с подсистемой реального времени INTime. Здесь в целом неважно, какая операционная система выполняется параллельно с подсистемой реального времени, поддержка Windows определяется только наличием модифицированного уровня аппаратных абстракций HAL для работы в таком режиме и наличием интерфейсов API для связи задач, работающих в режиме реального времени и в Windows-среде. С популяризацией многоядерных архитектур стало возможным и просто выделение отдельных ядер под Windows и под систему реального времени. Однако довольно сложная архитектура INTime не позволяет добиться высокой производительности в задачах реального времени.

В отличие от описанного подхода RTX тесно интегрируется с Windows. На рисунке приведена схема интеграции. RTX дополняет стандартный HAL Windows своим расширением, RTX HAL Extension. На этом уровне, кроме организации доступа к аппаратуре, обрабатываются прерывания от таймера подсистемы реального времени. Непосредственно функциональность реального времени реализует слой RTSS, Real-Time SubSystem. Это ядро всей подсистемы реального времени. Здесь находится свой планировщик, который оперирует выполнением задач реального времени и предоставлением ресурсов задачам Windows-среды. Фактически любая задача RTSS имеет более высокий приоритет, нежели любая задача, выполняющаяся в Windows. Также этот слой полностью реализует API реального времени, Real-Time API — RTAPI, на основе которого создаются приложения подсистемы RTSS.

Приложения реального времени, RTSS Process, выполняются на уровне ядра Windows и имеют те же привилегии и ограничения, что и драйверы устройств. Этот подход отличается от других реализаций (например, INTime обеспечивает приложениям реального времени пользовательский режим, собственное адресное пространство и изоляцию), но позволяет достигать очень быстрого переключения контекста задач.

Доступ к функциям RTAPI возможен как для процессов RTSS, так и для «обычных» приложений Win32. Это позволяет выделять в Windows-задачах отдельные критичные ко времени выполнения участки. Такой возможности лишены системы, где Windows и подсистема реального времени работают параллельно. Кроме того, расширение интерфейса Win32 API функциями RTSS позволяет приложениям Win32 и приложениям RTSS обмениваться данными.

Возможности RTX

Что RTX может дать разработчику? Во-первых, использование стандартной операционной системы Windows позволяет обойтись без дополнительного аппаратного обеспечения и специализированных систем реального времени. Весь проект от начала до конца может быть реализован специалистами, ранее разрабатывавшими только обычные Windows-приложения, поскольку API RTX максимально приближен к API Win32 и не требует много времени на освоение. Благодаря огромному сходству между этими двумя API, разработчикам, никогда не имевшим дела с программированием для систем реального времени, не составит большого труда научиться создавать приложения реального времени под RTX.

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

Кроме того, несмотря на тесную интеграцию с операционной системой, RTX обладает таким важным свойством, как устойчивость к сбоям среды Windows. Подсистема RTSS умеет корректно обрабатывать завершения Windows, как штатные, так и аварийные («синий экран»). Также в RTX имеется механизм, с помощью которого можно сделать доступной память, которую «не видит» Windows. Этой цели служат, в частности, функции PAE (Physical Address Extensions), расширяющие адресное пространство до 36 разрядов и позволяющие получать на 32-разрядных системах доступ к 64 Гбайт памяти. Еще одной очень важной особенностью RTX является организация связи между задачами Win32 и RTSS. Механизмами взаимодействия процессов, IPC, являются привычные события, мьютексы, семафоры и общая память. При этом взаимодействие между детерминированной подсистемой RTSS и недетерминированной подсистемой Windows организовано так, чтобы исключить их перекрестное влияние на работу друг друга. Еще один механизм, направленный на обеспечение безопасности взаимодействия подсистем, — механизм proxy-процессов, осуществляющий обращение из среды Windows к RTSS-окружению. Но самым важным свойством, которое появилось в версии RTX 2009, является поддержка для задач RTSS работы в режиме симметричной мультипроцессности SMP. Версии с поддержкой SMP и без поддержки SMP теперь есть как в SDK, так и в Runtime-части.

Несмотря на сложность архитектуры RTX, для пользователя общение c RTX является простым и прозрачным. Свойства подсистемы RTX задаются из одного довольно простого приложения (экран 1); кроме того, в составе RTX SDK имеется обширная документация по работе с RTX (экран 2).

Программисты, знакомые с Microsoft Visual Studio, имеют возможность пользоваться данным инструментарием для разработки задач RTX. В среду разработки добавляются шаблоны возможных вариантов приложений RTX (экран 3). Стандартные отладочные механизмы Microsoft Visual Studio при этом доступны для отладки приложений RTX. По сути, вся разработка ведется привычными методами и с помощью известных инструментов.

Правильный выбор

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

Алексей Исаев — директор бизнес-направления системного ПО в ЗАО «РТСофт», отделение базовых аппаратных и программных средств
Леонид Акиншин — обозреватель журнала «МКА: мир ВКТ»

---

Рисунок. Схема интеграции Windows и RTX

---

Расширяем Windows

егодня можно говорить о более чем 750 тыс. применений продукта RTX. В промышленности, медицине и области телекоммуникаций пользователями RTX являются такие компании, как Siemens, ABB, Quanser, National Instruments, VMIC, General Electric. В аэрокосмической отрасли RTX применяется, например, компаниями Raytheon, Boeing, Honeywell. Автомобильная промышленность также не обошла этот продукт вниманием: реализованные на RTX проекты есть у Porsche, Renault, у Peugeot-Citroen и других производителей. Хорошим практическим примером из промышленного сектора может служить проект Siemens по переводу своей Windows-платформы для контроллеров на базу RTX. В военной сфере RTX использовался, в частности, компанией Raytheon в системах обеспечения станций по тестированию ракет Patriot. В нашей стране расширение RTX чаще всего используется в промышленной автоматизации, а также в системах контроля, тестирования и измерений. Ниже приводятся ответы на часто задаваемые вопросы о применении RTX.

Нужно ли покупать встраиваемую версию Windows (Windows XP Embedded или Windows Embedded Standard) для работы с RTX?

Нет, продукт RTX прекрасно работает с обычными «настольными» версиями Windows из коробки. Но использование встраиваемых версий Windows предоставляет более широкие возможности по созданию целевых систем с различной конфигурацией.

Нужно ли покупать для расширения RTX какие-то специальные средства разработки?

Нет, ничего специального для разработки RTX-приложений покупать не нужно, достаточно стандартного пакета Microsoft Visual Studio, который имеется у большинства разработчиков.

Можно ли использовать расширение RTX как дополнительное средство, повышающее надежность системы?

Да, RTX можно применять в таком качестве, поскольку во многих случаях после того, как Windows зависает или даже появляется «синий экран», подсистема RTX продолжает работать и, как минимум, способна обеспечить мягкую перезагрузку системы.

Влияет ли RTX на характеристики и поведение Windows?

Нет, RTX интегрируется с Windows путем добавления компонентов, не изменяя ничего в самой операционной системе. Система остается в исходном виде, с полноценной функциональностью, и работает точно так же, как и без RTX. RTX не вносит никакого дополнительного риска в работу Windows и ее приложений.

Насколько быстро работает комбинация из Windows + RTX по сравнению с «чистой» операционной системой Windows?

Прежде всего, по сравнению с «чистой» операционной системой Windows комбинация из Windows и RTX в любом состоянии имеет предсказуемое время отклика для задач реального времени. При этом RTX работает с интервалом до 1 мкс, в то время как Windows оперирует в лучшем случае 1 мс. Говорить о времени реакции самой операционной системы Windows нельзя, поскольку она не является операционной системой реального времени и потому не обладает детерминированным поведением. Можно сравнить время реакции на одно и то же событие в Windows и в RTX на одной аппаратной платформе. Например, даже на такой платформе, как Intel Atom, расширение RTX обеспечивает время реакции на срабатывание таймера от 1 до 11 мкс, а Windows от 600 до 1500 мкс.

В каких прикладных областях используется расширение RTX на территории Российской Федерации?

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

Сколько стоит RTX?

По сравнению с классическими системами реального времени расширение RTX стоит меньше: 425 долл. для одной уникальной системы, при этом НДС согласно действующему российскому законодательству не взимается.

Можно ли использовать расширение RTX в бездисковых конфигурациях?

Не только можно, но и очень полезно. Расширение RTX может работать как со стандартной Windows, так и со встраиваемыми операционными системами Windows Embedded. При использовании с Windows Embedded расширение RTX способно улучшить качество готового изделия и дать ему дополнительные преимущества за счет повышения надежности и обеспечения поддержки реального времени.

Говорят, что при использовании расширения RTX пользователь имеет прямой доступ к оборудованию, как в реальном режиме MS-DOS?

Да, это так. Простота работы с оборудованием является одним из основных факторов, обуславливающим популярность расширения RTX у Windows-разработчиков.

Сложно ли написать драйвер устройства под систему с расширением RTX?

В каком-то смысле написать драйвер устройства под систему RTX даже проще, чем под стандартную Windows. Если вы не располагаете собственными инженерными ресурсами для написания драйверов, вы можете, например, обратиться в компанию РТСофт (www.rtsoft.ru), специалисты которой имеют большой опыт создания RTX-драйверов для самого разного, в том числе уникального, оборудования.

Много ли места занимает расширение RTX?

Нет. В том, что касается потребления памяти, дискового пространства и т. п. расширение RTX отличается предельной скромностью: обычно на RTX в целевом образе приходится не более 4 Мбайт. Идет ли речь о персональном компьютере или же о каком-нибудь компактном устройстве, докупать оперативную память, флеш-память и/или дисковые накопители для RTX вам точно не придется. Общий принцип таков: расширение RTX будет прекрасно себя чувствовать на любой аппаратной конфигурации, где работает стандартная Windows. Львиная доля потребляемых ресурсов всегда приходится именно на Windows, вклад же RTX пренебрежимо мал.

Насколько сильно снижается стоимость расширения RTX с ростом числа установок?

Уже при покупке лицензии на несколько десятков систем цена снижается весьма значительно. Расширение RTX — это недорогой продукт, и потому его система ценообразования очень удобна для пользователей.

Где взять специальные знания для эффективной работы с расширением RTX?

Весь нужный объем специальных знаний можно получить, например, в учебном центре компании РТСофт (www.rtsoft.ru). Но, как показывает практика, большой необходимости в этом нет. Любой специалист, способный писать приложения для Win32 API, разберется с RTX за пару дней. Другими словами, при использовании расширения RTX инвестировать дополнительные средства в обучение разработчиков можно, но не обязательно. Это одно из фундаментальных отличий RTX от традиционных систем реального времени, для эффективного применения которых совершенно необходимы квалифицированные специалисты с соответствующим уровнем зарплаты.

Какие дополнительные аппаратные ресурсы нужны для полноценной работы расширения RTX?

Расширение RTX очень нетребовательно к ресурсам, и в любой реальной системе — настольной рабочей станции, пульте управления, мобильном устройстве либо промышленном контроллере — большая часть ресурсов будет затрачена на саму Windows, настольную либо встраиваемую. Как уже говорилось, расширение RTX будет прекрасно себя чувствовать на любой аппаратной конфигурации, где работает стандартная Windows.

Облегчает ли расширение RTX создание детерминированных сетевых приложений?

Да, конечно. Это одна из традиционно сильных сторон RTX. Комплект поставки RTX включает детерминированные стеки и полный набор других компонентов, необходимых для обеспечения работы сетей Ethernet в реальном времени.

Насколько прост сам процесс интеграции расширения RTX в различные версии Windows?

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

Получается, что расширение RTX позволяет отказаться от традиционных операционных систем реального времени?

Да, во многих случаях это именно так! Если задача в принципе может быть успешно решена без использования операционной системы реального времени, ее задействовать не нужно. Во всем мире люди, умеющие считать деньги, поступают именно так. Расширение RTX уже позволило реализовать сотни тысяч проектов реального времени на базе самых обычных, не встраиваемых версий операционной системы Windows, которые стоят значительно меньше традиционных систем реального времени. Справедливости ради надо признать, что заменить классические профессиональные системы реального времени для любых приложений комбинация Windows + RTX не в состоянии. Однако в силу развития Windows, продукта RTX и современных х86-платформ, количество приложений, где возможностей связки Windows + RTX достаточно для эффективного решения актуальных задач, постоянно растет.

Есть ли какие-либо особенности у аппаратных платформ для расширения RTX?

Никаких! Там, где работает сама операционная система Windows — будь то решение типа PC Box, мобильный компьютер, система VME или CompactPCI, настольная персональная система, сервер или что-то еще — сможет работать и расширение RTX. Единственное «жесткое» аппаратное ограничение со стороны RTX — это наличие x86-совместимого центрального процессора, но данное требование выполняется автоматически, поскольку стандартные версии операционной системы Windows рассчитаны только на архитектуру x86, а все версии Windows Embedded для этой архитектуры доступны. Продукт RTX совместим с любыми x86-процессорами, от самых современных до весьма древних.

Чем отличается расширение RTX от других продуктов, таких как INTime компании TenAsys?

При использовании INTime на одной аппаратной платформе фактически работают две операционных системы: Windows и дополнительная подсистема реального времени, которая представляет собой, по сути, самостоятельную операционную систему с уровнями безопасности, разделением памяти, распределением процессорного времени и т. п. Современные многоядерные процессоры позволяют реализовать данный подход как с использованием INTime, так и какой-нибудь классической системы реального времени вроде QNX или VxWorks. Расширение же RTX встраивается в Windows очень плотно и становится в полном смысле этого слова частью операционной системы. Работая целиком на уровне драйверов, оно обеспечивает очень быстрое переключение задач. К тому же приложения для RTX можно писать в стандартном пакете Microsoft Visual Studio. Если совсем коротко, то основные преимущества RTX по сравнению с INTime — это быстродействие, компактность и удобство.

Время на прочтение
11 мин

Количество просмотров 15K

Преамбула

Фирма, в которой я работаю, производит аппаратуру для нейрохирургов и нейрофизиологов, в основе которой лежит технология Deep Brain Stimulation. Если коротко, в живой мозг втыкается электрод, и нейрохирург может считывать из мозга сигнал или стимулировать клетки мозга разрядом тока. У технологии огромное будущее в деле лечения болезней (например, болезни Паркинсона, дистонии, эпилепсии) и в создании нейроинтерфейсов: нейропротезирование, в частности, восстановление зрения; аугментация мозга дополнительными устройствами, расширение возможностей мозга. Скажем, спецслужбы очень интересуются способом считывать и записывать информацию из зрительных и слуховых нервов, а также управлять движением животных, что позволит создать новый класс шпионов.

Для клинического применения в целях лечения тремора при болезни Паркинсона достаточно лишь нескольких внедряемых контактов (а некоторые нейрохирурги обходятся вообще одним). Но для исследователей, изучающих работу мозга, количество контактов имеет значение, и им нужно получать данные от как можно большего числа контактов одновременно и синхронно. Скажем, тысяча, или две тысячи внедрённых в мозг контактных площадок. Понятно, хотелось бы, чтобы и скорость была пристойной, — скажем, сорок тысяч замеров с каждого контакта в секунду. И чтоб разрешение было повыше, чтоб каждый замер был хотя бы в 32 бита, в формате float или Q. Получаем, что система производит порядка 320 мегабайт данных в секунду, так что всё это придётся обрабатывать.

Кроме считываемых непосредственно из мозга «чистых» данных, есть ещё данные отфильтрованные: результат применённых к замерам фильтров верхних и нижних частот. Используются фильтры высоких порядков, хотя бы четвёртого, реализованные в виде полиномов. Они применяются к каждому входящему замеру, увеличивая количество данных, о которых система должна заботиться, вчетверо, и поднимая количество генерируемых данных до 1,3 гигабайта в секунду. Но это уже не моя забота, потому что они генерируются из переданных мной данных после того, как я свою часть работы выполнил.

Результат всего этого счастья нужен в режиме реального времени и крайне важен. Пропускать нельзя ни одного замера, потому что основную работу по анализу данных исследователи выполняют после окончания эксперимента. Поэтому всё это богатство данных, помимо показа на экране, придётся записывать на жёсткий диск. Все 1,3 гигабайта данных в секунду. И потом читать в Matlab`е, NeuroExplorer`е или другой программе. Система, которая сохраняла 99,99999% данных, не прошла контроль качества и была забракована, потому что теряла до 13 тысяч замеров каждую секунду.

А вот теперь мы со всем этим попробуем взлететь.

Формулировка задачи

Имеется разработанная фирмой плата с контроллером FPGA, с одной стороны в которую воткнуты провода, идущие от мозга, (ну, на самом деле, от конвертеров, типа такого), а с другой есть выход PCIe. Этим выходом плата будет воткнута в порт PCIe на самом обычном, просто очень мощном, компьютере.

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

Люди в теме уже сообразили, что речь идёт о hard realtime: гарантированный ответ на полученные данные в течение фиксированного времени, и неважно, что за дичь творится вокруг, без возможности задержаться или пропустить хотя бы один пакет. Эти же люди в теме уже покачали головой: творящаяся вокруг дичь — это Windows, hard realtime под Windows невозможен, Windows не операционная система реального времени. Более того, Windows не заточен под работу с квантами времени меньше миллисекунды, поэтому работа со скоростью «полный цикл обработки данных за 200 микросекунд» под Windows невозможна вдвойне.

Soft realtime отличается от hard realtime тем, что в soft иногда небольшие задержки всё-таки разрешены, при условии, что система от задержки очухается и успеет наверстать упущенное и разгрести данные, накопившиеся за время задержки, без потери производительности.

Существуют всякие расширения под Windows, которые позволяют частично имплементировать realtime. Например, операционные системы On Time, RTX64 от IntervalZero и прочие. Они сводятся к одной и той же идее: мы отбираем у Винды одно или несколько ядер и кусок памяти, делаем вид, что их в компьютере больше нет, и запускаем на них свою собственную операционку. После того, как этот монстр Франкенштейна раскочегарится и выйдет на рабочий режим, на компьютере будут работать одновременно две операционных системы: realtime и Windows. Между ними можно настроить общение. Это решение будет работать с двумя оговорками: во-первых, из-под Windows практически нет возможностей повлиять на то, что происходит внутри запущенной параллельно realtime ОС, (например, программы для неё надо компилировать при помощи проприетарной SDK; нельзя во время работы передать в неё свою собственную программу для обработки получаемых данных и запустить её), а во-вторых, стоимость этого решения, мягко говоря, неадекватна. Лицензия разработчика RTX64 стоит порядка 10 тысяч долларов, а за каждый экземпляр готового продукта, ушедшего клиенту (тому самому нейрохирургу), придётся заплатить ещё 500 долларов. Вдобавок к 600-долларовой лицензии на Винду, которую клиент тоже получит. Это выводит общую стоимость продукта из зоны конкурентоспособности и делает его финансово непривлекательным для потенциальных покупателей.

За десять тысяч долларов плюс неустановленное количество 500-долларовых лицензионных платежей я сам себе RTOS под Windows напишу, подумал я. И написал.

Применённые технические хитрости

1. Во-первых, нам нужно, чтобы как можно больше работы выполняла наша плата с FPGA на борту. Скажем, передачу данных лучше перевесить на неё: у неё DMA-контроллер точно ничем не будет занят, нет шансов, что, когда нам потребуется DMA-канал, Винда скажет нам в ответ «в очередь, линуксьи дети, в очередь!»

   Как подключать FPGA к PCIe так, чтобы DMA писал данные, куда надо, это совсем-совсем отдельная тема, которая выходит за рамки данной статьи. Скажу только, что FPGA должен быть сконфигурирован как PCIe Endpoint, потому что компьютер остаётся Root Complex, — ему ведь ещё видеоадаптером управлять. При этом, раз DMA запускается платой, то и трансляция адресов должна выполняться на плате. И тут возникает вопрос: а куда плата будет писать? Изнутри Windows я могу работать только с виртуальными адресами. Даже если я выделю реальную память при помощи MmAllocateContiguousMemory, я получу только виртуальный адрес, достучаться до которого плата не сможет.

   Так что совсем без решений Франкенштейна обойтись не удалось. Я резервирую кусок физической памяти на компьютере для использования только нашим устройством, выполнив в командной строке от Администратора команду следующего вида:

   bcdedit /set removememory Х(Х — сколько мегабайт зарезервировать)

   Таким образом, последние мегабайты скрыты от Windows, и обращаться к ним Винда не может. Помимо гарантии отсутствия столкновений на memory bus, таким образом решается ещё несколько проблем, в частности, отсутствует нужда в синхронизации доступа, что лишает меня необходимости использовать долгие и медленные семафоры и мьютексы. (Синхронизацию между записью данных в память и чтением можно осуществлять по времени: пусть плата пишет в пять буферов с разницей в 200 микросекунд; зная, что в нулевой буфер она писала в целое число миллисекунд, я буду читать буферы с отставанием на один: в целую миллисекунду — четвёртый, в миллисекунду и 200 микросекунд — нулевой, в миллисекунду и четыреста микросекунд — первый, и так далее. Как синхронизировать время на уровне микросекунд между двумя устройствами — задача, при наличии канала связи между ними, решаемая).

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

   /*
    * The ID of the PCI driver CPU core. Starting from 0.
    */
   static constexpr USHORT DRIVER_CPU_ID = 3;
   . . . .
   // Set the thread to run on specific processor
   KAFFINITY affinity = 1ULL << (DRIVER_CPU_ID);
   KeSetSystemAffinityThread(affinity);

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

   // Set the thread priority to the highest available -1
   // Тhe "-1" is because running for a long time in HIGH_PRIORITY
   // "starves" important system tasks which run in HIGH_PRIORTY
   KeSetPriorityThread(PsGetCurrentThread(), HIGH_PRIORITY - 1);

3. Но этого недостаточно. Нужно не только чтобы этот процесс бежал на одном ядре, но и чтобы никакой другой процесс на этом ядре не бежал. Для этого я поднимаю приоритет прерываний, которые могут прервать выполнение моего процесса (KIRQL), до максимального (DISPATCH_LEVEL):

   KIRQL oldIrql;
   KeRaiseIrql(DISPATCH_LEVEL, &oldIrql);

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

   // It's important that we don't stay at DISPATCH_LEVEL for too long
   // so we record the last tick we were at passive, and every once in
   // a while lower the KIRQL
   static constexpr ULONG64 MS_ALLOWED = 50;
   LARGE_INTEGER freq{};
   LONGLONG lastPassiveTick = 0;
   . . . . . .
   KeQueryPerformanceCounter(&freq);
   timePassed = ((KeQueryPerformanceCounter(nullptr).QuadPart - 
                               lastPassiveTick) * 1000ULL) / freq.QuadPart;
   if (timePassed >= MS_ALLOWED) {
       yieldProcessor();
       lastTickAtPassive = KeQueryPerformanceCounter(nullptr).QuadPart;
   }
   
   /* Yield Processor means lowering to PASSIVE_LEVEL and then raising back
    * to DISPATCH_LEVEL. It allows other important tasks to run in between,
    * if they are fast enough.
    */
   void yieldProcessor() {
       KIRQL oldIrql;
       KeLowerIrql(PASSIVE_LEVEL);
       KeRaiseIrql(DISPATCH_LEVEL, &oldIrql);
   }

4. А теперь самое весёлое.

   При инициализации драйвера я прохожу по всем имеющимся в операционной системе процессам и меняю их привязку к процессору:

namespace accelerator {
	class IAccelerator {
	public:
		explicit IAccelerator() = default;
		virtual void revert() = 0;
		virtual void accelerate() = 0;
		virtual ~IAccelerator() = default;
	};
}


namespace accelerator {

const std::vector<std::wstring> DEFAULT_BLACKLIST_PROCESSES = {
	L"system",
	L"system.exe",
	L"winlogon.exe"
};

class AffinitySetter : public IAccelerator {
public:
	/**
	 * Sets the processor affinity of all processes.
	 *
	 * Affinity is reset upon reseting the computer.
	 *
	 * @param activeCpuIdentifiers The cpu identifiers which should NOT be used by any process.
	 * @param blacklistProcesses A list of processes that should not be altered.
	 *
	 */
	explicit AffinitySetter(std::vector<uint8_t> activeCpuIdentifiers,
							std::vector<std::wstring> blacklistProcesses = DEFAULT_BLACKLIST_PROCESSES);
	virtual void revert();
	virtual void accelerate();
	virtual ~AffinitySetter() = default;
private:
	ULONG_PTR getAffinityMaskWithoutBlackList(ULONG_PTR maskLimit);
	std::vector<uint8_t> m_activeCpuIdentifiers;
	std::vector<std::wstring> m_blacklistProcesses;
  };
}

. . . . . . .
std::vector<std::unique_ptr<accelerator::IAccelerator>> accelerators;
auto affinitySetter = std::make_unique<accelerator::AffinitySetter>(
    std::vector<uint8_t>({ DRIVER_CPU_ID }));
accelerators.push_back(std::move(affinitySetter));
for (auto& accelerator : accelerators) {
	  accelerator->accelerate();
}

1. Но и это ещё не всё. Мало позаботиться о тех процессах, которые уже есть, надо ещё позаботиться о тех, которые пользователь создаcт в будущем. Для этого я регистрирую два системных коллбэка, на создание процесса и на создание потока; они вызываются для каждого нового процесса и потока, и я меняю их привязку к процессору:

   /*
    * We want to keep this core to ourself, so register a callback for each
    * process and thread created. At this callback we change their affinity
    * (the core they can run on) to be different from our core
    */
   if (!NT_SUCCESS(PsSetCreateProcessNotifyRoutine(newProcessCreated, FALSE))) {
       DEBUG_TRACE("PsCreateProcessNotifyRoutine failed");
       COMPLETE_IRP(Irp, STATUS_UNSUCCESSFUL);
   }
   FINALLY([&guardActivator]() {
       if (guardActivator) {
           PsSetCreateProcessNotifyRoutine(newProcessCreated, TRUE);
       }
   });
   
   if (!NT_SUCCESS(PsSetCreateThreadNotifyRoutine(newThreadCreated))) {
       DEBUG_TRACE("PsCreateProcessNotifyRoutine failed");
       COMPLETE_IRP(Irp, STATUS_UNSUCCESSFUL);
   }
   FINALLY([&guardActivator]() {
       if (guardActivator) {
           PsRemoveCreateThreadNotifyRoutine(newThreadCreated);
       }
   });
   . . . . . .
   
   void newProcessCreated(
       HANDLE ParentId,
       HANDLE ProcessId,
       BOOLEAN Create
   )
   {
       UNREFERENCED_PARAMETER(ParentId);
       if (Create) {
           KAFFINITY affinity = ~((1ULL << (DRIVER_CPU_ID)));
           KAFFINITY maximumAffinity = KeQueryActiveProcessors();
           affinity &= maximumAffinity;
   
           // Get process handle by id
           HANDLE processHandle;
           OBJECT_ATTRIBUTES objectAttributes{ 0 };
           InitializeObjectAttributes(&objectAttributes, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);
           CLIENT_ID clientid{ 0 };
           clientid.UniqueProcess = ProcessId;
           auto status = ZwOpenProcess(&processHandle, GENERIC_ALL, &objectAttributes, &clientid);
           if (!NT_SUCCESS(status)) {
               DEBUG_TRACE("ZwOpenProcess failed getting process for pid %d with status %d", ProcessId, status);
               return;
           }
           FINALLY([&processHandle]() {
               ZwClose(processHandle);
           });
   
           // Set the process affinity by handle
           DEBUG_TRACE("Will set process affinity: %d for process: %d", affinity, ProcessId);
   
           if (affinity) {
               status = ZwSetInformationProcess(processHandle, ProcessAffinityMask, &affinity, sizeof(affinity));
               if (!NT_SUCCESS(status)) {
                   DEBUG_TRACE("ZwSetInformationProcess failed getting process affinity for pid %d with status %d", ProcessId, status);
                   return;
               }
           }
   
       }
   }
   
   void newThreadCreated(
       HANDLE ProcessId,
       HANDLE ThreadId,
       BOOLEAN Create
   )
   {
       if (Create) {
           // Thread affinity should eventually be all cpus except our own.
           KAFFINITY affinity = ~((1ULL << (DRIVER_CPU_ID)));
           KAFFINITY maximumAffinity = KeQueryActiveProcessors();
           affinity &= maximumAffinity;
   
           // Get process handle by id
           HANDLE processHandle;
           OBJECT_ATTRIBUTES objectAttributes{ 0 };
           InitializeObjectAttributes(&objectAttributes, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);
           CLIENT_ID clientid{ 0 };
           clientid.UniqueProcess = ProcessId;
           auto status = ZwOpenProcess(&processHandle, GENERIC_READ, &objectAttributes, &clientid);
           if (!NT_SUCCESS(status)) {
               DEBUG_TRACE("ZwOpenProcess failed getting process for pid %d with status %d", ProcessId, status);
               return;
           }
           FINALLY([&processHandle]() {
               ZwClose(processHandle);
           });
   
           // Get the process affinity by handle
           PROCESS_BASIC_INFORMATION processInformation;
           ULONG returnLength;
           status = ZwQueryInformationProcess(processHandle, ProcessBasicInformation, &processInformation, sizeof(processInformation), &returnLength);
           if (!NT_SUCCESS(status)) {
               DEBUG_TRACE("ZwQueryInformationProcess failed getting process for pid %d with status %d", ProcessId, status);
               return;
           }
   
           // Reduce affinity to by subset of process
           affinity &= processInformation.AffinityMask;
   
           // Get thread handle by id
           HANDLE threadHandle;
           objectAttributes = { 0 };
           InitializeObjectAttributes(&objectAttributes, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);
           clientid = { 0 };
           clientid.UniqueThread = ThreadId;
           status = ZwOpenThread(&threadHandle, GENERIC_ALL, &objectAttributes, &clientid);
           if (!NT_SUCCESS(status)) {
               DEBUG_TRACE("ZwOpenThread failed getting thread for tid %d with status %d", ProcessId, status);
               return;
           }
           FINALLY([&threadHandle]() {
               ZwClose(threadHandle);
           });
   
           // Set the thread affinity by handle
           DEBUG_TRACE("Will set thread affinity: %d for thread: %d", affinity, ThreadId);
   
           if (affinity) {
               status = ZwSetInformationThread(threadHandle, ThreadAffinityMask, &affinity, sizeof(affinity));
               if (!NT_SUCCESS(status)) {
                   DEBUG_TRACE("ZwSetInformationThread failed getting thread affinity for tid %d with status %d", ProcessId, status);
                   return;
               }
           }
       }
   }

   Надо только не забыть убрать эти коллбэки при окончании работы.

Заключение

По факту, я реализовал систему, работающую в реальном времени, внутри Windows. Техника, в общем-то, такая же, как у коммерческих решений типа вышеупомянутой On Time: я забираю под свои цели ядро и часть памяти и не позволяю Windows добираться до них и мешать мне. Но есть и отличие: моё решение работает внутри Windows, в пространстве ядра, и позволяет пользоваться всеми преимуществами операционной системы. Я не ограничен в общении с остальными программами операционной системы и могу использовать весь набор средств для межпроцессного взаимодействия. Более того, я могу вернуть занятое драйвером ядро обратно Windows в любой момент, достаточно только убрать мои коллбэки и пройтись по процессам, исправляя их привязки.

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

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

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

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

У конструкторов могут возникнуть сложности в определении продолжительности наихудших задержек ISR или DPC стандартных устройств. Даже после тестирования конструктор не может гарантировать, что частный случай в живой системе не заставит эту систему пропустить критический срок. Более того, суммарное значение всех задержек системных DPC и ISR может существенно превышать значение, допустимое для чувствительной ко времени системы.

Хотя требования реального времени есть у многих типов встроенных систем (например, у принтеров и автомобильных компьютеров), у Windows Embedded Standard 7 характеристики реального времени отсутствуют. Это просто одна из разновидностей Windows 7, позволяющая выпускать компактные версии этой операционной системы, подходящие для запуска на устройствах с ограниченными ресурсами. Например, устройство без сетевых возможностей опустит все компоненты Windows 7, связанные с работой в сети, включая средства управления сетью, а также адаптер и драйвера устройств стека протокола.

Кроме того, существуют сторонние производители, поставляющие для Windows ядра реального времени. Подход, используемый ими, заключается во встраивании их ядра реального времени в специализированный HAL и в принуждении Windows запускаться в качестве задачи в операционной системе реального времени. Задача, запускающая Windows, служит в качестве пользовательского интерфейса к системе и имеет более низкий приоритет по сравнению с задачами, ответственными за управление устройством.

Связывание ISR с конкретным уровнем прерывания называется подключением объекта прерывания, а разобщение ISR и записи IDT называется отключением объекта прерывания. Эти операции, выполняемые путем вызова функций ядра IoConnectInterruptEx и IoDisconnectInterruptEx, позволяют драйверу устройства «включать» ISR при загрузке драйвера в систему и «выключать» ISR, если драйвер выгружается.

Использование объекта прерывания для регистрации ISR препятствует тому, чтобы драйверы устройства возились непосредственно с аппаратными средствами прерывания (имеющими отличия, связанные с архитектурами процессоров), и избавляет от необходимости знать обо всех подробностях IDT. Это свойство ядра помогает в создании переносимых драйверов устройств, поскольку оно исключает необходимость программировать на языке ассемблера или отражать разнообразие процессоров в драйверах устройств.

Объекты прерываний предоставляют также и другие преимущества. За счет использования объекта прерывания ядро может синхронизировать выполнение ISR с другими частями драйвера устройства, которые могут использовать с IRS общие данные.

Более того, объекты прерываний позволяют ядру легко вызывать более одной ISR-процедуры для любого уровня прерывания. Если объекты прерываний создаются несколькими драйверами устройств и подключаются к одной и той же записи IDT, диспетчер прерываний вызывает каждую процедуру при возникновении прерывания на указанной линии прерывания.

Эта возможность позволяет ядру легко поддерживать конфигурации, составленные из последовательных цепей, в которых несколько устройств совместно используют одну и ту же линию прерывания. Цепь прерывается, когда одна из ISR-процедур заявляет о правах собственности на прерывание, возвращая статус диспетчеру прерываний.

Если одновременного обслуживания требуют несколько устройств, использующих одно и то же прерывание, то, как только диспетчер прерываний снизит IRQL, устройства, не получившие подтверждения от своих ISR-процедур, снова выставят прерывание системы. Выстраивание в цепочку будет разрешено, только если все драйверы устройств, ожидающие использования одного и того же прерывания, покажут ядру, что они могут совместно использовать это прерывание; если они этого сделать не могут, диспетчер устройств Plug and Play перестроит назначение прерываний, чтобы учесть требования по общему использованию прерываний каждого устройства. При наличии общего вектора прерывания объект прерывания вызывает функцию KiChainedDispatch, которая по очереди вызовет ISR-процедуры каждого зарегистрированного объекта прерывания, пока одна из них не заявит права на прерывание или пока все они не будут выполнены. В показанном выше примере вывода команды !idt вектор 0xa2 подключен к нескольким выстроенным в цепочку объектам прерываний.

Так сложилось, что на системе, где была запущена команда, этот вектор соответствовал встроенному карт-ридеру 7-в-1, представляющему собой комбинацию из устройств чтения флеш-карт Secure Digital (SD), Compact Flash (CF), MultiMedia Card (MMC) и карт других типов, и у каждого устройства имелось свое собственное прерывание. Поскольку они были сгруппированы производителем в одно устройство, вполне разумно было его прерываниям использовать один и тот же вектор.

Сравнение прерываний на основе использования линий и прерываний, инициируемых сообщениями.

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

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

Еще одна проблема, связанная с генерированием прерываний по IRQ-линии, заключается в том, что неправильное управление IRQ-сигналом может привести к недопустимому пику прерываний (interrupt storms) или к возникновению других разновидностей взаимных блокировок, поскольку пока ISR-процедура не подтвердит получение сигнала, он выставляется на «высоком» или «низком» уровне. Более того, контроллер прерываний должен, как правило, получать также и сигнал завершения прерывания EOI.

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

Решением всех этих проблем является новый механизм прерываний, который впервые был представлен в стандарте PCI 2.2 под именем прерываний, инициируемых сообщениями (Message-signaledinterrupts, MSI). Хотя этот механизм остается необязательным компонентом стандарта, редко встречающимся на клиентских машинах, поддержка MSI, полностью поддерживаемая всеми последними версиями Windows, все чаще реализуется на серверах и рабочих станциях. В MSI-модели устройство доставляет сообщение своему драйверу, записывая его по конкретному адресу памяти.

Это действие вызывает прерывание, а затем Windows вызывает ISR-процедуру с содержимым сообщения (значением) и адресом, по которому оно было доставлено. Устройство также может доставить по адресам памяти несколько сообщений (до 32), предоставляя на основе события различную полезную информацию.

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

И наконец, во вводимое в PCI 3.0 расширение MSI-модели MSI-X добавляется поддержка 32-разрядных сообщений (вместо 16-разрядных) с максимумом в 2048 различных сообщений (вместо всего лишь 32), и, что более важно, возможность использования другого адреса (который может определяться в динамическом режиме) для каждой полезной информации MSI. Использование другого адреса позволяет записывать полезную информацию MSI в другой физический диапазон адресов, который принадлежит другому процессору или другому набору целевых процессоров, что дает возможность эффективно использовать технологию доставки прерывания, осведомленного о доступе к неоднородной памяти (nonuniform memory access, NUMA) тому процессору, который инициировал связанный с этим прерыванием запрос к устройству. Это улучшает время ожидания и масштабируемость путем контролирования во время завершения прерывания и загруженности, и расположения ближайшего NUMA-узла.

2006 г. Операционные системы реального времени И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко Препринт Института системного программирования РАН Назад Оглавление Вперёд 2.5. Расширения реального времени для Windows NT Windows NT проектировалась и, в основном, используется как универсальная ОС. Однако на рынке систем реального времени четко прослеживается тенденция использовать Windows NT и ее расширения в специализированных системах. На это существует несколько причин: Windows NT проектировалась согласно современным технологиям построения ОС, программный интерфейс приложений (API) для Win32 стал де-факто стандартом для программистов, графический пользовательский интерфейс (GUI) стал настолько популярным, что другие ОС стараются обеспечить похожий интерфейс, доступно большое количество драйверов устройств, доступны многие мощные интегрированные среды разработки. Сама по себе Windows NT не подходит для применения в системах реального времени, поскольку в ней слишком мало приоритетных уровней, отсутствует механизм наследования приоритетов. Для минимизации времени обработки прерываний (ISR) в Windows NT введена концепция отложенного вызова процедуры (DPC – deferred procedure call), приоритет которой выше, чем приоритет пользовательских и системных потоков, в то время как все DPC имеют одинаковый приоритет. Это приводит к тому, что все DPC ставятся в очередь FIFO, и DPC с высокоуровневым прерыванием сможет выполниться только после того, как все другие DPC, стоящие в очереди перед ней, будут выполнены. Такие ситуации ведут к непредсказуемым временам отклика, что несовместимо с требованиями к ОСРВ. Управление памятью в Windows NT основано на механизме виртуальной памяти. Это тянет за собой защиту памяти, трансляцию адресов и подкачку, которая неприемлема в ОСРВ. 2.5.1. RTX для Windows NT Расширение реального времени RTX (Real Time Extension) для ОС Windows NT (разработано корпорацией VenturСom) позволяет создавать приложения для высокоскоростного управления с детерминированным временем реакции на внешние события [RTX]. RTX глубоко интегрировано в ядро Windows NT и для обеспечения необходимых функций использует сервис Windows NT и API WIN32. Ядро реального времени (nucleus) интегрировано в ядро NT (kernel). Каждый процесс RTX выполняется как драйвер устройства ядра NT, при этом процессы не защищены друг от друга. Такая реализация приводит к быстрому переключению контекста, но небезопасна с точки зрения конфиденциальности. Расширения реального времени добавляют к Windows NT специфическую для реального времени функциональность. Обеспечивается возможность создавать процессы реального времени, управляемые собственным планировщиком. Этот планировщик работает уже по правилам реального времени и использует алгоритм вытеснения по приоритетам. Кроме того, процессы реального времени имеют преимущество перед стандартными процессами Win32, вытесняя их. Процессы реального времени имеют совсем иную, по сравнению со стандартными процессами Windows NT, степень надежности и специфическую функциональность. Процессы реального времени и стандартные процессы Win32 имеют средства взаимодействия друг с другом. Процессы реального времени имеют свой собственный программный интерфейс RTAPI, реализующий развитый набор средств, характерный для программных интерфейсов (API) ОСРВ. Приложение может использовать как стандартные функции Win32, так и специфические функции API реального времени (RTAPI), что позволяет выделять критические участки кода приложений Windows NT и контролировать время и надежность их выполнения. Имеется возможность контроля над работоспособностью и временами реакции системы. Зависания стандартных приложений Windows NT или крах системы не приводят к зависанию приложений реального времени. Предоставляется возможность работы с быстрыми часами и таймерами высокого разрешения. Обеспечивается возможность прямого доступа к памяти и физическим устройствам. RTX включает в себя следующие компоненты: уровень абстракции аппаратуры HAL (Hardware Abstraction Layer) реального времени (Real-Time HAL). HAL является программным компонентом самого низкого уровня при взаимодействии драйверов ядра с аппаратурой. В частности, именно на уровне HAL происходит первоначальная обработка прерываний от таймера, подсистему реального времени RTSS (Real-Time Subsystem), программный интерфейс расширений реального времени RTAPI (Real-Time Application Programming Interface). HAL реального времени подменяет стандартный HAL Windows NT. Подсистема реального времени RTSS обеспечивает выполнение большинства функций и управление ресурсами расширений реального времени. С точки зрения реализации, RTSS выглядит как драйвер Windows NT и выполняется в режиме ядра. Это позволяет достаточно простым способом устроить взаимодействие между процессами реального времени и процессами Windows NT. RTSS обеспечивает выполнение функций RTAPI и содержит планировщик потоков реального времени со 128-ю фиксированными приоритетами. RTSS содержит также менеджер объектов, предоставляющий унифицированные механизмы использования системных ресурсов. По сравнению с набором объектов Windows NT, добавлены такие объекты, как таймеры и обработчики прерываний. Работа с прерываниями Real-Time HAL. Перехватывая аппаратные прерывания, Real-Time HAL различает прерывания, относящиеся к обработчикам реального времени и обработчикам Windows NT. Прерывания, которые должны обрабатываться драйверами Windows NT, отправляются по стандартной цепочке. При этом Real-Time HAL следит за тем, чтобы прерывания не маскировались драйверами Windows NT более чем на 5 мкс, исключая возможность пропуска критического события. Быстрые часы и таймерные службы. Для измерения временных интервалов или для генерации прерываний Real-Time HAL позволяет работать с тиккером, разрешение которого 1 мкс. Системный таймер синхронизирован с тиккером, и может работать с периодом 100 мкс или быстрее, обеспечивая работу как стандартных таймерных сервисов, так и дополнительных, входящих в состав подсистемы реального времени. Поддержка подсистемы реального времени (RTSS). Кроме перечисленных выше функций (прерывания и таймеры), Real-Time HAL содержит поддержку функционирования всей подсистемы реального времени. Так, на основе прерываний от таймера строится диспетчер процессов реального времени. Real-Time HAL отвечает также за выполнение функций ввода-вывода подсистемы реального времени и пр. Программный интерфейс реального времени RTAPI является расширением Win32 и содержит, прежде всего, набор функций, необходимых для управления устройствами. RTAPI реализован в двух видах – как подмножество вызовов подсистемы реального времени (RTSS) и как динамическая библиотека (DLL), которая может вызываться из Win32-приложений. RTAPI содержит следующие группы функций: управление процессами и потоками – предоставляет Win32-совместимый интерфейс для управления, создания, изменения приоритетов, профилирования и завершения потоков реального времени, управление объектами RTSS – предоставляет возможности унифицированного управления объектами RTSS (создание, закрытие, доступ). Объектами RTSS являются: таймеры, обработчики преры-ваний и исключительных ситуаций (startup, shutdown, blue screen), потоки, процессы, семафоры, мьютексы (mutex), разделяемая память, почтовые ящики, консольный и файловый ввод-вывод, регистры. Взаимодействие между процессами. В RTAPI используются семафоры, мьютексы и разделяемая память для взаимодействия как потоков реального времени между собой, так и для их взаимодействия с процессами WIN32. Управление памятью позволяет фиксировать приложения в памяти, запрещая их выгрузку в файл подкачки. Доступ к физической памяти: приложение пользователя получает возможность доступа к данным по физическим адресам памяти. Управление прерываниями позволяет назначать и запрещать обработчики прерываний, разрешать и запрещать прерывания. Управление часами и таймерами разрешает создавать, удалять, отменять, инициализировать таймеры, назначать обработчики прерываний. Управление вводом-выводом RTAPI предоставляет два способа управления устройствами ввода-вывода. Во-первых, приложения пользователя получают возможность непосредственного доступа к адресам портов ввода-вывода, что позволяет программировать работу устройств напрямую. Кроме того, внешнее устройство может управляться специальными (легко разрабатываемыми) драйверами, для работы с которыми RTAPI предоставляет специальный интерфейс. 2.5.2. INtime Система INtime является расширением реального времени Windows, которое было разработано корпорацией Radisys Corporation, а в настоящее время поддерживается корпорацией TenAsys [INTIME]. INtime комбинирует возможности ОСРВ жесткого реального времени со стандартными ОС Windows, включая Windows XP, Windows XP Embedded, Windows 2000, Windows NT и Windows NT Embedded, не требуя дополнительной аппаратуры. INtime специально разработана под архитектуру процессора x86. Приложения реального времени и не реального времени выполняются на разных виртуальных машинах на единственном компьютере (см. рис. 4). INtime, в отличие от RTX, слабо связана с NT. Архитектура INtime основана на механизме аппаратного обслуживания задач (hardware tasking), которое обеспечивается процессором Intel. Получается, что два ядра выполняются на одной аппаратуре. Поскольку они разделяют одну аппаратуру, потребовались некоторые модификации NT HAL. Такой подход позволяет защитить и отделить среду выполнения и область памяти от Windows. Внутри INtime каждый процесс приложения имеет свое собственное адресное пространство. Кроме того, ядро и приложения выполняются на разных приоритетных уровнях, что позволяет защитить их друг от друга. INtime показывает предсказуемое поведение, однако ее сложная архитектура не позволяет достичь системе хорошей производительности. Из-за сегментационных ограничений INtime подходит не для всех систем реального времени. Рис. 4. Структура INtime. 2.5.3. Microsoft Windows Embedded Операционные системы Microsoft Windows Embedded для встраиваемых систем имеют две разновидности в соответствии с версиями ОС Windows – NT и XP [MSEmb]. Версии систем Embedded корпорации Microsoft состоят из многочисленных конфигурируемых частей, которые позволяют легко манипулировать набором установленного программного обеспечения. Windows NT Embedded использует технические ресурсы Windows NT и позволяет разрабатывать приложения, которые могут быть легко интегрированы в существующую информационную инфраструктуру. Набор средств разработки – Target Designer и Component Designer – позволяет OEM (original equipment manufacturer) производителям конфигурировать и создавать операционную систему для конкретной аппаратной платформы. Windows NT Embedded обладает специфическими компонентами для создания встраиваемых систем, которые позволяют работать в системах без видеоадаптера, осуществлять загрузку и работу накопителей в режиме «только чтение», выполнять удаленное администрирование и предоставляют дополнительные средства обработки ошибок и восстановления. Windows NT Embedded дает возможность создавать устройства, с которыми работать так же просто, как и со стандартными ПК на основе Windows, и управлять этими новыми устройствами на основе существующих профессиональных продуктов, таких как Microsoft Systems Management Сервер, HP OpenView, IBM Tivoli, CA Unicenter TNG, и др. Рис. 5. Процесс разработки встраиваемого ПО на основе Windows NT Embedded. Разработчик встраиваемых систем применяет для конфигурирования ОС Target Designer, используя готовый двоичный код Windows NT, дополнительные компоненты для встраивания и дополнительные приложения. В случае необходимости, для создания новых компонентов, не входящих в состав продукта (например, драйверов устройств, приложений и пр.), может использоваться Component Designer. Вновь созданные новые компоненты могут быть импортированы в Target Designer и включены в состав целевой ОС. После конфигурирования ОС с помощью Target Designer происходит проверка взаимосвязей компонентов и строится образ системы, готовый к загрузке и исполнению на целевой системе. Windows XP Embedded насчитывает до 10000 отдельных компонентов, а в Windows NT Embedded их было чуть больше 300. Основной отличительной чертой Windows XP Embedded является четкое разграничение компонентов системы, что позволяет разработчикам встраиваемого набора функций при создании образа системы включать только необходимые файлы и максимально сократить размер результирующей системы. Этими компонентами служат отдельные части системы Windows XP Professional. Компоненты Windows XP Embedded представлены сервисами, приложениями, библиотеками и драйверами – разработчику нужно сконфигурировать необходимый набор функций и собрать из компонентов необходимую конфигурацию в образ среды исполнения (runtime image). Все опции конфигурации собраны воедино в базу данных компонентов. Разработчик имеет к ней доступ и может ее редактировать с помощью специального инструмента – Component Database Manager. Для каждого компонента в процессе создания определяется ряд параметров: платформа, на которой будет выполняться данный компонент (определяет порядок компиляции и сборки); описание и схема подключения компонента; список ассоциированных ресурсов, таких как файлы и ключи реестра; зависимости компонента от других компонентов (например, от DirectX или NET runtime); указатель на хранилище файлов (чаще всего это просто локальный каталог, но может быть и сетевым ресурсом); принадлежность к группе для упрощения обращения сразу к нескольким компонентам как к целому. Сама база данных управляется СУБД MS SQL Server и может быть расположена как локально, на компьютере разработчика, так и на сервере. Назад Оглавление Вперёд