Linux-Architecture-Reference/LoPAR/ch_service_indicators.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Copyright (c) 2016, 2020 OpenPOWER Foundation

  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         xmlns:xl="http://www.w3.org/1999/xlink"
         version="5.0"
         xml:lang="en"
         xml:id="dbdoclet.50569347_31867">
  <title>Service Indicators</title>

  <para>This chapter defines service indicators
  <footnote xml:id="pgfId-648393">
    <para>Note that many times &#8220;indicators&#8221; are referred to as
    &#8220;LEDs&#8221; as this is one of the most common implementations for
    indicators at the current time.</para>
  </footnote>relative to:</para>

  <itemizedlist>
	  <listitem>
		  <para>Which service indicators may be exposed to an OS and which may
		  not</para>
	  </listitem>

	  <listitem>
		  <para>The usage model for service indicators, regardless of whether they
		  are exposed to the OS or not</para>
		</listitem>
	</itemizedlist>

  <section xml:id="dbdoclet.50569347_15739">
    <title>General</title>
    <para>This section gives some general background information required to
    understand the service indicator requirements. The service indicator
    requirements can be found starting in
    <xref linkend="dbdoclet.50569347_24150" />.</para>

    <section xml:id="dbdoclet.50569347_67030">
      <title>Basic Platform Definitions</title>
      <para>The following are the definitions of some of the terms used in this
      architecture. See also
      <xref linkend="dbdoclet.50569388_37308"/> for additional terms.</para>

	    <section xml:id="dbdoclet.50569347_12130">
	      <title>&#8220;Enclosure&#8221;, Packaging, and Other
	      Terminology</title>
	      <para>In order to abstract specific packaging differences between
	      different products, this architecture uses a number of terms that denote
	      a unit of packaging.</para>
	      <para>The term
	      <emphasis>enclosure</emphasis> means something different, depending on the
	      product line. Generally this is an entity that can be unplugged and be
	      removed from the system, but may include the entire system, and generally
	      encloses other FRUs. It is, however, possible to have a FRU that contains

	      <emphasis>one</emphasis> other FRU, and not have it be an enclosure. See
	      below, for more information.</para>
	      <para>The concept of the enclosure is very key to this architecture,
	      because the enclosure provides the anchor point for the Enclosure Fault,
	      Enclosure Identify, and (when applicable) the Error Log indicators.
	      <emphasis></emphasis></para>
	      <itemizedlist>
				  <listitem>
			      <para>For a blade system, a base blade plus any attached
			      sidecars.</para>
			      <itemizedlist>
						  <listitem>
					      <para>A <emphasis>sidecar</emphasis> is a blade that plugs
					      into a blade slot, but
					      which is physically connected to the base blade and which cannot be
					      removed without also removing the base blade and any other attached
					      sidecars.</para>
							</listitem>

						  <listitem>
					      <para>The Enclosure Identify indicator is located on the base blade.
					      Sidecars do not have an Enclosure Identify indicator.</para>
							</listitem>
						</itemizedlist>
					</listitem>

					<listitem>
			      <para>A stand-alone computing box, like a deskside unit.</para>
					</listitem>

					<listitem>
			      <para>A separately powered box that attaches to a stand-alone computing
			      box (for example, an I/O expansion tower).</para>
					</listitem>

					<listitem>
			      <para>For a rack system, a drawer or partial drawer, with its own power
			      domains, within a rack system (but not a chassis, in blade system
			      terms).</para>
					</listitem>
				</itemizedlist>

	      <para>FRUs that have one or no internal FRUs are a possible exception to
	      the above definition of enclosure. The general requirements are that the
	      enclosing FRU does not need an Error Log indicator (see also Requirement
	      <xref linkend="dbdoclet.50569347_86824" />), implements the full xipSIA
	      Lightpath architecture
	      <emphasis>including FRU Identify</emphasis>, has the enclosing FRU
	      Fault/Identify and internal (if any) FRU Fault/Identify indicators
	      visible from the outside of the system the same way that enclosure
	      indicators would be, and rolls-up the FRU Fault/Identify indicators to
	      the next level of indicators when there is a next level (for example,
	      chassis level indicators). Examples of the type of FRUs that the xipSIA
	      architecture team
	      <emphasis>might</emphasis> approve as a non-enclosures is:</para>

	      <itemizedlist>
				  <listitem>
			      <para>Appliance drawers (&#8220;appliance&#8221; means that there are
			      no field serviceable parts inside).</para>
				  </listitem>

				  <listitem>
			      <para>Appliance Blades, except if they require an Error Log
			      indicator.</para>
				  </listitem>

				  <listitem>
			      <para>A power supply which comprises two or fewer FRUs.</para>
				  </listitem>

				  <listitem>
			      <para>Fans, but not fan assemblies when the fan assemblies have three
			      or more Fault indicators.</para>
				  </listitem>
				</itemizedlist>

	      <para>In addition, the term
	      <emphasis>System Enclosure</emphasis> (also known as a
	      <emphasis>Primary Enclosure</emphasis>) is used to denote the enclosure
	      of a system that contains the one and only Error Log indicator
	      <footnote xml:id="pgfId-667292">
	        <para>Previously known as the System Information (Attention)
	        indicator.</para>
	      </footnote>for the system. An enclosure that is not a System Enclosure is
	      called a
	      <emphasis>secondary enclosure</emphasis>. The System Enclosure is
	      expected to be one that contains at least some of the system processors
	      for the platform.</para>

	      <para>In this chapter, the term
	      <emphasis>chassis</emphasis> will refer to a blade system chassis.</para>

	      <para>Other terminology used in this chapter includes:</para>

		    <variablelist>
			  	<varlistentry>
			  		<term><emphasis role="bold">activate</emphasis></term>
			  			<listitem>
					      <para>To activate an indicator (physical or virtual) means to
					      set it to a non-off state (blink, blip, or on). An indicator does not
					      need to be in the off (deactivated) state prior to being activated (for
					      example a second request to activate an already active indicator, is also
					      considered to be an activation of that indicator).</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">active state</emphasis></term>
			  			<listitem>
					      <para>An indicator in an active state is in a non-off state.
					      Different indicator types can be set to a different set of active states.
					      For each of the following indicators, the following states are applicable
					      in the indicator active state (See
					      <xref linkend="dbdoclet.50569347_69815" /> for more detail on when each
					      state is applicable and for the conditions under which a state transition
					      is made):</para>
					      <para>FRU Identify: blink</para>
					      <para>FRU Fault: on</para>
					      <para>Blue Enclosure Identify: on or blink</para>
					      <para>Enclosure Fault: on or blip</para>
					      <para>Error Log: on</para>
					      <para>Blue Rack Identify: on</para>
					      <para>Blue Row Identify: on</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">blip</emphasis></term>
			  			<listitem>
					      <para>A blink state with a short duty cycle used in the
					      &#8220;remind&#8221; state for Enclosure Fault Indicators. See also
					      Requirement
					      <xref linkend="dbdoclet.50569347_55538" />.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">Chassis Enclosure Identify</emphasis></term>
			  			<listitem>
					      <para>An Enclosure Identify indicator at the blade system chassis
					      level.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">CRU</emphasis></term>
			  			<listitem>
					      <para>See FRU.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">deactivate</emphasis></term>
			  			<listitem>
					      <para>To deactivate an indicator (physical or virtual) means
					      to set it to the off state. Deactivating a virtual indicator may or may
					      not deactivate the physical indicator associated with that virtual
					      indicator (see
					      <xref linkend="dbdoclet.50569347_69815" />).</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">Enclosure Fault</emphasis></term>
			  			<listitem>
					      <para>An amber indicator which indicates, when activated,
					      that there is a FRU Fault indicator in the enclosure that is
					      active.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">Enclosure Identify</emphasis></term>
			  			<listitem>
					      <para>An indicator that is used to identify an
					      enclosure in an installation or an enclosure in a group. This indicator
					      is blue in color and is turned on in the active identify state.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">FRU</emphasis></term>
			  			<listitem>
					      <para>Field Replaceable Unit. Used to also mean CRU (Customer
					      Replaceable Unit) in this chapter.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">FRU Fault</emphasis></term>
			  			<listitem>
					      <para>An amber indicator that is used to point to a failing FRU
					      in an enclosure.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">FRU Identify</emphasis></term>
			  			<listitem>
					      <para>An amber indicator that is used to identify a FRU in
					      an enclosure or a place where a FRU is to be plugged (for example, for an
					      upgrade operation).</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">Guiding Light Mode</emphasis></term>
			  			<listitem>
					      <para>A platform implementation that provides FRU
					      Identify indicators for identifying failing FRUs. See
					      <xref linkend="dbdoclet.50569347_16804" /> for more information.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">ID</emphasis></term>
			  			<listitem>
					      <para>Shorthand used some places (mainly figures) in this chapter for
					      &#8220;Identify&#8221; or &#8220;Identify indicator&#8221;.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">Lightpath Mode</emphasis></term>
			  			<listitem>
					      <para>A platform implementation that provides FRU Fault
					      indicators as the general way to identify failing FRUs. See
					      <xref linkend="dbdoclet.50569347_16804" /> for more information.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">not visible to the OS</emphasis></term>
			  			<listitem>
					      <para>See transparent to the OS.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">primary level indicators</emphasis></term>
			  			<listitem>
					      <para>The enclosure level indicators. For
					      example, for rack systems, the enclosure is either the blade, for blade
					      systems, or the drawer level, for non-blade systems.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">roll-down</emphasis></term>
			  			<listitem>
					      <para>This term is not used by this architecture, but some
					      people refer to roll-up as the action of activating a higher level
					      indicator and roll-down as the action of deactivating a lower level
					      indicator. This architecture will use roll-up for both activation and
					      deactivation. See roll-up.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">roll-up</emphasis></term>
			  			<listitem>
					      <para>The action of activating a higher level indicator, when a
					      lower level indicator is activated, and deactivating it when all the
					      lower level indicators that roll-up to that indicator are deactivated.
					      For example, if a FRU Fault indicator is activated, it rolls-up and turns
					      on the Enclosure Fault indicator, and when the last FRU Fault indicator
					      in an enclosure is deactivated, the Enclosure Fault indicator for that
					      enclosure is deactivated.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">secondary level indicators</emphasis></term>
			  			<listitem>
					      <para>The indicators on levels below the Primary Level and above the FRU
					      level.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">SFP</emphasis></term>
			  			<listitem>
					      <para>Service Focal Point. See also
					      <xref linkend="dbdoclet.50569347_95432" />.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">Error Log</emphasis></term>
			  			<listitem>
					      <para>An amber indicator that indicates that the user needs to look at
					      the error log or problem determination procedures, in order to determine
					      the cause.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">tertiary level indicators</emphasis></term>
			  			<listitem>
					      <para>The FRU level indicators.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">transparent to the OS</emphasis></term>
			  			<listitem>
					      <para>Indicators whose state cannot be modified or
					      sensed by OS or application level software. For example, power supply
					      Fault indicators.</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">turn off</emphasis></term>
			  			<listitem>
					      <para>To turn off a physical indicator means exactly like it
					      sounds. Turning off a virtual or logical indicator may or may not turn
					      off the physical indicator, depending on the state diagram for the
					      physical one (see
					      <xref linkend="dbdoclet.50569347_69815" />).</para>
					    </listitem>
			  	</varlistentry>

			  	<varlistentry>
			  		<term><emphasis role="bold">visible to the OS</emphasis></term>
			  			<listitem>
					      <para>Indicators whose state can be modified or sensed
					      by OS or application level software. For PCI Hot Plug indicators. See
					      also <xref linkend="dbdoclet.50569347_63097" />.</para>
					    </listitem>
			  	</varlistentry>
			  </variablelist>

	    </section>

	    <section xml:id="dbdoclet.50569347_63097">
	      <title>Service Indicator Visibility and Transparency to the
	      OS</title>
	      <para>An indicator is said to be transparent or not visible to the OS
	      when its state cannot be modified or sensed by OS or application level
	      software (for example, power supply Fault indicators). An indicator is
	      said to be visible to the OS when its state can be modified and sensed by
	      OS or application level software (for example, PCI Hot Plug
	      indicators).</para>
	      <para>Requirements on visibility can be found in
	      <xref linkend="dbdoclet.50569347_24150" />.</para>
	    </section>

	    <section>
	      <title>Service Indicator</title>
	      <para>A
	      <emphasis>service indicator</emphasis> is defined as any indicator that is
	      used in the course of servicing a system. The intent of service
	      indicators is
	      <emphasis>not</emphasis>, in general, to increase system Error Detection
	      and Fault Isolation (EDFI), but rather to guide the user in performance
	      of a service action. Usages include (but are not limited to):</para>

				<itemizedlist>
				  <listitem>
			      <para>Dynamic Reconfiguration (LoPAR indicator type 9002) to indicate
			      the status of DR operations on a Field Replacable Unit (FRU). More
			      information on DR indicators can be found in
			      <xref linkend="dbdoclet.50569342_75822" />. This indicator is amber
			      <footnote xml:id="pgfId-630879">
			        <para>The term &#8220;amber&#8221; will be used in this chapter to mean
			        any wavelength between yellow and amber.</para>
			      </footnote>in color except for some legacy implementations which combined
			      this indicator with the power indicator, where the color was
			      green.</para>
				  </listitem>

				  <listitem>
			      <para>An indication of a fault condition of a FRU (LoPAR indicator
			      type 9006, when OS visible). This indicator is amber in color. The FRU
			      Fault indicator is handled differently by the platform based on whether
			      or not the platform is Lightpath Mode platform or Guiding Light
			      Mode:</para>
						<itemizedlist>
						  <listitem>
					      <para>For Guiding Light Mode platforms, FRU fault indicators are
					      transparent to the software and therefore have some very specific
					      requirements relative to their very localized behavior. In this case,
					      although FRU Fault indicators themselves are transparent to the software,
					      the associated failure itself, which would activate a FRU Fault
					      indicator, will be available to the software that handles serviceable
					      events.</para>
						  </listitem>

						  <listitem>
					      <para>For Lightpath Mode platforms, a FRU fault indicator will be
					      available to the software and is activated by the detector of the error.
					      In addition, the FRU Fault rolls up to an Enclosure Fault
					      indicator.</para>
						  </listitem>
						</itemizedlist>
				  </listitem>

				  <listitem>
			      <para>A system-wide indication of a fault or some condition needing
			      attention in the system. An Error Log indicator (LoPAR indicator type
			      9006) is an example of an OS-visible
			      <footnote xml:id="pgfId-648471">
			        <para>For a definition of the visibility or transparency of an
			        indicator, see
			        <xref linkend="dbdoclet.50569347_63097"/>.</para>
			      </footnote>indicator of this class of indicators. The Error Log indicator
			      is a flag to the user that there is something in the system needing
			      attention, and therefore a starting point to indicate that they should
			      begin the isolation procedures to determine what needs attention. In a
			      partitioned system, the physical Error Log
			      <footnote xml:id="pgfId-632877">
			        <para>If the term &#8220;virtual&#8221; does not appear before
			        &#8220;Error Log&#8221;, then the text is referring to the physical
			        Error Log indicator.</para>
			      </footnote>indicator may be the logical OR of individual virtual Error
			      Log indicators (one virtual Error Log indicator per logical partition and
			      one for each other separate entity that is non-partition related). This
			      indicator is amber in color.</para>
				  </listitem>

				  <listitem>
			      <para>An indication of an Identify (locate) operation. An Identify
			      indicator (LoPAR indicator type 9007) is an example of an indicator of
			      this class. These indicators may or may not be visible to an OS. In this
			      capacity, the indicator is activated
			      <footnote xml:id="pgfId-664224">
			        <para>For a definition of what &#8220;activate&#8221; means, see
			        <xref linkend="dbdoclet.50569347_12130" />.</para>
			      </footnote>at the user&#8217;s request in order to help them locate a
			      component in the system (for example, a FRU, a connector, an enclosure,
			      etc.). This indicator is amber in color, except for the Enclosure, Rack,
			      and Row Identify indicators, which are blue in color.</para>
				  </listitem>

				  <listitem>
			      <para>An indication of the power state of an entity. This indicator is
			      platform controlled and is transparent to the OS(s). In addition to the
			      power state, this indicator may be used to indicate a power failure or
			      fault. This indicator is green in color.</para>
				  </listitem>

				  <listitem>
			      <para>Environmental indicators such as ambient temperature too high.
			      These are transparent to the OS.</para>
				  </listitem>

				  <listitem>
			      <para>Hardware only indicators such as Ethernet activity indicators.
			      These are transparent to the OS.</para>
				  </listitem>
				</itemizedlist>

	    </section>

	    <section xml:id="dbdoclet.50569347_16804">
	      <title>Service Indicator Modes</title>
	      <para>There are two modes that a platform can operate in relative to
	      service indicators: Lightpath Mode and Guiding Light Mode. Any particular

	      <emphasis>platform</emphasis> operates in one and only one mode relative
	      to service indicators: Lightpath Mode or Guiding Light Mode. A
	      <emphasis>component</emphasis> (hardware, firmware, or software) which is
	      designed to be used in both a Lightpath Mode and a Guiding Light Mode
	      platform needs to be able to operate in both modes.</para>
	      <para>For guidance in which mode a platform should be designed to
	      operate, see
	      <xref linkend="dbdoclet.50569347_82731"/>.</para>
	      <para>The following sections give an overview of these two modes. For
	      specific requirements of each mode, see
	      <xref linkend="dbdoclet.50569347_24150"/>.</para>

		    <section>
		      <title>Lightpath Mode</title>
		      <para>The
		      <emphasis>Lightpath Mode</emphasis> specifies a platform implementation of
		      service indicators much like what industry-standard servers originally
		      implemented with its Lightpath, except that FRU indicators also implement
		      an Identify state along with the current Fault state. The Identify state
		      overrides the Fault state while the Identify is active for an indicator,
		      and the indicator is put into the Fault state, if one is pending, when
		      the Identify is removed.</para>
		      <para>A summary of the Lightpath Mode is as follows (see
		      <xref linkend="dbdoclet.50569347_24150"/> for detailed
		      requirements):</para>

					<itemizedlist>
						  <listitem>
					      <para>FRU Fault indicators are used as the general way to identify
					      failing FRUs.</para>
						  </listitem>

						  <listitem>
					      <para>The physical indicator that implements the Fault indicator states
					      also implements the Identify indicator states (that is, a FRU Fault
					      indicator is also a FRU Identify indicator for the same FRU).</para>
						  </listitem>

						  <listitem>
					      <para>This mode is basically a superset of the Guiding Light
					      Mode.</para>
						  </listitem>

						  <listitem>
					      <para>FRU Fault indicators are presented to the OS for FRUs for which
					      the OS image is expected to detect errors for either the entire FRU or
					      part of the FRU. In the latter case, this represents a shared FRU, in
					      which case the FRU Fault indicator is virtualized, so that one partition
					      cannot view the setting by another partition, which would allow a covert
					      storage channel (see also
					      <xref linkend="dbdoclet.50569347_55025"/>).</para>
						  </listitem>

						  <listitem>
					      <para>The OS and firmware are responsible for activating the FRU Fault
					      indicator for a FRU for which they detect an error. Fault indicators are
					      reset by the service action on the failing part that they
					      represent.</para>
						  </listitem>

						  <listitem>
					      <para>FRU Identify indicators are presented to the OS for FRUs that are
					      fully owned by the OS image. They may also be presented for FRUs that are
					      partially owned by the OS image. Ownership of a FRU by the OS image is
					      defined as being the condition of the FRU being under software control by
					      the OS, a device driver associated with the OS, or application software
					      running on the OS. In the partially owned case, this represents a shared
					      FRU, in which case the FRU Identify indicator is virtualized, so that one
					      partition cannot view the setting by another partition, which would allow
					      a covert storage channel (see also
					      <xref linkend="dbdoclet.50569347_55025" />).</para>
						  </listitem>

						  <listitem>
					      <para>Connector Identify indicators are presented to the OS for
					      connectors that are fully owned by the OS image. Ownership of a connector
					      by the OS image is defined as being the condition of the connector being
					      under software control by the OS, a device driver associated with the OS,
					      or application software running on the OS.</para>
						  </listitem>

						  <listitem>
					      <para>Enclosure Identify indicators are available to the OS when the OS
					      fully owns a FRU in the enclosure. This indicator is virtualized in a
					      partitioned system, so that one partition cannot view the setting by
					      another partition, which would allow a covert storage channel.</para>
						  </listitem>

						  <listitem>
					      <para>The Error Log indicator or virtual copy thereof (for LPARed
					      platforms) is available to each OS image.</para>
						  </listitem>
					</itemizedlist>

		      <para>See Requirement
		      <xref linkend="dbdoclet.50569347_86824" /> for more information for
		      requirements on activation of the Fault indicators.</para>
		      <para>The Triple-S UI, when implemented, also adds additional requires to
		      Lightpath Mode implementations. See
		      <xref linkend="dbdoclet.50569347_88196" />.</para>
		    </section>

		    <section>
		      <title>Guiding Light Mode</title>
		      <para>A summary of the Guiding Light Mode is as follows (see
		      <xref linkend="dbdoclet.50569347_24150" /> for detailed
		      requirements):</para>

					<itemizedlist>
					  <listitem>
    		      <para>FRU Identify indicators are used as the way of identifying
    		      service procedures like repair, reconfiguration, and upgrade. FRU
    		      Identify indicators are activated/deactivated by user via a user
    		      interface, to identify the FRU(s) involved in the service
    		      procedure.</para>
					  </listitem>

					  <listitem>
    		      <para>FRU Identify indicators are presented to the OS for FRUs that are
    		      fully owned by the OS image. Ownership of a FRU by the OS image is
    		      defined as being the condition of the FRU being under software control by
    		      the OS, a device driver associated with the OS, or application software
    		      running on the OS.</para>
					  </listitem>

					  <listitem>
    		      <para>Connector Identify indicators are presented to the OS for
    		      connectors that are fully owned by the OS image. Ownership of a connector
    		      by the OS image is defined as being the condition of the connector being
    		      under software control by the OS, a device driver associated with the OS,
    		      or application software running on the OS.</para>
					  </listitem>

					  <listitem>
    		      <para>Fault indicators are allowed, but not required, but if provided,
    		      must be transparent to any OS image, and are reset by the service action
    		      on the failing part that they represent. To be transparent to an OS means
    		      that they cannot be controlled by the OS, nor will they interfere with
    		      any other indicator that is controlled by the OS.</para>
					  </listitem>

					  <listitem>
    		      <para>Enclosure Identify indicators are provided as part of the
    		      Identify roll-up. Enclosure Identify indicators are available to the OS
    		      when the OS fully owns a FRU in the enclosure. This indicator is
    		      virtualized in a partitioned system, so that one partition cannot view
    		      the setting by another partition, which would allow a covert storage
    		      channel.</para>
					  </listitem>

					  <listitem>
    		      <para>The Error Log indicator, or a virtual copy thereof (for LPARed
    		      platforms), is available to the OS.</para>
					  </listitem>
					</itemizedlist>

		    </section>

	    </section>

	    <section xml:id="dbdoclet.50569347_55025">
	      <title>Covert Storage Channels</title>
	      <para>A
	      <emphasis>covert storage channel</emphasis> is a path between two entities
	      that can be used to pass data outside the normal data sharing paths like
	      LANs. For example, if two OS images were given access to the same
	      physical indicator and if each OS image could read the state of the
	      indicator, then the indicator can become a single-bit covert storage
	      channel between cooperating entities in the two OS images, to pass data
	      back and forth. This cannot be allowed, for security reasons, and
	      therefore this architecture defines the concept of virtual
	      indicators.</para>
	      <para>A
	      <emphasis>virtual</emphasis> indicator is provided to each OS image for
	      each physical indicator that is shared between OS images. The physical
	      indicator is activated when any virtual indicator for that physical
	      indicator is activated and the physical indicator is deactivated when all
	      virtual indicators for that physical indicator are deactivated. The
	      general OS image can sense what it is trying to set the indicator to, but
	      cannot sense what the other virtual indicators are set to, and hence no
	      covert storage channel exists. The exception to the shared access is by a
	      trusted Service Focal Point (see
	      <xref linkend="dbdoclet.50569347_95432" /> for more details). For more
	      information on how virtual indicators affect the physical indicator
	      state, see the physical indicator state diagrams later in this
	      chapter.</para>
	      <para>An OS image in a partitioned system needs to realize that it may
	      not have full control over all physical indicators to which it has access
	      (that is, needs to realize that the indicators may be virtualized in some
	      cases), and in those cases it should not attempt to indicate to the user
	      via a user interface the state of the physical indicator which is
	      controlled by a virtual indicator.</para>
	      <para>Virtual indicators are controlled by the OS for which they are
	      generated, except that the platform may activate an OS&#8217; virtual
	      Error Log indicator if the partition in which the OS resides abnormally
	      terminates.</para>
	    </section>

	    <section xml:id="dbdoclet.50569347_95432">
	      <title>Service Focal Point (SFP) and Service Partition</title>
	      <para>The
	      <emphasis>Service Focal Point</emphasis> (SFP), when it exists, will
	      ultimately be the exclusive common point of control in the system for
	      handling all service actions which are not resolved otherwise (for
	      example, via Fault indicators). It interfaces with the error log where
	      all the serviceable events are stored from the various OS and service
	      processor diagnostics. The SFP, among other things, allows resetting of
	      the Error Log light by the user, allows controlling the activation and
	      deactivation of the FRU, connector, and Enclosure Identify indicators,
	      and allows the clearing of the service actions in the error log.</para>
	      <para>The SFP shares access to some of the same indicators as one or more
	      OS images, but needs access to the physical indicator state, and
	      sometimes the state of all the virtual indicators for that physical
	      indicator. If the SFP in a partitioned system were to be implemented on
	      an OS image that runs non-trusted applications, then the SFP partition
	      could not be given access to the physical and other OS&#8217; virtual
	      service indicators, or covert storage channels would exist (see
	      <xref linkend="dbdoclet.50569347_55025" />) between the SFP partition and
	      the other OS partitions. This architecture assumes that the SFP is
	      implemented as trusted or
	      <emphasis>privileged</emphasis> entity which does not allow non-trusted
	      applications running on the same OS image as the SFP, and therefore
	      covert storage channels are not considered to exist between the
	      SFP&#8217;s privileged OS image and other OS images in the system.</para>
	      <para>The SFP may also be implemented on as a separate entity from the
	      one being monitored. A system management entity like an HMC interfacing
	      to the platform via firmware interfaces, or an external system management
	      entity, are examples of such implementations.</para>
	      <para>For Lightpath Mode, the Triple-S UI is a user interface that is
	      associated with a SFP. See
	      <xref linkend="dbdoclet.50569347_88196" />.</para>
	      <para>The platform&#8217;s physical indicators are accessible to the SFP
	      through the normal indicator interface (LoPAR indicator types 9006 and
	      9007).</para>
	    </section>

	    <section>
	      <title>Logical Indicators vs. Physical Indicators</title>
	      <para>A physical indicator is, in many cases, used to represent several
	      logical and/or virtual indicators. For example, a physical FRU indicator
	      can be used in Lightpath Mode to represent both a FRU Identify indicator
	      and a FRU Fault indicator.</para>
	      <para>The hardware/firmware that implements the physical
	      indicator&#8217;s state machine is the entity which knows about the
	      combining of the logical and virtual into the physical, and higher level
	      software (OS and applications) that are given control of a logical or
	      virtual indicator are only aware of the control of that logical or
	      virtual indicator, and may not be even able to sense the state of the
	      physical indicator (that is, can only sense the state of their logical or
	      virtual ones).</para>
	      <para>The physical indicator state diagrams in
	      <xref linkend="dbdoclet.50569347_69815" /> indicate how logical and
	      virtual indicators are merged into the physical ones. See also
	      <xref linkend="dbdoclet.50569347_55025" /> relative to virtual
	      indicators.</para>
	    </section>
    </section>

    <section xml:id="dbdoclet.50569347_82731">
      <title>Machine Classes and Service Strategy</title>
      <para>Two broad classifications of computer implementations are defined
      here for purposes of defining service indicator implementations.
      <xref linkend="dbdoclet.50569347_67562" /> shows the comparison of these
      classes.</para>
      <para>&#160;</para>
      <table frame="all" pgwide="1" xml:id="dbdoclet.50569347_67562">
        <title>Machine Classifications and Service
        Characteristics</title>
        <?dbhtml table-width="75%" ?>
        <?dbfo table-width="75%" ?>
        <tgroup cols="3">
          <colspec colname="c1" colwidth="33*" align="center" />
          <colspec colname="c2" colwidth="33*" align="center" />
          <colspec colname="c3" colwidth="33*" align="center" />
          <thead>
            <row>
              <entry>
                <para>
                  <emphasis role="bold">Characteristic</emphasis>
                </para>
              </entry>
              <entry>
                <para>
                  <emphasis role="bold">Simple Class</emphasis>
                </para>
              </entry>
              <entry>
                <para>
                  <emphasis role="bold">Complex Class</emphasis>
                </para>
              </entry>
            </row>
          </thead>
          <tbody valign="middle" >
            <row>
              <entry>
                <para>Number of FRUs</para>
              </entry>
              <entry>
                <para>Few</para>
              </entry>
              <entry>
                <para>Many</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Servicing performed by</para>
              </entry>
              <entry>
                <para>Customer, generally</para>
              </entry>
              <entry>
                <para>CE more than customer</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Deferred maintenance</para>
              </entry>
              <entry>
                <para>Very little</para>
              </entry>
              <entry>
                <para>Enabled as much as possible
                <footnote xml:id="pgfId-667002">
                  <para>Deferred maintenance is one of the big drivers towards
                  use of Guiding Light mode or Lightpath Mode with Triple-S.
                  That is, having many Fault indicators active at one time
                  (FRUS waiting for service actions) can lead to confusion when
                  service is being performed.</para>
                </footnote></para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Concurrent maintenance</para>
              </entry>
              <entry>
                <para>Generally limited to redundant components (fans, power
                supplies) and I/O devices</para>
              </entry>
              <entry>
                <para>Generally a higher level of concurrent maintenance</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Value of a FRU Fault indicator</para>
              </entry>
              <entry>
                <para>High</para>
              </entry>
              <entry>
                <para>Questionable value due to complexity of the system</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>FRU Fault indicator implementation</para>
              </entry>
              <entry>
                <para>Realistic</para>
              </entry>
              <entry>
                <para>Complex, given the higher level of deferred and
                concurrent maintenance</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Console interface</para>
              </entry>
              <entry>
                <para>Rare</para>
              </entry>
              <entry>
                <para>Standard</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Platform service mode</para>
              </entry>
              <entry>
                <para>Lightpath Mode platform</para>
              </entry>
              <entry>
                <para>Guiding Light Mode platform</para>
                <para>or</para>
                <para>Lightpath Mode with Triple-S UI</para>
              </entry>
            </row>
          </tbody>
        </tgroup>
      </table>

      <para>Determining whether a platform&#8217;s classification, and
      therefore the service mode of the platform is dependent on the product
      requirements, and is beyond the scope of this architecture, but might
      include:</para>

			<itemizedlist>
			  <listitem>
          <para>The RAS requirements for the platform. The considerations for
          this come from
          <xref linkend="dbdoclet.50569347_67562" />.</para>
			  </listitem>

			  <listitem>
          <para>The mixture of machines expected in the environment. Although the
          Lightpath Mode and the Guiding Light Mode both contain the identify
          capability, and that could be considered to be the common denominator in
          servicing in a mixed environment, it could be that there are more
          Lightpath Mode platforms in the environment for which a new platform
          design is targeted, and therefore it might be desirable to make that new
          platform&#8217;s mode of operation be the Lightpath Mode for that
          reason.</para>
			  </listitem>
			</itemizedlist>

    </section>
    <section>
      <title>General Information about Service Indicators</title>
      <para>Indicators may serve multiple uses, but only as defined by this
      architecture. For example, a physical indicator used for a FRU is used
      for both the FRU Fault and FRU Identify indicators. Non-architected
      usages of an architected indicator are specifically disallowed by this
      architecture.</para>
      <para>In some cases, an indicator may not be visible directly by the user
      without removing covers, components, etc. In this case, there is required
      to be one or more indicators that are higher in the hierarchy which get
      activated in conjunction with the target indicator. This functionality is
      called indicator
      <emphasis>roll-up</emphasis>. Due to the hierarchy, there might be
      multiple indicators that get rolled-up into a single indicator. The
      platform (not the OS) is responsible for indicator roll-up. An example of
      a roll-up is that on the front of an enclosure
      <footnote xml:id="pgfId-634084">
        <para>Note that the enclosure is sometimes called the
        &#8220;unit,&#8221; but a unit is not necessarily a drawer and a drawer
        is not necessarily a unit, so the term &#8220;unit&#8221; is not be
        used here. Also note that an enclosure might be a drawer in a rack or
        might be part of a drawer. For example, some I/O drawers consist of two
        separate and independent enclosures. So, sometimes there may be
        multiple enclosure indicators per rack drawer. See also
        <xref linkend="dbdoclet.50569347_12130" />.</para>
      </footnote>in a rack there is a summary LED that summarizes the Identify
      LEDs within or on the back of the enclosure in a rack, and then the
      multiple enclosure summary LEDs are summarized at the rack level with a
      light on the top of the rack. Another example of a roll-up indicator is
      the Enclosure Fault indicator on each enclosure in Lightpath Mode
      platforms, which summarizes the Fault indicators within the enclosure.
      These roll-up indicators are transparent to the OS, and sometimes to the
      firmware, with the exception that the enclosure level Identify indicators
      (or virtual versions thereof, in the case of partitioned systems) may be
      accessible to the OS via the 9007 indicator type. The indicators that are
      provided for roll-up from FRU to enclosure to rack are identified by this
      architecture. Platforms may have unique indicators which are not visible
      to the OS and which are not defined by this architecture. These will not
      share the same indicator as used by one of the indicators which is
      architected, including indicators in the roll-up path, except as
      explicitly allowed by the architectural requirements in this
      architecture. In addition to the roll-up to a higher level indicator for
      visibility, the platform may also provide duplicate indicators for some
      of the indicators. For example, there may be a front and rear indicator
      for the enclosure indicators. These duplicate indicators are not defined
      by this architecture except that as for roll-up indicators, the platform
      is responsible for controlling any duplicate indicators and for not
      making the duplicates visible to the controlling entities. Finally, FRU
      indicators are required to be visible to the user during a service
      action. This may require, for example, that the indicator be able to be
      lit after power is removed from the system, requiring storage of power on
      the component with the indicator (for example, via a capacitor) and
      activation of the indicators by a push button by the user.</para>
      <para>An OS image is given access to the FRU Identify indicators when the
      OS image fully owns the resources, and is given access to the Enclosure
      Identify indicator for any enclosure in which the OS image fully owns any
      resource. An OS image is given access to the FRU Fault indicators when
      the OS image owns all or part of the FRU. The Enclosure Fault indicators
      are roll-up only indicators and access to these indicators are not given
      to the OS.</para>
      <para>In a partitioned system (logical or physical), there may be several
      virtual Enclosure Identify indicators and one physical Enclosure Identify
      indicator. In this case, the OS images are only given access to their
      copy of the virtual Enclosure Identify indicator, and do not have direct
      access to the physical Enclosure Identify indicator. Activating any
      virtual Enclosure Identify indicator which is associated with an
      enclosure activates the physical one for that drawer (if not already
      activated). Turning off the last virtual Enclosure Identify indicator for
      an enclosure turns off the physical one for that enclosure, providing all
      other Identify indicators in the enclosure are also off. If software in a
      partition senses the state of the virtual Enclosure Identify indicator,
      it needs to take into consideration that it may be seeing the virtual
      state and not the real state of the indicator, with the virtual state
      being what the partition set the indicator to, and this is not
      necessarily what the physical indicator is actually displaying.</para>
      <para>The Error Log indicator is located on the System Enclosure (the CEC
      enclosure) and is used to indicate that there was a failure in the
      system. This indicator may also be used by the system to indicate that
      some other attention is needed in the system. This Error Log indicator is
      the starting point for the determination of the necessary action by the
      user.</para>
      <para>In a partitioned system (logical or physical), there may be several
      virtual Error Log indicators and one physical Error Log indicator.
      Activating a virtual Error Log indicator activates the physical one.
      Turning off the last virtual Error Log indicator turns off the physical
      one. If software in a partition senses the state of the Error Log
      indicator, it needs to take into consideration that it may be seeing the
      virtual state and not the real state of the indicator, with the virtual
      state being what the partition set the indicator to, and this is not
      necessarily what the physical indicator is actually displaying.</para>
      <para>For Guiding Light Mode platforms, the FRU Identify indicators are
      the primary method for pointing to failing FRUs. For Lightpath Mode
      platforms, it is expected that the FRU Identify indicators will be used
      as a secondary assistance for FRU fault identification (the FRU Fault
      indicators being the primary). In both cases, the FRU Identify indicators
      can be used to assist with such things as identifying where an upgrade
      should be inserted.</para>
      <para>The general rules for activation and deactivation of indicators can
      be found in Requirements
      <xref linkend="dbdoclet.50569347_96910" /> and
      <xref linkend="dbdoclet.50569347_65011" />, and more explicit
      requirements of individual indicators in the state diagrams in
      <xref linkend="dbdoclet.50569347_69815" />. When the Triple-S UI is
      implemented, see also
      <xref linkend="dbdoclet.50569347_88196" />.</para>
      <para>This architecture assumes that the control of multiple users doing
      identify operations at the same time, is under procedural control, and is
      not handled or controlled in any way by this architecture, OS, or
      firmware.</para>
      <para>For Guiding Light Mode platforms, if a FRU contains a Fault
      indicator, then the Fault indicator is transparent to the OS and control
      of the FRU-level Fault indicator is entirely up to the FRU or to some
      OS-transparent method. For example, some power supplies contain a Fault
      indicator that does not get reported directly to the system controlling
      entity and which is turned off by a button on the power supply which is
      pushed when the service is complete.</para>
    </section>
    <section xml:id="dbdoclet.50569347_70115">
      <title>Secondary Light Panels</title>
      <para>A secondary light panel may be used to house roll-up indicators as
      indicated in the &#8220;intermediate&#8221; level or
      &#8220;secondary&#8221; level indicators in
      <xref linkend="dbdoclet.50569347_41855" /> and
      <xref linkend="dbdoclet.50569347_10334" />. These panels may also house
      other indicators which would otherwise not have a home (for example, an
      over-temperature indicator).</para>
      <para>Secondary light panels indicators are not to be used as replacement
      for FRU-level indicators. However, if an indicator is not directly
      visible when the unit is placed into the service position (for example,
      blocked by covers, baffles, cables, etc.), then the secondary light panel
      is one implementation to get around this restriction (other
      implementations may exist, for example light pipes, etc.).</para>
    </section>
    <section xml:id="dbdoclet.50569347_49927">
      <title>Group Identify Operation</title>
      <para>In some systems it may be desirable to identify a set of enclosures
      as being part of a group. This is called a group identify operation and
      can be performed by activating the appropriate Enclosure Identify
      indicators.</para>
      <para>For platform or systems that consist of multiple enclosures, it may
      be necessary to change the state of one enclosure before servicing
      another enclosure. For example, a system drawer (primary enclosure) may
      need to be powered down before servicing an I/O drawer (secondary
      enclosure). It may be useful in this case for the servicer to be able to
      identify the various enclosures that are linked. In such implementations,
      the enclosures should be designed with a method to activate the Group
      Identify function, with the &#8220;group&#8221; being all linked
      enclosures. One implementation of this is to put a pushbutton in
      proximity to the blue Enclosure Identify indicator, which is then used to
      activate the blue Enclosure Identify indicators of all connected
      enclosures, and subsequently to deactivate all of them. It is suggested
      that with this implementation of the Group Identify function, that this
      switch toggle the Group Identify function for this set of enclosures,
      with each push toggling the Group Identify function. If it takes awhile
      to activate all the blue Enclosure Identify indicators in the group, it
      may be useful to give the user feedback that the button has been pressed.
      One way to do this is to put the blue Enclosure Identify indicator next
      to the pushbutton into the blink state (momentarily) until all the other
      blue Enclosure Identify indicators in the group have been activated, and
      when that is complete, to put this indicator into the Identify state (on
      solid).</para>
    </section>

    <section>
      <title>System-Level Diagrams</title>
      <para>The following figures are conceptual diagrams showing indicator
      roll-ups:</para>

			<itemizedlist>
			  <listitem>
          <para><xref linkend="dbdoclet.50569347_41855" />.</para>
			  </listitem>

			  <listitem>
          <para><xref linkend="dbdoclet.50569347_10334" />.</para>
			  </listitem>

			  <listitem>
          <para><xref linkend="dbdoclet.50569347_69209" />.</para>
			  </listitem>
			</itemizedlist>


      <figure pgwide="1" xml:id="dbdoclet.50569347_41855">
        <title>Representation of the Indicators -- Lightpath Mode Platform</title>
        <mediaobject>
          <imageobject role="html">
            <imagedata fileref="figures/PAPR-34.gif" format="GIF"
            scalefit="1" />
          </imageobject>
          <imageobject role="fo">
            <imagedata contentdepth="100%" fileref="figures/PAPR-34.gif"
            format="GIF" scalefit="1" width="100%" />
          </imageobject>
        </mediaobject>
      </figure>

      <figure pgwide="1" xml:id="dbdoclet.50569347_10334">
        <title>Representation of the Indicators -- Guiding Light Mode Platform</title>
        <mediaobject>
          <imageobject role="html">
            <imagedata fileref="figures/PAPR-36.gif" format="GIF"
            scalefit="1" />
          </imageobject>
          <imageobject role="fo">
            <imagedata contentdepth="100%" fileref="figures/PAPR-36.gif"
            format="GIF" scalefit="1" width="100%" />
          </imageobject>
        </mediaobject>
      </figure>

      <figure pgwide="1" xml:id="dbdoclet.50569347_69209">
        <title>Representation of the Indicators -- Rack System</title>
        <mediaobject>
          <imageobject role="html">
            <imagedata fileref="figures/PAPR-37.gif" format="GIF"
            scalefit="1" />
          </imageobject>
          <imageobject role="fo">
            <imagedata contentdepth="100%" fileref="figures/PAPR-37.gif"
            format="GIF" scalefit="1" width="100%" />
          </imageobject>
        </mediaobject>
      </figure>
      <para><emphasis role="bold">Note:</emphasis> Guiding Light Mode platform shown,
      with optional Enclosure Fault indicators. For Lightpath Mode platforms,
      FRU Fault indicators would always exist and would roll up to the Enclosure
      Fault indicator, and additionally, the Rack and Row Identify indicators would
      have an additional Fault indicator (not shown) and the Fault indicators at the
      enclosure level would roll up to those.</para>
    </section>

  </section>

  <section xml:id="dbdoclet.50569347_24150">
    <title>Service Indicator Requirements</title>
    <para>Service indicators are required on all platforms.</para>

    <variablelist>
	  	<varlistentry>
	  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_24150"
				xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
	  			<listitem>
            <para>All platforms must implement either the
            Lightpath Mode or the Guiding Light Mode of service indicators, and all
            components and enclosures (the primary enclosure and any secondary
            enclosures (for example, I/O expansion drawers)) within the platform must
            be operating in the same mode.</para>
			    </listitem>
	  	</varlistentry>

	  	<varlistentry>
	  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_24150"
				xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
	  			<listitem>
            <para>Indicators defined by this architecture must
            not be used for any purpose other than is what is specified by this
            architecture, and only with the specific states defined by this
            architecture.</para>
			    </listitem>
	  	</varlistentry>
	  	<varlistentry>
	  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_24150"
				xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
	  			<listitem>
            <para>All platforms must provide the
            <emphasis role="bold"><literal>&#8220;ibm,service-indicator-mode&#8221;</literal></emphasis> property in
            the Open Firmware Device Tree root node.</para>
			    </listitem>
	  	</varlistentry>
	  </variablelist>


    <section xml:id="dbdoclet.50569347_83698">
      <title>Service Indicator General Requirements</title>
      <para>This section details requirements of indicators that are not
      specifically LoPAR indicator type 9006 or 9007 related. These are true
      even if the platform does not present any 9007 indicators to the OS. This
      includes requirements for platform actions like roll-up. For 9006 and
      9007 specific requirements, see
      <xref linkend="dbdoclet.50569347_84242" />.</para>
      <para>Requirements which are prefaced by
      &#8220;<emphasis role="bold">For Lightpath Mode platforms:</emphasis>&#8221;
      only apply to
      Lightpath Mode platforms. Requirements which are prefaced by
      &#8220;<emphasis role="bold">For Guiding Light Mode platforms:</emphasis>&#8221;
      only apply
      to Guiding Light Mode platforms. Requirements that are prefaced by
      neither, apply to both Lightpath Mode and Guiding Light Mode platforms.
      <emphasis>Components</emphasis> which are designed to work in both
      Lightpath Mode and Guiding Light Mode platforms, need to be able to
      comply with both Lightpath Mode and Guiding Light Mode sets of
      requirements, as well as the requirements that apply to all.</para>

      <section xml:id="fault_detection_pd">
        <title>Fault Detection and Problem Determination
        Requirements</title>
        <para>There are two general classifications of problems which are
        indicated by Service Indicators:</para>

  			<itemizedlist>
  			  <listitem>
            <para>An indication for FRUs that have failed and need to be
            replaced</para>
  			  </listitem>

  			  <listitem>
            <para>An indication of other system problems that may be causing
            performance degradation or which might cause failures in the future, for
            example:</para>

  					<itemizedlist>
  					  <listitem>
                <para>A FRU that is predicted to fail (may be treated as a failing FRU
                by some implementations)</para>
  					  </listitem>

  					  <listitem>
                <para>An over temperature conditions</para>
  					  </listitem>

  					  <listitem>
                <para>A loss of redundancy that is not caused directly by a FRU failure
                (for example, greater than 100% of the power of the base power being
                used)</para>
  					  </listitem>

  					  <listitem>
                <para>A configuration problem such as a missing resource, resource
                plugged into the wrong slot, or invalid configuration</para>
  					  </listitem>
  					</itemizedlist>
  			  </listitem>
  			</itemizedlist>

        <para>The general model for use of the Error Log
        <footnote xml:id="pgfId-667296">
          <para>Previously called the System Information (Attention)
          indicator.</para>
        </footnote>and Enclosure Fault indicators is to indicate problems as
        follows:</para>

  			<itemizedlist>
  			  <listitem>
            <para>Activation of either the Error Log or Enclosure Fault indicators
            is accompanied by a log entry in an error log that can be queried by the
            user</para>
  			  </listitem>

  			  <listitem>
            <para>Activation of the Error Log indicator is used when the user needs
            to perform some procedure, or acknowledge some condition, prior to taking
            corrective action</para>

  					<itemizedlist>
  					  <listitem>
                <para>For most types of problems, this requires the user to look into
                the error log at the start of the procedure</para>
  					  </listitem>

  					  <listitem>
                <para>In some cases (generally for more common or more urgent
                problems), additional indicators may be provided by a system and
                activated to allow the user to determine the problem without looking into
                the error log (these additional indicators are generally not allowed to
                be the same indicators as defined by this architecture, except as allowed
                by this architecture)</para>
  					  </listitem>

  					  <listitem>
                <para>The procedure performed by the user may include items
                like:</para>

      					<itemizedlist>
      					  <listitem>
                    <para>Activation of FRU Identify indicators (for example, as in Guiding
                    Light Mode systems)</para>
      					  </listitem>

      					  <listitem>
                    <para>Removal and re-connection of cables, reseating of cards,
                    etc.</para>
      					  </listitem>
      					</itemizedlist>
  					  </listitem>
  					</itemizedlist>
  			  </listitem>

  			  <listitem>
            <para>Activation of an Enclosure Fault (Lightpath Mode systems) is only
            allowed in the following cases:</para>
  					<itemizedlist>
  					  <listitem>
                <para>As an indication of the roll-up of a FRU Fault indicator</para>
  					  </listitem>

  					  <listitem>
                <para>In conjunction with a system error that prevents a FRU Fault
                indicator from being activated (this requires some other indication of
                the global failure problem, for example, an error code on an op
                panel)</para>
  					  </listitem>
  					</itemizedlist>
  			  </listitem>
  			</itemizedlist>

        <para>The following requirements define the actions to be taken by a
        system on the detection of a fault.</para>

  	    <variablelist>
  		  	<varlistentry xml:id="dbdoclet.50569347_86824">
  		  		<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>The detector of a fault condition must do the following:</para>

          			<itemizedlist>
          			  <listitem xml:id="dbdoclet.50569347_67687">
                    <para>If the a fault
                    occurs which cannot be isolated appropriately without the user performing
                    some procedure, then activate the Error Log indicator.</para>
          			  </listitem>

          			  <listitem xml:id="dbdoclet.50569347_99028">
                    <para>If a fault occurs
                    which can be isolated to a single FRU and if there exists a Fault
                    indicator for the FRU, then activate that FRU Fault indicator, otherwise
                    activate the Error Log indicator.</para>
          			  </listitem>

          			  <listitem xml:id="dbdoclet.50569347_76215">
                    <para>If a fault occurs
                    which cannot be isolated to a single FRU and if there exists a Fault
                    indicator for the most likely FRU in the FRU list, then activate that FRU
                    Fault indicator, otherwise activate the Error Log indicator.</para>
          			  </listitem>

          			  <listitem xml:id="dbdoclet.50569347_27853">
                    <para>If a fault occurs
                    which is isolated to a group of FRUs (called a FRU group) and if there
                    exists a Fault indicator for each of the FRUs, then activate all the FRU
                    Fault indicators, otherwise activate the Error Log indicator.</para>
          			  </listitem>
          			</itemizedlist>

                <para>See also,
                <xref linkend="dbdoclet.50569385_36278" />.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para><emphasis>(Requirement Number Reserved For
                Compatibility)</emphasis></para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_96910">
  		  		<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
  					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
  		  			<listitem>
                <para>Service Indicators (Error Log, Fault, and Identify) must be activated
                appropriately to guide a user to or through a service action or
                procedure.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_65011">
  		  		<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
  					xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
  		  			<listitem>
                <para>Service Indicators (Error Log, Fault, and Identify) must be deactivated
                appropriately, as follows:</para>

          			<orderedlist numeration="loweralpha">
          			  <listitem>
                    <para>A Service Indicator activated by an entity must be automatically
                    deactivated by that entity when that entity can determine that the
                    activation is no longer necessary, or</para>
          			  </listitem>

          			  <listitem>
                    <para>A Service Indicator must be automatically deactivated by the
                    platform when the platform can determine that the activation is no longer
                    necessary or may be necessary but will be redetected and therefore
                    reactivated a reasonable time later, or</para>
          			  </listitem>

          			  <listitem>
                    <para>A Service Indicator must be automatically deactivated by a
                    service procedure which fixes the issue that caused the indicator to be
                    automatically activated in the first place, or</para>
          			  </listitem>

          			  <listitem>
                    <para>A Error Log or Identify indicator must be deactivated when a
                    user request it to be deactivated by a system-level user
                    interface.</para>
          			  </listitem>

          			  <listitem>
                    <para>For the Lightpath UI Base Enablement, as indicated in
                    Requirement
                    <xref linkend="dbdoclet.50569347_68068"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_17117"
                    xrefstyle="select: labelnumber"/> and
                    <xref linkend="dbdoclet.50569347_43836"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_37801"
                    xrefstyle="select: labelnumber"/>.</para>
          			  </listitem>
          			</orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_17215">
  		  		<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
  					xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
  		  			<listitem xml:id="dbdoclet.50569347_17215_text">
                <para>For each
                activation of the Error Log and Enclosure Fault Indicators, one of the
                following must be true:</para>

          			<orderedlist numeration="loweralpha">
          			  <listitem xml:id="dbdoclet.50569347_39541">
                    <para>If the platform
                    is functional enough to allow it, then an associated entry must be made
                    in an error log that can be queried by a user interface.</para>
          			  </listitem>

          			  <listitem xml:id="dbdoclet.50569347_22743">
                    <para>In the case where
                    the platform is not functional enough to allow logging of an error log
                    entry, then there must exist a way for the user to determine the failure
                    associated with the indicator activation (for example, an error code on
                    an op panel on the system).</para>
          			  </listitem>
          			</orderedlist>

                <para>
                  <emphasis role="bold">Implementation Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>Requirement
                    <xref linkend="dbdoclet.50569347_65011" /> are intentionally written
                    general enough so that different platform types have some latitude in
                    implementation of Service Indicators. However, see the state diagrams,
                    <xref linkend="dbdoclet.50569347_69815" />, for some explicit
                    requirements for activation and deactivation of the various Service
                    Indicators. Those state diagrams take precedence over Requirement
                    <xref linkend="dbdoclet.50569347_65011" />. When the state diagrams and
                    Requirement
                    <xref linkend="dbdoclet.50569347_65011" /> do not give explicit direction
                    for implementation, implementers should consider compatibility with
                    existing implementations when making decisions about activation and
                    deactivation.</para>
                  </listitem>

                  <listitem>
                    <para>2. In Requirement
                    <xref linkend="dbdoclet.50569347_65011" />, the physical indicator may
                    not be turned off when deactivated from an OS interface (versus a
                    system-level interface), if another entity outside of that OS also has
                    the physical indicator activated. That is, if the physical indicator is
                    the combination of several logical indicators.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_38463">
  		  		<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
  					xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
  		  			<listitem>
                <para xml:id="dbdoclet.50569347_38463_text">The Error Log
                indicator must be activated only for Serviceable Events. Serviceable
                Events are platform, global, regional and local error events that require
                a service action and possibly a call home when the serviceable event must
                be handled by a service representative or at least reported to the
                service provider. Activation of the Error Log indicator notifies the
                customer of the event and the event indicates to the customer that there
                must be some intervention to rectify the problem. The intervention may be
                a service action that the customer can perform or it may require a
                service provider.</para>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="fru-level_connector_indicator">
        <title>FRU-Level and Connector Indicator Requirements</title>
        <para>The indicators specified in this section represent the lowest level
        indicators in the indicator roll-up hierarchy.</para>
        <para>See also requirements in
        <xref linkend="dbdoclet.50569347_71852" />.</para>
        <para>For the Lightpath UI, see also the requirements in
        <xref linkend="dbdoclet.50569347_88196" />.</para>

  	    <variablelist>
  		  	<varlistentry xml:id="dbdoclet.50569347_82786">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For Lightpath Mode platforms:</emphasis>
                All of the following must be true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>A FRU Fault indicator must be implemented for every replaceable
                    FRU, with the states of &#8220;off&#8221; and &#8220;on,&#8221; except
                    for FRUs which are excepted in Requirement
                    <xref linkend="dbdoclet.50569347_79405" />.</para>
                  </listitem>

                  <listitem>
                    <para>Clearing of the FRU Fault indicator from the Fault state must be
                    the result of part of the repair action and must be transparent to the
                    OS(s) and SFP (that is, the OS or SFP is not required to automatically
                    clear a FRU Fault indicator).</para>
                  </listitem>

                  <listitem>
                    <para>The physical indicator which implements the FRU Fault indicator
                    must also be Identify indicator and follow the requirements for Identify
                    indicators.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_69299">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para>FRU indicators
                (Fault and Identify) must be visible to the user during a service
                action.</para>
                <para>
                <emphasis role="bold">Implementation Note:</emphasis> Requirement
                <xref linkend="dbdoclet.50569347_69299" /> may require, for example, that
                the indicator be able to be lit after power is removed from the system,
                requiring storage of power on the component with the indicator (for
                example, via a capacitor) and activation of the indicators by a push
                button by the user (see Requirement
                <xref linkend="dbdoclet.50569347_66721" /> for requirements on this
                implementation). Another example would be via the use of a light pipe
                from the indicator to a visible place.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_90666">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For Guiding Light Mode platforms:</emphasis>
                If a FRU Fault
                indicator exists, then it must be transparent to the OS, SFP, and HMC and
                it must be independent of, and not physically combined into the same
                indicator with, any indicator defined by this architecture, including the
                setting of, resetting of, and displaying of the state of that indicator,
                except that a FRU Identify indicator may be activated to the Fault state
                (on solid) as a result of a FRU failure if all of the following are
                true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The failure that is being indicated must be a failure which
                    prevents the user from activating the said FRU Identify indicator to the
                    Identify state.</para>
                  </listitem>

                  <listitem>
                    <para>Clearing of the FRU Fault indicator must be the result of part
                    of the repair action and must be transparent to the OS, SFP, and
                    HMC.</para>
                  </listitem>
                </orderedlist>

                <para>
                  <emphasis role="bold">Architecture Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>For Guiding Light Mode platforms, the only FRU-level indicators
                    that are allowed to be visible to an OS, SFP, or HMC are the FRU Identify
                    indicators.</para>
                  </listitem>

                  <listitem>
                    <para>For Guiding Light Mode platforms, the only Fault indicator that
                    is allowed to be visible to an OS, SFP, or HMC is the Error Log
                    indicator.</para>
                  </listitem>

                  <listitem>
                    <para>Examples of the exception of the use of FRU and enclosure
                    indicators in Requirement
                    <xref linkend="dbdoclet.50569347_90666" /> as an indication of a fault
                    are: when the path for controlling an Enclosure Identify indicator or FRU
                    indicator in that enclosure is broken, or when the power supply in the
                    enclosure is broken and the indicator cannot be activated to the Identify
                    state. In these cases the FRU and/or enclosure indicators may be
                    activated (transparently) to the Fault state to indicate the failure, and
                    would be returned to the Normal state as a result of the repair action
                    that fixes the problem.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_79405">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
  		  			<listitem>
                <para>All platforms
                designs, except very low end servers,
                <footnote xml:id="pgfId-631249">
                  <para>The term &#8220;very low end servers&#8221; is not explicitly
                  defined here, but is used to refer to implementations where FRU-level
                  indicators cannot reasonably be implemented (for example, due to size
                  constraints) or where the product can show explicit financial
                  justification for not implementing.</para>
                </footnote>must include an Identify indicator for every FRU with the
                states of &#8220;off&#8221; and &#8220;blink,&#8221; except for the
                following classes of FRUs:</para>

                <orderedlist numeration="loweralpha">
                  <listitem xml:id="dbdoclet.50569347_44198">
                    <para>If a device
                    driver has access to some standard form of Identify/Fault indicators for
                    the DASD devices it controls (for example, some standard form of
                    enclosure services), then the platform does not need to provide FRU
                    indicators for these devices.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_45076">
                    <para>If a device
                    driver has access to some standard form of Identify/Fault indicators for
                    the removable media devices it controls (for example, some standard form
                    of enclosure services), then the platform does not need to provide FRU
                    indicators for these devices.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_33549">
                    <para>External
                    enclosures other than PCI expansion enclosures, and external devices (for
                    example, keyboard, mice, tablets) that attach via cable to IOAs, do not
                    require FRU indicators.</para>
                  </listitem>

                  <listitem>
                    <para>Cables that connect from IOAs to the devices defined in parts
                    <xref linkend="dbdoclet.50569347_44198"	xrefstyle="select: labelnumber nopage"/>,
                    <xref linkend="dbdoclet.50569347_45076"	xrefstyle="select: labelnumber nopage"/>, and
                    <xref linkend="dbdoclet.50569347_33549"	xrefstyle="select: labelnumber nopage"/>
                    of this requirement do not require FRU indicators.</para>
                  </listitem>

                  <listitem>
                    <para>Internal cables, interposers, and other FRUs which do not
                    contain active components do not require FRU indicators.</para>
                  </listitem>
                </orderedlist>

                <para>
                <emphasis role="bold">Implementation Note:</emphasis> Even though an item falls into
                the list of possible exceptions in Requirement
                <xref linkend="dbdoclet.50569347_79405" />, the designer of such a
                component should verify that leaving off the FRU Identify indicator from
                their component will not prevent the systems in which that component is
                used from meeting their serviceability requirements.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_53442">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
  		  			<listitem>
                <para>All FRU-level
                Identify indicators must implement the state diagram shown in
                <xref linkend="dbdoclet.50569347_53936" />, except that the Fault state
                is not required for Guiding Light Mode platforms.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_58940">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
  		  			<listitem>
                <para>All platforms
                must include an Identify indicator with the states of &#8220;off&#8221;
                and &#8220;blink&#8221; for every connector that is to be involved in an
                Identify operation.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_24444">
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
  		  			<listitem>
                <para>FRU-level and
                connector-level indicators must be made visible to the OS(s) as follows,
                and must be made transparent otherwise:</para>

                <orderedlist numeration="loweralpha">
                  <listitem xml:id="dbdoclet.50569347_39945">
                    <para><emphasis role="bold">For Lightpath Mode platforms:</emphasis> FRU Fault indicators
                    must be made visible to the OS for FRUs for which the OS image is
                    expected to detect errors for either the entire FRU or part of the
                    FRU.</para>
                  </listitem>

                  <listitem>
                    <para>FRU Identify indicators must be made visible to the OS for FRUs
                    that are fully owned by the OS image.</para>
                  </listitem>

                  <listitem>
                    <para>Connector Identify indicators must be made visible to the OS for
                    connectors that are fully owned by the OS image and for which a connector
                    Identify indicator exists.</para>
                  </listitem>
                </orderedlist>

                <para>
                  <emphasis role="bold">Implementation Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>In Requirement <xref linkend="dbdoclet.50569347_24444"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_39945"
                    xrefstyle="select: labelnumber"/>, for FRU Fault indicators that
                    are shared, the FRU Fault indicator is virtualized, so that one partition
                    cannot view the setting by another partition, which would allow a covert
                    storage channel (see also
                    <xref linkend="dbdoclet.50569347_55025" /> and
                    <xref linkend="dbdoclet.50569347_87607" />).</para>
                  </listitem>

                  <listitem>
                    <para>Ownership of a FRU or connector by the OS image is defined as
                    being the condition of the FRU or connector being under software control
                    by the OS, a device driver associated with the OS, or application
                    software running on the OS.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
  		  			<listitem>
                <para>An OS which activates a FRU Identify
                indicator must provide a method of deactivating that indicator.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
  					xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
  		  			<listitem>
                <para><emphasis>(Requirement Number Reserved For
                Compatibility)</emphasis></para>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="enclosure-level_indicator">
        <title>Enclosure-Level Indicator Requirements</title>
        <para>See also requirements in
        <xref linkend="dbdoclet.50569347_71852" />.</para>
        <para>For the Lightpath UI, see also the requirements in
        <xref linkend="dbdoclet.50569347_88196" />.</para>

  	    <variablelist>
  		  	<varlistentry xml:id="dbdoclet.50569347_11464">
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">On the System Enclosure:</emphasis>
                The platform must
                implement an Error Log indicator and all of the following must be
                true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The states of &#8220;off&#8221; and &#8220;on&#8221; must be
                    implemented and must be used for the Error Log function</para>
                  </listitem>

                  <listitem>
                    <para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis>
                    </para>
                  </listitem>

                  <listitem>
                    <para>This indicator must roll-up to the rack indicator, when the rack
                    indicator is implemented, and for blade implementations, to the Chassis
                    Error Log indicator.</para>
                  </listitem>

                  <listitem>
                    <para>The indicator must implement the state diagram shown in
                    <xref linkend="dbdoclet.50569347_44018" />.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_11464_e">
                    <para>The platform must provide a mechanism to allow the user to put
                    the Error Log indicator into the off state.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para>Except for enclosures that contain only
                FRUs that are exempted from FRU-level indicators as specified by
                Requirement
                <xref linkend="dbdoclet.50569347_79405" /> parts
                <xref linkend="dbdoclet.50569347_44198" />,
                <xref linkend="dbdoclet.50569347_45076" />, and
                <xref linkend="dbdoclet.50569347_33549" />, and which also do not have
                any Connector Identify indicators, the platform must implement an
                Enclosure Identify indicator on all enclosures, and all the following
                must be true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The states of &#8220;off,&#8221; &#8220;blink,&#8221; and
                    &#8220;on&#8221; must be implemented and must be used for the Identify
                    function.</para>
                  </listitem>

                  <listitem>
                    <para>This indicator must roll-up to the rack indicator, when the rack
                    indicator is implemented, and for blade implementations, to the Chassis
                    Enclosure Identify indicator.</para>
                  </listitem>

                  <listitem>
                    <para>The indicator must implement the state diagrams shown in
                    <xref linkend="dbdoclet.50569347_91006" /> and
                    <xref linkend="dbdoclet.50569347_27197" />.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_24076">
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For Lightpath Mode Platforms:</emphasis> All the following must
                be true for the Enclosure Fault indicator:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The platform must implement an Enclosure Fault indicator on each
                    enclosure in which there exists at least one FRU Fault indicator.</para>
                  </listitem>

                  <listitem>
                    <para>These indicators must implement the states of &#8220;off,&#8221;
                    &#8220;on,&#8221; and &#8220;blip&#8221;.</para>
                  </listitem>

                  <listitem>
                    <para>These indicators must implement the state diagram as shown in
                    <xref linkend="dbdoclet.50569347_59067" />.</para>
                  </listitem>

                  <listitem>
                    <para>These indicators must not be visible to any OS image.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_66944">
                    <para>The platform must
                    provide a mechanism to allow the user to put each Enclosure Fault
                    indicator into the blip state.</para>
                  </listitem>

                  <listitem>
                    <para>This indicator must roll-up to the rack indicator, when the rack
                    indicator is implemented, and for blade implementations, to the Chassis
                    Enclosure Fault indicator.</para>
                  </listitem>
                </orderedlist>


                <para>
                <emphasis role="bold">Implementation Note:</emphasis> One way of achieving Requirement
                <xref linkend="dbdoclet.50569347_24076"
                xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_66944"
                xrefstyle="select: labelnumber"/> is to provide a pushbutton (for
                example, on the secondary indicator panel).</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
  		  			<listitem>
                <para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
  		  			<listitem>
                <para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_97774">
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
  		  			<listitem>
                <para>Enclosure-level
                indicators must be made visible to the OS(s) as follows, and must be made
                transparent otherwise:</para>

                <orderedlist numeration="loweralpha">
                  <listitem xml:id="dbdoclet.50569347_73505">
                    <para>Enclosure
                    Identify indicators must be made visible to the OS when the OS fully owns
                    a FRU in the enclosure.</para>
                  </listitem>

                  <listitem>
                    <para>The Error Log indicator must be made visible to each OS image.</para>
                  </listitem>
                </orderedlist>

                <para>
                  <emphasis role="bold">Implementation Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>In Requirement
                    <xref linkend="dbdoclet.50569347_97774" />, for indicators that are
                    shared, the indicator is virtualized, so that one partition cannot view
                    the setting by another partition, which would allow a covert storage
                    channel (see also
                    <xref linkend="dbdoclet.50569347_55025" /> and
                    <xref linkend="dbdoclet.50569347_87607" />).</para>
                  </listitem>

                  <listitem>
                    <para>Ownership of a FRU by the OS image is defined as being the
                    condition of the FRU being under software control by the OS, a device
                    driver associated with the OS, or application software running on the
                    OS.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_44224">
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
  		  			<listitem>
                <para>An OS which
                activates an Error Log indicator must provide a method of deactivating
                that indicator, when such an activation is not be deactivated
                automatically as part of the service action.</para>
                <para>

                <emphasis role="bold">Implementation Note:</emphasis> Relative to Requirement
                <xref linkend="dbdoclet.50569347_44224" />, it is recommended that an OS
                that activates an Error Log indicator, provide a way to deactivate that
                indicator, regardless of whether that indicator would be reset as part of
                a service action.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
  		  			<listitem>
                <para>An OS which activates an Enclosure
                Identify indicator must provide a method of deactivating that
                indicator.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
  		  			<listitem>
                <para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For Guiding Light Mode Platforms:</emphasis> If a FRU Fault
                indicator exists, then it must not roll-up to the Enclosure Identify or
                Error Log indicator, and if there is such a requirement to roll-up such
                an indicator, then the enclosure must implement an Enclosure Fault
                indicator, with the same requirements as the Enclosure Fault indicator
                for Lightpath Mode platforms.</para>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="rack-level_indicator">

        <title>Rack-Level Indicator Requirements</title>

        <para>See also requirements in
        <xref linkend="dbdoclet.50569347_71852" />.</para>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="rack-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>If a platform implements a rack-level
                indicator then all of the following must be true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The rack indicator must be transparent to the OS, SFP, and
                    HMC.</para>
                  </listitem>

                  <listitem>
                    <para>The rack indicator must be Highly visible
                    <footnote xml:id="pgfId-629945">
                      <para>As defined by our usability groups</para>
                    </footnote>(distance and viewing angle) with covers in place.</para>
                  </listitem>

                  <listitem>
                    <para><emphasis role="bold">For Lightpath Mode:</emphasis> The rack tower indicator must
                    implement the state diagram indicated in
                    <xref linkend="dbdoclet.50569347_22016" />,
                    <xref linkend="dbdoclet.50569347_71112" />, and
                    <xref linkend="dbdoclet.50569347_15206" />.</para>
                  </listitem>

                  <listitem>
                    <para><emphasis role="bold">For the Guiding Light Mode:</emphasis> The rack tower indicator
                    must implement the state diagram indicated in
                    <xref linkend="dbdoclet.50569347_22016" />,
                    <xref linkend="dbdoclet.50569347_15206" />, and if the optional Enclosure
                    Fault indicators are implemented, then
                    <xref linkend="dbdoclet.50569347_71112" />.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="row-level_indicator">
        <title>Row-Level Indicator Requirements</title>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="row-level_indicator"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>If a system implements a row-level
                indicator to roll-up a row of rack-level indicators, then the following
                must be true for these indicators:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The indicator must be transparent to the OS, SFP, and
                    HMC.</para>
                  </listitem>

                  <listitem>
                    <para><emphasis role="bold">For Lightpath Mode:</emphasis> This indicator must implement the
                    state diagram indicated in
                    <xref linkend="dbdoclet.50569347_46164" />,
                    <xref linkend="dbdoclet.50569347_44514" />, and
                    <xref linkend="dbdoclet.50569347_96374" />.</para>
                  </listitem>

                  <listitem>
                    <para><emphasis role="bold">For the Guiding Light Mode:</emphasis> This indicator must
                    implement the state diagram indicated in
                    <xref linkend="dbdoclet.50569347_46164" />,
                    <xref linkend="dbdoclet.50569347_96374" />, and if the optional Enclosure
                    Fault indicators are implemented, then
                    <xref linkend="dbdoclet.50569347_44514" />.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="dbdoclet.50569347_87607">
        <title>Shared Indicator (Multiple Partition System)
        Requirements</title>
        <para>To avoid covert storage channels (see
        <xref linkend="dbdoclet.50569347_55025" />), virtual indicators are
        required for physical indicators which are shared between OS
        images.</para>

  	    <variablelist>
  		  	<varlistentry xml:id="dbdoclet.50569347_80861">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_87607"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>If a physical
                indicator (Fault or Identify) is shared between more than one partition,
                all the following must be true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>Except where there is explicit trust between the partitions, the
                    platform must provide a separate virtual indicator to each non-trusted
                    partition for each shared physical indicator and must control the
                    physical indicator appropriately, as indicated in the state diagrams in
                    <xref linkend="dbdoclet.50569347_69815" />.</para>
                  </listitem>

                  <listitem>
                    <para>If software in a partition senses the state of the virtual
                    indicator, it must take into consideration that it is seeing the virtual
                    state and not the real state of the indicator, with the virtual state
                    being what the partition set the indicator to, and this is not
                    necessarily what the physical indicator is actually displaying.</para>
                  </listitem>

                  <listitem>
                    <para>The SFP must be given access (sense and set) to the physical FRU
                    level indicators, and the platform must clear all the corresponding
                    virtual indicators when physical indicator is cleared by the SFP.</para>
                  </listitem>

                  <listitem>
                    <para>The SFP must be given access (sense and set) to the physical
                    Error Log indicator, and the platform must not clear the corresponding
                    virtual indicators when physical indicator is cleared by the SFP.</para>
                 </listitem>
                </orderedlist>

                <para>
                  <emphasis>Architecture Note:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>In Requirement
                    <xref linkend="dbdoclet.50569347_80861" />, an example of &#8220;explicit
                    trust&#8221; is where the sharing partitions are the SFP and one other
                    partition, where the SFP is running in an OS where all the applications
                    and drivers can be trusted to not open a covert channel to the other OS
                    or application in that other partition.</para>
                  </listitem>

                  <listitem>
                    <para>In Requirement
                    <xref linkend="dbdoclet.50569347_80861" />, it may be possible for the
                    SFP to get direct access to the virtual indicators, but such access is
                    beyond the scope of this architecture.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="dbdoclet.50569347_71852">
        <title>Additional Indicator Requirements</title>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>A user interface which presents to a
                user the state of the Identify indicators or which allows the user to set
                the state of the Identify indicators, must be prepared for an indicator
                to disappear from the list of indicators available to the OS image (for
                example, a &#8220;no such indicator&#8221; response to a set request),
                and must provide the user with an appropriate message and recovery (for
                example, prompt the user whether they want to refresh the list of
                available indicators).</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para>The color of indicators must be as follows:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>FRU Identify, FRU Fault, Enclosure Fault, Error Log indicators,
                    and any roll-up indicators for Error Log (rack-level, blade system
                    chassis-level, and row-level) must be amber.</para>
                  </listitem>

                  <listitem>
                    <para>The Enclosure Identify indicators and any roll-up indicators for
                    these indicators (rack-level, blade system chassis-level, and row-level)
                    must be blue.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_81809">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
  		  			<listitem>
                <para>The blink rate of
                all Identify indicators which blink, must be nominally 2 Hz (minimum 1
                Hz) with a nominal 50% duty cycle.</para>
                <para>
                <emphasis role="bold">Implementation Note:</emphasis> The 1 Hz rate should not be used
                unless absolutely necessary. The 1 Hz rate is put in to be consistent
                with the industry standard SHPC specification, which specifies 2 Hz with
                1 Hz minimum.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_55538">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
  		  			<listitem>
                <para>The
                &#8220;blip&#8221; rate for the Enclosure Fault indicators when in the
                &#8220;remind&#8221; state must be nominally 0.5 Hz with a duty cycle of
                0.2 seconds on, 1.8 seconds off.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
  		  			<listitem>
                <para>All indicator roll-up (activate and
                deactivate) must be controlled entirely by the platform and must be
                transparent to the OS, SFP, and HMC.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
  		  			<listitem>
                <para>Duplicate indicators that are
                implemented to reflect the same state as another indicator in the system
                (for example, an indicator on the back of an enclosure that is to reflect
                the same visible state as the enclosure indicator on the front of the
                enclosure) must be transparent to the OS and must be kept synchronized by
                the platform.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_11274">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
  		  			<listitem>
                <para>The platform must
                provide a way to light all the indicators (Identify, Fault, Error Log,
                etc.) without any OS present, for test purposes (manufacturing, field
                service, etc.).</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
  		  			<listitem>
                <para>The hardware must provide the firmware a
                way to read the state of the indicators (that is, the register which
                controls the visual state, not the actual visual state) as well as to set
                the state of the indicators.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_88831">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
  		  			<listitem>
                <para>The platform must
                be designed such that permanently removing a FRU does not remove the
                capability to use the Identify indicator(s) remaining in the platform or
                affect any roll-up.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_66721">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
  		  			<listitem>
                <para>In reference to
                Requirement <xref linkend="dbdoclet.50569347_24076"
                xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_66944"
                xrefstyle="select: labelnumber"/>, if a capacitor and pushbutton
                are used to be able to activate the indicator after removal of the part,
                then all the following must be true:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para><emphasis role="bold">For Lightpath Mode platforms:</emphasis> Both
                    the Identify and
                    the Fault states must be supported, and the indicator must activate when
                    the push button is depressed and must go off (with the remaining
                    capacitor charge maintained) when the pushbutton is released (Identify
                    state is displayed as &#8220;blink&#8221; and Fault state as
                    &#8220;on&#8221;).</para>
                  </listitem>

                  <listitem>
                    <para><emphasis role="bold">For Guiding Light Mode platforms:</emphasis>
                    The Identify state
                    must be supported, and the indicator must activate (&#8220;blink&#8221;)
                    when the push button is depressed and must go off (with the remaining
                    capacitor charge maintained) when the pushbutton is released.</para>
                 </listitem>

                  <listitem xml:id="dbdoclet.50569347_62866">
                    <para>There must be a
                    green indicator next to the pushbutton and the indicator must get turned
                    on when the button is pressed and when there is charge in the capacitor,
                    and must be off when the button is not pressed.</para>
                  </listitem>

                  <listitem>
                    <para>The capacitor must have the capability to store enough charge
                    for two hours and after that period must be able to light for 30 seconds
                    the green indicator and enough other indicators to be able to identify
                    any necessary group of FRUs (for example, four additional indicators if a
                    group of four DIMM locations is to be identified simultaneously).</para>
                  </listitem>
                </orderedlist>

                <para>
                <emphasis role="bold">Implementation Note:</emphasis> As part of Requirement
                <xref linkend="dbdoclet.50569347_66721" />, it is not necessary to
                roll-up any activated indicators to the next level when the button is
                pressed.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-11.</emphasis></term>
  		  			<listitem>
                <para>All indicators which are under standby
                power must work the way they do when full power is applied to the system,
                including all of the following:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>The indicators must continue to display the last state displayed
                    when the system power went to standby-only power, unless the state is
                    changed during the standby state by the user or by a service
                    action.</para>
                  </listitem>

                  <listitem>
                    <para>The changing of the state to the Identify state and then back to
                    the previous state by the user must be supported, when that functionality
                    is supported during full system power.</para>
                  </listitem>
                </orderedlist>

                <para>
                <emphasis role="bold">Implementation Note:</emphasis> Internal to the platform
                firmware, it will most likely be required to have a common control point
                for all service indicators in order to meet the requirements and meet the
                necessary state information</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-12.</emphasis></term>
  		  			<listitem>
                <para>Any secondary (intermediate) level
                roll-up indicator (see
                <xref linkend="dbdoclet.50569347_70115" />) must behave as
                follows:</para>

                <itemizedlist>
                  <listitem>
                    <para>Be blinking, if any Identify indicator that it represents is
                    blinking</para>
                  </listitem>

                  <listitem>
                    <para>Be on solid if any Fault indicator that it represents is on and
                    no Identify indicator that it represents is blinking</para>
                 </listitem>

                  <listitem>
                    <para>Be off if all indicators that it represents are off</para>
                  </listitem>
                </itemizedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
  					xrefstyle="select: labelnumber nopage"/>-13.</emphasis></term>
  		  			<listitem>
                <para>The icons used for the following indicators, and any
                roll-up of the same, must be as follows (see the usability specifications
                for size, color, and placement):</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>For the Error Log indicator:</para>
                    <informalfigure>
                      <mediaobject>
                        <imageobject role="html">
                          <imagedata fileref="figures/PAPR-38.gif" format="GIF"
                          scalefit="1" />
                        </imageobject>
                        <imageobject role="fo">
                          <imagedata contentdepth="100%" fileref="figures/PAPR-38.gif"
                          format="GIF" scalefit="1" width="100%" />
                        </imageobject>
                      </mediaobject>
                    </informalfigure>
                  </listitem>

                  <listitem>
                    <para>For the Enclosure Fault indicator:</para>
                    <informalfigure>
                      <mediaobject>
                        <imageobject role="html">
                          <imagedata fileref="figures/PAPR-39.gif" format="GIF"
                          scalefit="1" />
                        </imageobject>
                        <imageobject role="fo">
                          <imagedata contentdepth="100%" fileref="figures/PAPR-39.gif"
                          format="GIF" scalefit="1" width="100%" />
                        </imageobject>
                      </mediaobject>
                    </informalfigure>
                  </listitem>

                  <listitem>
                    <para>For the Enclosure Identify indicator:</para>
                    <informalfigure>
                      <mediaobject>
                        <imageobject role="html">
                          <imagedata fileref="figures/PAPR-40.gif" format="GIF"
                          scalefit="1" />
                        </imageobject>
                        <imageobject role="fo">
                          <imagedata contentdepth="100%" fileref="figures/PAPR-40.gif"
                          format="GIF" scalefit="1" width="100%" />
                        </imageobject>
                      </mediaobject>
                    </informalfigure>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="blade_systems_chassis-level">
        <title>Blade Systems Chassis-level Indicator
        Requirements</title>
        <para>The following describes the chassis-level Error Log and Enclosure
        Identify indicator requirements for blade chassis implementations. These
        are basically the same as for the rack and row level indicators, except
        that the Enclosure Identify indicators are required to be able to be
        turned on/off by a user interface, unlike the rack and row level
        indicators.</para>
        <para>For the Lightpath UI, see also the requirements in
        <xref linkend="dbdoclet.50569347_88196" />.</para>

  	    <variablelist>
  		  	<varlistentry xml:id="dbdoclet.50569347_47650">
  		  		<term><emphasis role="bold">R1-<xref linkend="blade_systems_chassis-level"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>The blade chassis
                must implement an amber Error Log indicator, with the state diagram
                indicated in
                <xref linkend="dbdoclet.50569347_31313" />.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_95128">
  		  		<term><emphasis role="bold">R1-<xref linkend="blade_systems_chassis-level"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para>The blade chassis
                must implement an amber Enclosure Fault indicator, with the state diagram
                indicated in
                <xref linkend="dbdoclet.50569347_48644" />.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_32909">
  		  		<term><emphasis role="bold">R1-<xref linkend="blade_systems_chassis-level"
  					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
  		  			<listitem>
                <para>The blade chassis
                must implement an blue Enclosure Identify indicator, with the state
                diagram indicated in
                <xref linkend="dbdoclet.50569347_20150" />.</para>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="dbdoclet.50569347_69815">
        <title>Service Indicator State Diagrams</title>
        <para>The following state diagrams show the transitions and states for
        the service indicators in the system.</para>
        <para>
        <emphasis role="bold">Implementation Note:</emphasis> Activation of an
        indicator by a
        roll-up operation from a lower level indicator will prevent a user from
        turning off such an indicator from a user interface without turning off
        the lower level indicator. It is recommended, if possible, that in the
        user interface that allows the user to attempt to deactivate an
        indicator, provide to the user a message that the indicator cannot be
        deactivated, if attempted, when a roll-up to that indicator is active.
        That is, something better than just silently not turning off the
        indicator. Alternatively, the user can be shown that the option of
        turning off such an indicator is not possible, when a roll-up to that
        indicator is active (for example, by graying out the option on the user
        interface).</para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_53936">
          <title>FRU or Connector Fault/Identify
          Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-41.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-41.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <para><emphasis role="bold">Notes:</emphasis>
          <orderedlist>
            <listitem>
              <para>Not being available means the failure that is being
              indicated must be a failure which prevents the user from
              activating the Identify for the FRU.</para>
            </listitem>

            <listitem>
              <para>Transition to Fault state may occur if a failure
              occurs which would prevent the activation of the indicator
              into one of the Identify states. Not all FRU Fault indicators
              in an enclosure get activated like this simultaneously;
              only those that are directly involved with the fault
              (for example, like the FRU Fault indicator associated with
              the indicator controller hardware)</para>
            </listitem>

            <listitem>
              <para><phrase role="red">OS is not expected to change an
              indicator from Fault to Normal, but is permitted to do so
              (providing that it has access to the indicator because it
              owns the resource).</phrase></para>
            </listitem>

            <listitem>
              <para><phrase role="red">Transition from Fault to the Identify
              or Normal states by the OS may not be possible if a hardware
              fault causes a failure which prevents access to the
              indicator.</phrase></para>
            </listitem>

            <listitem>
              <para>Format on the above diagram of “xxxx,y” means a
              call to the <emphasis>set-indicator</emphasis> or
              <emphasis>ibm,set-dynamic-indicator</emphasis>
              RTAS call with an indicator token of “xxxx” and a state
              value of “y” (only the token applicable for the specific
              indicator causes a state transition).</para>
            </listitem>

            <listitem>
              <para>The 9002 Identify and Action are the same state.</para>
            </listitem>

            <listitem>
              <para><phrase role="red">9006 FRU-level indicators only
              provided in Lightpath Mode platforms.</phrase></para>
            </listitem>

            <listitem>
              <para><phrase role="red">Fault indicators may be virtualized,
              with several OS images and firmware given access to a virtual
              FRU Fault indicator which controls the same physical
              Fault/Identify indicator. These get combined as shown in the state
              diagram, above; all virtual Fault indicators basically get
              ORed together.</phrase></para>
            </listitem>

            <listitem>
              <para>This indicator may be forced to the Normal (off)
              state under certain circumstances (for example, see Requirement
              <xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
            </listitem>

            <listitem>
              <para><phrase role="red">For the Lightpath UI, when implemented,
              other transition conditions are possible. See
              <xref linkend="dbdoclet.50569347_88196"/>
              for requirements.</phrase></para>
            </listitem>
          </orderedlist>
        </para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_44018">
          <title>Error Log
          Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-42.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-42.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <para><emphasis role="bold">Notes:</emphasis>
          <orderedlist>
            <listitem>
              <para>Format on the above diagram of “xxxx,y” means
              a call to the <emphasis>set-indicator</emphasis> or
              <emphasis>ibm,set-dynamic-indicator</emphasis>
              RTAS call with an indicator token of “xxxx” and a state
              value of “y” (only the token applicable for the
              specific indicator causes a state transition).</para>
            </listitem>

            <listitem>
              <para>This indicator may be forced to the Normal
              (off) state under certain circumstances (for example, see
              Requirement
              <xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
            </listitem>

            <listitem>
              <para>See Requirement
              <xref linkend="dbdoclet.50569347_11464"
                xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_11464_e"
                xrefstyle="select: labelnumber"/>.</para>
            </listitem>

            <listitem>
              <para>For the Lightpath UI, when implemented, other transition conditions
              are possible. See
              <xref linkend="dbdoclet.50569347_88196"/>
              for requirements.</para>
            </listitem>
          </orderedlist>
        </para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_91006">
          <title>Enclosure
          Identify Indicator State Diagram for Scalable Systems</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-43.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-43.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <para><emphasis role="bold">Notes:</emphasis>
          <orderedlist>
            <listitem>
              <para>This indicator may be forced to the Normal (off)
              state under certain circumstances (for example, see Requirement
              <xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).
              This indicator is off at the end of POST.</para>
            </listitem>

            <listitem>
              <para>The states in this diagram overlay the corresponding
              states in
              <xref linkend="dbdoclet.50569347_27197"/>.
              This figure represents the POST states and
              <xref linkend="dbdoclet.50569347_27197" xrefstyle="select: label nopage" />
              the after-POST states.</para>
            </listitem>

            <listitem>
              <para>The use of the Optional Identify state to indicate boot
              identify is only to be used for boot servers
              for scalable system nodes or blades of a blade system
              (for example, NUMA system nodes), and not for stand-alone
              systems or blades</para>
            </listitem>
          </orderedlist>
        </para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_27197">
          <title>Enclosure
          Identify Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-44.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-44.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <para><emphasis role="bold">Notes:</emphasis>
          <orderedlist>
            <listitem>
              <para>This indicator may be activated to the on state
              by any OS which is given access to the indicator per Requirements.
              For indicators that are shared by multiple OS instances, this indicator
              is virtualized (see
              <xref linkend="dbdoclet.50569347_55025"/>
              and
              <xref linkend="dbdoclet.50569347_87607"/>).
              LoPAR compliant OSs are only given the capability to activate the
              Enclosure ID to the on state, not to the blink state. The blink state
              may be activated through an external platform management interface by
              a user request through that interface to blink the physical Enclosure ID.</para>
            </listitem>

            <listitem>
              <para>This indicator may be forced to the off state under
              certain circumstances (for example, see Requirement
              <xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).
              This indicator is off at the end of POST.</para>
            </listitem>

            <listitem xml:id="Note3">
              <para>A user is not allowed to deactivate the Enclosure ID if
              there are still FRU IDs still active.</para>
            </listitem>

            <listitem>
              <para>A user request through a privileged user interface (for example,
              via an SFP) to set the physical Enclosure ID to off,
              forces any virtual Enclosure ID indicators that are active (on or
              blink) to their off state, but this does not override
              any FRU ID roll-ups (see Note
              <xref linkend="Note3" xrefstyle="select: nopage"/>).</para>
            </listitem>

            <listitem>
              <para>For Scalable (NUMA) systems, the states in this diagram
              overlay the corresponding states in
              <xref linkend="dbdoclet.50569347_91006"/>.
              This figure represents the after-POST states and
              <xref linkend="dbdoclet.50569347_91006" xrefstyle="select: label nopage" />.
              the POST states.</para>
            </listitem>

            <listitem>
              <para>A virtual Enclosure ID can be activated or turned off by the
              9007 indicator token for the target Enclosure ID.</para>
            </listitem>
          </orderedlist>
        </para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_59067">
          <title>Enclosure Fault
          Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-45.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-45.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <para><emphasis role="bold">Notes:</emphasis>
          <orderedlist>
            <listitem>
              <para>There is no direct activation or deactivation of
              this indicator by any OS.</para>
            </listitem>

            <listitem>
              <para>See Requirement
              <xref linkend="dbdoclet.50569347_24076" xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_66944" xrefstyle="select: labelnumber"/>
              and the Implementation Note below that requirement.</para>
            </listitem>

            <listitem>
              <para>This indicator may be forced to the Normal (off)
              state under certain circumstances (for example, see Requirement
              <xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
            </listitem>

            <listitem>
              <para>Activation of an Enclosure Fault indicator without
              activating a FRU Fault indicator within the
              enclosure is to be used only in exceptional cases where
              the FRU Fault cannot be activated. In
              such cases the system is required to also provide
              further direction to the user on how to resolve
              the fault (for example, by providing an error code on an
              op panel on the system).</para>
            </listitem>
          </orderedlist>
        </para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_31313">
          <title>For Blade Systems:
          Chassis-level Error Log Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-46.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-46.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_48644">
          <title>For Blade Systems:
          Chassis-level Fault Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-47.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-47.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_20150">
          <title>For Blade Systems:
          Chassis-level Enclosure Identify Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-48.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-48.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <para><emphasis role="bold">Notes:</emphasis>
          <orderedlist>
            <listitem>
              <para>This indicator may be forced to the Normal (off) state
              under certain circumstances (for example, see Requirement
              <xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
            </listitem>

            <listitem>
              <para>A user is not allowed to deactivate the chassis Enclosure
              ID if there are still FRU Identify or Blade Enclosure
              Identify indicators still active (see state transition qualifiers
              in the above diagram).</para>
            </listitem>

            <listitem>
              <para>A user request to set the Chassis Enclosure ID to the
              Identify (blink) state temporarily overrides roll-up
              operations (roll-up operations set the indicator to the on state).</para>
            </listitem>

            <listitem>
              <para>A user request to change state of the Chassis Enclosure
              ID cancels any previous user request against the
              same indicator, replacing the user requested state with the new state.</para>
            </listitem>
          </orderedlist>
        </para>

        <figure pgwide="1" xml:id="dbdoclet.50569347_22016">
          <title>Rack-level Error
          Log Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-49.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-49.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_71112">
          <title>Rack-level Fault
          State Indicator Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-50.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-50.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_15206">
          <title>Rack-level
          Enclosure Identify Indicator State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-51.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-51.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_46164">
          <title>Row-level Error
          Log State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-52.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-52.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_44514">
          <title>Row-level Fault
          State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-53.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-53.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

        <figure pgwide="1" xml:id="dbdoclet.50569347_96374">
          <title>Row-level
          Identify State Diagram</title>
          <mediaobject>
            <imageobject role="html">
              <imagedata fileref="figures/PAPR-54.gif" format="GIF"
              scalefit="1" />
            </imageobject>
            <imageobject role="fo">
              <imagedata contentdepth="100%" fileref="figures/PAPR-54.gif"
              format="GIF" scalefit="1" width="100%" />
            </imageobject>
          </mediaobject>
        </figure>

       <para><emphasis role="bold">Notes:</emphasis> A blinking Enclosure ID
       is assumed to be “active” for purposes of the Row Enclosure ID indicator
       state.</para>
      </section>

    </section>

    <section xml:id="dbdoclet.50569347_84242">
      <title>Requirements for 9002, 9006, and 9007 Indicators</title>
      <para>See
      <xref linkend="dbdoclet.50569347_83698" /> for service indicator
      requirements that are not 9006 and 9007 specific.</para>

	    <variablelist>
		  	<varlistentry xml:id="dbdoclet.50569347_74342">
		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
		  			<listitem>
              <para>When the platform
              presents a 9006 indicator to an OS, the following must be true:</para>

              <orderedlist numeration="loweralpha">
                <listitem>
                  <para>The platform must set the location code of the Error Log (9006)
                  indicator and sensor to be the location code of the system and this
                  indicator or sensor must be the first one in the list of 9006 indicators
                  or sensors.</para>
                </listitem>

                <listitem>
                  <para><emphasis role="bold">For Lightpath Mode platforms:</emphasis>
                  The platform must set
                  the location code of each FRU Fault indicator and sensor to be the
                  location code of the component to which that indicator or sensor is
                  associated.</para>
                </listitem>

                <listitem>
                  <para>For every 9006 indicator, there must be a corresponding 9006
                  sensor which has the same index as the corresponding indicator.</para>
                </listitem>
              </orderedlist>
				    </listitem>
		  	</varlistentry>

		  	<varlistentry xml:id="dbdoclet.50569347_41932">
		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
		  			<listitem>
              <para>When 9007
              indicators are to be provided to an OS, the platform must implement the
              <emphasis>ibm,get-indices</emphasis> RTAS call and must present that call
              in the device tree for the OS, and the OS needing access to the 9007
              indicators and sensors must use the
              <emphasis>ibm,get-indices</emphasis> call to get the indices of the 9007
              indicators and sensors available to the partition at the time of the
              call.</para>
              <para>
                <emphasis role="bold">Software Implementation Notes:</emphasis>
              </para>

              <orderedlist>
                <listitem>
                  <para>Relative to Requirement
                  <xref linkend="dbdoclet.50569347_41932" />, due to Dynamic
                  Reconfiguration, the indicators available at any point in time might be
                  different than on a previous call to
                  <emphasis>ibm,get-indices</emphasis>.</para>
                </listitem>

                <listitem>
                  <para>9007 indicators may need to be provided to the OS in the order
                  in which they are best displayed to the user, because the OS or the UI
                  may not reorder them (for example, sort them) before presenting them to
                  the user. This is true regardless of the method of presentation to the OS
                  (OF device tree or
                  <emphasis>ibm,get-indices</emphasis> RTAS call). Relative to presentation
                  order, see also Requirement
                  <xref linkend="dbdoclet.50569347_56109"
                  xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_68142"
                  xrefstyle="select: labelnumber"/></para>
                </listitem>
              </orderedlist>
				    </listitem>
		  	</varlistentry>

		  	<varlistentry xml:id="dbdoclet.50569347_56109">
		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
		  			<listitem>
              <para>If a platform
              provides any 9007 indicators to the OS, then the following must be
              true:</para>

              <orderedlist numeration="loweralpha">
                <listitem>
                  <para>The platform must set the location code of each Identify (9007)
                  indicator and sensor (Enclosure, FRU, or connector) to be the location
                  code of the enclosure, FRU, or connector to which that indicator is
                  associated.</para>
                </listitem>

                <listitem xml:id="dbdoclet.50569347_68142">
                  <para>The System
                  Enclosure Identify (9007) indicator must be the first indicator in the
                  list of 9007 indicators.</para>
                </listitem>

                <listitem>
                  <para>For every 9007 indicator, there must be a corresponding 9007
                  sensor which has the same index as the corresponding indicator.</para>
                </listitem>
              </orderedlist>
				    </listitem>
		  	</varlistentry>

		  	<varlistentry>
		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
					xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
		  			<listitem>
              <para>A DR indicator (9002) must only be
              provided to an OS if that particular OS image owns that resource and is
              going to control the physical add, remove, and replace operations on the
              FRU which is pointed to by that particular DR indicator.</para>
				    </listitem>
		  	</varlistentry>

		  	<varlistentry>
		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
					xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
		  			<listitem>
              <para>If a PCI Hot Plug slot implements a single
              physical amber indicator for use as both the PCI Hot Plug DR indicator
              (for concurrent maintenance) and as the FRU Identify indicator, then that
              indicator must be presented to a LoPAR compliant OS as both a 9002 and
              9007 indicator.</para>
				    </listitem>
		  	</varlistentry>

		  	<varlistentry>
		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
					xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
		  			<listitem>
              <para>All platforms must provide the
              <emphasis role="bold"><literal>&#8220;ibm,fault-behavior&#8221;</literal></emphasis> and
              <emphasis role="bold"><literal>&#8220;ibm,fru-9006-deactivate&#8221;</literal></emphasis> properties in
              the
              <literal>root</literal> node of the OF device tree, both with a value of
              <literal>1</literal>.</para>
				    </listitem>
		  	</varlistentry>
		  </variablelist>

    </section>

    <section xml:id="dbdoclet.50569347_88196">

      <title>Lightpath User Interface (UI) Requirements</title>
      <para>The base Lightpath architecture does not provide a User Interface
      (UI), per se, when one considers a UI as being an interactive entity;
      that is, where the user can input requests as well as just see the
      faults. When enabling the Identify indicators of the Lightpath mode, a UI
      is necessary. This architecture will call this the Lightpath UI. The
      Lightpath UI is an interface between the Service Focal Point (SFP) and
      the user of the SFP, and at a minimum, provides an interface to show
      hidden Fault indicators (for example, see
      <xref linkend="dbdoclet.50569347_25484" />). A slightly more
      sophisticated Lightpath UI -- one with a General UI (GUI) such as an LCD
      or general display like provided by IBM Director -- is required to
      provide access to the Identify indicators.</para>
      <para>Enablement of the Identify portion of Lightpath is important in
      larger systems for reasons of deferred maintenance and guided
      maintenance. In a system with deferred maintenance and Lightpath, many
      Fault indicators may remain lit, requiring directed repair via an
      Identify operation in order to see the component against which to do a
      particular repair action. In addition, guided maintenance may be required
      even if there is no failing component, to indicate to the user where to
      plug or un-plug components or cables.</para>
      <para>When a Lightpath UI is available, the platform does not display
      logical Fault or Error Log on the physical indicators until a user
      requests such a display of the indicators, with the exception that the
      highest level roll-up indicators will be lit as a flag for the user to
      use the Lightpath UI to identify the problem. The request to display
      Fault and Error Log indicators may be made, for example, by pressing a
      button or series of buttons, or by checking a check-box on a more
      sophisticated Lightpath UI. The button(s) may be physical or may be on a
      device like an LCD panel or other Service Focal Point (SFP) display, like
      an IBM Director display.</para>
      <para>
      <xref linkend="dbdoclet.50569347_95432" /> defines an SFP as:
      &#8220;&#8230;common point of control in the system for handling all
      service actions which are not resolved otherwise (for example, via Fault
      indicators).&#8221; SFPs may or may not exist lower end systems, and may
      exhibit different levels of sophistication in larger systems. The
      following are some (not all) system implementation examples:</para>

      <itemizedlist>
        <listitem>
          <para>For simple systems, there may be no SFP and no Lightpath UI,
          which means everything needs to be resolved by Fault indicators.</para>
        </listitem>

        <listitem>
          <para>For simple systems implementing Triple-S (see
          <xref linkend="dbdoclet.50569347_25484" />), there may exist a simple SFP
          with a simple Lightpath UI like one or more physical push-buttons. This
          could be the System Error indicator with a physical button associated
          with it, with the SFP being firmware underlying the button to communicate
          with lower layers of firmware (for example, turn off FRU Fault indicators
          as they are activated by the firmware, turn on all active FRU Faults
          indicators on a button press). There may also be buttons for enabling the
          lower layers of the Fault indicator hierarchy, and these buttons inform
          the SFP firmware of the user&#8217;s request to display Fault indicators
          on the physical indicators. In this case, the Lightpath UI is not
          full-function and does not provide for enablement of the Identify
          indicators. In this case, the firmware driving the Lightpath UI would use
          the Lightpath UI base enablement (see
          <xref linkend="dbdoclet.50569347_89428" />).</para>
        </listitem>

        <listitem>
          <para>For intermediate systems, the Lightpath UI could be an LCD panel.
          In this case, the firmware driving the Lightpath UI would use the
          Lightpath UI base enablement (see
          <xref linkend="dbdoclet.50569347_89428" />). The Triple-S UI is also
          possible (see
          <xref linkend="dbdoclet.50569347_25484" />).</para>
        </listitem>

        <listitem>
          <para>For larger systems, the Lightpath UI could be part of a more
          sophisticated interface, like IBM Director. This more sophisticated
          interface would use the Lightpath UI base enablement (see
          <xref linkend="dbdoclet.50569347_89428" />). The Triple-S UI is also
          possible (see
          <xref linkend="dbdoclet.50569347_25484" />).</para>
        </listitem>
      </itemizedlist>

      <section xml:id="dbdoclet.50569347_89428">
        <title>Lightpath UI Base Enablement Requirements</title>
        <para>This section defines the base enablement requirements for all
        Lightpath UI implementations. The Triple-S UI is one example of such a
        Lightpath UI that uses the Lightpath UI Base Enablement. Other Lightpath
        UIs are possible, and are not limited by this architecture.</para>

  	    <variablelist>
  		  	<varlistentry xml:id="dbdoclet.50569347_68068">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_89428"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For the Lightpath UI Base Enablement:</emphasis>
                The platform must do all of the following:</para>

                <orderedlist numeration="loweralpha">
                  <listitem>
                    <para>Implement Lightpath Mode, as defined by this architecture,
                    lighting FRU Fault indicators or Error Log indicator associated with a
                    fault. Lightpath Mode includes the implementation of Identify
                    indicators.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_86534">
                    <para>If the SFP is
                    separate from the platform, then report to the SFP that the platform
                    implements the Lightpath UI Base Enablement (explicitly or implicitly).
                    (see implementation note, below)</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_16323">
                    <para>Whenever
                    possible, report all fault conditions which activate a FRU Fault
                    indicator or Error Log indicator, up to the SFP, with enough information
                    to allow determination by the SFP as to which FRU or Error Log indicators
                    are activated and the possible failing FRU(s). See the implementation
                    note, below, for the only exception cases allowed to this
                    requirement.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_17117">
                    <para>Accept commands
                    from the Service Focal Point (SFP) to put each indicator (FRU, Enclosure,
                    etc.), into the Off, Fault and Identify states (that is, the SFP can
                    control each indicator), and not report an activation or deactivation
                    error to the SFP if the SFP requests putting the indicator into a state
                    to which the indicator is already activated. See the implementation note,
                    below, for the only exception cases allowed to this requirement.</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_14345">
                    <para>Prevent multiple
                    reports of same error, whenever possible. (see implementation note,
                    below)</para>
                  </listitem>
                </orderedlist>

                <para>
                  <emphasis role="bold">Implementation Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>Requirement
                    <xref linkend="dbdoclet.50569347_68068"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_86534"
                    xrefstyle="select: labelnumber"/> allows a SFP to manage multiple
                    platforms that implement different Service Indicator modes. Note that
                    this requirement can be implemented implicitly from other information
                    reported to the SFP (for example, machine type/model).</para>
                  </listitem>

                  <listitem>
                    <para>In Requirement
                    <xref linkend="dbdoclet.50569347_68068"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_16323"
                    xrefstyle="select: labelnumber"/> and
                    <xref linkend="dbdoclet.50569347_68068"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_17117"
                    xrefstyle="select: labelnumber"/>, acceptable reasons for not
                    being able to report errors to the SFP or have the SFP control the LEDs
                    may include:</para>

                    <itemizedlist>
                      <listitem>
                        <para>Loss of communications between the component and the SFP.</para>
                      </listitem>

                      <listitem>
                        <para>A fault indicator that is entirely controlled by an OS, hardware,
                        or code, or an entity which is not in communications with the platform
                        firmware or the SFP.</para>
                      </listitem>
                    </itemizedlist>
                  </listitem>

                  <listitem>
                    <para>Requirement
                    <xref linkend="dbdoclet.50569347_68068"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_14345"
                    xrefstyle="select: labelnumber"/> prevents continual
                    &#8220;blinking&#8221; of Fault indicator and the flooding of the
                    SFP&#8217;s event or error log.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_43836">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_89428"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For the Lightpath UI Base Enablement:</emphasis>
                The Service Focal
                Point (SFP) must exist and must do all of the following:</para>

                <orderedlist numeration="loweralpha">
                  <listitem xml:id="dbdoclet.50569347_42627">
                    <para>Receive and log
                    fault conditions reported by the platform. (see implementation note,
                    below)</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_37801">
                    <para>Turn off each
                    Fault indicator or Error Log indicator associated with a fault condition,
                    as soon as possible after the fault is reported, except as required to
                    remain on by user request user request (for example, see Requirement
                    <xref linkend="dbdoclet.50569347_19733" />).</para>
                  </listitem>

                  <listitem>
                    <para>Accept direction from a user to show any faults on the Fault and
                    Error Log indicators (for example, see Requirement
                    <xref linkend="dbdoclet.50569347_19733" />).</para>
                  </listitem>

                  <listitem xml:id="dbdoclet.50569347_84423">
                    <para>If the SFP
                    contains a GUI (for example, an LCD display or a display like provided by
                    IBM Director), accept direction from a user to Identify a FRU or
                    connector for a service operation, and then turn off all activated FRU
                    Fault and Error Log indicators, unless otherwise directed by the user
                    (for example, by a check-box on the UI), and activate the FRU Identify
                    (blink), along with the normal FRU roll-up defined by the base Lightpath
                    Mode.</para>
                  </listitem>
                </orderedlist>

                <para>
                  <emphasis role="bold">Implementation Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>Relative to Requirements
                    <xref linkend="dbdoclet.50569347_43836"
                    xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_42627"
                    xrefstyle="select: labelnumber"/>, a SFP may (but is not
                    required to) do additional failure analysis, or may apply policy rules,
                    on the failure(s) reported, and by doing so may change or re-prioritize
                    the list of failures, such that the most likely failure(s) is (are)
                    different than the fault indicator(s) that were initially turned on by
                    the detecting entity. In which case, when the user requests that the
                    indicators be reactivated, a different set may be activated than those
                    that were originally activated.</para>
                  </listitem>

                  <listitem>
                    <para>In simpler systems, it is expected that there may only be one
                    push-button implemented, and that would be associated with the highest
                    level Fault roll-up indicator. For systems, or collection of systems that
                    are managed by a SFP, which consist of many enclosures, it may be useful
                    for an implementation to implement several levels of buttons. For
                    example, a SFP that manages multiple systems may (at least) implement one
                    button per system.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="dbdoclet.50569347_25484">

        <title>See/Select/Service (Triple-S) User Interface
        Requirements</title>
        <para>The Triple-S UI architecture is built on top of the Lightpath UI
        Base Enablement architecture, which is in turn built on top of the
        Lightpath architecture. The Triple-S architecture is basically defined as
        follows (see Requirements for specifics):</para>

        <itemizedlist>
          <listitem>
            <para>Do not display Fault or Error Log on the physical indicators
            until user pushes a button or series of buttons.</para>

            <itemizedlist>
              <listitem>
              <para>Except that the highest level roll-up for the Enclosure Fault
              indicators and Error Log indicators will be activated if a lower level
              one of the same type was activated.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>After seeing the highest level roll-up for Enclosure Fault or
            Error Log being on, the user pushes one or more buttons (logical or
            physical) associated with those, and then the user
            <emphasis>Sees</emphasis> the Faults available for servicing.</para>
          </listitem>

          <listitem>
            <para>The user
            <emphasis>Selects</emphasis> the item they want to service, by observing
            the FRU Faults and selecting they want to then Service.</para>

            <itemizedlist>
              <listitem>
              <para>The <emphasis>Selects</emphasis> part of Triple-S may also involve
              activation of the FRU Identify indicator from the Lightpath UI.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>The user completes the Service action on that component which was
            selected.</para>
          </listitem>
        </itemizedlist>


  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For the Triple-S UI:</emphasis> The Lightpath UI Base Enablement
                requirements must be met, as defined in
                <xref linkend="dbdoclet.50569347_89428" />.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
  					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For the Triple-S UI:</emphasis> The platform must provide one or
                more push-buttons (physical button, or logical on a GUI), each associated
                with a set of Fault indicators or Error Log indicators which is (are) to
                be used by the user to display (&#8220;show&#8221;) or not display
                (&#8220;hide&#8221;) fault conditions on those group of indicators, as
                defined by Requirement
                <xref linkend="dbdoclet.50569347_19733" />.</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry xml:id="dbdoclet.50569347_19733">
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
  					xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For the Triple-S UI:</emphasis>
                The Service Focal
                Point (SFP) must accept direction from a user from a push-button
                (physical or logical) press to show any fault conditions on, or hide all
                fault conditions from, the physical indicators (FRU Faults and any
                associated roll-up indicators for those indicators), which are associated
                with the push-button (Fault or Error Log indicators). The fault
                conditions must represent any open problems known by the SFP related to
                the set of indicators associated with the push-button. The push of the
                button must be a toggle operation, with each press either going from the
                show state to the hide state or from the hide state to the show state,
                based on the state prior to the push-button press. The platform must turn
                off any indicators turned on by these push-button activations after a
                pre-set period of time after the button activation, unless the pre-set
                time is set to 0, in which case the indicators are left on until the
                button is press again or until the platform determines they are no longer
                needed to be on. (see implementation note, below).</para>
  				    </listitem>
  		  	</varlistentry>

  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
  					xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
  		  			<listitem>
                <para><emphasis role="bold">For the Triple-S UI:</emphasis> For more complex systems, and as
                determined by the RAS requirements for those systems, the SFP must
                implement a GUI (for example, an LCD or IBM Director display) and provide
                the capability to activate the Identify indicators, as defined in
                Requirement <xref linkend="dbdoclet.50569347_43836"
                xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_84423"
                xrefstyle="select: labelnumber"/>.</para>

                <para>
                  <emphasis role="bold">Implementation Notes:</emphasis>
                </para>

                <orderedlist>
                  <listitem>
                    <para>Relative to Requirement
                    <xref linkend="dbdoclet.50569347_19733" />, a SFP may (but is not
                    required to) do additional failure analysis, or may apply policy rules,
                    on the failure(s) reported, and by doing so may change or re-prioritize
                    the list of failures, such that the most likely failure(s) is (are)
                    different than the fault indicator(s) that were initially turned on by
                    the detecting entity. In which case, when the user requests that the
                    indicators be reactivated, a different set may be activated than those
                    that were originally activated.</para>
                  </listitem>

                  <listitem>
                    <para>Relative to Requirement
                    <xref linkend="dbdoclet.50569347_19733" />, the set of indicators
                    associated with a given push-button will normally be hierarchical, based
                    on the FRU Fault or Error Log roll-up path. For example, if a push-button
                    is associated with the Chassis Enclosure fault indictor, pressing that
                    button would toggle the show/hide state for all fault indicators within
                    that Chassis. Another example is pressing of a button associated with the
                    System Error roll-up indicator for a system, putting that system into the
                    &#8220;show&#8221; state could put that system basically into a Lightpath
                    (without Triple-S) mode, or &#8220;Lightpath Classic&#8221; mode. In this
                    latter example, it is not quite like previous implementations of
                    Lightpath because (1) service procedures may be different, (2) based on
                    Implementation note (a) the set of FRU Faults activated by the SFP may be
                    different than those activated by the entity detecting the error
                    originally, and (3) the Identify function can be used.</para>
                  </listitem>
                </orderedlist>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>
    </section>

  </section>

  <section>
    <title>Green Indicator Requirements</title>
    <para>This chapter defines the platform requirements for green
    indicators.</para>
    <para>The usage of green indicators has been separated from the rest of
    this chapter, because even though green indicators are used in some service
    procedures (for example, to check for presence or absence of power on a
    component or system), they are not to be used in lieu of amber FRU Fault
    and Identify indicators. That is, they should supplement, not replace, the
    amber indicators.</para>
    <para>There are several exceptions to having all the green indicator
    requirements in this chapter:</para>

    <itemizedlist>
      <listitem>
        <para>The green indicator associated with a capacitor and pushbutton
        implementation is specified in Requirement <xref linkend="dbdoclet.50569347_66721"
        xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_62866"
        xrefstyle="select: labelnumber"/>.).</para>
      </listitem>

      <listitem>
        <para>The capability to light all green indicators, as well as the amber
        and blue indicators, for test purposes, is specified in Requirement
        <xref linkend="dbdoclet.50569347_11274" />.</para>
      </listitem>

      <listitem>
        <para>Unless indicated otherwise in this chapter, the blink rate for
        green indicators, when they blink, is specified in Requirement
        <xref linkend="dbdoclet.50569347_81809" />.</para>
      </listitem>
    </itemizedlist>


    <section xml:id="green_indicator_uses">
      <title>Green Indicator Uses and General Requirements</title>
      <para>Green indicators generally are not used for indicating a fault
      condition.</para>

	    <variablelist>
		  	<varlistentry>
		  		<term><emphasis role="bold">R1-<xref linkend="green_indicator_uses"
					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
		  			<listitem>
              <para>A green indicator must not be used in
              place of an amber Fault/Identify indicator, except when use of amber
              Fault/Identify indicator is not possible, and in this exceptional case,
              the green must be off or blinking to indicate the error condition.</para>
              <para>
              <emphasis role="bold">Implementation Note:</emphasis> Examples where a
              green indicator
              might be used instead of an amber Fault/Identify indicator are:</para>

              <itemizedlist>
                <listitem>
                  <para>In a power supply to indicate lack of AC power (green
                  off).</para>
                </listitem>

                <listitem>
                  <para>In the case where there is insufficient power to power the
                  component (green blinking).</para>
                </listitem>
              </itemizedlist>
				    </listitem>
		  	</varlistentry>

		  	<varlistentry>
		  		<term><emphasis role="bold">R1-<xref linkend="green_indicator_uses"
					xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
		  			<listitem>
              <para>There must exist a green power indicator
              for every FRU that is to participate in concurrent maintenance
              (&#8220;hot plug&#8221; operation), unless that FRU does not require the
              removal of power to remove or insert that FRU.</para>
				    </listitem>
		  	</varlistentry>
		  </variablelist>

    </section>

    <section xml:id="dbdoclet.50569347_54601">
      <title>Green Indicator States</title>
      <para>This section attempts to capture the state requirements for all
      usages of green indicators. If a state or usage is not specified, then
      the user needs to get with the Architecture team for this architecture in
      order to add or replace any state or usage of that state.</para>

      <section xml:id="power_supply_green">
        <title>Power Supply Green Indicators</title>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="power_supply_green"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>For power supply indicators, the
                platform must implement the states defined in
                <xref linkend="dbdoclet.50569347_83372" /> for each green indicator, and
                must use those states only for the usages stated in
                <xref linkend="dbdoclet.50569347_83372" />.</para>
                <para>&#160;</para>
                <table frame="all" pgwide="1" xml:id="dbdoclet.50569347_83372">
                  <title>Power Supply Green Indicator States and Usage</title>
                  <?dbhtml table-width="80%" ?>
                  <?dbfo table-width="80%" ?>
                  <tgroup cols="2">
                    <colspec colname="c1" colwidth="40*" align="center" />
                    <colspec colname="c2" colwidth="60*" />
                    <thead>
                      <row>
                        <entry>
                          <para>
                            <emphasis role="bold">Green Indicator State</emphasis>
                          </para>
                        </entry>
                        <entry align="center">
                          <para>
                            <emphasis role="bold">Usage</emphasis>
                          </para>
                        </entry>
                      </row>
                    </thead>
                    <tbody valign="middle" >
                      <row>
                        <entry>
                          <para>Any not already covered in this table</para>
                        </entry>
                        <entry>
                          <para>Consult with the xipSIA architecture team for the proper
                          usage/behavior.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Off</para>
                        </entry>
                        <entry>
                          <para>For the input power indicator: no input power.</para>
                          <para>For the output power indicator: no output power.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>On</para>
                        </entry>
                        <entry>
                          <para>For the input power indicator: input power good.</para>
                          <para>For the output power indicator: output power good.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Slow blink (1 Hz, 50% duty cycle)</para>
                        </entry>
                        <entry>
                          <para>Power supply (or supplies) are in the standby state. A
                          power supply must not blink its green output power indicator
                          unless that particular supply is in the standby state.</para>
                        </entry>
                      </row>
                    </tbody>
                  </tgroup>
                </table>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="dbdoclet.50569347_21912">
        <title>System Power Green Indicators</title>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_21912"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>For system power indicators, the
                platform must implement the states defined in
                <xref linkend="dbdoclet.50569347_73050" /> for each green indicator, and
                must use those states only for the usages stated in
                <xref linkend="dbdoclet.50569347_73050" />.</para>
                <para>&#160;</para>
                <table frame="all" pgwide="1" xml:id="dbdoclet.50569347_73050">
                  <title>System Power Green Indicator States and Usage</title>
                  <?dbhtml table-width="80%" ?>
                  <?dbfo table-width="80%" ?>
                  <tgroup cols="2">
                    <colspec colname="c1" colwidth="40*" align="center" />
                    <colspec colname="c2" colwidth="60*" />
                    <thead>
                      <row>
                        <entry>
                          <para>
                            <emphasis role="bold">Green Indicator State</emphasis>
                          </para>
                        </entry>
                        <entry align="center">
                          <para>
                            <emphasis role="bold">Usage</emphasis>
                          </para>
                        </entry>
                      </row>
                    </thead>
                    <tbody valign="middle" >
                      <row>
                        <entry>
                          <para>Any not already covered in this table</para>
                        </entry>
                        <entry>
                          <para>Consult with the xipSIA architecture team for the proper
                          usage/behavior.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Off</para>
                        </entry>
                        <entry>
                          <para>System is off (no standby power).</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>On</para>
                        </entry>
                        <entry>
                          <para>System is on (operational state).</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Fast blink (4 Hz, 50% duty cycle)</para>
                        </entry>
                        <entry>
                          <para>A determination is being made as to whether the system
                          (for example, a Blade in a Blade System) has enough power
                          available to it, in order to power up, or a determination has
                          already been made that there is not enough power, and the
                          indicator remains in this state.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Slow blink (1 Hz, 50% duty cycle)</para>
                        </entry>
                        <entry>
                          <para>System is in the standby power state.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Fade-in/fade-out cycling of the power LED as done in
                          various PC and notebook manufacturers:</para>
                          <para>the period of this fade-in/fade-out cycle is 2 seconds,
                          gradually ranging from fully on to fully off</para>
                        </entry>
                        <entry>
                          <para>Systems that support system-level sleep states (such as
                          the S3 sleep state) must use this state as a way to indicate
                          the system is sleeping but still powered on.</para>
                        </entry>
                      </row>
                    </tbody>
                  </tgroup>
                </table>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="hdd_green">
        <title>HDD Green Indicators</title>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="hdd_green"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>For Hard Disk Drives (HDD) the platform
                must implement the states defined in
                <xref linkend="dbdoclet.50569347_38629" /> for each green indicator, and
                must use those states only for the usages stated in
                <xref linkend="dbdoclet.50569347_38629" />.</para>
                <para>&#160;</para>
                <table frame="all" pgwide="1" xml:id="dbdoclet.50569347_38629">
                  <title>HDD Green Indicator States and Usage</title>
                  <?dbhtml table-width="80%" ?>
                  <?dbfo table-width="80%" ?>
                  <tgroup cols="2">
                    <colspec colname="c1" colwidth="40*" align="center" />
                    <colspec colname="c2" colwidth="60*" />
                    <thead>
                      <row>
                        <entry>
                          <para>
                            <emphasis role="bold">Green Indicator State</emphasis>
                          </para>
                        </entry>
                        <entry align="center">
                          <para>
                            <emphasis role="bold">Usage</emphasis>
                          </para>
                        </entry>
                      </row>
                    </thead>
                    <tbody valign="middle" >
                      <row>
                        <entry>
                          <para>Any not already covered in this table</para>
                        </entry>
                        <entry>
                          <para>Consult with the xipSIA architecture team for the proper
                          usage/behavior.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Off</para>
                        </entry>
                        <entry>
                          <para>Platform specific.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>On</para>
                        </entry>
                        <entry>
                          <para>Platform specific.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Flickering (randomly blinking)</para>
                        </entry>
                        <entry>
                          <para>HDD activity (HDD is powered on and is being
                          used).</para>
                        </entry>
                      </row>
                    </tbody>
                  </tgroup>
                </table>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="other_component_green">
        <title>Other Component/FRU Green Indicators</title>
        <para>This section attempts to capture the state requirements for usages
        of green indicators that are not specifically called out as special cases
        elsewhere in
        <xref linkend="dbdoclet.50569347_54601" />. To reiterate what was
        specified, above: if a state or usage is not specified, then the user
        needs to get with the Architecture team for this architecture in order to
        add or replace any state or usage of that state.</para>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="other_component_green"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>For FRUs or components other than
                specific ones specified elsewhere in
                <xref linkend="dbdoclet.50569347_54601" />, which require power
                indicators, the platform must implement the states defined in
                <xref linkend="dbdoclet.50569347_66324" /> for each green indicator, and
                must use those states only for the usages stated in
                <xref linkend="dbdoclet.50569347_66324" />.</para>
                <para>&#160;</para>
                <table frame="all" pgwide="1" xml:id="dbdoclet.50569347_66324">
                  <title>Sub-Unit (Component) Green Indicator States and
                  Usage</title>
                  <?dbhtml table-width="80%" ?>
                  <?dbfo table-width="80%" ?>
                  <tgroup cols="2">
                    <colspec colname="c1" colwidth="40*" align="center" />
                    <colspec colname="c2" colwidth="60*" />
                    <thead>
                      <row>
                        <entry>
                          <para>
                            <emphasis role="bold">Green Indicator State</emphasis>
                          </para>
                        </entry>
                        <entry align="center">
                          <para>
                            <emphasis role="bold">Usage</emphasis>
                          </para>
                        </entry>
                      </row>
                    </thead>
                    <tbody valign="middle" >
                      <row>
                        <entry>
                          <para>Any not already covered in this table</para>
                        </entry>
                        <entry>
                          <para>Consult with the xipSIA architecture team for the proper
                          usage/behavior.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Off</para>
                        </entry>
                        <entry>
                          <para>Component/FRU is powered off and/or is not in
                          operation.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>On</para>
                        </entry>
                        <entry>
                          <para>Component/FRU is powered on.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Blink 1 Hz, 50% duty cycle</para>
                        </entry>
                        <entry>
                          <para>(Optional) Component/FRU is in transition to the off
                          state. Note that although this is an optional state, it is
                          highly recommended (for Human Factors reasons) for cases where
                          it takes awhile to power off the component (for example, for
                          hardware like a Blade in a Blade System that has to be quiesced
                          before powering off).</para>
                        </entry>
                      </row>
                    </tbody>
                  </tgroup>
                </table>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

      <section xml:id="communication_link_green">
        <title>Communication Link Green Indicators</title>

  	    <variablelist>
  		  	<varlistentry>
  		  		<term><emphasis role="bold">R1-<xref linkend="communication_link_green"
  					xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
  		  			<listitem>
                <para>For communication links, the platform
                must implement the states defined in
                <xref linkend="dbdoclet.50569347_90668" /> for each green indicator, and
                must use those states only for the usages stated in
                <xref linkend="dbdoclet.50569347_90668" />.</para>
                <para>&#160;</para>
                <table frame="all" pgwide="1" xml:id="dbdoclet.50569347_90668">
                  <title>Communication Link Green Indicator States and
                  Usage</title>
                  <?dbhtml table-width="80%" ?>
                  <?dbfo table-width="80%" ?>
                  <tgroup cols="2">
                    <colspec colname="c1" colwidth="40*" align="center" />
                    <colspec colname="c2" colwidth="60*" />
                    <thead>
                      <row>
                        <entry>
                          <para>
                            <emphasis role="bold">Green Indicator State</emphasis>
                          </para>
                        </entry>
                        <entry align="center">
                          <para>
                            <emphasis role="bold">Usage</emphasis>
                          </para>
                        </entry>
                      </row>
                    </thead>
                    <tbody valign="middle" >
                      <row>
                        <entry>
                          <para>Any not already covered in this table</para>
                        </entry>
                        <entry>
                          <para>Consult with the xipSIA architecture team for the proper
                          usage/behavior.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Off</para>
                        </entry>
                        <entry>
                          <para>No link connection or link connected but no
                          activity.</para>
                        </entry>
                      </row>
                      <row>
                        <entry>
                          <para>Flickering (randomly blinking)</para>
                        </entry>
                        <entry>
                          <para>Communication link activity.</para>
                        </entry>
                      </row>
                    </tbody>
                  </tgroup>
                </table>
  				    </listitem>
  		  	</varlistentry>
  		  </variablelist>

      </section>

    </section>

   </section>
</chapter>