Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069602
Тема сообщения
Нарушения в ТС, требуем рассмотреть
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "IT-Quantum"
Представитель поставщика
ҚАЙРАТҰЛЫ БАУЫРЖАН
Дата и время отправки сообщения
2026-10-06 00:38:03
Текст сообщения
1. Раздел аппаратно-программного комплекса беспроводных измерительных датчиков содержит чрезмерно детализированное описание не только функциональности оборудования, но и конкретного сетевого протокола, формата сообщений, программной архитектуры, структуры пользовательского интерфейса и его визуального оформления.
2. Комплекс должен включать центральный приемно-вычислительный модуль и набор минимум 15 типов отдельных беспроводных датчиков.
3. Само количество типов датчиков может быть обосновано образовательной задачей, однако ТС далее фиксирует практически всю внутреннюю реализацию системы.
4. Приемник должен самостоятельно формировать локальную Wi-Fi сеть, работать как Access Point, разворачивать точку доступа не позднее 60 секунд после включения и обеспечивать радиус покрытия не менее 50 метров на открытом пространстве.
5. Каждый датчик должен подключаться к приемнику не более чем за 10 секунд и после потери связи повторять попытки подключения с интервалом не более пяти секунд.
6. Передача данных должна осуществляться строго по WebSocket согласно RFC 6455, причем каждое сообщение обязано иметь именно JSON-структуру.
7. WebSocket и JSON являются способом внутренней программной реализации. Функционально эквивалентная система может использовать MQTT, HTTPS, CoAP, WebRTC DataChannel, protobuf либо иной протокол и обеспечивать такую же или меньшую задержку.
8. Привязка к конкретному протоколу без необходимости интеграции с существующим API Заказчика необоснованно ограничивает архитектуру производителя.
9. Просим определить конечные показатели: локальная автономная работа без Интернета, частота обновления данных, задержка, безопасность, возможность одновременного подключения необходимого количества датчиков — без обязательного WebSocket/JSON.
10. Каждый датчик должен иметь жестко запрограммированный ID минимум восемь символов, передавать заряд в процентах и RSSI в dBm, обладать аккумулятором минимум 1000 мАч и автономностью минимум 24 часа при частоте передачи раз в секунду.
11. Емкость батареи сама по себе не является конечным эксплуатационным результатом. Устройство с аккумулятором 800 мАч и автономностью 30 часов объективно не хуже, но формально не соответствует.
12. Просим оставить требование автономной работы и исключить жесткую минимальную емкость.
13. Также ограничен зарядный ток не более 1 А. Современная батарея может безопасно заряжаться током 2 А и завершать заряд существенно быстрее.
14. Увеличение безопасного зарядного тока не является ухудшением характеристики.
15. Просим исключить верхний предел 1 А либо установить соответствие штатному зарядному режиму производителя.
16. Перечень 15 датчиков включает температуру, влажность, давление, скорость ветра, освещенность, газ, радиосигнал/звук, напряжение, заряд батареи, универсальное состояние, гироскоп, магнитометр, акселерометр, звук и отдельный оптический датчик.
17. Некоторые позиции функционально пересекаются. Например, датчик освещенности и оптический датчик оба измеряют световые параметры; датчик уровня сигнала допускается в описании как микрофон/анализатор радиоэфира, что делает сам измеряемый физический параметр неоднозначным.
18. Просим конкретизировать учебные эксперименты и требуемый результат каждого сенсора.
19. Особенно необычным является «датчик заряда батареи» для тестирования внешних аккумуляторных ячеек в диапазоне 0–100%. Процент заряда не является непосредственно измеряемой универсальной физической величиной без знания химии, номинального напряжения и модели аккумулятора.
20. Просим указать методику определения процента либо заменить параметр измерением напряжения.
21. Универсальный датчик состояния описан как резервный логический или аналоговый модуль, передающий безразмерные величины или логический 0/1. Не указано количество входов, диапазон напряжений и допустимый способ подключения.
22. Данный пункт требует технического уточнения.
23. Приемник должен поддерживать минимум 30 WebSocket-соединений, иметь CPU не менее 1,2 ГГц, RAM 1 ГБ, storage 8 ГБ и работать под ОС с открытым исходным кодом.
24. Производительность системы не может объективно оцениваться только по частоте процессора. Современная система на ином CPU либо микроконтроллере может обеспечивать все требуемые 30 соединений при частоте менее 1,2 ГГц.
25. Просим нормировать количество подключений и скорость обновления, а не внутреннюю частоту CPU.
26. ТС подробно фиксирует внешний вид веб-интерфейса: обязательная темная тема, глубокий черный/темно-серый фон, название типа Sensor Hub, стилизованная пиктограмма микрочипа, текстовый счетчик активных датчиков, строго 15 информационных карточек, расположение элементов внутри карточки, номер в овале/круге, определенные единицы измерения, график последних десяти минут, батарея слева, активность по центру, Wi-Fi справа.
27. Также прямо задается состояние «НЕАКТИВЕН» на красном фоне в виде стилизованной таблетки/кнопки.
28. Эти требования относятся к графическому дизайну конкретного интерфейса и не определяют образовательную ценность продукта.
29. Эквивалентная система может иметь светлую тему, список вместо карточек, единый график нескольких датчиков, другое расположение статусов либо иные иконки.
30. Просим удалить требования к цвету, форме, расположению элементов и визуальной теме, оставив обязательным отображение текущего значения, статуса связи, заряда и истории показаний.
31. Требование хранить историю именно 10 минут также нуждается в пересмотре. Система, хранящая историю час, день или месяц, функционально лучше.
32. Необходимо установить «не менее 10 минут», а не конструктивно ограничивать интерфейс.
33. ТС содержит гарантийное требование замены неисправного компонента в срок не более 15 рабочих часов.
34. Формулировка именно в рабочих часах крайне жесткая. Если неисправность подтверждается вечером, перед выходными либо требуется поставка откалиброванного датчика, соблюдение такого SLA может быть практически невозможно.
35. Просим определить срок реакции и срок замены отдельно и использовать реалистичный срок в рабочих днях.
36. Наиболее существенным ограничивающим условием вновь является обязанность участника приложить к заявке авторизационное письмо производителя на поставку продукта, причем письмо должно содержать QR-код для проверки информации на официальном сайте.
37. Наличие QR-кода на авторизационном письме является чрезвычайно специфичным требованием к внутренней системе документооборота производителя.
38. Многие известные производители выдают подписанные авторизационные письма без онлайн-сервиса проверки и QR-кода. Отсутствие QR-кода не делает письмо менее подлинным.
39. Просим исключить обязательный QR-код либо допустить иные способы проверки документа.
40. Также участник должен предоставить документы на право реализации продукта, сформулированные как «авторское право на исходный код ПО». Как и в разделе образовательной платформы, право распространения и право собственности на исходный код юридически не тождественны.
41. Если оборудование производится иностранной компанией, дополнительно требуется документ официального представителя или дистрибьютора на территории Республики Казахстан.
42. Совокупность данных требований фактически ограничивает участие компаниями, уже включенными производителем в локальную дистрибьюторскую цепочку до объявления закупки.
43. Просим допустить подтверждение оригинальности и лицензионности при поставке и исключить квалификационные требования из ТС.
44. В самой ТС прямо указано, что установление квалификационных требований к потенциальному поставщику не допускается.
45. В целом комплекс датчиков следует описывать через перечень физических величин, диапазоны и точность измерений, автономность, количество одновременных устройств, частоту обновления, безопасность и способы визуализации, не фиксируя конкретный транспортный протокол, JSON, ОС, оформление dashboard и механизм авторизации поставщика.
2. Комплекс должен включать центральный приемно-вычислительный модуль и набор минимум 15 типов отдельных беспроводных датчиков.
3. Само количество типов датчиков может быть обосновано образовательной задачей, однако ТС далее фиксирует практически всю внутреннюю реализацию системы.
4. Приемник должен самостоятельно формировать локальную Wi-Fi сеть, работать как Access Point, разворачивать точку доступа не позднее 60 секунд после включения и обеспечивать радиус покрытия не менее 50 метров на открытом пространстве.
5. Каждый датчик должен подключаться к приемнику не более чем за 10 секунд и после потери связи повторять попытки подключения с интервалом не более пяти секунд.
6. Передача данных должна осуществляться строго по WebSocket согласно RFC 6455, причем каждое сообщение обязано иметь именно JSON-структуру.
7. WebSocket и JSON являются способом внутренней программной реализации. Функционально эквивалентная система может использовать MQTT, HTTPS, CoAP, WebRTC DataChannel, protobuf либо иной протокол и обеспечивать такую же или меньшую задержку.
8. Привязка к конкретному протоколу без необходимости интеграции с существующим API Заказчика необоснованно ограничивает архитектуру производителя.
9. Просим определить конечные показатели: локальная автономная работа без Интернета, частота обновления данных, задержка, безопасность, возможность одновременного подключения необходимого количества датчиков — без обязательного WebSocket/JSON.
10. Каждый датчик должен иметь жестко запрограммированный ID минимум восемь символов, передавать заряд в процентах и RSSI в dBm, обладать аккумулятором минимум 1000 мАч и автономностью минимум 24 часа при частоте передачи раз в секунду.
11. Емкость батареи сама по себе не является конечным эксплуатационным результатом. Устройство с аккумулятором 800 мАч и автономностью 30 часов объективно не хуже, но формально не соответствует.
12. Просим оставить требование автономной работы и исключить жесткую минимальную емкость.
13. Также ограничен зарядный ток не более 1 А. Современная батарея может безопасно заряжаться током 2 А и завершать заряд существенно быстрее.
14. Увеличение безопасного зарядного тока не является ухудшением характеристики.
15. Просим исключить верхний предел 1 А либо установить соответствие штатному зарядному режиму производителя.
16. Перечень 15 датчиков включает температуру, влажность, давление, скорость ветра, освещенность, газ, радиосигнал/звук, напряжение, заряд батареи, универсальное состояние, гироскоп, магнитометр, акселерометр, звук и отдельный оптический датчик.
17. Некоторые позиции функционально пересекаются. Например, датчик освещенности и оптический датчик оба измеряют световые параметры; датчик уровня сигнала допускается в описании как микрофон/анализатор радиоэфира, что делает сам измеряемый физический параметр неоднозначным.
18. Просим конкретизировать учебные эксперименты и требуемый результат каждого сенсора.
19. Особенно необычным является «датчик заряда батареи» для тестирования внешних аккумуляторных ячеек в диапазоне 0–100%. Процент заряда не является непосредственно измеряемой универсальной физической величиной без знания химии, номинального напряжения и модели аккумулятора.
20. Просим указать методику определения процента либо заменить параметр измерением напряжения.
21. Универсальный датчик состояния описан как резервный логический или аналоговый модуль, передающий безразмерные величины или логический 0/1. Не указано количество входов, диапазон напряжений и допустимый способ подключения.
22. Данный пункт требует технического уточнения.
23. Приемник должен поддерживать минимум 30 WebSocket-соединений, иметь CPU не менее 1,2 ГГц, RAM 1 ГБ, storage 8 ГБ и работать под ОС с открытым исходным кодом.
24. Производительность системы не может объективно оцениваться только по частоте процессора. Современная система на ином CPU либо микроконтроллере может обеспечивать все требуемые 30 соединений при частоте менее 1,2 ГГц.
25. Просим нормировать количество подключений и скорость обновления, а не внутреннюю частоту CPU.
26. ТС подробно фиксирует внешний вид веб-интерфейса: обязательная темная тема, глубокий черный/темно-серый фон, название типа Sensor Hub, стилизованная пиктограмма микрочипа, текстовый счетчик активных датчиков, строго 15 информационных карточек, расположение элементов внутри карточки, номер в овале/круге, определенные единицы измерения, график последних десяти минут, батарея слева, активность по центру, Wi-Fi справа.
27. Также прямо задается состояние «НЕАКТИВЕН» на красном фоне в виде стилизованной таблетки/кнопки.
28. Эти требования относятся к графическому дизайну конкретного интерфейса и не определяют образовательную ценность продукта.
29. Эквивалентная система может иметь светлую тему, список вместо карточек, единый график нескольких датчиков, другое расположение статусов либо иные иконки.
30. Просим удалить требования к цвету, форме, расположению элементов и визуальной теме, оставив обязательным отображение текущего значения, статуса связи, заряда и истории показаний.
31. Требование хранить историю именно 10 минут также нуждается в пересмотре. Система, хранящая историю час, день или месяц, функционально лучше.
32. Необходимо установить «не менее 10 минут», а не конструктивно ограничивать интерфейс.
33. ТС содержит гарантийное требование замены неисправного компонента в срок не более 15 рабочих часов.
34. Формулировка именно в рабочих часах крайне жесткая. Если неисправность подтверждается вечером, перед выходными либо требуется поставка откалиброванного датчика, соблюдение такого SLA может быть практически невозможно.
35. Просим определить срок реакции и срок замены отдельно и использовать реалистичный срок в рабочих днях.
36. Наиболее существенным ограничивающим условием вновь является обязанность участника приложить к заявке авторизационное письмо производителя на поставку продукта, причем письмо должно содержать QR-код для проверки информации на официальном сайте.
37. Наличие QR-кода на авторизационном письме является чрезвычайно специфичным требованием к внутренней системе документооборота производителя.
38. Многие известные производители выдают подписанные авторизационные письма без онлайн-сервиса проверки и QR-кода. Отсутствие QR-кода не делает письмо менее подлинным.
39. Просим исключить обязательный QR-код либо допустить иные способы проверки документа.
40. Также участник должен предоставить документы на право реализации продукта, сформулированные как «авторское право на исходный код ПО». Как и в разделе образовательной платформы, право распространения и право собственности на исходный код юридически не тождественны.
41. Если оборудование производится иностранной компанией, дополнительно требуется документ официального представителя или дистрибьютора на территории Республики Казахстан.
42. Совокупность данных требований фактически ограничивает участие компаниями, уже включенными производителем в локальную дистрибьюторскую цепочку до объявления закупки.
43. Просим допустить подтверждение оригинальности и лицензионности при поставке и исключить квалификационные требования из ТС.
44. В самой ТС прямо указано, что установление квалификационных требований к потенциальному поставщику не допускается.
45. В целом комплекс датчиков следует описывать через перечень физических величин, диапазоны и точность измерений, автономность, количество одновременных устройств, частоту обновления, безопасность и способы визуализации, не фиксируя конкретный транспортный протокол, JSON, ОС, оформление dashboard и механизм авторизации поставщика.
