Alert Management Service Avatar
  1. OMG Specification

Alert Management Service — Closed Issues

  • Acronym: ALMAS
  • Issues Count: 23
  • 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
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

Issues Descriptions

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