Skip to main content

Kanoa and Ignition

On this page

Kanoa MES is built on and for Inductive Automation’s Ignition platform. This is not just a “compatible integration”—Ignition is the runtime environment that hosts Kanoa and enables its extensibility.

Kanoa is delivered as a combination of three things working together:

  1. A kanoaCore database schema deployed to Microsoft SQL Server
  2. A Kanoa Ignition Module installed on an Ignition Gateway
  3. A set of Kanoa Ignition Perspective Projects that provide the out-of-the-box MES application

This structure is intentional: it gives you a complete MES on day one, while keeping everything Ignition-native so you can extend it using the same tools and workflows you already use for industrial applications.

Kanoa MES is an Ignition module that you install in your Gateway, but it is more than a module and includes our database schema and Ignition projects.

Why build MES on Ignition?​

MES needs to sit at the intersection of:

  • shop floor data (PLC/SCADA, equipment events, production signals)
  • manufacturing context (assets, materials, orders, states, genealogy)
  • business systems (ERP, quality systems, reporting, analytics)

Ignition is a strong foundation for that because it’s designed as an industrial application platform with:

  • a server-based Gateway runtime and deployment model
  • modular, integrated feature delivery (drivers, modules, project system)
  • a modern web application framework via Perspective
  • native scripting and integration patterns for custom workflows

Kanoa builds on these fundamentals so we can focus on what’s unique to MES: standardized manufacturing structures and execution logic—without forcing customers into a closed or rigid application model.

What “Ignition-native” means in practice​

Because Kanoa runs inside Ignition, your team can treat Kanoa as part of your Ignition ecosystem:

  • Kanoa installs and runs on the Ignition Gateway
  • Kanoa screens and configuration tools are Ignition projects
  • Extensions and customizations are made in the Ignition Designer
  • Custom logic is implemented using Ignition scripting + system.kanoa APIs
  • Integrations use familiar Ignition patterns (gateway scripts, bindings, tags, web services)

If you know Ignition—especially Ignition Perspective—you already know much of the tooling required to work effectively with Kanoa. Perspective is also the UI framework for Kanoa’s out-of-the-box application.

How Kanoa extends the Ignition Gateway​

Ignition’s module system is designed to add platform capabilities directly into the Gateway environment (Gateway settings, Designer resources, drivers, scripting functions, etc.). Kanoa uses this model to extend Ignition with MES-specific functionality.

Kanoa adds:​

1) A standardized MES data model (SQL Server)​

Kanoa deploys a dedicated schema to Microsoft SQL Server and uses it as the system of record for:

  • configuration (assets, materials, routing structures, specs)
  • production context (orders, states, events, counts)
  • operational history (downtime, mode transitions)
  • optional module data (Quality and Trace)

Microsoft SQL Server is required for Kanoa MES deployments. We do not support any other database platforms at this time.

2) A high-performance MES API layer (KanoaMES Module)​

The KanoaMES Module runs inside the Gateway and provides the system.kanoa scripting namespace. This layer encapsulates:

  • validated MES operations
  • efficient database transactions
  • consistent write patterns and integrity safeguards
  • an API surface you can call from anywhere in Ignition

Example calls:

system.kanoa.asset.addAsset(...)
system.kanoa.events.getAssetStateEvents(...)
system.kanoa.order.addProductionOrder(...)

3) A production-ready application layer (Ignition Projects)​

Kanoa installs a structured set of Ignition projects that provide:

  • engineering configuration tools
  • operator execution screens
  • common MES workflows and navigation patterns

Because these are standard Ignition projects, you can inspect, troubleshoot, and extend them using normal Ignition skills—without being locked out of the application.

The Kanoa architecture model​

A typical deployment looks like this:

  • Ignition Gateway: runtime engine and hosting environment
  • Kanoa Module: MES logic + system.kanoa APIs inside the Gateway
  • Microsoft SQL Server: kanoaCore database (configuration + production history)
  • Kanoa Perspective Projects: out-of-the-box MES app + extension points
  • Your extensions: custom pages, scripts, reports, and integrations built in Ignition

What you can customize (and where)​

One of the main benefits of being built on Ignition is how and where you extend the system.

Common extension patterns​

Operator UX (Perspective)​

  • tailor operator stations to site-specific workflow
  • add line-specific execution controls
  • build mobile-friendly views for tablets and kiosks

Dashboards, reporting, and analytics​

  • build dashboards directly in Ignition
  • query the kanoaCore database for KPIs and trend views
  • implement role-based views for supervisors, engineers, and QA

Integrations (ERP / business systems)​

  • implement transactions (consume/produce, confirmations, inventory)
  • exchange master data (materials, routings, orders)
  • use gateway scripts and standard integration approaches

Custom automation logic​

  • execute site-specific workflow rules
  • apply validation layers around data collection
  • implement scheduling or orchestration helpers

In all cases, Kanoa’s goal is to provide strong MES foundations and APIs so your Ignition work stays clean, consistent, and upgradeable.

A philosophy of openness and ownership​

Kanoa is designed so your team can:

  • understand what the system is doing
  • access the data in SQL
  • inspect and extend the application projects
  • implement custom logic in the Ignition tools you already use

Kanoa will support the platform, ship fixes, and deliver upgrades—but you shouldn’t be forced into a black-box dependency model to troubleshoot or evolve your system.