авторефераты диссертаций БЕСПЛАТНАЯ  БИБЛИОТЕКА

АВТОРЕФЕРАТЫ КАНДИДАТСКИХ, ДОКТОРСКИХ ДИССЕРТАЦИЙ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ

Pages:   || 2 |

Теория и техника систем числового программного управления с открытой модульной архитектурой для автоматизации машиностроительного оборудования

-- [ Страница 1 ] --

На правах рукописи

Мартинов Георги Мартинов Теория и техника систем числового программного управления с открытой модульной архитектурой для автоматизации машиностроительного оборудования Специальность: 05.13.06 – Автоматизация и управление технологическими процессами и производствами (промышленность)

Автореферат диссертации на соискание ученой степени доктора технических наук

Москва - 2001 г.

Работа выполнена в Московском Государственном технологическом университете “СТАНКИН”

Научный консультант: доктор технических наук, профессор Сосонкин В. Л.

Официальные оппоненты: доктор технических наук, профессор Аршанский М. М.

доктор технических наук, профессор Горнев В. Ф.

доктор технических наук, профессор Фролов Е. Б.

Институт проблем управления РАН Ведущая организация

Защита состоится “” 2001 г. в _ часов на заседании диссертационного Совета Д 212.142.03 в Московском Государственном технологическом университете “СТАНКИН” по адресу: 101472, ГСП, Москва, Вадковский переулок, д. 1.

С диссертацией можно ознакомиться в библиотеке Московского Государственного технологического университета “СТАНКИН”.

Автореферат разослан “” _ 2001 г.

Ученый секретарь диссертационного Совета к.т.н. Е.Г. Семячкова

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

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

В результате комплекса исследований и разработок, выполненных при подготовке диссертации, созданы научные основы построения открытых модульных систем ЧПУ широкого назначения.

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

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

• снижение себестоимости, повышение надежности систем ЧПУ и обеспечение конкурентоспособности за счет возможности изменения компоновки и встраивания готовых коммерческих компонентов;

• сокращение времени разработки, настройки и адаптации систем ЧПУ за счет формализации процесса проектирования и инструментальной поддержки этого про цесса;

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

• разработать теоретические аспекты построения модульной архитектуры и моде ли систем ЧПУ типа PCNC;

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

• разработать теоретические аспекты построения диспетчера реального времени и коммуникационной среды для решения проблемы интеграции модулей системы PCNC;

• на базе теоретических и методологических знаний о построении открытой мо дульной системы ЧПУ разработать практические аспекты реализации модулей от крытой системы ЧПУ.

На защиту выносятся:

1. Результаты комплексного анализа вопросов создания открытых модульных сис тем ЧПУ.

2. Результаты теоретических исследований модульной архитектуры и моделей сис тем ЧПУ типа PCNC, результаты исследования задач диспетчирования в реальном времени и организации коммуникационной среды.

3. Результаты методологических разработок и экспериментальных исследований открытых систем ЧПУ.

4. Результаты практической разработки геометрической, логической, терминальной и диагностической задач систем ЧПУ.

Методы исследования. Теоретические исследования базировались на теории ин терфейсов, теории формальных грамматик, теории графов, теории конечных авто матов, теории алгоритмов;

на методах объектно-ориентированного проектирования (декомпозиции, абстракции, иерархии) и методах компонентного моделирования и OLE (Object Linking and Embedding) автоматизации.

Научная новизна работы заключается в следующем:

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

2. Созданы модели системы ЧПУ;

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



3. Разработаны теоретические основы формального построения компонентной COM-модели системы ЧПУ, которые позволяют с единых методологических позиций описывать COM-интерфейсы компонентов;

систематизирован базовый набор ин терфейсов.

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

5. Разработан теоретический базис для создания системы ЧПУ по типу открытого языкового процессора и для формирования системы команд этого процессора.

6. Разработаны теоретические аспекты построения диспетчера реального времени и коммуникационной среды PCNC-системы на базе объектно-ориентированного и компонентного подходов.

7. Разработаны методические аспекты и создано «ноу-хау» в области реализации геометрической, логической, терминальной и диагностической задач открытой сис темы ЧПУ, в том числе:

a) формализован процесс построения основных модулей геометрического ка нала системы ЧПУ, модуля интерпретации и модуля интерполяции;

b) предложен подход к формализации языка ISO-7bit, позволяющий проектиро вать такие модули систем ЧПУ, которые способны воспринимать любую версию языка программирования;

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

d) систематизированы и формализованы принципы построения интерфейса оператора;

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

Практическая ценность работы заключается:

• в разработке базовых понятий открытой модульной архитектуры систем ЧПУ ши рокого назначения;

• в разработке такой методики проектирования системы ЧПУ типа PCNC, которая обеспечивает:

a) возможность адаптации и настройки системы ЧПУ типа PCNC как к управ ляемому объекту, так и к технологическому процессу;

b) порождение версий систем ЧПУ без их перепрограммирования и перекомпи ляции;

динамическое изменение и реконфигурацию системы на основе стан дартного механизма компонентного подхода;

c) возможность использования стандартных средств операционной системы и расширения реального времени, а также коммерческих инструментальных средств разработки программного обеспечения системы ЧПУ типа PCNC;

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

Реализация работы. Научные и практические результаты внедрены:

• в Федеральном государственном унитарном предприятии «НИИ Автоэлектрони ка», в опытном производстве автотракторного электрооборудования.

• в учебной лаборатории кафедры “Компьютерные системы управления” МГТУ “СТАНКИН” при организации учебного процесса.

Кроме того, научные и практические результаты диссертации использованы при чте нии лекций и руководстве курсовыми и магистерскими работами на кафедре ком пьютерных систем управления МГТУ “СТАНКИН”;

а также в работе с аспирантами кафедры.

Апробация работы.

Теоретические и практические результаты, полученные автором, неоднократно до кладывались на заседаниях кафедры компьютерных систем управления, а также на конференциях, в том числе международных.

Работа выполнена в Университете «СТАНКИН» на кафедре компьютерных систем управления при научной консультации профессора д.т.н. Сосонкина В.Л.

Публикации. По материалам диссертации опубликованы 34 печатных работы.

Структура и объем диссертации. Диссертационная работа состоит из введения и пяти глав, изложенных на 211 страницах машинописного текста;

содержит 98 рисун ка, 17 таблиц и список литературы из 181 наименовании. Общий объем работы страниц.

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ

