AI Showcase · AIoT innovation lab for connected products

When connected devices start to understand their data.

Discover how artificial intelligence explains device data, detects anomalies, supports users, and turns connected hardware into a smarter product experience.

From sensor signal to understandable action: the chain every demonstrator on this page follows.

Framing

Intelligence does not live in the model alone.

A product is not intelligent just because a chat window was bolted on. Intelligence emerges from how the whole system works together, and that is exactly what we build.

relevant device data context reliable transmission suitable models uncertainty scoring clear explanation meaningful interaction clear limits and control

We do not treat AI in isolation, but as part of a complete connected-product system: device, connection, app, backend, data, and people.

Module A

interactive prototype

Explain device data clearly.

Devices produce readings, error codes, and states that are hard for users to understand. The AI feature translates them into natural language and explains them in context. Pick a device state of the fictional M40 monitor:

Inputs

Telemetry, error codes, operating state, connection quality, and product documentation.

Business value

Fewer support tickets, faster problem solving, higher product acceptance.

Architecture

Device → BLE → App → context prep → language model → checked output

Limits and safety

Explanations are recommendations, not diagnoses. Critical states follow fixed rules, not the model.

Module B

interactive prototype

Detect anomalies and faults early.

Devices often drift for weeks without any single reading triggering an alarm. The comparison shows why pattern recognition in time series reacts earlier than a fixed threshold:

Inputs

Time series from vibration, temperature, runtime, and load profiles across the device fleet.

Business value

Reduce downtime, make maintenance plannable, lower warranty and service cost.

Architecture

Device → telemetry → cloud pipeline → anomaly model → prioritization → service dashboard

Limits and safety

No model predicts every fault with certainty. Detections are signals with confidence that a human evaluates.

Module C

concept demo

AI-assisted product support with device context.

Classic support systems know the documentation, but not the customer’s device. The difference shows on the same request:

Inputs

Product docs, current device state, user description, known fault patterns, support history.

Business value

Fewer follow-up questions, more consistent answers, real relief for first-level support.

Architecture

Device state + docs → retrieve relevant content → language model → answer with sources and escalation path

Limits and safety

Answers rely on approved sources. When uncertain, the assistant hands off to a human instead of guessing.

Architecture decision

Edge, app, cloud, or hybrid: where should AI compute?

The same AI feature can run on the device, in the app, in the cloud, or distributed. The right answer depends on the product, and it shapes privacy, cost, and user experience.

Edge · Device
On-device · App
Cloud
Hybrid
Latency
minimal
very low
network-dependent
optimized per function
Privacy
Data stays on the device
Data stays with the user
Transfer needed, protection by design
Sensitive data local, rest central
Offline capability
full
full
none
core features offline
Model size
strongly limited
limited
nearly unlimited
distributed as needed
Energy and cost
Battery load on the device
Smartphone carries the load
ongoing operating cost
Cost follows usage
Updates
Firmware cycle, slow
App release cycle
anytime, central
central + coordinated

This trade-off is an architecture decision, not a model question. In the Connected Product Blueprint it is documented and justified.

Responsible AI

AI that users and companies can trust.

Good AI shows not only in what it does, but also in when it does not act. These mechanisms are part of product quality for us, not ethics folklore:

Data minimization

Collect and transmit only the data the feature truly needs. Prefer Edge over Cloud where it works.

Make uncertainty visible

Every statement carries its confidence. Users see how sure the system is, instead of a facade of certainty.

Human approvals

Critical actions need confirmation. Human in the loop is an architecture rule, not a slogan.

Safe fallbacks

If the model fails or is uncertain, defined rule behavior takes over. The product stays usable.

Monitoring in production

Model quality is measured after launch. Wrong decisions are captured and fed back into improvement.

EU AI Act in view

Regulatory requirements are framed early so compliance is not a retrofit project.

From experiment to product

A convincing AI prototype is not yet a reliable product.

The path from demo to a durable product feature follows ten steps for us:

01 Define the user or business problem
02 Assess available data
03 Prioritize the AI use case
04 Build a prototype
05 Evaluate quality and risks
06 Plan architecture and privacy
07 Define human-in-the-loop rules
08 Pilot inside a real product
09 Measure impact
10 Roll out gradually to production
In preparation
Predictive maintenance Context-sensitive product behavior Visual quality inspection Energy optimization Local on-device AI