Skip to main content
NOVYRON

PRODUCTS

Five capability modules, licensed and deployed as one system

Each module runs standalone or as part of the connected loop. NOVYRON ships the software: licences, deployment, integration and lifecycle services. Robots, cameras and PLCs remain your hardware or your vendor's — the platform stays vendor-neutral.

  • SOFTWARE LICENCE
  • EDGE / CLOUD DEPLOYMENT
  • INTEGRATION SERVICES
  • LIFECYCLE SUPPORT

01 · MODEL

Simulation & Digital Twin

The problem. Physical trial-and-error on a running line is slow, expensive and risky. Layout changes, new products and automation decisions get made on intuition because testing them for real would stop production.

WORKFLOW

  1. S1Model the process, assets and constraints from layouts, cycle data and PLC signals
  2. S2Run baseline and candidate scenarios against recorded or synthetic demand
  3. S3Compare throughput, utilisation and bottlenecks side by side with stated assumptions
  4. S4Commission the chosen change virtually, then hand validated parameters to the floor

COMMON USE CASES

  • CELL & LINE DESIGN
  • VIRTUAL COMMISSIONING
  • SCENARIO COMPARISON
  • SYNTHETIC DATA
  • TRAINING ENVIRONMENTS
twin · packaging-cell-04 · scenario compareSIMULATED DATA
  • BASELINE · current layout142 u/h
  • SCENARIO B · added buffer + re-route178 u/h
  • SCENARIO C · second gripper171 u/h

ASSUMPTIONS

demand profile W34 · changeover 4.5 min · 2 operators · run 10×8h

Scenario comparison view: a baseline layout at 142 units per hour, scenario B with an added buffer and re-route at 178 units per hour, and scenario C with a second gripper at 171 units per hour, all under stated assumptions.
INPUTS
CAD / layout files, cycle and takt data, PLC signal logs, demand profiles
OUTPUTS
Scenario comparisons, bottleneck analysis, validated parameters, synthetic datasets
INTEGRATES
CAD/PLM exports, historian databases, OPC UA, the Perception and Guidance modules

02 · PERCEIVE

AI Perception

The problem. Manual inspection and monitoring miss defects, drift with fatigue and produce no structured record. Camera and sensor data exists but never becomes evidence anyone can act on.

WORKFLOW

  1. S1Connect camera streams and sensors; validate coverage, lighting and data quality
  2. S2Train or configure detection models — with synthetic data from the twin where labelled samples are scarce
  3. S3Run inspection, counting and anomaly detection live; every detection carries source frame, timestamp, confidence and model version
  4. S4Route low-confidence detections to human review queues; feed verdicts back into evaluation

COMMON USE CASES

  • VISUAL QUALITY INSPECTION
  • ANOMALY DETECTION
  • COUNTING & TRACKING
  • SAFETY MONITORING
perception · line-2 · detection D-88412Review required
Detection review: a captured frame with a highlighted seal-gap region scored 0.81 against a 0.85 threshold, so the detection is queued for a QA verdict rather than auto-accepted. Model inspect-seal v3.2.1, camera 7.
CLASS
seal_gap (defect)
CONFIDENCE
0.81 · threshold 0.85 → queued
MODEL
inspect-seal v3.2.1
REVIEW
awaiting QA verdict
Detection review: a captured frame with a highlighted seal-gap region scored 0.81 against a 0.85 threshold, so the detection is queued for a QA verdict rather than auto-accepted. Model inspect-seal v3.2.1, camera 7.
INPUTS
Camera streams (GigE/RTSP), industrial sensors, part specifications, labelled or synthetic samples
OUTPUTS
Detections with evidence, review queues, quality reports, structured event streams
INTEGRATES
Vision hardware vendors, MES/QMS, the Guidance module's approval gates, Events & Alerts

03 · DECIDE

Guidance & Decision Support

The problem. AI output without governance is either ignored or blindly trusted. Operations teams need recommendations they can interrogate — and a record of who approved what, when and why.

WORKFLOW

  1. S1Define rules, thresholds and approval gates per event type and role
  2. S2Receive events from Perception, the twin or external systems; generate recommendations with confidence and evidence attached
  3. S3A permitted human approves, modifies or rejects — consequential actions never auto-execute past a gate
  4. S4Every decision lands in the audit trail with actor, evidence snapshot and downstream effect

COMMON USE CASES

  • APPROVAL WORKFLOWS
  • ESCALATION ROUTING
  • DECISION AUDIT
  • SHIFT GUIDANCE
guidance · approval gate G-1141 WAITING

Divert lane 2 output to rework buffer

