HLD As-Is — ADMS (núcleo, adapters e integrações diretas)

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Fonte: Síntese de sete artefatos já publicados — dominio-funcional-adms.md (Ata 03), blueprint-componentes-adms.md (consolidado), fluxos-atendimento-adms.md (Ata 09 + wiki técnica), integracao-gis-adms.md (Ata 06), integracao-manutencao-dms-adms.md (Ata 07), integracao-wfm-adms.md (Ata 08) e integracao-sustentacao-adms.md (sessão sem Ata, 24/07) — mais a matriz de riscos consolidada e a matriz de achados e lacunas Status: Rascunho para validação — HLD As-Is (arquitetura atual), não To-Be Elaborado por: Consultoria Syntropy

Nota de leitura

HLD As-Is — documenta a arquitetura do ADMS (núcleo, adapters e integrações diretas) como ela é hoje, não o desenho To-Be. Parte dos achados citados aqui (R31 em diante, incluindo R34, R42 e R43) ainda não passou pela validação de Fase 3 com Norberto e Rômulo — onde um achado é "hipótese a validar" ou "risco potencial", o texto sinaliza isso explicitamente; caso contrário, é tratado como confirmado. Ver também o HLD do Barramento e o diagrama de contexto do ecossistema.

Por que este documento existe

O levantamento (Fase 1 do assessment) está perto do fechamento — falta apenas o retorno com o WFM. O ADMS é o sistema central do assessment: todo o resto (Barramento, GIS, WFM, SGM, atendimento, observabilidade) existe para alimentá-lo ou consumi-lo. Antes de avançar para o To-Be (Fase 4), faz sentido consolidar num único documento de arquitetura tudo que já se sabe sobre o núcleo do ADMS e suas integrações diretas, hoje espalhado em sete artefatos e duas matrizes — incluindo um achado recente e ainda pouco divulgado (o caminho duplo ADMS/RabbitMQ-MSGOT) que muda a leitura de "o ADMS já processa tudo" para "o ADMS processa para quem já migrou". Esse é o objetivo deste HLD: ser o ponto de entrada único para "como o ADMS funciona hoje e com quem ele fala diretamente", com links para o detalhe em cada artefato de origem — não substituí-los.

Diagrama 1 — Visão consolidada: núcleo, adapters e integrações diretas

Este diagrama consolida numa única visão o núcleo do ADMS (cinco módulos internos: EMS, SCADA, DMS, OMS, OTS), o ambiente de staging que recebe o cadastro do GIS, o banco operacional (SQL Server) e as sete integrações diretas já confirmadas: GIS (cadastro), WFM/SIGOD (equipes), SGM (notas de serviço), Atendimento/CRM (ocorrências técnicas, com o caminho duplo ADMS/RabbitMQ recém-descoberto), Motor de cálculo IQOS (indicadores regulatórios de continuidade DEC/FEC para a ANEEL, via Barramento — ver Diagrama 3 de integracao-wfm-adms.md), Sustentação (operação) e AMI/MDM (ainda não implementada). O Barramento Confluent Kafka aparece como caixa externa — sua topologia interna, capacidade e governança de eventos já estão detalhadas no HLD do Barramento, não repetidas aqui.

Achado central deste HLD, ainda não amplamente divulgado: o caminho duplo ADMS/RabbitMQ via parâmetro global 70 do SIATT. Diferente do que os Diagramas 1 e 2 de fluxos-atendimento-adms.md sugerem isoladamente, o ADMS não processa hoje 100% das aberturas de ocorrência técnica — só processa para as distribuidoras já migradas. As demais seguem por um caminho legado (RabbitMQ → sistema MSGOT) sem nenhuma cobertura documental até 08/08/2026 (proposto como R43). Como o G1 é justamente a onda de migração em curso (go-live 01/09), esse achado é relevante para qualquer leitura de "cobertura atual do ADMS" — inclusive para este próprio HLD, que documenta o ADMS assumindo o caminho migrado como a via principal.

Diagrama 2 — Sequência: bifurcação ADMS/RabbitMQ-MSGOT (R43)

Diagrama de sequência — Diagrama 10 de fluxos-atendimento-adms.md. Até a revisão anterior deste HLD, esse achado só existia em prosa, em nenhum artefato-fonte; o diagrama foi promovido para o artefato de origem nesta revisão, junto com uma lacuna registrada sobre o comportamento interno do MSGOT (retry, dead-letter, ordenação) — ver detalhe lá.

