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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¾      переход на написание траекторий в 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) - унифицированный процесс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.   Минимальное время разработки - 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.

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

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

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

Таким образом, определено, что для проектирования используется модель 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.       Возможность производить реверс кода.

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

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

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

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

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

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

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

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

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

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

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

- бесплатно.

Выбор 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
Стоимость приобретения		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].

.        Monotone [18].

.        OpenCM [18].

.        Aegis [18].

.        Darcs [19].

.        Git [20].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- система работает под ОС 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.       Диаграммы классов и диаграммы компонентов. Они отражают объекты, которые требуются для поддержки бизнес-процессов.

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

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

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

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

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

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

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

)        подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. [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>) - записать условия шага.(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). К блоку формирования параметров программы пользователь может перейти сразу, если программа формируется “с нуля”. Если параметры программы читаются из файлов, то после чтения пользователь может перейти к блоку формирования параметров для изменения считанных параметров. Также пользователь может вернуться к блоку формирования параметров после генерации файлов для изменения параметров. После формирования параметров программы или их изменения необходимо сгенерировать программные файлы, так как они являются результатом работы разрабатываемой системы.

Рисунок 12 - Общая диаграмма состояний системы

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

При формировании параметров программы программист первым делом может определить:

1.   Этапы программы.

2.       Входные сигналы.

.        Выходные сигналы.

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

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

Остальные состояния системы и переходы к ним отображены на рисунке 13.

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

Рисунок 13 - Диаграмма состояний “Формирование параметров программы”

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

В обработке данных при выполнении процесса определения входных сигналов задействованы следующие объекты (см. рис. 14):

1.   Вкладка интерфейсной формы “Входные сигналы”.

2.       Список ListIn класса Logic - список входных сигналов.

.        Список ListUse класса Logic - список назначений.

.        Список ListSigSlave класса Logic - список сигналов для роботов Slave.

При вызове метода отображения вкладки вызываются методы чтения имён входных сигналов (метод GetListNameIn()) и сгенерированных назначений (метод GetListUse()). Пользователю отображается таблица с выпадающими списками для выбора назначения сигнала (Robot - сигнал подключенного к роботу оборудования, SYS - системный сигнал робота, SlaveX - сигнал управления роботом Slave №X) и имени. При выборе назначения сигнала “SYS” в списке отображаются все системные входа робота, они считаются методом GetListSysIn(). При выборе назначения сигнала “SlaveX” в списке отображаются все сигналы уже определённые для других роботов Slave. То есть если программируемый робот управляет несколькими роботами Slave, и для одного робота уже определены какие-то входные сигналы, то для другого робота Slave можно использовать уже определённое имя сигнала. Это предусмотрено в связи с частым повторением имён сигналов для разных роботов Slave при программировании одной задачи. Также имеется возможность определить другое имя сигнала (новое).

При вызове метода деактивации вкладки (переход на другую вкладку) вызывается метод записи всей информации о входных сигналах SetListIn(ListInOut : list<InOut>). Блоки сообщений “ref” отображают пользовательскую последовательность команд. На приведённой диаграмме применяется для отображения ветвления.

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

В обработке данных при выполнении процесса определения входных сигналов задействованы следующие объекты (см. рис. 15):

1.   Вкладка интерфейсной формы “Условия шагов”.

2.       Список ListIn класса Logic - список входных сигналов.

.        Список Steps класса Logic - список этапов программы.

Рисунок 14 - Диаграмма последовательности действий системы при выполнении процесса определения входных сигналов

При вызове метода отображения вкладки вызывается метод чтения условий шагов программы GetCondIn(). Этот метод вызывается для каждого шага программы, поэтому вызов данного метода занесён в блок “loop”. После чтения данных пользователю отображается таблица условий с именами входов. Если при программировании данной задачи пользователь впервые заходит на вкладку, то отобразится пустая таблица и выпадающие списки прописанных на вкладке “Входные сигналы” имена входов.

При переопределении последовательности условий (входных сигналов) вызывается метод, записывающий добавленные в список сигналы SetListAddIn(ListAddIn : list<string>), и метод, читающий не добавленные в список сигналы GetListNotAddIn(). Это предусмотрено, чтобы исключить ручной ввод имён входных сигналов и повторный выбор сигнала из списка.

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

При вызове метода деактивации вкладки (переход на другую вкладку) вызывается метод удаления пустых объектов из списка входных сигналов DellNullObject (ListInOut : list<InOut>) и метод сортировки SortListInOut (ListNameInOut : list<string>, ListInOut : list<InOut>). Далее для каждого шага записывается массив условий (метод SetCondIn(CondIn : list<string>)). SortListInOut(ListNameInOut : list<string>, ListInOut : List<InOut>) - метод сортировки. Список ListIn сортируется в последовательности, которую пользователь задал при определении условий. Это применяется для возможности склейки списка входных сигналов с матрицей условий.

Рисунок 15 - Диаграмма последовательности действий системы при выполнении процесса определения условий шагов программы

Моделирование обработки данных при выполнении процесса написания сообщений

В обработке данных при выполнении процесса определения входных сигналов задействованы следующие объекты (см. рис. 16):

1.   Вкладка интерфейсной формы “Сообщения”.

2.       Список ListIn класса Logic - список входных сигналов.

.        Список Steps класса Logic - список этапов программы.

При вызове метода отображения вкладки вызывается методы чтения имён входных сигналов GetListNameIn(), чтения условий шагов программы GetCondIn() и чтения уже написанных сообщений GetMess().

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

При вызове метода деактивации вкладки (переход на другую вкладку) вызывается метод записи сообщений и статуса сообщений SetMess(ListMess : list<string>, ListTypeMess : list<string>). Метод вызывается для всех шагов программы.

Подробное описание назначения некоторых методов приведено в разделе “Разработка основных алгоритмов”.

В данном подразделе выделены варианты использования разрабатываемой АИС: создание программы и модификация программы (анализ). Каждый из них содержит свои этапы. При моделировании данных выделено три абстрактных класса:

¾  граничный класс “Форма отображения данных”;

¾      сущностный класс “Параметры программы”;

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

Рисунок 16 - Диаграмма последовательности действий системы при выполнении процесса написания сообщений

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

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

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

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

¾      генерировать программные файлы;

¾      экспортировать сборку программных файлов в хранилище данных по локальной сети;

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

¾      изменять параметры программы и создавать новую сборку;

¾      импортировать сборку программных файлов из хранилища данных;

¾      работать со сборками программных файлов (сохранять и считывать) на локальном компьютере.

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

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

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

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

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

Для разработки АИС должна использоваться технология RAD, для проектирования CASE-средство - Visual Paradigm.

Для функционирования системы необходимо внедрить систему управления версиями Subversion. В качестве её web-сервера использовать web-сервер Apache и модуль WebDAV.

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

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

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

При моделировании АИС выделены следующие варианты использования: создание программы и модификация программы (анализ). Создание программы включает этапы:

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

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

¾      определение матрицы условий и выходных сигналов для шагов программы;

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

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

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

При моделировании данных выделено три абстрактных класса:

¾  граничный класс “Форма отображения данных”;

¾      сущностный класс “Параметры программы”;

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

Расписан сущностный класс “Параметры программы”.

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

2. Конструкторско-технологическая часть

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

2.1 Выбор средств реализации

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

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

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

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

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

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

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

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

Для выбора подходящего языка программирования необходимо рассмотреть мировые тенденции в области современных языков программирования. Для большей достоверности будут рассмотрены рейтинги современных языков программирования двух компаний TIOBE Software и DOU.

Рейтинг языков программирования, составленный компанией TIOBE Software представлен на рисунке 17.

Рисунок 17 - Рейтинг языков программирования компании TIOBE Software

По данным компании TIOBE Software лидером среди языков программирования является Java.

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

1.   Экономическая доступность. Для разработки программ на языке Java существует несколько свободно распространяемых сред разработки.

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

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

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

.        Архитектурная независимость. Центральной проблемой для проектировщиков Java была долговечность. Проектировщики сделали несколько жёстких решений в языке и виртуальной Java-машине в попытке решения этой проблемы. Их цель можно сформулировать так: “запись - однажды; выполнение - везде, в любое время, всегда”. В значительной степени эта цель была достигнута.

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

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

Компания DOU предоставляет другой рейтинг (см. рис. 18).

Рисунок 18 - Рейтинг языков программирования компании DOU

По данным компании DOU лидером среди языков программирования является С#. Но данный язык программирования не соответствует первому из поставленных требованию: для программирования на С# разработана своя среда Visual Studio от корпорации Microsoft. Для разработки коммерческих проектов необходимо использовать версии Professional или Ultimate. Обе эти версии платные (Professional 550$, Ultimate 12000$). [26] Таким образом, данный язык программирования уже уступает выделенному лидеру.

