Consideramos mais fácil avaliar um sistema de iluminação pública solar com IA e IoT quando separamos suas funções em camadas. Em nossos materiais de produto, descrevemos um sensor capaz de detectar fluxo de tráfego e condições climáticas, um controlador MPPT com IA e IoT com funções de controle remoto, iluminação e via PC/aplicativo, além de gerenciamento via web ou aplicativo móvel para status e comandos. Também descrevemos a integração escalável com câmeras de segurança, sistemas de alerta precoce e equipamentos de monitoramento meteorológico. Essas afirmações definem limites úteis para a arquitetura, mas não comprovam um protocolo de comunicação específico, fornecedor de nuvem, API, modelo de câmera ou configuração de permissões.

Neste artigo, explicamos como esses componentes se encaixam. Para o conceito e a decisão de adequação ao projeto, consulte O que são postes de iluminação pública solares com IA e IoT? Tecnologias, funções e vantagens explicadas.Para uma licitação ou implementação real, recomendamos confirmar cada função em relação ao modelo selecionado e ao projeto.

Qual o papel de cada componente em um sistema de iluminação pública solar com IA e IoT?

Os sensores fornecem informações.

Em nosso HC-CZSL-39 Na descrição do produto, afirmamos que o sensor detecta o fluxo de tráfego e as condições climáticas, podendo auxiliar no ajuste automático de brilho e temperatura de cor. Em termos de arquitetura, consideramos o sensor como a camada de entrada. Ele observa uma condição que pode influenciar a decisão de iluminação. Nosso registro não identifica um modelo de sensor universal, precisão de medição, posição de instalação, intervalo de amostragem ou algoritmo. Portanto, reservamos esses detalhes como questões específicas do projeto.

O controlador executa trabalhos de iluminação local.

Nosso registro de produto lista um controlador MPPT de IA para IoT com funções de PC/aplicativo, controle de iluminação e controle remoto. MPPT refere-se ao carregamento solar e ao gerenciamento de energia; controle de iluminação e controle remoto referem-se à operação. Posicionamos o controlador próximo ao ponto de iluminação na arquitetura de alto nível, onde ele conecta o hardware de energia e iluminação ao fluxo de trabalho de gerenciamento. Não inferimos nenhum protocolo, chip, padrão sem fio ou projeto de circuito de controle a partir das palavras "IA para IoT".

A plataforma de gerenciamento expõe o status e os comandos.

Em nossas Perguntas Frequentes, afirmamos que uma plataforma Web ou de aplicativo pode ajustar o brilho, a temperatura da cor, o status ligado/desligado e os limpadores de para-brisa, e que as plataformas de navegador Web e aplicativos móveis oferecem suporte à visualização de dados. Em um fluxo de trabalho de projeto, nossa camada de plataforma é onde um operador autorizado pode revisar o status, enviar um comando e responder a um alerta. As telas exatas, as funções do usuário, as regras de retenção de dados e as dependências de rede ainda precisam ser confirmadas.

Câmeras e outros dispositivos são alvos de integração.

Nosso material de comparação descreve a integração escalável com câmeras de vigilância de segurança, sistemas de alerta precoce por transmissão, equipamentos de monitoramento meteorológico e outros requisitos. Usamos isso como uma diretriz de projeto. Não se trata do mesmo que afirmar que uma câmera já vem integrada em cada poste de iluminação solar ou que cada modelo inclui uma interface de câmera pronta para uso. Tratamos dispositivos externos como um fluxo de trabalho de integração separado, com seus próprios requisitos de energia, montagem, largura de banda, dados, privacidade e aceitação.

Como os componentes trocam informações?

Nosso modelo de alto nível mais seguro é:

Sensoriamento → controle local → visibilidade do status → comando remoto → resposta em campo

1. Nosso sensor observa condições como fluxo de tráfego ou clima.
2. Nosso controlador aplica a lógica de iluminação e energia disponível no poste ou luminária.
3. As informações operacionais tornam-se visíveis através da nossa camada de gerenciamento configurada.
4. Um operador autorizado pode enviar um comando compatível, como um ajuste ou uma instrução de ligar/desligar.
5. Verificamos o resultado localmente e registramos o evento para fins de manutenção ou aceitação.

Este modelo nos ajuda, assim como aos nossos compradores, a fazer as perguntas certas sem precisar inventar uma pilha tecnológica complexa. Quais dados são coletados? Quais decisões são tomadas localmente? Quais comandos são permitidos remotamente? O que acontece se a conectividade for interrompida? O comando é registrado? Quem pode alterá-lo? Qual dispositivo externo recebe os dados? Essas perguntas são mais úteis do que presumir que "plataforma em nuvem" significa uma arquitetura padrão.

Quais funções pertencem ao ponto de iluminação e quais pertencem à plataforma?

