Manufacturer as a technology partner

Remote reading of water, heat or gas meters today starts with a request that was uncommon few years ago: customers want data in a clearly documented format, integrated into their own environment, without one-off scripts and without compromising security. This shifts the role of the IoT device manufacturer.

The "box" with a radio module is no longer enough on its own. Without parsers, an open API, remote management and a documented firmware lifecycle, a project either fails to reach production or ends up in a grey zone that the internal development team has to maintain long-term.

The shift from hardware supplier to technology partner is not a marketing position. It is a practical consequence of how today's AMR (Automated Meter Reading) and AMI (Advanced Metering Infrastructure) projects look: hundreds to thousands of devices, several meter types, multiple communication layers (M-Bus, wM-Bus, LoRaWAN, NB-IoT) and an upstream system that expects a consistent payload across firmware versions.

What "complete solution" means today

A modern manufacturer of IoT converters typically delivers four layers that need to hold together:

• Hardware with tailored configuration: a converter prepared for a specific meter type, communication profile and network topology, not a universal device requiring manual pairing in the field.

• Software tools and parsers: documented parsers for payload decoding, an open API for direct integration into the upstream system, a clear data contract version. One concrete example is the M-Bus installation tool Wizard from ACRIOS, which guides technicians through configuration step by step.
• Backend components for on-prem deployment: containerised applications (e.g. in Docker) that can run on the customer's own infrastructure without dependence on a third-party cloud.
• Remote management and firmware updates: OTA updates, remote diagnostics, controlled rollout of new versions across the fleet without physical interventions in the field.

‍

When these layers exist side by side and remain mutually compatible, most of the "glue" work disappears. The customer's internal development team focuses on business logic and proprietary applications, not on tuning format conversions or writing one-off adapters between two systems that fail to understand each other.

Concrete benefits in project terms

• Shorter implementation: pre-built integrations, documented APIs and ready-made parsers shorten the path from "we want to measure" to "we have data in the system" from months to weeks.
• Lower load on internal development: customer teams handle their own application logic, not payload structures and decoding routines.
• Easy scaling: adding a new site or another few hundred devices is a repeatable process, not a new integration analysis.
• Long-term sustainability: the manufacturer maintains compatibility across firmware versions, addresses regulatory changes and provides security updates throughout the lifecycle.

Security is not an audit, it is a routine

The security layer in IoT is not a one-off certification. It is an ongoing process: device authentication, encrypted transmission, access control, signed firmware updates, controlled versioning and a documented recovery procedure after an outage. Without a stable data contract, the cost of measurement errors quickly compounds.

Under the CRA (Cyber Resilience Act, EU Regulation 2024/2847), this also stops being optional. Reporting obligations for manufacturers start applying from September 2026, with full application from December 2027. From that date, only products with digital elements that meet security requirements throughout the lifecycle may be placed on the European market, including mandatory reporting of actively exploited vulnerabilities within 24 hours and the provision of security updates for the expected lifetime of the product (in practice at least 5 years).

For operators of AMR and AMI infrastructure, the practical consequence is clear: choosing a manufacturer that does not actively address the CRA shifts the compliance risk onto the customer. A manufacturer acting as a partner handles this obligation as part of the product, from documentation through vulnerability management to support during incident reporting.

Practical scenarios from the field

In practice, the combination of product and services typically takes three forms:

Water utilities

Water utility operator deploys ACRIOS converters on existing water meters and within a few weeks has reliable remote reading. Supplied parsers and documented APIs cut integration into the upstream system from months to days.

District heating

A pilot at one district heating site is followed by rollout to other buildings using the same procedure, without a new integration phase. Converter configuration is repeatable, the data contract remains stable.

Gas utilities

Communication security and compliance with standards for sensitive meters, are critical here. A manufacturer-partner monitors the regulatory framework (CRA, EED), maintains compatibility across gas meter generations and delivers remote updates without on-site visits.

Openness as insurance against vendor lock-in

Concerns about technological dependence are legitimate. The answer lies in choosing a partner committed to openness: documented APIs, described data formats, support for open protocols, containerised backend components for self-hosted operation and transparent versioning. When these elements are in place, partnership does not mean loss of control. On the contrary, the customer keeps data in their own environment, in a format they can parse independently at any time.

Impact on TCO

From a total cost of ownership perspective, the equation is straightforward. Shorter implementation and fewer service interventions translate into immediate savings. Stable interfaces and a versioned data contract dampen hidden costs that otherwise arrive with every firmware or upstream system change. Remote management eliminates technician visits to individual converters. And because data flows in a predictable format, building proprietary analytics and decision logic on top of it becomes easier, whether in internal systems or in the cloud.

A manufacturer-partner does not pull control to themselves. They give the customer clean, documented data foundations and tools to work with according to their own rules.

Key takeaways

The shift from hardware supplier to technology partner is about how the lifecycle of an IoT project actually unfolds. Ready-made parsers, an open API, a containerised backend and remote firmware management shorten implementation, reduce the load on internal development and keep compliance with frameworks such as the CRA on the manufacturer's side, not the customer's. For operators of AMR and AMI infrastructure, this translates in practice into lower TCO, a stronger security posture and data that can be relied on for further decision-making.