8.1 Maintenance, Technical Logs & Serviceability

8.1 Maintenance, Technical Logs & Serviceability

Quick Answer: Do not fly an unserviceable RPAS (CAR 901.29). Keep and follow manufacturer manuals (901.30–901.31). Record defects, repairs, inspections, and software/firmware changes in technical logs (901.48 themes). Separate elementary care from critical tasks; use two-person perform/verify for critical work. Pre-flight inspection is mandatory discipline; if it fails, ground the aircraft.

Advanced RPAS operations fail in the field more often from maintenance and configuration errors than from airspace theory. A declared multirotor with a cracked arm, overdue battery, or half-applied firmware update is not “still Advanced-capable”—it is an unserviceable system that can void safe operation and, for declared aircraft, undermine the configuration the safety assurance case assumed.

CAR 901.29 — Serviceability before flight

CAR 901.29 is the hard gate: the Remotely Piloted Aircraft System must be serviceable for the intended flight. Serviceability means the aircraft, control station, command-and-control link, power system, navigation/sensors required for the flight, and any installed safety features (return-to-home, geofencing, flight termination interfaces where fitted) are in a condition that meets the manufacturer’s requirements and the rules for that operation.

Operational translation:

Exam and field trap: confusing registration and marking (you may be legal on paper) with serviceability (the machine must actually work as required). Both matter; neither replaces the other.

CAR 901.30–901.31 — Manuals available and followed

901.30–901.31 themes require that the applicable manufacturer instructions, operating manuals, and maintenance documentation for the RPAS (and relevant components) are available to the people who operate and maintain the system, and that those instructions are followed.

What “available and followed” means in practice:

1. Available — crew can access the correct manual for this model and software/hardware revision, not a random PDF for a similar airframe or an outdated printed booklet from three firmware generations ago.
2. Followed — assembly, calibration, charging, firmware update, arming, emergency procedures, and maintenance intervals are performed as written, not as remembered from social media.
3. Configuration control — if the manufacturer issues revised procedures after a service bulletin, use the current revision for the installed configuration.

Ignoring a manufacturer torque value, battery storage voltage, compass calibration sequence, or “do not fly with cracked propeller” prohibition is a 901.30–901.31 compliance failure layered on a 901.29 serviceability failure.

Elementary vs critical maintenance tasks

Professional RPAS programs borrow manned-aviation thinking: not every task carries the same risk if done wrong.

Elementary tasks (typical pilot/owner care)

Elementary work is routine, low-risk care that does not redesign the aircraft or reverse critical structural/avionics integrity when done per the manual:

• Cleaning sensors and lenses with approved methods
• Installing user-replaceable propellers of the approved type
• Battery inspection, balancing charge per manufacturer procedure
• User-level compass/IMU calibration when the manual assigns it to the operator
• Checking fasteners and applying manufacturer-specified torque for user-serviceable items
• Updating firmware when the manufacturer documents the process as operator-performed and prerequisites are met

Even elementary tasks require the right parts, tools, and records when defects are found.

Critical tasks (airworthiness-affecting work)

Critical tasks affect structural integrity, flight controls, power distribution, navigation safety functions, or flight-termination hardware in ways that a wrong step can create a latent failure:

• Structural arm/boom repair or replacement after impact
• Motor, ESC, or flight-controller replacement and setup
• Wiring harness repairs on power or control buses
• Installation of non-OEM structural or propulsion parts
• Work on parachute recovery, flight-termination, or other safety-critical subsystems
• Any modification that changes mass, CG, EMI characteristics, or control laws beyond the declared configuration

Rule of thumb for Advanced candidates: if a mistake could cause loss of control, flyaway, fire, or invalidation of a safety assurance declaration, treat it as critical—document it, use qualified people, and verify independently.

Two-person perform / verify practice

Best practice for critical tasks (and a strong professional standard for complex elementary work) is two-person discipline:

