Indeema
Talk to an IoT Architect

Intelligent Products & AI

Connected products that interpret what is happening and respond

Intelligence becomes part of how the product works: what it senses, what it concludes, what it may do and how it improves, engineered with the device that carries it.

Need one team responsible for the AI method, where it runs, runtime integration and lifecycle? See AI for IoT & Edge AI.

See what changes in the product Find your starting point

  1. SignalVibration from the machine
  2. ContextNormal for this unit and load
  3. DecisionA developing change, not noise
  4. ResponseA person is told what to inspect
Illustrative behavior, not a project result.

What becomes possible

Intelligence changes what a product can notice, decide and do

An intelligent connected product interprets signals from its physical environment and uses that context to support or make a decision, within limits its makers define.

  1. Notice a condition while it is still developing

    Is this normal for this machine, today?

  2. Respond where the cloud is too far, too slow or not permitted

    What is in view, and who needs to know now?

  3. Adapt to the installation it finds itself in

    Which threshold fits this unit?

  4. Diagnose itself from signals it already has

    Which part is at fault? Sometimes no extra sensor is needed.

Not every product needs this. If a rule or threshold is enough, it should stay a rule. In one elevator-monitoring project, detecting trips across lifts with different starting currents meant adapting thresholds to each lift, not training a model. A model earns its place when the decision depends on patterns a rule cannot express. See the elevator project

How intelligence enters the product

Design the product so intelligence can take part where it creates value

Intelligence added later inherits whatever signals, compute and update path the product already has. Designed in, it can take part where it creates value and change after launch.

That is what AI-native means for a connected product: data, context, decision boundaries and feedback designed into the architecture. It does not mean AI in every layer, cloud AI or autonomy in every decision.

One decision, placed three ways

Where does the decision run?

Everything runs on the device; evidence returns to the cloud. Fits decisions that must be fast, work offline or keep data local, within the device’s compute and power budget.

The device senses; an edge gateway builds context across devices and decides. Fits when several devices share context, or a gateway can carry more compute than each device.

The device senses; the cloud decides; a person receives a recommendation in an application. Fits decisions that need fleet-wide data or heavy compute and can tolerate delay.

Sense
Which signals, trusted how far?
Context
What situation do they describe?
Decide
On what evidence, within what limits?
Act
What happens, and what stays human?
Feedback
How does the outcome reach engineers?

A lens, not a pipeline: most steps may stay ordinary rules. The dashed path is reviewed and ships as signed updates; the product does not retrain itself.

Edge AI runs machine-learning inference on or near the device instead of sending everything to the cloud. It is one of three places a decision can run, and none is better in general. What edge computing means for IoT

A circuit board at the base of a layered render, with signal-processing layers above it and a waveform panel on top

Beyond the model

A model that works in a notebook is not yet product behavior

Sensor, firmware, connectivity, data path, model and update path are one design problem. What is chosen at design time decides whether intelligence can be added later without rebuilding the product.

  • Signals

    Can the decision trust what the product senses?

    Placement, noise, representative data

  • Constraints

    Can it run where it must, within the power, compute and latency allowed?

    Runtime, memory, connectivity

  • Trust

    What happens when it is wrong, uncertain or offline?

    Failure behavior, override, privacy, security

  • Lifecycle

    Can it be updated, observed and rolled back after launch?

    Signed updates, monitoring, drift

Recognize one of these seams in your product? Tell us what the product needs to sense, interpret or decide. The decision is framed first; the model, if one is needed, comes after. Discuss where intelligence fits your product

How far it should act

Give the product only the authority it can be trusted with

Authority is set one decision at a time: what a wrong decision costs, whether it can be undone, and whether a person can step in.

  1. Human decidesConditions are made visible; a person chooses.
  2. AI recommendsIntelligence proposes an action, with context.
  3. System acts within rulesDeterministic rules handle known conditions.
  4. Bounded autonomyIt acts inside explicit limits, with oversight and fallback.

At every level, people set the limits, see what the product did and can override it. Higher autonomy is not the goal.

The full model: Why Cognitive IoT When the product must act in the physical world

Engineered, not only demonstrated

An AI capability has to be tested as part of the product, not only evaluated as a model

On the real sensors, in the real light, on the real hardware. In each project below, the model is one part of a system we engineered around it.

