More context, if needed (from a previous exchange on the HPI WG email reflector).  I’m still hunting down the use case emails, which are very helpful in understanding the intent of the Annunciator MI. 

 

Charlene

 

*****************************

 

 

Q: What are HPI "Annunciator" management instruments, how are they used, and how do they relate to the Domain Alarm Table?

 

A:  It is a common feature of various platforms to have built-in methods of displaying status information to a technician.  For example, these methods may include LEDs, text displays, audible alarms, dry-contact relay closures, etc.  It is difficult for portable management software to use these devices effectively, because they may differ from platform to platform.  One platform may have three LEDs to indicate alarm levels; another may have a single LED that changes color or blinks for different alarm levels.  Others may have text displays, text displays in conjunction with LEDs, or relays.  If management software has to directly interact with each individual control on each different platform, then that software could not easily move from one platform to the next.

 

To help address this problem, HPI provides the "Annunciator" management instrument.  The purpose of this management instrument is to allow management software to interact with platform status information display hardware in an abstract way that is independent of the specifics of how that particular platform displays information (i.e., through lighting LEDs, or putting messages on a text display, or whatever).  An HPI Annunciator is a virtual device into which a set of "Announcements" can be loaded.  The platform-specific HPI implementation will take whatever actions are appropriate for that platform to display (that is, to "annunciate") that set of Announcements.  One platform that has only LEDs may simply light an LED if any Announcements, or any Announcement of a sufficient severity is present.  Another platform may scroll through all active Announcements on a small front-panel text display.  A third may take a combination of these actions, all dependent on what specific display hardware is available on that platform.

 

Announcements can be added to or deleted from an HPI Annunciator by a management application using the HPI interface.  So, if the management application determines that some condition should be displayed, it can add an Announcement for that condition to the Annunciator, and the platform specific HPI implementation will take whatever actions are appropriate to communicate the information on its display(s).   Platforms may also automatically add or delete Announcements in an HPI Annunciator.  Thus, a management application can learn what information is being displayed by reading the set of Announcements in an Annunciator.  There is no requirement, however, on what information a platform must automatically announce, so reading the contents of an Annunciator is not a reliable way to learn status information about the system; it is just a way to learn what information is being displayed.

 

There is a potential confusion between the functionality and use of HPI Annunciators, and the HPI Domain Alarm Table (DAT).  Although they are both tables that contain information about abnormal "Alarm" conditions on the platform, these two facilities are intended to serve different purposes.  The purpose of the HPI Annunciator management instrument is as described above:  it provides an abstract interface to some sort of physical status display hardware.  The primary purpose of the DAT, on the other hand, is to communicate Alarm status information to HPI users via the HPI interface.  Because these two structures serve different purposes, there are some subtle, but significant differences in their functionality, as described below.

 

1) The specification describes explicitly what information the HPI implementation will add to and remove from the DAT, but does not place any restrictions on what the implementation will add to or remove from an Annunciator (except that an Annunciator may be set into "User Mode" in which case the HPI implementation must not add or remove any Announcements).  The reason for this difference is that the DAT is intended to be a place users can learn about the status of the system.  Thus, it is important to define what status information will be reflected in the DAT.  On the other hand, the Announcements in an Annunciator will reflect whatever the platform happens to be displaying to a technician.  Because the HPI specification does not address what information should be displayed to technicians on a platform, it cannot dictate what Announcements the implementation must add to an Annunciator.

 

2) Users may only add "User" Alarms to the DAT, but they may add any sort of Announcements to an Annunciator.  Because the DAT is primarily used to communicate from the platform to users, having users add the same sort of Alarms to the DAT as the HPI implementation adds itself (e.g., sensor or resource Alarms) would be potentially very confusing, hence the restriction to User Alarms.  There may be valid reasons for users to add Announcements concerning sensor or resource status conditions to an Annunciator, though.  For example, a user can choose to place an Annunciator into "User Mode" and thus directly control all information that is displayed to the technician.  In this case, the user can provide a "filter" for system status conditions, and choose to display (or not) individual Announcements, including sensor and resource Announcements, by writing them to the Annunciator.

 

