· web viewКомплектовочная карта КК ГОСТ 3.1102-2011 9 **Лист...

СОГЛАСОВАНО

Главный конструктор

АО «НПК «ВТ и СС»

А.В. Бизяев

«_____»___________ 2020 г.

УТВЕРЖДАЮ

Генеральный директор

АО «НПК «ВТ и СС»

А.В. Литвинов

«_____»___________ 2020 г.

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

Наименование проекта: «Создание комплексного информационно-программного»

Разработано: 11 сентября 2023 г.

Стр. 2 из 71


ОглавлениеОбщие сведения.......................................................................................................................................5

1.1 Наименование работ......................................................................................................................5

1.2 Область применения системы......................................................................................................5

1.3 Заказчик..........................................................................................................................................5

1.4 Сроки начала и окончания работ.................................................................................................5

1.5 Источники и порядок финансирования работ............................................................................5

1.6 Порядок оформления и предъявления Заказчику результатов оказания услуг......................5

2 Назначение и цели создания системы................................................................................................6

2.1 Общее назначение системы:.........................................................................................................6

2.2 Цели создания системы.................................................................................................................6

3 Характеристика объектов автоматизации..........................................................................................7

3.1 Краткие сведения об объекте автоматизации.............................................................................7

4 Требования к системе..........................................................................................................................8

4.1 Требования к системе в целом.....................................................................................................8

4.1.1 Требования к структуре и функционированию системы....................................................8

4.1.2 Требования к численности и квалификации персонала и режиму его работы.................9

4.1.3 Показатели назначения........................................................................................................10

4.1.4 Требования к надежности....................................................................................................11

4.1.5 Требования безопасности....................................................................................................12

4.1.6 Требования к эргономике и технической эстетике...........................................................12

4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы........................................................................................................................13

4.1.8 Требования к защите информации от несанкционированного доступа..........................15

4.1.9 Требования по сохранности информации при авариях....................................................15

4.1.10 Требования к защите от влияния внешних воздействий................................................16

4.1.11 Требования к патентной чистоте.......................................................................................16

4.1.12 Требования по стандартизации и унификации................................................................16

4.2 Требования к функциям (задачам), выполняемым КИПР.......................................................16

4.2.1 Требования к системе в целом.............................................................................................16

4.2.2 Подсистема управления проектами....................................................................................17

4.2.3 Подсистема управления требованиями к изделию............................................................18

4.2.4 Подсистема управления нормативно-справочной информацией....................................20

Стр. 3 из 71


4.2.5 Подсистема управления данными об изделии...................................................................21

4.2.6 Подсистема проектирования изделия.................................................................................28

4.2.7 Подсистема проектирования электрических и кабельных систем..................................29

4.2.8 Подсистема проектирования печатных плат.....................................................................31

4.2.9 Подсистема технологической подготовки производства (ТПП).....................................32

4.2.10 Подсистема производственного планирования...............................................................36

4.2.11 Подсистема подготовки и сопровождения эксплуатационной документации.............40

4.2.12 Подсистема интеграционного решения............................................................................42

4.2.13 Временной регламент реализации каждой функцией системы.....................................46

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

4.2.15 Перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.....................................................................................................................................46

4.3 Требования к видам обеспечения..............................................................................................47

4.3.1 Требования к математическому обеспечению...................................................................47

4.3.2 Требования к информационному обеспечению системы.................................................47

4.3.3 Требования к лингвистическому обеспечению.................................................................50

4.3.4 Требования к программному обеспечению........................................................................51

4.3.5 Требования к техническому обеспечению.........................................................................51

4.3.6 Требования к метрологическому обеспечению.................................................................51

4.3.7 Требования к организационному обеспечению.................................................................51

5 Состав и содержание работ по созданию КИПР.............................................................................53

5.1 Состав и содержание работ по КИПР........................................................................................53

5.1.1 Состав разработки.................................................................................................................53

6 Порядок контроля и приемки КИПР................................................................................................55

6.1 Порядок контроля выполнения работ.......................................................................................55

6.2 Виды, состав, объем и методы испытаний подсистемы и ее составных частей..................55

6.3 Общие требования к приемке работ по стадиям......................................................................57

6.4 Сведения о гарантийном и послегарантийном обслуживании системы................................58

6.5 Порядок выполнения доработок и устранения допущенных исполнителем ошибок, которые выявлены на стадии приемки.................................................................................................59

7 Требования к документированию.....................................................................................................60

8 Требования к результату работ.........................................................................................................62

9 Требования к организации работ на территории Заказчика..........................................................63

Стр. 4 из 71


10 Источники разработки.....................................................................................................................64

11 Список используемых терминов и сокращений............................................................................66

Стр. 5 из 71


Общие сведения

1.1 Наименование работ

Работы по внедрению комплексного информационно-программного решения

(далее—КИПР) в АО Научно-промышленная компания «Высокие технологии и

стратегические системы».

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

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

производственное планирование в АО «НПК «ВТиСС».

1.3 Заказчик

Заказчик: АО «НПК «ВТиСС».

Исполнитель: Определяется на конкурсной основе.

1.4 Сроки начала и окончания работ

Плановая дата начала работ: 10 дней с даты заключения договора.

