Выполнение составной части комплексного проекта по теме: «Разработка программ и методик и проведение испытаний высокотехнологичных программно-аппаратных комплексов для обеспечения смарт хранения, обработки и передачи больших массивов данных»

Межотраслевой инжиниринговый центр «Композиты России» МГТУ им. Н.Э. Баумана ОБЪЯВЛЯЕТ СБОР ЗАИНТЕРЕСОВАННОСТЕЙ на выполнение СЧ НИОКТР по теме: «Разработка программ и методик и проведение испытаний высокотехнологичных программно-аппаратных комплексов для обеспечения смарт хранения, обработки и передачи больших массивов данных» в рамках договора на выполнение НИОКТР
№ 218.2510-17 от 25.10 2017 г. Тема НИОКТР: «Организация производства высокотехнологичных программно-аппаратных комплексов для обеспечения смарт хранения, обработки и передачи больших массивов данных».  МГТУ им. Н.Э. Баумана является головным исполнителем НИОКТР (соисполнитель научной составляющей общего проекта).

Место выполнения работы или оказания услуги: г. Москва, Лефортовская наб., д. 1

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

1 Этап: с даты подписания договора–30.06.2020 г

2 Этап: 01.07.2020 г.–31.10.2020 г.

3 этап: 01.11.2020 г.–31.12.2020 г.

В случае заинтересованности в выполнении вышеуказанных работ, просим составить Коммерческое предложение с указанием функциональных характеристик, стоимости и сроков выполнения на имя Заместителя директора МИЦ «Композиты России» МГТУ им. Н.Э. Баумана Бородулина Алексея Сергеевича.

Коммерческие предложения и запросы по разъяснению технического задания просим направлять на почтовый адрес: purchase@emtc.ru

Срок сбора заинтересованностей – до 20.03.2020 г.  не позднее 14:00 по московскому времени.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

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

Результаты выполнения СЧ комплексного проекта

1.1. В ходе выполнения СЧ комплексного проекта должно быть разработано и создано:

1.1.1. Программа и методика квалификационных испытаний установочной партии сервера хранения данных (СХД)

1.1.2. Программа и методика квалификационных испытаний установочной партии сервера телематических услуг (СТУ).

1.1.3. Акт и протокол испытаний СТУ

1.1.4. Акт и протокол испытаний СХД.

1.1.5. Акт и протокол квалификационных испытаний ПАК.

1.1.6. Акт и протокол приемочных испытаний

2. Цели СЧ комплексного проекта

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

2.2. Задачи СЧ комплексного проекта:
1) Разработка программы и методик квалификационных испытаний установочной партии СТУ.
2) Разработка программы и методик квалификационных испытаний установочной партии СХД.
3) Проведение квалификационных испытаний установочной партии СТУ.
4) Проведение квалификационных испытаний установочной партии СХД.
5) Проведение квалификационных испытаний установочной партии ПАК в соответствии с ПМИ версии 3.0.
6) Проведение приемочных испытаний установочной партии ПАК в соответствии с ПМИ.

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

3.1. Объектами автоматизации являются процессы хранения, обработки и передачи больших массивов данных. Указанные процессы направлены на решения информационных задач в следующих направлениях:
1) обеспечение работы Системы в облачных и распределенных сервисах;
2) обеспечение предоставления ресурсов хранения в концепции «Инфраструктура как сервис».
3.2. Объект автоматизации включает себя следующие подпроцессы:
1) подпроцесс предоставления графических интерфейсов;
2) подпроцесс ролевой модели и обеспечения информационной безопасности;
3) подпроцесс оповещения, мониторинга и журналирования;
4) подпроцесс хранения больших объёмов данных;
5) подпроцесс передачи и обработки данных;
6) подпроцесс интеграции с другими системами;
7) подпроцесс обеспечения отказоустойчивости и автоматического восстановления;
8) подпроцесс миграции данных;
9) подпроцесс обеспечения распределенной архитектуры;
10) подпроцесс репликации данных в распределенных архитектурах;
11) подпроцесс программного определения сетей для нужд Системы;
12) подпроцесс асинхронной и параллельной обработки данных;
13) подпроцесс дедубликации и компрессии данных.

4. Требования к системе
4.1. Требования к системе в целом
4.1.1. Требования к структуре и функционированию системы
4.1.1.1. Перечень подсистем, их назначение и основные характеристики
4.1.1.1.1. Перечень подсистем, разработанный на этапах эскизного и технического проектирования, передается Заказчиком Исполнителю. В состав подсистем должны входить программные и аппаратные решения, обеспечивающие выполнение комплексов задач, соответствующих подпроцессам объекта автоматизации, а именно:

