Автоматизация экспертизы технической документации на соответствие техническим условиям и техническому заданию на проектирование

Тип работы:
Реферат
Предмет:
Общие и комплексные проблемы естественных и точных наук


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Электронный документооборот УДК 004. 428. 4+656. 25
Р. Т. Мустафаев
Автоматизация экспертизы технической документации на соответствие техническим условиям и техническому заданию на проектирование
Введение
В настоящее время технические условия (ТУ) и техническое задание (ТЗ) на проектирование объектов железнодорожной инфраструктуры выполняются полностью вручную в различных текстовых редакторах, как правило, на основе шаблонов. Проверка проекта на соответствие техническому заданию и техническим условиям полностью выполняется вручную. При этом высока роль человеческого фактора — от квалификации проверяющего эксперта зависит полнота и качество проверок.
1 Реализация решения задачи автоматизации работы с проектной документации
Для решения проблем автоматизации экспертизы технической документации (ТД) в НТЦ САПР ПГУПС (Научно-технический центр систем автоматизированного проектирования Петербургского государственного университета путей сообщения) разработан «Менеджер проекта». Данная программа содержит в себе два модуля: «Редактор Т У и ТЗ» и «Модуль соответствия проекта».
Первый модуль занимается формированием ТУ и ТЗ с использованием библиотек ответов пользователя. Сегодня процесс составления данных документов является редактированием файла в среде MS Word, и каждое новое ТУ или ТЗ отличается от предыдущего. Данный модуль сокращает время составления этих документов, а также их обработку.
Второй модуль проверяет соответствие технической документации данным, указанным в ТУ и ТЗ. Для правильного функционирования этого модуля были разработаны алгоритмы, реализованные при помощи языка DSL.
Первостепенной задачей стало создание среды для составления ТУ и ТЗ. Для реализации поставленной задачи был использован язык программирования F# (F Sharp), а также, расширяемый язык разметки XML.
Для создания оболочки «Менеджера проекта» используется язык F#, а для оперирования информацией (сохранение, открытие, конвертация, использование и т. д.) — язык XML.
66
Электронный документооборот
«Менеджер проекта», помимо его прочих функций, представляет собой программный продукт, позволяющий составлять из набора проектной документации целый проект. В перечень категорий добавляемой ТД входят:
¦ схематический план станции (СПС) —
¦ двухниточный план станции (ДПС) —
¦ кабельные сети (КС) —
¦ принципиальные схемы (ПС) —
¦ монтажные схемы (МС) —
¦ аппарат управления (АУ) —
¦ таблицы взаимозависимостей (ТВЗ) —
¦ спецификации-
¦ описи.
Пользователь имеет возможность сортировать все типы ТД и сохранять сформированный проект. Сам файл проекта — это XML документ, содержащий пути и названия всех составляющих его документов. Программа может как сохранить все файлы ТД в указанном месте, так и просто хранить пути к этим файлам. В дальнейшем пользователь открывает только файл проекта, программа сама загружает все связанные с ним файлы.
На рис. 1 показано окно программы «Менеджер проекта».
Рис. 1 «Менеджер проекта» 67
Электронный документооборот____________________________________________
2 Редактор Т У и ТЗ
Следующей важной задачей для разработки подобной системы была формализация ТУ и ТЗ. Формализация подразумевает под собой создание некой библиотеки, содержащей в себе перечень возможных ответов пользователя.
Для упрощения работы пользователя ему предоставляется шаблон ТУ или ТЗ, т. е. он вносит изменения прямо в документ. Такая концепция значительно упрощает способ составления этих документов и является интуитивно понятной. На рис. 2 приведено окно редактора ТУ и ТЗ, в котором открыт шаблон для составления ТЗ на электрическую централизацию (ЭЦ).
Рис. 2 Фрагмент окна «Редактора Т З и ТУ» 68
____________________________________________________Электронный документооборот
Библиотека, из которой производится выбор нужных параметров, может составляться самим пользователем и легко редактируется им же. Вид диалогового окна редактора библиотеки приведен на рис. 3.
Рис. 3 Окно редактора библиотеки
3 Разработка модуля для проверки технической документации на соответствие техническим условиям и техническому заданию
Аналитическую роль в данной задаче удалось решить при помощи языка DSL. Когда пользователь формирует, например ТЗ, после сохранения документа появляется возможность его обработки при помощи программных средств. Файлы Т З и ТУ создаются на языке XML и имеют расширения «. oftz» и «. oftu» соответственно. Для проверки на соответствие применяется алгоритм анализа исходных данных. Ими являются сам файл ТЗ/ТУ, а также какой-либо из указанных заранее (указывается в коде теста) документов из ТД.
Сам интерфейс модуля по проверке качества ТЗ/ТУ интегрирован в «Менеджер проекта» таким образом, что пользователь имеет возможность посмотреть, какие из документов проекта подвергаются проверке в данный момент. По окончании проверки пользователю предоставляется отчет о соответствии тем или иным пунктам, требований, указанных в ТЗ и ТУ.
Стоит заметить, что для обработки ТД необходимо ее составление в так называемом отраслевом формате технической документации (ОФТД СЦБ). Это вызвано тем, что остальные форматы представления ТД не содержат достаточное количество данных, необходимых для проведения автоматизированной экспертизы.
69
Электронный документооборот
Структура одного из тестов, в котором производится проверка вида тяги на станции, показана на рис. 4.
(¦ етпасв — DCsupply. fs
Fie ЕЛ Options Biffers Tools F/ Help
Heat & quot-Вид тяги. Постоянный ток& quot- starting & quot-21. 03. 2012"- whenSuccess [] vhenVrong []
check: & quot-1"- Targets. Two line on (haveElement
[{name = & quot-XmlMame"-- value = & quot-ДросселъТрансфорнатор"-- oftype = MatchType. eq}- {name = & quot-РодТока"-- value = & quot-постоянный"-- oftype = MatchType. eq}])
chech & quot-2"- Targets. Tvoline on (haveElement
[{name = & quot-XmlName"-- value = & quot-ДросселъТрансфорнатор"-- oftype = MatchType. eq}- {name = & quot-РодТока"-- value = & quot-0,2"-- oftype = MatchType. eq}])
chech & quot-3"- Targets. Tuoline on (haveElement
[{name = & quot-XmlName"-- value = & quot-ДросселъТрансфорнатор"-- oftype = MatchType. eq}- {name = & quot-РодТока"-- value = & quot-0,4"-- oftype = MatchType. eq}])
chech & quot-4"- Targets. Tvoline on (haveElement
[{name = & quot-XmlName"-- value = & quot-ДросселъТрансфорнатор"-- oftype = MatchType. eq}- {name = & quot-РодТока"-- value = & quot-0,6"-- oftype = MatchType. eq}])
Рис. 4 Структура теста
В любом из тестов может использоваться как большое количество условий, так и одно условие. В итоге внутри тестового кода составляется функция алгебры логики (ФАЛ) с логическим сложением и/или логическим умножением. После составления теста на то или иное условие он подвергается проверке в различных условиях для подтверждения его корректности.
Заключение
Работа, описанная в данной статье, сегодня перспективна и востребована. Тема экспертизы ТД проектов СЦБ только недавно начала разрабатываться в полном объеме. Автоматизация экспертизы ТД и, в частности, создание формализованного документа-требования (ТУ и ТЗ) актуальна как инструмент общения между заказчиком и исполнителем. Кроме того, сама по себе автоматизация экспертизы улучшает выходное качество проектов СЦБ, а также сокращает расходы при пусконаладочных работах.
При написании статьи использован следующий источник: Averill M. Law, W. David Kelton. Simulation modeling and analysis, Osborne. — 2004. — Pp. 249−284.
70
¦язи

ПоказатьСвернуть
Заполнить форму текущей работой