Software for physical automation

Understand, verify, and improve automation across vendors.

Mekai Labs connects robot and machine data with the requirements and decisions around it. Run the same KPIs, alarms, interface checks, tests, incident reviews, and change workflows across every project.

For robot builders, system integrators, automation teams, and multi-vendor operators.

Across vendorsUse one KPI and exception definition.
Across projectsReuse mappings, checks, and reports.
Across changesKeep the accepted state and what must be revisited.

The work Mekai removes

Stop rebuilding the same operational logic for every vendor and site.

Performance numbers sit in vendor portals. Checks sit in scripts. Project evidence sits in documents. Accepted configurations sit in people's memory. Mekai turns that repeated work into versioned, inspectable functions and records.

What Mekai automates

From daily operations to post-change revalidation.

Start with the job your team still runs by hand.

Daily operations

Compare performance across vendors.

  • Normalize robot and site events
  • Calculate shared KPIs and contracted outcomes
  • Monitor exceptions, alarms, and trends
OutputCross-vendor operations report

Checks and verification

Reuse checks across machines and projects.

  • Map vendor tags into reviewed system concepts
  • Check sequences, timing, and handshakes
  • Run the same function on recorded, simulated, or live data
OutputTraceable verification result

Commissioning · FAT · SAT · UAT

Run commissioning and acceptance.

  • Connect requirements to tests and required evidence
  • Run commissioning, FAT, SAT, and UAT workflows
  • Track gaps, deviations, retests, reviews, and sign-off
OutputAcceptance, handover, and baseline pack

After a change

Know what changed and what to revisit.

  • Compare the deployed configuration with its accepted baseline
  • Flag affected evidence and candidate rechecks
  • Reconstruct incident timelines across systems
OutputIncident or revalidation record

SLA · contracted outcomes

Prove the service levels the contract is paid against.

  • Record the contracted uptime, throughput, MTTR, and response targets
  • Compute each one on the definition both sides agreed
  • Show shortfalls, exclusions, and the evidence behind every figure
OutputSLA and contracted-performance record

Kickoff · boundary · responsibilities

Agree who proves what, before the build starts.

  • Set the system boundary, the parties, and the responsibility matrix
  • Map requirements and risks to controls and verification methods
  • Name what the planned setup will not be able to prove
OutputResponsibility matrix and evidence plan

End to end

One record from scope to revalidation.

Each stage hands the next one something it can use. The boundary becomes the evidence plan, the evidence plan becomes the test run, the test run becomes the accepted baseline, and the baseline decides what a change makes stale.

  1. Scope and boundary

    Parties, responsibilities, contracted outcomes, and the evidence each one will need.

  2. Design and internal validation

    Checks written once and replayed against recorded or simulated data before anyone travels.

  3. Commissioning and FAT, SAT, UAT

    Protocols run against live and recorded evidence, with deviations and retests tracked as they happen.

  4. Acceptance and handover

    Criteria, results, reviewer decisions, and sign-off assembled into one reviewable pack.

  5. Operations and service levels

    Cross-vendor KPIs, exceptions, and contracted service levels on the definitions already accepted.

  6. Change and revalidation

    The accepted baseline compared with what is deployed now, and what that comparison makes stale.

The systems already in the project

Use live data where permitted. Use recorded evidence everywhere else.

Mekai works above the tools that already control and operate the system.

Machines

What the equipment reports

Robot controllers, ROS 2, MCAP, rosbag2, VDA 5050, MQTT, PLCs, OPC UA, doors, lifts, conveyors, chargers, and cells.

Operations

What the site and business systems know

WCS, WES, WMS, FMS, MES, SCADA, historians, databases, APIs, files, orders, missions, alarms, and maintenance events.

Project record

What the deployment must achieve

Requirements, interface specifications, drawings, risk controls, test procedures, measurements, media, witness records, deviations, and approvals.

The full list

Every workflow, and everyone who runs it.

The four headline automations are the common starting points. This is the rest of what the same data, function and evidence layer covers.

Workflows

Data and context
  • Source and asset inventory with access limits
  • Vendor tag mapping into reviewed system concepts
  • Data-quality, coverage and provenance reporting
  • Configuration, firmware and layout versioning
  • Session capture, storage and replay
Operations
  • Cross-vendor KPI and exception reporting
  • Availability, utilisation and throughput
  • Waiting, blocking and charging analysis
  • Alarm definition, routing and suppression
  • Trend and degradation detection
  • Shift, site and management reporting
Verification
  • Sequence, timing and invariant checks
  • Interface and handshake verification
  • Fault-matrix and edge-case checks
  • Regression checks against a reference period
  • Replay against recorded or simulated data
  • PASS, FAIL and NOT VERIFIABLE results
Project and assurance
  • System boundary and responsibility matrix
  • Requirement, risk, control and evidence matrix
  • Evidence-readiness planning before a test
  • Commissioning and FAT, SAT, UAT execution
  • Deviations, punch items, retests and closure
  • Witness review, sign-off and approval history
After acceptance
  • Accepted deployment baselines
  • SLA and contracted-performance records
  • Change-impact paths across the baseline
  • Stale-evidence detection and retest scope
  • Incident timelines across systems
  • Revalidation governance and history
Output and integration
  • Acceptance, handover and audit packs
  • Traceability from criterion to signature
  • HTML, PDF, DOCX, JSON and API exports
  • Notifications, tickets and work orders
  • Multi-site and multi-tenant management
  • Private, on-premises or air-gapped deployment

Who runs them

Runs it daily
  • Robotics, controls and integration engineers
  • Commissioning and test engineers
  • Fleet and plant operations teams
  • Reliability and maintenance engineers
  • Data and digital-manufacturing engineers
  • Project managers and site-execution engineers
