Alert Management Service Avatar
  1. OMG Specification

Alert Management Service — Closed Issues

  • Acronym: ALMAS
  • Issues Count: 49
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
ALMAS-50 Topic GetFilledMessageText needs ReceiverID attribute ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-49 In the PIM, when creating an Alert ( RaiseAlertFrom...) ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-48 Struct ALMAS_GetFilledMessageText ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-47 Operation Operation RemoveAlertsWithDynamicMessageData: ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-46 Operation RaiseAlertFromOverrides ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-45 Operation RaiseAlertFromOverrides ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-44 Type of element name "Tag" not correct ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-43 Definition and behaviour of AlertDistributionNotification is not consistent ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-42 ConfirmReceipt contains parameter ReceiverID ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-41 Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-40 ALMAS - IDL COM Corrections - Use SAFEARRAYs instead of the UDT array types ...TypeSet ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-39 Section 6.2, 7.1: Name inconsistency ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-38 Section 6.3.6: RegisterReceiver ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-37 Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType? ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-36 Enable receiver hierarchy per alert template? ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-35 Operation Unregister should be UnregisterReceiver ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-34 Consistently start methods with capitals (or not). ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-33 UpdateAlert not useful, so remove it from the spec ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-32 Removal of alerts is not clearly addressed in the spec ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-31 Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-30 mapping a number of methods ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-29 RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert). ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-28 DynamicMessageData instances ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-27 Catgorisation rules ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-26 ALMASReceiver.stateChangeNotification(int, Enumeration) ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-25 Attribute TimeoutAction ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-24 priority attribute value ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-23 Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides) ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-22 Method GetAllTemplateIDs of ALMASManager not mapped ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-21 ALMAS configuration files contain not valid xsd constructs ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-20 2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-19 Sections 2.6.1.3, 2.7.4.2, 2.8.1.3 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-18 Section 2.6.1.1 ALMAS_DataModel.idl ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-17 Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-16 Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-15 Section 2.8.1.3 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-14 ALMAS DCOM IDL corrections: Sections 2.8.11 & 2.8.1.3 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-13 Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length" ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-12 ALMAS Template Alert Data specification schema - Current schema only allows one Alert Template per XML file ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-11 2.3.3.1.1 ReceiverKind Operations ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-10 2.3.2.8 DataTag ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-9 2.3.2.3 AlertDataExtraAttributes ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-8 2.3.2.1 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-7 Section 2.3.2.1 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-6 Section 2.3.1 & 2 ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-5 2.3 General ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-4 2.3.1 ALMAS Client Callbacks ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-3 2.2 Conformance requirements ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-2 Section 2.1 ALMAS 1.0b1 ALMAS 1.0 Resolved closed

Issues Descriptions

Topic GetFilledMessageText needs ReceiverID attribute

  • Key: ALMAS-50
  • Legacy Issue Number: 13176
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Topic GetFilledMessageText needs ReceiverID attribute because a ReceiverID may set a specific language (Topic ALMAS_SetLanguage). Proposed solution: Add attribute ReceiverID to topic GetFilledMessageText

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update IDL in section 9.3.2

  • Updated: Fri, 6 Mar 2015 20:57 GMT

