01 · Challenge
The challenge was visibility across layers.
Equipment data is often trapped at the device level: inside a control panel, on a local screen or in a logbook. The people responsible for that equipment need a short, reliable view of its condition and a clear way of handling exceptions, without reading every measurement.
The demonstration set out to show one way of closing that gap, using every layer from the sensor 1 to the alert 6.
02 · Context
An internal build, not a client project.
This is an internal demonstration. It was built and run by HekimaCore on test equipment. There is no client, no site and no operational data to report, and none is implied.
03 · Scope
Every layer, at demonstration scale.
- Field signals from a motor-driven unit: pressure and vibration 1
- A control panel with PLC inputs, local alarms and interlocks 2
- An embedded gateway reading the PLC 3
- An API with a normalised event model and rules 4
- A responsive web dashboard 5 and alert notifications 6
Not included: production hosting or integration with a maintenance system.
04 · HekimaCore role
Designed, built and tested in-house.
HekimaCore designed and built each layer: sensor selection and wiring, panel and control logic, the gateway, the API and rules, and the dashboard and alerts. The interfaces between them were written down before any part was built.
05 · Practice
Integrated Solutions: both practices, one thread.
Engineering Solutions led the physical layers 123. Software & Digital Solutions led the hosted layers 456. The boundary between the gateway and the API was defined jointly, including signal names, units and what happens when data stops arriving.
How integrated projects are organised06 · Solution
One signal path, followed from end to end.
The demonstration maps field signals into a normalised event model, applies rules and presents status and alerts suited to each role.
- 1
Sense. A pressure transmitter on the discharge line and a vibration sensor on the motor produce standard analogue signals.
- 2
Control. The PLC scales the signals into engineering units and keeps alarms and interlocks local, so safety never depends on the network.
- 3
Connect. The gateway reads values from the PLC, adds a timestamp and sends them over an encrypted connection.
- 4
Normalise. The API turns each reading into an event with an asset, a tag, a value and a unit, stores it and checks it against rules.
- 5
Show. The dashboard groups status by asset and highlights only what needs attention.
- 6
Act. When a rule is broken, an alert goes to the responsible user, who can acknowledge it.
07 · Technologies
Embedded, cloud and web.
- Field
- Analogue and digital I/O
- Control
- PLC with local HMI
- Gateway
- Embedded gateway
- Transport
- Encrypted publish over TLS
- Back end
- API, event store and rules
- Front end
- Responsive web dashboard and alerts
08 · Outcome
What the demonstration showed.
Field signals moved through every layer to status views and alerts suited to each role, on test equipment. It shows the architecture working end to end at bench scale.
Results are limited to what was demonstrated. No performance, availability or cost figures are claimed, and none should be inferred for a production installation.
09 · Evidence
What can be reviewed.
- System architecture drawing On this page
- Technical walkthrough with the engineering and software leads On request
10 · Lessons
Two decisions to make early.
- Define interfaces and failure states before building, not after the first integration test.
- Design the dashboard around decisions rather than every available measurement.