Inventário de componentes

Componente	Papel	Observação
EMS	Loadflow, estimador de estados, localização de faltas, manobras de restabelecimento, IVVO, modelo de rede	Módulo novo, incorporado com o ADMS
SCADA	Aquisição de dados, monitoração, controle supervisório, alarmes, gestão de TAGs, self-healing	Pré-existente, aprimorado pelo ADMS; sem integração direta documentada com o GIS e sem inventário de protocolo/RTU/IED nem modelo de cutover dos SCADAs legados (R45, ver "Lacunas e pendências de evidência")
DMS	UBLF, localização de faltas, manobras, FLISR, IVVO, monitoração DER, modelo de rede, simulador, historiador	Mistura de funções novas e aprimoradas; recebe cadastro do GIS via GIS Adapter
OMS	Previsão de interrupção, verificação e restauração, ETRs, gestão de equipes de campo, análise de confiabilidade	Módulo novo; entrada em produção (G1) prevista 01/09, sem critérios formais de aceite (R34)
OTS	Ambiente de treinamento	Comum a todos os módulos
ADMS Staging (Grupo 3)	Recebe e valida (4 etapas) os extratos do GIS antes da importação	Single tenant compartilhado entre 3 empresas do grupo — sem segregação por perfil
SQL Server ADMS/DMS	Banco operacional; hospeda views proprietárias que chamam DLLs internas do produto	Versão em divergência aberta: 2019 (diagrama) vs. 2022 (Norberto)
GIS Adapter	Traduz modelo GE (Smallworld) → Schneider, calcula atributos derivados	Customizado, fornecedor provável Minsait (?) — não confirmado
Adapter WFM (SOAP)	Descompacta e processa carga full de equipes	Sem endpoint de equipe única — só carga completa ou mudança de status via tela
WSROT	Serviço de entrada de ocorrências técnicas; decide o caminho ADMS vs. RabbitMQ/MSGOT	Parâmetro global 70 do SIATT
MsCrmMiddleware	Interface síncrona com o ADMS (POST /TroubleTickets/)	Via Sensedia

Módulos internos do ADMS

Detalhado com diagrama de domínio funcional em dominio-funcional-adms.md (Ata 03). Resumo: o ADMS reúne cinco módulos — EMS e OMS trazem funções inteiramente novas para a Energisa; SCADA é pré-existente e aprimorado; DMS mistura funções novas e aprimoradas; OTS é o ambiente de treinamento comum. O perímetro de integração direta é GIS, SIATT/SIATE, SGM, atendimento digital e WFM/SIGOD — nenhum desses tem protocolo, direção ou contrato de interface totalmente detalhado no slide de origem, lacuna que os artefatos de integração individuais (linkados abaixo) fecham parcialmente. AMI/MDM segue como a única integração não implementada, avaliada para uma fase futura pelo risco de falso positivo (medidor pode indicar falta de energia por desligamento do próprio disjuntor do cliente).

Diagrama 3 — Sequência: aquisição de dados de campo do SCADA (genérico do fabricante, não confirmado — R45)

Este diagrama não descreve a Energisa. Nenhum artefato do assessment documenta como os equipamentos de campo alimentam o SCADA (ver R45 nas "Lacunas e pendências de evidência" abaixo) — o que segue é a arquitetura de aquisição de dados genérica do produto, conforme o Anexo A (Manual Técnico do EcoStruxure ADMS 3.8, seção 5 "SCADA"). Ele existe aqui só para dar forma concreta à pergunta que falta responder com a Energisa: qual protocolo, quantas RTUs/IEDs, e qual dos três modelos de cutover descritos pelo fabricante (RTU de porta dupla, listen-only ou ICCP entre sistemas) foi de fato usado na transição dos SCADAs legados (Siemens, EFACEC) para o SCADA do ADMS.

Ambiente compartilhado: single tenant do Grupo 3

Detalhado em integracao-gis-adms.md (Diagrama 3). O ambiente de ADMS Staging do Grupo 3 é compartilhado por três empresas (Mato Grosso do Sul, Minas e Rio, Sudeste) sem segregação por perfil — um usuário de uma empresa também vê e pode processar, por desatenção, o extrato de outra. A Ata 06 já classifica esse achado como severidade Alta (item 1.7.15.2). Origem do trade-off: o desenho original previa um ADMS por empresa, inviável por custo; a consolidação em grupos reduziu custo, mas o produto não oferece segregação técnica dentro do grupo — hoje o único controle é a atenção manual do usuário. É o mesmo padrão de "ambiente compartilhado trocando isolamento por custo" já visto no ksqlDB do Barramento (9 empresas consolidadas num único cluster).

