Inventário de Fornecedores (Vendors)¶
Canonical neste site (
arquitetura/). Os sitestpf-motiva/ekickoff/referenciam esta página. Veja também Inventário de Sistemas ARTESP e Dados e Projeções.Como usar este documento
Este inventário organiza o escopo de integração por ferramenta, não por sistema ARTESP. O cronograma firmado com a Artesp tem 24 linhas, mas só ~13 ferramentas únicas — agrupar por ferramenta dá o ponto único de contato para conduzir Discovery (ex.: KCOR cobre 5 sistemas; uma única conversa com o owner KCOR resolve todos). Tabela canônica em Sistemas ARTESP.
Status atual: a maior parte das informações C/P/B, hosted, fluxo e schema é hipótese a confirmar. Os campos marcados com
?ou(a confirmar)são exatamente o que o roteiro de entrevista (§2) precisa preencher.Vínculo com Discovery: o preenchimento das fichas alimenta as Specs por integração do Track 2 do
plano-discovery-agile.md(emtpf-motiva/). As fichas das ferramentas da Onda 1 (KAPSCH, Ícaro) precisam ser preenchidas primeiro.
1. Visão geral — tabela master¶
Legenda da coluna C/P/B (em relação ao Plug): - P = Producer (envia dados para o Plug) - C = Consumer (recebe dados do Plug) - B = Both (troca nos dois sentidos) - ? = a determinar nas entrevistas
| # | Ferramenta | Vendor | Sistemas ARTESP | Datas Plug | C/P/B | Hosted | Onda(s) | Notas |
|---|---|---|---|---|---|---|---|---|
| 1 | KAPSCH | KAPSCH | SISFREEFLOW (1) | jul/26 | P? | ? | 1 | Free flow / arrecadação eletrônica. Provavelmente intranet-only. |
| 2 | Ícaro | ? | SGP (1) | jul/26 | ? | ? | 1 | SGP = Sistema de Gestão de Pavimentos. |
| 3 | KCOR | KCOR | SISACIDENTES, SIS-SAU, SISEQP, SISPESMOV (4) | ago, set, out, dez/26 | P? | On-prem (intranet-only) | 2,3,4,5 | Vendor crítico (5x). Premissa confirmada: nunca exposto à internet → exige VM intermediária. SISPESMOV usa variante "HS-Wim". |
| 4 | Kartado | Kartado | SISOAES, SIGECON, SIR, SISATIVOS (4) | ago/26, ago/26, ago/26, fev/27 | B? | SaaS (Motiva tenant) | 2,2,2,6 | Vendor crítico (4x). SaaS pertencente à Motiva, não à TPF. Em SIGECON usa em conjunto com MITS. |
| 5 | MITS | ? | SIGECON (1, combinado com Kartado) | ago/26 | ? | ? | 2 | Co-ferramenta com Kartado em SIGECON. Papel exato a esclarecer. |
| 6 | Plug | TPF (próprio) | SIR, SIS-CSP, SISSOND, SISGIS (4) | ago/26, dez/26, N/A, N/A | B | SaaS (Cloud K8s + Cloud SQL) | 2,5,N/A,N/A | Auto-referência. Em SIS-CSP aparece como "Plug > PowerBI" (Plug é fonte de dados para Power BI). |
| 7 | Portal Faixa de Domínio | ? | SISDEMANDA (1) | ago/26 | ? | ? | 2 | Tudo a confirmar. |
| 8 | AutoDesk Build | Autodesk Inc | SISOBRAS, SGP, SISATIVOS (3) | set/26, set/26, fev/27 | B? | SaaS | 3,3,6 | Vendor crítico (3x). SaaS, API rica. Confirmado nas premissas como "tranquilo". |
| 9 | AutoDesk Navisworks + BIM Collab | Autodesk Inc | SISOBRAS (1, combinado com Build) | set/26 | C? | SaaS | 3 | Mesmo vendor (Autodesk Inc) — entrevista pode ser conjunta com Build. |
| 10 | AutoDesk (suite, não-especificado) | Autodesk Inc | SISPROJ (1) | set/26 | ? | SaaS | 3 | A entrada do cronograma diz só "AutoDesk" — confirmar qual produto da suite (Build? AutoCAD? Civil 3D?). |
| 11 | SAT (Sistema de Análise de Tráfego) | ? | SISSAT (1) | dez/26 | P? | ? | 5 | Sistema de análise de tráfego. Provavelmente Producer. |
| 12 | Construtivo | ? | SISQUALI (1) | fev/27 | ? | ? | 6 | Ponto de atenção alto. Sistema em desenvolvimento — ainda não existe. Precisa contrato de dados antes que o fornecedor construa. |
| 13 | Esteio-ETT (API DER) | Esteio Engenharia | SISRAD (1) | N/A | — | ? | N/A | Marcado N/A no cronograma. Hipótese: consumido via outra rota (DER). A confirmar. |
| 14 | ArcGIS (como ferramenta) | Esri | SISGIS (1) | N/A | B (consolidador) | On-prem (Motiva) | N/A | É também o consolidador central das premissas — recebe de tudo. Marcado N/A em SISGIS porque integrá-lo com Plug seria redundante. |
Vendors críticos por multiplicidade: KCOR (5), Kartado (4), AutoDesk (5 entradas / 4 sistemas distintos).
2. Roteiro-base de entrevista¶
Template reutilizável. Para cada ferramenta, usar este roteiro como base e acrescentar as customizações específicas listadas na ficha da ferramenta na §3.
Duração esperada: 45–60 min por ferramenta. Se houver vendor + owner Motiva separados, fazer duas sessões (uma com cada).
2.1 — Identificação e contexto operacional¶
- O que esta ferramenta faz, em uma frase?
- Quais sistemas ARTESP ela implementa? (validar contra cronograma)
- Quais áreas operacionais da Motiva dependem dela hoje (ou vão depender no D+1 da operação)?
- Existe algum sistema legado que ela substitui? Como é a transição?
2.2 — Owners e pontos focais¶
- Quem é o owner técnico desta ferramenta do lado da Motiva?
- Quem é o ponto focal técnico do lado do vendor?
- Quem é o owner de negócio (key user operacional)?
- Qual o tempo de resposta típico do ponto focal vendor para questões técnicas?
- Existe contrato de SLA documentado?
2.3 — Acesso e autenticação¶
- A ferramenta é SaaS, on-premise ou híbrida?
- Se SaaS: qual hyperscaler / qual região? Está em conformidade com a premissa de "Azure quando precisar cloud"?
- Se on-premise: em que rede roda? Intranet Motiva? Exige VPN/VM intermediária?
- Como o Plug autentica nela? (login/senha, OAuth, mTLS, API key, certificado?)
- Existem ambientes separados (dev/staging/prod)? O Plug terá acesso a quais?
- Quem tem que aprovar o acesso técnico inicial? (InfoSec? Cyber? Design Authority?)
2.4 — APIs e protocolos de integração¶
- Existe API pública? REST? SOAP? GraphQL? gRPC?
- Existe documentação? Onde? Versão atual?
- Se não houver API: integração via DB Link? Arquivos (CSV/XML)? Mensageria (Kafka/RabbitMQ)?
- A ferramenta tem webhooks para notificar mudanças? Ou só pull?
- Existem rate limits? Quotas? Janelas de uso?
- Versionamento de API: como mudanças quebram clientes?
2.5 — Fluxo de dados end-to-end¶
A classificação Producer/Consumer/Both é binária em relação ao Plug. Esta seção amplia para o fluxo completo: de onde o dado vem antes da ferramenta, e para onde ele vai depois do Plug. Sem isso, não dá para entender o valor da integração nem identificar dependências reais.
Upstream — antes da ferramenta - De onde nasce o dado original? (Sensor físico? Operador humano? Outro sistema? Coleta de campo?) - Quem é o "primeiro autor" do dado? (Pessoa ou equipamento responsável pela primeira escrita) - O dado já chega na ferramenta processado, ou ela faz processamento próprio (agregação, normalização, validação)? - Existe alguma fonte de dado de referência (cadastro, dicionário, master data) que a ferramenta consome?
Pela ferramenta - O que a ferramenta transforma vs apenas armazena? (Calcula índices? Valida regras? Apenas persiste?) - Existe estado mantido pela ferramenta que precisa ser propagado? (Ex.: status de aprovação, workflow)
Downstream — depois do Plug - Quem consome este dado depois que está no Plug e no ArcGIS? Operadores diretos? Dashboards? Relatórios? Outras integrações? - Existe relatório regulatório à ARTESP que depende deste dado? Qual periodicidade? Qual o formato esperado? - Existe decisão operacional que depende deste dado? (Ex.: programação de manutenção, despacho, cobrança) - O dado vai para fora do ecossistema Motiva? (Outros órgãos? Concessionária vizinha? Auditoria externa?) - Existem múltiplos destinos finais, ou só um?
Vínculo entre upstream e downstream - O fluxo é "fire-and-forget" (dado é gerado e descartado após uso) ou tem rastreabilidade completa? - Há feedback loop? (Ex.: decisão tomada com base no dado gera nova entrada na ferramenta?) - Quando o dado expira ou perde validade?
2.6 — Schema dos dados relevantes¶
- Quais entidades de dados principais a ferramenta gerencia?
- Para cada entidade que vai integrar com o Plug:
- Lista de campos e tipos
- Quais são chaves primárias / identificadores únicos?
- Existem chaves estrangeiras para outras ferramentas?
- Há enumerações ou códigos de domínio?
- Há dados históricos ou só estado atual?
- Existe modelo de dados documentado (ER, JSON Schema, OpenAPI)?
- O dado é "limpo" ou tem qualidade variável (campos opcionais sempre vazios, valores inconsistentes)?
2.7 — Volumes e cadência¶
- Quantos registros por entidade hoje? Crescimento esperado?
- Frequência de atualização: tempo real? minuto? hora? dia? semana?
- Latência aceitável entre fato e disponibilidade no Plug?
- O Plug consulta sob demanda ou recebe push?
- Janelas de manutenção da ferramenta? (Quando ela fica fora?)
2.8 — Operação e SLA¶
- Qual o uptime atual / contratual?
- Qual o canal de suporte? Tempo de resposta?
- Como erros e indisponibilidades são notificados?
- A ferramenta tem monitoramento próprio ou depende de monitoramento externo?
- Como é o processo de backup e recovery?
2.9 — Segurança e compliance¶
- Quais classificações de dado circulam? (Pessoal? Sensível? Operacional?)
- Há dados sob LGPD? Como o Plug deve tratar?
- Criptografia em trânsito (TLS)? Em repouso?
- Existe trilha de auditoria? O Plug precisa contribuir para ela?
- A integração precisa de aprovação de InfoSec / Cyber / Design Authority? Qual o lead time?
- Há requisitos de retenção ou descarte de dados?
2.10 — Dependências e gargalos¶
- Esta ferramenta depende de outras para funcionar? (Quais? Como falham?)
- Há outras ferramentas que dependem dela? (Risco de ripple effect)
- Quais são os gargalos conhecidos hoje? (Performance? Estabilidade? Suporte?)
- Há contrato de dados já formalizado com o vendor? Se não, quem tem que assinar?
- O que pode dar errado entre hoje e a deadline de Integração Plug? Plano B?
3. Fichas por ferramenta¶
Cada ficha começa com identificação + classificação preliminar + conhecimento atual, seguida das customizações ao roteiro-base específicas para essa ferramenta.
3.1 — KAPSCH (SISFREEFLOW)¶
- Vendor: KAPSCH
- Sistemas ARTESP: SISFREEFLOW
- Onda: 1 (deadline jul/26 — urgente)
- C/P/B (hipótese): Producer — gera dados de cobrança eletrônica / passagens de veículo
- Hosted (hipótese): On-premise (sistema operacional crítico de arrecadação)
- Conhecimento atual: praticamente nada. Premissas mencionam "arrecadação, radar" como sistemas operacionais Motiva intranet-only — KAPSCH provavelmente está nesse grupo.
Fluxo de dados (hipotético — confirmar nas entrevistas):
| Etapa | O que acontece |
|---|---|
| Upstream | Pórticos físicos free flow na rodovia: antenas RFID/AVI, câmeras OCR de placas, loops indutivos, classificadores de eixos |
| KAPSCH | Detecta passagem, identifica veículo (TAG ou placa), classifica (categoria tarifária por eixos/altura), calcula tarifa, aplica isenções, gera evento de passagem |
| Plug | Consome eventos de passagem normalizados (ID veículo, timestamp, km, sentido, classe, valor cobrado, status pagamento) |
| ArcGIS | Persiste como camada geo (eventos pontuais por pórtico ou agregados por trecho/hora) |
| Downstream | Relatórios operacionais de arrecadação; dashboards de tráfego e cobrança; relatórios regulatórios à ARTESP (volume, evasão, performance de cobrança); possivelmente Lake/BI da Motiva no futuro (fora de escopo agora) |
| Decisões dependentes | Programação de fiscalização, identificação de evasão, ajustes de classificação tarifária, conciliação financeira |
Customizações ao roteiro-base: - §2.3: confirmar se exige VM intermediária dentro da Motiva (premissa para sistemas intranet-only) - §2.6: confirmar quais campos da passagem (ID veículo, placa, timestamp, valor cobrado, classe tarifária) entram no escopo Plug - §2.7: tempo real é necessário? Ou agregação por hora/dia é suficiente para o caso de uso operacional? - §2.9: dados de placa de veículo são pessoais (LGPD) — qual o tratamento?
Riscos específicos: - Onda 1 = ~12 semanas até deadline. Discovery precisa começar imediatamente. - Se for intranet-only, todo o setup de VM intermediária + aprovação Cyber está no caminho crítico.
3.2 — Ícaro (SGP — Sistema de Gestão de Pavimentos)¶
- Vendor: a confirmar
- Sistemas ARTESP: SGP — Sistema de Gestão de Pavimentos
- Onda: 1 (deadline jul/26 — urgente)
- C/P/B (hipótese): Producer? — Ícaro provavelmente coleta/registra dados de condição de pavimento (IRI, afundamentos, trincas, levantamento de campo)
- Hosted (hipótese): ?
- Conhecimento atual: SGP aparece duas vezes no cronograma — Ícaro (deadline jul/26) e AutoDesk Build (deadline set/26). Hipótese: Ícaro é a parte de levantamento/medição de pavimentos (especialista no domínio); AutoDesk Build é a parte de projetos / documentação BIM dos pavimentos. As duas alimentam o mesmo SGP por ângulos diferentes. Confirmar.
Fluxo de dados (hipotético — confirmar nas entrevistas):
| Etapa | O que acontece |
|---|---|
| Upstream | Levantamentos de campo: perfilômetro a laser (IRI), deflectometria FWD, inspeção visual de defeitos (trincas, afundamentos, panelas), GPR. Equipes técnicas em campanhas periódicas |
| Ícaro | Registra medições por trecho (km início/fim), calcula índices consolidados (IRI, ICP, condição), mantém histórico por trecho ao longo do tempo |
| Plug | Consome estado atual + histórico de pavimento por trecho, normaliza para o esquema do ArcGIS |
| ArcGIS | Persiste como camada de pavimento linear (km início, km fim, sentido, faixa, índices) |
| Downstream | Planejamento de intervenções (programação de manutenção); dashboard de PMS (Pavement Management System); relatórios contratuais à ARTESP sobre cumprimento de metas de qualidade de pavimento; alimenta decisões de orçamento de manutenção |
| Decisões dependentes | Quando reconstruir um trecho? Onde priorizar manutenção? Há trechos abaixo do mínimo contratual ARTESP? |
Customizações ao roteiro-base: - §2.1: confirmar a divisão de papel entre Ícaro e AutoDesk Build no SGP — Ícaro é coleta de dados de campo? Modelagem técnica? Histórico de intervenções? - §2.1: que tipos de medição de pavimento o Ícaro registra? (IRI, afundamento, ATR, trincas, irregularidade, condição superficial?) - §2.6: como os dados são geo-referenciados? Estaca? Quilometragem? Lat/long? (Crítico para entrar no ArcGIS) - §2.6: existe ciclo de levantamento (mensal? trimestral? anual?) e o Plug precisa do histórico ou só do estado atual? - §2.7: dados de pavimento são tipicamente batch (após campanha de campo) — confirmar se é assim ou se há monitoramento contínuo
Riscos específicos: - Onda 1 = urgência máxima - Divisão de escopo entre Ícaro e AutoDesk Build precisa ficar clara cedo, senão gera retrabalho
3.3 — KCOR (SISACIDENTES, SIS-SAU, SISEQP, SISPESMOV)¶
- Vendor: KCOR
- Sistemas ARTESP: 4 (SISACIDENTES, SIS-SAU, SISEQP, SISPESMOV)
- Onda: 2, 3, 4, 5 (escalonado ago→dez/26)
- C/P/B (hipótese): Producer
- Hosted (confirmado): On-premise / intranet-only — premissa explícita das reuniões. Nunca exposto à internet. Exige VM intermediária dentro da Motiva.
- Conhecimento atual: vendor crítico (cobre 5 ocorrências no cronograma). Em SISPESMOV usa a variante "HS-Wim" (provavelmente "High-Speed Weigh-in-Motion" — pesagem em movimento).
Fluxo de dados (hipotético — confirmar nas entrevistas):
KCOR cobre 4 sistemas distintos. O fluxo varia por sistema, mas o destino (Plug → ArcGIS → consumidores) é comum.
| Sistema | Upstream | KCOR faz | Downstream consumidores |
|---|---|---|---|
| SISACIDENTES | Operadores CCO, polícia rodoviária, equipes de campo registrando ocorrências | Armazena, classifica gravidade, georreferencia, mantém workflow de atendimento | Estatísticas de sinistralidade, relatórios à ARTESP (taxas por km, tipos), planejamento de pontos críticos |
| SIS-SAU | (a confirmar — provavelmente Sistema de Atendimento ao Usuário: chamadas 0800, ocorrências reportadas) | Workflow de chamadas, despacho de equipes, registro de atendimento | Métricas de SLA de atendimento, relatório à ARTESP sobre tempos de atendimento |
| SISEQP | (a confirmar — possível Sistema de Equipamentos de operação: guincho, ambulância, viaturas) | Inventário, status, manutenção, despacho de recursos | Disponibilidade da frota operacional, planejamento de prontidão |
| SISPESMOV | Sensores HS-Wim (pesagem em alta velocidade) embarcados no pavimento | Identifica veículo, calcula peso por eixo + velocidade, classifica | Fiscalização de excesso de carga, relatório à ARTESP, encaminhamento para autuação |
Plug → ArcGIS comum a todos: persistência georreferenciada por km/sentido, com timestamps para análise temporal.
Customizações ao roteiro-base: - §2.1: pedir para o owner KCOR explicar a diferença entre os 4 sistemas que KCOR implementa. Eles compartilham backend? São deploys separados? - §2.3: confirmar arquitetura intranet-only e desenhar a VM intermediária com Cyber/InfoSec na primeira semana - §2.4: KCOR tem uma única API para os 4 sistemas, ou cada um tem a sua? Os schemas se sobrepõem? - §2.6: para SISPESMOV (HS-Wim), entender o formato dos dados de pesagem (peso por eixo, velocidade, classe de veículo, timestamp) - §2.10: identificar quem é o único ponto focal técnico KCOR que pode responder pelos 4 sistemas, OU se são pessoas diferentes - Estratégia: uma sessão única com KCOR cobrindo os 4 sistemas é mais eficiente que 4 sessões separadas
Riscos específicos: - Vendor crítico — atraso aqui afeta 4 entregas - Intranet-only → VM intermediária + aprovação Cyber é caminho crítico - Se SISPESMOV (HS-Wim) for uma variante isolada do produto principal, pode ter um time KCOR diferente
3.4 — Kartado (SISOAES, SIGECON, SIR, SISATIVOS)¶
- Vendor: Kartado
- Sistemas ARTESP: 4 (SISOAES, SIGECON, SIR, SISATIVOS)
- Onda: 2, 2, 2, 6
- C/P/B (hipótese): Both — provavelmente troca dados nos dois sentidos
- Hosted: SaaS, tenant Motiva (confirmado nas premissas: "Kartado é nosso, não é da TPF")
- Conhecimento atual: vendor crítico (4 sistemas). É SaaS tenant da Motiva — TPF pode consumir API direto, mas dado tem que refletir no ArcGIS imediatamente (premissa).
Fluxo de dados (hipotético — confirmar nas entrevistas):
| Sistema | Domínio (hipótese) | Upstream | Downstream consumidores |
|---|---|---|---|
| SISOAES | OAEs = Obras de Arte Especiais (pontes, viadutos, túneis, passarelas) | Inspeções estruturais periódicas, projetos | Programa de inspeções, relatório à ARTESP sobre estado de OAEs, planejamento de reabilitações |
| SIGECON | Sistema de Gestão de Construção (a confirmar) | Equipes de obra, medições, RDOs (Relatórios Diários de Obra) | Controle físico-financeiro de obras, dashboards de execução |
| SIR | a confirmar (possível Sistema de Inspeção de Rotina ou Sistema de Inventário Rodoviário) | Equipes de inspeção rotineira | Planejamento de manutenção, relatórios à ARTESP |
| SISATIVOS | Inventário de Ativos Rodoviários (sinalização, defensas, drenagem, mobiliário) | Levantamentos de ativos em campo + cadastros iniciais | Programa de manutenção de ativos, ciclo de vida, depreciação |
Plug ↔ Kartado (Both): provavelmente o Plug consome dados de Kartado E pode enviar dados de volta (ex.: status de execução de manutenção). Confirmar a direção em cada caso.
Plug → ArcGIS: persistência georreferenciada — pontos para OAEs, polígonos/linhas para obras, pontos para ativos.
Downstream comum: dashboards de gestão, relatórios contratuais à ARTESP (todas as 4 entidades têm obrigações de prestação de contas), planejamento orçamentário.
Customizações ao roteiro-base: - §2.1: explicar a relação entre os 4 sistemas Kartado — são módulos do mesmo produto ou produtos diferentes? - §2.3: confirmar credenciais do tenant Motiva, ambientes (sandbox?), URL base - §2.4: Kartado tem API documentada pública? OpenAPI? Webhooks? - §2.6: para cada um dos 4 sistemas, mapear as entidades-chave (especialmente para SISATIVOS — ativos rodoviários — que está na onda 6 com mais tempo) - §2.6: SIGECON usa Kartado + MITS — entender como os dois se conectam (Kartado é o frontend e MITS é backend? Ou são duas integrações independentes?) - §2.10: confirmar com Roberta/Mike se Kartado é mesmo "tenant Motiva" ou se há nuance contratual
Riscos específicos: - Vendor crítico — 3 sistemas na Onda 2 (mesma deadline ago/26) - A combinação Kartado + MITS em SIGECON é uma incógnita - Conflito de premissa: se Kartado é tenant Motiva, "passar dado por Kartado primeiro" pode contar como "dado em SaaS antes do Motiva on-premise" — validar com Mike
3.5 — MITS (SIGECON)¶
- Vendor: a confirmar
- Sistemas ARTESP: SIGECON (combinado com Kartado)
- Onda: 2 (deadline ago/26)
- C/P/B (hipótese): ?
- Hosted (hipótese): ?
- Conhecimento atual: aparece apenas em SIGECON, sempre junto com Kartado.
Fluxo de dados (hipotético — quase tudo a confirmar):
| Etapa | O que acontece (hipótese) |
|---|---|
| Upstream | ? — depende do papel de MITS (sistema legado de obras? Camada de transformação? ETL?) |
| MITS | ? — pode ser front-end legado, backend de cálculo, ou sistema separado que coexiste com Kartado |
| Plug | ? — possivelmente nem integra direto com MITS; pode integrar só com Kartado, e MITS é "invisível" |
| ArcGIS | (mesmo que Kartado em SIGECON) |
| Downstream | (mesmo que Kartado em SIGECON) |
Pergunta-chave da entrevista: o Plug precisa integrar com MITS diretamente, ou MITS é só um detalhe interno do stack do SIGECON do lado Motiva (e a integração é só com Kartado)?
Customizações ao roteiro-base: - §2.1: o que MITS faz especificamente em SIGECON? É uma camada de transformação? Backend? Sistema legado? - §2.1: MITS tem owner separado de Kartado, ou são o mesmo time? - §2.4: a integração com o Plug é via MITS ou via Kartado? Ou ambas? - Esta ficha pode ser muito curta se MITS for só uma sub-componente — mas vale verificar para não esconder um gargalo
Riscos específicos: - Pouca informação. É a "incógnita silenciosa" da Onda 2.
3.6 — Plug (TPF, próprio) — auto-referência¶
- Vendor: TPF (próprio produto)
- Sistemas ARTESP: SIR, SIS-CSP, SISSOND, SISGIS (4)
- Onda: 2, 5, N/A, N/A
- C/P/B: Both por definição (é o produto sendo entregue)
- Hosted: SaaS — Cloud K8s + Cloud SQL (confirmado nas premissas)
- Conhecimento atual:
- Em SIR: o Plug é uma das ferramentas listadas (junto com Kartado) — provavelmente o Plug consome de Kartado e é o sistema SIR de algum ponto de vista
- Em SIS-CSP: aparece como "Plug > PowerBI" — Plug é fonte de dados para Power BI
- Em SISSOND (N/A): a ferramenta É o Plug — auto-referência. Por isso N/A para integração
- Em SISGIS (N/A): mesma lógica
Fluxo de dados (hipotético — confirmar com time TPF):
| Sistema | Papel do Plug | Upstream | Downstream |
|---|---|---|---|
| SIR | Front-end / camada de apresentação consolidada | Kartado (produtor de dados) | Operadores Motiva veem dashboard SIR; relatório à ARTESP |
| SIS-CSP | Fonte de dados para Power BI | Plug agrega dados de várias outras integrações (CSP = Centro de Serviços de Performance? a confirmar) | Power BI consome do Plug e gera relatórios executivos / regulatórios |
| SISSOND (N/A) | Sistema completo (sem upstream/downstream externos ao Plug) | Operação do Plug em si | Stakeholders Motiva consultam direto o Plug — sem segunda integração |
| SISGIS (N/A) | Sistema completo (Plug consumindo ArcGIS — auto-referência) | ArcGIS Motiva (camadas geo) | Operadores Motiva |
Observação: SIS-CSP é o caso mais interessante — coloca o Plug como fonte para um sistema de BI externo. Isso é diferente de todas as outras integrações onde o Plug é o destino final dos dados antes do ArcGIS. Vale entender o pipeline Plug → Power BI em detalhe.
Customizações ao roteiro-base: - Esta ficha não é "entrevistar o Plug" — é alinhar internamente com o time TPF (Felipe, Francisco, Isa, Alex) o que significa "Plug como ferramenta" em cada contexto - §2.1: para cada um dos 4 sistemas, qual é exatamente o papel do Plug? É front-end? É repositório? É consolidador? - §2.4: para SIS-CSP (Plug > PowerBI), entender o pipeline: o Plug exporta para o PowerBI ou o PowerBI consulta o Plug? Qual o formato? - Confirmação dos N/A: SISSOND e SISGIS são realmente "fora de escopo de integração" porque a ferramenta é o próprio Plug? Esta é uma das perguntas-chave do backlog de descobertas.
Riscos específicos: - Confusão semântica: "Plug" é ao mesmo tempo o produto sendo entregue e uma "ferramenta" no cronograma. Esse double-duty pode esconder requisitos - A interpretação dos N/A precisa ser confirmada antes de planejar a Onda final
3.7 — Portal Faixa de Domínio (SISDEMANDA)¶
- Vendor: a confirmar
- Sistemas ARTESP: SISDEMANDA
- Onda: 2 (deadline ago/26)
- C/P/B (hipótese): ?
- Hosted (hipótese): ?
- Conhecimento atual: nenhum.
Fluxo de dados (hipotético — quase tudo a confirmar):
| Etapa | O que acontece (hipótese) |
|---|---|
| Upstream | Solicitantes externos (concessionárias de serviços, prefeituras, empresas) submetem pedidos relacionados à faixa de domínio: instalação de dutos, travessias, acesso, ocupação |
| Portal | Workflow de aprovação: submissão → análise técnica → aprovação/rejeição → emissão de licença |
| Plug | Consome status dos pedidos? Cria pedidos automaticamente? Geo-localiza intervenções aprovadas? |
| ArcGIS | Persiste pontos/linhas/polígonos das ocupações da faixa de domínio aprovadas |
| Downstream | Cadastro georreferenciado de ocupações da faixa de domínio; suporte a fiscalização; relatório à ARTESP sobre uso da faixa; planejamento de obras (evitar conflito com ocupações existentes) |
Pergunta-chave: SISDEMANDA = Sistema de Demanda(s) — provavelmente gerencia as demandas externas relacionadas à ocupação da faixa de domínio.
Customizações ao roteiro-base: - §2.1: o que é "Faixa de Domínio" no contexto Sorocabana? (Termo jurídico/regulatório de área lateral à rodovia?) - §2.1: SISDEMANDA = Sistema de Demanda? De que tipo? (Solicitações de licenças? Pedidos de obras?) - §2.4: portais de fornecedores costumam ter integração via export CSV agendado em vez de API moderna — confirmar - §2.8: portais costumam ter SLA fraco — confirmar
Riscos específicos: - Tudo a confirmar. Risco de ser o pior tipo de gargalo: pequeno, ignorado, e sem API.
3.8 — AutoDesk Build (SISOBRAS, SGP, SISATIVOS)¶
- Vendor: Autodesk Inc
- Sistemas ARTESP: SISOBRAS, SGP, SISATIVOS (3 entradas)
- Onda: 3, 3, 6
- C/P/B (hipótese): Both — plataforma BIM colaborativa, troca dados nos dois sentidos
- Hosted: SaaS (Autodesk hospeda)
- Conhecimento atual: confirmado nas premissas como "tem API para tudo, facilita". Vendor crítico (3 sistemas + a entrada ambígua "AutoDesk" para SISPROJ + Navisworks/BIM Collab = 5 ocorrências totais Autodesk).
Fluxo de dados (hipotético — confirmar nas entrevistas):
| Sistema | Upstream | AutoDesk Build faz | Downstream |
|---|---|---|---|
| SISOBRAS | Projetistas e gerentes de obra publicam modelos BIM, documentos, RFIs, submittals | CDE (Common Data Environment) — versionamento de modelos, workflow de aprovação, issues | Controle físico de obra; relatórios de avanço à ARTESP; integração com Navisworks (3.9) |
| SGP (parte BIM) | Modelos BIM dos pavimentos, projetos de reabilitação | Documentação técnica, workflow de aprovação | Aprovação técnica; histórico de intervenções; complementa Ícaro (3.2) |
| SISATIVOS (parte BIM) | Modelos BIM dos ativos rodoviários (sinalização, drenagem, OAEs) | Catálogo de ativos modelados, geometria, propriedades | Inventário georreferenciado de ativos; ciclo de vida |
Plug ↔ AutoDesk Build (Both): - Plug consome: metadados de modelos, status de issues, documentos publicados, RFIs em aberto - Plug envia (?): status de execução em obra (talvez gere issues automáticas em casos de não-conformidade)
ArcGIS: persiste metadados georreferenciados (não os modelos BIM completos — esses ficam no Build). A pergunta arquitetural é o que vai pro ArcGIS vs o que fica como link/referência ao Build.
Downstream: dashboards de obras, planejamento, controle físico-financeiro, relatórios contratuais à ARTESP sobre obras, ARTESP pode auditar diretamente o CDE (a confirmar).
Customizações ao roteiro-base: - §2.1: por que SISOBRAS, SGP (Sistema de Gestão de Pavimentos) e SISATIVOS usam todos AutoDesk Build? São casos de uso diferentes na mesma plataforma? - §2.1: no SGP, AutoDesk Build cobre a parte de projetos/documentação BIM dos pavimentos (hipótese); a parte de medição de campo está com Ícaro. Confirmar a divisão. - §2.4: Autodesk Build tem API rica — mas qual API exatamente? Autodesk Platform Services (APS, antes Forge)? Outro? - §2.6: para SISATIVOS (ativos rodoviários), entender se o modelo de dados é hierárquico (BIM) ou relacional - §2.9: como Autodesk Build trata multi-tenant? O tenant Motiva é compartilhado entre os 3 sistemas? - §2.10: a entrevista com Autodesk pode (e deve) cobrir Build, Navisworks+BIM Collab e o "AutoDesk" ambíguo de SISPROJ na mesma sessão — é o mesmo vendor
Riscos específicos: - Vendor cooperativo (premissa) ≠ projeto trivial. Suíte Autodesk é complexa. - 3 ondas distintas (3, 3, 6) — manter as fichas alinhadas
3.9 — AutoDesk Navisworks + BIM Collab (SISOBRAS)¶
- Vendor: Autodesk Inc
- Sistemas ARTESP: SISOBRAS (1, junto com Build)
- Onda: 3
- C/P/B (hipótese): Consumer — provavelmente recebe modelos do Build para visualização/coordenação
- Hosted: SaaS / desktop híbrido (Navisworks tem componente desktop)
Fluxo de dados (hipotético):
| Etapa | O que acontece |
|---|---|
| Upstream | Modelos BIM publicados no AutoDesk Build (3.8) |
| Navisworks | Coordenação 4D/5D, clash detection entre disciplinas, federação de modelos multidisciplinares |
| BIM Collab | Issue tracking das interferências detectadas — workflow de resolução |
| Plug | Consome issues abertas/resolvidas, métricas de coordenação (ex.: número de clashes não-resolvidos por obra) |
| ArcGIS | Persiste métricas de qualidade da coordenação por obra (não os modelos federados em si) |
| Downstream | Indicadores de qualidade de projeto; alertas para obras com muitas interferências não-resolvidas; suporte ao planejamento de execução |
Customizações ao roteiro-base: - §2.1: por que SISOBRAS precisa de Build E Navisworks+BIM Collab? São papéis complementares? - §2.1: BIM Collab é o issue tracker — o Plug precisa criar/consultar issues nele? - §2.4: Navisworks tem componente desktop — como o Plug interage com isso? É via os arquivos no Build, ou via API direta? - Entrevistar junto com a ficha 3.8 — mesmo vendor, mesma sessão
3.10 — AutoDesk (não-especificado, SISPROJ)¶
- Vendor: Autodesk Inc
- Sistemas ARTESP: SISPROJ
- Onda: 3
- C/P/B: ?
- Conhecimento atual: a entrada do cronograma diz só "AutoDesk" — sem especificar produto. Pode ser AutoCAD, Civil 3D, Build (mesmo da ficha 3.8) ou outro.
Fluxo de dados (hipotético):
SISPROJ = Sistema de Projetos (provavelmente repositório de projetos de engenharia rodoviária).
| Etapa | O que acontece (hipótese) |
|---|---|
| Upstream | Projetistas (internos Motiva ou contratados) entregam projetos: planta-baixa, perfil longitudinal, seções transversais, terraplenagem, drenagem, sinalização |
| AutoDesk (?) | Se for Civil 3D: modelagem nativa de projeto rodoviário; se for AutoCAD: desenhos 2D + metadados; se for Build: armazenamento + workflow (consolidar com 3.8) |
| Plug | Consome metadados de projetos (versão, status, autor, geometria do trecho, escopo); possivelmente arquivos completos via link |
| ArcGIS | Persiste metadados georreferenciados por trecho de projeto |
| Downstream | Repositório central de projetos por trecho; rastreabilidade entre projeto → obra (SISOBRAS); histórico de mudanças regulatórias à ARTESP |
Pergunta-chave (primeira da entrevista): confirmar qual produto AutoDesk — pode mergir esta ficha com 3.8 ou virar uma ficha completamente diferente.
Customizações ao roteiro-base: - §2.1: primeira pergunta — qual produto AutoDesk exatamente? Esta ficha pode acabar mergeando com 3.8 ou 3.9 dependendo da resposta - §2.1: SISPROJ = Sistema de Projetos (CAD/projetos de engenharia)? - Entrevistar junto com 3.8 e 3.9 — mesmo vendor
Riscos específicos: - Ambiguidade no cronograma. Se for um produto diferente dos outros (ex.: AutoCAD ou Civil 3D), a integração é completamente diferente.
3.11 — SAT (Sistema de Análise de Tráfego)¶
- Vendor: a confirmar
- Sistemas ARTESP: SISSAT
- Onda: 5 (deadline dez/26)
- C/P/B (hipótese): Producer — gera dados de contagem/análise de tráfego
- Hosted (hipótese): ?
- Conhecimento atual: nas premissas Rafael cita "arrecadação, radar, SAT" como sistemas operacionais Motiva — sugerindo on-premise, mas precisa confirmar.
Fluxo de dados (hipotético — confirmar nas entrevistas):
| Etapa | O que acontece |
|---|---|
| Upstream | Sensores de contagem de tráfego: loops indutivos, radares Doppler, sistemas de visão computacional, classificadores por eixos. Posicionados em pontos estratégicos da rodovia |
| SAT | Agrega contagens em VDM (Volume Diário Médio), VHP (Volume da Hora de Pico), classifica por categoria de veículo, calcula sentido, velocidade média |
| Plug | Consome agregados por ponto de medição + período; potencialmente também eventos individuais para análises detalhadas |
| ArcGIS | Persiste como camada de pontos de medição com séries temporais |
| Downstream | Planejamento de capacidade da rodovia, dimensionamento de obras de ampliação, relatórios à ARTESP sobre VDM (referência para revisões tarifárias e contratuais), suporte a estudos de impacto |
| Decisões dependentes | Quando duplicar uma faixa? Onde está saturando? Há crescimento de tráfego além do previsto contratualmente? |
Customizações ao roteiro-base: - §2.1: SAT cobre quais tipos de medição? (Volume? Velocidade? Classe de veículo? Sentido?) - §2.3: se for on-premise como os outros operacionais, vai precisar de VM intermediária - §2.6: dados de tráfego são tipicamente agregados (counts por intervalo). Granularidade? Intervalos? - §2.7: tempo real é necessário para tráfego, ou agregação por hora/dia é suficiente para o uso operacional?
Riscos específicos: - Onda 5 dá tempo para Discovery, mas precisa começar antes de set/26 - Se for on-premise, soma à fila de aprovações Cyber
3.12 — Construtivo (SISQUALI)¶
- Vendor: Construtivo (a confirmar empresa)
- Sistemas ARTESP: SISQUALI
- Onda: 6 (deadline fev/27)
- C/P/B: ?
- Hosted: ?
- Conhecimento atual: PONTO DE ATENÇÃO ALTO. Premissas explicitam que este sistema ainda não existe — está sendo construído pelo fornecedor. Precisa de contrato de dados fechado antes que o fornecedor construa.
Fluxo de dados (hipotético — sistema a co-projetar):
SISQUALI = Sistema de Qualidade (a confirmar). Hipótese: gestão de qualidade de obras / materiais / ensaios.
| Etapa | O que acontece (a co-projetar com fornecedor) |
|---|---|
| Upstream | Laudos de laboratório, ensaios de materiais (compactação, granulometria, módulo de resiliência, slump de concreto), inspeções de qualidade em obra, certificados de fornecedores |
| Construtivo | Recebe laudos, valida contra especificações técnicas, mantém histórico, gera não-conformidades quando aplicável |
| Plug | Consome resultados de ensaios, status de não-conformidades, certificações por trecho/obra |
| ArcGIS | Persiste resultados georreferenciados por obra/trecho |
| Downstream | Aprovação/rejeição de etapas de obra, relatórios contratuais à ARTESP sobre conformidade técnica, evidência para auditorias |
| Decisões dependentes | Liberação de etapas de obra; demanda de retrabalho; rastreabilidade de qualidade ao longo do ciclo de vida |
Por ser um sistema a construir, este fluxo é uma proposta — o que negociar com o fornecedor antes que ele desenvolva. Não é Discovery passiva; é co-projeto ativo.
Customizações ao roteiro-base: - Esta entrevista é diferente das outras — não é descobrir uma ferramenta existente, é co-projetar o contrato de dados antes que ela seja construída - §2.1: confirmar quem é o owner Motiva responsável por destravar com o fornecedor Construtivo - §2.1: confirmar status real do sistema (rascunho? especificação? alpha?) - §2.4: oferecer ao fornecedor um OpenAPI / JSON Schema rascunhado pela TPF como ponto de partida - §2.6: alinhar entidades-chave de qualidade (de obra? de pavimento? de projeto?) que o Plug vai precisar - §2.7: alinhar latência, frequência e formato enquanto o fornecedor ainda pode escolher - §2.10: entender o cronograma do fornecedor — quando ele precisa "congelar" a especificação técnica?
Riscos específicos: - Risco mais alto do projeto. Atraso aqui é caminho crítico para Onda 6. - Mesmo sendo Onda 6 (entrevista a partir de nov/26), o engajamento com o fornecedor pode/deve começar antes — porque o fornecedor precisa de tempo para construir a integração, não só para conversar. - Sugestão: iniciar contato com Construtivo já durante a Onda 1 (em paralelo), mesmo que a ficha completa só seja preenchida em nov/26.
3.13 — Esteio-ETT (API DER) — N/A¶
- Vendor: Esteio Engenharia
- Sistemas ARTESP: SISRAD
- Onda: N/A para integração Plug
- C/P/B: — (sem integração)
- Hosted: ?
- Conhecimento atual: marcado N/A no cronograma. "API DER" sugere que é consumido via API do DER (Departamento de Estradas de Rodagem) — ou seja, o caminho não é direto Plug↔Esteio, mas via DER.
Fluxo de dados (hipotético — bypass do Plug):
| Etapa | O que acontece (hipótese) |
|---|---|
| Upstream | Operação/manutenção de radares de fiscalização eletrônica de velocidade na rodovia |
| Esteio-ETT | Sistema de gestão dos radares; coleta autuações, gerencia ciclo de vida do equipamento |
| API DER | Esteio expõe os dados via API do DER (Departamento de Estradas de Rodagem) — órgão regulador estadual |
| Plug | Não consome diretamente — é por isso que está N/A |
| Destino | DER → Detran → infrações no documento do veículo |
Por que N/A (hipótese): o fluxo é puramente regulatório — passa pelo DER e Detran sem nunca tocar o Plug ou o ArcGIS Motiva. A Motiva pode até consumir dados via outra rota (Lake?), mas não é parte do escopo de Integração Plug.
Customizações ao roteiro-base (versão reduzida — só confirmar status N/A): - §2.1: por que SISRAD não precisa integrar com Plug? Ele é consumido por outra ferramenta (ArcGIS direto?) ou já vem do DER? - §2.1: existe alguma chance de SISRAD voltar para o escopo Plug em algum momento? - §2.10: quem é o responsável Motiva por SISRAD? (Para saber a quem perguntar se o status mudar)
Riscos específicos: - Risco de "esquecer" e acordar tarde se a interpretação dos N/A estiver errada - Confirmar interpretação dos N/A é item explícito do backlog de Discovery
3.14 — ArcGIS (como ferramenta) — N/A em SISGIS, central nas premissas¶
- Vendor: Esri
- Sistemas ARTESP: SISGIS (N/A para Plug)
- Onda: N/A
- C/P/B: Both por papel arquitetural — é o consolidador central, recebe de todas as outras integrações e o Plug consome dele
- Hosted: On-premise (Motiva)
- Conhecimento atual: ArcGIS é o repositório consolidador central das premissas. Toda persistência converge para cá. SISGIS (sistema ARTESP que tem ArcGIS como ferramenta) está marcado N/A justamente porque "integrar SISGIS com Plug" via Plug seria redundante — o Plug já consome do ArcGIS.
Fluxo de dados (papel arquitetural — não é integração comum):
O ArcGIS não tem upstream/downstream "linear" como as outras ferramentas — é o hub central.
| Direção | Quem alimenta / consome |
|---|---|
| Recebe de | TODAS as outras integrações deste inventário (KAPSCH, KCOR, Kartado, AutoDesk Build, Ícaro, Construtivo, etc.) — direta ou indiretamente via VM intermediária |
| Camadas mantidas | Pavimento, OAEs, ativos rodoviários, ocupação da faixa de domínio, eventos de tráfego, ocorrências, qualidade de obra, projetos, etc. |
| Consumido por | Plug (principal consumidor para fins de integração) + ferramentas Motiva internas (Field Maps, dashboards GIS, ArcGIS Pro, etc.) |
| Downstream final | Operadores Motiva via Plug ou via ferramentas GIS nativas; relatórios à ARTESP gerados a partir das camadas consolidadas |
Como o Plug usa o ArcGIS: faz queries REST nas camadas, usa para resolver coordenadas → trecho → contexto, usa como fonte de visualização geo.
Por que SISGIS é N/A: o "sistema SISGIS" do cronograma é o próprio ArcGIS Motiva. "Integrar SISGIS com Plug" seria circular — o Plug já é consumidor primário do ArcGIS por arquitetura. Não há nada a "integrar" no sentido normal.
Customizações ao roteiro-base: - Esta entrevista é com o owner ArcGIS Motiva (provavelmente Mike e/ou alguém do time GIS) — não é com Esri - §2.4: estado atual da camada de dados do ArcGIS Motiva — quais feature classes existem? quais vão receber dados das outras integrações? - §2.4: REST API do ArcGIS Server / ArcGIS Enterprise — versão? autenticação? portal? - §2.6: padrão de nomenclatura de feature classes / campos. Glossário canônico que vai ser referência para todas as outras fichas - §2.7: capacidade do ArcGIS — ele aguenta o volume agregado das ~20 integrações ativas? - §2.10: dependências — a Motiva está fazendo upgrade do ArcGIS? Há janela de migração no cronograma? - Esta ficha provavelmente vira um documento de referência transversal mais do que uma ficha de integração
Riscos específicos: - Se o ArcGIS não estiver em capacidade ou versão adequada, é gargalo arquitetural — afeta tudo - Schema do ArcGIS é o "contrato implícito" entre todas as outras integrações; se não estiver padronizado, gera conflitos
4. Vínculo com plano-discovery-agile.md¶
Este inventário alimenta o Track 2 (Discovery por integração) do plano:
- As fichas das ferramentas da Onda 1 (KAPSCH, Ícaro) precisam ser preenchidas primeiro — esta semana
- Em paralelo, o engajamento com Construtivo (Onda 6 mas alto risco) deve começar agora
- Após preencher uma ficha, o resultado vira input das Specs por integração em
discovery/specs/<sistema>-<ferramenta>.md - Vendors críticos (KCOR, Kartado, AutoDesk) devem ter uma única sessão de descoberta cobrindo todos os sistemas que implementam — não múltiplas sessões fragmentadas
Ordem sugerida de preenchimento¶
| Prioridade | Ferramenta | Justificativa |
|---|---|---|
| 1 | KAPSCH, Ícaro | Onda 1 — deadline jul/26 |
| 1 | Construtivo | Sistema em desenvolvimento — engajamento precoce destrava cronograma |
| 2 | KCOR, Kartado | Vendor crítico + Onda 2 |
| 2 | AutoDesk (3 fichas em uma sessão) | Vendor crítico + Onda 3 |
| 2 | MITS, Portal Faixa de Domínio | Onda 2 — pouco conhecido, precisa iniciar |
| 3 | Plug (auto-referência) | Alinhamento interno TPF — pode ser feito em paralelo |
| 3 | ArcGIS | Owner Motiva — referência transversal |
| 4 | SAT | Onda 5 — pode esperar mais |
| 5 | Esteio-ETT | N/A — só confirmar interpretação |
5. Itens em aberto a esclarecer¶
- Confirmar interpretação dos N/A (Esteio-ETT, Plug em SISSOND/SISGIS) — backlog de Discovery do
plano-discovery-agile.md - Confirmar vendor de: Ícaro, MITS, Portal Faixa de Domínio, SAT, Construtivo
- Confirmar qual produto AutoDesk está em SISPROJ (ficha 3.10)
- Confirmar divisão de responsabilidade entre Ícaro e AutoDesk Build em SGP (Sistema de Gestão de Pavimentos) — hipótese atual: Ícaro = medição/campo; AutoDesk Build = projetos/documentação BIM
- Confirmar se Kartado tenant Motiva conta como "dado em SaaS antes do on-premise" (potencial conflito de premissa — perguntar a Mike)