Device Types

A device type is a reusable, versioned definition of a piece of industrial equipment — its tags, alarms, commands, faceplate components, and state machine. A device instance is one of those types commissioned against real hardware at a specific site. The relationship mirrors a Rockwell AOI or an Ignition UDT (the type) and an AOI instance in a running PLC program (the instance).

Defining equipment once and instantiating it many times is what makes Consystence’s model tractable: a fix to a pump faceplate or an alarm threshold lands everywhere the type is deployed, and dependency tracking (which instances use which type version) stays explicit.

Types vs instances

	Device type	Device instance
What it is	Reusable template: tags, alarms, commands, components, state machine	A configured device at a site, based on a type
Scope	Shared, versioned, portable across sites and orgs	Per-site; never reused
Identity	Dotted type id, e.g. consystence.pump.centrifugal	Site-local asset, e.g. AssetNumber PP-01
Defines	The shape of the equipment	The mapping of that shape onto real controller tags
Lives in	A library package	A commissioned site’s configuration

A type declares an abstract tag named Speed; an instance binds that tag to a concrete controller address (for example Program:DamTransfer.Pump1.Speed). An instance is live as soon as it is created — through the web console’s Add device form, the CLI or the API, or when a site configuration export is provisioned onto a server — with alarms, P&ID bindings, AI context, and historian attribution built on its tag mappings from that point. Confirming those mappings against the real controller is engineering discipline the platform does not yet enforce: a formal propose-then-commission workflow is planned, not shipped.

The engineering model

Tags should not float in a flat namespace — they have a known physical origin. Consystence’s engineering model is controller → module → channel → tag, with the controller’s Tag Register — its data points — as the authoritative namespace a device type may draw from.

flowchart TD
  C[Controller<br/>ControlLogix / PLCnext] --> M[Module<br/>slot-addressed I/O]
  M --> CH[Channel<br/>single I/O point]
  CH --> TR[(Tag Register<br/>flat tag namespace)]
  TR -. references .-> DT[Device Type<br/>reusable definition]
  DT --> DI[Device Instance<br/>commissioned per site]
  DI --> P[Process<br/>instances at a site]

• Controller — owns the backplane and scan cycle; the root of all I/O ownership. Consystence uses the term controller (ControlLogix and PLCnext today), not “PLC”.
• Module — passive, slot-addressed hardware (digital/analogue I/O, comms adapters, safety, power, compute). In the target model, modules are schemas, not state machines.
• Channel — an individual I/O point that feeds the Tag Register.
• Tag Register — the authoritative flat namespace of every data point (typed controller tag) the controller exposes, populated by browsing the controller.

Shipped vs target model

Today the platform ships the two ends of this chain: controllers, whose Tag Register is a flat namespace filled by tag browse, and device types that map onto those tags. Modules and channels are not yet first-class objects — rack-mount I/O modules are currently modelled as ordinary device types in the consystence.io library (and those types do declare advisory display states such as Running / Faulted / Offline). The module → channel provenance layer, and the module-replacement impact analysis it enables, is the target model.

Mapping validation: by design, a device type should reference data points that exist in the controller’s Tag Register. The platform does not yet check this — tag mappings are stored as given, and a mistyped path surfaces as a runtime read/write failure rather than an error when the instance is created. Validation of tag mappings against the register is planned.

For how those tags are read from the controller — gRPC to PLCnext GDS/PORT variables, or EtherNet/IP CIP direct to ControlLogix — see PLC communication.

Anatomy of a type package

A device type is a YAML manifest plus assets. A library groups related device types under a library.yaml manifest; a library’s page in the web console can also save it as a .cspkg package.

consystence.pump.centrifugal/
├── manifest.yaml      # type id, tags, calculations, states, aiContext
├── simulation.yaml    # optional simulation profile
├── components/        # faceplate, status card, detail view
├── alarms/            # alarm definitions
└── commands/          # command definitions (tag writes, preconditions, audit)

Each layer has its own page:

