Signed in as:
filler@godaddy.com
Event Engine: The Middleware That Keeps Up With Your Plant
Purpose-built integration between your PLCs and enterprise systems — without the overhead.
The Problem
Manufacturing data integration projects fail the same way every time. Engineers spend weeks configuring individual tags. Systems fall behind under data volume. When something breaks, nobody can tell where it broke or why. And when the process changes, updating the middleware becomes a project of its own. Event Engine was built to fix that.
How it works
Four steps to your first event.
1. Point Event Engine at your PLC and import its structure definitions — UDTs, data blocks, PLC data types.
2. Bind the tags you need. Browse the PLC or enter names directly.
3. Map the event to your database procedure or table.
4. Trigger it and watch the result land.
No desktop client. No VPN session. No PLC download.
And don’t stop there. Configuration changes are made live, without affecting events already running.
See for yourself.
Requires Windows, SQL Server/Oracle, and a PLC or OPC server.
Fully functional · 30 days · no credit card · no sales call
Why transactions fail, and why yours don't have to.
Most middleware treats database connections as disposable — opened, used, dropped, re-authenticated. Under normal load nobody notices. When the line surges and twenty events fire at once, reconnection cost stacks up and the PLC's timeout window closes first. The event faults. The part gets scrapped. Nobody can tell you why.
Event Engine keeps warm connections ready, so a burst is handled at the speed of the database, not the speed of a login.
Reliability: No hidden queue
Store-and-forward exists to solve two different problems: load spikes that outrun the system, and outages that take it away entirely. The spikes are by far the common case — and as above, Event Engine solves those at the source rather than queueing through them. Buffering manages the symptom; warm connections and modern algorithms remove the cause.
That leaves the true outage. Start with what buffering actually is: a historian pattern. A historian collects values for later analysis — nobody is waiting on them, so backfilling an hour of data an hour late costs nothing. A transactional record is different. A quality result, a genealogy record, a serial number assignment participates in the process; something downstream is waiting to act on it. Buffering treats the second like the first.
So production keeps running, and a queued record is a promise, not a record. Ask the database whether a part passed the last operation and the answer comes back honestly: no record. Downstream logic reads that as not processed. The operator reads it as not built. The truth about that part lives somewhere else — in a queue, on another machine, under a clock nobody reconciles. For the length of the outage, you are building product against assumptions you cannot verify, from two systems of record, consulting the wrong one.
Vendors will tell you they log when the outage started and ended, so at least you know the window. A window is not a containment. It doesn't tell you which parts were built inside it, which were cleared against records that weren't there, or where those parts are now. Someone still walks it back by hand, under pressure, which is the work traceability was bought to eliminate.
And the premise has moved. Store-and-forward was designed when middleware ran on an industrial PC in a control cabinet at the end of a fragile plant network. Your database now runs on a managed server in a data center, with failover and an uptime target in writing. If it genuinely isn't reliable, that is the thing to fix — buffering only makes the unreliability harder to see.
Event Engine works in real time. Every event is acknowledged back to the controller — completed or failed, with a status code and a timestamp. If the database can't be reached, the PLC knows immediately, and your logic decides what happens next: retry, alarm, hold the line, or divert the part. The machine is never running on the assumption that a record landed when it didn't.
Define the structure once. Use it everywhere.
Traditional middleware makes you define and manage individual tags by hand — labor that multiplies with every controller and every change. Event Engine imports the structure definitions taken straight from the PLC, so configuration effort scales with the number of structures, not the number of tag members. A 100-element array of a 10-member structure is one definition, not a thousand.
When a structure changes on the PLC side, re-import it once to cover all instances — no tag-by-tag audit.
When it fails at 2 a.m., find out why at 2:01.
When middleware misbehaves, most platforms leave you guessing. Event Engine records what was attempted, what the controller returned, what the database returned, and where the sequence stopped — per event, with status, timing, and search capabilities. No black box, no reproducing the fault to study it.
Configuration and monitoring shouldn't need a desktop install.
All the diagnostics in the world don’t matter if they can’t be seen. Event Engine's interface runs in any browser on the plant network — configuration, monitoring, and diagnostics, with user access control over who can see what and who can change it. No fat client to install on every engineering workstation. No VPN session to check on a transaction.
Works with what you already run.
- Controllers: Direct Drivers for Rockwell Logix/Siemens S7/Modbus TCPIP, any PLC reachable over OPC
- Databases: Microsoft SQL Server, Oracle
- Platform: Windows — on-premises or in the cloud. No vendor cloud service required.
Proof: An hour of lost production a day recovered
An automotive components manufacturer averaged 5 events per second — but the process swung between 0 and 35 concurrent events. The peaks were enough to fault transactions with no assignable cause: dropped records, scrapped parts, missed cycles, and an hour of lost production every day. Months of troubleshooting found nothing.
Switching to Event Engine eliminated the issue by handling the bursts which previously paralyzed their system. It allowed them to consolidate multiple middleware instances onto a single Event Engine instance, which still used a fraction of the system resources required by any single instance of the former platform.
Put a stopwatch on it.
Every middleware vendor says they're fast. Fast to build, fast when running. Download the 30-day trial and measure it against what you're running now.
Requires Windows, SQL Server/Oracle, and a PLC or OPC server.
Fully functional · 30 days · no credit card · no sales call
