Требования к системе MDC: различия между версиями

Материал из О цифровизации и вообще
Строка 206: Строка 206:
Простой» («Нерегламентированный перерыв») – станок включен и готов к работе, но операции обработки/изготовления не выполняются, шпиндель не вращается в течение определённого времени по причине отсутствия оператора или отсутствия/несвоевременного ввода причины простоя.
Простой» («Нерегламентированный перерыв») – станок включен и готов к работе, но операции обработки/изготовления не выполняются, шпиндель не вращается в течение определённого времени по причине отсутствия оператора или отсутствия/несвоевременного ввода причины простоя.


·        «Станок выключен» – фиксируется при наличии сигнала от станка в положении ВЫКЛ.
«Станок выключен» – фиксируется при наличии сигнала от станка в положении ВЫКЛ.


·        «Наладка станка» («Производственный простой») – станок включен и готов к работе, производится замена приспособлений и заготовки обрабатываемой детали, наладка на операцию (станок находится в ручном режиме).
«Наладка станка» («Производственный простой») – станок включен и готов к работе, производится замена приспособлений и заготовки обрабатываемой детали, наладка на операцию (станок находится в ручном режиме).


·        «Измерение детали исполнителем» («Производственный простой») – станок включен и готов к работе, происходит контроль параметров изделия оператором в процессе выполнения программы обработки (процесс выполнения выбранной программы ЧПУ находится в режиме ожидания).
«Измерение детали исполнителем» («Производственный простой») – станок включен и готов к работе, происходит контроль параметров изделия оператором в процессе выполнения программы обработки (процесс выполнения выбранной программы ЧПУ находится в режиме ожидания).


·         «Нет данных» – фиксируется при отсутствии сигнала (обрыв сети, сбои ПО на станке).
«Нет данных» – фиксируется при отсутствии сигнала (обрыв сети, сбои ПО на станке).


При невозможности идентификации состояния оборудования у системы ЧПУ, данные состояния должны вводиться через терминал ручного ввода (киоск) посредством web-интерфейса ввода-вывода данных мониторинга.
При невозможности идентификации состояния оборудования у системы ЧПУ, данные состояния должны вводиться через терминал ручного ввода (киоск) посредством web-интерфейса ввода-вывода данных мониторинга.
Строка 218: Строка 218:
'''Дополнительные состояния:'''
'''Дополнительные состояния:'''


·        «Авария» («Технический простой») – отказ работы оборудования по причине поломок станка.
«Авария» («Технический простой») – отказ работы оборудования по причине поломок станка.


·        «Ремонт и ППР» («Технический простой») – ведется ремонт оборудования и/или планово-предупредительный ремонт.
«Ремонт и ППР» («Технический простой») – ведется ремонт оборудования и/или планово-предупредительный ремонт.


·        «Сбой станка» («Технический простой») – сбой электроавтоматики, гидравлики, ЧПУ, кратковременный скачок либо провал напряжения.
«Сбой станка» («Технический простой») – сбой электроавтоматики, гидравлики, ЧПУ, кратковременный скачок либо провал напряжения.


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


·        «Отсутствие материалов, заготовки» («Организационный простой») – станок включен и готов к работе, нет заготовок.
«Отсутствие материалов, заготовки» («Организационный простой») – станок включен и готов к работе, нет заготовок.


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


·        «Отсутствие оснастки» («Организационный простой») – станок включен и готов к работе, нет годной оснастки.
«Отсутствие оснастки» («Организационный простой») – станок включен и готов к работе, нет годной оснастки.


·        «Отсутствие ТП» («Организационный простой») – станок включен и готов к работе, нет технологического процесса (ТП), технического указания, а также ошибка в ТП, разногласие в ТП и УП и т.д.
«Отсутствие ТП» («Организационный простой») – станок включен и готов к работе, нет технологического процесса (ТП), технического указания, а также ошибка в ТП, разногласие в ТП и УП и т.д.


·        «Отсутствие УП» («Организационный простой») – станок включен и готов к работе, нет управляющей программы, ошибка в УП.
«Отсутствие УП» («Организационный простой») – станок включен и готов к работе, нет управляющей программы, ошибка в УП.


·        «Регламентированный перерыв» – станок включен и готов к работе, отсутствие исполнителя согласно расписанию перерывов, обед.
«Регламентированный перерыв» – станок включен и готов к работе, отсутствие исполнителя согласно расписанию перерывов, обед.




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


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


6.7.2.       Для фильтрации и группировки должны использоваться все поля базы данных подходящего типа.
# Подсистема отчетности должна позволять формировать аналитические отчеты в виде таблиц, диаграмм (линейных графиков, графиков с заполнением, круговых диаграмм, дашбордов (спидометров)) для вывода на экран, для печати.
# Для фильтрации и группировки должны использоваться все поля базы данных подходящего типа.
# При формировании стандартных аналитических отчетов должна быть возможность учета графика работы оборудования с учетом рабочих смен (дневных, вечерних, ночных) и выходных и / или праздничных дней.
# Система должна позволять создавать/изменять отчеты с использованием любой информации из журналов и справочников без кодирования.
# Страницы (панели отчетов) должны позволять размещать отчеты в любых комбинациях.
# Отчеты должны просматриваться как из системы, так и экспортироваться в формат PDF. Отчеты, формируемые в табличном виде, должны экспортироваться в формат xls или xlsx.
# Система должна иметь встроенный механизм для автоматического формирования и рассылки отчетности по расписанию или по событию.
# Отчеты должны отправляться получателям по электронной почте (письма с вложениями). Параметры подключения и шаблоны для отправки писем должны настраиваться без доработки ПО.
# При внедрении Системы должны быть реализованы отчеты, указанные в приложении №2 Каталог отчетов.


