1. ARE THERE ANY SPECIAL SOFTWARE REQUIREMENTS FOR SIL SOLVER®?
2. WHAT VERSIONS OF WINDOWS DOES SIL SOLVER® SUPPORT?
3. ARE THERE ANY SPECIAL HARDWARE REQUIREMENTS FOR SIL SOLVER®?
4. DOES SIL SOLVER® SUPPORT MIRRORED DRIVES?
5. CAN THE USER DESIGNATE WHERE SIL SOLVER® IS INSTALLED?
6. DOES SIL SOLVER® SUPPORT A MULTI-USER INSTALLATION?
7. HOW MUCH DATA IS IN THE DEVICE DATABASE?
8. WHERE DOES THE DATA COME FROM?
9. HOW DOES SIL SOLVER® DO THE CALCULATIONS?
ANSI/ISA 84.00.01-2004 (IEC 61511)
IEC 61508SIL Solver® is capable of analyzing PIF with multiple input and output elements, tested at different intervals, including partial stroke testing of valves, and includes a device failure rate database.
10. WHAT ARE THE REPORT FEATURES?
11. HAS THE DATA BEEN ACCEPTED BY REGULATORY AUTHORITIES?
12. WHAT VOTING ARCHITECTURES ARE AVAILABLE?
SIL Solver is structured to allow rapid modeling of instrumented functions in an easy to use interface. SIL Solver provides 1oo1, 1oo2, 1oo3, 2oo2, 2oo3, and 3oo3 in both diagnostic and non-diagnostic configurations. SIL Solver limits the selected voting architectures to reduce potential systematic error.
Some process requirements specifications will include voting architectures that are 2ooN, where N can be a large number, e.g., 2oo9, 2oo16, and 2oo50. While the IPS logic may be implemented in this manner, these architectures are misleading from a verification standpoint, because they often indicate more fault tolerance than is actually provided by the installation. For example, a 2oo9 architecture requires that 8 devices fail dangerously before a hazardous event occurs; 2oo16 requires 15 failures, and 2oo50 requires 48 failures. It is unlikely that 9, 16 or 50 devices would be installed if all were measuring the same process condition and addressing the same process hazard.
2ooN architectures with large N values typically indicate applications where the unacceptable process condition can occur in multiple distinct locations, e.g., a hot spot on the vessel wall. What appears to be a redundant architecture is actually a simplification of what could be a more complex voting scheme. For example, in the case of a plugged flow reactor, it may be that 2oo3 voting sensors are used in each of three reactor zones, leading to an overall 2oo9 voting scheme. The verification of the risk reduction should be based on the voting architecture that detects the hazardous event. In the case of 2ooN architectures, the voting architecture is usually 2oo2 or 2oo3 at best.
13. WHAT PERCENTAGE OF FUNCTIONS CAN BE MODELED?
14. WHAT LIMITS THE TEST INTERVAL SELECTION?
SIL Solver provides pre-built test intervals for user selection. The test intervals are daily, weekly, monthly, 3 months, 6 months, 12 months, 18 months, 2 years, 3 years, 4 years, 5 years, 6 years, and 7 years. The default data is limited to 7 years, because there is insufficient evidence that the assumed failure rates are valid when the equipment undergoes such infrequent proof testing. Of course, the user can build custom datasheets and enter any test interval desired, whether a whole number or fraction.
The user should choose the test interval, which provides the most cost effective maintenance scheduling meeting the PFDAVG and has been proven through experience to be sufficient to maintain the equipment in the “as good as new” condition. In general, the test interval is constrained by production schedules which provide off-line access to equipment. Opportunities for inspection, preventive maintenance, and proof testing should be identified by process engineering and operations personnel in the process requirements specification.