Alerts & Indications

[alvarosanuy]

This is a space created to centralize the management of S-101 Alarms & Indications by:

• Detailing the mapping of A&I between S-52 to S-101 (endorsed view).
• Keeping track of changes to the 'original' modelling (New/amended entries)

The draft mapping document below is our starting point and needs your review. Once we arrive to an agreed final version, this will assist with the final QC of all the A&I entries in the S-101 PC. The goal is to arrive to a complete A&I PC version post S101 1.1.0. A&I must be completed in a subsequent 1.n.0 version of the S101 PC to allow for testing before finalizing version 2.0.0.

S101 - Alarms & Indications mapping Table_v1_20220727.docx

[DavidGrant-NIWC]

Discussion

• [ ] Should MarineFarmCulture always alert as in S-52,
• [ ] or only when valueOfSounding is (unknown or <= safetyContourValue)

Background

• See S-52 PresLib 4.0.3 Part 1, 10.5.9 - 10.5.12
• See S-64 3.0.3:
  • 5 Detection and Notification of Navigational Hazards
  • 6 Detection of Areas for which Special Conditions Exist
  • 7 Detection and Notification of the Safety Contour

Corrections

1. The "Type" column should indicate the type of alert rather than the priority. Note that alerts may have different priorities depending on route monitoring vs. planning, and also depending on system configuration. The alert highlight style and viewing group used by the highlight also vary.

   • Navigational Hazard (Group: AtoNs, Overhead Obstructions, Obstructions)
   • Prohibited Area (Group: Areas for which Special Conditions Exist)
   • Safety Contour (Group: Safety Contour)

2. Add condition to NEWOBJ: "CLSNAM prefix = 'Virtual AtoN'"

3. OBSTRN/UWTROC/WRECKS

   • Recommend this note is put in the "Conditions" column rather than at the bottom of the spreadsheet (not all OBSTRN/UWTROC/WRECKS get evaluated for alerts).
   • UWTROC condition is missing "safety" ("contour value" -> "safety contour value")
   • defaultClearanceDepth is not equivalent to DEPTH_VALUE. The equivalence is:
     • DEPTH_VALUE = valueOfSounding or defaultClearanceDepth or DEPTH_VALUE as output from OBSTRN07/WRECKS05
     • The first encoded value is used, e.g. if valueOfSounding is missing or unknown, then defaultClearanceDepth is used, etc.
   • S-101 alert is output in UDWHAZ05.lua
     • when input DEPTH_VALUE <= safety contour value

4. SOUNDG

   • S-101 condition: sounding depth <= safety contour value (evaluated in SOUNDG03.lua)
     • ZCOO subfield is a scaled integer and can't be compared directly
     • depth == safety contour should also trigger alert

5. RestrictedAreaNavigational and RestrictedAreaRegulatory

   • Is always associated with a Prohibited Area alert.
   • restriction and categoryOfRestrictedArea can be multi-valued ("contains" vice "=")
   • The restriction or categoryOfRestrictedArea value only changes the viewing group of the alert highlight
     • If restriction contains 14 (area to be avoided) then vg=107
     • otherwise, if categoryOfRestrictedArea contains 28 (PSSA), vg=114
     • otherwise, vg=104

6. "Hulkes" => "Hulk"

7. DEPARE/DRGARE

   • Based on the comments in DEPARE03.lua (green notes), there are some differences wrt PL 4.0.3 CSP DEPARE03

[alvarosanuy]

Template for discussion at January's meeting:

S101.-.Alarms.Indications.mapping.Table_v2_20230111.docx

[DavidGrant-NIWC]

Note that the priorities in MSC.232(82) for priority selection for areas with special conditions no longer applies. The selection is now between "Warning" and "Caution" per IEC 61174:2015 Annex D, which was updated to conform with MSC.252(83) appendix 5 table 2.

MSC.232(82):

MSC.252(83):

IEC 61174:2015:

[MikusRL]

• Based on the comments in DEPARE03.lua (green notes), there are some differences wrt PL 4.0.3 CSP DEPARE03

