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 CLI or 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 / Modbus] --> 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, PLCnext, Modbus), 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 the edge actually reads and writes those tags — gRPC to PLCnext GDS/PORT variables, or the legacy direct EtherNet/IP CIP path — see PLC communication.

Anatomy of a type package

A device type is a YAML manifest plus assets. A library of related device types ships as a .cspkg bundle.

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 three first-party libraries below make up the Consystence Standard Library — 22 device types today across pumps and industrial equipment, I/O and controllers, and materials handling. Each library is versioned, and the control behaviour beneath the types is a single behaviour master: one block library maintained against published conformance vectors, replayed in CI so every target expresses the same behaviour. 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, sequencers	consystence.pump.centrifugal, consystence.motor.vfd, consystence.sensor.flow, consystence.valve.motorised, consystence.pid.controller
consystence.io (I/O & Controllers)	Controllers and rack-mount I/O modules	consystence.controller.logix, consystence.controller.plcnext, consystence.io.di32, consystence.io.do16, consystence.io.remoteio
consystence.materials-handling	Dry-bulk handling and condition monitoring	consystence.conveyor.belt, consystence.crusher, consystence.chute, consystence.sensor.temperature, consystence.sensor.vibration

The library schema supports inter-library dependencies with semver constraints — though the three first-party libraries currently declare none. The first-party libraries ship pre-registered in the platform-wide (global) type registry, so any org can use them without an install step; custom types are installed into an org’s own registry, which is checked before the global one. Either way, instances reference a type at a pinned version. The per-org registry is being retired in favour of the global catalog: customisation is moving to per-instance and tenant-level overrides against a pinned (typeId, version), rather than per-org type forks — see Marketplace.

Caution

A public marketplace for discovering and installing third-party libraries is planned and not yet available; its distribution and commercial model are to be announced. Today the three first-party libraries above ship with the platform. See Marketplace.

The advisory boundary

Consystence’s AI helps you author device types: today its tools span read-only discovery — discovering a controller, reading its identity (name, platform, firmware, serial), browsing its data points and inspecting types — plus admin-gated configuration actions such as registering a controller. Commands are propose-only (an operator confirms every execution), control-code deployment requires out-of-band operator confirmation, and creating device instances remains a human action through the CLI or API. 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 in AwaitingPermissives because DischargePressure is above threshold”) rather than inferring it from raw booleans.

Advisory only

The AI configures, queries, classifies, and explains equipment — it never commands it. 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 logic can run in the Consystence runtime: under the Native topology a type’s control function block executes as a .NET grain (see the type system). 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.
• Build your own with creating types.
• Distribute and discover with the marketplace.