Alert Management Service Avatar
  1. OMG Specification

Alert Management Service — Open Issues

  • Acronym: ALMAS
  • Issues Count: 23
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
ALMAS11-47 Issue ALMAS11-31 is wrong - XSD should be http not https ALMAS 1.0 open
ALMAS11-39 ALMAS_Template_Alert_Data.xsd use incorrect schema attributes ALMAS 1.0 open
ALMAS11-40 RaiseAlertFromOverrides still has a reference to ALMAS_AlertDataAttributesType ALMAS 1.0 open
ALMAS11-28 Name of RaiseAlertWithDynamicData is ‘FromOverrides’ in the COM IDL and DLRL PSMs ALMAS 1.0 open
ALMAS11-38 ALMAS 11-10 changes to be applied to the PSM IDL file ALMAS 1.0 open
ALMAS11-37 ALMAS 11-5 changes to be applied to PSM IDL file as well ALMAS 1.0 open
ALMAS11-36 ALMAS 11-4 to be applied to PSM IDL file ALMAS 1.0 open
ALMAS11-31 Use https in schema definitions ALMAS 1.0 open
ALMAS11-30 RaiseAlertFromOverrides in DLRL is missing parameter name DynamicMessageData ALMAS 1.0 open
ALMAS11-29 URLs of machine readable PSM files to have PSM sub dir ALMAS 1.0 open
ALMAS11-27 Request Id for RaiseAlertWithDynamicData should be the typedef type ALMAS 1.0 open
ALMAS11-11 Efficient use of dynamic data ALMAS 1.0 open
ALMAS11-12 Typo in struct ALMAS_AlertReportType ALMAS 1.0 open
ALMAS11-8 Typedefs introduced in DDS PSM ALMAS 1.0 open
ALMAS11-10 Optionality in RaiseAlertFromOverrides ALMAS 1.0 open
ALMAS11-9 Untyped enumerations in the PIM ALMAS 1.0 open
ALMAS11-4 request_id should have its own type ALMAS 1.0 open
ALMAS11-6 DDS PSM Rationale Incomplete ALMAS 1.0 open
ALMAS11-5 Class Alert Data has an inconsistent name in the DDS PSM ALMAS 1.0 open
ALMAS11-7 Missing attributes of Class Alert Data in the DDS PSM ALMAS 1.0 open
ALMAS11-2 Filename is inconsistent with module name and other IDL modules ALMAS 1.0 open
ALMAS11-3 Section 7.3 hierarchy ALMAS 1.0b1 open
ALMAS11-1 Missing comma after cancelled enum ALMAS 1.0 open

Issues Descriptions


ALMAS_Template_Alert_Data.xsd use incorrect schema attributes

  • Key: ALMAS11-39
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

RaiseAlertFromOverrides still has a reference to ALMAS_AlertDataAttributesType

  • Key: ALMAS11-40
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

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

  • Key: ALMAS11-28
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

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

  • Key: ALMAS11-38
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

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

  • Key: ALMAS11-37
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

ALMAS 11-4 to be applied to PSM IDL file

  • Key: ALMAS11-36
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

Use https in schema definitions

  • Key: ALMAS11-31
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

RaiseAlertFromOverrides in DLRL is missing parameter name DynamicMessageData

  • Key: ALMAS11-30
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

URLs of machine readable PSM files to have PSM sub dir

  • Key: ALMAS11-29
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

Request Id for RaiseAlertWithDynamicData should be the typedef type

  • Key: ALMAS11-27
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Sat, 21 Sep 2019 00:01 GMT

Efficient use of dynamic data

  • Key: ALMAS11-11
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT
  • Attachments:

Typo in struct ALMAS_AlertReportType

  • Key: ALMAS11-12
  • Status: open  
  • Source: BAE SYSTEMS ( Simon Mettrick)
  • Summary:

    This struct contains
    tring ReceiverID
    rather than
    string ReceiverID

  • Reported: ALMAS 1.0 — Mon, 24 Sep 2018 19:18 GMT
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Typedefs introduced in DDS PSM

  • Key: ALMAS11-8
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Optionality in RaiseAlertFromOverrides

  • Key: ALMAS11-10
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Untyped enumerations in the PIM

  • Key: ALMAS11-9
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT
  • Attachments:

request_id should have its own type

  • Key: ALMAS11-4
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

DDS PSM Rationale Incomplete

  • Key: ALMAS11-6
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Class Alert Data has an inconsistent name in the DDS PSM

  • Key: ALMAS11-5
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Missing attributes of Class Alert Data in the DDS PSM

  • Key: ALMAS11-7
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Filename is inconsistent with module name and other IDL modules

  • Key: ALMAS11-2
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Section 7.3 hierarchy

  • Key: ALMAS11-3
  • Legacy Issue Number: 13031
  • Status: open  
  • 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT

Missing comma after cancelled enum

  • Key: ALMAS11-1
  • Status: open  
  • Source: BAE SYSTEMS ( 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
  • Updated: Mon, 19 Aug 2019 00:35 GMT