Pular para conteúdo

C3 — Ícaro / SGP (medição de pavimentos)

Zoom no Container Staging Ícaro (extractor do hub no C2) e no Projetor SGP (constrói o Read Model SGP em BANCO ARTESP).

AutoDesk Build ainda não foi modelado nesta versão — quando entrar (após Discovery 08), pode passar a alimentar o mesmo Projetor SGP com dados BIM.

Estado: hipotético. Ficha de Discovery ainda não iniciada — ver tpf-motiva/docs/0-discovery/02-icaro.md no repositório. Componentes refletem entendimento atual a partir de Fornecedores §3.2 e do produto/blueprint-solucao.md. Marcadores de confiança nas afirmações.

Contexto rápido

  • Ferramenta: Ícaro
  • Vendor: a confirmar [?] (D6 do blueprint)
  • Sistema ARTESP: SGP (parte de medição de pavimentos) [B]
  • Onda: 1 — deadline jul/2026 (urgente)
  • Padrão arquitetural (C2): Pull-On-Prem ou Pull-SaaS — a confirmar (D5 do blueprint) [?]
  • C/P/B: Producer (provável) [B]
  • Hosted: a confirmar — pode ser SaaS ou On-Prem [?]

Diagrama

Componentes do Container Staging Ícaro

# Componente Tecnologia (hipótese) Responsabilidade
1 Extrator de medições Python ou .NET, executado pelo SINCRONIZADOR Pull de medições. Cadência depende de Ícaro ser SaaS (pode ter webhook) ou on-prem (provável pull periódico). Reprocessável via checkpoint. [?]
2 Normalizador (mínimo) Mesma stack Resolve geo-referenciamento (km início/fim → geometria linear) via lookup contra cadastro de eixos/trechos da Sorocabana. Sem regra de negócio — só normalização técnica. [B]
3 Publisher Staging Driver Oracle Upsert na tabela do schema ICARO em BANCO STAGE. Idempotente por id_segmento. Mantém histórico por data_medicao (não overwrite). [B]

Projetor SGP

Lê de BANCO STAGE.ICARO e (em onda futura, quando o Container Staging AutoDesk Build for criado) também de BANCO STAGE.AUTODESK. Combina os schemas e persiste o Read Model SGP unificado em BANCO ARTESP. É no Projetor que medição-de-campo e projetos-BIM se encontram para formar uma única visão de produto.

Aspecto Decisão atual
Tecnologia a definir — Python/.NET ou Oracle PL/SQL. [?]
Cadência dispara após batch consolidado de Staging Ícaro; combina com snapshot mais recente de AutoDesk (quando existir). [?]
Idempotência Read Model reescrito por campanha; reprocessar é seguro. [B]

Contrato de dados em Staging (entidade-chave: SegmentoPavimento — as-is)

Schema hipotético em BANCO STAGE.ICARO.medicoes_rawa confirmar.

Campo Tipo Origem Notas
id_segmento string composto: rodovia + km_ini + km_fim + sentido + faixa Chave única; idempotente
rodovia string cadastro Motiva SP-XXX, BR-XXX
km_inicio decimal Ícaro
km_fim decimal Ícaro
sentido enum Ícaro norte/sul/leste/oeste
faixa int Ícaro
data_medicao date Ícaro Data da campanha de campo
iri decimal Ícaro International Roughness Index
icp decimal Ícaro Índice de Condição do Pavimento
atr decimal Ícaro Afundamento de Trilha de Roda
trincas_pct decimal Ícaro % área com trincas
geometria linestring resolver no normalizador Útil para o Read Model

O Read Model SGP em BANCO ARTESP combina esses campos com projetos/BIM do AutoDesk (projetos_pavimento, RFIs, submittals) e adiciona derivados (condicao, recomendações, indicadores agregados) — a desenhar com Design Authority (D3 do blueprint).

Fronteira com AutoDesk Build (SGP — parte BIM)

SGP no cronograma aparece duas vezes:

Cronograma Ferramenta Onda C3
linha 2 Ícaro 1 (jul/2026) este documento
linha 13 AutoDesk Build 3 (set/2026) a fazer em onda futura

Na nova arquitetura, a divisão fica clara: cada ferramenta tem seu próprio Container Staging que grava no seu schema dedicado de BANCO STAGE; o Projetor SGP é o ponto único onde os dois mundos se combinam em uma única visão de produto. Não há sobreposição na Staging — sobreposição se resolve no Projetor.

Aspecto Ícaro (Staging) AutoDesk Build (Staging)
Foco Medição/levantamento de campo Projetos / documentação BIM dos pavimentos
Dado típico Índices (IRI, ICP, ATR, trincas) por trecho Modelos BIM, projetos executivos, RFIs, submittals
Schema STAGE ICARO.medicoes_raw (estado e histórico) AUTODESK.projetos_raw (metadados georreferenciados)
Periodicidade Campanhas periódicas Por projeto/obra

Se a entrevista revelar duplicação real de informação entre Ícaro e AutoDesk (não só perspectivas distintas da mesma realidade), revisar a fronteira no Projetor SGP antes de seguir.

Decisões pendentes

# Pergunta Confidence atual Onde resolver
D-I1 Vendor do Ícaro? (D6 blueprint) [?] §2.2 + cronograma original
D-I2 Hosting: SaaS ou on-prem? Define o padrão arquitetural (D5 blueprint) [?] §2.3
D-I3 Quais tipos de medição Ícaro registra (IRI, ATR, ICP, trincas, FWD)? [?] §2.1 e §2.6
D-I4 Como dados são geo-referenciados? Estaca, km, lat/long? [?] §2.6
D-I5 Periodicidade de levantamento (mensal? trimestral? anual?)? [?] §2.7
D-I6 Plug precisa do histórico ou só estado atual? (afeta forma do Read Model) [?] §2.6 + key user Motiva
D-I7 Divisão Ícaro vs AutoDesk Build em SGP — confirmar arquitetura da combinação no Projetor [A](é importante) [?](é resolvido) sessão conjunta com ambos os times

Decisões transversais aplicáveis: D3 (Read Model SGP), D5 (hosting Ícaro), D6 (vendor Ícaro), D12 (tecnologia SINCRONIZADOR) — ver Apêndice D do blueprint.

Riscos críticos

  • Onda 1, deadline jul/2026 — junto com KAPSCH no caminho crítico
  • Vendor desconhecido — sem owner identificado, Discovery não destrava
  • Sobreposição com AutoDesk Build no Read Model SGP — embora a Staging seja limpa (schemas separados), a forma de combinar no Projetor exige alinhamento entre os times. Recomenda-se sessão conjunta o quanto antes.
  • Hosting indefinido — afeta padrão (Pull-On-Prem vs Pull-SaaS) e por consequência InfoSec/Cyber

Referências

  • C2 (padrões de ingestão): c2-containers.md
  • Blueprint da solução: produto/blueprint-solucao.md (no repositório, fora deste site)
  • Ficha de Discovery: tpf-motiva/docs/0-discovery/02-icaro.md
  • Ficha relacionada (AutoDesk Build): tpf-motiva/docs/0-discovery/08-autodesk-build.md
  • Inventário §3.2: inventarios/fornecedores.md