SDX Deposit Documentation

This folder documents how to format TIM payloads and deposit them to SDX using the SEMI ASN definitions in SEMI_v2.4.2_050925_j2024.asn.

Source of Truth

• SEMI module version: 2.4.2-draft (2025-05-09)
• Important note in this version: advisoryMessage supports OCTET STRING (SIZE(0..7000)) for multi-region ASD TIMs.
• Note that this SEMI can be found in the asn1_codec repo on GitHub as well.

CTW TIM Documentation

Use these local documents together with the SEMI ASN file:

• TravelerInformation structure for standard TIMs v20260213.docx
  • Defines use of the J2735 TravelerInformation structure to build standard TIMs for CTW.
  • Captures ITWG-aligned TIM construction practices (through Nov 2025 draft guidance).
• CTW-TIMs-ITIS-v20260218.xlsx
  • Defines TIM message types and associated ITIS code/phrase sequences.
  • Use as the message content reference when building TIM payload semantics.

SDX Service Endpoints

• SDX service UI: https://sdx-service.trihydro.com
• Single-message deposit endpoint: /api/deposit
• Multi-message deposit endpoint: /api/deposit-multi

TIM Format in SEMI

TIM content is carried as an encoded binary message in ASD structures.

TIM Construction in TravelerInformation (CTW Guidance)

When constructing TIM content before encoding into advisoryMessage, follow CTW guidance from the TravelerInformation document:

• Treat packetID + msgCnt as the TIM unique identifier pair.
• Manage msgCnt as updates to an existing TIM (0..127, rollover handled with timestamp logic).
• Include and update timeStamp with each TIM update (minute-of-year UTC; ITWG recommends mandatory use).
• Build packetID as 9 octets with:
  • first 3 octets = authority identifier (GNIS-based prefix)
  • last 6 octets = unique ID within active TIM set
• Use multiple dataFrames in a single TIM only for tightly coupled messages that should be managed together.
• Populate TravelerDataFrame.content using sequences of ITIS codes (J2540 based) to define message meaning.

Additional CTW/ITWG conventions noted in the document:

• frameType: use roadSignage for public road authority generated TIMs.
• msgId: use furtherInfoID (default value 0); do not use roadSignID path.
• urlB: recommended not used.

These conventions apply to the TIM structure used to generate the encoded bytes carried in SEMI ASD deposit messages.

Message Types and ITIS Phrase Sequences

Use CTW-TIMs-ITIS-v20260218.xlsx as the authoritative mapping for:

• TIM message type definitions
• ITIS code sequences
• ITIS phrase/text sequencing rules used to populate TIM content consistently

During TIM build/validation, verify that each message uses an approved message type and the corresponding ITIS sequence from this spreadsheet before encoding and deposit.

Where TIM Appears

• AdvisoryDetails.asdmType uses AdvisoryBroadcastType
• AdvisoryBroadcastType.tim = (2)
• TIM bytes are sent in:
  • AdvisoryDetails.advisoryMessage OCTET STRING (SIZE(0..7000))

Core ASD Deposit Message

For TIM deposit to SDX, use AdvisorySituationData:

• dialogID: advSitDataDep (156) (0x009C)
• seqID: data (5)
• groupID: GroupID (TemporaryID; use 00 00 00 00)
• requestID: TemporaryID (4-byte transfer ID)
• recordID (optional): TemporaryID (use to overwrite existing record(s))
• serviceRegion: GeoRegion (NW and SE corners)
• asdmDetails: AdvisoryDetails

Inside AdvisoryDetails for TIM:

• asdmID: TemporaryID
• asdmType: set to tim (2)
• startTime (optional): DFullTime
• stopTime (optional): DFullTime
• advisoryMessage: encoded TIM bytes, max 7000 bytes. Note this is the ASN1 UPER encoded MessageFrame

SDX Deposit Flow

Use the SDX API at https://sdx-service.trihydro.com for TIM deposits.

1. Build and encode the SEMI ASD payload

• Build an AdvisorySituationData message with TIM content (asdmType = tim (2)).
• UPER-encode the ASD message bytes.
• Represent the encoded bytes using one of the supported encodeType values:
  • hex
  • base64
  • uper

2. Submit a single-message deposit (POST /api/deposit)

• Endpoint: https://sdx-service.trihydro.com/api/deposit
• Request body schema: DepositRequest
• Required fields:
  • encodedMsg (string)
  • encodeType (hex, base64, or uper)
• Optional fields:
  • estimatedRemovalDate (ISO date-time)
  • sharedId (nullable string used for correlation. ignore)
• Success response (200): integer recordId of the deposited advisory message.
• Possible error responses:
  • 400 invalid request
  • 403 user org not authorized for deposit region
  • 500 internal server error

3. Submit a multi-message deposit (POST /api/deposit-multi) when batching

• Endpoint: https://sdx-service.trihydro.com/api/deposit-multi
• Request body schema: DepositRequestList
  • depositRequests: array of DepositRequest
• Success response (200): DepositMultiSummary
  • depositedRecordIds: list of successful record IDs
  • failedDepositRequests: list of failed request payloads/errors
  • failedAuthorizedAsds: authorized ASD records that still failed processing

4. Verify deposit results

• For single deposit, store the returned recordId.
• For multi deposit, process both successful and failed entries from the summary.
• Optionally query deposited records with:
  • GET /api/deposited-by-me/{semiDialogId} (use 156 for Advisory Situation Data Deposit)

5. Recommended pre-check

• Before depositing, use POST /api/decode to validate encoded payload format and decodeability.

Validation Checklist

Before deposit:

• TIM payload is properly encoded into bytes.
• advisoryMessage length is <= 7000 bytes.
• asdmType is exactly TIM (2).
• groupID and requestID are present and tracked through the full dialog.
• serviceRegion matches intended deployment area.
• startTime and stopTime (if used) are UTC and valid for intended broadcast window.

After deposit:

• Confirm DataConfirmation, DataAcceptance, and DataReceipt were received with matching IDs/hashes.
• If replacing a record, verify overwrite behavior using the same recordID.

Notes

• This README documents ASN message structure and expected exchange sequence.
• Service URL and deposit endpoint paths are documented above but may be subject to change; always refer to the latest SDX API documentation for current endpoints and request/response formats.