Технологическая инструкция и2 гост 34 пример

Перейти к основному содержанию

Пример документа «Технологическая инструкция» (И2 по ГОСТ 34.201-89), разработанного для автоматизированной измерительно-информационной системы коммерческого учета электроэнергии (АИИС КУЭ) согласно требованиям подраздела Технологическая инструкция по РД 50-34.698-90 к структуре, содержанию и содержимому документа. Оформлен по ГОСТ 2.104 и ГОСТ 2.106. Редакция от 20.06.2018.

Технологическая инструкция (И2 по ГОСТ 34.201-89) автоматизированной измерительно-информационной системы коммерческого учета электроэнергии (АИИС КУЭ) (пример)

Создан 24.03.2014 12:23:18

- Технологическая инструкция АИИС КУЭ

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

Все документы боевые, прошедшие множество экспертиз, включая экспертизы в ФГУП «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИМАШ) РОССТАНДАРТА, поэтому качество документов сомнению не подлежит.

Для получения бесплатной сокращенной версии любого документа в виде файла формата *.pdf достаточно щелкнуть мышью по изображению титульного листа. Документ откроется в браузере с возможностью сохранения на локальном компьютере. Полные версии документов — платные, их можно получить в редактируемом формате за определенную сумму, воспользовавшись контактной формой. Любой документ может в течение некоторого времени быть доработан под конкретные требования заказчика. Условия обсуждаются.

Время на прочтение
12 мин

Количество просмотров 447K

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

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

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

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов

Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:

  • приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
  • структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
  • пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
  • Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
  • Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
  • администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

Соответственно, в стандарте есть артефакты, наподобие следующего:

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

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

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

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо

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

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

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

Можно смеяться над тем, что создатели стандартов ничего не знали о java или .NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

Как читать и понимать стандарты документации по ГОСТ серии 34

Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

  • Эскизный проект (ЭП)
  • Технический проект (ТП)
  • Разработка рабочей документации (РД)

Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

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

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

Части (разделы) проектной документации по созданию АСУ

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

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

Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

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

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

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

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

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

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

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя. Комментарии излишни, я думаю.

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

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

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

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

как

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

какие

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

не ставим

. Мы эти бизнес-процессы

автоматизируем

.

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

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

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

А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

Варианты использования ГОСТ 34

  1. Полное и точное следование стандарту. Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
  2. Мы просто любим ГОСТы. В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
  3. Нам плевать на документацию, лишь бы все работало. Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями — директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

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

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

    ГОСТ 3.1407-86

Группа Т53

 МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система технологической документации

ФОРМЫ И ТРЕБОВАНИЯ К ЗАПОЛНЕНИЮ И ОФОРМЛЕНИЮ ДОКУМЕНТОВ НА ТЕХНОЛОГИЧЕСКИЕ ПРОЦЕССЫ (ОПЕРАЦИИ), СПЕЦИАЛИЗИРОВАННЫЕ ПО МЕТОДАМ СБОРКИ

Unified system for technological documentation. Forms and requirements for filling and arrangement of documents on technological processes (operations) specialized in assembling methods

МКС 01.110          

ОКСТУ 0003

Дата введения 1988-01-01

 ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 25.11.86 г. N 3542

3. ВЗАМЕН ГОСТ 3.1406-74, ГОСТ 3.1407-74, ГОСТ 3.1411-74, ГОСТ 3.1413-73, ГОСТ 3.1417-74, ГОСТ 3.1419-74, ГОСТ 3.1422-75, ГОСТ 3.1426-76, ГОСТ 3.1427-77, ГОСТ 3.1430-78

4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Обозначение НТД, на который дана ссылка

Номер пункта,  приложения

ГОСТ 2.004-88

2.1

ГОСТ 2.312-72

2.9.4

ГОСТ 3.1103-82

2.6

ГОСТ 3.1105-84

1.1, приложение 1

 ГОСТ 3.1107-81

    1.5, 2.4

ГОСТ 3.1118-82

1.1, 1.3.3, 2.8.1, 2.11.1, приложение 1

ГОСТ 3.1119-83

2.4, 2.13

ГОСТ 3.1120-83

2.5

ГОСТ 3.1121-84

1.1, 2.4, 2.13, приложение 1

ГОСТ 3.1122-84

1.1, приложение 1

ГОСТ 3.1123-84

1.1

ГОСТ 3.1129-93

2.1

ГОСТ 3.1130-93

2.1

ГОСТ 3.1502-85

1.1

ГОСТ 3.1702-79

     1.4

ГОСТ 3.1703-79

2.3

ГОСТ 3.1704-81

2.3

ГОСТ 3.1705-81

2.3

ГОСТ 11969-93

Приложение 1

ГОСТ 19249-73

2.9.4, приложение 1

5. ПЕРЕИЗДАНИЕ. Апрель 2003 г.

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

 1. ФОРМЫ И ТРЕБОВАНИЯ К ЗАПОЛНЕНИЮ ДОКУМЕНТОВ

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

Таблица 1

Тип произ-

водства

Стадии разра-

ботки докумен-

тации

Степень детали-

зации описания ТП

Наименование метода (процесса, операции)

Наиме-

нование

вида и

обозна-

чение формы документа

Условное обозна-

чение

документа, функции которого выполняет

документ

Указания по применению

Единичное, мелко-

серийное

Предвари-

тельный проект.

Разработка докумен-