3) All Alarms in the DAT must have a severity of SAHPI_CRITICAL, SAHPI_MAJOR, or SAHPI_MINOR, but Announcements in an Annunciator may have any severity level.  The purpose of the DAT is specifically to communicate Alarm conditions to users, which is why its entries are restricted.  A platform Annunciator, though, may be designed to display normal conditions as well as Alarm conditions.

 

3) Users may not delete any Alarms from the DAT except for User Alarms, but users may delete any Announcements from an Annunciator (unless the Annunciator is in "Auto Mode," which prevents any additions or deletions by the user).  Allowing a user to delete Alarms from the DAT would make it invalid as a source of status information for other users.  On the other hand, if a user is attempting to control what is displayed via an Annunciator, then the user needs to be able to delete any Announcement that the user concludes should no longer be displayed.

 

4) There is always one and only one DAT per domain, but there may be any number of Annunciators located in one or more Resources.  DATs are located in each Domain so that users have a single, easy to access table that can be used to learn about all Alarm conditions within the entire Domain.  Annunciators, like other management instruments, are defined to reflect actual platform management hardware - in this case display hardware - which may or may not exist throughout the system.  Annunciators are housed in resources, like all management instruments, because they are associated with actual display hardware managed through resources.

 

There may be multiple Annunciators on a single resource, or spread among multiple resources if there are multiple logical status displays on the platform.  A "logical status display" may itself contain multiple devices.  For example a single "logical status display" may be made up of three LEDs indicating "Minor", "Major", or "Critical" alarms are present, a text display that shows details of the alarms, and an audible alert that sounds when unacknowledged alarms are present.  All of these devices, working together to display the same set of alarms would be one "logical status display", and thus interfaced through one Annunciator.  But, say a platform contained a separate set of "Minor/Major/Critical" LEDs for different sub-systems.  Then each set of LEDs would be a separate "logical status display", each displaying a different set of Announcements (e.g., Announcements related to each individual sub-system), so the HPI implementation would need to create multiple Annunciator management instruments for each sub-system's LED set.

 

A primary point of confusion arises from the fact that there is a way to add User Alarms to the DAT.  If the purpose of the DAT is to communicate Alarm conditions from the HPI implementation to the user, why would the user ever want to add information to the DAT?  The main reason for this capability is simply to allow the User to make the DAT be a more "complete" database of Alarm conditions in the system.  Users may add Alarms to the DAT so that they can later retrieve that Alarm information, or so that other users that access the same Domain can find both HPI implementation generated and User generated Alarms in one place. 

 

In addition, an HPI implementation may use the contents of the DAT to drive implementation-specific status displays.  The HPI specification addresses this (in section 3.2.1, on page 19):

HPI implementations should use the contents of a Domain Alarm Table to control the annunciation of alarms on a platform.  Alarm annunciation by a particular HPI implementation is implementation-specific. The implementation may directly control annunciation hardware as a result of changes to the DAT, or it may utilize HPI control or annunciator management instruments in various resources to announce the alarms.  It is implementation-specific what annunciation actions are taken when alarms are added, removed, or acknowledged in the Domain Alarm Table.

 

Although the specification says that an implementation "should" somehow use the contents of the DAT to control display of alarm information on the platform, a user cannot depend on an HPI implementation to provide this capability.  It is true that an HPI implementation may do whatever it wishes with the contents of the DAT "below the line" of the HPI interface, and this includes providing some sort of automatic display of status information from the DAT on the platform.  But, the user cannot assume that adding User Alarms to the DAT has any effect on the system other than to add a record to the DAT, which can be subsequently read by HPI users.

 

