Azure IoT Hub is a fully managed service specifically designed for IoT devices, providing a secure and scalable way to connect, monitor, and control billions of IoT devices.
OAS provides connectivity to Azure IoT Hub using the OAS Azure IoT driver by setting the Type to IoT Hub.
The following connection parameters can be configured:
Azure IoT Device ID: The ID that uniquely identifies this connection.
Azure IoT Connection: The connection string to Azure IoT.
Azure IoT Hub: The name of the Event Hub.
Azure IoT Transport: The protocol to use for communication. [AMQP, AMQP Web Sockets Only]
Return to Online: The frequency in seconds to check for good communications when the interface is taken offline.
Store and Forward
Enable data buffering when communication failure occurs. Values will be stored to directory specified under Configure > Options > Store and Forward.
To buffer data from remote OAS Engine enable Buffer for Remote IoT Publish under Configure > Options > Store and Forward on each remote data source system.
Failover
You can enable the Enable Failover property and configure a secondary bootstrap server and security protocol. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to communicate.
Publish Selected Tags
The Publish Selected Tags feature allows you to specify a list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a Boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.
Azure Event Hubs is a big data streaming platform and event ingestion service that is designed to handle millions of events per second. It is optimized for high-throughput, low-latency data streaming scenarios.
OAS provides connectivity to Azure Event Hubs using the OAS Azure IoT driver by setting the Type to Event Hubs.
The Azure Event Hubs service supports ingestion using standard JSON payloads or optimized payloads using the Apache Avro format. Set the Schema Type to one of the following:
None: Use the standard JSON format.
Avro: Use the Avro schema format.
Note that if you want to use the Avro schema type you will have to define a schema in Azure using the Schema Group setting in the Schema Registry.
Connection Parameters
The following connection parameters can be configured:
Azure IoT Connection: The connection string to Azure IoT.
Azure IoT Hub: The name of the Event Hub.
Partition Key: The partition key to use.
Return to Online: The frequency in seconds to check for good communications when the interface is taken offline.
Store and Forward
Enable data buffering when communication failure occurs. Values will be stored to directory specified under Configure > Options > Store and Forward.
To buffer data from remote OAS Engine enable Buffer for Remote IoT Publish under Configure > Options > Store and Forward on each remote data source system.
Failover
You can enable the Enable Failover property and configure a secondary bootstrap server and security protocol. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to communicate.
Publish Selected Tags
The Publish Selected Tags feature allows you to specify a list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a Boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.
Sparkplug B is an industry-standard that enables common topic and payload definitions on top of a standard MQTT data transport layer.
OAS can be configured in a number of ways to act as a Primary Application, Secondary Application or Edge of Network (EoN) node. It can even be configured as both a host and an EoN to support scenarios such as acting as a data proxy and protocol conversion.
👉 See the following links to get started with Sparkplug B:
The OAS platform provides three different modes of operation when using a Sparkplug B driver:
Edge of Network (EoN) Node (Edge Node)
Primary Application (Host App)
Secondary Application (Client App)
Edge Node
To configure your OAS instance as an EoN node you will first create a Sparkplug B driver instance where the Mode parameter is set to Edge Node and configure the relevant properties such as the Host ID, Group ID and Edge Node ID. The driver will manage the connection to the Primary Application.
For each Tag that you wish to publish using the Sparkplug B interface, you have to set the Host Group ID, Host Edge Node ID, Host Device ID, and Host Metric properties. This works for any Tag that you have configured in your OAS instance irrespective of the data source configured on the Tag. This allows OAS to act as a gateway between various device protocols and convert data to MQTT.
With the Edge Node configuration you can also manage the Host Mode to be either Self Hosted or Remote Hosted. When self hosted, the state of the Tag will be managed by whether the OAS instance is in runtime mode or not. When remote hosted, the state is managed by the Primary Application.
Host App
To configure OAS as a Primary Application node you will first create a Sparkplug B driver instance where the Mode parameter is set to Host App and set the Host ID. In this mode, the driver will receive MQTT messages that are destined to the given Host ID.
If Add Client Tags Automatically is selected then OAS will automatically add tags to the Sparkplug B instance. You can further control which Tags are added based on Group, Edge Node and Device filters.
Client App
When the Mode parameters is set to Client App the node will act as a Secondary Application. This is similar to the Host App configuration, but it will only subscribe to the Tags and the data changes rather. It will not track the state of nodes.
MQTT Broker
When configuring a Sparkplug B driver, you can choose to connect to the internal OAS MQTT broker or you can use an external MQTT broker. The driver configuration provides properties that you can use to configure the connection and security parameters for your broker:
Host: The MQTT broker IP address or host name.
Port: The MQTT broker port number. [1883]
User Name: The username used to authenticate into the MQTT broker.
Password: The password used to authenticate into the MQTT broker.
Keep Alive Time: The MQTT broker connection keep-alive time in seconds. [60]
Reconnect Time: How long to wait before reconnecting if connection is lost in seconds. [1]
Buffer Timeout: The time in seconds the broker must respond after a write, if not responsive the buffer will be cleared. [0]
Max Buffer Messages: The maximum number of messages that can be queued before older messages are dropped. [30,000]
Protocol Version: The MQTT protocol version. [V311]
Client ID: The MQTT client ID.
Return to Online: The frequency in seconds to check for good communications when the interface is taken offline. [60]
The OAS MQTT broker can be configured using MQTT Broker tab in the Configure > Options screen. If you have the internal broker running, you can set the Host to localhost or to the IP or host name of another OAS instance that is running the MQTT broker. You will also need to configure the port, username, password and SSL/TLS parameters based on the broker configuration.
Failover
The Sparkplug B driver supports configuration of a failover MQTT broker. You can do this by setting the Enable Failover checkbox and then filling in the failover connection properties. The secondary connection will be used if the primary interface is deemed to be offline. It will switch back to the primary interface if it becomes available.
The OAS platform MQTT connector provides a MQTT broker and a MQTT client. Any local or remote MQTT client can subscribe to the OAS broker and receive Tag data updates in real-time. You can also send data to remote brokers using the MQTT driver configuration and assign individual Tags to subscribe to external broker topics or publish a set of selected tags to an external broker.
MQTT Broker
The broker provided by the OAS platform is a part of the MQTT product feature. It is installed as part of the OAS platform installation providing you with a broker for reading and writing Tag data.
Tag data is presented in topic names that use standard Tag Path notation. For example, if you have a tag group called Site1 and tag in the tag group called Temperature then the tag path for the Value property of the Temperature tag will be Site1.Temperature.Value.
The following images illustrate how a Tag is presented as an MQTT topic:
Using the Configure > Options > MQTT screen, you can configure a number of MQTT parameters including:
Port numbers
SSL security
Broker client ID
Retain feature
Authentication
MQTT Client Driver
The MQTT client driver provided by the MQTT product feature allows you to publish to and subscribe from external MQTT brokers.
Subscribe to External Broker Topics
To subscribe to external broker topics, you will create an MQTT driver instance with the required connection parameters to authenticate against the external broker. To read the value of a specific topic, you will create a Tag, set the Data Source property to MQTT, select the driver you created and then specify the topic name. This Tag will now be updated whenever the external broker publishes a new value to the specified topic.
Publish to External Broker Topics
To publish to an external broker topic, you will create an MQTT driver instance and then set the Publish Selected Tags feature.
This feature allows you to specify a list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a Boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.
The OAS Kafka communication interface is both a producer and consumer, to both local and cloud clusters.
Kafka Consumer
A Kafka Consumer configuration is one where you configure the parameters of a Kafka driver to connect to a Kafka cluster and you create Tags with the Data Source set to Kafka. You then specify the topic that the Kafka consumer should subscribe to in order to receive the data.
A Kafka Producer configuration is one where you configure a Kafka driver and you enable the Publish Selected Tags property to specify the list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.
The Kafka driver supports the following connection parameters:
Bootstrap Servers: The Kafka cluster bootstrap server IP or hostname and port.
Security Protocol: The security type to use for the connection. [Plaintext | Ssl | SaslPlaintext | SaslSsl]
Acks: The acknowledgement strategy to use in order to control durability. [None | Leader | All]
Client Id: An id string to pass to the server when making requests.
Compression Type: The compression level to use. [None | Gzip | Snappy | Lz4 | Zstd]
Networking Parameters
The Kafka driver supports the following networking and message parameters for tweaking the performance of the connection:
Batch Num Messages: The number of messages to send in one batch when using async mode. [10,000]
Batch Size: The batch size in bytes. [1,000,000]
Linger: The number of milliseconds a producer is willing to wait before sending a batch out. [5]
Max In Flight: Controls the maximum number of outstanding requests a producer can send to a Kafka broker before waiting for a response. [1,000,000]
Message Max Bytes: Maximum Kafka protocol request message size. [1,000,000]
Message Timeout: Local message timeout in milliseconds. This value is only enforced locally and limits the time a produced message waits for successful delivery. A time of 0 is infinite. [300,000]
Queue Buffering Max Kbytes: Maximum total message size sum allowed on the producer queue. This queue is shared by all topics and partitions. This property has higher priority than Queue Buffering Max Messages. [1048576]
Queue Buffering Max Messages: Maximum number of messages allowed on the producer queue. This queue is shared by all topics and partitions. [100,000]
Request Timeout: Timeout for sending messages in milliseconds [30,000]
Socket Connection Timeout: Maximum time allowed for broker connection setup (TCP connection setup as well SSL and SASL handshake). If the connection to the broker is not fully functional after this the connection will be closed and retried. [30,000]
Socket Keepalive Enable: Enable TCP keep-alives on broker sockets. [False]
Socket Timeout: Default timeout for network requests in milliseconds. [60,000]
Transaction Timeout: The maximum amount of time in milliseconds that the transaction coordinator will wait for a transaction status update from the producer before proactively aborting the ongoing transaction. [60,000]
Store and Forward
Enable data buffering when communication failure occurs. Values will be stored to directory specified under Configure > Options > Store and Forward.
To buffer data from remote OAS Engine enable Buffer for Remote IoT Publish under Configure > Options > Store and Forward on each remote data source system.
Failover
You can enable the Enable Failover property and configure a secondary bootstrap server and security protocol. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to communicate.
The OAS MTConnect IOT Data Connector provides automated setup from MTConnect enabled devices, typically CNC machines. The device information is read on event to optionally automate the tag creation from device, components, sub-components, and ids for Events, Conditions, and Samples.
When creating a MTConnect driver instance the default configuration enables the Add Tags Automatically property. With this property enabled, the driver will generate all of the Tag Groups and Tags based on the received schema. You can then delete any Tags that you do not need.
Reconnect and Polling Interval
You can control two properties to manage driver reconnection and polling interval:
Return to Online: How long to wait between successive connection attempts following a failed connection [60 seconds]
Interval: The interval at which to poll the endpoint [0.5 seconds]
Failover
You can enable the Enable Failover property and configure a secondary Live Data Url to connect to an alternative schema and data endpoint. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to read any data.
The Siemens connector is a device driver with support for Ethernet connectivity to common Siemens S7 processor types including S7-200, S7-300, S7-400, S7-1200 and S7-1500.
The following sections describes properties that relate to the driver configuration.
IP Address
The IP address of the device.
Connection Type
The connection to a Siemens device can be configured with the following parameters:
Processor Type: The processor type [S7-200 | S7-300 | S7-400 | S7-1200 | S7-1500]
Link Type: The link type [PC | OP | PG]
Rack: The rack number [0]
CPU Slot: The CPU slot number [1]
Timeouts and Retries
You can manage the timeouts and retries that OAS will apply to the connection. You can tweak the following configuration properties depending on your requirements:
Transaction Timeout: The timeout when sending a message in milliseconds [1000]
Connection Timeout: The timeout when opening a connection in milliseconds [2500]
Return to Online: When a driver is disconnected due to bad messages, a new connection will be attempted after this many seconds [60]
Write Behaviors
You can manage the behavior of the Siemens driver when performing writes using the following properties:
Write Latest Value Only
When enabled only the last value in the pending queue of writes will be written to the controller. This property is useful to account for slow networks or slow responding controllers.
Single Write
When enabled each value will be written one at a time to the device. When disabled all values will be written together to the device.
Read After Write
When enabled a synchronous read will be called after each write to the controller.
Failover
You can enable the Enable Failover property and configure a secondary IP address, rack and CPU slot. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to send a message after a failed connection.
The following sections describes properties that relate to the driver configuration.
Type
Master | Slave
When you choose a Slave connection type you will be able to specify a Device Address. This is the device address that any Modbus master clients must use to connect to this slave instance.
These options are available on both serial and Ethernet connection types. This gives you the ability to choose between native protocols and protocol conversion such as Ethernet to serial converters.
For example:
Choosing Ethernet and TCP will result in a standard Modbus TCP connection.
Choosing Ethernet and RTU will result in a Modbus RTU over TCP connection.
Choosing Serial and RTU will result in a Modbus RTU connection.
Address and Port
Ethernet
The Ethernet connection type allows you to specify:
IP Address: The IP address of the Modbus device listening for connections
Port Number: The port number of the Modbus device listening for connections [502]
Serial
The Serial connection type allows you to specify:
Serial Port Number: The COM port number (Windows) [1]
Linux Port Name: The TTY port address (Linux) [/dev/ttyS0]
Baud Rate: 110 to 921600 [Baud Rate 9600]
Parity: None | Odd | Even | Mark | Space [None]
Data Bits: 7 | 8 [Data Bits 8]
Stop Bits: None | One | Two | One Point Five [One]
RTS Enable: True | False [False]
Timeouts and Retries
For both Master and Slave as well as Ethernet and serial connections you can manage the timeouts and retries that OAS will apply to the connection. You can tweak the following configuration properties depending on your requirements:
Timeout: The timeout when sending a message in milliseconds [1000]
Connection Timeout: The timeout when opening a connection in milliseconds [2500]
Number of Retries: The number retires before it is deemed a failure [3]
Delay Between Packets: Time to wait between each packet in seconds (Ethernet only) [0]
Bad Msgs to Offline: After this many messages have failed, the driver will be disconnected [3]
Return to Online: When a driver is disconnected due to bad messages, a new connection will be attempted after this many seconds [60]
Write Behaviors
You can use the Enable Single Write and Enable Multiple Write configuration properties to manage the behavior of the Modbus driver when writing to one or more registers.
Enable Single Write
When this option is disabled, the driver will use function code 15 for output coils and function code 16 for holding registers even if only one register is being written to.
When this option is enabled, the driver will use function code 05 when only one output coil needs to be written and 06 when only one holding register needs to be written to.
Enable Multiple Write
When this option is disabled, the driver will write holding registers one at a time using function code 06. The number of words that are written depends on the data type of the Tag that is using this driver.
Int16 = 1 (short)
UInt16 = 1 (unsigned short)
Int32 = 2 (int)
UInt32 = 2 (unsigned int)
Int64 = 4 (long)
Uint64 = 4 (unsigned long)
Float32 = 2 (single)
Float64 = 4 (double)
When this option is enabled, the driver will write multiple holding registers using function code 16.
Counters
The Modbus driver provides the option to enable one or more communication quality monitoring counters for both reads and writes. The following are provided:
Bad Count: The number of transitions from good to bad
Bad Read Count: The number of failed reads
Bad Time: The total number of seconds the driver has been in a bad state
Bad Write Count: The number of failed writes
Good Count: The number transitions from bad to good
Good Read Count: The number of successful reads
Good Time: The total number of seconds the driver has been in a good state
Good Write Count: The number of successful writes
To reset the above counters, set a boolean Tag in the Count Reset property and then set the value of the Tag to TRUE. You can also use the Tag’s Reset Value To False property to make sure the Tag’s value automatically goes back to FALSE so that you can reset the counters again next time without having to manually set the Tag back to FALSE.
Failover
When using the Master communication type, you can enable the Enable Failover property and configure a secondary IP address or serial port depending on whether you have an Ethernet or Serial connection. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to send a message after the given Number of Retries and Bad Msgs to Offline attempts.
Logging
You can enable detailed message and transaction logging for Modbus drivers by configuring the logging option in the Configure > Options > System Logging menu.
Enable the Log Modbus Communications property and optionally specify the name of the driver interface you wish to log. Note that this kind of logging consumes additional CPU and storage resources if left enabled.
The Allen Bradley connector is a device driver with support for two categories of Allen Bradley devices. The two driver types that are provided in this connector are called AB Logix and AB Classic. Both drivers communicate over an Ethernet connection.
If you are using a ControlLogixData Highway Remote I/O Communications Interface Modbus (DHRIO), you specify the IP address as a connection string using the following format:
<IP Address>,<Backplane Number>,<Slot Number of DHRIO>,<Channel Number of DHRIO>,<Node Address of Remote Device>
where:
The Backplane Number is always set to 1.
The Slot Number is a decimal number.
The Channel Number of DHRIO has a value of A or B.
The Node Address is provided as an octal number.
AB Logix Driver Type
The Allen Bradley AB Logix supports the devices listed in the previous section.
Processor Type
The supported processor types are ControlLogix and Micro800.
The Control Logix processor type requires setting a Backplane number and a CPU Slot number.
AB Classic Driver Type
The Allen Bradley AB Classic supports the devices listed previously.
Device Type
The AB Classic driver supports the following connection types:
CSP: Default for PLC5 and SLC5/05 Direct Connections
EIP: Micrologix 1010 and newer PLC5 and SLC5/05 Direct Connections
ENI: 1761-NET-ENI connections to PLC5, SLC500 and MIcroLogix
CLG DH: ControlLogix Gateway to PLC5, SLC500, MicroLogix and ControlLogix Gateway to SLC5/04 via DH+
For each selected connection type, you have a choice of the following Processor Types:
The Open Automation Software Device Connectors give you the option to connect to and source data using a range of protocols supported by a range of local and remote device vendors. These connectors include:
Allen Bradley
Modbus
MTConnect
Siemens S7
In addition to this, the OAS platform also supports communicating with Raspberry Pi GPIO.
Allen Bradley
The Allen Bradley Connector provides connectivity for two families of controllers: AB Logix and AB Classic.
The AB Logix family includes ethernet communications and can communicate with ControlLogix, CompactLogix, GuardLogix and Micro800 processors.
The AB Classic family includes MicroLogix, SLC 500, and PLC-5.
The Modbus connector provides connectivity to Modbus devices in master and client mode and supports Modbus TCP for ethernet communications and Modbus RTU and ASCII for serial communications.
The MTConnect Connector is designed to integrate with your MTConnect enabled devices based on a defined schema. Data is ingested based on events and Tags can be added automatically.
The Raspberry Pi GPIO Connector supports communications with General Purpose Input / Output pins when the OAS instances is deployed on a Raspberry Pi 4. Tags can be defined to directly read or write to the GPIO pins.