Just in the light of my yesterdays comment. As I understand that the waterLevelEffect now is used by Offshore Production Area feature too. That is to update then the comments text in lua I guess, if nothing else is impacted otherwise.

[DavidGrant-NIWC]

• Based on the comments in DEPARE03.lua (green notes), there are some differences wrt PL 4.0.3 CSP DEPARE03

Just in the light of my yesterdays comment. As I understand that the waterLevelEffect now is used by Offshore Production Area feature too. That is to update then the comments text in lua I guess, if nothing else is impacted otherwise.

@MikusRL - I think this comment should be for a different issue?

[alvarosanuy]

Portrayal subWG meeting - 11th January 2023

1. Mapping Table document - Agreement to include new columns to record 'Alert Priority'. S101.-.Alarms.Indications.mapping.Table_v3_20230112.docx
2. For 'Alert Priority' mappings and 'highlights' to be used in portrayal refer to Draft 'Revised ECDIS PS' approved by NCSR9 in 2022 (see below) and corresponding S-64 test outcomes. DRAFT_IMO ECDIS PS, NCSR-9.pdf
3. OEMs are requested to test the implementation of Alerts & Indications as currently prototyped by NIWC (combination of instructions within portrayal rules and the use of the AlertsCatalogue.xml file) and report findings and recommendations ASAP.
4. NIWC is required to provide the official source used for the the wording of the different Alert messages contained within the AlertsCatalogue.xml file. These messages need endorsement by the subWG.
5. The subWG decided to aim for PC 1.2.0 as the target version for a complete release of A&I.

[DavidGrant-NIWC]

NIWC is required to provide the official source used for the the wording of the different Alert messages contained within the AlertsCatalogue.xml file. These messages need endorsement by the subWG.

These mostly originate from IEC 61174:2015 Annex D Table D.1, which reproduces appendix 5 of IMO resolution MSC.232(82) updated for the alert classification of appendix 5 of IMO MSC.252(83).

When populating the alert catalog I tried to update the messages for:

• Consistency - similar messages should have similar text
• Clarity - it should be clear what the message is indicating
• Conciseness - minimize use of space in the ECDIS user interface

The ProhAreHighlightOffMsg should probably be updated to use the message as required by the route planning requirements ("Indication of some prohibited areas or areas with special conditions is Off") as opposed to the message as required by the route monitoring requirements ("If any indication is in the off state, a permanent indication: 'ProhAre' shall be provided.")

Alert catalog messages in PC 1.1.1

Mode	61174 clause	Message id	Message	Requirement (from Table D.1)	Notes
M	4.10.3 (232/A11.4.3)	CrossingSafetyContourMsg	Crossing safety contour	Crossing safety contour
P	4.10.2.1 (232/A11.3.4)	CrossingSafetyContourMsg	Crossing safety contour	Route planning across safety contour	The message is required to be in the user dialog area of the route plan. "Route planning across" is redundant.
M	4.10.3 (232/A11.4.4)	CrossingProhAreMsg	Crossing prohibited or special conditions area	Area with special conditions	Message lacks clarity
P	4.10.2.1 (232/A11.3.5)	CrossingProhAreMsg	Crossing prohibited or special conditions area	Route planning across specified area	The message is required to be in the user dialog area of the route plan. "Route planning across" is redundant.
M	4.10.3 (232/A11.4.6)	CrossingNavHazardsMsg	Crossing navigational hazard	Crossing a navigational hazard in route monitoring mode	"in route monitoring mode" is inconsistent and redundant
P	4.10.2.1 (232/A11.3.5)	CrossingNavHazardsMsg	Crossing navigational hazard	Route planning across navigational hazard	The message is required to be in the user dialog area of the route plan. "Route planning across" is redundant.
M P	4.10.2.1, 4.10.3	SafetyContourHighlightOffMsg	Indication of crossing safety contour is Off	Off state of route planning across safety contour, prohibited areas and hazards indication	Conflicting requirement. See 4.10.2.1 para 8 and 4.10.3 para 8: "When selected for off state, a permanent indication shall be provided that the 'Indication of crossing safety contour is Off'"
M	4.10.3	ProhAreHighlightOffMsg	ProhAre	not in table	para 13: "If any indication is in the off state, a permanent indication: "ProhAre" shall be provided."
P	4.10.2.1	ProhAreHighlightOffMsg	ProhAre	not in table	para 14: 'Indication of some prohibited areas or areas with special conditions is Off'."
M P	4.10.2.1, 4.10.3	NavHazardsHighlightOffMsg	Indication of navigational hazards is Off	not in table	4.10.2.1 2nd from last para: "If any of the selectable indications is in the off state, there shall be a relevant permanent indication: 'Indication of navigational hazards is Off'". Same requirement is in 4.10.3
-	-	ProhArePriorityLbl	ProhAre Alert Priority	No requirement	Machine-readable user interface label
-	-	NavHazardsPriorityLbl	Nav Hazards Alert Priority	No requirement	Machine-readable user interface label

