EQUIPMENT. APPLICATIONS. PEOPLE.

Connect the systems
behind the operation.

Find a connection for your controllers, production equipment, data systems and enterprise identities. See what it connects to, how it could be used and what is available to configure.

Implementation phase

Phase labels follow estimated implementation progress for the connection scope shown: below 50% is In development, 50–79% is Pilot phase, and 80% or more is Complete. Deployment commissioning is assessed separately. Demo availability is shown alongside the phase.

Complete

Estimated implementation is 80% or more for the documented connection scope.

Pilot phase

Estimated implementation is 50–79%; the connection core is ready for pilot evaluation within its documented scope.

In development

Estimated implementation is below 50%; core features and the remaining scope are listed per connection.

Demo available

A lab runtime or simulated profile is available alongside the implementation phase.

CONNECTION DIRECTORY

Start with what you operate.

Search for a protocol, machine type or use case.

17 connection profiles

Plant & process equipment

6 connection profiles
OPC UAA common interface for equipment values and explicitly mapped machine actions.CompleteDemo available
85%

Secure native reads, writes, methods, visual mapping and scoped browsing are implemented and covered by protocol and gateway tests.

Connects to

  • PLCs and production controllers exposing an OPC UA server
  • Extruders, curing presses, packaging lines, drives and process skids

Typical use cases

  • Monitor temperatures, pressure, speed and operating state
  • Request a bounded setpoint change, line pause or exported controller action

Prepare for setup

  • Server endpoint and namespace
  • Readable NodeIds, units and data types
  • Gateway certificates, integration identity and permitted action mappings
Connection scope

Native OPC UA adapter with visual tag mapping, scoped browsing and policy-controlled commands.

Open setup reference Try working example Protocol reference
FactoryTalk OptixConnect to the published OPC UA interface of an Optix application.CompleteDemo available
80%

The OPC UA adapter supports published Optix nodes and exported methods; equipment-specific Optix applications are configured during deployment.

Connects to

  • Rockwell-based cells with a FactoryTalk Optix application
  • HMI applications that publish equipment tags and exported methods

Typical use cases

  • Read application tags and machine status
  • Request an approved recipe or bounded action exported by the application

Prepare for setup

  • Optix OPC UA server endpoint
  • Published nodes and exported methods
  • Trusted certificates and an integration account
Connection scope

Uses the native OPC UA adapter to read published application nodes and invoke exported methods.

Open setup reference Try working example Protocol reference
EtherNet/IP / CIPConnect approved Rockwell / Allen-Bradley tags for monitoring and optional bounded parameter writes through an enrolled Copper gateway.Pilot phaseDemo available
70%

Saved Logix tag reads and bounded writes, type checks, enrollment and evidence are implemented; controller validation currently uses a driver contract.

Connects to

  • Allen-Bradley ControlLogix and CompactLogix controllers
  • Vendor-profiled CIP devices such as drives and production equipment

Typical use cases

  • Monitor extruder temperatures, motor load, counters and alarms
  • Request an approved barrel setpoint or mapped boolean PLC request and record its acknowledgement and readback

Prepare for setup

  • Controller model, firmware, IP address and route or slot
  • Readable tags and explicitly writable scalar tags with actual device types
  • Gateway client 0.4, local write opt-in, engineering bounds, controller interlocks and an authorizing policy
Connection scope

Read mapped ControlLogix / CompactLogix tags through pycomm3. Optional governed mode writes explicitly mapped scalar tags with type checks, saved bounds, controller acknowledgement and matching readback. Requires local gateway opt-in and policy authorization. Readback confirms the parameter; process outcome requires separate verification. Cyclic I/O, motion and CIP Safety remain separate.

Configure core setup Try working example Protocol reference
PROFINETMonitor a PROFINET station and request approved scalar setpoints through its HTTPS gateway, with station identity and readback checks.In developmentDemo available
45%

Station-bound monitoring and governed writes work through an HTTPS gateway. A native cyclic PROFINET controller stack remains to be built.

Connects to

  • PROFINET controllers, distributed I/O and Siemens-based production cells
  • Conveyors, assembly systems, drives and process equipment

Typical use cases

  • Monitor station temperature, pressure and equipment state through an existing PLC HTTPS exporter
  • Set a bounded station parameter and verify its acknowledgement and fresh station-specific readback
  • Keep each machine mapping bound to its saved station and record the approved operation in evidence