Вторым в рейтинге компании DOU является язык программирования Java. Его соответствия поставленным требованиям уже расписаны выше.

Таким образом, разработка автоматизированной информационной системы программирования логики промышленных роботов для ООО “ВМЗ” будет производиться на объектно-ориентированном языке программирования Java. Система будет разрабатываться в среде NetBeans, она свободно распространяемая, также имеются навыки работы в этой среде. [27,28,29]

2.2 Разработка пользовательского интерфейса

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

1.   Генерация/Чтение.

2.       Входные сигналы.

.        Выходные сигналы.

.        Шаги.

.        Условия шагов.

.        Сообщения.

.        Сигналы шагов.

.        Системные переменные.

Каждая вкладка работает с определёнными данными.

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

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

Рисунок 19 - Общий вид формы

Режим программирования можно менять в любой момент. При этом списки назначений генерируются автоматически.

Описание вкладки “Входные сигналы”

На вкладке “Входные сигналы” расположена таблица, первый столбец которой состоит из выпадающих списков. Каждая ячейка первого столбца (столбец “Назначение”) содержит список возможных назначений. Если заданный режим программирования “Robot”, то список назначений содержит две строки “Robot” и “SYS”. Назначение “Robot” определяет сигналы устройств, подключенных к роботу. Это может быть оснастка, элементы безопасности (фотобарьеры) и другие. Назначение “SYS” определяет системные сигналы робота. Имеется определённый неизменяющийся набор системных сигналов робота. При выборе назначения “SYS” возможно выбрать сигнал, то есть изменить номер входа/выхода сигнала. Остальная информация о системных сигналах (имя, комментарий) не изменяется. Все системные сигналы прописаны в таблице на вкладке “Системные переменные”. Если заданный режим программирования “Master”, то в список назначений добавляются назначения роботов Slave по количеству указанному при определении режима программирования (см. рис. 20).

Рисунок 20 - Вкладка “Входные сигналы”. Заполнение

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

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

Рисунок 21 - Вкладка “Входные сигналы”. Сигналы slave2

При программировании робота, который управляет несколькими роботами Slave, имеется возможность дублировать сигналы. То есть, если для одного робота Slave уже прописаны какие-то сигналы, то их имена можно использовать для определения сигналов другого робота Slave. Эта возможность предусмотрена, так как при решении одной производственной задачи все роботы обмениваются однотипными сигналами. Но разные роботы также могут иметь уникальные сигналы. Чтобы добавить новый сигнал для Slave необходимо выбрать строку выпадающего списка “new” и вписать имя сигнала.

Описание вкладки “Шаги”

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

Рисунок 22 - Вкладка “Шаги”

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

Описание вкладки “Условия шагов”

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

Рисунок 23 - Вкладка “Условия шагов”. Общий вид

При выборе сигналов блока выбранный сигнал удаляется из выпадающего списка (см. рис. 24). Это реализовано для исключения возможности повторного выбора одного сигнала.

Рисунок 24 - Вкладка “Условия шагов”. Списки

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

Описание вкладки “Сигналы шагов”

Выходные сигналы имеют 4 вида: пульсирующий сигнал с положительным фронтом, пульсирующий сигнал с отрицательным фронтом, постоянный положительный сигнал, постоянный отрицательный сигнал. Для пульсирующих сигналов задаётся одинаковое время сохранения поданного сигнала (см. рис. 25). По умолчанию это время пульсирующего сигнала 0,5 сек., но его можно менять.

Рисунок 25 - Вкладка “Сигналы шагов”

Также как и на вкладке “Условия шагов” выходные сигналы делятся на блоки, которые отображают сигналы одного назначения и имеют разные цвета. Цвет одного назначения один на разных вкладках, то есть на вкладке “Выходные сигналы” отображение идентично отображению на вкладке “Входные сигналы”.

Описание вкладки “Системные переменные”

Системные переменные для робота определены системой управления (KRC). В программу занесены имена системных переменных и их расшифровка. Все переменные отображаются в одной таблице, поэтому имеется столбец “IN/OUT/Variable”, который определяет происхождение сигнала (см. рис. 26). В разрабатываемой системе прописаны только те системные переменные, которые имеют битовый тип данных (boolean), так другие системные переменные не используются при программировании логики промышленного робота.

Рисунок 26 - Вкладка “Системные переменные”

На вкладке “Системные переменные” отсутствует возможность изменять данные переменных. В программе можно менять только номера системных входов/выходов. Номера системных входов/выходов на вкладке “Системные переменные” меняются автоматически при переопределении сигнала на вкладке “Входные сигналы” или “Выходные сигналы”.

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

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

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

Функция записи списка входных сигналов

Метод SetListIn (ListInOut : list<InOut>) записывает данные в список ListIn. Этот метод нельзя назвать стандартным, так как он не просто перезаписывает данные, но при перезаписи проверяет наличие в списке записываемых объектов по полям “Имя” и “Номер” (см. рис. 27). Эти поля выбраны для проверки, так как при переопределении сигнала может измениться имя уже используемого сигнала или номер.

Рисунок 27 - Алгоритм метода “SetListIn”

Метод SetListIn(ListInOut : list<InOut>) сначала проверяет присутствие объектов в списке по полю “Имя”, затем по полю “Номер”. Это аргументируется тем, что чаще меняется имя сигнала, чем его номер.

Функция удаления пустых объектов из списка

DelNullObject (ListInOut : list<InOut>) - метод удаления пустых объектов из списка входных сигналов. В процессе переопределения входных сигналов какие-то сигналы удаляются, какие-то сигналы добавляются. Так как объекты списка Steps ссылаются на номера объектов списка ListIn, то при удалении и добавлении объектов в список ListIn будет теряться связь в списке Steps. Чтобы избежать данной проблемы при удалении входных сигналов, объекты, содержащие эти сигналы, не удаляются, а происходит удаление имени сигнала (см. рис. 28). При перезаписи списка Steps объекты списка ListIn с обнулёнными именами удаляются методом DelNullObject.

Рисунок 28 - Алгоритм метода “DelNullObject”

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

Функция чтения списка не добавленных в условия входных сигналов

После определения сигналов и записи их в список ListIn пользователь на форме определяет последовательность сигналов при проверке условий шагов программы. Выбор сигналов происходит из списка сигналов, которые ещё не прописаны в последовательности. Для облегчения функциональности графического интерфейса проверка на отсутствие сигналов в последовательности происходит методом GetListNotAddIn(), который считывает поле AddIn у объектов и формирует список не прописанных в последовательности сигналов (см. рис. 29).

Рисунок 29 - Алгоритм метода “GetListNotAddIn”

Метод возвращает список имён сигналов, так как для формирования последовательности используется только это поле объекта.

Функция сортировки списков в пользовательской последовательности

Метод SortListInOut (ListNameInOut : list<string>, ListInOut : List<InOut>) предназначен для сортировки объектов списков в последовательности, заданной пользователем. При определении сигналов и первой их записи они записываются в список в порядке чтения с таблицы. При определении условий или выходных сигналов пользователь определяет последовательность проверяемых/передаваемых сигналов. Чтобы сохранить эту последовательность для дальнейшего чтения список сортируется. Алгоритм функции сортировки представлен на рисунке 30.

Рисунок 30 - Алгоритм метода “SortListInOut”

Методы SetListIn, DelNullObject, SortListInOut обеспечивают сохранение связи между списками ListIn и Steps. Методы SetListOut, GetListNotAddOut для списка ListOut аналогичны методам SetListIn и GetListNotAddIn, поэтому нет надобности описания их функциональности. Программный код методов отображён в Приложении А.

Функция генерации файла конфигурации

Вся информация, хранящаяся в объектах, записывается в следующие файлы:

¾  init.src;

¾      update.src;

¾      config.txt;

¾      comment.txt;

¾      machine.dat.

Файл comment.txt является вспомогательным, он хранит комментарии. Остальные файлы являются необходимыми для конфигурации системы и работоспособности технологии. Файл config.txt содержит глобальные переменные, необходимые для работоспособности технологии. Файл config.txt содержит блок данных, который является частью данных файла config.dat. Алгоритм метода “GenConfig” удобнее описать, так как блок схема будет перегружена строковыми переменными. При описании алгоритма постоянные строки программы не будут прописаны, полный текст файла можно увидеть в Приложении Б.

Алгоритм метода “GenConfig”:

1.   Прописать название фолда (блока данных) и неизменяемые структуры (типы данных).

2.       Если список назначений ListUse содержит только два объекта, перейти к шагу 4.