тации опытного образца (опытной партии)

Маршрутное,

маршрутно-

операци-

онное

Все методы сборки, а также сопутствующие операции (процессы)

Маршрутная карта (МК) формы 2, 1б, 4, 3б по ГОСТ 3.1118

КТП, КТТП

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

То же

КТИ

Для указания переменной информации к типовому (групповому) технологическому процессу (ТТП, ГТП), к типовой (групповой) технологической операции (ТО, ГО) на ДСЕ одного обозначения

»

ВТП (ВТО)

То же

»

ОК

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

»

КТО

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

»

КН

Для указания соответствующей информации по наладке оборудования (для сварки, пайки, клепки и т.п.)

»

КК

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

Ведомость деталей (сборочных единиц) к типовому (групповому) техноло- гическому процессу или операции (ВТП или ВТО) формы 6, 6а, 7, 7а по ГОСТ 3.1121

ВТП (ВТО)

Для указания переменной информации к ТТП (ГТП) или ТО (ГО) с привязкой к соответствующему обозначению ДСЕ

Ведомость техноло-

гических документов (ВТД) формы 4, 4а, 5, 5а по ГОСТ 3.1122

ВТД

Для указания состава сборочных единиц (изделий) к ТТП (ГТП) с целью оптимизации поиска и нахождения соответствующих документов и данных, относящихся к ДСЕ

Комплек-

товочная карта (КК) формы 6, 6а, 7, 7а по ГОСТ 3.1123

КК

См. указания по применению МК/КК. Применяют по усмотрению разработчика

Настройка и регулировка

Техноло-

гическая инструкция (ТИ) формы 5, 5а по ГОСТ 3.1105

КТП

Для нормирования трудозатрат. Применяют

совместно с МК (формы 2, 1б или 4, 3б) по ГОСТ 3.1118, выполняющую функции сводного документа на процесс

Средне-

серийное, крупно-

серийное

Разработка докумен-

тации серийного (массового) произ-

водства

Операци-

онное

Все методы сборки, а также сопутствующие операции (процессы)

МК формы 2, 1б, 4, 3б по ГОСТ 3.1118

КТП, КТТП,

КТИ, ВТП (ВТО), ОК, КТО, КН, КК

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

Карта типового (группового) техноло-

гического процесса (КТТП) формы 1, 1а по ГОСТ 3.1121

КТТП

Для разработки типовых (групповых) технологических процессов

ВТП (ВТО) формы 6, 6а, 7, 7а по ГОСТ 3.1121

ВТП (ВТО)

Для указания переменной информации к ТТП (ГТП) или ТО (ГО) с привязкой к соответствующему обозначению ДСЕ

Карта эскизов (КЭ) формы 6, 6а, 7, 7а, 8, 8а по ГОСТ 3.1105

КЭ

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

ВТД формы 4, 4а, 5, 5а по ГОСТ 3.1122

ВТД

Для указания состава сборочных единиц (изделий) к ТТП (ГТП) с целью оптимизации поиска и нахождения соответствующих документов и данных, относящихся к ДСЕ

Разработка докумен-

тации серийного (массового) произ-

водства

Операци-

онное

Все методы сборки, а также сопутствующие операции (процессы)

КК формы 6, 6а, 7, 7а по ГОСТ 3.1123

КК

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

Операцион-

ная карта (OК) формы 1, 1а, 2, 2а настоящего стандарта

ОК

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

ОК формы 3, 3а настоящего стандарта

ОК

Для разработки ОК на операции, выполняемые с применением конвейера (автоматической линии) без применения средств механизации и автоматизации для их проектирования

ОК формы 1, 1а, 2, 2а, 3, 3а настоящего стандарта

КТО, КТИ

Для указания переменной информации к типовой (групповой) операции на ДСЕ одного обозначения в КТИ и постоянной информации в КТО

Настройка и регулировка

ТИ, формы 5, 5а по ГОСТ 3.1105

КТП

См. указания по применению ТИ/КТП для единичного, мелкосерийного производства с учетом степени детализации описания

ОК формы 2, 2а по ГОСТ 3.1502

ОК

Для разработки ОК на настройку и регулировку.

КТО

Для указания постоянной информации к ТО (ГО) настройки и регулировки

Ведомость операций (ВОП), формы 1, 1а по ГОСТ 3.1502

ВОП

Для указания состава операций настройки и регулировки, входящих в технологический процесс

Примечание. Применение документов других видов, не указанных в табл.1, устанавливается в отраслевых нормативно-технических документах (НТД) или в документах на уровне предприятия (организации).

1.2. Требования к построению и заполнению операционных карт (ОК), устанавливаемых настоящим стандартом, (формы 1 и 1а, 2 и 2а, 3 и 3а) — по табл.2.

Таблица 2

Но-

мер гра-

фы

Номер формы OK

Размер графы

Наименование (условное обозначение) графы

Содержание графы

мм

коли-

чество знаков

1

1, 1a, 2, 2a, 3 ,3a

13,0

5

Обозначение служебного символа и порядковый номер строки. Запись выполняют на уровне одной строки, например К06, М04. Допускается при указании номера строки от 01 до 09 применять вместо знака «0» знак «

«, например М

4

2

1

119,6

46

Код, наименование операции

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

2, 3

148,2

57

3

1

132,6

51

Обозначение документа

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

2

148,2

65

4

1, 2

