Alert Management Service Avatar
  1. OMG Specification

Alert Management Service — Closed Issues

  • Acronym: ALMAS
  • Issues Count: 121
  • 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
ALMAS13-22 The Dynamic Behaviour section isn't well referenced inside the specification ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-26 Implications on safety criticality ALMAS 1.1b1 ALMAS 1.3 Resolved closed
ALMAS13-17 Summary Description for RemoveAlertsWithDynamicMessageData is too specific ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-25 Poor description of TimeoutAction attribute ALMAS 1.1b1 ALMAS 1.3 Resolved closed
ALMAS13-14 Multi-language support mechanism is poorly described ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-28 Confusion between ALMAS Configuration and ALMAS Categorization ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-18 Clarity on use of AlertID ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-27 Ambiguity between ALMAS Client Callback Interfaces ALMAS 1.1b1 ALMAS 1.3 Resolved closed
ALMAS13-29 MIssing Acronyms and Abbreviations ALMAS 1.1b1 ALMAS 1.3 Resolved closed
ALMAS13-7 LoadTemplateSet error conditions ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-24 Ambiguity of TypeOfByteData attribute ALMAS 1.1b1 ALMAS 1.3 Resolved closed
ALMAS13-1 Ambiguity regarding raising alerts after calling SetAlertInhibited ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-3 Coordination of unique request IDs ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-11 Behaviour of SetLanguage operation is unclear ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-10 GetFilledMessageText doesn't account for different languages ALMAS 1.1 ALMAS 1.3 Closed; No Change closed
ALMAS13-9 Ambiguity in Routing Error Condition ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-16 Inconsistent optionality marking ALMAS 1.1b1 ALMAS 1.3 Resolved closed
ALMAS13-12 Error condition on SetLanguage ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-8 Semantics of undefined receivers ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-5 Receiver Hierarchy Error Conditions ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-13 No multi-language support for dynamic message data ALMAS 1.1 ALMAS 1.3 Resolved closed
ALMAS13-15 Meaning of Categorization Rules not clear when referenced ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-2 Register and Unregister Receiver are unnecessary in the DDS PSM ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-6 No mechanism to feedback alternative action choice ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-19 The role of ALMAS Manager is unclear ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-4 No standard DDS key specification ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-43 Unable to override extra attributes in alert template when raising an alert ALMAS 1.2b1 ALMAS 1.3 Deferred closed
ALMAS13-20 Standardisation of Logging ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-21 Operation tables for interfaces aren't easy to read ALMAS 1.1 ALMAS 1.3 Deferred closed
ALMAS13-23 CallStatus Reason should be an enumeration not an int ALMAS 1.1b1 ALMAS 1.3 Deferred closed
ALMAS12-46 Error in ALMAS_RaiseAlertWithDynamicData topic struct declaration ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-26 RaiseAlertFromOverrides Summary formatting ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-3 Greater Granularity and Clarity in Conformance Levels ALMAS 1.1b1 ALMAS 1.2 Resolved closed
ALMAS12-45 Inconsistency in DynamicMessageData param between PIM and PSM ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-63 DDS PSM Mapping rationale for the ALMAS_CreatedAlert topic is missing ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-21 Typo in RemoveAlertsWithDynamicMessageData Summary ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-44 Repeat of RaiseAlertFromOverrides in CORBA PSM ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-15 Use less colloquial language in ValidAlertResponse ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-37 Typo in AlternativeAction xml schema element ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-14 Rogue hyphen in DataValue attribute description ALMAS 1.1b1 ALMAS 1.2 Resolved closed
ALMAS12-43 Typo in CORBA PSM Section Heading ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-13 Ambiguity in dynamic message data substitution ALMAS 1.1b1 ALMAS 1.2 Resolved closed
ALMAS12-8 Formatting and duplication of Status description ALMAS 1.1b1 ALMAS 1.2 Resolved closed
ALMAS12-2 Remove Original Submission Information ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-27 UpdateAlertPriority summary grammar ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-25 ALMAS Producer component terminology ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-4 Incomplete Normative References ALMAS 1.1b1 ALMAS 1.2 Resolved closed
ALMAS12-28 UnregisterReceiver hyphen typo ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS12-1 Add GraphQL PSM for ALMAS ALMAS 1.1 ALMAS 1.2 Resolved closed
ALMAS11-30 RaiseAlertFromOverrides in DLRL is missing parameter name DynamicMessageData ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-29 URLs of machine readable PSM files to have PSM sub dir ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-28 Name of RaiseAlertWithDynamicData is ‘FromOverrides’ in the COM IDL and DLRL PSMs ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-27 Request Id for RaiseAlertWithDynamicData should be the typedef type ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-31 Use https in schema definitions ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-11 Efficient use of dynamic data ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-10 Optionality in RaiseAlertFromOverrides ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-9 Untyped enumerations in the PIM ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-8 Typedefs introduced in DDS PSM ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-7 Missing attributes of Class Alert Data in the DDS PSM ALMAS 1.0 ALMAS 1.1 Duplicate or Merged closed
ALMAS11-6 DDS PSM Rationale Incomplete ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-5 Class Alert Data has an inconsistent name in the DDS PSM ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-4 request_id should have its own type ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-12 Typo in struct ALMAS_AlertReportType ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-47 Issue ALMAS11-31 is wrong - XSD should be http not https ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-40 RaiseAlertFromOverrides still has a reference to ALMAS_AlertDataAttributesType ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-39 ALMAS_Template_Alert_Data.xsd use incorrect schema attributes ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-38 ALMAS 11-10 changes to be applied to the PSM IDL file ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-37 ALMAS 11-5 changes to be applied to PSM IDL file as well ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-36 ALMAS 11-4 to be applied to PSM IDL file ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-2 Filename is inconsistent with module name and other IDL modules ALMAS 1.0 ALMAS 1.1 Resolved closed
ALMAS11-3 Section 7.3 hierarchy ALMAS 1.0b1 ALMAS 1.1 Deferred closed
ALMAS11-1 Missing comma after cancelled enum ALMAS 1.0 ALMAS 1.1 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-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-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-46 Operation RaiseAlertFromOverrides ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-45 Operation RaiseAlertFromOverrides 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-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-44 Type of element name "Tag" not correct 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-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-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-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-4 2.3.1 ALMAS Client Callbacks 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-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-5 2.3 General ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-6 Section 2.3.1 & 2 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-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
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-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-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-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-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-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-33 UpdateAlert not useful, so remove it from the spec ALMAS 1.0b1 ALMAS 1.0 Resolved closed
ALMAS-26 ALMASReceiver.stateChangeNotification(int, Enumeration) ALMAS 1.0b1 ALMAS 1.0 Resolved closed