1) комплекс задач предоставления графических интерфейсов, далее ГИ;
2) комплекс задач ролевой модели и обеспечения информационной безопасности, далее РМиОИБ;
3) комплекс задач оповещения, мониторинга и журналирования, далее ОМЖ;
4) комплекс задач хранения данных, ХД;
5) комплекс задач передачи и обработки данных, далее ПиОД;
6) комплекс задач интеграции с внешними системами, ИСВС;
7) комплекс задач отказоустойчивости и автоматического восстановления, далее ОиАВ;
8) комплекс задач миграции данных, далее МД;
9) комплекс задач распределенной архитектуры, далее РА;
10) комплекс задач репликации данных, далее РД;
11) комплекс задач программного определения сетей для нужд ПАК СХД, далее ПОС;
12) комплекс задач асинхронной и параллельной обработки данных, далее АиПОД;
13) комплекс задач дедубликации и компрессии данных, ДиК.

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

4.1.1.2 Требования к способам и средствам связи
4.1.1.2.1 Для взаимодействия подсистем допускается использование каналов связи Ethernet и протокола TCP/IP, обращений к API подсистем либо их компонент и обмен сообщениями в формате JSON/XML, также допускается использование систем управления очередями сообщений.
4.1.1.2.2 Для взаимодействия с СУБД, входящими в состав отдельных подсистем, должны использоваться протоколы соответствующих СУБД. Форматы данных и шаблоны сообщений, разработанные и утвержденные на этапе технического проектирования, передаются Заказчиком Исполнителю.
4.1.1.2.3 Для обмена данными с внешними и внутренними устройствами хранения должен применяться интерфейс iSCSI и/или FC с поддержкой протокола SMB 2.0.
4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
4.1.1.3.1 В общем случае взаимодействие Системы со смежными/внешними системами осуществляется путем:
— предоставления API с документацией, описывающей порядок использования API (Документ “Описание программ”).
— использования известных (документированных) протоколов взаимодействия, например, протокол LDAP для взаимодействия с Microsoft Active Directory.
4.1.1.4 Требования к режимам функционирования Системы
4.1.1.4.1 Система должна функционировать в следующих режимах:
— Нормальный режим – режим, при котором АС и смежные системы работают без сбоев и реализуют обмен данными, работа системы осуществляется в полном объеме. Нормальный режим функционирования Системы должен рассчитываться исходя из формулы 247365.
— Режим ограниченной производительности – режим, при котором в целом Система работает без сбоев, но одна или несколько подсистем (компонент) не отвечают на запросы и не осуществляют обмен данными. Например, выход из строя зарезервированных подсистем. В этом режиме возможно снижение показателей производительности.
— Режим ограниченной функциональности – режим, при котором Система продолжает работу в случае выхода из строя одной из компонент, реализующей определенный набор функций. В этом режиме функции, реализуемые другими компонентами, предоставляются в полном объеме, но возможно снижение показателей доступности.
— Аварийный режим. В этом случае резервные средства контроля и управления должны обеспечить безопасный останов установки (группы установок) при полном отказе Системы, либо работу установки (группы установок) в течение 1 часа до восстановления работоспособности Системы.
4.1.1.4.2 Основным режимом функционирования Системы является нормальный режим. В случае перехода Системы в другие режимы необходимо выполнить комплекс мероприятий по устранению причины перехода в аварийный режим, комплекс таких мер, разработанный и согласованный на стадии технического проектирования, должен быть передан Заказчиком Исполнителю.
4.1.1.5 Требования по диагностированию системы
4.1.1.5.1 Программные и технические средства Системы должны обеспечивать диагностику и самодиагностику компонентов Системы с глубиной поиска места отказа до модуля.
4.1.1.5.2 С помощью средств диагностики должны фиксироваться следующие ситуации:
— отказ источников питания;
— отказ модулей управления;
— отказ устройства хранения данных;
4.1.1.5.3 В разрабатываемой Системе должны формироваться следующие диагностические сообщения:
— отказ (восстановление) Системы, подсистем и отдельных компонент подсистем;
— отказ устройств хранения информации;
— отказ в системе электропитания.
4.1.1.5.4 При возникновении аварийных ситуаций и ошибок в программном обеспечении, диагностические инструменты разрабатываемой Системы должны позволять сохранять набор информации, необходимой для идентификации нештатной ситуации: снимки экранов, текущее состояние памяти, файловой системы.
4.1.1.5.5 Детальный список ситуаций (событий) для диагностики, разработанный на этапе разработки Технического задания на Систему или её отдельные подсистемы, передается Заказчиком Исполнителю.
4.1.2 Требования к показателям назначения
4.1.2.1 Разрабатываемая Система должна обеспечивать следующие показатели:

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

