Инструкция по эксплуатации технических средств гост

Справка

Текст стандарта

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

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

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

Приложение 1 (Справочное) — Пояснения терминов, применяемых в настоящем стандарте

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

Полезные ссылки

Файлы

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

Компания Серконс оказывает услуги в сфере разработки руководства по эксплуатации

Зачем и для кого создается документ?

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

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

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

Особенности создания и оформления

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

Руководство может создаваться на подготовительном этапе, как на отдельный продукт, так и на группу однотипных моделей с едиными данными и правилами. Процесс его оформления не отличается от конструкторско-технической документации и регулируется положениями национальных стандартов ГOCТ 2.601-2013 и ГOCТ 2.105-95.

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

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

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

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

Требования к созданию руководства по эксплуатации

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

• ГОСТ 2.610-2013;
• ГОСТ 2.601-2013;
• ТР ТС 010/2011;
• ТР ТС 016/2011.

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

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

Кто разработчик?

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

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

Отправить заявку на разработку руководства по эксплуатации

Вас может заинтересовать

Среди наших клиентов

Требования ГОСТ на автоматизированные системы в ИБ-проектах. Что изменилось и как это применять?

Традиционно разработчики документации на автоматизированные системы при создании и обеспечении защиты этих систем применяли ГОСТы 34-й серии. С 2022 года наконец-то произошло обновление старых стандартов в рамках новой серии национальных и межгосударственных стандартов на автоматизированные системы (далее — ГОСТ на автоматизированные системы).

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

Состав ГОСТов на автоматизированные системы

С первой половины 2022 года вступили в действие новые стандарты (пункты 1–6) согласно Таблице 1.

Таблица 1 — Перечень действующих стандартов.

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

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

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

• ГОСТ 34.201–2020 (взамен ГОСТ 34.201–89), определяющий состав документов технического проекта;

• ГОСТ Р 59795–2021 (взамен руководящего документа РД 50–34.698–90), определяющий содержание каждого разрабатываемого документа технорабочей документации.

Основные изменения стандартов

Основополагающие в проектировании автоматизированных систем стандарты, разработанные еще в 1989–1992 годах, не подвергались пересмотру 30 лет и, естественно, утратили свою актуальность. Они уже не учитывали современных тенденций развития технологий. Например, с тех времен, когда документы отчерчивали на кульмане, в составе проектной документации было принято разрабатывать «Чертеж формы документа (видеокадра)», а для хранения данных в картотеках с полу автоматизированной обработкой формировался «Каталог базы данных». Был непонятен статус старых стандартов (ведь было принято переиздавать стандарты как минимум раз в 10 лет, но этого не происходило).

И вот, наконец-то стандарты пересмотрены, переизданы и введены в действие.

• Кардинально изменилась ситуация неопределенности требований к содержанию технорабочей документации, возникшая с момента отмены в 2019 году методических рекомендаций РД 50–34.698–90. Теперь требования к содержанию документации регламентированы ГОСТ Р 59795–2021.

• Стали более четкими формулировки ГОСТ 34.201–2020, введенного взамен ГОСТ 34.201–89 (который устанавливал наименование, комплектность и обозначение документов), теперь устанавливает требования к видам, наименованию, комплектности и обозначению документов. Таким образом, новые требования к наименованию и содержанию документов ГОСТ на автоматизированные системы перешли из разряда методических рекомендаций в разряд требований.

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

• Ведомость машинных носителей информации (ВМ);

• Состав выходных данных (сообщений) (В8), при этом оставлен документ «Перечень выходных сигналов (документов)» (В2);

• Инструкция по формированию и ведению базы данных (набора данных) (И4).

Остальные 55 документов, 4 из которых — с измененными формулировками (например, вместо «Чертеж формы документа (видеокадра)» — теперь «Шаблон документа», вместо «Каталог базы данных» — «Описание базы данных»), оставлены в перечне документов по ГОСТ 34.201–2020.

Состав работ по созданию систем

Основной стандарт, определяющий последовательность работ по созданию автоматизированных систем, — это ГОСТ Р 59793–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» (принят взамен ГОСТ 34.601–90). Данным стандартом определено 8 стадий создания автоматизированных систем, но, по сложившейся практике выполнения проектов, стадии объединяются, и работы выполняются в несколько этапов, перечисленных в Таблице 2.

Таблица 2 – Стадии работ по созданию системы.

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

• под «созданием системы» подразумеваются как проекты создания, так и проекты модернизации (доработки) системы;

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

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

Отдельных комментариев заслуживают стадии: 1. «Формирование требований к АС», 3. «Техническое задание», 4-6, объединенные в этап работ на практике 3) «Технорабочее проектирование». Разберем их подробнее.

Техническое задание

Может возникать путаница в обозначении того, что считается Техническим заданием (Частным техническим заданием):

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

• На стадии 3. «Техническое задание» разрабатывается Техническое задание на систему, которое является Техническим заданием по ГОСТ на автоматизированные системы.

