PI Nexus+ / Reference
Scan Automation Reference
This reference lists the cadences, windows, queue rules and timings of automatic monitoring. The Administration Guide chapter Scan Automation links here instead of repeating them.
Overview
This reference lists the cadences, windows, queue rules and timings of automatic monitoring. The Administration Guide chapter Scan Automation links here instead of repeating them.
Policy settings
| Setting | Options | Default |
|---|---|---|
| Scan intensity | Low - as little load as possible, Medium - recommended, High - freshest health, more load | Medium |
| Heavy work starts / Heavy work ends | Any time, scanner server local time | 22:00 to 06:00 |
| Automatic per target | On or off | On for every enabled target when automatic monitoring is first started |
| Cadence mode | Automatic (derived) or Custom cadences (set under Advanced) | Automatic |
A changed intensity, window or target selection takes effect on the next dispatcher pass, within 5 minutes.
Cadences per intensity
Each periodic cadence is derived per target: the duration of that target's last successful run, divided by the share of time the intensity allows, kept between the shortest and longest interval. A target that has not completed the relevant run yet uses the shortest interval.
| Low | Medium | High | |
|---|---|---|---|
| Health refresh, shortest interval | 8 hours | 3 hours | 1 hour |
| Health refresh, share of time | 1 % | 3 % | 10 % |
| Health refresh, longest interval | 7 days | 7 days | 7 days |
| Full verification, shortest interval | 90 days | 30 days | 7 days |
| Full verification, share of time | 1 % | 3 % | 5 % |
| Full verification, longest interval | 365 days | 365 days | 365 days |
| Interface and adapter runtime poll | Every 5 minutes | Every minute | Every minute |
Examples at Medium:
| Target | Last measured run | Resulting cadence |
|---|---|---|
| PI Data Archive | Health refresh 4 minutes | Health every 3 hours (shortest interval) |
| PI Data Archive | Health refresh 1 hour | Health every 33 hours |
| AF database | Full scan 20 minutes | Verification every 30 days (shortest interval) |
| AF database | Full scan 3 days 4 hours | Verification every 106 days |
Only a health refresh that succeeded, or completed with errors and was credited (see Scan Runs Reference), counts as a measurement. Only a successful full scan measures the verification cadence.
A target without a change feed is fully scanned at its verification cadence. PI Vision instances get no health refresh: their health follows the health of the attributes and points they use (Follows attribute health).
Custom cadences (Advanced)
| Value | Options | Value restored by Use automatic cadences |
|---|---|---|
| Operational health | Every 15 or 30 minutes, Hourly, every 2 or 4 hours | Hourly |
| Inventory freshness | Daily, every 3 days, Weekly, every 2 weeks | Weekly |
| Full verification | Weekly, Monthly, Quarterly, Yearly, Only on demand | Monthly |
| Interface and adapter runtime poll | Every 1, 2, 5, 10 or 15 minutes | Every minute |
With custom cadences, the Scanning page warns when a target's last credited health refresh took 80 % or more of the Operational health cadence. The setting is not changed: the next refresh is planned after the previous one ends, so the real period becomes the cadence plus the refresh time. With Only on demand, the page states Inventory is feed-driven; no periodic full verification is scheduled.
Note: On upgrade from 1.5.x, an installation still on the four shipped values (hourly, weekly, monthly, every minute) moves to automatic cadences at Medium. One with any value changed keeps its values as Custom cadences.
What waits for the heavy-work window
| Work | Waits for the window |
|---|---|
| Full verification and routine automatic full inventory scans | Yes |
| PI Point rule reconciliation queued by automatic monitoring | Yes |
| First full scan of a target (baseline), after starting automatic monitoring, enabling a target or ticking Automatic | No |
| Health refresh | No |
| Inventory update from a change feed | No |
| Interface and adapter runtime poll | No (not queued with scans) |
| Anything requested by a person, work promoted with Run now, and legacy schedules | No |
The window compares wall-clock time: on a daylight-saving change a skipped hour is skipped and a repeated hour counts twice. A start equal to the end means "any hour". The window controls only when work starts.
Dispatcher and concurrency
| Item | Value |
|---|---|
| Dispatcher pass | Every 5 minutes |
| Items started per pass | Up to 4, of which at most 1 full scan |
| Full scans running at the same time | 1 |
| Health refreshes and inventory updates | Can run beside a full scan |
| Automatic full scan giving way to due health work | Up to 24 hours (a baseline: up to 1 hour) |
| Requested (manual) runs waiting in the queue | At most 100; an AF request counts one per AF database |
Change feeds
| Item | Value |
|---|---|
| Sources with a change feed | AF databases, PI Data Archives, PI Vision instances |
| Feed established by | A successful full scan of the target |
| Poll interval | Every 5 minutes |
| Wait before an inventory update | 30 minutes after the last reported change, at most 2 hours after the first |
| Failed polls before a full scan is queued | More than 12 (about one hour) |
| Proof of deleted PI Points (PointID comparison) | At least every 6 hours |
| Inventory column | Meaning | Action |
|---|---|---|
| Change feed healthy | The source answers and changes are applied | None |
| Change feed delayed | Polling works but runs behind | None |
| Change feed degraded | Polling fails | Check the connection; a full scan is queued if failures continue |
| Change feed needs a full scan | The source rejected the starting point (too old, or the source was replaced or restored) | None; PI Nexus+ queues the full scan and lists the target under Needs attention until it succeeds |
| Change feed not available on this AF Server (or PI Data Archive, PI Vision instance) | The source cannot report changes | None; the target keeps full scans and is not unhealthy |
| Changes detected — inventory update planned after activity settles, in about N minutes | Changes are waiting for the quiet period | None |
| Changes detected — inventory update planned as soon as the queue allows | The quiet period is over | None |
| Last inventory update | When the last change-driven update ran |
When a feed is in use, the target's full-scan time is shown as Last full verification.
Queue rules
| Rule | Behaviour |
|---|---|
| Duplicate request | Not queued again; the existing item is reported (Already queued). For AF, checked per database |
| Request over the 100-run limit | Refused as a whole; the message names the runs requested and already queued |
| A person requests work for a target | Queued automatic work for the same target is superseded |
| A scan completes | Queued work it made unnecessary is superseded, for example a health refresh after a successful inventory scan |
| A full PI Point scan of every PI Data Archive | Retires the queued PI Point rule reconciliation |
| A target is disabled or no longer managed | Its queued work is superseded; its inventory is marked excluded |
| Run now | Moves the item to the next start slot, past the window and any retry wait; does not interrupt a running scan. The trigger becomes Run now. A failed promoted item is not retried; automatic monitoring creates it again |
Superseded items are not failures; they keep the reason they were retired.
Retries of automatic work
| Item | Value |
|---|---|
| Failures that are retried | Temporary or unknown infrastructure failures |
| Retries | Up to 3, after 5 minutes, 15 minutes and 1 hour |
| Failures that are not retried | Configuration, validation, authorization and unsupported-scope failures |
| After the last retry | The item needs attention: it appears under Needs attention and sends an Automatic monitoring failures email if switched on |
| Wait before a target that keeps failing is tried again | Doubles from 5 minutes, at most 6 hours |
Pause
| Item | Behaviour |
|---|---|
| What stops | New automatic work: health refreshes, inventory updates, verification, reconciliation |
| What continues | Running scans; manual work; the interface and adapter runtime poll |
| What is kept | Inventory, issues, suppressions, history and the queue |
| Where it is shown | Scan Automation banner (Paused since … by …), Scanning page Status (Paused, with a Resume button), a Dashboard notice, the Automatic monitoring check in Readiness |
Who can do what
| Action | Role |
|---|---|
| View the Scanning page, request manual scans and health checks, Run now, cancel, remove requested work | Operator |
| Everything under Admin > Scan Automation, including start, pause and resume | Admin |
| Recover a stuck scan, permanently delete scan history | Admin |