Issues Descriptions

The Dynamic Behaviour section isn't well referenced inside the specification

  • Key: ALMAS13-22
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Section 6.5 on Dynamic Behaviour would aid the understanding of the other parts of section 6, but it's existence isn't well sign-posted within the section. The roles of the interfaces declared aren't very clear with the sequence diagrams in particular needed to show where all the parts fit in.

  • Reported: ALMAS 1.1 — Sat, 5 Feb 2022 15:58 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Signpost behavior subsection from the start of section 6

    Add an overview from the beginning of section 6 that introduces the PIM.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Implications on safety criticality

  • Key: ALMAS13-26
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The specification appears to imply functionality that should be applied in the case of safety critical systems - ConfirmationRequired attribute of AlertData. This is in appropriate - the spec should do no more than offer this as an example use case for potential mitigation.

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 13:26 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Remove references to safety criticality

    Remove references to safety critical system design. Use of ALMAS should in no way be suggestive of contributing to a safety case.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Summary Description for RemoveAlertsWithDynamicMessageData is too specific

  • Key: ALMAS13-17
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The Summary Description for RemoveAlertsWithDynamicMessageData refers to a real world object being removed. This is just one reason for using this method; others exist. In general this is a method to remove all alerts that refer to a specific value.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:22 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Generalise description of RemoveAlertsWithDynamicMessageData

    Make the removal of a real-world object an example of a more general principle.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Poor description of TimeoutAction attribute

  • Key: ALMAS13-25
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The description of TimeoutAction attribute of Class AlertData describes its enumeration type rather than the attribute itself

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 13:28 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Describe the timeout action attribute not the type

    Replace text with a description of the meaning of the attribute with respect to the alert.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Multi-language support mechanism is poorly described

  • Key: ALMAS13-14
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The features of the alert data model supporting multiple languages are not brought out well in the description. The description of static messages should discuss that there is intended to be one static message instance for each supported language variant

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:59 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Clarify multi-language support in StaticMessage class

    State that there should be one static message for each language supported

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Confusion between ALMAS Configuration and ALMAS Categorization

  • Key: ALMAS13-28
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    In describing the PIM structure, four packages are described plus an optional one (ALMAS Categorization). However in the detail one of the packages (ALMAS Configuration) is actually a class within the ALMAS Management package.

  • Reported: ALMAS 1.1 — Mon, 31 Jan 2022 11:37 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Describe as three main packages

    Describe as three packages as presented in subsection 6.1, 6.2 & 6.3

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Clarity on use of AlertID

  • Key: ALMAS13-18
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The description of GetAlert would be improved by describing how the ID for an Alert is known

  • Reported: ALMAS 1.1 — Sat, 5 Feb 2022 16:14 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    GetAlert gets current data for a known alert

    The operation retrieves the current data for an alert already known to the client component. E.g. because that component raised the alert and stored the AlertID passed out, or the component received a notification about the alert.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Ambiguity between ALMAS Client Callback Interfaces

  • Key: ALMAS13-27
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    It is not clear whether there are semantic differences between the events that trigger the ALMAS Client Callbacks ALMASNotificationListener and ALMASReceiver. The method summaries suggest that ALMASNotificationListener relates to safety critical alerts, but elsewhere in the spec this is only an example usage.

  • Reported: ALMAS 1.1b1 — Mon, 31 Jan 2022 11:49 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    AlertDistributionNotification corresponds to Raised state

    The AlertDistributionNotification should be triggered when the alert is in the Raised state (the first state for state machines in subsections 6.5.1 & 6.5.2).
    Clarify that StateChangeNotifications are also generated for new alerts.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

MIssing Acronyms and Abbreviations

  • Key: ALMAS13-29
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The Acronyms and Abbreviations section is missing entries - e.g. for PSM technologies such as DDS.

  • Reported: ALMAS 1.1b1 — Mon, 31 Jan 2022 09:59 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Add entries for acronyms from PSM

    Add:

    • COM
    • DCPS
    • DDS
    • DLRL
    • GraphQL
    • QoS
  • Updated: Fri, 30 Jun 2023 20:30 GMT

LoadTemplateSet error conditions

  • Key: ALMAS13-7
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    It is unclear whether the following are error conditions:
    Duplicate template id with previous load
    Unsupported variable type in dynamic message data
    Unsupported type of data in alert data extra attributes
    Mismatched tags between dynamic and static messages
    Missing text for mandatory languages
    Capacity limits exceeded

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 18:06 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    State error condition for load template set

    The following are error conditions

    • duplicate of existing template id
    • unsupported data type for dynamic message data
    • type of byte data out of range in extra attributes
    • mismatched tags between dynamic and static messages
    • missing text for mandatory languages
    • capacity limits exceeded
      Where applicable they should be stated for raising alerts as well.
  • Updated: Fri, 30 Jun 2023 20:30 GMT