The HPI interface thus provides three ways for users to interface with display hardware:

1) Individual LEDs, text panels, audible alarms, relays, etc. may be exposed as specific HPI Controls.  When so exposed, an HPI user is able to directly turn individual LEDs on or off, place specific text on a text display panel, an so forth.  With this sort of interface, the user can control both what alarm data is displayed and how it is displayed.  But, the user application must deal with the fact that different platforms will have different sets of display hardware controls, so producing portable management applications may be very difficult.

 

2) "Logical displays" consisting of multiple LEDs, text panels, etc. may be modeled as HPI Annunciators.  When Annunciators are defined, an HPI user can see and control what status conditions are being displayed on a particular "logical display" in the system without needing to understand the specifics of how the data is presented on the platform display hardware.  The user has control over what information is to be displayed, but not how it is displayed.  By hiding the details of platform-specific display hardware, this level of interface can be more easily used by portable management applications.

 

3) An HPI implementation may automatically control platform displays using data found in the DAT.  The user can add User Alarms to the DAT, and the HPI implementation may use this to update its status displays.  However, the user has no control over how, or even if the User Alarm is displayed in the system, nor any way of displaying non-alarm status information.

 

An HPI implementation may make any or all of these interfaces available.  For example:

1) Each LED, text panel, audible alarm, alarm relay, etc., may be modeled as an individual HPI Control.  This allows an HPI user to take direct control of each device, if desired.  These HPI Controls can also be modeled in "Auto Mode", allowing the HPI implementation to control them as part of a "logical display" tied to an HPI Annunciator.

 

2) Each "logical display" collection of LEDs, text panels, etc., that are used together to display status information can be modeled as an HPI Annunciator.  This allows an HPI user to interface in a portable way with the "logical display" by reading and writing Announcements.  The Annunciator can be implemented by software (within the HPI implementation) that analyzes the current set of Announcements and drives the "logical display" by changing the Control State of the individual HPI Controls tied to each LED, text panel, etc.

 

3) If the HPI implementation automatically drives platform displays from the contents of a DAT, it can also define Annunciators for each logical display, and then automatically populate Announcements in those Annunciators from the DAT.  If the Annunciators can be changed to "User" mode, this allows the user to override the automatic status display provided by the HPI implementation.  Even if the Annunciator does not allow User access - i.e., if the Annunciator is configured to operate only in "Auto" mode – there are arguments for exposing to the user what status information is being displayed by reflecting it in an HPI Annunciator.

 

 

 

 

 

The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

 

-----Original Message-----
From: David Judkovics [mailto:djudkovi@us.ibm.com]
Sent: Thursday, August 18, 2005 7:17 AM
To: Swortwood Bill-G3666C
Cc: Todd, Charlene J; Daniel F de Araujo; Konrad Rzeszutek; saf mib
Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB

 

Swortwood Bill-G3666C wrote:

 

>The response was

> 

>" Announcements are a type of Management Instrument (like controls, sensors, etc.).  I would generally see them under the RDR branch of the tree, and not under the event or event log branch of the tree.  Though they sometimes capture events as Annunciator Conditions,

> 

Charlene,

 

This would validate the current location of the AnnouncementTable, which

is the Event branch. 

 

The AnnouncementTable under the EventLog branch has beed removed.

 

I have not moved the AnnouncementTable to the Reources branch.  If this

is to be done today is the day.    If we were to do this we should

create a new branch/folder that is the Annunciator Branch and within

that branch should be the EntryCount for the AnnunciatorTable, the

AnnunciatorTable and the AnnouncementTable.

 

To me the creation and/or existance of an Announcement is very much

analygous to an event.  Therefore I am comfortable leaving the

AnnouncementTable in its present location.   And I am willing to move it.

 

DJ

 

>they aren't trying to emulate the event log functionality.  "

> 

> Reading further, it looks like the logging of events should be handled by other table objects.

