ОС

Большая Часть Читателей технических журналов - мужчины, и они наверняка ее помнят. Необычайно красивая, волнующе привлекательная и (для тех, кому за 30) сделанная в ГДР. Что это? Конечно же, игрушечная железная дорога! Прямые и полукруглые рельсы, мосты и семафоры, электровозы и вагончики. Все это хозяйство замечательным образом оживало от прикосновения большой квадратной батарейки к контактам, растущим откуда-то из черной смолы. Управлять железной дорогой нужно было так, чтобы составы терпеливо ждали друг друга на стрелках, въезжали на вокзал с нужной стороны и не вываливали по дороге порой весьма негабаритных пассажиров.

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

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

Подсистема реального времени для Windows компании VenturCom - RTX (Real-Time eXtension) - представляет собой классическое ядро реального времени с собственным планировщиком, 128 фиксированными приоритетами для работы с потоками и Win32-совместимый API, позволяющий разрабатывать и исполнять приложения с помощью стандартных средств разработки на платформе Windows NT/2000. Задачи, выполняемые в подсистеме RTX, имеют абсолютный приоритет над всем происходящим в Windows и совместно используют только процессорное время.

Структура RTX для Windows

Что же должен сделать программист? Здесь выбора практически нет. Выделить необходимые системные ресурсы, назначить обработчики прерываний, определить потоки, ответственные за обработку данных, формат этих данных и завести кучу семафоров для обеспечения синхронизации работы всего приложения. Нелегкая задача в случае 5-10 потоков по обработке данных превращается в настоящий кошмар в системах с большим количеством устройств связи с объектом, если не прибегнуть к использованию программных средств по моделированию поведения процессов или других специализированных пакетов.

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

В идеале хотелось бы иметь следующее:

2 программное средство для создания, конфигурации и описания структур данных, с которыми потом должны работать как физические устройства, так и задачи по обработке данных;

2 виртуальные драйверы, умеющие взаимодействовать с такой базой данных и соответствующими физическими устройствами;

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

2 обеспечение детерминизма при чтении или записи элементов данных, т. е. такого режима работы, при котором операция чтения или записи одного элемента данных происходила бы в пределах заранее известного отрезка времени.

Для решения этой задачи компания VenturCom под давлением многочисленных пользователей выпустила в свет первую версию программного продукта DCX (Distributed Control and data eXchange), предназначенного для радикального снижения трудоемкости разработки систем реального времени традиционными средствами.

Базовая архитектура DCX

Рассмотрим по порядку основные принципы, на которых построена реализация DCX.    

Абстракция данных

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

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

Диспетчер DCX

Диспетчер берет на себя все функции по обеспечению эффективного и оперативного доступа к данным. Он экспортирует простой, строго определенный, не зависящий от платформы API для клиентов - приложений DCX. По утверждению разработчиков, поддержание данных в кэш-памяти, организуемой, по сути дела, в контексте вызывающего потока, гарантирует, что на стандартном ПК (Celeron 300) элементарная операция чтения или записи элемента данных происходит менее чем за 1 мкс. Разумеется, это верно лишь в случае чистого DCX-приложения, т. е. работающего под управлением RTX. Кроме обеспечения приложений доступом к данным, DCX также может организовывать каналы обмена данными между приложениями. В этом случае используется модель издатель/подписчик, когда в определенный момент одно приложение публикует данные (операция записи в элемент данных), а другое принимает их (операция чтения из элемента данных). В следующий момент эти роли могут измениться.

Что получается в результате? Идеализированный вариант железной дороги: клиент № 1 выдает диспетчеру заявку на доставку 1 т яблочного повидла в течение 1 мкс. Диспетчер принимает заявку, помещает груз в вагон соответствующего типа (цистерна), обеспечивает своевременную доставку и информирует получателя - клиента № 2. Операции чтения-записи могут быть, разумеется, множественными, т. е. происходить в одно и то же время, причем как в синхронном, так и в асинхронном режиме - либо “издатель” ждет завершения приема данных “подписчиком” и лишь затем публикует новые данные, либо поставляет их с той частотой, с которой считает нужным. Для поддержки этих режимов используется кэш-память данных в диспетчере.

OPC-сервер

