Global UPC Library

UPC (User Programmable Control) scripts currently come in two forms:

• Local UPC Scripts — attached to a single regulator (Pump Station or Valve), can only target that one object, and are easy to manage in isolation since they live on that object's own property sheet.

• Global UPC Scripts — the only option when control logic needs to reference or act on more than one regulator (e.g. coordinating pumps across separate Pump Stations, or referencing a shared reservoir/node condition across multiple regulators).

In practice, many real networks require several independent pieces of multi-object control logic (e.g. "Pump Station A duty/assist coordination," "Reservoir B fill-sequencing," "Zone C pressure-reducing valve coordination with a remote flow meter"). Since all Global logic must currently live in a single monolithic Global UPC Script, these unrelated pieces of logic end up concatenated together in one script. This creates real modeling and operational problems:

• Difficult to manage: unrelated control logic for different parts of the network is mixed together in one text block, making it hard to navigate.

• Difficult to troubleshoot: a script error or unexpected simulation result requires scanning the entire Global script to isolate which sub-section is responsible, even if only one small piece of logic is misbehaving.

• Difficult to test in isolation: because rules within a Global Script execute in written order and can interact (e.g. rules targeting a Pump Station as a whole vs. rules targeting individual pumps within it), it's hard to safely test or disable one piece of multi-object logic without risking side effects on unrelated logic elsewhere in the same script.

• No granular enable/disable: unlike a Local Script (which has a per-object "Disable UPC" checkbox), there's no way to toggle just one piece of Global logic on or off without editing/removing it from the shared script.

Suggested Enhancement

Introduce a Global UPC Library: a collection of independently authored, named, and stored "Global UPC modules," each of which can target multiple network objects (like today's Global Script), but which are managed, edited, and version-controlled as separate items rather than one shared text block.

Suggested behavior

• Each module in the library has its own name/description, its own script text, and its own enabled/disabled toggle — similar in concept to the existing "Disable UPC" checkbox available for Local Scripts, but scoped per-module rather than per-object.

• At simulation run time, InfoWorks WS Pro would compile all enabled modules into a single effective Global UPC Script internally, in the same way multiple Local Scripts on different objects are already evaluated together today, following the existing rule-evaluation order (rules evaluated top-to-bottom; individual pump actions following a Pump-Station-level action are applied independently).

• Modules could be ordered/prioritized within the library (drag-and-drop, similar to how UPC window items can already be reordered) to give predictable control over which module's rules are evaluated first, for cases where module interactions matter.

• The existing Test / diagnostics functionality on the UPC Script page could be extended to validate a single module independently, or the fully compiled result, so authors can catch errors in one module without re-validating unrelated modules.

• Disabling a module would exclude it from compilation for that simulation run, without deleting or altering its saved script — letting users quickly run "what if this piece of control logic is removed" scenarios.

Benefits

• Keeps each piece of multi-object control logic focused, named, and independently reviewable/testable — mirroring the clarity Local Scripts already provide for single-object logic.

• Reduces risk of accidentally breaking unrelated control logic when editing or troubleshooting one part of a large network's Global control.

• Makes it easier to reuse or copy individual modules between models (e.g. a "reservoir fill sequencing" module used across multiple projects) without extracting it from a much larger combined script.

• Supports faster root-cause isolation during simulation troubleshooting: toggling one module off/on to confirm whether it is the source of an unexpected result.