Плановая дата окончания работ: 15 месяцев с даты заключения договора (6

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

1.5 Источники и порядок финансирования работ

Услуги финансируются Заказчиком на основании Договора на оказание услуг,

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

Источник финансирования – собственные средства.

1.6 Порядок оформления и предъявления Заказчику результатов оказания услуг

По завершении оказания услуг по каждому этапу Исполнитель предоставляет

Заказчику отчетную документацию в соответствии пунктом 7 настоящего Технического

задания.

Стр. 6 из 71


2 Назначение и цели создания системы

2.1 Общее назначение системы:

КИПР предназначено для автоматизации коллективной работы специалистов и

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

Проектирование и разработка изделий

Разработка программных и информационных изделий

Конструкторско-технологическая подготовка производства

Планирование производства.

2.2 Цели создания системы

Цели создания Системы:

обеспечение коллективной разработки изделия в электронном виде;

создание единой базы данных об изделии;

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

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

представление необходимой информации обо всех этапах жизненного

цикла изделия;

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

изделиях АО «НПК «ВТиСС»;

обеспечение производственного планирования производства.

Стр. 7 из 71


3 Характеристика объектов автоматизации

3.1 Краткие сведения об объекте автоматизации

Объектом автоматизации (организационным периметром) является:

АО «НПК «ВТиСС», 127083, Москва, ул. 8 Марта, д. 10, строение 1

Обособленное подразделение Заказчика «Конструкторское бюро

разработки антенных систем», 196143, Санкт-Петербург, ул.

Орджоникидзе, д. 42.

Целевой показатель общего количества пользователей КИПР для всех подсистем

составляет 450 с возможностью расширения до 700.

Стр. 8 из 71


4 Требования к системе

4.1 Требования к системе в целом

4.1.1 Требования к структуре и функционированию системы

6.1.1.1 Состав КИПРКИПР состоит из следующих подсистем, обеспечивающих выполнение

определенных задач предприятия:

Подсистема управления проектами («Подсистема УП»)

Подсистема управления требованиями к изделию («Подсистема УТ»)

Подсистема управления нормативно-справочной информацией

(«Подсистема НСИ»)

Подсистема управления данными об изделии («Подсистема PDM»)

Подсистема проектирования механической и аппаратной части

(«Подсистема CAD»)

Подсистема проектирования электрических и кабельных систем

(«Подсистема ECAD»)

Подсистема проектирования печатных плат

Подсистема технологической подготовки производства («Подсистема ТПП»)

Подсистема производственного планирования

Подсистема подготовки и сопровождения эксплуатационной документации

(«Подсистема CMS»)

Подсистема интеграционного решения («Подсистема ИР»)

6.1.1.2 Требования к способам и средствам связи для информационного обмена между подсистемами КИПР

Связь между подсистемами КИПР должна осуществляться по КСПД Заказчика.

Детальная проработка структуры и функционирования КИПР должна быть

осуществлена на этапе разработки технических решений подсистем и описана в

документах «Пояснительная записка» на каждую подсистему.

6.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы Связь между подсистемами КИПР определяется в процессе разработки

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

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

канала связи между территориями.

Связь между подсистемами КИПР должна осуществляться через стандартные

протоколы обмена данными, поддерживаемые КСПД предприятия Заказчика.

Стр. 9 из 71


6.1.1.4 Требования к режимам функционирования системыКИПР должно обеспечивать:

в штатном режиме:

непрерывную работу подразделений в едином пространстве;

обмен данными между подсистемами;

в сервисном режиме:

модернизацию КИПР;

резервное копирование;

в аварийном режиме:

резервное копирование.

6.1.1.5 Требования по диагностированию системыДиагностирование КИПР должно обеспечивать выявление его

неработоспособности.

Диагностирование компонентов хранения и обработки данных КИПР должно

осуществляться стандартными средствами СУБД SQL встроенными средствами

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

6.1.1.6 Перспективы развития, модернизации системыКИПР должна поддерживать обновление версий ПО, допускать модернизацию

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

пользователей согл. п. 3.1 настоящего ТЗ.

4.1.2 Требования к численности и квалификации персонала и режиму его работы

Требования к численности персонала КИПР должен быть определен

утвержденным штатным расписанием по подразделениям, работающих в КИПР.

Требования к квалификации персонала КИПР устанавливаются утвержденными и

применяемыми для каждой штатной единицы на предприятии должностными

инструкциями. Так же персонал, работающий в КИПР, должен пройти стандартные курсы

и дополнительные курсы к каждой подсистеме.

Пользователи, работающие в КИПР, должны быть знакомы с проектной

документацией, разработанной в ходе проектирования КИПР.

Режим работы персонала должен быть определен в соответствии с режимом

работы подразделений предприятия. Дополнительных требований к режиму работы

персонала не предъявляются.

Стр. 10 из 71


4.1.3 Показатели назначения

6.1.1.7 Общие требованияКИПР, установленное на аппаратной платформе Заказчика с

производительностью, не ниже требований, указанных в разделе 4.3.5, должна

обеспечивать выполнение всех требований Заказчика, заданных в настоящем ТЗ.

КИПР должно иметь возможности к изменению под условия бизнес – процессов

Заказчика.

6.1.1.8 Степень приспособляемости системы к отклонениям параметров объекта автоматизации

КИПР должна обеспечивать:

масштабируемость по количеству пользователей согласно п. 3.1

намстоящего ТЗ;

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

пользователей;

независимость от изменений в организационной структуре подразделений

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

возможность передислокации пользователей в пределах корпоративной

сети.

6.1.1.9 Допустимые пределы модернизации и развития системыКИПР должна обеспечивать возможность модернизации и развития для

повышения степени приспособляемости при изменении параметров объекта

автоматизации, а также при необходимости изменения состава требований к

выполняемым функциям и видам обеспечения.

Модернизация и развитие КИПР должно проводиться экспертами в предметной

области и прикладными программистами службы эксплуатации с помощью

соответствующего программного обеспечения, автоматизирующего процесс

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

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

подсистем входящих в КИПР и утверждается в Частных технических заданиях на каждую

подсистему КИПР.

6.1.1.10 Вероятностно-временные характеристики, при которых сохраняется целевое значение системы

Минимальный срок эксплуатации КИПР – не менее семи лет.

Стр. 11 из 71


При расширении функциональности или количества пользователей КИПР должны

быть оценены и определены потребности в технических средствах для сохранения

временных характеристик функционирования КИПР.

Допускается согласованное изменение временных характеристик КИПР при

изменении количества пользователей и объема размещаемой и хранимой информации,

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

отклика КИПР на запросы пользователей.

4.1.4 Требования к надежности

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

корректно обрабатывать действия пользователя и сообщения об ошибках, поступающих

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

со стороны пользователя.

Структура КИПР, технические и программные средства должны позволять

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

подсистем без остановки КИПР в целом.

КИПР должна обеспечивать восстановление работоспособности в течение 4-х

часов при нарушении работоспособности прикладного программного обеспечения, если

при этом отсутствуют проблемы с аппаратным обеспечением, не требуется

восстановления операционной системы, развертывания и настройки специального

программного обеспечения на серверах или восстановления данных с использованием

последней резервной копии.

КИПР должна обеспечивать защиту от потери информации при различных

уровнях отказов программно-аппаратного комплекса (например, сервера, СУБД).

Сбои или прекращение электропитания не должны приводить к нарушению

целостности данных, должно обеспечиваться восстановление базы данных до состояния

на момент последней завершенной подсистемой транзакции. В случае повреждения

журналов транзакций СУБД должно обеспечиваться восстановление состояния КИПР на

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

момента сбоя.

Обеспечение надежности КИПР должно проводиться на стадиях разработки и

эксплуатации.

На стадии разработки КИПР должно быть предусмотрено структурное

резервирование критических компонентов КИПР, включающее введение в структуру

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

Стр. 12 из 71


На стадии внедрения КИПР должны быть разработаны конкретные требования к

показателям надежности в следующих документах:

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

электронной технической документацией для каждой подсистемы КИПР;

руководство пользователя для каждой подсистемы КИПР;

руководство администратора для каждой подсистемы КИПР.

На стадии эксплуатации КИПР должны использоваться следующие методы

обеспечения надежности:

регламентация выполнения работ персонала;

сервисное обслуживание и поддержка компонентов комплекса технических

средств;

своевременная диагностика и анализ неисправностей;

повышение квалификации пользователей и эксплуатационного

обслуживающего персонала;

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

эксплуатации по выходу из аварийных ситуаций.

4.1.5 Требования безопасности

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

обеспечения КИПР не предъявляются.

4.1.6 Требования к эргономике и технической эстетике

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

разрабатываемых задач и удовлетворять используемым в настоящее время

соглашениям по построению системы Windows не ниже версии 7. КИПР должна

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

подсказки.

Интерфейс КИПР должен быть понятным и удобным, не должен быть перегружен

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

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

Средства редактирования информации должны удовлетворять принятым соглашениям в

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

оконной системы. Кнопки и надписи должны быть информативными и не вызывать

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

соответствовать общепринятым правилам и нормам и не должен вступать в

противоречие с психологическими особенностями человека.

Стр. 13 из 71


КИПР должно обеспечивать корректную обработку аварийных ситуаций,

вызванных неверными действиями пользователей, неверным форматом или

недопустимыми значениями входных данных. В указанных случаях КИПР должно

выдавать пользователю соответствующие сообщения, после чего возвращаться в

рабочее состояние, предшествовавшее неверной (недопустимой) команде или

некорректному вводу данных.

Экранные формы должны проектироваться с учетом требований унификации:

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

выполнены в едином графическом дизайне в рамках одного ПО, с

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

для обозначения сходных операций должны использоваться сходные

графические значки, кнопки и другие управляющие (навигационные)

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

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

также последовательности действий пользователя при их выполнении,

должны быть унифицированы.

Для всех видов интерфейсов должны быть обеспечены удобство,

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

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

4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

КИПР должно быть рассчитано на эксплуатацию в составе программно-

технического комплекса Заказчика. Техническая и физическая защита аппаратных

компонентов КИПР, носителей данных, бесперебойное энергоснабжение, резервирование

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

организационными средствами, предусмотренными в ИТ-инфраструктуре Заказчика.

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

использование оборудования КИПР с заданными техническими показателями, в том

числе виды и периодичность обслуживания или допустимость работы без обслуживания,

должны быть определены в эксплуатационной документации.

Обслуживание КИПР должно производиться администратором КИПР.

Режим работы обслуживающего персонала должен быть определен в

соответствии с режимом (регламентом) эксплуатации КИПР.

Стр. 14 из 71


Технические решения по развитию и модернизации КИПР должны

предусматривать возможность планового останова отдельных подсистем КИПР для

регламентного обслуживания без потери функциональности и останова КИПР в целом.

Эксплуатация программно-технических средств КИПР должна включать

следующие виды обслуживания:

оперативное обслуживание;

профилактические работы;

эксплуатацию при авариях;

модернизацию подсистем КИПР;

восстановление после аварии.

Оперативное обслуживание должно предусматривать ежедневный контроль

функционирования программно-технических средств КИПР с использованием

автономных средств администрирования подсистем КИПР, проведение операций по

резервному копированию информации, обрабатываемой КИПР. Оперативное

обслуживание не должно нарушать выполнения функций КИПР по предоставлению

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

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

подсистем КИПР, выработку рекомендаций по совершенствованию работы КИПР.

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

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

Профилактические работы должны включать периодическую проверку

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

работоспособности процедур резервирования отдельных подсистем КИПР, процедур

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

процедуры предусмотрены эксплуатационной документацией. Профилактические работы

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

функционирования модулей и элементов КИПР, выработку рекомендаций по

совершенствованию работы КИПР.

Резервная копия текущей версии прикладного программного обеспечения КИПР

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

использования обслуживающим персоналом.

Эксплуатация при авариях КИПР должна предусматривать порядок перехода

служб на резервные элементы, оповещение руководства и пользователей о

переключении на резервные элементы, обеспечение актуальности программного и

информационного обеспечения, работоспособности резервных элементов КИПР,

проведение необходимого комплекса аварийно-восстановительных работ.

Стр. 15 из 71


Модернизация должна предусматривать набор регламентированных процедур по

выводу из эксплуатации и замене устаревших элементов подсистем КИПР, вводу

обновленных элементов в действие, документированию проведенных действий.

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

восстановление работоспособности подсистемами КИПР, восстановление данных при

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

средств, анализ неисправностей и причин аварии. Восстановление должно

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

аварии и функционирования КИПР при аварии, выработку рекомендаций по обеспечению

надежности работы КИПР и внесение необходимых изменений в регламенты

восстановления подсистем КИПР.

4.1.8 Требования к защите информации от несанкционированного доступа

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

помощью следующих механизмов:

авторизация пользователей;

аутентификация пользователей в КИПР должна осуществляться путем

ввода персонального логина и пароля;

назначение прав доступа к функциям и данным КИПР;

протоколирование операций, выполняемых пользователями КИПР.

Для случая удаленного доступа к функциям КИПР дополнительно должны

обеспечиваться двухфакторная авторизация пользователя.

4.1.9 Требования по сохранности информации при авариях

Допускается потеря информации по последней транзакции, при этом информация

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

администратору. Архивирование всех сохраненных данных должно выполняться без

остановки КИПР с обеспечением их восстановления при отказе любой из подсистем

КИПР. КИПР должно обеспечивать возможность выборочного восстановления данных из

ранее созданных архивов в случае, например, ошибочного их удаления или

модификации.

КИПР должно обеспечивать сохранность информации в случае технического сбоя

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

автономных носителях или в защищенном хранилище.

Стр. 16 из 71


4.1.10 Требования к защите от влияния внешних воздействий

Требования к радиоэлектронной защите средств КИПР, инсталлированной на ПК,

не предъявляются.

Требования по стойкости, устойчивости и прочности к внешним воздействиям

(среде применения) для подсистем КИПР не предъявляются.

4.1.11 Требования к патентной чистоте

Проектные и технические решения по построению КИПР должны отвечать

требованиям действующего законодательства Российской Федерации об авторском

праве и смежных правах по патентной чистоте, регламентирующих создание КИПР

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

4.1.12 Требования по стандартизации и унификации

При разработке КИПР должны быть использованы унифицированные формы

входных документов, международные, государственные и отраслевые классификаторы,

унифицированные протоколы обмена информацией между всеми уровнями КИПР.

Пользовательский интерфейс КИПР должен являться типовым для всех

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

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

отдельный список).

Для пользователей КИПР в части доступа к сервисам должны быть использованы

типовые решения построения АРМ.

КИПР должно быть построено с использованием стандартных и унифицированных

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

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

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

Системное программное обеспечение должно быть унифицировано по версиям и

составу в рамках объекта внедрения и автоматизированного рабочего места.

4.2 Требования к функциям (задачам), выполняемым КИПР

4.2.1 Требования к системе в целом

Система должна состоять из нескольких экземпляров:

Среды разработки Системы

Промышленная среда.

Стр. 17 из 71


ИT-инфраструктура, необходимая для установки, настройки и проведения

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

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

4.2.2 *1Подсистема управления проектами