In the PIM, when creating an Alert ( RaiseAlertFrom...)

  • Key: ALMAS-49
  • Legacy Issue Number: 13175
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    In the PIM, when creating an Alert ( RaiseAlertFrom...) it is required that the created Alert is returned as an out parameter (AlertID). This is omitted in the DCPS PSM. Here only the result in terms of successfull/not successfull is returned by means of a topic. Note that the created AlertID might be needed by the ALMASProducer for subsequent calls. Proposed solution: Define a new topic, called ALMAS CreatedAlert, containing request_id and AlertID.

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update IDL in section 9.3.2

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Struct ALMAS_GetFilledMessageText

  • Key: ALMAS-48
  • Legacy Issue Number: 13174
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Struct ALMAS_GetFilledMessageText: No way is defined to return the filled message text. Proposed solution: Define a new topic, called ALMAS FilleMessageText, containing request_id and filled messages.

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update IDL in section 9.3.2 to create a new topic called ALMAS_FilledMessageText which has a long long request_id and ALMAS_StringSet Messages.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Operation Operation RemoveAlertsWithDynamicMessageData:

  • Key: ALMAS-47
  • Legacy Issue Number: 13173
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Operation Operation RemoveAlertsWithDynamicMessageData: "RelatedObject Value" not defined in specification. Proposed solution: Replace "ObjectName: String" by "DataType: String" + "DataValue: String". These two together form the unique identification.

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Proposed solution: Replace "ObjectName: String" by "DataType: String" + "DataValue: String". Also remove mention of RelatedObject from description. Affects section 6.3.4, 8.4, 9.4.2, 10.4

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Operation RaiseAlertFromOverrides

  • Key: ALMAS-46
  • Legacy Issue Number: 13172
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Operation RaiseAlertFromOverrides: "SecondaryGrouping", "Persistent" and "ReliablyDistributed" omitted. Proposed solution: Add "SecondaryGrouping", "Persistent" and "ReliablyDistributed".

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Add in the additional parameters as proposed.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Operation RaiseAlertFromOverrides

  • Key: ALMAS-45
  • Legacy Issue Number: 13171
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Operation RaiseAlertFromOverrides: "Message: String" not correct. Proposed solution: Should be "StaticMessageDataSet: StringSet".

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Operation RaiseAlertFromOverrides needs to be able to set more than one message text and language. The proposal is to replace "Message: String" and MessageLanguage with a StaticMessageSet parameter.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Type of element name "Tag" not correct

  • Key: ALMAS-44
  • Legacy Issue Number: 13170
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Issue: Type of element name "Tag" not correct. Proposed solution: Type should be string instead of integer.

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Tag element type should be string not integer. XML in section 7.1to be updated

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition and behaviour of AlertDistributionNotification is not consistent

  • Key: ALMAS-43
  • Legacy Issue Number: 13169
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    The name implies that the alert has been distributed, however the description says: "...has been received..." and the sequence diagram also shows that that the alertDistributionNotification is called as soon as the alert command has been received by ALMAS. Proposed solution: Since the intention of the AlertDistributionNotification is to confirm receipt of safety critical alerts, it is logical to include the distribution of the alert because a receiver alert command may effectively not result in a alert. This could happen because it is inhibited or there are no receivers available in the system. Therefore, in Figure 6.7 (Page 30) move sequence 3.1.1 to 3.1.6. Alternatively, alert distribution could be excluded, renaming alertDistributionNotification into alertCmdReceived

  • Reported: ALMAS 1.0b1 — Fri, 19 Dec 2008 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Change text for AlertDistributionNotification , section 6.1.1, to be: "This is called as soon as a safety critical alert has been received by the ALMAS system. The onward distribution is notified through the StateChangeNotification callback."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ConfirmReceipt contains parameter ReceiverID

  • Key: ALMAS-42
  • Legacy Issue Number: 13042
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    ConfirmReceipt contains parameter ReceiverID. This parameter seems to be not neccessary since ConfirmReceipt of one Responder is enough to enter the Received state. Solution: Remove parameter.

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Add to the description for Confirm Receipt of ALMASResponder in 6.3.6 "The ReceiverID field enables action & situation alerts to transition when sufficient confirmations have been received. 'Sufficient' is the 'actionee' for action alerts, and anyone for situation alerts. It can also be used for logging purposes.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction

  • Key: ALMAS-41
  • Legacy Issue Number: 13037
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update ALMAS Data Model IDL

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ALMAS - IDL COM Corrections - Use SAFEARRAYs instead of the UDT array types ...TypeSet

  • Key: ALMAS-40
  • Legacy Issue Number: 13034
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    We should be using the DCOM SAFEARRAY type instead of the UDT array types ALMAS_ReceiverKindTypeSet, ALMAS_DynamicMessageDataTypeSet, ALMAS_StaticMessageTypeSet, ALMAS_AlertDataExtraAttributesTypeSet.

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update the DCOM IDL in section 10.2 and 10.4

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 6.2, 7.1: Name inconsistency

  • Key: ALMAS-39
  • Legacy Issue Number: 13033
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Section 6.2, 7.1: Name inconsistency: AlternativeAction in section 6.2 is Alert_Responses in section 7.1. Solution: Use the same names.

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Use AlternativeAction in 7.1

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 6.3.6: RegisterReceiver

  • Key: ALMAS-38
  • Legacy Issue Number: 13032
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Section 6.3.6: RegisterReceiver: Parameter AvailableAlertReceiver.ReceiverKind.RKParentType can not be filled by the caller with useful information because it is not relevant here. Solution: Remove this parameter

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    See updated model, updated figure 6.3, change text for 6.3.6 RegisterReceiver as follows:
    replace parameters to be ALMASReceiver, String, String
    replace description as follows: This registers a receiver with ALMAS, the parameters are ReceiverHandle (for callback); ReceiverID (for use in all other methods, including UnregisterReceiver) and RKType to provide link to RK hierarchy.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType?

  • Key: ALMAS-37
  • Legacy Issue Number: 13030
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType? RKParentType is a string (1 ..10) in which whitespaces are allowed. Solution: Specify that no ReceiverKind.RKParentType is indicated by only whitespaces in the string. Or change stringtype string (0 .. 10) for which string(0) indicates no ReceiverKind.RKParentType

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Add to 6.2.9 description that a lack of a Parent is indicated by an empty string.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Enable receiver hierarchy per alert template?

  • Key: ALMAS-36
  • Legacy Issue Number: 13029
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Hierarchy, as can be specified according the Receiver Hierarchy Configuration file is alert (Template) independent. Is this not too restrictive? Solution: Enable receiver hierarchy per alert template?

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Operation Unregister should be UnregisterReceiver

  • Key: ALMAS-35
  • Legacy Issue Number: 13028
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Operation Unregister should be UnregisterReceiver

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    6.3.6 Replace operation Unregister by UnregisterReceiver.

    Also update the IDL in 8.4, 9.3.2, 9.4.2, 10.4

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Consistently start methods with capitals (or not).

  • Key: ALMAS-34
  • Legacy Issue Number: 13027
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Consistently start methods with capitals (or not).

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Figure 6.1:
    stateChangeNotification => StateChangeNotification
    alertDataNotification => AlertDataNotification
    alertDistributionNotification => AlertDistributionNotification
    6.1.2:
    stateChangeNotification => StateChangeNotification
    alertDataNotification => AlertDataNotification

  • Updated: Fri, 6 Mar 2015 20:57 GMT