Prepare for setup

  • Existing PROFINET PLC or bridge exposing an HTTPS JSON service
  • Station name, scalar monitoring mappings and a JSON field returning that station name
  • For writes: client 0.7, fixed endpoint paths, typed bounds, explicit success, GET readback, local opt-in and an authorizing policy
Connection scope

HTTPS gateway core with monitoring by default and optional governed scalar POST/PUT/PATCH writes. Governed telemetry, acknowledgements and GET readbacks must identify the saved station name. Typed bounds, signed expiry, local gateway opt-in and an authorizing policy apply. The native cyclic PROFINET stack is separate.

Configure core setup Try working example Protocol reference
Modbus TCPMonitor Modbus TCP equipment and optionally write approved holding registers or coils within saved bounds.CompleteDemo available
85%

Mapped register and coil reads, bounded writes, acknowledgement/readback and governed gateway execution are covered by actual TCP fixtures.

Connects to

  • Temperature controllers, energy meters and variable-speed drives
  • Pumps, chillers, furnaces, PLCs and process instruments with Modbus TCP

Typical use cases

  • Monitor extruder zone temperatures, pressure, screw speed or energy usage
  • Apply a bounded temperature setpoint or approved boolean request and record equipment acknowledgement and readback

Prepare for setup

  • Device IP address, port and unit identifier
  • Vendor register map, address base, scaling and byte or word order
  • Readable and writable ranges and confirmation registers
  • Gateway client 0.4, explicit write mappings, local operator opt-in and an authorizing policy
Connection scope

Read mapped registers, coils and discrete inputs. Optional governed mode uses function 5/6/16 writes with saved types, scaling, engineering limits, exact acknowledgement and matching readback. Requires local gateway opt-in and policy authorization; writes are not retried automatically. Readback verifies the parameter rather than the process outcome. TCP responses are checked for transaction, protocol and unit identifiers.

Configure core setup Try working example Protocol reference
Modbus RTUMonitor Modbus RTU equipment and optionally write approved holding registers or coils within saved bounds.CompleteDemo available
80%

Serial reads, CRC checking, bounded register/coil writes and readback are implemented and tested through a serial fixture.

Connects to

  • RS-485 or RS-232 instruments and temperature controllers
  • Legacy meters, drives, pumps and small process devices

Typical use cases

  • Monitor extruder zone temperatures, pressure, screw speed or energy usage
  • Apply a bounded temperature setpoint or approved boolean request and record equipment acknowledgement and readback

Prepare for setup

  • On-site serial interface and bus topology
  • Baud rate, parity, stop bits and unit addresses
  • Vendor register map, scaling and a hardware test connection
  • Gateway client 0.4, explicit write mappings, local operator opt-in and an authorizing policy
Connection scope

Read mapped registers, coils and discrete inputs. Optional governed mode uses function 5/6/16 writes with saved types, scaling, engineering limits, exact acknowledgement and matching readback. Requires local gateway opt-in and policy authorization; writes are not retried automatically. Readback verifies the parameter rather than the process outcome. Serial responses are checked for unit address and CRC.

Configure core setup Try working example Protocol reference

Data & applications

4 connection profiles
MQTTMonitor fresh equipment telemetry and request approved parameter changes with an explicit equipment acknowledgement.CompleteDemo available
80%

Persistent JSON telemetry and governed TLS application commands, expiry, matching acknowledgements and evidence are implemented and tested.

Connects to

  • Industrial IoT gateways and connected sensors
  • Monitoring systems, fleet services and applications publishing MQTT topics

Typical use cases

  • Monitor temperature, vibration and line-state telemetry
  • Request a bounded extruder setpoint through an equipment gateway implementing the JSON command/acknowledgement contract
  • Record an applied-value acknowledgement, explicit rejection or indeterminate outcome in the governed operation

Prepare for setup

  • TLS broker, trusted certificates, integration credentials and topic ACLs
  • Telemetry subscriptions, JSON value mappings and maximum reading age
  • Client 0.5, explicit command/acknowledgement topics, remote parameter names and typed bounds
  • Equipment application support for the documented JSON contract, command expiry, deduplication and local interlocks
Connection scope