На стадии 3. «Техническое задание» определяются требования к системе в целом. На основании требований о защите информации государственных информационных систем, значимых объектов критической информационной инфраструктуры, персональных данных, автоматизированных систем управления, утвержденные Постановлением Правительства Российской Федерации от 06.07.2015 №676 и приказами ФСТЭК от 11.02.2013 №17, от 25.12.2017 №239, от 18.02.2013 №21, от 14.03.2014 №31, одновременно с определением требований, определяются и меры защиты информации, применение которых необходимо для нейтрализации актуальных угроз, выявленных по результатам моделирования угроз безопасности информации. Меры защиты включаются в Техническое задание на систему и затем при необходимости могут уточняться в рамках проектирования.

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

На этапе работ «Технорабочее проектирование» разрабатываются два блока документации:

• Проектные решения (технический проект иногда называют «документацией на систему»). Данный блок описывает будущую систему в терминах принятых архитектурных и технических решений. Стадия эскизного проектирования — упрощенная версия технического проекта.

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

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

Практика применения требований ГОСТ на автоматизированные системы

Обязательность применения требований ГОСТ

В соответствии с Федеральным законом от 29.06.2015 №162-ФЗ «О стандартизации в Российской Федерации», добровольность применения документов по стандартизации — один из принципов стандартизации (статья 4).

ГОСТ становится обязательным,

• если это установлено Федеральным законом (в случае защиты государственной тайны или в отношении оборонной продукции (статья 6) — что не является общим случаем для применения ГОСТ на автоматизированные системы);

• если изготовитель/исполнитель принимает на себя требования (например, требования Технического задания) о применении национального/межгосударственного стандарта (статья 26 вышеуказанного 162-ФЗ).

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

• Технического задания на создание подсистемы безопасности;

• модели угроз безопасности информации;

• документации на систему (проектной документации);

• рабочей (эксплуатационной) документации.

В данных случаях необходимо руководствоваться требованиями ГОСТ на автоматизированные системы, даже если в современных трактовках вышеуказанных нормативных требований к разработке документации не употребляется прямая отсылка к ним, а, например, указываются цитаты из ГОСТ Р 59793–2021:

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

• рабочая документация должна содержать «все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) АС в соответствии с принятыми проектными решениями».

Так, например, на необходимость учета требований ГОСТ на автоматизированные системы при создании систем указывает действующая нормативная база, в частности:

• ГОСТ Р 51583–2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения»;

• Приказ ФСТЭК России от 11.02.2013 №17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;

• Постановление Правительства Российской Федерации от 06.07.2015 №676 (в редакции от 23.12.2021) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

Последний из указанных нормативных актов не содержит прямого указания на ГОСТ Р 59793–2021, но содержит цитату из него, дополненную требованиями по защите информации: «Этап разработки документации на систему и ее части включает разработку, согласование и утверждение документации в объеме, необходимом для описания полной совокупности проектных решений (в том числе по защите информации) и достаточном для дальнейшего выполнения работ по созданию системы».

ГОСТы на автоматизированные системы и связанные с ними стандарты регламентируют следующие 5 основных областей требований к проектированию систем:

1. стадии проекта создания системы;

2. состав проектной документации;

3. содержание проектной документации;

4. оформление проектной документации;

5. последовательность приемки системы.

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

Таблица 3 — Обязательность отдельных областей требований к документации.

Состав документации

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

Полный состав документации, определенный в ГОСТ 34.201–2020, — избыточен. Среди предложенных документов могут быть выбраны наиболее подходящие исходя из специфики задачи. Если требования заказчика не вполне определены, я предлагаю присмотреться к одному из предложенных в Таблице 4 подходу к проектированию (1…5) — набору документации, описываемой ГОСТами на автоматизированные системы. Один из таких подходов можно выбрать и применять в качестве рекомендации, от которой можно далее отталкиваться.

Таблица 4 — Рекомендуемые наборы документации.

Коды документов в Таблице 4 приведены в соответствии с ГОСТ 34.201–2020. Акты, протоколы, приказы, эскизный проект, редко разрабатываемые документы из списка 55 документов по ГОСТ 34.201–2020 не учитывались в данной таблице.

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

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

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

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

Набор 5 редко требуется в настолько широком составе, даже для аттестации систем.

Содержание документации

Требования к содержанию документации установлены ГОСТ Р 59795–2021, на который (вместо РД 50–34.698–90) следует ссылаться при определении технических требований на проектирование системы.

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

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

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

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

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

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

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

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

Оформление документации

Стандартом оформления технической документации принято считать ЕСКД (ГОСТ 2) «Единая система конструкторской документации». Требования к тестовым документам установлены ГОСТ 2.105–2019.

Согласно ГОСТ Р 59795–2021 (строки 4-26 в Таблице 4) оформление технической документации выполняют по ГОСТ 2.105 и ГОСТ 2.106, которыми установлены требования к оформлению текстовых документов и чертежей, включая рамку по границам листа, с надписью внизу рамки по ГОСТ 2.104 и с кодом документа по ГОСТ 34.201–2020.