20,8

8

МИ

Масса изделия по конструкторскому документу

5

1

119,6

46

Резервная графа. Заполняется по усмотрению разработчика. Графу можно использовать для записи информации об оборудовании

6

1

114,4

44

Код, наименования оборудования

Код, краткое наименование оборудования, его инвентарный номер. Информацию следует указывать через разделительный знак «;». Допускается взамен краткого наименования оборудования указывать модель, не указывать инвентарный номер

2

130,0

50

7

1, 2, 3

18,2

7

Тв

Вспомогательное время на операцию

8

1, 2

20,8

8

То

Основное время на операцию

3

18,2

7

9

1, 1a

119,6

46

Наименование

детали, сб. единицы

или материала

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

2, 2a

169,0

65

3, 3a

169,0

65

10

1, 1a

75,4

29

Код, обозначение

Обозначение (код) деталей, сборочных единиц по конструкторскому документу или материала по классификатору

2, 2a

72,8

28

3, 3a

72,8

28

11

1, 1a, 2, 2a, 3, 3a

13,0

5

ОПП

Обозначение подразделения (склада, кладовой и т.п.) откуда поступают комплектующие детали, сборочные единицы или материалы; при разработке — куда поступают

12

1, 1a, 2, 2a, 3, 3a

13,0

5

ЕВ

Код единицы величины (массы, длины и т. п.) детали, заготовки, материала по Классификатору СОЕИ. Допускается указывать единицы измерения величины

13

1, 1a, 2, 2a, 3, 3a

13,0

5

ЕН

Единица нормирования, на которую установлена норма расхода материала, например 1, 10, 100

14

1, 1a, 2, 2a, 3, 3a

18,2

7

КИ

Количество деталей, сборочных единиц, применяемых при сборке изделия; при разборке — получаемых

15

1, 1a, 2, 2a, 3, 3а

20,8

8

Н. расх.

Норма расхода материала

16

3, 3a

18,2

7

Поз.

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

17

3

18,2

7

Т в. пр.

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

18

3

18,2

7

Т сум.

Суммарная норма времени на операцию

19

3

18,2

7

Кол. за цикл

Количество сборочных единиц (изделий) за цикл

20

3

18,2

7

Тшт.

Норма штучного времени на операцию

21

3

18,2

7

Произв.

Расчетно-часовая производительность оборудования

22

3

41,6

16

Обозначение ИОТ

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

23

3

109,2

42

Наименование оборудования

Наименование оборудования

24

3

59,8

23

Код, обознач. оборудования

Код, обозначение оборудования по классификатору

25

3, 3а

18,2

7

ПИ

Номер позиции инструментальной наладки. Применяется по усмотрению разработчика

26

3, 3а

78,2

28

Наименование ТО

Наименование технологической оснастки

27

3, 3а

57,2

22

Код, обозначение ТО

Код, обозначение технологической оснастки по классификатору

28

3, 3а

20,8

8

Кол.

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

Примечания:

1. В графе «количество знаков» указано число знаков, соответствующее ширине данной графы. Максимальное количество знаков, вносимых в графу, на один знак меньше числа знаков, указанных в табл.2.

2. Размеры граф даны исходя из шага печатающих устройств, равного 2,6 мм.

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

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

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

Типовые блоки режимов приведены в  приложении 1.

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

1.3.3. Типовые блоки режимов могут быть внесены в бланки документов после строки со служебным символом К/М с привязкой к служебному символу Р. В этом случае формы документов будут иметь специальное назначение и распространяться только на сварку или пайку конкретных видов (способов). Обозначение таких форм документов следует выполнять в соответствии с требованиями, изложенными в  приложении 1.

Примечания:

1. Наиболее удобными формами документов для внесения типовых блоков технологических режимов в головку таблицы являются формы 2 и 1б МК по ГОСТ 3.1118  и ОК формы 1 и 1а настоящего стандарта.

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

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

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

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

 2. ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ДОКУМЕНТОВ

2.1. Общие требования к формам и бланкам документов при проектировании документов и общие требования к их оформлению:

— по ГОСТ 3.1129 и ГОСТ 3.1130 — без применения средств механизации и автоматизации;

— по ГОСТ 2.004 — с применением средств механизации и автоматизации.

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

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

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

Пример оформления МК/ОК для слесарных работ приведен в приложении 2.

2.3. Запись операций и переходов в документах следует выполнять:

— по ГОСТ 3.1703 — для слесарных, слесарно-сборочных работ;

— по ГОСТ 3.1704 — для пайки и лужения;

— по ГОСТ 3.1705 — для сварки.

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

2.4. Общие требования к комплектности и оформлению комплектов документов:

— по ГОСТ 3.1119 — для единичных технологических процессов;

— по ГОСТ 3.1121 — для типовых (групповых) технологических процессов (операций).

2.5. Отражение и оформление общих требований безопасности труда в технологической документации — по ГОСТ 3.1120.

2.6. При применении форм МК, выполняющих функции документов других видов, их оформление следует выполнять в соответствии с правилами для документов применяемых видов, предусмотренными стандартами ЕСТД. При этом в графе 28 блока Б6 основной надписи по ГОСТ 3.1103 следует проставлять через дробь условное обозначение соответствующего вида документа, функции которого выполняет МК, например МК/КТП, МК/ОК и т.д.

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

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

