UL 1998 Standard: software classes

Does anyone have experience with UL 1998 (Standard for Safety - Software in Programmable Components)?

I was doing ok until I hit the appendix which kind of falls into a discussion of software classes. Nothing in the body seems to refer to any classes. It's rather unclear (to me) how to apply the clauses in Appendix A3. Some of the statements indicate specific classes and others don't. I presume if they don't then they apply to both classes (but then why didn't they put that in the main body)?

Why has no one answered Brother @yodon ? (I offer my own apologies for not dipping into this sub-forum before today)

My own personal assessment of UL 1998 is that it was developed with a minimum of "consensus". Many standards of that era (mid 2000s) have a common set of peculiarites: one of these is the use of terminology that looks like it belongs to some other family of standards. I don't know if any other product-specific UL standards exist that use the "Class 1/Class 2" terminology for software... but the wording in A3 of UL 1998 has an echo of particular standards for use with 60601-1.

In practical terms, the last time I did a deep dive through UL 1998 (2013 version) it was to motivate the analysis of software (system) risks and consideration of specific software (system) risk controls for a Software Hazard Analysis of medical devices developed in compliance with 62304. See 8.2 of UL 1998. I used to teach Software Hazard analysis and UL 1998 informed my teaching on the topic of active vs. passive protective measures in the design of software systems, but other than that I can't say that the standard has made a big impact on my career.

I can think of a few specific examples where my (medical device) software development teams leveraged (by my suggestion) a few of the ideas from UL 1998 to reduce risks associated in some particular elements of design space, but I don't think my teams were aware that what we did was inspired by UL 1998.

After posting the above, I was possessed by the spirit of the staircase and have decided to add the following piece of fluff from my head.

UL is not unique among businesses which generate standards (e.g. ASHRAE, NSF) to include within standards elements to support/direct/mandate specific tests that can be used to establish compliance with (other) standards. The Class 1, Class 2 of UL1998 has the feel of this, at least to me. My own experiences with NRTL (multiple different TL, with diverse classes of products) is that NRTLs have to be able to charge for something (a test or inspection) and what they actually charge for has to derive in some way from a consensus standard so the mantra of "we charge all our customers the same amount for the same service, so that each of them can objectively compare their products against their competitors" is not meaningless.

It is not at all uncommon to review standards from these sorts of bodies and wonder "why is that the 'consensus' test method?" when a peculiarly specific piece of equipment is called out as required in the 'consensus standard'. The answer always includes elements of 'they got there first' and 'they don't want it to be too easy for competing NRTLs to get into the same business.'

In the case of programmable components, there are far less obvious ways of specifying test methods and equipment. I feel that UL was trying to lay some sort of groundwork in UL1998 to motivate tests in, and possibly updates to, other standards.