Chapter 8 — Homologation This chapter describes the homologation (validation) process that a company must complete before receiving a production API Key and being authorized to operate in the BR-UTM ecosystem. 8.1 What Is Homologation? Homologation is DECEA's process for validating that a USS implementation: Correctly implements all required APIs (as defined in the OpenAPI specifications). Behaves correctly in all defined operational scenarios. Meets all non-functional requirements (timing, precision, synchronization). Is ready to operate safely alongside other USSs in the live ecosystem. The process is primarily manual — conducted by DECEA engineers who run test scenarios against your deployed system. DECEA may also use internal automated testing tools ( uss_qualifier or equivalent) to exercise specific scenarios programmatically. 8.2 Prerequisites for Homologation Before requesting homologation, your USS must: Implement all mandatory production endpoints (see Chapter 6 ): GET /uss/v1/operational_intents/{entityid} POST /uss/v1/operational_intents POST /uss/v1/constraints GET /uss/flights GET /uss/flights/{id}/details GET /version GET /diagnostics/time POST /telemetry Implement all testing endpoints : All flights.yaml endpoints All injection.yaml endpoints The versioning.yaml endpoint Be deployed and reachable from the internet with a valid HTTPS base URL. Be registered in the Sandbox with a development API Key and able to interact with the Sandbox DSS. Satisfy all non-functional requirements (see Chapter 7 ), especially NTP synchronization. 8.3 Requesting Homologation To initiate the homologation process: Contact DECEA through the official support channels: Mattermost (developer channel) Central de Ajuda (ticketing system) Provide: Your company name and CNPJ. The version of your software being submitted. The publicly accessible base URL of your USS. Contact details for the technical team. DECEA will schedule the homologation session and provide: A testing API Key (granting access to the test ecosystem). The URL of the test ecosystem (if separate from the main Sandbox). The test scenario list to prepare for. 8.4 What DECEA Tests DECEA validates your USS against 18 defined scenarios. Each scenario tests one or more functional and non-functional requirements. Scenario Matrix # Scenario Key Requirements Tested 1 Register an operation in an empty area Auth (8.1), NTP, notifications (8.2), OIR creation (8.3), conflict check (8.4), DSS discoverability 2 Register an operation near a non-intersecting Constraint + Constraint query and processing (8.7) 3 Register an operation near an intersecting Constraint + 4D intersection detection, deconfliction (8.5), operator notification 4 Register an operation near a non-intersecting OIR + Peer-to-peer OIR details fetch 5 Register an operation near an intersecting OIR + Deconfliction, operator notification 6 Delete an operation (OIR) + Deletion notification to subscribers 7 Activate an operation conflicting with another active OIR at the same priority + Pre-activation conflict check (8.6), blocking activation 8 Activate an operation conflicting with an active OIR at higher priority + Deconfliction before activation 9 Activate an operation conflicting with an active OIR at lower priority + Correctly allows activation when lower priority conflict exists 10 DECEA creates a Constraint over an existing Accepted OIR + Reaction to constraint notification (8.11), deconfliction or state change 11 DECEA creates a Constraint over an existing Activated OIR + Immediate reaction (Nonconforming or deconfliction) 12 DECEA's USS activates a higher-priority OIR over an active OIR + Priority-based conflict resolution, deconfliction 13 USS creates an ISA when the OIR is activated + Remote ID ISA lifecycle (8.8) 14 USS shares drone position during an active operation + Telemetry serving at /uss/flights and /uss/flights/{id}/details 15 USS updates drone position every 10 seconds + Update frequency requirement 16 Drone position exits OIR volume → transition to Nonconforming + Conformance monitoring timing (≤10s detection, ≤5s DSS update) 17 Drone position exits OIR → Nonconforming → returns → back to Activated + Recovery from non-conformance 18 Drone position exits OIR → Nonconforming for 60s → Contingent + Full emergency state machine Requirement Mapping Code Full Requirement RF 1 4D geospatial intersection calculation, 1 cm precision RF 2 DSS discoverability before state transitions RF 3 Automatic high priority for critical situations RF 4 Transition to Accepted only if no higher-priority conflict RF 5 Pre-activation final conflict check RF 6 Continuous situational awareness via subscriptions RF 7 Automatic conflict notification to operators RF 8 CMSA-only role for Nonconforming/Contingent transitions RF 9 Constraint intersection analysis before OIR creation RF 10 Continuous constraint monitoring during operations RF 11 Automatic propagation of constraint notifications to affected operators RF 12 Full telemetry recording during conformance monitoring RF 13 Aircraft position updated and available within ≤10 seconds RNF 1 NTP synchronization to ntp.decea.gov.br RNF 2 Consistent timestamps from synchronized clock RNF 3 Notification latency ≤5s in ≥95% of cases RNF 4 ISO 8601 / RFC 3339 with UTC timezone RNF 5 Audit logs with NTP-derived timestamps 8.5 How the Automated Testing Works For scenarios involving Remote ID (scenarios 13–15), DECEA's test framework calls your injection.yaml endpoints to inject simulated telemetry: DECEA's framework calls PUT /tests/{test_id} with a sequence of simulated aircraft positions. Your USS processes these as if they were real drone telemetry and makes them available via GET /uss/flights . DECEA's framework queries GET /uss/flights and GET /uss/flights/{id}/details to verify the data is correct and timely. After the test, DELETE /tests/{test_id}/{version} clears the injected data. For scenarios involving flight planning (scenarios 1–12), DECEA's framework uses your flights.yaml endpoints: DECEA's framework calls PUT /flight_plans/{id} to simulate a user creating a flight plan. Your USS translates this into an OIR creation in the DSS and notifies subscribers. DECEA validates the DSS state and your subscriber notifications. POST /clear_area_requests may be used to reset the test environment between scenarios. For conformance monitoring scenarios (16–18), DECEA combines both injection.yaml (to inject positions outside the volume) and flights.yaml (to set up the OIR), then monitors whether your USS correctly transitions states and notifies within the required time limits. 8.6 Testing Environment Access During homologation, DECEA provides a dedicated test environment: A test API Key with access to the test ecosystem. Possibly a separate test DSS instance. Access credentials for DECEA's monitoring systems (Interface UTM) to observe your operations during the test. This testing key and environment are separate from your normal development (Sandbox) key. 8.7 After Successful Homologation Upon passing all scenarios: DECEA grants your software the U1 permission level for the production environment . You receive a production API Key tied to your validated software version. You can now: Create UTM Zones in the production Portal UTM. Begin operating flights in production. Generate sub-keys for third-party operators using your software. Third-Party Sub-Keys If your USS software is a platform sold to third-party drone operators: Your company (as the validated software owner) creates sub-API Keys for each third-party client. The third-party client uses their sub-key to authenticate and to create their own UTM Zones. All operations under sub-keys are still associated with your validated software version. 8.8 Re-Homologation If you release a new major version of your USS software with significant architectural changes, a new homologation process may be required. Contact DECEA to determine whether re-validation is needed for your specific changes. Minor updates and bug fixes that do not affect the API contract or safety-critical behaviors typically do not require re-homologation. 8.9 Homologation Checklist Use this checklist before requesting homologation: APIs GET /uss/v1/operational_intents/{entityid} implemented and tested POST /uss/v1/operational_intents implemented (correctly handles creation, update, deletion) GET /uss/v1/constraints/{entityid} implemented POST /uss/v1/constraints implemented GET /uss/v1/operational_intents/{entityid}/telemetry implemented (active in Nonconforming/Contingent) GET /uss/flights implemented with correct data structure GET /uss/flights/{id}/details implemented GET /version implemented GET /diagnostics/time implemented with NTP status POST /telemetry implemented All flights.yaml endpoints implemented All injection.yaml endpoints implemented versioning.yaml endpoint implemented Functional OIR creation → DSS → subscriber notification flow works end-to-end OIR state transitions (Accepted → Activated → Nonconforming → Contingent) work correctly Pre-activation conflict check is performed Constraint queries and processing are implemented ISA is created on activation and deleted on flight closure Incoming POST /uss/v1/operational_intents notifications trigger conflict re-evaluation OIR deletion triggers subscriber notification (with operational_intent omitted) Nonconforming detected within 10 seconds DSS updated within 5 seconds of Nonconforming detection Contingent triggered after 60 seconds of Nonconforming Non-Functional NTP synchronized to ntp.decea.gov.br with ≤5s offset All timestamps in ISO 8601 / RFC 3339 / UTC Subscriber notifications sent within 5 seconds in ≥95% of cases Telemetry data updated at most every 10 seconds 4D intersection precision at 1 cm Audit logs in place with NTP-derived timestamps All inbound JWT tokens validated (signature, expiry, audience, scope) System deployed publicly on HTTPS