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

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

Введение

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

1.1 Наиболее распространенные виды документации в отечественной и международной классификации

1.2 Способы сокращения затрат на разработку технической документации

1.3 Источники затрат при разработке документации

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

2.1 Требования к системам разработки документации

2.2 Принципы создания программно-технических комплексов электронных архивов технической документации

2.3 Разработка конструкторской документации с применением CАПР

Заключение

Список литературы

ВВЕДЕНИЕ

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

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

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

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

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

Цель работы - выявить необходимость использования САПР при разработке технической документации.

Для достижения цели необходимо решить следующие задачи:

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

- определить способы сокращения затрат на разработку технической документации,

- ознакомиться с источниками затрат при разработке документации,

- изучить требования к системам разработки документации,

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

- рассмотреть разработка конструкторской документации с применением САПР.

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ С ИСПОЛЬЗОВАНИЕМ САПР

1.1 Наиболее распространенные виды документации в отечественной и международной классификации

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

информационное обеспечение логистических процессов в цепочках поставок (разработчик - дистрибьютор - дилер - потребитель).

Цели:

1) сокращение времени обработки заявок на закупку (поставку) запасных частей;

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

3) информационное обеспечение процессов эксплуатации и ремонта техники в сервисных организациях и у потребителя.

Цели:

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

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

обучение специалистов с использованием элементов документации или отдельных ее видов.

Цели:

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

2) автоматизировать процедуру оценки персонала;

3) сократить затраты на обучение [10, c.97].

Исходя из вышеназванных задач, наиболее распространенными видами документации являются: КДС (аналог в S1000D - IPD), РЭ, РР (аналогами в S1000D являются информационные наборы, представленные в таблице), УП (аналог в S1000D - публикации, содержащие модули данных обучения и пакеты SCORM). В таблице представлено соответствие видов документов и информационных наборов, разрабатываемых с учетом требований отечественной нормативной базы и международной спецификации S1000D.

1.2 Способы сокращения затрат на разработку технической документации

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

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

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

Однако на всех этих стадиях автоматизации проектирования инженеру помимо изучения инструкций по эксплуатации и написанию программ приходится познавать ряд по сути дела ненужных ему подробностей системных программ и языков программирования. Кроме того, при использовании в проектировании специализированных по объектам разрозненных пакетов прикладных программ (ППП) инженер вынужден каждый раз вновь кодировать и вводить информацию согласно инструкции ППП. Отмеченные недостатки приводят к тому, что частичная («позадачная») автоматизация не оказала существенного влияния на повышение качества и производительности проектирования технических систем и средств в целом [12, c.67].

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

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

1.3 Источники затрат при разработке документации

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

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

Наибольший вес в структуре затрат на разработку документации составляет:

- разработка графической части;

- разработка текстовой части (для новых документов);

- формирование публикации.

В совокупности они составляю около 80-85 % издержек на создание технической документации.

Как бы это не казалось очевидным, но при формировании структур документов целесообразно следовать требованиям нормативной документации. В действующих отечественных и международных стандартах укрупненные структуры документов определены довольно однозначно. Однако множество вопросов возникает на этапе детализации общей структуры документа для конкретного изделия[13, c.90].

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

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

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

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

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

Для технических руководств необходимо предусмотреть создание модулей данных для всех элементов конструкции или функциональных систем, которые требуют воздействия на этапе эксплуатации и ремонта. Встает вопрос - где же можно взять перечень элементов, которые должны попасть в структуру руководства (DMRL)? Наиболее очевидны ответ - из БД АЛП, результатов АВПКО. Т.е. из тех источников, которые нам позволяют сформировать данные о вероятности выхода из строя элементов изделия, необходимости проведения планового обслуживания. Однако, достоверные данные из БД АЛП и результаты АВПКО, как правило, недоступны для новых изделий. Также их проблематично получить, если данные о стадиях жизненного цикла выпущенных изделий нигде не агрегируются. В этом случае можно использовать метод аналогий и результаты расчетов надежности тех или иных элементов конструкции [11, c.82].

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

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

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

Если говорить о еще более глубокой автоматизации создания структур документов, то это требует наличия базы АЛП или базы S2000M.

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