Основными задачами, которые должны выполняться в Подсистемой УП, являются

разработка и ведение календарных планов выполнения проектов разработки и

производства новых и модернизации существующих изделий. В том числе:

*разработка планов выполнения проектов, в том числе разработка

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

*планирование потребностей в ресурсах;

*управление календарями;

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

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

рабочих процессов (Workflow), что позволяет обеспечить автоматическую

фиксацию в графике факта выполнения работы по завершению этапов

процесса Workflow;

*обеспечение возможности интеграционного решения между Jira и 1С в

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

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

заработной платы сотрудника;

*расчет и оптимизация планов выполнения проектов с учетом ограничений

на ресурсы;

*построение отчета о видах и интенсивности нагрузок на рабочие группы, а

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

плана;

*рассылка уведомлений пользователям о назначении или изменении задач,

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

предопределенных событий или совершения предопределенных действий,

связанных с задачей и/или план-графиком;

*подписка на оповещения о событиях, действующая аналогично рассылке

уведомлений с той лишь разницей, что сам пользователь может

подписаться на информирование об интересующих его событиях;

1 Здесь и далее знаком «*» отмечены работы, выполняемые Заказчиком

Стр. 18 из 71


*обеспечение прозрачности процессов взаимодействия между

подразделениями компании и автоматизации контроля рабочими

процессами.

4.2.3 Подсистема управления требованиями к изделию

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

функциональность:

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

- спецификация требований к изделию

каждое единичное требование должно быть представлено в подсистеме УТ

как отдельный информационный объект с поддержкой собственного

жизненного цикла требований;

работа пользователей в подсистеме УТ должна осуществляться с

использованием клиентского приложения и Web-приложения (допускается

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

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

функционала);

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

интерфейсом подсистемы PDM;

возможность оповещения пользователей об изменениях существующих или

назначении новых требований по корпоративной электронной почте

Заказчика;

**2формирование отчётных документов по трассировке требований на

изделие в форматах Excel и PDF штатными средствами установленной у

Заказчика системы;

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

возможность при формировании конечного отчетного документа размещать

в нём необходимую атрибутивную информацию, связанную с конкретным

требованием;

наличие рабочих процессов проверки корректности и полноты требований к

изделию;

возможность создания трассировочных связей между требованиями и

целевыми данными;

отображение трассировочных связей и комментариев к ним;

2 Здесь и далее знаком «**» отмечены работы, выполняемые Исполнителем не в рамках пилотного проекта. Требования могут быть уточнены по итогам пилотного проекта.

Стр. 19 из 71


возможность вариантного конфигурирования функциональных и логических

структур требований;

возможность ввода требований путем их импорта из документа в формате,

поддерживаемом ПО MS Office;

возможность редактирования требований путём их экспорта в документ в

формате, поддерживаемом ПО MS Office;

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

формата, поддерживаемого ПО MS Office, с применением конечного

шаблона оформления документа, настроенного в системе;

возможность сравнения двух структур требований между собой на уровне

записей в структурах;

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

(шаблона или аналога);

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

дочерними требованиями;

возможность создания трассировочных связей между исходными

требованиями и другими объектами КИПР;

**использование подсистемы НСИ для формирования общекорпоративной

базы объектов требований и их атрибутов;

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

в стандартном интерфейсе других подсистем КИПР;

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

проектируемого изделия непосредственно из подсистемы CAD;

**возможность постановки задачи на верификацию требования (например,

разработка программного продукта) соответствующим функциональным

подразделениям и/или пользователям;

**возможность сохранения результатов верификации требований в связке с

исходными требованиями и задачами на верификацию требований;

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

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

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

(отрицательном) результате согласования требования

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

требований на уровне отдельных пользователей, групп пользователей или

ролей.

Стр. 20 из 71


возможность просмотра структуры документов, трассировок документации в

браузере;

проведение консультационного семинара «Управление требованиями» для

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

более 12 человек.

4.2.4 Подсистема управления нормативно-справочной информацией

Подсистема НСИ должна обеспечить выполнение следующих функций:

ведение структуры справочников НСИ в виде иерархического дерева с

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

класса в дочерний;

исключение дублирования объектов НСИ путём проверки наличия

соответствующей записи при создании новой записи или объекта в

справочнике НСИ;

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

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

- логический

- целый

- вещественный

- строковый

- ссылочный

- наследуемый

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

классах справочника с возможностью задания различной атрибутивной

информации;

единообразие отображения и загрузки всех объектов из Подсистемы НСИ в

Подсистемы CAD, ECAD и проектирования печатных плат;

элементы библиотеки ПКИ Capital должны быть автоматически связаны с

компонентами соответствующих ветвей классификатора;

элементы библиотеки ПКИ PADS/Xpedition должны быть автоматизировано

связаны с компонентами соответствующих ветвей классификатора;

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

(шаблоны, прототипы);

связь группы элементов с одним параметрическим файлом ЭМ с

автоматическим заполнением атрибутов в соответствии параметров ЭМ и

объекта;

Стр. 21 из 71


управление представлениями справочников НСИ для разных групп


управление правилами доступа пользователей к структуре и элементам

НСИ;

управление возможностью применения НСИ в электронных документах на

основе информации о применяемости НСИ;

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

наполнение справочников элементами НСИ с использованием встроенных

приложений, а также на основе настроенных рабочих процессов;

возможность просмотра справочных данных НСИ в браузере;

**экспорт объектов классификатора ПКИ из различных систем в

согласованном в ЧТЗ формате данных;

проведение консультационного семинара «Ведение НСИ в КИПР» для

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

более 12 человек.

4.2.5 Подсистема управления данными об изделии

Подсистема PDM должна обеспечивать выполнение следующих функций:

создание и ведение электронной структуры изделия с возможностью

поддержки многовидовых структур (варианты исполнения, варианты

представления и т.п.);

возможность управления опциями изделия;

ведение ревизий элементов ЭСИ;

учёт применяемости на дату;

обозначения объектов должны назначаться согласно заданных шаблонов;

автоматическую проверку уникальности обозначения элементов

назначение связей (отношений) между элементами

подсистема PDM должна обеспечить сквозное взаимодействие с

Подсистемой CAD:

- возможность напрямую из Подсистемы PDM, без промежуточных

преобразований и передач, редактировать / просматривать

объекты Подсистемы CAD;

- возможность создания соответствующих элементов Подсистемы

PDM из Подсистемы CAD, запущенной в режиме интеграции с

Подсистемой PDM;

Стр. 22 из 71


Подсистема PDM должна содержать настроенные шаблоны Подсистемы

CAD для элементов:

- «Деталь»;

- «Сборочная единица»;

- «Стандартное изделие»;

- «Покупное изделие»;

- «Материал в сборке»;

- «Псевдосборка»;

- «Прочие изделия»;

- «Комплекс»;

- «Комплект»

возможность создания для элемента нескольких альтернативных

представлений ЭГМ, с возможностью выбора необходимого

альтернативного представления при вставке/позиционировании данного

элемента в сборке;

возможность прямого доступа к справочникам Подсистемы НСИ по

различным тематикам;

отображение файлов в визуализаторе Подсистемы PDM на основе

созданных в подсистеме CAD 3D-моделей;

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

шаблоном;

возможность отображения полного состава, всех уровней вложенности

изделий и его составных частей;

автоматизированную простановку/корректировку позиций компонентов в

контексте ЭСИ;

обеспечивать автоматическое формирование следующих видов

конструкторской и технологической документации в соответствии с ЕСКД,

ЕСТД и стандартами предприятия:

№ п/п

Наименование документаКод

документаНормативные документы

1**Ведомость документов на носителях данных

ВН ГОСТ 2.123-93

2 Ведомость покупных изделий ВП ГОСТ 2.106-96

3**Ведомость содержания драгоценных материалов

Д26 ГОСТ 2.608-78

Стр. 23 из 71


4**Ведомость содержания цветных металлов

Д30 ГОСТ 2.608-78

5 **Габаритный чертеж ГЧ ГОСТ 2.109-73

6 **Данные топологии (CD) СБ1М ГОСТ Р 56571-2015

7 **Карты рабочих режимов Д4 РД В 319.01.09-94

8 Комплектовочная карта КК ГОСТ 3.1102-2011

9 **Лист утверждения ЛУ ГОСТ 2.105-95

10 Маршрутная карта МК ГОСТ 3.1118-82

11 **Паспорт ПС ГОСТ 2.601-2013

12 Перечень элементов ПЭ3 ГОСТ 2.102-2013

13 Сборочный чертеж СБ ГОСТ 2.109-73

14 Сопроводительный паспорт СП ГОСТ 3.1102-2011

15 Спецификация СП

ГОСТ 2.108-68ГОСТ 2.106-96ГОСТ 2.104-2006ГОСТ 2.102-2013

16 Схема электрическая принципиальная Э3ГОСТ 2.701-2008 ГОСТ 2.702-2011

17 Чертеж деталей ГОСТ 2.109-73

18 **Электронная модель блока ЭСБ ГОСТ 2.052-2006 выпуск документации в Подсистеме PDM должен осуществляться по

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

процессов выпуска и утверждения;

все изменения, вносимые в ходе согласования и утверждения

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

(рабочий процесс), с назначением элементу соответствующего статуса.

Если элемент не имеет статуса, то все изменения должны проводиться

путем редактирования, существующего (находящегося в разработке)

элемента;

**подписание документов должно осуществляться по электронной

процедуре с использованием ЭЦП;

**в случае принятия положительного решения по утверждению,

согласующий подписывает объект ЭЦП, после чего процесс должен

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

всех этапов согласования в Подсистеме PDM должна быть утверждена

ревизия элемента, подписанная ЭЦП;

Стр. 24 из 71


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

элементов Подсистемы PDM, прошедших процедуру согласования и

утверждения;

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

процедур согласования отчетов:

- «Извещение о первичном выпуске»;

- «Извещения об изменении»;

- *«Предложения об изменении»;

- *«Предварительное извещение об изменении;

- *«Отчет о проблеме»;

- *«Дополнительное извещение об изменении»;

- *«Дополнительное предварительное извещение об изменении»

ЭСИ должна формироваться в Подсистеме PDM на основе элементов и