M = route monitoring P = route planning

[alvarosanuy]

MSC.530(106) - PERFORMANCE STANDARDS FOR ELECTRONIC CHART DISPLAY AND INFORMATION SYSTEMS (ECDIS)_Nov2022.pdf

[DavidGrant-NIWC]

BTW, here's a look at the test bed implementation. Route monitoring alerts are up top. Route planning alerts are in the lower tabular area.

[alvarosanuy]

S101.-.Alarms.Indications.mapping.Table_v4_20230510.docx

[DavidGrant-NIWC]

• defaultClearanceDepth is not equivalent to DEPTH_VALUE. The equivalence is:

  • DEPTH_VALUE = valueOfSounding or defaultClearanceDepth or DEPTH_VALUE as output from OBSTRN07/WRECKS05
  • The first encoded value is used, e.g. if valueOfSounding is missing or unknown, then defaultClearanceDepth is used, etc.

• S-101 Features column Hulkes => Hulk

• S-101 condition: sounding depth <= safety contour value (evaluated in SOUNDG03.lua)

  • ZCOO subfield is a scaled integer and can't be compared directly

• Checks against the safety contour depth should be <= rather than <

[alvarosanuy]

Decisions made at Portrayal subWG meeting on 11/5/23

• [ ] NIWC - Remove RestrictedAreaRegulatory from the 'Areas for which special conditions exist' Alert Group.
• [x] Alvaro - Amend the A&I mapping table accordingly (Rename 'S-101 Alerts & Indications mapping table'). This becomes a consolidated, easy to read version of the S-101 PC A&I implementation.
• The PsWG agreed that the most up to date document regulating A&I in ECDIS is now MSC.530(106) - PERFORMANCE STANDARDS FOR ELECTRONIC CHART DISPLAY AND INFORMATION SYSTEMS (ECDIS)_Nov2022. IEC 61174 Ed 4.0.0 has not yet been reviewed and updated to incorporate new/amended performance requirements.
• The PsWG agreed that the IMO Alert types 'Warning' and 'Caution' can't be differentiated and therefore a unique name should be used in the Alert Messages linked to INDHLT (i.e. Warning/Caution'). There's no criteria in IMO's MSC.502(106) to designate some messages as 'Warnings' and others as "Cautions'.
• [ ] All - Review the quantity and content of all the Alert messages proposed by NIWC and provide comments by Monday 5th of June. Assessment must be made against Route Monitoring and Route Planning sections in MSC.530(106). refer to preliminary mappings in the latest version (refer to V5 in the next comment) of the 'S-101 Alerts & Indications mapping table'.
• [ ] NIWC to provide an updated Alert Catalog Messages table soon after the closing date above.

[alvarosanuy]

Latest version of the 'S-101 Alerts & Indications mapping table' is: S-101 Alerts & Indications mapping table_v5_20230519.docx

S-101 PC 1.20 implementation must adhere to the content in this document.

[KlasOstergren-SMA]

The S-101 Feature TrafficSeparationZone is changed to SeparationZoneOrLine in ed.1.1.0 and can also be a curve. Otherwise, I have no comments.

[alvarosanuy]

The S-101 Feature TrafficSeparationZone is changed to SeparationZoneOrLine in ed.1.1.0 and can also be a curve. Otherwise, I have no comments.

