ECR Title: Update SEI watchdogs for better handling of saturation history	DCC No: E1500325-v1
Date: July 29, 2015
Requester: Brian Lantz	Impacted Subsystem(s): SEI
Description of Proposed Change(s): 1) Add a "clear saturations" button which is separate from the "reset Watchdog" button. The "Reset Watchdog" button will be unchanged, and the new "clear saturation" button will just clear the saturations. 2) The watchdog is setup so that if the total saturations in the history are greater than the allowed number of saturations then the watchdog will trip. Currently, the history is kept until the watch trips or the history is reset.We propose changing the saturation history buffering so that saturations more than 1 hour old (defined in the simulink model) are automatically cleared. The history will be stored in 60 bins, each 1 minute long. Bins more that 1 hour old are cleared. Please see T1500406 for implementation documentation. Changes to HEPI master model, BSC-ISI master model, HAM-ISI master model, various MEDM Watchdog screens.
Reason for Change(s): Change #1 is so that we can separate the “reset watchdog” from the “clear old saturations” function. Change #2 is so we only trip on recent troubles, not a slow accumulation of old trouble. JimW at LHO states that the operators now reset the history manually every day so that we don’t get accidental trips.
Estimated Cost: $0
Schedule Impact Estimate: slight. Master models tested at Stanford. Implemented at sites on model rebuild.
Nature of Change (check all that apply): Safety Correct Hardware Correct Documentation	Improve Hardware Improve Software Improve/Clarify Documentation Change Interface Change Requirement
Importance: Desirable for ease of use, maintenance, safety Desirable for improved performance, reliability Essential for performance, reliability Essential for function Essential for safety	Urgency: No urgency Desirable by date/event: _ before O1 software freeze_ Essential by date/event: ____________ Immediately (ASAP)
Impacted Hardware (select all that apply): Repair/Modify. List part & SNs: ______________________ Scrap & Replace. List part & SNs:_____________________ Installed units? List IFO, part & SNs: _________________ Future units to be built	Impacted Documentation (list all dwgs, design reports, test reports, specifications, etc.): Issuing T1500406 to describe changes Impacted Software (list all that apply): HAM-ISI, BSC-ISI, HEPI master models
Disposition of the proposed change(s): The disposition of this proposed engineering change request is to be completed by Systems Engineering and indicated in the “Notes and Changes” metadata field in the DCC entry for this ECR. The typical dispositions are as follows: Additional Information Required: in which case the additional information requested is defined. The ECR requester then re-submits the ECR with the new information using the same DCC number for the ECR but with the next version number. Rejected: in which case the reason(s) for the rejection are to be given Approved Approved with Caveat(s): in which case the caveat(s) are listed TRB: the ECR is referred to an ad-hoc Technical Review Board for further evaluation and recommendation. It is the System Engineer’s (or designee’s) responsibility to organize the TRB. The System Engineer (or designee) then makes a technical decision based on the TRB’s recommendation. Links to the TRB’s documentation (charge, memos, final report, etc.) are to be added to the “Related Documents” field for this ECR. CCB: a change request for approval of additional funds or schedule impact is to be submitted to the Configuration Control Board. Links to the CCB’s documentation (CR, etc.) are to be added to the “Related Documents” field for this ECR. Concurrence by Project Management: Acknowledgement/acceptance/approval of the disposition is to be indicated by the electronic “signature” feature in the DCC entry for this ECR, by one the following personnel: Systems Scientist Systems Engineer Deputy Systems Engineer