Every OEM developing smart equipment today faces the same fork in the road. Build the software stack in-house, from protocol drivers up through the user interface, or find a foundation that already handles the parts that don't differentiate the product. The first path can take years and pull engineering resources away from the features that actually set a product apart. The second path is where most successful smart equipment programs land.
This post breaks down what it actually takes to build smart connected equipment, why so many OEM software projects stall out, and how a framework-based approach changes the math on speed to market.
A software framework is a pre-built software layer that an equipment manufacturer embeds into its own product rather than developing from the ground up. Instead of writing protocol drivers, building a graphics engine, and standing up edge-to-cloud connectivity in isolation, an OEM licenses or partners around a framework that already includes those capabilities and builds its differentiated application on top.
In practice, this covers several layers of the stack:
A framework doesn't replace an OEM's engineering team. It gives that team a starting point that already handles the common, non-differentiating parts of the stack, so their time can focus on the features that differentiate the product in the market.
On paper, building a proprietary software platform sounds straightforward: hire developers, write the code, ship the product. In practice, OEMs run into the same set of obstacles again and again.
The scope is bigger than it looks. A smart connected equipment platform is more than just a single piece of software. It's a controller operating system, a protocol integration layer, a graphics and visualization engine, a data historian, an analytics layer, and often a cloud service to tie it all together. Each of those is a multi-year engineering effort on its own.
Multi-vendor interoperability is a moving target. Buildings rarely run on a single protocol or a single vendor's equipment. An OEM's controller has to coexist with systems built by other manufacturers, on other protocols, installed at different points in the building's history. Supporting that reliably means building and maintaining integration for multiple standards at once, and keeping up as those standards evolve.
Compliance and security requirements keep expanding. Regulations like the EU's Energy Performance of Buildings Directive and the Cyber Resilience Act are pushing connected equipment toward stricter requirements around interoperability, energy monitoring, and security by design. Meeting those requirements from scratch means dedicating engineering time to compliance work instead of product features.
Opportunity cost compounds. Every month spent building protocol drivers or a graphics framework is a month not spent on the control logic, energy optimization, or product experience that actually differentiates the equipment in the market. Competitors who start from an existing foundation get to that differentiation faster.
The result is a familiar pattern: OEMs commit to a from-scratch platform, timelines stretch from months into years, and the team ends up maintaining commodity infrastructure instead of building the product roadmap they set out to deliver.
The obstacles outlined above play out differently depending on which path an OEM chooses. Here's how the two approaches compare across the layers of a connected equipment platform.
| Building From Scratch | Building on an OEM Framework | |
|---|---|---|
| Embedded software | Written and maintained in-house from the ground up | Pre-built controller software; OEM adds product-specific logic on top |
| Protocol integration | Each protocol (BACnet, Modbus, KNX, MQTT, OPC UA, etc.) built and maintained separately | Multi-protocol support already included and kept current as standards evolve |
| Custom applications | Built alongside the rest of the stack, competing for the same engineering time | Built on existing APIs, so engineering time goes straight to differentiation |
| Edge deployment | Local processing and offline operation designed and tested from zero | Edge capability already built in and proven across other deployments |
| Visualization | Graphics engine and dashboards designed and built in-house | Configurable, brandable dashboards ready to adapt to the product |
| Analytics | Data pipeline, fault detection, and energy insights developed independently | Analytics tools already in place; OEM tunes them to the product |
| Compliance and security | OEM tracks and implements every new regulation (e.g., EPBD, Cyber Resilience Act) on its own | Framework updated centrally as regulations evolve |
| Time to market | Often multiple years before a full-featured product ships | Commonly months from concept to market-ready product |
| Engineering focus | Split between commodity infrastructure and product differentiation | Concentrated on the features that set the product apart |
| Ongoing maintenance | OEM owns the full stack, including parts that don't differentiate the product | Framework provider maintains the shared foundation |
The pattern is consistent across each row: building from scratch means an OEM's engineering team is responsible for every layer, including the parts that don't set their product apart. Building on a framework shifts that shared, non-differentiating work off their plate, so the team's time goes toward the control logic, product experience, and features that actually matter to the customer.
Consider an HVAC manufacturer that wants to launch a next-generation plant room controller. The business goal is straightforward: give facility teams a controller with graphics-rich dashboards, energy performance tracking, and remote monitoring, and get it to market before competitors close the gap.
Built entirely from scratch, this project touches nearly every layer of the stack. Engineering has to build the embedded control logic for the equipment, a protocol layer to talk to other building systems on-site, a graphics engine for the operator dashboards, and a data pipeline to support energy analytics. Realistically, that's a multi-year build before the first unit ships.
Starting from an OEM framework changes the shape of the project. The out-of-the-box application suite, protocol integration, and dashboard tools are already there. The manufacturer's engineers focus their time on what makes this controller theirs: the control sequences, the energy optimization logic, and the product's specific workflows. The graphics and visualization layer can be branded and configured for the manufacturer's own product identity rather than built from zero. Edge deployment means the controller can run its logic locally, without depending on a constant cloud connection, while still feeding data upstream for fleet-level analytics.
This is the pattern behind several real OEM launches in building automation: an Italian HVAC manufacturer used exactly this approach to bring a plant room controller to market with graphics-rich dashboards and energy performance features already built in, shortening the development timeline so their team could focus on tailoring the product to their markets. A ventilation equipment supplier took a similar approach to build advanced monitoring and ventilation management into its own branded platform. In both cases, the manufacturer owns the product and the customer relationship. The framework just removes the commodity engineering from the critical path.
What is the difference between building a custom platform and using an OEM framework? Building a custom platform means developing every layer of the software stack in-house, from embedded control logic to protocol drivers to the user interface. An OEM framework provides those foundational layers as a starting point, so engineering time goes toward the application logic and features that differentiate the product, rather than infrastructure that every connected device needs.
Does using a framework mean giving up control over the product? No. OEMs that build on a framework still own their product, their branding, and their customer relationships. The framework provides the underlying software layers; the OEM's team builds and owns the application logic, user experience, and go-to-market strategy on top of it.
How does edge deployment fit into a connected equipment strategy? Edge deployment means equipment can run its control logic and process data locally, without depending on a constant connection to the cloud. This matters for reliability in environments with limited connectivity and for reducing the latency of time-sensitive control decisions. Data can still be synced to the cloud for fleet-wide analytics and remote monitoring when connectivity is available.
Why does multi-protocol support matter for OEM equipment? Buildings and industrial sites rarely run on a single protocol. Equipment that only supports one protocol limits where it can be installed and how well it integrates with existing systems on-site. Supporting multiple protocols, such as BACnet, Modbus, KNX, MQTT, and OPC UA, widens the range of environments equipment can be deployed into without custom integration work for every project.
What role does visualization play in connected equipment? Visualization is how operators and facility teams actually interact with equipment day to day. Dashboards, graphics, and alarms need to be clear and configurable, since a technically capable product with a confusing interface will struggle to gain adoption. Framework-based visualization tools let OEMs deliver a polished, branded interface without building a graphics engine from scratch.
How long does it typically take to bring connected equipment to market using a framework versus building from scratch? Timelines vary by product complexity, but OEMs building from scratch commonly report multi-year development cycles for a full-featured connected product. OEMs starting from an existing framework have reported moving from concept to market-ready product in a matter of months, since the foundational software layers are already in place.
Is a framework approach only useful for large OEMs? No. Smaller and mid-sized OEMs often benefit the most, since they typically don't have the engineering headcount to build and maintain a full software platform alongside their core equipment business. A framework lets smaller teams compete on product innovation without needing a large in-house software division.
Want to learn more about FIN Framework as an OEM developing a smart connected software platform? Get started here.