UpdateAlert not useful, so remove it from the spec

  • Key: ALMAS-33
  • Legacy Issue Number: 13026
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    UpdateAlert:By means of an UpdateAlert a producer can update an already raised alert with new AlertData as parameter. Two problems here: 1. The producer may change all attributes of the AlertData making this very complex to realise. However, most, if not all attributes, are not likely te be changed. 2. The alert may already be partly (by some addresses) handled making the realisation even more complex. Solution: UpdateAlert not useful, so remove it from the spec.

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Reduce the scope of UpdateAlert to cover the change of priority and rename to be UpdateAlertPriority. Update figure 6.3, section 6.3.5 and the management IDL files

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Removal of alerts is not clearly addressed in the spec

  • Key: ALMAS-32
  • Legacy Issue Number: 13025
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Removal of alerts is not clearly addressed in the spec. Should be addressed explicitly. Solution: Alerts are removed as follows: . For all alert categories holds that they are removed when cancelled by the producer. . Information and Warning alerts: Removed when an acknowledge is required and the appropriate acknowledge is given or when a timeout is defined when the timeout is expired or when no timeout is defined a general (adaptable) timeout is assumed. . Action alert: Removed when HandleAlert is called by all addressees. . Situation alert: Will not be removed when HandleAlert is called by all addressees. Will only be removed if cancelled by producer.

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Covered as part of issue 12290 response.
    For clarity the updates to section 6.3 are repeated here:
    · For all alert categories, an alert is removed when cancelled. Note that Situation alerts are only removed when cancelled.
    · Information and Warning alerts are removed when the required number of acknowledgements (as identified in the AlertData AcknowledgementModel attribute) are given or (if a timeout is defined) when the timeout is expired.
    · Action alerts are removed when HandleAlert is called by the Receiver identified as the Actionee in its AlertReport.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01

  • Key: ALMAS-31
  • Legacy Issue Number: 13024
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Copy correct picture and update figure 6.6 to same style.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

