Dados de Vendors e Projeções Necessárias¶
Página tracker que cruza vendors (do Inventário de Fornecedores) com projetores (da DSL docs/likec4/workspace.c4) e marca o que ainda falta descobrir para cada par.
Legenda de confiança (mesma convenção do _schema.md do tpf-motiva):
- [A] Alta — confirmado em entrevista ou documentação
- [M] Média — hipótese forte, falta confirmar
- [B] Baixa — palpite com pouca base
- [?] Pendente — sem informação
1. Projetores: estado atual¶
A DSL workspace.c4 nomeia hoje 5 projetores (4 nomeados + 1 placeholder). A realidade do cronograma implica ao menos ~12 projetores reais. A tabela abaixo lista todos — os nomeados e os implícitos a renomear.
| Projetor | Read Model produzido | Sistemas ARTESP atendidos | Status DSL C4 | Status dos dados |
|---|---|---|---|---|
projSgp |
Read Model SGP em BANCO ARTESP | SGP | nomeado | [M] parcial — divisão Ícaro vs AutoDesk Build em aberto |
projSisgis |
Read Model SISGIS | SISGIS | nomeado | [?] N/A no cronograma — esclarecer escopo |
projArcgis |
Read Model SCHEMA ARCGIS | (consumido pelo ArcGIS) | nomeado | [A] API ArcGIS REST bem conhecida |
projPlug |
Read Model SCHEMA PLUG | (consumido pelo Plug) | nomeado | [M] APIs a construir |
projKapsch |
Read Model KAPSCH (SISFREEFLOW) | SISFREEFLOW | não nomeado (em projOutros) |
[?] Onda 1 sem schema documentado |
projKcor |
Read Model KCOR | SISACIDENTES, SIS-SAU, SISEQP, SISPESMOV | não nomeado | [?] 4 sistemas, 1 vendor, 0 schema |
projKartado |
Read Model Kartado | SISOAES, SIGECON, SIR, SISATIVOS | não nomeado | [B] SaaS moderno mas sem docs confirmadas |
projAutodesk |
Read Model AutoDesk (BIM) | SISOBRAS, SGP (parte BIM), SISPROJ, SISATIVOS | não nomeado | [M] API rica (APS/Forge); produto exato de SISPROJ a confirmar |
projPortalFD |
Read Model Portal Faixa Domínio | SISDEMANDA | não nomeado | [?] tudo a confirmar |
projSat |
Read Model SAT | SISSAT | não nomeado | [B] provável on-prem, vendor a confirmar |
projConstrutivo |
Read Model Construtivo | SISQUALI | não nomeado | [?] sistema ainda não existe — co-projeto |
projMits |
(papel a definir em SIGECON) | SIGECON (parte) | não nomeado | [?] incógnita silenciosa — integra direto ou só via Kartado? |
Tarefa subsequente fora do escopo desta entrega: nomear formalmente os 8 projetores não-nomeados na DSL
workspace.c4, eliminando o placeholderprojOutrosà medida que cada um for definido.
2. Matriz vendor × projetor¶
Linhas = vendors; colunas = projetores. Célula = tipo de dado que flui (ou [?] se desconhecido). — significa que o vendor não alimenta aquele projetor.
| Vendor \ Projetor | projKapsch | projSgp | projKcor | projKartado | projAutodesk | projPortalFD | projSat | projConstrutivo | projMits |
|---|---|---|---|---|---|---|---|---|---|
| KAPSCH | passagens, cobrança, classe veicular [B] | — | — | — | — | — | — | — | — |
| Ícaro | — | medições IRI/ICP/ATR, histórico por trecho [M] | — | — | — | — | — | — | — |
| KCOR | — | — | acidentes, atendimento, frota, pesagem HS-Wim [?] | — | — | — | — | — | — |
| Kartado | — | — | — | OAEs, obras, inspeções, ativos rodoviários [B] | — | — | — | — | dados SIGECON [?] |
| MITS | — | — | — | — | — | — | — | — | papel exato [?] |
| AutoDesk | — | docs BIM SGP [M] | — | — | issues, modelos, RFIs, ativos BIM [M] | — | — | — | — |
| Portal Faixa Domínio | — | — | — | — | — | licenças, ocupações [?] | — | — | — |
| SAT | — | — | — | — | — | — | VDM, VHP, contagem, classificação [B] | — | — |
| Construtivo | — | — | — | — | — | — | — | laudos, ensaios, não-conformidades [?] | — |
| ArcGIS (fonte) | — | — | — | — | — | — | — | — | — |
| Plug (fonte) | — | — | — | — | — | — | — | — | — |
Observações sobre projetores de consumo (projArcgis, projPlug): estes projetores não consomem direto de vendor — consomem dos schemas de Staging já populados pelos outros vendors. Por isso não aparecem como colunas na matriz acima.
Esteio-ETT (SISRAD) bypass: marcado N/A no cronograma — consumido via API do DER, não passa pelo hub. Não tem projetor previsto.
3. Lacunas críticas, ordenadas por onda¶
Cada lacuna é uma pergunta de Discovery que precisa ser respondida antes que o projetor correspondente possa ser implementado.
Onda 1 — jul/2026 (~12 semanas restantes)¶
- KAPSCH → projKapsch — schema de eventos de passagem desconhecido; política LGPD para placa de veículo não definida (bloqueador); confirmar se exige VM intermediária. Ficha
01-kapsch.md. - Ícaro → projSgp — divisão de papel entre Ícaro (medição de campo?) e AutoDesk Build (projetos BIM?) no SGP não resolvida; vendor do Ícaro a confirmar; geo-referenciamento (estaca? km? lat/lng?). Ficha
02-icaro.md.
Onda 2 — ago/2026¶
- MITS papel em SIGECON — integra direto com o Plug ou só via Kartado? Owner e backend exato em aberto. Pode colapsar
projMitsemprojKartadose MITS for sub-componente. - Kartado → projKartado — 4 sistemas distintos (SISOAES, SIGECON, SIR, SISATIVOS) — são módulos do mesmo produto ou produtos separados? API documentada? Webhooks?
- Portal Faixa Domínio → projPortalFD — vendor, hosting, API: tudo a confirmar. Risco de não ter API moderna (típico de portais de fornecedor).
- KCOR → projKcor (SISACIDENTES) — primeiro dos 4 sistemas KCOR; intranet-only confirmada → caminho crítico de aprovação Cyber + VM intermediária.
Onda 3 — set/2026¶
- AutoDesk → projAutodesk — confirmar qual produto está em SISPROJ (Build? Civil 3D? AutoCAD?); confirmar uso de Autodesk Platform Services (APS); decidir o que vai pro ArcGIS vs o que fica como link/referência ao Build.
Onda 4 — out/2026¶
- KCOR → projKcor (SISEQP) — gestão de equipamentos operacionais; mesmo gargalo Cyber.
Onda 5 — dez/2026¶
- KCOR → projKcor (SISPESMOV, HS-Wim) — formato de dados de pesagem (peso por eixo, velocidade, classe); dados pessoais (placa, CPF motorista) — LGPD.
- SAT → projSat — vendor a confirmar; provável on-prem → fila Cyber; granularidade temporal de tráfego (real-time vs agregado hora/dia).
- Plug > PowerBI (SIS-CSP) — auto-referência. Confirmar pipeline: Plug exporta para PowerBI ou PowerBI consulta o Plug?
Onda 6 — fev/2027¶
- Construtivo → projConstrutivo — sistema ainda não existe. Co-projeto ativo: oferecer ao fornecedor um OpenAPI rascunhado pela TPF antes que ele desenvolva. Iniciar engajamento já na Onda 1 (em paralelo), não esperar nov/2026.
- Kartado/AutoDesk → projKartado/projAutodesk (SISATIVOS) — inventário de ativos rodoviários alimentado por duas fontes; resolver concorrência/precedência.
Lacunas transversais (não atreladas a uma onda)¶
- DSL incompleta —
workspace.c4lista 5 projetores; realidade exige ~12. Nomear formalmente os ~8 projetores faltantes e eliminar o placeholderprojOutrosà medida que entrarem. - Contrato de dados dos Read Models — nenhum Read Model em
BANCO ARTESPtem schema/OpenAPI documentado hoje. Sem isso, projetores e consumidores (Plug, ArcGIS) não têm contrato estável. - Voz da ARTESP como consumidora — ARTESP aparece no C1 como ator que autentica e consulta o Plug, mas nenhum requisito, formato ou critério de aceite veio dela. Risco: entregar Read Models que tecnicamente satisfazem o contrato mas operacionalmente não servem ao relatório que a ARTESP precisa.
- Modelo de dados canônico do hub — esqueleto definido (schema-per-fornecedor em Staging; Read Model por produto em ARTESP), mas o modelo canônico por entidade de domínio (trecho, veículo, ativo, ocorrência…) ainda está em aberto.
4. Como usar este tracker¶
- Antes de cada sessão de Discovery: cruzar a célula vendor × projetor e listar as 3 perguntas mais críticas dali.
- Após cada sessão: atualizar os marcadores de confiança e mover lacunas da seção 3 para a tabela na seção 1 ou 2 conforme forem respondidas.
- Quando um projetor for nomeado na DSL: mudar a coluna Status DSL C4 de "não nomeado" para "nomeado" e atualizar
workspace.c4na mesma PR. - Releitura mínima recomendada: revisão semanal pelo time TPF; revisão a cada início de onda pelo PO.