Автоматизированная информационная система программирования логики промышленных роботов для ООО "ВМЗ"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 23.06.2012
Размер файла 7,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Пояснительная записка

к дипломному проекту на тему

Автоматизированная информационная система программирования логики промышленных роботов для ООО “ВМЗ”

Введение

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

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

Разработка АИС программирования промышленных роботов актуальна, так ООО “ВМЗ” увеличивает количество проектов, что требует сокращение трудоёмкости выполнения одного проекта. Новизной разработки является возможность генерировать программные файлы с параметрами, определёнными в графическом интерфейсе, а также считывать информацию с программных файлов и представлять её в графическом интерфейсе.

1. Системотехническая часть

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

1.1 Описание объекта автоматизации

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

ООО “ВМЗ” - занимается мехобработкой, гальваникой, термообработка, сборочным производством, производством автомобильных компонентов, производством пресс-форм и штампов.

В решении проектных задач задействован мощный конструкторско-технологический ресурс.

Количество сотрудников составляет ? 2500 человек.

Общая площадь помещений 222 тыс.кв.м.

Производственные площади 109 тыс.кв.м.

Выпуск продукции составляет 3000000 тыс. руб. ежегодно (средний показатель за последние 5 лет).

За 39 лет Производство технологического оборудования и оснастки (с 01 октября 2011 года ООО "Волжский машиностроительный завод") прошло параллельный путь развития вместе с открытием и освоением российской и зарубежной наукой новейших технологий машиностроения. Начав с изготовления генераторов и стартеров для легковых автомобилей, сегодня ВМЗ российский лидер в области подготовки и оснащения производственных предприятий современным станочным и роботизированным оборудованием, автоматическими линиями, специальным оборудованием и инструментом.

Основные этапы становления и развития ВМЗ:

1972: Начало строительства в г. Тольятти завода генераторов и стартеров;

1977: Собраны первые фрезерные станки ОФ.55, СФ.250;

1979: Начато освоение автоматических манипуляторов МП-9С и МП-11;

1982: Промышленное освоение унифицированных узлов по лицензии Хюллер-Хилле;

1984: Начало серийного выпуска промышленного робота ПР 601/60 по лицензии ф.КУКА;

1984-1989: Проектирование и изготовление оборудования для автомобиля ВАЗ-2108, ВАЗ-2109;

1989-1997: Изготовление оборудования для семейства “десятых” автомобилей: 12 автоматических линий, 50 агрегатных станков, 35 портальных манипуляторов, 15 центровально-подрезных модулей, 11 сварочных линий, 10 РТК сварки деталей, 216 сварочных роботов;

2000: Объединение станкостроительных мощностей АВТОВАЗ в ПТО;

2000-2004: Подготовка производства автомобиля LADA KALINA;

2005-2007: Подготовка производства автомобиля LADA PRIORA;

2008: Объединение производственных мощностей ПТО и Производства Прессов и Штампов в Производство Технологического Оборудования и Оснастки.

2011: Выделение ПТОО в ООО "ВМЗ" - дочернее общество ОАО “АВТОВАЗ”.[1]

Описание организационно-штатной структуры конструкторского отдела систем управления технологического оборудования предприятия ООО "ВМЗ"

Структура предприятия ООО "ВМЗ" представлена на рисунке 1.

Рисунок 1 - Структура служб предприятия ООО "ВМЗ"

Структура службы заместителя генерального директора по развитию представлена на рисунке 2.

Рисунок 2 - Структура службы заместителя генерального директора по развитию

Конструкторский отдел систем управления технологического оборудования обеспечивает своевременную конструкторскую подготовку и авторский надзор производства электрооборудования и систем управления различного технологического оборудования путем решения следующих задач:

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

2. Авторский надзор соответствия выпускаемого оборудования требованиям конструкторской документации.

3. Решение оперативных вопросов внесения изменений в конструкторскую документацию, связанных с изменениями, возникающими в процессе производства.

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

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

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

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

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

9. Разработка и реализация планов НИОКР.

10. Разработка и согласование технических требований, предложений, заданий, на проектирование перспективных изделий.[2]

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

Рисунок 3 - Структура конструкторского отдела систем управления технологического оборудования

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

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

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

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

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

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

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

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

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

ѕ авторское сопровождение изготовления, монтажа и пусконаладки металлорежущего и специального оборудования.

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

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