6.7.3.       При формировании стандартных аналитических отчетов должна быть возможность учета графика работы оборудования с учетом рабочих смен (дневных, вечерних, ночных) и выходных и / или праздничных дней.
== Требования к преднастроенным отчетам ==
В системе мониторинга должны быть предусмотрены аналитические отчеты о работе оборудования и производственного персонала.


6.7.4.       Система должна позволять создавать/изменять отчеты с использованием любой информации из журналов и справочников без кодирования.
Входными параметрами для формирования аналитических отчетов должны быть:


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


6.7.6.       Отчеты должны просматриваться как из системы, так и экспортироваться в формат PDF. Отчеты, формируемые в табличном виде, должны экспортироваться в формат xls или xlsx.
При формировании отчетов должен учитываться график работы оборудования с учетом рабочих смен (дневных. вечерних. ночных) и выходных и/или праздничных дней.


6.7.7.       Система должна иметь встроенный механизм для автоматического формирования и рассылки отчетности по расписанию или по событию.
В отчетах вместе с итоговыми данными должны отображаться ключевые показатели эффективности (КПЭ). Пользователи должны иметь возможность настройки основных КПЭ, приведенных ниже, а также формировать собственные КПЭ.


6.7.8.       Отчеты должны отправляться получателям по электронной почте (письма с вложениями). Параметры подключения и шаблоны для отправки писем должны настраиваться без доработки ПО.
== Преднастроенные отчеты ==
 
6.7.9.       При внедрении Системы должны быть реализованы отчеты, указанные в приложении №2 Каталог отчетов.
 
== 6.8       Требования к преднастроенным отчетам ==
6.8.1.       В системе мониторинга должны быть предусмотрены аналитические отчеты о работе оборудования и производственного персонала.
 
6.8.2.       Входными параметрами для формирования аналитических отчетов должны быть:
 
·        Временной интервал для формирования отчета - за определенный период времени (смена, день, месяц, год).
 
·        Подразделение (или по всем подразделениям).
 
·        Станок (или по всем станкам).
 
·        Оператор.
 
6.8.3.       При формировании отчетов должен учитываться график работы оборудования с учетом рабочих смен (дневных. вечерних. ночных) и выходных и/или праздничных дней.
 
6.8.4.       В отчетах вместе с итоговыми данными должны отображаться ключевые показатели эффективности (КПЭ). Пользователи должны иметь возможность настройки основных КПЭ, приведенных ниже, а также формировать собственные КПЭ.
 
== 6.9       Анализ общей эффективности оборудования ОЕЕ ==
6.9.1.       Система мониторинга должна обеспечивать расчет общей эффективности оборудования (ОЕЕ) как произведение трех составляющих:
 
А —  доступность или загрузка оборудования:
 
Р — производительность оборудования;
 
О — качество работ на оборудовании.
 
Методика расчета ОEE должна соответствовать ГОСТ Р 22400-2 - 2016.
 
6.9.2.       Система мониторинга должна предоставлять возможность ведения расчета ОБЕ как по преднастроенной методике с заданными формулами для определения основных показателей ОЕЕ, так и возможность изменять вариант расчета каждого показателя ОЕЕ в зависимости от методики расчета общей эффективности работы оборудования, принятой на предприятии.
 
6.9.3.       В системе мониторинга должен быть реализован механизм анализа показателя ОЕЕ как по предприятию в целом, так и по подразделению или станку. Необходимо реализовать возможность анализа динамики изменения ОЕЕ за произвольно выбранный период.
 
== 6.10   Преднастроенные отчеты ==
Перечень преднастроенных отчетов:
Перечень преднастроенных отчетов:


·        Отчет о загрузке оборудования.
* Отчет о загрузке оборудования.
* Отчет о работе и простоях оборудования.
* Отчет о работе операторов оборудования.


·        Отчет о работе и простоях оборудования.
== Мобильный мониторинг ==
 
·        Отчет о работе операторов оборудования.
 
== 6.11   Мобильный мониторинг ==
Пользователям должна быть предоставлена возможность работы с данными мониторинга на мобильных устройствах (смартфонах, планшетах) с помощью веб-интерфейса или мобильного приложения, а именно:
Пользователям должна быть предоставлена возможность работы с данными мониторинга на мобильных устройствах (смартфонах, планшетах) с помощью веб-интерфейса или мобильного приложения, а именно:


·        Получать данные о работе оборудования в реальном времени с отображением состояния каждого станка, обрабатываемой на станке детали, а также оператора, который в данный момент осуществляет работу на станке.
* Получать данные о работе оборудования в реальном времени с отображением состояния каждого станка, обрабатываемой на станке детали, а также оператора, который в данный момент осуществляет работу на станке.
 
* Отображать сводный анализ о работе оборудования за текущую смену и за любой заданный период (состояния. причины простоев) по предприятию в целом. по подразделениям, по станкам.
·        Отображать сводный анализ о работе оборудования за текущую смену и за любой заданный период (состояния. причины простоев) по предприятию в целом. по подразделениям, по станкам.
 
== 6.12   Управление программами для станков с ЧПУ ==
6.12.1.    Система мониторинга должна обеспечивать загрузку управляющих программ (УП) для станков с ЧПУ по локальной сети и ведения хранилища таких УП.


6.12.2.    Оператор должен с помощью АРМ иметь возможность запроса УП на станок либо по имени (номеру) УП, либо по технологической операции, за которой закреплена данная УП.
== Управление программами для станков с ЧПУ ==


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


6.12.4.    УП должны помещаться в промежуточный каталог и сверяться с эталоном УП.
== Администрирование и самодиагностика ==


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