—  А, Б, К/М, О, Т, Р — для форм МК с горизонтальным расположением поля подшивки;

— В, Г, Д, Л/М, Н/М, О, Т, Р — для форм МК с вертикальным расположением поля подшивки;

— К/М, О, Т, Р — для форм ОК с горизонтальным расположением поля подшивки;

— Л/М, Н/М, О, Т, Р — для форм ОК с вертикальным расположением поля подшивки.

2.8.1. При применении форм МК/ОК запись информации в графах, относящихся к служебным символам А, Б или В, Г, Д и Е, следует выполнять по ГОСТ 3.1118 с учетом дополнений:

— в графе «Обозначение документа» следует приводить ссылки на применяемые ТИ и инструкции по охране труда (ИОТ);

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

— не заполнять графы по трудозатратам, кроме граф «Тп.з» и «Тшт.», в которые следует вносить данные по суммарному вспомогательному и основному времени соответственно.

2.8.2. Запись информации в графах, относящихся к служебным символам К/М, Л/М, Н/М, независимо от применяемых форм документов, следует выполнять в следующем порядке: вначале следует указывать информацию о комплектующих составных частях изделия (сборочной единицы), затем о применяемых основных и вспомогательных материалах на операцию.

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

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

Допускается записывать информацию по всей длине строки с возможностью переноса информации на последующие строки и указывать номер позиции перед наименованием ДСЕ.

2.9. Описание содержания переходов в операциях следует выполнять с привязкой к служебному символу 0 по всей длине строки с возможностью переноса информации на последующие строки.

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

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

Примечание. Простановку данных по То  и Тв в формах ОК следует выполнять соответственно в графах 14 и 15, в формах МК/ОК — соответственно в графах Тп.з. и Тшт.

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

2.9.3. В содержание основных переходов допускается включать дополнительную информацию:

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

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

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

— по ГОСТ 2.312 — для сварных соединений;

— по ГОСТ 19249 — для паяных соединений, а также по соответствующим государственным и отраслевым стандартам на типы, конструктивные элементы и размеры сварных (паяных) соединений.

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

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

Допускается:

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

стапели — СТ,

приспособления — ПР,

вспомогательный инструмент — ВИ,

слесарный и слесарно-монтажный инструмент — СЛ,

режущий инструмент — РИ,

специальный инструмент — СП,

средств измерений — СИ;

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

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

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

2.11. При разработке процессов (операций), выполняемых с применением специальных средств технологического оснащения (конвейеров для сборки, автоматизированных линий и т.п.) следует применять ОК формы 3 и 3а совместно с МК.

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

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

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

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

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

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

2.11.1. Допускается применять формы 3б МК по ГОСТ 3.1118 или 2а ОК настоящего стандарта взамен формы 3а.

2.11.2. Пример оформления ОК приведен в приложении 2.

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

2.12.1. Формы МК/КН допускается применять в виде самостоятельных документов или в составе документов на типовые и групповые операции.

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

2.13. Примеры оформления МК/КТП приведены в ГОСТ 3.1119, МК/КТТП и МК/ВТП — в ГОСТ 3.1121.

ОПЕРАЦИОННАЯ КАРТА

(первый или заглавный лист)

ОПЕРАЦИОННАЯ КАРТА

(последующие листы)

ОПЕРАЦИОННАЯ КАРТА

(первый или заглавный лист)

ОПЕРАЦИОННАЯ КАРТА

(последующие листы)

ОПЕРАЦИОННАЯ КАРТА

(первый или заглавный лист)

ОПЕРАЦИОННАЯ КАРТА

(последующие листы)

ПРИЛОЖЕНИЕ 1

Обязательное

 ТРЕБОВАНИЯ К ЗАПОЛНЕНИЮ И ОФОРМЛЕНИЮ ТИПОВЫХ БЛОКОВ РЕЖИМОВ, ПРИМЕНЯЕМЫХ В ДОКУМЕНТАХ НА СВАРКУ И ПАЙКУ

1. При описании операций сварки и пайки следует применять типовые блоки режимов, указанные соответственно на черт.1 и 2. Другие блоки режимов допускается устанавливать на уровне отрасли или предприятия (организации).

2. Размеры граф, входящих в блоки режимов, устанавливает разработчик документов, исходя из:

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

— необходимости размещения граф таким образом, чтобы вертикальные линии, разделяющие графы строки со служебным символом К/М и графы блока режимов, по возможности совпадали;

— требуемого количества знаков для записи параметров режимов с учетом единиц величины;

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

3. При введении в формы документов блоков режимов в строке со служебным символом Р следует указывать сокращенное обозначение блока режимов по черт.1 и 2, например РС3 — блок режимов газовой сварки, РП2 — блок режимов пайки в печи.

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

4. Графы блоков режимов сварки (РС1-РС8) следует заполнять в соответствии с табл.3.

Таблица 3

Но-

мер графы

Условное обозначение графы при

Номер блока режимов сварки

Содержание графы

ручном способе запол-

нения

автомати-

зированном проек-

тировании

1

ПС

ПС

РС1, РС3

Обозначение положения сварки по ГОСТ 11969-93*

2

НП

НП

РС1, РС3

Номер прохода для многослойных сварных швов

3

DC

DC

РС1

Диаметр сопла для сварки в защитных газах со струйной защитой

4

LC

РС1

Расстояние от торца сопла до поверхности свариваемых деталей для дуговой сварки в защитных газах со струйной защитой