Integração GIS → ADMS (cadastro de ativos)

Diagrama de sequência principal do fluxo GIS → ADMS — Diagrama 2 de integracao-gis-adms.md. Topologia e o diagrama de risco do single tenant (Diagramas 1 e 3) continuam só naquele artefato.

Detalhado com diagramas de topologia e sequência em integracao-gis-adms.md (Ata 06). Fluxo unidirecional e assíncrono: o GIS Adapter (customizado, fornecedor provável Minsait — não confirmado) traduz o modelo GE (Smallworld) para o modelo Schneider, calcula atributos derivados e entrega extratos XML por grupo/empresa via SFTP, em batch noturno. O ADMS Staging valida em 4 etapas e rejeita o extrato completo do circuito em caso de erro — não item a item, o que amplifica o impacto de qualquer inconsistência pontual no cadastro.

Integração SGM (Manutenção) → OMS

Diagrama de sequência principal do fluxo SGM → OMS — Diagrama 2 de integracao-manutencao-dms-adms.md. Topologia dos três microsserviços e o diagrama de risco de escalabilidade (Diagramas 1 e 3) continuam só naquele artefato.

Detalhado em integracao-manutencao-dms-adms.md (Ata 07). O SGM (sistema de gestão de manutenção — EAM) gera notas de serviço consumidas pelo OMS através de três microsserviços dedicados (consulta/envio/notificação), via Kafka e Sensedia.

Integração WFM/SIGOD → OMS e motor de cálculo IQOS

Diagrama de sequência principal do fluxo WFM/SIGOD → OMS (achado confirmado R10) — Diagrama 2 de integracao-wfm-adms.md. O motor de cálculo IQOS tem seu próprio diagrama de sequência (Diagrama 3, dependência entre incidentes) e a topologia (Diagrama 1) — ambos só naquele artefato.

Detalhado em integracao-wfm-adms.md (Ata 08). Carga full de equipes via SOAP/SFTP — sem endpoint de equipe única, sem confirmação de processamento (achado confirmado, R10). O motor de cálculo IQOS e as integrações do WFM pressionam o barramento em janelas concentradas de tempo (hipótese a validar, pendente de confirmação de volumetria com o especialista do WFM — é justamente essa sessão pendente que está perto de fechar o levantamento).

Atendimento/CRM ↔ ADMS: ocorrências técnicas

Diagrama de sequência principal do fluxo Atendimento/CRM ↔ ADMS — Diagrama 2 de fluxos-atendimento-adms.md. Os outros 8 diagramas de sequência (Desligamento Programado, Encerramento de Comunicação, Geração de Comunicação, Atualização de Clientes, Desligamento Emergencial, Flexible Load, Load Profile) e o mapa estático de microsserviços continuam só naquele artefato.

Detalhado com 9 diagramas de sequência em fluxos-atendimento-adms.md (Ata 09 + wiki técnica, 08/08/2026). O WSROT recebe a abertura de ocorrência dos canais (digitais ou convencional), decide o caminho pelo parâmetro global 70 do SIATT e publica no Kafka (crm_chamada_ocorrencia_tecnica) para distribuidoras já migradas — o MsCrmMiddleware consome, aciona o ADMS via Sensedia (POST /TroubleTickets/, síncrono) e o retorno flui de volta pelo Kafka. Para distribuidoras não migradas, o mesmo WSROT publica no caminho legado RabbitMQ → MSGOT (ver achado central acima, R43). Payloads reais do tópico crm_chamada_ocorrencia_tecnica contêm CPF e telefone em texto puro, sem Schema Registry (proposto como R42). Nenhum dos 8 tópicos deste fluxo tem schema registrado hoje.

Integração ADMS ↔ Sustentação

Diagrama de sequência principal do fluxo de diagnóstico ADMS ↔ Sustentação — Diagrama 1 de integracao-sustentacao-adms.md. A proposta de event sourcing paralelo e a racionalização de tópicos (Diagramas 2 e 3) continuam só naquele artefato.

