Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069382
Тема сообщения
Нарушения в ТС
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "SilkTech"
Представитель поставщика
ОМИРБЕКОВ САЙЛАУ ЖАКЫПБЕКОВИЧ
Дата и время отправки сообщения
2026-10-02 01:32:46
Текст сообщения
1. Раздел аппаратно-программного комплекса беспроводных датчиков содержит чрезмерно детализированное описание конкретной архитектуры взаимодействия приемника и измерительных модулей, включая обязательную локальную Wi-Fi сеть, режим Access Point, автоматический запуск точки доступа не более чем за 60 секунд, подключение каждого датчика не более чем за 10 секунд, повторное подключение с интервалом не более 5 секунд, обязательное использование исключительно WebSocket RFC 6455 и JSON.
2. Указанные сетевые технологии представляют собой способ реализации функции, а не конечный образовательный результат.
3. Аналогичный комплекс может использовать MQTT, HTTP/2, BLE Mesh, Zigbee, Thread, иной защищенный локальный протокол или сочетание технологий и обеспечивать сопоставимое либо лучшее время доставки телеметрии.
4. Просим заменить требование «строго WebSocket RFC 6455» на функциональное требование надежной двусторонней передачи телеметрических данных в реальном времени с задержкой не более установленного значения.
5. Аналогично формат JSON является внутренним форматом сообщений. Конечный пользователь не взаимодействует непосредственно с JSON-пакетами, поэтому привязка к нему необоснованно исключает бинарные или иные эффективные протоколы.
6. Просим допустить любой стандартизованный формат обмена, обеспечивающий требуемую совместимость и скорость.
7. ТС требует минимум 15 типов датчиков с конкретной нумерацией каналов 01–15 и чрезвычайно подробными диапазонами, включая температуру от -40 до +85 °C, влажность 0–100%, давление 300–1100 hPa, скорость ветра 0–30 м/с, освещенность 0–65000 люкс, газ 400–5000 ppm, радиосигнал, напряжение 0–36 В, заряд батареи, универсальный логический канал, гироскоп, магнитометр, акселерометр, звук и отдельный оптический датчик.
8. Не все указанные диапазоны очевидно необходимы для школьного учебного применения внутри помещения.
9. Например, датчик температуры -40…+85 °C значительно превосходит типовой диапазон безопасной работы в школьной лаборатории, а отдельный датчик ветра до 30 м/с предполагает использование в условиях, нехарактерных для кабинета.
10. Просим обосновать образовательные сценарии, для которых необходим каждый конкретный диапазон.
11. Требование каждого измерительного модуля иметь отдельный корпус IP54 также может исключать модульные лабораторные системы, где датчики подключаются к защищенному интерфейсному блоку и не имеют индивидуального IP54-корпуса.
12. Для внутреннего школьного кабинета обязательная IP54-защита всех 15 независимых модулей требует отдельного обоснования.
13. Просим установить требования к безопасности и механической защите, не требуя конкретного класса IP для каждого датчика, если эксплуатация осуществляется внутри помещения.
14. Каждый датчик должен иметь встроенный аккумулятор не менее 1000 мАч и автономность не менее 24 часов при частоте передачи один раз в секунду.
15. Емкость аккумулятора сама по себе не определяет автономность: энергоэффективное устройство с батареей 700 мАч может работать дольше устройства с батареей 1000 мАч.
16. Просим оставить функциональное требование к автономности не менее 24 часов, исключив минимальную емкость батареи.
17. Ограничение тока зарядки не более 1 А также относится к конструкции электроники производителя и не влияет на образовательные функции.
18. Современный модуль может поддерживать безопасную быструю зарядку 1,5–2 А, что улучшает эксплуатацию.
19. Просим исключить максимальный ток зарядки либо установить только требования электрической безопасности.
20. На стороне приемника требуется открытая операционная система, веб-сервер, WebSocket-сервер, минимум 1,2 ГГц, 1 ГБ RAM и 8 ГБ накопителя.
21. Если приемник с меньшими номинальными характеристиками способен стабильно обслуживать все 30 соединений и визуализировать данные, его исключение только по частоте CPU либо RAM не связано с конечным результатом.
22. Просим устанавливать производительность приемника через количество одновременных датчиков, задержку, стабильность и скорость интерфейса.
23. Особенно детализирован дизайн веб-интерфейса: обязательная темная тема, глубокие темные оттенки, иконка микрочипа, конкретное размещение индикаторов, ровно 15 карточек, визуальные формы индикаторов, красный фон статуса «неактивен», определенная структура каждой карточки.
24. Это описание фактически фиксирует дизайн конкретного готового программного интерфейса, а не его функцию.
25. Функционально эквивалентная система может использовать светлую тему, иной макет, таблицу, графики и иконки, сохраняя всю необходимую информацию.
26. Просим убрать требования к Dark Theme, форме карточек, расположению иконок, цвету конкретного статуса и оставить обязательный состав отображаемой информации.
27. Установлена обязательная история графика именно за последние 10 минут с обновлением не реже одной секунды.
28. Другой комплекс может позволять выбирать 1, 10, 30 минут, час, сутки, что функционально превосходит указанное требование.
29. Просим допустить настраиваемый период отображения при условии наличия периода не менее 10 минут.
30. Необходимо также уточнить, входит ли возможность сохранения исторических данных за более длительный период. При текущей формулировке интерфейс показывает только оперативный десятиминутный график, что недостаточно для полноценных учебных экспериментов длительностью несколько часов или дней.
31. Требование немедленного обнуления центрального счетчика активных датчиков при потере WebSocket-связи также относится к конкретной программной логике. Если соединение кратковременно прервалось, более корректным может быть отображение последнего известного статуса с отметкой времени.
32. Просим не фиксировать внутреннее поведение интерфейса столь детально.
33. Указано, что комплекс должен работать круглосуточно 24/7/365, одновременно каждый датчик рассчитан минимум на 24 часа аккумуляторной работы. Для непрерывного режима потребуется регулярная зарядка датчиков, в течение которой часть каналов может быть недоступна.
34. Просим разъяснить, каким образом обеспечивается заявленный 24/7/365 режим именно для автономных батарейных датчиков.
35. Не определено наличие зарядной станции либо достаточного количества зарядных кабелей.
36. Просим включить в комплект все средства одновременной зарядки датчиков.
37. Требования к рабочей температуре датчиков -20…+60 °C не полностью согласуются с диапазоном самого температурного сенсора -40…+85 °C. Измерительный элемент способен измерять значения, при которых устройство в целом согласно ТС эксплуатироваться не должно.
38. Просим согласовать диапазоны либо пояснить лабораторный способ измерения экстремальных температур без помещения всего модуля в соответствующую среду.
39. Отдельное замечание касается требования предоставить авторизационное письмо производителя с QR-кодом, ведущим на официальный сайт для проверки документа, причем дата письма не может быть ранее даты публикации текущего объявления.
40. Это фактически требует от каждого участника получения специально сформированного документа после публикации конкретной закупки.
41. Производитель может вообще не иметь технической возможности размещать каждое авторизационное письмо в публичной базе с QR-проверкой.
42. Таким образом, поставщик оригинального продукта может быть исключен не по качеству товара, а из-за внутренней процедуры документооборота производителя.
43. Просим допустить иные способы проверки документа: официальный e-mail производителя, электронную цифровую подпись, номер сертификата партнера, проверку дилерского статуса на сайте либо договор дистрибуции.
44. Дополнительно требуется подтверждение прав на реализацию продукта, включая права на исходный код ПО.
45. Обычный поставщик готового аппаратно-программного комплекса не обязан владеть авторскими правами на исходный код производителя и зачастую не имеет доступа к нему.
46. Право продавать лицензионное ПО и владение авторским правом на исходный код — принципиально разные правовые основания.
47. Просим исключить требование наличия у поставщика прав на исходный код и заменить его подтверждением права законного распространения/использования программного обеспечения.
48. При иностранном происхождении товара дополнительно требуется документ официального представителя либо дистрибьютора на территории РК с обязательными датой и сроком действия.
49. Просим допустить международную цепочку поставки и документы иностранных дистрибьюторов, если законность товара подтверждается.
50. Требуемые документы запрещается заменять любым гарантийным письмом, в том числе обязательством представить их после конкурса.
51. Такое условие усиливает зависимость участников от третьих лиц именно на стадии подачи заявки.
52. Для защиты от контрафакта достаточно использовать серийные номера, заводские паспорта, сертификаты происхождения, лицензионные ключи и проверку подлинности на этапе поставки.
53. Просим разделить требования к фактической оригинальности товара и требования к коммерческому статусу конкретного поставщика.
54. Также обращаем внимание, что программное обеспечение датчиков описывается фактически как специализированная самостоятельная разработка. Если Заказчик ожидает конкретную систему, целесообразно либо прямо обосновать совместимость с существующей инфраструктурой, либо обеспечить полноценное допущение функционально эквивалентных решений.
2. Указанные сетевые технологии представляют собой способ реализации функции, а не конечный образовательный результат.
3. Аналогичный комплекс может использовать MQTT, HTTP/2, BLE Mesh, Zigbee, Thread, иной защищенный локальный протокол или сочетание технологий и обеспечивать сопоставимое либо лучшее время доставки телеметрии.
4. Просим заменить требование «строго WebSocket RFC 6455» на функциональное требование надежной двусторонней передачи телеметрических данных в реальном времени с задержкой не более установленного значения.
5. Аналогично формат JSON является внутренним форматом сообщений. Конечный пользователь не взаимодействует непосредственно с JSON-пакетами, поэтому привязка к нему необоснованно исключает бинарные или иные эффективные протоколы.
6. Просим допустить любой стандартизованный формат обмена, обеспечивающий требуемую совместимость и скорость.
7. ТС требует минимум 15 типов датчиков с конкретной нумерацией каналов 01–15 и чрезвычайно подробными диапазонами, включая температуру от -40 до +85 °C, влажность 0–100%, давление 300–1100 hPa, скорость ветра 0–30 м/с, освещенность 0–65000 люкс, газ 400–5000 ppm, радиосигнал, напряжение 0–36 В, заряд батареи, универсальный логический канал, гироскоп, магнитометр, акселерометр, звук и отдельный оптический датчик.
8. Не все указанные диапазоны очевидно необходимы для школьного учебного применения внутри помещения.
9. Например, датчик температуры -40…+85 °C значительно превосходит типовой диапазон безопасной работы в школьной лаборатории, а отдельный датчик ветра до 30 м/с предполагает использование в условиях, нехарактерных для кабинета.
10. Просим обосновать образовательные сценарии, для которых необходим каждый конкретный диапазон.
11. Требование каждого измерительного модуля иметь отдельный корпус IP54 также может исключать модульные лабораторные системы, где датчики подключаются к защищенному интерфейсному блоку и не имеют индивидуального IP54-корпуса.
12. Для внутреннего школьного кабинета обязательная IP54-защита всех 15 независимых модулей требует отдельного обоснования.
13. Просим установить требования к безопасности и механической защите, не требуя конкретного класса IP для каждого датчика, если эксплуатация осуществляется внутри помещения.
14. Каждый датчик должен иметь встроенный аккумулятор не менее 1000 мАч и автономность не менее 24 часов при частоте передачи один раз в секунду.
15. Емкость аккумулятора сама по себе не определяет автономность: энергоэффективное устройство с батареей 700 мАч может работать дольше устройства с батареей 1000 мАч.
16. Просим оставить функциональное требование к автономности не менее 24 часов, исключив минимальную емкость батареи.
17. Ограничение тока зарядки не более 1 А также относится к конструкции электроники производителя и не влияет на образовательные функции.
18. Современный модуль может поддерживать безопасную быструю зарядку 1,5–2 А, что улучшает эксплуатацию.
19. Просим исключить максимальный ток зарядки либо установить только требования электрической безопасности.
20. На стороне приемника требуется открытая операционная система, веб-сервер, WebSocket-сервер, минимум 1,2 ГГц, 1 ГБ RAM и 8 ГБ накопителя.
21. Если приемник с меньшими номинальными характеристиками способен стабильно обслуживать все 30 соединений и визуализировать данные, его исключение только по частоте CPU либо RAM не связано с конечным результатом.
22. Просим устанавливать производительность приемника через количество одновременных датчиков, задержку, стабильность и скорость интерфейса.
23. Особенно детализирован дизайн веб-интерфейса: обязательная темная тема, глубокие темные оттенки, иконка микрочипа, конкретное размещение индикаторов, ровно 15 карточек, визуальные формы индикаторов, красный фон статуса «неактивен», определенная структура каждой карточки.
24. Это описание фактически фиксирует дизайн конкретного готового программного интерфейса, а не его функцию.
25. Функционально эквивалентная система может использовать светлую тему, иной макет, таблицу, графики и иконки, сохраняя всю необходимую информацию.
26. Просим убрать требования к Dark Theme, форме карточек, расположению иконок, цвету конкретного статуса и оставить обязательный состав отображаемой информации.
27. Установлена обязательная история графика именно за последние 10 минут с обновлением не реже одной секунды.
28. Другой комплекс может позволять выбирать 1, 10, 30 минут, час, сутки, что функционально превосходит указанное требование.
29. Просим допустить настраиваемый период отображения при условии наличия периода не менее 10 минут.
30. Необходимо также уточнить, входит ли возможность сохранения исторических данных за более длительный период. При текущей формулировке интерфейс показывает только оперативный десятиминутный график, что недостаточно для полноценных учебных экспериментов длительностью несколько часов или дней.
31. Требование немедленного обнуления центрального счетчика активных датчиков при потере WebSocket-связи также относится к конкретной программной логике. Если соединение кратковременно прервалось, более корректным может быть отображение последнего известного статуса с отметкой времени.
32. Просим не фиксировать внутреннее поведение интерфейса столь детально.
33. Указано, что комплекс должен работать круглосуточно 24/7/365, одновременно каждый датчик рассчитан минимум на 24 часа аккумуляторной работы. Для непрерывного режима потребуется регулярная зарядка датчиков, в течение которой часть каналов может быть недоступна.
34. Просим разъяснить, каким образом обеспечивается заявленный 24/7/365 режим именно для автономных батарейных датчиков.
35. Не определено наличие зарядной станции либо достаточного количества зарядных кабелей.
36. Просим включить в комплект все средства одновременной зарядки датчиков.
37. Требования к рабочей температуре датчиков -20…+60 °C не полностью согласуются с диапазоном самого температурного сенсора -40…+85 °C. Измерительный элемент способен измерять значения, при которых устройство в целом согласно ТС эксплуатироваться не должно.
38. Просим согласовать диапазоны либо пояснить лабораторный способ измерения экстремальных температур без помещения всего модуля в соответствующую среду.
39. Отдельное замечание касается требования предоставить авторизационное письмо производителя с QR-кодом, ведущим на официальный сайт для проверки документа, причем дата письма не может быть ранее даты публикации текущего объявления.
40. Это фактически требует от каждого участника получения специально сформированного документа после публикации конкретной закупки.
41. Производитель может вообще не иметь технической возможности размещать каждое авторизационное письмо в публичной базе с QR-проверкой.
42. Таким образом, поставщик оригинального продукта может быть исключен не по качеству товара, а из-за внутренней процедуры документооборота производителя.
43. Просим допустить иные способы проверки документа: официальный e-mail производителя, электронную цифровую подпись, номер сертификата партнера, проверку дилерского статуса на сайте либо договор дистрибуции.
44. Дополнительно требуется подтверждение прав на реализацию продукта, включая права на исходный код ПО.
45. Обычный поставщик готового аппаратно-программного комплекса не обязан владеть авторскими правами на исходный код производителя и зачастую не имеет доступа к нему.
46. Право продавать лицензионное ПО и владение авторским правом на исходный код — принципиально разные правовые основания.
47. Просим исключить требование наличия у поставщика прав на исходный код и заменить его подтверждением права законного распространения/использования программного обеспечения.
48. При иностранном происхождении товара дополнительно требуется документ официального представителя либо дистрибьютора на территории РК с обязательными датой и сроком действия.
49. Просим допустить международную цепочку поставки и документы иностранных дистрибьюторов, если законность товара подтверждается.
50. Требуемые документы запрещается заменять любым гарантийным письмом, в том числе обязательством представить их после конкурса.
51. Такое условие усиливает зависимость участников от третьих лиц именно на стадии подачи заявки.
52. Для защиты от контрафакта достаточно использовать серийные номера, заводские паспорта, сертификаты происхождения, лицензионные ключи и проверку подлинности на этапе поставки.
53. Просим разделить требования к фактической оригинальности товара и требования к коммерческому статусу конкретного поставщика.
54. Также обращаем внимание, что программное обеспечение датчиков описывается фактически как специализированная самостоятельная разработка. Если Заказчик ожидает конкретную систему, целесообразно либо прямо обосновать совместимость с существующей инфраструктурой, либо обеспечить полноценное допущение функционально эквивалентных решений.