Persistent JSON telemetry subscriptions with freshness checks. Optional governed mode publishes bounded parameter requests to fixed TLS topics using the documented FortEmerald equipment application contract. Requests expire, use fresh correlation IDs and require a matching non-retained applied-value reply. Broker delivery alone cannot complete an operation. Local gateway opt-in and policy authorization are required; no automatic command retry or physical-outcome claim.

Configure core setup Try working example Protocol reference
Sparkplug BMonitor scalar Sparkplug metrics with lifecycle checks and optionally request a fresh birth when joining or recovering a session.Pilot phaseDemo available
65%

Scalar birth/data/death decoding, aliases, sequence tracking and optional bounded birth recovery are implemented; broader metric types and output commands remain.

Connects to

  • Sparkplug-enabled edge nodes and industrial gateways
  • SCADA, HMI and plant data systems exchanging Sparkplug metrics

Typical use cases

  • Discover typed equipment metrics from birth messages
  • Track node or device availability and stale data
  • Exchange explicitly mapped node or device commands
  • Acquire a fresh birth after joining an already-running node or recovering a missing alias/sequence mapping

Prepare for setup

  • MQTT broker and credentials
  • Group, edge-node and device identifiers
  • Required metrics and permitted command mappings
  • For optional birth recovery: client 0.7, TLS broker access, NCMD permission for the saved node, request interval and attempt limit
Connection scope

Persistent scalar Sparkplug B receiver with birth/death, alias and sequence tracking. Optional TLS birth recovery sends only Node Control/Rebirth to the saved node, waits for fresh selected metrics and enforces request intervals and attempt limits. Passive monitoring remains the default. Output commands, datasets, templates and full host conformance remain separate.

Configure core setup Try working example Protocol reference
PI Vision / PI SystemRead process context from PI Web API and approved display information from PI Vision.CompleteDemo available
80%

Mapped PI values, history and saved PI Vision display references run through the gateway and evidence flow; Windows integrated authentication remains separate.

Connects to

  • Plant historians and PI-based process monitoring environments
  • Production lines whose equipment values are already recorded in PI

Typical use cases

  • Read mapped process values and bounded historical data
  • Investigate a deviation and locate approved PI Vision displays

Prepare for setup

  • PI Web API and PI Vision URLs
  • Readable stream WebIds and approved display IDs
  • An integration account or supported local credential profile
Connection scope

Native read adapter for snapshots, bounded history and the PI Vision display directory.

Open setup reference Try working example Protocol reference
HTTP / REST APIRead mapped HTTPS values and optionally submit approved scalar parameters to saved API endpoints, with acknowledgement and fresh GET readback.CompleteDemo available
80%

Saved HTTPS reads and bounded scalar POST/PUT/PATCH writes with authentication, acknowledgement and fresh readback are implemented and covered by TLS tests.

Connects to

  • MES, ERP and maintenance-management platforms
  • Vendor equipment services, workflow systems and business applications with documented APIs

Typical use cases

  • Monitor extruder setpoints, temperatures and other scalar equipment data through a documented API
  • Set an approved temperature target within saved bounds and verify the returned setpoint
  • Map a documented maintenance or process flag to an approved scalar operation and confirm its readback

Prepare for setup

  • Documented HTTPS base URL, GET telemetry mappings and private Basic, Bearer or OAuth credentials
  • For writes: client 0.6, a fixed POST/PUT/PATCH path, one scalar request pointer, success response and GET readback path/field
  • Approved types and bounds, provider support for idempotency and expiry where required, local opt-in and an authorizing policy
Connection scope

Gateway core available. Monitoring is the default. Governed mode supports saved POST, PUT or PATCH operations with bounded scalar JSON, explicit HTTP/application acknowledgement and exact GET readback. Signed expiry, local gateway opt-in and an authorizing policy are required. No automatic write retry or arbitrary URL, method or JSON payload.

Configure core setup Try working example Protocol reference

Robotics & mobile equipment

4 connection profiles
J1939 / CANPrepare and enroll a read-only Copper gateway for J1939 / CAN monitoring, with mapped values, freshness checks and policy-authorized reads.In developmentDemo available
40%

The gateway decodes approved single-frame PGN bit mappings; multipacket transport, diagnostic requests and bus control remain to be built.

