KepConnect is a unique service that shims multiple Kepware™ communications servers and your enterprise systems. Data exchange between the two environments is accomplished through Kepware’s IoT Gateway agents. With KepConnect, you choose what to connect, collect, combine, compute, and convey. index
Interop With Enterprise Systems
Leverage the Microsoft.NET framework and transform industrial data into information and knowledge through C# scripts.
Script Missing PLC Logic
Create custom representations of data from multiple PLC sources.
Generate Knowledge With Splunk
Combine manufacturing and operational data and convey it into Splunk with a single line of code.
Approach IIOT with a pragmatic lens and a community driven framework.
Web Application / HTTP API
Created using the latest version of Microsoft ASP.NET MVC and Web API.
Kepware Technologies is the only player that satisfies our requirements of communicating with industrial programmable logic controllers on-premise. We have researched platforms from larger and smaller companies and arrived at the conclusion that only KEPServerEX™ fits into our IIOT strategy as a data broker.
The focus of their communications platform remains on connecting machinery and industrial equipment.
The IoT Gateway enables communication with industrial equipment out of the box using standards such as HTTP and MQTT.
They strive to improve their product by listening to their customers’ needs. This is evident through new feature releases.
KepConnect has four scripting engines:
- feature scripting engine
- action scripting engine
- stream scripting engine
- database seeding script engine
All scripting engines utilize the Managed Extensibility Framework to load script libraries during engine initialization. This approach allows you to add, replace, and remove script libraries on the fly.
/api/featureendpoint from any HTTP client. The inbound payload must be JSON and in the correct format. Based on the requested thing’s identifier value and requested environment, the correct IoT Gateway HTTP server agent URI is retrieved from the service endpoints list. Then, a user script is located by matching the thing’s kind (or category type) and requested unlisted feature name. An instance of the matching script is created and invoked with the received external features and any defined lookups. Any reading and writing of internal features defined in the script occurs against the previously retrieved service endpoint URI.