Patent Application
20200074410
The present disclosure relates generally to the field of airworthiness certification of aircraft and, more particular, to a distributed public ledger system for maintaining records related to airworthiness certification.
Current commercial aircraft certification is structured to provide regulatory approval of a design (through Type Certification or Amended Type Certification), followed by regulatory approval of a particular aircraft under an approved design (Airworthiness Certification or Production Certification). Modifications of aircraft with an existing Type Certificate require a Supplemental Type Certificate, which is intended to incorporate by reference the existing Type Certificate.
The existing certification process was developed to provide certification of blocks of similar aircraft, as it was impractical at the time the system was developed to provide regulatory approval of the design and production features of individual aircraft. As this approach was developed to address large numbers of aircraft at once, it consequently results in high per-airplane costs whenever changes are made for a small number of aircraft. For example, a design update for an approved aircraft design may be too costly to incorporate if it impacts the Type Certificate for the aircraft and only a small number of units are planned for production. For products with uncertain or infrequent sales, the burden of obtaining a Supplemental Type Certification can mean that design updates are deferred for long periods because the incremental sales block may be insufficient to amortize the costs of re-certification. This delay in making design changes in turn tends to limit frequent design changes to “minor” updates that do not impact the Type Certificate, followed by infrequent “major” updates under an Amended Type Certificate. The existing certification process thus can prevent or delay useful product improvements from being delivered to the market for extended periods, and create unintended regulatory arbitrage opportunities between entities requesting Supplemental and Amended Type Certificates.
The present disclosure provides an airworthiness certification system for certifying the airworthiness of an aircraft. The airworthiness certification system employs a digital public ledger (DPL) that records compliance with all regulatory requirements that must be met to obtain and/or maintain airworthiness certification. When a user verifies compliance with a regulatory requirement, the user generates a digital compliance record containing certification data proving compliance with the regulatory requirement and a digital signature of the user. The user records the digital compliance record in a digital public ledger by generating a new transaction block in the DPL containing the digital compliance record and cryptographically linking the transaction block with a previous transaction block in the DPL.
The initial design and validation process for the aircraft builds out the beginning of the DPL for the aircraft by assembling corresponding transaction blocks into a blockchain. As production of the aircraft proceeds, each step in the manufacturing process (e.g., supplier delivery or job completion) creates a similar transaction (or block) in the chain by establishing the result of the process step meets the regulatory requirements. The addition of digital compliance records to the DPL is repeated for each process step for each aircraft produced. The certification basis for the aircraft is established by the complete chain of individual transactions throughout the design, validation, and production processes.
Changes can be made to the aircraft during maintenance, upgrade or modification without impacting the overall certification. Rather, the changes or modifications only need to satisfy the regulatory requirements impacted by the upgrade or modification. Following each upgrade or modification impacting the airworthiness certification, a new digital compliance record is generated and added to the DPL to show compliance with the regulatory requirements impacted by the upgrade or modification in the same manner as described above. The DPL accumulates blocks for each upgrade or modification on each aircraft until the aircraft is removed from service.
The airworthiness certification process as described above does not rely on distinctions between Type, Supplemental, Amended or Production Certificates and eliminates the unintended regulatory arbitrage opportunities among these certification methods. Instead, the airworthiness certification process relies on the public ledger transactions to individually and comprehensively establish the airworthiness of the aircraft. For the same reason, this process enables greater incremental change to aircraft in production or service, since the scope of the airworthiness certification impact is limited only to the elements of change.
The features, functions and advantages that have been discussed can be achieved independently in various aspects or can be combined in yet other aspects further details of which can be seen with reference to the following description and the drawings.
Having thus described variations of the disclosure in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
The embodiments described herein recognize and take into account that previous solutions for certifying aircraft focused on certifying blocks of aircraft of a common group. For example, a Type Certificate signifies the airworthiness of a particular category of aircraft and confirms that the aircraft is manufactured to an approved design, and that the design complies with airworthiness requirements. The embodiments described herein recognize and take into account that the previous solutions result in greater than desired costs for implementing changes in a small subset of aircraft. The solutions also enable production of parts for aircraft to be more closely tracked, making it more difficult to put unapproved aircraft parts into the supply stream used by aircraft manufacturers.
The solutions described herein for recording compliance with regulatory requirements for air worthiness certification do not rely on distinctions between Type, Supplemental, Amended or Production Certificates and eliminates the unintended regulatory arbitrage opportunities among these certification methods. A technical effect of the solutions described herein include reduced cost and complexity of certification of aircraft. The solutions enable changes or modifications to be made to a small number of aircraft without incurring high costs for airworthiness certification. The reduced regulatory burden in turn enables greater incremental change to aircraft in production or service, since the scope of the airworthiness certification impact is limited only to the regulatory requirements affected by the change.
Referring now to the drawings in which similar reference numbers are used throughout the Figures to indicate similar elements,
Each of the network nodes 25 in the DPL network 20 comprises a computing device capable of communicating with the other network nodes 25 in the DPL network 20, referred to herein as peer nodes. Each network node 25 in the DPL network 20 stores a copy of the DPL 10. Records are added to the DPL 10 by consensus of the network nodes 25
Network nodes 25A-25F, shown as attached to the DPL network 20, are associated with respective users of the DPL network 20. Typical users of the airworthiness certification system 100 comprise aircraft manufacturers, aircraft owners, maintenance and service organizations, parts suppliers, regulatory agencies such as the Federal Aviation Administration (FAA), investigative agencies such as the National Transportation safety Board (NTSB), members of the public, and the like. Each of the network nodes 25A-25F includes an Air Worthiness Certification (AWC) application for submitting certification records to the DPL network 20 for recordation in the DPL 10. One of the network nodes 25 can also function as an administrator of the DPL network 10. For example, network node 25D under the control of the FAA can be configured to function as an administrator of the DPL network 10. The administrator is responsible for user management, authentication, and authorization of other users of the DPL network 20. The administrator (e.g. network node 25D) stores user information needed for the operation of the air worthiness certification system 100. User information can include information such as user identification, user passwords, user addresses, user permissions and privileges, and pubic keys of the users. Users of the airworthiness certification system 100 can be required to register with the administrator and different users can have different permission levels. For example, an aircraft manufacturer can have permission to write to and read from the DPL 10, but members of the public can have permission only to read the DPL 10. As another example, some users (e.g., manufacturers) can be given permission to create a new DPL 10 for a particular aircraft or group of aircrafts. For example, a user may start a new DPL 10 for each aircraft produced. The administrator handles registration of users and assignment of permissions to the users, and communicates with other network nodes 25 to provide relevant user information (e.g., user identification, permissions, public keys, etc.)
The airworthiness certification system 100 can be used to implement a new process for airworthiness certification that obviates the need for the current Type Certificate/Production Certificate model. Before further describing the details of the airworthiness certification system 100, a brief example is given here to provide context for understanding the disclosure. Assume that an aircraft manufacturer desires to certify the airworthiness of a new aircraft. In this example, it is assumed that the aircraft to be certified is the first of its kind and that a DPL 10 has been created for the aircraft. The Applicant (e.g., the manufacturer) defines the Methods of Compliance used to satisfy regulatory requirements consistent with current practice. The complete set of the Methods of Compliance establish the standards for approving the airworthiness of the aircraft. Following each instance of a regulatory requirement being satisfied (e.g., an approved engineering analysis, completed validation test, etc.), the Applicant generates a transaction record, referred to herein as a digital compliance record, to be included in a DPL 10 for the aircraft. In one example, each digital compliance record contains the regulatory requirement, the compliance data satisfying the regulatory requirement, a digital timestamp, and a signature of the party asserting the compliance. The Applicant submits the digital compliance record to the DPL subsystem 30 for recordation in the DPL 10. After the digital compliance record is validated (e.g., by consensus of the network nodes 25 in the DPL network 20), the digital compliance record (represented by a new transaction block in a blockchain) is added to the DPL 10. The new transaction block includes an encryption key (or hash) linking the new transaction block to other transaction blocks in the aircraft's chain verification to form a blockchain.
The initial design and validation process for the aircraft builds out the beginning of the DPL 10 for the aircraft by assembling the transaction blocks described above into a blockchain. As production of the aircraft proceeds, each step in the manufacturing process (e.g., supplier delivery or job completion) creates a similar transaction block in the blockchain by establishing the result of the process step meets the standards established by the declared Methods of Compliance. The addition of digital compliance records to the DPL 10 is repeated for each process step for each aircraft produced. The certification basis for the aircraft is established by the complete chain of individual transactions throughout the design, validation, and production processes. When all of the regulatory requirements are satisfied, the aircraft is deemed airworthy. In this way, the certification basis is a chain of individual transactions (blocks), rather than an aggregated collection of events.
Changes can be made to the aircraft during maintenance, upgrade or modification without impacting the overall certification. Rather, the changes or modifications only need to satisfy the regulatory requirements impacted by the upgrade or modification. Following each upgrade or modification impacting the airworthiness certification, a new digital compliance record is generated and added to the DPL 10 to show compliance with the regulatory requirements impacted by the upgrade or modification in the same manner as described above. The DPL 10 accumulates transaction blocks for each upgrade or modification on each aircraft until the aircraft is removed from service.
The airworthiness certification process as described above does not rely on distinctions between Type, Supplemental, Amended or Production Certificates and eliminates the unintended regulatory arbitrage opportunities among these certification methods. Instead, this airworthiness certification process relies on the public ledger transactions to individually and comprehensively establish the airworthiness of the aircraft. For the same reason, this process enables greater incremental change to aircraft in production or service, since the scope of the airworthiness certification impact is limited only to the elements of change.
The airworthiness certification process also enables closer tracking of the supply of aircraft parts. Using the solutions described herein, each parts supplier can be required to certify every unit produced and each unit produced can be individually tracked. Thus, it will be more difficult for unapproved parts to enter into the supply chain. The part can be certified when the part is initially produced and each transfer of the part can be recorded in a DPL 10. The certification of the part can then be included in the overall airworthiness certification record.
The message digest 125 and digital timestamp 115 comprise two elements of the digital compliance record 150. Including the message digest 125 in the digital compliance record 150 rather than a plaintext record enables the user to prove an assertion of compliance without disclosing to the public the underlying data proving the claim. In the event that the assertion of compliance is challenged by a third party, the user can produce the original certification data 110 and the digital timestamp 110 used to generate the message digest 125. The third party can verify the assertion of compliance by generating a hash using the original certification data 110 and the digital timestamp 115 as input, and comparing the generated hash to the message digest 125. If the generated hash matches the message digest 125, the digital compliance record 150 is authenticated as the basis for the assertion of compliance.
The message digest 125 along with a private key 130 of the user is input to a signature function 135. The private key 130 is part of a key pair including the private key 130 and a corresponding public key (not shown). The signature function 135 encrypts the message digest 125 with the private key 130 of the user to generate a cryptographic signature 140 on the message digest 125. The cryptographic signature 140 is included in the digital compliance record 150 to prove the identity of the user asserting compliance, i.e., the user that submits the digital compliance record 150 to the DPL 10. To prove the identity of the user asserting compliance, the public key of the user can be used to decrypt the cryptographic signature 140 to obtain the decrypted signature. The decrypted signature can then be compared to the actual message digest 125 contained in the digital compliance record 150 and, if they are a match, the identity of the user is proven. Exemplary signing algorithms suitable for use in the present disclosure include the Digital Signature Algorithm (DSA) and the Elliptic Curve DSA (ECDSA).
The digital compliance record 150 in this example comprises the message digest 125, digital timestamp 115 and cryptographic signature 140 of the user. The message digest 125 is used to authenticate the certification data 110 that proves compliance with a regulatory requirement. The digital timestamp 115 proves existence of the data as of the date of the digital timestamp 115. The cryptographic signature 140 proves the identity of the user asserting the compliance. This record is then submitted by the user to the DPL network 20 for recordation in the DPL 10 for the aircraft. Other information can be included in the digital compliance record 150, or provided to the DPL 10 along with the digital compliance record 150. For example, an identifer that uniquely identifies a DPL 10 to which the digital compliance record 150 is being added can be included in or provided along with the digital compliance record 150. The identifer can be associated with a single aircraft, a group of aircraft, an aircraft part, or a group of aircraft parts.
The process 300 is typically performed by a network node 25 in the DPL network 20 under the control of an authorized user such as an aircraft manufacturer, aircraft owner, or service and maintenance organization. It is assumed that the DPL 10 is a permissioned public ledger, that the user is registered with the administrator, and that the user has been granted permission to add records to the DPL 10 for the aircraft. The network node 25 obtains certification data 110 indicating compliance with a regulatory requirement for airworthiness certificate. The certification data 110 can include, for example, the regulatory requirement, the Method of Compliance associated with the regulatory requirement, and compliance data satisfying the Method of Compliance for the regulatory requirement. Other information can also be included in the certification data 110. The certification data 110 and a nonce 105 are input to a one-way hash function 120 to generate a message digest 125. The nonce 105 can be obtained from a random number generator. As one example, the one-way hash function 120 could comprise an implementation of the SHA-256 algorithm. The output of the one-way hash function 120 comprises a message digest 125. The message digest 125 and nonce 105 comprise two elements of the digital compliance record 150.
The message digest 125 along with a private key 130 of the user is input to a signature function 135. The private key 130 is part of a key pair including the private key 130 and a corresponding public key (not shown). The signature function 135 encrypts the message digest 125 with the private key 130 of the user to generate a cryptographic signature 140 on the message digest 125. The cryptographic signature 140 is included in the digital compliance record 150 to prove the identity of the user asserting compliance, i.e., the user that submits the digital compliance record 150 to the DPL 10. To prove the identity of the user asserting compliance, the public key of the user can be used to decrypt the cryptographic signature 140 to obtain the decrypted signature. The decrypted signature can then be compared to the actual message digest 125 contained in the digital compliance record 150 and, if they are a match, the identity of the user is proven. Exemplary signing algorithms suitable for use in the present disclosure include the Digital Signature Algorithm (DSA) and the elliptic curve DSA (ECDSA).
The digital compliance record 150 in this example comprises the message digest 125, nonce 105, and cryptographic signature 140 of the user. The message digest 125 and nonce 105 are used to authenticate the certification data 110 that proves compliance with a regulatory requirement. The cryptographic signature 140 proves the identity of the user asserting the compliance. This record is then submitted by the user to the DPL network 20 for recordation in the DPL 10 for the aircraft.
As noted in the discussion of
Validation of the digital compliance record 150 could rely on other information in the digital compliance record 150. In the examples illustrated by
The first network node 25 in the airworthiness certification system 100 associated with the user obtains, from the user, the certification data 110 indicating compliance with a regulatory requirement for airworthiness certification (block 440). The certification data 110 can be received by one of the first network node 25 from another computing device under the control of the user, or via direct user input, or some combination thereof. After obtaining the certification data 110, the first network node 25 generates a message digest 125 from the certification data 110 and a digital timestamp 115 as shown in
The method 500 begins when a first network node 25 in the airworthiness certification system 100 associated with a user obtains certification data 110 indicating compliance with a regulatory requirement for airworthiness certification (block 510). The certification data 110 can comprise the regulatory requirement, a Method of Compliance for satisfying the regulatory requirement, and compliance data satisfying the Method of Compliance. The compliance data can comprise, for example engineering analysis, test data, or similar information. Other information relevant to the compliance can also be included in the certification data 110. As one example, the certification data may include an explicit indication that the compliance data satisfies the Method of Compliance for the regulatory requirement. The certification data 110 can be received by the network node 25 from another computing device, or via user input, or some combination thereof.
After obtaining the certification data, the first network node 25 generates a digital compliance record 150 including the certification data 110 and the cryptographic signature 140 of the entity certifying compliance (block 520). The first network node 25 can be configured to generate the digital compliance record 150 according to one of the processes 200, 300 shown in
The second network nodes 25 in the DPL network 20 record the digital compliance record 150 generated by the first network node 25 in a DPL 10 containing the complete compliance history for the aircraft (block 530). The second network nodes 25 can comprise a superset that includes the first network node 25. Recording the digital compliance record in the DPL 10 comprises generating a new transaction block 12 including the digital compliance record 150 (block 540). The new transaction block 12 is then cryptographically linked to a previous transaction block 12 in the DPL 10 (block 550). In some variations, cryptographically linking the new transaction block 12 with a previous transaction block 12 comprises generating a hash using the previous transaction block 12 and the new digital compliance record 150. In other variations, cryptographically linking the new transaction block 12 with a previous transaction block 12 in the DPL 10 comprises generating a hash using the previous transaction block 12, the digital compliance record 150, and a digital timestamp 170.
Responsive to the receipt of the digital compliance record 150, the second network nodes 25 in the DPL network 20 record the digital compliance record 150 generated by the network node 25 in a DPL 10 containing the complete compliance history for the aircraft (block 620). Recording the digital compliance record in the DPL 10 comprises generating a new transaction block 12 including the digital compliance record 150 (block 630). The new transaction block 12 is then cryptographically linked to a previous transaction block 12 in the DPL 10 (block 640). In some variations, cryptographically linking the new transaction block 12 with a previous transaction block 12 comprises generating a hash using the previous transaction block 12 and the new digital compliance record 150. In other variations, cryptographically linking the new transaction block 12 with a previous transaction block 12 in the DPL 10 comprises generating a hash using the previous transaction block 12, the digital compliance record 150, and a digital timestamp 170.
The processing circuit 720 controls the operation of the computing device 700. The processing circuit 720 executes an AWC application 740 that implements the methods herein described. The processing circuit 720 may comprise one or more microprocessors, hardware circuits, firmware, or a combination thereof.
Memory 730 comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuit 720 for operation. Memory 730 may comprise any tangible, non-transitory computer readable storage medium for storing data including electronic, magnetic, optical, electromagnetic or semiconductor data storage. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a read only memory (ROM), erasable programmable ROM (EPROM) or flash memory. Temporary data generated during operation may be stored in a volatile memory, such as a random access memory (RAM).
Memory 730 stores the AWC application 740 that configures the computing device 700 to perform the AWC functionality as described herein. The AWC application 740 comprises executable program instructions that, when executed by the processing circuit 720 in the computing device 700, causes the computing device 700 to implement the methods herein described. In some variations, the AWC application 740 for configuring the processing circuit 720 as herein described may be stored in a removable memory, such as a portable compact disc, portable video digital disc, or other removable media. The AWC application 740 may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.
The airworthiness certification system 100 as described above does not rely on distinctions between Type, Supplemental, Amended or Production Certificates and eliminates the unintended regulatory arbitrage opportunities among these certification methods. Instead, the airworthiness certification system 100 relies on the public ledger transactions to individually and comprehensively establish the airworthiness of the aircraft. For the same reason, this process enables greater incremental change to aircraft in production or service, since the scope of the Airworthiness Certification impact is limited only to the elements of change.
The present invention can, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
