AI agency in Utrecht
We build AI using sensor data and manage it in production. Together with ProRail’s Datalab, we’ve applied machine learning to fibre-optic signals.
Using machine learning on fibre-optic cables to automate train and wheel defect detection at ProRail
At ProRail’s Datalab, we explored together what Fiber-Optic Acoustic Sensing can do: fibre-optic cables measure sound waves. We used machine learning and AI to automate the detection of trains, track components and wheel defects, with the aim of making the rail network safer and more sustainable.
Who responds when the model flags an anomaly in the middle of the night?
A model monitoring trains, points or trams runs day and night. Every alert needs someone to act on it, and the model must remain accurate when a sensor or vehicle is replaced.
From sensor signal to a model that stays maintained
An alert from raw signals
For ProRail, we used machine learning on fibre-optic cables that measure sound waves to automate the detection of trains, railway components and wheel defects.
A workflow that keeps the model running
At Waternet, as part of the Datalab team, we set up and maintain the MLOps workflow, including an MLflow model registry and CI/CD templates.
Templates for the next model
For GVB, we set up an MLOps workflow in Databricks with reusable templates to put their segmentation model into production and maintain it.
Managed by the team that built it
Once live, we can monitor, retrain and continuously improve what we have built. We agree who will do that and how before the model goes live.
A model only goes live when the operations team knows what to do with an alert
-
The alert and who handles it
Which anomaly should the model flag, who receives the alert and what do they do with it?
-
Training on your own measurement series
We train on historical sensor data and check the alerts against what inspections and failures revealed.
-
Live with monitoring and an owner
When the model goes live, version control, drift monitoring and retraining are in place, and it is clear who intervenes.
Does our sensor data tell us enough to run a model in day-to-day operations?
A good fit if
Sensors, measurement trains or fault reporting systems have been collecting data for some time, and you can link that data to what happened: a defect, an inspection or a recorded fault.
Not a good fit if
A fixed threshold in the existing monitoring system already detects the anomaly, or nobody in operations has time to respond to an alert. In that case, a model only creates extra work.
What determines the scope
How many sensors and source systems are involved, how quickly an alert is needed, where the model runs, and how much monitoring and retraining it needs after going live.
Too many false alerts?
That is the biggest pitfall in detection. So the model runs alongside operations first, without anyone acting on its alerts, and we set the threshold together with the operations team.
Batch, near real-time or real-time: how quickly must an alert arrive?
One analysis per night
Choose this if the alert feeds into maintenance planning and nobody needs to respond immediately. Our advice: start here. It’s easier to manage, and you can make it faster later.
Near real-time
Choose this if an alert needs to reach the right person quickly, but not within seconds, as with a wheel showing a deviation. The model then runs at short intervals.
Real-time
Choose this if the alert needs to prompt immediate action. This requires streaming data, stricter monitoring and a plan for when the model fails.
We only take on ongoing management of what we’ve built ourselves
Data Science Lab has been around since 2016, is a partner of Databricks and Microsoft, and shares knowledge in its own lab. Based on Westerdoksdijk in Amsterdam, we work with you at your premises in Utrecht, at our office or online.

Just one anomaly your operations miss is reason enough for a first conversation
Stef Stoelwinder
Business DevelopmentStef is your first point of contact. In our first conversation, we’ll discuss which anomaly you want to detect, what sensor data is available and who will manage the model.
E-mail info@datasciencelab.nl
Phone +31 (0)20 3636 724
Which anomaly in your network would you like to spot sooner?
Describe the anomaly, the sensors or systems already providing data, and who currently responds to it. We’ll reply by email, or arrange an initial conversation.
Message sent
Thanks for your message. We’ll be in touch as soon as possible.
Frequently asked questions
An AI agency, or AI company, builds applications that use data to support decisions and keeps them running in production. In Utrecht, this often involves networks: ProRail has its headquarters at Moreelsepark, and the province owns the tram system.
We build these models as part of our AI applications. If you first need advice on which application to choose, read about our AI consultant in Utrecht.
With Fiber-Optic Acoustic Sensing, fibre-optic cables measure sound waves. The ProRail case study lists techniques including Fourier transforms, image segmentation using a U-Net model and Tensorflow, on Databricks and Azure. A Fourier transform breaks a signal down into its component frequencies.
For day-to-day operations, other questions arise: how many false alerts are acceptable, who responds, and what happens when a cable is replaced? Read the ProRail case study.
Version control for code and models, a model registry, a pipeline that tests and deploys new versions, and monitoring that sends an alert to whoever is responsible at the time. You also need an agreement on what the operations team does if the model fails.
At Waternet, as part of the Datalab team, we set up and maintain an MLOps workflow with an MLflow model registry and CI/CD templates. Read about how it works under MLOps.
Its input changes. A new cable, a different type of wheel or a renewed section of track produces signals the model does not recognise. It still generates alerts, but they become less accurate. This is called drift.
That is why we monitor inputs and predictions and retrain the model when needed. For GVB, we established an MLOps lifecycle because its segmentation model needed to stay up to date as things changed over the years.
Yes, provided there is a history of maintenance and faults that you can compare with the measurement series. According to the province of Utrecht’s Beheervisie Tramsysteem 2020-2024, the province owns the assets, while the Trambedrijf Beheer en Onderhoud team manages the local rail infrastructure.
With maintenance records for trams, rails and points, you can predict where maintenance is needed. Read more about predictive maintenance and AI for infrastructure management.
Possibly. Point 2 of Annex III of the AI Act covers systems intended as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating or electricity. Rail systems fall under the European product rules in Annex I.
Under the AI omnibus, the requirements of Annex III apply from 2 December 2027. Legal interpretation is for your lawyer or compliance department; we can help identify the relevant systems and propose a risk classification. See AI Act.
Yes, if your team has experience with models in production. We then agree in advance who owns the model, who receives alerts, when it is retrained and who approves a new version. If you lack the capacity, you can hire an MLOps engineer.
If we continue to manage it, we do so through AI Managed Services. We only manage solutions we have developed ourselves.
If a fixed threshold in your monitoring system already detects the anomaly reliably, or if the operations team mainly needs a clearer overview, a dashboard built on your existing data will help more than a model.
If you do not yet know whether the signals contain enough information, explore the data first. That is what our data science agency in Utrecht is for. Building a model only makes sense if you can demonstrate a relationship.
How do we build applications, and how do we keep a model running in production?
- AI applicationsAn overview of our applications: prediction, detection in images and signals, text and generative AI.
- Data science consultancy in UtrechtPredictive models for healthcare and services in and around Utrecht, from data to validation.
- MLOpsModel registry, testing and deploying versions, drift alerts and a set schedule for retraining.