Detalhado em integracao-sustentacao-adms.md (sessão de 24/07/2026, sem Ata formal correspondente — lacuna de cobertura documental, não erro de fidelidade). Cobre o dia a dia operacional de diagnóstico e correção de incidentes no ecossistema ADMS/SIGOD/Kafka: hoje sem event sourcing e sem alerta efetivo, segundo o diagnóstico da própria equipe de Sustentação (Wagner, Pedro, Lucas).

Dados e persistência

O SQL Server ADMS/DMS hospeda as views proprietárias do produto, que invocam DLLs e funções internas — algumas leem o SCADA em memória — e por isso não podem ser capturadas por CDC nativo diretamente. A materialização de views (job customizado da Energisa, 5–10 min, merge por chave) é a única alternativa hoje, criada sob pressão de prazo e sem equipe formalmente responsável (R21, R26). Atualizações do fornecedor já quebraram views, tabelas e colunas sem comunicação prévia, interrompendo materialização e captura em produção (R04, achado confirmado). O conector de captura mais extremo (oracle-source-xst-com-mgr) roda 47 tabelas numa única task — teto arquitetural de paralelismo que é causa-raiz proposta para os atrasos de captura já registrados em D9. Separadamente, o próprio adaptador do ADMS sofre de contenção single-thread com defeito de produto em aberto junto à Schneider (R06, crítico) — fila única que cria contenção de priorização, não apenas de vazão.

Riscos e achados conhecidos (ADMS, núcleo e integrações diretas)

#	Sev.	Risco	Domínio	Status de validação
R04	crítico	Atualização do fornecedor quebra views/materialização/captura, sem comunicação prévia de mudança de esquema	ADMS / CDC (D1)	Base v1.10 — achado confirmado (Ata 12)
R06	crítico	Contenção single-thread do adaptador ADMS sob crescimento de volume, defeito de produto em aberto	ADMS / OMS (D1)	Base v1.10 — achado confirmado (Atas 01, 08)
R08	alto	Dual write sem Outbox e ausência de correlation ID nos fluxos de incidentes	CRM / Barramento (D3)	Base v1.10 — achado confirmado (Ata 09)
R09	alto	Janela de sincronização GIS-ADMS de ~12h gera eventos tardios e duplicidades	GIS / ADMS (D2)	Base v1.10 — risco potencial, validação pendente
R10	alto	Carga full de equipes WFM com falhas, timeouts e ausência de confirmação	WFM (D4)	Base v1.10 — achado confirmado (Ata 08)
R21	alto	Procedimentos customizados da cadeia de captura sem responsável formal, SLA ou ciclo de vida	CDC / Governança (D1, D9)	Base v1.10 — validação pendente na Fase 3
R22	alto	Mudança de esquema pode causar perda silenciosa de dados entre origem e consumidores	CDC / Dados (D1, D9)	Base v1.10 — candidato a elevação, validação pendente
R26	médio	Dependência de componentes proprietários do fornecedor para views e bibliotecas	ADMS (D1)	Base v1.10 — validação pendente na Fase 3
R34	alto	Entrada em produção do OMS (01/09) sem critérios objetivos de aceite de integração	G1 / Integrações	Base v1.10 — validação pendente na Fase 3
R42 (proposto)	alto	PII em texto puro em tópico CRM (crm_chamada_ocorrencia_tecnica) sem Schema Registry	CRM / LGPD (D3)	Fora da consolidação v1.10 — evidência de produção, 05/08
R43 (proposto)	alto	Caminho duplo ADMS/RabbitMQ-MSGOT sem inventário nem processo de decomissionamento	G1 / Integrações	Fora da consolidação v1.10 — leitura de wiki técnica, 08/08
R45 (proposto)	alto	Aquisição de dados do SCADA (protocolo, RTU/IED, modelo de cutover dos SCADAs legados Siemens/EFACEC) sem inventário nem confirmação — única relação de entrada documentada (campo → SCADA) está classificada como fora de escopo do projeto	ADMS / SCADA (D1)	Fora da consolidação v1.10 — síntese analítica cruzada de artefatos + manual do fabricante, 08/08

Ver a lista completa, com todas as severidades e origens, na matriz de riscos consolidada (domínios D1–D4) e na matriz de achados e lacunas (seções D1–D4).

Lacunas e pendências de evidência