ВВЕДЕНИЕ Мелкие и средние фирмы, составляющие большинство в развитых странах, нужда ются в производствах, которые обладают структурной, функциональной и техноло гической гибкостью. Такие производства создают на базе оборудования с ЧПУ, так как только системы ЧПУ располагают потенциалом обеспечения гибкости на всех стадиях жизненного цикла: у производителя, станкостроителя и конечного пользова теля.

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

Большой вклад в разработку теоретических и практических аспектов управления технологическим оборудованием внесли российские и зарубежные ученые: Горнев В.Ф., Кутин А.А., Митрофанов В.Г., Павлов В.В., Соломенцев Ю.М., Сосонкин В.Л., Фролов Е.Б., Притчев Г. (Pritschow G.), Спур Г. (Spur G.), Сторр А. (Storr A.) и многие другие. Проблема создания систем ЧПУ нового поколения вышла за пределы внут рипроизводственных и отраслевых задач и превратилась в национальную и межго сударственную. Важность и актуальность этой проблемы подтверждается тем, что за последние несколько лет разработан ряд национальных и международных проектов, с целью создания систем ЧПУ нового типа. В американском проекте ОМАС, общеев ропейских проектах OSACA и OPC;

в немецком проекте HUMNOS, в японских проек тах IROFA и OSEC приняли участие десятки национальных и международных компа ний.

В рамках указанных проектов тенденции развития систем ЧПУ обозначены как ко ренное переосмысление потребительских свойств, структуры, архитектуры и мате матического обеспечения систем ЧПУ. В идеале любая современная система ЧПУ должна обладать открытой модульной архитектурой, в которой стандартизованы как отдельные модули, так и их интерфейсы. Подобная проблема до сих пор полностью решена не была. Именно персональные системы ЧПУ типа PCNC (Personal Com puter Numerical Control) относятся к принципиально новому поколению систем управ ления. Они допускают конфигурирование на всех этапах жизненного цикла, позво ляют интегрировать покупные программные продукты, обеспечивают непрерывную эволюцию в условиях максимальной независимости от базовой платформы, предос тавляют возможность доступа к информации о состояниях любого программного мо дуля системы, а также к диагностической информации аппаратуры, приводов и объ екта.

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

не выработаны принципы и методы формализации проектирования и разработки по добных систем, которые бы в полной мере отвечали широкому спектру требований производителей, станкостроителей и конечных пользователей систем ЧПУ.

1. Глава 1. Современные системы ЧПУ. Тенденции и проблемы развития Причины радикальных изменений потребительских свойств, структуры, архитектуры и математического обеспечения систем ЧПУ состоят: в резком повышении доли спе циального технологического оборудования;

в расширении активности оператора не посредственно в цеху;

в общем росте привлекательности персональных систем ЧПУ типа PCNC, поддерживающих такой стиль управления, который соответствует рабо те на компьютере. Однако есть и более глубокие причины: внедрение новых техно логий, как, например, технологии объектно-ориентированного программирования и COM-технологии (Component Object Model), без которых создание программного обеспечения систем ЧПУ в объеме многих мегабайт попросту невозможно.

1.1 Современные достижения в области ЧПУ, обусловленные потребностями рынка Оптимизация потребительских свойств машин, устройств и отдельных предметов, диктуемая рынком, неизбежно приводит к росту масштабов выпуска “нетехнологич ных” деталей. Анализ обработки нетехнологичных деталей на станках с ЧПУ выде лил такие особенности операций: сложные многомерные траектории инструмента, не укладывающиеся в привычные комбинации прямых и окружностей;

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

экзотические рабочие процессы с привлечением новейших техноло гий;

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

Эволюция систем ЧПУ привела к таким их потребительским свойствам, о которых несколько лет назад можно было только мечтать. Современные системы ЧПУ обес печивают скорости рабочей подачи до 60 м/мин и более, управляют обработкой по верхностей практически любой формы, реализуют нетрадиционные рабочие процес сы с привлечением новых технологий, используют новые типы интерполяции (сплайн-интерполяцию и ее разновидности), и сложные алгоритмы управления раз гоном и торможением и алгоритмы сглаживания траекторий (получившие наимено вание Look-a-head – опережающий просмотр), используют языки высокого уровня.

Системы ЧПУ предоставляют богатый сетевой сервис, начиная с простого подклю чения к внешней среде и вплоть до дистанционного диагностирования управления электроавтоматикой и приводами.

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

Современные тенденции построения систем ЧПУ нового поколения опираются на следующие особенности: аппаратная база предполагает технологические и стоимо стные преимущества персональных компьютеров;

программная реализация исполь зует все достоинства объектно-ориентированного подхода;

оператору предлагается привычный Windows-интерфейс;

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

структура управления построена на основе принципов многоканальности;

технологу-программисту предлагаются новые способы задания управляющих программ.

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

Свойства гибкости необходимы, но не достаточны для построения концепции систе мы ЧПУ с открытой архитектурой. К другим важным признакам такой системы отно сятся: стандартизация модульной архитектуры и базовых внутренних структур дан ных, определение модулей в виде гибких командных процессоров. Они определяют наиболее значимые направления, на которые ориентированы основные междуна родные проекты по системам управления.

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

уменьшение времени разработки и интеграции систем управления;

обеспечение открытости для технических изменений и развития систем;

снижение себестоимости и повышение надежности за счет использования стандартных PC-решений;

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

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

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

эволюция систем управления;

доступ к информации;

стандарти зация пользовательских интерфейсов;

включение системы в сетевую коммуникаци онную среду.

Система ЧПУ может развиваться в двух направлениях. Быстрое решение состоит в использовании объектно-ориентированного подхода с разработкой обширных биб лиотек классов, виртуальных структур и абстрактных уровней в иерархической мо дели системы. Перспективное решение состоит в привлечении СОМ-подхода, под разумевающего крупномодульную архитектуру, совместимость на основе стандарти зованных СОМ-интерфейсов и реализацию систем на базе стандартных механизмов распределенного функционирования.

2. Глава 2. Теоретические аспекты построения модульной архитектуры и мо дели систем ЧПУ типа PCNC Основу предлагаемой далее концепции следует рассматривать не как альтернативу существующим представлениям о PCNC-архитектуре, но как естественное развитие наиболее плодотворных идей, сформулированных ранее. Ключевые архитектурные представления переосмыслены с учетом новейших достижений и тенденций разви тия индустрии ЧПУ и смежных областей, а также с учетом современных требований конечных пользователей.





2.1 Представление о модульной архитектуре системы ЧПУ На прикладном уровне проблема модульности архитектуры системы PCNC остается открытой.

