Previous post in this series: Drone Regulations – Part 1: UIN, UAOP, Operational Restrictions
In this post, we will explore the concept of NPNT, the concept of a Flight Module Provider and functional requirements of an RFM (Registered Flight Module) as specified in the RPAS Guidance Manual.
Flight Module Provider
The Guidance Manual introduces the concept of a Flight Module Provider. As per Chapter 7 Section 1.3: “… the term ‘Flight Module Provider’ is used to refer to a RPAS
manufacturer or any agency who has a partnership with the manufacturer to manage
certification and related software/security aspects of registered flight modules… “. For most practical purposes, the manufacturer of a drone will be the Flight Module Provider. The manual also states that “The Flight Module Provider should be a legal entity registered in India and is responsible for certification, key management (as per this specification), and any security or other responsibilities set forth by DGCA.” There are two implications of this statement. First, if the drone is imported, an entity registered in India should register itself as the Flight Module Provider of the drone and undertake the responsibility for NPNT-compliance of the drone through certification and secure key management. Second, the Flight Module Provider’s responsibility does not end with the sale of a drone, she is also responsible to provide security updates and patches for the drone firmware/autopilot in case any vulnerability is discovered in her drone model after the sale of the drone.
Registered Flight Module
As per Section 2 of Chapter 7 of the RPAS Guidance Manual, a Registered Flight Module is a device or a combination of devices on-board the drone which fulfils the following specifications:
- Non-Repudiable Identification of RPAS – every Flight Module has a unique identifier allowing an end to end traceability, accountability, traffic management and forms the foundation for issuance of UIN.
- No Permission No Takeoff (NPNT) – every RPAS must obtain a valid permission artefact and verify the same before it can arm itself.
- Eliminating use of synthetic flight logs – there should be no mechanism for any external system to provide simulated flight logs and get it signed.
The manual leaves the implementation details to the manufacturer and states that “DGCA does not mandate any specific hardware design and Flight Module Providers
are expected to innovate appropriate form factors for market use.” This implies that the manufacturers are free to design and develop the hardware/software as they want as long as they can demonstrate that the unit as a whole fulfils the NPNT requirements.
In the first version of the Guidance Manual, there was a confusion with regards to the location of the RFM and whether the NPNT requirements can be implemented on the GCS itself. In Revision 1 of the Guidance Manual, a look at Exhibit C clears this issue.
In the above diagram, the RFM unit is clearly within the left-most demarcation labelled as Drone. This confirms the fact that the RFM functionality should reside within the drone unit.
Now we’ll discuss the RFM specifications in detail:
Non-Repudiable Identification of RPAS
The RFM should allow for secure storage to store the digital identifiers for a drone. Unauthorized access should not be allowed to this storage. The digital identifiers can include the drone private key, UIN and Drone Id among other manufacturer-specific identifiers. The RFM should utilize these identifiers to determine the identity of the drone and to detect any tamper with the components. The RFM should be able to communicate the identity of the drone if required to do so.
No Permission No Takeoff
A Permission Artifact is an electronic document generated by the Digital Sky platform which specifies the permitted parameters for a flight. An RFM should be able to accept a Permission Artifact and the RFM should allow the drone to be armed only when the Permission Artifact is validated and the permission parameters are verified. We’ll discuss the Permission Artifact in detail later.
Eliminating Synthetic Flight Logs
An RFM is required to generate flight logs in the format specified in the Guidance Manual. These flight logs later need to be submitted to the Digital Sky platform. An RFM should prevent the generation of spoofed flight logs. To ensure this, the RFM should make sure that the flight logs are signed in a secure manner.
In the next blog post, we will be looking at the registration flow which involves the generation of key pair, registering the drone on Digital Sky and the role of Flight Module Management Server.
Next Post: NPNT Regulations – Part 3: Digital Sky, RPAS Acquisition Application, UAOP License Application