ѕ авторское сопровождение пусконаладки технологического оборудования, изготовленного по проектам отдела.[2]

Группа программного обеспечения занимается непосредственно программированием роботов. При установке роботов на линию без внешнего контроллера программируется полностью вся логика робота, его взаимодействие с внешними устройствами, управление внешними осями. Также группе программного обеспечения перешла обязанность написания траекторий. Группа программного обеспечения - новое объединение. Она образована 1 февраля 2012 года. Перед ним поставлены задачи:

ѕ разработка технологии управления роботами другим роботом (технология master-slave);

ѕ переход на написание траекторий в offline режиме;

ѕ создание внутреннего стандарта программирования роботов;

ѕ изучение и коррекция машинных настроек роботов;

ѕ другие.

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

Постановка проблемы

Программирование промышленных роботов делится на два вида: Online-программирование и Offline-программирование.

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

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

Offline программирование - программирование робота на обыкновенном компьютере без непосредственного участия робота. Дает возможность программирования робота без остановки производственного процесса.

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

Графическое программирование (3D-модели) - это программирование контуров обрабатываемых деталей посредством запоминания отдельных пунктов, достаточно кропотливая работа, занимающая зачастую много времени. С развитием компьютерной техники и конструкторских программ, стало возможным применение CAD моделей для программирования траектории движения робота на графические модели деталей и затем интерпретировать их в язык программирования роботов. Данные программы позволяют так же создавать модели и прототипы робототехнических комплексов с роботами и периферийным оборудованием, которые наглядно отображают технологический процесс. Конечно, такие программы, не лишены недостатков и должны быть впоследствии адаптированы непосредственно на месте. Преимущество таких программ, бесспорно. Их использование экономит много времени и практически не останавливает производства, дает возможность работать с программами моделирования, которые позволяют увидеть работу робота прямо на экране монитора. Получаемое наглядное изображение дает возможность предварительной оценки многих параметров еще на стадии планирования и конструирования робототехнического комплекса.

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

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

В данном подпункте описана организационно-штатная структура ООО “ВМЗ” и отдела, в котором находится группа программирования промышленных роботов. Проблемой при программировании промышленных логики роботов является отсутствие автоматизированной системы и необходимость писать программы вручную, что влечёт за собой значительное повышение времени на написание и исправление ошибок программиста (опечаток) при отгадке программы.

1.2 Формализация существующих бизнес-процессов

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

Моделирование существующей технологии

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

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

Этапы программирования логики отображены ниже на рисунке 4.

Рисунок 4 - Существующая технология написания программы логики

Процесс определения логики программы является достаточно ёмким, его формализация представлена на рисунке 5.

Рисунок 5 - Процесс описания логики программы

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

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

Определение количества шагов (этапов) программы и количества условий каждого шага зависит непосредственно от решаемой задачи.

Матрица условий представляет собой таблицу (см.рис. 6).

Рисунок 6 - Матрица условий

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

io_init - файл условий и выходных сигналов.

io_update - файл обновления значений входов, определённых в условиях.

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

Далее происходит отладка программы по представленной выше схеме.

Выявление недостатков существующей технологии и поиск путей решения проблем

Существующая технология имеет существенные недостатки.

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

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

2. Написание кода вручную влечёт за собой увеличение количества ошибок (опечатки) и время написания.

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

3. Человеческие ошибки и невозможность быстро изменить (проанализировать) технологию в режиме offline приводит к частым сбоям программы на производстве. Это влечёт частое присутствие программиста на технологической операции производства для отладки кода в режиме online. Это занимает много рабочего времени программиста и отнимает возможность заниматься новыми проектами, изучением новых технологий, исследовательской деятельностью, что тормозит развитие отдела и производства в целом.

Существует несколько путей решения проблем автоматизации:

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

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

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

Для описанной выше проблемы единственным возможным путём решения является разработать систему “с нуля”, так как аналогов системы не существует.

Обоснование требований к разрабатываемой автоматизированной системе

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

Система программирования логики создаётся с целью:

ѕ обеспечения удобного написания логических программ промышленных роботов;

ѕ снижения трудоёмкости и времени написания программ

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

ѕ обеспечения возможности создания программ для роботов по технологии “Master-Slave” с гибкой структурой (разным числом управляемых роботов и разными параметрами управления).

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

