Alert Management

1
Alert Management

• A high level DD(X) perspective

2
Disclaimer

• These slides do not represent any official
  position for DD(X).
• They have been reviewed by HCI and HSI leads for
  DD(X) on the government and contractor side.

3
DD(X) view of alerts

• Realize that the Alert Management service is not
  directly concerned with HCI, however the
  requirements are driven by the end-use.
• We DD(X) approach the concept of alerts both
  action and informational from the perspective of
  creating a situational aware decision-maker and
  not an operator-initiated button Smasher
• The user is to be made aware of his/her
  situation, however they are not to spend any time
  processing alerts.

4
Usage features

• Goal contextual situational understanding
• The evidence of what alerts "used to be" is
  realized in the display
• No longer "process alerts" to form a mental
  picture of what they think the text based alerts
  mean
• Now Draw an understanding in real-time, in
  context of what is going on to decide on what to
  do.
• Some HCI modalities for delivery of
  understanding.
• changing shapes and colors and icons
• Text, descriptions, etc.
• avatars and noises

5
Example Damage Control

• There is a virtual ship GUI that reflects the
  ship's actual layout.
• Each compartment shows its status
• Green (OK), Yellow (degraded), Red (out), or
  black (No info).
• If you were to take a hit, the impacted
  compartments would become black (No info) giving
  an instant visual understanding of what
  compartments were effected.  
• As the sensors stabilize they become green,
  yellow, red or remain black (if destroyed), to
  reflect their actual condition.
• The operator first SEEs what has happened and
  then from that initial SA, they can begin to
  proactively work their way through the HCI and
  make decisions and form a pro-active and
  situationally aware point of view. 

6
(No Transcript)
7
Infrastructure Support

• How do you make the magic happen?

8
End-to-end Need

• A condition/alert/notice is generated within the
  system
• It is sent to the appropriate consumer(s)
• The consumer(s) processes the alert
• Previous Discussion
• If necessary, the producer is notified of the
  result

9
Issues

• Constraints on sending?
• The Alert object / package
• Delivery
• The recipient
• Callback

10
Constraints on sending

• I dont know if and what there is to put in here.

11
The Alert object / package

• Alert contains
• Timeliness
• Alert Category
• Alert Type (detailed context)
• Classification / Security Level
• Priority
• Intended recipient(s)
• role, software, user
• Data
• Text Message
• Audio
• Video
• Other Data
• Callback requirements

12
Delivery

• Elements in the system (software, human) put
  notices/alerts/information packets on the
  network.
• Alert Management determines the location of the
  intended recipient
• Working with User / Role / Org Management
• Working with Dynamic Resource Management
• Support
• Multiple recipient messages
• Single recipient messages
• Security preservation

13
The Recipient

• A client of the sent alert message
• Software system
• HCI / human recipient
• Determine available modalities for presentation
• Consider location / capabilities of recipient
• Consider busy channels of recipient
• HCI provides to alert in appropriate context /
  modalitiy
• Previous example

14
Callback

• Some alerts require response to the originator
• Immediate or delayed
• Some are information only and require no callback
• No longer servicing an alert queue
• Alert Management must transparently support this
  callback to notify sender where needed.

15
Clarification

• Not doing workload balancing task management
• Not doing dynamic task allocation