Thanks @KlasOstergren-SMA for your input. I have created a new version of the Table to replace TrafficSeparationZone with SeparationZoneOrLine and include CURVE as a valid geometric primitive. S-101.Alerts.Indications.mapping.table_v6_20230523.docx

[alvarosanuy]

Decisions made at Portrayal subWG meeting on 17/10/23

• [ ] NIWC to update S-101.Alerts.Indications.mapping.table_v6_20230523.docx to reflect the re-introduction of RestrictedArea as a single feature (as per S-52) and update the PC accordingly.

• [ ] NIWC to discuss with Hannu the need to update the wording of the Alert Messages as presented by NIWC in a previous comment.

• Note that the PsWG agreed on using INDHLT and DNGHL portrayal to depict interactions between a 'ship's safety framework' and the 'Uncertainty Buffer Area' around a feature (same as if it was clashing against the charted feature itself). This also applies to the wording of the Alert message. In short, the portrayal and the messages used to Alert mariners when their safety framework interacts with either a charted feature or the uncertainty buffer zone around that feature (position/depth), must be identical. Different symbology and/or messages' wording would only be introduced at Mariner's request (potentially after practical testing in ECDIS .....).

[TomRichardson6]

Noting discussions at S-101PT11 is it necessary to extend this table to cover how uncertainty applies to each item in the tables? For example for Areas for which special conditions exist uncertainty may not be applicable as these are generally not physical objects but objects defined in regulations or guidance. Similarly for floating AtoNs uncertainty may be less relevant as buoys will move for obvious reasons. I'm also aware that an ENCWG sub group is meeting to discuss this from the S-52 perspective.

[alvarosanuy]

@TomRichardson6 - Specifically on IMO clauses 11.3.6 & 11.4.9 (uncertainties), we are following the recommendations made by the DQWG where the focus is on hydrographic features (anything with VALSOU) in depths=<30m. There's nothing in the DQWG recommendations around uncertainties of other features. Furthermore I'm not sure who would be encoding that info anyway .... It was (and still is) a mammoth task to convince HO's to encode POSACC & SOUACC on the limited features recommended by the DQWG.

My view is that the IHO's interpretation of IMO requirements has to be around hydrographic features in depths=<30m. Nothing else. This mapping of the IMO requirement against the practical implementation in S-101 should be included in S-98 (?). Similar to the mapping done in S-52 between the term 'Area for which special conditions exist" and the S-57 Objects and attributes that would cover that IMO requirement.

In S-52/S-57, I would say that giving mariners the ability to plan and monitor routes so they do not get closer than a specified distance from M_QUAL boundaries having a specific CATZOC values (i.e. C & D) would be most pragmatic and realistic interpretation to the new IMO requirement. I wouldn't go further than that but something the ENCWG will have to discuss in more detail, of course.

The other thing new that has been added as requirement in the latest IMO ECDIS PS is the triggering of A&I when a ship is to pass closer than a user-defined distance from ANY charted feature (nothing to do with the Uncertainties). @DavidGrant-NIWC - Would this be an extension to all Portrayal feature rules?

[DavidGrant-NIWC]

The other thing new that has been added as requirement in the latest IMO ECDIS PS is the triggering of A&I when a ship is to pass closer than a user-defined distance from ANY charted feature (nothing to do with the Uncertainties). @DavidGrant-NIWC - Would this be an extension to all Portrayal feature rules?

Not sure that I agree with your interpretation. It would be a challenge to try to develop an alert catalog containing so many viewing groups, but since an alert can be added to any geometry referenced by a drawing instruction; yes, it should be possible.

[alvarosanuy]

@DavidGrant-NIWC - I would like to close this issue if we have implemented all A&I as per the spreadsheet. We could then create a new issue in the S-98/S-164 GitHub space to track ECDIS requirements (as per MSC.530(106)_November 2022) to allow mariners to plan a route (or monitor it) using:

• Encoded 'Uncertainties of charted features. My view is that the 'IHO interpretation' of this requirement should follow DQWG guidance and limit it to hydrographic features (anything with VALSOU) in depths=<30m. Point features for the time being (until S-100 is updates to support buffering of Curves & Surfaces).

