forked from b.peck/BAT
70 lines
3.5 KiB
Markdown
70 lines
3.5 KiB
Markdown
# Test Data — Simulated Alarm Activity
|
||
|
||
Generates realistic alarm journal data for building/testing the alarm analysis dashboard.
|
||
Everything here uses native Ignition features only (memory tags + tag alarms + Jython).
|
||
|
||
## Files
|
||
|
||
- `simulation_tags.json` — Ignition 8.3 tag export: a `BuildathonSim` folder with 49
|
||
Boolean memory tags across 5 plant areas (`Intake`, `BoilerHouse`, `Packaging`,
|
||
`Utilities`, `TankFarm`). Every tag has one Equality alarm (active when the tag is
|
||
`true`) with priorities spread across Low / High / Critical.
|
||
- `alarm_simulator.py` — Jython script that drives those tags. Full usage instructions
|
||
are in the header comment.
|
||
|
||
## Setup (after the gateway + journal are configured per the main README)
|
||
|
||
### 1. Import the tags
|
||
|
||
Already done if you ran `python3 tools/provision.py provision` (it imports this file
|
||
through the REST API; re-run `python3 tools/provision.py import-tags` after editing it).
|
||
Manual alternative: Designer → Tag Browser → select the `default` tag provider root →
|
||
right-click → **Import Tags** → choose `simulation_tags.json`. Either way you should see
|
||
`BuildathonSim/<Area>/<Tag>` folders appear.
|
||
|
||
### 2. Install the simulator (gateway timer script — recommended)
|
||
|
||
1. Designer → **Project Library** → new script named `alarmsim` → paste the contents of
|
||
`alarm_simulator.py`.
|
||
2. **Project → Gateway Events → Timer** → add a script:
|
||
- Delay: `5000` ms, Fixed Delay, Dedicated thread
|
||
- Body: `alarmsim.tick()`
|
||
3. Save the project. Alarm events start flowing into the journal immediately and keep
|
||
running as long as the gateway is up (no Designer needed).
|
||
|
||
Alternative: paste the whole file into the Designer **Script Console** and call
|
||
`run_console(minutes=30)` — simpler, but it blocks the console and stops when you close it.
|
||
|
||
### 3. Let it run
|
||
|
||
Give it 30-60 minutes for meaningful analytics. Roughly every 30-60 minutes one area gets
|
||
a flood burst; to force one for a demo, call `alarmsim.force_flood()` (e.g. temporarily
|
||
from the timer script, or from the console if using console mode). `alarmsim.reset()`
|
||
clears all sim tags and state.
|
||
|
||
## Patterns generated (what your analytics should detect)
|
||
|
||
| Pattern | Tags | Behavior |
|
||
| ---------- | ------------------- | ----------------------------------------------------------- |
|
||
| Baseline | 40 tags, all areas | Random activations, active 30 s–5 min, ~3-4/min plant-wide |
|
||
| Chattering | `*_Chatter` (3) | Re-trigger every 30–60 s, active 5–15 s each cycle |
|
||
| Standing | `*_Standing` (2) | Active from first tick, never clear |
|
||
| Fleeting | `*_Fleeting` (4) | Active < 10 s (2–8 s), ~1/min |
|
||
| Flood | one random area | 15+ activations within 10 min in a single area |
|
||
|
||
## Querying the journal
|
||
|
||
Events land in MariaDB tables `PrimeControls_alarm_events` / `PrimeControls_alarm_event_data`
|
||
(created automatically on first event). The **plant area is the folder in the alarm's
|
||
source path** — e.g. `prov:default:/tag:BuildathonSim/TankFarm/T101_LevelHigh:/alm:...` —
|
||
so area analytics can group on the path segment after `BuildathonSim/`. Priority is stored
|
||
on the event; `eventtype` 0/1/2 = active/clear/ack.
|
||
|
||
Quick sanity check from your SQL client (localhost:3306, user `ignition`/`ignition`):
|
||
|
||
```sql
|
||
SELECT source, displaypath, priority, eventtype, eventtime
|
||
FROM PrimeControls_alarm_events
|
||
ORDER BY eventtime DESC LIMIT 20;
|
||
```
|