Use of “Software Only” Functional Safety Requirements

19 Aug 2026

Examining the Gaps between Software Evaluation and True Functional Safety

Some product standards deviate from traditional functional safety (FS) requirements for safety controls (controls which are relied upon for protection) and only require a software/firmware evaluation, leaving hardware to be evaluated by legacy-style abnormal fault tests, or no evaluation at all.

Most standards will include a requirement that says something along the lines of “evaluate safety controls to a relevant functional safety standard.” This pushes all hardware, software, and other detailed requirements to the relevant FS standard. However, there are some standards that instead refer to FS standards for software-only evaluations. Namely:

• ANSI/CAN/UL 2200, Stationary Engine Generator Assemblies (3^rd edition, clause 29.3),
• ANSI/CAN/UL 6200, Controllers for Use in Power Production (1^st edition, clause 37.5), and
• UL 1741, Inverters, Converters, Controllers and Interconnection System Equipment for Use with Distributed Energy Resources (3^rd edition, clause 50.2.2).

These standards (or parts of them) indicate that only when software is used as part of the safety system, then the software itself is the only part required to be evaluated to a functional safety standard. Relying on abnormal component fault testing and ignoring FS hardware evaluations can be problematic for several reasons.

Random Hardware Faults

Considering hardware reliability through the lens of legacy-style abnormal component faults, this misses the main purpose of functional safety reliability: consideration of random hardware failures. This is critical when building control systems with microprocessors that support software.

Part of the hardware analysis for functional safety circuits determines the diagnostic capability of the control and subsequently drives requirements for software development. As hardware reliability is analysed the design engineer may realize that additional diagnostic capability is needed. This would be missed by skipping this part of the analysis.

Further, using legacy abnormal faults to test safety critical circuits may overlook latent faults or exempt the control circuits entirely. We will consider at these details in the next section.

Legacy Abnormal Fault Testing for Controls

Whether control systems use software or not, the use of abnormal fault testing does not accurately validate the failure modes associated with the hardware of safety circuits. There are several shortfalls with using component fault test in lieu of complete hardware analysis:

1. In practice, legacy abnormal component faults only test a small set of components in a circuit. It is not a 100% failure mode analysis of all circuit components as would be required in UL 991, 60730, or other FS standards. This does not validate to the level of detail that a typical Failure Modes, Effects, and Diagnostic Analysis (FMEDA) analysis would provide and may simply overlook faults that result in dangerous failures.
2. Legacy abnormal component faults are not designed to validate safety functions. Every standard with abnormal fault testing is going to have evaluation of compliance criteria along the lines of: “The product must not emit flame, molten metal, and must comply with the dielectric test after the fault test.”
   
   This can be seen in UL 1741 clause 50.1, which describes the general conditions for the abnormal test sequence:
   
   50.1.1 A unit shall not emit flame or molten metal or become a risk of fire, electric shock, or injury to persons – see 50.1.3 – when subjected to the tests specified in 50.1.2 – 50.7.3.
   
   50.1.2 Following each test, the unit shall comply with Dielectric Voltage-Withstand Test, Section 47.
   
   Unless the circuit has been designed for functional safety and fault tolerance, then the introduction of a single fault in a logic circuit could defeat the safety function entirely. But since this fault mode may be affecting the output pin on a latch, or shorting the pin on an AND gate, there will be no obvious result. These digital components are designed to operate in this manner, and as the circuits are also typical supplied by low-power supplies, there will be no obvious result. The system will likely continue to operate with this latent fault, unbeknownst to the operator that the safety function has been completely disabled. There are no criteria in the standard to say this is a non-compliant result.

3. The other big miss from this approach is that often abnormal fault tests will exempt circuits powered by limited energy or Class 2 sources. It is fairly common to have a safety control in a 5 or 12 Vdc circuit, and if this is powered by a low-voltage limited energy (LVLE) or Class 2 power source, then the evaluator is not going to consider any faults whatsoever.

From these points we can see that hardware-only circuits should be evaluated under a relevant functional safety standard. Many faults can occur in hardware-based logic systems that may be missed by a simple component fault test. A rigorous hardware analysis (such as an FMEDA) is necessary to ensure all relevant failures have been considered.

Example