Reviews and signs
  • Customer acceptance engineers and witnesses
  • Quality and compliance teams
  • Safety consultants and assessors
  • Third-party reviewers within their own authority
Owns the budget
  • Heads of deployment, service and integration
  • Project and engineering directors
  • Automation and plant digitalisation leaders
  • Operations managers and site owners
  • Quality and compliance leaders

Mekai Open + Mekai Platform

Open makes the functions portable. Platform makes the decisions traceable.

Free and self-hostedAGPL-3.0

Mekai Open

The vendor-neutral data and function foundation for physical automation.

What can this system compute — and where are the limits?

Open foundation
  • Source, event, asset, configuration, and function definitions
  • Local adapters, replay, storage, and versioned function runtime
  • CLI, API, SDK, local results, and reusable function packs
Functions kept open
  • Cross-vendor KPIs, exceptions, observability, and alarms
  • Incident replay, interface checks, trends, and custom functions
  • Coverage, quality, provenance, and explicit missing-data results
Paid productDeployment workspace

Mekai Platform

The reviewed workspace for verification, acceptance, configuration, and change.

What was agreed, tested, accepted — and what must be proven again?

  1. Project scope, assets, interfaces, responsibilities, and evidence plan
  2. Versioned functions, checks, runs, evidence gaps, and reviewer decisions
  3. Commissioning, FAT, SAT, UAT, acceptance, and handover
  4. Accepted baselines, change impact, rechecks, and revalidation
  5. Approvals, audit history, enterprise integrations, and private deployment

Questions

What engineering and commercial teams ask first.

Closed by default. Open one and only that answer shows. An asterisk means the answer carries a qualification, printed with it.

Getting started

No change to your current structure.* Mekai reads from the systems already running the project and writes its results alongside them. Nothing has to be migrated, re-platformed or replaced before you get a result.

Mekai does not replace your WCS, WES, WMS, FMS, MES, SCADA, historian, PLC programming environment or recorder, and it does not require your data to be moved into a new store.

The acceptance criteria or checks you already use, and recorded data from one project — exports, logs, capture files or bag files. Recorded data is enough to produce a full result.*

Live connections are used only where the site permits them. Where they are not, everything runs from recorded files and exports.

One project, one criterion. You send the criteria and the recorded run, and you get back the computed result, the evidence behind it, and an explicit list of what could not be proven from the data supplied.

Technical

Robot controllers, ROS and ROS 2, MCAP and rosbag2, VDA 5050, MQTT, PLCs and OPC UA, drives, doors, lifts, conveyors and chargers, plus WCS, WES, WMS, FMS, MES, SCADA, historians, databases, APIs, files and manually recorded evidence.*

These are representative inputs. Which of them are available on a given site depends on what that site exposes and what access it grants.

No. It is read-only by default. Observation and action are separate, the default action policy is deny, and any non-safety write would need an explicit capability, bounds, approval and an audit trail. Safety control is outside the product entirely.

The result says NOT VERIFIABLE and names what is missing. Mekai does not fill a gap with an assumption, an average or a model output. Coverage, gaps and provenance travel with every result.

Every result carries the formula version, the mapping version, the configuration it ran against, the evidence window, the exclusions and references to the source data. Someone else can re-run it and get the same number.

Yes. Checks, KPIs and reports are versioned functions with declared inputs, logic, outputs and tests. You can write them, change ours, or run both. In Mekai Open the calculations are open source, so nothing is hidden behind a licence.

Yes. Mekai Open runs entirely on your own infrastructure. Mekai Platform can be deployed privately, on-premises or air-gapped where the site or the customer requires it.

Vendor neutrality is how the data and function model is designed: the core event, asset and function model does not belong to one protocol or robot type.*

It is a design goal, not a qualification claim. What works with a specific vendor depends on the sources that vendor exposes and the access the site grants.

Commercial

Mekai Open is free. It is published under AGPL-3.0, runs on your infrastructure, and has no licence fee, seat count or sales call attached. Mekai Platform is quoted per deployment.*

Scope, number of sites and the integrations required decide the quote. There is no public price list, and no figure on this site is an offer.

No. It removes the manual assembly work around them — collecting evidence, recomputing numbers, rebuilding packs. The engineering judgement, the approval and the signature stay with the people who hold that authority today.

No. Mekai organizes and reviews evidence and reports what the available data supports. It does not approve systems, issue certification, perform conformity assessment or act as a notified body. The engineer, assessor or authority who signs today still signs.

Often you would not, for the part you have already built. The question worth asking is what happens to it when the ground moves under it, because it usually moves in three ways.

  • Standards keep changing. ISO 3691-4, ISO 13849 and IEC 60204-1 revise on their own schedule, and the EU machinery rules with them. A check written against last year's clause version does not fail loudly when the clause moves — it keeps passing and quietly stops meaning what it used to.
  • Your site keeps changing: a swapped sensor, a firmware or controller update, a second vendor's robot added to the fleet, a re-layout, a WCS or FMS release, a changed parameter set. Each one can invalidate a mapping, a threshold or a test your in-house layer assumed was stable, and nothing tells you which.
  • Your customer's reviewer still has to accept the number. An internal dashboard proves it to you. A result carrying its formula version, its window, its exclusions and its gaps proves it to them, without either side rebuilding it by hand.

Download Mekai Open and point it at your own recorded data. Nothing to sign, nothing to buy, no account. If it is useful, the conversation about the paid workspace can happen afterwards.

Mekai organizes and reviews evidence. It does not approve systems or replace engineering sign-off. It is not a certification or conformity-assessment service.

Mekai Labs

Bring the automation work your team still rebuilds by hand.

One fleet report, interface check, commissioning workflow, or change review is enough to start.

Schedule a call