Обычно под модульностью на прикладном уровне понимают разбиение системы ЧПУ на функциональные части, разрабатываемые разными группами разработчиков.

Такие системы практически не поддаются модернизации.

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

Магистраль служит единым механизмом не только для внутреннего обмена между модулями, но и для обмена информацией с внешней средой.

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

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

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

Изложенное выше предопределяет принципиально иную (в сравнении с известными решениями) организацию системы ЧПУ, в которой даже модули с традиционными наименованиями имеют новое функциональное и алгоритмическое наполнение, а также и новую программную реализацию.

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

Тем самым обеспечивается оптимальное использование вычислительных ресурсов, наряду с исключительно высокой гибкостью системы. Систему ЧПУ можно конфигу рировать и реконфигурировать во время ее работы (run time), обеспечивать локаль ное или распределенное (удаленное) функционирование ее модулей, подключать систему к сетям управления на уровне предприятия.

Таким образом, далее будем говорить о системе следующего поколения, имеющей объектно-ориентированную реализацию, и о системе, через поколение построенной на базе компонентного подхода. При этом систему ЧПУ с компонентной реализацией построим на базе системы с объектно-ориентированной реализацией, обеспечив при этом преемственность базовых решений.

2.3 Принцип выделения модулей в 1. Декомпозиция ядра архитектуре систем ЧПУ системы ЧПУ Логическая схема последовательного создания 2. и трансформации моделей систем ЧПУ типа Архитектурная модель PCNC для их полного описания и формализа ции представлена на Рис. 1.

3.

Виртуальная модель Декомпозиция системы ЧПУ осуществляется с целью выделения задач и модулей, закреплен 4.

ных за каждой из задач, а также составляющих Потоковая (DFD) модель модули блоков. Построение архитектурной модели определяет платформа системы. Соз 5. Объектно-ориентированная модель дается виртуальная модель, а также опреде ляются абстрактные модели для выявления 6.

иерархических зависимостей между платфор Компонентная модель мой и прикладной компонентой. Построение потоковой модели систематизирует основные 7.

Клиент-серверная модель потоки данных в прикладной компоненте. По строение объектно-ориентированной модели 8.

Распределенная модель увязывает модули системы ЧПУ и потоки дан ных между модулями в целостную систему. На базе объектно-ориентированной модели осу Рис. 1. Последовательная трансфор мация моделей систем ЧПУ ществляется реализация. Построение компо нентной модели специфицирует интерфейсы компонентов и определяет уровень независимого программного обеспечения от особенностей аппаратной реализации.

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

Построение распределенной модели определяет сетевую схему функционирования компонентов.

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

В системах ЧПУ нового поколе- Геометрическая Логическая Технологическая Терминальная задача задача задача задача ния принято выделять систем ную платформу РС и ядро сис- Специальные Прикладные Диспетчер режимов приложения... приложения...

темы ЧПУ). Системная плат Программируе- Пользователь Интерпретатор Канал ЧПУ форма строится, в основном, мый контроллер ский интерфейс путем использования унифици- Интерполятор рованной PC-аппаратуры и Администратор стандартной операционной сис- интерполяции темы. Для ядра системы ЧПУ Блок "look-ahead" можно обозначить три уровня Тонкая интерполяция декомпозиции (см. Рис. 2). Грубая интерполяция Первый уровень состоит в вы Рис. 2. Декомпозиция ядра системы ЧПУ типа PCNC делении «задач управления». В числе подобных задач: геометрическая;

логическая;

технологическая;

терминальная.

Второй уровень декомпозиции состоит в выделении модулей в составе задач управления;

причем каждый отдельный модуль соответствует фазе решения задачи управления. Часть таких модулей имеет собственный прикладной интерфейс API;

другие же сильно зависимые между собой, объединяются в группы с целью построе ния общего интерфейса API. Примером подобной группы может послужить геомет рический “канал ЧПУ”, объединяющий интерпретатор и интерполятор. Объединение модулей в группы снижает нагрузку на коммуникационную среду;

однако при этом уменьшается гибкость системы ЧПУ и ее способность к реконфигурации.

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

2.4 Варианты архитектурных моделей систем ЧПУ Сегодня особо гибкие и сложные системы ЧПУ типа PCNC с открытой архитектурой, ориентированные на многокоординатную, многостаночную, высокоскоростную, высо коточную обработку, - выполняют в виде двухкомпьютерной архитектурной модели (системы Typ3 osa (Bosch), Andronic 2000 (Andron) и Sinumeric 840 D (Siemens)). Вы бор двухкомпьютерного решения обусловлен большей вычислительной мощностью по сравнению с однокомпьютерным вариантом и возможностью отделения терми нальной задачи от задач реального времени на разных компьютерах. В перспективе преимущества на стороне однокомпьютерного архитектурного варианта, который предполагает меньшую себестоимость системы за счет исключения второго компью тера и его операционной системы и увеличивает надежность за счет исключения межкомпьютерной коммуникации, являющийся узким местом.

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

Однокомпьютерная модель (см. Рис. 3) предполагает использование традиционного PC-компьютера, оснащенного специ альными устройствами в виде плат контроллеров.

Файловая система Приклад API Операционной системой сегодня долж ные прог раммы Коммуникационная среда на быть Windows NT, в силу ее много Платформа Операци онная Операционная система задачности, больших сетевых система PC и NC Аппаратура Рис. 3. Однокомпьютерный архитектурный вариант возможностей и мощного графического интерфейса.

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

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

при этом различия архитектурных моделей остаются на различиях базовой платформы.

Основная задача построения архитектурной модели заключается в определении ба зовой платформы системы PCNC;

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

в формировании коммуникационной среды по типу виртуальной шины;

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

2.5 Виртуальная модель системы ЧПУ Формально структуру PCNC-системы в целом, а также структуру ее компонентов можно представить как некоторую совокупность трех элементов абстрактной моде ли: данные, команды и процессы. Каждый из этих элементов характеризуется набо ром свойств и набором функциональных возможностей, позволяющих осуществлять операции над элементом. Указанные элементы позволяют определить единообраз ные механизмы как для системы в целом, так и для ее компонентов. На базе эле ментов абстрактной модели построены: обмен между модулями, режимы системы и система команд PCNC-системы.

Первый элемент абстрактной модели – данные - характеризируется типом, раз мерностью, текущим значением и т.д. Функциональные возможности определяют способ их запросом.

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