данных из Подсистемы CAD;

конфигурирование поэкземплярного или действующего на определенную

дату/серию ЭСИ на основании информации о применяемости;

**управление вариантными правилами;

управление процессом проведения инженерных изменений:

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

соответствии с требованиями ЕСКД с учетом внутренних

нормативных документов Заказчика

- выпуск и проведение ИИ, **ПИ, **ПР, **ДИ, **ДПИ

- проведение изменений в Подсистеме PDM должны

осуществляться по электронным процедурам согласования на

основе настроенных рабочих процессов выпуска и утверждения с

сопровождением документа с описанием изменения;

- автоматическое оповещение указанных групп пользователей о

выпуске/изменении ЭКД, по внутренней почте Подсистемы PDM и

с использованием внешних почтовых программ, таких как

Microsoft Outlook»;

- возможность в функционале модуля «Управление изменениями»

группового или индивидуального указания об использовании

задела для изделий, на которые выпускаются изменения;

- обеспечение автоматического ограничения серии (заводского

номера) или даты применяемости действующей ревизии изделия,

Стр. 25 из 71


при выпуске новой ревизии изделия;

- внесение изменений в содержательную часть ЭКД или в

реквизиты, непосредственно содержащие значения свойств

изделия, должно приводить к созданию новой ревизии этого ЭКД

с сохранением его обозначения и наименования и установлением

соответствующего статуса;

- изменения элементов, имеющих стадию «Хранение» должны

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

информационного поиска и анализа его результатов;

формирование и хранение технических требований в объектах и ЭГМ и

ЭСИ;

**управление техническими требованиями должно осуществляться в

Подсистеме PDM с помощью специального программного приложения или

надстройки над PDM-системой. Данная надстройка предоставляет

пользователю следующие функциональные возможности:

- создания, редактирования и копирования текста ТТ;

- добавление текста ТТ из библиотеки типовых формулировок;

- просмотр ТТ должен осуществляться в Подсистеме PDM;

- содержание набора типовых формулировок ТТ должен

передаваться из Подсистемы PDM в подсистему CAD, а также

иметь синхронизацию между PDM-системой и подсистемой CAD

при изменении ТТ в Подсистеме PDM;

формирование и настройку данных для ведения электронного архива КД и

ТД, таких как:

- инвентарный учет разработанных ДЭ в электронном архиве в

соответствии с требованиями ГОСТ 2.501-2013;

- каталогизированное хранение КД в формате, представленной как

в виде электронных документов, так и в виде электронных копий

бумажных документов (сканированной КД);

- на каждый документ должна быть заведена «Карточка учета

документа», предназначенная для учета выданной и поступившей

документации.

- должна быть предусмотрена возможность учета внешних и

внутренних абонентов.

- инвентарная книга представляет собой объект, имеющий состав,

Стр. 26 из 71


в которой входят учитываемая КД.

- атрибуты «Инвентарный номер», «Дата поступления в архив»,

«Принято в архив» и «Примечание» должны храниться, как

свойства вхождения КД в структуру Инвентарной книги.

- атрибут «Инвентарный номер» должен заполняться в системе

автоматически, после включения КД в состав инвентарной книги.

- атрибут «Инвентарный номер» не должен изменяться при

внесении изменения в КД.

- отчетная форма «Инвентарная книга» должна выгружаться в

табличной форме аналогично отображаемой в PDM-системе.

- для учёта ИИ, ПИ и ПР должна формироваться книга

регистрации.

- уникальные обозначения ИИ должны формироваться в момент

создания соответствующих им объектов.

- отчетная форма «Книга регистрации» должна выгружаться в

табличной форме аналогичной отображаемой в PDM-системе.

- для поиска КД должен использоваться штатный функционал

поиска с перенастроенным шаблоном «По инвентарному

номеру».

- регистрационный номер и дату поступления КД в архив

необходимо размещать в реквизитах КД с помощью

динамического атрибута.

- объект «Учётная карточка» должен быть связан с КД посредством

специального отношения.

- учётная карточка представляет собой объект, в состав которого

входят абоненты, которым разослана КД.

- свойства учётной карточки (количество, вид документа)

представляют собой свойства вхождения абонента в структуру

учётной карточки.

- на основании информации об объекте «Абонент» и «Учётная

карточка документа» специально разработанным функционалом

системы должна формироваться отчётный документ

«Абонентская карточка» согласно ГОСТ 2.501-2013 форма 3».

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

Стр. 27 из 71


позволяющая выгрузить перечень документов формате WORD и

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

файловой структуре.

- в системе должна быть предусмотрена возможность учета КД,

которая была разработана вне PDM-системы, но при этом

размещается в ней в виде сканированной электронной копии КД.

- в PDM-системе подлежат обращению (в том числе разработке)

следующие виды электронных конструкторских документов по

способу их выполнения и характеру использования:

подлинник электронной структуры изделия;

подлинник электронной модели изделия (детали,

сборочной единицы) в формате разработки;

подлинник электронного чертежа (схемы) в формате

PDF;

оригинал электронного чертежа (схемы) в формате

разработки;

подлинник текстового электронного КД в формате PDF;

оригинал текстового электронного КД в формате

разработки;

электронная копия бумажного конструкторского

документа в формате PDF.

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

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

инвентарной книги, книги регистрации и карточки учета

документа, должны быть доступны только для просмотра.

Внесение изменений осуществляется сотрудниками

ответственными за Архивный учет.

проведение консультационного семинара «Администрирование системы» с

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

не более 12 человек;

проведение консультационного семинара «Управление данными в PLM-

системе» с использованием раздаточного материала для одной группы.

Состав группы не более 12 человек;

Стр. 28 из 71


проведение консультационного семинара «Ведение архива в PLM-системе»

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

группы не более 12 человек;

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

возможностью записи результата в отчетную форму (Excel);

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

4.2.6 Подсистема проектирования проектирования механической и аппаратной части

Подсистема CAD должна обеспечивать проектирование следующих составных

частей изделия:

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

проверка ЭМ на соответствие требованиям;

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

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

систем подсистема CAD должна обеспечивать:

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

геометрических моделей, описывающих состав, форму, взаимное

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

требуемом объеме и с заданной степенью детализации;

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

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

инструментов создания и управления ассоциативными связями;

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

пересечения;

Подсистема CAD должна содержать абсолютную систему координат (АСК)

и иметь возможность создания и сохранения дополнительных систем

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

собственную систему координат, подсистема CAD должна позволять

создавать рабочую систему координат (РСК) с возможностью ее

сохранения для дальнейшего использования;

организацию проекта с возможностью одновременной работы

конструкторов разных подразделений над одним конструкторским проектом;

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

Должна быть обеспечена работа снизу-вверх и сверху-вниз при

формировании сборочной единицы;

Стр. 29 из 71


создание и отслеживание ассоциативных связей между различными

деталями;

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

фотореалистического изображения отдельной детали, сборки и интерьера

рабочей зоны;

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

инструкциям предприятия;

непосредственное обращение к библиотеке компонентов подсистемы НСИ

из подсистемы CAD;

**анализ эргономики, собираемости и взаимодействия манекена с макетом

в NX;

возможность отслеживания работ над данным изделия из браузера;

проведение консультационного семинара «Работа в CAD (основы

моделирования, создание сборок, основы оформление чертежа, работа с

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

маршрутизации)» с использованием раздаточного материала для одной

группы. Состав группы не более 12 человек.

4.2.7 Подсистема проектирования электрических и кабельных систем

Подсистема ECAD должна быть реализована с применением модуля

проектирования электропроводки в 3D и Mentor Graphics Capital (либо его аналог), и

функционировать в тесной интеграции с подсистемами НСИ и PDM в части работы в

едином информационном пространстве с использованием электронного макета изделия и

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

*Подсистема ECAD должна обеспечивать выполнение следующих задач:

*создание проекта разработки электросистемы;

*создание и изменение логических схем (Э3 и Э4);

*создание маршрута для жгутов в 3D;

*оформление чертежа на электрическую схему и жгут;

Подсистема ECAD должна обеспечивать выполнение следующих функций:

*в части создания проекта разработки электросистемы:

- *возможность настройки параметров электросистемы и

параметров проекта;

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

опций и конфигураций;

- *управление изменениями и создание ревизий дизайнов

Стр. 30 из 71


электропроводки;

- *возможность создания и управления библиотеками ПКИ и УГО;

- *управление доступом к проекту и назначение групп


- *возможность работы с проектом в режиме multi-user (совместный

доступ).

в части создания и изменения логических схем:

- *возможность создание схем с применением различных

настраиваемых стилей оформления;

- *возможность использования существующих дизайнов в качестве

шаблонов;

- *создание принципиальных схем электросистемы (Э3);

- *создание схемы соединений (Э4) на основе принципиальной

схемы (Э3);

- *автоматическое назначение библиотечных деталей объектам

чертежа по заданным правилам;

- *возможность сравнения дизайнов и формирование списка задач

на изменение.

в части создания маршрута для жгутов и кабелей в 3D Routing:

- создание компонента маршрутизации и определение маршрута

жгута с привязкой к «обстановке»;

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

уровня с портами в сборке жгута;

- возможность отобразить добавляемый компонент в

представлениях с разной (настраиваемой) детализацией;

- возможность формирования и выбора трасс жгута различными

способами;

- интеграция ЕСАD с 3D Routing

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

электрической схемы;

- возможность установления автоматической связи между

компонентами электрической схемы и 3D моделями;

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

- анализ построения жгута, корректировка трас, резервирование

пространства;

Стр. 31 из 71


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

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

на плоскости;

в части оформления чертежей жгутов и выпуска КД на электрические

системы:

- *возможность настройки выгрузки определенных типов данных из

3D;

- *расчет длины и ширины ветвей;

- оформление чертежа жгута по заданным стандартам;

- *автоматическое добавление обязательных компонентов;

- *автоматическое создание слоев изоляции по заданным

правилам;

- автоматизированную простановку/корректировку позиций

компонентов в контексте ЭСИ (элементы «Сборочная единица»,

«Псевдосборка») в соответствии с ЕСКД в Capital (либо в его

аналоге);

в части интеграции с PDM:

- возможность интеграции с ECAD для двустороннего обмена

