Síntese executiva
A expansão dos sistemas de armazenamento de energia em baterias no Brasil desloca o principal desafio dos projetos de BESS da simples aquisição de equipamentos conformes para a capacidade de demonstrar, de forma verificável, como o sistema se comportará diante de falhas, perturbações e condições operacionais adversas. O ponto central é que conformidade normativa e segurança demonstrável não são equivalentes: certificados comprovam atendimento a requisitos específicos, mas não necessariamente evidenciam que a arquitetura integrada manterá o ativo dentro de limites conhecidos quando sensores, comunicação, refrigeração, células ou funções de controle falharem. Essa distinção ganha relevância no novo ambiente brasileiro, no qual sistemas de armazenamento passam a operar sob requisitos de conexão, formação de rede, fiscalização, penalidades e potencial empilhamento de serviços. Nesse contexto, a arquitetura de controle deixa de ser um subsistema de automação e passa a influenciar diretamente segurança, disponibilidade, risco regulatório, segurabilidade e capacidade de monetização do ativo.
Abstract
Brazil’s emerging battery energy storage system (BESS) market introduces a challenge that extends beyond equipment certification and regulatory compliance: the ability to demonstrate that an integrated system will remain within known operational and safety limits under faults, disturbances, and degraded conditions. This Technical Note argues that such demonstrability is fundamentally a property of the control architecture. Functions should be allocated according to the time constants of the physical phenomena they govern, while the operational envelope must be continuously derived from the asset’s actual physical state. Economic optimization may remain remote, but safety-critical actuation authority should reside in a deterministic and verifiable layer capable of constraining commands from local algorithms, artificial intelligence models, or external platforms. The proposed architecture separates Instrumentation, Perception, Decision, and Safety Shielding, enabling advanced models to evolve without transferring ultimate control authority to probabilistic components. For asset owners, investors, integrators, insurers, and lenders, this approach shifts technical due diligence from compliance checklists toward evidence of system behavior, traceability, worst-case execution performance, autonomy, interoperability, and validation under abnormal conditions. As Brazil moves toward large-scale, multi-service BESS deployment, control architecture therefore becomes not only a functional design choice, but a relevant determinant of safety demonstrability, operational flexibility, regulatory exposure, and asset bankability.
Contexto
O marco regulatório brasileiro de 2026 cria condições para uma expansão relevante do armazenamento em baterias e, simultaneamente, eleva o nível de responsabilidade operacional desses ativos. Conforme o artigo analisado, as Resoluções Normativas ANEEL nº 1.161 e nº 1.162 estabelecem requisitos de outorga, faturamento, fiscalização e penalidades, enquanto as exigências técnicas de conexão trazem funções dinâmicas que precisam ocorrer localmente e em escalas de tempo incompatíveis com dependência exclusiva de centros remotos.
O efeito prático é uma mudança na natureza da decisão de engenharia. Não basta perguntar se o equipamento possui determinado certificado ou atende individualmente a uma norma. É necessário avaliar como instrumentação, BMS, PCS, controladores, algoritmos, sistemas de proteção e plataformas remotas se combinam e, principalmente, onde reside a autoridade final para comandar o ativo.
A experiência internacional apresentada no artigo reforça essa necessidade. Os casos analisados mostram situações em que capacidades de proteção existiam, mas estavam indisponíveis em determinado modo operacional; sistemas de segurança atuaram de maneira contraproducente; precursores evoluíram durante períodos suficientemente longos para permitir intervenção; e respostas locais rápidas foram determinantes para o comportamento do sistema elétrico. A conclusão não é que determinado fabricante ou tecnologia seja inseguro, mas que segurança depende do comportamento do sistema integrado e das condições sob as quais suas funções permanecem efetivamente disponíveis.
Tese técnica
A decisão de projeto mais relevante para sistemas BESS não é escolher entre inteligência local e inteligência em nuvem. É estabelecer uma arquitetura em que cada função seja posicionada de acordo com a constante de tempo do fenômeno que precisa controlar e com o nível de garantia exigido para sua atuação.
Funções associadas à proteção de células, resposta dinâmica do conversor, formação de rede, contingências e outras malhas rápidas precisam permanecer próximas ao processo físico. Atividades como otimização econômica, análise de frota e requalificação de modelos podem utilizar infraestrutura remota porque operam em horizontes de tempo maiores. Entre essas duas extremidades está uma função crítica: a construção contínua do envelope operacional do ativo, isto é, o conjunto de limites dentro dos quais qualquer comando econômico ou operacional pode ser executado com segurança.
Esse envelope não é estático. Ele depende do estado real das células e módulos, de temperatura, desequilíbrio, condição de saúde, capacidade instantânea, restrições do ponto de conexão, estado dos sistemas auxiliares e eventuais precursores de falha. Por essa razão, parte relevante dessa inteligência precisa ser produzida localmente.
O problema da autoridade de controle
A utilização de algoritmos de inteligência artificial ou modelos aprendidos não constitui, por si só, o principal risco. O risco arquitetural surge quando componentes probabilísticos passam a deter autoridade direta sobre funções cuja segurança precisa ser demonstrável.
A arquitetura proposta no artigo estabelece uma assimetria deliberada: modelos de IA, plataformas de otimização e controladores avançados podem propor ações, enquanto uma camada determinística e verificável deve decidir se essas ações podem efetivamente chegar aos atuadores. O princípio é simples: a inteligência opera dentro do envelope seguro; ela não possui autoridade para redefini-lo durante a execução.
Essa separação também reduz o acoplamento entre inovação e certificação. Modelos de previsão, estimação ou otimização podem evoluir ao longo da vida do projeto sem que cada mudança altere necessariamente a lógica fundamental de segurança do sistema, desde que a camada responsável pela imposição das restrições permaneça segregada e verificável.
Arquitetura de referência
O artigo organiza essa arquitetura em quatro camadas funcionais, representadas também no diagrama da página 10: Instrumentação, Percepção, Decisão e Blindagem. A figura explicita que propostas de controle percorrem as camadas superiores, enquanto a autoridade de escrita sobre os atuadores permanece concentrada na Blindagem. A governança de modelos ocorre externamente à planta, utilizando telemetria seletiva e processos periódicos de requalificação.
A Instrumentação fornece observabilidade em nível compatível com os riscos que se pretende controlar. A Percepção transforma medições em estimativas de estado, saúde, desequilíbrio e precursores. A Decisão compõe o envelope operacional e compatibiliza objetivos concorrentes. A Blindagem verifica de forma determinística cada ação antes de autorizá-la.
Essa organização também estabelece uma divisão mais clara entre a plataforma de mercado e a engenharia do ativo. A otimização econômica pode permanecer remota, enquanto o controlador local informa, continuamente, quais regiões de operação permanecem admissíveis. Assim, o sistema econômico solicita desempenho; a arquitetura física determina se esse desempenho é possível naquele instante.
Implicações para investidores, integradores e proprietários de ativos
A principal consequência é que a especificação técnica de um BESS precisa avaliar evidências de comportamento, e não apenas listas de conformidade.
Um projeto pode utilizar equipamentos reconhecidos, apresentar certificados aplicáveis e ainda assim conservar lacunas relevantes em integração, modos operacionais, autoridade de controle ou resposta a falhas. O caso de licenciamento apresentado na abertura do artigo ilustra precisamente essa diferença: a questão colocada pela autoridade não foi apenas o atendimento às orientações existentes, mas a robustez das evidências de que os controles propostos seriam eficazes.
Para investidores e financiadores, isso amplia o conceito de due diligence técnica. Para seguradoras, aumenta a importância da demonstração de barreiras e da rastreabilidade operacional. Para proprietários, significa que requisitos de controle, interoperabilidade e propriedade dos dados precisam ser contratados antes que a arquitetura fique condicionada às escolhas do fornecedor.
Há ainda uma implicação econômica importante. O artigo cita a experiência brasileira de um sistema de 30 MW/60 MWh no qual estudos sobre aplicações adicionais identificaram a necessidade de alterações em proteção e algoritmos de controle para viabilizar determinados serviços. O ponto é estratégico: em um ativo já instalado, potência e energia disponíveis não garantem capacidade de empilhamento de receitas. A flexibilidade comercial depende também da flexibilidade da arquitetura de controle.
Recomendações para especificação e contratação
Para novos projetos, a especificação técnica deve migrar de uma abordagem centrada exclusivamente em produto para uma abordagem centrada no argumento de segurança do sistema. Isso requer, entre outros elementos, separação explícita entre funções baseadas em aprendizado e funções determinísticas; demonstração do tempo de execução no pior caso para malhas críticas; declaração da taxa de falsos negativos e do comportamento diante de falha de sensores; evidência de ensaios de contenção no nível efetivamente relevante; impossibilidade de desabilitação inadvertida das funções essenciais de segurança; rastreabilidade das ações bloqueadas e das restrições ativas; operação segura sem conectividade externa; e interfaces que preservem interoperabilidade e acesso aos dados operacionais. Esses elementos são diretamente derivados dos critérios de especificação propostos no artigo.
A validação também deve ser tratada como parte da arquitetura, não como etapa final do comissionamento. O caminho indicado combina gêmeos digitais, ensaios hardware-in-the-loop e entrada gradual em operação, inicialmente com funções avançadas em modo supervisório. O objetivo não é apenas demonstrar que o controlador funciona em condições nominais, mas produzir evidências sobre seu comportamento quando as condições se afastam do cenário esperado.
conformidade-nao-e-seguranca-bess-arquitetura-controle.docx
Decisões prioritárias
Para empreendimentos em fase de desenvolvimento, contratação ou financiamento, quatro decisões merecem antecipação:
| Decisão | Questão executiva |
|---|---|
| Arquitetura de controle | Onde reside a autoridade final sobre os atuadores e quais funções podem alterá-la? |
| Envelope operacional | Como os limites operacionais são calculados e atualizados a partir do estado físico real do ativo? |
| Validação | Que evidências demonstram comportamento seguro sob falhas, contingências e condições extremas? |
| Contratação e dados | A arquitetura permite evolução de controladores, serviços e modelos sem dependência estrutural de um único fornecedor? |
Essas decisões precisam ser tomadas antes da consolidação das especificações de fornecimento. Posteriormente, sua alteração tende a envolver interfaces de BMS, PCS, proteção, supervisão e comunicação, transformando uma decisão inicialmente arquitetural em retrofit de maior complexidade.
Conclusão
O avanço do armazenamento em baterias no Brasil torna insuficiente uma estratégia baseada apenas em selecionar equipamentos certificados e integradores reconhecidos. Esses elementos permanecem necessários, mas o risco relevante migra para a integração: como o ativo percebe sua condição, como transforma essa condição em limites operacionais, quem pode comandá-lo e que evidência demonstra que essas regras continuarão válidas quando algo sair do comportamento nominal.
A arquitetura de controle passa, portanto, a ser parte do argumento de segurança e da própria tese econômica do investimento. Projetos capazes de separar otimização de mercado, inteligência embarcada e autoridade determinística terão melhores condições de demonstrar segurança, preservar flexibilidade operacional e sustentar novas aplicações durante a vida do ativo. O artigo também reconhece o limite dessa conclusão: a arquitetura integrada proposta ainda requer validação experimental como sistema, especialmente quanto ao comportamento computacional embarcado sob condições térmicas representativas do ambiente brasileiro.