1. Performer executes the task step-by-step against the manual or work card.
2. Verifier independently checks the critical steps, correct parts, torque, connector seating, software version, and functional test results.
3. Both identities, date/time, task description, and result are logged.
4. A functional check flight or ground test (as appropriate) confirms the system before operational use.

This is not bureaucracy for its own sake. Single-person “I fixed it last night” errors are a leading cause of post-maintenance incidents in all aviation, including drones. On the exam, prefer answers that emphasize documentation + independent verification for critical work over “the pilot’s memory is enough.”

Pre-flight inspection discipline

Every flight needs a disciplined pre-flight inspection, not a casual glance. Build a repeatable flow:

1. Documents — registration, pilot certificate, manuals access, authorizations, declaration status for the intended privilege.
2. Airframe — props, arms, landing gear, fasteners, cracks, delamination, foreign object debris.
3. Power — battery health, temperature, charge state, connector condition, swollen packs grounded.
4. Avionics / link — GNSS/compass status, control-link quality, GCS battery, failsafe settings match the site plan.
5. Payload — secure mounting, lens covers removed, power/data cables strain-relieved, mass/CG still within limits.
6. Safety systems — RTH altitude/home point, geofence if used, flight termination / parachute status if installed, lighting for the operation.
7. Environment — weather minima, icing risk, wind vs performance, site hazards.

If any required item fails, the aircraft is unserviceable for that flight. Do not “test it in the air.”

Technical logs and CAR 901.48 records

CAR 901.48 themes address records associated with the RPAS and its operation/maintenance. Professional technical logs typically capture:

• Aircraft identity (model, serial, registration marking as applicable)
• Flight time / cycles where tracked
• Defects found (open vs closed)
• Corrective actions and parts used
• Inspection and maintenance due/accomplished dates
• Firmware and software versions before and after updates
• Who performed and who verified the work
• Grounding and return-to-service statements

Why logs matter on Advanced ops:

• They prove due diligence after an incident or TC/TSB inquiry.
• They prevent the next crew from flying a known defect.
• They support configuration control for declared aircraft (software and hardware must match what was declared).
• They make deferred maintenance visible instead of tribal knowledge.

Exam posture: incomplete or missing records are a compliance and safety failure, not an administrative inconvenience.

Firmware updates as maintenance

Treat firmware and flight-control software updates as maintenance events, not app-store hobbies:

1. Read the manufacturer release notes—some updates change flight behaviour, geofencing, or payload compatibility.
2. Confirm the update is approved for your exact model/hardware revision.
3. Ensure batteries and link power are stable; never interrupt an in-progress critical update.
4. Log the from → to version numbers, date, and person who applied the update.
5. Perform post-update calibration and a controlled functional check before high-risk missions (controlled airspace, near people, over people).
6. If the update fails or behaviour is abnormal, ground the system until recovered per manufacturer procedure.

A declared RPAS flown on unvalidated software may no longer represent the configuration behind the Standard 922 declaration path—pair this section with Section 8.3 on modifications and declarations.

Grounding unserviceable systems

Grounding is a positive safety action:

• Tag or otherwise identify the airframe/control station as unserviceable.
• Open a defect entry in the technical log with symptoms and when discovered.
• Remove the aircraft from the ready-to-fly pool so another pilot does not launch it.
• Clear the defect only after corrective action, verification, and (where required) functional test.
• Never pressure-accept an unserviceable drone because a client is waiting—Advanced privileges include the judgment to say no go.

Common exam traps for Section 8.1

• Flying with a known defect because the pilot is Advanced and “experienced”
• Claiming manuals are optional once you know the aircraft well
• Treating firmware updates as non-maintenance events with no log entry
• Skipping independent verification after critical structural or avionics work
• Confusing registration compliance with serviceability
• Deferring defects indefinitely without assessment or record

Master 901.29 serviceability, manuals followed (901.30–901.31), logs (901.48), elementary vs critical work, and grounding discipline—and maintenance questions become systematic rather than guesswork.