== 6.13   Администрирование и самодиагностика ==
== Требования к интеграции ==
6.13.1.    В системе мониторинга должны быть предусмотрены средства администрирования и самодиагностики, обеспечивающие надежности функционирования для целей оперативного автоматизированного реагирования на проблемы, возникающие при работе системы мониторинга. При этом должны отслеживаться нештатные ситуации (ошибки, сбои) программного обеспечения системы мониторинга.
 
6.13.2.    В случае возникновения нештатных ситуаций ответственные пользователи должны уведомляться о событии по электронной почте, SMS или всплывающими сообщениями.
 
== 6.14   Требования к интеграции ==
''Указать требования к интеграции со смежными информационными системами компании.''
''Указать требования к интеграции со смежными информационными системами компании.''


== 6.15   Требования к аппаратному обеспечению (датчикам, контроллерам, промышленным сетям). ==
== Требования к аппаратному обеспечению (датчикам, контроллерам, промышленным сетям). ==
''Указать требования к оборудованию, которое должно быть поставлено в рамках настоящего задания.''
''Указать требования к оборудованию, которое должно быть поставлено в рамках настоящего задания.''


== 6.16   Технические требования ==
== Технические требования ==
Система должна:
Система должна:


6.16.1.    быть выполнена в трехзвенной архитектуре;
* быть выполнена в трехзвенной архитектуре;
 
* сервер приложений и СУБД должны поддерживать как минимум одну из следующих ОС: Astra Linux (ГК «Астра»), ОС «Альт» («БазАльт СПО») и «Ред ОС» («Ред Софт»);
6.16.2.    сервер приложений и СУБД должны поддерживать как минимум одну из следующих ОС: Astra Linux (ГК «Астра»), ОС «Альт» («БазАльт СПО») и «Ред ОС» («Ред Софт»);
* использовать для функционирования СУБД, внесенную в реестр <nowiki>https://reestr.digital.gov.ru/</nowiki>, либо их версии СПО, либо интегрированную в Систему СУБД.
 
* поддерживать работу в виртуализированной среде;
6.16.3.    использовать для функционирования СУБД, внесенную в реестр <nowiki>https://reestr.digital.gov.ru/</nowiki>, либо их версии СПО, либо интегрированную в Систему СУБД.
* клиентское приложение должно иметь вариант исполнения в виде веб-сервиса и должно функционировать на браузере Яндекс.
 
6.16.4.    поддерживать работу в виртуализированной среде;


6.16.5.    клиентское приложение должно иметь вариант исполнения в виде веб-сервиса и должно функционировать на браузере Яндекс.
== Требования к защите информации ==
 
= 7             Требования к защите информации =
''Далее приведен полный перечень документации для систем класса SCADA с возможностью управления или влиянием на работу оборудования. Для систем класса MDC или SCADA без подключения к управляющим контурам список требуемых документов целесообразно сократить до необходимого минимума.''
''Далее приведен полный перечень документации для систем класса SCADA с возможностью управления или влиянием на работу оборудования. Для систем класса MDC или SCADA без подключения к управляющим контурам список требуемых документов целесообразно сократить до необходимого минимума.''


В рамках разработки системы защиты информации должна быть разработана следующая документация.
В рамках разработки системы защиты информации должна быть разработана следующая документация.


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


Исполнитель должен обеспечить надлежащий уровень защиты информации в СМПИО в соответствии с разработанной документацией.
Исполнитель должен обеспечить надлежащий уровень защиты информации в СМПИО в соответствии с разработанной документацией.


= 8             Требования к работам по установке датчиков и контроллеров =
== Требования к работам по установке датчиков и контроллеров ==
''Указать требования к работам по установке датчиков и контроллеров.''  
''Указать требования к работам по установке датчиков и контроллеров.''


= 9             Требования к работам по настройке программного обеспечения =
== Требования к работам по настройке программного обеспечения ==
''Указать требования по настройке программного обеспечения.''
''Указать требования по настройке программного обеспечения.''


= 10        Требования к документированию =
== Требования к документированию ==
Исполнитель должен предоставить:
Исполнитель должен предоставить:


10.1.  Техническую документацию, полно описывающую архитектуру, функции и возможности Системы.
* Техническую документацию, полно описывающую архитектуру, функции и возможности Системы.
* Эксплуатационную документацию, в т.ч. паспорт системы.
* Руководство по подключению оборудования к СМПИО.
* Инструкции пользователей по ролям.


10.2Эксплуатационную документацию, в т.ч. паспорт системы.
== Требования к обучению пользователей ==
Исполнитель должен провести обучение пользователей по предоставленному  Заказчиком спискуПо итогам обучения должно быть проведено тестирование пользователей на знание системы.


10.3.  Руководство по подключению оборудования к СМПИО.
Вопросы и материалы тестирования должны быть предварительно согласованы с заказчиком.


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


= 11        Требования к обучению пользователей =
Инструкции пользователей должны быть предоставлены до начала проведения обучения.
11.1.  Исполнитель должен провести обучение пользователей по предоставленному  Заказчиком списку.  По итогам обучения должно быть проведено тестирование пользователей на знание системы.


11.2.  Вопросы и материалы тестирования должны быть предварительно согласованы с заказчиком.
== Техническая поддержка ==
 
11.3.  По итогам обучения Исполнитель должен предоставить Заказчику записи видео обучения. В случае демонстрации на видео экрана или печатных материалов при обучении, изображения и текст должны быть хорошо различимы и читаемы.
 
11.4.  Инструкции пользователей должны быть предоставлены до начала проведения обучения.
 