ѕ время и удобство определения всех параметров программы

ѕ время написания логических программ промышленных роботов, за счёт генерации файлов программы

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

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

В системе предлагается выделить следующие функциональные подсистемы:

ѕ подсистема визуализации настойки входных и выходных сигналов;

ѕ подсистема визуализации и формирования параметров программы (этапы программы, условия и др.);

ѕ подсистема генерации программных файлов;

ѕ подсистема перевода программных файлов в графическое представление;

ѕ подсистема перевода программных файлов в графическое представление.

ѕ подсистема работы с хранилищем (импорт/экспорт).

Источниками данных для системы должны быть:

ѕ параметры создаваемой программы логики для промышленных роботов, определённых пользователем;

ѕ программные файлы (в случае изменения или анализа существующей программы).

Система должна поддерживать следующие режимы функционирования:

1. Режим начального программирования - режим создания программы “с нуля”, без использования уже созданных файлов программ.

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

К квалификации персонала, эксплуатирующего систему, предъявляются следующие требования:

ѕ знание соответствующей предметной области;

ѕ знание особенностей программирования промышленных роботов;

ѕ знание параметров программы для текущей (программируемой) задачи;

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

Требования к режимам работы персонала не предъявляются.

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

ѕ количество этапов программы - до 80;

ѕ количество условий каждого этапа - до 50;.

ѕ количество управляемых роботов - до 8.

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

ѕ сбой в электроснабжении рабочей станции пользователей системы;

ѕ ошибки системы, не выявленные при отладке и испытании системы.

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

Надежность программного обеспечения подсистем должна обеспечиваться за счет:

ѕ надежности общесистемного ПО и разрабатываемой системы;

ѕ проведением комплекса мероприятий отладки, поиска и исключения ошибок.

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

В части внешнего оформления:

ѕ интерфейсы подсистем должен быть типизированы и интуитивно понятны;

ѕ должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя;

ѕ размер шрифта должен быть не менее 12 пт;

ѕ цветовая палитра должна быть не раздражающих цветов;

ѕ должна выполняться проверка данных.

Требования к функциям, выполняемым системой, прописаны в таблице 1.

Таблица 1 - Функции системы

Функция

Задача

Определение входных и выходных сигналов

Чтение и изменение параметров системных сигналов

Сохранение информации во внутренних объектах программы

Определение этапов программы

Сохранение информации во внутренних объектах программы

Определение матрицы и выходных сигналов для этапов программы

Чтение имён входных и выходных сигналов

Вызов процедур переопределения списка сигналов (задание последовательности)

Сохранение информации во внутренних объектах программы

Описание сообщений для условий

Чтение имён входных сигналов

Чтение матрицы условий

Разграничение прав изменения для ячеек

Сохранение информации во внутренних объектах программы

Генерация файлов

Чтение всех внутренних объектов программы

Структуризация информации объектов

Генерация программных файлов

Сохранение и чтение программных файлов

Обращение к репозиторию

Чтение файлов

Сохранение файлов

Требования к математическому обеспечению не предъявляются.

Разрабатываемая система не должна быть закрыта для смежных систем и должно поддерживать возможность экспорта данных в смежные системы.

АИС должна обеспечить возможность загрузки данных, получаемых от смежной системы.

Генерируемые файлы должны иметь формат *.src и *.txt.

Требования к лингвистическому обеспечению:

ѕ при реализации системы должны применяться языки высокого уровня;

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

Разрабатываемая АИС должна быть совместимо с любой версией Windows, не старше Windows XP SP2.

К обеспечению качества подсистем предъявляются следующие требования:

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

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

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

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

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

Сервер хранилища данных должен быть развернут на IBM PC совместимом ЭВМ, минимальная конфигурация которого должна быть: RAM: 256 MB; HDD: 20 Gb; Network Card: 1 (100 MB).

Требования к метрологическому обеспечению не предъявляются.

Основными пользователями разрабатываемой АИС являются группа программистов промышленных роботов на ООО “ВМЗ”.

Требования к методическому обеспечению не предъявляются. [3,4,5]

В данном разделе описана технология обработки информации “как есть”, выделены следующие её недостатки:

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

ѕ написание кода вручную влечёт за собой увеличение количества ошибок (опечатки) и время написания;