данными;

- возможность проектирования кабельных систем в контексте

электронной модели сборочной единицы и электрических

принципиальных схем;

- представление компонентов CAD-библиотек в виде

классификаторов, также, как и в PDM-системе.

4.2.8 Подсистема проектирования печатных плат

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

функциональность по проектированию топологии печатных плат (ПП) в Mentor PADS

Professional и Mentor Xpedition Enterprise:

проектирование топологии печатных плат (ПП) в Mentor PADS Professional:

разработка посадочных мест компонентов топологии ПП;

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

создание ограничений и правил в Constraint Manager в топологии ПП;

работа с Xpedition xDX Variant Manager;

способы трассировки топологии ПП;

Стр. 32 из 71


интерактивная трассировка AutoActive;

параллельная работа в Xpedition xPCB Team Layout;

способы верификации проекта топологии ПП;

работа с DRC (модулем);

оптимизация выводов ПЛИС I/O Designer;

создание системы на нескольких платах Xpedition xSD Systems Designer;

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

двусторонний обмен данными с 3D;

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

решение задач теплового анализа РЭА, печатных плат и микроэлектронных

компонентов и на изделие в целом;

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

4.2.9 Подсистема технологической подготовки производства (ТПП)

В Подсистеме ТПП должна быть обеспечена следующая функциональность:

ведение технологического состава изделия;

управление атрибутивной информацией объектов системы в виде строковых,

числовых значений и значений в формате даты;

предоставление доступа к электронной КД и ТД всем пользователям,

участвующим в эксплуатации системы в соответствии с правами доступа;

обеспечение создания и хранения электронных ТД для просмотра без

возможности редактирования, в соответствии с правами доступа;

обеспечение визуального просмотра электронной КД и ТД на экране монитора;

предоставление информации о входимости (применяемости) КСЕ, ТСЕ и

деталей в других изделиях;

Подсистема ТПП должна обеспечивать:

в части ведения технологического состава изделия:

- формирование ТСИ на основе конструкторской структуры изделия

(КСИ) с учетом расположения компонентов в изделии, при этом

СЧ технологической структуры должны содержать те же атрибуты

и информацию, что и СЧ конструкторской структуры;

- возможность добавления в ТСИ дополнительных технологических

элементов в виде технологических деталей;

- возможность отображение технологической ЭСИ полным списком

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

уровнях её иерархии;

Стр. 33 из 71


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

посредством связей между составными частями;

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

изделий или сборочных единиц на наличие общих СЧ или для

оценки различий в их составах;

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

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

- *согласование, утверждение и аннулирование технологической

ЭСИ в электронной форме.

в части разработки сквозного технологического маршрута:

- разработка, управление и изменение маршрутных и

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

должны осуществляться в соответствии с внутренней

нормативной документацией Заказчика;

- разработка маршрутной и операционной технологии должна

осуществляться на основе ТСИ/КСИ;

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

межцехового технологического маршрута (цехозахода) и

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

выполняемых работ;

- сквозной маршрут должен быть ассоциативно связан с ТСЕ или

ДСЕ;

- возможность разрабатывать сквозной маршрут на основе ранее

предопределенных шаблонов сквозных маршрутов,

технологических процессов, операций, переходов;

- сквозной маршрут должен позволять хранить следующую

информацию:

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

документах; последовательность цехозаходов; ссылку о материале или заготовке; трудоемкость; статус.

- цехозаход должен позволять хранить следующую информацию:

атрибуты;

Стр. 34 из 71


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

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

- операция технологического процесса должна позволять хранить

следующую информацию:

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

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

местах; файлы технологических эскизов (различных CAD – систем); последовательность переходов, их описание, информацию

об СТО и материалах на переход; трудоемкость; статус.

- создание временных маршрутов с возможностью задания срока

их действия;

- возможность создания маршрутов и внесения изменений в

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

серийных номеров изделий;

- возможность создания параллельных (альтернативных)

маршрутов;

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

процессов;

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

диаграммы Ганта;

- организация процедур выпуска и внесение изменений в ТД,

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

виде стандартными средствами PDM-системы посредством

рабочих процессов.

В части трудового и материального нормирования, Подсистема ТПП должна

обеспечивать:

- выполнять автоматизированный расчет норм времени:

расчет вспомогательного времени; расчет подготовительно-заключительного времени;

Стр. 35 из 71


расчёт основного времени на операцию; расчет трудовых норм на операцию, цехозаход, сквозной

маршрут; расчет штучного времени и штучно-калькуляционного на

операцию с учетом коэффициентов штучного времени и серийности;

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

- определение трудовых норм времени по нормировочным

таблицам;

- использование при расчётах поправочных коэффициентов на

штучное время и серийность;

- возможность трудового нормирования как при разработке

технологического процесса, так и на основании уже

разработанного ранее технологического процесса;

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

электронной форме;

- расчет норм расхода вспомогательных материалов (не более 40

формул) на операции технологического процесса;

- расчет трудовых норм должен осуществляться на основе

справочников, внесенных в подсистему ТПП;

- работу с составными материалами.

В части отчетной документации, Подсистема ТПП должна обеспечивать:

- автоматизированное формирование технологической

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

сквозного маршрута;

- формирование ИИ и ПР в отдельном пользовательском

интерфейсе в соответствии с учетом требований ГОСТ 2.503.

*В части рабочих процессов, Подсистема ТПП должна обеспечить

функционирование не более десяти отдельных рабочих процессов (Workflow), в

том числе указанных ниже (см. Таблица 1)

Таблица 1 – Перечень рабочих процессов по подсистеме ТПП

№ Название рабочего процесса

1 *Запуск КД в производство

2 *Разработка и согласование ТП

Стр. 36 из 71


3 *Внесение изменений по ИИ в ТП

4 *Выпуск технологического предложения (Отчет о проблеме)

5 *Выпуск предложения об изменении

6 *Разработка оснастки

7 *Разработка и согласование ТТП

8 *Внесение изменений по ИИ в ТТП

4.2.10 *Подсистема производственного планирования

*Подсистема производственного планирования должна обеспечивать:

*в части подготовки производственных нормативов:

- *определение продолжительности выполнения этапов

производства (цехозаходов) с учетом организационных и иных

временных потерь;

- *ввод параметров разбиения заказанного количества

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

центров.

*в части планирования производства в виде сочетания объемно-календарных

планов производства и позаказного планирования с точностью до цехозаходов

и (опционально) внутрицеховых производственных расписаний (межцеховой

уровень).

*Схема процесса межцехового планирования представлена ниже (см. Рисунок 1)

Стр. 37 из 71


Рисунок 1- Схема процесса межцехового производственного планирования

Стр. 38 из 71


- *Долгосрочный объемно-календарный план

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

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

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

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

*после актуализации планов должны создаваться «Заказы на производство», дата выпуска которых должна попадать в актуализированный горизонт;

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

- *График производства

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

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

Стр. 39 из 70


*для каждого этапа производства должно определяться подразделение-исполнитель, дата начала и окончания производства, формироваться потребность в материальных ресурсах (сырье, материалах, полуфабрикатах), а также «заниматься» определенная часть мощности оборудования на ту же дату;

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

- *График подготовки производства

*формировать в подсистеме графики с плановой загрузкой сотрудников на разработку КД и ТД

*в части управления запасами и обеспечением производства

- *для покупных материалов и ДСЕ, а также для

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

графика производства в системе должна формироваться

информация о потребностях;

- *для каждой номенклатуры и склада (подразделения) в

системе должен быть определен источник и способ

обеспечения (если закупка – то у какого контрагента, если

производство – то в каком цехе, если складское

перемещение – то с какого склада);

- *определять потребность в обеспечении оснасткой и

трудовыми ресурсами на основании данных графика

производства.

*в части учета факта выполнения работ

- *учет факта выполнения работ по заказам должен

выполняться в разрезе этапов производства

(цехозаходов) с одновременным отражением

производственных материальных затрат и регистрацией

выработки сотрудников (для последующего расчета

сдельной зарплаты и для аналитических целей) по

каждому этапу;

- *учет факта выполнения работ по разработке КД и ТД;

Стр. 40 из 70


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

анализа себестоимости производства в разрезе заказов и

подразделений-исполнителей;

- *должен быть реализован учет производственных затрат и

обособленный учет ТМЦ согласно требований 275ФЗ.

- **при ведении пооперационного учета на внутрицеховом

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

технологических операций.

*в части учета факта движения ТМЦ в производстве обеспечить учет:

- *поступления на склад производственного подразделения

материалов и покупных ДСЕ;

- *внутреннего движение ТМЦ, включая межскладские

перемещения и передачу выпущенных полуфабрикатов

между подразделениями;

- *отгрузки готовой продукции с производственного склада

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

сборку которых должен выполнять пользователь.

4.2.11 **Подсистема подготовки и сопровождения эксплуатационной документации

**Подсистема подготовки и сопровождения эксплуатационной

документации (СМS) должна обеспечивать возможность разработки и публикации

эксплуатационной документации на изделия в соответствии с заданными

стандартами на основе конструктивного состава изделия. Подсистема должна