Далее полученную структуру мы можем импортировать в специализированное ПО для создания тех. документации.

Для большинства проектов по разработке документации, как правило, можно использовать обозначения SNS, приведенные в S1000D или Авиационном справочнике (AC 1.1.S1000DR-2007).

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

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

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

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

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

С другой стороны код DMC может быть частично определен в шаблоне документа. Например, для всех разделов, относящихся к хранению можно заранее задать код, определенный в S1000D[10, c.91].

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

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

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

использование ПО, которое позволяет упростить процесс повторного применения фрагментов текста (использование репозиториев информации);

применение упрощенного языка (Упрощенный технический русский (УТР-1), Simplified Technical English® (ASD-STE100)).

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

1) 3D модель - Специальное ПО - Иллюстрация;

2) чертежи - Специальное ПО - Иллюстрация;

3) фотографии - Графические редакторы - Иллюстрация;

4) чертежи, фотографии, внешний вид изделия - художник-конструктор - иллюстрация.

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

Принципиальный способ сокращения затрат при разработке графических объектов заключается в применении в качестве исходной информации 3D моделей, разработанных в САПР.

Это позволяет:

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

- во-вторых существенно сократить затраты на разработку и актуализацию графических объектов;

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

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

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

Например, для составных иллюстраций, включающих несколько моделей потребуется САПР и программы для создания иллюстраций (3DVia Composer, IsoDraw, Deep Exploration, Corel Technical Illustration и т.п.).

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

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

Подготовка 3D моделей для использования в технической документации включает следующие этапы:

- конвертирование 3D модели для загрузки в ПО, предназначенное для создания 3D интерактивного объекта;

- оптимизация модели специальным ПО (в качестве примера такого ПО может выступать продукт компании Parallel Graphics - Internet Model Optimizer);

- «настройка» модели (группировка элементов в соответствии с эксплуатационным составом изделия; разнесение, расстановка выносок, создание анимации, настройка интерактивности);

- экспорт 3D интерактивного объекта в формат, воспринимаемый системой разработки документации.

Для мультимедийных объектов экспорт осуществляется в видеоряд в соответствии с требованиями S1000D.

Выбор технологии разработки графических объектов предлагаю вам рассмотреть на примере расчета окупаемости создания графики для условного машиностроительного изделия, состоящего из 30 систем (конструкторских групп).

При расчете использованы показатели, определенные опытным путем, рассчитанные на основе нормативов и результатов хронометража.

Нормативным документом, который может быть использован при расчете трудоемкости разработки иллюстраций художником-конструктором, являются «Типовые нормы времени на разработку конструкторской документации (проектирование технологического оснащения) (утв. постановлением Госкомтруда СССР, секретариата ВЦСПС от 17.03.1986 n 93/6-6)».

Из расчета следует, что наибольшая трудоемкость соответствует разработке графических объектов художниками-конструкторами, а также в виде 3D моделей (см. таблицу ниже).

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

При расчете полных затрат принято следующее:

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

- переменные затраты учитывают только работы по обновлению графических объектов;

- в течение года изменения конструкции затрагивают все системы изделия.

Исходя из этого, определены начальные и совокупные издержки первого периода разработки графических объектов на изделие.

При расчете точки безубыточности в денежном выражении (BEP - break-even point) и срока окупаемости проекта (PBP - Pay-Back Period) использованы следующие исходные данные:

- количество активных клиентов - 500 ед.;

- стоимость годового абонентского обслуживания - 5 000 руб.;

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

На основе принятых допущений и исходных данных определено следующее:

- при использовании 3D моделей в качестве графических объектов документа срок окупаемости составляет менее 2-х лет при значении точки безубыточности равном 4,2 млн. руб.;

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

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

Несмотря на незначительную разницу срока окупаемости для 3D и 2D графических объектов, необходимо обратить внимание на совокупную прибыль, которая обозначена на графиках закрашенным треугольником с буквой P. Площади этих треугольников, а соответственно и значения прибыли, отличаются почти в 2 раза[11, c.92].

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

2. ПРИМЕНЕНИЕ СПЕЦИАЛИЗИРОВАННЫХ СИСТЕМ РАЗРАБОТКИ ДОКУМЕНТАЦИИ