> There seems to be no compelling reason to keep the table, according to Charlene.

> 

> Make it go bye-bye.

> 

> That help ?

> 

>- Bill

>

> 

>-----Original Message-----

>From: David Judkovics [mailto:djudkovi@us.ibm.com]

>Sent: Wednesday, August 17, 2005 2:30 PM

>To: Swortwood Bill-G3666C

>Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib

>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB

>Importance: High

> 

>Swortwood Bill-G3666C wrote:

> 

> 

>>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to

>>forward back the current HPI MIB?

>>

>>- Bill

>>   

>> 

> 

>Yes,

> 

>And we have on one unanswered question.  Should the saHpiAnnouncementEventLogTable be removed.

> 

> From Charlene's repsonse I believe the answer is yes.  And I would like a definitive YES or NO from her.

> 

>If the answer is YES the remove of the table is something you could do if we are running short on time or I can do it within 30 minutes of a resolution and checkin to SF and email you a copy.

> 

>If you feel its no big deal we have a useless table we can proceed now. 

>Your call.

> 

> 

>>----------------------------------------------------------------------

>>--

>>From: David Judkovics [mailto:djudkovi@us.ibm.com]

>>Sent: Friday, August 12, 2005 2:18 PM

>>To: David Judkovics

>>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;

>>Konrad Rzeszutek; saf mib

>>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB

>> 

>>David Judkovics wrote:

>> 

>>   

>> 

>>>The two columnar nodes have been added in order to support the acknowledging of Domain Alarms and Annoucements based on severity.

>>> 

>>>Also a AnnunciatorNum columnar node has been added to support the Ack'ing in any mode of Announcements in the saHpiAnnouncementTabe().

>>> 

>>> 

>>>saHpiDomainAlarmTable:

>>> 

>>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE

>>>       SYNTAX SaHpiSeverity

>>>       MAX-ACCESS read-create

>>>       STATUS current

>>>       DESCRIPTION

>>>               "Use this columnar node to acknowledge Alarms based on severity.

>>>         An HPI SNMP Manager acknowledges an alarm to indicate that it is aware of the alarm

>>>               and to influence platform-specific alarm annunciation that may be provided 

>>>               .

>>>         .

>>>         .

>>>         .

>>> 

>>>               "

>>>       ::= { saHpiDomainAlarmEntry 5 }

>>> 

>>>saHpiAnnouncementTable:

>>> 

>>>Two new columnar nodes have been added.

>>> 

>>> 

>>>saHpiAnnunciatorNum OBJECT-TYPE

>>>

>>> 

>>>     

>>> 

>>Named changed to

>> 

>>    saHpiAnnouncementAnnunciatorNum OBJECT-TYPE

>> 

>>For consistency.

>> 

>>   

>> 

>>>       SYNTAX SaHpiInstrumentId

>>>       MAX-ACCESS read-create

>>>       STATUS current

>>>       DESCRIPTION

>>>               "Annunciator number for the addressed Annunciator."

>>>       ::= { saHpiAnnouncementEntry 2 }

>>> 

>>> 

>>>saHpiAnnouncementAckBySeverity OBJECT-TYPE

>>>       SYNTAX SaHpiSeverity

>>>       MAX-ACCESS read-create

>>>       STATUS current

>>>       DESCRIPTION

>>>               "Use this columnar node to acknowledge

>>>         all Announcements of a particular severity."

>>>       ::= { saHpiAnnouncementEntry 7 }

>>> 

>>> 

>>> 

>>> 

>>>Best Regards/ Mit freundlichen Grüssen

>>> 

>>>David Judkovics

>>> 

>>>dmjudkov@us.ibm.com

>>>Adv. Software Engineer

>>>LTC xSeries Linux

>>>IBM Server -- Endicott, NY

>>>Tel: 607-429-4745 - Tie 620-4745

>>> 

>>>     

>>> 

>> 

> 

>