функционировать в тесной интеграции с подсистемой PDM (в том числе работать

с электронными структурами изделия, хранящимися в PDM, и использовать

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

подсистемой НСИ (использовать единые классификаторы и библиотеки

материалов, стандартных изделий, покупных изделий и т.п).

**В комплект ЭД должны входить следующие документы:

**руководство по эксплуатации;

**руководство по обслуживанию;

**каталог деталей и сборочных единиц

Стр. 41 из 70


**С точки зрения организации параллельной работы разработчиков

электронной эксплуатационной документации Подсистема CMS должна

обеспечивать:

**определение ролей пользователей и разграничение прав доступа

конкретного пользователя Подсистемы CMS объектам подсистемы

PDM и подсистемы CMS;

**оповещение разработчиков ЭД о прошедших изменениях в

конструкторской документации.

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

CMS должна обеспечивать:

**создание модулей данных как основной информационной единицы

при создании эксплуатационной документации;

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

документов и модулей данных;

**интерактивные ссылки внутри текста создаваемого документа (на

позиции, на рисунки, на модули данных, на таблицы, на области

изображения);

**ссылки на материалы и инструменты, необходимые при

проведении работ;

**сквозные изменения во всем документе (изменилось обозначение

детали / компонента - значит его нужно поменять во всех местах

упоминания в тексте);

**ссылочное дублирование части одного модуля данных в части

другого модуля данных;

**автоматизацию процессов отслеживания изменений в КД, которые

повлекут изменения в ЭД;

**автоматизацию процессов внесения изменений в ЭД:

- **изменение обозначения объекта КД должно повлечь за

собой изменение обозначения ссылки (в том числе и

позиций выносок) во всех документах ЭД;

- **изменение конструкции объекта КД должно повлечь за

собой изменение иллюстраций во всех документах ЭД, на

которых изображен объект;

- **перед внесением изменений в ЭД необходимо

Стр. 42 из 70


организовать процедуру принятия или отклонения

автором решения об изменении.

**сборку единого документа, готового к публикации, из отдельных

частей (модулей данных);

**возможность вывода документа в формат pdf в соответствии с

выбранным стандартом публикации;

**формирование общей (единой) базы данных электронной

эксплуатационной документации;

**управление данными контента - создание, изменение и удаление

элементов контента;

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

**управление доступом к данным контента (режим чтение/запись,

блокировки);

**синхронизация данных между элементами контента и исходными

данными;

**управление шаблонами и таблицами стилей;

**управление и создание репозитория терминов, определений,

единиц измерения, аббревиатур;

**поддержку формирования документов с использованием

различных языков (переводов документации);

**отслеживание версионности модулей данных и ведение журнала

извещений об изменениях;

**возможность просмотра инструкций по обслуживанию изделий в

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

пользователь.

4.2.12 Подсистема интеграционного решения

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

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

Стр. 43 из 71


Рисунок 2- Схема взаимодействия подсистем КИПР

Стр. 44 из 71


Описание взаимодействия подсистем КИПР:

УП-PDM:

- экспорт в PDM заданий по работам на проектах с

помощью настроенных рабочих процессов между PLM-

системой и 1С

- импорт из PDM данных о выполненных работах на

проектах с помощью настроенных рабочих процессов

между PLM-системой и 1С

УТ-PDM:

- экспорт в PDM требований к изделию;

- импорт из PDM запросов на изменение требований к

изделию

PDM-CMS:

- экспорт в CMS КД и ТД;

- импорт из CMS ЭД

PDM-CAD:

- экспорт в CAD заданий, связанных с разработкой и

изменением КД;

- импорт из CAD электронной модели и структуры изделия

PDM-ECAD:

- экспорт в ECAD заданий, связанных с выпуском и


- импорт из ECAD:

проект сборки/подсборки; проект сборки/ подсборки (файл); состав сборки/ подсборки

PDM-ППП:

- экспорт в ППП заданий, связанных с выпуском и


- импорт из ППП:

проект сборки/подсборки; проект сборки/ подсборки (файл); состав сборки/ подсборки

PDM-ТПП:

- экспорт в ТПП:

Стр. 45 из 70


заданий, связанных с выпуском и изменением ТД; КД

- импорт из ТПП:

ТД; технологический состав изделия

ТПП-Производственное планирование:

- экспорт в Производственное планирование:

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

технологическом процессе (оборудование, оснастка, профессии и др.)

CAD-НСИ:

- экспорт в НСИ:

заявки на создание НСИ; 3-D модели НСИ

- импорт из НСИ объектов используемых при

проектировании изделия (материалы, СтИ, ПКИ)

ECAD-НСИ:

- экспорт в НСИ:

заявки на создание НСИ; покупные изделия



ППП-НСИ:

- экспорт в НСИ заявок на создание НСИ;



ТПП-НСИ:

- экспорт в НСИ заявок на создание НСИ;

- импорт из НСИ объектов используемых при при

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

оборудование, профессии, оснастка и др)

НСИ-Производственное планирование:

Стр. 46 из 70


- экспорт в производственное планирование данных по

справочникам, кроме справочников профессий и

структурных подразделений;

- импорт из производственного планирования данных по

справочникам профессий и структурных подразделений

4.2.13 Временной регламент реализации каждой функцией системы

Требования к временному регламенту реализации функций КИПР, задач

или комплексов задач не предъявляются.

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

Качество реализации функций КИПР должно обеспечивать полное

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

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

результатов.

Требования к форме представления выходной информации,

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

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

в проектной документации на КИПР.

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

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

следующим группам:

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

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

В группу функций с заданными требованиями по обеспечению надежности

входят функции, выполняющие операции по изменению, удалению и вводу

данных в КИПР.

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

надежности относятся все остальные функции КИПР.

Отказом является невозможность корректного выполнения функции или

завершения операции с успешным признаком.

Стр. 47 из 70


Критерием отказа является нарушение функционирования и

невозможность реализации функциональных требований к КИПР.

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

предъявляются следующие требования:

работа в режиме транзакционного изменения данных в базе данных

с откатом всех изменений при неуспешном завершении;

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

возможность сохранения изменений (включая создание, изменение,

удаление) данных без статуса.

При сохранении изменений данных должна сохраняться следующая

информация:

идентификатор пользователя, изменившего данные;

время и дата изменения;

идентификатор рабочей станции, с которого были выполнены

изменения.

К группе функций без специальных требований дополнительных

требований по обеспечению надежности не предъявляется.

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

обеспечению надежности должен разрабатываться и утверждаться в составе

проектной документации.

4.3 Требования к видам обеспечения

4.3.1 Требования к математическому обеспечению

Требования к математическому обеспечению КИПР не предъявляются.

4.3.2 Требования к информационному обеспечению системы

6.1.1.11 Требование к составу, структуре и способам организации данных системы

Архитектура программно-технического комплекса КИПР должна

предусматривать централизованное хранение данных с возможностью

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

Подробнее про архитектуру каждой подсистемы КИПР должно быть

описано в Частном техническом задании на каждую подсистему КИПР.

Стр. 48 из 70


6.1.1.12 Требования к информационному обмену между компонентами системы

Обмен информацией должен осуществляться в общесистемной среде

ЛВС, средства для передачи данных по телекоммуникационным сетям для

обеспечения удаленного обмена между подсистемами КИПР по стандартным

протоколам.

6.1.1.13 Требования к информационной совместимости со смежными системами

В КИПР должен быть реализован принцип открытой архитектуры

построения системы. КИПР должна иметь открытый интерфейс для развития и

интеграции.

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

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

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

системам.

6.1.1.14 Требования по применению систем управления базами данныхДля хранения информации и доступа к базам данных КИПР должна

использоваться система управления базами данных (СУБД) SQL.

6.1.1.15 Требования к структуре процесса сбора, обработки и передачи данных в системе и представлению данных

Сбор данных в КИПР должен обеспечиваться путем загрузки и ручного

ввода первичных документов.

КИПР должно обеспечивать экспорт/загрузку получаемых извне данных,

обеспечивать контроль целостности электронного документа в процессе

прохождения (обработки и передачи) в соответствии с настраиваемой моделью

состояний (статусной моделью) и полномочиями по его обработке или

подтверждению.

При представлении данных на экранных формах должна обеспечиваться

детализация по иерархии (понижение уровня отображения данных от сводных

показателей к детальной информации, являющейся базой свода – drill down).

Должна быть реализована возможность сохранения отчетов в виде

файлов. Состав таких отчетов должен быть уточнен в Частных технических

заданиях на каждую подсистему КИПР.

Стр. 49 из 70


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

Сохранность информации в КИПР должна обеспечиваться при всех

аварийных ситуациях.

В случае возникновения аварии или сбоя должно быть обеспечено

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

последней завершенной транзакции.

В случае повреждения журналов транзакций СУБД должно

обеспечиваться восстановление состояния КИПР на момент создания последней

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

6.1.1.17 Требования к контролю, хранению, обновлению и восстановлению данных

Предъявляются следующие требования:

для сохранения данных используется ежедневное резервное

копирование данных;

резервная копия данных должна храниться на магнитных или

оптических носителях;

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

СУБД и ОС и должна содержать восстановление с последней копии

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

6.1.1.18 Требования к приданию юридической силы документам, продуцируемым в системе

Юридическая значимость документов и их информационного обмена

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

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

договорами между Заказчиком и внешними организациями, являющимися

сторонами информационного обмена.

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

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

использование криптографических методов защиты информации.

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

документов, продуцируемых в КИПР при выполнении следующих операций:

ввод в КИПР документов, для которых обязательно подтверждение

авторства или подтверждение правомерности формирования

Стр. 50 из 70


документа в соответствии с внутренними положениями Заказчика,

законодательством Российской Федерации или другими

нормативными документами;

санкционирование определенных процессов (например,

импорт/экспорт данных) для обеспечения подтверждения

правомерности формирования документа и обеспечения

неотказуемости от совершенных действий Заказчиком в

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

договорами по обеспечению внешнего информационного обмена.

4.3.3 Требования к лингвистическому обеспечению

6.1.1.19 Требования к применению в системе языков программирования высокого уровня

ПО КИПР должно быть реализовано на языках высокого уровня.

Используемые при разработке языки должны обеспечивать решение всех

задач по реализации функций КИПР.

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

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

6.1.1.20 Требования к применению языков подготовки отчетовДля подготовки отчетов должен использоваться язык, позволяющий

проводить модификацию существующих и создание новых отчетов. Язык

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

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

форматов, таких, например, как текст (RTF), книга Excel (XLS), WEB-документ

(HTML) и (XML).

6.1.1.21 Требования к способам организации диалога с пользователемПользователи должны осуществлять взаимодействие с КИПР на уровне

графического пользовательского интерфейса.

6.1.1.22 Требования к языкам взаимодействия пользователя и технических средств