Третий элемент абстрактной модели - команды. Каждая команда имеет свой идентификатор, список параметров и приоритет. Предусмотренные акции команд состоят в проверке на возможность выполнения и в самом выполнении. Команды входят в сложные отноше ния между собой для обра... NC_Editor MMI Диспетчер Прикладной зования системы команд уровень режимов Интерпретатор Интерполятор PLC модулей системы PCNC, Инвариантный Классы коммуникационной объектно среды ориентированный MFC построенной по типу языко уровень API Win 32 API, RTX API NC API вого процессора.

уровень Системный Драйверы OS Windows NT, RTX В «вертикальном сечении» уровень Аппаратура NC Аппаратура система ЧПУ имеет много Аппаратура Рис. 4. Виртуальная однокомпьютерная модель системы ЧПУ уровневую структуру (см.

Рис. 4) и соответствует модели виртуальной машины.

О каждом уровне виртуальной модели можно говорить как о независимом уровне абстракции, который может быть рассмотрен вне связи с другими уровнями.

На аппаратном уровне решают задачи выбора компонентов, их физической совмес тимости и т.д.

На системном уровне конфигурируют операционную систему Windows NT, встраи вают расширитель реального времени RTX, инсталлируют (возможно, разрабатыва ют) драйверы для NC-оборудования.

На API уровне контролируют доступ к системному уровню и определяют спектр ока зываемого сервиса.

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

На прикладном уровне решают конкретные прикладные задачи с использованием готовых решений и нижних уровней.

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

2.6 Потоковая модель данных системы ЧПУ ( DFD-модель) DFD-модель (Data Flow Diagram, диаграмма потоков данных) служит целям углуб ленной структуризации модулей Электроав системы PCNC, предшествующей томатика водов электроавтоматики объектно-ориентированному про Поток сигналов от при электроавтоматики Вызов операции Следящие граммированию этих модулей.

ам приводы егр ел дачи Панель т DFD-модель является многоуров ая по ма ам и ющ ам оператора егр ач ля од е л по д ав рив ят р За в Уп а п невой иерархией.

на водо да м он ни ци при е На а ви рм их гац фо ящ На Рис. 5, приведена исходная ия И н сл е д Выпол- от нить диаграмма, в которой вся система задание а ан Тр экр а PCNC представлена (в кружке) нз он а к он кц ао ок ии Транзакции фай ен ловой системы ля БД См яд глобальным процессом “Выпол и ац База рм Экран фо данных Ин нить задание”, а внешние источни ки и стоки (т.е. адресаты) данных Файловая система (в прямоугольниках) составляют Рис. 5. Исходная диаграмма DFD-модели окружение системы PCNC. Потоки данных (обозначены стрелками с именами потоков) моделируют передачу информа ции, которая может быть одно- или двунаправленной. Назначение процесса (здесь процессом является глобальная функция системы PCNC) состоит в продуцировании из входных потоков выходных в соответствии с действием, заданным в имени про цесса.

Процесс «Выполнить задание» декомпозирован на два других, соответственно PC подсистеме (процесс «Разработать задание») и NC-подсистеме (процесс «Управ лять объектом»). В результате декомпозиции вскрылись новые потоки данных между двумя подсистемами (дальнейшая декомпозиция не отражена).

2.7 Объектно-ориентированная модель системы ЧПУ Объектно-ориентированная модель использует объекты и отношения между ними, сохраняя семантические связи между функциями и соответствующими данными.

Модель системы имеет иерархическую структуру, что позволяет на любом уровне иерархии сконцентрировать внимание на конкретных элементах модели.

Структура системы ЧПУ представлена на Рис. 6 как некоторая совокупность базовых модулей (обведены сплошными линиями) и дополнительных модулей (обведены пунктирными линиями). При этом каждый из модулей закреплен за определенной задачей управления. Модуль автономен и является вложенным объектом (embedded object), т.е. обладает алгоритмической структурой и структурой данных;

а также и ин терфейсной оболочкой, ориентированной на интерактивную работу в клиент серверной среде.

Терминальная задача PC - подсистема Человеко-ма- Редактор упра- Пользова шинный интер- вляющих прог- тельские фейс (MMI) рамм (NC_Editor) приложения API Коммуникационная среда (Объектно - ориентированная магистраль) API API API API NC- подсистема API Диспетчер Интерпре- Модуль управле режимов татор (ISO - Интерполятор ния следящими Програм процессор) приводами мируемый Канал ЧПУ контроллер Канал ЧПУ Канал ЧПУ Геометрическая задача Логическая задача Рис. 6. Построение модели на базе общей объектно-ориентированной магистрали Модель представлена двумя подсистемами - NC-подсистемой и PC-подсистемой.

Первая является ведущей и формирует среду функционирования ЧПУ ориентированных модулей в реальном времени. PC-подсистема образует среду Windows-образного интерфейса пользователя.

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

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

Объектно-ориентированный подход предоставляет ряд стандартных фор Геометриче- Геометриче мализмов для описания модели. На ба PLC канал ский канал ский канал......

зе стандартного формализма - диа...

граммы классов, спроектирована струк тура модуля PCNC в терминах объекта.

Рис. 7. Модель системы ЧПУ на базе общей COM Для выделения данных в системе PCNC магистрали сформулирован принцип, согласно которому основой выделения данных системы PCNC в классы служит неразрывное (единое) представление о данных и их функциональных характеристиках (способах запросов к ним). В соответствии с принципом выделения данных, объект, представляющий данные PCNC-системы, имеет такие характеристики, как: тип, размер, текущее значение;

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

Механизм отображения данных раскрыт с помощью стандартных формализмов: диа граммы взаимодействия и диаграммы объектов.

2.8 Компонентная модель системы ЧПУ В рамках COM архитектуры (Component Object Model) выделены: раздел базовой платформы, представленный компонентами;

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

Геометрический канал осуществляет интерпретацию и интерполяцию кадра управ ляющей программы, а также управление приводами. PLC канал управляет электро автоматикой станка и синхронизирует работу со вспомогательным оборудованием, таким, как робот, устройство смены палет и т.д. Терминальный модуль выполняет функции интерфейса с пользователем (MMI). Здесь реализованы рабочие экраны, а также машина состояния (State Machine), непосредственно реагирующая на дейст вия оператора и изменения состояний Уровень, Геометрический канал зависимый от системы PCNC.

версии языка Интерпретатор УП В обобщенной формулировке назначе ние канала (геометрического или PLC) Геометрический модуль Независимый Модуль управления заключается в трансформации данных и уровень шпинделями их передаче. Внутренние связи модулей Модуль управления Аппаратно вводом-выводом канала обычно сильнее внешних. Канал зависимый...

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