ѕ невозможность быстро изменить (проанализировать) программу в режиме offline.

При поиске путей решения поставленной проблемы решено, что система будет разрабатываться “с нуля”.

1.3 Обоснование технологии разработки автоматизированной системы программирования логики промышленных роботов

Технология проектирования (технология разработки ПО) -- способ организации процесса создания программы, совокупность приемов и способов выполнения определенных видов деятельности. Выбор технологии проектирования и разработки автоматизированной системы программирования логики промышленных роботов. На разных уровнях формализации разработки и для разных критериев разработки (время, ресурсы, стоимость) выделяют пересекающиеся модели проектирования [6]:

1. RAD (Rapid Application Development) -- быстрая разработка приложений.

2. RUP (Rational Unified Process) - унифицированный процесс.

3. XP (eXtreme Programming) - экстремальное программирование.

4. Crystal Clear - методология, позволяющая менять степень формализации процесса разработки в зависимости от критичности задач и количества участников разработки.

5. FDD (Feature Driven Development) - функционально-ориентированная разработка.

6. MSF (Microsoft Solutions Framework) - методология разработки программного обеспечения, предложенная корпорацией Microsoft.

Для выбора технологии проектирования применяются следующие критерии:

1. Использование в технологии итеративного подхода.

0 - критерий не удовлетворяет требованию

10 - критерий удовлетворяет требованию

2. Формализованность процесса разработки.

0..5 - степень выполнения критерия

3. Создание документации в ходе разработки.

0..5 - степень выполнения критерия

4. Контроль рисков.

0..10 - степень выполнения критерия.

0 - риски непредсказуемы

10 - риски отсутствуют

5. Минимальное время разработки - 10 баллов

0..10 - степень выполнения критерия.

0 - разработка очень длительная

10 - разработка максимально быстрая

На основе сформированных критериев произведён выбор технологии. В таблице 2 представлена оценка каждой технологии.

Таблица 2 - Сравнение технологий проектирования

Методология

RAD

RUP

XP

CC

FDD

MSF

итеративный подход

5

5

5

5

5

5

формализованность процесса разработки

5

5

2

3

3

4

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

4

5

2

2

2

5

управление рисками

8

10

4

5

5

10

минимальное время разработки

9

5

10

10

10

6

И ТОГ:

31

30

23

25

25

30

На основе оценки [6] всех выбранных для сравнения технологий определено, что для разработки данного проекта наиболее приемлемая технология RAD.

Этапы RAD-технологии

1. Моделирование функционального поведения системы. Такую модель можно определить с помощью диаграммы вариантов использования UML.

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

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

4. Создание приложения. Используются готовые компоненты и утилиты автоматизации.

5. Объединение и тестирование.

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

Сравнительный анализ и выбор CASE-средств

На основе списка средств UML-моделирования, представленного в источнике [7], и информационного поиска по каждому средству моделирования выделены следующие основные средства для проектирования с помощью UML:

ѕ Visual Paradigm[8];

ѕ Rational Rose [9];

ѕ Borland Together [10];

ѕ ArgoUML [11];

ѕ Netbeans UML Plugin [12];

ѕ Eclipse Omondo Plugin [13];

ѕ Enterprise Architect [14].

Для выбора наиболее подходящего будут использоваться следующие критерии:

1. Возможность генерации программного кода.

2. Возможность производить реверс кода.

3. Поддержка ОС Windows.

4. Стоимость приобретения.

5. Опыт успешного использования (отзывы).

6. Простота освоения и использования.

Все критерии кроме стоимостного оценивается следующими балами:

0 - не удовлетворят требованию

5 - частично удовлетворяет требованию

10 - полностью удовлетворяет требованию

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

0 - высокая стоимость;

10 - средняя стоимость;

20 - бесплатно.

Выбор CASE-средства представлен в таблице 3.

Таблица 3 - Исходные данные для выбора CASE-средства

Visual Paradigm

Rational Rose

Borland Together

ArgoUML

Netbeans UML Plugin

Eclipse Omondo Plugin

Enterprise Architect

Возможность генерации программного кода

10

0

0

10

5

0

10

Возможность производить реверс кода

10

0

0

10

0

10

10

Поддержка ОС Windows

10

10

10

0

10

10

10

Стоимость приобретения

20

0

10

20

20

10

10

Опыт успешного использования (отзывы)

