Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1068721
Тема сообщения
Нарушения в ТС
Тип сообщения
Запрос о разъяснении АД
Поставщик
АРУЖАН
Представитель поставщика
КУЛАКОВ БЕЙБИТ МАДАТАЕВИЧ
Дата и время отправки сообщения
2026-09-24 22:56:12
Текст сообщения
ЗАПРОСЫ
1. Почему для подтверждения легальности ПО недостаточно лицензионного сертификата или договора поставки?
2. Почему требуется именно персональное авторизационное письмо производителя?
3. Почему авторизационное письмо должно содержать QR-код?
4. Каким нормативным требованием предусмотрен QR-код?
5. Почему дата письма не может предшествовать публикации закупки?
6. Может ли действующий официальный дилерский сертификат быть предоставлен вместо нового письма?
7. Почему запрещена замена авторизационного документа гарантийным письмом?
8. Почему поставщик готового ПО должен иметь права на исходный код?
9. Требуется ли передача исходного кода Заказчику?
10. Кто будет являться правообладателем после поставки?
11. Если передаются только неисключительные права использования, зачем участнику авторские права на исходный код?
12. Почему иностранный разработчик обязан иметь представителя в Казахстане?
13. Допускается ли прямой договор участника с иностранным разработчиком?
14. Допускается ли поставка через международного реселлера?
15. Почему требуется протокол обследования именно сетевой инфраструктуры?
16. Какая конкретная сеть исследуется данным протоколом — сеть разработчика или сеть Заказчика?
17. Если сеть Заказчика еще не исследовалась поставщиком, каким образом заранее существующий протокол подтверждает ее безопасность?
18. Почему протокол должен быть выдан именно NCA-аккредитованной лабораторией?
19. Допускается ли лаборатория ILAC?
20. Допускается ли иностранная лаборатория?
21. Почему нужен отдельный протокол процессов информационной безопасности?
22. Какой конкретный стандарт проверяется этим протоколом?
23. Почему недостаточно ISO/IEC 27001?
24. Почему нагрузочные испытания должны быть проведены до подачи заявки?
25. Какая минимальная нагрузка должна быть подтверждена протоколом?
26. Должны ли испытания подтверждать 100 или 1000 пользователей?
27. Почему требуется SAST?
28. Какие классы уязвимостей должны проверяться?
29. Почему разработчик обязан раскрывать исходный код сторонней лаборатории?
30. Допускается ли SAST, проведенный собственным подразделением безопасности разработчика?
31. Допускаются ли отчеты SonarQube, Fortify, Checkmarx, Veracode и аналогичных средств?
32. Почему требуется СТ РК ISO/IEC 15408-2-2017?
33. Какой объект оценки определяется?
34. Какой профиль защиты используется?
35. Какой уровень доверия требуется?
36. Почему отсутствие одного протокола ведет к автоматическому несоответствию?
37. Просим назвать минимум два продукта, имеющих все пять документов.
38. Почему ПО должно включать ровно 18 модулей?
39. Как Заказчик проверит количество модулей без доступа к исходному коду?
40. Почему именно reverse proxy?
41. Допускается ли managed load balancer?
42. Допускается ли cloud-native архитектура?
43. Почему требуется 1000 одновременных подключений?
44. Какова максимальная численность учащихся лицея в одну смену?
45. Сколько устройств реально будет одновременно подключено?
46. Почему серверная конфигурация указана для 100 пользователей?
47. Просим устранить расхождение 100/1000.
48. Почему учетные записи должны быть без количественного ограничения?
49. Является ли лицензия бессрочной?
50. На какой срок должны работать обновления?
51. Должна ли техническая поддержка продолжаться после 12 месяцев?
52. Кто оплачивает серверную инфраструктуру после окончания гарантии?
53. Где физически размещается сервер?
54. Кто предоставляет домен и SSL-сертификат?
55. Кто обеспечивает резервный массив?
56. Что конкретно входит в RTO 4 часа?
57. Почему RPO 24 часа?
58. Почему требуется до трех кликов на любую функцию?
59. Как Заказчик будет измерять количество кликов?
60. Почему touch target именно 44×44?
61. Почему минимум 16 млн цветов?
62. Почему минимум 10 инструментов рисования?
63. Почему минимум 10 точек на 3D-модели?
64. Почему минимум 500 символов на всплывающую карточку?
65. Почему 3 базовых ракурса?
66. Почему видео ограничено 15 минутами?
67. Допустимо ли часовое учебное видео?
68. Почему WebSocket обязателен?
69. Почему JSON обязателен?
70. Допустим ли MQTT over TLS?
71. Допустим ли gRPC?
72. Почему данные должны отправляться именно раз в секунду?
73. Можно ли использовать адаптивный интервал передачи?
74. Почему каждый датчик должен иметь батарею минимум 1000 мА·ч?
75. Что важнее — емкость или 24 часа работы?
76. Почему зарядный ток максимум 1 А?
77. Почему интерфейс должен быть темным?
78. Почему нельзя использовать светлую тему?
79. Почему требуется надпись Sensor Hub?
80. Почему необходима пиктограмма микрочипа?
81. Почему карточки должны быть с закругленными углами?
82. Почему статус НЕАКТИВЕН отображается именно красным фоном?
83. Почему требуется ровно 15 виджетов?
84. Может ли одна страница отображать датчики таблицей?
85. Почему центр электрической безопасности должен поддерживать 64 устройства?
86. Почему не 16?
87. Сколько устройств планируется добавить фактически?
88. Почему ИК-подсветка не должна превышать 15 м?
89. Будет ли 20 м ухудшением?
90. Почему карта памяти ограничена максимум 256 ГБ?
91. Будет ли поддержка 512 ГБ основанием для отклонения?
92. Почему требуется microSD либо только компактный аналог?
93. Допускается ли встроенная eMMC?
94. Почему розетка должна выполнять сценарии по погоде?
95. Как погода связана с электрической безопасностью школьного кабинета?
96. Почему обязательно управление по восходу и закату?
97. Можно ли исключить эти функции?
98. Почему розетка должна поддерживать 16 А и 3,5 кВт?
99. Какая максимальная фактическая нагрузка будет подключаться?
100. Почему реакция приложения должна быть до 2 секунд?
101. Как это проверяется при нестабильном интернете?
102. Почему перегрузка должна отключаться именно до 1 секунды?
103. Какой стандарт определяет данное значение?
104. Почему выключатель должен выдерживать 100 000 циклов?
105. Каким документом это подтверждается?
106. Почему нужна 2FA?
107. Может ли безопасная учетная запись без 2FA соответствовать?
108. Почему требуется AES-128 именно на уровне приложения?
109. Допустим ли TLS 1.3 с иным набором шифров?
110. Почему требуется возможность разделения прав между «семьей или коллегами» в школьной системе?
111. Просим убрать бытовые функции, не связанные с учебным использованием.
112. Почему поставщик обязан иметь авторизованный или собственный сервисный центр в течение всего срока эксплуатации?
113. Каков заявленный срок эксплуатации?
114. Может ли гарантийный сервис выполняться путем замены оборудования без локального сервисного центра?
115. Просим подтвердить возможность исключения требований, зависящих от производителя и третьих лиц.
1. Почему для подтверждения легальности ПО недостаточно лицензионного сертификата или договора поставки?
2. Почему требуется именно персональное авторизационное письмо производителя?
3. Почему авторизационное письмо должно содержать QR-код?
4. Каким нормативным требованием предусмотрен QR-код?
5. Почему дата письма не может предшествовать публикации закупки?
6. Может ли действующий официальный дилерский сертификат быть предоставлен вместо нового письма?
7. Почему запрещена замена авторизационного документа гарантийным письмом?
8. Почему поставщик готового ПО должен иметь права на исходный код?
9. Требуется ли передача исходного кода Заказчику?
10. Кто будет являться правообладателем после поставки?
11. Если передаются только неисключительные права использования, зачем участнику авторские права на исходный код?
12. Почему иностранный разработчик обязан иметь представителя в Казахстане?
13. Допускается ли прямой договор участника с иностранным разработчиком?
14. Допускается ли поставка через международного реселлера?
15. Почему требуется протокол обследования именно сетевой инфраструктуры?
16. Какая конкретная сеть исследуется данным протоколом — сеть разработчика или сеть Заказчика?
17. Если сеть Заказчика еще не исследовалась поставщиком, каким образом заранее существующий протокол подтверждает ее безопасность?
18. Почему протокол должен быть выдан именно NCA-аккредитованной лабораторией?
19. Допускается ли лаборатория ILAC?
20. Допускается ли иностранная лаборатория?
21. Почему нужен отдельный протокол процессов информационной безопасности?
22. Какой конкретный стандарт проверяется этим протоколом?
23. Почему недостаточно ISO/IEC 27001?
24. Почему нагрузочные испытания должны быть проведены до подачи заявки?
25. Какая минимальная нагрузка должна быть подтверждена протоколом?
26. Должны ли испытания подтверждать 100 или 1000 пользователей?
27. Почему требуется SAST?
28. Какие классы уязвимостей должны проверяться?
29. Почему разработчик обязан раскрывать исходный код сторонней лаборатории?
30. Допускается ли SAST, проведенный собственным подразделением безопасности разработчика?
31. Допускаются ли отчеты SonarQube, Fortify, Checkmarx, Veracode и аналогичных средств?
32. Почему требуется СТ РК ISO/IEC 15408-2-2017?
33. Какой объект оценки определяется?
34. Какой профиль защиты используется?
35. Какой уровень доверия требуется?
36. Почему отсутствие одного протокола ведет к автоматическому несоответствию?
37. Просим назвать минимум два продукта, имеющих все пять документов.
38. Почему ПО должно включать ровно 18 модулей?
39. Как Заказчик проверит количество модулей без доступа к исходному коду?
40. Почему именно reverse proxy?
41. Допускается ли managed load balancer?
42. Допускается ли cloud-native архитектура?
43. Почему требуется 1000 одновременных подключений?
44. Какова максимальная численность учащихся лицея в одну смену?
45. Сколько устройств реально будет одновременно подключено?
46. Почему серверная конфигурация указана для 100 пользователей?
47. Просим устранить расхождение 100/1000.
48. Почему учетные записи должны быть без количественного ограничения?
49. Является ли лицензия бессрочной?
50. На какой срок должны работать обновления?
51. Должна ли техническая поддержка продолжаться после 12 месяцев?
52. Кто оплачивает серверную инфраструктуру после окончания гарантии?
53. Где физически размещается сервер?
54. Кто предоставляет домен и SSL-сертификат?
55. Кто обеспечивает резервный массив?
56. Что конкретно входит в RTO 4 часа?
57. Почему RPO 24 часа?
58. Почему требуется до трех кликов на любую функцию?
59. Как Заказчик будет измерять количество кликов?
60. Почему touch target именно 44×44?
61. Почему минимум 16 млн цветов?
62. Почему минимум 10 инструментов рисования?
63. Почему минимум 10 точек на 3D-модели?
64. Почему минимум 500 символов на всплывающую карточку?
65. Почему 3 базовых ракурса?
66. Почему видео ограничено 15 минутами?
67. Допустимо ли часовое учебное видео?
68. Почему WebSocket обязателен?
69. Почему JSON обязателен?
70. Допустим ли MQTT over TLS?
71. Допустим ли gRPC?
72. Почему данные должны отправляться именно раз в секунду?
73. Можно ли использовать адаптивный интервал передачи?
74. Почему каждый датчик должен иметь батарею минимум 1000 мА·ч?
75. Что важнее — емкость или 24 часа работы?
76. Почему зарядный ток максимум 1 А?
77. Почему интерфейс должен быть темным?
78. Почему нельзя использовать светлую тему?
79. Почему требуется надпись Sensor Hub?
80. Почему необходима пиктограмма микрочипа?
81. Почему карточки должны быть с закругленными углами?
82. Почему статус НЕАКТИВЕН отображается именно красным фоном?
83. Почему требуется ровно 15 виджетов?
84. Может ли одна страница отображать датчики таблицей?
85. Почему центр электрической безопасности должен поддерживать 64 устройства?
86. Почему не 16?
87. Сколько устройств планируется добавить фактически?
88. Почему ИК-подсветка не должна превышать 15 м?
89. Будет ли 20 м ухудшением?
90. Почему карта памяти ограничена максимум 256 ГБ?
91. Будет ли поддержка 512 ГБ основанием для отклонения?
92. Почему требуется microSD либо только компактный аналог?
93. Допускается ли встроенная eMMC?
94. Почему розетка должна выполнять сценарии по погоде?
95. Как погода связана с электрической безопасностью школьного кабинета?
96. Почему обязательно управление по восходу и закату?
97. Можно ли исключить эти функции?
98. Почему розетка должна поддерживать 16 А и 3,5 кВт?
99. Какая максимальная фактическая нагрузка будет подключаться?
100. Почему реакция приложения должна быть до 2 секунд?
101. Как это проверяется при нестабильном интернете?
102. Почему перегрузка должна отключаться именно до 1 секунды?
103. Какой стандарт определяет данное значение?
104. Почему выключатель должен выдерживать 100 000 циклов?
105. Каким документом это подтверждается?
106. Почему нужна 2FA?
107. Может ли безопасная учетная запись без 2FA соответствовать?
108. Почему требуется AES-128 именно на уровне приложения?
109. Допустим ли TLS 1.3 с иным набором шифров?
110. Почему требуется возможность разделения прав между «семьей или коллегами» в школьной системе?
111. Просим убрать бытовые функции, не связанные с учебным использованием.
112. Почему поставщик обязан иметь авторизованный или собственный сервисный центр в течение всего срока эксплуатации?
113. Каков заявленный срок эксплуатации?
114. Может ли гарантийный сервис выполняться путем замены оборудования без локального сервисного центра?
115. Просим подтвердить возможность исключения требований, зависящих от производителя и третьих лиц.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-03 01:09:43
Автор:
САДУОВ СЕРИК ИСЛЯМОВИЧ
Решение:
Представить разъяснение положений аукционной документации
1. Лицензионный сертификат или общий договор поставки без подтверждения полномочий от производителя декларирует лишь факт передачи прав между посредниками, но не удостоверяет легальность первоначального ввода программного обеспечения в гражданский оборот и готовность правообладателя нести гарантийные обязательства по регламенту SLA (исправление программных дефектов и уязвимостей). 2. Предоставление авторизационного документа от производителя либо его официального представителя на территории РК является общепринятым инструментом, подтверждающим реальное согласие правообладателя на отгрузку оригинального продукта конечному государственному пользователю и распространение заводской гарантийной поддержки. 3. Наличие QR-кода на авторизационном письме обеспечивает конкурсной комиссии возможность экспресс-проверки подлинности документа на официальном сетевом ресурсе вендора/правообладателя в режиме реального времени без направления длительных письменных запросов. 4. Инструменты верификации определяются в соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках» и открытыми стандартами цифрового документооборота в целях пресечения оборота фальсифицированных писем и защиты бюджетных средств от недобросовестных посредников. 5. Заказчиком принято решение об исключении из технической спецификации требования о том, что дата выдачи письма не должна предшествовать дате публикации объявления о проведении текущего конкурса (согласно предписанию ДВГА). В техническую спецификацию вносятся соответствующие изменения. 6. Да, действующий официальный дилерский, партнерский или дистрибьюторский сертификат/договор, выданный до публикации объявления, признается Заказчиком надлежащим подтверждением полномочий в пределах срока его действия. 7. Простое гарантийное письмо от потенциального поставщика декларирует лишь его собственные намерения и не подтверждает фактического согласия вендора/правообладателя на предоставление неисключительных прав и официальной технической поддержки. 8. В технической спецификации указано общее требование подтверждения законности распространения продукта. Указание в скобках «(авторское право на исходный код ПО)» приведено в качестве примера для поставщиков, являющихся непосредственными разработчиками-правообладателями. 9. Нет, передача исходного кода программного обеспечения Заказчику не требуется; доступ к системе организуется через веб-браузер. 10. Правообладатель сохраняет исключительные авторские права на программный продукт; Заказчику передаются неисключительные права на использование ПО в образовательной организации («campus license»). 11. Поставщик не обязан являться владельцем исходного кода; законность поставки подтверждается стандартными дилерскими, дистрибьюторскими или лицензионными соглашениями о передаче неисключительных прав на распространение от правообладателя. 12. Наличие официального представительства или уполномоченного дистрибьютора на территории Республики Казахстан гарантирует юрисдикцию РК, локализацию гарантийного сервиса и соблюдение регламентов SLA технической поддержки (4–24 часа). 13. Прямой контракт с зарубежным правообладателем допускается при условии обеспечения гарантийного обслуживания, SLA и технической поддержки на государственном и русском языках на территории Республики Казахстан. 14. Поставка допускается при подтверждении официальной цепочки партнерских полномочий от разработчика и обеспечения гарантийных обязательств в Республике Казахстан. 15. Закупаемое программное обеспечение разворачивается в локальной сети лицея и взаимодействует с моноблоками и устройствами учащихся. Протокол исследования сетевой инфраструктуры подтверждает защищенность клиент-серверных взаимодействий платформы от атак перехвата и подмены учебного контента (Man-in-the-Middle). 16. Исследуется сетевая архитектура и протоколы взаимодействия самого поставляемого программного продукта в стандартных условиях локальных вычислительных сетей организаций образования. 17. Протокол подтверждает корректность сетевых настроек и защищенность программного стека платформы, исключая уязвимости до момента ее инсталляции в школьную сеть. 18. В государственных закупках Республики Казахстан юридическую силу имеют официальные документы испытательных лабораторий, аккредитованных в национальной системе аккредитации (NCA) РК в соответствии с Законом РК «О техническом регулировании». 19. Документы лабораторий с аккредитацией ILAC признаются на территории Республики Казахстан исключительно при прохождении процедур нострификации и подтверждения соответствия в порядке, установленном законодательством РК. 20. Протоколы зарубежных лабораторий подлежат обязательному подтверждению и валидации в соответствии с законодательством Республики Казахстан о техническом регулировании. 21. Протокол подтверждает внедрение разработчиком регламентов DevSecOps, контроль доступа к дидактическим медиабазам и способность оперативно выпускать защитные обновления (патчи) при выявлении новых киберугроз. 22. Проверяются процедуры безопасного жизненного цикла разработки ПО (Secure SDLC/DevSecOps) и регламенты обеспечения информационной безопасности. 23. Сертификат ISO/IEC 27001 подтверждает общие процессы менеджмента информационной безопасности юридического лица, но не удостоверяет отсутствие дефектов и уязвимостей в конкретном поставляемом программном продукте. 24. Проведение нагрузочных испытаний до подачи заявки подтверждает зрелость и стабильность тиражного программного продукта при пиковых массовых обращениях пользователей. 25. Протокол должен подтверждать устойчивость серверного ядра платформы при одновременной нагрузке до 1000 активных сетевых соединений (WebSocket/HTTP). 26. Протокол предоставляется на сетевую масштабируемость программного ядра платформы (до 1000 соединений). 27. Статический анализ исходного кода (SAST) необходим для подтверждения отсутствия в коде скрытых недекларированных возможностей («закладок», вредоносных скриптов, уязвимостей переполнения буфера). 28. Проверяются базовые классы уязвимостей (CWE/OWASP, переполнение буфера, инъекции кода, недекларированные функции). 29. Статический анализ проводится испытательной лабораторией в условиях государственной аттестации и строгого соблюдения конфиденциальности (NDA); поставщик запрашивает у правообладателя готовый протокол плановой сертификации продукта. 30. Внутренний аудит разработчика носит декларативный характер и не заменяет независимой экспертизы аккредитованной испытательной лаборатории государственной системы NCA РК. 31. Отчеты автоматизированных сканеров (SonarQube, Fortify и др.) могут использоваться лабораторией в качестве инструментальной базы, однако итоговым документом является официальный протокол испытаний аккредитованной лаборатории NCA РК. 32. Государственный стандарт СТ РК ISO/IEC 15408-2-2017 является действующим национальным стандартом Республики Казахстан; протокол подтверждает надежность функций идентификации, аутентификации и разграничения ролевого доступа. 33. Объектом оценки выступает прикладная программная платформа для интерактивного обучения. 34. Профиль защиты определяется функциональными компонентами безопасности в соответствии с частью 2 стандарта СТ РК ISO/IEC 15408-2-2017. 35. Оценочный уровень доверия устанавливается утвержденными методиками испытательной лаборатории для прикладного образовательного софта. 36. Каждый из пяти протоколов закрывает самостоятельный контур безопасности (сеть, DevSecOps-процессы, нагрузка, исходный код, функции ролевого доступа); отсутствие любого документа создает прямую угрозу безопасности образовательной среды. 37. На рынке Республики Казахстан представлены тиражные образовательные платформы и цифровые экосистемы (включая BilimLand, Daryn Online и их сертифицированные аналоги), успешно прошедшие испытания в лабораториях системы NCA РК. 38. Перечень из не менее 18 логических модулей определяет функциональную полноту образовательной платформы, гарантируя покрытие утвержденной учебной программы и компонентную изоляцию сервисов. 39. Соответствие модульной структуры проверяется в ходе приемочных испытаний функциональным тестированием сервисов и верификацией эксплуатационной документации («Руководства системного администратора»). 40. Механизм reverse proxy обусловлен регламентами ИБ: терминация TLS-соединений, балансировка нагрузки и защита сети лицея от атак типа «отказ в обслуживании» (DoS/DDoS). 41. Допускаются эквивалентные технологии (API Gateway, managed load balancer, ingress controller), обеспечивающие выполнение указанных защитных функций. 42. Использование cloud-native решений и микросервисной контейнеризации допускается при соблюдении требований безопасности и локального развертывания. 43. Показатель 1000 активных сетевых соединений (WebSocket/HTTP) определяет архитектурную емкость программного ядра при проведении синхронных общелицейских срезов знаний, олимпиад и параллельных уроков. 44. Контингент специализированного лицея составляет сотни учащихся, распределенных по параллелям классов и сменам. 45. Платформа рассчитана на одновременное подключение классов, мобильных устройств учащихся при соревновательных викторинах и измерительных модулей. 46. В технической спецификации противоречие отсутствует. Серверные аппаратные ресурсы (не менее 8 ядер, 16 ГБ ОЗУ) указаны как локальный минимум вычислительных мощностей аудитории для стабильной работы одного класса (до 100 пользователей), тогда как показатель 1000 соединений определяет емкость ядра ПО. 47. Оба показателя согласованы и обязательны: 100 пользователей определяют расчет аппаратного сервера класса, а 1000 соединений — сетевую емкость ядра веб-софта. 48. Отсутствие ограничений по числу учетных записей внутри организации образования («campus license») гарантирует равный доступ всему контингенту учащихся и педагогов без скрытых доплат. 49. Да, Заказчику передаются неисключительные права на использование ПО на весь срок действия авторских прав (бессрочно). 50. Обновления безопасности и устранение дефектов предоставляются на протяжении гарантийного срока (не менее 12 месяцев); базовая версия софта функционирует бессрочно. 51. После истечения 12 месяцев регламентной гарантии SLA сопровождение осуществляется штатной ИТ-службой лицея либо в рамках отдельного договора на техническую поддержку. 52. Расходы на содержание локальной ИТ-инфраструктуры несет организация образования в рамках утвержденной сметы расходов. 53. Программная платформа разворачивается в локальной вычислительной инфраструктуре лицея в соответствии с Руководством системного администратора. 54. Локальное функционирование осуществляется по внутренней сетевой адресации; доверенные сертификаты безопасности генерируются встроенными средствами платформы. 55. Резервные копии изолируются на дисковом массиве школьной вычислительной инфраструктуры; закупка отдельного внешнего массива не требуется. 56. Параметр RTO часов регламентирует нормативное время полного восстановления сервисов платформы из резервной копии при критическом аппаратном сбое. 57. Параметр RPO часов гарантирует, что максимальный объем возможных потерянных данных при аварии ограничен глубиной суточного бэкапа. 58. Правило «не более трех логических переходов» («правило трех кликов») является международным стандартом эргономики пользовательских интерфейсов (ISO 9241-110, UI/UX), гарантирующим оперативный доступ учителя к материалам урока. 59. Проверяется приемочной комиссией выполнением базовых действий (запуск урока, открытие 3D-модели, запуск викторины) по инструкции пользователя. 60. Размер интерактивного элемента не менее 44х44 пикселя научно обоснован международными стандартами мобильной доступности (W3C WCAG 2.1), предотвращая ошибочные нажатия пальцами на экранах мобильных устройств. 61. Палитра TrueColor (16 миллионов оттенков по HEX-коду) является базовым отраслевым стандартом HTML5 Canvas, необходимым для точного цветового кодирования схем и графиков. 62. Набор из 10 инструментов рисования обеспечивает полноценную замену классической классной доски при работе у экрана. 63. Наличие не менее 10 точек взаимодействия обеспечивает возможность детального изучения составных анатомических и технических объектов. 64. Вместимость не менее 500 символов определяет максимальный объем контейнера информационной карточки, гарантируя отображение развернутого академического описания без обрезки текста. 65. Три базовых ракурса (спереди, сбоку, в разрезе) позволяют преподавателю мгновенно переключать внимание класса на ключевые проекции изучаемого объекта в один клик. 66. Ограничение продолжительности учебных видеофрагментов (от 5 до 15 минут) установлено в строгом соответствии с Санитарными правилами «Санитарно-эпидемиологические требования к объектам образования» Республики Казахстан, регламентирующими непрерывную длительность применения технических средств обучения (ТСО) на уроке. 67. Нет, непрерывная демонстрация часового видеоматериала на школьном уроке прямо нарушает санитарно-гигиенические нормы охраны зрения учащихся и структуру урока. 68. Протокол WebSocket (RFC 6455) обеспечивает постоянное полнодуплексное двустороннее соединение реального времени и прямо поддерживается всеми современными браузерами нативно, позволяя транслировать данные датчиков без установки сторонних проприетарных драйверов. 69. Формат JSON (RFC 8259) является открытым текстовым стандартом, штатно десериализуемым JavaScript любого браузера без применения сторонних бинарных библиотек. 70. Протокол MQTT требует установки и администрирования промежуточного брокера сообщений, что нарушает концепцию автономного готового комплекса «из коробки». 71. Протокол gRPC ориентирован на межсервисное бинарное взаимодействие и требует специализированных клиентских компиляторов, создавая риски несовместимости с браузерами моноблоков. 72. Ежесекундная отправка формирует базовый шаг временного ряда (Time-series) для построения детальных графиков в лабораторных журналах учащихся. 73. Плавающий адаптивный шаг затрудняет синхронное сопоставление показаний различных датчиков на одном временном графике. 74. Емкость не менее 1000 мА·ч установлена исходя из естественной деградации литиевых аккумуляторов при циклической многолетней эксплуатации, гарантируя сохранение суточной работы на протяжении всего срока службы техники. 75. Обязательными являются оба показателя: время автономной работы гарантирует проведение серии уроков, а емкость аккумулятора — долговечность батарейного блока при многолетней эксплуатации. 76. Ограничение зарядного тока до 1 А продиктовано требованиями пожарной и электробезопасности детских учреждений, предотвращая перегрев батарей при одновременной зарядке 15 модулей в учебном кабинете. 77. Темная цветовая схема (Dark Theme) научно обоснована эргономикой: она снижает зрительное утомление и обеспечивает высокую контрастность графиков при демонстрации результатов эксперимента с расстояния нескольких метров. 78. Светлая тема на больших экранах создает повышенную световую нагрузку на зрение учащихся в условиях длительного наблюдения за графиками. 79. Наименование "Sensor Hub" приведено в технической спецификации в качестве примера («мысалы, "Sensor Hub"») текстового обозначения системы в интерфейсе. 80. Пиктограмма микрочипа является элементом визуальной идентификации центрального аппаратного узла в шапке веб-интерфейса для быстрой ориентации учащихся. 81. Скругленные углы карточек являются стандартным правилом современной эргономики графического интерфейса, обеспечивающим комфортное визуальное разделение виджетов. 82. Контрастная индикация статуса «НЕАКТИВЕН» строго на красном фоне обеспечивает мгновенную визуальную диагностику сбоя датчика учителем и исключает отображение «зависших» устаревших данных под видом актуальных измерений. 83. Сетка (Grid-layout) из 15 карточек обеспечивает одновременное наглядное отображение всех 15 каналов без необходимости вертикальной прокрутки экрана во время фронтального урока. 84. Табличное представление не обеспечивает достаточной наглядности и читаемости динамических графиков с расстояния нескольких метров. 85. Емкость Центра управления не менее 64 умных устройств заложена Заказчиком в целях перспективного масштабирования системы безопасности аудитории (плановое поэтапное оснащение индивидуальными блоками безопасности и сенсорами каждого лабораторного стола учащихся) без необходимости повторного расходования бюджетных средств на замену базовой станции. 86. Емкость в 16 устройств недостаточна для перспективного охвата всех ученических столов и розеточных групп специализированного лабораторного кабинета. 87. Планируется поэтапное подключение индивидуальных модулей безопасности рабочих мест учащихся (до 30–40 устройств). 88. Диапазон действия инфракрасной подсветки от 5 до 15 метров научно и геометрически обоснован размерами учебного помещения (длина типового класса лицея составляет 8–12 метров). Применение ИК-подсветки свыше 15 метров в замкнутом пространстве кабинета создает паразитную засветку и переотражение светового потока от стен и мебели, что ухудшает контрастность и детализацию ночной видеофиксации. 89. Да, превышение верхнего порога (свыше 15 метров) в замкнутом пространстве класса влечет оптическую засветку матрицы и деградацию качества ночной видеозаписи. 90. Диапазон объема поддерживаемых карт памяти от 64 до 256 ГБ является оптимальным техническим стандартом для стабильного функционирования файловых систем FAT32 и exFAT на микроконтроллере устройства при циклической перезаписи видеоархива событий глубиной до 30 дней. 91. Поддержка карт памяти объемом свыше 256 ГБ не является основанием для отклонения, если устройство штатно и стабильно поддерживает требуемый базовый диапазон от 64 до 256 ГБ включительно. 92. Слот формата microSD является общепринятым стандартом сменных носителей, обеспечивающим удобство извлечения архива при регламентном обслуживании. 93. Встроенная память eMMC используется для системных файлов; сменный слот необходим для циклического хранения архива видеозаписей. 94. Сценарии автоматизации по погодным условиям позволяют автоматически оптимизировать дежурные режимы освещения кабинета и вентиляции в зависимости от естественных климатических условий. 95. Погодные алгоритмы предотвращают перегрузку электрической сети и избыточный расход энергии в дежурных режимах работы кабинета. 96. Сценарии «восход/закат» являются базовыми алгоритмами энергосбережения современных контроллеров, исключающими человеческий фактор оставления включенных силовых приборов и освещения на ночь. 97. Алгоритмы автоматизации являются штатными встроенными функциями контроллеров систем безопасности и сохраняются в спецификации. 98. Коммутационная способность розетки 16 А (мощность не менее 3,5 кВт) необходима для безопасного подключения группы электрооборудования кабинета и зарядной базы лабораторных датчиков с высокими пусковыми токами. 99. Подключается суммарная силовая нагрузка лабораторного оборудования, лазерных печатно-сканирующих устройств и зарядной базы измерительных датчиков. Время отклика не более 2 секунд характеризует быстродействие встроенного микроконтроллера при нормальном сетевом подключении и критически важно при необходимости экстренного дистанционного ручного обесточивания линии преподавателем. Параметр проверяется в нормальных условиях функционирования сети; кратковременные задержки публичного интернета не влияют на заводские характеристики контроллера прибора. Быстродействие защиты от перегрузки не более 1 секунды обусловлено нормативными требованиями Правил устройства электроустановок Республики Казахстан (ПУЭ РК), предотвращая нагрев проводки и термическое повреждение сети школы. Параметр регламентирован Правилами устройства электроустановок РК (ПУЭ РК) и подтверждается официальным техническим паспортом изделия завода-изготовителя. Ресурс не менее 100 000 циклов срабатывания является общепринятым отраслевым стандартом надежности профессиональной электроустановочной арматуры, подтверждаемым техническим паспортом производителя или сертификатом. Параметр подтверждается официальным техническим паспортом изделия, эксплуатационной документацией завода-изготовителя либо сертификатом соответствия. Поддержка двухфакторной аутентификации (2FA) для учетных записей администраторов обязательна для превентивной защиты силового электропитания школьного кабинета от несанкционированного перехвата управления третьими лицами. Учетные записи без многофакторной защиты подвержены рискам несанкционированного доступа и не обеспечивают требуемого уровня безопасности государственных объектов образования. Применение шифрования не ниже AES-128 соответствует государственным стандартам защиты беспроводных сетей телеметрии. Использование защищенных криптографических протоколов TLS 1.3 с алгоритмами шифрования AES-128 или AES-256 полностью допускается. Формулировка «членам семьи или коллегам» приведена в технической спецификации в качестве описания функциональной возможности группового ролевого доступа. В условиях школы роли распределяются в рамках структуры организации образования: «Администратор» и «Пользователь». Наличие авторизованного или собственного сервисного центра (договорных отношений с сервисом) на территории Республики Казахстан на протяжении заявленного срока службы гарантирует ремонтопригодность поставляемого силового оборудования, доступность оригинальных запасных частей и выполнение обязательств по технической поддержке после ввода в эксплуатацию, защищая государственное учреждение от поставки неремонтопригодных приборов «одноразового» использования. Заявленный срок службы устанавливается официальным техническим паспортом завода-изготовителя (как правило, не менее 3–5 лет для микроэлектроники). В гарантийный период агрегатная замена допускается, однако наличие сервисной инфраструктуры в РК необходимо для обеспечения долгосрочной ремонтопригодности оборудования. Техническая спецификация сформирована в строгом соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках» и Правилами осуществления государственных закупок исходя из объективных потребностей специализированного лицея. Характеристики закупаемого комплекса базируются на открытых отраслевых, национальных и международных стандартах, не содержат указаний на товарные знаки или конкретных изготовителей и позволяют предложить сертифицированную продукцию различных брендов, представленных на рынке Республики Казахстан. За исключением исключенных требований к дате выдачи и реквизитам авторизационных писем (п. 5, согласно предписанию ДВГА), оснований для изменения параметров технической спецификации не имеется.