= 12        Техническая поддержка =
Исполнитель должен в течение в течение 1 (одного) года от даты окончания работ по внедрению СМПИО оказывать Заказчику техническую поддержку:
Исполнитель должен в течение в течение 1 (одного) года от даты окончания работ по внедрению СМПИО оказывать Заказчику техническую поддержку:


·        проводить технические консультации по вопросам использования и обслуживания СМПИО;
* проводить технические консультации по вопросам использования и обслуживания СМПИО;
 
* оперативно решать инциденты с нарушением работоспособности серверной и клиентской частей СМПИО;
·        оперативно решать инциденты с нарушением работоспособности серверной и клиентской частей СМПИО;
* исправлять выявленные ошибки и/или устранять неисправности;
 
* предоставлять обновления программного обеспечения системы мониторинга.
·        исправлять выявленные ошибки и/или устранять неисправности;
 
·        предоставлять обновления программного обеспечения системы мониторинга.
 
= 13        Виды, состав и методы испытаний АС и ее составных частей =
 
== 13.1   Общие требования к испытаниям АС и ее составных частей ==
13.1.1.    Для проверки разработанного функционала АС устанавливаются следующие виды испытаний:
 
-       Предварительные.
 
-       Опытная эксплуатация.
 
-       Приемочные.
 
13.1.2.    По согласованию между Заказчиком и Подрядчиком предварительные испытания программных средств АС допускается проводить на технических средствах Подрядчика при создании условий получения достоверных результатов испытаний.
 
13.1.3.    АС должна пройти все виды испытаний и опытную эксплуатацию на объектах автоматизации в соответствии с требованиями настоящего ТЗ и ЧТЗ (при наличии).
 
13.1.4.    Для проведения испытаний Подрядчиком должна быть подготовлена Программа и методика испытаний (ПМИ), утверждаемая Заказчиком. ПМИ должна содержать сценарии испытаний.
 
13.1.5.    До начала проведения испытаний Подрядчиком должна быть выпущена пользовательская документация (руководство пользователя, руководства администратора)
 
13.1.6.    До начала проведения испытаний Подрядчик должен отладить и протестировать поставляемые технические и программные средства АС.
 
13.1.7.    До начала проведения испытаний Подрядчик должен провести инструктаж для персонала Заказчика, участвующего в испытаниях.
 
13.1.8.    До начала проведения испытаний АС должен быть определен объем исходных данных, необходимых для первоначальной загрузки в АС.
 
13.1.9.    Результаты испытаний должны оформляться Подрядчиком в виде Протокола испытаний и утверждаться Заказчиком.
 
13.1.10. Испытания АС могут проводиться дистанционно при согласовании Заказчиком.
 
== 13.2   Проведение предварительных испытаний ==
13.2.1.    Предварительные испытания АС проводятся с целью предварительной оценки соответствия АС требованиям настоящего ТЗ.
 
13.2.2.    Предварительные испытания проводятся с целью определения готовности АС к вводу в опытную эксплуатацию.
 
== 13.3   Проведение опытной эксплуатации ==
13.3.1.    Опытная эксплуатация АС проводится с целью:
 
-       Проверки правильности функционирования АС при выполнении всех функций и требования к АС, указанных в настоящем ТЗ;
 
-       Проверки готовности персонала к работе со средствами АС в условиях ее опытной эксплуатации;
 
-       Проверки полноты, содержания эксплуатационной документации на АС.
 
13.3.2.    Порядок проведения опытной эксплуатации АС устанавливается в соответствии со следующими условиями:
 
-       Опытная эксплуатация должна проводиться в соответствии с Программой опытной эксплуатации АС, разработанной Подрядчиком и утвержденной Заказчиком;
 
-       Для проведения ОЭ в АС должны быть заведены учетные записи пользователей, участвующих в ОЭ и настроены права доступа в соответствии с их пользовательскими ролями в АС;


-       Опытная эксплуатация должна проводиться на Продуктивном контуре, развернутом на вычислительных ресурсах Заказчика, в соответствии с разработанной документацией на АС;
== Виды, состав и методы испытаний АС и ее составных частей ==


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


-       Подрядчик должен обеспечить сопровождение опытной эксплуатации АС с момента сдачи АС в опытную эксплуатацию и до окончания опытной эксплуатации;
* Предварительные.
* Опытная эксплуатация.
* Приемочные.


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


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


13.3.4.    Все сведения должны фиксироваться в журнале опытной эксплуатации АС с указанием даты и ФИО ответственных лиц Заказчика, принимающих участие в ОЭ.
Для проведения испытаний Подрядчиком должна быть подготовлена Программа и методика испытаний (ПМИ), утверждаемая Заказчиком. ПМИ должна содержать сценарии испытаний.


13.3.5.    В журнал опытной эксплуатации АС также могут заноситься замечания пользователей АС и персонала по удобству эксплуатации АС.
До начала проведения испытаний Подрядчиком должна быть выпущена пользовательская документация (руководство пользователя, руководства администратора)


13.3.6.    В ходе проведения опытной эксплуатации АС, Подрядчиком проводится анализ сведений, внесенных в журнал опытной эксплуатации, АС, на соответствие их требованиям ТЗ и разработанной документации на АС, а также требованиям Программы ОЭ.
До начала проведения испытаний Подрядчик должен отладить и протестировать поставляемые технические и программные средства АС.


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


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


13.3.9.    По окончании опытной эксплуатации АС Подрядчик готовит Протокол устранения замечаний в ходе опытной эксплуатации АС и предоставляет его Заказчику.
Результаты испытаний должны оформляться Подрядчиком в виде Протокола испытаний и утверждаться Заказчиком.


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


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


