
Asset and operations management
A shared overview of municipal buildings, spaces, equipment, documentation, faults, maintenance and statutory inspections.
Explore the solutionSolutions for municipalities
Every municipality manages different sites, works with different information and has its own operational priorities. Some first need to organise building and equipment records. Others most need to understand consumption, track faults or obtain data from locations that are not regularly supervised.
We are developing SmartGovIOT as a modular platform connecting assets, measurements, documentation, events and responsibility. A specific solution is designed around the problem the municipality needs to solve, the information it has available and what is technically and operationally feasible within the agreed scope.
You can start with one site, a selected measurement or a particular workflow. Further areas are added when they have a clear purpose and build on what the municipality already uses or has verified.
Describe your requirements · View features
For each area, we distinguish available capabilities, pilot solutions and features in development. The label always applies to the stated scope, not automatically to all related platform capabilities.

A shared overview of municipal buildings, spaces, equipment, documentation, faults, maintenance and statutory inspections.
Explore the solution
Monitoring electricity, gas, water and heat consumption, cost trends, deviations and information for energy-related decisions.
Explore the solution
Remote measurement of levels, temperature, humidity, rainfall, environmental quality and technical states using supported sensors and LoRaWAN.
Explore the solution
Records of lighting points, distribution boards, technical condition, faults, service interventions, consumption and planned renewal.
Explore the solution
A planned overview of technical alarms and operational events linked to a location, responsibility and the resolution process. No processing of camera footage.
Explore the solution
Planned records of roads and related technical assets, their condition, faults, maintenance, documentation and geographical context.
Explore the solutionWe first clarify what should become simpler, clearer or better documented after introduction.
A request to ‘digitise the municipality’ can encompass very different needs. It therefore needs to be turned into a specific task: finding equipment documentation, knowing about an upcoming inspection, comparing consumption at different sites or tracking the progress of fault resolution.
An objective defined this way helps identify the data required, the staff involved and how the outcome will be verified. It also separates the essential first step from capabilities that can wait for a later stage.
Illustrative example: A municipality wants to keep school maintenance under control. Installing sensors need not be the first step. Verifying the equipment list, attaching documentation, adding inspection deadlines and assigning responsible people may be more useful. Measurement is added only where it helps answer a specific operational question.
There is no need to start entirely from scratch. We first assess what the municipality already has.
Site lists, technical documentation, meter readings, service records and data from existing systems can form the foundation of a solution. It is important to verify how up to date they are, their source and their link to a particular location or device.
For some data, organisation and added context may be enough. Other data will need to be checked directly on site or obtained from a supported source. Missing information needs to be identified, not replaced by an estimate that might later appear to be confirmed data.
SmartGovIOT is not intended to automatically replace every application and specialist system the municipality uses. Connections are assessed where they are available, authorised and practically useful. Sometimes an integration is more suitable; at other times, a secure import or separate records are preferable.
Assets, consumption and maintenance often concern the same site.
At a cultural centre, an asset manager may need heating documentation, an energy manager consumption data and a technician the fault history. Each works with a different part of the information, but all of it concerns the same building and its operation.
We therefore look for shared relationships when designing a solution. A metering point should belong to the correct site, a fault to a particular device and a service document to the work performed. Individual records can then gradually be connected according to the available features and agreed scope.
This does not mean that everything must be introduced at the same time. A usable foundation is defined first, followed by further expansion.
For every area, it is important to know not only what it should deliver, but also what it depends on. This may include data availability, equipment type, integration options, documentation quality or the cooperation required from municipal staff.
An available solution can be included in a proposal after the specific conditions have been verified. Pilot solution is used for practical testing of an agreed scope. The label In development means that the capability is not yet offered as a standard available component.
The aim is for the municipality to understand, before deciding, what it will receive, what will be tested and what remains outside the agreed scope.
Choose the area that best matches your need. We will help clarify the details according to your sites, information and way of working.
Some requests concern one device; others involve several buildings or the work of an entire team. The following areas help explain SmartGovIOT's capabilities and identify a suitable starting point.
You do not need to separate assets, energy and maintenance precisely when choosing. One need may span several areas. What matters is defining what the solution should deliver, which data it requires and who will work with it.
Pilot solution
Knowing your assets means knowing what you manage, its condition and what requires attention.
This area suits municipalities that need to connect building and equipment records with documentation, maintenance and everyday requests. It helps address situations where basic data is in one spreadsheet, statutory inspection reports are in a paper folder, and information about the last repair is known only to a particular staff member.
Pilot preparation defines the organisation of sites, spaces and equipment. Verified data, available documentation, responsibilities and operational records are gradually assigned to them. Distinguishing confirmed information from older source material and information still requiring verification is an important part of this work.
Records prepared in this way can support tracking faults, maintenance and inspection deadlines. A task then no longer stands alone: it is clear which device it concerns, what supporting information is available and what was dealt with on that device in the past.
Example of an initial scope: One municipal site, a selected group of technical devices, assignment of available documents and testing of the process from fault reporting to recording the outcome.
What to take into account: Importing a list does not mean having a physically verified asset register. Equipment condition, documentation completeness and professional inspection deadlines need confirmation from the relevant information. The system does not replace a professional inspection or a decision by the responsible person.
Explore asset and operations management
Available according to scope
Understanding consumption means knowing its pattern, the source of data and the operational context.
This area suits municipalities that need to organise metering points, compare site consumption or investigate unusual trends. It can build on existing readings, available local measurements, billing information or individually verified integrations.
The first step is to assign the metering point correctly to a site and establish what each value represents. An ongoing meter reading, consumption over a period and a value from an invoice are not interchangeable. Processing must therefore preserve units, time period, source and available data quality information.
Depending on the agreed scope, a measurement history, basic charts, comparisons and deviation alerts can be prepared. Where suitable information is available, the solution may also include costs or data on on-site energy generation. A shared energy view across several sites is designed according to the availability of individual sources.
Example of an initial scope: Selected water and electricity metering points at several sites, checks of their assignment, processing of available history and a proposal for a regular overview.
What to take into account: The level of detail in evaluation depends on the measurement and the quality of supporting information. Missing data must not be presented as zero consumption, and an unusual pattern does not, on its own, confirm a fault. Connection to authorised data sources, such as OKTE/EDC, must not be treated as an automatically available part of every solution.
Available according to scope
Monitoring a remote location means having both a value and information about whether it is still current.
This area suits locations where measurements need to be collected between in-person checks. Depending on the specific need, they may concern level, temperature, humidity, rainfall, environmental quality or the technical state of supported equipment.
Design starts with what the measurement should help identify and how the data will be used. A suitable sensor, installation point, transmission method, measurement interval and operating conditions are then assessed. LoRaWAN is one transmission option; the specific technology is selected according to site conditions and the intended use.
Within the agreed scope, the solution may include receiving values, their history, a basic display and alerts. Recognising a communication outage is equally important so that the last value received does not appear to be a new measurement.
Example of an initial scope: One measurement location, verification of communication at the installation point, a value history and an alert to a designated staff member for an agreed deviation.
What to take into account: Coverage, accuracy and positioning suitability are verified under the actual conditions. Equipment checks and maintenance also need to be considered. The basic solution provides monitoring and alerts; it does not mean automatic control of technology, flood prediction or a complete replacement for physical checks.
Explore IoT and LoRaWAN monitoring
Pilot solution
Usable lighting records connect a lighting point, its condition and the history of work performed.
This area suits municipalities that need to refine records of lighting points and distribution boards, organise fault reports or retain service history. Remote control need not be the first objective. Unambiguous identification of a location and a traceable record of work performed there can already offer practical value.
Pilot preparation starts from available documentation and existing lists. It establishes which data is usable and what needs verification in the field. Records are gradually supplemented with current identity, location, technical data and operational context.
Fault and intervention records can build on the verified foundation. Depending on the information available, links to metering points, consumption monitoring or information needed for renewal planning can be added.
Example of an initial scope: A selected street or part of the network, checks of existing identifiers, verification of selected lighting points and a consistent process for recording faults and repairs.
What to take into account: Historical design documentation may not describe the current condition. Connection and technical-condition data require the appropriate verification. Individual control of luminaires is not an automatic part of the records pilot; any addition of that capability has its own technical and operational conditions.
In development
We are preparing connections between a technical alert, its location, responsibility and the next steps.
This area focuses on permitted operational events and technical states of supported systems. The aim is for an alert to clearly identify its source, the site concerned, when it occurred and how its investigation is progressing.
The planned workflow is intended to support a responsible staff member taking ownership of an event, adding findings and recording the outcome. It is important to distinguish receipt of a message from confirmation of its cause. A communication outage, for example, does not yet explain whether the problem lies in the device, power supply or transmission path.
Preparing a particular integration must define which events can be obtained, who can access them and what process should follow. The presence of a security or camera system alone does not confirm its compatibility with SmartGovIOT.
Example of testing in preparation: Receiving a selected technical report from a supported source, assigning it to a site and testing the process from receipt to recording the inspection outcome.
Firm boundaries: This area is not offered as a completed municipality-wide deployment. SmartGovIOT is not to process camera footage, images or data obtained through their analysis. The basic pilot does not include activating, deactivating or bypassing security components. Specialist systems remain separate.
In development
We are preparing records that preserve both the location of a problem and the history of its resolution.
This area focuses on local roads, traffic infrastructure components and related technical assets. Its aim is to connect an item's identification with its location, available documentation, a deficiency found and maintenance performed.
Preparation will require assessment of existing registers, identification methods, ownership and management responsibilities. Not every item within a municipality's territory is also managed by that municipality. These distinctions must remain clear in the records and when assigning tasks.
The proposed solution is intended to allow work to build on previous inspections and repairs. For a recurring problem, it will then be possible to find available records and assess the next steps. The map display should support orientation, not replace verification of input data accuracy.
Example of a scope in preparation: A selected group of components, such as drainage beside a local road, adding identification and management responsibility, and designing a process for recording inspections and repairs.
What to take into account: The area is in development, and a specific pilot will be defined only after the supporting information has been assessed. A working map or imported list is not presented as a complete, professionally verified asset register. The information made available must also respect the sensitivity of technical data.
A request need not belong to only one category. At a municipal building, equipment records, consumption monitoring, documentation and maintenance may come together. For public lighting, it may be lighting-point identification, faults and energy measurement.
In that case, we will propose a shared initial scope and define which information should remain connected. There is no need to create a separate project for every feature. It must nevertheless be clear what the solution includes, what is still being tested and which further steps it will support.
Describe the problem, the sites concerned and the expected outcome. We will help clarify a suitable combination of areas.