For your information, UL allows safety instructions to be in 'electronic' or 'soft' format if printed material is provided with instructions for initialization of the product in question "without the introduction of a hazard".
Per UL, the printed material should also include information describing existence of the electronic instructions within the product software. Regards, Bandele Jetstream Communications, Inc. badep...@jetstream.com -----Original Message----- From: Rich Nute [mailto:ri...@sdd.hp.com] Sent: Friday, July 28, 2000 10:18 AM To: gary.mcintu...@worldwidepackets.com Cc: dick.grob...@medgraph.com; marti...@appliedbiosystems.com; emc-p...@majordomo.ieee.org Subject: Re: UL Acceptance of On-Line Manuals Safety standards specify topics which must be addressed in manuals. Only those portions of the manual addressing those specific safety topics are "controlled" by the certifier. The remainder of the manual is "controlled" by the product manufacturer; this remainder may be provided in any form the manufacturer chooses. So, the manual can be considered as consisting of two sets of data: 1) data required by the safety standard; and 2) data provided by the manufacturer (e.g., instructions on how to install, operate, and service the equipment). The certifier cannot tell us how to run our business with regard to item 2. The manufacturer can provide the data in any form he chooses. Data required by the safety standard can be subdivided into two parts: a) data required for installation (i.e., up to the point where data could be read from an electronic format); and b) data required after installation. Clearly, any safety data required before the unit can display electronic data, (a), must be provided in hard-copy or equivalent form. Data for (b) can be provided in electronic format. In my experience, certifiers accept these kinds of categorization of manual safety data. Regards, Rich ps: > I have approached UL with the request... Asking permission (e.g., from a certifier) empowers the other party to determine how you will behave and what you need to do to satisfy him. Often, such empowerment results in decisions well beyond the range or outside the bounds of the standard. In the end, you are often stuck with an onerous requirement that does not coincide with either safety or business needs. I address such issues with a proposal together with a rationale why my proposal meets the standard or the intent of the standard. This enables a discussion of the principles that are involved, and does not empower the other party to make decisions for me. ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Jim Bacher: jim_bac...@mail.monarch.com Michael Garretson: pstc_ad...@garretson.org For policy questions, send mail to: Richard Nute: ri...@ieee.org ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Jim Bacher: jim_bac...@mail.monarch.com Michael Garretson: pstc_ad...@garretson.org For policy questions, send mail to: Richard Nute: ri...@ieee.org