.        Прописать структуру данных SLAVEROBTYPE, содержащую перечень сигналов slave из списка ListSigSlave.

.        Прописать переменные хранящие количество шагов программы, количество условий и время пульсации.

.        Если список назначений ListUse содержит только два объекта, перейти к шагу 8.

.        Объявить массив SLAVEROB. Размерность массива соответствует количеству назначений slaveX.

.        Для каждого элемента массива SLAVEROB прописать все переменные списка ListSigSlave. Если в списке ListIn/ListOut с соответствующим назначением отсутствует объект ListIn.Name== ListSigSlave(текущий), то после прописи сигнала поставить 0, иначе записать ListIn.Num.

.        Прописать закрытие фолда переменных и открытие фолда сигналов.

.        Прописать имена и номера сигналов с назначением “Robot”.

.        Прописать закрытие фолда сигналов.

Результаты функций генерации с привязкой к объектам отображены в Приложении В.

Таким образом, в данном подпункте описаны следующие методы:

¾  алгоритм метода “SetListIn”, реализующий функцию записи списка входных сигналов;

¾      алгоритм метода “DelNullObject”, реализующий функцию удаления пустых объектов из списка;

¾      алгоритм метода “GetListNotAddIn”, реализующий функцию чтения списка не добавленных в условия входных сигналов;

¾      алгоритм метода “SortListInOut”, реализующий функцию сортировки списков в пользовательской последовательности;

¾      алгоритм метода “GenConfig”, реализующий функцию генерации блока основного файла конфигурации config.txt.

Алгоритмы методов SetListOut, GetListNotAddOut для списка ListOut аналогичны методам SetListIn и GetListNotAddIn, поэтому нет надобности описания их функциональности. Код программы с реализацией методов отображён в Приложении А. Результаты функций генерации “GenInit”, “GenUpdate” и “GenConfig” с привязкой к объектам отображены в Приложении Б.

.4 Тестирование системы программирования логики промышленных роботов

Тестирование программного обеспечения - процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

Полное тестирование любой системы включает:

1.   Функциональное тестирование (functional testing) - это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

2.       Тестирование производительности (performance testing) - тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой.

.        Юзабилити-тестирование (usability testing) - исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект для его предполагаемого применения (Проверка эргономичности).

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

.        Тестирование безопасности (security testing) - оценка уязвимости программного обеспечения к различным атакам.

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

.        Тестирование совместимости (compatibility testing) - метод, основной целью которого является обеспечение качественной работы конечного продукта с другими программами, операционными системами, железом. [30, 31]

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

Функциональное тестирование

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

При тестировании будет проверено:

1.   Наличие графических элементов.

2.       Выполнение функций общей формы.

.        Выполнение функций вкладки “Генерация/Чтение”.

.        Выполнение функций вкладки “Входные сигналы”

.        Выполнение функций вкладки “Выходные сигналы”.

.        Выполнение функций вкладки “Шаги”.

.        Выполнение функций вкладки “Условия шагов”.

.        Выполнение функций вкладки “Сообщения”.

.        Выполнение функций вкладки “Сигналы шагов”.

.        Выполнение функций вкладки “Системные переменные”.

.        Корректная работа с Subversion

После тестирования будет составлен BugReport, отражающий ошибки позитивного и негативного тестирования.

