UL 1998:2000 pdf download Software in Programmable Components
1.1 These requirements apply to non-networked embedded microprocessor software whose failure iscapable of resulting in a risk of fire, electric shock, or injury to persons.
1.2 This is a reference standard in which the requirements are to be applied when specifically referencedby other standards or product safety requirements.
1.3 These requirements address the risks unique to product hardware controlled by software inprogrammable components.
1.4 These requirements are intended to supplement applicable product or component standards andrequirements, and are not intended to serve as the sole basis for investigating the risk of fire, electricshock, or injury to persons.
1.5 These requirements are intended to address risks that occur in the software or in the process usedto develop and maintain the software, such as the following:
a) Requirements conversion faults that cause differences between the specification for theprogrammable component and the software design;
b) Design faults such as incorrect software algorithms or interfaces;
c)Coding faults, including syntax, incorrect signs, endless loops, and other coding faults;
d) Timing faults that cause program execution to occur prematurely or late,
e)Microelectronic memory faults, such as memory failure, not enough memory, or memoryoverlap;
f)Induced faults caused by microelectronic hardware failure:
g) Latent, user, input/output, range, and other faults that are only detectable when a given stateoccurs;and
h) Failure of the programmable component to perform any function at all.
1.6 Product standard requirements may amend or supersede the requirements in this standard,asappropriate
2 Definitions of Terms Used
2 effective November 30，1998
2.1 For the purpose of this standard, the following definitions apply
2.2 APPLICATION-SPECIFIC INTEGRATED CIRCUIT (ASIC) An electronic device comprised ofmany transistors and other semiconductor components which integrate standard cells and arrays from aibrary into one piece of silicon intended for a particular use.
2.3 BUILT-IN TEST – A design method that allows a product to test itself by adding logic for test signalgeneration and analysis of test results.
2.4 CENTRAL PROCESSING UNIT (CPU) – The unit of a computing and controlling system that
includes the circuits controlling the interpretation of instructions and their execution.
2.5 CRITICAL SECTION – A segment of the software that is intended to perform the functions thataddress or control risks.
2.6 DATA – A representation of facts, concepts, or instructions in a manner suitable for storagecommunication,interpretation, or processing.
2.7 DESIGN – The process of defining the software architecture, components, modules, interfaces, testapproach, and data for a software system to satisfy specified requirements.
2.8 ELECTRONICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY (EEPROM)- Areprogrammable read-only memory in which cells may be erased electrically and in which each cell iscapable of being reprogrammed electrically.
2.9 EMBEDDED SOFTWARE – Software that is physically part of a product and whose primarypurpose is to maintain some property or relationship between other components of the product in orderto achieve the overall system objective.
2.10 ERASABLE PROGRAMMABLE READ ONLY MEMORY(EPROM) – A type of programmablememory device which can only be read and not altered under normal use. The memory is capable ofbeing erased by ultraviolet light and reprogrammed.
2.11 ERROR – A discrepancy between a computed, observed, or measured value or condition and thetrue, specified, or theoretically correct value or condition.
2.12 FAlL-OPERATIONAL PROCEDURE – A procedure executed in the event that a failure hasoccurred which continues product operation but provides degraded performance or reduced functionalcapabilities.
2.13 FAL-SAFE PROCEDURE – A procedure executed to maintain the Risks Addressed (RA) state ofa product while transitioning into a non-operational mode.
2.14 FAILURE – The inability of a product or component to perform its specified function.
2.15 FAILURE MODE – The physical or functional manifestation of a failure.
2.16 FAILURE MODE TEST – A suite of tests that have been specifically developed based upon thefailure modes that exist in a programmable component or product.
2.17 FAULT – A deficiency in a product or component which is capable of, under some operationalconditions,contributing to a failure.