This is a full-use standard, a revision of ISO/IEC 13213:1994; its scope reflects accumulated experience with the CSR architecture since it was first promulgated as a standard in 1991. In the intervening years, two bus standards, Scalable Coherent Interface (SCI), IEEE Std 1596-199x, and Serial Bus, IEEE Std 1394-1995, have been the source of most practical implementation experience. The revised scope of the CSR architecture is given below: a) The overall architectural framework partitions the… read more total available address space into equal spaces available to individual nodes. A node's address space is in turn partitioned into regions which have different usage models, e.g., memory space, private space for vendor uses, configuration ROM and an I/O space (units space) where transactions may have side effects; b) A minimal transaction set (read, write and lock requests and their associated completion responses) required for compliant bus standards. Bus bridges compliant with this architecture, whether in a homogeneous or heterogeneous environment, are also expected to transport this transaction set; c) Fundamental control and status registers (CSRs) are defined to provide a common infrastructure for all compliant buses. In some cases the details of the registers are entirely bus-dependent but the function is common to all compliant buses; d) Message request and response CSRs are specified to enable directed delivery or broadcast of messages to multiple nodes. The message format permits organizations or vendors to define the meaning of the data payload without the need for a centralized registry of all possible formats; and e) Configuration ROM provides self-descriptive data structures that permit nodes to uniformly characterize the device services available. This is critical for buses that permit live insertion and removal of nodes; each newly inserted node contains sufficient information for it to be uniquely identified and for the requisite device drivers to be loaded. Although the original CSR architecture anticipated widespread development of bridges between heterogeneous bus standards and a diversity of addressing modes, both fixed and variable, no such implementations have been made. As a consequence, the most significant changes in scope between the earlier CSR architecture and this standard are the adoption of a single, fixed addressing model and the removal of tutorial material pertaining to the design of bridges. read less
This is a full-use standard, a revision of ISO/IEC 13213:1994; its scope reflects accumulated experience with the CSR architecture since it was first promulgated as a standard in 1991. In the intervening years, two bus standards, Scalable Coherent Interface (SCI), IEEE Std 1596-199x, and Serial Bus, IEEE Std 1394-1995, have been the source of most practical implementation experience. The revised scope of the CSR architecture is given below: a) The overall architectural framework partitions the… read more total available address space into equal spaces available to individual nodes. A node's address space is in turn partitioned into regions which have different usage models, e.g., memory space, private space for vendor uses, configuration ROM and an I/O space (units space) where transactions may have side effects; b) A minimal transaction set (read, write and lock requests and their associated completion responses) required for compliant bus standards. Bus bridges compliant with this architecture, whether in a homogeneous or heterogeneous environment, are also expected to transport this transaction set; c) Fundamental control and status registers (CSRs) are defined to provide a common infrastructure for all compliant buses. In some cases the details of the registers are entirely bus-dependent but the function is common to all compliant buses; d) Message request and response CSRs are specified to enable directed delivery or broadcast of messages to multiple nodes. The message format permits organizations or vendors to define the meaning of the data payload without the need for a centralized registry of all possible formats; and e) Configuration ROM provides self-descriptive data structures that permit nodes to uniformly characterize the device services available. This is critical for buses that permit live insertion and removal of nodes; each newly inserted node contains sufficient information for it to be uniquely identified and for the requisite device drivers to be loaded. Although the original CSR architecture anticipated widespread development of bridges between heterogeneous bus standards and a diversity of addressing modes, both fixed and variable, no such implementations have been made. As a consequence, the most significant changes in scope between the earlier CSR architecture and this standard are the adoption of a single, fixed addressing model and the removal of tutorial material pertaining to the design of bridges. read less
These recommendations apply to the following types of steam turbines, rated at 500 kW and larger, intended to drive electric generators at constant speed: 1) Condensing or noncondensing turbines without initial steam-pressure control, exhaust steam, pressure control, or either, including turbines used with reheat, regenerative feedwater heaters, or both. (See Figs 1 and 2). 2) Condensing or noncondensing turbines with initial steam-pressure control, exhaust steam-pressure control, or both,… read more including turbines used with reheat, regenerative feedwater heaters, or both. [See Figs 3, 7, 8(a), and 8(b)]. 3) Automatic extraction, induction, or both, and mixed-pressure turbines. [See Figs 4, 5, and 8(c)]. read less
This guide covers fire hazards from electrical distribution and utilization systems installed in industrial, residential, and public buildings/areas. This guide also describes how a practical fire hazard assessment can be established for electrical equipment containing insulating materials. The hazard assessment should be based on relevant fire or failure scenarios based on service experience and engineering analysis. The relationship between small-scale material tests and large-scale fire… read more hazard tests is discussed. read less
This standard covers the construction, mechanical, electrical, and optical performance, installation guidelines, acceptance criteria, test requirements, environmental considerations, and accessories for a nonmetallic, all-dielectric self-supporting (ADSS) fiber optic cable. The ADSS cable is designed to be located primarily on overhead utility facilities.
This standard applies to the Plan used for the development, procurement, maintenance, and retirement of safety-critical software; for example, software products whose failure could cause loss of life, serious harm, or have widespread negative social impact. This standard requires that the Plan be prepared within the context of the system safety program. The scope of this standard includes only the safety aspects of the software. This standard does not contain special provisions required for… read more software used in distributed systems or in parallel processors. read less
This standard defines an application program interface (API) to the services of the OSI File Transfer, Access, and Management (FTAM) application-service-element. The API provides access to a set of high-level operations. That is, API functions map on to a sequence of FTAM primitives that implement the required operation. Apart from association management functions, functions that map directly onto FTAM service primitives are not provided. The API provides file transfer and file management… read more operations. File access and filestore management operations are not provided. The API supports the FTAM initiator role. The FTAM responder role is not supported. The API supports a context-free mode of operation (where the operation is performed using an FTAM association that is created specifically for the operation and destroyed once the operation is completed) and a context-sensitive mode of operation (where the FTAM association is created and destroyed independently, and operations are performed within the context of this independent association). In order to support the context-sensitive mode of operation, the API defines a set of association management functions that create and destroy FTAM associations. An implementation conforming to this standard requires support of an implementation of the services defined in IEEE Std 1224-1993 {14}. This standard is a "thick" C binding (that is, it defines both the semantics of the operations and the C language binding to those semantics). An understanding of FTAM is assumed in the remaining parts of this specification. Those unfamiliar with FTAM may wish to read Annex , Overview of FTAM (and perhaps Annex , Overview of OM) before proceeding with the remainder of this standard. read less