В качестве языка пользовательского интерфейса (наименование полей на

экранных формах, подсказки к этим полям, пользовательские и системные

сообщения, встроенная справка по системе и печатные выходные формы –

Стр. 51 из 70


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

сообщений, не подлежащих русификации.

6.1.1.23 Требования к языкам ввода-вывода данныхЯзыки ввода-вывода данных должны:

поддерживать реляционную и объектно-реляционную базы данных;

реализовывать SQL, совместимый со стандартом ANSI 1992 г.;

поддерживать стандарт ODBC.

6.1.1.24 Требования к языкам манипулирования даннымиЯзыки манипулирования данных должны отвечать требованиям стандарта

ANSI 1992г. (реализация SQL) и поддерживать реляционную и объектно-

реляционную модели баз данных, а также стандарт ODBC.

6.1.1.25 Требования к средствам описания предметной области (объекта автоматизации)

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

предметной области и объекта автоматизации, обеспечивающие

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

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

6.1.1.26 Требования к кодированию и декодированию данныхТребования к кодированию и декодированию данных не предъявляется.

Программное обеспечение КИПР должно быть реализовано на языках высокого

уровня.

4.3.4 Требования к программному обеспечению

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

Частных технических заданиях на каждую подсистему КИПР.

4.3.5 Требования к техническому обеспечению

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

Частных технических заданиях на каждую подсистему КИПР.

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

обеспечения КИПР должен быть не менее семи лет.

4.3.6 Требования к метрологическому обеспечению

К метрологическому обеспечению требования не предъявляются.

Стр. 52 из 70


4.3.7 Требования к организационному обеспечению

Организационное обеспечение должно определять:

порядок применения и функционирования КИПР;

действия должностных лиц по обеспечению применения КИПР;

действия обслуживающего персонала по поддержанию

работоспособности КИПР;

организацию и порядок проведения ремонта и восстановления

КИПР;

понятия источников и потребителей информации КИПР;

состав пользователей, являющихся потребителями информации;

перечень и виды информации взаимообмена в КИПР.

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

функционировании КИПР и обеспечивающих ее эксплуатацию, должны быть

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

внедрения КИПР:

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

обмена электронной технической документацией на каждую

подсистему КИПР;

руководство пользователя на каждую подсистему КИПР;

руководство администратора на каждую подсистему КИПР.

К защите от ошибочных действий персонала предъявляются следующие

требования:

КИПР должна строиться таким образом, чтобы ошибочные действия

персонала не привели к фатальным последствиям – разрушению и

невозможности её восстановления. С этой целью КИПР должна

быть разбита на подсистемы. Таким образом, сбой в одном

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

подсистем. КИПР в целом может потерять часть функционала, но

сохранить работоспособность;

при сбое в КИПР обмена электронными документами должна быть

предусмотрена возможность осуществлять обмен на съемных

электронных носителях информации;

с целью защиты КИПР должны быть созданы системы резервного

копирования и протоколирования действий;

Стр. 53 из 70


устанавливать жесткое соответствие вводимых данных

справочникам и классификаторам подсистемы;

проверять данные при вводе в зависимости от установленных

параметров контроля в подсистеме;

протоколировать действия пользователей;

позволять изменять только те данные, которые доступны

конкретному пользователю для корректировки;

обеспечивать ведение модели состояний для каждого типа

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

Стр. 54 из 70


5 Состав и содержание работ по созданию КИПР

Сроки начала и окончания выполнения работ по созданию КИПР

приведены в разделе 1.4.

Для ввода в эксплуатацию КИПР необходимо соблюдение установленных

требований и выполнение запланированных работ, приведенных в таблице (см.

Таблица 2).

Таблица 2 Стадии и этапы работ по созданию КИПР

Стадии Этапы работ Отчетные документы1 Технический проект

Разработка проектных решений

Частное техническое задание

2 Ввод КИПР в действие

- Подготовка объекта автоматизации к вводу КИПР в действие;

- Подготовка персонала;

- Программы семинаров;- Протоколы проведения

семинаров;- Программа и методика

приемочных испытаний;- Протокол приемочных испытаний;

Акт сдачи-приемки;

3 Сопровождение КИПР

- Выполнение работ в соответствии с гарантийными обязательствами;

- Послегарантийное обслуживание

- Акт о проведении работ

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

календарным планом.

Все работы должны быть выполнены в соответствии с действующим

законодательством РФ с обязательным выполнением норм и правил охраны

труда, пожарной безопасности и техники безопасности, производственной

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

нахождения на охраняемой территории (соблюдать режимные требования и

пропускной режим, установленные на объекте).

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

установлен Заказчиком.

5.1 Состав и содержание работ по КИПР

5.1.1 Состав разработки

Состав разработок при создании КИПР должен быть уточнен в Частном

техническом задании.

Стр. 55 из 70


Состав работ Исполнителем указан в настоящем ТЗ:

Реализация требований (см. п. 4.2);

Разработка и согласование документов (см. п. 5).

Стр. 56 из 70


6 Порядок контроля и приемки КИПР

6.1 Порядок контроля выполнения работ

В течение 5 дней с даты заключения договор Исполнитель должен

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

сроков завершения этапов работ с учетом этапов договора.

6.2 Виды, состав, объем и методы испытаний подсистемы и ее составных частей

Испытания каждой подсистемы КИПР должны быть организованы и

проведены в соответствии с ГОСТ 34.603-92.

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

КИПР:

предварительные испытания;

опытная эксплуатация;

приемочные испытания.

Результаты испытаний отражают в протоколе испытаний.

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

(невозможности) приемки подсистем КИПР в эксплуатацию, а также перечень

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

Решение о необходимости проведения дополнительных испытаний, состав

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


Предварительные испытания подсистем КИПР проводятся в соответствии

с Программой и методикой предварительных испытаний.

Опытная эксплуатация подсистем КИПР проводится в соответствии с

Программой опытной эксплуатации.

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

документации. Решение о допуске подсистем КИПР к предварительным

испытаниям принимается Заказчиком по итогам экспертизы качества

предъявленной документации. Возможен допуск подсистем КИПР к испытаниям

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

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


Стр. 57 из 70


Для проведения Испытаний должна быть организована комиссия в составе

представителей Исполнителя, представителей Заказчика, представителей

Функциональных заказчиков.

В ходе предварительных испытаний подсистем КИПР члены

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

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

КИПР и идентичности предъявленных решений их описанию в документации.

Для этого должны быть выполнены все или выборочные проверки

функциональности, дана оценка предъявленным документам, дано заключение о

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

описанием порядка, приведенным в Программе опытной эксплуатации, а также

подтверждена готовность предоставления в соответствии с планом-графиком

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

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

В случае неготовности подсистем КИПР к опытной эксплуатации в

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

подсистем КИПР и назначается дата проведения повторных предварительных

испытаний.

Число проводимых повторных предварительных испытаний не ограничено.

При этом за нарушение сроков завершения этапов договора Исполнитель несет

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

Завершение предварительных испытаний подсистем КИПР происходит на

основании Протокола предварительных испытаний подсистем КИПР после

подписания Акта о вводе в опытную эксплуатацию подсистем КИПР.

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

Развертывание подсистем КИПР и ее подготовку к опытной эксплуатации

обеспечивает Исполнитель. Сопровождение подсистем КИПР в период опытной

эксплуатации обеспечивает Исполнитель.

В ходе опытной эксплуатации Исполнитель обеспечивает прием и

регистрацию в Журнале опытной эксплуатации всех замечаний пользователей к

работе подсистем КИПР, а также, фиксирует в журнале опытной эксплуатации

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

Замечания пользователей к работе подсистем КИПР должны

классифицироваться по степени критичности для продолжения опытной

эксплуатации и их влияния на возможность запуска подсистем КИПР в

Стр. 58 из 70


промышленную эксплуатацию. Критичность замечаний устанавливается

пользователем, заявившим о наличии замечания, но может быть изменена в

процессе обработки по согласованию с Заказчиком.

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

подсистем КИПР должны также фиксироваться в Журнале опытной эксплуатации.

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

запуску в промышленную эксплуатацию, подсистемы КИПР находятся в опытной

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

перенесено Исполнителем на этап гарантийного обслуживания подсистем КИПР

после согласования перечня таких замечаний с Заказчиком.

По итогам проведения проверок, предусмотренных Программой опытной

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

проведении приемки подсистем КИПР. Приемка подсистем КИПР производится в

соответствии с Программой и методикой приемочных испытаний приемочной

комиссией в составе представителей Исполнителя, представителей Заказчика,

уполномоченных представителей пользователей, участвовавших в проведении

опытной эксплуатации.

В рамках приемки подсистем КИПР подводятся итоги опытной

эксплуатации и определяется готовность подсистем КИПР к промышленной

эксплуатации. В случае неготовности подсистем КИПР к промышленной

эксплуатации продлевается опытная эксплуатация и определяется условия и

сроки повторной приемки.

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

сроков завершения этапов договора Исполнитель несет ответственность согласно

условиям договора.

Завершение опытной эксплуатации происходит на основании Протокола

приемочных испытаний подсистем КИПР после подписания Акта о вводе

подсистем КИПР в промышленную эксплуатацию.

6.3 Общие требования к приемке работ по стадиям

Приемка результатов работ осуществляется поэтапно в соответствии с

календарным планом выполнения работ по договору.

До начала этапа «Опытная эксплуатация» Исполнитель передает

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

подсистемам КИПР, необходимых для ее развертывания и эксплуатации.

Стр. 59 из 70


Приемка результатов выполнения работ по этапам оформляется Актом

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

При проведении испытаний основанием для составления и подписания

Акта сдачи-приемки выполненных работ по этапу является наличие

утвержденного Заказчиком соответствующего Акта о вводе в эксплуатацию.

При передаче Заказчику программ для ЭВМ и баз данных, созданных при

выполнении работ, в виде исполняемого или объектного кода Исполнитель

должен также передать исходные тексты передаваемых программ и баз данных

на электронном носителе в формате, наиболее пригодном для осуществления их

модификации программно-техническими средствами Заказчика.

6.4 Сведения о гарантийном и послегарантийном обслуживании системы

Гарантийное обслуживание проводиться в течении 12 месяцев с момента

сдачи Исполнителем выполненных работ.

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

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

Исполнитель оказывает функциональную поддержку КИПР в течении

срока гарантийного обслуживания:

консультирование пользователей КИПР по вопросам

функционирования подсистем КИПР;

уведомление пользователей КИПР о внесенных в течении срока

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

возможности КИПР.

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

работоспособности КИПР силами Заказчика, специалисты Исполнителя должны

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

В случае изменения Заказчиком программного кода в течение

гарантийного срока эксплуатации без согласования с Исполнителем, гарантия на

программное обеспечение в отношении измененного модуля становится

недействительна.

Для сопровождения ПО в послегарантийный срок с Исполнителем может

быть заключен отдельный договор.

Стр. 60 из 70


6.5 Порядок выполнения доработок и устранения допущенных исполнителем ошибок, которые выявлены на стадии приемки

Недостатки и ошибки в реализации КИПР, выявленные в ходе проведения

испытаний, должны быть устранены Исполнителем в рамках выполнения работ по

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

должен быть определен в документах «Программа и методика предварительных

испытаний», «Программа и методика приемочных испытаний» и «Программа

опытной эксплуатации» на каждую подсистему КИПР. Сроки устранения

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

испытаний, определяются в Актах о вводе в эксплуатацию на каждую подсистему

КИПР.

Стр. 61 из 70


7 Требования к документированию

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

персональных компьютеров сотрудников Проектной группы со стороны

Исполнителя и переносятся в соответствующие каталоги репозитария,

хранящиеся на проектном сервере. Обновление документов репозитария

выполняется не реже одного раза в неделю или по мере готовности и

согласования/утверждения проектных документов. Ответственными за

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

проектного репозитария являются все сотрудники Проектной группы со стороны

Исполнителя.

Заказчику должен быть передан полный комплект документации в двух

экземплярах:

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

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

электронном виде в формате «pdf» на электронном носителе

информации – флеш-накопителе.

Еще один экземпляр комплекта документации должен храниться у

Исполнителя.

Документация, передаваемая предприятию, является неотчуждаемой

собственностью предприятия. Текстовые документы должны быть оформлены в

соответствии с ГОСТ 34.201-89, ГОСТ 34.602-89.

В состав проектной документации на КИПР должны войти следующие

документы:

Частное техническое задание

В комплект рабочей документации на КИПР должны войти следующие

документы:

*руководство пользователя на каждую роль в КИПР;

*руководство администратора на каждую подсистему;

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

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

Заказчик).