Таблица 5 - Тест-кейс для позитивного тестирования АИС программирования логики промышленных роботов

Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Назначение: Наличие графических элементов
Наличие RadioButton для выбора режима программирования	-	RadioButton “Robot” и “Master”	pass
Наличие Spinner для выбора количества Slave	-	Элемент Spinner присутствует	pass
Наличие вкладки “Генерация/Чтение”	-	Элемент присутствует	pass
Наличие вкладки “Входные сигналы”	-	Элемент присутствует	pass
Наличие вкладки “Выходные сигналы”	-	Элемент присутствует	pass
Наличие вкладки “Шаги”	-	Элемент присутствует	pass
Наличие вкладки “Условия шагов”	-	Элемент присутствует	pass
Наличие вкладки “Сообщения”	-	Элемент присутствует	pass
Наличие вкладки “Сигналы шагов”	-	Элемент присутствует	pass
Наличие вкладки “Системные переменные”	-	Элемент присутствует	pass
Закрытие программы по окончанию работы	1. Зайти на вкладку “Генерация/Чтение”. 2. Определить параметры сохранения. 3. Нажать на кнопку “Генерация”. 4. Закрыть программу	Закрытие программы	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Преждевременное закрытие программы	Закрыть программу без генерации файлов	Диалог “Сохранить данные перед закрытием?”	pass
Назначение: Выполнение функций общей формы
Выбор режима программирования “Robot”	Выбрать RadioButton “Robot”	Элемент Spinner не активен	pass
Выбор режима программирования “Master”	Выбрать RadioButton “Master”	Элемент Spinner активен	pass
Увеличения количества slave до 8	Увеличить значение элемента Spinner до 8	Значение элемента Spinner 8	pass
Назначение: Выполнение функций вкладки “Входные сигналы”
Наличие назначений “Robot” и “SYS” при режиме программирования “Robot”	1. Выбрать RadioButton “Robot”. 2. Перейти на вкладку “Входные сигналы”. 3. Раскрыть список в столбце назначение.	Список содержит две строки “Robot” и “SYS”	pass
Наличие назначений “Slave1” и “Slave2” при выборе двух slave	1. Выбрать RadioButton “Master”. 2. Увеличить значение Spinner до двух. 3. Перейти на вкладку “Входные сигналы”. 4. Раскрыть список в столбце назначение.	Список содержит строки “Robot”, “SYS”, “Slave1”, “Slave2”	pass
Выделение цветом строк с разными назначениями сигналов	-	Строки поделены на группы по назначениям. Группы строк разных цветов.	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Наличие выпадающего списка в поле “Имя” при выборе назначения “SYS”	В столбце “Назначение” выбрать назначение “SYS”	В столбце “Имя” появился выпадающий список	pass
Наличие всех входных системных сигналов в выпадающем списке в поле “Имя” при выборе назначения “SYS”	1. В столбце “Назначение” выбрать назначение “SYS”. 2. В столбце “Имя” раскрыть выпадающий список.	Строки списка соответствуют системным входным сигналам	pass
Отображение всех 1026 номеров в поле “Номер”	Пролистать таблицу до конца	В столбце “Номер” отображены все номера от 1 до 1026	pass
Последовательное отображение номеров в поле “Номер”	Пролистать таблицу до конца	В столбце “Номер” все номера записаны последовательно	pass
Наличие выпадающего списка в поле “Имя” при выборе назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” раскрыть выпадающий список.	Строки списка содержат имена Slave1 и строку “new”	pass
Возможность выбора имени из выпадающего списка при выборе назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” выбрать в выпадающем списке имя.	Выбранное имя добавлено в ячейку.	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Возможность задания нового имени при выборе назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” выбрать в выпадающем списке строку “new”.	В столбце “Имя” пустая строка с курсором.	pass
Дублирование комментария при выборе имени из выпадающего списка для назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” выбрать в выпадающем списке имя.	В столбце “Комментарий” появился комментарий выбранного имени	pass
Назначение: Выполнение функций вкладки “Выходные сигналы”
Наличие назначений “Robot” и “SYS” при режиме программирования “Robot”	1. Выбрать RadioButton “Robot”. 2. Перейти на вкладку “Выходные сигналы”. 3. Раскрыть список в столбце назначение.	Список содержит две строки “Robot” и “SYS”
Наличие назначений “Slave1” и “Slave2” при выборе двух slave	1. Выбрать RadioButton “Master”. 2. Увеличить значение Spinner до двух. 3. Перейти на вкладку “Выходные сигналы”. 4. Раскрыть список в столбце назначение.	Список содержит строки “Robot”, “SYS”, “Slave1”, “Slave2”	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Выделение цветом строк с разными назначениями сигналов	-	Строки поделены на группы по назначениям. Группы строк разных цветов.	pass
Наличие выпадающего списка в поле “Имя” при выборе назначения “SYS”	В столбце “Назначение” выбрать назначение “SYS”	В столбце “Имя” появился выпадающий список	pass
Наличие всех входных системных сигналов в выпадающем списке в поле “Имя” при выборе назначения “SYS”	1. В столбце “Назначение” выбрать назначение “SYS”. 2. В столбце “Имя” раскрыть выпадающий список.	Строки списка соответствуют системным входным сигналам	pass
Отображение всех 1026 номеров в поле “Номер”	Пролистать таблицу до конца	В столбце “Номер” отображены все номера от 1 до 1026	pass
Последовательное отображение номеров в поле “Номер”	Пролистать таблицу до конца	В столбце “Номер” все номера записаны последовательно	pass
Наличие выпадающего списка в поле “Имя” при выборе назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” раскрыть выпадающий список.	Строки списка содержат имена Slave1 и строку “new”	pass
Возможность выбора имени из выпадающего списка при выборе назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” выбрать в выпадающем списке имя.	Выбранное имя добавлено в ячейку.	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Возможность задания нового имени при выборе назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” выбрать в выпадающем списке строку “new”.	В столбце “Имя” пустая строка с курсором.	pass
Дублирование комментария при выборе имени из выпадающего списка для назначения “Slave2”	1. В столбце “Назначение” выбрать назначение “Slave2”. 2. В столбце “Имя” выбрать в выпадающем списке имя.	В столбце “Комментарий” появился комментарий выбранного имени	pass
Написание целого числа в поле “Номер”	Записать целое число в поле “Номер”	Число записано	pass
Написание комментария в поле “Комментарий”	Записать текст в поле “Комментарий”	Текст записан	pass
Добавление строки после выделенной	1. Выделить строку.  2. Нажать кнопку “Добавить шаг после текущего”.	Добавлена строка после выделанной строки	pass
Удаление выделенной строки	1. Выделить строку.  2. Нажать кнопку “Удалить текущий шаг”.	Выделенная строка удалена	pass
Назначение: Выполнение функций вкладки “Условия шагов”
Наличие выпадающих списков в столбце “Входа”	-	Элемент присутствует	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Разделение цветом блоков строк по назначениям	-	Строки поделены на группы по назначениям. Группы строк разных цветов.	pass
Выпадающий список в блоке одного назначения имеет сигналы только этого назначения	Раскрыть выпадающий список	Строки списка соответствуют записанным сигналам под данным назначением	pass
При выборе сигнала он исчезает из списка	1. Открыть выпадающий список.  2. Выбрать сигнал. 3. Открыть на другой строке выпадающий список этого же назначения.	Список содержит только не прописанные в столбце имена сигналов.	pass
При удалении имени сигнала из ячейки “Входа” удалённый сигнал появляется в списке	1. Выбрать сигнал из списка. 2. Проверить отсутствие выбранного сигнала в списке. 3. Удалить ранее выбранный сигнал из ячейки.	Удалённый сигнал присутствует в списке.	pass
Количество столбцов шагов равно количеству шагов	Сравнить количество шагов на вкладке “Условия шагов” с количеством шагов на вкладке “Шаги”	Количество шагов программы и их номера совпадают.	pass
Запись объектов при вводе 0/1 в ячейки условий шагов	1. Записать в ожидаемые значения сигналов цифры 0/1. 2. Перейти на другую вкладку. 3. Вернуться на вкладку “Условия шагов”.	Данные отображены также как были записаны (объекты записаны и считаны корректно)	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Назначение: Выполнение функций вкладки “Сообщения”
Активизация ячеек сообщений	-	Ячейки для написания сообщений на условиях, в которых прописаны ожидаемые значения, активны	pass
Блокировка ячеек сообщений.	-	Ячейки для написания сообщений на условиях, в которых прописаны ожидаемые значения, не активны	pass
Возможность выбора статуса сообщения из выпадающего списка	В активной ячейке выбрать статус сообщения	В ячейке записан статус сообщения	pass
Возможность написать сообщения для всех шагов и необходимых условий	-	Таблица отображает все необходимые ячейки	pass
Назначение: Выполнение функций вкладки “Сигналы шагов”
Наличие выпадающих списков в столбце “Выхода”	-	Элемент присутствует	pass
Разделение цветом блоков строк по назначениям	-	Строки поделены на группы по назначениям. Группы строк разных цветов.	pass
Выпадающий список в блоке одного назначения имеет сигналы только этого назначения	Раскрыть выпадающий список	Строки списка соответствуют записанным сигналам под данным назначением	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
При выборе сигнала он исчезает из списка	1. Открыть выпадающий список.  2. Выбрать сигнал. 3. Открыть на другой строке выпадающий список этого же назначения.	Список содержит только не прописанные в столбце имена сигналов.	pass
При удалении имени сигнала из ячейки “Входа” удалённый сигнал появляется в списке	1. Выбрать сигнал из списка. 2. Проверить отсутствие выбранного сигнала в списке. 3. Удалить ранее выбранный сигнал из ячейки.	Удалённый сигнал присутствует в списке.	pass
Количество столбцов шагов равно количеству шагов	Сравнить количество шагов на вкладке “Условия шагов” с количеством шагов на вкладке “Шаги”	Количество шагов программы и их номера совпадают.	pass
Запись объектов при вводе 0/1/Р0/Р1 в ячейки условий шагов	1. Записать в ожидаемые значения сигналов 0,1,Р0,Р1. 2. Перейти на другую вкладку. 3. Вернуться на вкладку “Сигналы шагов”.	Данные отображены также как были записаны (объекты записаны и считаны корректно)	pass
Увеличение времени сигнала	Увеличить значение элемента Spinner	Значение увеличивается	pass
Уменьшение времени сигнала до 0	Уменьшить значение элемента Spinner до 0	Значение элемента Spinner 0	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Назначение: Выполнение функций вкладки “Системные переменные”
Отображение системных переменных и данных по ним	-	Присутствие всех системных переменных и корректная расшифровка переменных	pass
Изменение данных	Удалить текст из ячейки	Изменение текста заблокированно	pass
Соответствие номеров системных переменных с изменениями на вкладках определения сигналов	1. Перейти на вкладку “Входные сигналы”. 2. Выбрать назначение “SYS”. 3. Выбрать имя системного сигнала. 4. Перейти на вкладку “Системные переменные”. 5. Сравнить номера сигналов на вкладках “Входные сигналы” и Системные переменные	Номера сигналов совпадают	pass
Назначение: Корректная работа с Subversion
Извлечение сборки из хранилища	1. Определить путь сборки в хранилище. 2. Определить путь локального сохранения рабочей копии. 3. Нажать кнопку “Извлечь”.	Сборка сохранена по указанному пути. Данные отображены в АИС	pass
Сохранение сборки в хранилище	1. Определить путь сохранения в хранилище.  2. Нажать кнопку “Генерация”.	Файлы сгенерированы и сохранены по указанному пути	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Сохранение сборки на локальную машину	1. Определить путь сохранения на локальную машину.  2. Нажать кнопку “Генерация”.	Файлы сгенерированы и сохранены по указанному пути	pass
Создание новой ветки сборок	1. Определить путь сохранения в хранилище.  2. Нажать кнопку “Генерация”.	Указанная ветка создана. Файлы сохранены.	pass

Негативное тестирование (см. табл. 6) проводится для проверки работоспособности системы при вводе некорректных данных.

Таблица 6 - Тест-кейс для негативного тестирования АИС программирования логики промышленных роботов

Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Назначение: Выполнение функций общей формы
Увеличения количества slave до 10	-	Значение элемента Spinner 8	pass
Уменьшение количества slave до -1	-	Значение элемента Spinner 0	pass
Назначение: Выполнение функций вкладки “Входные сигналы”
Запись повторяющихся имён	-	Сообщение об ошибке	fail
Назначение: Выполнение функций вкладки “Выходные сигналы”
Запись повторяющихся имён	-	Сообщение об ошибке	fail
Сценарий	Действия	Ожидаемый результат	Полученный результат (pass, fail)
Назначение: Выполнение функций вкладки “Шаги”
Написание дробного числа в поле “Номер”	Записать в поле “Номер” дробное число	Невозможно поставить знак препинания	fail
Написание строки в поле “Номер”	Записать в поле “Номер” строку	Символы не подрисовываются	pass
Повторение номера шага	Записать в поле “Номер” один номер для разных шагов	Сообщение об ошибке	fail
Написание номеров шагов не по возрастанию	Написать номера шагов в порядке убывания	Сообщение об ошибке	fail
Написание одинаковых расшифровок шагов	Написать одинаковый комментарий для разных шагов	Комментарий принят (записан)	pass
Назначение: Выполнение функций вкладки “Условия шагов”
Запись объектов при вводе дробного числа в ячейки условий шагов	Записать дробное число в ячейку ожидаемого значения	Блокировка набора символов отличных от 0 и 1	pass
Запись объектов при вводе текста в ячейки условий шагов	Записать текст в ячейку ожидаемого значения	Блокировка набора символов отличных от 0 и 1	pass
Назначение: Выполнение функций вкладки “Сообщения”
Статус сообщения не выбран	Записать текст сообщения. Статус оставить пустым	Запись статуса по умолчанию	pass
Статус сообщения выбран, текст сообщения не написан	Выбрать статус, текстовое поле сообщение оставить пустым	Запись статуса и сообщения по умолчанию	pass
Поля сообщения не заполнены	-	Запись статуса и сообщения по умолчанию	pass
Сообщения повторяются	Написать одинаковые сообщения	Записать сообщения	pass
Сценарий	Действия	Ожидаемый результат	Полученный результат
Назначение: Выполнение функций вкладки “Сигналы шагов”
Уменьшить время сигнала до -1	Уменьшить значение элемента Spinner до значения -1	Значение элемента Spinner 0	pass
Запись объектов при вводе дробного числа в ячейки сигналов шагов	Записать дробное число в ячейку	Блокировка набора знаков препинания	pass
Запись объектов при вводе другой строки (не Р1 и Р2) в ячейки условий шагов	Записать строку в ячейку	Блокировка набора строк отличных Р1,Р2	fail

