Ir para o conteúdo

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.

Leia o caso de estudo

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.

Agende uma conversa

Do sinal do sensor a um modelo com manutenção contínua

Fale connosco sobre o seu alerta

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

  1. O alerta e quem o trata

    Que anomalia deve o modelo detetar, quem recebe o alerta e o que faz essa pessoa com ele?

  2. 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.

  3. 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?

Avalie-o numa conversa

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.

Agende uma reunião de apresentação

Uma anomalia que a sua operação não deteta basta para uma primeira conversa

Stef Stoelwinder

Stef Stoelwinder

Desenvolvimento de Negócio

Stef é 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.

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.

Introduza um endereço de e-mail válido.

Diga-nos como podemos ajudar.

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.