2.1 Требования к системам разработки документации

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

Перед нами не стоит задача рекомендовать конкретное ПО для разработки документации. Целью является определение основных характеристики таких систем, на которые стоит обратить внимание при выборе.

На наш взгляд основными из подобных характеристик являются:

- как это не кажется очевидным, но все же - это поддержка стандартов;

- наличие графического интерфейса редактора модулей данных, обеспечивающий ввод и форматирование текста в соответствии с S1000D, вставку различных графических объектов (2D, 3D, мультимедиа);

- функция формирования и управления PM, DMRL;

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

- возможность вывода документа на печать. Причем полученный бумажный документ, так же должен отвечать действующим стандартам;

- наличие функций для управления доступом к объектам CSDB;

- ведение нескольких SNS, автоматизированное назначение кода;

- распределенная разработка документации в клиент-серверной среде;

- желательно наличие функций планирования работ и управления процессами разработки документации (workflow) [10, c.92].

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

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

Как бы то ни было, для большинства компаний разного калибра процесс разработки (сопровождения и т.д.) техдокументации остается занятием в немалой степени рутинным, трудоемким и ресурсоемким и, как правило, неблагодарным по отношению к непосредственным исполнителям[13, c.99].

Итак, целями автоматизации разработки являются:

- повышение управляемости жизненного цикла техдокументации;

- снижение трудоемкости и ресурсоемкости процессов жизненного цикла технической документации.

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

во избежание ответственности перед законом - на авиажаргоне такой подход называется «прикрытием задней полусферы»;

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

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

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

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

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

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

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

вынужденным осознанием факта, что техническая документация должна быть;

отсутствием интереса к процессу разработки (и т. д.) техдокументации.

С отношением и назначением покончено, теперь коротко о составе технической документации.

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

техническая документация на автоматизированные системы;

техническая документация на изделия;

техдокументация на программные изделия - программная документация.

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

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

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

- процесс разработки технической документации;

- процесс публикации техдокументации как на бумажных носителях, так и в электронном виде;

- процессы учета и хранения технической документации;

- процессы модификации, отслеживания изменений техдокументации - сопровождения;

- процесс обмена технической документацией между подразделениями компании;

- процесс передачи техдокументации заказчику (или конечному пользователю).

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

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

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

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

стили заголовков с многоуровневой нумерацией - особо продвинутыми пользователями (крайне редко);

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

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

Так ведь и претензии предъявить нельзя! У того же проджект-менеджера основная задача - не владение Вордом на уровне продвинутого пользователя, а получение подписи заказчика на Акте приемки-сдачи работ. Мотивация, пардон, отсутствует.

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

Об учете - попытки поставить классический учет бумажных документов терпит фиаско. Уследить за всеми участниками процесса разработки нереально. Время заказ-нарядов на машинописные работы давным-давно прошло. Быстро не «только кошки плодятся», но и документация. И также «промискуитетно».

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

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

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

Предпосылки применения САПР в автоматизации процессов жизненного цикла технической документации:

- доступность специализированных средств разработки текстовых документов, построенных на основе концепции единого источника (исходника) - single source;

- замечательные особенности советской нормативно-технической документации.

Специализированных средств разработки технической (да и любой документации) навалом. Производятся таковые как отечественными компаниями, так и буржуйскими. Средства известные, на слуху, подробно останавливаться и приводить сравнительный анализ особого смысла нет. Предпочтения автора сводятся к применению при разработке (сопровождении и т.д.) техдокументации программы AuthorIT от AuthorIT Software Corporation Ltd. [10, c.83]

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

Электронная техдокументация хранится в едином централизованном хранилище - в базе данных. AuthorIT позволяет применять в качестве базы данных как MS SQL, так и отдельные файлы библиотек. А вот MySQL, увы, пока не позволяет. Библиотеки структурно подразделяются на книги, книги на разделы и подразделы, пункты и подпункты (топики) - аж до девяти уровней вложенности. Собственно топики и являются атомарными модулями данных. Топики (модули данных), инкапсулируя в себе содержание разделов и подразделов книг, содержат также и служебную информацию - шаблоны разметки. Каждому модулю данных присваивается уникальный код (номер) согласно системы кодификации или название (силами пользователя).