Connects to

  • Generators, engine controllers and power units
  • Heavy vehicles and mobile industrial equipment publishing J1939 data

Typical use cases

  • Monitor engine speed, coolant temperature, operating hours and mapped diagnostics
  • Correlate equipment condition with maintenance and machine availability

Prepare for setup

  • Compatible CAN interface, bus bitrate and connection details
  • Required PGNs, SPNs and vendor signal definitions
  • Equipment-specific address and transport requirements
Connection scope

Gateway monitoring core available. Passively receive extended CAN frames through Linux SocketCAN and decode approved single-frame PGN bit mappings. No bus transmission or multipacket transport.

Configure core setup Try working example Protocol reference
MAVLinkExplore governed vehicle operations using the current lab runtime and portable test client.Pilot phaseDemo available
75%

The lab runtime, portable client, governed requests and acknowledgements are implemented; vehicle-specific field commissioning remains.

Connects to

  • MAVLink-capable drones and autopilot systems as an integration target
  • ArduPilot SITL and the portable virtual-device client in the current lab

Typical use cases

  • Rehearse readiness checks and approved vehicle-operation requests
  • Inspect command acknowledgements and returned telemetry in a simulated flight environment

Prepare for setup

  • Autopilot model and MAVLink interface
  • Companion gateway and transport details
  • Approved operations and a suitable validation environment
Connection scope

Lab runtime and portable virtual client for governed vehicle workflows, command acknowledgements and telemetry.

Open setup reference Try working example Protocol reference
ROS 2 / DDSMonitor mapped DDS or rosbridge topics and optionally call approved scalar services, with explicit success and a new matching topic readback.Pilot phaseDemo available
65%

DDS and TLS rosbridge topic monitoring and scalar services are implemented; rosbridge has wire tests and DDS has SDK contract coverage.

Connects to

  • ROS 2 robot controllers and autonomy software as integration targets
  • Robot arms, inspection robots and autonomous mobile robots

Typical use cases

  • Read approved robot-state and sensor message fields with per-topic freshness checks
  • Request a bounded process setpoint or an approved boolean equipment flag through an existing scalar service
  • Verify service success and a new matching state/setpoint topic value; retain the simulated robot-job profile separately

Prepare for setup

  • A sourced ROS 2 installation with rclpy, message and service packages, or a TLS rosbridge server with rosapi introspection
  • Explicit topics, message types and scalar field pointers; DDS domain, namespace and QoS
  • For writes: client 0.6, saved service name/type, exactly one scalar request field, boolean success field and matching readback topic
  • Approved bounds, local gateway opt-in, an authorizing policy and equipment-side interlocks; gateway timeout does not cancel remote work
Connection scope

Gateway core available. Monitoring is the default. Governed mode supports one saved typed scalar service request through rclpy DDS or TLS rosbridge, explicit success and a fresh matching topic value after acknowledgement. rosbridge also requires rosapi type and request-shape introspection. Signed expiry, local opt-in and policy approval apply. No automatic service replay, action goals or topic publishing. Physical and ROS distribution commissioning remains required.

Configure core setup Try working example Protocol reference
CANopenRead mapped CANopen objects and node heartbeat; optionally write bounded application objects with verified SDO acknowledgement and readback.Pilot phaseDemo available
65%

Scalar SDO reads/writes and heartbeat checks use real frames on a virtual CAN bus; PDO, NMT and motion profiles remain separate.

Connects to

  • CANopen drives, actuators and embedded controllers as integration targets
  • Motor-control equipment and motion subsystems

Typical use cases

  • Read temperature, status, counters and diagnostic scalar objects
  • Check node heartbeat and identify missing or stale telemetry
  • Write an approved application setpoint within saved bounds and record acknowledgement and readback

Prepare for setup

  • Operator-configured Linux SocketCAN interface, bitrate and node ID
  • Readable scalar object indexes, subindexes, data types and scaling from the equipment manual
  • Optional heartbeat age and a controlled CAN test environment
  • For writes: client 0.4, explicit writable application objects, engineering limits, local gateway opt-in and an authorizing policy
Connection scope

Expedited scalar SDO uploads over operator-configured SocketCAN. Optional governed mode adds bounded application-object downloads at indexes 0x2000–0xFFFF, exact acknowledgements and matching uploaded bytes. Requires local gateway opt-in, policy authorization and a recent heartbeat when configured. No NMT or predefined motion profile; process outcome is separately verified. The existing equipment demo remains separate.

