The Web-site of design Company Chelyabenergoproekt in English   English
Проектные работы в проектной организации Челябэнергопроект Заказать проектные работы в письме к проектной организации Челябэнергопроект Карта сайта
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch




Création de site web société française Chelyabenergoproekt   Française

   Облако тегов на сайте проектной организации Челябэнергопроект
Проекты интеллектуального мастерства!
новости компании
30.12.2015 С Новым годом!
Администрация ...
21.12.2015 С Днём Энергетика!
Уважаемые друзья и коллеги! Поздравляю вас с нашим большим праздником – Днем Энергетика! ...



новости отрасли
объекты Ростехнадзора
  Облако тегов
проектирование монтаж ключ котел кран сертификат ГОСТ ремонт заказЧелябинск

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

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

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

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

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

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

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

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

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

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

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

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

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

Попытаемся сформулировать определение комплексной системы автоматизации проектирования.

Это комплекс программных средств и мероприятий, который призван обеспечить сквозной цикл многовариантного проектирования объектов и сооружений (изыскания и генплан, технология и инженерные коммуникации, строительство, электрика и АСУ, выпуск ПСД и КД) под управлением системы технического документооборота на базе единого информационного пространства для всего цикла проектирования в тесной связи с системой международных стандартов менеджмента качества проектной продукции ИСО 9000.

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

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

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

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

Взаимосвязь этих этапов представлена на рисунке.



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

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

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

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

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

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

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

Рассмотрим этап обследования.

Этот этап – основа всех будущих работ. Специалист по внедрению не станет приступать к автоматизации проектирования без детального изучения специфики предприятия-заказчика.

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

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

Рассмотрим разработку стандарта работы в AutoCAD.

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

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

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

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

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

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

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

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

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

Естественно, для организации единого информационного пространства необходим соответствующий инструмент.

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

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

Рассмотрим задачу планирования.

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

В связи с этим в реализуемой среде разработки создается не одно дерево объектов, отражающих структуру проекта, а два: дерево 3D-моделей, описывающих геометрию разрабатываемого изделия (в дальнейшем – «дерево 3D-моделе»), и дерево документов, в которое включаются 2D-модели и все остальные типы моделей и объектов проекта (в дальнейшем – «дерево документов»).

В качестве системы планирования на предприятии предложено использовать систему MS Project и программный интерфейс ее взаимодействия с системой TDMS.

Кратко опишем организацию программного взаимодействия систем TDMS и MS Project.

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

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

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

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

При ведении такой разработки под управлением среды TDMS, каждая 3D-сборка, объект или документ имеет свой статус, отражающий стадию разработки. В свою очередь, каждой стадии разработки соответствует определенный процент выполнения работ над документом. В зависимости от статуса этот процент «переносится» посредством программного интерфейса из среды TDMS в систему планирования MS Project. По окончании разработки КД в среде TDMS в среду MS Project через интерфейс поступает команда на отображение отметки о выполнении работ по соответствующей строке плана-графика.

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

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

Рассмотрим задачу проектирования.

Основным средством разработки трехмерных моделей на предприятии является система трехмерного твердотельного проектирования Pro/ENGINEER от компании PTC. Следует отметить, что окончательное формирование двумерных чертежей на предприятии осуществляется как в данной системе, так и в системах плоскостного проектирования, созданных сторонними разработчиками. При этом ассоциативная связь между трехмерной моделью и порожденными ею двумерными чертежами может оказаться разорванной. Для предотвращения подобной ситуации в системе TDMS была разработана структура хранения данных, обеспечивающая сохранность ассоциативной связи. Ее идеологическим отличием является интеграция двух древовидных структур объектов TDMS, предназначенных соответственно для хранения трехмерных (дерево 3D-моделей) и двумерных (дерево документов) структур изделия. Такая интеграция предусматривает наличие горизонтальных перекрестных связей для ускорения навигации между деревьями, скажем, при переходе от трехмерной детали к ее проекции. По этим перекрестным связям также автоматически отслеживаются изменения трехмерной модели или плоского чертежа, и в случае изменения объекта с одной стороны связи автоматически формируется соответствующее уведомление конструктору о несоответствии оригинала порожденному им чертежу с требованием исправления возникшей ситуации. Рассмотрим поэтапно методологию работы конструкторов проектной организации после завершения описанных выше процессов планирования.

1. Создание и регистрация сборки верхнего уровня будущего изделия. На предприятии внедряется методология нисходящего проектирования и управления большими сборками в Pro/ENGINEER, предусматривающая создание на начальном этапе пустой древовидной структуры проектируемой сборки с ее последующим наполнением. Для создания концептуальной схемы будущего изделия руководитель проекта формирует сборку верхнего уровня, которая имеет прямую наследственную связь со срезом схемы изделия, полученным на этапах планирования. Таким образом, после окончания планирования руководитель проекта формирует в Pro/ENGINEER трехмерное дерево будущего изделия и при наличии соответствующих прав переносит его в TDMS. При этом в соответствии с принятым на предприятии соглашением об обозначениях объектов TDMS автоматически формируются перекрестные связи между древовидными структурами объектов среза схемы деления и регистрируемых 3D-объектов сборки верхнего уровня и, следовательно, – горизонтальные связи между деревом 3D-моделей и деревом документов.