10

10

10

10

0

5

10

Простота освоения и использования.

10

5

10

10

10

5

10

ИТОГ:

70

25

40

60

45

40

60

Анализ показал, что наиболее подходящее для проектирования CASE-средство это Visual Paradigm.

В донном подразделе определено, что для разработки автоматизированной информационной системы программирования логики промышленных роботов будет использоваться модель RAD (быстрая разработка приложений). Проектирование будет производиться в CASE-средстве Visual Paradigm.

1.4 Разработка архитектуры автоматизированной системы программирования логики промышленных роботов

Автоматизированная информационная система программирования логики промышленных роботов генерирует сборку файлов программ для промышленных роботов. В процессе внедрения и отладки программ файлы сборки модифицируются. Также файлы могут меняться при проведении запланированной модернизации на уже запущенном и отлаженном комплексе. В результате подобных изменений появляются версии сборок программ. Для их структуризации и упорядочения предлагается внедрить систему управления версий. Система управления версиями (от англ. Version Control System, VCS или Revision Control System) -- программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое[15]. Система будет внедрена на сервере, где будет располагаться центральное хранилище файлов. АИС будет работать с системой управления версий локальную сеть. В настоящее время имеется достаточное количество систем управления версиями. На основе информационного поиска из списка систем управления версиями, представленного в источнике [16], выделены самые используемые системы управления версиями:

1. Subversion [17].

2. Arch [18].

3. Monotone [18].

4. OpenCM [18].

5. Aegis [18].

6. Darcs [19].

7. Git [20].

Для формирования критериев и их оценки необходимо определиться с архитектурой репозитариев и методом хранения изменений.

Репозитарии бывают централизованные и рассредоточенные. Централизованная архитектура изображается как центральный репозиторий ресурсов и множество разработчиков работающих с ним. Разработчик выгружает код из центрального репозитория на локальную машину (check out), и после внесения изменений, фиксирует их и загружает обратно в центральный репозиторий (commit), таким образом, и другие разработчики имеют доступ к его изменениям.

Рассредоточенный подход позволяет разработчикам работать со своими изолированными репозиториями, а не с локальными машинами. Они могут делать изменения, вносить их в свои локальные репозитории и синхронизировать изменения с другими разработчиками, не трогая главную ветку. Затем разработчики могут сделать набор изменений, доступный своим "вышестоящим" коллегам.[21]

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

Модели хранения версий бывают: модель "моментальных снимков" (snapshot model) и модели "набора изменений" (changeset model). В модели "моментальных снимков" хранятся файлы целиком для каждой версии (с оптимизацией размера дерева). В модели "набора изменений", хранится только разница в версиях, создавая компактный репозиторий. [21] В процессе настройки производственной ячейки возможен возврат к любой другой версии сборки программы или использование какой-либо версии сборки для другой ячейки. Это требование определяет, что наиболее подходящей моделью хранения версий является модель "моментальных снимков".

Критерии выбора системы управления версиями:

1. Перемещение и переименование файлов и директорий.

2. Копирование файлов и директорий.

3. Подробная история построчных изменений.

4. Возможность получения отдельной директории из репозитория.

5. Контроль изменений в рабочей копии, до commit'а в репозиторий.

Критерии с 1 по 5 оцениваются следующими баллами:

0 - система не удовлетворяет критерию;

2 - система удовлетворяет критерию.

6. Задание отдельного текста комментария для отдельного файла при commit'е.

Этот критерий является важным для работы со сборками программ, поэтому баллы его оценки выше.

0..5 - степень удовлетворения критерия.

7. Простота установки.

0..3 - степень удовлетворения критерия.

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

8. Централизованный репозиторий.

Оценки критерия:

0 - система использует распределённый репозиторий.

8 - система использует централизованный репозиторий.

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

9. Web-интерфейсы пользователя.

10. GUI интерфейсы пользователя.

Критерии 9-10 оцениваются по шкале 0..8, где 8 означает большое количество интерфейсов, 0 - интерфейсы отсутствуют.

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

11. Модель “моментальный снимок”.

Оценки критерия:

0 - система использует модель “набор изменений”.

8 - система использует модель “моментальный снимок”.

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

12. Работа под Windows.

Оценки критерия:

0 - система не поддерживает ОС Windows.

10 - система работает под ОС Windows.

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