·        Журнал опытной эксплуатации АС;
Предварительные испытания проводятся с целью определения готовности АС к вводу в опытную эксплуатацию.


·        Протокол устранения замечаний в ходе опытной эксплуатации АС;
== Проведение опытной эксплуатации ==
Опытная эксплуатация АС проводится с целью:


·        Доработанная АС и скорректированная документация на АС.
* Проверки правильности функционирования АС при выполнении всех функций и требования к АС, указанных в настоящем ТЗ;
* Проверки готовности персонала к работе со средствами АС в условиях ее опытной эксплуатации;
* Проверки полноты, содержания эксплуатационной документации на АС.


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


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


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


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


13.4.3.    Состав членов комиссии определяется Заказчиком.
В журнал опытной эксплуатации АС также могут заноситься замечания пользователей АС и персонала по удобству эксплуатации АС.


13.4.4.    В состав комиссии включаются представители Подрядчика.
В ходе проведения опытной эксплуатации АС, Подрядчиком проводится анализ сведений, внесенных в журнал опытной эксплуатации, АС, на соответствие их требованиям ТЗ и разработанной документации на АС, а также требованиям Программы ОЭ.


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


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


-       ТЗ на АС, ТЗ и/или ЧТЗ на части АС (при наличии);
По окончании опытной эксплуатации АС Подрядчик готовит Протокол устранения замечаний в ходе опытной эксплуатации АС и предоставляет его Заказчику.


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


-       Программа и методика испытаний;
Результатом опытной эксплуатации АС должны являться:


-       Согласованные тесты (контрольные примеры);
* Журнал опытной эксплуатации АС;
* Протокол устранения замечаний в ходе опытной эксплуатации АС;
* Доработанная АС и скорректированная документация на АС.
* По результатам опытной эксплуатации АС, Заказчик принимает решение о готовности предъявления частей АС и АС в целом на приемочные испытания, или о неготовности предъявления частей АС и АС в целом на приемочные испытания и необходимости ее доработки.
* Опытная эксплуатация АС завершается оформлением и утверждением Заказчиком Акта о завершении опытной эксплуатации АС и подготовкой уведомления о готовности АС к приемочным испытаниям


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


-       Акт приемки АС в опытную эксплуатацию;
Приемочные испытания АС должны проводится комиссией, назначенной Заказчиком, на объекте эксплуатации, в соответствии с утвержденной им программой и методикой испытаний.


-       Акт о завершении опытной эксплуатации АС.
Состав членов комиссии определяется Заказчиком.


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


13.4.7.    Приемочные испытания должны включать проверку:
Для проведения приемочных испытаний АС Подрядчиком должны быть представлены:


-       Полноты и качества реализации функций и требований к АС, указанных в ТЗ и ЧТЗ (при наличии) на АС;
* Уведомление о готовности АС к приемочным испытаниям;
* ТЗ на АС, ТЗ и/или ЧТЗ на части АС (при наличии);
* Документация на АС;
* Программа и методика испытаний;
* Согласованные тесты (контрольные примеры);
* Программные средства и оборудование, необходимые для проведения испытаний, и соответствующая им эксплуатационная документация;
* Акт приемки АС в опытную эксплуатацию;
* Акт о завершении опытной эксплуатации АС.


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


-       Средств и методов восстановления работоспособности АС после отказов;
Приемочные испытания должны включать проверку:


-       Комплектности и качества эксплуатационной документации на АС.
* Полноты и качества реализации функций и требований к АС, указанных в ТЗ и ЧТЗ (при наличии) на АС;
* Удобства работы пользователей и персонала АС;
* Средств и методов восстановления работоспособности АС после отказов;
* Комплектности и качества эксплуатационной документации на АС.


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


13.4.9.    Результатом приемочных испытаний АС должен являться:
Результатом приемочных испытаний АС должен являться:


-       Единый протокол приемочных испытаний АС.
* Единый протокол приемочных испытаний АС.


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


= 14        Требования к проектному опыту поставщика =
= Требования к проектному опыту поставщика =
14.1.  Компания-производитель должна предоставить все подтверждающие документы (разрешения, сертификаты и лицензии).
14.1.  Компания-производитель должна предоставить все подтверждающие документы (разрешения, сертификаты и лицензии).


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

Версия от 21:52, 29 ноября 2024

В РАБОТЕ-----------------------------------------------------

1             Термины, определения и сокращения

АРМ Автоматизированное рабочее место
КВС Корпоративная (заводская) вычислительная сеть
ОС Операционная система
ПО Программное обеспечение
СКС Структурированная кабельная система
Система, СМПИО Система мониторинга промышленного и инженерного оборудования
УП Управляющая программа
ЧПУ Числовое программное управление
ЧТЗ Частное техническое задание
АС Автоматизированная система
ОЭ Опытная эксплуатация
MDC Machine data collection – Сбор машинных данных
SCADA Supervisory Control and Data Acquisition — Диспетчерское управление и сбор данных

Цели проекта

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

Описание объекта автоматизации

<Описание компании>

<Локации>

<Ссылка на приложение №1 Перечень контролируемого оборудования.>

<Системы CAM, ТОиР и MES/APS, подлежащие интеграции.>

<Количество и роли пользователей.>

Состав комплексного решения

Комплексное решение включает:

  1. Поставка лицензий программного комплекса класса MDC или SCADA.
  2. Поставка и установка контрольно-измерительных приборов (датчиков).
  3. Поставка интеллектуального оборудования (контроллеров) в составе щитов автоматизации.
  4. Подключение датчиков к контроллерам.
  5. Настройка и подключение контроллеров в промышленную сеть.
  6. Настройка программного обеспечения.
  7. Обучение.