2. Выгрузка трехмерных данных из TDMS. При наличии соответствующих прав командой TDMS инициализируется выгрузка файлового состава из объектов в папку на локальной машине, местоположение которой задается конструктором. Этот процесс необходим для повышения отказоустойчивости системы в целом, поскольку работа конструктора становится автономной и на данном этапе разработки не зависит от состояния серверных и сетевых составляющих компонент. В процессе выгрузки данных в дереве 3D-моделей TDMS создается объект, файловый состав которого включает в себя все выгружаемые файлы, а также XML-файл, содержащий всю атрибутивную и иерархическую структуру выгружаемых объектов. Такой объект, создаваемый при каждой выгрузке, необходим для последующего восстановления выгруженных данных в случае их потери или для восстановления предшествующего состояния выгруженных объектов, являясь, таким образом, версией выгружаемых данных.

3. Загрузка трехмерных данных в TDMS. Загрузка результата работы проектировщика из Pro/ENGINEER также инициализируется соответствующей командой TDMS. При этом во временную папку на локальной машине конструктора из Pro/ENGINEER выгружаются файлы последней версии модели, переносящиеся затем на сервер в дерево 3D-моделей TDMS. Данный процесс аналогичен процессу переноса объектов сборки верхнего уровня, однако здесь при включении файлов в состав объектов первоначального дерева 3D-моделей возможны три варианта поведения TDMS:
    - перенос измененного объекта – в данном случае в TDMS загружается измененный в процессе работы конструктора объект, ранее присутствовавший в модели, которая выгружается из дерева 3D-моделей. При этом происходит замена файлового состава и атрибутивной части в существующих объектах дерева 3D-моделей;
    - перенос добавленного объекта – в процессе переноса ранее не существовавшего в TDMS объекта в соответствующем месте дерева 3D-моделей формируется структура переносимого нового узла либо поддерева. При этом осуществляется проверка наличия объектов в дереве документов в соответствии с принятым на предприятии соглашением об обозначениях. При их наличии устанавливается перекрестная взаимосвязь между созданными объектами дерева 3D-моделей и найденными объектами дерева документов. Объекты, отсутствующие в дереве документов, создаются, как и в случае с деревом 3D-моделей, при этом перекрестные связи также устанавливаются автоматически.
    - перенос удаленного объекта – если удаленный объект имел в дереве документов объекты с существующим файловым составом, то он не удаляется из дерева 3D-моделей, а приобретает статус «аннулированного». В противном случае объект удаляется из дерева документов.

Рассмотрим задачу проведения изменений.

Механизм внесения изменений в конструкторские документы в системе TDMS разрабатывается на основании типовой схемы процесса внесения изменений в КД. При этом во время проведения регламентных работ предусматривается возможность вносить в КД данные о замене устаревших элементов на новые, соответствующие достигнутому технологическому уровню. Таким образом, производится модернизация технических систем. Внесение изменений в электронном виде осуществляется в соответствии не только с положениями ГОСТ 2.503-90, регламентирующими проведение изменений в конструкторской документации, но с и требованиями к проведению изменений в электронных конструкторских документах, изложенными в приложении А ГОСТ 2.051-2006 «Электронные документы».

При проведении изменений в электронных конструкторских документах реализован следующий алгоритм.
1. Инициатор создает в TDMS извещение на изменения (ИИ), заполняет все необходимые поля карточки.
2. ИИ встроенными средствами маршрутизации системы TDMS отправляется для получения регистрационного номера в отделе.
3. Сотрудникам отдела СИТД приходит письмо с просьбой выдать регистрационный номер.
4. После выдачи регистрационного номера ИИ отправляется обратно инициатору.
5. Инициатор создает в системе TDMS электронное административное поручение, при помощи которого извещение отправляется по маршруту согласования.
6. После согласования всеми указанными в маршруте лицами инициатору приходит соответствующее письмо, позволяющее приступать к внесению изменений.
7. Инициатор создает производственные поручения со ссылкой на извещение и конструкторский документ, в который необходимо внести изменения, и рассылает их отделам-разработчикам для внесения изменений.
8. Каждому отделу-разработчику приходит письмо и производственное поручение, в котором указан конструкторский документ, требующий внесения изменений.
9. В системе TDMS в соответствии с требованиями приложения А ГОСТ 2.051-2006 генерируются новые версии электронных документов, в которые и вносятся изменения. Все версии документов сохраняются в БД TDMS.
10. В карточке учета указываются вносимые в конструкторский документ изменения, а в карточке версионности – новая версия и основание изменений.
11. После прохождения маршрута рецензирования процесс внесения изменений в данный конструкторский документ считается завершенным.
12. По окончании отработки всех производственных поручений и внесения необходимых изменений работа с извещением завершается и оно переводится в статус архива.

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

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

