Agência de IA em Utrecht
Desenvolvemos IA com dados de sensores e gerimo-la em produção. Em conjunto com o Datalab da ProRail, aplicámos machine learning a sinais de fibra ótica.
Machine learning em fibra ótica para automatizar a deteção de comboios e defeitos nas rodas na ProRail
No Datalab da ProRail, explorámos em conjunto o que a tecnologia Fiber-Optic Acoustic Sensing pode fazer: cabos de fibra ótica medem ondas sonoras. Usámos machine learning e IA para automatizar a deteção de comboios, componentes da via e defeitos nas rodas, com o objetivo de tornar a rede ferroviária mais segura e sustentável.
Quem responde quando o modelo sinaliza uma anomalia a meio da noite?
Um modelo que monitoriza comboios, agulhas ou elétricos funciona dia e noite. Cada alerta precisa de alguém que lhe dê seguimento, e o modelo tem de continuar a produzir resultados fiáveis quando um sensor ou veículo é substituído.
Do sinal do sensor a um modelo com manutenção contínua
Um alerta a partir de sinais brutos
Para a ProRail, utilizámos machine learning em cabos de fibra ótica que medem ondas sonoras para automatizar a deteção de comboios, componentes da via férrea e defeitos nas rodas.
Um workflow que mantém o modelo em funcionamento
Na Waternet, como parte da equipa Datalab, criamos e mantemos o workflow de MLOps, com um model registry de MLflow e templates de CI/CD.
Templates para o próximo modelo
Para a GVB, configurámos em Databricks um workflow de MLOps com templates reutilizáveis para colocar o seu modelo de segmentação em produção e mantê-lo.
Gestão por quem desenvolveu o modelo
Depois de entrar em produção, podemos monitorizar, voltar a treinar e melhorar continuamente aquilo que desenvolvemos. Definimos quem o fará e como antes de o modelo entrar em produção.
Um modelo só entra em produção quando a equipa operacional sabe o que fazer com um alerta
-
O alerta e quem o trata
Que anomalia deve o modelo detetar, quem recebe o alerta e o que faz essa pessoa com ele?
-
Treinar com as suas próprias séries de medições
Treinamos com dados históricos de sensores e verificamos os alertas à luz do que as inspeções e as avarias revelaram.
-
Em produção, com monitorização e um responsável
Quando o modelo entra em produção, o controlo de versões, a monitorização de drift e o retreino estão preparados, e está definido quem intervém.
Os nossos dados dos sensores são suficientes para um modelo funcionar nas operações?
Adequado se
Os sensores, comboios de medição ou sistemas de registo de avarias já recolhem dados há algum tempo, e é possível relacionar esses dados com o que aconteceu: um defeito, uma inspeção ou uma avaria registada.
Não é adequado se
Um limiar fixo no sistema de monitorização existente já deteta a anomalia, ou ninguém na equipa operacional tem tempo para responder a um alerta. Nesse caso, um modelo só cria trabalho adicional.
O que determina a dimensão
O número de sensores e sistemas de origem envolvidos, a rapidez com que é necessário emitir um alerta, onde o modelo é executado e quanta monitorização e treino adicional serão necessários após a entrada em produção.
Demasiados falsos alertas?
Esse é o maior risco na deteção. Por isso, o modelo funciona primeiro em paralelo, sem que ninguém atue com base nos seus alertas, e definimos o limiar em conjunto com a equipa operacional.
Em lote, quase em tempo real ou em tempo real: com que rapidez deve chegar um alerta?
Uma análise por noite
Opte por esta abordagem se o alerta servir para planear a manutenção e não exigir uma resposta imediata. O nosso conselho: comece por aqui. A gestão é mais simples e pode acelerar o processo mais tarde.
Quase em tempo real
Opte por esta abordagem se o alerta tiver de chegar rapidamente à pessoa certa, mas não ao segundo, como no caso de uma roda com um desvio. O modelo é então executado em intervalos curtos.
Em tempo real
Opte por esta abordagem se o alerta exigir uma ação imediata. Isto requer streaming data, uma monitorização mais rigorosa e um plano para o caso de o modelo falhar.
Só assumimos a gestão posterior do que construímos
A Data Science Lab existe desde 2016, é parceira da Databricks e da Microsoft e partilha conhecimento no seu próprio laboratório. A partir da Westerdoksdijk, em Amesterdão, trabalhamos consigo nas suas instalações em Utrecht, no nosso escritório ou online.

