Lynxby DOMINION
← Back to components

COMMUNICATION DRIVERS Connect to what is already on the plant floor.

Every protocol that turns up on the plant floor tends to bring a custom development behind it. And another thing to maintain.

The Communication drivers are the data inlet and outlet of Lynx. They read plant equipment in the protocols it already speaks —Modbus TCP/RTU, OPC UA · IEC 62541, MQTT / Sparkplug B, EtherNet/IP, BACnet, IEC 61850, DNP3 and the native protocols of Siemens, Rockwell and Omron PLCs, among others—. And they write setpoints to the equipment that allows it. The data flows both ways with your ERP, MES and CMMS, and is available to your own software over REST and MQTT.

Request a demo →

Configure the platform →

lynxplatform.cloud/conexiones/drivers
Connections · Drivers

WHAT YOUR PLANT ALREADY SPEAKS The three that move most of the data, and none of them has to be coded

The drivers talk to PLCs and sensors, SCADA systems, inverters and meters and process equipment in the protocols they already use. They read the signals and, where the equipment allows it, write setpoints. These three move most of the data; the rest of what the core speaks is in the list below.

  • Modbus TCP/RTURead and write

    Registers of PLCs, meters and field equipment, over Ethernet or serial line. Signal reads and setpoint writes.

  • OPC UA · IEC 62541Read and write

    Subscription to SCADA and PLC nodes, and writes to the nodes the server has enabled for it.

  • MQTT / Sparkplug BPublish and subscribe

    IIoT telemetry with the Sparkplug B data model, to and from the equipment and plant gateways.

  • No communication code to write

    They all come as standard: equipment that speaks any one on the list connects through its driver, with no communication layer developed from scratch.

  • Read and write

    Besides reading signals, the drivers write setpoints to the equipment that allows it, under the platform permissions.

  • Both ways with your systems

    ERP, MES, CMMS and BI receive the plant data, and Lynx receives from them what it needs, such as manufacturing orders.

  • A single point of access to the data

    REST and MQTT serve the normalized data, the same the modules see, to any third-party software.

WHAT IF YOUR EQUIPMENT SPEAKS SOMETHING ELSE? Three ways in, and you find out about none of them halfway through

No device is left out because of the protocol it speaks. Most are already implemented in the core and come in without touching the price; for the rest, either it gets developed or a third-party gateway translates it. All three ways are written down before you sign, not after.

  1. In the core

    The protocols the drivers already speak, most of them running in live installations: the open plant protocols and the native ones of Siemens, Rockwell and Omron PLCs. The device connects through its driver, with no communication layer developed from scratch and no change to the price.

    • Modbus TCP/RTU
    • OPC UA · IEC 62541
    • MQTT / Sparkplug B
    • EtherNet/IP · CIP
    • EtherCAT
    • CANopen
    • IEC 61850 · MMS
    • IEC 60870-5-101/104
    • DNP3
    • SunSpec
    • BACnet/IP · MS/TP
    • KNX · KNXnet/IP
    • M-Bus · Wireless M-Bus
    • DLMS/COSEM · IEC 62056
    • S7 · ISO-TCP
    • Logix · CIP
    • FINS

    Included in the core, with no per-driver fee and no charge per connected source.

  2. Through a gateway

    The field buses that cannot be solved in software: they need a master, an ASIC or dedicated electronics. A gateway translates them into Modbus TCP or OPC UA, and from there they come in through the core. Lynx does not speak them: the gateway does, which is why there is nothing to code.

    • PROFIBUS DP/PA
    • PROFINET
    • FOUNDATION Fieldbus
    • AS-Interface
    • DeviceNet
    • IO-Link
    • HART · WirelessHART

    The gateway is field equipment: it goes in the quote, with the rest of the installation.

  3. Custom built

    Whatever speaks none of the above and has no off-the-shelf gateway. It is integrated against the specific device, with its documentation at hand. This is DOMINION field work, the same that delivered the projects this site already publishes.

    • Proprietary protocols
    • Legacy equipment
    • Integrations already in place

    This is development, not licensing: it is quoted against the equipment in front of you.

What your plant speaks today, and which way each device comes in, is what the audit answers — before you sign anything. Who installs it: Turnkey →

ERP, MES, CMMS AND BI The data reaches your management systems, and comes back

Lynx delivers plant data to corporate systems and receives from them what the operation needs: the manufacturing orders from the ERP, for instance, are what the Production orders module crosses with electricity consumption.

  • ERP · SAP, Dynamics…

    Manufacturing orders into Lynx and plant data back to the management system.

  • MES · Manufacturing

    Process and energy data alongside the production of each line.

  • CMMS

    Communication states and asset alarms, available to the maintenance system.

  • BI and corporate platforms

    Series and indicators for company dashboards.

NO MANUAL EXPORTS Your software reads the same data the modules see

What Lynx collects and computes is available to third-party software without manual exports: queries through REST services and live subscription over MQTT, under the same permissions that apply in the platform.

  • REST

    Queries for series, latest values and indicators from any application that speaks HTTP.

  • MQTT

    Subscription to changes as they happen, for software that needs the data to the second.

Lynx by Dominion

Bring us your device list

Every device on that list is a custom development waiting its turn. Tell us which protocol each one speaks and which systems sit behind them, and we tell you which of the three ways each one comes in through, and what it takes.

Request a demo →

Or write to us directly at support.dt@dominion-global.com

← Back to components