На примере геометрического канала показана его многоуровневая структура (см.

Рис. 8). В ней выделен модуль «управление вводом-выводом следящих приводов», который маскирует от других уровней аппаратные особенности приводов. Адаптация геометрического канала к другому типу приводов состоит в замене модуля управле ние вводом-выводом.

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

Еще выше расположен «интерпретатор», который учитывает специфику разнооб разных версий языка ISO-7bit. Замена интерпретатора позволяет адаптировать ра боту геометрического канала к другой версии языка УП. Модули геометрического канала, оформлены в виде отдельных компонентов, и каж дый из них имеет некоторый набор системных и прикладных интерфейсов.

В работе создана клиент-серверная модель PCNC системы с выделенным глобаль ным сервером для решения проблемы системной интеграции модулей системы.

Специфика модулей системы ЧПУ заключается в том, что должны быть одновре менно и серверами и клиентами.

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

При выделении общего PCNC COM-сервера системы была выдвинута и реализова на идея динамической агрегации, когда один компонент расширяет свои функцио нальные возможности за счет возможностей второго во время работы (run time).

2.9 Модель распределенной системы ЧПУ Распределенная архитектура системы ЧПУ предполагает работу отдельных ее мо дулей (компонентов) на разных машинах в сети. Отдельной машиной может быть удаленный терминал в локальной сети, с помощью которого можно управлять не сколькими PCNC-системами. Другой пример, - диагностика системы PCNC, осущест вляемая из диагностического центра по сети Internet. В обоих случаях PCNC служит сервером, поскольку предоставляет Удаленные Удаленная диагностика сервис другим системам в сети. Но CAM-расчеты по по сети Internet из PCNC корпоративной сети диагностического Intranet центра возможен и другой случай, когда PCNC является клиентом как на пример, при выполнении сложных Удаленное выполнение терминальной задачи по локальной сети САМ-расчетов в вычислительном Рис. 9. Пример распределенного функционирования центре по корпоративной сети (см.

PCNC системы Рис. 9).

Распределенность системы PCNC означает: обеспечение функционирования ее компонентов на удаленных машинах;

возможность перенаправления компонентов к удаленной системе, т.е. запуск модуля на удаленной системе;

возможность расши рения системы и включения новых модулей только за счет конфигурирования.

Модель распределенной системы полностью соответствует компонентной модели системы ЧПУ. Различие состоит в необходимости реализации компонентов в виде исполняемых модулей (*.exe файлов) и необходимости создания регистрационной записи на этапе конфигурации системы. Проблемы межпроцессного обмена в рас пределенной системе решаются на уровне DCOM (Distributed Compomponet Object Model - распределенная COM-модель), т.е. на уровне операционной системы, в ко торой DCOM-модель реализована.

3. Глава 3. Методологические аспекты построения открытых систем ЧПУ Теоретические результаты этой главы имеют своей целью сделать процесс разра ботки системы PCNC регулярным с учетом специфики каждого экземпляра системы управления.

3.1 Представление о системе PCNC как об открытой системе управления В Табл. 1 систематизированы уровни открытости PCNC системы.

Табл. 1. Открытость системы PCNC на основных этапах жизненного цикла № Уровни открытости Описание 1 Открытость на уровне про- Возможность встраивания готовых решений (аппаратных, изводителей программных, программно-аппаратных решений) в базовую платформу Определение набора API функций, который открыт и досту пен для использования.

2 Открытость на уровне стан- Создание собственной версии языка управляющих программ;

костроителей определение собственного набора стандартных циклов;

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

Встраивание собственных или покупных диагностических комплексов.

Реализация собственных интерфейсов оператора (MMI);

включение коммерческих приложений;

построение информа ционно-технологических подсистем.

3 Открытость на уровне ко- Расширение интерфейса оператора, настройка на технологи нечных пользователей ческий процесс.

Использование собственного технологического “ноу-хау”.

Реально, открытость систем PCNC находится в руках производителей, но не пользо вателей. Использование API-функций Средства Стандартные языкового доступно или производителям систем средства ОС процессора ЧПУ, или квалифицированным коллек тивам технических университетов.

Проблема Когда мы говорим об открытости на Проблема много открытости задачности уровне пользователя, то, в первую оче Создание открытой редь, подразумеваем: возможность PCNC системы использования API-функций, вынесен Проблема Проблема ведения формализации ных во входной язык;

возможность на проекта разработки стройки с помощью конфигурационных файлов и файлов инициализации;

воз Стандартные Оригинальные инструментальные инструментальные можность изменения значения реестра средства средства Windows NT;

возможность добавления Рис. 10. Методологические проблемы создания от и синхронизации внешних приложений крытых PCNC систем на базе входных и выходных файлов. И лишь во вторую очередь рассматриваем возможность получения дополнительного сервиса от ядра системы PCNC через API интерфейс.

При построении систем ЧПУ помимо проблемы открытости, нерешенными остаются проблемы реализации многозадачности прикладной компоненты, проблемы контро ля над ведением проекта, проблемы формализации рутинных работ при разработке и настройке системы для конкретного заказчика.

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

3.2 Опыт и методика построения систем ЧПУ по типу открытого языкового процессора программы Под открытым языковым PLC процессором будем по входного языка Конфигурация нимать модуль, у которо Программи- Управление го хотя бы часть API руемый электро автоматикой контроллер функций вынесена во IPD формат входной язык или в файл УП на языке Интерпретатор ISO-7bit конфигурации модуля, что позволяет использо Управление Интерполятор приводами вать функциональные Ядро PCNC возможности ядра сис интерполятора Конфигурация темы ЧПУ, не прибегая к Управление Состояние системой системы прямому программиро ванию. Примером служит реализация специфич Интерфейс Действия Управление оператора оператора экранами ных измерительных цик лов G581-G589 в систе Скрипт ме.

файл На Рис. 11 система Рис. 11. PCNC-система как набор языковых процессоров PCNC представлена в виде упрощенного набора языковых процессоров. На вход интерпретатора поступа ют управляющие программы на языке ISO-7bit;

настройка на конкретную версию языка ISO-7bit осуществляется с помощью специального конфигурационного файла.

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

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

Функциональность системы PCNC определяется во многом геометрической задачей.

Здесь увеличение резервов гибкости и ресурсов быстродействия немедленно ска зывается на потребительских качествах системы управления в целом. Поэтому была разработана концепция интерпретатора управляющей программы в виде геометри ческого ISO-процессора. Суть концепции состоит в привлечении двух принципов ор ганизации программной среды для решения геометрической задачи.

