notes-from-aug-20-kep-mtg.md

Notes from August 20 2018 meeting with Kepware

Attendees

• Shea
• Sam
• Brent (Kep)
• Nick (Kep

Kepware's IoT Gateway REST Server does not store data in a historical or time-series fashion

• Imagine a correspondence between a memory register on a PLC device (e.g. representing max torque measured, or max torque allowed) and a memory register on the KEPServerEX server
• When a new value is written on the PLC device, it also overwrites the value in the Kepware server register
• The exception to this is when using an IoT Gateway REST Client
  • An IoT Gateway REST Client is a Kepware service that collects data from KEPServerEX and forwards it to downstream services (e.g. Parsable)
  • In that case, new values written to the register are collected into a batch until the IoT Gateway REST Client is ready to forward them on downstream
  • However, after the batch is forwarded, it is gone forever

Brent suggested using an IoT Gateway REST Client to send us POSTs of new data

• This amounts to a preference for a push model, over a pull model
• With GETs to a REST Server, we'll miss any "last known values" that are overwritten between polls
• Can be used in concert with a REST Server receiving GETs in a push-to-pull model

Replication/Redundancy

• Some customers have a Primary/Secondary scheme to handle failures
• It requires more work through IoT Gateway than through the OPC UA protocol
• Procedure for handling broken Kepware<->Device connection:
  • client determines that the Kepware server has lost connection with a device
    • tags have a "quality" value that will change from "good" to "bad"
  • client sets the "_System.Enabled" tag to false on the device for the primary that lost connection
  • client sets the "_System.Enabled" tag to true on the device for that secondary
• Procedure for handling broken Kepware<->Parsable connection:
  • unclear

Simulated Devices

• Two methods:
  1. when creating the channel, select "Simulator" as the driver
  2. if using a regular driver, set the "Operation Mode" to "Simulated"

Addresses

• I'm still not totally clear on what an address is
• OPC UA defines an address space, so that could be it
• But it appears to be analogous to a variable on a device that can be read, and sometimes set

How and why do servers talk to one another?

KepServers and non-Kep, OPC Servers communicate via OPC UA to:

1. (KepServe@KepServer) aggregate tags from distributed servers onto a central server that can be queried more easily
2. (KepServer@OPCServer) make data available from the KepServer that was formerly only available via OPC

Security provisions

1. Use HTTPS
2. Some customers like an "airgap" of adding an extra KepServer hop between the one that connects directly to the control network and the one that talks to the open world
3. Users and User Groups can be created that only have access to certain resources

• "User Manager" for creating users and groups
• "Security Policies" for determining access

Deployment

• Each site gets one or more KepServer hosts, running KEPServerEX V6 and IoT Gateway
• Each host has a project (with Channels with Devices with Tags)
• An HTTP Client running in IoT Gateway sends POST requests to Parsable
• If we come across a customer who already uses Kepware, then:
  • Ensure they have a late enough version to support IoT Gateway
  • Either hook directly into their server, or put another one in front of it

Interface methods

OPC UA

• Free

REST

• Support will only be increasing, as Kepware expects more clients to utilize this
• Costs a licencing fee per deployment

ODBC

• Uses the "Data Logger" plugin
• Allows the Kepware side to handle transport, and the database to handle storage