Понятно, что наличие диспетчера DCX дает разработчику систем реального времени значительные преимущества, практически освобождая его от большинства рутинных задач синхронизации и доступа к данным. Но поскольку речь идет о системах на базе Windows, необходим также простой инструмент, обеспечивающий обычным Windows-программам доступ к данным DCX, пусть даже и не в реальном времени. Для решения этой задачи в DCX встроен так называемый OPC-сервер. OPC (OLE for Process Control) представляет собой спецификацию программного интерфейса для реализации драйверов обмена данными с промышленными устройствами на основе COM/DCOM технологий фирмы Microsoft. Любое приложение - OPC-клиент может обмениваться данными с OPC-сервером, разработанным сторонней компанией, в том случае, если и клиент, и сервер написаны в соответствии со спецификацией OPC. Данный стандарт также опирается на типизацию и структурирование данных, поэтому DCX разрабатывался на основе спецификаций OPC. Таким образом, добавление OPC-сервера в DCX было достаточно простой задачей и большинство приложений для промышленного применения, такие, например, как SCADA, могут обмениваться данными с системой DCX, обеспечивая возможность работы в режиме реального времени с Windows-приложениями без программирования.

DCX-редактор

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

Пример интерфейса редактора

Распределенные и отказоустойчивые конфигурации

 

Режим издатель/подписчик (а в DCX возможен также режим издатель/много подписчиков) предоставляет простую возможность для построения резервируемых систем в сетевых решениях при сохранении единой конфигурации DCX. В этом случае два или более издателя/подписчика, расположенные на разных узлах сети, взаимодействуют с одним элементом данных. Такой режим хотя и предусмотрен в DCX, но в текущей версии 1.1 не поддерживается и ожидается лишь в следующей версии, запланированной на первую половину 2000 г. Ключевым элементом сетевых решений должен стать новый протокол обмена данными между узлами, позволяющий достигать наибольшей скорости обмена данными. Предполагается, что такое решение, тесно интегрированное с COM/ DCOM, будет гарантировать не только высокое быстродействие, но и прозрачность и масштабируемость самих решений, независимо от того, где в сети расположены конкретные издатели/подписчики.

Кросс-платформность

Разработчики систем управления, остановившиеся на Windows как на программной платформе, в последнее время оказались перед дополнительным выбором: Windows NT Embedded (NTE), прекрасно подходящая для систем, требующих всей функциональности этой ОС, а главное, полной совместимости с огромным количеством существующих приложений, - или малогабаритная, модульная Windows CE, перенесенная на множество процессорных платформ, но имеющая пока ограниченную программную поддержку. DCX призван стать ключом к этой головоломке. Приложения, разработанные на основе DCX API, должны быть полностью переносимы между этими ОС, освобождая разработчика от тягостной необходимости жертвовать той или иной функциональностью при выборе платформы. Версия DCX для Windows CE должна появиться вскоре после выхода Windows CE 3.0, предназначенной для рынка систем реального времени и обладающей лучшими временными характеристиками по сравнению с ее предшественниками.

Получит ли DCX распространение - зависит от поддержки ОЕМ-производителями, которые должны поставлять DCX-совместимые драйверы со своей аппаратурой, но если вы разрабатываете достаточно сложные системы реального времени на платформе Windows, DCX может оказать существенную помощь.

К автору статьи можно обратится по телефону: (095) 465-6702 или по E-mail: rtsoft@rtsoft.msk.ru.

Драйверы DCX

Драйверы DCX выполняют роль, аналогичную роли драйверов любой другой операционной системы, отличаясь лишь организацией и механизмом исполнения. Прежде всего драйвер является не монолитной процедурой, осуществляющей инициализацию и работу с устройством самостоятельно, а, по существу, лишь некоторым набором базовых функций, вызываемых диспетчером DCX, который описан ниже. То есть разработчик драйвера, пользуясь специализированным API DCX, создает ряд процедур по управлению устройством и операциями чтения и записи и регистрирует при загрузке драйвера эти процедуры в диспетчере DCX. Таким образом, приложения DCX не могут и не должны самостоятельно обращаться к драйверам, а драйверы - к устройствам. Здесь необходимо отметить, что, поскольку DCX опирается на технологию RTX, создаваемые драйверы могут через простой API обращаться напрямую к аппаратуре. Это сильно облегчает их написание и гарантирует максимальное быстродействие.