8-900-374-94-44
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)
ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.
Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.
5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.
Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.
«Видеокадр» — это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.
Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.
Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.
А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.
Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.
Можно смеяться над тем, что создатели стандартов ничего не знали о java или .NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.
Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.
Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.
Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.
Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):
Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?
Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.
Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.
Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?
Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.
Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.
В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.
Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.
Организационное обеспечение (ОО). Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.
На стадии ТП раздел содержит всего один документ «Описание организационной структуры», в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.
На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.
Руководство пользователя. Комментарии излишни, я думаю.
Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.
Технологическая инструкция. В связи с модой на формализацию бизнес процессов, в этот документ ушлый заказчик иногда стремится запихнуть регламенты работы службы эксплуатации. Так вот, делать этого ни в коем случае не нужно.
Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы — все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.
Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим. Мы эти бизнес-процессы автоматизируем.
Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».
Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.
Общесистемные решения (ОР). Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала — менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.
Варианты использования ГОСТ 34
Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).
ГОСТ 19.201-78
Группа Т55
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Единая система программной документации
ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
Unified system for program documentation. Technical specification for development. Requirements for contents and form of pressentation
МКС 35.080
Дата введения 1980-01-01
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80
ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81).
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79*.
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. — Примечание изготовителя базы данных.
(Измененная редакция, Изм. N 1).
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
(Измененная редакция, Изм. N 1).
2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
2.2. В разделе «Основание для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
2.1, 2.2 (Измененная редакция, Изм. N 1).
2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
(Измененная редакция, Изм. N 1).
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.
2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
2.4.5 В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
(Измененная редакция, Изм. N 1).
2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5а. В разделе «Требования к программной документации» должны быть указаны предварительный состав программной документации и, при необходимости, специальные требования к ней.
(Введен дополнительно, Изм. N 1).
2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.
2.8. В приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. —
М.: Стандартинформ, 2010
Доброе время суток!
Решил создать новый подраздел с примерами конкретных технических решений систем видеонаблюдения с учётом всех нюансов с питанием и заземлением. Примеры будут из жизни, но, естественно, без указания названий и координат объектов. Ну и, чтобы не тянуть кота за хвост, — Пример №1:
Исходные данные.
Имеем длиннючий супермаркет, порядка 130м в длину, к которому добавилась некая пристройка со своей локальной охранной сигнализацией (ОС). В супермаркете имеется действующая аналоговая система видеонаблюдения и охранная сигнализация. Есть еще и пожарная естественно, но в данном случае она нас не интересует. Системы ОС в супермаркете и пристройке совместимы — обе на базе приборов системы «Орион» производства фирмы «Болид» (Королёв) — безусловного российского лидера в системах сигнализации. На одном из видеорегистраторов (самом удалённом — в полном соответствии с законом бутера) имеется несколько свободных видеовходов. Вот максимально упрощённая схема здания:
Задача:
— соединить приборы охраны, находящиеся в пристройке, с приборами, стоящими в помещении поста охраны супермаркета, для создания единой системы охраны;
— разместить в пристройке 3 видеокамеры и вывести сигналы от них на удалённый видеорегистратор;
— добавить в торговом зале супермаркета одну камеру и так же вывести сигнал от неё на видеорегистратор.
Путём титанических напряжений мозговой извилины родилось решение использовать для передачи видеосигнала от камер и данных от приборов охраны (интерфейс RS-485) кабель FTP 4х2 — 4 витых пары в общем экране в уличном исполнении. Дело в том, что потолки этого супермаркета крайне сложны для прокладки кабеля и тащить 100 с лишним метров за потолками- это лучше сразу залезть в микроволновку и самоубиться, как тот кот у Рафшана и Джумшуда.
Здесь надо заметить, что злейшим врагом инженера систем безопасности является дизайнер, интерьерный или ландшафтный — без разницы. Для нас, технарей, идеальный ландшафт — это голое бетонное поле с полосой отчуждения, регулярно встречающимися пулемётными точками, прожекторами, овчарками по периметру и табличками «стой, запретная зона». То же самое, с некоторыми поправками, можно сказать об идеальном интерьере. Но само существование этих ботаников подразумевает наличие густой растительности в самых опасных местах периметра, всяческие неровности и альпийские горки на просматриваемой территории, дурацкие многоуровневые гипсовые потолки, где невозможно протянуть кабель, и прочие громоздкие гадости, которые не только мешают работе, но ещё постоянно норовят обрушиться и похоронить все плоды трудов. Отдельно большое человеческое мерси хочется сказать рекламщикам. Они вешают свои баннеры и всяческие осветительные прожектора перед «мордой лица» телекамер, полностью закрывая обзор или ослепляя, с такой дивной изобретательностью, что просто диву даёшься. В конце концов — можно не любить. но за что же так ненавидеть?
В общем, кабель между пристройкой, постом охраны и удалённым регистратором протянули над крышей по тросу, т.к. чердака у здания нет. Отсюда и кабель в исполнении для уличной прокладки и экран: заземлённый экран значительно снижает вероятность выгорания оборудования от грозовых разрядов (здесь на сайте есть более подробная статья о грозозащите). Согласование 75-омного выходного сопротивления телекамер с волновым сопротивлением витой пары выполнено с помощью пассивных приёмопредатчиков видеосигнала по витой паре (или балунов — balun от слов balanced/unbalanced, по нашему симметричный/несимметричный). Вот так вот оно выглядит:
Пассивные были выбраны, т.к максимальная длина линии невысока — порядка 150м-170м с учётом всяких переходов с этажа на этаж, петель запаса и т.д. Стоимость пары таких балунчиков — рублёв 300-500, кушать ввиду пассивности не просят, монтаж — проще некуда, габариты мизерные, короче — сплошное удовольствие.
Немножко о передаче видеосигнала по витой паре. Я упоминал этот метод в подразделе об интерфейсах видеокамер. Чуть подробнее. Вся прелесть этого способа передачи видеосигнала заключается в симметричности линии передачи. Коаксиальный кабель несимметричен по определению — он состоит из тонкого центрального проводника, закрытого снаружи оплёткой гораздо большей площади, которая выполняет роль второго проводника. Естественно, что внешнее электромагнитное поле наведёт гораздо более сильную помеху на оплётку, чем на центральный проводник. Отсюда между проводниками возникает разность потенциалов т.н. синфазной помехи, накладывающейся на видеосигнал и вызывающей сильные искажения изображения. Так при параллельном пробеге коаксиала с силовыми кабелями наводки могут привести к полному срыву синхронизации и пропаданию изображения.
Витая же пара, выполненная промышленным способом, представляет из себя два проводника, свитых между собой, с постоянным шагом, практически одинаковых геометрически. Соответственно, внешнее электромагнитное поле наведёт одинаковую помеху на оба проводника, т.е. разность потенциалов синфазной помехи на проводниках будет стремиться к нулю, и, как следствие, соотношение сигнал/шум будет гораздо выше. Отсюда и повышенная дальность передачи сигнала и очень высокая устойчивость к наводкам от всяческой «силовухи.» Честно говоря, не знаю, почему аналоговое видеонаблюдение так цеплялось за свои коаксиалы, пока не появилось IP-видео. Информационщики тоже раньше гоняли Ethernet по коаксиалу да быстро перешли на витуху, оттуда и выигрыш по скоростям и технологичности.
Схема соединений получилась следующей:
Схема, в целях компактности, топографически не совпадает с приведённым выше планом, так что напрягаем извилину.
Суть нарисованного следующая. От помещения поста охраны исходит три отрезка кабеля:
— в пристройку,
— к камере в здании супермаркета,
— к удалённому регистратору.
От пристройки приходят сигналы:
— по синей, оранжевой и зелёной парам — видеосигналы от трёх телекамер,
— по коричневой паре — данные по интерфейсу RS-485 для объединения в одну систему оборудования охранной сигнализации, расположенного в щитах ОПС пристройки и основного здания супермаркета,
— свободные от видеосигнала отрезки этих же пар используются для подачи к телекамерам питания 12В от источника, расположенного в шкафу ОПС пристройки (см. схему)
Отрезок кабеля, идущий в сторону камеры расположенной в торговом зале основного здания используется для подачи на камеру питания (зелёная пара) от центрального щита ОПС и передачи от камеры видеосигнала (коричневая пара).
Сигналы интерфейса RS-485 благополучно коммутируются в центральный щит ОПС. А все 4 полученных видеосигнала по третьему отрезку кабеля передаются на удалённый регистратор.
Можно добавить, что схема упрощена. Например 485-й интерфейс подключен через приборы С2000-ПИ (преобразователь интерфейса), использующиеся здесь как буферы с гальванической развязкой. Не стал загромождать рисунок обозначениями экранированного кабеля — и так написано, что витуха с экраном.
В общем, схема проста до неприличия (так и подмывает написать «как и всё гениальное»). Из хитростей наверное можно упомянуть только заземление.Все удалённые источники питания заземлены только по высокой стороне (со стороны 220В). Низковольтная часть и, соответственно, сигнальный общий видеокамер соединены с землёй только через видеорегистратор. О заземлении телекамер я писал уже отдельную статью.
Там же кстати заземлён и экранный контактный проводничок. Это делать крайне желательно при уличной прокладке кабеля для защиты от грозовых разрядов. При прокладке внутри помещений я особого эффекта от подобных экранов не замечал.
Ну вот, в общем и всё. Особо нового здесь ничего не открыто. Достигнуто некоторое снижение стоимости за счет передачи 4-х видеосигналов по одному кабелю, сравнимому по стоимости с приличным коаксиалом. Вот только коаксиалов понадобилось бы 4 шт.
Помехоустойчивость витой пары здесь себя особо не проявила, т.к. кабель протянут по крыше, вдали от мощных источников наводок.
Так что позвольте откланяться до следующего припадка вдохновения.
Вопросы — в комментарии, подписывайтесь — форма внизу.
В общем, до связи.
На главную, к оглавлению, в начало
ГОСТ 15.005-86
Группа Т52
СОЗДАНИЕ ИЗДЕЛИЙ ЕДИНИЧНОГО И МЕЛКОСЕРИЙНОГО ПРОИЗВОДСТВА, СОБИРАЕМЫХ НА МЕСТЕ ЭКСПЛУАТАЦИИ
System of products development and launching into manufacture. Development of single and small-scale production units assembled at the place of use
МКС 01.110
ОКСТУ 0015
Дата введения 1987-01-01
1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам
РАЗРАБОТЧИКИ
А.Л.Теркель, канд. техн. наук; О.В.Яременко, канд. техн. наук; Ю.А.Кияшев; Г.П.Бассейн; В.Г.Цыкаленко; В.Б.Яров; Б.М.Бейлинсон; Н.Д.Маркозов; М.С.Сахаров; Б.И.Калиненок, канд. техн. наук; И.Т.Ямалутдинов; Л.П.Белоусова; М.К.Комаровская
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 15.10.86 N 3095
Изменение N 4 Принято Межгосударственным советом по стандартизации, метрологии и сертификации (протокол N 49 от 15.03.2012)
За принятие изменения проголосовали национальные органы по стандартизации следующих государств: BY, KZ, KG, RU, UA
Дату введения в действие настоящего изменения устанавливают указанные национальные органы по стандартизации*
________________
* Дата введения в действие на территории Российской Федерации — 2012-09-01.
3. ВВЕДЕН ВПЕРВЫЕ
4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
Обозначение НТД, на который дана ссылка | Номер пункта | |||
ГОСТ 15.012-84 | 1.7 | |||
5. Ограничение срока действия снято Постановлением Госстандарта СССР от 17.07.89 N 2390
6. ИЗДАНИЕ (январь 2013 г.) с Изменениями N 1, 2, 3, 4, утвержденными в апреле 1987 г., январе 1988 г., апреле 1989 г., марте 2012 г. (ИУС 7-87, 4-88, 7-89, 11-2012)
Настоящий стандарт устанавливает порядок разработки, согласования и утверждения технического задания, технической документации, а также порядок изготовления, контроля, монтажа, приемки и сдачи в эксплуатацию изделий единичного и мелкосерийного производства и их составных частей, контрольная сборка, доизготовление, окончательная сборка, наладка, испытания и доводка которых могут быть проведены только на месте эксплуатации в составе конкретного производственного объекта.
Стандарт не распространяется на указанные изделия, разрабатываемые по заказам Министерства обороны РФ*.
________________
* Для Российской Федерации.
Положения настоящего стандарта обеспечиваются заказчиком (основным потребителем), разработчиком и изготовителем при создании и освоении продукции.
Термины, применяемые в стандарте, и пояснения к ним приведены в приложении 1.
(Измененная редакция, Изм. N 3, 4).
1.1. Изделия единичного и мелкосерийного производства, собираемые на месте эксплуатации (далее — изделия), подлежащие разработке, на момент сдачи в эксплуатации должны удовлетворять требованиям технических регламентов, межгосударственных, национальных стандартов, сводов правил, обеспечивать эффективное функционирование объекта или выполнение технологического процесса, для которого они предназначены.
Требования к техническому уровню продукции устанавливают с учетом требований, предусмотренных в законодательных и иных нормативных актах.
(Измененная редакция, Изм. N 4).
1.2. Создание изделий осуществляется на основе договоров между заказчиком, разработчиком, изготовителем, а также другими организациями, привлекаемыми ими к выполнению отдельных работ.
Разработка продукции может выполняться по конкурсу в соответствии с положением о нем. Результаты разработки как вид научно-технической продукции передаются заказчику или, по его указанию, изготовителю для производства промышленной продукции.
(Измененная редакция, Изм. N 2, 3).
1.3. Исходным документом для создания изделий является техническое задание или другой документ (контракт, протокол и т.п.), содержащий необходимые и достаточные требования для разработки и признанный заказчиком и разработчиком (далее под техническим заданием следует также понимать документ, заменяющий его).
1.4. Оценка технического уровня изделия проводится на этапе рассмотрения технического проекта (при его отсутствии — рабочей документации) с участием заинтересованных организаций. Результаты оценки являются основанием для отнесения изделия к соответствующей категории качества.
1.3, 1.4. (Измененная редакция, Изм. N 3).
1.5. Карту технического уровня и качества продукции как самостоятельный документ не оформляют, а необходимые сведения о сравнении показателей с аналогами включают в техническое задание.
1.6. Изготовление, приемку и поставку этого изделия (партии) осуществляют в соответствии с техническим заданием.
В случае продолжения производства данных изделий разрабатывают технические условия, которые согласовывают, утверждают и регистрируют в соответствии с НТД.
По согласованию с заказчиком при повторении индивидуального заказа допускается технические условия не составлять, а изготовление, приемку и поставку изделия (партии) осуществлять по ранее разработанному ТЗ.
(Измененная редакция, Изм. N 3, 4).
1.7. Патентный формуляр по ГОСТ 15.012 составляют по согласованию заказчика и изготовителя.
1.8. Решение по разногласиям, возникающим на всех этапах создания изделий, регулируются в претензионном или судебном порядке и руководствуются Гражданским кодексом и иными нормами законодательства стран СНГ.
1.6-1.8. (Измененная редакция, Изм. N 4).
1.9. (Исключен, Изм. N 3).
2.1. Техническое задание (ТЗ) разрабатывают и утверждают совместно заказчик и разработчик, изготовители, организация, осуществляющая сборку, если иной порядок не установлен этими сторонами по договоренности.
В процессе разработки ТЗ для получения исходной информации при необходимости привлекают разработчика (заказчика), изготовителя, головного проектировщика, организацию, производящую сборку и монтаж.
ТЗ на технологический комплекс, поставляемый комплектно потребителю согласно перечню, разрабатывают совместно с организацией, осуществляющей сборку и/или монтаж.
(Измененная редакция, Изм. N 2, 3, 4).
2.2. В ТЗ в общем случае устанавливают технические и экономические требования к изделию, в том числе уровню заводской готовности и монтажной технологичности, требования к разработке, изготовлению и приемочному контролю, включая объем заводской контрольной сборки и испытаний, требования к комплектности поставки, а также требования к строительной части, наладке, испытаниям на объекте, приемке, техническому обслуживанию и ремонту.
В ТЗ должны быть указаны ориентировочные сроки разработки, изготовления, контрольной сборки, сборки, монтажа на месте эксплуатации, монтажа и сдачи изделия в эксплуатацию.
Не допускается включать в ТЗ требования, которые противоречат требованиям стандартов и нормативных документов органов, осуществляющих надзор за безопасностью, охраной здоровья и природы.
При наличии у заказчика индивидуальных требований к разрабатываемой продукции, которые отличаются от требований стандартов, но не снижают эффективности применения продукции в оговоренных условиях, следует составлять специальные технические условия, согласованные в Главгосэкспертизе России*.
________________
* Для Российской Федерации.
(Измененная редакция, Изм. N 1, 3, 4).
2.2.1. (Исключен, Изм. N 3).
2.3. Необходимость согласования ТЗ с заинтересованными организациями определяет разработчик совместно с заказчиком.
(Измененная редакция, Изм. N 1, 3, 4).
2.4, 2.5. (Исключены, Изм. N 3).
2.6. При необходимости изменения ТЗ оно осуществляется на любом этапе создания изделия оформлением протокола, подписанного заказчиком, разработчиком и изготовителем. Указанный протокол является неотъемлемой частью ТЗ. На титульном листе ТЗ должна быть запись «Действует совместно с протоколом N … от …».
2.7. Действие ТЗ распространяется на все этапы создания изделия (партии), включая сдачу его в эксплуатацию и достижение проектных значений показателей.
2.8. (Исключен, Изм. N 3).
2.9. Для разработки комплектующих изделий головной разработчик выдает ТЗ разработчику комплектующих изделий.
Допускается разработка комплектующих изделий по ТЗ, составленному разработчиком комплектующего изделия на основании выданной головным разработчиком заявки с исходными требованиями.
(Измененная редакция, Изм. N 2, 3).
3.1. Стадии разработки проектно-конструкторской документации устанавливают в ТЗ.
Обязательными стадиями разработки конструкторской документации являются технический проект и рабочая документация. По согласованию с заказчиком допускается разрабатывать только рабочую документацию.
(Измененная редакция, Изм. N 4).
3.2. Необходимость и порядок разработки технического предложения и эскизного проекта определяет головной разработчик.
3.3. Рассмотрение технического проекта, которое, как правило, организует головной разработчик, должно проводиться со всеми участниками создания продукции. Необходимость участия в данном рассмотрении других заинтересованных организаций определяет головной разработчик.
На рассмотрение представляют техническое задание и комплект документов технического проекта.
При создании объектов необходимо учитывать нормы Градостроительного кодекса РФ* в части государственной экспертизы проекта, строительного надзора и ввода в эксплуатацию, а также требования по энергоэффективности.
________________
* Для Российской Федерации.
Если разработка технического проекта не предусмотрена, рассматривают документы, входящие в комплект рабочей документации, по которым можно судить об изделии в целом и его основных составных частях.
(Измененная редакция, Изм. N 4).
3.4. По результатам экспертизы принимают решение об утверждении технического проекта или его доработке, а также соответствии изделия мировому уровню.
Утвержденный технический проект, прошедший государственную экспертизу, является основанием для разработки рабочей документации и изготовления по ней изделий и его составных частей, а также разрешением для включения изделий в технологическую часть проекта на строительство (реконструкцию) промышленного объекта и (или) технологического процесса.
(Измененная редакция, Изм. N 3, 4).
3.5. Рабочую конструкторскую документацию разрабатывает разработчик с участием изготовителя и утверждает разработчик, если иное не предусмотрено условиями договора между заказчиком и разработчиком. По мере готовности рабочая документация передается изготовителю в порядке, определенном разработчиком и согласованном с изготовителем.
Если в создании составных частей участвуют несколько разработчиков и (или) изготовителей, то утверждение и передача изготовителям рабочей документации на эти составные части осуществляется без участия головного разработчика.
(Измененная редакция, Изм. N 4).
3.6. (Исключен, Изм. N 4).
3.7. Программу и методику испытаний изделий разрабатывает и утверждает разработчик по согласованию с заказчиком и изготовителем.
При необходимости, определяемой головным разработчиком и указанной в ТЗ, разработчики составных частей разрабатывают, согласовывают с головным разработчиком и изготовителями и утверждают программы и методики испытаний составных частей.
(Измененная редакция, Изм. N 4).
4.1. Подготовку производства и изготовление составных частей их изготовители осуществляют до разработки полного комплекта конструкторской документации по мере получения от разработчика необходимой документации.
4.2. Каждая составная часть должна подвергаться у изготовителя приемо-сдаточным испытаниям (приемочному контролю), которые проводит служба технического контроля изготовителя, как правило, в испытаниях участвуют представители заказчика и органов, осуществляющих надзор за безопасностью, охраной здоровья и природы.
(Измененная редакция, Изм. N 3, 4).
4.3. Положительные результаты приемочного контроля (приемо-сдаточных испытаний) являются основанием для отгрузки изделия (составной части) заказчику или генеральному поставщику.
4.4. Сборку составных частей или изделия на месте эксплуатации проводит изготовитель, если иное не установлено договором.
Монтаж и наладку изделий на месте эксплуатации проводит организация, указанная в договоре, заключенном между заинтересованными организациями и предприятиями, с привлечением в необходимых случаях специализированных монтажных организаций.
Приемочные испытания изделий на месте эксплуатации проводит заказчик совместно с разработчиком и изготовителями.
Доводку изделия проводят изготовители с участием разработчика и заказчика.
(Измененная редакция, Изм. N 2, 3, 4).
4.5. Приемочную комиссию утверждают заказчик.
В состав комиссии включают представителей заказчика (председатель комиссии), разработчика, изготовителя, проектной организации, монтажной, наладочной и ремонтной организаций (при их наличии), а также в зависимости от назначения изделия представителей органов государственного надзора и (или) технической инспекции ЦК профсоюзов.
(Измененная редакция, Изм. N 3, 4).
4.6. До начала испытаний приемочная комиссия определяет степень завершенности монтажных и пусконаладочных работ, рассматривает программу и методику испытаний, оценивает возможность воспроизведения заданных режимов испытаний и в случае необходимости вносит изменения в программу и методику испытаний.
4.7. Приемочные испытания изделий проводят для определения фактических значений показателей и подготовки рекомендаций по совершенствованию изделия и правильной его эксплуатации.
4.8. При изготовлении партии испытаниям подвергают головной образец (головные образцы). По результатам испытаний головного образца (головных образцов) в соответствии с рекомендациями приемочной комиссии доводят остальные экземпляры изделия (если они запущены в производство) с соответствующей корректировкой технической документации.
4.9. По результатам приемочных испытаний приемочная комиссия устанавливает соответствие изделия требованиям ТЗ и, в случае необходимости, дает рекомендации по доработке, а также по выводу изделия на проектную мощность (в случае, если изделие по объективным причинам не может быть выведено на проектную мощность в процессе приемочных испытаний).
4.10. На основе рассмотрения представленных документов и результатов испытаний комиссия составляет акт приемки изделия, который утверждает председатель комиссии.
(Измененная редакция, Изм. N 3).
4.11. Утвержденный акт приемки изделия является основанием дли передачи изделия в промышленную эксплуатацию при наличии заключения органов государственного надзора для мелкосерийных изделий, кроме того — для продолжения производства.
(Измененная редакция, Изм. N 3, 4).
4.12. Изделия партии, кроме головных образцов, подвергают приемо-сдаточным испытаниям в порядке, установленном заказчиком по согласованию с изготовителем.
ПРИЛОЖЕНИЕ 1
Справочное
Термин | Пояснение |
1. Создание изделий | Процесс разработки, изготовления, контроля, сборки, монтажа, наладки и приемки в эксплуатацию первого экземпляра изделия (партии) |
2. Головной образец | Первый экземпляр изделия, изготовленный по вновь разработанной документации для применения заказчиком с одновременной отработкой конструкции и технической документации для производства и эксплуатации остальных экземпляров изделия |
Головных образцов при создании конкретного изделия может быть несколько |
ПРИЛОЖЕНИЕ 1. (Измененная редакция, Изм. N 4).
ПРИЛОЖЕНИЕ 2
Рекомендуемое
Содержание информации | Исполнители |
1. Общие сведения о разработке (основание, область применения, цель, назначение, объем партии, сроки изготовления, сборки, монтажа и сдачи в эксплуатацию) | Заказчик |
2. Сведения о мировом уровне данного вида продукции (в том числе результаты патентных исследований) | Разработчик |
3. Технические требования | Заказчик, разработчик |
4. Экономические требования (эффективность, лимитная цена и т.д.) | Разработчик, заказчик и изготовители |
5. Требования к разработке (стадии и этапы, комплектность документации и порядок ее контроля и приемки и т.д.) | Разработчик |
6. Требования к изготовлению и приемочному контролю | Изготовители, монтажные организации |
7. Требования к поставке (очередность и сроки поставки) | Заказчик, разработчик, изготовители, монтажные организации |
8. Требования к строительной части | Разработчик, проектировщик |
9. Требования к монтажу | Разработчик, изготовители, монтажные организации |
10. Требования к испытаниям и приемке изделий | Разработчик, заказчик |
11. Требования к техническому обслуживанию и ремонту | Заказчик, разработчик, ремонтные предприятия |
12. Требования к контрольной сборке | Заказчик, разработчик, изготовители |
13. Требования к сборке составных частей и изделий | Заказчик, разработчик, изготовители |
Примечание. При наличии нескольких разработчиков сведения, требуемые от разработчика, сообщает головной разработчик, который при необходимости получает их от других разработчиков.
ПРИЛОЖЕНИЕ 2. (Измененная редакция, Изм. N 3, 4).
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
М.: Стандартинформ, 2013
ГОСТ 2.103-68
Группа Т52
____________________________________________________________________
Текст Сравнения ГОСТ 2.103-68 с ГОСТ 2.103-2013 см. по ссылке.
— Примечание изготовителя базы данных.
____________________________________________________________________
МКС 01.110
Дата введения 1971-01-01
Утвержден Комитетом стандартов, мер и измерительных приборов при Совете Министров СССР в декабре 1967 г. Дата введения установлена 1971-01-01
Изменение N 2 принято Межгосударственным советом по стандартизации, метрологии и сертификации по переписке (протокол N 23 от 28 февраля 2006 г.)
За принятие изменения проголосовали национальные органы по стандартизации следующих государств: AZ, AM, BY, KZ, KG, MD, RU, TJ, TM, UZ, UA [коды альфа-2 по МЭК (ИСО 3166) 004]
ИЗДАНИЕ (апрель 2011 г.) с Изменениями N 1, 2, утвержденными в июле 1981 г., июне 2006 г. (ИУС N 10-81, 9-2006)
ВНЕСЕНА поправка, опубликованная в ИУС N 2, 2012 год
Поправка внесена изготовителем базы данных
1. Настоящий стандарт устанавливает стадии разработки конструкторской документации изделий всех отраслей промышленности и этапы выполнения работ на каждой стадии разработки (см. таблицу).
Стадия разработки | Этапы выполнения работ |
Проектная конструкторская документация: | |
а) техническое предложение | Подбор материалов. |
Разработка технического предложения с присвоением документам литеры «П». | |
Рассмотрение и утверждение технического предложения. | |
б) эскизный проект | Разработка эскизного проекта с присвоением документам литеры «Э». |
Изготовление и испытание материальных макетов (при необходимости) и (или) разработка, анализ электронных макетов (при необходимости). | |
Рассмотрение и утверждение эскизного проекта. | |
в) технический проект | Разработка технического проекта с присвоением документам литеры «Т». |
Изготовление и испытание материальных макетов (при необходимости) и (или) разработка, анализ электронных макетов (при необходимости). | |
Рассмотрение и утверждение технического проекта. | |
Рабочая конструкторская документация: | Разработка конструкторской документации, предназначенной для изготовления и испытания опытного образца (опытной партии), без присвоения литеры. |
а) опытного образца (опытной партии) изделия, предназначенного для серийного (массового) или единичного производства (кроме разового изготовления) | Изготовление и предварительные испытания опытного образца (опытной партии). |
Приемочные испытания опытного образца (опытной партии). | |
Корректировка конструкторской документации по результатам приемочных испытаний опытного образца (опытной партии) с присвоением документам литеры » «. | |
Для изделия, разрабатываемого по заказу Министерства обороны, при необходимости, — повторное изготовление и испытания опытного образца (опытной партии) по документации с литерой «» и корректировка конструкторских документов с присвоением им литеры «». | |
б) серийного (массового) производства | Изготовление и испытание установочной серии по документации с литерой » » (или «»). |
Корректировка конструкторской документации по результатам изготовления и испытания установочной серии, а также оснащения технологического процесса изготовления изделия, с присвоением конструкторским документам литеры «А». | |
Для изделия, разрабатываемого по заказу Министерства обороны, при необходимости, — изготовление и испытание головной (контрольной) серии по документации с литерой «А» и соответствующая корректировка документов с присвоением им литеры «Б» |
Обязательность выполнения стадий разработки и этапов выполнения работ, форму представления конструкторской документации (бумажная или электронная) устанавливает разработчик, если это не предусмотрено техническим заданием на разработку.
Примечания:
1. Стадия «Техническое предложение» не распространяется на конструкторскую документацию изделий, разрабатываемых по заказу Министерства обороны.
2. Макет разрабатывается:
а) на стадии технического предложения с целью выявления и проверки вариантов основных конструктивных решений разрабатываемого изделия или его составных частей, анализа различных вариантов изделия, выявления дополнительных или уточненных требований к изделию;
б) на стадии эскизного проекта с целью проверки принципов работы изделия или его составных частей, условий размещения в отведенном пространстве, условий эргономичности использования и других свойств изделия или его составных частей;
в) на стадии технического проекта с целью проверки основных конструктивных решений разрабатываемого изделия или его составных частей по пространственно-кинематическому взаимодействию с другими изделиями и составных частей между собой, а также условий эргономичности;
г) на стадии рабочего проекта для предварительной проверки целесообразности изменения отдельных частей изготовляемого изделия до внесения этих изменений в рабочие конструкторские документы опытного образца (опытной партии).
Макеты могут выполняться в материальной форме (материальный макет) или электронной форме (электронный макет).
3. Необходимость разработки макетов, их вид, условия и программы испытаний (анализа), а также необходимость разработки документации для изготовления и испытания макетов устанавливает разработчик. Требования к материальному макету — по ГОСТ 2.002-72, к электронному макету — по ГОСТ 2.052-2006.
4. Под разовым изготовлением понимается единовременное изготовление одного или более экземпляров изделия, дальнейшее производство которого не предусматривается.
5. При выполнении конструкторской документации в электронной форме требования к форматам данных рекомендуется устанавливать на предшествующей стадии разработки, если это не предусмотрено техническим заданием.
(Измененная редакция, Изм. N 1, 2).
2. Рабочим конструкторским документам изделия единичного производства, предназначенным для разового изготовления, присваивают литеру «И» при их разработке, которой может предшествовать выполнение отдельных стадий разработки (техническое предложение, эскизный проект, технический проект) и соответственно этапов работ, указанных в таблице.
(Измененная редакция, Изм. N 1).
3. (Исключен, Изм. N 1).
4. Техническое предложение — совокупность конструкторских документов, которые должны содержать технические и технико-экономические обоснования целесообразности разработки документации изделия на основании анализа технического задания заказчика и различных вариантов возможных решений изделий, сравнительной оценки решений с учетом конструктивных и эксплуатационных особенностей разрабатываемого и существующих изделий и патентные исследования.
Техническое предложение после согласования и утверждения в установленном порядке является основанием для разработки эскизного (технического) проекта.
Перечень работ — по ГОСТ 2.118-73.
(Измененная редакция, Изм. N 1, 2).
5. Эскизный проект — совокупность конструкторских документов, которые должны содержать принципиальные конструктивные решения, дающие общее представление о назначении, об устройстве, принципе работы и габаритных размерах разрабатываемого изделия, а также данные, определяющие назначение, основные параметры и габаритные размеры разрабатываемого изделия.
Эскизный проект после согласования и утверждения в установленном порядке служит основанием для разработки технического проекта или рабочей конструкторской документации.
Перечень работ — по ГОСТ 2.119-73.
6. Технический проект — совокупность конструкторских документов, которые должны содержать окончательные технические решения, дающие полное представление об устройстве разрабатываемого изделия, и исходные данные для разработки рабочей документации.
Технический проект после согласования и утверждения в установленном порядке служит основанием для разработки рабочей конструкторской документации.
Перечень работ — по ГОСТ 2.120-73.
5, 6. (Измененная редакция, Изм. N 1).
7. Ранее разработанные конструкторские документы применяют при разработке новых или модернизации изготовляемых изделий в следующих случаях:
а) в проектной документации (техническом предложении, эскизном и техничесом проектах) и рабочей документации опытного образца (опытной партии) — независимо от литерности применяемых документов;
б) в конструкторской документации с литерами «» («»), «А» и «Б», если литерность применяемого документа та же или высшая.
Литерность полного комплекта конструкторской документации определяется низшей из литер, указанных в документах, входящих в комплект, кроме документов покупных изделий.
(Измененная редакция, Изм. N 1).
8. Конструкторские документы, держателями подлинников которых являются другие предприятия, могут применяться только при наличии учтенных копий или дубликатов.
Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
Единая система конструкторской документации.
Основные положения: Сб. ГОСТов. —
М.: Стандартинформ, 2011
Редакция документа с учетом
изменений и дополнений подготовлена
АО «Кодекс»
ГОСТ | Национальные Стандарты |
СНиП | Строительные нормы и правила |
ОСТ | Отраслевые стандарты |
GTN | Штат Технический осмотр |
ВНТП | Отраслевая норма по техническому проектированию |
MISC | Разные документы |
НПБ | Огонь Правила безопасности |
SN | Строительные коды |
СанПиН | Санитарные нормы и правила |
SP | Код практики |
RD | Нормативные документы |
KZ | Казахстанские нормативные документы |
VSN | Стандарты промышленного строительства |
ГГТН | Федеральная горно-промышленная инспекция России |
MPOT | Правила охраны труда и техники безопасности при эксплуатации электрооборудования Установки |
ЧУП | Стандарты эксплуатации электрооборудования |
PB | Правила безопасности |
RDS | Системные нормативные документы |
GN | Правила гигиены |
REG | Постановление Правительства РФ |
RCR | Российские таможенные правила |
RFS | Российская Финансовая Система |
GD | Постановление правительства |
MDS | Методические документы в строительстве |
РОССИЙСКИЙ ФЕДЕРАЛЬ МИНИСТЕРСТВА | |
РОССИЙСКИЙ ФЕДЕРАЛЬ АГЕНТСТВА | |
РОССИЙСКИЙ ФЕДЕРАЛЬ УСЛУГИ | |
ГОСТ | Национальные Стандарты |
СНиП | Строительные нормы и правила |
ОСТ | Отраслевые стандарты |
GTN | Штат Технический осмотр |
ВНТП | Отраслевая норма по техническому проектированию |
MISC | Разные документы |
НПБ | Огонь Правила безопасности |
SN | Строительные коды |
СанПиН | Санитарные нормы и правила |
SP | Код практики |
RD | Нормативные документы |
KZ | Казахстанские нормативные документы |
VSN | Стандарты промышленного строительства |
ГГТН | Федеральная горно-промышленная инспекция России |
MPOT | Правила охраны труда и техники безопасности при эксплуатации электрооборудования Установки |
ЧУП | Стандарты эксплуатации электрооборудования |
PB | Правила безопасности |
RDS | Системные нормативные документы |
GN | Правила гигиены |
REG | Постановление Правительства РФ |
RCR | Российские таможенные правила |
RFS | Российская Финансовая Система |
GD | Постановление правительства |
MDS | Методические документы в строительстве |
РОССИЙСКИЙ ФЕДЕРАЛЬ МИНИСТЕРСТВА | |
РОССИЙСКИЙ ФЕДЕРАЛЬ АГЕНТСТВА | |
РОССИЙСКИЙ ФЕДЕРАЛЬ УСЛУГИ | |