Alert Management Service Avatar
  1. OMG Specification

Alert Management Service — All Issues

  • Acronym: ALMAS
  • Issues Count: 30
  • Description: All Issues
Closed All
All Issues

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

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