Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069017
Тема сообщения
Замечание к АД
Тип сообщения
Замечание к АД
Поставщик
АРУЖАН
Представитель поставщика
КУЛАКОВ БЕЙБИТ МАДАТАЕВИЧ
Дата и время отправки сообщения
2026-09-28 20:58:51
Текст сообщения
ЗАМЕЧАНИЯ
1. Раздел аппаратно-программного комплекса беспроводных датчиков сформирован с чрезмерной детализацией сетевой архитектуры, аппаратной реализации и пользовательского интерфейса. Вместо определения необходимых учебных измерительных функций ТС фактически предписывает разработчику конкретный способ построения системы.
2. Установлено, что приемник обязан самостоятельно создавать Wi-Fi Access Point, развернуть сеть максимум за 60 секунд, обеспечить радиус не менее 50 метров на открытом пространстве, а датчики должны подключаться максимум за 10 секунд и повторять подключение с интервалом не более 5 секунд.
Просим оставить функциональное требование устойчивой беспроводной связи в пределах помещения и исключить жесткие временные параметры, которые зависят от радиообстановки.
3. Обмен между датчиками и приемником должен осуществляться строго через WebSocket RFC 6455, а каждое сообщение — строго в JSON.
WebSocket и JSON являются конкретной технологической реализацией. Функционально эквивалентная система может использовать MQTT, HTTP/REST, UDP, TCP, BLE Mesh, Zigbee либо собственный защищенный протокол и обеспечивать меньшую задержку и лучшую автономность.
Просим заменить конкретный протокол на максимальную допустимую задержку передачи данных.
4. Установлена задержка от физического измерения до интерфейса максимум 500 мс. Для большинства школьных измерений температуры, влажности, давления, освещенности и концентрации газа такая частота не является необходимой.
Просим увеличить допустимую задержку либо дифференцировать ее по видам датчиков.
5. Каждый датчик обязан иметь IP54. Для лабораторной эксплуатации внутри школьного помещения просим снизить требование до IP40/IP20 либо исключить, кроме датчиков, используемых во влажной или наружной среде.
6. Все датчики должны иметь аккумулятор минимум 1000 мА·ч и автономность минимум 24 часа при передаче раз в секунду. Объем аккумулятора сам по себе не является конечной характеристикой.
Просим оставить только минимальную автономность и позволить производителю использовать батарею иной емкости.
7. Ограничение зарядного тока не более 1 А также относится к внутренней системе питания. Современные аккумуляторы могут безопасно заряжаться током 1,5–2 А и быстрее.
Просим исключить максимальный зарядный ток.
8. Требуется ровно 15 типов датчиков, причем каждому жестко присвоен канал 01–15. Номера каналов являются особенностью конкретной программной реализации и не влияют на измерения.
Просим исключить обязательную нумерацию каналов.
9. Температурный датчик должен измерять от -40 до +85°C, при этом далее условия эксплуатации самих датчиков ограничены -20…+60°C. ТС содержит внутреннее несоответствие: датчик должен измерять температуры за пределами разрешенного диапазона эксплуатации собственного оборудования.
Просим согласовать данные показатели и установить диапазон исходя из реальных школьных опытов.
10. Для школьного кабинета диапазон температуры -40…+85°C может быть избыточным. Предлагается -20…+60°C либо иной объективно необходимый диапазон.
11. Анемометр должен измерять скорость до 30 м/с. Просим обосновать, где внутри школьного помещения предполагается поток воздуха 30 м/с и снизить диапазон до фактически необходимого.
12. Датчик освещенности до 65 000 лк также требует обоснования с учетом эксплуатации в помещении.
13. Газовый датчик описан как датчик «летучих органических соединений или CO2» с диапазоном 400–5000 ppm. VOC и CO2 являются различными физическими показателями и измеряются различными сенсорными технологиями.
Просим однозначно определить требуемую физическую величину.
14. «Датчик уровня сигнала» допускается как внешний радиочастотный монитор либо специализированный микрофон/анализатор радиоэфира. Указанные устройства измеряют разные физические параметры.
Просим конкретизировать назначение и единицы измерения.
15. «Универсальный датчик состояния» представляет собой резервный логический или аналоговый модуль без конкретной измеряемой физической величины. Просим либо описать конкретное учебное применение, либо исключить его.
16. Для акселерометра указано, что диапазон должен быть «не менее ±2g и не более ±16g», что допускает неоднозначное толкование. Просим сформулировать «поддержка выбираемых диапазонов, включая ±2g и ±16g» либо указать конкретный требуемый диапазон.
17. «Оптический датчик» одновременно назван спектральным либо инфракрасным датчиком, однако измеряемая величина указана в люксах, что создает техническую неоднозначность. Просим определить, требуется ли датчик освещенности, ИК-датчик или спектральный сенсор.
18. Приемник должен обслуживать не менее 30 WebSocket-соединений при наличии 15 типов датчиков. Просим обосновать двукратный резерв либо снизить до фактического количества устройств.
19. CPU приемника минимум 1,2 ГГц, RAM 1 ГБ и накопитель 8 ГБ являются внутренними характеристиками вычислительного блока. Производитель может достичь требуемой производительности с иной архитектурой.
Просим заменить аппаратные параметры требованием стабильной обработки всех подключенных датчиков без потери данных.
20. Особенно ограничивающим является обязательное использование операционной системы с открытым исходным кодом. Оборудование может работать под RTOS, проприетарной embedded OS или собственной прошивкой.
Просим исключить требование open-source ОС.
21. Требования к пользовательскому интерфейсу фактически воспроизводят готовый дизайн конкретного продукта: Dark Theme, название типа «Sensor Hub», пиктограмма микрочипа, счетчик «X активных датчиков из 15», строго 15 карточек Grid-layout, округленные углы, расположение элементов, конкретная структура каждой карточки.
Дизайн интерфейса не влияет на точность измерений.
22. Просим полностью исключить требования к темной теме, пиктограмме микрочипа, форме карточек, расположению номера канала и цветовому стилю.
23. Статус «НЕАКТИВЕН» должен отображаться именно стилизованной «таблеткой» на строго красном фоне. Это чисто дизайнерская особенность.
Просим заменить на общее требование ясно отображать потерю связи.
24. Каждая карточка обязана отображать историю за последние 10 минут и обновлять график максимум раз в секунду. Просим допустить иной период истории и частоту обновления, достаточную для учебного эксперимента.
25. При потере WebSocket-соединения все 15 карточек должны перейти в НЕАКТИВЕН, графики должны «заморозиться», а центральный счетчик мгновенно показывать ноль. Такая логика также относится к UI конкретного программного продукта.
26. Требование эксплуатации всего комплекса в режиме 24/7/365 является избыточным для мобильного школьного лабораторного оборудования с аккумуляторными датчиками, рассчитанными на 24 часа.
Просим исключить круглосуточный режим либо применить его только к центральному приемнику.
27. Набор датчиков должен оцениваться по образовательной функции, диапазонам и точности, а не по сетевому протоколу, дизайну интерфейса и внутренней архитектуре приемника.
28. Просим сформировать спецификацию через необходимые учебные эксперименты: измерение температуры, влажности, давления, движения, освещенности, напряжения, ускорения, магнитного поля, звука и т.д., предоставив участникам возможность предлагать различные технические реализации.
29. Отдельно просим исключить требования авторизационного письма производителя с QR-кодом, прав на исходный код и иных документов третьих лиц, если они распространяются на данный комплекс, поскольку они не характеризуют точность и функциональность датчиков.
30. В текущей редакции совокупность WebSocket + JSON + 15 фиксированных каналов + Dark Theme + Sensor Hub + точный карточный интерфейс имеет признаки описания конкретного ранее разработанного аппаратно-программного продукта. Просим расширить требования до функциональных эквивалентов.
1. Раздел аппаратно-программного комплекса беспроводных датчиков сформирован с чрезмерной детализацией сетевой архитектуры, аппаратной реализации и пользовательского интерфейса. Вместо определения необходимых учебных измерительных функций ТС фактически предписывает разработчику конкретный способ построения системы.
2. Установлено, что приемник обязан самостоятельно создавать Wi-Fi Access Point, развернуть сеть максимум за 60 секунд, обеспечить радиус не менее 50 метров на открытом пространстве, а датчики должны подключаться максимум за 10 секунд и повторять подключение с интервалом не более 5 секунд.
Просим оставить функциональное требование устойчивой беспроводной связи в пределах помещения и исключить жесткие временные параметры, которые зависят от радиообстановки.
3. Обмен между датчиками и приемником должен осуществляться строго через WebSocket RFC 6455, а каждое сообщение — строго в JSON.
WebSocket и JSON являются конкретной технологической реализацией. Функционально эквивалентная система может использовать MQTT, HTTP/REST, UDP, TCP, BLE Mesh, Zigbee либо собственный защищенный протокол и обеспечивать меньшую задержку и лучшую автономность.
Просим заменить конкретный протокол на максимальную допустимую задержку передачи данных.
4. Установлена задержка от физического измерения до интерфейса максимум 500 мс. Для большинства школьных измерений температуры, влажности, давления, освещенности и концентрации газа такая частота не является необходимой.
Просим увеличить допустимую задержку либо дифференцировать ее по видам датчиков.
5. Каждый датчик обязан иметь IP54. Для лабораторной эксплуатации внутри школьного помещения просим снизить требование до IP40/IP20 либо исключить, кроме датчиков, используемых во влажной или наружной среде.
6. Все датчики должны иметь аккумулятор минимум 1000 мА·ч и автономность минимум 24 часа при передаче раз в секунду. Объем аккумулятора сам по себе не является конечной характеристикой.
Просим оставить только минимальную автономность и позволить производителю использовать батарею иной емкости.
7. Ограничение зарядного тока не более 1 А также относится к внутренней системе питания. Современные аккумуляторы могут безопасно заряжаться током 1,5–2 А и быстрее.
Просим исключить максимальный зарядный ток.
8. Требуется ровно 15 типов датчиков, причем каждому жестко присвоен канал 01–15. Номера каналов являются особенностью конкретной программной реализации и не влияют на измерения.
Просим исключить обязательную нумерацию каналов.
9. Температурный датчик должен измерять от -40 до +85°C, при этом далее условия эксплуатации самих датчиков ограничены -20…+60°C. ТС содержит внутреннее несоответствие: датчик должен измерять температуры за пределами разрешенного диапазона эксплуатации собственного оборудования.
Просим согласовать данные показатели и установить диапазон исходя из реальных школьных опытов.
10. Для школьного кабинета диапазон температуры -40…+85°C может быть избыточным. Предлагается -20…+60°C либо иной объективно необходимый диапазон.
11. Анемометр должен измерять скорость до 30 м/с. Просим обосновать, где внутри школьного помещения предполагается поток воздуха 30 м/с и снизить диапазон до фактически необходимого.
12. Датчик освещенности до 65 000 лк также требует обоснования с учетом эксплуатации в помещении.
13. Газовый датчик описан как датчик «летучих органических соединений или CO2» с диапазоном 400–5000 ppm. VOC и CO2 являются различными физическими показателями и измеряются различными сенсорными технологиями.
Просим однозначно определить требуемую физическую величину.
14. «Датчик уровня сигнала» допускается как внешний радиочастотный монитор либо специализированный микрофон/анализатор радиоэфира. Указанные устройства измеряют разные физические параметры.
Просим конкретизировать назначение и единицы измерения.
15. «Универсальный датчик состояния» представляет собой резервный логический или аналоговый модуль без конкретной измеряемой физической величины. Просим либо описать конкретное учебное применение, либо исключить его.
16. Для акселерометра указано, что диапазон должен быть «не менее ±2g и не более ±16g», что допускает неоднозначное толкование. Просим сформулировать «поддержка выбираемых диапазонов, включая ±2g и ±16g» либо указать конкретный требуемый диапазон.
17. «Оптический датчик» одновременно назван спектральным либо инфракрасным датчиком, однако измеряемая величина указана в люксах, что создает техническую неоднозначность. Просим определить, требуется ли датчик освещенности, ИК-датчик или спектральный сенсор.
18. Приемник должен обслуживать не менее 30 WebSocket-соединений при наличии 15 типов датчиков. Просим обосновать двукратный резерв либо снизить до фактического количества устройств.
19. CPU приемника минимум 1,2 ГГц, RAM 1 ГБ и накопитель 8 ГБ являются внутренними характеристиками вычислительного блока. Производитель может достичь требуемой производительности с иной архитектурой.
Просим заменить аппаратные параметры требованием стабильной обработки всех подключенных датчиков без потери данных.
20. Особенно ограничивающим является обязательное использование операционной системы с открытым исходным кодом. Оборудование может работать под RTOS, проприетарной embedded OS или собственной прошивкой.
Просим исключить требование open-source ОС.
21. Требования к пользовательскому интерфейсу фактически воспроизводят готовый дизайн конкретного продукта: Dark Theme, название типа «Sensor Hub», пиктограмма микрочипа, счетчик «X активных датчиков из 15», строго 15 карточек Grid-layout, округленные углы, расположение элементов, конкретная структура каждой карточки.
Дизайн интерфейса не влияет на точность измерений.
22. Просим полностью исключить требования к темной теме, пиктограмме микрочипа, форме карточек, расположению номера канала и цветовому стилю.
23. Статус «НЕАКТИВЕН» должен отображаться именно стилизованной «таблеткой» на строго красном фоне. Это чисто дизайнерская особенность.
Просим заменить на общее требование ясно отображать потерю связи.
24. Каждая карточка обязана отображать историю за последние 10 минут и обновлять график максимум раз в секунду. Просим допустить иной период истории и частоту обновления, достаточную для учебного эксперимента.
25. При потере WebSocket-соединения все 15 карточек должны перейти в НЕАКТИВЕН, графики должны «заморозиться», а центральный счетчик мгновенно показывать ноль. Такая логика также относится к UI конкретного программного продукта.
26. Требование эксплуатации всего комплекса в режиме 24/7/365 является избыточным для мобильного школьного лабораторного оборудования с аккумуляторными датчиками, рассчитанными на 24 часа.
Просим исключить круглосуточный режим либо применить его только к центральному приемнику.
27. Набор датчиков должен оцениваться по образовательной функции, диапазонам и точности, а не по сетевому протоколу, дизайну интерфейса и внутренней архитектуре приемника.
28. Просим сформировать спецификацию через необходимые учебные эксперименты: измерение температуры, влажности, давления, движения, освещенности, напряжения, ускорения, магнитного поля, звука и т.д., предоставив участникам возможность предлагать различные технические реализации.
29. Отдельно просим исключить требования авторизационного письма производителя с QR-кодом, прав на исходный код и иных документов третьих лиц, если они распространяются на данный комплекс, поскольку они не характеризуют точность и функциональность датчиков.
30. В текущей редакции совокупность WebSocket + JSON + 15 фиксированных каналов + Dark Theme + Sensor Hub + точный карточный интерфейс имеет признаки описания конкретного ранее разработанного аппаратно-программного продукта. Просим расширить требования до функциональных эквивалентов.