При проведении тестирования выявлены ошибки работы системы. Они сведены в таблицу 7.

Таблица 7 - BugReport тестирования автоматизированной системы

№ бага	Краткое описание	Действие	Полученный результат	Ожидаемый результат	Приоритет бага
1	Запись повторяющихся имён на вкладке “Входа”	-	Ошибка системы	Сообщение об ошибке	нормальный
2	Запись повторяющихся имён на вкладке “Выхода”	-	Ошибка системы	Сообщение об ошибке	нормальный
3	Написание дробного числа в поле “Номер”	-	Ошибка системы	Невозможно поставить знак препинания	нормальный
4	Повторение номера шага	-	Ошибка системы	Сообщение об ошибке	низкий
5	Написание номеров шагов не по возрастанию	-	Ошибка системы	Сообщение об ошибке	низкий
6	Запись объектов при вводе другой строки (не Р1 и Р2) в ячейки условий шагов	-	Ошибка системы	Блокировка набора строк отличных Р1,Р2	высокий

При тестировании АИС программирования промышленных роботов выявлены шесть ошибок, которые необходимо отладить.

Тестирование совместимости

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

1)   совместима со всеми целевыми ОС -Windows XP SP2 и старше;

2)      корректно работает как на x86, так и на x64;

)        может быть выполнена различными версиями интерпретатора языка программирования (при использовании разных версий Java-машины).

Тестирование будет проводиться для следующих операционных систем:

¾  Windows XP SP2 x86;

¾      Windows XP SP3 x86;

¾      Windows XP SP3 x64;

¾      Windows 7 x64.

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

Таблица 8 - Тест-кейс для тестирования совместимости АИС программирования логики промышленных роботов

Операционная система	Версия JDK	Работоспособность системы
Windows XP SP2 x86	5.11	Отличная
	6.22	Отличная
	7.0	Отличная
Windows XP SP3 x86	5.11	Отличная
	6.22	Отличная
	7.0	Отличная
Windows XP SP3 x64	5.11	Отличная
	6.22	Отличная
	7.0	Отличная
Операционная система	Версия JDK	Работоспособность системы
Windows 7 x64	5.11	Отличная
	6.22	Отличная
	7.0	Отличная

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

В данном подразделе было проведено функциональное тестирование и тестирование совместимости. При негативном функциональном тестировании выявлено шесть ошибок. При тестировании совместимости была проверена корректная функциональность системы на платформах Windows XP SP2 x86, Windows XP SP3 x86, Windows XP SP3 x64, Windows 7 x64 и при различных версиях JDK. Проблем совместимости с перечисленным программным обеспечением АИС программирования промышленных роботов не имеет.

2.5 Схема реализации

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

Автоматизированная система программирования логики промышленных роботов состоит из трёх модулей (см. рис. 31):

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

¾  модуль логики программы (параметры программы) - компонент, реализующий функциональность АИС;

¾      модуль подключения к Subversion - компонент, служащий для подключения к системе управления версиями и импорта/экспорта сборок программ.

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

Для исполнения АИС подключены следующие библиотеки:

-   swing.jar - набор легковесных компонентов для создания графических интерфейсов пользователя.

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

-       awt.jar - классы для реализации графического пользовательского интерфейса

-       util.jar - вспомогательные классы, обеспечивающие работу со структурами данных и форматирование текста с учетом локализации;

-       org.tmatesoft.svn - классы, обеспечивающие работу с хранилищем системы управления версиями Subversion.

Взаимодействие между компонентами программы отображено на рисунке 31.

В данной части дипломного проекта определено, что разработка автоматизированной информационной системы программирования логики промышленных роботов для ООО “ВМЗ” будет производиться на объектно-ориентированном языке программирования Java. Система будет разрабатываться в среде NetBeans. Для демонстрации пользовательского интерфейса описаны основные его виды: : вкладка “Входные сигналы”, вкладка “Шаги”, вкладка “Условия шагов”, вкладка “Сигналы шагов”, вкладка “Системные переменные”. При разработки алгоритмов выделены и описаны алгоритмы функции записи списка входных сигналов (“SetListIn”), функции удаления пустых объектов из списка (“DelNullObject”), функции чтения списка не добавленных в условия входных сигналов (“GetListNotAddIn”), функции сортировки списков в пользовательской последовательности (“SortListInOut”) и функции генерации конфигурационного файла (“GenConfig”). На этапе тестирования выявлено шесть ошибок функционирования системы. Схема реализации отображена в виде диаграммы развертывания.

3. Экономическая часть

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

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

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

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

В данном разделе произведены следующие расчёты:

1.   Расчёт времени на разработку АИС программирования логики промышленных роботов для ООО “ВМЗ”.

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

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

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

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

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

.        Социальный эффект от внедрения АИС программирования логики промышленных роботов.

3.1 Расчёт времени на разработку АИС программирования логики промышленных роботов

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

Для расчёта времени на разработку системы выделены этапы разработки, они представлены в таблице 6.

Таблица 9 - Этапы разработки АИС программирования логики промышленных роботов

Наименование этапа	Продолжительность, часы	Используемое оборудование на этапе
Анализ предметной области	120	Ноутбук ASUS N53S
Формализация существующих бизнес-процессов и поиск проблем	40	Ноутбук ASUS N53S
Постановка задачи	32	Ноутбук ASUS N53S
Проектирование модели системы	80	Ноутбук ASUS N53S
Разработка функциональной части системы	120	Ноутбук ASUS N53S
Наименование этапа	Продолжительность, часы	Используемое оборудование на этапе
Разработка интерфейса пользователя	48	Ноутбук ASUS N53S
Тестирование и отладка программного продукта	40	Ноутбук ASUS N53S
	480

На рисунке 32 приведён график разработки.

Рисунок 32 - График разработки АИС программирования логики промышленных роботов

Общее время разработки автоматизированной системы составляет 480 часов. В одном месяце 20 рабочих дней, это составляет 20д*8ч=160часов. Таким образом, время разработки АИС программирования промышленных роботов составляет 480/160=3месяца. На всех этапах разработки используется ноутбук ASUS N53S.

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

Покупные изделия

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

                              (3.1)

где  - количество покупных изделий (полуфабрикатов) с-го вида на исследование, шт.;

 - оптовая цена покупных изделий с-го вида, руб/шт (по данным ООО “КанцМаркет” на март 2012 года).

Затраты на покупные изделия и полуфабрикаты отображены в таблице 10.

Таблица 10 - Затраты на покупные изделия и полуфабрикаты при разработке АИС программирования логики промышленных роботов

Наименование изделий (полуфабрикатов)	Кол-во шт.	Цена за 1 шт. руб./шт.	Сумма, руб.	Примечание
Бумага	100	0,22	22	по данным ООО “КанцМаркет” на март 2012г
Шариковая ручка	2	8	16
Карандаш	2	16	32
Стержни	1	12	12
Итого:			82

Затраты на электроэнергию

Затраты на энергию  учитывают все виды энергии (воздух, электроэнергию, газ, кислород, топливо и т. д.), если их расход связан с выполнением разработки. Затраты на энергию производятся по формуле:

                                               (3.2)

где  - норма расхода энергии в единицу времени, кВт/ч;

 - основное время, в течение которого расходуется энергия при разработке системы, ч;

 - стоимость энергии по прейскурантам оптовых цен, руб.

Таблица 11 - Затраты на энергию при разработке АИС программирования логики промышленных роботов

Потребитель энергии	Единица измерения	Норма расхода энергии, кВт/ч	Цена за кВт, руб.	Стоимость энергии, руб./ч.	Время расхода энергии, ч.	Сумма затрат, руб.
Ноутбук ASUS N53S	кВт	0,075	2,38	0,18	480	86
Освещение	кВт	0,48	2,38	1,14	480	548
Итого:						634