mapping a number of methods

  • Key: ALMAS-30
  • Legacy Issue Number: 13022
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It would be better to map a number of methods, which are now directly mapped on DDS level constructs, on control topics because of two reasons: 1. Without control topics a producer can not be directly notified of a producer or system related error/problem. E.g. when a producer produces a new alert, he can not be notified that this was not succesfull because no active receivers are present. 2. Much more important: An alert contains ""static"" information but also state information (e.g. AlertId, Currentstate, Receivers etc.). Only ALMAS should be allowed to maintain this information, not a producer. Because a producer can now write a complete Alert, it may also write state information. This would violate data hiding principles and therefore ALMAS would be unnecessarely complex and obscure. Solution: The following methods should map on control topics: 1. UpdateDynamicMessageData 2. SetAlertInhibited 3. RemoveAlertsWithDynamicMessageData 4. RaiseAlertFromOverrides 5. RaiseAlertFromData 6. UpdateAlert

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Remove the following items from table in section 9.3.2:
    ALMAS Manager - UpdateDynamicMessageData
    ALMAS Manager - SetAlertInhibited
    ALMAS Manager - RemoveAlertsWithDynamicMessageData
    ALMAS Producer - RaiseAlertFromOverrides
    ALMAS Producer - RaiseAlertFromData
    ALMAS Producer - CancelAlert

    Add the following new topics ALMAS_UpdateDynamicMessageData,
    ALMAS_SetAlertInhibited, ALMAS_RemoveAlertsWithDynamicMessageData , ALMAS_RaiseAlertFromOverrides,
    ALMAS_RaiseAlertFromData,
    ALMAS_CancelAlert
    to DCPS IDL
    For the purpose of these new topics, note that attributes are removed from struct ALMAS_AlertDataType and now contained in new struct ALMAS_AlertDataAttributesType.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert).

  • Key: ALMAS-29
  • Legacy Issue Number: 13021
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert). ALMAS must know which ReceiverKinds are active in the system at a certain moment. For example which roles are played that are interested in alerts. A (future) Role management system will not export such a relation because it will not import ALMAS particulars. Worse, it is not even able to do so because in OpenSplice it is not possible to determine which listeners are present for a certain topic. Even when that would be possible, there is no way to relate listeners to e.g. roles. Solution: For registration declare a new topic containing a RKType?

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Remove ALMAS Responder - RegisterReceiver from table in section 9.3.2.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

DynamicMessageData instances

  • Key: ALMAS-28
  • Legacy Issue Number: 13020
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    The number of DynamicMessageData instances is fixed for an Alert(Template). This means that for a specific Alert only a fixed maximum number of tags can be used. When you want to raise an alert like "Tracks present in an area", this number should be dynamic.

  • Reported: ALMAS 1.0b1 — Fri, 31 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Remove the number limitations of items Static_message, Alert_Data_extra_Attributes, Dynamic_Message_Data, Alert_Routing from the Alert_definitions.xsd file and item Receiver_Kind from the ALMAS_Hierarchy.xsd configuration file.
    Note that also fixed string lengths as defined in the configuration files are unnecessarily restrictive and should be removed.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Catgorisation rules

  • Key: ALMAS-27
  • Legacy Issue Number: 13019
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Catgorisation rules must be defined offline by means of the "ALMAS categorisation rule file". Rules can be attached and detached to alerts by means of methods "AttachCategorisationRule" and "DetachCategorisationRule". An alert can only be attached after it exists, so after it is raised. However, the intention of categorisation is to do an action (e.g. raising an alert) according to a condition on occurence of an event. There seems to be a chicken-and-egg problem. Solution: Attach/detach AlertTemplate instead of Alert?

  • Reported: ALMAS 1.0b1 — Thu, 30 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update figure 6.3 and section 6.3.4 - Use TemplateID instead of AlertID as parameter for both Attach… and Detach… methods. Change alert to AlertTemplate in both descriptions.

    Update IDL for these methods.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ALMASReceiver.stateChangeNotification(int, Enumeration)

  • Key: ALMAS-26
  • Legacy Issue Number: 13018
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    ALMASReceiver.stateChangeNotification(int, Enumeration): The values of the Enumeration are not specified. Solution: Same enumerations as for Alert.CurrentState.

  • Reported: ALMAS 1.0b1 — Thu, 30 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Add to 6.1.2 the following "These states are the same states as used in CurrentState for an Alert."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attribute TimeoutAction

  • Key: ALMAS-25
  • Legacy Issue Number: 13017
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Attribute TimeoutAction: There seems to be no way to inform somebody about a timeout. Solution: Enable notification by ALMASReceiver.stateChangeNotification(int, Enumeration) and adding Timed_Out to the enumeration.

  • Reported: ALMAS 1.0b1 — Thu, 30 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Change 6.2.1 description for CurrentState to include "Timed_Out" after "Cancelled"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

