Skip to main content

Chapter 7 — Non-Functional Requirements

This chapter defines the non-functional requirements (NFRs) that your USS must satisfy to be approved for the BR-UTM ecosystem. These are enforced during homologation and are continuously expected in production.

Failure to meet these requirements can result in:

  • Rejection during homologation.
  • Operational incidents (missed emergency notifications, incorrect timestamps, clock drift).
  • Potential deauthorization from the ecosystem.

7.1 Time Synchronization (NTP)

Requirement: Your USS's system clock must be synchronized with DECEA's NTP server with a precision of ≤ 5 seconds.

Parameter Requirement
NTP Server ntp.decea.gov.br
Maximum offset ≤ 5 seconds
Authentication Required (NTP authentication, integrity and anti-spoofing protection)

All timestamps generated by your system (for OIR time windows, telemetry, notifications, and audit logs) must be derived from this synchronized clock.

Verification endpoint: GET /diagnostics/time

Your GET /diagnostics/time endpoint must return current sync status, including the NTP source, stratum, offset in milliseconds, and last synchronization time. DECEA will call this endpoint during homologation to verify compliance.

{
  "system_time": "2026-07-01T10:32:15.482Z",
  "ntp_sync": {
    "synchronized": true,
    "source": "ntp.decea.gov.br",
    "stratum": 2,
    "offset_ms": 38,
    "last_sync": "2026-07-01T10:32:05.000Z"
  },
  "timestamp_format": "ISO 8601"
}

7.2 Timestamp Format

Requirement: All dates and times stored or transmitted by your USS must conform to ISO 8601 (RFC 3339) with the UTC timezone (expressed as Z suffix).

Parameter Requirement
Format ISO 8601 / RFC 3339
Timezone UTC (Z)
Examples "2026-07-01T10:32:15Z" or "2026-07-01T10:32:15.482Z"

Never use local time or non-UTC offsets in any field transmitted to the DSS, to other USSs, or in any API response. This includes:

  • OIR time windows (time_start, time_end)
  • Volume4D time bounds
  • Telemetry timestamps
  • ISA time windows
  • Audit log entries

When wrapping timestamps in the BR-UTM Time structure:

{ "value": "2026-07-01T10:32:15Z", "format": "RFC3339" }

7.3 Notification Latency

Requirement: When your USS creates, updates, or deletes an OIR or Constraint in the DSS and receives a list of subscribers to notify, it must send the POST /uss/v1/operational_intents (or POST /uss/v1/constraints) notifications to each subscriber within:

Metric Requirement
Target latency ≤ 5 seconds
Required percentile ≥ 95% of cases

This means that in 95% of all notification events, the subscriber USS must receive the notification within 5 seconds of your DSS write completing. Up to 5% of cases may exceed this threshold (e.g., due to transient network conditions).

Implementation guidance:

  • Use asynchronous notification dispatch to avoid blocking the main OIR creation flow.
  • Implement reasonable timeouts (e.g., 5–10 seconds per subscriber) so a slow subscriber doesn't delay notifications to others.
  • Fire notifications in parallel when there are multiple subscribers.

7.4 Conformance Monitoring Response Time

Requirement: When your USS detects that a drone has left its declared OIR volumes, it must:

Action Time Limit
Detect position out-of-volume ≤ 10 seconds after last telemetry update shows deviation
Update DSS with Nonconforming state ≤ 5 seconds after detection

This means the worst-case end-to-end timeline from drone position deviation to DSS update is 15 seconds.

Additionally:

  • After 60 continuous seconds in Nonconforming state, the USS must transition to Contingent.
  • Both state transitions must include notification to all subscribers in the area.

7.5 Telemetry Update Frequency

Requirement: Your USS must update the telemetry data served at GET /uss/flights at an interval of:

Metric Requirement
Maximum update interval 10 seconds
When required During any Activated, Nonconforming, or Contingent operation

In other words: the position data returned by GET /uss/flights must never be more than 10 seconds stale for an active flight.

7.6 Geospatial Intersection Precision

Requirement: Your USS must be able to calculate 4D intersection between volumes with:

Parameter Requirement
Horizontal precision 1 centimeter (1 cm)
Dimensions Latitude, longitude, altitude, time

This precision is required for accurate conflict detection between OIRs and between OIRs and Constraints. Using imprecise intersection algorithms (e.g., simple bounding box checks) is not acceptable and will fail homologation scenarios.

Your intersection logic must handle both polygon and circle geometries, and combinations thereof.

7.7 Audit Logging

Requirement: Your USS must maintain comprehensive audit logs of all safety-critical operations. All audit log entries must use timestamps derived from the NTP-synchronized clock.

The audit log must capture:

  • All OIR state transitions (creation, activation, nonconformance, contingency, deletion).
  • All peer-to-peer notifications sent and received.
  • All telemetry positions recorded during active operations.
  • All conflict detections and deconfliction actions taken.
  • All token validation results for inbound requests.

These logs must be retained for traceability and may be requested by DECEA during incident investigations.

7.8 Subscription Continuity

Requirement: Your USS must maintain an active subscription for any area where you have an active OIR. This ensures you receive notifications about changes in the airspace around your operations.

  • Subscriptions must remain active for the full duration of the OIR's time window.
  • If a subscription is lost (e.g., due to a DSS connectivity issue), your USS must re-create it as soon as connectivity is restored.
  • Your USS must process all incoming notifications and re-evaluate its conflict status whenever a new or updated OIR/Constraint arrives in the subscribed area.

7.9 DSS Discoverability

Requirement: An OIR may only transition between states (Accepted, Activated, Nonconforming, Contingent) if it is currently discoverable by other USSs via the DSS.

This means:

  • Before transitioning state, your OIR must exist in the DSS with the correct extents, uss_base_url, and subscription_id.
  • If your DSS write fails, you must not proceed with the state transition.
  • If your USS cannot reach the DSS, active flights must not proceed to activation.

7.10 Summary Table

NFR Requirement
NTP synchronization ntp.decea.gov.br, ≤5s offset, authenticated
Timestamp format ISO 8601 / RFC 3339, UTC (Z)
Notification latency ≤5 seconds in ≥95% of cases
Nonconformance detection ≤10 seconds
Nonconformance DSS update ≤5 seconds after detection
Contingent trigger After 60 continuous seconds Nonconforming
Telemetry update interval ≤10 seconds for active flights
Geospatial intersection precision 1 cm
Audit logs All safety-critical events, NTP-derived timestamps
Subscription continuity Active for full OIR duration
DSS discoverability Required before any state transition
No Comments
Back to top