Ambiguity of TypeOfByteData attribute

  • Key: ALMAS13-24
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    For attribute TypeOfByteData in Class AlertDataExtraAttributes
    Unclear whether or not strings should be null terminated.
    Unclear whether only one or multiple int, float values etc. are valid for one instance of the class
    Unclear whether the size of the value attribute not matching or being a multiple of the type from the TypeOfByteData attribute is an error condition

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 13:36 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Clarify validity of byte data in AlertDataExtraAttributes

    Strings are an array of UTF-8 characters without null termination
    Multiple values of a particular data type are valid
    The size of the value must be a multiple of the type of data unit size for Integer 16, 32 or 64
    There should be a specific type (7) for media types. The description string should be the type / substype tree for media types.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Ambiguity regarding raising alerts after calling SetAlertInhibited

  • Key: ALMAS13-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The description of SetAlertInhibited says "... suppress or allow the raising of all alerts of that template"
    This would suggest that calls to methods such as RaiseAlertFromTemplate for this template would subsequently fail (or succeed). An alternative interpretation is that these methods succeed but that Receivers ignore the corresponding Alert instance that is created.
    For implementation interoperability it must be clear as to which of these designs to follow.

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 17:53 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Fail attempts to raise alerts from inhibited templates

    Implementations of the ALMAS Producer interface should fail attempts to raise an alert for a template for which SetAlertInhibited has been called (with Inhibited set to True). This effects RaiseAlertFromOverrides, RaiseAlertWithDynamicData & RaiseAlertFromTemplate.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Coordination of unique request IDs

  • Key: ALMAS13-3
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The spec assumes "... that request IDs are generated by the caller and that they are unique across all ALMAS callers."
    This assumption imposes system implementation specific behaviour on users of the ALMAS specification and reduces portability across ALMAS systems.

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 08:59 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Request Uniqueness to be through Producer ID and Request ID

    ALMAS Producers (Clients) already specify a combination of request_id and producer_id in their method calls to ALMAS Manager. Therefore as producer_Id is unique to a producer request_id should only need to be unique to a single producer (client). This is advantageous as it does not require management to (for instance) pre-allocate request id ranges to different clients.
    A second consideration is that to apply the DDS Security model topic instance should be unique to a client so that each client is only permissioned for the data that relates to it. Therefore topic names should be post-fixed with the producer ID.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Behaviour of SetLanguage operation is unclear

  • Key: ALMAS13-11
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Operation SetLanguage is described as setting the language for a specific receiver. However the data model has the text for all languages (potentially) delivered to all receivers. Therefore it is unclear what the SetLanguage operation is supposed to achieve.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 13:58 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Resolve alert before delivery

    Alerts should be resolved by the ALMAS Manager prior to delivery to each ALMAS Responder. In particular delivered Alert instances should contain a single static message instance and no dynamic data.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

