Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069145
Тема сообщения
Нарушения в ТС, требуем рассмотреть
Тип сообщения
Замечание к АД
Поставщик
AI-Trade ИП
Представитель поставщика
ОРАЗБАЕВА АНОРА БЕИМБЕТОВНА
Дата и время отправки сообщения
2026-09-29 23:32:33
Текст сообщения
ЗАМЕЧАНИЯ
1. Требования к комплексу беспроводных измерительных датчиков содержат чрезмерное регулирование не только измеряемых параметров, но и внутренней сетевой архитектуры, транспортного протокола, формата пакетов данных, аппаратной платформы центрального приемника и даже конкретного визуального оформления пользовательского интерфейса.
2. Функциональная задача такого комплекса заключается в беспроводном сборе показаний различных датчиков, отображении параметров в реальном времени, хранении истории и обеспечении безопасной работы. Конкретная технология связи не должна искусственно ограничивать производителей.
3. ТС предписывает, что приемник должен самостоятельно формировать локальную Wi-Fi сеть в режиме Access Point. Между тем профессиональные учебные датчики могут использовать существующую Wi-Fi инфраструктуру учреждения, Bluetooth Low Energy, Zigbee, Thread, собственный защищенный RF-протокол либо иные технологии.
4. Просим заменить обязательный Wi-Fi Access Point требованием беспроводной связи с заявленной дальностью и устойчивостью.
5. Точка доступа должна развернуться за 60 секунд, датчик должен подключиться максимум за 10 секунд, а при потере связи повторять попытки с интервалом до 5 секунд. Такие параметры относятся к внутреннему алгоритму прошивки.
6. Самым ограничительным является требование строго использовать WebSocket по RFC 6455 для обмена между датчиками и приемником, причем каждое сообщение должно передаваться в формате JSON.
7. MQTT, бинарный WebSocket, TCP, HTTPS, BLE GATT и другие технологии могут обеспечивать такое же либо меньшее время доставки данных. Обязательность конкретного протокола и формата данных не является необходимой для пользователя.
8. Просим оставить только функциональное требование по максимальной задержке телеметрии, устойчивости соединения и защищенности данных.
9. Для каждого измерительного модуля установлена защита не ниже IP54. Необходимо объяснить предполагаемые условия эксплуатации. Если датчики используются в учебном помещении, для отдельных типов сенсоров IP54 может быть конструктивно избыточным.
10. Каждый датчик должен иметь аккумулятор минимум 1000 мА·ч и автономность минимум 24 часа. Главным эксплуатационным параметром является автономность, а не абсолютная емкость. Энергоэффективный датчик с батареей 800 мА·ч, работающий 30 часов, объективно не хуже.
11. Просим исключить минимальную емкость аккумулятора и оставить минимальное фактическое время работы.
12. Зарядный ток не должен превышать 1 А. Ограничение максимального тока может, наоборот, исключать современные устройства с безопасным ускоренным зарядом. Просим обосновать необходимость такого предела.
13. Все датчики должны передавать данные один раз в секунду. Для медленно изменяющихся величин — температуры, влажности, давления — такой интервал не всегда необходим и сокращает автономность.
14. Просим разрешить настраиваемую частоту измерения и передачи данных.
15. Температурный датчик должен иметь диапазон измерения от -40 до +85 °C, однако эксплуатационный диапазон всего датчика в дальнейшем определен только от -20 до +60 °C. Получается, что часть обязательного диапазона измерений находится за пределами допустимых условий эксплуатации самого устройства.
16. Просим устранить это противоречие либо отдельно определить диапазон чувствительного элемента и допустимый температурный диапазон корпуса/аккумулятора.
17. Датчик скорости воздушного потока должен измерять до 30 м/с. Для применения внутри школы значение 30 м/с, то есть порядка 108 км/ч, требует отдельного обоснования.
18. Датчик освещенности должен измерять до 65 000 лк, что соответствует очень высокой освещенности и предполагает потенциальное использование на открытом воздухе, тогда как комплекс описывается как учебный.
19. Газовый датчик описан неоднозначно: он должен измерять «летучие органические соединения или углекислый газ» в диапазоне 400–5000 ppm. CO2 и VOC — разные измеряемые параметры и требуют различных сенсоров.
20. Просим однозначно указать, требуется CO2, TVOC либо оба параметра.
21. «Датчик уровня сигнала» описан как радиочастотный монитор «или специальный микрофон/анализатор радиоэфира». Микрофон измеряет акустический сигнал, RF-анализатор — электромагнитный, то есть оборудование не является функционально взаимозаменяемым.
22. «Универсальный датчик состояния» не имеет четкой измеряемой величины, диапазона и точности. Просим раскрыть учебную задачу данного модуля.
23. Оптический датчик описан как спектральный или инфракрасный, но результат предлагается выражать в люксах. Спектральная мощность и ИК-излучение сами по себе не измеряются в люксах в том же смысле, что обычная освещенность.
24. Требования к приемнику содержат минимальную частоту CPU 1,2 ГГц, RAM 1 ГБ, накопитель 8 ГБ и обязательную ОС с открытым исходным кодом. Специализированная embedded-система может выполнять все задачи с существенно меньшими аппаратными ресурсами.
25. Просим установить показатели по фактической производительности, а не архитектуре аппаратного обеспечения.
26. Приемник должен обслуживать минимум 30 WebSocket-соединений, хотя обязательных типов датчиков всего 15. Просим пояснить, для каких дополнительных соединений требуется двойной запас.
27. Пользовательский интерфейс описан вплоть до цветовой темы: обязательный Dark Theme, черный или темно-серый фон, заголовок типа «Sensor Hub», стилизованная пиктограмма микрочипа, счетчик активных датчиков, Grid-layout из 15 карточек.
28. Далее фиксируется расположение элементов внутри каждой карточки: иконка слева сверху, номер справа сверху, значение по центру, график за последние 10 минут, статусная строка снизу.
29. Статус «НЕАКТИВЕН» должен отображаться именно на красном фоне в форме стилизованной «таблетки» или кнопки.
30. Такие требования описывают внешний дизайн конкретной программной реализации и не относятся к функциональным характеристикам закупаемого оборудования.
31. Эквивалентный интерфейс может использовать светлую тему, таблицу, список, карточки иной формы и цветовую индикацию, оставаясь не менее удобным и информативным.
32. Просим заменить требования к внешнему виду интерфейса перечнем информации, которая должна быть доступна пользователю: название датчика, текущее значение, единица измерения, заряд, качество связи, статус, история значений и график.
33. История каждого датчика должна отображаться только за последние 10 минут и обновляться каждую секунду. Более функциональная система с выбором интервала 1/5/10/30/60 минут, сутки и т.д. формально может не соответствовать точному описанию.
34. Просим установить не менее десятиминутной истории, но допустить более широкие настройки.
35. Комплекс заявлен для непрерывной эксплуатации 24/7/365, тогда как автономность каждого датчика установлена минимум 24 часа. Не определено, как обеспечить непрерывную передачу при необходимости ежедневной зарядки.
36. Просим указать, входит ли зарядная станция, сколько одновременно датчиков можно заряжать, допускается ли работа во время зарядки, а также входит ли второй сменный комплект аккумуляторов.
37. Дополнительно для комплекса датчиков требуется авторизационное письмо производителя с QR-кодом для проверки подлинности и с датой не ранее публикации конкурса. Это делает участие зависимым от получения индивидуального документа у конкретного производителя.
38. Просим допустить иные документы, подтверждающие право поставки оригинального оборудования.
39. В целях расширения конкуренции просим сформировать требования к измерительным диапазонам, точности, автономности, задержке, дальности связи, отображению данных и гарантии, исключив обязательные WebSocket/JSON, конкретную ОС, аппаратные ресурсы приемника и графический дизайн интерфейса.
1. Требования к комплексу беспроводных измерительных датчиков содержат чрезмерное регулирование не только измеряемых параметров, но и внутренней сетевой архитектуры, транспортного протокола, формата пакетов данных, аппаратной платформы центрального приемника и даже конкретного визуального оформления пользовательского интерфейса.
2. Функциональная задача такого комплекса заключается в беспроводном сборе показаний различных датчиков, отображении параметров в реальном времени, хранении истории и обеспечении безопасной работы. Конкретная технология связи не должна искусственно ограничивать производителей.
3. ТС предписывает, что приемник должен самостоятельно формировать локальную Wi-Fi сеть в режиме Access Point. Между тем профессиональные учебные датчики могут использовать существующую Wi-Fi инфраструктуру учреждения, Bluetooth Low Energy, Zigbee, Thread, собственный защищенный RF-протокол либо иные технологии.
4. Просим заменить обязательный Wi-Fi Access Point требованием беспроводной связи с заявленной дальностью и устойчивостью.
5. Точка доступа должна развернуться за 60 секунд, датчик должен подключиться максимум за 10 секунд, а при потере связи повторять попытки с интервалом до 5 секунд. Такие параметры относятся к внутреннему алгоритму прошивки.
6. Самым ограничительным является требование строго использовать WebSocket по RFC 6455 для обмена между датчиками и приемником, причем каждое сообщение должно передаваться в формате JSON.
7. MQTT, бинарный WebSocket, TCP, HTTPS, BLE GATT и другие технологии могут обеспечивать такое же либо меньшее время доставки данных. Обязательность конкретного протокола и формата данных не является необходимой для пользователя.
8. Просим оставить только функциональное требование по максимальной задержке телеметрии, устойчивости соединения и защищенности данных.
9. Для каждого измерительного модуля установлена защита не ниже IP54. Необходимо объяснить предполагаемые условия эксплуатации. Если датчики используются в учебном помещении, для отдельных типов сенсоров IP54 может быть конструктивно избыточным.
10. Каждый датчик должен иметь аккумулятор минимум 1000 мА·ч и автономность минимум 24 часа. Главным эксплуатационным параметром является автономность, а не абсолютная емкость. Энергоэффективный датчик с батареей 800 мА·ч, работающий 30 часов, объективно не хуже.
11. Просим исключить минимальную емкость аккумулятора и оставить минимальное фактическое время работы.
12. Зарядный ток не должен превышать 1 А. Ограничение максимального тока может, наоборот, исключать современные устройства с безопасным ускоренным зарядом. Просим обосновать необходимость такого предела.
13. Все датчики должны передавать данные один раз в секунду. Для медленно изменяющихся величин — температуры, влажности, давления — такой интервал не всегда необходим и сокращает автономность.
14. Просим разрешить настраиваемую частоту измерения и передачи данных.
15. Температурный датчик должен иметь диапазон измерения от -40 до +85 °C, однако эксплуатационный диапазон всего датчика в дальнейшем определен только от -20 до +60 °C. Получается, что часть обязательного диапазона измерений находится за пределами допустимых условий эксплуатации самого устройства.
16. Просим устранить это противоречие либо отдельно определить диапазон чувствительного элемента и допустимый температурный диапазон корпуса/аккумулятора.
17. Датчик скорости воздушного потока должен измерять до 30 м/с. Для применения внутри школы значение 30 м/с, то есть порядка 108 км/ч, требует отдельного обоснования.
18. Датчик освещенности должен измерять до 65 000 лк, что соответствует очень высокой освещенности и предполагает потенциальное использование на открытом воздухе, тогда как комплекс описывается как учебный.
19. Газовый датчик описан неоднозначно: он должен измерять «летучие органические соединения или углекислый газ» в диапазоне 400–5000 ppm. CO2 и VOC — разные измеряемые параметры и требуют различных сенсоров.
20. Просим однозначно указать, требуется CO2, TVOC либо оба параметра.
21. «Датчик уровня сигнала» описан как радиочастотный монитор «или специальный микрофон/анализатор радиоэфира». Микрофон измеряет акустический сигнал, RF-анализатор — электромагнитный, то есть оборудование не является функционально взаимозаменяемым.
22. «Универсальный датчик состояния» не имеет четкой измеряемой величины, диапазона и точности. Просим раскрыть учебную задачу данного модуля.
23. Оптический датчик описан как спектральный или инфракрасный, но результат предлагается выражать в люксах. Спектральная мощность и ИК-излучение сами по себе не измеряются в люксах в том же смысле, что обычная освещенность.
24. Требования к приемнику содержат минимальную частоту CPU 1,2 ГГц, RAM 1 ГБ, накопитель 8 ГБ и обязательную ОС с открытым исходным кодом. Специализированная embedded-система может выполнять все задачи с существенно меньшими аппаратными ресурсами.
25. Просим установить показатели по фактической производительности, а не архитектуре аппаратного обеспечения.
26. Приемник должен обслуживать минимум 30 WebSocket-соединений, хотя обязательных типов датчиков всего 15. Просим пояснить, для каких дополнительных соединений требуется двойной запас.
27. Пользовательский интерфейс описан вплоть до цветовой темы: обязательный Dark Theme, черный или темно-серый фон, заголовок типа «Sensor Hub», стилизованная пиктограмма микрочипа, счетчик активных датчиков, Grid-layout из 15 карточек.
28. Далее фиксируется расположение элементов внутри каждой карточки: иконка слева сверху, номер справа сверху, значение по центру, график за последние 10 минут, статусная строка снизу.
29. Статус «НЕАКТИВЕН» должен отображаться именно на красном фоне в форме стилизованной «таблетки» или кнопки.
30. Такие требования описывают внешний дизайн конкретной программной реализации и не относятся к функциональным характеристикам закупаемого оборудования.
31. Эквивалентный интерфейс может использовать светлую тему, таблицу, список, карточки иной формы и цветовую индикацию, оставаясь не менее удобным и информативным.
32. Просим заменить требования к внешнему виду интерфейса перечнем информации, которая должна быть доступна пользователю: название датчика, текущее значение, единица измерения, заряд, качество связи, статус, история значений и график.
33. История каждого датчика должна отображаться только за последние 10 минут и обновляться каждую секунду. Более функциональная система с выбором интервала 1/5/10/30/60 минут, сутки и т.д. формально может не соответствовать точному описанию.
34. Просим установить не менее десятиминутной истории, но допустить более широкие настройки.
35. Комплекс заявлен для непрерывной эксплуатации 24/7/365, тогда как автономность каждого датчика установлена минимум 24 часа. Не определено, как обеспечить непрерывную передачу при необходимости ежедневной зарядки.
36. Просим указать, входит ли зарядная станция, сколько одновременно датчиков можно заряжать, допускается ли работа во время зарядки, а также входит ли второй сменный комплект аккумуляторов.
37. Дополнительно для комплекса датчиков требуется авторизационное письмо производителя с QR-кодом для проверки подлинности и с датой не ранее публикации конкурса. Это делает участие зависимым от получения индивидуального документа у конкретного производителя.
38. Просим допустить иные документы, подтверждающие право поставки оригинального оборудования.
39. В целях расширения конкуренции просим сформировать требования к измерительным диапазонам, точности, автономности, задержке, дальности связи, отображению данных и гарантии, исключив обязательные WebSocket/JSON, конкретную ОС, аппаратные ресурсы приемника и графический дизайн интерфейса.