Согласно первому принципу ISO-процессор должен быть построен таким образом, чтобы воспринимать операторы языка ISO-7bit управляющей программы так, как ес ли бы они были машинными инструкциями. Второй принцип заключается в том, что реализация ISO-процессора осуществляется на основе объектно-ориентированного подхода.

Кадр управляющей программы на языке ISO-7bit несет информацию о заявленных алгоритмах и структурах данных (см. Табл. 2). Алгоритмы представлены подготови тельными функциями (G-функциями). Структуру данных составляют функции раз мерных перемещений (X, Y, Z, I, J, K, R), функция подачи (F), функция скорости главного движения (S). Функции структур данных можно рассматривать как парамет ры G- функций, а сами G-функции как системы команд ISO-процессора.

Табл. 2. Структура кадра управляющей программы в терминах концепции ISO-процессора Данные Алгоритмы наименование обозначение наименование обозначение Размерные перемещения X, Y, Z, I, J, K, R Подготовительные G функции Подача F Скорость главного движения S Вспомогательные M функции Управление последовательностью кадров L Все команды разбиты на несколько групп, определяющих их функциональное назна чение. В каждой группе выделены одна или несколько подгрупп ортогональных (т.е.

взаимоисключающих) G-функций. Интерпретация кадра для каждой группы осущест вляется независимо.

Конфигурация интерпретатора формируется структурой системы команд. Число групп G-функций задает количество групповых интерпретаторов;

а в каждом интер претаторе предусмотрены подгруппы, с которыми он работает, но не определены G функции, которые входят в каждую подгруппу. Групповой интерпретатор обращается к подготовительной функции как к соответствующей координате G-вектора и пере дает ей управление. Использование подобной схемы означает, что одно и то же уст ройство ЧПУ может использовать различные системы команд.

3.3 Опыт и методика использования стандартных средств для поддержания открытой архитектуры Расширение RTX заменяет аппаратно зависимый уровень HAL (Hardware Abstraction Layer) ядра Windows NT для того, чтобы гарантировать необходимое время реакции на события. При этом появляются новые объекты ядра с идентичными для прежних объектов механизмами взаимодействия, что и позволяет рассматривать Windows NT и расширение RTX как одно целое, т.е. операционную систему реального времени.

В системе PCNC существуют два или более процессов, которые могут быть процес сами реального времени и процессами машинного времени;

при этом процессы об мениваются данными и сообщениями.

В процессах реального времени в виде отдельных потоков должны быть реализова ны: интерполятор, модуль Look-a-head, система поддержки коммуникационной сре ды. В процессе машинного времени реализуют потоки поддержки коммуникационной среды, терминальную задачу (MMI);

интерпретатор, запускающий свои групповые интерпретаторы как отдельные процессы.

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

В отдельные потоки выделяют любые длинные операции с файлами. Например, в NC-редакторе в отдельные потоки выделены операции: 3D-моделирования управ ляющей программы, расчета G-вектора в текущем кадре управляющей программы и т.д.

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

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

Потоки являются мощным инструментом, который следует применять осознанно.

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

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

Использование разделяемой памяти с помощью критической секции (critical section) рассмотрим на примере интерпретатора и интерполятора. Интерпретатор интерпре тирует кадр и записывает его в формате IPD (Interpolator Data) в кольцевой буфер.

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

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

Другим средством синхронизации потоков служит объект ядра - мютекс (mutex), по зволяющий синхронизировать потоки разных процессов. Рассмотрим пример син хронизации данных коммуникационной среды между процессом реального времени и процессом машинного времени. Данные передаются через разделяемую память (Shared memory). В коммуникационном потоке процесса реального времени создает ся объект ”мютекс” с помощью функции CreateMutex(), которая сразу возвращает описатель (handler) объекта. Win32 поток получает описатель того же объекта ”мю текс” с помощью функции CreateMutex() или OpenMutex(). Код в обоих синхронизи руемых потоках обрамляется функцией WaitForSingleObject() в начале и функцией ReleaseMutex() в конце. Таким образом, одновременно блокируются попытки записи и считывания из разделяемой памяти соответственно коммуникационных потоков реального времени и машинного времени.

Объект «семафор» (semaphore) используют для управления ресурсами. В PCNC системе – это порты ввода-вывода. Когда запрашивается ресурс, то операционная система уменьшает содержание счетчика ресурсов. Семафор создается с помощью функции CreateSemaphor(), в которой указано количество ресурсов, подлежащих мо ниторингу. Описатель семафора из другого потока создается с помощью той же функции CreateSemaphor() или функции OpenSemaphor(). Аналогично с объектом ”мютекс” синхронизация происходит в блоке, обрамленном функциями Wait ForSingleObject() и ReleaseSemaphor(). Следует учитывать тот факт, что мютекс мо жет освободить только поток, занявший мютекс, а семафор может быть освобожден любым потоком.

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

Использование объекта «событие» (event) позволяет упростить схему диспетчери зации процессов реального времени. Диспетчер процессов реального времени по строен на базе таймера. По сути, это отдельный поток с наивысшим приоритетом.

При каждом срабатывании таймера вызывается его call-back функция, в которой реализована схема диспетчеризации. Согласно этой схеме управление потоками осуществляется путем изменения их приоритетов. На этом работа call-back функции таймера завершается. Останов и запуск процессов осуществляет сама операцион ная система.

Предложены решения важных проблем при создании открытых систем PCNC, по строены на использовании системных возможностей операционной системы Win dows NT, на ее концепциях многозадачности, механизма сообщений и объектов син хронизации. Использование отлаженных решений и опыт, накопленный в этой об ласти, позволяют существенно снизить трудоемкость разработок.

3.4 Опыт и методика использования стандартных инструментальных средств для поддержания открытой архитектуры Опыт лаборатории кафедры компьютерных систем управления МГТУ «СТАНКИН» показывает, что интеграция инструментальных средств возможна на основе техно логии Microsoft-OLE-Automation. В качестве базы был использован Visual C++. Сего дня Visual C++ входит в состав самого мощного пакета средств разработки про граммного обеспечения под Windows - MSDN (Microsoft Developer Network).

В проекте PCNC системы для Visual C++ каждый модуль оформлен в виде подпро екта. Подпроекты состоят в некоторой зависимости друг с другом;

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

Visual C++ обладает мощным механизмом для настройки средств разработки;

утили тами, обслуживающими проект;

механизмами встраивания внешних приложений.

Система поддержки проекта Source Safe и система проектирования Rational Rose встраиваются в Visual C++ как внешние приложения.