Uma anomalia que a sua operação não deteta basta para uma primeira conversa
Stef Stoelwinder
Desenvolvimento de NegócioStef é o seu primeiro ponto de contacto. Na primeira conversa, falamos sobre a anomalia que pretende detetar, os dados dos sensores disponíveis e quem ficará responsável pela gestão do modelo.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
Que anomalia na sua rede gostaria de detetar mais cedo?
Descreva a anomalia, os sensores ou sistemas que já fornecem dados e quem reage atualmente. Receberá uma resposta por email, ou agendamos uma primeira conversa.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
Perguntas frequentes
Uma empresa de IA desenvolve aplicações que usam dados para apoiar decisões e garante que continuam a funcionar em produção. Em Utrecht, isto envolve muitas vezes redes: a ProRail tem a sua sede em Moreelsepark e a província é proprietária do sistema de elétricos.
Desenvolvemos estes modelos no âmbito das nossas aplicações de IA. Se precisar primeiro de aconselhamento sobre que aplicação escolher, leia sobre o nosso consultor de IA em Utrecht.
Com Fiber-Optic Acoustic Sensing, os cabos de fibra ótica medem ondas sonoras. O caso de estudo da ProRail menciona técnicas como transformadas de Fourier, segmentação de imagens com um modelo U-Net e Tensorflow, em Databricks e Azure. Uma transformada de Fourier decompõe um sinal nas frequências que o constituem.
Na operação, surgem outras questões: quantos falsos alertas são aceitáveis, quem responde e o que acontece quando um cabo é substituído? Leia o caso de estudo da ProRail.
Controlo de versões do código e do modelo, um model registry, uma pipeline que testa e implementa novas versões e monitorização que envia um alerta a quem é responsável nesse momento. É também preciso definir o que a equipa de operações faz se o modelo falhar.
Na Waternet, enquanto parte da equipa Datalab, implementamos e mantemos um workflow de MLOps com um model registry em MLflow e templates de CI/CD. Saiba como funciona em MLOps.
Os dados de entrada mudam. Um cabo novo, um tipo diferente de roda ou um troço de via renovado produzem sinais que o modelo não conhece. O modelo continua a gerar alertas, mas estes tornam-se menos precisos. A isto chama-se drift.
Por isso, monitorizamos os dados de entrada e as previsões e voltamos a treinar o modelo quando necessário. Para a GVB, estabelecemos um ciclo de vida de MLOps porque o seu modelo de segmentação tinha de acompanhar as mudanças ao longo dos anos.
Sim, desde que exista um histórico de manutenção e avarias que possa ser comparado com as séries de medições. Segundo a Beheervisie Tramsysteem 2020-2024 da província de Utrecht, os ativos pertencem à província e a equipa Trambedrijf Beheer en Onderhoud gere a infraestrutura ferroviária local.
Com o histórico de manutenção dos elétricos, carris e agulhas, é possível prever onde será necessária manutenção. Saiba mais sobre predictive maintenance e IA para a gestão de infraestruturas.
Possivelmente. O ponto 2 do anexo III do Regulamento da IA abrange sistemas destinados a ser componentes de segurança na gestão e exploração de infraestruturas digitais críticas, do tráfego rodoviário e do fornecimento de água, gás, aquecimento ou eletricidade. Os sistemas ferroviários estão abrangidos pelas regras europeias para produtos do anexo I.
Com o pacote omnibus relativo à IA, os requisitos do anexo III aplicam-se a partir de 2 de dezembro de 2027. A interpretação jurídica cabe à sua equipa jurídica ou de compliance; ajudamos a identificar os sistemas relevantes e a propor uma classificação de risco. Consulte AI Act.
Sim, se a sua equipa tiver experiência com modelos em produção. Nesse caso, definimos antecipadamente quem é responsável pelo modelo, quem recebe os alertas, quando é feito um novo treino e quem aprova uma nova versão. Se não tiver capacidade suficiente, pode contratar um engenheiro de MLOps.
Se continuarmos a assegurar a gestão, fazêmo-lo através de AI Managed Services. Gerimos apenas soluções que desenvolvemos.
Se um limiar fixo no seu sistema de monitorização já detetar a anomalia de forma fiável, ou se a equipa de operações precisar sobretudo de uma visão de conjunto, um dashboard com os dados disponíveis será mais útil do que um modelo.
Se ainda não souber se os sinais contêm informação suficiente, explore primeiro os dados. É para isso que existe a nossa empresa de data science em Utrecht. Só faz sentido desenvolver um modelo se for possível demonstrar uma relação.
Como desenvolvemos aplicações e mantemos um modelo a funcionar em produção?
- Aplicações de IAUma visão geral das nossas aplicações: previsão, deteção em imagens e sinais, texto e IA generativa.
- Consultora de data science em UtrechtModelos preditivos para a saúde e os serviços na região de Utrecht, desde os dados até à validação.
- MLOpsModel registry, testes e implementação de versões, alertas de drift e um momento definido para voltar a treinar o modelo.