Case study. Live
SYNAPSE: keeping a distributed device fleet under control
Ledwalls, information screens, totems and remote units installed in different places, with a maintenance contract behind them. SYNAPSE brings into one tool what is installed, how it is doing, what has been reported and who is working on it. It runs today on two fleets of very different size, for the same client.
Written by Maximilian Giurastante. .
SYNAPSE is a web platform for monitoring and maintaining distributed device fleets: an asset register of the units with the parts installed in them, live status, alerts opened automatically, job management, the cycle a faulty part goes through, a spare parts store and scheduled maintenance. MAXYMIZE builds it to order and installs it on the client network.
Project summary
- Sector
- Audio-video systems integration and digital signage, maintenance contracts
- Client
- A systems integrator, for its own end customers (name withheld)
- Live installations
- Two: around 200 ledwall and totem installations at a large Italian airport; a national network of screens in retail outlets, with over 60,000 devices on the register
- Users
- Field technicians, spare parts store, administrators, end customer in read-only
- First version in use
- Seven weeks from the start of the project, with the scope split into three tiers
- Status
- Live on both fleets, development still going on
- Installation
- On the client network, with backups and an operations log
- Engagement model
- Fixed-price project for the first version, then ongoing support
The starting point
Anyone who maintains a device fleet does not have a technology problem, they have a traceability problem. Every job has to be documented for the customer, every faulty part has a route back, every spare part costs money. When that information lives in separate tools, the first thing you lose is the answer to "what happened to this device over the last six months".
The client is an audio-video systems integrator that runs maintenance contracts on fleets installed at its own customers. The first fleet handed to the platform is the ledwall and totem installations of a large Italian airport: signage and information screens spread across terminals, gates and outdoor areas, each with its own modules, receiving cards, power supplies and controllers.
The tools in use before the platform
- A spreadsheet listing the installations, updated by hand and with no history of the parts replaced.
- A monitoring system already installed on the units, giving one traffic light per device: it says whether a screen is on, not what happened to it.
- The end customer's reports, which arrive by email and are read, interpreted and retyped by hand.
The problem was not a lack of data, it was that none of that data spoke to the rest: the status detected did not open a job, the job did not know which parts were installed, the part replaced did not come off the stock. And a part taken out of a unit fell out of traceability the moment it was removed.
What the platform does
SYNAPSE holds together five things that usually live apart: what is installed, how it is doing, what has been reported, who is working on it and what has been replaced. The value is in none of the five on its own, it is in the fact that they are connected and that every step stays in the history of the device.
The loop the platform closes
A five step loop: register of what is installed, status detected in real time, alert opened automatically, job assigned and tracked, spare part taken off the stock. From the spare part it goes back to the register, which stays up to date.
- 1. Register: what is installed
- 2. Detected status: in real time
- 3. Alert: opened automatically
- 4. Job: assigned and tracked
- 5. Spare part: taken off the stock
A register with the parts inside it
Every device has a record with its location, specifications, network details and the parts physically installed in it, with model and serial number. It is the piece a spreadsheet does not have and the one that makes all the rest possible, because a fault is recorded against the part and not against the installation in general.
Alerts that open on their own
The platform watches the status of the devices and opens an alert when a unit goes into fault, without duplicating the ones already open. Alongside the automatic alerts sit the ones entered by technicians and the ones coming in from the end customer's channels, so there is a single queue of jobs instead of three.
The cycle of faulty parts
A part taken out does not disappear into a box: it enters a sequence of states that the platform enforces, from quarantine to the decision whether to repair it, return it to the supplier or send it for disposal, through to going back in stock. The transitions allowed are the ones in the client's own procedure, and a step the process does not foresee is refused.
The route of a faulty part
A six step flow: quarantine, assessment, in-house repair, testing, back in stock, disposal. From the assessment a part can go out as a supplier return and rejoin at testing, or go straight to disposal if it cannot be repaired.
- 1. Quarantine: part taken out
- 2. Assessment: repairable or not
- 3. Repair: technician and dates
- 4. Testing: result recorded
- 5. Back in stock: returns to the store
- 6. Disposal: not repairable
- Assessment → Testing (supplier return)
- Assessment → Disposal (not repairable)
Spare parts store and scheduled maintenance
The store handles stock levels, reorder thresholds, reservations tied to a job and compatibility between spare parts and devices, with the guarantee that a stock level cannot go below zero even with several people working at once. At the other end, the periodic maintenance the contract calls for does not depend on anybody remembering it: the platform works out the due dates per device and opens the job in advance.
Who sees what
Four access profiles with distinct permissions: administrators, field technicians, spare parts store and the end customer in read-only. That last one is the profile that changes the commercial relationship, because the customer checks the state of its own fleet and the maintenance due dates instead of asking for them. Where it helps, the same read-only view is available as an operations room view, made for a wall monitor and readable from a distance.
Two fleets, two scales
The same platform now serves two fleets that differ in both nature and size: the installations of a single large site, and a network of information screens spread across retail outlets all over Italy. That is the most useful evidence for anyone assessing it, because the model is not tied to one type of device or to one order of magnitude.
In the concentrated fleet the work revolves around the installation and its parts: whoever steps in is on site, the spare parts are in the store, scheduled maintenance sets the rhythm of the year. In the distributed network the centre of gravity moves: the devices are tens of thousands, scattered across the country, and what counts is working out which of them need attention, with what priority and for how long. The sources change too, because on a fleet of that size the register and the status live in third party systems that the platform reads and never writes to.
What changes between the two fleets
| Aspect | Fleet concentrated in one site | Network spread across the country |
|---|---|---|
| Order of magnitude | Around 200 installations | Over 60,000 devices on the register |
| Distribution | A single site, technicians on the spot | Retail outlets all over Italy |
| What is watched | The installation and the individual parts in it | Reachability, activity and versions of the device |
| Where the data comes from | Monitoring system already installed | Third party systems, read only |
| Jobs | Team on site, spare parts in the store | Remote actions and visits to the outlet |
| Main view | Installation list and job queue | Fleet dashboard and operations room view |
Making the data trustworthy before showing it
On a large fleet the problem is not collecting the data, it is deciding which of it deserves to appear. A dashboard showing numbers nobody recognises stops being opened after a week, and the platform goes with it. It is the least visible part of the work and the part that decides whether the tool gets used.
- The source lists contain devices that no longer exist. Decommissioned, replaced or switched on only for a test: they have to be excluded on explicit criteria, otherwise every count is inflated and nobody takes it seriously.
- Alerts that are not relevant have to be turned off by type. On a fleet of tens of thousands of devices they arrive in the thousands, often from known configurations. Each type can be switched off and back on, so the only ones left visible are the ones somebody actually acts on.
- Different measurements do not add up. Devices watched with different tools belong to different populations: the platform keeps the counts separate and states the base of each one, instead of producing a total that means nothing.
- How fresh the data is counts as information, not as a detail. Every view says when it was last updated and flags it when it stops being updated: a dashboard that has frozen but looks alive is worse than one that is off.
Results
The first version went into use seven weeks after the start, with the technicians opening, assigning and closing jobs from the platform. Since then the system has grown in iterations, on the needs that come out of using it, and it is now in production on both fleets.
- 2
- live fleets on the same platform (a single site and a national network)
- 7
- weeks from the start to the first version in use (scope split into three tiers before starting)
- 60,000+
- devices handled on the larger fleet (against around 200 installations on the first)
- 4
- access profiles with distinct permissions (including the end customer in read-only)
What the platform changed straight away is traceability: every device has a history you can read, every part taken out has a state, every stock movement has an author and a date. Alerts become jobs with no manual steps and scheduled maintenance opens by itself, while the end customer checks the state of its own fleet without having to ask for it.
Which fleets it fits
SYNAPSE started on ledwalls, but it is not tied to that kind of device: it holds for any network of remote devices that do something, report a status and have somebody behind them who has to keep them running.
- Information screens, ledwalls, totems and kiosks installed at third party sites.
- Network equipment and room devices spread across several sites.
- Sensors and industrial units under periodic maintenance contracts.
- Any fleet where the same three questions matter: which devices need attention, who is working on them and what has been replaced.
If you are weighing up a tool like this, the page on costs and how we work explains how a fixed-price project with later support is put together, and the custom software development service page describes how we work from analysis to release.
Technologies used
Technologies chosen for a system that has to run on a client network, be maintained for years and be picked up by people other than the ones who wrote it.
Application
- Web application
- Usable from a phone as well
Data
- Relational database
- Operations log
- Automatic backups
Access
- Central authentication
- Permissions by role
Operations
- Installed in containers
- On the client network
Frequently asked questions
What can SYNAPSE monitor?
Any fleet of remote devices that report a status: ledwalls and information screens, totems and kiosks, network equipment, sensors and machines under maintenance contracts. The two installations in production today cover ledwall installations at a large site and a national network of screens in retail outlets, but the model does not depend on the type of device.
How long did the first version take?
Seven weeks from the start of the project to the first version used by the technicians. The scope had been split into three tiers before starting, and the first version contained only the first one: the register with the parts, the import of the existing data, the cycle of faulty parts, jobs and access profiles. The rest arrived in later iterations.
Does the monitoring system already in use have to be replaced?
No, and that is a deliberate choice. SYNAPSE reads the existing monitoring systems and turns their signals into status, alerts and history. Replacing a network of probes that is already installed would push the project back by months without changing the result for the people who use it, and in many cases it is not even possible.
Where are the platform and the data installed?
On the client network, with periodic backups and an operations log. It is the usual requirement when the data concerns infrastructure or retail outlets belonging to third parties. Where that constraint is not there, the same platform can be hosted on managed infrastructure: the configuration changes, the product does not.
How many devices can it handle?
The largest fleet in production today is over sixty thousand devices on the register. At that size the limit is not the capacity of the system but the quality of the incoming data and the selection of what deserves to appear: that is where the work goes, and the platform has the controls to do it.
Can the end customer see the state of its own fleet?
Yes, with a read-only profile showing status, jobs and maintenance due dates, with nothing it can change. Where it helps, the same view is available as an operations room view for a wall monitor. It is the feature that cuts the "what is the status" phone calls the most.
Written by Maximilian Giurastante
Founder and software developer, MAXYMIZE. Designs and builds SaaS platforms, custom business software and automations with language models. Over twenty years as a project leader in technology, audio and video systems integration.
Do you have a device fleet to keep under control?
Tell us how you run it today, even if it is a spreadsheet. In thirty minutes we work out together whether you need a platform and which piece to start from.