Managing Component Release Certificates (Form 1, FAA 8130)
Component Release Certificates are a fundamental document required to prove the airworthiness of components fitted to aircraft. When an engineer or mechanic prepares to fit a component to an aircraft the first thing he looks for when checking the new part is the Component Release Certificate, be it a Form 1, FAA 8130 or Certificate or Conformity (C of C). Without the approved documentation the item can not be fitted. How do you manage your Component Release Certificates?
When was the last time you looked at your Component Release Certificate handling process and asked yourself the following questions?
- Is it fit for purpose?
- Are there any "holes" in the system that could lead to the loss of a certificate?
- Are you storing multiple physical and electronic copies of the same certificate, and how many copies do your really need?
- How do you validate authenticity?
- What is your retention policy, format and period of retention?
- Are they easily accessible and searchable should you need to refer to them?
- If you are approved to do so, how do you create release certificates?
The above are a few questions that I hope will stimulate some thought around how you handle these important documents both now and in the future.
The majority of organisations are still very much reliant on hard copies of release certificates, and these often travel with the shipped item. Copies are usually made at the goods receipt stage, (when the part is accepted in to the company), but in an Aircraft On Ground situation this can be missed in the urgency to get the part to the aircraft and engineer. As long as the original is retained by the engineer and passed back upon completion of the paperwork covering the component replacement, all is well. But there are many opportunities along the way for this crucial piece of paper to go missing, that could then generate many man-hours of work trying to either locate the certificate, request a copy from the originator, or worst case the need to replace the component again!
This is where the potential for blockchain technology and the use of de-centralised registries has huge potential. The physical release certificate could be replaced by an electronic record held on a secure blockchain, removing any concern over authenticity or loss of a certificate .
Any record associated to that component could then be attached to that blockchain entry. From the initial component release, installation and removal records, non-incident statements through to full overhaul records. A complete back to birth record available at your finger tips. The concept appears very attractive, but the up take so far appears to be relatively slow. Much of the ground work is in place in the form of Spec 2000 Chapter 16 which provides the frame work for how the release certificate data could be formatted and stored electronically as an e-Form. No more poor xerox copies of paper documents to worry about, and trying to work out if that is a zero or the letter "O" in the serial number!
Example Form 1 Component Release Certificate
The regulatory authorities have done a good job of establishing a recognised industry standard for a release certificate (shown above), with an approved "block numbering" system. So that even if the format looks different "Block 8" will always contain the part number of the component. Next step is to create the de-centralised registry (examples: Blockaviation, VeChain) and have everyone use it! Easier said than done, but I think we can all agree that the benefits justify the journey to get there. One of the bumps in the road remains that of eSignature. These certificates, in the same way as maintenance documents require signature by someone with appropriate Approval/Authorisation to do so. This is yet another database/dataset held within the issuing companies quality management system supporting their regulatory approval. eSignature is a topic in itself and one that deserves a blog in it's own right. But in it's simplest terms it must provide a secure link back to the issuing companies approval system. There are many eSignature providers out there, but any release certificate would require what is known as Long Term Validation (LTV) or equivalent. As an LTV is normally embedded within a PDF document, an alternative would need to be established if the release certificate was to remain as a true eForm on the blockchain. I am looking forward to seeing how blockchain technology can support this certification issue and be used to enhance the component release certification process as a whole as I believe it could set the frame work for the wider subject of "Aircraft Records".
As they say "Watch this space"...