As a user, I verify json updates have been processed in a testing environment before those json updates are applied to production. I review the NMS Topology Validation for errors along with verifying that Power Flow is solving before allowing the json update to be applied to production. If it fails my verification, I work with various teams to correct data and when a new json is available, I will re-verify. There are scenarios where there may be no TopVal errors and Power Flow is solving, and I will approve a json update to be applied to production.
In the production environments, there may be “abnormal” devices and other items that prevent a json update from processing. Likewise, there are scenarios where the model build will process a json update that in conjunction with abnormal areas of the network model and consequently remove portions of the network model. Understandably, this may be the desired effect for some utilities but there is no verification that in this specific scenario that alerts a user of this possibility. Therefore, the system should recognize this behavior and do the following:
- The NMS must alert the user of the scenario BEFORE it occurs.
- The NMS must provide a report that describes device counts and device names that would be removed BEFORE the json is processed.
- If the user does not agree with permitting the json to be applied, the user should have the option to stop it from processing.
- The report should be exportable and incorporate feeder filtering for ease of use.
- Where json updates have not been approved to process by a user due to creating the aforementioned scenario, the report should identify that a json is still pending.
The overall process is to ensure with json data being imported to NMS and later processed in production environments, that a user is aware of the device count comparison across environments as a result of jsons being processed. This helps ensure that areas of the network model are not accidentally removed by a user without having an opportunity to review a report. By having a report available, the user can provide the data to source model systems to correct discrepancies.
This scenario has a workaround by allowing multiple jsons to process to ensure areas of the model do not get removed due to load shifting but solely relies on a user to visually verify. This increases a risk of something being missed without a comprehensive report along with system warnings.
