
DGCA (QCI) Software Compliance for Drones
Drones are currently employed in a wide variety of civilian applications, including search and rescue, surveillance, traffic monitoring, weather monitoring, and firefighting, as well as personal drones and commercial drone-based photography, videography, agricultural, and even delivery services. Transportation, agriculture, defense, law enforcement, surveillance, and emergency response are just a few of the businesses that benefit from drones. In recent years, consumer interest has expanded as the demand for aerial photography and a wide range of business applications has grown in India’s B2B sector.
Quality Council of India (QCI) is an authority that adheres to the quality standards to improve the quality of human life and the well-being of every citizen of India. QCI has laid certain quality checks for drones that every drone OEM and drone user has to follow. Certain rules and regulations laid by the Government of India and mandatory checks laid by QCI must be followed when flying a drone in India, which will be explained further in this article.
The Drone Rule: Type Certification is a must to fly a drone which must be approved by the Government of India. Every drone model must be Type Certified by DGCA (Directorate General of Civil Aviation). Once drone model type certification is done, then every drone must have UIN (Unique Identification Number) to fly it. The pilot who flies the drone must be a certificate holder to fly a drone and he must fly drone in green zone or yellow zone (with additional permission) defined by the law.
Classification of unmanned aircraft systems: Based on the maximum all-up weight including payload unmanned aircraft systems (UAS) are classified as follows:
Nano UAS: weighing less than or equal to 250 grams.
Micro UAS: weighing more than 250 grams, but less than or equal to 2 kilograms.
Small UAS: weighing more than 2 kilograms, but less than or equal to 25 kilograms.
Medium UAS: weighing more than 25 kilograms, but less than or equal to 150 kilograms.
Large UAS: weighing more than 150 kilograms.
Drone Pilot Certificate: A drone remote pilot certificate is essential for anyone flying a drone in civil airspace. To earn a pilot certificate, a person must be at least of 18 years old, have passed the tenth-grade exams, and have completed the required training at an approved Remote Pilot Training Organization (RPTO). After acquiring a training certificate from an RPTO, the DGCA will issue a remote pilot certificate to a person through Digital Sky within 15 days. Operating nano and micro drones for recreational purposes does not require a remote pilot certificate.
Category of Flying Zones: The Drone Rules 2021 associated airspace maps classify Indian airspace into three zones as follows:
“Red Zone” means the airspace of defined dimensions, above the land areas or territorial waters of India, or any installation or notified port limits specified by the Central Government beyond the territorial waters of India, within which unmanned aircraft system operations shall be permitted only by the Central Government.
“Yellow Zone” means the airspace of defined dimensions above the land areas or territorial waters of India within which unmanned aircraft system operations are restricted and shall require permission from the concerned air traffic control authority. The airspace above 400 feet or 120 meters in the designated green zone and the airspace above 200 feet or 60 meters in the area located between the lateral distance of 8 kilometers and 12 kilometers from the perimeter of an operational airport, shall be designated as a yellow zone.
“Green Zone” means the airspace of defined dimensions above the land areas or territorial waters of India, up to a vertical distance of 400 feet or 120 meters that have not been designated as a red zone or yellow zone in the airspace map for unmanned aircraft system operations and the airspace up to a vertical distance of 200 feet or 60 meters above the area located between a lateral distance of 8 kilometers and 12 kilometers from the perimeter of an operational airport.
Drone Type Certification: In India, no drone can be operated unless it has a certificate of airworthiness or is exempted from the requirement under these laws. On an application filed by a manufacturer or importer of that type of drone on the digital sky platform, the Quality Council of India (QCI) or a certification entity authorized by the QCI or the Central Government may issue a certificate of airworthiness for that type of drone if it meets the specified certification standards. These standards may promote the use of made-in India technologies, designs, components, and drones; and India’s regional navigation satellite system named Navigation with Indian Constellation (NavIC).
Any manufacturer or importer seeking a certificate of airworthiness should apply through Form D-1 on the digital sky platform, to the QCI or any other certification entity authorized by these rules, providing the following:
a) Name, contact details, and GSTIN of the applicant.
b) Details and required documents in respect of the prototype drone.
c) Proof of payment of the prescribed fees; and
d) Prototype drone that shall be physically handed over to the certification entity.
Software Compliance Requirements for Type Certification
The software plays a crucial part in operating the RPAS as it is a remotely piloted aerial system that is to be operated remotely through the software. The software review process helps both the certification authority and the applicant to determine whether a drone model will meet the certification requirements. For each test conducted for certification credit, the conformity of the test article, test setup, test procedures used, and the validity of the test results should be established. It becomes mandatory to check the correct software version has been loaded into the system with the correct system hardware (part numbers and serial numbers) has been installed on the RPAS. When the software loading procedure or ground support equipment detects a mismatch in part and version numbers or an unsuccessful load, an error indication should be displayed. Here is a list of software compliance requirements.
1. Communication Link is Active and Working: Data link loss should be declared if the link is lost for more than the time specified by the manufacturer’s recommendations.
2. Correct GPS location of the drone: Ensure that the GCS software is showing the correct GPS location of the drone flying in flying view.
3. Secure Boot:
a.Flight Module Security: It is expected that the flight module security should be of level 0 or level 1; where communication between the Flight controller and companion computer must be encrypted usin128-bit symmetric encryption keys.
b. Calculations of Checksums: Initially, the OEM should submit the registered checksums for code and data checksums separately.
c. Power on self – test: On every boot of the drone, the checksum i.e. data and code checksum of the firmware must be checked by the drone. It must ensure that the checksum is matching with the previously updated checksum and upon successful verification of the checksum, it must allow the drone to operate further.
d. Firmware changes: All firmware changes should be recorded in the logs. On GCS’s side, a firmware update should be recorded in the file. After the RPAS is upgraded, the registered checksum should be securely updated on the flight. The checksums of the updated firmware (code and data) are to be digitally signed by the CB. RPAS should be able to verify the authenticity of the update by verifying it with the public key of the manufacturer. The public key can be retained from Flight Module (FM) and can be further used for verifying the origin of the logs generated by FM.
4. Firmware Tamper proof: UAS should not function if the firmware is changed by any procedure other than the authorized update procedure defined by the drone manufacturer.
a. Secure Firmware Upgrade facility available: Firmware is the software that is a brain of a drone. Everything from flight inputs to energy management and everything in between is controlled by it. As a result, having secure firmware is critical if you want to operate your drone securely and reliably. When updating your device, make sure you select the proper model because installing the wrong firmware can cause your drone to malfunction. There should be a proper firmware upgrade procedure defined so that only digitally signed firmware can be upgraded in the drone. There should be a provision of having a private key of the drone manufacturer’s digital certificate at the ‘Update server’ and each drone should hold the public key of the digital certificate. During the update of the firmware, the public key and private exchange must be done. Upon successful exchange of keys only, the firmware update must be allowed. The firmware needs to be upgraded only if new features are added or if any bugs are found in the earlier version. The OEM will release the notification regarding the firmware upgradation and accordingly the user should upgrade the firmware.
5. Geofence capabilities: Geofencing is virtual boundaries or invisible force fields around physical locations. This is the technology that prevents a drone from flying into a sensitive no-fly zone, such as an airport, nuclear power plant, or a high-profile event. Horizontal, vertical, and time geofencing are to be set for every flight. The maximum limit for vertical geofencing is 120 meters. The drone is allowed to fly vertically within 120 meters or 400 feet only. AeroGCS provides these settings in the mission plan flight settings.
6. RTH: Manufacturer to demonstrate with flight the implementation of Autonomous Flight Termination System or Return Home (RH) option and document the functionality about the same in RPAS Flight Manual.
Compliance Matrix Template
Compliance is the fact of obeying a particular law or rule or acting according to an agreement. The hardware and software developed for drones should follow all the rules mentioned above. To have a type certificate the Drone OEM should provide the evidence and proof of complying for all the rules and regulations. There are various parameters to comply with the product. These are broadly classified into hardware, software-related, safety and security of firmware and hardware also, environmental-related, area of application, etc.
QCI Compliance Matrix with AeroGCS KEA
A compliance matrix will show you how each requirement of compliance is addressed. A compliance matrix can assist you in creating a compliance outline that includes everything the certifying body expects to see. AeroGCS KEA provides the outline and essential documentation required to get your compliance.
1. Data link loss (Section 6.1): The user can set the link loss time as per the user’s choice in AeroGCS. In communication link settings under the advanced button, the user can see the disconnection time feature.
When a data link is lost for more than 10 seconds, the RPA follows a predefined path to ensure a safe end of flight within the required area restrictions Demonstration of implementation of command link loss strategy in the UAS. The system is capable to inform remote pilots using a warning signal in the event of data link loss.
2. GPS Location of the drone: AeroGCS software displays the correct GPS (Navigation) location as shown in the image below.
The latitude and longitude values are accurately displayed. The latitude and longitude give the exact position of the drone in the field. By using AeroGCS software one can easily track the drone flying at a remote place. Monitoring the path of flight is also possible.
3. Firmware Tamper proof (Section 5.2.1): AeroGCS Software does not allow unauthorized firmware upgrades in any way. When the firmware is changed from other GCS software it affects the compliance conditions. When the parameter changes, the checksum may mismatch. The changes in the parameters may result from the changes in the drone configuration or settings and the illegal keys. In this case, the firmware will not allow the drone to arm and take off. Power on Self-Test (POST) will be carried out for every time the drone boots. AeroGCS supports signing of firmware using digital certificates and embeds public keys of digital certificates in each firmware installed in each drone. After signing the firmware, the checksum is generated for each firmware. These code and data checksums are generated separately and help to maintain both separately. The private key of drone manufacturers’ digital certificate is stored at update server while public key is stored in drone.
AeroGCS KEA offers a central firmware update server so that whenever there is a new firmware version released due to bugs or feature, all the buyers can connect to this ‘update server’ to get and update the firmware as per the requirements. The notification regarding the authorized firmware up-gradation will be released by the respective OEM to all the buyers. The buyers can upgrade firmware easily after the notification is received. If the user is trying to change the type of frame then the code checksum will be affected resulting in a failure of the verification of firmware. The verification failed means no possibility to arm the device. When the user is trying to change the type of frame of device, he is trying to tamper with the firmware. Unless the user is selecting the proper frame type assigned to him, the AeroGCS won’t allow to arm the device.
This is required to provide the end-to-end security of the system. If anyone is trying to tamper with the hardware or any of the parameters of the firmware then the total security should not be affected. For the total integrity and security of the device and system POST and firmware tamper-proof facility is provided by AeroGCS. Thus AeroGCS is providing the end-to-end solution, security, and integrity to all.
4. Firmware Upgrade (Section 5.2.1): The user can flash the firmware of a particular device by selecting the desired type of firmware either manually or automatically. The dashboard of AeroGCS gives the facility to upgrade the firmware in the side drawer menu. In manual firmware up-gradation, the user can select the firmware file from the device which the user wants to flash into the board. The user can select the .apj type file and can flash the firmware into the board. In automatic firmware up-gradation, the user can select the type of firmware according to the requirement and can flash the type of firmware of a specific board type. The SHA-256 hash of the firmware calculated in GCS and the signature of the firmware calculated using the manufacturer’s private key will be sent to FM. FM will then verify the hash and signature using the public key it has. If they match then only firmware flashing will be permitted. RPAS prevents the firmware flashing if they don’t match. This means the firmware cannot be flashed in an unauthorized manner. To update the firmware the following things should be known properly:
a) Bootloader: The bootloader gets the control first when the device boots. There is no way to update the bootloader. It is the unique piece of code that ensures that only a valid firmware image is ever loaded onto the device. AeroGCS provides the secured bootloader for the secure booting of a drone.
b) A metadata header: This file contains firmware information that the bootloader uses to validate the firmware before loading it.
c) A firmware image: Contains the OS, Update client, and the user application.
Click on this link for firmware upgradation in AeroGCS. https://20.244.107.53/manual-firmware-upgrade/
For flashing the firmware the OEM user has to follow the following steps:
1. Buy the document sign digital certificate from CCA authority or distributor
2. Drone OEM should be able to generate the public and private keys from PFX file format using open SSL commands.
3. Embed the public key into the firmware.
4. Sign the firmware using the private key.
5. Drone OEM needs to upload all necessary information and signed firmware, Data Checksum, Code Checksum to their account on AeroMegh platform.
The flow of firmware signing in is as shown below:
5. Secure firmware Upgrade: A “secure firmware upgrade” is a device’s capacity to validate the digital signatures of new firmware binaries, ensuring that only officially approved versions can be installed from the host, network, or a Board Management Controller (BMC). Validating the authenticity of firmware upgrades keeps internet-connected devices performing as intended; failure to validate could result in device compromise or destruction. The firmware’s integrity and authenticity are validated by a signature. Regardless of authority, if the provided signature matches the firmware, a device can be confident that the holder of the private keys for the signature has approved the firmware.
Signature of the firmware is calculated using the manufacturer’s private key i.e. digital certificate and an SHA-256 hash of the firmware calculated in GCS will be sent to FM. FM will then verify the hash and signature using the public key it has and the SHA-256 hash of the firmware calculated in GCS sent to FM if they match, then only firmware flashing will be permitted. RPAS prevents the firmware flashing if they don’t match. This means the firmware cannot be flashed in an unauthorized manner.
6. Power on Self-Test (POST) (Section 5.2.4): POSTs are performed immediately after a board is powered up. The hardware components of the board are diagnosed during these testing. As soon as RPAS is powered on, it checks the checksum of the firmware. When the firmware is appropriate then only AeroGCS allows further process. AeroGCS always checks the checksum and after ensuring the right checksum, it allows further operations. All the logs related to POST are stored on a local SD card.
7. Flight Controller with flight data logging capability: Users can see the details of the flight like plan name, project name, start time, end time, date, flight id, duration, average altitude, and average speed. Also, the user can see the altitude, speed, battery, and logs related to the flight. The user will get the graphical and statistical data related to the completed flight in the form of details such as time, altitude, speed, battery status, etc. The flight logs indicate the changes in the device’s pitch, roll, yaw, and altitude values. The user will study the graphs and analyze the behavior of the device.
8. Arming Checks to perform (ARMING_CHECK) – Check all appropriate: Barometer, Compass, GPS lock, INS, Parameters, RC Channels, Board voltage, Battery Level, Airspeed, Logging Available, Hardware safety switch, GPS Configuration, System.
9. Calculations of Checksums (Section 5.2.3): Code and data checksum are calculated separately. Code checksum will be generated when the firmware is flashed for the first time and on every firmware update. Whereas, Data checksum will be generated whenever there is a change in the configuration and settings of a drone. So data/parameters can be easily updated. Registered checksums are stored inside the firmware. Update of registered checksum only happens after firmware flashing and firmware is only able to be flashed if it has been signed in an authorized manner.
10. Mismatch of checksum: Mismatch of checksum makes UAS non-functional i.e. it cannot be armed and will not take off. Firmware checksum verification failed message popup is shown. (If UAS is to be prevented from booting need to add some hardware indication like LED, buzzer on FM).
11. Authenticity: of the update by verifying it with the public key of the manufacturer.
AeroGCS will check for the authenticity of the firmware. The system will ask for details to enter in the prescribed format so that the signature will be verified. If any of the parameters is mismatched then the drone may not be able to fly.
12. Secure Change of Flight Parameters: The public key stored inside the FM verifies the signature and calculated hash. RPAS verifies the authenticity of the update using the public key of the manufacturer. Logs are stored on SD cards and GCS software. For any parameter which affects compliance is tried to change, the system does not allow to function the RPAS. Therefore, no invalid digital signature should be used. On GCS’s side, a firmware update is recorded in the file. Whenever UAS is upgraded, code and data checksum are calculated using SHA256 and securely saved in the FM. The attempt to update the parameter in the firmware that affects the compliance results in the hash and signature Verification and it is disallowing for vehicle operation and take off.
13. Geofencing (Section 5.5): The geofencing capability has been implemented in AeroGCS KEA. AeroGCS KEA allows defining the geofence around the mission plan and sets the actions for breaching the fence. This is a safety feature by default provided by AeroGCS KEA. The user can set the fence radius or height with the maximum values for causing a breach, and the action in the event of a breach.
The actions include:
Report only: Report fence breach: only reporting of the breaching the fence will be generated.
RTL: RTL or launch on fence breach: the device will be launched safely.
Max Radius: Circular fence radius: Breaching the radius of the fence will allow the safe launching of the device.
Max altitude: Fence maximum altitude to trigger altitude geofence. If the device reaches above the maximum altitude set then the system will indicate the warning.
Geofence is automatically defined in the Flight type of the mission plan. No need to define manually. If a device is moving outside this fencing then the system should act according to the settings provided.
14. Return to Launch (RTL) (Section 5.6): To secure the landing of drone at the launch point in case of any emergency, AeroGCS KEA offers the feature to configure RTL setting.
AeroGCS provides the details of the flight such as yaw, pitch, roll, and the value of altitude of the device. The status of the device such as RTL, armed, etc. is also displayed on the screen indicated by the black rectangle in the above image. The status of the battery is also displayed which is helpful for taking emergency decisions of landing, pausing, or not to fly, changing the batteries, etc.
15. Failsafe trigger: AeroGCS provides various drone safety options in RPA configuration. The user can set the various safety parameters such as Battery failsafe, Return to Launch (RTL), Geofence, Failsafe Triggering, and Arming Checks.
The Ground Station Control (GCS) failsafe regulates how the Copter reacts if it loses contact with the GCS. When a GCS failsafe is triggered, the copter can be configured via parameters to do nothing, land immediately, RTL, or SmartRTL. It can also be configured to bypass the failsafe in an Auto Mode mission, bypass the failsafe in pilot-controlled modes, or continue landing if already in a landing phase. Based on rate gyroscopes, accelerometer, compass, GPS, airspeed, and barometric pressure measurements, an Extended Kalman Filter (EKF) algorithm is used to estimate vehicle position, velocity, and angular orientation. An EKF also enables measurements from optional sensors such as optical flow and laser range finders to be used to assist navigation. The throttle failsafe is activated by setting the throttle input channel using the Throttle failsafe option in AeroGCS.
AeroGCS provides access to the OEM server, secure bootloader, and assistance for firmware setup, flashing, and upgrading the firmware. AeroGCS helps to verify the signature. It continuously verifies the checksums, calibration of drones, and all other drone-related operations. Also, AeroGCS extends its services to cater the QCI compliance.