Мы считаем, что систему уличного освещения на солнечных батареях с использованием ИИ и IoT проще оценить, если разделить ее функции на уровни. В наших материалах по продукту мы описываем датчик, способный отслеживать транспортный поток и погодные условия, контроллер MPPT с ИИ и IoT, имеющий функции управления с ПК/приложением, управления освещением и дистанционного управления, а также веб- или мобильное приложение для управления состоянием и командами. Мы также описываем масштабируемую интеграцию с камерами видеонаблюдения, системами раннего предупреждения и метеорологическим оборудованием. Эти утверждения определяют полезные архитектурные границы, но они не доказывают конкретный протокол связи, поставщика облачных услуг, API, модель камеры или схему разрешений.

В этой статье мы объясняем, как эти компоненты взаимодействуют друг с другом. Информацию о концепции и соответствии проекту см. в соответствующем разделе. Что такое солнечные уличные фонари с использованием ИИ и IoT? Объяснение технологий, функций и преимуществ.Для проведения тендера или фактического внедрения мы рекомендуем подтвердить соответствие каждой функции выбранной модели и проектной документации.

Какова роль каждого компонента в системе уличного освещения на солнечных батареях с использованием искусственного интеллекта и Интернета вещей?

Датчики обеспечивают ввод данных.

В нашем HC-CZSL-39 В описании продукта мы указываем, что датчик отслеживает транспортный поток и погодные условия, а также поддерживает автоматическую регулировку яркости и цветовой температуры. На архитектурном уровне мы рассматриваем датчик как входной слой. Он отслеживает условия, которые могут повлиять на решение об освещении. В наших записях не указана универсальная модель датчика, точность измерений, место установки, интервал выборки или алгоритм. Поэтому мы оставляем эти детали в качестве вопросов проекта.

Контроллер выполняет локальные работы по освещению.

В описании нашего продукта указан контроллер AI IoT MPPT с функциями управления с ПК/приложения, управления освещением и дистанционного управления. MPPT относится к солнечной зарядке и управлению энергией; управление освещением и дистанционное управление относятся к эксплуатации. Мы размещаем контроллер рядом с точкой освещения в высокоуровневой архитектуре, где он связывает оборудование для управления энергией и освещением с рабочим процессом управления. Мы не делаем выводов о протоколе, микросхеме, беспроводном стандарте или конструкции контура управления из слов «AI IoT».

Платформа управления предоставляет доступ к состоянию и командам.

В разделе часто задаваемых вопросов мы указываем, что веб-платформа или мобильное приложение позволяют регулировать яркость, цветовую температуру, состояние включения/выключения и работу стеклоочистителей, а веб-браузеры и мобильные приложения поддерживают визуализацию данных. В рабочем процессе проекта наш платформенный уровень — это место, где авторизованный оператор может просматривать состояние, отправлять команды и реагировать на оповещения. Точные экраны, роли пользователей, правила хранения данных и сетевые зависимости еще требуют подтверждения.

Камеры и другие устройства являются объектами интеграции.

В наших сравнительных материалах описывается масштабируемая интеграция с камерами видеонаблюдения, системами раннего оповещения, метеорологическим оборудованием и другими требованиями. Мы используем это в качестве направления проектирования. Это не то же самое, что сказать, что камера встроена в каждый солнечный уличный фонарь или что каждая модель включает в себя готовый интерфейс для камеры. Мы рассматриваем внешние устройства как отдельный поток работ по интеграции со своими собственными требованиями к питанию, креплению, пропускной способности, передаче данных, конфиденциальности и приемке.

Как компоненты обмениваются информацией?

Наша самая безопасная высокоуровневая модель:

обнаружение → локальное управление → видимость состояния → удаленное управление → реагирование на месте

1. Наш датчик отслеживает такие условия, как интенсивность движения транспорта или погодные условия.
2. Наш контроллер применяет логику управления освещением и энергопотреблением непосредственно на столбе или светильнике.
3. Информация об операционной деятельности становится доступной через настроенный нами уровень управления.
4. Авторизованный оператор может отправить поддерживаемую команду, например, команду на регулировку или команду включения/выключения.
5. Мы проверяем результат локально и регистрируем событие для последующего обслуживания или приемки.

Эта модель помогает нам и нашим покупателям задавать правильные вопросы, не изобретая сложную техническую инфраструктуру. Какие показания собираются? Какие решения принимаются локально? Какие команды разрешены удаленно? Что произойдет, если связь прервется? Записывается ли команда в журнал? Кто может ее изменить? Какое внешнее устройство получает данные? Эти вопросы гораздо полезнее, чем предположение, что «облачная платформа» означает одну стандартную архитектуру.

Какие функции должны выполняться в точке освещения, а какие — на платформе?

