System and method for updating software and public keys in an aircraft system
Patent Information
- Application Number
- CN202610538622.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-04-23
- Filing Date
- 2026-04-22
- Publication Date
- 2026-10-23
Smart Images

Figure CN122969788A_ABST
Abstract
Description
Technical Field
[0001] These teachings broadly relate to aircraft systems, and more specifically, to systems and methods for updating software within aircraft systems. Background Technology
[0002] Modern aircraft may include one or more systems controlled by a computing system. For example, an electronic engine controller can be used to control one or more engines of the aircraft to provide propulsion. Software installed on the computing system can be used to control various operations and functions of one or more engines or other systems on the aircraft. In some approaches, the software installed on the computing system may need to be updated, reconfigured, or reloaded, which may increase the likelihood of software configuration management and operator guidance issues. Therefore, systems and methods for updating software on the computing system may be desirable. Attached Figure Description
[0003] The systems and methods for updating software in aircraft systems, as described in the following detailed description, particularly when studied in conjunction with the accompanying drawings, at least partially meet various needs. A complete and feasible disclosure of all aspects of this specification, including its best mode, is set forth in the description with reference to the accompanying drawings for those skilled in the art, wherein:
[0004] Figure 1 These are schematic diagrams of engines based on various embodiments of these teachings;
[0005] Figure 2 This is a block diagram of a data loader and engine based on various embodiments of these teachings;
[0006] Figure 3 This is a block diagram of a system for updating a public key, based on various embodiments of these teachings;
[0007] Figure 4 This is a flowchart of a process for updating a public key based on various embodiments of these teachings;
[0008] Figure 5 This is a flowchart of a process for updating a public key in a computing system, based on various embodiments of these teachings;
[0009] Figure 6 It is a block diagram of a process for authenticating and updating public keys in a computing system, based on various embodiments of these teachings; and
[0010] Figure 7 This is a block diagram of a computing system based on various embodiments of these teachings.
[0011] The elements in the accompanying drawings are shown for simplicity and clarity and are not necessarily drawn to scale. For example, the size and / or relative positioning of some elements in the drawings may be exaggerated relative to other elements to aid in understanding the various embodiments of this teaching. Furthermore, common but well-understood elements that are useful or necessary in commercially viable embodiments are generally not depicted to facilitate less obstructed observation of these different embodiments of this teaching. Certain actions and / or steps may be described or depicted in a particular sequence of occurrence, but those skilled in the art will understand that such specificity regarding the sequence is not actually necessary. Detailed Implementation
[0012] The systems and methods described herein for updating software and public keys in aircraft systems provide methods for authenticating and updating public keys in computing systems on aircraft. In these aspects, and as described herein, the computing system on the aircraft may have a loadable portion including a public key loaded via a data loader.
[0013] In some embodiments, the aircraft includes one or more engines, which may include one or more computing systems and / or communicate with one or more computing systems. In some embodiments, the computing system is an electronic engine controller. Various operations and functions of the aircraft may be controlled by field-loadable software (referred to herein as a loadable portion) installed in one or more computing systems. For example, the loadable portion may be installed in the electronic engine controller to control various operations and functions of the engine. In some forms, the loadable portion may be considered part of the engine construction.
[0014] In some embodiments, it may be necessary to reinstall the loadable portion, or new loadable portions may need to be installed at various points during aircraft operation. The computing system may authenticate the loadable portion before storing it in the computing system. For example, to authenticate the loadable portion during a reprogramming operation, the computing system uses the public key associated with the loadable portion to decrypt the hash value of the loadable portion, which has been encrypted by a secret private key. The computing system calculates the hash value of the loadable portion and compares the decrypted hash value with the calculated hash value. If the hash values match, the loadable portion is considered reliable. However, the public and private key pairs may need to be updated over time due to key expiration or because the private key is no longer kept secret.
[0015] In traditional methods, to update a public key in a computing system, the new public key must be signed with the private key from an existing public-private key pair. After the new public key is stored in the computing system, the same loaded image of the public key cannot be reloaded because authentication will fail. Therefore, to update the public key, it may be necessary to release two loadable parts: a loadable part signed with the previous public-private key pair (loaded only once), and a loadable part signed with the new public-private key pair (loaded at any time after the first load). In this approach, since the loadable software parts can only be loaded once, special loading instructions can be used. However, these instructions can lead to configuration management problems and a significant amount of operator work due to the precise order of steps listed in the instructions and the specific order in which the loadable parts are loaded, increasing the likelihood of operator confusion. Therefore, the systems and methods for updating public keys as described herein allow updating the public key in the computing system simultaneously using a single loadable part that will be successfully loaded on the first and subsequent requests. In some embodiments, when the loadable part signed with the new public key differs from the public key already programmed into the computing system, the computing system will authenticate the loading public key.
[0016] Unless otherwise specified herein, the terms and expressions used herein have the ordinary technical meanings that those skilled in the art would assign to them. Unless otherwise specifically indicated, the word "or" as used herein should be interpreted as having a disjunctive structure rather than a conjunctive structure. Unless otherwise stated herein, the terms "connection," "fixed," "attached," etc., refer both to direct connection, fixation, or attachment, and to indirect connection, fixation, or attachment via one or more intermediate components or features.
[0017] Unless the context clearly indicates otherwise, the singular forms “a,” “a,” and “the” include plural references.
[0018] As used herein, "loadable portion" refers to any software or data that can be loaded onto an aircraft without removing the aircraft's hardware. Generally, it is conceivable that a loadable portion can be loaded in-situ onto a computing system to update or modify the system's functionality, configuration, or operation. In some embodiments, a loadable portion may include engine control software.
[0019] As used herein throughout the specification and claims, approximate language is applied to modify any quantitative expression that may allow for variation without altering its underlying function. Therefore, values modified by terms such as “about,” “approximate,” and “substantially” are not limited to specified exact values. In at least some cases, approximate language may correspond to the precision of the instrument used to measure the value, or the precision of the method or machine used to construct or manufacture the component and / or system. For example, approximate language may refer to a margin of 10%.
[0020] The foregoing and other benefits may become clearer after a thorough review and study of the following detailed description.
[0021] Now for reference Figure 1 A schematic cross-sectional view of a gas turbine engine 10 according to an exemplary embodiment of the present disclosure is provided. More specifically, for Figure 1 In one embodiment, the gas turbine engine is a high-bypass turbofan jet engine 10, referred to herein as "turbofan engine 10". Figure 1 As shown, the turbofan engine 10 defines an axial direction A (extending parallel to the longitudinal centerline 12 provided for reference) and a radial direction R. The turbofan engine 10 also defines a circumferential direction C extending circumferentially about the axial direction A (see...). Figure 3 Typically, the turbofan 10 includes a fan section 14 and a turbine 16 disposed downstream of the fan section 14.
[0022] The depicted exemplary turbine 16 is generally enclosed within a substantially tubular housing 18, which defines an annular inlet 20 and an annular outlet 21. The housing 18 surrounds, in a series flow relationship: a compressor section comprising a supercharger or low-pressure (LP) compressor 22 and a high-pressure (HP) compressor 24; a combustion section 26; a turbine section comprising a high-pressure (HP) turbine 28 and a low-pressure (LP) turbine 30; and an exhaust nozzle section 32. A high-pressure (HP) shaft or spool 34 drives the HP turbine 28 to the HP compressor 24. A low-pressure (LP) shaft or spool 36 drives the LP turbine 30 to the LP compressor 22. The compressor section, combustion section 26, turbine section, and nozzle section 32 together define a core airflow path 37 through which air flows.
[0023] In the depicted embodiment, fan section 14 includes a fixed-pitch fan 38 having a plurality of fan blades 40. Each fan blade 40 is attached to a disk 42, wherein the fan blades 40 and disk 42 together can be rotated about a longitudinal axis 12 via an LP shaft 36. In the depicted embodiment, the turbofan engine 10 is a direct-drive turbofan engine, such that the LP shaft 36 directly drives the fan 38 of fan section 14 without using a reduction gearbox. However, in other exemplary embodiments of this disclosure, the fan 38 may alternatively be a variable-pitch fan, and the turbofan engine 10 may include a reduction gearbox, in which case the LP shaft 36 may drive the fan 38 of fan section 14 across the gearbox.
[0024] Still referencing Figure 1In an exemplary embodiment, the disk 42 is covered by a rotatable front hub 48, which is aerodynamically shaped to facilitate airflow through a plurality of fan blades 40. Additionally, the exemplary turbofan engine 10 includes an annular nacelle assembly 50 circumferentially surrounding at least a portion of the fan 38 and / or turbine 16. In the depicted embodiment, the nacelle assembly 50 is supported relative to the turbine 16 by a plurality of circumferentially spaced outlet guide vanes 52. Furthermore, a downstream section 54 of the nacelle assembly 50 extends over the outer portion of the housing 18 to define a bypass airflow passage 56 therebetween. The ratio between a first portion of air passing through the bypass airflow passage 56 and a second portion of air passing through the inlet 20 of the turbine 16 and through the core airflow path 37 is generally referred to as the bypass ratio.
[0025] Still referencing Figure 1 The turbofan engine 10 also includes a controller 58 for controlling the operation of the turbofan engine 10. More specifically, the controller 58 can control one or more operations of the turbofan engine 10 and record operating and performance data of the turbofan engine 10. The controller 58 can be a single controller, or in some embodiments, it can be multiple controllers. In some embodiments, the controller 58 is an electronic engine controller (EEC). In some embodiments, the controller 58 can operate as a full authority digital engine control (FADEC) system.
[0026] The controller 58 is communicatively connected to various components of the turbofan engine 10 (e.g., via one or more suitable wireless or wired communication links). It is generally conceivable that the controller 58 may be communicatively connected to any suitable component of the turbofan engine 10, to other computing systems or components of the aircraft to which the turbofan engine 10 is connected, and / or to other remote computing systems or components outside the aircraft (e.g., ground systems, maintenance systems).
[0027] However, it should be understood that Figure 1 The exemplary turbofan engine 10 depicted herein is merely an example, and in other exemplary embodiments, aspects of this disclosure may be additionally or alternatively applied to any other suitable gas turbine engine. For example, in other exemplary embodiments, turbofan engine 10 may alternatively be any other suitable aviation gas turbine engine, such as a turbojet engine, turboshaft engine, turboprop engine, etc. Additionally, in other exemplary embodiments, exemplary turbofan engine 10 may include or be operatively connected to any other suitable accessory system. Additionally or alternatively, exemplary turbofan engine 10 may not include or may be operatively connected to one or more of the accessory systems discussed above.
[0028] Figure 2 A block diagram of an exemplary system 200 according to various embodiments is shown. System 200 includes an engine 202 and a data loader 208. The engine 202 may be... Figure 1 Engine 10. Engine 202 may include one or more computing devices 204 and / or communicate with one or more computing devices 204. In some embodiments, computing device 204 may be an electronic engine controller. Computing device 204 communicates with data loader 208 via network 214 (e.g., transmit, receive, send, push, etc.). More specifically, data loader 208 is communicatively coupled to computing device 204 to partially send software files, such as field-loadable software, referred to herein as a loadable portion, to computing device 204. Computing device 204 authenticates the loadable portion and, in some cases, stores the loadable portion, as follows: Figure 3-6 As described in [the text].
[0029] Computing device 204, or more specifically, an electric motor controller, may include one or more processors and one or more memory devices. Computing device 204 may include an interface module 206, for example, for communicating with data loader 208 (e.g., transmitting, receiving, sending, etc.). The one or more processors may include a microcontroller, microprocessor, central processing unit core, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), etc. The one or more memory devices may include a machine-readable medium that may be non-transitory and may also include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk drive, etc. The one or more processors may execute instructions (i.e., programming or software code) stored on the one or more memory devices to perform operations, such as any operation or function that computing device 204 is configured to perform. In some embodiments, regarding Figure 3-6 The described functionality may be included in instructions stored on one or more memory devices.
[0030] Network 214 can essentially be any associated wired and / or wireless computer and / or communication network (one or more local area networks (LANs), one or more wireless wide area networks (WANs), one or more other wireless networks (e.g., cellular, Wi-Fi, Bluetooth, LoRa, LoRa-WAN, etc.), other such networks, or combinations of two or more of such networks). Although computing device 204 is shown, in some forms, the functionality of computing device 204 can be implemented on one or more computing systems communicating on network 214.
[0031] Data loader 208 can be any type of electronic communication device. For example, data loader 208 may include a computer, a laptop computer, or any other suitable device capable of loading software onto an electronic device. Data loader 208 may include interface 210 for receiving user input 212 and communicating with computing device 204 (e.g., sending and receiving data). User input 212 may include commands, software files, configuration settings, and various other types of data. In some embodiments, data loader 208 may transmit a loadable portion to computing device 204 in response to receiving user input 212.
[0032] refer to Figure 3 The diagram illustrates a block diagram of an exemplary system 300 for authenticating a loadable portion 304 according to various embodiments. System 300 includes a computing device 302, which includes a key management system 312, a storage device 316, and a data loading function 320 for loading the loadable portion 304.
[0033] The computing device 302 may be, for example, Figure 2 The computing device 204 is located within the aircraft. In some aspects, the computing device 302 may be an electronic engine controller. For example, the electronic engine controller may be operatively coupled to an engine mounted on an aircraft. In response to the computing device 302 accepting a loading request, the computing device 302 can load data from a data loader (such as...) Figure 2 The data loader 208 shown receives a loadable portion 304. The loadable portion 304 includes a new public key 306. In some embodiments, the loadable portion 304 may include the new public key 306 and a new Computer Software Configuration Item (CSCI) file 308.
[0034] Storage device 316 may store one or more loadable software portions 318, as well as a public key 314 (e.g., an installed public key) that has been previously received, authenticated, and loaded into computing device 302. In some embodiments, storage device 316 may additionally store previously installed (e.g., authenticated) Computer Software Configuration Item (CSCI) files.
[0035] The key management system 312 performs an authentication process including a loadable portion 304 of the new public key 306. More specifically, the key management system 312 can access storage device 316 to determine whether to load the new public key 306, in part by comparing the new public key 306 with an installed public key 314 stored in storage device 316. Furthermore, in some embodiments, the key management system 312 can be based on, as referenced... Figure 4-5 The authentication results are described in further detail, with the new public key 306 updating and replacing the installed public key 314.
[0036] Figure 4 and Figure 5 An exemplary scenario is illustrated where a public key in an onboard computing system is authenticated and updated simultaneously using a single field-loadable portion. The public key can be a unique item within the field-loadable portion (such as...). Figure 4 (as shown), or it can be one of several items in the on-site loadable section (such as...) Figure 5 (As shown). As will be understood from the following description, the process according to various embodiments can be implemented by an electronic engine controller operatively and / or communicatively coupled to one or more aircraft engines mounted on and / or in an aircraft to field-load one or more loadable components.
[0037] refer to Figure 4 A flowchart of an exemplary process 400, according to various embodiments, is shown, authenticating and updating a public key in an onboard computing system while using a single field-loadable component. In some embodiments, process 400 is implemented between a data loader 402 and an electronic engine controller 404. The electronic engine controller 404 includes, in part, an installed public key that has been previously received, authenticated, and stored in the electronic engine controller 404.
[0038] Process 400 begins with a load request initiated by data loader 402. At step 406, data loader 402 generates a load request and sends it to the electric motor controller 404. In some embodiments, the load request includes details about the software to be loaded (e.g., updated or installed). In some embodiments, the software includes one or more loadable portions and a new public key associated with one or more loadable portions. For example, one or more loadable portions may be field-loadable software portions. In some embodiments, data loader 402 may generate a load request in response to input received from operator 434. For example, operator 434 may do so by clicking a button, entering a command, or through an interface of data loader 402 (such as...). Figure 2 The interface 210 shown provides options to input information about the loadable portion to be loaded and generates a loading request. In some embodiments, when the state of a loadable portion previously loaded on the electronic engine controller 404 is unknown, the data loader 402 can generate a loading request to initiate the loading process of one or more loadable portions, thereby enabling the engine (such as...) to load the loadable portion. Figure 1 The engine 100 shown is in a conformance state. For example, the loadable portion may include engine control software. Additionally or alternatively, the data loader 402 may generate a load request to update the public key stored in the electronic engine controller 404 because the public key has expired or the private key associated with the public key is no longer secret.
[0039] At step 408, the electronic engine controller 404 determines that the loading request is valid and, in some embodiments, sends a response accepting the loading request to the data loader 402. In some embodiments, the electronic engine controller 404 determines the validity of the loading request based on predefined criteria, such as verifying the format and / or origin of the loading request. If the request is accepted, at step 410, the data loader 402 transmits a loadable portion including a new public key to the electronic engine controller 404. In some embodiments, the data loader 402 transmits a loadable portion including a new public key that has been signed with a private key associated with a previously installed public key stored on the electronic engine controller 404.
[0040] At step 412, the electronic engine controller 404 receives a loadable portion including the new public key from the data loader 402. Next, at step 414, the electronic engine controller 404 checks whether the new public key is equal to the installed public key. More specifically, the electronic engine controller 404 compares the new public key with the installed public key to determine if the new public key matches the installed public key. Any suitable comparison method (e.g., byte-by-byte comparison, hash value comparison, key attribute comparison, fingerprint comparison, etc.) can be used to compare the new public key and the installed public key. If the new public key is determined to be equal to the installed public key (416), the electronic engine controller 404 proceeds to step 430 as described below. For example, when the new public key is determined to be equal to the installed public key (416), the authentication check is bypassed or skipped, and the installed public key is maintained. Alternatively, if the new public key is determined not to be equal to the installed public key (418), the electronic engine controller 404 proceeds to step 420. In this way, when the public key differs from the installed public key already stored (e.g., programmed) in the electronic engine controller 404, the electronic engine controller 404 only attempts to authenticate with the new public key in the loadable section. In other words, when the electronic engine controller 404 already has a loadable section installed, the same loadable section will not be reloaded onto the electronic engine controller 404 to prevent engine configuration problems and reduce operational confusion, because two identical loadable sections will not be installed on the electronic engine controller 404.
[0041] In some embodiments, before checking whether the new public key is equal to the installed public key at step 414, the electronic engine controller 404 checks whether the new public key is one of the items to be installed (e.g., such as...). Figure 5(As shown in step 514). The electronic engine controller 404 determines whether the new public key is one of the items to be loaded onto the electronic engine controller 404 based on the load request and / or loadable portion received from the data loader. If the new public key is not one of the items to be loaded, the electronic engine controller 404 skips step 414 and proceeds to step 430 as described below. Alternatively, if the new public key is one of the items to be loaded, the electronic engine controller 404 proceeds to step 414 as described above.
[0042] At step 420, the electronic engine controller 404 performs an authentication check on the new public key. Any suitable authentication process can be used. For example, the electronic engine controller 404 can verify one or more signatures. When one or more signatures are verified, the new public key is authenticated. If the new public key fails the authentication check, the electronic engine controller 404 proceeds to step 426 as described below. Alternatively, if the new public key passes the authentication check, the electronic engine controller 404 proceeds to step 428 as described below.
[0043] At step 426, the electronic engine controller 404 rejects the loading request in response to the new public key failing the authentication check (424). The electronic engine controller 404 sends a reply indicating the loading result to the data loader 402. More specifically, the electronic engine controller 404 transmits information indicating loading failure to the data loader 402.
[0044] At step 428, in response to the new public key passing the authentication check (422) at step 420, the new public key is stored as the installed public key.
[0045] At step 430, the electronic engine controller 404 executes a loading request in response to the new public key being stored as the installed public key (as described in step 428). Alternatively, the electronic engine controller 404 executes a loading request in response to the new public key being equal to the installed public key (as described in step 414). The electronic engine controller 404 sends a reply indicating the loading result to the data loader 402. More specifically, the electronic engine controller 404 transmits information indicating successful loading to the data loader 402.
[0046] In some embodiments, at step 432, the loading result is displayed on the interface of the data loader 402 for operator 434 to view. The loading result may include a response indicating successful or failed loading as described above. In one example, since the new public key has been previously installed, the loading result displayed on the data loader 402 may notify operator 434 that the loading was successful. In another example, since the new public key has been authenticated and subsequently stored in the electronic engine controller 404, the loading result displayed on the data loader 402 may notify operator 434 that the loading was successful. In yet another example, since the new public key has not been authenticated, the loading request displayed on the data loader 402 may notify operator 434 that the requested loading failed.
[0047] refer to Figure 5 A flowchart of an exemplary process 500, according to various embodiments, is shown, authenticating and updating a public key in an onboard computing system while using a single field-loadable component. In some embodiments, process 500 is implemented between a data loader 502 and an electronic engine controller 504. The electronic engine controller 504 partially includes an installed public key and one or more installed CSCI files. In other words, the installed public key and the installed CSCI files have previously been received, authenticated, and stored in the electronic engine controller 504.
[0048] Process 500 begins with a load request initiated by data loader 502. At step 506, data loader 502 generates a load request and sends it to the electric motor controller 504. The load request includes detailed information about the software to be loaded (e.g., updated or installed). In some embodiments, the software includes one or more loadable portions, a public key associated with one or more loadable portions, and one or more CSCI files. For example, one or more loadable portions may be field-loadable software portions. In some embodiments, data loader 502 may generate a load request in response to input received from operator 546. For example, operator 546 may do so by clicking a button, entering a command, or through an interface of data loader 502 (such as...). Figure 2 The interface 210 shown provides options to input information about the loadable portion to be loaded and generates a load request. In some embodiments, when the state of a loadable portion previously loaded on the electronic engine controller 504 is unknown, a load request can be generated to load one or more loadable portions, thereby enabling the engine (such as...) Figure 1 The engine 100 shown is in a compliant state. The loadable portion may include engine control software. Additionally or alternatively, a load request may be generated to update the public key stored in the electronic engine controller 504 because the public key has expired or the private key associated with the public key is no longer secret.
[0049] At step 508, the electronic engine controller 504 determines that the loading request is valid and, in some embodiments, sends a response accepting the loading request to the data loader 502. If the request is accepted, at step 510, the data loader 502 transmits a loadable portion including a new public key to the electronic engine controller 504. The new public key has been signed with a private key associated with a previously installed public key stored on the electronic engine controller 504. In some embodiments, the data loader 502 transmits a loadable portion of one or more new CSCI files including the new public key and a private key signed with an installed public key (e.g., the new public key transmitted by the data loader 502, or a previously installed public key).
[0050] At step 512, the electronic engine controller 504 receives a loadable portion including the new public key from the data loader 502. Alternatively or additionally, the electronic engine controller 504 may receive one or more CSCI files. Next, at step 514, the electronic engine controller 504 checks whether the new public key is one of the items to be installed. The electronic engine controller 504 determines whether the new public key is one of the items to be installed based on information received, for example, during the load request at step 508. If the public key is determined to be one of the items to be loaded (516), the electronic engine controller 504 proceeds to step 520. Alternatively, if the public key is determined not to be one of the items to be loaded (518), the electronic engine controller 504 proceeds to step 534 as described below.
[0051] At step 520, the electronic engine controller 504 checks whether the new public key is equal to the installed public key. More specifically, the electronic engine controller 504 compares the new public key with the installed public key to determine whether the new public key matches the installed public key. Any suitable comparison method (e.g., byte-by-byte comparison, hash value comparison, key attribute comparison, fingerprint comparison, etc.) can be used to compare the new public key and the installed public key. If the new public key is determined to be equal to the installed public key (524), the electronic engine controller 504 proceeds to step 534 as described below. For example, when the new public key is determined to be equal to the installed public key (524), the authentication check is bypassed or skipped, and the installed public key is maintained. Alternatively, if the new public key is determined not to be equal to the installed public key (522), the electronic engine controller 504 proceeds to step 526.
[0052] At step 526, the electronic engine controller 504 performs an authentication check on the new public key. Any suitable authentication process can be used. For example, the electronic engine controller 504 can verify one or more signatures. When one or more signatures are verified, the new public key is authenticated. If the new public key fails the authentication check (530), the electronic engine controller 504 proceeds to step 542 as described below. Alternatively, if the new public key passes the authentication check (528), the electronic engine controller 504 proceeds to step 532 as described below.
[0053] At step 532, in response to the new public key passing the authentication check (528) at step 526, the new public key is stored as the installed public key.
[0054] At step 534, the electronic engine controller 504 performs an authentication check on the CSCI file using the installed public key. Any suitable authentication process can be employed. For example, the electronic engine controller 504 can verify one or more signatures on the CSCI file. When one or more signatures are verified, the CSCI file is authenticated. In some embodiments, as described in step 532, the installed public key is a new public key stored as an installed public key. In some embodiments, the installed public key is a previously installed public key before the electronic engine controller 504 accepts the load request. For example, the installed public key is a previously installed public key when the new public key is not one of the items to be loaded (as described in step 514) and / or when the new public key is equal to the installed public key (as described in step 520).
[0055] At step 540, in response to the CSCI file passing the authentication check (536) at step 534, the CSCI file is stored in the electronic engine controller 504. Subsequently, at step 542, the electronic engine controller 504 executes the loading request and sends a reply indicating the loading result to the data loader 502. More specifically, the electronic engine controller 504 transmits information indicating successful loading to the data loader 502.
[0056] At step 542, the electronic engine controller 504 rejects the loading request in response to the CSCI file failing the authentication check (as described in step 534) (538). Alternatively, the electronic engine controller 504 rejects the loading request in response to the new public key failing the authentication check (as described in step 526) (530). The electronic engine controller 504 sends a reply indicating the loading result to the data loader 502. More specifically, the electronic engine controller 504 transmits information indicating loading failure to the data loader 502.
[0057] In some embodiments, at step 544, the loading result is displayed on the interface of the data loader 502 for operator 546 to view. The loading result may include a response indicating successful or failed loading as described above. In one example, since a new public key has been previously installed and the CSCI file has been authenticated using the new public key, the loading result displayed on the data loader 502 may notify operator 546 that the loading was successful. In another example, since a new public key has been authenticated and subsequently stored, and the CSCI file has been authenticated and subsequently stored using the new public key, the loading result displayed on the data loader 502 may notify operator 546 that the loading was successful. In yet another example, since the new public key and / or the CSCI file has not been authenticated, the loading request displayed on the data loader 502 may notify operator 546 that the loading failed.
[0058] Figure 6 A simplified block diagram is shown illustrating the process for authenticating and updating a public key in a computing system on an aircraft during a first load and one or more subsequent loads. The computing system may be an electronic engine controller. When a load (load 1) including a loadable portion P02 is first loaded, computing system 602 checks whether an installed public key (PK1) 604 matches a new public key (PK2) included in the loadable portion of load P02. In the depicted embodiment, the installed public key (PK1) 604 does not match the new public key (PK2), and the authentication process checks the new public key (PK2). If the new public key (PK2) is authenticated, the installed public key (PK1) is replaced with the new public key (PK2), and the load request succeeds. When a load (load 2) including the same loadable portion P02 is subsequently loaded a second time, computing system 602 checks whether an installed public key (PK2) 606 matches the new public key (PK2). In the depicted embodiment, the installed public key (PK2) 606 matches the new public key (PK2) and bypasses or skips the authentication check, without replacing the installed public key (PK2) 606 with the new public key (PK2), and the load request succeeds. In this way, the loadable portion (P02) is successfully loaded in the first load after the installed public key is replaced with the new public key, and is successfully loaded in one or more future loads of the loadable portion (P02) including the new public key, while the new public key remains unchanged. In other words, the same loadable portion is only installed once on the computing device to prevent engine configuration problems and reduce operator confusion, because two identical loadable portions will not be installed on the computing device.
[0059] Figure 7An exemplary computing system 700 is shown, which can be used to implement any of the components, processing resources, circuits, circuit systems, systems, functions, logic, devices, processes, and / or the systems or apparatus described above or below (e.g., computing devices, electric motor controllers, data loaders).
[0060] exist Figure 7 In the depicted exemplary embodiments, the exemplary computing system 700 includes a processor 702, a memory 704, a storage device 710, and a communication bus 712. In some embodiments, the exemplary computing system 700 includes an interface 714, an input / output (I / O) port 716, and a transceiver 718. The communication bus 712 provides communication between the processor 702, the memory 704, the storage device 710, and the interface 714, the I / O port 716, and the transceiver 718. Although Figure 7 Various components are shown to be communicatively connected together via communication bus 712, but it is conceivable that various components may be directly connected to processor 702 and / or one or more other components.
[0061] Processor 702 may be implemented by one or more processors, microprocessors, central processing units, logic, local digital storage devices, firmware, software, and / or other control hardware and / or software, and may be used to perform or assist in performing the steps of the processes, methods, functions, and techniques described herein, and to control various communications, decisions, configurations, interfaces, logging, reporting, etc. Processor 702 is configured to execute instructions 706 stored on memory 704 to perform operations, such as any operations or functions that a computing device is configured to perform as described above. In some embodiments, exemplary computing system 700 may include software 708 that implements the functions described above. In some forms, software 708 may include instructions that cause processor 702 to perform one or more processes for updating public keys and / or transferring loadable portions as described herein.
[0062] The memory 704 and storage device 710 can be any medium or device capable of storing information or executable instructions, such as RAM, ROM, EEPROM, flash memory, hard disk drive, optical disk, etc. The memory 704 can be disposed within the computing system 700, in which case the executable instructions can be considered to be mounted or embedded on the exemplary computing system 700. Additionally or alternatively, some or all of the memory 704 can be one or more remote, external, and / or portable storage media, and can be part of an installation package.
[0063] Interface 714 can be any suitable hardware (e.g., a USB port, an Ethernet port, etc.), software (e.g., an application programming interface, a communication protocol, etc.), network interface (e.g., a network interface card), or a combination thereof, for communicating with one or more external devices via a wired or wireless network. In some embodiments, interface 714 can allow an operator to interact with and receive information from computing system 700. For example, interface 714 may include a display and / or one or more user inputs, such as buttons, a touchscreen, a trackball, a keyboard, a mouse, etc., which may be part of or connected to computing system 700 via a wired or wireless connection. Furthermore, transceiver 718 can be configured for wired, wireless, optical, fiber optic, satellite, or other such communication constructs, or a combination of two or more such communications.
[0064] I / O port 716 can essentially be any relevant port or combination of ports, such as, but not limited to, USB, Ethernet, or other such ports. I / O port 716, or interface 714 in some embodiments, can be configured to allow wired and / or wireless communication to external devices. For example, I / O port 716 can provide wired and / or wireless communication (e.g., Wi-Fi, Bluetooth, cellular, RF, and / or other such wireless communication).
[0065] According to this teaching, in current methods for updating public keys in a computing system, the new public key must be signed with a private key from an existing public-private key pair. After the new public key is stored in the computing system, the same loading image of the public key cannot be reloaded because authentication will fail. This can lead to configuration management problems and significant operator workload due to the precise order of steps listed in the instructions and the specific order in which loadable parts are loaded, increasing the likelihood of operator confusion. In general, various aspects of this teaching can be adopted with systems, methods, etc., to facilitate the authentication and updating of public keys in computing systems on aircraft. The method described herein allows for updating public keys in a computing system simultaneously using a single loadable part that will be successfully loaded on the first and subsequent requests, thereby reducing operator confusion and the time and complexity required during public key updates.
[0066] Further aspects of this disclosure are provided by the subject matter of the following clauses:
[0067] A method includes: receiving a loadable portion including a new public key by a computing system associated with an aircraft system and having an installed public key; comparing the new public key with the installed public key to determine whether the new public key matches the installed public key; performing an authentication check on the new public key in response to the new public key not matching the installed public key; replacing the installed public key with the new public key in response to the new public key passing the authentication check; and transmitting information indicating unsuccessful loading to a data loader in response to the new public key failing the authentication check.
[0068] The method according to any of the foregoing clauses further includes: bypassing the authentication check on the new public key in response to the new public key matching the installed public key.
[0069] The method according to any of the foregoing clauses further includes: maintaining the installed public key in response to the new public key matching the installed public key.
[0070] The method according to any of the foregoing clauses further includes: in response to the new public key matching the installed public key, transmitting information indicating successful loading to the data loader.
[0071] The method according to any of the foregoing clauses further includes: checking whether the new public key should be loaded into the computing system before comparing the new public key with the installed public key.
[0072] The method according to any of the foregoing clauses further includes: bypassing the comparison of the new public key with the installed public key in response to determining that the new public key should not be loaded into the computing system.
[0073] The method according to any of the foregoing clauses further includes: in response to the new public key matching the installed public key, performing a second authentication check on any other item included in the loadable portion.
[0074] The method according to any of the foregoing clauses further includes: in response to replacing the installed public key with the new public key, transmitting information indicating successful loading to the data loading.
[0075] According to any of the foregoing clauses, the loadable portion is loaded in a first load in response to replacing the installed public key with the new public key; and further includes loading the loadable portion in one or more subsequent loads in response to receiving the loadable portion including the new public key.
[0076] The method according to any of the foregoing clauses further includes: performing a second authentication check on any other item included in the loadable portion after replacing the installed public key with the new public key.
[0077] The method according to any of the foregoing clauses further includes receiving the loadable portion in response to the loading request being accepted.
[0078] The method according to any of the foregoing clauses, wherein the computing system includes an electronic engine controller.
[0079] A system includes: an interface for communicating with a data loader; and a processor-based system coupled to the interface and having an installed public key, the processor-based system being associated with an aircraft, and wherein the processor-based system is configured to perform the steps of: receiving a loadable portion including a new public key; comparing the new public key with the installed public key to determine whether the new public key matches the installed public key; performing an authentication check on the new public key in response to the new public key not matching the installed public key; replacing the installed public key with the new public key in response to the new public key passing the authentication check; and transmitting information indicating unsuccessful loading to the data loader in response to the new public key failing the authentication check.
[0080] According to any of the foregoing clauses, the processor-based system is further configured to perform the following steps: in response to the new public key matching the installed public key, bypassing the authentication check on the new public key.
[0081] According to any of the foregoing clauses, the processor-based system is further configured to maintain the installed public key in response to the new public key matching the installed public key.
[0082] According to any of the foregoing clauses, the processor-based system is further configured to transmit information indicating successful loading to the data loader in response to the new public key matching the installed public key.
[0083] A non-transitory computer-readable storage medium stores one or more computer programs configured to cause a processor-based system to perform the following steps: receiving, by the processor-based system having an installed public key, a loadable portion including a new public key; comparing the new public key with the installed public key to determine whether the new public key matches the installed public key; performing an authentication check on the new public key in response to the new public key not matching the installed public key; replacing the installed public key with the new public key in response to the new public key passing the authentication check; and transmitting information indicating unsuccessful loading to a data loader in response to the new public key failing the authentication check.
[0084] According to any of the preceding clauses, a non-transitory computer-readable storage medium, wherein the one or more computer programs are further configured to cause the processor-based system to perform the following steps: in response to the new public key matching the installed public key, bypassing the authentication check on the new public key.
[0085] A non-transitory computer-readable storage medium according to any of the foregoing clauses, wherein the one or more computer programs are further configured to cause the processor-based system to perform the following steps: maintaining the installed public key in response to the new public key matching the installed public key.
[0086] According to any of the foregoing clauses, the non-transitory computer-readable storage medium, wherein the processor-based system is further configured to transmit information indicating successful loading to the data loader in response to the new public key matching the installed public key.
Claims
1. A method, characterized in that, include: The loading portion, including the new public key, is received by a computing system associated with the aircraft system and having an installed public key. The new public key is compared with the installed public key to determine whether the new public key matches the installed public key; In response to the new public key not matching the installed public key, an authentication check is performed on the new public key; In response to the new public key passing the authentication check, the installed public key is replaced with the new public key; as well as In response to the new public key failing the authentication check, information indicating unsuccessful loading is transmitted to the data loader.
2. The method according to claim 1, characterized in that, Further includes: In response to the new public key matching the installed public key, the authentication check on the new public key is bypassed.
3. The method according to claim 1, characterized in that, Further includes: In response to the new public key matching the installed public key, the installed public key is maintained.
4. The method according to claim 1, characterized in that, Further includes: In response to the new public key matching the installed public key, a message indicating successful loading is transmitted to the data loader.
5. The method according to claim 1, characterized in that, Further includes: Before comparing the new public key with the installed public key, check whether the new public key should be loaded into the computing system.
6. The method according to claim 5, characterized in that, Further includes: In response to determining that the new public key will not be loaded into the computing system, the comparison of the new public key with the already installed public key is bypassed.
7. The method according to claim 1, characterized in that, Further includes: In response to the new public key matching the installed public key, a second authentication check is performed on any other item included in the loadable portion.
8. The method according to claim 1, characterized in that, Further includes: In response to replacing the installed public key with the new public key, information indicating successful loading is transmitted to the data loader.
9. The method according to claim 8, characterized in that, in, The loadable portion is loaded in the first loading process in response to replacing the installed public key with the new public key; and It further includes loading the loadable portion in response to receiving the loadable portion including the new public key in one or more subsequent loads.
10. The method according to claim 1, characterized in that, Further includes: After the installed public key is replaced with the new public key, a second authentication check is performed on any other items included in the loadable portion.