Usamos essa separação para evitar dois erros comuns. Primeiro, uma função da plataforma não deve ser apresentada como prova de que todos os postes têm o mesmo hardware. Segundo, uma característica do hardware não deve ser apresentada como prova de que um projeto tem acesso remoto, cobertura de rede ou permissão para usá-lo.

O que uma equipe de projeto deve verificar antes de adotar essa arquitetura?

Recomendamos o uso de uma lista de verificação de arquitetura específica para cada modelo.

Verifique o hardware exato.

Confirmamos o número do modelo, o tipo de controlador, a disposição do painel e da bateria, o método de instalação, a altura de montagem, a área de iluminação e os limites ambientais. Nosso registro do modelo HC-CZSL-39-100W, por exemplo, lista a montagem em poste ou parede, uma altura de montagem de 4 a 6 m, uma caixa de bateria externa LiFePO4 e uma faixa de temperatura de cor ajustável por IA de 3000K a 6000K. Esses valores pertencem somente ao registro desse produto.

Verificar os requisitos de detecção

Definimos se o projeto precisa de dados de tráfego, clima, luminosidade, ocupação ou outro tipo de entrada. Questionamos onde o sensor será instalado, quais condições ele pode detectar, como a decisão é tomada e o que acontece quando a leitura não está disponível. Não transformamos uma simples declaração sobre um "sensor" em uma especificação de desempenho sem evidências.

Verifique o caminho de controle e de rede.

Documentamos os controles locais, os controles remotos, os comandos suportados, o método de conectividade, a cobertura, o comportamento offline, o processo de atualização de firmware e o registro de comandos. Também confirmamos se o acesso via Web e aplicativo móvel está incluído na configuração selecionada e quais funções de usuário podem alterar as configurações.

Verifique os dispositivos externos separadamente.

Para câmeras, transmissões ou dispositivos meteorológicos, confirmamos o orçamento de energia, a montagem, a interface, a largura de banda, a propriedade dos dados, os requisitos de privacidade, o armazenamento e os testes de aceitação. Nossos materiais apoiam o tratamento desses itens como requisitos de integração escaláveis; eles não eliminam a necessidade de uma revisão de interface específica para cada projeto.

Verifique o fluxo de trabalho de manutenção.

A descrição do nosso produto refere-se a verificações de estado de funcionamento em tempo real, posicionamento GPS, atualizações remotas de firmware, supervisão do sistema 24 horas por dia, 7 dias por semana e identificação única das lâmpadas. Confirmamos quais destes recursos estão incluídos através do Serviço de monitoramento remoto e gerenciamento inteligente de IoT com IA, qual limite de serviço se aplica e como um alerta se torna uma ação de campo. Um painel sem um responsável, regra de escalonamento e registro de conclusão não representa um processo de manutenção completo.

Em que situações as alegações na área da arquitetura necessitam de evidências específicas do produto?

Utilizamos três níveis de evidência:

6. Confirmado em um registro de produto específico:Controlador específico do modelo, bateria, montagem, área de iluminação ou função de controle listada.
7. Confirmado no material do sistema do cliente, mas dependente das condições:Gerenciamento via web/aplicativo, alertas, posicionamento ou funções remotas de firmware.
8. Diretrizes para a integração de projetos:Câmeras, sistemas de transmissão, equipamentos meteorológicos, API, rede, permissões e governança de dados.

Escrevemos os dois primeiros níveis como declarações de capacidade do cliente somente quando o escopo exato permanece visível. Escrevemos o terceiro nível como um requisito a ser verificado. Essa distinção é especialmente importante para Postes de iluminação pública solares com montagem em posteO poste, a luminária, o controlador, o sensor, a rede e o dispositivo externo podem ser fornecidos ou configurados por diferentes fluxos de trabalho.

Transição da arquitetura para o projeto

Antes da aprovação, preparamos um pacote de evidências de uma página contendo o número do modelo, a lista de componentes, o diagrama de controle, as premissas da rede, a lista de dispositivos externos, as funções do usuário, o fluxo de alertas, o teste de comissionamento e as evidências de aceitação. Marcamos cada linha como confirmada, configurada ou a ser verificada. Essa simples etiqueta de status impede que um diagrama conceitual se torne uma promessa de produto acidental.

Ao planejar um projeto de iluminação solar conectada, compartilhe as condições do local, as necessidades de sensores e câmeras, o fluxo de trabalho de monitoramento, o método de conectividade, o arranjo de montagem e as restrições de integração com nossa equipe por meio do [inserir link aqui]. Visão geral do sistema global de IA e IoT da Werise ou o Página de contato da WeriseAcreditamos que uma arquitetura sólida não é aquela com mais módulos; é aquela em que cada módulo tem uma função comprovada, um responsável declarado e uma transição clara para a próxima etapa.