Ранее требованиями ГОСТ 34.602–89 указывалось, что «ТЗ на АС оформляют… без рамки, основной надписи и дополнительных граф к ней». Однако, вступившим в силу ГОСТ 34.602–2020 данная оговорка заменена на «ТЗ на АС оформляют в виде текстового документа». Таким образом, Техническое задание на систему должно оформляться аналогично технорабочему проекту, в рамке по границам листа (если в заказе на разработку документации не будет указано обратное).

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

Для производства профессионально составленной документации разработчикам (техническим писателям) рекомендуется применять соответствующие ГОСТ рекомендации специализированных руководств, одним из наиболее заслуженных среди которых считается «Справочник издателя и автора» (Мильчин А.Э, Чельцова Л.К.), — шестое издание 2021 года. 

Отдельных комментариев заслуживает ситуация с санкционными ограничениями и отзывом в 2022 году компанией Monotype возможности доступа на загрузку распространенных шрифтов Times New Roman, Arial с российских IP-адресов. Данное ограничение не запрещает использовать указанные шрифты на территории Российской Федерации, однако подталкивает разработчиков документации к установке и переходу к использованию шрифтов отечественного производства, из которых наибольшую известность заслужили шрифты компании «Паратайп» (Paratype):

• PT Astra Serif – на смену Times New Roman;

• PT Astra Sans – на смену Arial.

Из системы стандартов по информации, библиотечному и издательскому делу (ГОСТ Р 7.0.97-2016) исключены рекомендации по использованию проприетарных шрифтов из состава ОС Windows (Times New Roman, Arial, Courier New, Verdana), а в ГОСТ 2.105-2019 добавлено примечание о том, что применение таких шрифтов может привести к искажениям при отображении этих документов в других операционных системах (например, при переходе на отечественное ПО), в которых эти шрифты отсутствуют в связи с санкционными и лицензионными ограничениями.

Подытожим?

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

ГОСТ 34.201-89

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

КОМПЛЕКС СТАНДАРТОВ
НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

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

Москва
ИПК Издательство стандартов
2002

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

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ Комплекс стандартов на автоматизированные системы ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ Information technology. Set of standards for automated systems. Types, sets and indication of documents for automated systems design

ГОСТ 34.201-89

Дата введения 01.01.90

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

Пояснения терминов, применяемых
в настоящем стандарте, приведены в приложении 1.

1.
ВИДЫ И НАИМЕНОВАНИЕ ДОКУМЕНТОВ

1.1. Состав видов документов, разрабатываемых на стадии «Исследование и обоснование
создания АС» определяют в соответствии с разд. 3 ГОСТ 34.601, исходя из требуемых результатов выполнения данной стадии.

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

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

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

Таблица 1

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

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

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

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

1) разрабатывать групповые и базовые документы в соответствии с разд. 1,
3, 4, 6 ГОСТ 2.113;

2) выпускать документы отдельными самостоятельными частями,
соответствующими разделам основного документа;

3) расширять номенклатуру документов, установленную настоящим
стандартом.

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

1) акт завершения работ;

2) акт приемки в опытную эксплуатацию;

3) акт приемки в промышленную эксплуатацию;

4) план-график работ;

5) приказ о составе приемочной комиссии;

6) приказ о проведении работ;

7) программа работ;

протокол испытаний;

9) протокол согласования.

Таблица 2

(Измененная редакция, Изм. №
1).

2.
КОМПЛЕКТНОСТЬ ДОКУМЕНТАЦИИ

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

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

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

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

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

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

3.
ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

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

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

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

3.3. Обозначение документа имеет следующую структуру:

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

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

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

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

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

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

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

ПРИЛОЖЕНИЕ 1
Справочное

ПОЯСНЕНИЯ ТЕРМИНОВ,
ПРИМЕНЯЕМЫХ В НАСТОЯЩЕМ СТАНДАРТЕ

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

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

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

ПРИЛОЖЕНИЕ 2
Рекомендуемое

ПРАВИЛА ОБОЗНАЧЕНИЯ СИСТЕМ И
ИХ ЧАСТЕЙ

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

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

3. Код классификационной характеристики системы или ее части
(подсистемы, комплекса, компонента) присваивают в соответствии с правилами,
установленными в отрасли на основе 425 подкласса общесоюзного классификатора
продукции и/или общесоюзного классификатора подсистем и комплексов задач
АСУ-184154.

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

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

__________

* См. примечание ФГУП
«СТАНДАРТИНФОРМ»

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

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

3. Срок проверки – 1999 г.;
периодичность проверки – 10 лет

4. ВЗАМЕН ГОСТ 24.101-80,
ГОСТ 24.102-80, РД 50-617-86

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

6. ИЗДАНИЕ с Изменением № 1,
утвержденным в декабре 1990 г. (ИУС 4-91)

Переиздание (по
состоянию на август 2008 г.)

ПРИМЕЧАНИЕ ФГУП «СТАНДАРТИНФОРМ»

На первой
странице дополнить кодом: МКС 35.240 (указатель «Национальные стандарты», 2008).
Информационные данные. Ссылочные нормативно-технические документы: ГОСТ 2.601-95
заменен на ГОСТ
2.601-2006.

СОДЕРЖАНИЕ

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

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

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

Приложение 1 (справочное) Пояснения терминов, применяемых в настоящем стандарте

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