Библиографическое описание:

Третьякова В. И. Моделирование операционной системы реального времени сетями Петри // Молодой ученый. — 2013. — №11. — С. 48-50.

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

В свое время группой сотрудников Университета [1] было разработано программное обеспечение для изготовленного на ПО «КОНТУР» устройства числового программного управления (УЧПУ), предназначенное для автоматизации и расширения функциональных возможностей, серийно выпускаемых копировально-фрезерных станков, например, типа 6Б443Г, имеющее существенные преимущества перед системами такого класса, выпускаемых в нашей стране [1].

Программное обеспечение разрабатывалось на основе системного анализа задач управления рабочим органом в многомерном пространстве с учетом конкретного станка и его органов управления.

Все программное обеспечение (ПО), в том числе и прикладное, разработано по модульному принципу и разбито на достаточно самостоятельные задачи. Системное ПО представляет собой операционную систему реального времени (ОС РВ). Главной особенностью таких систем является требование решения заданного набора задач к заданному моменту времени. Системы ОС РВ являются наиболее сложными из операционных систем, т. к. они, как правило, используются для управления многозадачными САУ при дефиците времени. При разработке прикладного ПО учитывалось отношение каждой задачи к реальному времени и ее приоритет [2, 3]. Общая структура программного обеспечения представлена на рис.1.

Упрощенный вариант программной системы используется для обучения студентов робототехнических направлений. На ее примере студенты изучают структуру системного и прикладного программного обеспечения системы ЧПУ. С точки зрения ПО наиболее сложным для студентов оказывается анализ принципов структурной организации системы и динамики управления задачами в режиме реального времени. Именно поэтому в учебном плане методически оправданным оказался подход графического моделирования ОС РВ сетями Петри [4].

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

Определяется, какие действия происходят в системе, какие состояния предшествовали этим действиям и какие состояния примет система после выполнения действия. Выполнения событийной модели в сетях Петри описывает поведение реальной системы во времени. Анализ результатов выполнения может сказать о том, в каких состояниях пребывала или не пребывала система, какие состояния в принципе не достижимы.

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

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

Запуск планировщика происходит по таймерному прерыванию. Планировщик, первым этапом сохраняет в стеке содержимое всех регистров и снимается запрет на прерывания. Это позволяет сохранить вектор состояния снятой по прерыванию задачи. Запускается первая задача РВ, если есть запрос на неё. Диспетчер должен знать её адрес (адрес первой исполняемой команды хранится в дескрипторе задачи).

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

Рис. 1. Алгоритм работы планировщика, диспетчера РВ и диспетчера ФЗ

После того, как задача РВ решена, запускается последняя задача, которой является диспетчер ФЗ (вторая часть планировщика), проверяется состояние счётчика фоновых задач R1. Если R1=0, то значит, все задачи обработаны, и до того, как в позиции «konec» появится метка, планировщик будет находиться в состоянии ожидания прерывания от таймера («konec»); когда же происходит ввод команды «konec», начинается выход из системы. Т. к. планировщик был запущен по прерыванию, была снята некоторая ранее работающая задача, для возврата этой задачи необходимо восстановить вектор её состояния, хранящийся в стеке. При запуске диспетчера РВ были запрещены прерывания, их необходимо разрешить. После этого происходит выход из системы.

Запуск диспетчера ФЗ происходит после того, как решены все задачи РВ, проверяется состояние счётчика фоновых задач R1, если R1 не равно 0, то значит, что ещё не все задачи обработаны. Поскольку фоновые задачи допускают прерывания, диспетчер фоновых задач должен снять запрет на прерывание, который установил диспетчер РВ.

Для запуска ФЗ ее адрес считывается из последнего слова паспорта (R0+4) и производится обращение к подпрограмме по этому адресу. С целью упрощения модели (с учетом стандартизации обработки задач) в модели обрабатываются четыре ФЗ, на две из них есть запросы. Тем не менее, диспетчер должен опросить все задачи.

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

Так как ФЗ могут прерываться, на рис.1 показаны прерывания от таймера, которые обеспечивают остановку решаемой задачи, продолжение решения начнётся с точки прерывания. После того, как последняя ФЗ будет решена, диспетчер, если не пришло прерывание от таймера, передаст управление планировщику.

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

Данная модель позволяет:

1.       задавать время решения каждой задачи;

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

3.       легко добавлять или исключать диспетчеры или задачи;

4.       легко модернизировать систему под n-процессорный вариант аппаратной части с целью повышения быстродействия системы;

5.       наблюдать визуально или исследовать динамику системы за счет механизма «фишек» в сетях Петри;

6.       оценивать правильность выполнения во времени взаимосвязанных цепочек задач;

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

Литература:

1.                  Раводин О. М., Давыдова Е. М. Моделирование системы управления устройства ЧПУ/ Интеллектуальные системы в управлении, конструировании и образовании/ под ред. А. А. Шелупанова.- Томск: SST, 2001.- 224с. УДК 06061201 ISBN 5–89503–078–52.

2.                  Раводин О. М., Бейнарович В. А. Принципы построения программного обеспечения копировально-фрезерных станков. // Аппаратно-программные средства автоматизации технологических процессов, -Изд-во ТУСУР. — Томск, 1998.

3.                  Раводин О. М.// Гибкие производственные системы и робототехника. -Учебное пособие. Издание 2-ое переработанное и дополненное. — Томск: В-Спектр, 2007. — 260с.

4.                  Первое знакомство с сетями Петри. Часть 2. Основы сетей Петри [Электронный ресурс] / В. М. Балк. [1998] URL: http://www.smolensk.ru/user/sgma/MMORPH/N-4-html/5.htm (дата обращения: 17.11.11).

Обсуждение

Социальные комментарии Cackle