Основная заработная плата

Для научных сотрудников, инженеров, лаборантов основная заработная плата рассчитывается дифференцированно, исходя из установленного должностного оклада и количества времени, необходимого для разработки системы. Время для разработки системы рассчитано в подразделе 3.1, оно составляет 3 месяца. Месячный оклад инженера-программиста 13200руб. Следовательно, отчисление на основную заработную плату можно рассчитать по формуле:

,                                                                   (3.3)

где О - месячный оклад, руб.;

nм - время разработки АИС, мес.

                                         

Дополнительная заработная плата

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

,                                                  (3.4)

где  - норматив отчислений на дополнительную заработную плату, % (14% по данным ООТиЗ ООО “ВМЗ”);

Зо - основная заработная плата, руб./ч.

Дополнительная заработная плата за время разработки АИС программирования логики промышленных роботов составляет:

программирование логика промышленный робот

Отчисление на социальное страхование

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

                                        (3.5)

где  - норма отчислений на социальное страхование, % (34,1% по данным ООТиЗ ООО “ВМЗ”).

Отчисления на социальное страхование за время разработки АИС программирования логики промышленных роботов составляет:

Амортизация оборудования

Амортизационные отчисления на оборудование рассчитывается по формуле (на 1 час):

,                                                 (3.6)

где  - первоначальная стоимость оборудования, руб./ед.(первоначальная цена ноутбука ASUS N53S 26000 руб.) ;

 - годовая норма амортизационных отчислений, % (20 % по данным ООТиЗ ООО “ВМЗ”).;

nм - время разработки АИС, мес.

Затраты на амортизационные отчисления на оборудование при разработке АИС программирования логики промышленных роботов:

Отчисления на содержание и эксплуатацию оборудования при разработке АИС программирования логики промышленных роботов

Отчисления на содержание и эксплуатацию оборудования рассчитываются по формуле:

                                                                   (3.7)

где KП - первоначальная стоимость оборудования, р.;

Нтр - норма отчислений на текущий ремонт, %;

nм - время разработки АИС, мес.

Норма отчислений на текущий ремонт 20% (по данным ООТиЗ ООО “ВМЗ”).

Затраты на содержание и эксплуатацию оборудования при разработке АИС программирования логики промышленных роботов:

Амортизация рабочего места

Амортизация рабочего места рассчитывается по формуле:

                                                                 (3.8)

где S - площадь, занимаемая рабочим местом, м2 (4 м2 );

Цм2 - цена единицы площади зданий, руб./м2 ;

НS - норматив амортизации здания, % (1% по данным ООТиЗ ООО “ВМЗ”);

nм - время разработки АИС, мес.

Затраты на амортизацию рабочего места при разработке АИС программирования логики промышленных роботов:

Накладные расходы

К накладным расходам относятся заработная плата (с начислениями) административного хозяйственного персонала; расходы по охране труда и технике безопасности; расходы на транспорт; затраты на ремонт, отопление, освещение и уборку производственной площади.

Накладные расходы рассчитываются по формуле:

                                                          (3.9)

где Ннр - норматив накладных расходов, %;

 - основная заработная плата за час, руб./час.

Норматив накладных расходов на ООО “ВМЗ” составляет 60 % (по данным ООТиЗ ООО “ВМЗ”).

                                                

Затраты на разработку АИС программирования логики промышленных роботов определяются как сумма всех вышеперечисленных затрат. Результаты расчетов по всем статьям затрат сводятся в таблицу 12.

Таблица 12 - Затраты на разработку АИС программирования логики промышленных роботов

Наименование статей затрат	Сумма, руб.
Покупные изделия	82
Затраты на электроэнергию	634
Основная заработная плата	39600
Дополнительная заработная плата	5544
Отчисление на социальное страхование	14880
Амортизационные отчисления	1258
Отчисления на содержание и эксплуатацию оборудования	1258
Амортизация рабочего места	240
Накладные расходы	23040
ИТОГО:	85168

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

3.3 Расчёт трудоёмкости процесса программирования логики промышленных роботов при выполнении одного проекта

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

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

Этапы выполнения	Ручное программирование		Автоматизированное программирование
	Время, час.	Оборудование	Время, час.	Оборудование
Первоначальное написание программы	18	Ноутбук ASUS N53S	2	Ноутбук ASUS N53S
Создание программных файлов	4	Ноутбук ASUS N53S	0	Ноутбук ASUS N53S
Внедрение и отладка программы	10	-	4	-
Анализ и изменение программы	16	-	1,5	Ноутбук ASUS N53S
Модификация программных файлов	4	-	0	Ноутбук ASUS N53S
Итого:	52		7,5

Трудоёмкость программирования логики промышленных роботов при базовом варианте составляет 52 часа, при проектном варианте 7,5 часов. Один проект выполняет один программист в обоих вариантах процесса программирования.

3.4 Расчет общих капитальных вложений на автоматизацию процесса программирования логики промышленных роботов для ООО “ВМЗ”

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

                                                             (3.10)

- элементы капитальных вложений на автоматизацию

Капитальные вложения на оборудование

Капитальные вложения на оборудование рассчитываются по формуле

                                                         (3.11)

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

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

- коэффициент использования оборудования.

Коэффициент использования оборудования рассчитывается по формуле (3.12).

                                                     (3.12)

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

- годовая программа программирования логики промышленных роботов (20 проектов в год), шт.;

 - годовой действительный фонд времени работы оборудования (1989 ч. По данным ООТиЗ ООО “ВМЗ” на 2012г), ч.

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

При этом Ноутбук ASUS N53S работает только 22 часа.

Для проектного варианта трудоемкость процесса программирования логики промышленных роботов составляет 7,5ч.

Ноутбук ASUS N53S работает тоже 7,5 ч.

Капитальные вложения на оборудование при программировании логики промышленных роботов сведены в таблицу 14. Первоначальная стоимость оборудования 26000руб.

Таблица 14 - Капитальные вложения на оборудование при программировании логики промышленных роботов сведены

Наименование оборудования	Цена, руб.	Ручное программирование			Автоматизированное программирование
		Коэффициент использования	Количество, шт.	Значение, руб.	Коэффициент использования	Количество, шт.	Значение, руб.
Ноутбук ASUS N53S	26000	0,22	1	5720	0,075	1	1950
Рабочий стол	1000	0,522	1	522	0,075	1	75
Стул	650	0,522	1	340	0,075	1	50
ИТОГО:				6582			2075

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

Капитальные вложения на программное обеспечение для установки и работы АИС публикации и обработки данных о детях рассчитаем по формуле:

                                                        (3.13)

- затраты на приобретение/разработку программного продукта, руб.;

- затраты на внедрение программного продукта, руб.;

- затраты на обучение персонала работе с программным продуктом, руб.

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

Таблица 15 - Трудоёмкость внедрения АИС программирования логики промышленных роботов

Наименование этапа	Время, час	Используемое оборудование на этапе
Подготовка аппаратного обеспечения	2,5	ЭВМ AMD 64 3200
Установка системы управления версиями Subversion	8	ЭВМ AMD 64 3200 Ноутбук ASUS N53S
Настройка системы управления версиями Subversion	16	ЭВМ AMD 64 3200 Ноутбук ASUS N53S
Установка разработанной системы программирования промышленных роботов на ПК программистов	0,5	Ноутбук ASUS N53S
Подключение системы программирования промышленных роботов к системе управления версиями Subversion	1	Ноутбук ASUS N53S
ИТОГО:	28

Общее время на внедрение системы составляет 28 часов. В одном месяце 160 часов, следовательно, время внедрения АИС составляет 0,175месяцев.

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

Таблица 16 - Результаты расчётов времени использования оборудования при внедрении АИС программирования логики промышленных роботов

Этап внедрения	Время работы потребителя AMD 64 3200, ч.	Время работы потребителя ASUS N53S, ч.
Подготовка аппаратного обеспечения	2,5	-
Установка системы управления версиями Subversion	8	8
Настройка системы управления версиями Subversion	16	16
Установка разработанной системы на ПК программистов	-	0,5
Подключение разработанной системы к системе управления версиями Subversion	-	1
Итого:	26,5	25,5

Расчёт энергии производится по формуле (3.2). Результаты расчётов представлены в таблице 17.

Таблица 17 - Затраты на электроэнергию при внедрении разработки АИС программирования логики промышленных роботов

Потребитель энергии	Единица измерения	Норма расхода энергии, кВт/ч	Цена за кВт, руб.	Время расхода энергии, ч.	Сумма затрат, руб.
Компьютер AMD 64 3200	кВт	0,25	2,38	0,595	26,5	15,8
Ноутбук ASUS N53S	кВт	0,075	2,38	0,18	25,5	4,6
Освещение	кВт	0,48	2,38	1,14	480	548
Итого:						568,4