5

РС1

Вылет электрода (расстояние от точки токоподвода до конца электрода, на котором горит дуга)

6

Пл

ПЛ

РС1

Обозначение полярности (П — прямая, О — обратная)

7

U

U

РС1

Напряжение при электрошлаковой сварке.

Напряжение дуги при остальных способах сварки

PС2

Ускоряющее напряжение

РС4, РС5

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

Зарядное напряжение при сварке на конденсаторной машине

8

I

I

РС1, РС2

Сила сварочного тока (при сварке трехфазной дугой — в цепи электрод-изделие)

9

vc

VC

РС1, РС2, PС4, РС8

Скорость сварки

10

vп

РС1, РС2

Скорость подачи присадочного металла

11

qoз

QO3

РС1, РС8

Расход защитного (плазмообразующего) газа для основной защиты в единицу времени

12

qдз

QДЗ

РС1, РС8

Расход защитного (плазмообразующего) газа для дополнительной защиты в единицу времени

13

QK

РС1

Расход защитного газа для защиты корня шва в единицу времени

14

Ти

ТИ

РС1, РС2

РС8

Длительность импульса сварочного тока

15

Тп

ТП

РС1, РС4

РС8

Длительность паузы между импульсами сварочного тока

16

РС1-РС8

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

17

lп

РС2

Расстояние от среза электронной пушки до поверхности свариваемых деталей

18

РС2

Сила тока фокусирующей катушки

19

f

Ч

РС2

Частота импульсов

20

HM

НМ

РС3

Номер мундштука

21

Рк

PK

РС3

Давление кислорода

22

Рг

РГ

РС3

Давление горючего газа

23

Fпp

FПР

РС4, РС7

Предварительное усилие сжатия

24

Tпр

ТПР

РС4

Длительность приложения предварительного

усилия сжатия

25

I

I1

РС4, РС5

Сила тока первого импульса (подогрева)

26

F

F1

РС4, РС5

Сварочное усилие сжатия при первом импульсе (подогреве)

РС6

Усилие сжатия в стадии нагрева заготовок

27

T

T1

РС4, РС5

Длительность первого импульса (подогрева)

РС6

Длительность нагрева заготовок

28

I

I2

РС4, РС5

Сила тока второго импульса (сварки)

29

F

F2

РС4, РС5

Сварочное усилие сжатия при втором импульсе тока

РС6

Усилие сжатия в стадии осадки

РС7

Рабочее усилие сжатия

30

Т

Т2

РС4, РС5

Длительность второго импульса

РС6

Длительность осадки

РС7

Длительность приложения рабочего усилия сжатия

31

РС4, РС5

Ковочное усилие сжатия

32

Тк

ТК

РС4, РС5

Длительность приложения ковочного усилия

33

Е

Е

РС4

Электрическая емкость конденсаторов (для конденсаторной сварки)

34

lус

LУС

РС5, РС6

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

35

Пр

ПР

РС5, РС6

Общий припуск

36

Пр

ПР1

РС5

Припуск на оплавление

РС6

Припуск на осадку при нагреве заготовок

37

Fзаж

FЗАЖ

РС5

Усилие зажатия стыковой машины

38

VO

РС5

Скорость оплавления

39

n

ЧВ

РС6

Частота или угловая скорость относительного вращения заготовок

40

Рв

РВ

РС7

Давление в камере после вакуумирования

41

Т-ра

Т-РА

РС7

Температура сварки

42

РС7

Скорость нагрева

43

vox

VOX

РС7

Скорость охлаждения

44

N

N

РС8

Мощность излучения

45

Расходим.

РАСХОДИМ.

РС8

Расходимость луча

46

РС8

Диаметр луча

47

РС8

Фокусное расстояние

48

L3

РС8

Заглубление фокуса относительно поверхности свариваемого изделия

5. Графы блоков режимов пайки (РП1-РП8) следует заполнять в соответствии с табл.4.     

Таблица 4

Но-

мер графы

Условное обозначение графы при

Номер блока режимов пайки

Содержание графы

ручном способе заполнения

автомати-

зированном проек-

тировании

1

ПС

ПС

РП1-РП8

Условное обозначение паяного шва по ГОСТ 19249

2

v

v

РП1, РП4, РП7, РП8

Скорость перемещения источника нагрева или изделия

3

vп

РП1

Скорость подачи припоя

4

Т-ра пп

Т-РА ПП

РП1

Температура предварительного подогрева детали (сборочной единицы)

5

Т-ра ж

Т-РА Ж

РП1

Температура жала паяльника

6

Пл

ПЛ

РП1

Вид пламени (нормальное, окислительное, науглероживающее). При заполнении графы применяют сокращения: норм., окисл., наугл.

7

РП1, РП2, РП5

Расход газа в единицу времени

8

НМ

НМ

РП1, РП5

Номер наконечника (мундштука)

9

Тн

ТН

РП1-РП8

Время нагрева при пайке

10

Тох

ТОХ

РП1-РП8

Время охлаждения при пайке

11

РП1-РП8

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

12

РП2, РП3

Скорость движения конвейера (манипулятора)

13

VH

РП2, РП4

Скорость нагрева при пайке

14

Т-ра ив

Т-РА ИВ

РП2, РП6

Температура изотермической выдержки

15

Т-ра п

Т-РА П

РП2, РП4

Температура пайки