• Type system — the manifest schema, versioning, dependencies, and the type/instance/library/marketplace hierarchy.
• Tags — the tag schema: dataType (Bool / Int / DInt / Real / String), access (Read / Write / ReadWrite), rangeMin/rangeMax, and the physicalRole (Input / Output / Internal / System) that classifies a tag in the simulator–controller data flow.
• Alarms & commands — condition-driven alarms and audited, precondition-gated commands.
• Creating types — authoring a type package from scratch.

Shipped libraries — the Standard Library

The four first-party libraries below make up the Consystence Standard Library — 42 device types today across pumps and industrial equipment, I/O and controllers, materials handling, and wet processing. Each library is versioned. The control behaviour beneath the types comes from a single behavioural master written in C#: the native simulator runs it directly, ControlLogix blocks are checked against test vectors the master produces, and a generated PLCnext runtime program is built from the same source and checked with live tests on a virtual PLCnext only, with no conformance replay yet; per-block vector replay on PLCnext is planned. Not every block has all three executions yet. On controllers, conformance testing and the device and sequence layers are ControlLogix today. The aim is equivalent behaviour, not identical execution. Type ids below are representative, not exhaustive — see each library manifest for the full set.

Library	Focus	Example type ids
consystence.pumps (Industrial Equipment)	Pumps, VFD motors, process sensors, valves, PID, pump-start and generic sequences	consystence.pump.centrifugal, consystence.motor.vfd, consystence.sensor.flow, consystence.valve.motorised, consystence.pid.controller
consystence.io (I/O & Controllers)	Controllers, controller diagnostics, rack-mount I/O modules and the standard sequence	consystence.controller.logix, consystence.controller.plcnext, consystence.io.di32, consystence.io.do16, consystence.io.remoteio, consystence.sequence
consystence.materials-handling	Dry-bulk handling and condition monitoring	consystence.conveyor.belt, consystence.crusher, consystence.chute, consystence.screen.vibrating, consystence.feeder.apron, consystence.weightometer, consystence.sensor.vibration, consystence.positioner, consystence.magnet.tramp-metal
consystence.wet-processing	The wet side of a coal preparation plant	consystence.dmc.cyclone, consystence.dmc.magnetic-separator, consystence.thickener, consystence.stockpile

The library schema supports inter-library dependencies with semver constraints — though the first-party libraries currently declare none. The first-party libraries ship pre-registered in the platform-wide type catalogue, so any organisation can use them without an install step, and instances reference a type at a pinned version. Device types belong to that global catalogue, not to an organisation. Loading your own libraries into it, and customising a type per tenant through overrides against a pinned (typeId, version) rather than through per-organisation copies, are planned; see Marketplace.

Roadmap

You cannot yet load your own device types: today the platform runs Consystence’s first-party libraries, and the four above ship with it. A public marketplace for discovering and installing third-party libraries is also planned; its distribution and commercial model are to be announced. See Marketplace.

The advisory boundary

Consystence’s AI helps you author device types. Today its tools read what the platform already holds: the site’s registered controllers (name, platform and status) and their browsed data points, device types, live values, trends, alarms and events. It can propose a live tag browse of a controller, which a person with engineering rights confirms on the controller’s page. Commands are propose-only (an operator confirms every execution); the assistant does not register controllers, change tag bindings or deploy controller code, and creating a device instance remains a human action. Richer onboarding — reading module and program structure, then proposing module profiles and device-type signal surfaces, confidence-scored, for an engineer to review device by device — is planned, not yet shipped. The platform also runs a shadow of each type’s state machine — fed by live tag values — so the AI can explain why a device is in a given state (for example, “Pump 1 is Interlocked because its Interlock input is active while it is not running”) rather than inferring it from raw booleans.

Advisory only

The AI reads, explains and recommends — it never commands equipment. The state-machine shadow is advisory. Hard safety interlocks live in I/O-module hardware, in safety relays, or in the controller — never in Consystence, and never behind the AI. Soft control of real equipment stays in the controller too: the Consystence runtime runs a type’s control block (the Native topology; see the type system) in simulation only. Operator commands defined on a type (Alarms & commands) are executed by people and are audited; the AI does not issue them.

Where next

• New to the model? Start with platform concepts.
• Understand the type system and the tag schema.
• Define behaviour with alarms & commands.
• See how a type is authored in creating types.
• Read about the planned marketplace for distributing libraries.