1. Are there any special software requirements for SIL Solver® Enterprise?
SIL Solver® Enterprise must be loaded on a server (physical or virtual) running Microsoft SQL Server software, version 2016.
2. What browsers do SIL Solver support?
3. Are there any special hardware requirements for SIL Solver?
4. Can SIL Solver be installed on multiple servers?
5. How much data is in the device database?
6. Where does the database come from?
7. How does SIL Solver® Enterprise do the calculations?
8. What are the new calculation features in Enterprise?
9. What are the report features?
Reports are generated from SIL Solver® Enterprise as PDFs. There are currently seven reports related to the safety functions: 1) documentation, 2) project datasheets, 3) protective function details, 4) protective function data summary, 5) protective function target results, 6) protective function results summary, and 7) protective function diagram.
Four additional reports provide system wide information on the data ID list and the revision histories of the device data sheet, logic solver data sheet, and support system data sheet collections.
10. Has the data been accepted by regulatory authorities?
11. What voting architectures are available?
SIL Solver® Enterprise is structured to allow rapid modeling of instrumented functions in an easy to use interface. There are three levels of gates available in the input architecture. At the input device level and the input subsystem level, SIL Solver® Enterprise provides 1oo1, 1oo2, 1oo3, 2oo2, 2oo3, and 3oo3 voting architectures. Complex subsystem architectures from one to three channels exist to allow transparent modelling of multi-device installations, such as a pressure-temperature-compensated flow measurement. Up to five input subsystems can be combined at the final gate in either a 1ooN or NooN architecture.
The use of diagnostics for sensors or partial stroke testing for valves is configurable for each device in the architecture.
SIL Solver® Enterprise limits the selected voting architectures to those most realistically achievable in process sector installations to reduce potential systematic error. 2ooN architectures with large N values in the PLC application program 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 an architecture with ample redundancy is most often 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 in the PLC. In each case, however, only three sensors at any given time are in position to see the developing hazard in time for safe action to be taken. The verification of the risk reduction should be based on the voting architecture that detects the hazardous event. Due to the limitations of installation instruments into process equipment, the voting architecture for the SIL Verification is usually 2oo2 or 2oo3 at best.
12. What percentage of functions can be modeled?
Beginning users can model more than 90% of the safety functions associated with refining and petrochemical applications. Power users can increase this percentage significantly by breaking the function down into subsystems for modeling. Other methods can also be used to independently model very complex portions of a function, with the resulting performance values entered into custom datasheets for inclusion in SIL Solver projects.
13. What limits the test interval selection?
14. ISA-61511 requires us to have a 70% upper bound confidence limit for the data used in the SIL verification analysis. How is that addressed in SIL Solver®?
Data in the SIL Solver® database are the result of a Delphi process that uses expert judgement to select appropriate failure rate values for typical process operating environments. Among the many sources of information used by the team of experts, preferential weight is given to data captured from actual installations. Our sources include a variety of the more challenging automation environments in the process sector. With this approach, the resulting failure rates are expected to have at least a 70% upper bound confidence limit for our process sector clients.
Ultimately, positive confirmation of the appropriateness of the data regarding your specific application comes from the periodic operations and maintenance performance assessment that is also required by the standard. Using a SIL verification reliability database that is designed to provide a more realistic estimate of actual field performance should reduce the likelihood of design rework resulting from this assessment.