Задачи, планируемые к решению с помощью СМПИО

  1. Сокращение внеплановых простоев оборудования.
  2. Увеличение производительности оборудования.
  3. Учет работы производственного и инженерного оборудования.
  4. Непрерывный сбор, первичная обработка и передача информации о техническом состоянии производственного и инженерного оборудования в реальном времени.
  5. Учет работы производственного персонала.
  6. Сокращение брака.
  7. Оптимизация графика работы производственного персонала и оборудования (отказ от работы в выходные дни, отказ от второй или третьей смены).
  8. Снижение затрат на приобретение дополнительного оборудования.
  9. Снижение эксплуатационных расходов.
  10. Контроль за соблюдением регламентированного технологического процесса производства продукции.
  11. Контроль выполнения производственных заданий.
  12. Контроль параметров телеметрии (температура, давление, нагрузка, вибрации и т.п.) при выполнении конкретной технологической операции.
  13. Автоматизация технологического процесса распределения и передачи управляющих программ для оборудования с ЧПУ.
  14. Сквозная передача цеховых данных в системы операторского (диспетчерского) уровня управления (верхний уровень) предприятием (ERP, MES).
  15. Сквозная передача цеховых данных в системы ТОиР.

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

Основные функциональные требования

СМПИО должна обеспечивать:

  1. Сбор и  хранение информации о технологических параметрах функционирования оборудования, в т.ч. токовой нагрузки, потребляемой электроэнергии, уровня входного напряжения (всплески и провалы).
  2. Сбор и хранение информации о параметрах технологических процессов.
  3. Регистрацию времени работы и простоев оборудования с классификацией их причин.
  4. Регистрацию времени выполнения технологических операций (по данным станков ЧПУ, по данным ручного ввода, по данным анализа технологических параметров).
  5. Идентификацию и регистрацию нахождения персонала на рабочем месте (по rfid-карте, по системе распознавания лиц, по отпечатку пальца).
  6. Передачу заданий (рабочих, производственных, сменно-суточных), электронных маршрутных карт на автоматизированное рабочее место исполнителя.
  7. Возможность отметки на АРМ исполнителя факта исполнения операции, задания вручную или по данным анализа данных с контроллера оборудования.
  8. Выявление отклонений фактических показателей операции от плановых.
  9. Регистрацию выпущенных изделий, регистрация бракованных изделий с указанием причины брака.
  10. Формирование аналитических отчетов о работе оборудования с возможностью создания произвольных отчетов.
  11. Наличие функции панели дашбордов для вывода в постоянном режиме на экраны оперативной и аналитической информации.
  12. Визуализацию оборудования, на планах помещений с отметками текущего состояния.
  13. Передачу программ на станки с ЧПУ, интеграцию с системами класса PDM и CAM; фиксацию в журнале операций программ, использованных при выполнении операций; СМПИО должна контролировать актуальность файлов УП и фиксировать изменения в журнале: время загрузки УП в систему ЧПУ оборудования, кто выполнял загрузку, время начала и окончания отработки УП на оборудовании.
  14. Интеграцию с системами класса EAM(ТОиР) для передачи информации о простоях, отклонениях (инцидентах), наработке; интеграцию с системами MES/APS для передачи рабочих заданий, маршрутных карт, сменно-суточных заданий в одну сторону и информации о выполнении заданий неработоспособности оборудования для оперативного перепланирования в другую сторону.

Требования к регистрации событий и состояний

  1. Система должна позволять дополнять/изменять/удалять типы событий, подлежащих регистрации без необходимости доработки и привлечения производителя.
  2. Система должна позволять определять алгоритмы обработки событий и соответствующих реакций (в т.ч. рассылка сообщений) без необходимости доработки с использованием скриптов или No-Code/Low-Code технологий.
  3. Система должна позволять подключать без доработки наиболее распространенные промышленные контроллеры.
  4. Система должна обеспечивать ведение справочников как минимум с указанными в таблице параметрами:
Справочник Параметры
Оборудование Номер оборудования
Наименование оборудования
Тип оборудования
Локация оборудования
Контролируемые параметры оборудования
Допустимые значения контролируемых параметров
Персонал Табельный номер
ФИО
Должность
Подразделение
Технологические операции Вид оборудования
Вид операции
Наименование операции
Плановая длительность операции
  1. Система должна вести как минимум следующие журналы, включая как минимум указанные в таблице параметры:
Журнал Параметры
События Оборудование
Тип события
Дата-время события
Контролируемые параметры, сопутствующие событию.
Сотрудник, зарегистрированный на рабочем месте на момент события
Номер смены
Параметры Оборудование
Дата-время
Вид параметра
Значение параметра
Операции Вид операции
Дата-время начала операции
Дата-время окончания операции
Фактическая длительность операции
Оборудование
Исполнитель

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

Производственные состояния:

Работа по программе – выполнение операций обработки/изготовления детали по программе ЧПУ.

Работа в ручном режиме – выполнение операций обработки/изготовления детали на ручном управлении.

Работа в режиме MDI – выполнение операций обработки/изготовления детали путем интерактивной подачи команд.

Станок включен – станок включен и готов к работе.

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

Простой» («Нерегламентированный перерыв») – станок включен и готов к работе, но операции обработки/изготовления не выполняются, шпиндель не вращается в течение определённого времени по причине отсутствия оператора или отсутствия/несвоевременного ввода причины простоя.

«Станок выключен» – фиксируется при наличии сигнала от станка в положении ВЫКЛ.

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

«Измерение детали исполнителем» («Производственный простой») – станок включен и готов к работе, происходит контроль параметров изделия оператором в процессе выполнения программы обработки (процесс выполнения выбранной программы ЧПУ находится в режиме ожидания).

