Does NeoShift touch our control loops?
NeoShift is designed not to. It writes supervisory setpoints, the targets your controllers already accept, and is designed not to modulate actuators or close loops. A representative action is asking a cold store to hold −18 °C rather than −20 °C for a defined window; your controller keeps regulating with its own tuning, interlocks and protection.
NeoShift is designed to write episodically, not continuously. A setpoint is written as a target held for an interval, typically minutes aligned to the demand period, and is not rewritten within that interval to steer the process. That is designed to keep NeoShift out of the real-time loop and leave your plant's safety case unchanged.
NeoShift is designed to adapt its transitions to each controller. Controllers that track successive setpoints receive a ramp; controllers that reset their integral term on every write receive a single change; where neither is safe, the step size is bounded. This is intended to prevent the rebound peak that a stepped release can cause.
What stops a bad command?
NeoShift's guardrail sits between every command and your plant. It contains no model, no model can change it, and it is designed to reject anything outside a fixed, operator-reviewed constraint set. When it rejects an action it reports the binding limit and when that limit clears, so the action is not retried in a loop.
| Check | Purpose |
|---|---|
| Minimum run and off times | Designed to prevent short-cycling |
| Maximum setpoint rate of change | Designed to prevent thermal and mechanical shock |
| Thermal duty and start frequency | Designed to stay inside the manufacturer's envelope |
| Recovery interval and recovery draw | Designed not to take an action whose recovery would create a bigger peak |
| Inrush and start separation | Designed to keep restarts from stacking into a new peak or tripping protection |
| Cross-asset coupling | Shared header pressure, chilled-water loops and minimum online capacity are constrained as a group |
| Phase balance | Designed to keep single-phase shedding from pushing imbalance past your protection settings |
| Transformer thermal duty | Designed so that flattening a profile does not lengthen time near thermal limits |
| Economic plausibility | A plan that would raise demand at a peak, or command unrelated assets to full output, is designed to be rejected even if every machine would be within limits |
| Your process limits | Permitted bands, excluded equipment, no-action windows, production states |
What happens when an operator changes a setpoint?
NeoShift is designed to release that asset immediately and not reassert its value. Control is designed to resume only when the operator returns the asset to automatic or explicitly re-enables it, not on a timer. Every override is logged, and repeated overrides on one asset trigger a review of its limits with your team.
NeoShift detects overrides by reading back what it wrote, using change-of-value subscriptions on BACnet and OPC UA, and a polling budget sized to spare capacity on serial networks, so detection is designed not to crowd out your own control traffic.
What about planned maintenance?
A declared maintenance state is designed as an absolute exclusion: zero commands to that equipment, of any kind, until your team clears it. It is designed not to expire on a timer or be cleared by a restart, a reconnection or a new strategy. Your lockout and tagout procedure remains the safeguard; NeoShift's job is to be reliably absent.
What if a controller's configuration changes underneath NeoShift?
NeoShift records a signature for every point it writes: device identifiers, expected value range and units, and normal behaviour. Before each write it is designed to check the signature again; if anything no longer matches, the write is withheld and the asset stays suspended until your team re-validates it.
What if the internet connection drops?
NeoCore is designed to continue on the last valid strategy while that strategy is within its validity window, narrow its scope when the strategy expires, and hand control back to your plant after that. A strategy built on a stale forecast is designed not to be applied to live equipment.
| Stage | Condition | Designed behaviour |
|---|---|---|
| Normal | Strategy current, connection available | Full coordination with local adaptation |
| Autonomous | Connection lost, strategy still valid, utility supply present | Continues on the last valid strategy |
| Conservative | Strategy validity expired | Reduced scope within tighter limits |
| Handback | Extended expiry, guardrail fault, or loss of utility supply | Coordination suspended; plant on native control |
What if the site switches to generator power?
NeoShift is designed to stop coordinating immediately when utility supply is lost or the site transfers to standby generation. Transfer is read from a hardwired contact on the transfer switch, not inferred from voltage and frequency, and an unreadable contact is treated as a transfer. A site with standby generation and no transfer signal is not coordinated.
NeoShift is not anti-islanding protection.
Islanding protection belongs to your certified inverters and protective relays, which act in milliseconds. NeoShift only observes that they acted and stands down.
What if NeoCore fails?
NeoCore is not wired in series with any control path, and every setpoint it writes is time-bounded. On failure, equipment is designed to revert through three levels: the equipment's own parameter expiry where it has one, a revert performed by NeoCore, or a watchdog at each remote node that reverts locally if it loses contact.
NeoShift states the limiting case plainly. If NeoCore loses power on equipment with no native expiry, a written value could persist. NeoShift is therefore designed to write only values that equipment can hold indefinitely, allows only energy-reducing writes there, or requires a hardwired interlock that returns the asset to local control. If none of these is possible, the asset is excluded.
Design principle
NeoShift is designed so that, if NeoCore stops, written setpoints expire and equipment returns to its own control.
Is NeoCore a way into our network?
In development Planned security design
NeoCore is being designed to initiate every connection itself, listen on no port, need no inbound firewall rule, and offer no remote shell, local web interface or vendor remote-access path; updates are planned to be polled, signed, verified on the device and staged across the fleet, with signing keys held offline. During the assessment NeoCore only reads data, and its network access is agreed with your IT team.
NeoShift is designed not to bridge your security zones. Where your network is segmented under IEC 62443 or the Purdue model, separate nodes sit in each zone, linked out of band, and switch-port access control on NeoCore's port is verified before automation starts.
What does NeoShift record?
NeoShift is designed to log every write with the value, time, strategy, inputs and the constraint check that allowed it. Records are designed to be integrity-protected, kept at the edge and in the platform, and ordered by sequence numbers and causal links rather than clocks alone, so you can ask why a command happened and see the recorded reasons.
NeoShift's records are not a tool for supervising staff. Records of individual operator actions are kept on a short schedule for technical review and settlement only.
What is NeoShift designed never to do?
- Enter a regulatory control loop or modify firmware
- Compete with an operator
- Act as a protection function
- Offer process load into sub-second frequency markets
- Reverse-engineer an undocumented register map to write to live plant
- Attach as a second master on a single-master serial bus