Общие принципы построения систем ЧПУ. Признаки нового поколения систем ЧПУ

Очередная смена поколений существенно меняет потребительские свой­ства, структуру, архитектуру и математическое обеспечение систем ЧПУ. Огромный опыт, накопленный в области ЧПУ мехатронными системами, серьезно пересматривается под давлением производителей мехатронного оборудования и конечных его пользователей. В свою очередь производи­тели систем ЧПУ прекрасно понимают, что простая эволюция традицион­ных решений приведет к потере рынка и полному их забвению. Внешние причины подобной ситуации состоят в увеличении разнообразия мехат- ронных систем, ориентированных на решение специфических задач (раз­нообразные технологические машины, роботы, испытательные стенды и др.), расширение зоны активности оператора мехатронного оборудования, росте привлекательности персональных систем ЧПУ типа PCNC. Однако есть и глубинная внутренняя причина - внедрение новой объектно-ориен­тированной технологии, без которой создание мультимегабайтного про­граммного обеспечения систем ЧПУ просто невозможно. Подобную тех­нологию используют не только на уровне программирования (для повы­шения надежности и обозримости математического обеспечения), но и на уровне макропроектирования системы: основные модули определяют как «вложенные объекты», отношения между которыми носят клиент-сервер­ный характер. Одним из вариантов общего решения является выделение глобального сервера-программной (виртуальной) шины, которая служит основным средством межмодульной коммуникации.

Принципиальной особенностью системы ЧПУ типа PCNC является ис­пользование открытой архитектуры, которая предполагает:

• конфигурирование системы у производителя мехатронного обору­дования и конечного пользователя;

• интеграцию покупных программных пакетов;

• эволюцию системы в условиях максимальной независимости от из­менений системной платформы;

• доступ к информации любого модуля, в том числе к диагностичес­кой информации самой мехатронной системы;

• подключение к внешней сетевой коммуникационной среде;

• использование в архитектуре системы принципов системной ин­теграции.

Остановимся более подробно на использовании принципов системной интеграции.

Известны принципы реализации тотального информационного серви­са на уровне предприятия, когда интегрируют многочисленные приложе­ния и коммерческие инструментальные средства (базы данных, CAD-CAM системы и др.), чтобы собрать целостную систему. При правильной орга­низации системной интеграции внимание концентрируют на доступе к данным, но не на структурах и типах этих данных.

Таким образом, возникает проблема доступа приложений к данным любого компонента производственной системы. Трудности состоят в бес­конечном множестве коммерческих и пользовательских приложений, рас­полагающих собственными интерфейсами и написанных на различных язы­ках программирования. Трудности могут быть преодолены на основе кон­цепции OLE/COM компании Microsoft. Эта концепция была использована при разработке европейского проекта ОРС. Цель проекта состояла в опре­делении стандартной клиент-серверной архитектуры и спецификаций СОМ-интерфейсов, обеспечивающих унифицированный доступ к данным, независимо от их типа и структуры. Таким образом, акцент был сде­лан на интеграцию, построенную на передаче данных (в том числе управля­ющих состояниями), а не на прямом управлении компонентами системы.

Обратимся теперь к области ЧПУ мехатронными системами. Основная задача при разработке систем типа PCNC нового поколения состоит в наи­более полном использовании принципов открытой архитектуры. Между­народные программы OSACA и другие не справились до конца с этой про­блемой. Между тем ее решение состоит в использовании лучших дости­жений системной интеграции больших систем. В самом деле, математическое обеспечение системы ЧПУ содержит оригинальные про­граммные компоненты производителя, компоненты, заказанные у других компаний, готовые коммерческие продукты, компоненты заказчика и конеч­ного пользователя. При этом система должна сохранять все признаки от­крытой архитектуры. В архитектуре PCNC с неменьшим успехом могут бьггь использованы принципы OLE/COM и некоторые спецификации ОРС, как при разработке отдельных модулей, так и на уровне макропроектирования всей системы в целом.

Модульная архитектура систем ЧПУна прикладном уровне

