Browse Prior Art Database

Architecture for dynamic mode changes between Guiding Light and Light Path service indicators

IP.com Disclosure Number: IPCOM000237563D
Publication Date: 2014-Jun-24
Document File: 2 page(s) / 27K

Publishing Venue

The IP.com Prior Art Database

Abstract

Described is a proposed architecture whereby each of the service indicator architectures is an operating mode the system can run in. The proposal allows the customer to dynamically switch the mode to their preference at any time.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Architecture for dynamic mode changes between Guiding Light and Light Path service indicators

Service indicator architecture has two major divisions. Light Path is where service indicators on individual field replaceable units (FRUs) are activated when failures are detected is delivered in smaller, low-to-medium sized systems. These systems tend to be more aligned to a "repair on failure" service strategy with only limited ability or inclination on the customer's part to keep running and defer the repair. Guiding Light is where only a single indicator with system-wide scope activates when a problem is detected anywhere in the system is delivered in larger, high-end systems. The high-end systems have robust reliability, availability, and serviceability (RAS) features allowing them to tolerate a number of faults and continue to run. Each architecture has advantages and appeals to customers from different perspectives. The systems are developed to operate as just one or the other architecture. This disclosure proposes an architecture whereby each of the service indicator architectures is an operating mode the system can run in. The proposal allows the customer to dynamically switch the mode to their preference at any time.

    Systems are developed and shipped with Guiding Light (GL) service indicators or Light Path (LP) service indicators. Some customers prefer Light Path (LP) as a service indicator architecture because, as components fail or are predicted to fail, indicators (LEDs) are activated showing what must be replaced. On relatively smaller systems with less RAS capability in terms of fault tolerance and redundancy, the service is performed soon after the indication of a failure. Other customers prefer GL, which makes more sense on larger systems with enhanced RAS characteristics that allow the system to continue running with some amount of failed or failing hardware due to redundancy or fault tolerance methods used. The drawback to LP on systems with more robust RAS characteristics is that the fault indicators (LEDs) will remain active as long as the service is deferred. This can lead to cases where the customer has deferred multiple repairs because the system can continue to run, but the number of active fault LEDs is increasing. This is sometimes referred to as the Christmas tree effect. Some customers have complained about this effect and would rather the system be a GL implementation. There is no crisp division in terms of system model and RAS features that would define where LP should end and GL s...