GetFilledMessageText doesn't account for different languages

  • Key: ALMAS13-10
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    GetFilledMessageText doesn't have a language parameter so it's implementation is unable to determine which static message from a set to use as a basis for performing message text dynamic parameter substitution.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 16:26 GMT
  • Disposition: Closed; No Change — ALMAS 1.3
  • Disposition Summary:

    ALMAS Manager has knowledge of language selection

    The ALMAS Manager has knowledge of any language selection for each receiver because of its SetLanguage operation.
    Accordingly MessageText is resolved for each receiver and the filled (resolved) message text can be calculated and returned.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Ambiguity in Routing Error Condition

  • Key: ALMAS13-9
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    It is unclear whether it is an error for an Alert Template to be RaiseToAll and to have receivers and/or secondary grouping specified.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 17:15 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    RaiseToAll error condition

    State that when RaiseToAll is set it is an error to have Receiver Kind instances or a secondary grouping defined.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Inconsistent optionality marking

  • Key: ALMAS13-16
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The summary for RemoveAlertsWithDynamicMessageData concludes with stating that implementation is optional. This is true for all methods in this interface - but is stated for only this one.
    Also there is a rogue full-stop (period) in the text.
    The ALMAS responder extensions do not have equivalent text either.

  • Reported: ALMAS 1.1b1 — Mon, 7 Feb 2022 11:26 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Remove implementation optional text

    Remove the text that inconsistently appears for RemoveAlertsWithDynamicMessageData

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Error condition on SetLanguage

  • Key: ALMAS13-12
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The error condition on specifying an unsupported language for the alert is not described for the SetLanguage operation.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 12:03 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Include unsupported language error condition

    Include error condition for completeness and portability. Map Reason to:
    4 = Requested Service Unavailable

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Semantics of undefined receivers

  • Key: ALMAS13-8
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    It is unclear whether it is an error condition to refer to a receiver before it has been registered or defined in a receiver hierarchy file. E.g. in an alert template configuration file, or when raising an alert (override or from data).
    It is also unclear whether when registering a receiver it must match an entry in the hierarchy file.
    It is also unclear whether it is permissible to call the LoadReceiverHierarchy multiple times and if so what semantics are expected.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 17:27 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Clarify Receiver Semantics

    It is an error to refer to a receiver before it has been defined by load receiver hierarchy. (But receivers don't have to be registered - for instance a user with the relevant role may not have logged on to the system).
    When registering a receiver it is an error for the receiver to not correspond to a hierarchy file entry.
    Load receiver hierarchy may be invoked more than once per execution lifetime of ALMAS Manager, for instance by multiple producers to load a specific hierarchies for their needs. The semantics in this case are additive whilst disjoint: producers should define receivers in their own namespace; it is an error to define the same receiver in multiple hierarchies. Receiver instances may register themselves multiple times with receiver names from different producer namespaces.
    Alternatively ALMAS Configuration maybe performed by a system function (entirely or in part). If entirely, the configuration operations are called once by the system function, producers don't invoke the configuration interface and receivers only register themselves once for the system defined receiver name.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Receiver Hierarchy Error Conditions

  • Key: ALMAS13-5
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Receiver Kind Type should be unique
    Parent should have it's own Receiver Kind definition
    Parent of a Receiver Kind should not introduce a circularity

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 18:33 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Place additional restrictions on Receiver Hierarchy configuration schema

    Receiver Kind Type uniqueness should be enforced using an xs:unique element within Receiver_Hierarchy_T acting on //Receiver_Kind/Type and scoped to itself (i.e. the hierarchy content).
    Parents should be declared as Receiver_Kind elements containing the elements of which they are parents (their 'children'). This avoids circular dependencies as each name is then only used once and the relationships are structural.
    'Parent-Child' isn't a great abstraction for this use case. Having inverted the relationships, 'priority receiver' would be better terminology. Therefore have each Receiver_Kind contain a Priority_Receivers element each with zero-or-more Receiver_Kind elements. Update the description for the file accordingly at the start of section section 7.3
    Parent should have it's own Receiver Kind definition
    Parent of a Receiver Kind should not introduce a circularity

  • Updated: Fri, 30 Jun 2023 20:30 GMT
  • Attachments:

No multi-language support for dynamic message data

  • Key: ALMAS13-13
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The data model doesn't support multiple languages for the dynamic message data - but this is not made clear in the descriptive text.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 12:01 GMT
  • Disposition: Resolved — ALMAS 1.3
  • Disposition Summary:

    Clarify concurrent multi-language support

    Concurrent support for multiple languages can be achieved by using multiple instances of static message and dynamic message data; one per language and one per language-placeholder combination resepectively.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Meaning of Categorization Rules not clear when referenced

  • Key: ALMAS13-15
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The summaries for operations AttachCategorisationRule and DetachCategorisationRule refer to Categorization Rules. Whilst there is some description in section 6.4 there is no overview of purpose prior to this point or forward sign-posting to section 6.4, so the purpose of these methods is left somewhat opaque.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:33 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Defer clarification on optional PIM

    ALMAS Categorization is an optional PIM, therefore resolution is lower priority so for scheduling reasons resolution is postponed to a future RTF.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Register and Unregister Receiver are unnecessary in the DDS PSM

  • Key: ALMAS13-2
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Topic types ALMAS_RegisterReceiver and ALMAS_UnregisterReceiver are not required as this functionality is covered by the statndard (DCPS) DDS Subscription Model.

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 10:00 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Address issues requiring IDL changes in v1.4

    For purposes of scheduling, a strategy of completing semantic clarifications and other minor typographic issues in v1.3 and moving to address issues requiring more substantive changes is proposed.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

No mechanism to feedback alternative action choice

  • Key: ALMAS13-6
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The spec does not appear to offer an interface for an alert client to be informed of the alternative or non-standard choice that has been made in response to an alert.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 18:12 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Address issues requiring IDL changes in v1.4

    For purposes of scheduling, a strategy of completing semantic clarifications and other minor typographic issues in v1.3 and moving to address issues requiring more substantive changes is proposed.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

The role of ALMAS Manager is unclear

  • Key: ALMAS13-19
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The description of ALMAS Manager does not give a clear picture of where it fits into the ALMAS system.

  • Reported: ALMAS 1.1 — Sat, 5 Feb 2022 16:12 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Defer extensive document changes to v1.4

    The role of ALMAS Manager with respect to the other ALMAS components should be clarified with reference to a set of behavioural diagram that describe how the various operations defined fit together.
    For scheduling reasons this is best done for v1.4.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

No standard DDS key specification

  • Key: ALMAS13-4
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The DDS-Xtypes specification now provides a standard way of specifying keys. This specification should use that mechanism

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 18:37 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Address issues requiring IDL changes in v1.4

    For purposes of scheduling, a strategy of completing semantic clarifications and other minor typographic issues in v1.3 and moving to address issues requiring more substantive changes is proposed.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Unable to override extra attributes in alert template when raising an alert

  • Key: ALMAS13-43
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The extra attribute mechanism is a useful extension mechanism for providing additional information and/or functionality relating to an alert. However, in the current specification there isn't a way to do this using predefined alert templates with runtime parameters.

  • Reported: ALMAS 1.2b1 — Tue, 7 Feb 2023 17:22 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Defer interface changes to v1.4

    For scheduling reasons this late-identified issue requiring interface code changes is noted and postponed to the next RTF.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Standardisation of Logging

  • Key: ALMAS13-20
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The specification does not standardise the logging mechanism. This could be achieved by PSM specific means.

  • Reported: ALMAS 1.1 — Sat, 5 Feb 2022 16:10 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Defer extensive document changes to v1.4

    ALMAS logging could be standardised by reference to a set of standard mechanisms in the PSM section, which refer to PSM specific method such as DDS serialisation standards.
    This change would also be better made after removal of the obsolete DLRL PSM.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Operation tables for interfaces aren't easy to read

  • Key: ALMAS13-21
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The formatting of tables for operations for interface classes doesn't aid readability

  • Reported: ALMAS 1.1 — Sat, 5 Feb 2022 16:04 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Defer large editorial change to a future RTF

    The layout and syntax of the tables in the specification that describe the operations could indeed be much improved. However, such a resolution would have a very large editorial impact and with regard to scheduling it is proposed to defer this to a later RTF.

  • Updated: Fri, 30 Jun 2023 20:30 GMT

CallStatus Reason should be an enumeration not an int

  • Key: ALMAS13-23
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The semantics of the reason attribute of the CallStatus call should be encapsulated as an enumeration. Also the formatting of the description of the attribute doesn't help clarity.

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 15:22 GMT
  • Disposition: Deferred — ALMAS 1.3
  • Disposition Summary:

    Defer interface changes to v1.4

    For scheduling reasons defer changes impacting IDL etc. to the next RTF

  • Updated: Fri, 30 Jun 2023 20:30 GMT

Error in ALMAS_RaiseAlertWithDynamicData topic struct declaration

  • Key: ALMAS12-46
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The declaration of the DynamicMessages field is incomplete and incorrect.
    It is missing the DynamicMessages field name
    It has an extra space in the type's package qualification
    The type should be ALMAS_DynamicMessageDataTypeSet

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 12:08 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Fix Issues with DynamicMessages field

    Apply suggested changes from the issue

  • Updated: Wed, 13 Jul 2022 14:17 GMT
  • Attachments:

RaiseAlertFromOverrides Summary formatting

  • Key: ALMAS12-26
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    No space between sentences. Would be improved by inserting new-lines.

    Also RaiseAlertWithDynamicData has an extra new-line.

    Also RaiseAlertFromData needs a new-line instead of a space.

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:42 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Improve Raise Alert Summary Formatting

    Add improvements as suggested by the issue.

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Greater Granularity and Clarity in Conformance Levels

  • Key: ALMAS12-3
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The Conformance section talks about general conformance level 1 functionality, but then adds extensions which are also numbered 1 to 4. There could be confusion as to what conformance to level 1 actually means.
    Also a useful system could be composed of components that implement a subset of the core (level 1) interface. Therefore, there should be one or more additional levels of conformance defined that reflects this.

  • Reported: ALMAS 1.1b1 — Mon, 31 Jan 2022 09:54 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Basic, Advanced and Extended Conformance on an Interface Role Basis

    There are three distinct roles in the ALMAS abstracted by the interface classes defined in the ALMAS Management package: Producer, Manager and Receiver. Conformance should recognise that a conforming application will be performing only one of these roles and therefore only a subset of the interface will be applicable.
    Additionally, conformance should recognise a minimal basic level of conformance as a pathway to adoption and use of the specification. This is the set of methods to support raising and receiving alerts without templates, customisation or modification.

  • Updated: Wed, 13 Jul 2022 14:17 GMT
  • Attachments:

Inconsistency in DynamicMessageData param between PIM and PSM

  • Key: ALMAS12-45
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    In the PIM the parameter for DynamicMessageDataSet in operations RaiseAlertFromOverrides and RaiseAlertWithDynamicData is StringSet, but in the CORBA and DDS PSM the type is DynamicMessageDataTypeSet (which is a sequence of the DynamicMessageDataType struct)

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 12:01 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Re-align PIM for DynamicMessageDataSet

    Change the PIM type to match the PSMs as the additional information in the PSM types is required to enable the required behaviour. Also align the parameter names (i.e. change to DynamicMessages).

  • Updated: Wed, 13 Jul 2022 14:17 GMT
  • Attachments:

DDS PSM Mapping rationale for the ALMAS_CreatedAlert topic is missing

  • Key: ALMAS12-63
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    There is no rationale for the DDS DCPS/IDL PSM topic type ALMAS_CreatedAlert.
    By closer inspection, this is introduced to map to the AlertID out parameter of the various alert creation methods in the Producer interface.
    It is needed so that producer know the alert id and are therefore able to cancel alerts that they have previously raised.

  • Reported: ALMAS 1.1 — Sat, 12 Feb 2022 11:49 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Add explanation of ALMAS_CreatedAlert

    Add explanatory text to the ALMAS Management DDS DCPS/IDL PSM section

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Typo in RemoveAlertsWithDynamicMessageData Summary

  • Key: ALMAS12-21
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    There is an erroneous space in the summary cell of RemoveAlertsWithDynamicMessageData
    "specific rea l world object" should be "specific real world object"

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:19 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Remove space in real

    Remove space (this is only in the published spec not in the 1.1 RTF convenience doc)

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Repeat of RaiseAlertFromOverrides in CORBA PSM

  • Key: ALMAS12-44
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    In the CORBA PSM there are two operations with the name RaiseAlertFromOverrides but RaiseAlertWithDynamicData is missing.

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 11:55 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Change second RaiseAlertFromOverrides to RaiseAlertWithDynamicData

    In the CORBA PSM change the second occurrence of RaiseAlertFromOverrides to RaiseAlertWithDynamicData so as to match the PIM

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Use less colloquial language in ValidAlertResponse

  • Key: ALMAS12-15
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The use of "pecking order" rather than prioritisation is unhelpful, particular if readers don't have English as first language.

  • Reported: ALMAS 1.1 — Sat, 5 Feb 2022 15:44 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Rework Pecking Order

    Change pecking order to actionee prioritisation

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Typo in AlternativeAction xml schema element

  • Key: ALMAS12-37
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    "none standard" should be "non-standard"

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 18:09 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Fix typo in AlternativeAction documentation element

    none should be non

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Rogue hyphen in DataValue attribute description

  • Key: ALMAS12-14
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Attribute DataValue for DynamicAlertData has instantia-tion. This does not need to be split.

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 15:32 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Remove hyphen

    remove hyphen in description

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Typo in CORBA PSM Section Heading

  • Key: ALMAS12-43
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Section heading is
    OMG ORBA/IDL Platform Specific Model
    should be
    OMG CORBA/IDL Platform Specific Model

  • Reported: ALMAS 1.1 — Tue, 8 Feb 2022 11:48 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Add C for CORBA back

    Correct Typo

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Ambiguity in dynamic message data substitution

  • Key: ALMAS12-13
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The description of class DynamicMessageData and its DataTag attribute is ambiguous as to whether one or two percent (%) markers are required. Also the protocol is ambiguous when there are 10 or more markers. Also, particularly with a single % marker there isn't a defined way to escape the markers.

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 15:30 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Clarify Dynamic Message Substitution

    Placeholder tags to be designated by a single exclosing percent characters.
    Multiple - in principle unbounded - replacements supported with each tag enclosed by space (or other non-alphanumeric character). The examples given in the current specification (t1, tn) are examples and more meaningful tags can be used and are encouraged (e.g. %number%, %score% or %name%).
    It is not necessary to provide a means of specifying a way to express %name% as a literal substring in a static message as this would have no meaning to a system user.
    Additionally, it should be possible to specify a replacement at the start or end of the static message. Equally it should be possible to have dynamic data at the start or end of the message and it should be possible to use punctuation around it (e.g. a comma). Therefore substitution points should be defined by:
    (start | non-alphanumeric)%t(numeric){end | non-alphanumeric)
    It is an error to specify static and dynamic data message instances with different substitution tags for the same alert template. In particular all static message instances (for different language locales) must have the same substitution set.

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Formatting and duplication of Status description

  • Key: ALMAS12-8
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The description of the status attribute for class AlertData repeats the information for the Status enumeration. This is also poorly formatted and so difficult to read.

  • Reported: ALMAS 1.1b1 — Sat, 5 Feb 2022 13:22 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Remove duplicate information

    Remove duplication of enumeration values for status attribute

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Remove Original Submission Information

  • Key: ALMAS12-2
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Section 11 Changes or extensions required to adopted OMG
    specifications applies to the submission and should not have been retained in the published specification

  • Reported: ALMAS 1.1 — Mon, 31 Jan 2022 09:38 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Remove section 11

    Remove Section 11: Change or extensions required to adopted OMG specifications

  • Updated: Wed, 13 Jul 2022 14:17 GMT

UpdateAlertPriority summary grammar

  • Key: ALMAS12-27
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    This is missing an apostrophe and is in any case could be stated more clearly

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:48 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Improve UpdateAlertPriority Summary description

    Improve description to be "Updated the priority of existing alert instances that have previously been raised."

  • Updated: Wed, 13 Jul 2022 14:17 GMT

ALMAS Producer component terminology

  • Key: ALMAS12-25
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Refer to system components rather than system objects in first sentence

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:36 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Change objects to components

    Change objects to components in ALMAS Producer description

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Incomplete Normative References

  • Key: ALMAS12-4
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The Normative References is missing entries for the PIM and PSM technologies

  • Reported: ALMAS 1.1b1 — Mon, 31 Jan 2022 09:56 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Add new Normative Reference Section

    Base style on TDAI normative reference section
    Add references for DDS, IDL, GraphQL, COM, CORBA, XML

  • Updated: Wed, 13 Jul 2022 14:17 GMT
  • Attachments:

UnregisterReceiver hyphen typo

  • Key: ALMAS12-28
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Extra hyphen in summary for UnregisterReceiver (avail-able)

  • Reported: ALMAS 1.1 — Mon, 7 Feb 2022 11:52 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Remove hyphen in UnregisterReceiver

    remove hyphen in available

  • Updated: Wed, 13 Jul 2022 14:17 GMT

Add GraphQL PSM for ALMAS

  • Key: ALMAS12-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Add a GraphQL PSM option using the mapping defined in the TDAI specification for implementations using web technologies

  • Reported: ALMAS 1.1 — Sat, 29 Jan 2022 18:58 GMT
  • Disposition: Resolved — ALMAS 1.2
  • Disposition Summary:

    Add GraphQL Platform Specific Model

    Add a GraphQL platform specific model as an alternative technology particular aimed at contexts using this technology and other similar web technologies.
    Base the PSM mappings on those defined for the TDAI specification, noting the principles of categorizing the PIM noted in the DDS / IDL / DCPS PSM.
    The schema is to be added to the normative machine readable files.

  • Updated: Wed, 13 Jul 2022 14:17 GMT
  • Attachments:

RaiseAlertFromOverrides in DLRL is missing parameter name DynamicMessageData

  • Key: ALMAS11-30
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The parameter for DynamicMessageData just has its type not the name of the parameter. ALMAS 11-11 was not specified correctly.

  • Reported: ALMAS 1.0 — Wed, 21 Aug 2019 16:44 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Add parameter name for RaiseAlertFromOverrides

    Add parameter name DynamicMessageData for operation RaiseAlertFromData in DLRL PSM (error in ALMAS 11-11)

  • Updated: Wed, 13 May 2020 16:36 GMT

URLs of machine readable PSM files to have PSM sub dir

  • Key: ALMAS11-29
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The PSM files for COM and DCPS have the same name and so the URLs become non-unique after applying ALMAS 11-2.

  • Reported: ALMAS 1.0 — Wed, 21 Aug 2019 16:42 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Supply new inventory file

    Create new inventory file for all machine readable files with unique URLs consistent file the files' filenames

  • Updated: Wed, 13 May 2020 16:36 GMT

Name of RaiseAlertWithDynamicData is ‘FromOverrides’ in the COM IDL and DLRL PSMs

  • Key: ALMAS11-28
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    In the COM & DLRL PSMs RaiseAlertFromOverrides should be RaiseAlertWithDynamicData (erroneous fix for ALMAS 11-11)

  • Reported: ALMAS 1.0 — Wed, 21 Aug 2019 16:40 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Fix errorneous FromOverrides duplicate PSM operations

    RaiseAlertFromOverrides operations in COM and DLRL PSM introduced by ALLMAS 11-11 should be named RaiseAlertWithDynamicData

  • Updated: Wed, 13 May 2020 16:36 GMT

Request Id for RaiseAlertWithDynamicData should be the typedef type

  • Key: ALMAS11-27
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    RaiseAlertWithDynamicData has a long request_id parameter in the DCPS PSM instead of the new typedef

  • Reported: ALMAS 1.0 — Wed, 21 Aug 2019 16:38 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Use typedef in RaiseAlertWithDynamicData

    replace long with the AlertIdType typedef

  • Updated: Wed, 13 May 2020 16:36 GMT

Use https in schema definitions

  • Key: ALMAS11-31
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The schemas defined in the XSD PSM should use the https protocol instead of plain http.

  • Reported: ALMAS 1.0 — Wed, 21 Aug 2019 16:46 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Replace http with https in schemas

    Replace http with https in schemas (Alert Data Template, ALMAS Configuration, Receiver Hierarchy & ALMAS categorisation rules) for the XML PSM

  • Updated: Wed, 13 May 2020 16:36 GMT

Efficient use of dynamic data

  • Key: ALMAS11-11
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The goal of templates and dynamic data, i.e. encapsulating HCI design time information outside of code and then just supplying runtime variant data - e.g. track or other object identifiers - is undermined by the methods available. The only way to supply dynamic data allows everything to be overridden, which is intended to be the abnormal case. An in-between method that just allows dynamic data to be supplied would be a much more friendly interface for alert producers.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 19:14 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Create a RaiseAlertWithDynamicData operation

    Add operation RaiseAlertWithDynamicData to class ALMASProducer in the Management PIM package - see updated diagram attached
    7.3.5 p17 change first two sentences of paragraph 2 from
    "Three mechanisms by which alerts can be raised are provided by the ALMASProducer interface class. Two variants RaiseAlertFromTemplate and RaiseAlertFromOverrides allow the system to raise an alert by simply specifying the alert ID, template ID and their own ProducerID, one of these also allows the over-ride of any placeholders that may be present in the ‘Message’ attribute of the alert data class associated with that template."
    to
    "Four mechanisms by which alerts can be raised are provided by the ALMASProducer interface class. Three variants RaiseAlertFromTemplate, RaiseAlertWithDynamicData and RaiseAlertFromOverrides allow the system to raise an alert by simply specifying the alert ID, template ID and their own ProducerID; with dynamic data allows the specification of the intentionally variable data to supplement the template alert definition; from overrides also allows the over-ride of any placeholders that may be present in the ‘Message’ attribute of the alert data class associated with that template."

    7.3.5.1 p18 insert a new 3rd row to the table
    Name: RaiseAlertWithDynamicData(String, int, int, StringSet)
    Type: public CallStatus[Parameters]ProducerID: String,TemplateID: int,out AlertID: int, DynamicMessageDataSet: StringSet,
    Summary: This will cause an alert based on a known alert template
    to be created and raised, whilst only specifying the dynamic data content that differs from the template definition. All parameters are mandatory. Return parameter indicates success or failure reason.

    9.4 p45
    insert after declaration of RaiseAlertFromOverrides
    ALMAS_DataModel::ALMAS_CallStatus RaiseAlertFromOverrides (
    in string ProducerID,
    in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID,
    in ALMAS_DataModel::ALMAS_DynamicMessageDataTypeSet DynamicMessageData,
    out ALMAS_DataModel::ALMAS_AlertIDType AlertID);

    10.3.2 p53
    insert after declaration of RaiseAlertFromOverrides
    struct ALMAS_RaiseAlertWithDynamicData

    { long request_id; string ProducerID; ALMAS_DataModel::ALMAS_TemplateIDType TemplateID; ALMAS_DataModel:: ALMAS_DynamicMessageDataType; }

    ;
    #pragma keylist ALMAS_RaiseAlertWithDynamicData request_id

    10.4.2 p58
    insert after declaration of RaiseAlertFromOverrides
    ALMAS_DataModel::ALMAS_CallStatus RaiseAlertFromOverrides (
    in string ProducerID,
    in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID,
    in ALMAS_DataModel:: ALMAS_DynamicMessageDataType,
    out ALMAS_DataModel::ALMAS_AlertIDType AlertID);

    11.4 p67
    insert after declaration of RaiseAlertFromOverrides
    HRESULT RaiseAlertFromOverrides (
    [out] ALMAS_AlertIDType *AlertID,
    [in] BSTR ProducerID,
    [in] ALMAS_TemplateIDType TemplateID,
    [in] SAFEARRAY(ALMAS_DynamicMessageDataType) DynamicMessageData,
    [out] ALMAS_CallStatus *CallStatus);

  • Updated: Wed, 13 May 2020 16:36 GMT
  • Attachments:

Optionality in RaiseAlertFromOverrides

  • Key: ALMAS11-10
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The optionality is not modelled in the PIM except for by way of explanation in the method's note.
    The Boolean flags in the DDS PSM struct do not encapsulate the information well - in particular it requires a producer to default an only partially used data structure, unions would be better.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 19:09 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Use Optional IDL syntax in the DDS PSM

    Describe mapping of implicitly optional attributes / parameters from the PIM in the PSM.
    Use IDL syntax for optionality (i.e. @optional)

  • Updated: Wed, 13 May 2020 16:36 GMT

Untyped enumerations in the PIM

  • Key: ALMAS11-9
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Several attributes in the PIM are typed as 'Enumeration'. The DDS PSM defines actual IDL enums for these with actual enumeration literals. The semantics of the literals are not defined there.
    The implementation of these enumerations are not dependent on an implementation technology such as DDS and therefore should be standardised in the PIM - and properly documented.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 19:02 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Define Enumerations in the PIM

    Add Enumeration classes for CategoryType, StateType, StatusType, ScopeType, TimeoutActionType and AckModelType to the PIM

  • Updated: Wed, 13 May 2020 16:36 GMT
  • Attachments:

Typedefs introduced in DDS PSM

  • Key: ALMAS11-8
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    IDL typedefs for ALMAS_AlertIDType, ALMAS_TemplateIDType & ALMAS_TimeoutType are introduced in the DDS PSM without explanation or correspondence with the PIM. Also the types are inconsistent: all int in PIM but long or long long in PSM. This should be consistent (and be so across all PSMs) and have rationale.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 18:46 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    PSM Typedefs to be explained and consistent

    ALMAS_AlertIDType is long for CORBA but long long for DDS
    Make it consistent with other mappings of int from PSM and hence be long for DDS too.
    Add explanation of Typedef introduction to PIM mapping discussion in section 9.1 (CORBA PSM rationale, referred to and followed by DDS PSM).

  • Updated: Wed, 13 May 2020 16:36 GMT

Missing attributes of Class Alert Data in the DDS PSM

  • Key: ALMAS11-7
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    struct ALMAS_AlertDataAttributesType (that maps to Class Alert Data - naming difference is subject to another issue) is missing correspondence with attribute TemplateID and the (unnamed) aggregation to class AlertDataExtraAttributes.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 18:38 GMT
  • Disposition: Duplicate or Merged — ALMAS 1.1
  • Disposition Summary:

    Resolve by aligning with PIM

    See linked proposal

  • Updated: Wed, 13 May 2020 16:36 GMT

DDS PSM Rationale Incomplete

  • Key: ALMAS11-6
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The following issues should be discussed in the DDS PSM rationale section to be clear and unambiguous.

    • The actual pairing of request and response topics
    • The semantics, particularly uniqueness, of request_id values
    • UML feature mappings - e.g composition, multiplicities
    • Representation of optional attributes
  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 18:29 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Define uniqueness of request ids and add compositions to mapping description

    Request Ids are to be unique across all ALMAS participants.
    The general UML mapping for CORBA and DDS PSMs is described in 9.1. It doesn't described composition explicitly, and should do so as per associations
    The pairing of requests and responses is no action
    The optionality of attributes is a duplicate

  • Updated: Wed, 13 May 2020 16:36 GMT

Class Alert Data has an inconsistent name in the DDS PSM

  • Key: ALMAS11-5
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Class Alert Data in the Data Model PIM is mapped to struct ALMAS_AlertDataAttributesType in the DDS PSM; this has 'Attributes' additionally inserted into the name. For clarity in understanding the spec the name should be consistent.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 18:08 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Align DDS PSM struct ALMAS_AlertData with PIM AlertData class

    rename ALMAS_AlertDataAttributesType to ALMAS_AlertDataType
    add the other additional attributes from original definition of struct ALMAS_AlertDataType
    remove original definition of struct ALMAS_AlertDataType
    place new definition of struct ALMAS_AlertDataType where the original one was

  • Updated: Wed, 13 May 2020 16:36 GMT

request_id should have its own type

  • Key: ALMAS11-4
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The DDS DCPS PSM introduces a request_id parameter into each of the topic types for the ALMAS Management Service. However, it is defined as a "long long" in each case except one, ALMAS_RaiseAlertFromOverrides, where its just a "long". It should be consistently defined. It would also be a better abstraction if it had its own typedef defined in the PSM IDL.

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 17:55 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Add Request Id typedef to IDL file

    Add typedef declaration to ALMAS_Management.idl and use for all request id attribute declarations as per revised text for section 10.3.2

  • Updated: Wed, 13 May 2020 16:36 GMT

Typo in struct ALMAS_AlertReportType

  • Key: ALMAS11-12
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    This struct contains
    tring ReceiverID
    rather than
    string ReceiverID

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 19:18 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Fix tring typo in IDL

    tring should be string for attribute in struct ALMAS_AlertReportType

  • Updated: Wed, 13 May 2020 16:36 GMT

Issue ALMAS11-31 is wrong - XSD should be http not https


RaiseAlertFromOverrides still has a reference to ALMAS_AlertDataAttributesType

  • Key: ALMAS11-40
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    This has been missed from the DLRL PSM in defining the changes for ALMAS 11-5

  • Reported: ALMAS 1.0 — Fri, 13 Sep 2019 21:46 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Change type of parameter for DLRL RaiseAlertFromOverrides

    Change the type of parameter Attributes from ALMAS_DataModel::ALMAS_AlertDataAttributesType to ALMAS_DataModel::ALMAS_AlertDataType

  • Updated: Wed, 13 May 2020 16:36 GMT

ALMAS_Template_Alert_Data.xsd use incorrect schema attributes

  • Key: ALMAS11-39
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The file uses minInclusive and maxInclusive for a xsd:string restriction element instead of minLength and maxLength

  • Reported: ALMAS 1.0 — Fri, 13 Sep 2019 20:11 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Use min/maxLength for xs:restriction base for xs:string

    Replace minInclusive with minLength and maxInclusive with maxLength in the Template Alert Data xsd PSM

  • Updated: Wed, 13 May 2020 16:36 GMT

ALMAS 11-10 changes to be applied to the PSM IDL file

  • Key: ALMAS11-38
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The RaiseAlertFromOverrides optionality changes are to be applied to the actual PSM IDL file ALMAS_Management_DCPS.idl

  • Reported: ALMAS 1.0 — Fri, 13 Sep 2019 20:07 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Apply ALMAS 11-10 to IDL file

    Apply changes to ALMAS_Management_DCPS.idl

  • Updated: Wed, 13 May 2020 16:36 GMT

ALMAS 11-5 changes to be applied to PSM IDL file as well

  • Key: ALMAS11-37
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Class Alert Data consistency changes need to be applied to the actual PSM IDL file ALMAS_Management_DCPS.idl as well as the specification.

  • Reported: ALMAS 1.0 — Fri, 13 Sep 2019 20:03 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Apply ALMAS 11-5 to IDL file

    In ALMAS_DataModel.idl rename ALMAS_AlertDataAttributesType to ALMAS_AlertDataType add the other additional attributes from the original definition of struct ALMAS_AlertDataType and remove original definition of struct ALMAS_AlertDataType. Place the new definition of struct ALMAS_AlertDataType where the original one was.

  • Updated: Wed, 13 May 2020 16:36 GMT

ALMAS 11-4 to be applied to PSM IDL file

  • Key: ALMAS11-36
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    request_id should have its own type in the PSM IDL file ALMAS_Management_DCPS.idl - i.e. ALMAS 11-4 changes should be applied to the actual file as well as the specification.

  • Reported: ALMAS 1.0 — Fri, 13 Sep 2019 20:00 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Apply ALMAS 11-4 to IDL file

    Add typedef declaration to ALMAS_Management_DCPS.idl and use for all request id attribute declarations as per ALMAS 11-4

  • Updated: Wed, 13 May 2020 16:36 GMT

Filename is inconsistent with module name and other IDL modules

  • Key: ALMAS11-2
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Filename is configured as DDS_common_IDL APM.idl, but ALMAS_DataModel.idl is logically the correct name and that expected by dtc/09-03-09 - DDS_DCPS_IDL APM.idl & DDS_DLRL_IDL APM.idl

  • Reported: ALMAS 1.0 — Fri, 7 Sep 2018 16:29 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Configure files with the correct name

    Configure file currently with URL ALMAS/20090301/DDS_common_IDL APM.idl as ALMAS/YYYYMMnn/ALMAS_DataModel.idl
    Configure file currently with URL ALMAS/20090301/DDS_DCPS_IDL APM.idl as ALMAS/YYYYMMnn/ALMAS_Management_DCPS.idl
    Configure file currently with URL ALMAS/20090301/DDS_DLRL_IDL APM.idl as ALMAS/YYYYMMnn/ALMAS_Management_DLRL.idl

  • Updated: Wed, 13 May 2020 16:36 GMT

Section 7.3 hierarchy

  • Key: ALMAS11-3
  • Legacy Issue Number: 13031
  • Status: closed  
  • Source: THALES ( Bert Van Der Meer)
  • Summary:

    Section 7.3: The hierarchy is defined in the Receiver Hierarchy Configuration File and is alert independent, so for all templates the same. Therefore RKParentType should be removed from ReceiverKind related to AlertTemplate in order to prevent a lot of redundant information. Solution: Remove RKParentType from ReceiverKind related to AlertTemplate.Instead, introduce a seperate class ReceiverHierarchy. Note that this has quite an impact on the PSMs!

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

    Consider Rationalisation of Receiver Hierarchy

    Consider optimisation of the Receiver Hierarchy data structures

  • Updated: Wed, 13 May 2020 16:36 GMT

Missing comma after cancelled enum

  • Key: ALMAS11-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    There is a comma missing after Cancelled in enum ALMAS_StateType

  • Reported: ALMAS 1.0 — Fri, 7 Sep 2018 16:33 GMT
  • Disposition: Resolved — ALMAS 1.1
  • Disposition Summary:

    Add comma for Cancelled

    Add missing comma after Cancelled in enum ALMAS_StateType in DDS_common_IDL_APM.idl

  • Updated: Wed, 13 May 2020 16:36 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_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

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

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

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

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 ( Mr. 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

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

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

Section 2.8.1.3

  • Key: ALMAS-15
  • Legacy Issue Number: 12989
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. 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 ( Mr. 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

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 ( Mr. 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 ( Mr. 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

2.3.2.8 DataTag

  • Key: ALMAS-10
  • Legacy Issue Number: 12295
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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 ( Mr. 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.1 ALMAS Client Callbacks

  • Key: ALMAS-4
  • Legacy Issue Number: 12289
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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.3.2.1

  • Key: ALMAS-8
  • Legacy Issue Number: 12293
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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 ( Mr. 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

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 ( Mr. 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 ( Mr. 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 General

  • Key: ALMAS-5
  • Legacy Issue Number: 12290
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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

Section 2.3.1 & 2

  • Key: ALMAS-6
  • Legacy Issue Number: 12291
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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.3.1.1 ReceiverKind Operations

  • Key: ALMAS-11
  • Legacy Issue Number: 12296
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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.2 Conformance requirements

  • Key: ALMAS-3
  • Legacy Issue Number: 12288
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. 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 ( Mr. 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

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

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 ( Mr. 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

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

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

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

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 ( Mr. 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 ( Mr. 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

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

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