Clio Liu
f6b32b42a1
The five design documents plus the implementation brief, brought across
as issued. Adds two things the old repo never recorded:
00-origin/ the one-page idea the whole document set was generated from
README.md how the set was produced - idea -> basic design -> detailed
design -> implementation brief - so the team can repeat the
method for their own demos, including what to do differently
CTL-003 gains a dated amendment block. Its section 2 register map was
verified line by line against register-map.csv and is correct; its
sections 1 and 9 specify a MatIEC flat-file build that does not exist on
Runtime v4, and forbid the PLCopen route actually used. Nine corrections
listed, body unchanged.
Not brought across: superseded/WRPS-CTL-002_OpenPLC_Build_Brief.md - dead,
and its number collides with the live FDS.
79 lines
5.2 KiB
Markdown
79 lines
5.2 KiB
Markdown
# SCADA++ AI Assistant — Demo Use Case: Pump Scheduling Decision Support
|
|
|
|
## Purpose
|
|
|
|
This is a curated, cross-industry demonstration of an embedded AI operator assistant running inside a CI Server operator workstation. The assistant sits alongside the operator interface and answers natural-language questions about the live plant — grounded in real-time process data, the historian, and contextual feeds such as energy tariffs and weather.
|
|
|
|
The scenario is designed to be **scalable in depth**: the same setup supports a two-minute "here's what it does" spiel or a full hour-long deep dive, without changing the underlying demo. All back-end components (microservices, containers, historian, contextual data feeds) are stood up as a realistic environment rather than a mock-up.
|
|
|
|
## Why pump scheduling
|
|
|
|
We deliberately avoided the obvious "how fast do I ramp the pump" example, because on any modern VSD the soft-start ramp is solved in the drive configuration — a technical audience will see through it immediately. The genuinely interesting decision isn't *how* to start a pump, it's **which pump, and when**. That's a judgement call the drive can't make for you, and it carries real cost and risk on both sides.
|
|
|
|
It also travels well. A pumping station with downstream storage reads naturally across every target market: gas (APLNG, Santos), water (Melbourne Water, SA Water), power generation, and prospective mining and water customers. One scenario, applicable to anyone in the room.
|
|
|
|
## The setup
|
|
|
|
A pumping station with three units feeding a network with storage downstream. The AI assistant has access to:
|
|
|
|
- Live tank levels and inflow rate
|
|
- Pump run hours and maintenance/service intervals
|
|
- Time-of-use energy tariff
|
|
- Weather feed
|
|
- The historian, for comparison against past operating conditions
|
|
|
|
## Narrative spine
|
|
|
|
It's a wet-weather evening. Inflow is climbing and the site is heading into peak electricity tariff. Three pumps are available, but one is approaching its service interval. The operator turns to the assistant and asks the simple question:
|
|
|
|
> "Do I need to start another pump?"
|
|
|
|
From that single question, the assistant reasons across risk, asset health, and cost — and the operator can stop at whichever layer suits the moment.
|
|
|
|
## The three layers
|
|
|
|
**Layer 1 — Risk and headroom (the two-minute wow).**
|
|
The assistant weighs current inflow against remaining tank headroom and answers plainly: *yes — at the current inflow rate you'll breach tank headroom in roughly 90 minutes, so riding it out isn't an option.* Simple question, clear answer, with the reasoning attached.
|
|
|
|
**Layer 2 — Cost and timing.**
|
|
Given a pump must run, timing becomes a trade-off. *If you start in 25 minutes rather than now, you clip the tariff peak and still stay ahead of the level — saving the associated energy cost without taking on spill risk.* Now the decision has dollars attached.
|
|
|
|
**Layer 3 — Asset health.**
|
|
Which unit to start is not arbitrary. *Start unit three: unit one is near its service interval, and there's no reason to clock hours on it tonight.* The assistant optimises asset life, not just the immediate moment.
|
|
|
|
Stitched together, one question yields a layered answer: *you'll breach headroom in about 90 minutes, so you can't ride it out; start unit three rather than unit one because unit one is due for service; and if you start it in 25 minutes instead of now, you clip the tariff peak and stay ahead of the level.*
|
|
|
|
## Historical grounding
|
|
|
|
This is where the assistant earns trust — and where the historian integration quietly demonstrates itself, which for a CI Server audience is half the point.
|
|
|
|
The operator can push back on any claim:
|
|
|
|
> "Are you sure? What did inflow actually do last time we had rain like this?"
|
|
|
|
And the assistant pulls the comparison:
|
|
|
|
> "Last comparable wet-weather event, three weeks ago, inflow peaked about 20% higher than now and the tank reached 92% before it turned. Your average evening inflow this month is roughly half what you're seeing right now — so this is clearly an event, not normal load."
|
|
|
|
The operator now has context, not just a prediction. He can act on it or overrule it, but he's informed either way.
|
|
|
|
The positioning line for the pitch: **the assistant isn't replacing the operator's judgement — it's giving him five years of plant memory in a single sentence.**
|
|
|
|
## Demo positioning
|
|
|
|
- **Two-minute version:** ask the question, get the Layer 1 answer with reasoning. Done.
|
|
- **Fifteen-minute version:** walk all three layers, show the single-question-to-layered-answer flow.
|
|
- **Hour-long version:** add the historical push-back, expose the back-end components (historian queries, contextual feeds, the microservice architecture), and open into customer-specific "what if" variations.
|
|
|
|
The through-line to land with any audience: the operator can make the call himself with better data in front of him, or lean on the assistant for a fuller autonomous recommendation. It augments judgement — it doesn't remove the operator from the loop.
|
|
|
|
## Target markets
|
|
|
|
| Segment | Reference / prospective customers |
|
|
|---|---|
|
|
| Gas | APLNG, Santos |
|
|
| Water | Melbourne Water, SA Water |
|
|
| Power generation | Existing power-gen customers |
|
|
| New business | Mining, water prospects |
|
|
|
|
One set of use case scenarios, applicable across all of the above.
|