• Self determined buffer zones around a number of listed features Example - Alert me if my ship is going to pass closer than 500m of any Caution Area. Features mentioned in IMO's doc. are: Safety contour; Prohibited & Areas for which special conditions exist (Annex 4) but also talks of ... 'user-selectable category of point objects, such as a fixed or floating aid to navigation or isolated danger. The user-selectable categories should be the same as the user selections for the display of objects and be based on IHO standards.' Note that this last sentence could be interpreted as any object that has its own VG and can be turned on/off at will by the mariner. IMO's MSC.530(106) sections 11.3.6 & 11.4.9 talk about giving mariners the additional option of enlarging the mariner's selected distance by taking into account accuracy information of relevant hydrographic information, as defined by IHO standards. I would interpret the text in bold as only applicable to features identified by DQWG (see bullet point 1).

Can we say that the IHO's interpretation of bullet 2 requirements (in terms of features/feature-attribute combinations) is what we currently have in the A&I Word doc table and currently implemented in PC 1.20 draft?

@DavidGrant-NIWC:

• Does PC 1.2.0 Draft currently support the first bullet point above (as per DQWGs recommendation)?
• If my statement above is correct, the only thing missing would be allowing mariners to select a buffer/distance they would like to keep away from those features and trigger INDHLT if breached. Would this functionality have to be implemented completely by OEM's, or is there anything else we would have to do to support it in the S101 PC itself ? Depending on your answer we may want to close this issue and create a new one in this GiutHub space for what would be pending to implement in PC 2.0.0 for this topic only.

[DavidGrant-NIWC]

S-101 Alerts Mapping Table v7 20240210.xlsx

Answers to your questions are below. I added a new issue to address a new requirement I failed to notice previously: #159. The alert catalog doesn't implement the new requirement because I need direction on which categories should be provided.

Does PC 1.2.0 Draft currently support the first bullet point above (as per DQWGs recommendation)?

No. We could implement this for point features (as demonstrated previously) but we recommend that the capability is targeted for a post-1.2 / pre-2.0 update to the PC (if desired). Ideally, we would get support for this added into S-100, but perhaps there are other ways to accomplish this that haven't occurred to me.

[...] Would this functionality have to be implemented completely by OEM's, or is there anything else we would have to do to support it in the S101 PC itself? [...] we may want to close this issue and create a new one [...]

Without S-100 support it is probably an OEM implementation unless we can come up with a workaround. I agree on closing this issue and opening a new issue targeted to the unimplemented functionality.

Pics from the v7 alert mapping tables provided for convenience

Alert Priorities

Navigational Hazards

Special Conditions

Safety Contour

[TomRichardson6]

@alvarosanuy and @DavidGrant-NIWC has this table been reviewed to reflect the work of the group under ENCWG looking at this from an S-52 perspective?

[DavidGrant-NIWC]

@alvarosanuy and @DavidGrant-NIWC has this table been reviewed to reflect the work of the group under ENCWG looking at this from an S-52 perspective?

Not that I'm aware of.

[alvarosanuy]

@alvarosanuy and @DavidGrant-NIWC has this table been reviewed to reflect the work of the group under ENCWG looking at this from an S-52 perspective?

I haven't been invited to any focus group meeting (although I am in the list ...) and therefore we have been flying 'solo' so far. I have this issue listed in the PsWG report to S101PT12.

[alvarosanuy]

Closing this issue and referring pending actions linked to IMO MSC.530(106) implementation to https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/159 & https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/160

Relevant MSC requirements are outlined in sections:

• 11.3.4; 11.3.5 and 11.3.6 (Route Planning)
• 11.4.3; 11.4.4; 11.4.6; and 11.4.9 (Route Monitoring)

[DavidGrant-NIWC]

Updated the alert mapping table to v8. Added DiscolouredWater to the Special Conditions tab. It (currently) uses the same viewing group as CautionArea to toggle the indication highlight.

S-101 Alerts Mapping Table v8 20240327.xlsx