13. Лицензия.

Критерий оценивается по шкале 1..10, где 10 - бесплатная система.

Сравнение систем управления версиями представлено в таблице 4.

Таблица 4 - Оценка систем управления версий

Системы управления

версиями

Критерии

Subversion

Arch

Monotone

OpenCM

Aegis

Darcs

Git

Перемещение и переименование файлов и директорий

2

2

2

2

2

2

2

Копирование файлов и директорий

2

0

2

0

0

0

0

Подробная история построчных изменений

2

2

2

0

2

2

2

Возможность получения отдельной директории из репозитория

2

0

0

0

2

0

0

Контроль изменений в рабочей копии, до commit'а в репозиторий

2

2

2

2

0

2

2

Задание отдельного текста комментария для отдельного файла при commit'е

5

0

5

0

2

0

0

Простота установки

1

3

3

2

2

2

2

Централизованный репозиторий

8

8

0

8

0

0

0

Web-интерфейсы пользователя

8

3

0

0

4

2

5

GUI интерфейсы пользователя

8

4

0

0

3

0

6

Модель “моментальный снимок”

8

0

8

8

0

0

0

Работа под Windows

10

0

10

10

0

10

10

Лицензия

10

10

10

10

10

10

10

ИТОГ:

66

34

52

40

25

28

37

Оценка осуществлялась с помощью источника [18,21,22]. Проведённая оценка показала, что наиболее подходящей системой управления версий является Subversion. Она также удовлетворяет описанным выше требованиям: имеет централизованную архитектуру репозиториев и использует модель “моментальных снимков” для хранения изменений. Эту систему можно внедрять под разными web-серверами. В предлагаемой архитектуре будет использоваться web-сервер Apache и модуль WebDAV. АИС будет обращаться к серверу как клиент Subversion. Предлагаемая архитектура отображена на рисунке 7.

Рисунок 7 - Архитектура системы

Итак, для эффективного использования разрабатываемой АИС предлагается внедрить систему управления версиями Subversion. Эта система имеет централизованную архитектуру репозитариев и использует модель “моментальных снимков” для хранения изменений. Обращение АИС к хранилищу данных происходит через локальную сеть. В качестве web-сервера будет использоваться web-сервер Apache и модуль WebDAV.

1.5 Разработка модели системы

Выше было определено, что для разработки системы программирования промышленных роботов будет использоваться технология RAD. Следуя её этапам, в данной части проекта осуществляется разработка модели системы. Разработка модели системы включает построение:

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

2. Диаграммы классов и диаграммы компонентов. Они отражают объекты, которые требуются для поддержки бизнес-процессов.

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

Моделирование функционального поведения системы

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

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

1) определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

2) сформулировать общие требования к функциональному поведению проектируемой системы;

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

4) подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. [23]

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

Требования к функционалу системы описаны выше. Модель системы “как будет” отображено на рисунке 8.

Рисунок 8 - Диаграмма вариантов использования

Из представленной модели видно, что программист имеет два варианта использования: создание программы “с нуля” и модификация написанной ранее программы. Функционал соответствует требованиям к функциям, выполняемым системой, описанным в пункте 1.2.4.

Моделирование данных

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

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

ѕ класс-сущность - класс, отображающий классы, которые являются хранилищами данных;

ѕ управляющий класс - класс, отвечающий за координацию действий других классов.

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

Граничным классом является форма отображения данных, хранящихся в объектах класса “Параметры программы”.

Сущностным классом является класс “Параметры программы”, который хранит данные обо всех параметрах программируемой логики.

Управляющим классом является класс подключения к системе управления версиями Subversion.

Рисунок 9 - Диаграмма коммуникации “Общая диаграмма классов”

Класс “Параметры программы” представляет собой совокупность классов, хранящих информацию о параметрах программируемой логики (см. рис. 10).

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

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

Рисунок 10 - Диаграмма классов

Класс “InOut” хранит информацию по входным и выходным сигналам.

Name - имя сигнала.

Num - программный номер сигнала.

Comment - описание сигнала.

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

Use - Назначение сигнала (собственный сигнал робота, системный сигнал, сигнал для Slave1, сигнал для Slave2). Определяет параметры генерации (имя и место описания сигнала).