«Нет данных» – фиксируется при отсутствии сигнала (обрыв сети, сбои ПО на станке).

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

Дополнительные состояния:

«Авария» («Технический простой») – отказ работы оборудования по причине поломок станка.

«Ремонт и ППР» («Технический простой») – ведется ремонт оборудования и/или планово-предупредительный ремонт.

«Сбой станка» («Технический простой») – сбой электроавтоматики, гидравлики, ЧПУ, кратковременный скачок либо провал напряжения.

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

«Отсутствие материалов, заготовки» («Организационный простой») – станок включен и готов к работе, нет заготовок.

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

«Отсутствие оснастки» («Организационный простой») – станок включен и готов к работе, нет годной оснастки.

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

«Отсутствие УП» («Организационный простой») – станок включен и готов к работе, нет управляющей программы, ошибка в УП.

«Регламентированный перерыв» – станок включен и готов к работе, отсутствие исполнителя согласно расписанию перерывов, обед.


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

Получение данных о работе оборудования

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

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

  1. Система должна иметь в составе АРМ (автоматизированные рабочие места) операторов станков для взаимодействия с ней производственного персонала.
  2. АРМ должны представлять собой приложения (или веб-приложения), которые могут быть установлены на устройства Заказчика. Одно устройство для работы с АРМ должно быть закреплено за группой станков и их операторов. В цеху могут быть несколько устройств для нескольких групп станков. При этом все такие устройства подключаются в локальную сеть для осуществления обмена информацией с серверным приложением СМПИО.
  3. Каждое АРМ должно быть рассчитано на поочередное (по мере необходимости) использование несколькими пользователями — операторами определенной группы станков, а также вспомогательным персоналом по ремонту и обслуживанию станков.
  4. Основные функции АРМ:
    • Регистрация оператора на станке.
    • Регистрация оператором причины простоя станка.
    • Получение оператором сменного задания.
    • Регистрация оператором выполняемой технологической операции.
    • Отображение хода выполнения сменного задания.
    • Загрузка оператором управляющей программы в станок с ЧПУ.
    • Ввод оператором отчета о выполнении сменного задания
  5. Регистрация оператора в АРМ и привязка к станку должна обеспечиваться путем ввода уникального табельного номера сотрудника вручную или с использованием технических средств (по rfid-карте, по системе распознавания лиц, по отпечатку пальца).
  6. Система должна иметь разграничение доступа по ролям и включать (или позволять настроить) как минимум следующие роли:
    1. Администратор.
    2. Директор по производству.
    3. Инженер.
    4. Мастер.
    5. Исполнитель.

6.  Механик

7.  Интеграция с другими системами.

Требования к системе оперативного вывода информации

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

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

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

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

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

  1. Подсистема отчетности должна позволять формировать аналитические отчеты в виде таблиц, диаграмм (линейных графиков, графиков с заполнением, круговых диаграмм, дашбордов (спидометров)) для вывода на экран, для печати.
  2. Для фильтрации и группировки должны использоваться все поля базы данных подходящего типа.
  3. При формировании стандартных аналитических отчетов должна быть возможность учета графика работы оборудования с учетом рабочих смен (дневных, вечерних, ночных) и выходных и / или праздничных дней.
  4. Система должна позволять создавать/изменять отчеты с использованием любой информации из журналов и справочников без кодирования.
  5. Страницы (панели отчетов) должны позволять размещать отчеты в любых комбинациях.
  6. Отчеты должны просматриваться как из системы, так и экспортироваться в формат PDF. Отчеты, формируемые в табличном виде, должны экспортироваться в формат xls или xlsx.
  7. Система должна иметь встроенный механизм для автоматического формирования и рассылки отчетности по расписанию или по событию.
  8. Отчеты должны отправляться получателям по электронной почте (письма с вложениями). Параметры подключения и шаблоны для отправки писем должны настраиваться без доработки ПО.
  9. При внедрении Системы должны быть реализованы отчеты, указанные в приложении №2 Каталог отчетов.

Требования к преднастроенным отчетам

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

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

  • Временной интервал для формирования отчета - за определенный период времени (смена, день, месяц, год).
  • Подразделение (или по всем подразделениям).
  • Станок (или по всем станкам).
  • Оператор.

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

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

Преднастроенные отчеты

Перечень преднастроенных отчетов:

  • Отчет о загрузке оборудования.
  • Отчет о работе и простоях оборудования.
  • Отчет о работе операторов оборудования.

Мобильный мониторинг

Пользователям должна быть предоставлена возможность работы с данными мониторинга на мобильных устройствах (смартфонах, планшетах) с помощью веб-интерфейса или мобильного приложения, а именно:

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

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

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

Администрирование и самодиагностика

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

Требования к интеграции

Указать требования к интеграции со смежными информационными системами компании.

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

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

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

Система должна:

  • быть выполнена в трехзвенной архитектуре;
  • сервер приложений и СУБД должны поддерживать как минимум одну из следующих ОС: Astra Linux (ГК «Астра»), ОС «Альт» («БазАльт СПО») и «Ред ОС» («Ред Софт»);
  • использовать для функционирования СУБД, внесенную в реестр https://reestr.digital.gov.ru/, либо их версии СПО, либо интегрированную в Систему СУБД.
  • поддерживать работу в виртуализированной среде;
  • клиентское приложение должно иметь вариант исполнения в виде веб-сервиса и должно функционировать на браузере Яндекс.

Требования к защите информации

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

В рамках разработки системы защиты информации должна быть разработана следующая документация.

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

Исполнитель должен обеспечить надлежащий уровень защиты информации в СМПИО в соответствии с разработанной документацией.

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

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

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

