Стандарты… А что же это такое?

Александр Лоза (Ведущий инженер отдела технической поддержки, ЗАО «Бюро САПР»)

Рамки и штампы в тестовой документации

Отсутствие стандартов

Организационная сторона вопроса

Какое же будет резюме?

Продолжение. Начало см. в «САПР и графика» № 9’2008.

Рамки и штампы в тестовой документации

Если раньше рамка была целесообразна и служила главным образом для задания границ текста, то теперь при разработке документации средствами текстового процессора (в 90% случаев это Microsoft Word) границы текста задаются без использования рамки. Рамка же служит только дополнительным декоративным элементом, она не ограничивает область текста! Зато ее применение приводит к ограничению использования возможностей программы, требует дополнительных неоправданных затрат как по формированию документа, так и по устранению возникающих некорректностей (например, типичной является ситуация, что рамка съехала или необходимо выровнять границу таблицы в соответствии с рамкой и т.п.).

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

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

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

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

Если быть более точным, в Excel имеются следующие способы формирования рамок:

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

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

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

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

Для того чтобы документ полностью соответствовал ГОСТу, нужно потратить некоторое время на его «дооформление». Только вот свободного времени у проектировщиков не бывает. А какой толк будет от такой работы? Практически никакого, то есть проектировщик выполняет работу только потому, что так «надо», а предприятие оплачивает пустую работу. Так не лучше ли эти силы направить на более полезные занятия: повышение квалификации, работу с документацией или более глубокое изучение программ?

Я не говорю, что документация должна быть оформлена как попало, отнюдь, но зачем выполнять лишнюю работу?

Теперь рассмотрим несколько ситуаций, когда стандарты отсутствуют.

Отсутствие стандартов

Оформление спецификаций

Если сравнить заказные спецификации, формируемые разными проектными организациями, то по оформлению они будут различаться, хотя каждое предприятие заявляет, что его проектная документация соответствует ГОСТу. Под оформлением подразумеваются не различные рамки, штампы и шрифты, а распределение информации по графам, заголовки разделов, порядок вывода разделов и т.п. Например, как записывать условный диаметр: «Ду» или « DN»? А в какой графе записывать марку краски — во второй или в третьей (рис. 1)?

Рис. 1

Где следует записывать материал — во второй графе или в третьей (рис. 2)?

Рис. 2

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

При настройке отчетов и формировании БД элементов немало проблем создает «нестандартизация» ГОСТов: где материал пишется через дефис, где через пробел, а где вообще не пишется — в плане автоматического формирования спецификаций ГОСТы фактически не формализованы, о чем хорошо написано в книге «САПР на базе AutoCAD — как это делается» С.Зуева и Н.Полищука (с. 991-1000).

Если сравнить заказные спецификации даже в пределах одного предприятия, но сформированные разными структурными подразделениями, то и они, скорее всего, будут различаться в плане оформления. В моей практике был такой случай: на одном предприятии отдел A ввел одну маркировку арматуры ( v1 — 30с41нж, v2 — другой тип и т.п.), а отдел B, который выполняет ту же самую работу, использовал другую. Это общий вопрос стандартизации работы в пределах одного предприятия.

Стандарты на выполнение документации в электронном виде

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

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

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

В качестве простейшего примера рассмотрим случай копирования текстовой информации (например, пояснительной записки, служебной записки, спецификации и пр.) из одного документа Word в другой. Часто бывает, что после копирования текст, который в исходном документе выглядел корректно, начинает разъезжаться, расстояние между строками «плывет» (рис. 3).

Рис. 3

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

При выполнении графической документации, например, в среде AutoCAD ситуация становится еще сложнее. Пусть у нас имеются два чертежа — А и Б — и необходимо скопировать часть информации из чертежа А в чертеж Б. Казалось бы, очень простая задачка, на решение которой должно уйти не более минуты. Но на практике зачастую оказывается, что не все так просто. Возникающие сложности особенно трудно понять сотрудникам, работающим только с бумажными документами (на бумаге чего проще — вырезаешь (или копируешь) и приклеиваешь на место). На самом деле на копирование информации влияют следующие факторы (рис. 4):

Рис. 4

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

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

Чтобы доказать, что это не только теория, приведу в качестве примера реальный случай. В моей практике была следующая ситуация. В один проектный институт приехали сотрудники субподрядной организации для сдачи разработанной ПСД. Количество сдаваемых графических листов составляло 500-1000 штук. Документацию выполняли несколько (10-15) проектировщиков. И у каждого был свой стандарт на задание толщины линии. У одного исполнителя желтый цвет означал тонкую линию, у второго — толстую, у третьего — штриховую и т.п. Исполнители работали быстро и хорошо, все было прекрасно до тех пор, пока из этих чертежей (в электронном виде) не сформировали пакет, подготовленный к отправке (грубо говоря, сложили их вместе). И тут выяснилось, что корректно распечатать такую документацию не представляется возможным, так как надо индивидуально настраивать параметры печати для каждого листа, причем слабо представляя, у какого пользователя какой цвет какую толщину линии определяет! В конце концов было принято решение распечатать всю документацию в тонких линиях.

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

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

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

• гарантировать идентичность, например, строительной подосновы во всех разделах выпускаемого проекта;
• облегчает процесс проверки документации на коллизии;
• позволяет смежникам своевременно отражать изменения;
• осуществить параллельное проектирование;
• организовать комплексное проектирование со сквозной передачей графической информации в рамках 2D-проектирования в среде AutoCAD без специальных программ.

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

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

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

Организационная сторона вопроса

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

Техническая сторона вопроса

Начиная с AutoCAD 2002 проверка на стандарты осуществляется методом сравнения с файлом стандартов AutoCAD. Данный способ позволяет легко настраивать требуемые проверки, но имеет существенный недостаток — ограниченные правила проверки. Этим способом невозможно проверить, например, наличие «мусора» за пределами форматной рамки чертежа, наличие самой форматной рамки чертежа (анализ на различные форматы), год выпуска документации и т.д. Для снятия такого ограничения требуется алгоритмический подход к проверке данных.

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

Поэтому компания «Бюро САПР» разработала систему по проверке документации на соответствие стандартам, позволяющую анализировать наличие требуемой рамки чертежа, штампа, колонтитула и т.п.

Какое же будет резюме?

При составлении внутреннего стандарта работы следует в первую очередь ориентироваться именно на первичные требования — на целесообразность и единообразие, пусть даже имеются отступления от ГОСТа (не следует слепо придерживаться требований ГОСТа). В противном случае получается, что, имея самолет, передвигаемся на нем, как на автомобиле.

Немалую роль в этом вопросе должна играть служба нормоконтроля (неважно, в каком структурном подразделении она находится, но связь с отделом САПР и проектировщиками должна быть непосредственная): там, где необходимо введение стандартов в электронном виде, они должны быть введены, а там, где они уже отжили свое, их следует исключить из стандартов предприятия. Стандарты нельзя единожды разработать и забыть о них. Они должны постоянно обновляться в соответствии с текущими условиями.

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

Уже давно стоит вопрос о росте производительности труда — она практически не повышается. Но если тратить время на выполнение работы впустую, не использовать современное ПО только на том основании, что выходная документация не удовлетворяет ГОСТу, не стандартизировать и не организовывать работу в электронном виде, то производительность труда не вырастет еще очень долго.

САПР и графика 10`2008