Configure core setup Try working example Protocol reference

Enterprise identity

3 connection profiles
OpenID Connect (OIDC)Sign in to the console with a company identity provider and explicit links to existing company accounts.CompleteDemo available
85%

Company sign-in, PKCE, RS256 verification, explicit account links and session revocation are implemented and covered by backend and browser tests.

Connects to

  • Enterprise identity providers such as Microsoft Entra ID and Okta
  • Corporate sign-in and user identity systems

Typical use cases

  • Sign operators and supervisors into their company console with enterprise identity
  • Keep existing company roles and approvals attached to the explicitly linked account
  • Revoke company SSO sessions by disabling an identity link or provider

Prepare for setup

  • Public HTTPS issuer advertising S256 PKCE and RS256 ID tokens, and an application registration
  • Register https://secure.fortemerald.com/api/identity/callback exactly; enter the client ID and client secret if required
  • Create or choose existing company accounts and link their exact immutable provider subject identifiers before enabling sign-in
Connection scope

Company console sign-in using authorization code, S256 PKCE, browser-bound state, nonce and RS256 ID-token verification. Administrators explicitly link immutable provider subjects to existing active company accounts. Sessions are restricted to that company and revoke when its provider, account link or membership changes. Provider secrets are encrypted at rest. No automatic account creation, email matching or platform-administrator SSO. Standalone CLI identity checks remain available.

Configure core setup Try working example Protocol reference
OAuth 2.0Use scoped client-credentials tokens for continuous API reads, with token reuse, expiry renewal and one retry after HTTP 401.CompleteDemo available
80%

Scoped client-credentials authentication, token reuse and renewal, private credentials and saved-GET retry are implemented and tested.

Connects to

  • APIs and enterprise services protected by an OAuth authorization server
  • Service-to-service integrations and approved delegated application access

Typical use cases

  • Obtain a scoped access token for a maintenance or production API
  • Renew connector access according to the authorization-server policy

Prepare for setup

  • Authorization-server endpoints and client registration
  • Approved grant type, audience and scopes
  • Credential custody and token-lifetime requirements
Connection scope

Identity core available. Reuse scoped client-credentials tokens across gateway API reads, renew on expiry and retry a saved GET once after HTTP 401. Client secrets stay in the private gateway credential file. No delegated user authorization.

Configure core setup Try working example Protocol reference
SCIM 2.0Stage enterprise directory identities, then explicitly review selected users for scoped SSO-only company accounts.Pilot phaseDemo available
75%

Users/Groups, updates, deactivation and reviewed scoped SSO-only account provisioning are implemented; bulk and enterprise extensions remain separate.

Connects to

  • Corporate identity directories and provisioning services
  • Enterprise joiner, mover and leaver workflows

Typical use cases

  • Receive enterprise users and groups without automatically granting platform access
  • Review selected plant staff for an auditor, operator or approver account within explicit company deployments
  • Deactivate an approved managed account when its directory identity is disabled or deleted

Prepare for setup

  • Tenant-specific SCIM endpoint and directory bearer token
  • An OIDC sign-in provider and exact provider-subject links for approved accounts
  • Company-owner review of each active user, limited role and deployment scope
  • A tested deactivation/reactivation flow and reconciliation of interrupted updates
Connection scope

Tenant-bound Users/Groups directory with CRUD, filtering, pagination and token rotation. Staging remains the default. Reviewed provisioning requires company-owner approval of each new member account, a limited role and explicit deployments; an OIDC subject link is required for sign-in. Directory deactivation/deletion revokes managed sessions, and reactivation never revives old sessions. No administrator provisioning, existing-account takeover, automatic new-account approval or group-to-role grants.

Configure core setup Try working example Protocol reference

Prepare a useful connection.

Bring the equipment and interface details into setup, then define the permitted operation.

Identify the equipment

Record the machine or controller model, its location, the published interface and the on-site gateway that can reach it.

Map the useful information

Choose the values, units, timestamps and reported states needed to understand the operation. Use the vendor's tag, register or API definitions.

Define the allowed action

Specify the target, parameter limits, roles, approvals and feedback that confirms the outcome. Local machine interlocks remain authoritative.