Указать требования по настройке программного обеспечения.

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

Исполнитель должен предоставить:

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

Требования к обучению пользователей

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

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

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

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

Техническая поддержка

Исполнитель должен в течение в течение 1 (одного) года от даты окончания работ по внедрению СМПИО оказывать Заказчику техническую поддержку:

  • проводить технические консультации по вопросам использования и обслуживания СМПИО;
  • оперативно решать инциденты с нарушением работоспособности серверной и клиентской частей СМПИО;
  • исправлять выявленные ошибки и/или устранять неисправности;
  • предоставлять обновления программного обеспечения системы мониторинга.

Виды, состав и методы испытаний АС и ее составных частей

Общие требования к испытаниям АС и ее составных частей

Для проверки разработанного функционала АС устанавливаются следующие виды испытаний:

  • Предварительные.
  • Опытная эксплуатация.
  • Приемочные.

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

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

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

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

До начала проведения испытаний Подрядчик должен отладить и протестировать поставляемые технические и программные средства АС.

До начала проведения испытаний Подрядчик должен провести инструктаж для персонала Заказчика, участвующего в испытаниях.

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

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

Испытания АС могут проводиться дистанционно при согласовании Заказчиком.

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

Предварительные испытания АС проводятся с целью предварительной оценки соответствия АС требованиям настоящего ТЗ.

Предварительные испытания проводятся с целью определения готовности АС к вводу в опытную эксплуатацию.

Проведение опытной эксплуатации

Опытная эксплуатация АС проводится с целью:

  • Проверки правильности функционирования АС при выполнении всех функций и требования к АС, указанных в настоящем ТЗ;
  • Проверки готовности персонала к работе со средствами АС в условиях ее опытной эксплуатации;
  • Проверки полноты, содержания эксплуатационной документации на АС.

Порядок проведения опытной эксплуатации АС устанавливается в соответствии со следующими условиями:

  1. Опытная эксплуатация должна проводиться в соответствии с Программой опытной эксплуатации АС, разработанной Подрядчиком и утвержденной Заказчиком;
  2. Для проведения ОЭ в АС должны быть заведены учетные записи пользователей, участвующих в ОЭ и настроены права доступа в соответствии с их пользовательскими ролями в АС;
  3. Опытная эксплуатация должна проводиться на Продуктивном контуре, развернутом на вычислительных ресурсах Заказчика, в соответствии с разработанной документацией на АС;
  4. Опытная эксплуатация должна проводиться (по разработанным Подрядчиком и утвержденным Заказчиком программам и сценариям) персоналом Заказчика, прошедшим необходимую подготовку, при техническом сопровождении Подрядчика;
  5. Подрядчик должен обеспечить сопровождение опытной эксплуатации АС с момента сдачи АС в опытную эксплуатацию и до окончания опытной эксплуатации;
  6. В течение опытной эксплуатации АС сотрудники Подрядчика должны оказывать услуги третьей линии поддержки, отвечая на вопросы второй линии поддержки (сотрудников ИТ-подразделения Заказчика), исправлять функционал, если он реализован вне соответствия с Техническим заданием.

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

Все сведения должны фиксироваться в журнале опытной эксплуатации АС с указанием даты и ФИО ответственных лиц Заказчика, принимающих участие в ОЭ.

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

В ходе проведения опытной эксплуатации АС, Подрядчиком проводится анализ сведений, внесенных в журнал опытной эксплуатации, АС, на соответствие их требованиям ТЗ и разработанной документации на АС, а также требованиям Программы ОЭ.

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

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

По окончании опытной эксплуатации АС Подрядчик готовит Протокол устранения замечаний в ходе опытной эксплуатации АС и предоставляет его Заказчику.

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

Результатом опытной эксплуатации АС должны являться:

  • Журнал опытной эксплуатации АС;
  • Протокол устранения замечаний в ходе опытной эксплуатации АС;
  • Доработанная АС и скорректированная документация на АС.
  • По результатам опытной эксплуатации АС, Заказчик принимает решение о готовности предъявления частей АС и АС в целом на приемочные испытания, или о неготовности предъявления частей АС и АС в целом на приемочные испытания и необходимости ее доработки.
  • Опытная эксплуатация АС завершается оформлением и утверждением Заказчиком Акта о завершении опытной эксплуатации АС и подготовкой уведомления о готовности АС к приемочным испытаниям

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

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

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

Состав членов комиссии определяется Заказчиком.

В состав комиссии включаются представители Подрядчика.

Для проведения приемочных испытаний АС Подрядчиком должны быть представлены:

  • Уведомление о готовности АС к приемочным испытаниям;
  • ТЗ на АС, ТЗ и/или ЧТЗ на части АС (при наличии);
  • Документация на АС;
  • Программа и методика испытаний;
  • Согласованные тесты (контрольные примеры);
  • Программные средства и оборудование, необходимые для проведения испытаний, и соответствующая им эксплуатационная документация;
  • Акт приемки АС в опытную эксплуатацию;
  • Акт о завершении опытной эксплуатации АС.

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

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

  • Полноты и качества реализации функций и требований к АС, указанных в ТЗ и ЧТЗ (при наличии) на АС;
  • Удобства работы пользователей и персонала АС;
  • Средств и методов восстановления работоспособности АС после отказов;
  • Комплектности и качества эксплуатационной документации на АС.

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

Результатом приемочных испытаний АС должен являться:

  • Единый протокол приемочных испытаний АС.

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

Требования к проектному опыту поставщика

14.1.  Компания-производитель должна предоставить все подтверждающие документы (разрешения, сертификаты и лицензии).

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