Time to Read 2 min
UL 1998 deals with software for programmable components that perform safety-relevant functions, the failure of which can lead to fire, electric shock or personal injury. The scope is close to Annex H of UL/ EN 60730-1 (Functional Safety of Electronic Controls, Section H.11.12 Software).
Certain product safety standards, such as UL/ EN 62109-1 (Safety of Power Converters for Use in Photovoltaic Power Systems) require compliance with a safety level (SIL: Safety and Integrity Level), but leave it up to the user to prove this in accordance with UL 1998 or Annex H of UL/ EN 60730-1. Products for the US market are therefore spoiled for choice between these two standards.
UL/ EN 60730-1 has the advantage of homologation between the EU and US markets, but is quite difficult to read and appears unwieldy and lacking focus. UL 1998, on the other hand, is slim (around 20 pages without appendix) and appears tidy. At first glance, it seems easier to comply with this standard. But does this impression stand up to closer scrutiny?
If you compare the two standards in detail, you will find that the requirements are largely similar. This is most noticeable in the tables UL 1998 Table A2.1 and UL/ EN 60730-1 Table H.1 (H.11.12.7), which deal with the coverage of hardware faults with the aid of software. The tables are largely identical, SW class B (C) of UL/ EN 60730-1 corresponds to SW class 1 (2) of UL 1998.
It is less conspicuous in the required documentation and in the traceability of requirements. UL/EN 60730-1 (Figure H.1) requires a slightly modified V-model compared to IEC 61508-3, a term that is not found in UL 1998. With sentences such as those in section 4.7 ("safety-related requirements... shall be traceable throughout the SW process activities and documented evidence supporting compliance with this standard"), a V-model is in fact also established and the system and SW architecture must be described and linked to the requirements.
It boils down to the fact that the same thing has to be done for both standards: V-model, measures against random hardware errors and against systematic errors, SW partitioning, static code analysis, unit tests, etc.
Disillusioned? Anyone familiar with functional safety standards and their origins in IEC 61508 will not be surprised, on the contrary. It is good to know that there are no shortcuts. Engineers have spent decades developing techniques that have proven effective in guaranteeing the safety of devices. There is (fortunately) no getting around these, they are just dressed up in different words depending on the standard.
We are happy to support you with our knowledge of standards in certification planning!
Samuel Leemann
Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!
No Comments