4.1.3 Требования к надежности
4.1.3.1 Технические решения должны обеспечивать высокую доступность, отказоустойчивость и катастрофоустойчивость Системы и её подсистем путём применения следующих мер, и средств:
— резервного копирования и восстановления информации;
— резервирования технических и программных средств;
— алгоритмов самовосстановления;
— кластерных и геораспределенных архитектур;
— миграции данных при выходе из строя узлов кластера;
— репликации данных;
— избыточных массивов независимых дисков (RAID).
4.1.3.2 Требования к качественным характеристикам надёжности представлены в Таблица 2.

Таблица 2 Требования к качественным характеристикам надежности

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

4.1.4 Требования безопасности
4.1.4.1 Общие требования к безопасности разрабатываемой Системы должны соответствовать требованиям Технических регламентов Таможенного союза.
4.1.4.2 Система должна обеспечивать возможность делегирования административных полномочий пользователям для создания распределенной модели администрирования с использованием ролевого подхода к управлению и эксплуатации системы. Должна быть обеспечена возможность наделения различных пользователей (ролей) строго определенным набором прав и полномочий в рамках эксплуатации. Перечень ролей, определённый на этапе Технического проекта, передается Заказчиком Исполнителю.

4.1.5 Требования к эргономике и технической эстетике
4.1.5.1 Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав Системы должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы. Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям системы.
4.1.5.2 Интерфейс пользователя должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен используется главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм.
4.1.5.3 Интерфейс администрирования Системы может быть основан на текстовом вводе-выводе на консоль управления сервером (виртуальной машины) и должен обеспечивать удаленное подключение по протоколу SSH.
4.1.5.4 Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
4.1.5.5 Экранные формы должны проектироваться с учетом требований унификации:
 все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
