Painel Geral de PoCs

Transformação Digital da Infraestrutura Física & Especificação de Requisitos

Ecosistema de Transformação Digital

Este ecossistema de soluções integradas visa revolucionar a gestão e a auditoria da infraestrutura física da Telefônica Brasil (Vivo). Através do uso estratégico de Inteligência Artificial, visão computacional e automações, o projeto elimina processos legados baseados em controles paralelos e planilhas despadronizadas, estabelecendo fluxos integrados com governança e validação de ponta a ponta.

PoC 1: App Vistoria

Aplicativo móvel corporativo (Android/iOS) que guia o técnico em campo, impede fraudes via bloqueio de galeria e insere marcas d'água de GPS e horário. Valida a qualidade das fotos em tempo real e extrai atributos via visão computacional.

PoC 2: Documentação Legada

Motor de IA de processamento de documentos on-premise. Ingere PDFs e imagens de projetos históricos (PPI, PDI, Arroom), extrai metadados técnicos de infraestrutura com rastreabilidade completa e desduplica itens.

PoC 3: Inventário Infra

Banco de dados relacional flexível com exibição gráfica de componentes em árvore. Oferece importações massivas resilientes (grava válidos e relata erros por célula) e controle de ciclo de vida atrelado a Ordens de Serviço.

Fluxo e Integração de Dados

O ecossistema opera de maneira cíclica e integrada. A PoC 3 (Inventário Infra) serve de centralizador que recebe e valida as cargas de dados vindas do passado (documentos) e do presente (campo):

1

Extração de Dados do Legado (PoC 2) → Inventário (PoC 3): O motor de IA lê a documentação histórica do site e preenche as tabelas relativas de inventário como equipamentos no status "Planejado" (PPI) ou "Instalado" (PDI).

2

Vistorias Físicas de Auditoria (PoC 1) → Inventário (PoC 3): Técnicos coletam dados reais em campo de forma padronizada. Essas informações estruturadas de auditoria física são enviadas via API para o inventário, consolidando ou atualizando a realidade do site.

3

Ciclo de Vida e Validação de Negócio (PoC 3): O inventário gerencia a árvore relacional do site, garante a paternidade das restrições (ex: sem placas sem rack, sem baterias sem gabinete) e promove ativos planejados para ativos instalados mediante gatilhos de conclusão de Ordens de Serviço.

Benefícios Esperados para a Telefônica

  • Eliminação de Retrabalho: Queda acentuada na necessidade de novas visitas técnicas devido a fotos tremidas ou dados faltantes bloqueados na origem pelo app móvel.
  • Precisão do Inventário Histórico: Ingestão rápida e automatizada de dados que hoje estão engessados em PDFs fechados de obras de engenharia.
  • Autonomia para Engenharia: Capacidade de criar novas classes de equipamentos e alterar esquemas de atributos diretamente na interface gráfica, sem dependência de cronogramas de desenvolvimento de TI.
  • Eficiência de Importação: Redução drástica no tempo de triagem de planilhas corrompidas graças ao importador com reporte detalhado por célula e gravação parcial.

PoC 1: Aplicativo de Vistoria de Campo (App Vistoria)

1. Identificação da PoC

  • Nome Provisório: App Vistoria de Campo (Auditoria Digital de Infraestrutura)
  • Objetivo Principal Percebido: Validar uma solução móvel que guie e otimize a coleta de dados de campo (fotos, atributos e metadados) em sites existentes, garantindo a qualidade da evidência (por exemplo, prevenindo fotos tremidas e fraudes) e automatizando a extração de dados através de inteligência artificial (Computer Vision) para carregar e atualizar sistemas de inventário.

2. Resumo Executivo

A PoC visa validar se um aplicativo móvel estruturado pode guiar técnicos em vistorias de sites existentes, padronizando a coleta de evidências e minimizando o preenchimento manual de dados. A principal dor de negócio reside na baixa qualidade e incompletude das vistorias atuais (fotos sem nitidez, dados faltantes e falta de correspondência com o planejado), o que gera retrabalho e visitas repetidas a campo. Com a PoC, pretende-se validar a viabilidade de usar visão computacional (Computer Vision) para extrair metadados e atributos diretamente de fotos legíveis, assegurar a geolocalização e data/hora da vistoria (evitando fraudes via upload de fotos antigas da galeria), e permitir o funcionamento offline first com posterior sincronismo e limpeza automatizada de cache nos smartphones corporativos.

3. Problema de Negócio

As vistorias de campo para levantamento de inventário físico são executadas de forma descentralizada e manual. Os técnicos frequentemente coletam fotos com qualidade insatisfatória (tremidas, embaçadas, sem o enquadramento correto), esquecem de registrar atributos essenciais e capturam imagens que não refletem a situação no dia e hora estipulados. Além disso, a subida de fotos da galeria do celular abre brechas para fraudes e uso de evidências de outros sites. A falta de formulários dinâmicos faz com que o técnico tenha checklists estáticos longos que não se aplicam ao cenário específico do site (ex: exigir dados de bateria em locais sem abrigo/gabinete), resultando em processos lentos, retrabalho em campo e dados de inventário inconsistentes ou incompletos.

