Baseline: docker stack, provisioning tools, test-data, gateway-as-files (pre-PrimeBAT build)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
148
plan.md
Normal file
148
plan.md
Normal file
@@ -0,0 +1,148 @@
|
||||
1. Read the grading before you design
|
||||
|
||||
UI/UX carries the most weight. The winning move is not the most features — it's a dashboard where a plant manager finds the answer to "is my alarm system healthy, and what do I fix first?" in under 10 seconds. Every design decision below serves that.
|
||||
|
||||
The judges grade on their test system with their alarms. So:
|
||||
|
||||
|
||||
Never hardcode source paths, priorities, areas, or display paths. Derive everything from queried data.
|
||||
Handle empty states gracefully (no data in range → clean "no events" message, not a broken chart).
|
||||
Assume a potentially large journal — paginate, limit, and bound every query by date range.
|
||||
|
||||
|
||||
|
||||
2. Core concept: "From triage to root cause"
|
||||
|
||||
One view named Dashboard, structured as a story in three horizontal layers plus tabs:
|
||||
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ HEADER: Alarm Health Score (A–F) │ KPI ribbon │ Date range │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ FILTER BAR: priority ▾ area/path ▾ state ▾ search │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ TABS: Overview │ Analysis │ Bad Actors │ Journal │
|
||||
│ │
|
||||
│ (tab content = embedded sub-views, full remaining height) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
|
||||
Header + filter bar are part of the main view (not docked — that's prohibited). Filters live in session props under the PrimeControls object so every sub-view binds to the same state.
|
||||
|
||||
Signature feature: the Alarm Health Score
|
||||
|
||||
A single composite A–F grade in the header, computed from ISA-18.2 benchmarks: alarm rate vs. target (<6/hr/operator), % time in flood, chattering alarm count, standing alarm count, priority distribution vs. the 80/15/5 rule. Clicking it opens a popup showing the sub-scores and why the grade is what it is. This gives judges an instant "wow, this tells me something" moment and anchors the whole dashboard around ISA-18.2 — which 8.3 now explicitly supports with alarm metrics.
|
||||
|
||||
Second signature feature: the Insights panel
|
||||
|
||||
A small "What changed" card on Overview generating plain-English findings via scripting: "Alarm rate up 34% vs. prior period — 61% driven by 3 sources," "2 alarms are chattering (>10 re-triggers/hr)," "Flood condition 2:10–2:40 AM Tuesday." Cheap to build (it's just threshold logic over data you already computed), huge perceived sophistication, and it's built for the operator.
|
||||
|
||||
|
||||
3. Tab contents
|
||||
|
||||
Overview (the 10-second answer)
|
||||
|
||||
|
||||
Active alarm counts by priority (big number cards, color by priority)
|
||||
Alarm rate timeline (XY chart, 10-min bins, shaded ISA target band, flood periods highlighted)
|
||||
Unacked / shelved / standing counts
|
||||
Insights panel
|
||||
Compact top-5 most-active-sources list → click drills into Bad Actors tab pre-filtered
|
||||
|
||||
|
||||
Analysis (trends & patterns)
|
||||
|
||||
|
||||
Heatmap: alarm count by hour-of-day × day-of-week (flex repeater of colored cells — reveals shift patterns, judges love it)
|
||||
Priority distribution donut vs. ISA 80/15/5 recommendation, side by side
|
||||
MTTA (time to ack) and MTTR (active→clear) trend lines
|
||||
Flood analysis: table of flood episodes (>10 alarms/10 min) with duration and top contributor
|
||||
|
||||
|
||||
Bad Actors (what to fix)
|
||||
|
||||
|
||||
Pareto chart: top 10 sources by event count with cumulative % line ("these 5 alarms are 60% of your problem")
|
||||
Chattering detection: sources re-triggering within short intervals
|
||||
Standing/stale alarms: active longer than 24h
|
||||
Fleeting alarms: active <10s (likely nuisance/deadband issues)
|
||||
Row click → detail popup: that alarm's event history, sparkline of daily counts, avg time-to-ack, top acking operators
|
||||
|
||||
|
||||
Journal (the raw truth)
|
||||
|
||||
|
||||
Paginated, searchable event table with state-transition coloring
|
||||
Per-event detail popup (full event properties, associated data)
|
||||
CSV export button (system.dataset.toCSV + system.perspective.download)
|
||||
|
||||
|
||||
|
||||
4. Standout ideas ranked (build vs. skip)
|
||||
|
||||
Build — high impact per hour:
|
||||
|
||||
|
||||
Health Score A–F with drill-down popup
|
||||
Plain-English Insights panel
|
||||
Hour×day heatmap
|
||||
Pareto with cumulative line
|
||||
Chattering/fleeting/standing detection (simple interval math, very "alarm-management-literate")
|
||||
Consistent design system via style classes: one accent color, priority color scale used identically everywhere, generous whitespace
|
||||
|
||||
|
||||
Build if time allows:
|
||||
7. Native Drawing Editor (new in 8.3) for the Health Score gauge — shows 8.3 fluency with zero rule risk (it's native)
|
||||
8. "Compare to prior period" deltas on every KPI (▲/▼ chips)
|
||||
9. Shift report popup: pre-formatted summary for shift handover
|
||||
|
||||
Skip — poor ROI or risky:
|
||||
|
||||
|
||||
Event Streams / Kafka (gateway config won't travel with the submission; graded on their system)
|
||||
Alarm shelving controls (drifts toward alarm operations; brief says analysis)
|
||||
Live-updating everything (poll on refresh/interval is fine; don't burn hours on subscriptions)
|
||||
Elaborate animations, multi-theme switchers
|
||||
|
||||
|
||||
|
||||
5. Technical architecture
|
||||
|
||||
Data access — prefer system.alarm.queryJournal / queryStatus over SQL. This sidesteps the entire database-agnostic problem: no dialect issues, no table-prefix coupling, works against whatever journal the judges configured. Wrap them in project script functions (PrimeControls.alarms.getJournalEvents(start, end, filters)) that return datasets.
|
||||
|
||||
If you need SQL for heavy aggregation, keep queries dumb (SELECT with time-range params only) and do bucketing/grouping in Jython — that stays agnostic. If you must write dialect-specific SQL, provide all three variants and note it in the submission.
|
||||
|
||||
Computation layer: one script module computes everything (rate bins, floods, chattering, MTTA/MTTR, Pareto, health score) from a single journal fetch per refresh. Store results on view custom props; sub-views receive them via view params. One fetch, many consumers — fast and consistent.
|
||||
|
||||
Structure per the requirements:
|
||||
|
||||
|
||||
All resources under a PrimeControls folder: views, style classes, named queries, scripts
|
||||
Main view: PrimeControls/Dashboard
|
||||
Session custom props inside one object: session.custom.PrimeControls.{dateRange, filters, theme...}
|
||||
Journal table prefix PrimeControls_ if using SQL directly (note it in submission); default DB set on project
|
||||
Sub-views + Embedded View / Flex Repeater / Tab Container — all allowed. No docked views anywhere.
|
||||
|
||||
|
||||
Style classes: define the priority color scale, card style, chip styles once. Bind colors through classes, not inline — judges opening the Designer will notice discipline.
|
||||
|
||||
|
||||
6. 8-hour plan
|
||||
|
||||
HourWork0:00–0:30Fresh install ritual: project, folder structure, session prop object, style classes, priority color scale, page layout skeleton (header/filter/tabs). Configure local test alarms + a chaos script that generates realistic journal data (floods, chatterers, stales) — you can't demo analytics on 10 clean events.0:30–1:30Data layer: script module with journal fetch + all computations (bins, floods, chattering, MTTA/MTTR, health score). Test in script console before touching UI.1:30–2:30Header + KPI ribbon + filter bar, wired to session props. Health Score displayed.2:30–4:00Overview tab complete: rate chart, priority cards, insights panel, top-5 list.4:00–5:00Bad Actors tab: Pareto, chattering/standing/fleeting tables, detail popup.5:00–6:00Analysis tab: heatmap, donut vs. 80/15/5, MTTA/MTTR.6:00–6:45Journal tab: paginated table, event popup, CSV export.6:45–7:30Polish pass: spacing, empty states, loading states, responsive check, consistent number formatting, tooltips. This pass is where UI/UX points are won — protect this time.7:30–8:00Submission hardening: export project, import into a clean gateway, verify nothing references resources outside the PrimeControls folder, write submission notes (DB assumptions, prefix), submit with margin.
|
||||
|
||||
Cut order if behind: Journal export → MTTA/MTTR trends → heatmap → shift report. Never cut the polish pass or the clean-gateway test.
|
||||
|
||||
|
||||
7. Pitfalls checklist
|
||||
|
||||
|
||||
View is named exactly Dashboard, inside company folder
|
||||
Zero docked views (check page config)
|
||||
All session props inside the PrimeControls object
|
||||
No custom fonts/icons/themes/third-party modules — Material icons and built-in themes only
|
||||
Nothing hardcoded to your local tag paths or alarm names
|
||||
Empty date range / no data → graceful, not broken
|
||||
Large journal → queries bounded and paginated
|
||||
Default database set on the project
|
||||
Tested via export → import on a fresh gateway
|
||||
Submission note covers DB choice, prefix, any assumptions
|
||||
Post-event: upload to Ignition Exchange tagged Build-a-Thon 2026
|
||||
Reference in New Issue
Block a user