Unmanned Flight and Airspace Management Specification


#1

Hello everyone,

We are working on developing an open-source standard for unmanned flight/airspace management standard which will be developed under apache2 license so that it can be easily adopted in other parts of the world.

The standard should define interaction and/or behavior of

  1. Switch
  2. Various Service Providers (DSP, ATC, etc)
  3. Manufacturer
  4. Unmanned Aircraft
  5. Others

Key concepts are borrowed from existing DigitalSky standard 1.0 and we have identified the following areas for improvement on RFM.

  1. Add versioning
  2. Inclusion of ECC
  3. Clarity on Internal ID/UUID
  4. Clarity on Keypair Generation
  5. Flights Logs API - Skylark/Abhiroop
  6. Programmability of Permissions Artefact (Formats, Signature, Updates to Permission Artefacts) - atleast one compact format
  7. Clarification on Pilot Pin
  8. Responsibility Shift of Device Management Server (Telco operator model, Sidhant’s feedback)
  9. Key rotation without need of management server
  10. Registration before sale?
  11. Minimum standards for communication between chips/modules/TEE
  12. Sequence Diagram on APIs
  13. Geofence (Hard/Soft) and actions in case of a breach

We will have weekly calls on Sunday, 3:00 PM. Let’s start by having our first call on April 14th, 2019.
Please reply if you are interested in contributing and can join the call this Sunday. We can use skype.

Thanks all, looking forward to completely open drone ecosystem.


#2

Hey Sidhant, sorry I did not notice this thread. I am open to joining the discussion. Please let me know when is the next call.


#3

Please join, Sunday @ 3:00 pm :slightly_smiling_face:
Send me your Skype address


#4

Hi Sidhant, from what I’ve understood, the responsibility of key rotation will no longer rest with the Management Server? Where is this to happen in this case?

From what we thought, the ability to rotate keys should solely rest with the manufacturer, who is in full control of the Management Server.


#5

Let’s restart this? Could we have the first call this Sunday 2nd June at 3:00 PM?


#6

Hi cks123,

The ability of key rotation is with manufacturer and hence RFM itself can key rotate, signing new public key with old key pair, in which case no server is required.


#7

Hi All,

We met on Tuesday, 4th June 2019, 3:00PM at IKP Eden. Following are the notes from the meeting.

Flight log feedback and Todos

A new simpler flight log schema was proposed that can provide the required features -

  • Traceability between entries and Permission Artefacts
  • Simpler to parse and create
  • Computationally less expensive.

Proposed record template -

{ PA_ID:

Drone ID (any , up for discussion) :

Timestamp:

Coords:

Type:

Previous Hash:

Record Hash: for non-final record only.

Record Signature: for Final record only.}

However the old schema also has to be updated with the changes that will help achieve the same functionality.

  • Type of Entry to be added to every record - (Armed/Takeoff ; Geofence Breach ; Time breach ; Land/Disarmed)
  • Signature to be added to schema
  • Previous log signature

UPDATE - Existing schema to be updated EOD

Followup - Update schema in test tool after that

Public key (registration and renewal)

  1. Add certificate (generated by Manufacturer containing, public key of RPAS and other drone data) as a field in register api.
  2. Signature specification in PKCS8
  3. Public key should be in PKCS8 - DER and base64 encoded.
  4. Create a new end point for renewal of key. Send updated key
  5. Note - Send the certificate of the drone along with the flight log for upload.

Compact Permssion Artefact

Goal - smaller easier PA

TLV , DER, - not positional , upgradeable

Feedback to Digital sky Portal - Generate a signed PDF of permission details on every request.

Note - OID for certificate details.

Note - review the registration API and other API’s to check for need and consistency

The Great clarification on Drone ID’s

  1. UIN - issued after operator Linkage. Volatile.

  2. Drone ID -

  3. Fixed for lifetime

  4. UUID

  5. Generated by RPAS/ Manufacturer Server

  6. Included in certificate signed by the manufacturer.

  7. Internal IDs - may or may not be used and generated by manufacturer in RPAS. not relevant to Digital sky

Other IDs

Pilot and Operator ID should be internal only. There should be another ID that acts like a license/registration number.

Backend Digital sky thing only

RFM APIs

A lot of the APIs are not required for operation of the RPAS and have to be removed.

For Remote ID ,

TODO - research on the Remote ID specifications.

Data to transmit on remote ID -

  • Drone ID and Certificate
  • Pilot ID number form PA
  • Coords
  • UIN

TODO: Telco operator Model

Schedule a discussion

We are planning to have weekly meeting on weekdays instead of weekends, will post the schedule and agenda of next meeting soon.

Cheers
Sidhant


#8

Kudos to the community for the meet. There is a new online tool available on https://digitalsky.dgca.gov.in/ Is this using Python only or some other language. We have tested our code using the json functions used on the python based provisional testing tool. I want to ask if there any difference lies in the signature verification between both the tools. Also, there is one more test added No. 6 for breach test which was absent in the python based tool. It would certainly be helpful for everyone if you can give a better clarity regarding that.

Regards
Satyam


#9

Share schedule, Avianco would love to contribute.


#10

@nihal @sidhant
right now the PA we are getting from DGCA are in .zip format, and when we send PA from RPAS to DGCA that can be in any format i mean DGCA accepts PA in any format i.e. .zip, .xml etc.
so will be there any standard format in DGCA in future to accpet the PA in the particular format.
what format should we follow? now we are sending PA in zip format.
kindly suggest


#11

@nihal @sidhant
We are developing NPNT software from three months.
till dat we acheived

  • Key management
  • Flight log generation
  • Verified authenticity of the PA digitally signed certificate
  • Device Registration check
  • Get Internal ID and UUID mapping
  • MS APIs
  • Flight module public key on MS
  • Self signed digital certificate
  • Registration and deregistration mock API
  • Geofencing
  • breach logs
  • time limit logs

we have some doubts as follows-
–how to test complete NPNT flow
–formats ,crypto algorithms used in NPNT

can we have talk in person or skype call?


#12

My company, Algopixel Technologies, provides Flight Module Management Server. The server also has a test mode which can be used to test the complete flow using a replica of Digital Sky. I have sent you the details on DM.