Расчёт основной заработной платы производится по формуле (3.3). Время внедрения АИС составляет 0,175месяцев.

Расчёт дополнительной заработной платы производится по формуле (3.4).

Отчисления на социальное страхование рассчитывается по формуле (3.5).

Расчёт амортизационных отчислений на оборудование производится по формуле (3.6). Результаты расчётов представлены в таблице 18.

Таблица 18 - Затраты на амортизацию оборудования при внедрении АИС программирования логики промышленных роботов

Наименование оборудования	Первоначальная цена ед. оборудования, руб.	Годовая норма амортизационных отчислений, %	Фонд времени работы оборудования, ч.	Амортизационные отчисления, руб.
Компьютер AMD 64 3200	10000	20	26,5	26,5
Ноутбук ASUS N53S	26000	20	25,5	66,81
ИТОГО:				93,31

Расчёт амортизационных отчислений на ремонт оборудования производится по формуле (3.7). Результаты расчётов представлены в таблице 19.

Таблица 19 - Затраты на текущий ремонт оборудования при внедрении АИС программирования логики промышленных роботов

Наименование оборудования	Первоначальная цена ед. оборудования, руб.	Годовая норма отчислений на тек. ремонт, %	Фонд времени работы оборудования, ч.	Амортизационные отчисления, руб.
Компьютер AMD 64 3200	10000	20	26,5	26,5
Ноутбук ASUS N53S	26000	20	25,5	66,81
Итог:				93,31

Затраты на внедрение АИС программирования логики промышленных роботов определяются как сумма всех вышеперечисленных затрат. Результаты расчетов по всем статьям затрат сводятся в таблицу 20.

Таблица 20 - Затраты на внедрение АИС программирования логики промышленных роботов

Наименование статей затрат	Время, ч.	Сумма, руб.	Примечание
Затраты на электроэнергию	-	568,4	см табл. 17
Основная заработная плата	28	2240
Дополнительная заработная плата	28	313,6
Отчисление на социальное страхование	28	868
Амортизационные отчисления	-	93,31	см табл. 18
Отчисления на содержание и эксплуатацию оборудования	-	93,31	см табл. 19
Амортизация рабочего места	28	14
Накладные расходы	28	1344
Итого:		5535

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

Обучение программистов работе в созданном программном продукте составляет 1 час. Необходимо обучить 6 программистов. Обучающий и обучаемые программисты имеют одинаковый оклад, следовательно, можно считать, что на обучение будет потрачено 7 часов (0,044мес.) рабочего времени инженера-программиста. Также в капитальные вложения на обучение входят затраты на оплату обучающего программиста. Все эти программисты имеют одинаковый оклад, следовательно, на каждого из них завод затрачивает одинаковую сумму. То есть затраты на обучение в течение одного часа семи программистов соответствует затратам производства на семь часов работы инженера-программиста. При обучении задействованы ПК всех программистов и сервер. Это учитывается в расчётах затрат на электроэнергию, амортизацию оборудования и отчислений на текущий ремонт оборудования.

Расчёт энергии производится по формуле (3.2). Результаты расчётов представлены в таблице 21.

Таблица 21 - Затраты на электроэнергию при обучении пользователей работе на АИС программирования логики промышленных роботов

Потребитель энергии	Единица измерения	Норма расхода энергии, кВт/ч	Цена за кВт, руб.	Стоимость энергии, руб./ч.	Время расхода энергии, ч.	Сумма затрат, руб.
Компьютер AMD 64 3200	кВт	0,25	2,38	0,595	1	0,595
Ноутбук ASUS N53S	кВт	0,075	2,38	0,18	7	1,26
Освещение	кВт	0,48	2,38	1,14	7	7,98
Итого:						10

Расчёт основной заработной платы производится по формуле (3.3). Время внедрения АИС составляет 0,044месяцев.

Расчёт дополнительной заработной платы производится по формуле (3.4).

Отчисления на социальное страхование рассчитывается по формуле (3.5).

Расчёт амортизационных отчислений на оборудование производится по формуле (3.6). Результаты расчётов представлены в таблице 22.

Таблица 22 - Затраты на амортизацию оборудования при обучении пользователей работе на АИС программирования логики промышленных роботов

Наименование оборудования	Первоначальная цена ед. оборудования, руб.	Годовая норма амортизационных отчислений, %	Фонд времени работы оборудования, ч.	Амортизационные отчисления, руб.
ЭВМ AMD 64 3200	10000	20	1	1
Ноутбук ASUS N53S	26000	20	7	18,34
Итог:				19,34

Расчёт амортизационных отчислений на ремонт оборудования производится по формуле (3.7). Результаты расчётов представлены в таблице 23.

Таблица 23 - Затраты на текущий ремонт оборудования при обучении пользователей работе на АИС программирования логики промышленных роботов

Наименование оборудования	Первоначальная цена ед. оборудования, руб.	Годовая норма отчислений на тек. ремонт, %	Часовые амортизационные отчисления, руб./ч.	Фонд времени работы оборудования, ч.	Амортизационные отчисления, руб.
Компьютер AMD 64 3200	10000	20	1	1	1
Ноутбук ASUS N53S	26000	20	2,62	7	18,34
Итог:					19,34

Амортизация рабочего места рассчитывается по формуле (3.8). Время внедрения АИС составляет 0,044месяцев.

Накладные расходы рассчитываются по формуле (3.9).

Затраты на обучение пользователей работе на АИС программирования логики промышленных роботов определяются как сумма всех вышеперечисленных затрат. Результаты расчетов по всем статьям затрат сводятся в таблицу 24.

Таблица 24 - Затраты на внедрение АИС программирования логики промышленных роботов

Наименование статей затрат	Время, ч.	Сумма, руб.	Примечание
Затраты на электроэнергию	-	10	см табл. 21
Основная заработная плата	7	560
Дополнительная заработная плата	7	78,4
Отчисление на социальное страхование	7	217
Амортизационные отчисления	-	19,34	см табл. 22
Отчисления на содержание и эксплуатацию оборудования	-	19,34	см табл. 23
Амортизация рабочего места	7	3,5
Накладные расходы	7	336
Итого:		1244

Затраты на обучение программистов при внедрении разработанной системы составляют 1244 руб. Капитальные вложения на программное обеспечение для работы АИС программирования логики промышленных роботов сведены в таблицу 25.

Таблица 25 - Капитальные вложения на программное обеспечение для работы АИС программирования логики промышленных роботов

Наименование показателя	Значение, руб.
	Ручное программирование	Автоматизированное программирование
Затраты на приобретение и разработку программного продукта	0	85168
Затраты на внедрение программного продукта	0	5535
Затраты на обучение персонала работе с программным продуктом	0	1244
Итог:	0	91947

Капитальные вложения на площадь рассчитываются по формуле (3.14).

,                                            (3.14)

- площадь -ого рабочего места для работы на АИС программирования логики промышленных роботов (4 м2), м2;

- количество рабочих мест для работы на АИС программирования логики промышленных роботов, шт.;

- цена площади помещения (25000 руб./м2), руб./м2;

- коэффициент использования площади -м оборудованием для работы АИС программирования логики промышленных роботов.

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

Общие капитальные вложения рассчитываются по формуле (3.10). результаты расчета отображены в таблице 26.

Таблица 26 - Общие капитальные вложения на АИС программирования логики промышленных роботов

Статья затрат	Ручное программирование	Автоматизированное программирование
Капитальные вложения на оборудование, руб.	6582	2075
Капитальные вложения на программное обеспечение, руб.	0	91947
Капитальные вложения на площадь, руб.	55200	7500
Итого:	61782	101522

Общие капитальные вложения на АИС программирования логики промышленных роботов составляют 101522 руб.

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

Ручной и автоматизированный процессы программирования роботов преимущественно отличаются количеством времени, которое затрачивается на выполнение этапов программирования. Трудоёмкость программирования логики промышленных роботов при базовом варианте процесса составляет 52 часа (0,325мес), при проектном варианте процесса 7,5 часов (0,047мес).

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

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

Таблица 27 - Затраты на покупные изделия и полуфабрикаты при программировании логики промышленных роботов

Наименование изделий (полуфабрикатов)	Ручное программирование			Автоматизир. программ-е
	Количество, шт.	Цена за ед., руб.	Сумма, руб.	Сумма, руб.
Бумага	25	0,22	5,5	0
Шариковая ручка	1	8	8	0
Итого:			13,5	0

