[Nancy Leveson wrote]
 
> One other thing I forgot. There is no such concept in System Safety as the
> safety level of a system component in isolation from the specific system design
> in which it will be used. A valve may be safety-critical or not depending on
> How it is used in the system, for example, depending on the role it plays in the nuclear
> power plant design. Because in systems theory safety is an emergent system
> property (and not a component property), the safety level or safety of a component
> does not "travel with" the component. If that component is used in a different system,
> it's criticality and safety is totally different and must be evaluated in
> that particular system.
 
Dear Nancy, 
 
A valve sitting on a shelf is simply a component, it is neither safety critical or not, this is obvious. I don't think that we need to read a paper to understand that.
 
SIL is a *requirement* that is imposed on a component because of its contribution to one or more hazards of certain severity in a given application. This is the intention of 61508 I believe, at least this is what it should be. 
 
I am not an author or active practitioner of 61508, so on your question about generic certification, I can only say that people perhaps use SILs for generic certification of software like RTOS exploiting the ambiguities regarding what SIL means for software.
 
Having said that, I would not dismiss the idea of an Integrity Level which is independent of application, even if this contradicted *systems' theory*; not without further thought and valid reasons. Why? 
 
The valve sitting on the self may *not be safety critical* but it was perhaps designed for *high integrity* and is just waiting there to be used in the cooling system of a nuclear power plant, while other valves may be just waiting to be fitted in showers :). 
 
Similarly, a stereo amplifier has been designed for *high fidelity*. How it is used in practice, for nursery rhymes, Bach or both is a different story.
 
Here is an idea on this topic:
 
It may be possible to assign a de-contextualised Integrity Level (IL not SIL) to the valve while sitting on the shelf.
 
A valve has certain failure characteristics. It has a number of failure modes (stuck closed, stuck open etc) and each of those will have a probability of failure (lets say per unit time if we average over lifetime). These probabilities of failure could define the IL of the valve. Perhpas each failure mode of the valve should have its own IL to get a more refined view of the component, when we *consider its use* in a potential application.   
 
The IL can determine whether the valve *can* be used in an application where *a* valve is required.  If we know that the *required* valve must fail with probability Pv to satisfy the probability P of the hazards it causes then we can determine that we need a valve of SIL X that corresponds to Pv. In other words, we know the requirement.
 
We can then check whether a given valve of IL Y sitting on a shelf meets the requirement for SIL X. I guess it must be Y>=X
 
This comes with a warning: the de-contextualised IL level of the valve might need to be adjusted before it can become a SIL to reflect a different environment (an environment with different characteristics might change failure rates, even introduce previously unanticipated failure modes). 
 
One could see the relationship between de-contextualised IL and application SIL as one of inheritance.
 
De-contextualised IL reflects failure characteristics due to design/manufacturing quality of the valve as exhibited within a pre-specified anticipated environment. Application SIL inherits these characteristics, but it can extend/override aspects of IL to reflect the effect of a given environment.
 
Best regards
 
Yiannis
 
ps: Aristotle has written a lot on the relationship between *potential* and *actual* 
--
Dr Yiannis Papadopoulos 
Senior Lecturer
Department of Computer Science
University of Hull
Cottingham Rd
HU67RX, HULL, UK
tel: +44 1482 465981
e-mail: y.i.papadopoulos@xxxxxx
http://www2.dcs.hull.ac.uk/people/cssyp