Класс “InOutSlave” отражает уже обозначенные сигналы роботов Slave. Несколько роботов Slave могут использовать сигналы с одинаковыми названиями и комментриями. Список класса “InOutSlave” позволяет выбирать уже добавленные сигналы для роботов Slave (без дополнительной обработки списков входов и выходов) и значительно упрощает генерацию кода (программных файлов).

Name - имя сигнала.

Comment - описание сигнала.

InOut - вход/выход (true - вход, false - выход).

Каждый шаг программы содержит набор условий и выходных сигналов. Для хранения информаци по каждому условию используется класс “CondIn”, он хранит данные:

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

WaitStateIn - ожидаемое значение.

Mess - сообщение, выводимое при невыполнении условия.

MessType - тип выводимого сообщения.

Для хранения информации по каждому выходному сигналу используется класс с “CondOut”, он хранит следующую информацию:

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

StateOut - подаваемое значение.

Pulse - запрос подачи сигнала импульсом.

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

ListCondIn - список условий

ListCondOut - список выходных сигналов

Name - наименование шага

Num - программный номер шага

Методы класса “Step”:

SetCondOut(CondOut:list<string>) - записать выходные сигналы шага.

SetCondIn(CondIn: list<string>) - записать условия шага.

SetMess(ListMess list<string>,ListTypeMess:list<string>) - записать сообщения для условий. Номера списков ListMess и ListTypeMess соответствуют.

В главном классе программы “Logic” создаётся список шагов типа “Step”.

Методы классы “Logic”:

SetListAddInOut(ListAddInOut:list<string>) - записать в список добавленные сигналы (отметить как добавленные).

GetListNotAddInOut() - считать имёна сигналов, которые не добавлены в условия.

ChangeListAddInOut(NameInOut:string) - отметить переданный сигнал как добавленный.

GetListNameInOut() - считать список имён сигналов.

SortListInOut(ListInOut:list<string>) - отсортировать список сигналов в переданной последовательности.

SetListInOut(ListInOut:list<InOut>) - записать матрицу сигналов. Если список не пуст, то дописать недостающие сигналы.

DellNullObject() - удалить все объекты с удалённым полем Name, то есть нулевые объекты.

Элементы графического интерфейса (см. рис. 11) также являются объектами, которые участвуют в работе с данными.

Рисунок 11 - Диаграмма компонентов

Графический интерфейс представляет собой одну форму, которая включает в себя несколько вкладок. Каждая вкладка позволяет работать с определённым видом данных и определённым образом участвует в обмене данных с объектами классов.

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

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

Моделирование состояний графических элементов

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


Подобные документы

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

    курсовая работа [1,1 M], добавлен 06.04.2012

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

    курсовая работа [1,3 M], добавлен 27.12.2011

  • Классификация и назначение промышленных роботов. Применение робототехнических комплексов в промышленности. Назначение робототехнического комплекса "Ритм – 01". Описание инструментальных средств программирования и языки программирования контроллеров.

    дипломная работа [2,4 M], добавлен 17.07.2012

  • Разработка автоматизированной информационной системы "Супермаркет DNS" с опорой на платформу NET, в среде MS Visual Studio, на языке программирования C. Объектная модель программной системы согласно методологии ОМТ. Описание алгоритмов обработки данных.

    курсовая работа [394,0 K], добавлен 21.10.2012

  • Автоматизированные информационные системы и их структура. Обзор существующих автоматизированных информационных систем "Расписание". Структурный подход к проектированию автоматизированной системы "Расписание", построение моделей данных и анализ внедрения.

    дипломная работа [3,1 M], добавлен 29.06.2010

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

    контрольная работа [486,7 K], добавлен 29.10.2013

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

    дипломная работа [1,2 M], добавлен 14.10.2012

  • Методы разработки автоматизированных систем. Характеристика языка программирования Delphi и операционной системы Windows. Разработка автоматизированной системы контроля знаний на примере дисциплины "История мира". Этапы разработки программного продукта.

    курсовая работа [3,8 M], добавлен 18.05.2014

  • Основы визуального программирования интерфейса. Архитектура программных систем. Проектирование базы данных. Анализ предметной области и связей между сущностями. Построение модели "сущность-связь". Разработка автоматизированной информационной системы.

    курсовая работа [4,4 M], добавлен 16.11.2014

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

    контрольная работа [848,9 K], добавлен 04.06.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.