Расчет и анализ системы обслуживания робототехнического комплекса производства деталей ЭВА

Расчет и анализ системы обслуживания робототехнического комплекса производства деталей ЭВА

ФЕДЕРАЛЬНЫЙ КОМИТЕТ ПО НАУКЕ И ОБРАЗОВАНИЮ

КУРСОВАЯ РАБОТА

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

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

В курсовой работе анализируется СМО робототехнического комплекса производства деталей РЭА.

1. Условие и исходные данные

Заявки на ремонт и наладку четырех компонентов комплекса (станков с программным управлением, промышленных роботов, программных транспортных устройств, управляющих ЭВМ) образуют i (i=1,4) входных потоков однородных событий. Поскольку функционирование системы связано как с регулярными (плановыми) ремонтами , так и ремонтами при внезапных отказах технических средств, то в общем случае входные потоки следует рассматривать как потоки Эрланга с параметрами i ,i (i=1,4) . В случае упрощенных расчетов можно исследовать предельный случай. Когда i=0, и рассматривать пуассоновские входные потоки с параметрами i (i =1,4 ). Необходимо рассмотреть два случая функционирования канала обслуживания. Длительность выполнения заявки для каждого компонента робототехнического комплекса является случайной величиной i (i=1.4). подчиняющейся экспоненциальному закону распределения с параметрами i (i=1,4) , либо постоянной величиной b. При ожидании обслуживания возникают стоимостные потери, связанные с простоями технических средств. Величина потерь в единицу времени Сi(i=1,4) . Проанализировать эффективность СМО при различных дисциплинах очереди: в порядке поступления заявок (бесприоритетное обслуживание), с относительными, абсолютными и смешанными приоритетами.

Исходные данные даны в таблице 1 и таблице 2.

Таблица 3 - Исходные данные

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

.(2.1.1)

Длительность обслуживания характеризуется вторым средневзвешенным моментом, который находится по формуле:

,(2.1.2)

где bi(2) - это дисперсия экспоненциального распределения, которая зависит от параметра распределения µ через соотношение:

.(2.1.3)

По условию, задано отношение , которое мы обозначили, как Const_, тогда:

,(2.1.4)

где bi - математическое ожидание экспоненциального распределения.

, .

.(2.1.5)

Тогда с учетом (2.1.2), (2.1.3) и (2.3.4) формул получим окончательное выражение суммарной дисперсии:

,(2.1.6)

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

,(2.1.7)

,

.

Длительность обслуживания характеризуется также средневзвешенными потерями:

,(2.1.8)

.

Тогда среднее время ожидания:

,(2.1.9)

.

Суммарные потери вычисляются по формуле:

,(2.1.10)

.

2.2 Расчет при оптимальных относительных приоритетах

При относительных приоритетах среднее время ожидания заявок типа равно:

,(2.2.1)

где Ri1--коэффициент загрузки системы всеми заявками от 1-го до i1-го типа включительно.

Расчет коэффициента загрузки канала :

,(2.2.2)

.

Расчет коэффициента загрузки системы:

,(2.2.3)

.

С учетом выше приведенных формул выражение можно переписать в виде:

.(2.2.4)

Введя временную переменную Vremper= , получим следующее выражение:

, (2.2.5)

.

Расчет среднего времени ожидания заявок:

,

,

,

.

Суммарные потери:

.

2.3 Расчет при оптимальных абсолютных приоритетах

Расчет среднего времени ожидания заявок при оптимальных абсолютных приоритетах производится по формуле:

,(2.3.1)

,

,

,

.

Суммарные потери:

.

2.4 Расчет параметров системы при смешанных приоритетах

Рассмотрим касс смешанных приоритетов. Условимся, что среди заявок в очереди, обслуживание которых не началось, заявки i-го типа имеют преимущество перед заявками i1-го типа, если i>i1. Далее определим интервалы времени ti,i1 таким образом что , если i<i1 и, если ii1, Кроме того, Тогда заявка i1 -го типа, до окончания обслуживания которого осталось время (причем), имеет преимущество перед заявкой i-го типа, обслуживание которой не началось. Если же, то перед ней имеет преимущество любая заявка i-го типа.

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

