Проблемы автоматизации экспертизы проектной документации

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

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

Рис. 1. Процесс разработки проектной документации в плоском семантическом пространстве

Ведомственная экспертиза проводится специально аттестованной для этого организацией и является достаточно сложным бизнес-процессом. Пример описания такого бизнес-процесса в виде диаграммы потоков данных в нотации BPMN 2.0 ² приведен на рисунке 2.

Рис. 2 Диаграмма потоков данных бизнес-процесса экспертизы проектной организации, составленная на основании внутренних нормативных документов ПАО «Газпром»

Как видно из диаграммы, бизнес-процесс экспертизы проектной документации в основном сводится к следующему: подготовке документов для экспертизы, собственно проведению экспертизы и согласованию ее результата. Если рассматривать представленный бизнес-процесс в аспекте автоматизации, то можно обратить внимание, что подготовка и контроль документации перед экспертизой и ее согласование после являются типичными бизнес-процессами для документо-центричной системы класса PDM ³, возможно даже с усеченным функционалом. Программная система, поддерживающая подобный бизнес-процесс, будет в существенной степени эргатической ⁴. При этом ее ключевая часть (см. выноску на рисунок 2) осуществляется полностью пользователем и имеет во всем процессе наибольшую трудоемкость.

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

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

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

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

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

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

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

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

Обойти ловушку многозначности возможно. Для этого нужно трансформировать аморфные тексты проектов и норм в структуры, называемые семантическими сетями ⁷. Целевой моделью трансформации могут быть: сети Куиллиана ⁸, бинарные сети Абриаля ⁹ или, при предельном ослаблении типизации ¹⁰, инфологические модели данных (в понимании Д. Цикритзиса и Ф. Лоховски [1]).

Трансформация нормативных документов в любую из семантических структур должна производиться человеком-экспертом однократно путем «разметки» текста этого документа при помощи специального программного средства. При разметке эксперт указывает программе типы концептуальных элементов модели в тексте и устанавливает связи между ними. Альтернативой такому «реинжинирингу» семантической сети является формирование сначала собственно сети с последующей генерацией «человекочитаемого» текста нормативного документа на ее основе. Работы в этом направлении ведутся компанией «Нанософт разработка» (продукт NSR NormaCS Specification ¹¹).

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

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

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

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

Основные проблемы на пути построения системы поддержки принятия решений

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

1. Проблема извлечения знаний о методах экспертизы (для построения системы продукций).
2. Проблема выбора модели знаний и способов сравнения структур концептов этой модели в процессе экспертизы.
3. Проблема трансформации аморфных документов в семантические сети или подобные им структуры.

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

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

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

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

1. Под семантическим пространством здесь понимается метрическое пространство базовых показателей процесса, в данном случае двумерное, в которое он отображается с целью определения направления изменения этих показателей. Такое отображение показывает, что рост объема и номенклатуры проектных документов сопровождается ростом их качества как комплекта документации. ↑
2. BPMN 2.0 (BPMN — Business Process Management Notation) — это язык моделирования бизнес-процессов, который является промежуточным звеном между формализацией/визуализации и воплощением бизнес-процесса. ↑
3. PDM (Product Data Management — система управления данными об изделии) — программная система, обеспечивающая управление всей информацией об изделии. ↑
4. Эргатическая система — человеко-машинная (человеко-программная) система, одним из элементов которой является человек-пользователь, преобразующий (обрабатывающий) данные. ↑
5. Эвристика — здесь под этим подразумеваются рассуждения по определенному перечню правил в рамках выбранной парадигмы (образца, принципа вывода). ↑
6. Продукция — элемент модели знаний, построенный по парадигме «если…, то…, и действие…». ↑
7. Семантическая сеть — вид модели знаний, представляющий собой ориентированный граф. Вершины графа соответствуют объектам предметной области, а дуги (ребра) задают отношения между ними. Объектами могут быть понятия, события, свойства, процессы. ↑
8. Семантические сети Куиллиана — модель понимания смысла слов, получившая название ТLС-модели (Теасhable Lаnguage Соmprehender — доступный механизм понимания языка). ↑
9. Бинарная сеть — это графовая модель, в которой вершины являются представлениями простых однозначных атрибутов, а дуги — представлениями бинарных связей между атрибутами. ↑
10. Типизация модели данных — степень общности модели данных, показывающая соответствие концептов в предметной области концептуальным объектам в модели данных. ↑
11. https://www.nanocad.ru/products/nsr_specification/ ↑