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.

This page starts with what intelligence enables in the product. Need responsibility for method, placement, runtime integration and lifecycle? See AI for IoT & Edge AI.

See what changes in the product
  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. A model earns its place when the decision depends on patterns a rule cannot express.

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

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.

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. Three anonymized projects, three lessons.

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. Recognize 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. Lightweight detection was optimized for edge processing.

    See the project

    What this showsProof of concept. Recognition was simulated with shapes projected onto a floor. No detection performance is claimed.

  2. Flag a developing fault

    A warning is only as good as the signal behind it

    Vibration from rotating machinery was analyzed against reference levels, with alarms and a diagnostic dashboard for operators.

    See the project

    What this showsThe record supports signal analysis, alarms and a diagnostic dashboard, not quantified outcomes or predictive fault detection.

  3. Adapt to the installation

    Not every smart behavior is a model

    Lifts differ in starting current, so detecting trips accurately meant adapting thresholds to each lift’s operating characteristics.

    See the project

    What this showsAdaptive thresholds are algorithmic. They are not machine learning.

Project examples focus on engineering scope, evidence and system boundaries.

Your starting point

Which of these sounds like you?

From prototype to product

  • We have an AI prototype, but not a product architecture.
  • We’re exploring computer vision.

First, we would look atWhat the prototype proved and what it did not; then what must change for real hardware, power, latency and updates.

Decide before you commit to engineering

From product data to product behavior

  • We already collect useful product data.
  • We want the product to understand context.
  • We’re not sure where intelligence belongs.

First, we would look atThe 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.

How IoT product engineering works

When placement is forced

  • We need faster, local decisions.
  • Cloud-only behavior isn’t enough.
  • We’re considering greater autonomy.

First, we would look atWhat forces the decision to run where it does (latency, connectivity, privacy, power), and how much authority it should have.

Embedded and firmware engineering

Bring the product, the decision it should make and the data you have.

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