A camera module on an aluminium rail aimed at a target screen, with an adjustable lamp beside it, drawn as a test set-up

  1. Indeema product · engineering completedName the developing fault

    A diagnosis is only as good as the signal behind it

    Vibration from rotating machinery is compared against reference levels that raise alarms, and AI identifies the type of fault in bearings and other rotating parts, shown on a diagnostic dashboard for operators.

    See the project

    What we engineered

    • Multichannel accelerometer unit and its firmware
    • Calibration and self-diagnostics
    • Signal processing, reference-level alarms and AI fault classification
    • Alarms and diagnostic dashboard

  2. Client project · engineering deliveredSupport a doctor’s review

    In a medical product, AI supports the clinician’s decision

    AI analysis of heart-signal recordings (ECG, PCG, PPG) highlights potential cardiac risks for a doctor’s review. The sensor firmware was moved from Arduino to native ESP-IDF to make the existing device more stable and easier to extend.

    See the project

    What we engineered

    • Sensor firmware (ESP-IDF, BLE)
    • Android app for patients
    • Azure cloud
    • Web portal for doctors

  3. Client project · engineering deliveredForecast what each installation will produce

    A forecast is useful where the product can act on it

    Production analytics collected over time are combined with weather forecasts in an AI model that predicts the energy each PV installation will produce, inside the platform installers use to manage those systems. The platform has been used by photovoltaic wholesalers and installers in Europe since its launch in October 2018.

    See the project

    What we engineered

    • Firmware that connects devices to the service
    • Encrypted data exchange between devices and the cloud
    • Web service with user roles
    • AI production forecasting

  4. Client project · proof of conceptRecognize and alert at the edge

    Recognition has to survive motion, light and a small budget

    A drone concept had to recognize objects in motion, through shake, blur and changing light, and alert a person. A compact shark-detection neural network was trained in our lab for processing on the drone.

    See the project

    What we engineered

    • System architecture from a high-level concept
    • Flight electronics on open-source flight software
    • Detection model trained on drone-view images
    • iOS app and wristband alerts

Each example states what Indeema engineered and where its part ended.

Your starting point

Which of these sounds like you?

Already in a product

Add intelligence to a product already in the field

  • We already collect useful product data.
  • Cloud-only behavior isn’t enough.
  • Can our current hardware carry it?

Why it mattersYour hardware, firmware and data path are already in customers’ hands. We evaluate what can be reused before recommending any redesign, so intelligence goes where the product can carry it.

What we would look at first

The decision first, then what the product can already sense, its compute and update headroom, and where the result must appear. Often the first change is the data path, not the model.

If the decision has to run locally: what forces it there (latency, connectivity, privacy, power), and how much authority it should have.

  • Client project · engineering delivered Existing sensor firmware moved to ESP-IDF; AI highlights potential cardiac risks for a doctor’s review. See the project
  • Client project · engineering delivered AI forecasts each PV installation’s production inside the platform installers already use. See the project
How IoT product engineering works

Exploring what is possible

Engineer a new intelligent product

  • We’re planning a product that has to sense, interpret or decide.
  • We’re not sure it needs AI at all.

Why it mattersSensor, compute and update-path choices made early in development decide whether intelligence can work later. Deciding them together, across hardware, firmware, cloud and AI, brings integration risks into view while they are still easy to change.

What we would look at first

How the intelligence will be engineered together with the device that carries it: sensor, firmware, connectivity, data path, model and update path as one design problem.

  • Indeema product · engineering completed Accelerometer unit, firmware, signal processing, reference-level alarms, AI fault classification and the operators’ dashboard, engineered as one system. See the project
Decide before you commit to engineering

Prototype or proof of concept

Take an AI prototype to production

  • We have an AI prototype, but not a product architecture.
  • The model works on a workstation, not yet on the device.
  • We’re exploring computer vision.

Why it mattersOn the real hardware a model meets latency, power, memory, connectivity and update limits. Working through those limits early gives you a realistic view of what it takes to ship, before the launch plan depends on it.

What we would look at first

What the prototype proved and what it did not; then what must change for real hardware, power, latency and updates.

  • Client project · proof of concept A shark-detection model trained in our lab; the next-stage requirements put detection on a separate edge module beside unmodified flight firmware. See the project
Embedded and firmware engineering

What happens next. Our engineering team reads your enquiry and replies by email. The first conversation covers the product goal, what exists today and the decision you need to make next. If the problem needs it, a discovery phase follows; it does not commit you to building with Indeema. How a first engagement works

No full specification needed: bring the product, the decision it should make and the data you have. The form asks where you are with AI today, so you can pick the stage named above.

Discuss where intelligence fits your product

After launch

A product improves through an engineered loop, not on its own

Outcomes return as evidence; engineers review, validate and ship a signed update with a way back. That is why the update path is designed before the first model.

Cognitive IoT is Indeema’s model for where connected products are heading, from connected through observable to intelligent and adaptive. This page is the engineering path into those stages. Why Cognitive IoT

Where relevant, reusable Indeema engineering foundations can support the work. None is required. Explore the Indeema Ecosystem

Privacy controls

Choose optional measurement

Your choice is remembered in this browser for 180 days, then we ask again. Analytics measures page views and interactions and stores campaign attribution. You can withdraw consent in Privacy settings.

With analytics allowed, HubSpot also records the pages you visit on this site, so that if you contact us or request a resource our team can see how you found us.