Заказчику (в рамках пилотного проекта и в рамках финального проекта)

передается полный пакет документов в бумажном и электронном виде на КИПР:

частное техническое задание;

Стр. 62 из 70


*руководство пользователя каждую роль в КИПР;

*руководство администратора на каждую подсистему;

программа и методика предварительных испытаний КИПР;

программа и методика приемочных испытаний КИПР;

*программа опытной эксплуатации КИПР;

программы обучения;

протокол предварительных испытаний;

протокол приемочных испытаний;

протоколы обучения персонала и проверки его способности

обеспечить функционирование КИПР в части касающейся

Исполнителя;

акт сдачи-приемки КИПР;

акт о вводе в ОЭ КИПР;

акт о вводе в ПЭ КИПР;

*журнал ОЭ;

акт о проведении работ.

Микрофильмирование документации не требуется.

.

Стр. 63 из 70


8 Требования к результату работ

Результатом реализации Проекта по внедрению КИПР являются:

программно-аппаратный комплекс, который соответствует

требованиям ТЗ, включая лицензии на ПО;

развернута и настроена подсистемы КИПР в соответствии с ЧТЗ на

каждую подсистему КИПР;

документация соответствует требованиям данного ТЗ (раздел 7);

проведенные испытания подсистем КИПР и опытная эксплуатация

признаны успешными, что подтверждено соответствующими актами.

При передаче Заказчику программ для ЭВМ и баз данных, созданных при

выполнении работ, в виде исполняемого или объектного кода Исполнитель

должен также передать исходные тексты передаваемых программ и баз данных

на электронном носителе в формате, наиболее пригодном для осуществления их

модификации программно-техническими средствами Заказчика.

Комплект документации (см. раздел 7), акты и протоколы должны быть

переданы Заказчику на электронном носителе информации – флеш-накопителе в

формате «pdf». Так же комплект документации, акты и протоколы должны быть

переданы в бумажном виде.

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

заводской номер электронного носителя информации, на котором он передается.

Установленные и настроенные подсистемы КИПР по результатам

выполнения работ 4 этапа «Ввод подсистемы в действие» должны

соответствовать требованиям настоящего ТЗ и ЧТЗ на каждую подсистему КИПР

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

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

настоящем ТЗ.

Стр. 64 из 70


9 Требования к организации работ на территории Заказчика

Исполнитель должен не позднее 1 (одного) рабочего дня до выполнения работ на территории Заказчика предоставить и согласовывать график их проведения. Работы должны проводиться в рабочее время, по следующему графику: понедельник – четверг с 9.30 до 17.30 пятница с 9.30 до 16.30 по МСК.

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

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

на одного сотрудника должно приходиться не менее 5 м2 площади

рабочей комнаты, рабочее место каждого сотрудника должно быть

обеспечено:

отдельным рабочим столом;

стулом;

двумя розетками электрической сети;

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

одной розеткой для доступа в телефонную сеть (по

дополнительному обоснованию);

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

возможностью двухсторонней печати на листах формата А4 и

скоростью печати не менее 30 страниц в минуту;

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

копирования листов формата А4 и автоматической подачей листов

оригинала;

наличие вешалок для верхней одежды всех сотрудников,

размещенных в рабочей комнате;

наличие одного шкафа для документов;

наличие стола для заседаний и стульев;

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

Стр. 65 из 70


10 Источники разработки

При разработке настоящего ТЗ и создании КИПР используются следующие нормативно-технические документы:

ГОСТ 3.1102-2011 ЕСТД. Стадии разработки и виды документов

ГОСТ 6.10.4-84 Унифицированные системы документации. Придание юридической силы документам на машинном носителе и машинограмме, создаваемым средствами вычислительной техники

ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов

ГОСТ 19.103-77 ЕСПД. Обозначения программ и программных документов

ГОСТ 19.104-78 ЕСПД. Основные надписи

ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

ГОСТ 19.402-78 ЕСПД. Описание программы

ГОСТ 19.601-78 ЕСПД. Общие правила дублирования, учета и хранения

ГОСТ 19.602-78 ЕСПД. Правила дублирования, учета и хранения программных документов, выполненных печатным способом

ГОСТ 24.701-86 Единая система стандартов автоматизированных систем управления. Надежность автоматизированных систем управления. Основные положения

ГОСТ 26.205-88 Комплексы и устройства телемеханики. Общие технические условия

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

ГОСТ 34.601-90 Автоматизированные системы. Стадии создания

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

Стр. 66 из 70


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

ГОСТ 34.603-92 Виды испытаний автоматизированных систем

ГОСТ Р ИСО 10303-45-2012

Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 45. Интегрированный обобщенный ресурс. Материал и другие технические характеристики

СаНПиН 2.2.2/2.4.1340-03

Гигиенические требования к персональным электронно-вычислительным машинам и организации работы

Стр. 67 из 70


11 Список используемых терминов и сокращений

Таблица 3. Термины

Термин Определение

Workflow Формализованные рабочие процессы и процедуры на различных стадиях жизненного цикла:

Выдача задания; Сдача-приёмка результата выполнения задания; Выпуск и проведение инженерного изменения; Согласования требований.

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

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

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

Стр. 68 из 70


Таблица 4. Сокращения

Сокращение Определение

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

CMS (от английского Content Managеment System, система управления содержимым) система по подготовке и сопровождению эксплуатационной документации

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

MS Microsoft

PLM Product Lifecycle Management – управление жизненным циклом изделия (ЖЦИ)

АО Акционерное общество

АРМ Автоматизированное рабочее место

АСК Абсолютная система координат

ВТ и СС Высокие технологии и стратегические системы

ГОСТ Государственный стандарт

ДИ Дополнительное извещение

ДПИ Дополнительное предварительное извещение

ДСЕ Деталь, сборочная единица

ДЭ Документ электронный

ЕСКД Единая система конструкторской документации

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

Стр. 69 из 70



ИИ Извещение об изменении

ИР Интеграционное решение

ИТ Информационные технологии

КД Конструкторская документация

КИПР Комплексное информационно-программное решение

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

КСЕ Конструкторская сборочная единица

КСИ Конструкторский состав изделия

КСПД Корпоративная сеть передачи данных

КТПП Конструкторско-технологическая подготовка производства

ЛВС Локально-вычислительная сеть

НПК Научно-промышленная компания

НСИ Нормативно-справочная информация

ОЭ Опытная эксплуатация

ПИ Предварительное извещение

ПКИ Покупные комплектующие изделия

ПО Программное обеспечение

ПП Печатная плата

ППП Проектирование печатных плат

ПР Предложение об изменении

ПЭ Промышленная эксплуатация

РСК Рабочая система координат

РЭА Радиоэлектронная аппаратура

СТО Средства технологического оснащения

Стр. 70 из 70



СТО Стандарт организации

СУБД Система управления базами данных

СЧ Составная часть

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

ТЗ Техническая задание

ТМЦ Товарно-материальные ценности

ТПП Технологическая подготовка производства

ТСЕ Технологическая сборочная единица

ТСИ Технологическая структура изделия

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

УГО Условные графические обозначения

УП Управление проектами

УТ Управление требованиями

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

ЭВМ Электронная вычислительная машина

ЭГМ Электронная геометрическая модель

ЭД Эксплуатационная документация

ЭКД Электронная конструкторская документация

ЭСИ Электронная структура изделия

ЭЦП Электронная цифровая подпись

СОГЛАСОВАНО

Заместитель главного конструктора

Д.Г. Медведев

«___»_________2020 г.

Директор по информационным технологиям

Д.В. Шлыков

«___»_________2020 г.

Стр. 71 из 70


Начальник КБ разработки антенных систем

А.С. Марьясов

«___»_________2020 г.

Руководитель НТЦ Синхронные системы радиосвязи

А.К. Ялин

«___»_________2020

Начальник производственного отдела

Д.В. Чмеренко

«___»_________2020

Начальник отдела технической экспертизы и нормоконтроля

С.Г. Бубнов

«___»_________2020

Руководитель проекта PLM

П.А. Филин

«___»_________2020

Руководитель проекта 1С ERP

И.В. Васильев

«___»_________2020

· web viewКомплектовочная карта КК ГОСТ 3.1102-2011 9 **Лист...

Documents