— для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
— внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.
4.1.5.6 Система должна соответствовать требованиям эргономики при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности Росстандарта.
4.1.6 Требования к транспортабельности
4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.1.7.1 Система должна быть рассчитана на эксплуатацию в различных ИТ ландшафтах (инфраструктурах).
4.1.7.2 Для нормальной эксплуатации разрабатываемой Системы должно быть обеспечено бесперебойное питание ПЭВМ. При эксплуатации система должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации ПЭВМ температура и влажность воздуха.
4.1.7.3 Периодическое техническое обслуживание используемых технических средств должно проводиться в соответствии с требованиями разрабатываемой эксплуатационной документации. Для осуществления периодического технического обслуживания должно быть предусмотрено время (технологическое окно), в течение которого Система может работ в режиме ограниченной производительности.
4.1.7.4 Эксплуатационной документацией должно предусматриваться проведение периодического технического обслуживания, в том числе проведение внешнего и внутреннего осмотр, чистка технических средств, проверка контактных соединений, проверка параметров настроек работоспособности технических средств и тестирование их взаимодействия, обновление программного обеспечения. На основании результатов тестирования технических средств должны проводиться анализ причин возникновения обнаруженных дефектов и приниматься меры по их ликвидации. Восстановление работоспособности технических средств должно проводиться в соответствии с эксплуатационными инструкциями технических средств и документами по восстановлению работоспособности технических средств и завершаться проведением их тестирования.
4.1.7.5 Размещение помещений и их оборудование должны исключать возможность бесконтрольного проникновения в них посторонних лиц и обеспечивать сохранность находящихся в этих помещениях конфиденциальных документов и технических средств. Размещение оборудования, технических средств должно соответствовать требованиям техники безопасности, санитарным нормам и требованиям пожарной безопасности.
4.1.7.6 Все пользователи системы должны соблюдать правила эксплуатации электронной вычислительной техники. Квалификация персонала и его подготовка должны соответствовать технической документации.
4.1.8 Требования к защите информации от несанкционированного доступа
4.1.8.1 Выполнение требований к защите информации от несанкционированного доступа должно обеспечиваться архитектурными решениями. Должно обеспечиваться выполнение следующих требований по защите информации:
— идентификация и аутентификация (проверки подлинности) субъекта доступа при входе в Систему по периодически обновляемому и уникальному паролю;
— автоматическая блокировка доступа субъекта при превышении допустимого количества предъявлений неверного пароля;
— ограничение области видимости объектов на основе ролевой модели;
— контроль и разграничение доступа субъектов к защищаемым информационным ресурсам и функциям в соответствии с ролевой моделью Системы;
— защищённая часть системы должна автоматически блокировать сессии пользователей и приложений по заранее заданным временам отсутствия активности со стороны пользователей и приложений;
— регистрацию входа (выхода) субъектов доступа в (из) систему (узел);
— учёт носителей информации;
— защищённая часть системы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов.
4.1.8.2 Должны быть исключены функциональные ограничения на применение программных модулей по комплексному обеспечению информационной безопасности передаваемых и хранимых данных на системах хранения данных.
4.1.9 Требования по сохранности информации при авариях
4.1.9.1 Должна быть предусмотрена сохранность информации в условиях нормальной эксплуатации системы и при эксплуатации в аварийной ситуации за счет создания резервных копий и их последующего восстановления. Заказчик должен предоставить Исполнителю уточненные требования к сохранности информации при авариях для оценки необходимости и возможности включения их в программу испытаний.
4.1.10 Требования к защите от влияния внешних воздействий
4.1.10.1 В предоставленных помещениях размещения серверов должны обеспечиваться климатические условия, определяемые требованиями со стороны производителей используемых технических средств.
4.1.10.2 Помещения должны быть оборудованы стандартными монтажными стойками. В стойках должно быть достаточно места для установки аппаратного обеспечения элементов системы, и, при необходимости, помещения должны позволять разместить в них дополнительные стандартные монтажные стойки.
4.1.10.3 Оборудование должно размещаться в помещениях серверных комнат, имеющих выделенную розеточную электросеть 220В 10%, 50 Гц с защитным заземлением. Должно обеспечиваться бесперебойное электропитание на время достаточное для корректного выключения серверов СМУ. Также необходимо обеспечить следующие климатические условия:
— температура окружающей среды – от +5 до +40 градусов Цельсия;
— относительная влажность воздуха — от 40% до 95% (без конденсата);
— атмосферное давление — от 630 мм. рт.с. до 800 мм. рт.с.;
— отсутствие пыли и агрессивных по отношению к оборудованию веществ.
4.1.11 Требования по стандартизации и унификации
4.1.12 Дополнительные требования
4.2 Требования к функциям
Функциональные требования, описывающие функции каждого из комплексов задач, представленных ниже, должны быть представлены Заказчиком для использования Исполнителем при разработке программы и методик испытаний:
— комплекс задач предоставления графических интерфейсов, далее ГИ;
— комплекс задач ролевой модели и обеспечения информационной безопасности, далее РМиОИБ;
— комплекс задач оповещения, мониторинга и журналирования, далее ОМЖ;
— комплекс задач хранения данных, ХД;
— комплекс задач передачи и обработки данных, далее ПиОД;
— комплекс задач интеграции с внешними системами, ИСВС;
— комплекс задач отказоустойчивости и автоматического восстановления, далее ОиАВ;
— комплекс задач миграции данных, далее МД;
— комплекс задач распределенной архитектуры, далее РА;
— комплекс задач репликации данных, далее РД;
— комплекс задач программного определения сетей для нужд ПАК СХД, далее ПОС;
— комплекс задач асинхронной и параллельной обработки данных, далее АиПОД;
— комплекс задач дедубликации и компрессии данных, ДиК.
4.3 Требования к видам обеспечения
4.3.1 Требования к математическому обеспечению
4.3.1.1 Математическое обеспечение разрабатываемой Системы должно содержать:
— алгоритм асинхронной параллельной обработки данных множеством модулей хранения на основе вероятностных метрик и динамических очередей;
— алгоритм обеспечения отказоустойчивости и автоматического самовосстановления системы;
— алгоритм дедубликации данных;
— алгоритм компрессии данных;
— алгоритмы и методы выявления и минимизация ошибок чтения;
— алгоритмы и методы обеспечение схемы резервирования.
4.3.1.2 Требования к совместимости со смежными системами должны (протоколы взаимодействия, методы API) должны быть представлены Заказчиком Исполнителю для оценки необходимости включения в программу и методики испытаний Системы и ее частей на этапе квалификационных и приемочных испытаний.
4.3.2 Требования к программному обеспечению
4.3.2.1 На серверах Системы должна применяться многопользовательская операционная система, обеспечивающая наличие высокоуровневых средств администрирования операционных систем и средств контроля над функционированием. На АРМ Системы должны применяться многозадачные операционные системы.
4.3.2.2 Программные модули должны функционировать на персональном компьютере с оперативной памятью не менее 16 Гбайт под управлением операционной системы не ниже MS Windows 7 при наличии не менее 2 Гбайт свободного пространства на жёстком диске или Linux (версия ядра не ниже 2.14).
4.3.2.3 Заказчик должен предоставить исполнителю уточненные на этапе разработки Технического задания требования к программному обеспечению.
4.3.3 Требования к техническому обеспечению
4.3.3.1 Серверы, используемые для построения Системы, должны соответствовать рекомендациям производителя используемых программных и аппаратных средств. Спецификация характеристик аппаратного обеспечения для построения Систем , разработанная на этапе Технического проекта, должна быть предоставлена Заказчиком Исполнителю.
4.3.3.2 Технические характеристики всего оборудования (серверов, активного сетевого оборудования, модулей хранения и т.д.) должны обеспечивать требования настоящего Технического задания как в части функциональных возможностей, так и в части надежности и возможности построения распределенных отказоустойчивых и катастрофоустойчивых архитектур.
4.3.4 Требования к метрологическому обеспечению
4.3.4.1 Заказчик должен предоставить Исполнителю уточненные требования к метрологическому обеспечению для оценки необходимости включения в программу и методики испытаний Системы и ее частей на этапе квалификационных и приемочных испытаний.
5 Требования к документации
5.1 Заказчик предоставляет Исполнителю перечень и комплект разработанной документации на изделия СХД, СТУ, ПАК. Основными стандартами для разработки документации настоящего проекта являются государственные стандарты следующих серий:
— ГОСТ серия 34 (автоматизированные системы) и РД 50-34.698-90.
— ГОСТ серия 15. Система разработки и постановки продукции на производство.
5.2 В рамках проекта должен быть разработан следующий комплект документов:
1) Программа и методика квалификационных испытаний установочной партии сервера хранения данных (СХД).
2) Программа и методика квалификационных испытаний установочной партии сервера телематических услуг (СТУ).
3) Акт и протокол испытаний СТУ
4) Акт и протокол испытаний СХД.
5) Акт и протокол квалификационных испытаний ПАК.
6) Акт и протокол приемочных испытаний
6 Специальные требования
6.1 Требования к проведению испытаний
6.1.1 Для подтверждения соответствия разрабатываемой Системы и ее составных частей требованиям, приведенным в настоящем Техническом задании, Исполнителем должны быть проведены следующие испытания:
1) Квалификационные испытания с целью определения фактических значений количественных и качественных характеристик, фактической эффективности и готовности персонала к работе в условиях функционирования Системы и ее составных частей системы (СТУ, СХД, ПАК) корректировки (при необходимости) технической документации.
2) Приемочные испытания для определения соответствия Системы (ПАК) требованиям, приведенным в настоящем техническом задании, оценки качества изделий и решения вопроса о возможности постановки в производство.
6.1.2 С целью проведения квалификационных испытаний Системы и ее составных частей, Исполнитель должен разработать Программу и методики квалификационных испытаний СХД и СТУ. Разработанные Программы и методики испытаний должны быть утверждены Заказчиком и согласованы Исполнителем. Заказчик передает Исполнителю Программу и методики квалификационных испытаний установочной партии ПАК
6.1.3 Для проведения испытаний Заказчик передает установочную партию СХД, установочную партию СТУ и установочную партию ПАК Исполнителю.
6.1.4 Приемочные испытания ПАК должны быть проведены по утвержденным Заказчиком программам и методикам. Для проведения испытаний Заказчик передает Исполнителю Программу и методики приемочных испытаний установочной партии ПАК.
6.1.5 Исполнитель разрабатывает и изготавливает стенды для проведения квалификационных и приемочных испытаний.
6.1.6 Участие в испытаниях представителей Заказчика уточняется в рабочем порядке в процессе проведения работ по этапам.
7 Порядок выполнения и приемки этапов
7.1 Работа должна выполняться в соответствии с требованиями ГОСТ 15.301-2016.
7.2 Место проведения квалификационных и приемочных испытаний – на территории Исполнителя.

Календарный план

В случае заинтересованности в выполнении вышеуказанных работ, просим составить Коммерческое предложение с указанием функциональных характеристик, стоимости и сроков выполнения на имя Заместителя директора МИЦ «Композиты России» МГТУ им. Н.Э. Баумана Бородулина Алексея Сергеевича.

Коммерческие предложения и запросы по разъяснению технического задания просим направлять на почтовый адрес: purchase@emtc.ru

Срок сбора заинтересованностей – до 20.03.2020 г.  не позднее 14:00 по московскому времени.