Um documento público com críticas, sugestões e questionamentos a respeito da Minuta do Edital de concorrência pública para “Concessão da Gestão Financeira do Sistema de Transporte Público Coletivo do Município e Serviços Associados”
A Prefeitura de São José dos Campos, por meio da Secretaria de Mobilidade Urbana, disponibilizou publicamente as minutas dos editais referentes aos sistemas de tecnologia e controle financeiro do novo sistema de transporte público do município, os quais podem ser acessados aqui. Com isso, a ONBOARD, empresa que está transformando digitalmente o transporte público no Brasil, revisou “Edital Plataforma 1“, o qual apresenta publicamente suas considerações em relação ao documento.
“Buscamos atuar de forma colaborativa e transparente, visando a construção de editais mais competitivos e verdadeiramente inovadores, além de garantir a qualidade necessária a estes documentos.”
Luiz Renato M. Mattos, CEO da ONBOARD.
O Agora é simples, editado pela ONBOARD, têm como missão contribuir para informação relevante sobre essas áreas no país, por meio de notícias, artigos de opinião e pesquisas. Assim, diante de leitores, gestores e profissionais do setor de transportes e mobilidade urbana, compartilhamos publicamente a manifestação abaixo.
MANIFESTAÇÕES REFERENTES AO EDITAL DA PLATAFORMA 1 DO PROCEDIMENTO DE MANIFESTAÇÃO DE INTERESSE
A ONBOARD
A ONBOARD é uma empresa de dados e tecnologia que tem como missão a transformação digital de sistema de transportes coletivo de passageiros com o objetivo de resgatar a sua competitividade no mercado. A ONBOARD recebeu investimentos da Toyota Mobility Foundation e do Ford Fund Lab. Recentemente teve a sua solução eleita como a melhor e mais inovadora solução para sistema de transporte coletivo de passageiros pela NTU – Associação Nacional das Empresas de Transportes Urbanos em 2019 e se consagrou no 100 Open Startups como uma das 10 soluções de mobilidade mais atrativas para o mercado corporativo, sendo a única solução de transportes públicos no Top 10 da competição internacional.
CONSIDERAÇÕES GERAIS
Observou-se uma falta de harmonização no que diz respeito aos parâmetros de desempenho dos itens que devem compor a solução apresentada. Ou seja, há itens em que os parâmetros estão bastante detalhados, enquanto há outros em que não há detalhamento suficiente. Isso pode implicar em prejuízos ao processo de avaliação das propostas concorrentes, uma vez que se torna possível o livre estabelecimento dos critérios de desempenho que, por sua vez, podem influenciar nos custos gerais da proposta e nas características técnicas e operacionais da solução apresentada.
Sugere-se que questões relativas à operação diária do sistema devem ser separadas das operações de planejamento e controle de desempenho geral do sistema. Considerando que a guarda dos dados de usuários do sistema afeta o desempenho da operação de bilhetagem eletrônica e oferece riscos à empresa detentora da concessão, entende-se que o nível de serviço passa a ser dependente da disponibilidade e da comunicação com a plataforma de operação.
Parte-se do princípio de que dados cadastrais de usuários transitando por entes diferentes do sistema implica em aumento dos riscos de exposição e vazamento de dados dos usuários, e de que dados anonimizados atendem às necessidades de planejamento inerentes à Plataforma 2. Desta forma, entende-se que os dados pessoais diretos dos usuários atendem às necessidades de bilhetagem, pois se referem aos direitos de uso do sistema e suas comprovações, bem como aos comportamentos de uso inerentes aos benefícios atribuídos pelo ente concedente.
Entende-se que a pontuação da equipe de projeto tem o potencial de incentivar a participação de profissionais com experiência na área do edital. Para tanto, sugere-se bonificar com mais pontos o currículo que, devidamente comprovado, demonstre que o profissional tem experiência no desenvolvimento de projetos ligados ao transporte público.
Ao atribuir 37,5% da pontuação potencial no item “pontuação da empresa” (item 8.3.4) à necessidade de apresentação de certificações em normas de qualidade, entende-se que este item traz em si uma distorção que representa um desincentivo à participação de micro e pequenas empresas desenvolvedoras de softwares e sistemas, ainda que consorciadas. É sabido que a obtenção destas certificações implica num alto investimento financeiro, que não pode ser suportado pelas empresas de pequeno e médio porte. Considerando que o Estado tem por uma de suas prerrogativas fundamentais o estímulo à livre iniciativa, e o apoio às micro e pequenas empresas é um elemento de promoção do desenvolvimento econômico e tecnológico do país, torna-se um contrassenso a exigência de elementos que sejam restritivos a esta parcela da comunidade empresarial. Desta forma, sugere-se a supressão do método de avaliação por meio de certificações, ou a isenção das micro e pequenas empresas do critério, com atribuição de nota máxima para este critério, uma vez que este critério não é acessível às micro e pequenas empresas. A falta de métodos de avaliação objetivos e que respeitem os princípios de isonomia inviabilizam a substituição por outros critérios.
Observou-se que não há no edital nenhum desenho esquemático da distribuição dos equipamentos embarcados nos veículos, nem de como serão as interfaces de comunicação entre os equipamentos embarcados e sua comunicação com o sistema central.
Sugere-se atenção ao fato de que o edital também não apresenta como será avaliado e comprovado o atendimento dos requisitos técnicos por ele estabelecidos, dando a entender que isto será feito por autodeclaração dos proponentes. As empresas de bilhetagem eletrônica possuem um vasto histórico no país de não-cumprimento ou não-atendimento às exigências de editais que as selecionaram/contrataram. A praxe da urgência no processo de contratação de sistemas de bilhetagem, somada à falta de capacidade técnica para averiguação e comprovação do atendimento aos requisitos dos editais, beneficia a manutenção do status quo, uma vez que o critério de escolha passa a ser o de projetos já executados, desconsiderando se os requisitos desses projetos foram atendidos ou não. Considerando os padrões atuais, uma vez implementado um sistema de bilhetagem é praticamente impossível a sua substituição devido aos custos e transtornos do processo, além da falta de autonomia por questões de governança de dados e tecnologia. Esses fatos contribuem para a manutenção e preservação dos contratos de bilhetagem que não atendem os requisitos do edital mesmo após sua contratação. Portanto, no caso deste edital em questão, a necessidade de comprovação se faz ainda mais necessária por se tratar de um conceito de bilhetagem novo, do qual nenhuma empresa de bilhetagem no país possui experiência e os casos deste conceito aplicados ao redor do mundo ainda são extremamente raros.
CONSIDERAÇÕES ESPECÍFICAS
Anexo I
Item “Dispositivos embarcados nos veículos”, página 49 e seguintes
Validadores:
Não foram especificados os pontos a seguir:
- Faixa de tensão de operação (09V, 12V, 24V, etc.);
- Tipos de slots para conexão com outros dispositivos e suas respectivas quantidades (Ethernet, RS232, USB, etc.);
- Quantidade de slots para chip SAM;
- Tipo do chip SAM;
- Os índices de proteção de partícula, impacto e vibração em padrão internacional;
- Necessidade ou não de tela e quando houver definir o seu tamanho mínimo;
- Tipos de sinalização (sinal sonoro, luminoso, etc);
- Faixa de temperatura de operação;
- Tipo de processador;
- Necessidade de memória RAM;
- Entrada para memória externa (cartão SD).
Na parte que se refere a especificação dos tipos de processamento de pagamentos, o edital aponta os cartões de crédito e débito como um padrão, quando na verdade são produtos. Esses produtos podem ser de tarja magnética, chip ou aproximação. O edital não especifica quais destas tecnologias devem ser contempladas. O padrão adotado pela indústria de cartões bancários para pagamentos em sistemas de transporte público é o EMV contactless, contemplado na especificação dos dispositivos EMV (ISO/IEC 14.443 A/B)
Ainda sobre o processamento dos pagamentos, a especificação exige compatibilidade apenas com cartões microprocessados e não-microprocessados do tipo MIFARE, que é um padrão proprietário, desconsiderando os padrões abertos internacionais como CIPURSE e CALYPSO. Além disso, o edital deixa extremamente ampla sua especificação quando exige a compatibilidade com quaisquer outras tecnologias de pagamento que venham surgir. O problema disso está no fato de que os equipamentos de processamento de pagamento, que no caso são os validadores, precisam ter compatibilidade com essas tecnologias, o que é difícil de prever. Para citar alguns exemplos de tecnologias de pagamento estão o bluetooth, a frequência ultrassônica e o laser a partir dos avanços da fotônica. Os exemplos citados foram listados em ordem de maturidade mercadológica para aplicação de pagamentos e servem para exemplificar o desafio de compreender de forma ampla as tecnologias para este fim.
Sobre o padrão de conectividade, o edital exige padrão de conexão mínima 4G. A forma como o requisito está especificado abre margem para uma interpretação errônea que pode levar a desconsideração de gerações de internet móvel que ainda representam a maior cobertura de internet no país. Os próprios aparelhos celulares, durante seu uso, transitam entre as diferentes gerações de internet móvel de acordo com a disponibilidade, uma vez que a geração mais atual não está sempre disponível. Portanto, nossa recomendação é que a especificação seja da seguinte forma: “Conexão GPRS/EDGE/3G/4G”.
Na especificação da conexão com dispositivos adicionais para estender as funcionalidades de controle, não é especificado a quantidade de portas que cada tipo deve contemplar. Entre os dispositivos adicionais, o leitor biométrico é citado como exemplo, no entanto, não especifica o tipo de leitor, abrindo a possibilidade de utilização de leitores de digitais que não são recomendados por serem um vetor de doenças e pela dificuldade na leitura das digitais em um ambiente tão hostil e popular como o transporte público.
Na parte que especifica a capacidade de armazenamento, a utilização dos termos “de forma segura”deixa a especificação vaga. A recomendação é que se defina o tipo de criptografia assim como a sua complexidade, como por exemplo, AES256, SHA256, TKIP, etc. Quanto à recuperação, não é mencionada por quais meios seria feita a captura dos dados. Se seria necessário algum software para de recuperação através da conexão com o dispositivo, ou se seria feita apenas através de um cartão SD. Nesse caso não é definido se o dispositivo teria um cartão SD ou se a memória seria soldada na placa com por exemplo um eMMC. Um sistema que possua tanto a memória soldada na placa quanto um cartão SD é o ideal. Além disso, para acesso aos dados que estariam soldados na placa, o ideal é que isso seja feito através de conexão segura utilizando protocolos abertos de rede, como SSH ou FTP.
A presença de um cartão SD, em conjunto com a memória interna (ROM) é encorajada, neste caso, porque existe uma facilidade muito maior de escala quando estender a memória do dispositivo necessita apenas da troca de um cartão.
Para a parte de segurança, em sistemas modernos, existe a criptografia de todo o sistema presente no dispositivo, que garante que dados sensíveis não serão acessíveis por quem não tiver acesso às chaves criptográficas.
Um desses padrões são as partições LVM, que permitem acesso apenas a pessoas com a chave criptográfica e é rápido o suficiente para que não haja nenhum gargalo para a operação. LVM são partições de discos físicos ou lógicos de uso aberto, ou seja, não precisa de licença.
AVL (GPS + Computador De Bordo)
O edital não deixa claro a possibilidade do AVL e do Validador serem um único equipamento, algo que já é possível com os validadores atuais. Nossa recomendação é que o edital apontasse a possibilidade de unificação dos equipamentos visando a redução de custos com sistemas embarcados e a manutenção de diversos dispositivos. De qualquer forma, assim como na especificação dos validadores, não foram especificados requisitos técnicos como os já apontados nos validadores.
A ISO 14.638: 2014 apontada no edital como referente ao Global Positioning Systems na verdade refere-se a especificação do Geometrical Product Specifications, não atendendo aos propósitos desejados neste edital, como pode ser ser observado no link a seguir: https://www.iso.org/committee/54924.html.
Não existe uma norma ou um padrão ISO que especifique o GPS, pois trata-se de uma tecnologia proprietária que varia muito entre fornecedores. Obviamente, no entanto, existe uma especificação base, mas que não se caracteriza como uma ISO. A ISO fornece um padrão, por exemplo, como no caso do Bluetooth, que é a ISO 13485:2012, ou Wi-Fi, ISO 14001, ou mesmo NFC, ISO 14443, com inúmeras variações. Uma sugestão de especificação técnica possível para o GPS seria a seguinte: “Sistema de posicionamento definido por constelações (GPS, GLONASS, GALILEO, Beidou e SBAS) de satélites que permitem determinar o posicionamento e localização de qualquer objeto no globo terrestre”.
Tanto a especificação da comunicação sem fio quanto da possibilidade de acoplamento de outros sensores se enquadram nas mesmas críticas feitas às especificações correspondentes no tópico Validadores.
De forma geral, a definição do AVL é bastante antiga. Considerar apenas o envio de dados por tempo, desconsiderando grades, pontos notáveis, garagens, terminais e pontos de ônibus deixa a especificação na contramão das melhores e mais recentes práticas do mercado.
Sensores de Porta
Não foi especificado qual tecnologia será responsável pela contagem de passageiros e nem como ela irá operar, muito menos a performance mínima desejável. A especificação não define onde os dados podem e/ou devem ser armazenados e nem como e quando serão transmitidos.
Existem diferentes abordagens para atender a demanda de registro das entradas e saídas de passageiros pelas portas do coletivo. Dentre as possibilidades estão a utilização de câmeras stereo, câmeras RGB-D, câmeras térmicas, e câmeras RGB. Também existe a possibilidade de fazer o registro dos embarques e desembarques utilizando sensores que detectam obstáculos, como sensores Lidar, sensores ultrassônicos, etc.
Visto que cada tipo de câmera ou sensor terá uma faixa de custo diferente, assim como diferentes acurácias, como visto em trabalhos na literatura, é importante que isso esteja bem definido no edital, pois existem soluções que podem custar menos que outras, mas oferecer uma acurácia menor.
Câmeras
Em linhas gerais, a especificação mais apropriada seria de um circuito fechado ou interno de televisão, também conhecido como CFTV, que diferentemente das câmeras, são capazes de armazenar e transmitir os vídeos. É através de um circuito integrado que é possível associar as câmeras aos veículos.
Em nosso entendimento, a exigência de armazenamento definida neste tópico é irreal, uma vez que não é possível, num HD comum, armazenar 30 dias * 12 horas de transmissão em alta resolução. Levando em conta uma estimativa econômica de dados, 12 horas de vídeo corresponde a 100 GB, supondo jornadas dos ônibus de 12 horas. Levando isso para 30 dias, seriam em torno de 03 TB (30*100GB), por câmera instalada dentro do veículo, que deveriam ser armazenados. Isso é inviável tanto do ponto de vista de armazenamento, uma vez que não é nada trivial ter 03 TB disponíveis. Além do que transmitir este volume de dados, mesmo que por Wi-Fi, imaginando um cenário em que vários ônibus teriam que fazer esta transmissão, necessitaria de mais do que dias de ônibus parados para que a transmissão fosse completada.
Neste caso, a orientação a produtos específicos, em vez de princípios gerais que possam nortear a construção de alternativas tecnológicas otimizadas de acordo com as inovações do mercado e a própria evolução do aparato tecnológico dificultam uma abordagem inovadora, econômica e viável para a questão.
A especificação da integração com outros sistemas se enquadra nas mesmas críticas feitas à especificação correspondente no tópico Validadores e AVL.
Pelo descrito no edital foram consideradas apenas câmeras para monitoramento do salão dos veículos, não sendo consideradas câmeras para o monitoramento de fadiga e comportamentos de condução perigosa dos motoristas e para monitoramento externos ao veículo como colisões, por exemplo.
Além disso, acreditamos que duas câmeras não sejam suficientes para cobrir toda a área do salão de um ônibus do tipo Padron e principalmente de um articulado.
Câmeras Integradas aos Validadores
Assim como os outros equipamentos especificados neste edital, não há especificações de características físicas e funcionais deste equipamento. A especificação das conexões destas câmeras depende dos tipos de conexão disponíveis nos Validadores.
Além disso, o software de captura e análise das imagens para o reconhecimento facial não foi especificado. Na mesma linha, não são definidos o padrão das imagens, a quantidade de imagens ou frames por segundo e nem como deve ser feita a gravação e transmissão das imagens.
O edital não deixa claro se o armazenamento das imagens deve ser feito localmente ou em um servidor. Além disso, não é especificado se o armazenamento de 30 dias deve ser de todas as imagens capturadas ou somente das imagens que apresentarem alguma inconsistência entre o portador do benefício e quem o usufruiu.
Ao deixar as configurações de qualidade das imagens geradas e a frequência de obtenção das mesmas em aberto, sem estabelecer seus requisitos mínimos, o edital abre brechas que podem distorcer o processo concorrencial assim como não definem um nível de serviço desejado para a solução.
Roteador Wi-Fi
O edital não deixa claro se o roteador Wi-Fi deve ser um equipamento específico ou se ele pode ser parte integrante de um dos outros equipamentos embarcados também especificados. Além disso, não são estabelecidas as características físicas e algumas funcionais, principalmente se este se tratar de um equipamento específico.
O edital traz a seguinte especificação: “Hotspot Wi-Fi 2.4 GHz e/ou 5 GHz sob o padrão IEEE 802.11 A/B/G/N/AC, ou equivalente”. O que não está claro é se o roteador pode operar somente na frequência de 2.4GHz, ou somente 5GHz, ou ambos. E ao mencionar “sob o padrão IEEE 802.11 A/B/G/N/AC” não fica explícito se é necessário atingir algum padrão de velocidade do protocolo atendendo a algum requisito mínimo de velocidade do protocolo.
Outro ponto relevante é sobre a conta de 60 (usuários) x 512 kbps (de velocidade), resultando em torno de 30 mbps de velocidade na rede móvel. Considerando alguns dados de utilização da rede LTE em capitais brasileiras, a média de acesso está bem abaixo disso, conforme fontes do OpenSignal.
Além disso, o edital falha ao não deixar claro como será comprovada a capacidade de 60 usuários conectados simultaneamente a uma velocidade para downstream de no mínimo 512 Kbps.
Para concluir este tópico, o edital ainda exige o armazenamento dos logs de utilização durante as viagens, com capacidade mínima suficiente para 30 dias de registro. No entanto, o edital não define se esses logs se referem, podendo ser consumo de dados, GPS, temperatura, número de conexões, entre outros. Além disso, a especificação não define se o armazenamento dos logs propostos, deve ser local (no próprio equipamento), na nuvem ou em ambos.
Serviço Wi-Fi
Verificamos que o valor destinado ao serviço de dados, é de R$110.121,00 por ano para 513 equipamentos, logo foi considerada uma mensalidade de R$17,88 por chip de dados. O que de acordo com os dados de empresas parceiras que atuam no fornecimento de conectividade embarcada para sistemas de transporte coletivos, podemos afirmar que é um valor fora da realidade. Um plano de 40GB de dados da operadora Claro, tem um valor de R$79,90 mensal, e atualmente esse é o menor plano de dados ofertado pela operadora.. Portanto o único chip de dados que poderia corresponder ao valor estabelecido no edital, seria de chips M2M (machine to machine), mas que possuem uma quantidade de banda muito limitada, sendo utilizado para poucas transações de dados, como máquina de cartão de crédito/débito. Por isso acreditamos que os valores precisam ser revistos.
Um outro ponto que o edital não esclarece é em relação a restrição de conteúdos nessa rede Wi-Fi. Conteúdos de vídeo, por exemplo, consomem mais dados e geralmente são restringidos em redes Wi-Fi de internet móvel. Quem será o responsável pela definição dos limites de acesso ao serviço?
O edital ainda prevê que o serviço de Wi-Fi irá proporcionar uma linha de receita com projeções mais otimistas do que os resultados efetivos obtidos por empresas que operam o serviço. De acordo com a experiência de nossos parceiros, os anunciantes não estão dispostos a investir em uma mídia que não tem aprovação e comprovação do mercado. A instabilidade e indisponibilidade da conexão Wi-fi devido às condições operacionais do transporte público acabam afastando anunciantes que não querem associar sua marca a serviços com esse nível de qualidade.
Casos como o da Google ilustram bem este desafio. Em fevereiro de 2020 a empresa anunciou o encerramento do seu projeto Google Station que oferecia Wi-Fi gratuito em espaços públicos. Em 2019 o projeto chegou ao Brasil por meio de um convênio com a Prefeitura Municipal de São Paulo para oferecer o Wi-Fi Livre SP. Mesmo atingindo milhões de usuários em nove países, o projeto se mostrou insustentável levando ao seu encerramento.
A informação sobre o encerramento do projeto podem ser conferidas no blog oficial da Google através do link a seguir: https://brasil.googleblog.com/2020/02/uma-atualizacao-sobre-o-google-station.html
Outro dado que corrobora este desafio é um estudo realizado pelo Inesc – Instituto de Estudos Socioeconômicos em 2019 que aponta que as receitas não tarifárias (como publicidade) de todo sistema de transporte coletivo do Brasil correspondem a R$ 375 mil. Ou seja, a expectativa de arrecadação com dos serviços de Wi-Fi Propaganda e Premium são quase quatro vezes e meia o valor que setor de transporte coletivo arrecadou com receitas acessórias.
Não está claro no edital o que acontecerá caso essas expectativas de receita não se concretizem.
Sistema de Controle da Bilhetagem
Um ponto crítico na especificação do Sistema de Controle de Bilhetagem que na verdade também envolve outros os editais é o que diz respeito à atribuição à Plataforma 2 do que o edital chamou de “Tarifas e Gratuidades”, que dentre as suas principais funcionalidades estão Cadastro de Usuários, Cadastro de Tarifas, Cadastro de Gratuidades e Homologação de meios de pagamento. Visto que as informações presentes nesses sistemas influenciam nos modelos de cobrança, tarifação e integração com outros sistemas e modais, como pedido nesta especificação, além de possuírem uma interdependência muito grande de outros módulos da bilhetagem, toda sua atribuição deveria ser feita a Plataforma 1.
Quanto a ISO/IEC 24014-1:2015(E) intitulada de Public transport – Interoperable fare management system, nós não a conhecíamos e não tivemos tempo hábil para analisá-la, o que não nos coloca na posição de avaliar a sua viabilidade ou mesmo de criticá-la.
Em sua especificação o edital menciona que o Sistema de Controle de Bilhetagem deve cumprir a norma internacional PCI-DSS Payment Card Industry Data Security Standard, ou equivalente, o que não é necessário.
Existem dois tipos de certificação PCI. São elas a PCI-PTS (PIN Transaction Security) e a PCI-DSS (Data Security Standard).
A certificação PCI-PTS (PIN Transaction Security) aplica-se para PINPADS. Para terminais que não são pinpad, a certificação é chamada SRED. Em ambos os casos, para que seja certificado PCI-PTS / SRED é necessário ter dispositivo anti-tamper no “invólucro” do produto. Para aplicações em Transporte Público, a experiência do mercado provou que com a trepidação inerente dos veículos esse tamper é disparado com certa frequência.
Já a certificação PCI-DSS (Data Security Standard), é uma certificação para a solução de Hardware + Software + backend com o objetivo de garantir sigilo de dados do cliente. Essa certificação não é do hardware, e sim da Solução completa, e não exige que o Hardware utilizado seja certificado PCI PTS, como por exemplo em soluções propostas com a utilização de LEITOR NFC que não tem pinpad. Em sua documentação, a certificação PCI se configura como uma recomendação e não uma obrigatoriedade.
Há outras maneiras de certificar que os dados dos clientes estão protegidos, como por exemplo o uso de uma chave forte (por exemplo TDES com DUKPT), que pertença a um Processador (Adquirente), garantindo assim que o criptograma gerado no momento da transação só poderá ser aberto pelo HSM do Adquirente, em ambiente protegido e certificado PCI. Dessa forma, todos os componentes entre a leitora e o HSM são considerados fora do escopo do PCI, pois estão trafegando encriptados. Ou seja, exigir que o Sistema de Bilhetagem seja PCI é o mesmo que exigir que a TIM, a Claro ou a Vivo sejam certificadas PCI-DSS, pois trafegarem dados de pagamento em suas redes, ainda que estejam encriptados. Para concluir, quem deve possuir a certificação PCI-DSS é o proprietário da chave criptografia dos dados, ou seja, quem processa os pagamentos (adquirente), pois todos os agentes que estão entre o leitor e o HSM que sabe ler a chave estão fora do escopo da certificação.
O edital não apresenta os requisitos mínimos de segurança para os métodos de pagamentos, tais como smart cards e QR Codes. Sistemas de bilhetagem atuais como o da SPTrans em São Paulo e o da Transurc em Campinas, para citar alguns, apresentam fraudes e brechas de segurança conhecidas, mas que as empresas fornecedoras de bilhetagem ainda não foram capazes de resolver.
A especificação para o Sistema de Controle de Bilhetagem ainda estabelece que o modelo aplicado deve permitir o desenvolvimento de novas funcionalidades e produtos conforme necessário, independentemente das características e funcionalidades já existentes, entretanto, a especificação não define quem será o responsável pelo desenvolvimento dessas novas funcionalidades e produtos e nem de que forma isso deve ser garantido, como por exemplo uma arquitetura baseada em microsserviços com APIs públicas que são asseguradas por chaves de autenticação.
O edital também estabelece que o Sistema de Controle de Bilhetagem deve reconhecer e prevenir ataques de fraude internos ou externos, mas não estabelece um requisito mínimo de prevenção a ataques como de Proxy, DDOS, Força Bruta, etc.
Sistema de Clearing
Em sua especificação, espera-se que o sistema de Clearinghouse suporte a intermediação de novos métodos de pagamento a serem incorporados de forma evolutiva ao decorrer do contrato. Como o edital faz menção ao PIX para viabilizar o recebimento de pagamentos dos usuários de transporte coletivo, mas a especificação não deixa clara se a aceitação do PIX deve ser apenas para creditar a conta dos usuários (ABT) ou como mecanismo de pagamento dos embarques nos validadores.
Caso a segunda opção seja um objetivo deste edital, recomendamos a sua reconsideração, uma vez que a transação PIX depende de conectividade com a internet e pode levar de 04 (quatro) a 10 (dez) segundos para ser efetivada, um cenário que não condiz com a realidade operacional do transporte público.
DW – Data Warehouse e Datalake
O edital não apresenta definições sobre segurança no Data Center quanto ao processamento, armazenamento e replicação dos dados, por exemplo. Além de que as estimativas de volumetrias e frequências apresentadas não são suficientes para estimar os custos envolvidos para então elaboração de uma proposta.
Proteção de Dados
Apesar de fazer menção a LGPD – Lei Geral de Proteção de Dados, exigindo sua compatibilidade com a Legislação, o edital não é claro na definição das responsabilidades uma vez que os dados sensíveis estão sob a responsabilidade da Plataforma 2. O edital não menciona como será feita a transferência desses dados e nem como eles estarão estruturados, organizados e armazenados.
Não identificamos no edital da Plataforma 1, nenhuma citação ao Marco Civil da Internet e suas consequências. O Marco Civil da Internet vai falar sobre crimes cibernéticos, diferentemente da LGPD que basicamente se refere a dados pessoais. Ao não definir as regras para restrição de conteúdos no serviço de Wi-Fi, o edital coloca em risco a provedora da Plataforma 1 caso um IP (Internet Protocol), por exemplo, seja utilizado em algum crime cibernético. Se o rastreamento deste crime não chegar ao usuário final, a provedora do acesso a provedora da Plataforma 1, poderá ser responsabilizada. Portanto, a definição das regras de restrição de acessos, assim como a autonomia para o trabalho de manutenção diário desta lista de restrições, deve estar delimitado no edital.
[crowdsignal rating=8915070]