Архитектура на прикладном уровне определяется количеством и со­ставом прикладных разделов, называемых задачами управления. В числе подобных задач можно упомянуть:

• геометрическую, ориентированную на управление следящими при­водами;

• логическую, организующую управление электроавтоматикой;

• технологическую, гарантирующую поддержание или оптимизацию параметров технологического процесса;

• диспетчеризации, обеспечивающую управление другими задачами на прикладном уровне;

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

Структура системы ЧПУ (рисунок 4.8) представляет собой совокупность базовых модулей (обведены сплошными линиями) и дополнительных мо­дулей (обведены пунктирными линиями). Модули закреплены за за­дачами управления. К дополнительным модулям отнесены коммерческие приложения. Модуль автономен и является вложенным объектом: он рас полагает собственными алгоритмической структурой, структурой данных и интерфейсной оболочкой для работы в клиент-серверной среде. Общая структура представлена NC-подсистемой (Numerical Control) и РС-подси- стемой (Personal Computer). Первая формирует среду для ЧПУ ориентиро­ванных модулей, работающих в реальном времени, и (возможно) для спе­циальных приложений пользователя. Вторая подсистема образует среду Windows-образного интерфейса пользователя и включает инструменталь­ную систему подготовки и тестирования управляющих программ, а также (возможно) другие специальные приложения.

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

Структура, представленная на рисунке 4.8, обозначает набор модулей, по­зволяет специфицировать их интерфейсы, выявляет типы запросов, помога­ет составить техническое задание на объектно-ориентированную магистраль.

Рисунок 4.8- Модульная архитектура системы ЧПУ типа PCNC и задачи управления

Открытая архитектура систем управления

Гибкие и наиболее сложные системы ЧПУ с открытой архитектурой выполняют согласно двухкомпьютерной архитектурной модели. По мере роста вычислительной мощности компьютеров все более привле­кательным становится однокомпьютерный вариант.

Двухкомпьютерная модель предполагает размещение РС-подсистемы на одном компьютере, а NC-подсистемы - на другом. В РС-подсистеме наиболее целесообразна операционная система Windows NT, а в NC-под- системе - операционная система реального времени UNIX. Обе операци­онные системы совместимы в том смысле, что поддерживают коммуника­ционные протоколы TCP/IP. Это позволяет построить коммуникационную среду, объединяющую подсистемы. Включение в эту среду прикладного уровня с функциями доступа к интерфейсам модулей (а общее число та­ких функций может достигать нескольких сот) создает виртуальную шину, оказывающую низкоуровневые услуги доступа. Объектная надстройка в шине формирует глобальный сервер, т.е. единую для обеих подсистем объектно-ориентированную магистраль.

Однокомпьютерная модель предполагает использование традиционного компьютера, оснащенного дополнительными контроллерами для связи с мехатронными объектами управления. В их числе могут быть контроллер следящих приводов, программируемый контроллер PLC (Programmable Logic Controller), специальные устройства для управления технологичес­кими процессами и др. В качестве операционной может быть использова­на система Windows NT, которая, однако, не является системой реального времени и в этой связи требует соответствующего расширения, например в виде системы RTX 4.1 американской фирмы VentureCom.

Система RTX (Real Time eXtention) модифицирует слой HAL (Hardware Abstraction Layer) операционной системы Windows NT и дополняет его диспетчером потоков (threads) реального времени. Диспетчер изолирует прерывания, позволяя строить приложения реального времени, о существо­вании которых любые другие приложения не подозревают.

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

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

Разработанную с использованием RTX программу можно отлаживать и запускать также в среде Win32. Однако в RTX есть функции, не имеющие аналогов в Win32, например функции работы с прерываниями.

Архитектурные варианты, показанные выше, дают общее представ­ление о принципах открытой архитектуры применительно к ЧПУ: четкое разграничение между системным, прикладным и коммуникационным ком­понентами; возможность независимого развития любого из этих компо­нентов как на основе оригинальных разработок, так и путем встраивания покупных программных систем; клиент-серверная организация взаимодей­ствия подсистем; стандартизация интерфейсов и транзакций