Arquitetura C4 do ADMS (Schneider EcoStruxure ADMS 3.8)¶
Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte primária: Anexo A-4 — Manual Técnico do EcoStruxure ADMS 3.8 (Schneider Electric), Capítulo 2 "Arquitetura" (pp. 32–58), Capítulo 5 "SCADA" (pp. 162–274), Capítulo 8 "Outage Management (OMS)" (pp. 340 e ss.), Capítulo 9 "Gestão de Equipes" (pp. 427–431), Capítulo 11 "Aplicações Avançadas de Distribuição/DMS" (pp. 441–570), Capítulo 12 "Utility DERMS" (pp. 570–608) + Capítulo 13 "Gestão de Microgrid" (pp. 608–619), Capítulo 14 "Aplicações Avançadas de (Sub)Transmissão/EMS" (pp. 619–671), Capítulo 17 "Operational Historian" (pp. 710–752) Status: Rascunho para validação técnica Elaborado por: Consultoria Syntropy
Nota metodológica¶
Este documento modela a arquitetura interna do produto EcoStruxure ADMS nos três primeiros níveis do modelo C4 (Contexto, Container, Componente), a partir da leitura estrutural do manual técnico do fabricante (Anexo A-4, 933 páginas) — não de uma sessão com o arquiteto da Energisa. Por isso, cada elemento dos diagramas é classificado em duas categorias, seguindo a mesma convenção de rigor já usada em catalogo-adapters-schneider-adms.md:
- Genérico do produto — descrito no manual como parte da arquitetura de referência do ADMS, independente de cliente. Não implica que a Energisa usa o componente exatamente como documentado, nem que o módulo esteja de fato ativo no ambiente Energisa.
- Confirmado na Energisa — cruzado com artefatos já validados em sessão neste assessment (
dominio-funcional-adms.md,blueprint-componentes-adms.md,catalogo-adapters-schneider-adms.md,integracao-wfm-adms.md,integracao-wfm-eforce-ordem-servico.md).
Dois níveis de profundidade de leitura convivem neste documento — importante não os tratar como equivalentes. Para o Capítulo 2 (arquitetura geral) e os Capítulos 8/9 (OMS + Gestão de Equipes), a leitura foi corpo a corpo, página por página, incluindo a Figura 8-1 (diagrama conceitual explícito de dependências entre unidades lógicas do OMS) — as relações (Rel(...)) do diagrama de Nível 3 do OMS reproduzem esse diagrama do fabricante. Para os cinco capítulos adicionados nesta rodada (SCADA, DMS, DERMS, Gestão de Microgrid, EMS, Operational Historian), a leitura foi o sumário detalhado de cada capítulo — que no próprio manual já é granular o suficiente para nomear cada sub-função com página exata — mais a página de abertura/visão geral de cada um. Nenhum desses cinco capítulos teve o corpo integral lido linha a linha, e nenhum deles trouxe um diagrama de dependências explícito equivalente à Fig. 8-1. Por isso, nesses cinco diagramas, a enumeração de componentes é confiável (vem do sumário estruturado do próprio fabricante), mas as setas de relação entre componentes são inferência da consultoria a partir da prosa de abertura de cada capítulo — não a reprodução de um diagrama do fabricante. Ver a nota "Leitura" ao final de cada seção para o grau de confiança específico.
Nível 1 — Contexto do Sistema¶
Baseado na Figura 2-1 do manual ("Alto Nível") e na Figura 8-1 (atores de negócio: Control Room, Call Center, Corporate Environment & Field personnel), com os sistemas externos genéricos do manual substituídos/complementados pelos sistemas reais já confirmados no landscape da Energisa.
Elementos do diagrama
Operador é quem trabalha na sala de controle, monitorando e operando a rede em tempo real através do DMD ou dos clientes web (manual, p. 33) — é o usuário para quem o Sistema Real-time (Core) existe.
Usuário Corporativo representa engenharia e planejamento, que usam o Web DMD e o Access Services System (DMZ) para simulação, análise e relatórios sobre o modelo de rede — histórico ou de cenários futuros — sem interferir na operação em tempo real (manual, p. 33).
Promotor de Modelo é quem importa, valida e publica alterações no modelo de rede através do Network Builder e do Staging System, um ambiente separado do Core justamente para testar mudanças antes de aplicá-las (manual, p. 33–34).
Atendente / CSR registra chamadas de falta de energia e gerencia retornos ao cliente através do Web Call Center — a porta de entrada do OMS para reclamações vindas do call center (manual, p. 340).
Equipe de Campo recebe e baixa serviços através do Field Client (Cliente Campo), o aplicativo móvel único para todo trabalho de campo, com modos online/offline (manual, p. 429).
ADMS é o próprio sistema modelado neste documento — a plataforma da Schneider Electric que unifica SCADA, DMS, OMS, EMS e DERMS num modelo de dados e GUI comuns, expondo integrações padronizadas por Adapter para os sistemas externos listados abaixo (manual, p. 32).
GIS (Smallworld) é o cadastro georreferenciado de ativos de rede da Energisa (postes, cabos, transformadores) — integração confirmada em sessão, unidirecional e assíncrona via GIS Adapter e SFTP em carga noturna.
WFM (SIGOD + eForce) despacha e executa trabalho de campo — hoje dois sistemas convivendo durante a migração: o legado SIGOD (client-server, carga full de equipes via SOAP/SFTP) e o eForce moderno (microsserviços .NET, despacho/baixa via Kafka e ApiOntMiddleware), ambos confirmados em sessão.
SGM (EAM) é o sistema de gestão de manutenção que gera notas de serviço consumidas pelo OMS — confirmado em sessão, integra via Kafka e Sensedia.
CRM-Service (SIATT/SIATE) é a origem de chamadas, ocorrências e callbacks de falta de energia registrados pelo atendimento — confirmado em sessão, integra via Kafka nos tópicos identificados como WSROT (crm_*).
ERP aparece na Fig. 2-1 do manual como um dos sistemas empresariais genéricos que o ADMS integra via ESB CIM/XML — nenhuma fonte da Energisa detalha até agora como (ou se) essa integração existe de fato no ambiente real.
CIS / Billing é o Customer Information System genérico do manual (Fig. 2-1); na Energisa corresponde plausivelmente a SICCO/SIFAR, mas sem detalhe de integração confirmado em nenhuma sessão até agora.
AMI / MDM representa a infraestrutura de medidores inteligentes — a integração com o ADMS está prevista no manual (Adapter AMI) mas não está implementada na Energisa; avaliação para fase 2, com risco reconhecido de falso positivo.
Dispositivos de Campo são os IEDs e remotas que trocam telemetria e comandos com o ADMS via FEP, usando os protocolos IEC 60870-5-104, DNP3 e ICCP (manual, p. 41) — a camada de aquisição SCADA, detalhada no Nível 3 de SCADA mais adiante.
Leitura: o manual (Fig. 2-1) descreve o ADMS como uma fronteira única que expõe integrações padronizadas por Adapter para um conjunto genérico de sistemas empresariais (ERP, CIS, AMI/MDM, GIS) via ESB CIM/XML — esse é o "contexto de produto". Na Energisa, três desses pontos de integração genéricos foram substituídos por sistemas reais e confirmados em sessão (GIS/Smallworld, WFM/SIGOD+eForce, SGM), e dois adicionais existem sem contrapartida direta na Fig. 2-1 (SGM e CRM-Service atendem funções — manutenção e atendimento — que o manual não nomeia como adapter dedicado na visão de alto nível, mas que aparecem detalhadas no catálogo de adapters ONT/OSR/SMR/SMN).
Nível 2 — Containers¶
Baseado nas Figuras 2-2 ("Arquitetura multicamada"), 2-3 ("relações de alto nível entre componentes e blocos funcionais") e 2-5 ("Hierarquia dos Componentes") do Capítulo 2, mais os grupos de serviço descritos em prosa nas páginas 41–45 (Application Services, Historical Services, Landbase Service).
Elementos do diagrama
DMD é o cliente desktop operacional completo — a interface principal do Operador para monitoramento e operação em tempo real, com um modo adicional de treinamento/simulação (manual, p. 35–36).
Network Builder é o editor desktop usado pelo Promotor de Modelo para criar, editar e excluir elementos de rede, conectividade e diagramas, além de gerenciar estudos de planejamento e a execução de aplicações de potência sobre esses estudos (manual, p. 36).
Web DMD é a versão leve e somente-leitura do DMD, voltada a usuários corporativos: mesmo visual do DMD, mostrando estado atual da rede, telemetria, coloração de topologia, resultados de fluxo de carga, ordens de serviço e gestão de equipes e incidentes (manual, p. 36–37).
Field Client (Cliente Campo) compartilha a mesma tecnologia do Web DMD, mas roda como app móvel para a Equipe de Campo, com modos online/offline e sincronização, além de reporte de status e posição GPS (manual, p. 37, 429).
Web Call Center ajuda operadores de call center a registrar chamadas de falta de energia relatadas por clientes, roteá-las ao OMS e gerenciar callbacks — é usado pelo Atendente/CSR (manual, p. 37).
Processador Front-End (FEP) é o serviço que coleta dados SCADA e emite comandos para os dispositivos de campo; suporta múltiplas instâncias para balanceamento de carga e abstrai o protocolo específico (IEC 104, DNP3, ICCP etc.), permitindo que o mesmo FEP converse com dispositivos de fabricantes e protocolos diferentes (manual, p. 41).
ADMS Platform Services agrupa os serviços de aplicação em memória que mantêm o estado corrente da rede: Network Model Service (elementos e configuração), Graphical Model Service (telas e representações visuais), Dynamics Data Service (valores de ponto, tags, alarmes, elementos temporários) e Model Topology Service (topologia calculada — energização, circuito de alimentação) (manual, p. 41–42).
Aplicações de Potência (DMS/EMS) compartilham o mesmo modelo de aplicação, rodando sobre a parte da rede marcada como distribuição (DMS) ou transmissão (EMS); podem ser aplicações principais, que executam automaticamente e alimentam o Core Functions Service, ou de solicitação-resposta, que só retornam resultado a quem pediu (manual, p. 42) — decompostas em detalhe nos diagramas de Nível 3 de DMS e EMS.
Motor de Cálculo é a plataforma comum que trata o disparo, agendamento, execução, transporte de resultado e tratamento de erro das Aplicações de Potência; os cálculos são particionáveis em múltiplos núcleos e preparados para paralelização em cluster HPC (manual, p. 42–43).
Interrupção e Gestão do Trabalho (Outage and Work Management) despacha todo o trabalho planejado e não-planejado da distribuição — interrupções, manobras, riscos, manutenção — e inclui a Gestão de Equipes; é o container mais diretamente ligado às integrações já mapeadas neste assessment (WFM, SGM, CRM), decomposto em detalhe no primeiro diagrama de Nível 3 (manual, p. 43).
Serviços de Apoio são componentes de infraestrutura de aplicação que dão suporte à execução e implantação dos demais serviços de aplicação, sem funcionalidade direta voltada ao usuário final (manual, p. 43).
Módulo de Séries Temporais coleta, arquiva e serve grandes volumes de dados de série temporal — telemetria, dados manuais e resultados de cálculo de aplicações DMS — usados tanto para relatórios quanto como insumo de outras aplicações (previsão de carga, por exemplo); decomposto do lado de apresentação/relatórios no diagrama de Nível 3 do Operational Historian (manual, p. 43–44).
Módulo de Log de Eventos é a trilha de auditoria de longo prazo: todos os alarmes e eventos do sistema, mais toda ação de usuário em qualquer cliente GUI (login/logout, reconhecimento de alarme, ações de controle, mudanças de configuração) (manual, p. 44).
Repositório do Modelo de Rede guarda o modelo de rede e todas as suas mudanças como changesets incrementais — normalmente vindos do módulo de importação do GIS ou do Network Builder — permitindo reconstruir qualquer versão passada do modelo ou preparar um estado futuro planejado (manual, p. 44).
Outros Repositórios agrupam dados históricos complementares: sequências de manobra, save cases (snapshots do estado de rede), alterações de elementos temporários e de tags, rede afetada por interrupção, resultados de VVO e modelo de carga (manual, p. 44).
OSISoft PI (opcional) é um historiador de terceiros que pode substituir ou complementar o Módulo de Séries Temporais nativo, conforme mostrado na Figura 2-2 do manual — sem evidência de uso confirmada na Energisa.
Serviço Landbase fornece dados raster e vetoriais de base territorial (imagens de fundo georreferenciadas) para as aplicações gráficas, além de busca avançada por endereço ou interseção mais próxima (manual, p. 45).
GIS, WFM (SIGOD/eForce), SGM e CRM-Service são os mesmos sistemas externos confirmados já descritos no Nível 1 — aqui aparecem apontando especificamente para os containers que consomem seus dados (Repositório do Modelo de Rede e Interrupção e Gestão do Trabalho), em vez do ADMS como caixa única.
ERP / CIS / AMI (genérico) agrupa, para simplificar o diagrama, os três sistemas empresariais genéricos do manual (Fig. 2-1) sem contrapartida de integração detalhada confirmada na Energisa — ver Nível 1 para o tratamento individual de cada um.
Leitura: os três blocos da Figura 2-2 (Presentation / Application / Database Layer) mapeiam diretamente para os três System_Boundary do diagrama. Dentro da camada de aplicação, os seis containers seguem a divisão do próprio manual (p. 41: "A funcionalidade do aplicativo EcoStruxure ADMS é dividida em partes disjuntivas implementadas por um conjunto de serviços de aplicativo. Cada serviço é executado em um processo separado"). O container Interrupção e Gestão do Trabalho é o único decomposto em Nível 3 neste documento — ver seção seguinte.
Não representado neste diagrama (para não sobrecarregar): a replicação entre Sistemas (Core/RealTime, Access Services-DMZ, Staging) descrita na Fig. 2-5 — cada um dos containers acima existe, na prática, como instância redundante em pelo menos dois desses sistemas, mais o site de backup/DR. Ver arquitetura-datacenters-redundancia.md para o tratamento de redundância/DR já existente neste assessment (produto genérico segundo o manual: par HOT/STANDBY por serviço, sem ponto único de falha, cluster Windows Server para HA de RDBMS — p. 45–46).
Nível 3 — Componentes: "Interrupção e Gestão do Trabalho" (Outage and Work Management)¶
Este é o container mais diretamente relevante às integrações já mapeadas no assessment (WFM, SGM, CRM-Service). Baseado na Figura 8-1 do manual ("Diagrama conceitual de alto nível" do OMS, p. 340) e no Capítulo 9 (Gestão de Equipes, p. 427–431).
Elementos do diagrama
Gerenciamento de Dados do Cliente armazena e expõe os dados individuais de cada cliente — nome, conta, endereço, contato — para os demais componentes do OMS que precisam deles; por lidar com dado pessoal, o manual destaca que geralmente está sujeito a auditoria e segurança de dados rigorosas (manual, p. 340).
Gerenciamento de Chamadas registra chamadas de problema e eventos de medidor inteligente, mantendo uma imagem em tempo real das chamadas ativas, e administra a configuração de tipos de chamada, motivos e resultados válidos; foi desenhado para lidar com grande volume de chamadas simultâneas (manual, p. 340).
Gerenciamento de Incidentes é o núcleo do OMS: browser e detalhamento de incidentes previstos e confirmados, criação manual, trabalho planejado, resoluções, operações de manobra associadas, ETR (tempo estimado de restabelecimento) e follow-up — a unidade que mais artefatos deste assessment (WFM, SGM, CRM) alimentam indiretamente (manual, Cap. 8, p. 349 e ss.).
Avaliação de Danos registra e classifica danos reportados em campo durante um incidente, alimentando o Gerenciamento de Incidentes com essa informação adicional (manual, Cap. 8, p. 377).
FLISR (Fault Location, Isolation and Supply Restoration) localiza a falta, isola a seção afetada e restaura o suprimento nas demais, podendo operar em modo automático ou manual, com perfis e opções globais configuráveis; é acionado pelo Gerenciamento de Incidentes e usa o motor de cálculo em tempo real do DMS (manual, Cap. 8, p. 379).
Large Area Restoration (LAR) trata da restauração quando uma falta afeta uma área grande demais para os mecanismos padrão do FLISR — o Gerenciamento de Incidentes escalona para este componente quando aplicável (manual, Cap. 8, p. 410).
Relatórios do OMS oferecem o browser histórico de interrupções, análise de confiabilidade (reliability analysis) e relatórios genéricos configuráveis, consultando a base histórica de operações (manual, Cap. 8, p. 414).
Gerenciamento de Manobra cuida das sequências de manobra e planos de chaveamento, colaborando tanto com o Gerenciamento de Incidentes (quando uma manobra é necessária para isolar/restaurar) quanto com a Gestão de Atribuição de Equipes (quem executa a manobra em campo) (manual, Cap. 7, p. 289).
Real-Time Model Topology Processing calcula o estado topológico e de energização da rede em tempo real a partir dos dados que o SCADA entrega — é o insumo que o Gerenciamento de Incidentes usa para saber o que está de fato desenergizado (manual, Fig. 8-1).
Gerenciamento de Dados de Equipe mantém o cadastro de equipes, membros e veículos em browsers tabulares — a base de dados que o eForce/WFM alimenta via cadastro de equipes (manual, Cap. 9, p. 427).
Gestão de Atribuição de Equipes decide qual equipe atende qual incidente ou manobra, colaborando diretamente com o Gerenciamento de Manobra e o Gerenciamento de Incidentes — é este componente que troca despacho e baixa de serviço com o eForce via ApiOntMiddleware (manual, Cap. 9, p. 427).
Despacho de Equipe é a janela onde a atribuição decidida é de fato enviada à equipe em campo (manual, Cap. 9, p. 429).
Cliente Campo (Field Client) é a mesma aplicação móvel já descrita no Nível 2, aqui no papel específico de receber o despacho e devolver status/baixa de serviço à Gestão de Atribuição de Equipes, com suporte a modos online e offline (manual, Cap. 9, p. 429).
DMS RT Calculation Engine, Network Model e SCADA são os três containers de Nível 2 (Motor de Cálculo, ADMS Platform Services e a camada SCADA) que este diagrama referencia como fronteira externa — FLISR usa o motor de cálculo, a topologia usa o modelo de rede, e o SCADA alimenta o estado da rede em tempo real.
CustomerDB e OperationsDB (Histórico) são as duas bases de dados nomeadas explicitamente na Figura 8-1 do manual — a primeira guarda os dados de cliente persistidos pelo Gerenciamento de Dados do Cliente, a segunda o histórico de operações consultado pelos Relatórios do OMS e alimentado pelo Gerenciamento de Incidentes.
CRM-Service, SGM e WFM (SIGOD/eForce) são os mesmos três sistemas externos confirmados do Nível 1, aqui apontando para os componentes internos específicos que efetivamente consomem seus dados — chamadas para o Gerenciamento de Chamadas, notas de serviço para o Gerenciamento de Incidentes, cadastro e despacho de equipe para os dois componentes de Gestão de Equipes.
Leitura: os nove componentes do corpo principal seguem literalmente a decomposição que o próprio manual propõe na Fig. 8-1 ("o Gerenciamento de interrupções pode ser dividido nas seguintes unidades lógicas", p. 340) mais as unidades detalhadas no restante do Capítulo 8 (Avaliação de Danos, FLISR, LAR, Relatórios). O sub-Container_Boundary de Gestão de Equipes replica a estrutura do Capítulo 9: duas funções internas (dados de equipe, atribuição) mais dois sub-componentes de interface (Despacho de Equipe, Cliente Campo).
As relações com crm, sgm e wfm já estão confirmadas em outros artefatos deste assessment — os componentes-alvo específicos (call_mgmt, incident_mgmt, crew_data/crew_assign) são inferência estrutural a partir do manual, cruzando o que cada adapter transporta (catálogo de adapters) com a unidade lógica do OMS que plausivelmente o consome; não foram confirmados nome-a-nome em sessão com o arquiteto da Energisa.
Nível 3 — Componentes: SCADA¶
Baseado no Capítulo 5 do manual (pp. 162–274) — sumário detalhado da seção + páginas de abertura (162–170, Aquisição de Dados/FEP). O manual organiza SCADA como capítulo próprio, mas arquiteturalmente (Cap. 2, p. 41–43) suas funções vivem dentro do "Serviço RealTime": aquisição via FEP, e processamento/tags/alarmes dentro do Dynamics Data Service (parte do container ADMS Platform Services no Nível 2) — por isso este container não tinha nome próprio no diagrama de Nível 2; o Container_Boundary abaixo é um agrupamento lógico do Capítulo 5, não um container adicional ao Nível 2.
Elementos do diagrama
Aquisição de Dados (FEP) é o Front-End Processor descrito também no Nível 2: gerente de comunicação orientado a conexão, capaz de rodar em múltiplas instâncias (uma para campo, outra para ICCP, por exemplo), com polling em modo host, remoto ou listen-only e caminhos de comunicação redundantes escolhidos por menor custo (manual, p. 163–165).
Camada de Protocolos é o conjunto de drivers que o FEP usa para falar com dispositivos de campo e outros centros de controle: DNP3, IEC 104, IEC 101, Modbus e ICCP/TASE.2 (incluindo "ICCP seguro"), com segurança tratada pela série de normas IEC 62351 (manual, p. 172–184).
Processamento de Dados trata pontos analógicos, digitais e acumuladores — conversão para unidades de engenharia, verificação de qualidade, Device Operation Monitoring (contadores, resets), dados manuais/calculados e agregação de séries temporais — é o núcleo que decide o que o resto do sistema "sabe" sobre o estado da rede (manual, p. 187–217).
Controle Supervisório trata o envio de comandos ao campo: controle de dispositivo, comando SBO (select-before-operate, que exige seleção e confirmação antes de executar), setpoint, validação de controle, reserva e intertravamento entre equipamentos (manual, p. 217–224).
Tagging implementa exceções e inibição de controle por dispositivo, associadas a uma Área de Responsabilidade (AOR) do usuário; suporta herança e agrupamento de tags para aplicar regras de negócio da concessionária sem alterar o modelo de rede em si (manual, p. 225–232).
Gestão de Alarmes e Eventos cobre configuração, atributos, atraso, escalonamento, reconhecimento, supressão e "shelving" (arquivamento temporário) de alarmes, além do armazenamento de eventos para auditoria — é o componente que efetivamente notifica o Operador (manual, p. 233–266).
Motor de Cálculo Genérico (GCE) permite ao usuário configurar cálculos simples ou complexos sobre outros valores (somas, integrais), ações automáticas personalizadas e alarmes derivados de lógica de negócio específica, sem precisar de uma aplicação de potência completa (manual, p. 266–269).
Sequências de Controle monitoram sinais analógicos e discretos específicos e, uma vez ativadas, disparam ordens de comando em múltiplas UTRs até que um critério de saída configurado seja atingido — por exemplo, uma sequência de corte de carga até atingir um nível-alvo (manual, p. 163, 269–271).
Dispositivos de Campo são os mesmos IEDs e RTUs já descritos no Nível 1 — aqui como fronteira externa que troca telemetria e comandos com a Aquisição de Dados.
ADMS Platform Services é o mesmo container do Nível 2; o Processamento de Dados deste diagrama alimenta especificamente o Dynamics Data Service dentro dele, o que reforça a nota acima sobre SCADA não ter container próprio no Nível 2.
Aplicações de Potência (DMS/EMS) também é o mesmo container do Nível 2 — consome o estado da rede (pontos analógicos e digitais) que o Processamento de Dados do SCADA disponibiliza, como insumo para Fluxo de Carga, Estimação de Estado e as demais aplicações detalhadas nos diagramas seguintes.
Leitura: os oito componentes seguem a própria estrutura de seções do Capítulo 5 (5.1 Aquisição de Dados, 5.2 Protocolos, 5.3 Processamento de Dados, 5.4 Controle Supervisório, 5.5 Tagging, 5.6 Alarmes + Eventos, 5.7 Motor de Cálculo Genérico + Sequências de Controle) — enumeração confiável, direto do sumário do fabricante. As relações são inferência da consultoria a partir da prosa das páginas 162–170 (ex.: "a comunicação com dispositivos de campo é realizada pelo processador de Front End", p. 163) — o manual não traz um diagrama de dependências explícito entre estes oito itens (a Fig. 5-1, "Arquitetura de Alto Nível", citada no texto extraído do PDF perdeu o conteúdo gráfico na extração, restando só a legenda "ADMS → FEP").
Nível 3 — Componentes: Aplicações de Potência — DMS¶
Baseado no Capítulo 11 do manual (pp. 441–570) — sumário detalhado da seção + página de abertura (442–443, Aplicações Principais).
Elementos do diagrama
Fluxo de Carga (Load Flow) calcula o estado estável da rede — tensões complexas, correntes, fluxos ativos/reativos, quedas e perdas — para redes radiais e fracamente malhadas de média e baixa tensão; o manual o descreve como mecanismo usado por quase todas as outras aplicações de energia do ADMS (estimação de estado, índices de desempenho, DER, reconfiguração, VVO, FLISR, validação de manobra), rodando automaticamente em segundo plano e disparando por mudança de topologia, de setpoint, periodicamente ou por solicitação do usuário (manual, p. 443).
Estimação de Estado complementa o Fluxo de Carga com pré-estimação, verificação de medição, alocação de carga, verificação de tensão medida e observabilidade de DER — produz o "estado estimado" da rede quando a medição direta é insuficiente (manual, p. 452–457).
Simulação de Lógica de Controle permite simular o comportamento de lógicas de controle configuradas antes de aplicá-las de fato na rede (manual, p. 462–464).
Redução de Tensão de Emergência é uma aplicação baseada em SCADA (sem depender de Fluxo de Carga/Estimação de Estado) para reduzir tensão em situação de emergência (manual, p. 467).
Controle de Tensão / VAR ajusta tensão e potência reativa com base em medição SCADA direta (manual, p. 468).
Lite Load Relief é a versão "Lite" (baseada em regras/SCADA, sem modelo de rede completo) do alívio de carga — contraponto mais simples ao Load Relief da família de Otimização e Restrição (manual, p. 469–472).
Load Shedding corta carga de forma controlada quando necessário, também com abordagem baseada em SCADA (manual, p. 473–474).
Índices de Desempenho calcula KPIs de desempenho da rede a partir dos resultados de outras aplicações (manual, p. 476–479).
Monitoração Térmica acompanha o carregamento térmico de equipamentos da rede (manual, p. 482–483).
Energia e Perdas Operacionais calcula energia consumida e perdas técnicas/operacionais da rede (manual, p. 486–490).
Análise de Confiabilidade Probabilística / Determinística avalia a confiabilidade da rede por dois métodos complementares — probabilístico (baseado em taxas de falha históricas) e determinístico (manual, p. 491–494).
Análise de Curto-Circuito cobre cálculo de falhas, equivalente Thevenin e capacidade fusível de disjuntor — a base para dimensionar proteção (manual, p. 495–504).
Relé de Proteção trata coordenação de proteção, tempo mínimo de tripping, sensibilidade, configuração e proteção adaptativa de relés — consome diretamente os resultados da Análise de Curto-Circuito (manual, p. 505–513).
Análise de Contingência simula a perda de um elemento da rede (contingência N-1) para antecipar violações, usando a Estimação de Estado como insumo (manual, p. 515–516).
Análise Harmônica avalia distorção harmônica na rede (manual, p. 519–520).
Previsão (Forecasting) projeta carga futura, alimentando o Look Ahead (manual, p. 523–527).
Look Ahead projeta o estado futuro da rede a partir da previsão de carga, para planejamento operacional de curto prazo (manual, p. 531–533).
Under Load Switching avalia manobras sob carga antes de executá-las (manual, p. 535–537).
Reconfiguração da Rede recalcula a topologia ótima da rede (normalmente para restauração ou redução de perdas), usando o Fluxo de Carga como insumo (manual, p. 538–541).
Load Relief é a versão "Avançada" do alívio de carga, baseada em modelo de rede — contraponto ao Lite Load Relief das Aplicações baseadas SCADA (manual, p. 545–549).
Otimização Volt VAR (VVO) otimiza tensão e potência reativa em toda a rede usando o modelo completo (ao contrário do Controle de Tensão/VAR baseado em SCADA), realimentando os cálculos de Energia e Perdas Operacionais (manual, p. 557–562).
Protetor de Rede trata a proteção de redes malhadas secundárias de baixa tensão (manual, p. 568).
Fluxo de Carga — Rede Malhada Secundária é uma variação do Fluxo de Carga principal, especializada em redes malhadas secundárias de baixa tensão (manual, p. 568).
Dados de Medidores Inteligentes em DMS incorpora leituras de medidores inteligentes (AMI) como insumo às aplicações DMS de baixa tensão — relevante notar que a integração AMI ainda não está implementada na Energisa, per o Nível 1 (manual, p. 569).
Network Model é o mesmo container do Nível 2 (dentro de ADMS Platform Services) que fornece modelo e topologia calculada como insumo ao Fluxo de Carga.
Motor de Cálculo é o mesmo container do Nível 2 que executa as Aplicações Principais via trigger e agendamento.
SCADA é o conjunto de componentes detalhado no diagrama anterior, que fornece medição em tempo real ao Fluxo de Carga.
Leitura: os 20 componentes seguem literalmente as seis subseções do Capítulo 11 e suas respectivas aplicações nomeadas — enumeração de alta confiança (sumário do fabricante, cada item com página própria). As relações representadas são poucas e deliberadamente conservadoras: refletem apenas o que a página de abertura (442–443) afirma explicitamente ("O LF é usado como um mecanismo em quase todas as outras aplicações de energia do ADMS") — o manual não documenta, nesta leitura, um mapa de dependências completo entre os 20 componentes; presumir mais relações do que as listadas seria especulação da consultoria, não leitura do fabricante.
Nível 3 — Componentes: Aplicações de Potência — DERMS¶
Baseado no Capítulo 12 (Utility DERMS, pp. 570–608) + Capítulo 13 (Gestão de Microgrid, pp. 608–619) do manual — sumário detalhado de ambos + páginas de abertura do Cap. 12 (570–571, conceito Lite vs. Avançado).
Elementos do diagrama
Modelagem DER representa os recursos energéticos distribuídos no modelo de rede — DER primária (conectada diretamente à rede), behind-the-meter DER (atrás do medidor do consumidor) e os sinais de monitoramento/controle associados a cada um (manual, p. 573–577).
Agregação DER agrupa DERs individuais em unidades gerenciáveis, incluindo integração com sistemas de terceiros (agregadores) e a ponte conceitual com microrredes (manual, p. 577–580).
Monitoramento DER acompanha em tempo real e de forma prevista a produção e capacidade dos DERs no nível do circuito — é aqui que a abordagem "Lite" (baseada em dados SCADA) se apoia quando não há modelo de rede refinado o bastante para a abordagem Avançada (manual, p. 581–582).
Controle DER despacha comandos aos DERs, seja a partir de relatório, da visualização de rede ou com validação de manobra (manual, p. 585).
Gerenciamento de Restrições DERMS detecta e trata violações de tensão, sobrecarga e fluxo reverso de energia causadas pela penetração de DER, incluindo um modo de gerenciamento antecipado de restrições que tenta preveni-las antes que ocorram (manual, p. 587–591).
Gestão da Demanda administra programas de resposta à demanda (DR) que usam os DERs como recurso de flexibilidade (manual, p. 592).
Flexibilidade Watt & VAR quantifica a flexibilidade disponível de potência ativa e reativa nos DERs agregados, sem necessariamente verificar restrições de rede — insumo para a Otimização Volt VAR Watt (manual, p. 593–595).
Otimização Volt VAR Watt (VVWO) é a versão do VVO que também considera a potência ativa (Watt) disponível nos DERs, além de tensão e VAR — a otimização mais completa da família DERMS (manual, p. 596–601).
Habilitando o DER cobre duas funcionalidades de viabilização: capacidade de armazenamento de energia e conexão de novos DERs ao consumidor (manual, p. 603–607).
Gestão de Microgrid é tecnicamente do Capítulo 13, mas foi incluída neste diagrama por já ser referenciada dentro do Cap. 12 como "Microgrids & DERMS" — cobre controle DER automático e otimização econômica de microrredes operando em modo ilhado ou conectado (manual, p. 608–619).
Fluxo de Carga / Estimação de Estado (DMS) representa, de forma agregada, as duas aplicações principais do diagrama de DMS que a abordagem Avançada do DERMS consome como insumo de modelo de rede.
SCADA é o conjunto de componentes já detalhado, aqui como a fonte de dados que sustenta a abordagem Lite do DERMS quando o modelo de rede não é preciso o suficiente para a abordagem Avançada.
Leitura: um conceito arquitetural relevante do Cap. 12 (p. 570–571), não representado como componente próprio mas que atravessa todos eles: cada função do DERMS pode operar em modo Lite (baseado em regras/SCADA, sem Fluxo de Carga/Estimação de Estado) ou Avançado (baseado em modelo de rede, usa Fluxo de Carga/Estimação de Estado/Cálculo de Falhas) — a mesma dualidade documentada para FLISR e VVO no Nível 2. microgrid_mgmt é tecnicamente um capítulo à parte (13) mas foi incluído aqui por já ser referenciado dentro do próprio Cap. 12 como "Microgrids & DERMS" (p. 580) — decisão de agrupamento da consultoria, não do manual.
Nível 3 — Componentes: Aplicações de Potência — EMS¶
Baseado no Capítulo 14 do manual ("Aplicações Avançadas de (Sub)Transmissão", pp. 619–671) — sumário detalhado da seção + página de abertura (619, Fig. 14-1).
Elementos do diagrama
EMS Estimação de Estado é o equivalente, para a rede de (sub)transmissão, da Estimação de Estado do DMS — produz o estado estimado a partir do estado topológico das "ilhas elétricas" calculado pelo Topology Analyzer (manual, p. 620–624).
EMS Fluxo de Carga calcula o estado estável da rede de transmissão, consumindo a Estimação de Estado como insumo (manual, p. 629–632).
EMS Índices de Desempenho calcula KPIs de desempenho apresentados em dashboards do ADMS, alimentados pela Análise de Contingência (manual, p. 635–636).
EMS Análise de Contingência simula a perda de elementos da rede de transmissão para antecipar violações, a partir do Fluxo de Carga (manual, p. 637–640).
EMS Estabilidade de Tensão avalia o risco de colapso de tensão na rede de transmissão (manual, p. 643–645).
EMS Monitoramento de Reserva Reativa acompanha a margem de potência reativa disponível no sistema (manual, p. 646–647).
EMS Estabilidade de Sinal Baixo avalia estabilidade de pequenos sinais (oscilações) na rede de transmissão (manual, p. 648–651).
EMS Cálculo de Falta calcula correntes e efeitos de falhas na rede de transmissão, alimentando a Proteção Adaptável de Relé (manual, p. 651–652).
EMS Capacidade do Disjuntor avalia se a capacidade de interrupção dos disjuntores é suficiente para as correntes de falta calculadas (manual, p. 655–657).
EMS Proteção Adaptável de Relé ajusta a configuração de relés de proteção de forma adaptativa, a partir dos resultados do Cálculo de Falta (manual, p. 658–659).
EMS Operação do Relé acompanha e registra a operação efetiva dos relés de proteção (manual, p. 661).
EMS Fluxo de Potência Ótimo otimiza o despacho de potência na rede de transmissão respeitando restrições operacionais (manual, p. 663–664).
EMS Alteração Otimizada da Topologia avalia mudanças de topologia como ferramenta de otimização/gerenciamento de restrições (manual, p. 667–668).
EMS Cálculo do Fator de Penalidade calcula fatores de penalidade usados no despacho econômico (manual, p. 669–670).
Topology Analyzer é citado no manual como o componente que atualiza dinamicamente as "ilhas elétricas" da rede de transmissão — ele é a fronteira externa que alimenta toda a família de Avaliação de Segurança com o estado topológico corrente (manual, Fig. 14-1, p. 619).
Leitura: os 14 componentes seguem as três subseções do Capítulo 14. O manual descreve EMS como compartilhando a mesma plataforma comum (modelo de rede, SCADA, alarmes, tags, AOR, elementos temporários, UI, relatórios, base histórica) com os demais módulos — arquiteturalmente é a mesma família "Aplicações de Potência" do Nível 2, só que operando sobre a parte da rede marcada como transmissão em vez de distribuição (p. 619). Fora de escopo declarado da Energisa hoje (o assessment cobre distribuição — ver dominio-funcional-adms.md); incluído aqui por completude do produto, não porque haja evidência de uso na Energisa.
Nível 3 — Componentes: Operational Historian (Reporting)¶
Baseado no Capítulo 17 do manual (pp. 710–752) — sumário detalhado da seção + páginas de abertura (710–711, ADMS Reporting Summary). Decompõe o container Módulo de Séries Temporais do Nível 2 do lado da camada de aplicação/apresentação de relatórios — o Cap. 17 é a camada de acesso e apresentação sobre os dados que os módulos de Historical Services (Nível 2) armazenam.
Elementos do diagrama
Historical Data Browser apresenta dados históricos em visão tabular, incluindo os browsers especializados de Elementos Temporários, Tags e Faltas, mais o Historical Changes Summary — é o ponto de entrada mais genérico para consulta de dados históricos (manual, p. 711–717).
Tendências (Trending) oferece a janela de tendências propriamente dita, com seleção de intervalo, múltiplas fontes, somatório de tendência, salvamento de gráficos, carregamento de snapshot e playback — a ferramenta de análise temporal mais usada do historiador (manual, p. 718–736).
Sumário de Violação Histórica lista violações de limites/restrições ocorridas no passado, para análise retrospectiva (manual, p. 737).
Curva de Duração de Carga apresenta a curva de duração de carga a partir de dados de tendência, com filtro de seleção de dados e atributos configuráveis (manual, p. 739–740).
Exportação de Dados Históricos permite selecionar e exportar dados históricos, com propriedades de seleção configuráveis (manual, p. 741–744).
Componentes de Relatórios Personalizados são os três componentes que o manual nomeia explicitamente como base de relatórios customizáveis do ADMS: o ADMS SQL Engine, o Microsoft SQL Server (como parte da arquitetura do próprio ADMS) e o Microsoft SQL Server Reporting Services — complementam os relatórios pré-definidos do Historical Data Browser (manual, p. 711, 747–748).
Capacidades de Arquivamento de Dados definem a política de retenção/arquivamento de dados históricos ao longo do tempo (manual, p. 752).
Módulo de Séries Temporais e Módulo de Log de Eventos são os mesmos ContainerDb já descritos no Nível 2 — aqui aparecem como as fontes de dados que o Historical Data Browser e a Tendências efetivamente consultam.
DMD é o mesmo container de Nível 2 que hospeda os relatórios pré-definidos do ADMS, complementando os relatórios personalizados deste diagrama.
Leitura: o manual é explícito (p. 710) que o Operational Historian não é só armazenamento — é uma "plataforma de apoio" com "recursos genéricos próprios, independentes dos componentes individuais do sistema ADMS", o que justifica tratá-lo como container de Nível 3 separado, decompondo o acesso/apresentação sobre os dados que os ContainerDb do Nível 2 armazenam, em vez de fundir os dois. Os três componentes de relatórios personalizados (custom_reports) recebem menção explícita como os "três componentes principais de relatórios customizáveis ADMS" (p. 711) — a única lista fechada e explícita do capítulo; os demais componentes são inferidos da estrutura de seções.
O que ficou fora deste levantamento¶
Com esta rodada, todos os containers de Nível 2 diretamente ligados a "Aplicações de Potência" e a "Serviço RealTime" (SCADA, DMS, DERMS, EMS) mais o Operational Historian têm decomposição de Nível 3. Ainda assim, dois tipos de lacuna permanecem, e é importante distingui-los:
Lacuna de profundidade (o capítulo foi tocado, mas não lido corpo a corpo — ver "Nota metodológica"): SCADA (Cap. 5), DMS (Cap. 11), DERMS (Cap. 12), Gestão de Microgrid (Cap. 13), EMS (Cap. 14) e Operational Historian (Cap. 17) tiveram a enumeração de componentes extraída do sumário detalhado do fabricante (alta confiança), mas as relações entre componentes são inferência da consultoria a partir de 1–2 páginas de abertura por capítulo, não da leitura integral. Só o Cap. 2 (arquitetura geral) e os Cap. 8/9 (OMS + Gestão de Equipes) tiveram leitura corpo a corpo completa.
Lacuna de cobertura (capítulo nunca aberto, nem sumário nem corpo): os seguintes capítulos do manual não foram lidos em nenhum grau nesta ou na rodada anterior —
| Capítulo do manual | Páginas | Por que é relevante |
|---|---|---|
| Cap. 6 — Contextos de Simulação | 274–289 | Mecanismo de "what-if"/simulação citado no Nível 1 (Fig. 2-1, Access Services System) mas nunca decomposto |
| Cap. 7 — Gerenciamento de Manobra | 289–340 | Referenciado como switching_mgmt no Nível 3 do OMS, mas o capítulo próprio nunca foi aberto |
| Cap. 10 — Configuração e Monitoramento do ADMS | 432–441 | Profile Library, modo Normal/Storm — só a página de transição (431–432) foi vista de relance |
| Cap. 15 — Aplicações de Geração (GMS) | 671–681 | Quinto domínio do produto (SCADA+DMS+OMS+EMS+DERMS, p. 32) sem nenhuma leitura ainda |
| Cap. 16 — Planejamento de Rede | 681–710 | Não lido |
| Cap. 18 — Simulador de Treinamento do Operador (OTS) | 754–819 | ToC capturado (Ambiente do Aluno/Instrutor, Gravador de Cenário, Lógica de Campo Simulada), corpo não lido — módulo já citado como container próprio em dominio-funcional-adms.md |
| Cap. 19 — Integração de Sistemas Corporativos | 821–903 | Candidato mais valioso para leitura futura — pelo título, é provável que detalhe exatamente os adapters já catalogados em catalogo-adapters-schneider-adms.md (pp. 883–899 ficam dentro desta faixa), com possível material adicional de arquitetura de integração ainda não incorporado a nenhum artefato |
| Cap. 20 — Segurança | 903–927 | Não lido — relevante para IAM/hardening, fora do escopo de integração deste assessment até agora |
| Cap. 21 — Monitoramento e Administração do Sistema | 927+ | Não lido — potencialmente relevante para monitoramento-observabilidade-adms.md |
Se o objetivo for um C4 realmente completo do ADMS, os próximos candidatos por ordem de valor esperado são: Cap. 19 (cruza diretamente com o catálogo de adapters já existente), Cap. 7 (fecha o container de Gerenciamento de Manobra já referenciado no Nível 3 do OMS) e Cap. 18/OTS (módulo inteiro ainda sem qualquer componente mapeado).
Referências internas: blueprint-componentes-adms.md · dominio-funcional-adms.md · catalogo-adapters-schneider-adms.md · integracao-wfm-adms.md · integracao-wfm-eforce-ordem-servico.md · arquitetura-datacenters-redundancia.md