Мы используем это разделение, чтобы предотвратить две распространенные ошибки. Во-первых, функциональность платформы не следует представлять как доказательство того, что каждый столб оснащен одинаковым оборудованием. Во-вторых, характеристики оборудования не следует представлять как доказательство того, что проект имеет удаленный доступ, покрытие сети или разрешение на его использование.

Что должна проверить проектная группа, прежде чем принять эту архитектуру?

Мы рекомендуем использовать контрольный список архитектуры, специфичный для данной модели.

Проверьте точное оборудование.

Мы подтверждаем номер модели, тип контроллера, расположение панели и батареи, способ установки, высоту монтажа, площадь освещения и ограничения по условиям окружающей среды. Например, в нашей документации на HC-CZSL-39-100W указаны установка на столб или стену, высота монтажа 4–6 м, внешний аккумуляторный блок LiFePO4 и диапазон цветовой температуры 3000K–6000K с регулировкой с помощью искусственного интеллекта. Эти значения относятся только к данной документации на продукт.

Проверьте требования к датчикам.

Мы определяем, необходимы ли для проекта данные о дорожном движении, погоде, уровне освещенности, занятости или другие параметры. Мы выясняем, где установлен датчик, какие условия он может обнаруживать, как принимается решение и что происходит, когда показания недоступны. Мы не превращаем общее описание «датчика» в техническое задание без подтверждающих доказательств.

Проверьте путь управления и сетевой путь.

Мы документируем локальные элементы управления, удаленные элементы управления, поддерживаемые команды, метод подключения, зону покрытия, работу в автономном режиме, процесс обновления прошивки и ведение журнала команд. Мы также подтверждаем, включены ли в выбранную конфигурацию доступ через веб-браузер и мобильное приложение, и какие роли пользователей могут изменять настройки.

Внешние устройства проверяйте отдельно.

Для камер, теле- и радиоаппаратуры или метеорологических приборов мы подтверждаем энергетический бюджет, крепление, интерфейс, пропускную способность, права собственности на данные, требования к конфиденциальности, хранение данных и приемочные испытания. Наши материалы позволяют рассматривать эти требования как масштабируемые требования к интеграции; они не отменяют необходимости проверки интерфейса для конкретного проекта.

Проверьте порядок выполнения работ по техническому обслуживанию.

В описании нашего продукта упоминаются проверка состояния в реальном времени, GPS-позиционирование, удаленное обновление прошивки, круглосуточный мониторинг системы и уникальная идентификация ламп. Мы подтвердим, какие из этих функций включены, через форму обратной связи. Сервис удаленного мониторинга и интеллектуального управления на основе ИИ и Интернета вещейКакие границы обслуживания применяются и как оповещение становится действием на поле. Панель мониторинга без владельца, правила эскалации и записи о закрытии не является полноценным процессом обслуживания.

В каких случаях для обоснования претензий в сфере архитектуры требуются доказательства, относящиеся к конкретному продукту?

Мы используем три уровня доказательности:

6. Подтверждено в записи о конкретном продукте:контроллер, батарея, крепление, зона освещения или указанная функция управления, специфичные для данной модели.
7. Подтверждено в материалах системы заказчика, но зависит от условий:Управление через веб-приложение/приложение, оповещения, определение местоположения или функции удаленного управления встроенным программным обеспечением.
8. Направление интеграции проекта:камеры, системы вещания, метеорологическое оборудование, API, сеть, разрешения и управление данными.

Первые два уровня мы указываем в виде описаний возможностей заказчика только тогда, когда точный объем работ остается понятным. Третий уровень мы указываем как требование для проверки. Это различие особенно важно для Солнечные уличные фонари с креплением на столб.Опора, светильник, контроллер, датчик, сеть и внешнее устройство могут поставляться или настраиваться различными рабочими группами.

Передача проекта от архитектурного проектирования к реализации.

Перед утверждением мы подготавливаем одностраничный пакет документов, содержащий номер модели, список компонентов, схему управления, предположения о сети, список внешних устройств, роли пользователей, алгоритм оповещений, результаты пусконаладочных испытаний и подтверждение приемки. Мы помечаем каждую строку как подтвержденную, сконфигурированную или подлежащую проверке. Эта простая метка статуса предотвращает превращение концептуальной схемы в случайное обещание качества продукта.

При планировании проекта по внедрению подключенной системы солнечного освещения, пожалуйста, сообщите нашей команде информацию об условиях на объекте, потребностях в датчиках и камерах, алгоритме мониторинга, способе подключения, варианте монтажа и ограничениях интеграции. Обзор глобальной системы искусственного интеллекта и Интернета вещей Werise или Страница контактов WeriseМы считаем, что надежная архитектура — это не та, в которой больше всего блоков; это та, в которой каждый блок имеет проверенную роль, ответственного владельца и четкую передачу на следующий этап.