,(3.4.1)

,(3.4.2)

.(3.4.3)

Выберем ti в соответствии с вышеприведенным условием, причем приоритетной будет 1 заявка.

Тогда первое время выбирается из интервала 0<t1<0,611, t1=0,3.

Второе время выбирается из интервала 0<t2<0,688, t2=0,35.

Третье время будет выбираться из интервала 0<t3<0,786, t3=0,4

Четвертое время выбирается из интервала 0<t4<0,917, t4=0,45

,

,

,

,

,

,

,

.

Параметров Ti:

,

,

,

,

,

,

,

.

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

Обозначим:

,(3.4.4)

.

Среднее время ожидания заявки при смешанных приоритетах:

,

,

,

,

,

,

,

.

Суммарные потери:

.

Таблица 4 - Результаты расчета параметров СМО при различных дисциплинах очереди

Вывод:

Из полученных результатов следует, что условию оптимизации:

,

в полной мере отвечает система обслуживания робототехнического комплекса производства деталей ЭВА со смешанными приоритетами.

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

3. Разработка экранных форм

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

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

Для измерительных систем разработаны свои ГОСТы на систему интерфейса. Имеется обширная литература по видам, типам, структуре интерфейсов, критериям их выбора и реализации. Пользовательский интерфейс, относящийся в основном к компьютерным диалоговым системам, является предметом исследования и разработок достаточно узкого круга специалистов. Об этом свидетельствуют материалы. Первой международной научной конференции «Пользовательский интерфейс в современных компьютерных системах», проведенный в г.Орле в 1999 году.

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

К числу других графических сред можно также отнести:

* Presentation Manager (OS/2);

* OpenLook, Motif (Unix - станции);

* NextStep (Next).

Укажем несколько принципов, лежащих в основе перечисленных выше систем. К числу таковых относятся:

* графический режим работы;

* представление ряда объектов пиктограммами;

* многооконность;

* использование указующего устройства - мыши;

* адекватность изображения на экране изображаемому объекту (принцип WYSIWYG - What You See Is What You Get);

* наглядность;

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

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

* использование clipboard (pasteboard) - некоторого общего места (хранилища), с помощью которого программы могут обмениваться данными: в одной программе пользователь выделяет объект (фрагмент текста, изображение) и помещает в clipboard, а в другой может взять этот объект и вставить его в текущий документ (изображение);

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

В основе любой системы GUI лежит достаточно мощный графический пакет: QuickDraw в Macintosh, GDI в Microsoft Windows, Display Post Script в NextStep. Этот пакет должен поддерживать работу со всеми областями сложной формы и отсечения изображения по таким областям.

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

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

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

а)

б)

в) г)

д) е)

ж) з)

и) к)

Рисунок 3.1 - Структура интерфейса: а) Вид окна при загрузке программы; б) Меню «Файл»; в) Меню «Расчет»; г) Меню «Справка»; д) Вид окна ввода исходных данных для расчета; е) Вид окна вывода результатов расчета СМО при бесприоритетном обслуживании; ж) Вид окна вывода результатов расчета СМО при оптимальных относительных приоритетах; з) Вид окна вывода результатов расчета СМО при оптимальных абсолютных приоритетах; и) Вид окна вывода результатов расчета СМО при смешанных приоритетах; и) Вид окна «О программе»

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

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

* модель на основе командного языка;

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

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

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

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

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

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

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

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

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

В соответствии с упомянутой концепцией пользовательский интерфейс должен обеспечить:

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

отыскание их отображения в БД и в диалоговом режиме формирование общей графической структуры системы управления;

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

отыскание в БД имитационных моделей, адекватных выбранным математическим моделям;

формирование в диалоговом режиме имитационной модели ТС, адекватной заданным задачам - функциям, и ее отображение на экране монитора;

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

4. Спецификация на программу