priority attribute value

  • Key: ALMAS-24
  • Legacy Issue Number: 13016
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Is the priority attribute value independent of the category meaning that an information alert can have a higher priority than a situation alert?

  • Reported: ALMAS 1.0b1 — Thu, 30 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Add to 6.2.2 description for Priority "the priority is open for client use and not intended for interpretation by ALMAS."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides)

  • Key: ALMAS-23
  • Legacy Issue Number: 13015
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    By means of RaiseAlertFromData an alert can be raised that is not present in the ALMAS template database. However, receivers (ReceiverKind, see Section 6.2) can only be associated with templates. How can receivers now be defined? Solution: Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides)?

  • Reported: ALMAS 1.0b1 — Mon, 9 Feb 2009 05:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    To reduce the complexity of this the approach taken is to change the AlertData parameter type to be an AlertTemplate parameter - this is not read or initialised from the XML, so the TemplateID field is invalid, but it reduces the complexity of the interface significantly.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Method GetAllTemplateIDs of ALMASManager not mapped

  • Key: ALMAS-22
  • Legacy Issue Number: 13014
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Method GetAllTemplateIDs of ALMASManager not mapped. Solution: Map to: DDS read with query condition.

  • Reported: ALMAS 1.0b1 — Thu, 30 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Add to table on page 59 one row below method GetTemplate:
    "ALMAS Manager - GetAllTemplateIDs (String, TemplateIDSet) - DDS read with query condition"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ALMAS configuration files contain not valid xsd constructs

  • Key: ALMAS-21
  • Legacy Issue Number: 13013
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    ALMAS configuration files contain not valid xsd constructs. E.g. Alert_Definitions.xsd/24-01-2008: xs:restriction not terminated. ALMAS_Categorisation.xsd/23-01-2008: space chars invalid in some attributes. ALMAS_Hierarchy.xsd/24-01-2008: invalid characters (--) in element. Solution: Validate configuration files with appropriate xml editor.

  • Reported: ALMAS 1.0b1 — Thu, 30 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    XSD files validated.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs

  • Key: ALMAS-20
  • Legacy Issue Number: 12994
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs - cannot return data directly. Will need to be returned from additional callbacks on the appropirate interfaces, so out parameter now removed and replaced with an input parameter to pass in the receiver's handle.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    This affect the DCOM interface for ALMAS Notification Listener in section 10.3

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sections 2.6.1.3, 2.7.4.2, 2.8.1.3

  • Key: ALMAS-19
  • Legacy Issue Number: 12993
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Sections 2.6.1.3, 2.7.4.2, 2.8.1.3 Query - Method UpdateDynamicMessage takes in OldValue - why?

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No change to model

    Add the following to UpdateDynamicMessageData description in 6.3.3:
    "OldData is necessary in order to clearly indicate which dynamic message data should be changed."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2.6.1.1 ALMAS_DataModel.idl

  • Key: ALMAS-18
  • Legacy Issue Number: 12992
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Added prefix "ALMAS_" to enums to avoid conflict with existing definitions within our system.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    This is only necessary for the DCOM mapping and affects IDL in section 10.2 only

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides

  • Key: ALMAS-17
  • Legacy Issue Number: 12991
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides - optional parameters are not supported in C++ as defined in version 7 page 37 for this method. 'Optional' parameters can be supported if the parameters are changed to pointers. Parameters that are not required can then be passed in as NULL.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Propose that the method is amended to include a 'valid' indicator for each optional parameter in the PSMs.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter

  • Key: ALMAS-16
  • Legacy Issue Number: 12990
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter. Some methods define it as CallStatus, others as Status. Suggest we change methods which define the parameter as Status to CallStatus.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Carry out the change for section 8.3, 10.3, 10.4 as in attached IDL. For section 6.1.1 remove Status from the parameters

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2.8.1.3

  • Key: ALMAS-15
  • Legacy Issue Number: 12989
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    _put_ALMAS_SystemID - parameter changed to "in out" instead of "in" because of compiler limitation for parameter type BSTR.
    GetFilledMessageText - parameter MessageText changed to "in out" instead of "out" - compiler limitation for type BSTR.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Remove put_ALMAS_System_ID this is not intended to be alterred by the ALMAS user.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ALMAS DCOM IDL corrections: Sections 2.8.11 & 2.8.1.3

  • Key: ALMAS-14
  • Legacy Issue Number: 12988
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Sections 2.8.11 & 2.8.1.3 LPSTR types should be changed to BSTR (automation type).

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Agreed - this affect the DCOM IDL files in sections 10.2, 10.3, 10.4.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length"

  • Key: ALMAS-13
  • Legacy Issue Number: 12987
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length" for the Text variable data to aid sizing the final text when attempting to expand the dynamic text.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ALMAS Template Alert Data specification schema - Current schema only allows one Alert Template per XML file

  • Key: ALMAS-12
  • Legacy Issue Number: 12986
  • Status: closed  
  • Source: BAE SYSTEMS ( Stephen Gilfillan)
  • Summary:

    Current schema only allows one Alert Template per XML file. Correct to allow more than one alert.

  • Reported: ALMAS 1.0b1 — Tue, 28 Oct 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.3.3.1.1 ReceiverKind Operations

  • Key: ALMAS-11
  • Legacy Issue Number: 12296
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    Each of these operations, in fact, only work with an XML file that conforms to a particular XSD, which is defined later in the specification. This needs to be made explicit

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    6.3.1 table row entries need updating to reflect the XML file linkages.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.3.2.8 DataTag

  • Key: ALMAS-10
  • Legacy Issue Number: 12295
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    the format of this string needs to be specified so that different products can parse it consistently and thus can interoperate.

  • Reported: ALMAS 1.0b1 — Fri, 21 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Clarify format of the string.
    Update 6.2.10 table description for MessageText:
    This is a text string, which in an Alert or AlertTemplate is only partially completed. With the MessageText being "xxxxx %t1 yyyyyyy zzzz" in an Alert or AlertTemplate, and with a DynamicMessageData with DataTag having the value 't1' and DataValue having the value '123' then the resulting MessageText in response to GetFilledMessageText will be 'xxxxx 123 yyyyyyy zzzz'. All substitution points are bracketed by use of "<space>%" and <space>, and are case sensitive, alphanumeric strings ("t1" in the above) which should correspond to a DataTag in an associated DynamicMessageData.
    Update text for DataTag in 6.2.8:
    This identifies the insertion point for the related object in the MessageText associated with the Alert. I.e. where the MessageText is "xxxxx %t1 yyyyyyy zzzz", then DataTag has the value 't1'. It is a case sensitive, alphanumeric string

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.3.2.3 AlertDataExtraAttributes

  • Key: ALMAS-9
  • Legacy Issue Number: 12294
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    This section provides an extension mechanism for AlertData so that this data can safely be transferred to products that don't understand the extensions. The requirements that receipt of any of this data not be "dropped" etc. need to be clarified. Also, there should be the possibility for providing a "type" indication (possibly either a string or enumeration) that would allow different products to interpret different extensions.

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Need to update Figure 6.2 and 6.2.3 AlertDataExtraAttributes attributes table:
    1) add attribute "TypeOfByteData" of type int, with the description of
    "Valid values for this are:
    0 = string
    1 = Integer8
    2 = Integer16
    3 = Integer32
    4 = Float32
    5 = Float64
    6 = bytes"
    2) add attribute "Description" of type string with description "Used to provide indicaton of the content e.g. "image (jpg)", "URL", "track object", ..."
    Replace the last sentence of the AlertDataExtraAttributes description
    'The extra attributes are configured via the ALMAS Alert definition xml PSM specified in section 7.1. If defined in the Alert definition XML provided to ALMAS, then ALMAS shall support the definition, receipt, storage and passing of this data to receivers as part of a standard implementation.'

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.3.2.1

  • Key: ALMAS-8
  • Legacy Issue Number: 12293
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    The text for the attribute CurrentState implies that there is a constraint between the allowed values and the category of the alert. These constraints need to be formally captured, e.g., through OCL.

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Update the model as described below and the text in section 6.2.1.:
    1) give a name to association between Alert and Alert Data on AlertData end of "alert_data"
    2) include an OCL constraint for this: "context a: Alert inv: if ((a.alert_data.Category = Information) or (a.alert_data.Category = Warning))) then (a.CurrentState <> Handled)"
    Documentation changes required to section 6.2.1 description for current state in attributes table to append 'Note that Handled is not a valid state for Information and Warning Alerts.' Figure 6.2 requires update to show the constraint.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2.3.2.1

  • Key: ALMAS-7
  • Legacy Issue Number: 12292
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    The description of Alert has the text: "The message text is not fully filled in here." This looks like an editorial comment.

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2.3.1 & 2

  • Key: ALMAS-6
  • Legacy Issue Number: 12291
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    It is real error that there is no relationship (including possibly a derivation) between AvailableAlertReceiver and ALMASReceiver. A link by a string name doesn't allow type-safe technology to check the proper provision of a ALMASReceiver as a available receiver.

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No change to the model has been made. The following additional text has been added to section 6.2.6 (as part of resolution of issue 12290): '…through the ReceiverID attribute, which is provided at registration time to ALMAS using the RegisterReceiver method.'

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.3 General

  • Key: ALMAS-5
  • Legacy Issue Number: 12290
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    the descriptions of the model elements are not sufficient. For example, the description of ALMASNotificationListener is "Class provided by registering notification listeners for receipt of alert distribution notifications", which is not much more descriptive than the name of the class

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Included significantly more descriptive text in the model section of the specification. Section 6, 6.1, 6.2, 6.3 affected significantly. Edited text supplied as additional change-barred document, attached. Note that this issue should be applied FIRST, there are some additional changes to the text in section 6 which should be applied after this issue.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.3.1 ALMAS Client Callbacks

  • Key: ALMAS-4
  • Legacy Issue Number: 12289
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    ALMAS Client Callbacks (comment on a previous version that has not been addressed) Package names or parts of the package names are reused and redundant within the class name. Examples include ALMAS::Client Callbacks::ALMASReceiver and ALMAS::Client Callbacks::ALMASNotificationListener

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Removed the redundant names. Replace section 10.3 with the following IDL (changes annotated with comments):

  • Updated: Fri, 6 Mar 2015 20:57 GMT

2.2 Conformance requirements

  • Key: ALMAS-3
  • Legacy Issue Number: 12288
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:
    • Conformance level 0 seems to me so weak that it may actually detract from the specification, i.e., the ability to conform at level 0 is so easy that it is not clear that any vendor would invest in Level 1 conformance.
    • The statement in clause c) seems not to capture the intended conformance options. In our discussions, I think we agreed that we need an explicit list of optional conformance points and a statement of the ability to independently conform to each.
  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    Replace all text in section 2 of beta 1 with the following revised text.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2.1

  • Key: ALMAS-2
  • Legacy Issue Number: 12287
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    This section seems to be misplaced. It is a table without headings or other explanations

  • Reported: ALMAS 1.0b1 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — ALMAS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT