Solutions

One platform. Multiple smart infrastructure solutions.

Build and operate connected solutions across cities, utilities, buildings and industrial infrastructure without creating separate software stacks for every use case.

Explore SolutionsBook a Demo

Vision Smart Platform solutions: street lighting, environmental sensing, metering, control cabinets, HVAC and video connected around the platform core

One platformSeven solutions, one registry, one permission model, one audit trail.
Configured, not codedModels, rules, dashboards and maps are defined in the interface.
Open to what you ownExisting devices, protocols and systems can stay where they are.

Explore solutions built on Vision Smart Platform.

Each solution combines devices, connectivity, platform modules, dashboards and automation around a specific operational challenge.

 
Smart Lighting
Remote control, dimming, schedules, fault monitoring and automated lighting scenarios.

Explore solution

 
Smart Environment
Monitor environmental parameters, thresholds, alerts and geographic distribution.

Explore solution

 
Smart Metering
Collect and analyze electricity, water and gas consumption.

Explore solution

 
Smart Infrastructure / SCADA
Telemetry, control, alarms, historical data and operational workflows.

Explore solution

 
Smart Buildings / BMS
Connect building systems, lighting, energy and environmental operations.

Explore solution

 
Smart Video & Analytics
Turn video events into operational data and automated actions.

Explore solution

 
Smart City Operations
Create one operational layer across multiple urban infrastructure domains.

Explore solution

One architecture. Many outcomes.

 
Devices & Edge
 
Connectivity
 
Vision Smart Platform
 
Dashboards & Automation
 
Operational Outcomes

How it is built

A solution is a configuration, not a rebuild.

Every solution on this page follows the same six steps. What differs between them is the equipment, the payloads and the rules — not the platform underneath.

1

Define the model

Describe the class of equipment once — its parameters, data types, units of measure and defaults.

2

Add the version

Attach the commercial product: internal and manufacturer codes, the vendor, and any configuration specific to that version.

3

Enroll the instances

Register the units actually installed, with their location and their place in an IoT system or group.

4

Map metrics and commands

Metric templates extract values from the incoming payload; command templates define what can be sent back, and which response metrics validate it.

5

Add the rules

Conditions on metrics, parameters and time combine with AND/OR to trigger commands, notifications or parameter changes.

6

Build the screens

Dashboards, widgets and a map profile turn the model into the view an operator actually works in.

Attributes are inherited, not retyped. What is defined on a model is inherited by its versions and instances, and can be overridden locally where a particular unit needs it.

Common foundation

What every solution inherits.

None of this is rebuilt per project. It is the same platform underneath, which is why a second solution costs less than the first.

Digital twin registry

Model, version and instance, with attributes inherited downwards and overridable locally.

Reusable dynamic attributes

Parameters, metric templates and command templates — defined once, used in rules, screens and commands.

Command validation

Commands carry the parameters needed at execution, the response metrics that confirm them, and a state over time.

Visual rules engine

Predefined operators, AND/OR combinations, priorities and operational enable/disable — built in an editor, not in code.

Dashboards and widgets

Operational screens defined per version and per installation, from a widget palette.

Maps and spatial operations

Devices, groups and systems on interactive maps, with filters, shapes and map profiles.

Roles, permissions and audit

Identity and access control, plus a change history with old and new values on practically every entity.

Administration and nomenclators

Organisational units, operators, states, units of measure, data types and the holiday calendar.

Integration and deployment fit

What it can integrateProtocols run as configurable, containerised service instances, alongside HTTP and MQTT integrations and per-controller CODEC definitions.
What stays configurableModels, versions, parameters, metric and command templates, rules, dashboards and map profiles are all configured in the interface.
Where custom logic belongsThere are defined places for it — the rule expression language, CODEC definitions and the integration APIs — rather than forks of the platform.
How access is controlledIdentity and access management, roles and permissions, and a centralised audit trail that records old and new values.

By sector

Where these solutions are deployed.

The same solutions look different depending on who operates them, what they already own and what they are accountable for.

Cities & Public Infrastructure

Street lighting, environmental monitoring and public assets under one operational model.

See the fit ›

Utilities

Distributed metering and network assets, with consumption data and controlled actions.

See the fit ›

Industry & Critical Infrastructure

Telemetry, alarms and controlled commands across industrial and critical sites.

See the fit ›

Buildings & Campuses

Lighting, energy and environmental systems across a portfolio of buildings.

See the fit ›

Defence

Connected assets and operational awareness in constrained, controlled environments.

See the fit ›

Have a specific infrastructure challenge?

Tell us what you need to connect and what outcome you want to achieve.

Discuss your Solution