Every platform on a shortlist says it does real-time processing, OT protocol support, and security by design. The differences that matter do not appear in feature lists. They show up in how the platform behaves when connectivity drops, who is responsible when something goes wrong, and what the third deployment looks like compared to the first.
This checklist is for teams that have already decided edge computing is the right architecture and are now comparing platforms. For the earlier question of whether to go edge at all, start with the [main guide].
1. Protocol coverage at your specific assets
Ask vendors for the complete list of supported protocols, not a general "yes we support OT." Common requirements in offshore: OPC-UA, Modbus, WITS/WITSML, proprietary OEM formats from NOV, Schlumberger, Halliburton. Maritime: NMEA 0183, NMEA 2000, proprietary engine and navigation protocols. Renewables: IEC 61850, Modbus, SunSpec. Manufacturing: OPC-UA, Profibus, EtherNet/IP, proprietary PLC formats.
If a protocol is not on the list, ask how long a new adapter takes to build and who owns that work.
2. Behavior during connectivity loss
Most platforms claim they work offline. Ask specifically: what stops when the uplink drops? Which control actions continue? Which dashboards go stale? Which alerts are queued and which are dropped?
A platform that buffers locally and syncs when connectivity returns is a different product from one that stops processing new data when the uplink goes down. Get the specific answer in writing and test it in a proof of concept before committing.
3. Who owns the full stack
Industrial edge deployments almost always span multiple vendors: device manufacturer, platform software, connectivity provider, SCADA integrator, possibly a system integrator above all of them. When something breaks, the question of who is responsible gets passed between parties.
A platform covering device management, application runtime, security, protocol integration, and cloud connectivity in one product has one accountable party. A five-vendor stack does not.
Ask vendors to define exactly where their responsibility ends. The answer tells you what you are taking on.
4. Security architecture
Security posture is a marketing claim. Security architecture is verifiable.
Ask: Are device identities certificate-based? Is remote access governed by a central policy or configured per site? Are OTA updates signed before deployment? Is there a complete access log per device per session, available for audit without a data extraction project?
The EU Cyber Resilience Act requires certificate-based device identity across the full product lifecycle. NIS2 requires audit-ready access logs for essential entities. Platforms that handle both structurally reduce pre-audit work from weeks to hours.
5. Deployment speed and operational overhead
Ask for an actual deployment timeline from a recent customer deployment, not the estimate from a sales deck. Helin deployed across 100+ Boskalis vessels in under two weeks. That is a verifiable reference point.
Then ask: what does your team need to do per site? What does the vendor do? What does deployment at site 20 look like compared to site one? Platforms with a defined onboarding process get faster with scale. Ones that treat every deployment as a new integration project stay expensive.
6. Application extensibility
The initial deployment rarely covers every use case the operator eventually needs. Ask what it takes to add a new application after go-live. Can the operator deploy their own applications, or only what the vendor builds? What does integrating a third-party application require?
Platforms built as an application runtime, where any containerised application can be deployed, governed, and updated centrally, are more extensible than platforms where the vendor roadmap is the ceiling.
7. Hardware dependency
Ask whether the platform requires proprietary hardware. Some vendors lock the software to their own units. Others, including Helin, run on customer-supplied hardware and provision from the OS up. For asset estates where hardware replacement is not on the table, the distinction matters from day one.
Red flags in vendor conversations
- Proof points using "up to" without naming the deployment or methodology
- Feature descriptions with no reference deployments at your asset type
- Security claims describing policies rather than architecture
- Deployment timelines given as ranges rather than named customer references
- Answers to "what happens when the uplink drops" that redirect to connectivity redundancy instead of describing offline behavior
The shortlist decision
Once you have run this checklist, the gaps become visible. A platform with named, verifiable deployments at comparable assets is a different category from one that claims the same things without the evidence.
Helin has named deployments across offshore drilling (Noble, BP), maritime (Boskalis, 500+ vessels), and renewables (Sunrock, 300 solar farms). If your evaluation covers any of those asset types, we can connect you with the relevant reference.
Back to the main guide: Industrial edge computing, what it is and how it works
By Helin