Рассмотрим задачу ведения архива.

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

Рассмотрим выполнение пилотных (учебных) проектов.

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

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

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

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

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

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

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

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


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

Рассмотрим программную систему TechnologiCS.

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

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

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

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

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

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

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

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

Получая исходную информацию в виде поступающих заказов, специалисты плановых служб приступают к первичному планированию. Первое, что они могут определить, – это потребности производства по данному заказу и плану производства в целом: сколько материалов, инструмента, покупных и комплектующих необходимо выдать или закупить для цеха либо участка, какова будет загрузка его производственных мощностей и как это согласуется с трудовым фондом. Далее с использованием данных по производственным складам, ведение которых также обеспечивается TechnologiCS (включая партионный учет, формирование и учет складских документов прихода/расхода, списания и передачи материальных ценностей, хранение параметров конкретных деталей, комплектующих, материалов и инструмента в соответствии с требованиями контроля качества по ИСО 9001), формируются производственные спецификации. Производственная спецификация базируется на ранее заложенных технологии и структуре изделия, но учитывает реальное состояние склада и производства. На этом этапе задается необходимость исключения из плана определенных позиций (например, в связи с их наличием на складе) или, напротив, дополнительное производство некоторых из них на склад. Здесь же можно учесть оперативные изменения в связи с отсутствием на складе нужного сортамента или материала, оптимизировать партии запуска, распараллелить маршруты движения разных партий одного и того же изделия... Используя трудовые нормативы, TechnologiCS автоматически рассчитывает циклограмму выполнения данной производственной программы и формирует, исходя из общих рамок, предварительные даты запуска и выпуска отдельных позиций.

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


Сформированная производственная программа поступает в производство. Разумеется, параллельно с электронным планом оформляется и все «бумажное» сопровождение: документы по складу, наряды, маршрутные листы, карты комплектования и другие документы. Тем самым TechnologiCS предлагает облегчить жизнь уже внутрицеховым специалистам – мастерам цехов и диспетчерам. Автоматизируется и формирование документации, и фиксация прохождения изделия по производственному маршруту. Оформление сдачи изготовления по факту производства может производиться как пооперационно с учетом результатов выполнения каждой операции (фактическая трудоемкость; наличие, вид и причина брака; параметры контроля по результатам операции), так и подетально. Использование данных по факту изготовления позволяет анализировать причины возникновения брака и иных отклонений в производстве, вырабатывать наиболее эффективные методы борьбы с ними.

Результаты работы производственного модуля – производственные планы, отчеты по фактическому изготовлению, данные по складам – могут передаваться в производственные системы класса MRP II/ERP для дальнейшей обработки, расчета себестоимости, зарплаты и решения других задач управления предприятием.

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

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


Источники:
1. Ревзин, В. Комплексная автоматизация проектных организаций: цели, условия, результаты // CADmaster, №4(29), 2005 [http://csf.ru/file/eOkCZcQRJJVRcYWu8298015/cm_29_avt_proekt_org.pdf]
2. Лебедев, И. Генеральная линия// CADmaster, №4(39), 2007 [http://www.cadmaster.ru/articles/article_25662.html]
3. Воробьев, А., Пивоваров, В., Алимов М. и др. Концепция создания единой среды проектирования как первый этап обеспечения жизненного цикла изделий. Опыт ОАО «Конструкторское бюро специального машиностроения»// CADmaster, №42, 2008 [http://csf.ru/file/hpAluIfzzMTlxrwI8298037/cm_42_opyt_kbsm.pdf]
4. Серавкин, А. Промышленным предприятиям – комплексные решения под маркой CSoft// CADmaster, №1(16), 2003 [http://csf.ru/file/dDptLBxJNRUBuIgS8298017/cm_16_kompl_resh_csoft.pdf]
5. Штарев, В. Банкрутенко, В. Лазарев А. и др. Сквозной цикл производства изделия как результат внедрения ИПИ-технологий в Опытном конструкторском бюро машиностроения// CADmaster, №5(40), 2007 [http://www.cadmaster.ru/articles/article_27976.html]

Автор: Челябэнергопроект
Дата: 22.07.2009

Комментарии специалистов Челябэнергопроект:
Нет
Статьи

смета проектных работ
©Челябэнергопроект – проектные работыinfo@chepr.ru, 2007-2013
DRA.RU - проектирование сайта под ключ; системный администратор ООО «Челябэнергопроект»
Главная|О компании|Стратегия|
Компетенция / услуги|Контакты
Сертификат качества