4. Objetivo da PoC

  • O que se quer provar/validar:
    • A capacidade do aplicativo de guiar o técnico de forma dinâmica por meio de checklists adaptáveis ao tipo do site.
    • A eficiência do uso de Computer Vision na extração automática de dados técnicos de fotos capturadas.
    • A integridade do processo de auditoria (bloqueando imagens da galeria e forçando fotos reais com marca d'água de GPS e data/hora).
    • A viabilidade operacional da arquitetura offline first em áreas sem conectividade.
  • Hipóteses de Valor: A aplicação guiada e a validação em tempo real da qualidade da imagem em campo reduzem as taxas de retrabalho para menos de 5% e eliminam a necessidade de transcrição manual de dados estruturados pós-vistoria.
  • Critérios Gerais de Sucesso: Padronização completa da entrada de dados, verificação de completude antes do término da OS e dados exportados prontos para carga no banco relacional.

5. Escopo Inicial da PoC

  • Dentro do Escopo:
    • Vistoria técnica em sites existentes (site existente) focado em levantamento de inventário físico.
    • Criação de formulários e checklists dinâmicos baseados no tipo do site e nos elementos cadastrados.
    • Captura de fotos obrigatória diretamente da câmera com bloqueio de upload da galeria do aparelho.
    • Inserção automática de marca d'água nas fotos com: latitude/longitude, data/hora e ID da Ordem de Serviço (OS).
    • Validação de legibilidade/nitidez da imagem capturada em tempo real (alerta de foto tremida/embaçada).
    • Funcionalidade offline first para armazenamento local e sincronização automática pós-conexão.
    • Mecanismo de limpeza automática de cache de imagens do celular do técnico após confirmação do sincronismo na nuvem.
    • Exportação de relatórios digitais (ex: PDF estruturado com fotos, metadados e descrições) e base de dados estruturada.
    • Compatibilidade nativa ou híbrida para Android e iOS.
  • Fora do Escopo:
    • Vistorias em sites novos (pois as informações podem ser extraídas diretamente dos projetos de engenharia preliminares).
    • Vistorias de aceitação de obra definitiva e finalização de instalação física (deixados para fases futuras).
    • Validação de divergência automática de projeto versus real em campo nesta fase da PoC.
  • Premissas:
    • Será fornecida uma planilha Excel padrão com a estrutura mínima de atributos que devem ser validados pela visão computacional/técnico (ex: gabinetes, baterias, cabos).
    • A extração automática via inteligência artificial pode rodar em nuvem ou no aparelho, mas deve tolerar celulares intermediários.
  • Restrições:
    • O aplicativo deve funcionar em aparelhos corporativos comerciais com hardware intermediário (não focado em dispositivos topo de linha).
    • O armazenamento local deve ser otimizado para evitar problemas de memória nos celulares dos técnicos.

6. Requisitos Funcionais

ID Requisito Funcional Descrição Detalhada Prioridade Observações
RF-VIST-01 Formulários Dinâmicos O app deve gerar dinamicamente campos de checklist com base na infraestrutura física declarada do site (ex: exibir campos de bateria apenas se houver gabinete/sala cadastrada). Alta Evita retrabalho do técnico em preencher campos desnecessários.
RF-VIST-02 Captura Direta da Câmera A inserção de evidências fotográficas deve ser realizada unicamente através do acionamento da câmera dentro do aplicativo. Alta Requisito essencial de integridade da evidência.
RF-VIST-03 Bloqueio de Galeria O aplicativo deve impedir a seleção e o upload de fotos armazenadas previamente na galeria do celular. Alta Regra crítica contra má conduta e inconsistências temporais.
RF-VIST-04 Marca d'Água Obrigatória Aplicar na imagem gerada uma marca d'água contendo latitude, longitude, data, hora e ID da Ordem de Serviço (OS) correspondente. Alta Garante a autenticidade e a auditoria da imagem de campo.
RF-VIST-05 Geofencing de OS Bloquear o início e conclusão de vistorias se o GPS do celular do técnico não estiver dentro de um raio de tolerância do site atrelado à OS. Alta Previne vistorias incorretas por erro de navegação ou direcionamento.
RF-VIST-06 Validação de Qualidade de Imagem Analisar em tempo real se a foto está borrada, escura ou tremida, notificando o técnico para repetir a foto imediatamente caso não atinja o padrão de leitura. Alta Garante a eficácia do Computer Vision na etapa posterior de extração.
RF-VIST-07 Checklist de Completude Bloquear a finalização do relatório se houver fotos ou atributos obrigatórios vazios, sinalizando graficamente as pendências. Alta Evita que o técnico saia do site com informações ausentes.
RF-VIST-08 Modo Offline First Permitir a execução de toda a vistoria, preenchimento de checklists e registro de fotos localmente no dispositivo sem conectividade de rede. Alta Essencial para operações em áreas rurais ou subsolos.
RF-VIST-09 Sincronismo Automático Sincronizar todos os dados coletados localmente com a nuvem de forma automática assim que for restabelecido o sinal de internet. Alta O processo deve ocorrer em segundo plano sem travar o app.
RF-VIST-10 Limpeza de Cache Local Deletar as mídias temporárias da memória interna do celular após a confirmação bem-sucedida de recebimento pelo banco de dados na nuvem. Alta Previne que o app consuma todo o espaço de armazenamento do técnico.
RF-VIST-11 Exportação de PDF Técnico Gerar relatórios formatados em PDF que vinculem as imagens aos respectivos campos explicativos para compartilhamento humano. Média Utilizado para auditorias externas e reports para operadoras parceiras.
RF-VIST-12 Organização e Filtro por Metadados Permitir a exportação de dados estruturados com tags associadas às fotos, possibilitando filtragem por tipo de elemento técnico. Média Facilita a consulta das evidências por elemento específico de infra.

7. Requisitos Não Funcionais

ID Requisito Não Funcional Categoria Prioridade
RNF-VIST-01 Compatibilidade de SO Portabilidade Alta
RNF-VIST-02 Requisito Mínimo de Hardware Desempenho Alta
RNF-VIST-03 Arquitetura de Nuvem Interna Infraestrutura Alta
RNF-VIST-04 Escalabilidade de Acessos Escalabilidade Alta
RNF-VIST-05 Qualidade de Imagem p/ Visão Computacional Desempenho Alta

8. Dados, Integrações e Dependências

  • Sistemas Citados: Nuvem interna da Vivo (Telefônica), sistema de Ordens de Serviço (OS), plataforma central de relatórios de vistoria.
  • Fontes de Dados: Planilha Excel com cadastro dos atributos desejados por elemento (ex: gabinete: fabricante, tipo de cabo, alimentação, ligação em GMG, detentora, etc.).
  • Integrações Necessárias: Integração com o sistema de OS para consumir os dados cadastrais da localidade (latitude, longitude, ID do site, tipo de vistoria) e associar as saídas estruturadas.
  • Dependências: Fornecimento prévio da planilha Excel estruturada pela engenharia da Telefônica; liberação de acessos à nuvem Vivo para a instalação da infraestrutura da PoC.

9. Fluxo de Processo Atual e Fluxo Desejado

  • Processo Atual ("As-Is"): O técnico recebe uma demanda de vistoria por canais pouco integrados. Vai a campo e preenche checklists estáticos ou de papel. Coleta evidências fotográficas em massa, muitas vezes de baixa qualidade (borradas ou escuras), sem marcação geográfica oficial. Ao retornar ao escritório, percebe imagens inutilizáveis, necessitando retornar ao local (retrabalho). Os relatórios são manuais e as fotos não possuem relação direta estruturada com os campos de inventário no banco de dados.
  • Processo Desejado ("To-Be"): O técnico recebe a ordem de serviço no aplicativo. Ao chegar ao site, o aplicativo valida as coordenadas via GPS (geofencing). O formulário é gerado dinamicamente para o tipo de site. Ao fotografar cada item, o aplicativo analisa instantaneamente a nitidez e legibilidade da imagem e insere a marca d'água com metadados invioláveis. Se não houver rede, os dados ficam em cache. Ao detectar conexão, o sincronismo sobe os dados estruturados e limpa a memória local do celular. O banco de dados recebe as saídas e gera o relatório PDF.

10. Critérios de Sucesso da PoC

  • Métricas Mencionadas na Reunião:
    • Garantia de que 100% dos dados essenciais (definidos no Excel de atributos) sejam mapeados.
    • Bloqueio efetivo de uploads da galeria.
    • Marca d'água contendo coordenadas GPS, hora e OS em todas as fotos da vistoria.
    • Funcionamento offline completo com sincronismo robusto pós-conexão.
  • Indicadores Sugeridos pelo Analista:
    • Tempo médio de vistoria (Throughput): Redução de pelo menos 20% no tempo gasto em campo devido à dinamicidade do formulário.
    • Taxa de Retrabalho (Rework Rate): Queda nas vistorias reprovadas por falta de nitidez ou ausência de dados para menos de 2%.
    • Acurácia da Visão Computacional (CV Accuracy): Taxa de acerto superior a 80% no preenchimento automatizado de gabinetes e baterias a partir das fotos válidas.

11. Detalhamento de Levantamento de Inventário Mínimo Monitorado

O aplicativo de vistoria de campo deve ser parametrizado para guiar a coleta estruturada e a validação fotográfica dos 15 elementos de infraestrutura física, garantindo que o técnico realize o levantamento conforme os padrões exigidos:

Nota de Usabilidade: O fluxo de formulários do aplicativo é dinâmico. Um formulário para elementos filhos (ex: BATERIAS ou RETIFICADOR) só será exibido se o elemento pai (ex: ABRIGO ou FCC) for identificado e cadastrado previamente pelo vistoriador.

Elemento Campos a Coletar / Validar Regra de Coleta no Aplicativo Extração Inteligente (Visão Computacional)
Dados Site ID_UFSIGLA, ID_MASTER, ID_TIPO_SITE Preenchido automaticamente via GPS (geofencing) e integração com a OS. O tipo de site (Greenfield, Rooftop, etc.) deve ser validado visualmente. N/A (Validação cadastral via coordenadas).
Entrada Energia PADRAO, CLASSIFICACAO_TENSAO, TENSAO, CAPACIDADE_DISJUNTOR, MODELO/FABRICANTE DISJUNTOR, GRADIL, BITOLA_CABO, SITUACAO Campos de seleção (Ex: Monofásico/Bifásico/Trifásico; Baixa/Média tensão; 127/220/380V). Seleção de situação: Planejado/Implantado/Desativado. Identificação automática de bitola de cabos e padrão de entrada a partir da imagem do padrão de energia.
Medidor CODIGO, UNIDADE_CONSUMIDORA, CONCESSIONARIA (CNPJ), SITUACAO Leitura obrigatória do código do medidor e digitação do número da Unidade Consumidora (UC). Vínculo obrigatório à Entrada de Energia correspondente. Extração automática do código do medidor e dados textuais (OCR) a partir da foto do visor/placa do medidor.
QDCA PADRAO, DISJ_GERAL_CAPACIDADE, DISJ_GERAL_MODELO, DISJ_GERAL_FABRICANTE, GRADIL, BITOLA_CABO, TIPO_CABO, TOMADA_GMG, SITUACAO Checklist do quadro elétrico. Pergunta obrigatória se possui tomada para GMG (Grupo Motor Gerador) com validação visual (foto). Detecção de fabricante e modelo do disjuntor geral e presença de tomada GMG via reconhecimento de padrões na foto do interior do QDCA.
Abrigo TIPO, SITUACAO, BITOLA_CABO, TIPO_CABO, TOMADA_GMG, DETENTORA, FABRICANTE, MODELO, TIPO_CLIMATIZACAO, GRADIL, CADEADO_BLUETOOTH, STEP_CONTRATADO, QTE_US_CAPACIDADE Identificação do tipo de abrigo (Gabinete, Alvenaria, Container, Rack). Cadastro da capacidade de US (Unidades de Rack). As métricas de US livres, ocupadas e reservadas são calculadas automaticamente. Classificação visual automática do tipo de abrigo (gabinete vs container/alvenaria) e identificação do modelo do cadeado Bluetooth.
FCC FABRICANTE, MODELO, CAPACIDADE_TOTAL, SITUACAO, QTE_CAPACIDADE_RETIFICADOR, DETENTORA Coleta dos dados da Fonte de Corrente Contínua. Requer vinculação ao Abrigo pai. OCR e leitura de chapa de identificação do fabricante/modelo da FCC e contagem física de retificadores visíveis na foto.
Retificador MODELO, FABRICANTE, CAPACIDADE, SITUACAO, DETENTORA Cadastro individual de cada módulo retificador acoplado ao bastidor da FCC correspondente. Reconhecimento do modelo e capacidade do retificador a partir do código do módulo na imagem do bastidor CC.
Baterias SITUACAO, FABRICANTE, MODELO, CAPACIDADE_AH, TENSAO_V, ANO_FABRICACAO, DETENTORA Mapeamento do banco de baterias. OBRIGATÓRIA a digitação de capacidade (Ah) e ano de fabricação. Requer vinculação a um Abrigo pai. Leitura automática dos dados gravados no rótulo da bateria (Ah, tensão, data) via OCR especializado em baterias industriais.
GMG MODELO_ALTERNADOR, TENSAO_OPERACAO, TIPO_LIGACAO, GRADIL, USCA, TIPO_COMBUSTIVEL, CAPACIDADE_KVA, SITUACAO, DETENTORA Checklist específico para geradores. Mapeamento de tipo de ligação e combustível. Requer registro fotográfico do painel de controle (USCA). Extração de dados do painel e visor digital do gerador (status, KVA, tensões) a partir da imagem da USCA.
Estrutura Vertical TIPO_DE_ESTRUTURA, ALTURA, CAPACIDADE_AEV, DETENTORA Identificação do tipo (Poste, Torre, Mastro, etc.) e altura nominal em metros. Classificação visual automática do tipo de estrutura física na foto panorâmica do site.
Suporte EV CARGA_KG, COMPRIMENTO, SITUACAO Especificação física de cada suporte metálico fixado na torre/estrutura vertical. N/A (Coleta visual orientada).
RRU MODELO, FABRICANTE, SITUACAO Mapeamento das Unidades de Rádio Remotas fixadas nos suportes da estrutura vertical. Detecção de modelo e fabricante a partir da etiqueta traseira/lateral da RRU em fotos com zoom.
Antena MODELO, FABRICANTE, SITUACAO Cadastro e contagem das antenas de RF instaladas em cada suporte da estrutura vertical. Classificação visual de modelos aproximados de antena a partir das fotos de campo.
Equipamento MODELO, FABRICANTE, CAPACIDADE_PLACAS Cadastro de chassis/sub-bastidores de equipamentos ativos no abrigo. As métricas de placas ocupadas/livres são calculadas dinamicamente. Reconhecimento de fabricante e modelo do chassi ativo a partir da foto frontal do rack de equipamentos.
Placa MODELO, FABRICANTE, SITUACAO, QTE_US_QUE_OCUPA, POSICOES_PLACAS Mapeamento individual de placas instaladas nos slots de cada equipamento pai cadastrado. Identificação de códigos e modelos de placa instalados em cada slot do bastidor ativo via OCR.

PoC 2: Levantamento de Informações de Documentação Legada (Documentação Legada)

1. Identificação da PoC

  • Nome Provisório: Ingestão Inteligente de Documentação Legada (Extração documental via IA)
  • Objetivo Principal Percebido: Validar uma solução tecnológica baseada em inteligência artificial (LLMs/Visão Computacional) capaz de interpretar e extrair especificações técnicas de documentos históricos não estruturados (PDFs, relatórios técnicos, imagens, projetos preliminares - PPIs, projetos definitivos - PDIs, "arrooms") estruturando-os em um banco de dados unificado de inventário.

2. Resumo Executivo

A finalidade desta PoC é testar a eficiência de soluções baseadas em Large Language Models (LLMs) e OCR para consolidar informações de inventário a partir de um repositório histórico de documentos de engenharia da Telefônica. Atualmente, a empresa possui milhares de documentos técnicos não estruturados em formatos variados. A equipe de engenharia precisa minerar esses arquivos manualmente para cadastrar a infraestrutura instalada. Com a PoC, pretende-se carregar uma amostragem destes documentos em um ambiente controlado, avaliar a capacidade dos algoritmos de extrair atributos de gabinetes, baterias, cabos e estruturas físicas, mapear a rastreabilidade da informação até a página do documento de origem e classificar os status dos ativos (ex: planejado vs. instalado) eliminando duplicidades provenientes de revisões documentais de uma mesma intervenção.

3. Problema de Negócio

A Telefônica possui um vasto legado documental não estruturado contendo dados fundamentais da infraestrutura de seus sites. Informações críticas (bitola e material de cabos, fabricante de gabinetes, números de série e capacidade de baterias) estão "escondidas" em arquivos PDF, relatórios escaneados e fotos de projetos. O esforço humano para ler, interpretar e transcrever esses dados é inviável em termos de prazo e custo. Além disso, a coexistência de múltiplos projetos de uma mesma obra (como o PPI, que prevê a instalação, e o PDI, que consolida o que foi executado) gera redundância e duplicidade nos levantamentos, fazendo com que sistemas de inventário registrem equipamentos fantasmas ou omitam itens realmente instalados.

4. Objetivo da PoC

  • O que se quer provar/validar:
    • A viabilidade técnica de utilizar inteligência artificial para minerar arquivos PDF textuais/escaneados e extrair atributos de infraestrutura de telecom com alta fidelidade.
    • A capacidade do sistema em mapear o status de planejamento de um elemento (planejado vs. implantado).
    • A eficácia do algoritmo na desduplicação de ativos quando um site possui documentos preliminares (PPI) e definitivos (PDI) da mesma obra.
    • A flexibilidade de integração da ferramenta a LLMs internos da Telefônica (on-premise).
  • Hipóteses de Valor: A extração por IA reduz em mais de 80% o custo e o tempo de cadastro de inventário legado comparado ao processo de mineração manual e garante a rastreabilidade direta do banco para o documento fonte.
  • Critérios Gerais de Sucesso: Acurácia de extração aferida por amostragem humana, identificação precisa de lacunas documentais e não duplicação de registros de uma mesma intervenção de engenharia.

5. Escopo Inicial da PoC

  • Dentro do Escopo:
    • Ingestão e leitura de múltiplos tipos de documentos históricos (PDFs textuais, PDFs escaneados como imagem, fotos de diagramas, relatórios em Excel, PPIs, PDIs e projetos do Arroom).
    • Extração de atributos técnicos prioritários detalhados no Excel de referência (ex: tipo de gabinete, modelo de alimentação, fabricante, bitola de cabo, tipo de cabo - cobre/alumínio, ligação em GMG, etc.).
    • Classificação automática dos documentos para entender a natureza das informações (se são documentos de planejamento ou execução física).
    • Atribuição de status do ativo técnico: "previsto/planejado" (extraído de PPIs/projetos) ou "instalado/executado" (confirmado por PDIs/As-Built).
    • Mecanismo de desduplicação de equipamentos de uma mesma obra/intervenção física representada em múltiplos documentos.
    • Rastreabilidade completa de ponta a ponta (manter o link/caminho indicando de qual arquivo e página a informação foi extraída).
    • Identificação de lacunas de dados (gerar alertas de ausência de informações para campos obrigatórios do modelo).
    • Suporte a instalação on-premise integrada à nuvem Telefônica.
    • Compatibilidade com modelos LLM customizados fornecidos pela Telefônica (arquitetura plugável).
  • Fora do Escopo:
    • Comparação em tempo real do planejado em projeto histórico versus o executado em campo atualmente (a PoC se limitará a consolidar a informação estruturada unificada dos documentos).
    • Criação de fluxos de aprovação ou reprovação documental manual nesta etapa de testes.
    • Atualização automatizada em lote de bancos de dados de produção de inventários já existentes.
  • Premissas:
    • A Telefônica fornecerá um lote de documentos (massa de testes heterogênea) e o Excel de modelo de dados.
    • Caso a empresa desenvolvedora não possua conhecimento específico da estrutura documental de telecom da Vivo, haverá sessões de mentoria e transferência de conhecimento sobre a terminologia.
  • Restrições:
    • Os documentos contêm dados confidenciais de rede; a solução da PoC não deve enviar dados para APIs de LLM externas não autorizadas (exigência on-premise ou uso de LLM Vivo).

6. Requisitos Funcionais

ID Requisito Funcional Descrição Detalhada Prioridade Observações
RF-DOC-01 Processamento Multiformato A solução deve ser capaz de ingerir e realizar a leitura de arquivos em formato PDF (textual e escaneado), planilhas Excel e arquivos de imagem. Alta Exige aplicação de OCR robusto para documentos antigos.
RF-DOC-02 Classificação Documental Classificar automaticamente a tipologia dos arquivos processados, distinguindo PPIs (Projeto Preliminar), PDIs (Projeto Definitivo), Arroom e projetos de engenharia. Alta Permite aplicar pesos diferentes para a extração do status.
RF-DOC-03 Extração de Atributos de Infra Extrair os dados técnicos de elementos de infraestrutura (gabinetes, baterias, cabos, protecionais, suportes e estruturas metálicas) conforme planilha de atributos. Alta Mapeamento baseado no gabarito Excel fornecido.
RF-DOC-04 Status Previsto vs. Instalado Definir o status do equipamento no inventário da plataforma com base na fonte documental (PPI = Planejado; PDI = Instalado). Alta Permite saber a maturidade da informação histórica do site.
RF-DOC-05 Desduplicação de Intervenção Consolidar registros que representem a mesma intervenção física de engenharia no site, evitando gerar múltiplos cadastros de um mesmo item físico. Alta Regra crucial para manter o inventário livre de dados inflados.
RF-DOC-06 Rastreabilidade do Documento Fonte Vincular o campo de dados extraído diretamente ao arquivo original, indicando o nome do documento e a página de origem da evidência. Alta Facilita a auditoria humana nos casos de inconsistências.
RF-DOC-07 Mapeamento de Gaps Gerar relatórios de lacunas indicando quais campos exigidos no modelo de dados não foram localizados nos documentos analisados. Alta Norteia o plano de vistorias físicas futuras para sanar as lacunas.
RF-DOC-08 Integração de LLM Pluggable A arquitetura de extração deve suportar a integração dinâmica com diferentes modelos de LLM, com prioridade para LLM interno fornecido pela Vivo. Alta Evita o acoplamento a um único fornecedor de modelo de linguagem.
RF-DOC-09 Exportação Relacional Formatar e estruturar os dados extraídos em uma base de dados relacional voltada à integração de inventário. Alta Base fundamental para a migração ao sistema definitivo.

7. Requisitos Não Funcionais

ID Requisito Não Funcional Categoria Prioridade
RNF-DOC-01 Instalação On-Premise Segurança Alta
RNF-DOC-02 Acurácia de Extração (Precisão) Confiabilidade Alta
RNF-DOC-03 Mentoria de Negócio Operação Média

8. Dados, Integrações e Dependências

  • Sistemas Citados: Cloud corporativo da Telefônica, LLM interna da Telefônica.
  • Fontes de Dados: Repositório de teste com documentos em PDF (projetos de instalação), arquivos Excel e imagens/fotos associadas; planilha Excel padrão com a taxonomia de campos a extrair.
  • Integrações Necessárias: Conexão/API com o ambiente de LLM corporativo da Telefônica para processamento de linguagem natural.
  • Dependências: Fornecimento tempestivo do lote documental sanitizado pela engenharia da Telefônica; liberação de credenciais de acesso às APIs do modelo LLM interno Vivo.

9. Fluxo de Processo Atual e Fluxo Desejado

  • Processo Atual ("As-Is"): O cadastro histórico é feito sob demanda. Quando uma área precisa de informações de um site (ex: altura de suporte ou tipo de cabo), um funcionário localiza os arquivos PPI ou PDI em pastas compartilhadas. Abre o arquivo, faz uma leitura visual de dezenas de páginas de relatórios de engenharia e copia os dados manualmente para controles locais. Se houver divergência de arquivos de datas diferentes, o analista decide de forma intuitiva, resultando em retrabalho, alto tempo de pesquisa e registros de inventário desatualizados ou incompletos.
  • Processo Desejado ("To-Be"): Os documentos são inseridos no motor de ingestão. A solução de IA classifica o tipo do documento (PPI, PDI, etc.) e aplica regras de OCR e extração baseadas em LLM local. A IA preenche a tabela padrão de inventário, relacionando o equipamento ao site. O algoritmo correlaciona PPI e PDI para determinar se o item é planejado ou já instalado e elimina a duplicidade caso pertençam à mesma obra. Se algum atributo do modelo não for localizado, ele gera um alerta de lacuna. O dado é gravado com o link da página do arquivo de origem para conferências futuras.

10. Critérios de Sucesso da PoC

  • Métricas Mencionadas na Reunião:
    • Extração correta dos campos e estruturação relacional final utilizável.
    • Detecção precisa de ausência de informações (lacunas).
    • Diferenciação correta de status "previsto" e "instalado".
    • Rastreabilidade ponta a ponta vinculando dados extraídos ao documento fonte.
  • Indicadores Sugeridos pelo Analista:
    • Acurácia da Extração (Accuracy Score): Aderência mínima de 85% dos dados extraídos pela IA frente a uma amostragem auditada de 100 documentos extraídos manualmente por especialistas da Telefônica.
    • Taxa de Falsos Positivos de Duplicidade: Menos de 5% de itens duplicados erroneamente (por exemplo, cadastrar 2 gabinetes em vez de consolidar o planejado vs executado da mesma obra).
    • Tempo de Processamento por Documento: Tempo médio inferior a 30 segundos por documento processado (considerando arquivos de média complexidade com até 50 páginas).

11. Detalhamento de Levantamento de Inventário Mínimo Monitorado

O motor de ingestão e processamento de documentação legada (PoC 2) deve ser configurado com heurísticas de OCR e processamento de linguagem natural (LLM) para identificar e minerar atributos específicos dos 15 elementos de infraestrutura física, aplicando regras automatizadas de governança:

Nota de Rastreabilidade: Cada campo extraído deve possuir metadados contendo o nome do arquivo de origem e o número da página de onde a informação foi extraída (ex: "As-Built_EstacaoX.pdf" — Pág. 14), permitindo auditoria humana instantânea.

Elemento Estratégia de Mineração (OCR / LLM) Mapeamento de Status (PPI vs PDI) Regras de Desduplicação
Dados Site Extração dos cabeçalhos dos documentos e carimbos de projetos (UFSigla, IDMaster e tipo de site). Vínculo cadastral principal do site. Unificação baseada na chave primária do IDMaster do site.
Entrada Energia Varredura de projetos elétricos e memoriais descritivos para identificar o padrão (monofásico/bifásico/trifásico), disjuntores e bitolas de cabo. Status Planejado se extraído de PPI; status Implantado se extraído de PDI ou termo de aceite da concessionária. Unifica os dados de fornecimento de energia mantendo o registro da última atualização documental.
Medidor Pesquisa de faturas históricas de energia anexadas, cadastros da concessionária e contratos de fornecimento. Status Implantado no caso de contas ativas ou termos de ligação. Cruzamento pelo código do medidor ou número da Unidade Consumidora (UC) para eliminar cadastros duplicados.
QDCA Interpretação de diagramas unifilares e listas de carga do quadro de corrente alternada. Status Planejado (PPI) ou Implantado (PDI / As-Built). Gera um registro único do quadro principal, relacionando-o à Entrada de Energia pai correspondente.
Abrigo Leitura de plantas baixas de arquitetura e projetos de engenharia civil para extrair o tipo de abrigo (gabinete, container, rack) e capacidade de US. Mapeamento do status da estrutura física (normalmente Implantado). Desduplica abrigos comparando as posições físicas indicadas nos diagramas gerais do site.
FCC Extração a partir de diagramas elétricos de sistemas de corrente contínua e listas de materiais da obra. Status Planejado (PPI) ou Implantado (PDI). Consolidação pelo número de série ou fabricante/modelo do bastidor CC quando descritos no projeto definitivo.
Retificador Leitura dos módulos de retificação declarados nas listas de peças de reposição e diagramas de potência. Status Planejado (PPI) ou Implantado (PDI). Vincula os módulos instalados à FCC pai, consolidando a capacidade nominal total.
Baterias Extração de dados a partir dos testes de autonomia (laudos de baterias) e especificações técnicas de engenharia. Status Planejado (PPI) ou Implantado (PDI / Relatório de Teste de Carga). Agrupamento por banco de baterias no abrigo, correlacionando fabricante e capacidade em Ah para evitar duplicidade de elementos.
GMG Mineração de fichas de ensaio de geradores, laudos de entrega e diagramas de interligação do GMG. Status Planejado (PPI) ou Implantado (PDI / Laudo de Aceite de Start). Gera registro único para o gerador do site, unificando capacidade KVA e combustível.
Estrutura Vertical Interpretação de projetos mecânicos e fundações (torre, poste, mastro) com respectiva altura e carga AEV. Status do ativo atrelado ao projeto definitivo de engenharia. Unificação baseada na geolocalização e altura nominal da torre principal do site.
Suporte EV Extração a partir de projetos de fixação de antenas (detalhes de fabricação metálica). Status Planejado (PPI) ou Implantado (PDI). Consolidação dos suportes vinculados à respectiva Estrutura Vertical.
RRU Leitura de diagramas de rádio (RF) e mapas de interligação de portas. Status Planejado (PPI) ou Implantado (PDI). Eliminação de duplicidades por meio da correlação de tecnologia, fabricante, modelo e suporte associado.
Antena Extração de tabelas de RF (ganho, azimute, tilt, modelo da antena). Status Planejado (PPI) ou Implantado (PDI). Desduplica as antenas de RF cruzando as informações de azimute e altura nos diagramas de transmissão.
Equipamento Leitura de diagramas lógicos de rede de dados e inventários lógicos do site. Status Planejado (PPI) ou Implantado (PDI). Unificação baseada no modelo de chassi e rack físico onde o elemento está instalado.
Placa Varredura de relatórios de comissionamento de equipamentos e listas de placas. Status Planejado (PPI) ou Implantado (PDI). Vincula as placas aos slots físicos do Equipamento pai correspondente, removendo duplicados se houver relatórios de datas diferentes (mantendo a mais recente).

PoC 3: Inventário de Infraestrutura de Telecom (Inventário Infra)

1. Identificação da PoC

  • Nome Provisório: Inventário de Infraestrutura de Telecom (Plataforma Escalável e Robusta)
  • Objetivo Principal Percebido: Definir e demonstrar a estrutura mínima e relacional de um banco de dados de inventário físico robusto e escalável capaz de representar a infraestrutura de sites em uma hierarquia em árvore (Site -> Abrigo -> Gabinete -> Fonte -> Componentes -> Placas), oferecendo total autonomia para o usuário criar novas classes de equipamentos, cadastrar modelos e gerenciar o ciclo de vida dos ativos (planejado vs. implantado/desativado) via Ordens de Serviço (OS), com APIs robustas de leitura/escrita e carga massiva resiliente.

2. Resumo Executivo

Esta PoC visa validar uma plataforma de inventário físico escalável e robusta de infraestrutura de telecom que sirva como a solução oficial e definitiva para a gestão da Telefônica. A principal dor está na falta de padronização, no isolamento dos dados em planilhas desestruturadas e na rigidez dos sistemas de TI que impedem o usuário de negócios de cadastrar novos modelos ou atributos sem intervenção técnica. A solução demonstrará a capacidade de modelar dados dinamicamente, representar visualmente o site em uma árvore hierárquica lógica de componentes (pai-filho), permitir importação massiva (planilhas) com tratamento tolerante a falhas (gravação de linhas corretas e relatório minucioso de erros por linha/coluna com retorno de IDs), e gerenciar o ciclo de vida dos ativos físicos integrado aos workflows de Ordens de Serviço (OS), possibilitando desativações e migrações de componentes órfãos.

3. Problema de Negócio

Atualmente, a Telefônica carece de um repositório central estruturado para inventariar a infraestrutura técnica de seus sites. Os dados encontram-se espalhados em planilhas Excel informais de fornecedores e de áreas operacionais. Quando novos equipamentos ou campos técnicos surgem, a equipe de engenharia não tem autonomia para cadastrá-los, dependendo de processos lentos de desenvolvimento de TI para alterar o esquema do banco. Outro gargalo crítico ocorre nas importações de dados em lote: se um arquivo de importação contiver um único erro em centenas de linhas, o sistema aborta toda a operação, forçando os usuários a realizarem pesquisas manuais estressantes no arquivo original para localizar a célula incorreta. Por fim, não há consistência relacional para rastrear o ciclo de vida de ativos que passam por modificações em campo via Ordens de Serviço (OS).

4. Objetivo da PoC

  • O que se quer provar/validar:
    • A flexibilidade do banco de dados em permitir ao usuário administrativo criar dinamicamente novas classes de equipamentos, adicionar atributos e configurar validações (ex: formato de data, numérico, combos) sem alterar o código-fonte da aplicação.
    • A visualização gráfica e lógica da infraestrutura do site baseada em uma árvore hierárquica relacional (Site -> Gabinete -> Fonte -> Baterias, etc.).
    • A resiliência de cargas massivas parciais (gravar registros corretos, reportar linhas erradas e exportar os IDs dos itens salvos).
    • A integridade referencial do inventário (bloquear registros órfãos, como uma bateria sem vínculo a um gabinete pai).
    • O ciclo de vida dos dados integrado ao fluxo planejado vs. implantado/desativado de Ordens de Serviço (OS).
  • Hipóteses de Valor: A modelagem dinâmica operada diretamente pelo usuário elimina em 100% a dependência da TI para novos cadastros e a carga massiva com relatório de erros específico reduz em até 70% o tempo gasto na correção de planilhas de carga.
  • Critérios Gerais de Sucesso: Árvore do site totalmente legível, importação em lote resiliente bem-sucedida, APIs de integração testadas e fluxo de OS funcional.

5. Escopo Inicial da PoC

  • Dentro do Escopo:
    • Banco de dados relacional flexível baseado no identificador único centralizado da Telefônica (UFSigla / IDMaster).
    • Visualização em árvore hierárquica de componentes e relacionamentos internos de cada site (Site -> Abrigo -> Gabinete -> Fonte -> Retificadores/Baterias -> Racks -> Posições/Placas).
    • Interface de usuário (UI) para modelagem e criação dinâmica de novas classes de itens e campos customizados (tipos de dados: data, numérico, texto, seleção única, múltipla seleção).
    • Cadastro de modelos prontos de equipamentos parametrizados (ex: Gabinete Delta X com campos pré-definidos).
    • Carga massiva de dados por meio de planilhas (Excel/CSV) tolerante a erros (grava o que está correto e lista o que falhou).
    • Relatório detalhado de falhas de importação especificando o número da linha, a coluna do campo e a mensagem do erro correspondente.
    • Exportação de IDs gerados no banco de dados tanto nos logs de sucesso quanto nos relatórios de erros para retroalimentação.
    • Validação rigorosa de tipos de dados nos campos (bloquear entrada alfa em campos numéricos ou textos inválidos em campos de data).
    • Validação estrutural de paternidade (impedir inserção de elementos filhos sem o elemento pai cadastrado).
    • APIs REST integradas para leitura e escrita (permitindo integração com dados de outras PoCs).
    • Fluxo de ciclo de vida de ativos via Ordem de Serviço (OS): status "Planejado/Previsto", ajustes de engenharia e consolidação para "Ativo/Implantado" ou "Desativado/Inutilizado".
    • Fluxo de migração de componentes filhos ao substituir/desativar um equipamento pai.
  • Fora do Escopo:
    • Substituição imediata dos sistemas legados oficiais de inventário corporativo da Telefônica.
    • Visualizações complexas em mapas georreferenciados (GIS) avançados de rede (foco em hierarquia técnica do site).
    • Lógica interna para leitura de fotos e documentos (função exclusiva das PoCs 1 e 2).
  • Premissas:
    • A amarração lógica dos sites será feita com base no código UFSigla / IDMaster existente na Vivo.
    • O usuário final será o responsável por definir as classes e atributos iniciais baseando-se no arquivo Excel de referência fornecido.
  • Restrições:
    • A PoC deve aceitar conexões via APIs REST padrão para viabilizar a injeção automatizada de dados externos.
    • Nenhum elemento filho pode ser inserido no sistema sem que seu elemento pai correspondente esteja fisicamente registrado no inventário.

6. Requisitos Funcionais

ID Requisito Funcional Descrição Detalhada Prioridade Observações
RF-INV-01 Modelagem Dinâmica Interface para o usuário administrador criar, editar e excluir classes de equipamentos e respectivos campos de atributos sem programação. Alta Oferece a autonomia exigida pela engenharia de infra.
RF-INV-02 Configuração de Atributos Possibilidade de escolher o tipo de dado do campo criado (texto, data, numérico, seleção única e múltipla seleção) e suas validações. Alta Garante a padronização e higienização dos dados na entrada.
RF-INV-03 Árvore Hierárquica de Componentes Exibir visualmente o relacionamento de componentes de um site em estrutura de árvore pai-filho. Alta Essencial para compreender a topologia e ocupação do site.
RF-INV-04 Carga Massiva de Dados Permitir a importação em lote de dados de infraestrutura via planilhas formatadas (Excel/CSV). Alta Utilizada para migrações iniciais de grandes volumes de sites.
RF-INV-05 APIs REST de Leitura/Escrita Disponibilizar endpoints REST para operações completas de consulta, inserção e atualização de inventário. Alta Permite que o App Vistoria e o motor de Documentos atualizem o banco.
RF-INV-06 Importação Parcial Resiliente Gravar os registros sem erros durante cargas massivas, ignorando apenas as linhas incorretas. Alta Requisito chave para eficiência e usabilidade operacional.
RF-INV-07 Relatório de Erros Detalhado Exportar relatório de inconsistências de carga especificando a linha, a coluna do campo e a mensagem do erro correspondente. Alta Agiliza a identificação e correção de dados corrompidos.
RF-INV-08 Logs com Retorno de IDs Retornar na lista de logs/erros os IDs exclusivos gerados no banco de dados para os itens cadastrados com sucesso. Alta Permite correções incrementais sem duplicar o cadastro principal.
RF-INV-09 Validação de Tipos de Dados Bloquear a inserção de dados que descumpram os tipos configurados (ex: rejeitar letras em campos numéricos ou formatos de data inválidos). Alta Garante a qualidade histórica dos dados no banco relacional.
RF-INV-10 Validação de Paternidade Impedir a criação de registros filhos se o identificador do elemento pai correspondente não estiver cadastrado no inventário. Alta Evita a proliferação de ativos órfãos e dados inconsistentes.
RF-INV-11 Fluxo de OS (Planejado vs. Ativo) Permitir pré-cadastrar equipamentos com status "Planejado" vinculados a uma OS, permitindo atualizações e ativação ("Ativo") na conclusão do workflow. Alta Garante o controle do inventário futuro durante o rollout de engenharia.
RF-INV-12 Migração e Desativação de Componentes Possibilitar a desativação de um equipamento pai (ex: gabinete antigo) e migração de seus componentes filhos para um novo pai (ex: gabinete novo) mantendo histórico. Média Gerenciamento de ciclo de vida e substituição de hardware técnico.

7. Requisitos Não Funcionais

ID Requisito Não Funcional Categoria Prioridade
RNF-INV-01 Autonomia de Interface Usabilidade Alta
RNF-INV-02 Consistência e Integridade de Relacionamentos Segurança Alta
RNF-INV-03 Performance de API e Carga Desempenho Média

8. Dados, Integrações e Dependências

  • Sistemas Citados: Workflow de Ordens de Serviço (OS), banco de dados relacional robusto e escalável de inventário.
  • Fontes de Dados: Identificador único dos sites (UFSigla / IDMaster); planilha Excel contendo o gabarito das entidades e atributos técnicos de infraestrutura.
  • Integrações Necessárias: APIs de recepção de dados estruturados gerados pelas PoCs de Vistoria de Campo (App Vistoria) e Ingestão de Documentação Legada, além do sinal de conclusão do sistema de OS para transição de status dos equipamentos (planejado para instalado).
  • Dependências: Alinhamento e fornecimento prévio da base atualizada de identificadores de site (UFSigla / IDMaster) pela Telefônica.

9. Fluxo de Processo Atual e Fluxo Desejado

  • Processo Atual ("As-Is"): Inexistência de um banco de dados relacional unificado para inventário físico de infraestrutura de telecomunicações. Os dados técnicos são controlados em planilhas Excel soltas mantidas por diferentes áreas, sem validação sistêmica de tipo de dados ou relacionamento hierárquico. Ao realizar importações em lote, qualquer erro na planilha trava todo o processamento. Não existe controle de ciclo de vida (status planejado vs. instalado) atrelado à evolução das obras de engenharia (OS).
  • Processo Desejado ("To-Be"): Implementação de um banco de dados relacional robusto, escalável e centralizado, com potencial para se tornar o inventário oficial de infraestrutura. O usuário administrador cria as classes de equipamentos e campos customizados na UI de forma autônoma. O inventário exibe a estrutura física do site em árvore relacional. A importação em lote é resiliente, salvando linhas válidas e gerando relatórios de erro por linha/coluna com o retorno de IDs de banco. Novas obras entram no inventário via OS no status "Planejado", e passam a "Ativo" de forma automatizada no momento da entrega e aceitação física, desativando os itens antigos e migrando componentes associados.

10. Critérios de Sucesso da PoC

  • Métricas Mencionadas na Reunião:
    • Exibição correta da árvore hierárquica do site.
    • Suporte completo à carga massiva (Excel) e chamadas API de leitura e escrita.
    • Suporte à modelagem e parametrização de novos itens diretamente pelo usuário.
    • Carga em lote resiliente (gravação parcial de corretos com relatório de erros e IDs).
    • Controle de ciclo de vida de ativos via Ordem de Serviço (status previsto, conclusão de obra e ativação).
  • Indicadores Sugeridos pelo Analista:
    • Taxa de Rejeição de Carga (Batch Import Efficiency): Tempo de resolução de erros de planilha reduzido em pelo menos 50% devido ao detalhamento de linha/coluna nos relatórios de erros.
    • Autonomia do Usuário (Time to Market de Novas Classes): Tempo para cadastrar e liberar uma nova classe de equipamento no sistema de inventário reduzido de semanas (processo com IT/DBA) para menos de 10 minutos (executado pelo usuário via interface gráfica).
    • Acurácia de Paternidade (Relational Accuracy): 100% de consistência nas chaves estrangeiras, com zero registros órfãos inseridos no banco de dados.

11. Detalhamento de Levantamento de Inventário Mínimo Monitorado

O Banco de Dados Relacional da plataforma de inventário (PoC 3), concebido para ser escalável e robusto a fim de consolidar-se como o inventário oficial de infraestrutura da empresa, e seu respectivo painel administrativo devem ser projetados para modelar e gerenciar rigidamente os 15 elementos de inventário físico, aplicando validações transacionais:

Nota de Governança Elástica: A plataforma fornece autonomia completa para o administrador estender essa base de dados, adicionando novos atributos ou registrando modelos parametrizados (ex: "Bateria Heliar 150Ah" contendo campos pré-preenchidos), sem alteração de banco de dados ou código-fonte.

11.1 Árvore de Componentes e Restrições de Paternidade

A estrutura de dados mantém a consistência da topologia física de telecomunicações do site. A exclusão ou desativação de um elemento pai exige a tomada de ação sobre os filhos (exclusão em cascata ou migração com histórico):

Nível da Árvore Elemento Relacionamento Pai (Chave Estrangeira) Regra de Paternidade / Validação Referencial
1 Dados Site Raiz (IDMaster) Chave primária indexadora de todo o site no inventário.
2 Entrada Energia Site (IDMaster) Vínculo direto com o site. Apenas uma Entrada de Energia principal por site.
3 Medidor Entrada Energia Depende de uma Entrada de Energia ativa. Bloqueada a inserção órfã.
3 QDCA Entrada Energia Depende de uma Entrada de Energia ativa. Bloqueada a inserção órfã.
2 Abrigo Site (IDMaster) Ponto de acoplamento físico para sistemas de energia CC, baterias e telecom.
3 FCC Abrigo Apenas inserido dentro de um Abrigo cadastrado. Representa a fonte retificadora central.
4 Retificador FCC Módulos de retificação. Bloqueados se a FCC correspondente for excluída.
3 Baterias Abrigo Baterias de backup físico. Devem obrigatoriamente referenciar um Abrigo pai.
2 GMG Site (IDMaster) Grupo Motor Gerador atrelado ao site, com conexões elétricas opcionais ao QDCA.
2 Estrutura Vertical Site (IDMaster) Estrutura de suporte físico. Vínculo georreferenciado direto ao site.
3 Suporte EV Estrutura Vertical Suporte de fixação de rádio/antena. Exige vínculo com a Estrutura Vertical pai.
4 RRU Suporte EV Equipamento de rádio. Vinculado a um Suporte EV instalado na torre.
4 Antena Suporte EV Antena de transmissão. Vinculada a um Suporte EV instalado na torre.
3 Equipamento Abrigo Sub-bastidores/chassis ativos instalados em racks dentro do Abrigo.
4 Placa Equipamento Placas inseridas em slots específicos. Bloqueadas sem o Equipamento pai correspondente.

11.2 Resiliência de Carga Massiva e Logs de Importação

O processador de importação de planilhas Excel da PoC 3 analisa cada célula e garante a resiliência operacional:

  • Gravação Parcial: Se um arquivo contiver 500 linhas de componentes de inventário e 5 apresentarem erros de digitação (ex: texto em capacidade de disjuntor ou data inválida), o sistema grava com sucesso os 495 registros corretos no banco.
  • Retorno de IDs: O log de sucesso e a exportação geram os IDs gerados automaticamente pelo banco de dados para os itens persistidos, facilitando vinculações futuras e atualizações incrementais.
  • Dossiê de Erros: O arquivo de logs de erro reporta de forma cirúrgica o número da linha, a coluna e a célula inválida, acelerando em 70% o processo de higienização do arquivo original pelo usuário operacional.

11.3 Gestão Transacional do Ciclo de Vida do Ativo

Os status de ciclo de vida definidos no Excel (PLANEJADO, IMPLANTADO, DESATIVADO, DESINSTALADO) são gerenciados pelas APIs vinculadas ao fluxo de Ordens de Serviço (OS):

Regra Crítica de Negócio: Novos ativos ingeridos via PPI ou projetos entram no banco como Planejado. O gatilho de transição para Implantado ocorre exclusivamente mediante a chamada de API de encerramento da OS correspondente. Itens desativados que possuem componentes filhos disparam fluxos automáticos de migração de componentes órfãos para o novo item pai ou de alteração em cascata de status para desinstalado.