2.2 Принципы создания программно-технических комплексов электронных архивов технической документации

система автоматизированный разработка документация

Оживление российской экономики и явно наметившийся рост в промышленности заставляют задуматься о том, что на производствах накопился огромный объем бумажных технических документов. На предприятиях-гигантах этот объем достигает 6 млн. единиц хранения разных форматов (от А5 и А4/2 до нескольких А0) с разным количеством листов и крайней разнородностью документов (конструкторская и технологическая документация, чертежи, схемы, карты, текстовые и табличные документы, спецификации, ведомости и т.д.). До сих пор эксплуатируются объекты, документация на которые выпущена в первой половине XX столетия (и это еще не предел!) и, естественно, находится в плачевном состоянии.

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

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

Тем не менее, наиболее активные в области автоматизации предприятия уже производят сканирование инженерных документов в электронный архив (вместе с подписями), объявляют их «электронными подлинниками» и все последующее размножение производят непосредственно из электронного архива[19, c.47].

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

· перевод в электронный вид (сканирование) имеющихся бумажных документов;

· запись в электронный архив электронных копий бумажных документов либо электронных документов, разрабатываемых с использованием САПР;

· хранение электронного архива на оперативных (HDD, RAID) и долгосрочных (CD, DVD и т.п.) накопителях, оперативный доступ к архивным данным (поиск, просмотр, размножение, выкопировка);

· вывод и тиражирование по заявкам инженерной документации из электронного архива.

При создании электронного архива надо учитывать, что инженерная документация может быть различных форматов. Любой технический документ можно отнести к широкоформатным (А2-А0+) либо к узкоформатным (А5-А3). При этом требования к аппаратным средствам для обработки широкоформатных и узкоформатных документов -- абсолютно разные.

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

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

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

2.3 Разработка конструкторской документации с применением САПР