trigger
D-88412 seal_gap · conf 0.81 · cam-07 22:14:03 GST
impact
14 units re-routed · est. 6 min · reversible

role required: line supervisor · you are signed in as s.rahman · action + evidence will be recorded

Approval gate G-114 with one item waiting: divert lane 2 output to the rework buffer, triggered by detection D-88412. Impact is 14 units re-routed, about six minutes, reversible. Approve, modify and reject controls require the line supervisor role and record the action with its evidence.
INPUTS
Perception events, twin scenarios, external system events, rules and role policies
OUTPUTS
Governed decisions, approval records, escalations, full decision history
INTEGRATES
Identity providers (SSO/RBAC), messaging/ticketing, the Orchestration module

04 · ORCHESTRATE

Robotics Orchestration

The problem. Robots, AGVs and software services each speak their vendor's language. Coordinating them into one workflow usually means brittle point-to-point integrations that fail silently.

WORKFLOW

  1. S1Connect robots, systems and services through vendor-neutral adapters
  2. S2Compose workflows from tasks, states and handover rules — approved changes only
  3. S3Execute with live state per participant; exceptions pause into defined safe states
  4. S4Operators resolve exceptions with manual controls; every intervention is logged

COMMON USE CASES

  • MIXED-FLEET COORDINATION
  • LINE ↔ WMS HANDOVERS
  • EXCEPTION MANAGEMENT
  • TASK DISPATCH
orchestration · wf pick-pack-dispatch · liveRunning
  • picking · t-3081arm-A2 · kukapicking · t-3081
  • en route · dock 3amr-07 · miren route · dock 3
  • degraded · retrying 2/3label-svc · apidegraded · retrying 2/3
  • paused · awaiting upstreamwrap-cell · abbpaused · awaiting upstream

EXCEPTION RULE

if label-svc fails 3× → hold dispatch, notify shift lead, safe-state wrap-cell

Live workflow pick-pack-dispatch with four participants: a picking arm running task t-3081, an AMR en route to dock 3, a labelling service degraded and retrying, and a wrapping cell paused awaiting upstream. An exception rule holds dispatch and safe-states the wrapping cell if the labelling service fails three times.
INPUTS
Robot/AGV APIs, PLC and MES signals, WMS/ERP tasks, approved Guidance decisions
OUTPUTS
Coordinated task execution, live workflow state, exception logs, intervention records
INTEGRATES
KUKA, ABB, UR, MiR and other vendor APIs · OPC UA, MQTT, REST · WMS/MES/ERP

05 · OPTIMISE

Edge & Cloud Operations

The problem. AI systems degrade quietly: models drift, edge devices fall offline, versions diverge across sites. Without operational tooling, yesterday's working deployment is next quarter's incident.

WORKFLOW

  1. S1Package modules and models into signed, versioned deployment units
  2. S2Deploy to edge and cloud targets with staged rollout and health checks
  3. S3Monitor telemetry, model performance and data freshness; degraded states surface as first-class alerts
  4. S4Roll back in one governed step; every version change lands in the audit trail

COMMON USE CASES

  • FLEET-WIDE ROLLOUTS
  • MODEL LIFECYCLE
  • SITE TELEMETRY
  • AUDIT & COMPLIANCE
operations · deployments · site DXB-14 TARGETS
Deployment table for site DXB-1 with four targets: two edge nodes healthy on v2.4.1, a dock gateway rolled back from v2.4.1 to v2.3.9 under audit record 4471, and cloud analytics healthy on v2.4.1.
TARGETVERSIONHEALTH
edge · cell-04v2.4.1healthy
edge · line-2v2.4.1healthy
edge · dock-gwv2.3.9 ← v2.4.1rolled backaudit #4471
cloud · analyticsv2.4.1healthy
Deployment table for site DXB-1 with four targets: two edge nodes healthy on v2.4.1, a dock gateway rolled back from v2.4.1 to v2.3.9 under audit record 4471, and cloud analytics healthy on v2.4.1.
INPUTS
Deployment units, target inventory, telemetry streams, model registries
OUTPUTS
Staged rollouts, health dashboards, rollback actions, complete audit history
INTEGRATES
Kubernetes/edge runtimes, observability stacks, SIEM, enterprise identity

SOFTWARE / HARDWARE BOUNDARY

NOVYRON licenses and operates software. Robots, cameras, sensors and controllers are supplied by you or your hardware vendors; the platform connects to them through documented, vendor-neutral interfaces. Hardware procurement can be coordinated within a project, but it is never a hidden dependency.

Which module fits your environment?

Bring the process and the systems involved — we map them to the modules above and reply with an architecture sketch, not a sales deck.

Request a technical discussionSee the platform loop