В проект создания PCNC системы вовлечено несколько десятков человек;

постоянно вносятся изменения;

нужна поддержка релизов и дальнейшее развитие версий. Та кой проект нельзя начинать без системы Source Safe (компании Microsoft) поддержки проекта. Source Safe реализует достаточно простую концепцию работы с исходными кодами, поскольку только один разработчик может взять файл из Source Safe с по мощью функции CheckOut;

по окончании работы разработчик возвращает файл об ратно в Source Safe, используя функцию CheckIn.

Иерархия классов, которая была создана на промежуточном этапе разработки ком муникационной среды в виде объектно-ориентированной магистрали, содержит бо лее 150 классов, поэтому архитектор проекта не в состоянии отследить взаимосвязь между ними и довести до программиста детали их реализации. Проблемы подобного рода решаются с помощью CASE-системы Rational Rose, поддерживающей практи чески все распространенные нотации представления моделей, в том числе и UML (Unified Modeling Language).

Прикладные компоненты описываются Динамическое представление системой Rational Rose с помощью четы Статическое рех представлений объектно представление ориентированного подхода (см. Рис. 12).

Структура классов PCNC Логическое Структура объектов PCNC представление Логическое представление определяет Архитектура модулей PCNC Физическое ключевые абстракции и механизмы, Архитектура процессов PCNC представление формирующие предметную область и ар Рис. 12. Основные представления PCNC систе хитектуру PCNC системы. Физическое мы, поддерживаемые Rational Rose представление определяет конкретную программно-аппаратную платформу, на ко торой реализована система. Все это описывается диаграммой классов, диаграммой объектов, диаграммой модулей, диаграммой процессов. Если рассматривать систе му со стороны статики/динамики, то здесь интерес представляют: диаграммы пере ходов из одного состояния в другое, диаграмма взаимодействия и обмена сообще ниями, определяющая порядок их передачи.

3.5 Опыт и методика использования оригинальных инструментальных средств для поддержания открытой архитектуры системы ЧПУ Стандартные средства операционной системы и стандартные инструментальные средства недостаточны для разработки PCNC системы.

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

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

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

AppWizard представляет средство создания и конфигурирования нового проекта в среде Microsoft Visual C++. В частности, NCs AppWizard определяет в интерактивной форме свойства и функциональные возможности будущего модуля PCNC.

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

Установка Ncs AppWizard в систему разработки состоит в копировании файла с рас ширением «.AWX» в директорию Template Microsoft Visual C++.

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

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

Машина состояния описывается с помощью графа. Это и было использовано при построении визуального инструментария разработки машины состояния State Ma chine Builder (генератора машины состояния). При этом были использованы допол нительные понятия, MSDN окружение разработки такие, как: сложные CASE система Система поддержки состояния, порты вво проекта (Rational Rose) да/вывода.

(Visual Source Save) итеративное !

проектирование;

ведение проекта;

!

Эти понятия позволи проверка фиксация релизов;

! !

корректности модели. архивация версии.

!

ли выстраивать ие рархические структуры графа;

причем в нача Интегрированная Дополнительный среда разработки инструментарий Процесс разработки ле иерархии находится открытой системы (Visual C++) (...) PCNC редактирование;

!

единственное сложное ведение !

компиляция;

!

документации;

линковка.

!

состояние. На каждой....

!

следующей ступени иерархии сложные со Библиотеки ядра ОС Оригинальные инструментальные стояния распадаются средства (Win32 API) (Ncs AppWizard, State Machine Builder) на совокупности про механизм сообщения;

!

генерация машины состояния;

!

объекты синхронизации ! стых или простых и генерация скелета приложения.

!

потоков.

сложных состояний.

Инструмент разработ Рис. 13. “Окружения разработки” PCNC системы ки State Machine Builder позволяет визуально представить машину состояния в виде иерархического графа, задать имена классов, реализующих состояния и переходы;

определить файлы их расположения. В результате инструментарий генерирует С++ код для машины состояния и встраивает его в Visual C++ проект PCNC системы.

3.6 Формирование окружения разработки Стадии разработки сопоставим системе решений, рассмотренных в разделах 3.3, 3.4, 3.5. Соответственно, Rational Rose и State Machine Builder закрепим за фазами анализа и проектирования;

NCs AppWizard закрепим за фазами проектирования и разработки, а Visual C++ и Win32 API закрепим за фазой разработки. В результате получим целостную систему, наполняющую все фазы разработки и поддерживаю щую ведение проекта. Систему эту назовем “окружением разработки” открытой PCNC системы (см. Рис. 13). В окружение разработки, помимо рассмотренные меха низмов и инструментов, можно ввести дополнительный инструментарий, например, систему ведения документации, что показано на рисунке серым цветом. Интеграция всего окружения осуществлена на базе MSDN.

В результате исследования сформирована методология решения проблемы созда ния открытой системы PCNC.

4. Глава 4. Теоретические аспекты построения диспетчера реального времени и коммуникационной среды Декомпозируем проблему интеграции модулей в РCNC-систему на две части. Пер вая часть связана с встраиванием модулей в единую логическую структуру, в соот ветствии с работой системы. Вторая часть связана с встраиванием в единый меха низм передачи данных и общения между ними. Если первая проблема решается на уровне планирования и диспетчирования задач, то вторая решается на уровне ком муникационной среды.

4.1 PCNC как система реального времени На основе анализа систем реального времени, проведена обобщенная классифика ция и обозначено в ней место PCNC-системы. Современные системы числового про граммного управления используют операционную систему Windows NT с расшире нием реального времени.

Windows NT не является операционной системой реального времени (ОСРВ), по скольку: она не имеет достаточного диапазона приоритетов потоков;

она не позво ляет управлять наследованием приоритетов;

механизм синхронизации потоков не предсказуем;

время реакции на прерывание непредсказуемо. В силу растущей попу лярности операционной системы Windows NT управления проблема реального вре мени в системах должна быть решена.

Были выработаны основные правила реализации системы реального времени на базе Windows NT, которые сведены в Табл. 3.

Из всех существующих предложений по реализации ОСРВ на базе Windows NT практическое значение имеют всего два подхода. Первый подход состоит в запуске Windows NT в виде низко-приоритетной задачи операционной системы реального времени (супервизора);

при этом предполагается применение ядра классической ОСРВ типа QNX или VxWorks.

Табл. 3. Правила реализации системы реального времени на базе Windows NT Правила Описание 1. Реализация разрешения ре- Речь идет о времени реакции и времени переключение кон ального времени. текста, а также о требованиях, необходимых для обеспечения предсказуемости.