РП3

Температура припоя в ванне

16

Тив

ТИВ

РП2, РП6

Время изотермической выдержки

17

Тв

ТВ

РП2, РП3

Время выдержки при пайке

18

РП2, РП6

Усилие сжатия паяемых деталей

19

Ср

СР

РП2

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

20

Т-ра р

Т-РА Р

РП2

Точки росы газа

21

Ро

РО

РП2, РП7

Значение остаточного давления в рабочей вакуумной камере

22

qвф

QВФ

РП3

Расход воздуха при пенном флюсовании

23

Рф

РФ

РП3

Давление струи флюса

24

Ук

УК

РП3

Угол наклона конвейера при пайке волной припоя

25

vпи

VПИ

РП3

Скорость подъема изделия из расплавленного припоя при пайке погружением

26

ЧВ

РП3

Частота вибрации изделия при подъеме из расплавленного припоя

27

А

А

РП3

Амплитуда вибрации изделия

28

РП4

Зазор между индуктором и изделием или приспособлением

29

РП4

Мощность генератора

30

РП4

Сила тока индуктора

31

РП4

Сила тока генератора

32

РП4

Напряжение генератора

33

РП4

Напряжение индуктора

34

РП5

Диаметр электрода

35

DC

DC

РП5

Диаметр сопла

36

П

П

РП5

Обозначение полярности (П — прямая, О — обратная)

37

l

L

РП5

Расстояние от торца электрода или сопла до поверхности паяемых деталей

38

РП5

Напряжение дуги

39

РП5

Сила тока дуги

40

У

У

РП5

Угол наклона горелки или электрода

41

F

F

РП5

Сжимающее усилие на электродах при электродуговой пайке

42

Fпp

FПP

РП6

Предварительное усилие сжатия

43

Тпр

ТПР

РП6

Время приложения предварительного усилия сжатия

44

l

I1

РП6

Сила тока первого импульса (подогрева)

45

Fc

FC

РП6

Усилие сжатия при пайке

46

lп

РП6

Сила тока при пайке

47

Fив

FИВ

РП6

Усилие сжатия при изотермической выдержке

48

Iив

IИВ

РП6

Сила тока при изотермической выдержке

49

lп

РП7, РП8

Расстояние от источника энергии до поверхности паяемых деталей

50

Uy

РП7

Ускоряющее напряжение

51

РП7

Сила тока фокусирующей катушки

52

РП7

Сила тока эмиссии

53

s

S

РП7, РП8

Площадь облучаемой зоны

54

f

Ч

РП8

Частота импульсов

55

Uил

UИЛ

РП8

Напряжение излучателя

56

ПМ

ПМ

РП8

Максимальная плотность лучистого потока в облучаемой зоне

57

Плс

ПЛС

РП8

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

58

W

W

РП8

Вид концентрированной энергии (инфракрасное излучение, излучение лазера, сфокусированный световой луч).

При заполнении графы применяются сокращения: инфр. и., изл. лаз., сф. св. л.

Типовые блоки технологических режимов сварки

Черт.1

Типовые блоки технологических режимов пайки

Черт.2

ПРИЛОЖЕНИЕ 2

Рекомендуемое

 ПРИМЕРЫ ОФОРМЛЕНИЯ ДОКУМЕНТОВ, ВЫПОЛНЕННЫХ НА МК И ОК

Пример распечатки формы ОК на АЦПУ ЭВМ

Оформление ОК, выполненной на МК, на слесарную операцию

Оформление ОК на пайку в печи

Оформление ОК на контактную точечную сварку, выполняемую на автоматической линии

Оформление ОК на сборку

Дата введения 2022-01-01

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 22 декабря 2020 г. N 58)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97 Код страны по МК (ИСО 3166) 004-97 Сокращенное наименование национального органа по стандартизации
Армения АМ ЗАО «Национальный орган по стандартизации и метрологии» Республики Армения
Беларусь ВY Госстандарт Республики Беларусь
Киргизия KG Кыргызстандарт
Россия RU Росстандарт
Узбекистан UZ Узстандарт
Украина UA Минэкономразвития Украины

4 Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2021 г. N 1521-ст межгосударственный стандарт ГОСТ 34.201-2020 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2022 г.

5 ВЗАМЕН ГОСТ 34.201-89

6 ИЗДАНИЕ (март 2022 г.) с Поправкой (ИУС N 3 2022 г.)

1 Область применения

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

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы

_______________

1) В Российской Федерации действует ГОСТ Р 2.601-2019.

ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов

ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

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

3 Виды и наименование документов

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

На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602.

Допускается разрабатывать ТЗ на составные части системы (подсистемы, комплексы задач, программно-технические комплексы, компоненты технического и программного обеспечения и т.п.).

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

Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация», приведены в таблице 1.

Таблица 1 — Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация»

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

Виды документов на программные средства, используемые при создании АС (ее частей), — по ГОСТ 19.101.

Виды документов на технические средства, используемые при создании АС (ее частей), — по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

Наименования конкретных документов, разрабатываемых при проектировании АС в целом или ее части, приведены в таблице 2.

Таблица 2 — Наименования конкретных документов, разрабатываемых при проектировании АС в целом или ее части

Стадия создания Наименование документа Код документа Часть проекта Принадлежность к Дополнительные указания
        проектно- сметной доку- ментации эксплуа- тационной докумен- тации  