Для разработки печатной платы в OrCAD необходимо создать новый проект. Проекты, созданные с помощью программы OrCAD Capture, заносятся в файлы с расширением .opj (по терминологии, принятой в программе, проект называется Project), которые содержат ссылки на имена всех используемых файлов: файлов отдельных схем (*.dsn, по принятой терминологии файлы схем называются Design), библиотек, текстовых VHDL-файлов, файлов отчетов о проекте и др.). В файле проекта могут содержаться ссылки на одну или несколько папок (эти папки изображаются в окне менеджера проектов, ассоциируемых с файлами принципиальных схем. Папка принципиальной схемы содержит одну или несколько страниц схемы. Файл схемы содержит также Design cache -- кэш проекта, который содержит копии символов компонентов, используемых в схеме. Проект может содержать ссылки на несколько библиотек. Однако он может иметь только одну схему (файл с расширением имени .dsn). Можно создать новый проект и затем создать новые схемы, библиотеки и VHDL-файлы. Для создания нового проекта выполняется команда File>New Project, после чего в открывшемся диалоговом окне на строке Name указывается имя проекта, а на строке Location -- имя подкаталога, где его файл должен быть расположен (при этом для просмотра файловой структуры удобно пользоваться кнопкой Browse). Далее в средней части этого окна выбирается тип проекта: Analog or Mixed-Signal Circuit -- аналоговые или смешанные аналого-цифровые устройства, моделируемые с помощью программы PSpice (возможна дальнейшая разработка печатной платы с помощью OrCAD Layout); библиотеки символов, используемых в проекте, указываются под управлением Мастера создания проекта. По команде Design Properties или Schematic Page Properties задаются параметры индивидуальной текущей схемы. В появившемся окне можно выбирать требуемую систему измерений, а также выбрать формат листа либо поставить размеры, которые необходимы.

После создания нового проекта необходимо собрать электрическую схему разрабатываемого модуля. Библиотеки программы Capture содержат в себе символы компонентов, источников питания и "земли". Они размещаются на схеме по команде Place>Part. В диалоговом окне этой команды сначала в списке Libraries выбирается имя одной или нескольких библиотек, содержание которых отображается на панели Part (для выбора нескольких библиотек нажимается и удерживается клавиша [Ctrl]). После этого на панели Part выбирается имя компонента, символ которого должен быть помещен на схему. В разделе Graphic выбирается обычное (Normal) или эквивалентное изображение логических компонентов в стиле DeMorgan (Convert). В разделе Packaging указывается номер секции компонента, после чего в расположенном ниже окне выводится изображение выбранной секции компонента с указанием номеров цоколевки его выводов (на строке Parts per Pkg. указывается общее количество секций компонента). Нажатием на кнопку Add Library открывается диалоговое окно для добавления библиотек в список Libraries, мы на данном этапе использовали библиотеку Pspice, так как она наиболее подходит для дальнейшего моделирования платы в Layout. Нажатие на кнопку Remove Library удаляет выбранную библиотеку из списка. Кнопка Part Search предназначена для поиска конкретного компонента в библиотеках из списка Libraries. После нажатия на кнопку ОК символ выбранного компонента переносится на схему.

Движением курсора компонент перемещается в нужное место схемы и фиксируется нажатием левой кнопки мыши. После этого на схему может быть размещена еще одна копия этого же символа. Нажатие правой кнопки мыши открывает всплывающее меню, в котором дублируется вызов команд основного меню для вращения (Rotate), зеркального отображения (Mirror), изменения масштаба изображения (Zoom), редактирования параметров компонента (Edit Properties) и ряд других. Завершение размещения на схеме символа выбранного компонента производится после выбора в этом меню команды End Mode или нажатия на клавишу [Esc]. Если, не прерывая режима размещения символов компонентов на схеме во всплывающем меню выбрать команду Edit Properties, выводится диалоговое окно редактирования параметров текущего символа. В нем имеются следующие поля: Part Reference -- позиционное обозначение компонента. Оно проставляется здесь вручную, если на закладке Miscellaneous команды Options>Preferences не выбран параметр Automatically reference placed parts -- автоматическое присваивание позиционных обозначений размещаемым на схеме компонентам.

На панели РСВ Footprint можно выбрать или скорректировать имя корпуса компонента, выбор панели Power Pins Visible указывает на необходимость отображения на схеме выводов "земли" и питания. На панели Primitive выбирается тип компонента: Yes -- элементарный (примитивный) компонент; No -- компонент, имеющий иерархическую структуру, Default -- устанавливается по умолчанию (в соответствием с настройкой конфигурации на закладке Hierarchy команды Options>Design Template. На панели Packaging указывается общее количество однотипных секций компонента и имя (номер) текущей секции (к сожалению, на этой закладке номер секции размещаемого символа компонента изменять нельзя).

По команде Place>No connect наносятся символы отсутствия соединений No-connect (NC), которые на схеме отображаются в виде символов "X", подсоединенных к выводам компонентов. Выводы, помеченные такими символами, не включаются в отчеты сообщений об ошибках и в списки соединений. Символы NC не могут быть удалены нажатием на клавишу [Delete], для их удаления нужно поверх символа NC разместить еще один такой же символ.

Проводники цепей размещаются по команде Place>Wire, нажатием комбинации клавиш [Shift]+W или нажатием на кнопку панели инструментов. Начало ввода цепи отмечается щелчком левой кнопки мыши, после чего курсор изменяет свою форму, приобретая вид креста. Цепь прокладывается движениями курсора. Каждый излом проводника фиксируется щелчком левой кнопки мыши. Таким образом, в цепи можно сделать ортогональные изломы под углами, кратными 90°. Ввод проводника под произвольным углом производится при нажатой клавише [Shift]. Ввод текущей цепи завершается, если ее конец совпадает с выводом компонента или любой точкой другой цепи. Принудительное завершение ввода цепи выполняется двойным щелчком левой кнопки мыши, после чего можно провести другой проводник. Режим ввода цепей завершается нажатием клавиши [Esc] или выбором строки End Wire во всплывающем меню, открываемом щелчком правой кнопки мыши.

После создания схемы для производства трассировки печатной платы необходимо создать список цепей собранной схемы. На закладке Layout команды Tools>Create Netlist можно отметить опцию Run ECO, тогда после составления списка соединений он будет автоматически передан в OrCAD Layout, и в текущей плате будет выполнены соответствующие изменения (загружены недостающие корпуса компонентов, удалены лишние и скорректированы электрические соединения, т.е. выполнена корректировка печатной платы по данным о принципиальной схеме). Если при этом файл печатной платы с предварительно размещенными компонентами открыт, то будет выведен запрос на подтверждение загрузки файла списка соединений; если же файл печатной платы не открыт, то OrCAD Layout выведет запрос на подтверждение загрузки модифицированного списка соединений после повторного открытия файла печатной платы[11, c.91].

Трассировку печатной платы будем производить в программе Layout, входящей в пакет OrCAD. Для создания новой печатной платы в OrCAD Layout выполняется команда File>New и в диалоговых окнах указывается имя файла шаблона печатной платы (*.tch). Для нашего случая был выбран шаблон metric.tch. Далее, в открывшемся окне выбираем имя файла списка цепей (*.mnl) и имя файла создаваемой печатной платы (*.mах).

После выполнения выше указанных пунктов на экране отображаются элементы схемы и существующие между ними связи. Далее, выставляем шаг координатной сетки с помощью команды Орtions> Sistem settings. Для задания размеров платы используем команду Tool > Obstracle > New и по координатам задаем границы платы. После этого размещаем граничные элементы (соединители) на печатной плате, а все остальные элементы размещаем автоматически командой Auto>Place>Board. После размещения проверяем расположение элементов и при необходимости вручную изменяем положение элементов. Для этого командой Tool >Component >Select Tool выделяем компоненты и расставляем их. После завершения размещения элементов командой Tool > Net > Select From Spreadsheet задаем ширину печатного проводника. Для трассировки платы используем команду Auto > Autoroute > Bord.

После чего получаем готовую печатную плату, которую сохраняем в файле с расширением *.dxf для дальнейшего редактирования платы в AutoCAD. Для этого используем следующую команду File > Export > Layout to DXF. После чего появляется диалоговое окно в котором выбирается файл для конвертации.

Открываем "AutoCad 2002" и запускаем файл созданной печатной платы с расширением *.dxf. После открытия чертежа в DXF-формате его необходимо отмасштабировать, предварительно выбрав масштаб.

Масштаб следует выбирать исходя из требуемого масштаба чертежа: если масштаб чертежа 1:1, то масштаб увеличений должен быть 12,7; при масштабе 2:1 - 25,4. Для масштабирования вставленного рисунка использовалась команда SCALE, которая работает следующим образом:

Command: scale

Select objects: Other corner: 1 found /запрос на выбор объектов. Выбор объектов можно производить либо окном, либо прямым указанием на объект/

Select objects:

Base point: /запрос на выбор базовой точки/

<Scale factor>/Reference: 25.4 /запрос на ввод масштабного коэффициента/

Масштабированное изображение необходимо редактировать, так как оно не соответствует требованиям стандартов. Редактирование заключается в переводе всех изображений печатных проводников из линий в полилинии и придании им необходимой ширины. Это редактирование осуществляется следующим образом: с помощью команды Explode производится разбиение чертежа на отдельные отрезки:

Command: explode

Select objects: Other corner: /выбираем объект окном, нажимаем правую кнопку мыши и разбиение произведено/

Затем в меню Modify выбираем Object и Polyline, после чего последует запрос на выбор полилинии:

Select polyline: /запрос на выбор полилинии/

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

Object selected is not a polyline

Do you want to turn it into one? <Y>

После этого предлагается набор действий над полилинией:

Open/Join/Width/Edit vertex/Fit/Spline/Decurve/Ltype gen/Undo/exit : w

Ответ "w" на запрос означает редактирование ширины полилинии (ширина указывается в миллиметрах).

Enter new width for all segments: 2

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

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

В выпадающем меню Dimension выбираем графу Style и в окне редактирования стилей создаем собственный стиль размеров на основе стандарта.

Автоматическая простановка допусков при помощи AutoCAD не соответствует требованиям стандартов и поэтому численные значения допусков удобнее наносить вручную. Для этого при простановке размеров, указав точки привязки, в командной строке вводим Text или Mtext после чего вводим значение размера и допуск[14, c.47].

ЗАКЛЮЧЕНИЕ

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

Были решены следующие задачи:

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

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

- ознакомились с источниками затрат при разработке документации,

- изучили требования к системам разработки документации,

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

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

...