2. Обработка исключения сбоя При “крахе” Windows NT генерируется исключение «blue Windows NT. screen», после чего возможна только перезагрузка системы.

3. Защита от некорректных Win- Установка драйвера или приложение независимого поставщи dows-драйверов и приложений. ка может привести к «зависанию» системы, что абсолютно недопустимо.

4. Обработка сбоев жесткого Программный механизм должен гарантировать архивизацию диска данных при сбое жесткого диска.

Второй подход заключается в расширении Windows NT для поддержки реального времени. Это может быть оригинальная разработка изготовителя системы управле ния или использование готового коммерческого решения, например RTX 4.1 фирмы VenturCom, на чем и базировалась работа.

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

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

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

в отличие от жесткого времени здесь допустимы задержки потока из-за свопинга (подкачки) памяти, обращения к жесткому Интерпретатор (ISO-processor) диску, прерывания и т.д. В ре жиме машинного времени ра Интерполятор Пользователь- Алгоритм Таймер ская call-back планирования ботают остальные стандартные функция (Диспетчер) Ввод/вывод прикладные модули системы Коммуникаци Window NT и RTSS управления.

онная среда Стратегия диспетчеризации за Интерфейс Фоновый процесс оператора (MMI) дач в PCNC системе (см. Рис.

Рис. 14 Стратегия диспетчеризации задач реального време- 14) заключается в использова ни PCNC-системы нии таймера реального време ни. По истечении кванта времени стандартный механизм генерирует прерывание, которое обрабатывается так называемой прикладной call-back функцией. Функция реализует алгоритм планирования (диспетчеризации) задач интерпретации, интер поляции, ввода/вывода, коммуникации и интерфейса оператора.

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

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

Согласно принятым представлениям о режимах времени в системе управления, вы делим три группы потоков: потоки жесткого реального времени;

они работают в процессе реального времени;

это так называемые RTSS-процессы;

потоки мягкого реального времени;

они функционируют в Win32 и RTAPI-процессах;

потоки ма шинного времени;

они работают в стандартных Win32-процессах.

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

Обмен данными между процессами мягкого реального времени и процессами жест кого реального времени осуществляется на базе разделяемой памяти (shared mem ory) – механизма, предоставляемого со стороны RTX.

RTSS-процесс на Рис.

Win32 процессы Win32 и RTAPI процессы Процессы реального времени (RTSS) 15 включает в себя Машинное время Мягкое реальное время Жесткое реальное время Поток коммуникационной среды Win набор потоков, ре Грубая интерполяция Тонкая интерполяция Поток коммуникационной Поток интерфейса с оператором шающих критические Порожденные потоки групповых Look Ahead Поток интерпретатора Поток NC редактора задачи в PCNC Порожденные потоки PLC поток среды РВ моделирования УП интерпретаторов системе. Поток дис петчера, по сути, яв ляется call-back функ Потоки ин цией таймера, где терполяции реализован плани Поток диспетчера РВ ровщик процессов.

Планировщик с помо Рис. 15. Потоки PCNC системы щью мютексов или семафоров запускает или останавливает тот или иной поток.

Коммуникационную среду разделим на два потока, один из которых функционирует в жестком реальном времени (поток коммуникационной среды реального времени);

а другой работает в мягком реальном времени (поток коммуникационной среды Win32). Задача состоит в передаче данных как между потоками внутри процесса, так и между процессами.

Задача интерполяции реализуется: потоком Look-Ahead, выполняющим опережаю щий просмотр и коррекцию кадров управляющей программы;

потоком грубой интер поляции, вызываемым обычно с частотой 50Гц;

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

Частота вызова интерполяторов параметрически настраивается в планировщике (в потоке диспетчера реального времени). Поток программируемого контроллера ре шает задачу управления электроавтоматикой и задачу ввода-вывода.

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

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

Предложенное разбиение потоков в PCNC-системе позволяет выделить критические ко времени потоки, а их запуск в RTSS-процессе гарантирует нам жесткое реальное время в Windows NT. При этом оптимально используются вычислительные ресурсы процессора.

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

Задача эмуляции в Windows NT актуальна только для решений на базе супервизора.

Нужно разработать специальное программное обеспечение, которое решает про блемы: адресного пространства;

приоритетов;

соответствия объектов синхрониза ции;

соответствия базовых функций.

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

Решение перечисленных проблем создания эмулятора супервизора определяет ос новные шаги методики.

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

2. Создание таблицы соответствия приоритетов.

3. Реализация объектов синхронизации задач супервизора на базе объектов ядра Windows NT.

4. Реализация функции супервизора на базе API функции Windows NT.

Приведенная методика определяет основные шаги построения эмулятора суперви зора. Конечно, при этом прямое обращение из ОС Windows по адресу аппаратуры не обрабатываются как эмуляторов RTX, так и эмуляторов супервизора.

4.2 Построение коммуникационной среды по типу общей объектно ориентированной магистрали Традиционно коммуникационную среду системы ЧПУ трактуют как некоторый набор интерфейсных API-функций для обмена данными с ядром системы ЧПУ. При таком подходе, однако, любое изменение в архитектуре системы проблематично. API функции задают некоторый общий интерфейс подключения модулей в системе ЧПУ, но не поддерживают их интеграцию.

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

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

Функции управления можно разбить на три группы: функции управления каналом, открывающие и закрывающие канал;

функции процессов, контролирующие ход их выполнения, включая запуск и останов;

функции управления состояниями (они будут рассмотрены ниже).

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

В процессе обмена данными через магистраль выделены две фазы. В фазе запроса данных определяется сервер данных, устанавливается тип запроса и приемник дан ных (клиент). В фазе отображения определяется тип и формат отображения. Формат отображения предполагает, что одни и те же данные могут быть отображены, на пример, в виде пиктограмм, в текстовом или числовом виде.

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

В зависимости от способа вывода данных, отображения разделены на несколько групп: визуализация в галерее управляющих элементов, которая строится на базе стандартных Windows-элементов;

визуализация в галерее ActiveX-элементов, кото рая строится на базе OLE-элементов Windows;

визуализация в среде «документа представления» при создании пользовательских приложений на базе стандартного механизма MFC;

визуализация с целью управления ходом процесса в PCNC системе;

статистическое накопление данных для сохранения, например, для их по следующего анализа.



Pages:   || 2 |
 

Похожие работы:





 
2013 www.netess.ru - «Бесплатная библиотека авторефератов кандидатских и докторских диссертаций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.