ЭП Ведомость эскизного проекта ЭП* ОР
  Пояснительная записка к эскизному проекту П1 ОР
ЭП Схема организационной структуры СО ОР Допускается включать в документ ПЗ или ПВ
ТП Структурная схема комплекса технических средств С1* ТО Х Допускается включать в документ П9
  Схема функциональной структуры С2* ОР При разработке документов С0, С1, С2, С3 на стадии ЭП допускается их включение в документ П1
  Перечень заданий на разработку специализированных (новых) технических средств В9 ТО Х При разработке на стадии ТП допускается включать в документ П2
  Схема автоматизации С3* ТО Х
  Технические задания на разработку специализированных (новых) технических средств ТО В состав проекта не входят
ТП Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, подготовительные работы, связанные с созданием системы ТО Х В состав проекта не входят
  Ведомость технического проекта ТП* ОР
  Ведомость покупных изделий ВП* ОР  
  Перечень входных данных В1 ИО
  Перечень выходных данных В2 ИО
  Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы В3 ТО Х Допускается включать в документ П2
  Пояснительная записка к техническому проекту П2 ОР Включает план мероприятий по подготовке объекта к вводу системы в эксплуатацию
  Описание автоматизируемых функций П3 ОР
  Описание постановки задач (комплекса задач) П4 ОР Допускается включать в документы П2 или П3
  Описание информационного обеспечения системы П5 ИО
ТП Описание организации информационной базы П6 ИО
  Описание систем классификации и кодирования П7 ИО
  Описание массива информации П8 ИО
  Описание комплекса технических средств П9 ТО Для задачи допускается включать в документ П6 по ГОСТ 19.101
  Описание программного обеспечения ПА ПО
  Описание алгоритма (проектной процедуры) ПБ МО Допускается включать в документы П2, П3 или П4
  Описание организационной структуры ПВ ОО
  План расположения С8 ТО Х Допускается включать в документ П9
  Ведомость оборудования и материалов ТО Х
  Локальный сметный расчет Б2 ОР Х
ТП, РД Проектная оценка надежности системы Б1 ОР
  Шаблон документа С9 ИО Х На стадии ТП допускается включать в документы П4 или П5
РД Ведомость держателей подлинников ДП* ОР
  Ведомость эксплуатационных документов ЭД* ОР Х
  Спецификация оборудования В4 ТО Х
  Ведомость потребности в материалах В5 ТО Х
  Описание информационного массива В6 ИО Х
  Описание базы данных В7 ИО Х
  Локальная смета Б3 ОР Х
  Методика (технология) автоматизированного проектирования И1 ОО Х
  Технологическая инструкция И2 ОО Х
  Руководство пользователя И3 ОО Х
РД Инструкция по эксплуатации комплекса технических средств ИЭ ТО Х
  Схема соединения внешних проводок С4* ТО Х Допускается выполнять в виде таблиц
  Схема подключения внешних проводок С5* ТО Х То же
  Таблица соединений и подключений С6 ТО Х
  Схема деления системы (структурная) Е1* ТО
  Чертеж общего вида ВО* ТО Х
  Чертеж установки технических средств СА ТО Х
  Схема принципиальная СБ ТО Х
  Схема структурная комплекса технических средств С1* ТО Х
  План расположения оборудования и проводок С7 ТО Х
  Описание технологического процесса обработки данных (включая телеобработку) ПГ ОО Х
  Общее описание системы ПД ОР Х
  Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем) ПМ* ОР
  Формуляр ФО* ОР Х
  Паспорт ПС* ОР Х

* Документы, код которых установлен в соответствии с требованиями стандартов Единой системы конструкторской документации (ЕСКД).

Примечания

1 В таблице приняты следующие обозначения: ЭП — эскизный проект; ТП — технический проект; РД — рабочая документация; ОР — общесистемные решения; ОО — решения по организационному обеспечению; ТО — решения по техническому обеспечению; ИО — решения по информационному обеспечению; ПО — решения по программному обеспечению; МО — решения по математическому обеспечению.

2 Знак «Х» означает принадлежность к проектно-сметной или эксплуатационной документации.

3 Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

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

В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:

  • разрабатывать групповые и базовые документы в соответствии с разделами 1, 3, 4, 6 ГОСТ 2.113— 75;
  • выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
  • расширять номенклатуру документов, установленную настоящим стандартом.

При изготовлении несерийных компонентов комплексов средств автоматизации и на стадии «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:

  • акт завершения работ;
  • акт приемки в опытную эксплуатацию;
  • акт приемки в промышленную эксплуатацию;
  • план-график работ;
  • приказ о составе приемочной комиссии;
  • приказ о проведении работ;
  • программа работ;
  • протокол испытаний;
  • протокол согласования.

4 Комплектность документации

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

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

4.2 На каждый комплект должна быть составлена ведомость документов.

4.3 Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, — по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства — по ГОСТ 2.601.

4.4 Комплектность документации на программные средства вычислительной техники — по ГОСТ 19.101.

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

5 Обозначения документов

5.1 Каждому разработанному документу должно быть присвоено самостоятельное обозначение. Документ, выполненный на разных носителях данных, должен иметь одно обозначение. К обозначению документов, выполненных на машинных носителях, добавляют букву «М».

Заимствованным документам сохраняют ранее присвоенные обозначения.

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

5.3 Обозначение документа имеет следующую структуру, показанную на рисунке 1.