Let’s consider an example to see why this is an important issue: imagine we have an AC-DC converter for microgrid systems that is covered under UL 1741. Let’s assume there is no grid interactivity. 

First, the only mention of functional safety for this particular product type in UL 1741 is clause 50.2.2 for the output overload test:

50.2.2 Firmware or Software controlling the temperature limits of an inverter shall be disabled for the tests described in 50.2, or evaluated for reliability in accordance with the Standard for Software in Programmable Components, UL 1998.

Let’s also say that the product relies on a safety function for over temperature protection to prevent catastrophic failure in the event the output is overloaded. So, we cannot bypass the safety function and comply with the overload test. Finally, let’s say they implement this function in hardware only, using logic gates and other discrete components (no software).

The first issue is that this standard only requires UL 1998 to evaluate software. That misses the hardware faults entirely. According to clause 50.2.2, we do no further evaluation of the safety circuit.

The second issue, as described in the preceding section, the abnormal component fault tests of UL 1741:

1. May not consider any of the control circuits if they are powered by a LVLE or Class 2 source
2. May not select the fault(s) that cause hazardous failure modes
3. If the fault is applied, the results may be deemed compliant because there is no fire, molten metal, or dielectric breakdown – even though the entire safety function is disabled and the product is now operating without the safety control.

Clearly this is a major gap in the requirements of UL 1741. You can see how deviating from a structured functional safety evaluation can easily result in a product failing in an unsafe manner.

Use of 61508-3 as a Standalone Document

Another issue related to the above, but with different implications, is found in the standards UL 2200 and UL 6200. These provide several options for software-only evaluation. For example, clause 29.3 from UL 2200:

The use of 60730, 1998, or CSA 0.8 may be an acceptable pathway for this – as these standards have built-in requirements which mandate software diagnostics to mitigate faults originating from hardware failures (ignoring the latent hardware faults previously discussed). Failures such as stuck-at bits, memory errors, timing errors, and many others. This can be found in UL/IEC 60730 Table H.2 (6^th Edition) or 1998 Table A2.1.

Unfortunately, IEC 61508-3 was not intended for use “in a vacuum” as it is referred to here. The expectation is that a safety system evaluated under IEC 61508 would follow a prescribed development path, using parts -1 and -2 along with -3, and that system-level and hardware-level evaluations would drive requirements for safety software. There are no normative requirements in 61508-3 (when used by itself) which would force the evaluator to consider random hardware errors as they relate to software only. This itself is a massive oversight by the end-product standards promoting this approach.

Recommendations

Undoubtedly the decision on which FS standards are applied by the end-product standards is ultimately the decision of accredited test laboratories and notified bodies. Ideally the standard writing committees would take a consistent approach and leave safety requirements to the relevant FS standards to cover without taking parts of them out of context. As much as we may disagree with the requirements, we also understand that clients should not necessarily be held to higher burdens than others using the same requirement set. Until the standard committees decide to change these requirements, these issues will persist.

Since there are multiple intertwined issues, there may, unfortunately, not be just one simple solution.

The comprehensive solution is to conduct a complete FS evaluation per the relevant standards – meaning evaluations for both hardware and software. The certifier may not review these FS evaluations, but clients would be better served having done this work and keeping this information internally to assure themselves that the system is designed using best engineering practices. This approach would address both the hardware and software risks of the safety system.

If not conducting a full functional safety evaluation, the next best option would be to refrain from using 61508-3 by itself. Instead use UL 1998, 60730, or CSA 0.8 (as appropriate) which at least include the relevant requirements to mitigate microprocessor fault (refer to tables A2.1 or H.2, respectively). It is critical to highlight that this approach does not capture all hardware failures that the FMEA process would capture. It would befit system developers to at least consider single fault tolerance of hardware circuits, even if this does not get captured in a formal FMEDA.

How Intertek Assurance Can Help

Intertek Assurance supports organisations at this early decision-making stage through structured standards research and applicability analysis, helping to remove uncertainty before significant design or certification effort begins.

Our support typically includes:

• Design and gap analysis
• Standards identification and scoping

Intertek Assurance helps clients move forward with confidence – knowing that their functional safety strategy is technically sound, proportionate to risk, and aligned with both current and future market expectations.