• Single tenant do Grupo 3: achado já classificado Alta na Ata 06 (item 1.7.15.2), mas sem número R correspondente na matriz de riscos consolidada até a data deste HLD — vale confirmar se essa ausência é intencional (ex.: absorvido em outro item) ou uma lacuna de consolidação a fechar.
• Fornecedor do GIS Adapter: identificado como "Minsait (?)" — possível erro de reconhecimento automático de voz (ASR) nas transcrições-fonte, não confirmado.
• Versão do SQL Server ADMS/DMS: divergência aberta entre o diagrama do cliente (2019) e a resposta direta de Norberto (2022) — duas fontes do próprio cliente se contradizem; tratar como não resolvida, não arbitrar silenciosamente.
• Caminho legado RabbitMQ/MSGOT: sem inventário de quantas distribuidoras ainda dependem dele nem processo formal de corte/decomissionamento — achado muito recente (08/08/2026), ainda não incorporado a nenhuma Ata. O modelo de bifurcação em si (migradas → Kafka, demais → RabbitMQ) foi confirmado por Castellani em 12/08/2026, mas o comportamento interno do MSGOT (retry, dead-letter, ordenação, tratamento de falha) segue sem nenhuma evidência — ver lacuna detalhada no Diagrama 10 de fluxos-atendimento-adms.md.
• Volumetria do motor IQOS e do WFM: hipótese a validar, pendente da sessão com o especialista do WFM (retorno que falta para fechar o levantamento da Fase 1).
• Adapter AVL confirmado em uso, sistema consumidor não identificado: Norberto da Silva Prado (Energisa) confirmou em 27/08/2026 o uso do adapter AVL (Automated Vehicle Location — ver catalogo-adapters-schneider-adms.md), mas nenhum artefato deste assessment identifica qual sistema do lado Energisa consome esses dados de geolocalização de equipes; por isso não foi adicionado ao Diagrama 1 acima. Hipótese a validar, não confirmada: poderia ser o mesmo mecanismo já citado em blueprint-componentes-adms.md (APIs de mapa do Google Cloud) — mas aquele artefato registra esse uso como da mobilidade e do WFM, explicitamente não do ADMS diretamente, o que tornaria a hipótese uma contradição a resolver, não uma confirmação. Ver pergunta correspondente no questionário de mitigação de lacunas, Bloco 5.
• Sessão de Sustentação (24/07): sem Ata formal correspondente — lacuna de cobertura documental que se soma à mesma lacuna já registrada para a sessão de DevOps (06/08) no HLD do Barramento.
• Contrato de interface GIS/SIATT/SGM/atendimento/WFM: protocolo, direção e contrato de interface não totalmente detalhados na fonte original (slide da Ata 03) — os artefatos de integração individuais fecham parte disso, mas não formalizam contrato versionado.
• Aquisição de dados do SCADA (campo → SCADA): nenhum artefato do assessment documenta protocolo (DNP3/IEC 104/IEC 101/Modbus), inventário de RTU/IED, nem modelo de cutover dos SCADAs legados por fornecedor (Siemens — EPB/ESE/EMG; EFACEC — EMS, citados em business-model-canvas.md como parte da meta de consolidação "de 6 fornecedores para 1") para o SCADA do ADMS. A única relação de entrada de dados documentada em todo o assessment (Automação de campo → SCADA, em dominio-funcional-adms.md) está classificada no próprio diagrama como fora de escopo do projeto ADMS — ou seja, a lacuna não é falta de detalhe, é ausência total de mapeamento. Como o G1 já opera com "SCADA recém implantado" (rede-telecom-adms.md), isso é lacuna atual, não só prospectiva. O Diagrama 3 acima ilustra o mecanismo genérico do fabricante só para dar forma à pergunta — não é uma resposta confirmada. Ver R45 na matriz de riscos consolidada e a entrada correspondente em D1 na matriz de achados e lacunas.

Próximo passo

Este HLD é insumo para a Fase 4 (To-Be) do assessment, não o desenho To-Be em si. Antes de qualquer proposta de arquitetura alvo para o ADMS e suas integrações diretas, o plano de trabalho prevê a validação do diagnóstico com Norberto e Rômulo, seguida da rodada técnica com as áreas — que ainda não ocorreu para a maior parte dos achados citados aqui (R31 em diante, incluindo R34, R42 e R43). O achado do caminho duplo ADMS/RabbitMQ-MSGOT (R43) merece atenção prioritária nessa validação, dado o go-live do G1 previsto para 01/09 — recomenda-se não tratar "cobertura do ADMS" como 100% até esse inventário existir. Recomenda-se tratar este documento como parte da base a apresentar na validação, junto com o HLD do Barramento, e não pular direto para uma proposta de arquitetura alvo do ADMS antes dela.