Расчёт энергии производится по формуле (3.2). Результаты расчётов представлены в таблице 27.

Таблица 28 - Затраты на электроэнергию при программировании логики промышленных роботов

Потребитель энергии	Единица измерения	Норма расхода энергии, кВт/ч	Цена за кВт, руб.	Стоимость энергии, руб./ч.	Время расхода энергии, ч.	Сумма затрат, руб.
Ноутбук ASUS N53S	кВт	0,075	2,38	0,18	7	1,26
Освещение	кВт	0,48	2,38	1,14	7	7,98
Итого:						10

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

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

Наименование статей затрат	Формула	Ручное программирование		Автоматизированное программирование
		Время работы, мес.	Сумма, руб.	Время работы, час.	Сумма, руб.
Покупные изделия		-	13,5	-	0
Затраты на электроэнергию		52	9,36	7,5	1,35
Основная заработная плата	3.3	52	4160	7,5	600
Дополнительная заработная плата	3.4	52	582,4	7,5
Отчисление на социальное страхование	3.5	52	1612	7,5	232,5
Амортизационные отчисления	3.6	52	136,24	7,5	19,65
Отчисления на содержание и эксплуатацию оборудования	3.7	52	136,24	7,5	19,65
Амортизация рабочего места	3.8	52	26	7,5	3,75
Накладные расходы	3.9	52	2496	7,5	360
Итог:			9158		1321

Из таблицы видно, что себестоимость процесса программирования при ручном программировании составляет 9158 руб., а при автоматизированном - 1321 руб.

3.6 Расчет годового эффекта и прочих показателей экономической эффективности

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

Ожидаемый годовой экономический эффект

Годовой экономический эффект рассчитывается по формуле (3.15).

,                                                  (3.15)

где С' - затраты на программирование роботов вручную, руб.;

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

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

Таблица 30 - Данные для расчета годового экономического эффекта

Затраты на программирование роботов вручную С', руб.	Затраты на автоматизированное программирование роботов С", руб.	Количество проектов в год N, шт.	Норм. коэффициент экономической эффективности Е	Дополнительные капитальные вложения К, руб.	Годовой экономический эффект Эг, руб.
9158,24	1320,9	20	0,33	101522	126404,3

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

Условно годовой экономический эффект

Условно годовой экономический эффект рассчитывается по формуле (3.16).

,                                                    (3.16)

где С' - затраты на проведение операций вручную, руб.;

С" - затраты на проведение операций с использованием автоматизированной системы, руб.; - количество проектов в год.

                                      

Условно годовой экономический эффект разработки составляет 156746,8.

Срок окупаемости

Расчётный срок окупаемости определяется по формуле (3.17).

,                                                    (3.17)

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

ЭУГ - условно годовой экономический эффект.

Расчётный срок окупаемости данной разработки составляет 0,59 года, что составляет 7 месяцев.

Коэффициент экономической эффективности

Коэффициент экономической эффективности является обратной величиной для срока окупаемости. Он рассчитывается по формуле (3.18).

,                                                    (3.18)

Коэффициент экономической эффективности разработки составляет 1,7.

Снижение трудоёмкости

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

,                                                      (3.19)

где t’ - трудоёмкость базового процесса, ч.;

t” - трудоёмкость проектного процесса, ч.

                                                     

Снижение годовой трудоёмкости при автоматизированном создании программ для роботов составляет 85,6 %.

Рост производительности труда

Рост производительности труда рассчитывается по формуле (3.20).

,                                                   (3.20)

       

Рост производительности труда при внедрении автоматизированной системы программирования роботов составляет 593%.

3.7 Социальный эффект от внедрения

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

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

Социально-научный эффект проявляется в росте числа открытий, изобретений, в увеличении суммарного объема научно-технической информации, полученной в результате выполнения НИР.

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

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

Элементом количественной оценки социально-научного эффекта является определение коэффициента научно-технического эффекта НИР, который рассчитывается по формуле (3.21).

,                                             (3.21)

где   весовой коэффициент i-го признака научно-технического эффекта, определяется по табл. 31;

  количественная оценка i-го признака научно-технического эффекта НИР.

При оценке социального эффекта разработки используются следующие признаки научно-технического эффекта:

1.   Уровень новизны.

2.       Теоретический уровень.

.        Возможность реализации.

Разработку можно считать новой, уровень новизны новой разработки соответствует коэффициенту 0,6.

Разработку можно отнести к категории разработок “Разработка способа”. Теоретический уровень новой разработки соответствует коэффициенту 0,6.

Возможность реализации рассчитывается как сумма времени реализации и масштабов реализации. Разрабатываемая система должна быть разработана и внедрена в течение первых 10 лет. Такой критерий оценки времени соответствует 10 баллам, то есть коэффициент оценки времени составляет 1. Проект предполагается внедрять на одном предприятии. Такой масштаб разработки соответствует коэффициенту 0,2. Таким образом, возможность реализации имеет суммарный коэффициент 1,2.

Исходные данные для определения оценок признаков научно-технического эффекта приведены в Приложении В.

Таблица 31 - Количественная оценка признаков научно-технического эффекта

Признак научно-технического эффекта НИР (i)	Количественная оценка i-го признака научно-технического эффекта (k)
Уровень новизны	0,6
Теоретический уровень	0,6
Возможность реализации	1,2

Весовые коэффициенты признаков научно-технического эффекта отображены в таблице 32.

Таблица 32 - Значения весовых коэффициентов признаков

Признак научно-технического эффекта НИР (i)Значения весового коэффициента (r) признака
Уровень новизны	0,6
Теоретический уровень	0,4
Возможность реализации	0,2

Теперь можно рассчитать коэффициент научно-технического эффекта:

Социально-научный эффект разработки автоматизированной системы программирования промышленных роботов соответствует коэффициенту 0,84.

3.8 Выводы и предложения

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

От использования данной системы ожидается:

¾  годовой эффект 126404 руб.;

¾      условно годовой экономический эффект 156746,8 руб.;

¾      срок окупаемости 7 месяцев;

¾      коэффициент экономической эффективности 1,7;

¾      снижение годовой трудоёмкости на 85,6%.

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

4. Безопасность жизнедеятельности

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

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

Компетентность людей в мире опасностей и способах защиты от них - необходимое условие безопасности жизнедеятельности. Отсутствие естественных механизмов защиты от них требует приобретения человеком навыков обнаружения опасностей и применения средств защиты. Это достижимо только в результате обучения и приобретения опыта на всех этапах образования и практической деятельности человека. Поэтому все больше возрастает значение подготовки специалистов, способных не только обеспечить личную безопасность, но и выработать мероприятия по защите персонала объекта экономики, а также организации их выполнения в чрезвычайных ситуациях различного характера в качестве руководителя объекта. [32]

4.1 Анализ вредных производственных факторов

Опасные и вредные производственные факторы подразделяются по природе действия на следующие группы:

¾  физические;

¾      химические;

¾      биологические;

¾      психофизиологические.

На рассматриваемом участке могут присутствовать физические, химические и психофизические факторы.

Физические опасные и вредные производственные факторы:

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

¾      повышенная запыленность и загазованность воздуха рабочей зоны;

¾      повышенная или пониженная температура поверхностей оборудования, материалов;

¾      повышенная или пониженная температура воздуха рабочей зоны;

¾      повышенный уровень шума на рабочем месте;

¾      повышенный уровень статического электричества;

¾      повышенный уровень электромагнитных излучений;

¾      повышенная яркость света.

Психофизиологические опасные и вредные производственные факторы:

¾  умственное перенапряжение;

¾      перенапряжение анализаторов;

¾      эмоциональные перегрузки.

Нормируемые параметры шума на рабочих местах определены ГОСТ 12.1.003-83 и санитарными нормами СН 2.2.4/2.1.8.562-96 “Шум на рабочих местах, в помещениях жилых, общественных зданий и на территории жилой застройки”. Допустимый уровень звукового давления для помещений научно-производственных лабораторий составляет 60 дБА согласно ГОСТ 12.1.003-83.

Нормирование электромагнитных излучений проводится по ГОСТ 12.1.006-84 “Электромагнитные поля радиочастот. Общие требования безопасности” и Санитарным правилам и нормам СанПиН 2.2.4/2.1.8.055-96 “Действующие дозы ЭМИ с учетом энергетической нагрузки”. Интенсивность ЭМИ характеризуется плотностью потока энергии (ППЭ). Максимальное значение ППЭ не должно превышать 10 Вт/м2, а при локальном облучении кистей рук 50 Вт/м2. Защита осуществляется по ГОСТ Р 50377-92 “Защиты Человека от Электромагнитных Излучений”.

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

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

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

1.