Рисунок 2.27 – Система с тремя несвязанными подсистемами и
висящей связью
Теперь рассмотрим вариант (2, 6, 2).
Рисунок 2.28 – Система с двумя связанными подсистемами и
висящими связями
Улучшим значение третьего критерия. Получим вариант (2, 6, 1).
Рисунок 2.29 – Система с двумя связанными подсистемами и висящей
связью
Теперь рассмотрим вариант (2, 5, 2).
Рисунок 2.30 – Две связанные подсистемы с двумя висящими связями
Наконец, рассмотрим вариант (2, 5, 1) со средними значениями по всем критериям.
Рисунок 2.31 – Две связанные подсистемы с одной висящей связью
Таким образом, из восьми формально возможных вариантов реализации системы с не лучшими значениями по всем критериям, варианты (3, 6, 1), (2, 6, 1) и (2, 5, 1) обладают одним недостатком, варианты (3, 6, 2), (3, 5, 1), (2, 6, 2) и (2, 5, 2) – двумя недостатками, а вариант (3, 5, 2) – тремя.
2.5 Сравнение UFO-моделей
Проанализировав все 27 формально возможных вариантов реализации системы можно сказать, что для сравнения моделей системы недостаточно использовать только критерии «количество подсистем», «количество внутренних связей» и «количество висящих связей». Оказывается, что модель системы, формально худшая по совокупности значений по критериям, может иметь меньше недостатков и лучше функционировать, чем формально более лучшая система. Примером могут служить варианты (1, 5, 0) и (2, 5, 0) (табл. 2.1).
Таблица 2.1 – Характеристики моделей системы
Количество | |||
подсистем | внутренних связей | висящих связей | недостатков |
1 | 4 | 0 | 0 |
1 | 4 | 1 | 1 |
1 | 4 | 2 | 2 |
1 | 5 | 0 | 1 |
1 | 5 | 1 | 2 |
1 | 5 | 2 | 3 |
1 | 6 | 0 | 2 |
1 | 6 | 1 | 3 |
1 | 6 | 2 | 4 |
2 | 4 | 0 | 0 |
2 | 4 | 1 | 1 |
2 | 4 | 2 | 2 |
2 | 5 | 0 | 0 |
2 | 5 | 1 | 1 |
2 | 5 | 2 | 2 |
2 | 6 | 0 | 0 |
2 | 6 | 1 | 1 |
2 | 6 | 2 | 2 |
3 | 4 | 0 | 1 |
3 | 4 | 1 | 2 |
3 | 4 | 2 | 3 |
3 | 5 | 0 | 1 |
3 | 5 | 1 | 2 |
3 | 5 | 2 | 3 |
3 | 6 | 0 | 0 |
3 | 6 | 1 | 1 |
3 | 6 | 2 | 2 |
Количество недостатков модели системы определяется количеством висящих связей, наличием внутренних «петель» и подсистем, не имеющих входа или выхода.
Вероятно, самым существенным недостатком является наличие висящей связи, менее существенным – наличие подсистем, не имеющих входа или выхода, а наименее существенным – наличие внутренних «петель».
3. Классификация UFO-моделей в MicrosoftExcel
3.1 Описание UFO-моделей в MicrosoftExcel
Наилучшую модель (1, 4, 0) системы представим, как показано на рис. 3.1.
Рисунок 3.1 – Описание наилучшей модели системы
Для генерации количества висящих связей (рис. 3.2) используем формулу:
=ЕСЛИ(C2=2;0;C2+1)
Рисунок 3.2 – Описание третьего критерия
Для генерации внутренних связей (рис. 3.3) используем формулу [42]:
=ЕСЛИ(И(B2=6;C2=2);4;ЕСЛИ(И(C2=2;C3=0);B2+1;B2))
Рисунок 3.3 – Описание второго критерия
Для генерации количества подсистем (рис. 3.4) используем формулу:
=ЕСЛИ(И(A2=3;B2=6;B3=4);1;ЕСЛИ(И(B2=6;B3=4);A2+1;A2))
Рисунок 3.4 – Описание первого критерия
Затем введем для каждой модели количество недостатков и подсчитаем вес модели (рис. 3.5) по формуле:
=СУММ(A2:C2)+D2*4
Рисунок 3.5 – Описание недостатков и веса модели
К первому классу отнесем все модели, у которых нет недостатков (вес от 5 до 9). Ко второму – модели с 1 или 2 недостатками (вес от 10 до 14 и от 15 до 19). Оставшиеся модели (с 3 и 4 недостатками) отнесем к третьему классу (вес от 20 до 22 и 25).
Для вычисления номера класса (рис. 3.6) используем формулу:
=ЕСЛИ(И(E2>=5;E2<=9);1;ЕСЛИ(И(E2>=10;E2<=19);2;3))
Рисунок 3.6 – Описание класса модели
Для вычисления количества моделей в каждом классе (рис. 3.7) используем формулу:
=СЧЁТЕСЛИ($F$2:$F$28;H4)
Рисунок 3.7 – Описание количества моделей в классах
3.2 Анализ классов UFO-моделей
Данные о принадлежности моделей к классам были обработаны в системе SPSS 8.0 forWindows для статистической обработки результатов эксперимента (рис. 3.8).
Рисунок 3.8. – Представление данных в системе SPSS 8.0 forWindows
Анализ показал, что распределение моделей по классам удовлетворяет закону нормального распределения (рис. 3.9).
Рисунок 3.9 – Нормальное распределение моделей по классам
4. Использование порядковой классификациив процессе
UFO-моделирования систем телемеханики
Все результаты, представленные в этом разделе, получены в ходе преддипломной практики на фирме «Технокон» [43].
4.1 Общие сведения о фирме «Технокон»
Предприятие «Технокон» предлагает услуги по проектированию и поставке «под ключ» заказных систем и комплексов телемеханики для применения на объектах:
–теплофикации;
–водоснабжения, канализации и водоочистки;
–электроэнергетики;
–нефтяной и газовой промышленности;
–транспорта.
Проектируемые под заказ системы и комплексы телемеханики комплектуются всем необходимым для решения задач дистанционного контроля и управления оборудованием удаленных объектов, включая:
–программируемые логические контроллеры;
–модемы для обмена данными с системами оперативно-диспетчерского контроля и управления;
–заказное прикладное программное обеспечение;
–системы терморегулирования;
–силовая защитная и коммутационная аппаратура;
–аппаратура электропривода исполнительных механизмов;
–средства обеспечения искробезопасности, молниезащиты и пр.
В зависимости от особенностей конкретного применения, в качестве платформы (ядра) узла заказной системы телемеханики используются стандартные элементы промышленной автоматики, выпускаемые группой SchneiderElectric: программируемые логические контроллеры (ПЛК) серий Modicon TSX Quantum, Compact или Micro, и, при необходимости, сопрягаемые с ними устройства распределенного сбора и обработки сигналов объекта – Modicon TSX Momentum.
4.2 Стратегия работы с заказчиком
Современная скорость эволюционирования систем и средств автоматизации диктует необходимость применять технологии разработки, способные учитывать как изменения требований заказчика, так и возможностей аппаратуры и ПО. Иначе в результате выполнения работ по проекту заказчик может получить именно то, что он запрашивал, но это будет не то, что ему действительно необходимо.
Стратегия фирмы «Технокон» по работе с заказчиком основывается на вовлечение его в процесс разработки продукта и концепции «ориентированного на пользователя» программного обеспечения. Участие заказчика на всех этапах создания продукта гарантирует выпуск продукции высокого качества, удобной в эксплуатации и удовлетворяющей всем требованиям заказчика еще и потому, что сам пользователь проникается концепцией и восприятием конечного продукта. Вовлечение заказчика в процесс проектирования значительно повышает качество обучения персонала заказчика.
При необходимости взаимодействие с заказчиком реализуется с помощью различных методов прототипирования – традиционного макетирования (создание функционирующей системы, в значительной степени подобной проектируемой) и демонстрационного (создание опережающей реализации ограниченной версии системы в соответствии со структурой или этапностью процесса проектирования и разработки).
На этапе функционального проектирования полномасштабного программно-технического комплекса работающий прототип улучшает взаимодействие между исполнителем и заказчиком, проясняет функциональные требования к системе. Пользователь может также ознакомиться с особенностями ввода/вывода и его мнение может быть учтено при проектировании.
Тесное взаимодействие с заказчиком позволяет получить обратную связь от пользователя на ранних шагах проектирования и исключить дорогостоящие изменения проекта после этапа рабочего проектирования [44].
4.3 Порядковая классификация UFO-моделей системы
телемеханики
Пусть необходимо построить систему телемеханики, контекстная диаграмма которой показана на рис. 4.1.