5.3.1 Правила обозначения системы (части системы) приведены в приложении А.

5.3.2 Код документа состоит из двух буквенно-цифровых знаков. Код для документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 таблицы 2. Код дополнительных документов формируют следующим образом: первый знак — буква, означающая вид документа согласно таблице 1, второй знак — цифра или буква, указывающая порядковый номер документа данного вида.

Код документа отделяют от предыдущего обозначения точкой.

Рисунок 1. Структура обозначения документа.

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

5.3.4 Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

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

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

Приложение А (рекомендуемое). Правила обозначения систем и их чертежей

А.1 Структура обозначения автоматизированной системы или ее части имеет вид, показанный на рисунке А.1.

Рисунок А.1. Структура обозначения АС

А.2 Код организации-разработчика представляет собой основной государственный регистрационный номер (ОГРН) из Единого государственного реестра юридических лиц (ЕГРЮЛ).

А.З Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли.

А.4 Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведение картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

Скачать документ в формате .doc вы можете здесь.

Технологическая инструкция – технологический документ Единой системы конструкторской документации

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

Если Технические условия состоят из набора требований к сырью, материалам, технологическим процессам, процессам контроля производства, полуфабрикатов и готовой продукции, то Технологическая инструкция являет собой описание самого процесса: одной или нескольких операций. Регламентируется составление, разработка и оформление ТИ стандартами серии ГОСТ 34, разработанными в системе ЕСКД.

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

Согласно РД 50-34.698-90, устанавливающему требования к разработке Тех. инструкций, они должны содержать для каждой операции:

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

Описание самого порядка действий должно соответствовать технологической последовательности и требованиям ГОСТ 3.1129 и ГОСТ 3.1130. При надобности в ТИ указываются последовательность корректирующих действий и методы проверки результатов операции. Технологическая инструкция по производству для наглядности часто включает в себя чертежи и иллюстрации.

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

В общем случае ТИ по производству может включать в себя следующие разделы:

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

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

Типовые технологические инструкции

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

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

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

Например, в пищевой отрасли существует ГОСТ Р 53105-2008, который устанавливает требования к технологической документации: к технологической карте, инструкции, к технико-технологической карте (разрабатывается на нетрадиционную продукцию). Разработан данный стандарт Всероссийским научно-исследовательским институтом сертификации, утвержден Федеральным агентством по тех. регулированию и метрологии. И действует на территории РФ с 1 января 2010 года. В данном документе учтены принципы стандартизации, установленные ФЗ № 184 «О техническом регулировании».

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

  • обязательность указания области применения документа. Здесь должны быть указаны виды продукции (ассортимент продукции) и перечень предприятий или филиалов, которым предоставлено право изготовления, транспортировки или сбыта видов продукции, перечисленных в ТИ;
  • обязательность установления требований к сырью и к пищевым полуфабрикатам, применяемым для изготовления продукции. Обязательно указываются нормативные или технические документы на сырье, а также документы, подтверждающие их безопасность и качество в соответствии с законодательством Российской Федерации;
  • обязательность установления требований к рецептуре для каждого блюда и изделия, установление норм расхода сырья и пищевых продуктов (с учетом потерь при кулинарной обработке). Данные показатели устанавливаются предприятием-изготовителем на основании актов проработки экспериментальным способом;
  • подробное описание технологического процесса, включающего последовательность технологических операций с используемым технологическим оборудованием и с параметрами технологических режимов (продолжительность операции, температура, влажность и т.д.). К технологическим процессам стандарт относит также  правила внутрицеховой транспортировки, приемки,  хранения сырья и продуктов, их подготовку к технологическому процессу;
  • обязательность установления требований и порядка санитарной обработки оборудования, помещений и прочих объектов, используемых в технологической операции;
  • обязательность установления требований к организации контроля качества и безопасности продукции на каждом этапе технологической операции и прочие требования.

Отправьте заявку

Время на прочтение
12 мин

Количество просмотров 457K

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

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

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

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов

Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:

  • приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
  • структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
  • пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
  • Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
  • Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
  • администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

Соответственно, в стандарте есть артефакты, наподобие следующего:

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

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

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

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо

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

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

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

Можно смеяться над тем, что создатели стандартов ничего не знали о java или .NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

Как читать и понимать стандарты документации по ГОСТ серии 34

Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

  • Эскизный проект (ЭП)
  • Технический проект (ТП)
  • Разработка рабочей документации (РД)

Эскизный проект следует после стадии Техническое задание и служит для разработки предварительных проектных решений.

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

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

Части (разделы) проектной документации по созданию АСУ

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

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

Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

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

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

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

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

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

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

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя. Комментарии излишни, я думаю.

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

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

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

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

как

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

какие

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

не ставим

. Мы эти бизнес-процессы

автоматизируем

.

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

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

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

А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

Варианты использования ГОСТ 34

  1. Полное и точное следование стандарту. Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
  2. Мы просто любим ГОСТы. В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
  3. Нам плевать на документацию, лишь бы все работало. Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями — директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

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

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

Понравилась статья? Поделить с друзьями:
  • Академия штиглица руководство
  • Оксанол агро ж инструкция по применению
  • Сделать букет из мягких игрушек своими руками пошаговая инструкция
  • Аленталь таблетки инструкция по применению цена 100 мг
  • Инструкция работы на кассовом аппарате в магазине