OMG C4I DTF

1
OMG C4I DTF

• User, Role and Alert Management
• OMG Technical Committee Meeting
• Orlando, FL, USA
• 20. 25.02.2004
• Dr. Zbigniew Marciniak

2
Common understanding issuesBefore we start

• We need exact definitions for user and roles in
  the context of the CMS
• We need exact definitions of information types
  managed by the alert management
• What is an Alert
• Do we have Alerts and Alarms? What is a
  difference
• We we distribute other type of operator
  notifications e.g. warnings and/or pure
  information without the warning-alert-alarm
  semantics
• What exactly do we want to support
• System with both user and role management only?
• System with user management but without role
  management?
• System with role management but without user
  management?
• System where both user and role management are
  not available?
• We need exact definitions for the scope and
  relationships of services managing users

3
Common understanding issueseven more basic
questions

• We need exact definitions for the scope and
  relationships of services managing users, roles
  and alerts in the CMS with other HLS e.g.
• Application management
• System monitoring
• World/Session management
• Application instrumentation
• We need more information about the relationship
  of services managing users, roles and alerts to
  the tactical parts of the CMS e.g.
• Control of sensors
• Control of actuators
• Control of functional tasks

4
Basic requirements for user and role management

• The user management shall allow to
• define, modify and delete users
• check that a user is known and the given password
  is correct.
• store the current list of users on demand.
• load previously stored list of users on demand
  and during start-up.
• get the list of users on demand.
• The role management interface specification shall
• allow to define, modify and delete roles.
• allow to
• store the current set of roles on demand.
• load previously stored sets of roles on demand
  and during start-up.
• get a list of available roles for a given user on
  demand.
• provide a PIM for the following properties
• A role shall define which applications shall be
  started in this role.
• Assignment of one or more roles to a user.
• Assignment of zero or more users to a role.
• Role counter limit which indicates the number of
  users that may use this role simultaneously.

5
Basic requirements for alert management functions

• The submitter shall specify interfaces to accept
  alarms, warnings and other information dedicated
  to human operators.
• The submitter shall provide a PIM of the Operator
  Notifications which includes
• The message itself
• Message classification (alarm, warning,
  information, others)
• Who send the notification (i.e. specification of
  user and its role)
• Where the notification was created (i.e.
  application and node)
• When the notification was created (i.e. Timestamp
  of notification creation)
• How long the message is valid and how shall it be
  managed from time point of view (lifetime,
  increase time from information to warning and
  from warning to alarm)
• If and how an operator shall react to the message
  (Shall the Notification be acknowledged or
  answered? How and where the answer shall go?)
• The submitter shall provide a PIM for the
  following properties
• The multi-language Operator Notifications by
  configuration.
• Log file for Operator Notifications.
• Distribution of the Operator Notifications via
  standardized OMG notification service.
• The submitter shall specify
• Interface to retrieve the Operator Notifications
  on demand.
• Interfaces filter(s) for retrieval of Operator
  Notifications.
• Interface to set the sort criteria for retrieval
  of Operator Notifications.

6
Conclusion

• User, Role and Alert Management is not trivial in
  CMS
• A working group should be established to prepare
  the first context and scope description for these
  services (Navy as domain only?)
• C4I DTF should start drafting the RFP soon in
  order to issue these (both?) documents in 3. or
  4. Q. 2005