Patent Description:
Aircraft systems may incorporate a plurality of sensors that sense various conditions relating to the aircraft components, which are used by software programs to detect, diagnose, or predict issues and/or faults in real time, even as the aircraft is being operated (e.g., flying). When a component of an aircraft system is reset or powered on, the software programs may be loaded onto a memory device, and a processing device of the aircraft system may subsequently execute the software programs once they are loaded onto the memory device.

Prior to loading the software programs onto the memory device and prior to executing the software programs, an initialization protocol may be executed. During the initialization protocol, the software programs may be authenticated using various cryptographic authentication methods in order to, for example, confirm that the software was not subjected to tampering. Once the software programs are authenticated, the software programs may be loaded onto the memory device for subsequent execution by the processing device.

However, when the aircraft systems are reset, the engine of the aircraft may still be operating. Since the software programs utilized for controlling and monitoring the engine are not executed until after the initialization protocol is completed, the operation of the engine may be negatively impacted if the initialization protocol is not completed within a certain period of time. Accordingly, a need exists for initialization protocols that prevent tampering of the aircraft systems and minimize the negative impact on engine operation. <CIT> discloses a method of secure booting of a system-on-chip using a boot image comprising a first stage boot loader (FSBL) and a second stage boot loader (SSBL). After the FSBL is authenticated, the SSBL is loaded and authenticated. <CIT> relates to systems and methods for authenticating data stored on a device and has particular utility in authenticating such content at run time.

These and other features, and characteristics of the present technology, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the disclosure. As used in the specification and in the claims, the singular form of 'a', 'an', and 'the' include plural referents unless the context clearly dictates otherwise.

The embodiments set forth in the drawings are illustrative and exemplary in nature and are not intended to limit the subject matter defined by the claims.

Referring to the figures, embodiments of the present disclosure are generally related to devices, systems, and methods for securely initializing (e.g., booting) an engine control system of an aircraft system (and/or one or more other embedded systems) in stages to prevent tampering and/or to minimize the impact on engine operation. As described below in further detail, in order to securely initialize the engine control system of the aircraft system, the initializing protocol may authenticate the software programs using various cryptographic authentication techniques, thereby preventing the software programs from being subjected to, for example, malicious tampering.

While the present disclosure relates primarily to an engine control system, it should be understood that the devices, systems, and methods described herein may be used for other embedded systems in aircraft. Furthermore, the engine control systems described herein may include or be a part of an embedded system in some embodiments. Other illustrative embedded systems include, but are not limited to, a microcontroller including one or more central processing units (CPUs).

Furthermore, by initializing the engine control system of the aircraft system in stages, the engine control system can execute priority software programs related to the operation and control of the engine of the aircraft within a predetermined period of time. As a non-limiting example and as described below in further detail, the priority software programs may include machine-readable instructions for controlling the operation of the engine, such as returning the engine to normal operation. Moreover, certain software programs for controlling the operation of the engine may need to be executed within a predetermined period of time when the processing device is released from a reset state in order to prevent damage to the engine of the aircraft. Accordingly, once the processing device is released from the reset state, the priority software programs may be authenticated, loaded onto a designated memory, and initialized within the predetermined period of time.

Once the priority software programs are initialized, non-priority software programs that are unrelated to the operation and control of the engine may be authenticated, loaded onto the designated memory, and then initialized. Additional details regarding the non-priority software programs will be described herein. By executing the staged initialization protocol, the software programs can identify suspicious activity and/or evidence of tampering while simultaneously minimizing the negative impacts to the operation of the engine during the initializing protocol.

Executing the staged initialization protocol described herein improves the speed in which priority software programs for controlling the operation of the engine are loaded onto the designated memory and subsequently executed, thereby improving the operation of the engine control system of the aircraft. Furthermore, executing the staged initialization protocol described herein prevents priority software programs from executing when the priority software programs are not cryptographically authenticated, thereby improving the security of the engine control system of the aircraft.

Referring now to <FIG>, an illustrative aircraft system <NUM> is schematically depicted. In the illustrated embodiment of <FIG>, the aircraft system <NUM> generally includes an aircraft <NUM>, which may include a fuselage <NUM>, wing assemblies <NUM>, and one or more engines <NUM>. While <FIG> depicts the aircraft <NUM> as being a fixed-wing craft having two wing assemblies <NUM> with one engine <NUM> mounted on each wing assembly <NUM> (two engines <NUM> total), other configurations are contemplated. For example, other configurations may include more than two wing assemblies <NUM>, more than two engines <NUM> (e.g., trijets, quadjets, etc.), engines <NUM> that are not mounted to a wing assembly <NUM> (e.g., mounted to the fuselage <NUM>, mounted to the tail, mounted to the nose, etc.), non-fixed wings (e.g., rotary wing aircraft), and/or the like.

As illustrated in <FIG>, the aircraft <NUM> may include the engines <NUM> coupled to the wing assemblies <NUM> and/or the fuselage <NUM>, a cockpit <NUM> positioned in the fuselage <NUM>, and the wing assemblies <NUM> extending outward from the fuselage <NUM>. A control mechanism <NUM> for controlling the aircraft <NUM> is included in the cockpit <NUM> and may be operated by a pilot located therein. It should be understood that the term "control mechanism" as used herein is a general term used to encompass all aircraft control components, particularly those typically found in the cockpit <NUM>.

In some embodiments, a plurality of aircraft control systems <NUM> that enable proper operation of the aircraft <NUM> may also be included in the aircraft <NUM>, as well as an engine control system <NUM>. The aircraft control systems <NUM> may generally be any systems that effect control of one or more components of the aircraft <NUM>, such as, for example, cabin pressure controls, elevator controls, rudder controls, flap controls, spoiler controls, landing gear controls, heat exchanger controls, and/or the like. In some embodiments, the avionics of the aircraft <NUM> may be encompassed by one or more of the aircraft control systems <NUM>. In various embodiments, the engine control system <NUM> may be operably coupled to the other controllers of the aircraft <NUM>, the plurality of aircraft control systems <NUM>, and the engines <NUM>. While the embodiment depicted in <FIG> specifically refers to the engine control system <NUM> controlling the engines <NUM>, it should be understood that other controllers may also be included within the aircraft <NUM> to control various other systems that do not specifically relate to the engines <NUM>.

As shown in the illustrated embodiment of <FIG>, the engine control system <NUM> may include one or more processing devices <NUM> and/or one or more memories <NUM>. In some embodiments, the one or more memories <NUM> may include a non-transitory computer-readable medium, such as random access memory (RAM), read-only memory (ROM), flash memory, or one or more different types of portable electronic memory, such as discs, DVDs, CD-ROMs, or the like, or any suitable combination of these types of memory. The one or more processing devices <NUM> may carry out programming instructions stored on the one or more memories <NUM>, thereby causing operation of the engine control system <NUM>. That is, the one or more processing devices <NUM> and the one or more memories <NUM> within the engine control system <NUM> may be operable to carry out the various processes described herein with respect to the engine control system <NUM>.

Non-limiting example processes include, but are not limited to, operating various components of the aircraft <NUM> (such as the engine <NUM> and/or components thereof), monitoring the health of various components of the aircraft <NUM> (e.g., the engine <NUM> and/or components thereof), monitoring operation of the aircraft <NUM> and/or components thereof, installing software programs, installing software updates, and/or the like. As another non-limiting example, the processes may include diagnosing and/or predicting one or more engine system faults in the aircraft <NUM>. Diagnosed and/or predicted faults may include, but are not limited to, improper operation of components, failure of components, indicators of future failure of components, and/or the like.

The programming instructions run by the engine control system <NUM> (e.g., executed by the one or more processing devices <NUM> and stored within the one or more memories <NUM>) may include a computer program product that includes machine-readable media for carrying or having machine-executable instructions or data structures. Such machine-readable media may be any available media, which can be accessed by a general purpose or special purpose computer or other machine with a processor. Generally, such a computer program may include routines, programs, objects, components, data structures, algorithms, and/or the like that have the technical effect of performing particular tasks or implementing particular abstract data types. Machine-executable instructions, associated data structures, and programs represent examples of program code for executing the exchange of information as disclosed herein. Machine-executable instructions may include, for example, instructions and data, which cause a general purpose computer, special purpose computer, or special purpose processing machine to perform a certain function or group of functions. In some embodiments, the computer program product may be provided by a component external to the engine control system <NUM> and installed for use by the engine control system <NUM>. The computer program product may generally be updatable via a software update that is received from one or more components of the aircraft system <NUM>, such as, for example, a remote computing device <NUM>. The software is generally updated by the engine control system <NUM> by installing the update such that the update supplements and/or overwrites one or more portions of the existing program code for the computer program product. The software update may allow the computer program product to more accurately diagnose and/or predict faults, provide additional functionality not originally offered, and/or the like.

In some embodiments, each of the engines <NUM> may include a fan <NUM> and one or more engine sensors <NUM> for sensing various characteristics of the fan <NUM> and the engine <NUM> during operation of the engines <NUM>. Illustrative examples of the one or more engine sensors <NUM> include, but are not limited to, a fan speed sensor <NUM>, a temperature sensor <NUM>, and a pressure sensor <NUM>. The fan speed sensor <NUM> is generally a sensor that measures a rotational speed of the fan <NUM> within the engine <NUM>. The temperature sensor <NUM> may be a sensor that measures a fluid temperature within the engine <NUM> (e.g., an engine air temperature), a temperature of fluid (e.g., air) at an engine intake location, a temperature of fluid (e.g., air) within a compressor, a temperature of fluid (e.g., air) within a turbine, a temperature of fluid (e.g., air) within a combustion chamber, a temperature of fluid (e.g., air) at an engine exhaust location, a temperature of cooling fluids and/or heating fluids used in heat exchangers in or around the engine <NUM>, and/or the like. The pressure sensor <NUM> may be a sensor that measures a fluid pressure (e.g., air pressure) in various locations in and/or around the engine <NUM>, such as, for example, a fluid pressure (e.g., air pressure) at an engine intake, a fluid pressure (e.g., air pressure) within a compressor, a fluid pressure (e.g., air pressure) within a turbine, a fluid pressure (e.g., air pressure) within a combustion chamber, a fluid pressure (e.g., air pressure) at an engine exhaust location, and/or the like.

In some embodiments, each of the engines <NUM> may have a plurality of engine sensors <NUM> associated therewith (including one or more fan speed sensors <NUM>, one or more temperature sensors <NUM>, and/or one or more pressure sensors <NUM>). That is, more than one of the same type of engine sensor <NUM> may be used to sense characteristics of an engine <NUM> (e.g., an engine sensor <NUM> for each of the different areas of the same engine <NUM>). In some embodiments, one or more of the engine sensors <NUM> may be utilized to sense characteristics of more than one of the engines <NUM> (e.g., a single engine sensor <NUM> may be used to sense characteristics of two engines <NUM>). The engines <NUM> may further include additional components not specifically described herein, and may include one or more additional engine sensors <NUM> incorporated with or configured to sense such additional components in some embodiments.

In embodiments, each of the engine sensors <NUM> (including, but not limited to, the fan speed sensors <NUM>, the temperature sensors <NUM>, and the pressure sensors <NUM>) may be communicatively coupled to one or more components of the aircraft <NUM> such that signals and/or data pertaining to one or more sensed characteristics are transmitted from the engine sensors <NUM> for the purposes of determining, detecting, and/or predicting a fault, as well as completing one or more other actions in accordance with software programming that requires sensor information. As indicated by the dashed lines extending between the various engine sensors <NUM> (e.g., the fan speed sensors <NUM>, the temperature sensors <NUM>, and the pressure sensors <NUM>) and the aircraft control systems <NUM> and the engine control system <NUM> in the embodiment depicted in <FIG>, the various engine sensors <NUM> may be communicatively coupled to the aircraft control systems <NUM> and/or the engine control system <NUM> in some embodiments. As such, the various engine sensors <NUM> may be communicatively coupled via wires or wirelessly to the aircraft control systems <NUM> and/or the engine control system <NUM> to transmit signals and/or data to the aircraft control systems <NUM> and/or the engine control system <NUM>.

As a non-limiting example, while the aircraft <NUM> is being operated, the control mechanism <NUM> may be utilized to operate one or more of the aircraft control systems <NUM>. Various engine sensors <NUM>, including, but not limited to, the fan speed sensors <NUM>, the temperature sensors <NUM>, and/or the pressure sensors <NUM> may output data relevant to various characteristics of the engine <NUM> and/or the other aircraft control systems <NUM>. The engine control system <NUM> may utilize inputs from the control mechanism <NUM>, the fan speed sensors <NUM>, the temperature sensors <NUM>, the pressure sensors <NUM>, the various aircraft control systems <NUM>, one or more databases, and/or information from airline control, flight operations, or the like to diagnose, detect, and/or predict faults. Once a fault has been diagnosed, detected, and/or predicted, an indication may be provided on the aircraft <NUM> and/or to the ground system <NUM>.

In the illustrated embodiment, the aircraft system <NUM> may include an interconnectivity of components coupled via a network <NUM>, which may include a wide area network, such as the internet, a local area network (LAN), a mobile communications network, a public service telephone network (PSTN) and/or other network and may be configured to electronically connect components. The illustrative components that may be connected via the network <NUM> include, but are not limited to, a ground system <NUM> in communication with an aircraft <NUM> (e.g., via the ground wireless communications link <NUM> and the aircraft wireless communications link <NUM>) and the remote computing device <NUM> configured to, for example, provide software updates to various components of the aircraft system <NUM> may transmit data such that data and/or information pertaining to the fault may be transmitted off the aircraft <NUM>. The aircraft wireless communications link <NUM> may generally be any air-to-ground communication system now known or later developed. Illustrative examples of the aircraft wireless communications link <NUM> include, but are not limited to, a transponder, a very high frequency (VHF) communication system, an aircraft communications addressing and reporting system (ACARS), a controller-pilot data link communications (CPDLC) system, a future air navigation system (FANS), and/or the like.

In some embodiments, the ground system <NUM> may be a transmission system located on the ground that is capable of transmitting and/or receiving signals to/from the aircraft <NUM>. That is, the ground system <NUM> may include a ground wireless communications link <NUM> that is communicatively coupled to the aircraft wireless communications link <NUM> wirelessly to transmit and/or receive signals and/or data. As a non-limiting example, the ground system <NUM> may be an air traffic control (ATC) tower and/or one or more components or systems thereof. Accordingly, the ground wireless communications link <NUM> may be a VHF communication system, an ACARS unit, a CPDLC system, FANS, and/or the like. Using the ground system <NUM> and the aircraft wireless communications link <NUM>, the various non-aircraft components depicted in the embodiment of <FIG> may be communicatively coupled to the aircraft <NUM>, even in instances where the aircraft <NUM> is airborne and in flight, thereby allowing for communication of faults detected by the engine control system <NUM> and on-demand transmission of software and/or software updates whenever such software and/or software updates may be needed. However, it should be understood that the embodiment depicted in <FIG> is merely illustrative. In other embodiments, the aircraft <NUM> may be communicatively coupled to the various other components of the aircraft system <NUM> when on the ground and physically coupled to one of the components of the aircraft system <NUM>.

While an example aircraft <NUM> has been described and illustrated in <FIG>, the aircraft <NUM> may have other configurations and/or may be other aerial vehicles in other embodiments. As a non-limiting example, the aircraft <NUM> may be a high speed compound rotary-wing aircraft with supplemental translational thrust systems, an aircraft with dual contra-rotating propellers, an aircraft with a coaxial rotor system, an aircraft with a turboprop engine, a tilt-rotor aircraft, a tilt-wing aircraft, a conventional take-off and landing aircraft, and other turbine-driven machines in other embodiments.

While the embodiment of <FIG> specifically relates to components within an aircraft <NUM>, the present disclosure is not limited to such. That is, the various components depicted with respect to the aircraft <NUM> may be incorporated within various other types of craft. For example, the various components described herein with respect to the aircraft <NUM> may be present in watercraft, spacecraft, and/or the like without departing from the scope of the present disclosure.

With reference to <FIG>, functional block diagram including the engine control system <NUM> is schematically depicted. As illustrated in <FIG>, the engine control system <NUM> may be, but is not limited to, a full authority digital engine control (FADEC) system. The FADEC system generally has full authority over operating parameters of the engines <NUM> and cannot be manually overridden. The operating parameters of the FADEC system can be modified by installing and/or updating software. As such, the FADEC system can be programmatically controlled to determine engine limitations, receive engine health reports, and receive engine maintenance reports and/or the like to undertake certain measures and/or actions in certain conditions.

In some embodiments, the engine control system <NUM> includes an electronic engine controller module (EECM) <NUM>, as well as one or more distributed control modules (DCMs) <NUM> configured to control various aspects of performance of the engines <NUM>. While the illustrated embodiment depicts two DCMs <NUM>, it should be understood that any number of DCMs <NUM> may be included within the engine control system <NUM> in other embodiments.

As described above, the engine sensors <NUM> may output data relevant to various characteristics of the engine <NUM>. The engine control system <NUM> may utilize inputs from the fan speed sensors <NUM>, the temperature sensors <NUM>, the pressure sensors <NUM>, or the like to diagnose, detect, and/or predict faults. As non-limiting examples, the engine control system <NUM> may analyze the data output by the engine sensors <NUM> (e.g., the fan speed sensors <NUM>, the temperature sensors <NUM>, the pressure sensors <NUM>, etc.), over a period of time to determine drifts, trends, steps, or spikes in the operation of the engines <NUM>.

In some embodiments, the engine control system <NUM> may receive a plurality of input variables of a current flight condition, including, but not limited to, air density, throttle lever position, and/or the like from the aircraft control system <NUM>. The inputs are received, analyzed, and used to determine operating parameters such as, but not limited to, fuel flow, stator vane position, bleed valve position, and/or the like. As a non-limiting example, in response to receiving a signal indicating a change in the throttle lever position, the engine control system <NUM> may output a signal causing one or more actuators <NUM> to adjust a parameter of the engine <NUM> accordingly. As another non-limiting example, in response to receiving an input variable corresponding to turning on or turning off the engine <NUM>, the engine control system <NUM> may activate or deactivate the engines <NUM> by controlling an ignition <NUM>. As yet another non-limiting example, the engine control system <NUM> may output a signal to control a hydromechanical fuel unit <NUM> in response to receiving an input variable corresponding to adjusting an amount of fuel provided to the engine <NUM>.

While not illustrated in <FIG>, it should be understood that the engine control system <NUM> may be in communication with other components of the aircraft <NUM>. As non-limiting examples, the engine control system <NUM> may be communicatively coupled to an alternator, reverser solenoids and switches, engine condition monitoring signals, and/or the like in some embodiments.

Referring now to <FIG>, an example embodiment of the engine control system <NUM> is schematically depicted showing additional hardware components contained therein. The engine control system <NUM> generally includes the one or more processing devices <NUM>, a first memory <NUM>-<NUM> a second memory <NUM>-<NUM> of the one or more memories <NUM>, a communication interface <NUM>, network interface hardware <NUM>, and a data storage device <NUM>. The components of the engine control system <NUM> may be physically and/or communicatively coupled through the communication interface <NUM>. While the illustrated embodiment of <FIG> illustrates the first memory <NUM>-<NUM> and the second memory <NUM>-<NUM>, it should be understood that the engine control system <NUM> may have any number of memory components. As a non-limiting example, the first memory <NUM>-<NUM> and the second memory <NUM>-<NUM> may be replaced with a single memory component in some embodiments.

The communication interface <NUM> is formed from any medium that is configured to transmit a signal. As non-limiting examples, the communication interface <NUM> is formed of conductive wires, conductive traces, optical waveguides, or the like. The communication interface <NUM> may also refer to the expanse in which electromagnetic radiation and their corresponding electromagnetic waves are propagated. Moreover, the communication interface <NUM> may be formed from a combination of mediums configured to transmit signals. In one embodiment, the communication interface <NUM> includes a combination of conductive traces, conductive wires, connectors, and buses that cooperate to permit the transmission of electrical data signals to and from the various components of the engine control system <NUM>. Additionally, it is noted that the term "signal" means a waveform (e.g., electrical, optical, magnetic, mechanical or electromagnetic) configured to travel through a medium, such as DC, AC, sinusoidal-wave, triangular-wave, square-wave, vibration, and the like.

The network interface hardware <NUM> may include and/or be configured to communicate with any wired or wireless networking hardware, including an antenna, a modem, a LAN port, a wireless fidelity (Wi-Fi) card, a WiMax card, a long term evolution (LTE) card, a ZigBee card, a Bluetooth chip, a USB card, mobile communications hardware, and/or other hardware for communicating with other networks and/or devices. As a non-limiting example, the network interface hardware <NUM> may include hardware enabling the engine control system <NUM> to communicate with ground support equipment (GSE) <NUM> and/or a memory loader <NUM> of the GSE <NUM>. As used herein, the GSE <NUM> refers to external equipment used to support and test the engine control system <NUM> and/or other components of the aircraft <NUM>. As a non-limiting example, the memory loader <NUM> of the GSE <NUM> may be configured to provide software updates to the engine control system <NUM> and download data obtained by the engine control system <NUM> during a flight. As another non-limiting example, the GSE <NUM> may include production support equipment for restricted data monitoring, test support equipment for comprehensive data monitoring and changing adjustable parameters, and integration test rigs for system and software testing. In some embodiments, the GSE <NUM> may be connected to the engine control system <NUM> via the ground system <NUM> and the aircraft wireless communications link <NUM>.

The data storage device <NUM>, which includes a key database <NUM>, is communicatively coupled to the one or more processing devices <NUM>. As a non-limiting example, the data storage device <NUM> may include one or more database servers that support NoSQL, MySQL, Oracle, SQL Server, NewSQL, or the like. As described below in further detail with reference to <FIG>, the key database <NUM> may include a plurality of private and/or public keys that are utilized to cryptographically authenticate the engine control system <NUM> during an initialization protocol.

As described above, the one or more processing devices <NUM>, each of which may be a computer processing unit (CPU), may receive and execute machine-readable instructions stored in the first memory <NUM>-<NUM> and the second memory <NUM>-<NUM>. As a non-limiting example, the one or more processing devices <NUM> may be one of a shared processor circuit, dedicated processor circuit, or group processor circuit. As described herein, the term "shared processor circuit" refers to a single processor circuit that executes some or all machine-readable instructions from the multiple modules. As described herein, the term "group processor circuit" refers to a processor circuit that, in combination with additional processor circuits, executes some or all machine-executable instructions from the multiple modules of the memories <NUM>.

The first memory <NUM>-<NUM> and the second memory <NUM>-<NUM> are communicatively coupled to the one or more processing devices <NUM>. As a non-limiting example, each of the first memory <NUM>-<NUM> and the second memory <NUM>-<NUM> may be one of a shared memory circuit, dedicated memory circuit, or group memory circuit. As described herein, the term "shared memory circuit" refers to a single memory circuit that stores some or all machine-readable instructions from multiple modules, which are described below in further detail. As described herein, the term "group memory circuit" refers to a memory circuit that, in combination with additional memories, stores some or all machine-readable instructions from the multiple modules. Non-limiting examples of the first memory <NUM>-<NUM> and the second memory <NUM>-<NUM> include random access memory (including SRAM, DRAM, and/or other types of random access memory), read-only memory (ROM), flash memory, registers, compact discs (CD), digital versatile discs (DVD), and/or other types of storage components.

As shown in <FIG>, the first memory <NUM>-<NUM> includes a plurality of logic modules. Each of the logic modules may be embodied as a computer program, firmware, or hardware, as an example. An illustrative example of a logic module includes, but is not limited to, an initialization module <NUM>. In some embodiments, the initialization module <NUM> includes a plurality of boot stage loaders <NUM>, a first stage boot loader backup image <NUM>, an operating system (OS) kernel <NUM>, a configuration module <NUM>, an authentication module <NUM>, and a verification module <NUM>. Additional illustrative examples of the logic modules include the one or more DCMs <NUM> and the EECM <NUM>. Each of the logic modules may include one or more programming instructions that are executable by the one or more processing devices <NUM>, such as the processes described in <FIG>.

With continued reference to <FIG>, the engine control system <NUM> is illustrated as being turned off or immediately after the engine control system <NUM> is reset via a hardware or software command. Initially, the first memory <NUM>-<NUM> stores the initialization module <NUM>, the one or more DCMs <NUM>, and the EECM <NUM>. Once the engine control system <NUM> is turned on and/or released from reset, the engine control system <NUM> may initialize a staged initialization protocol in order to load the one or more DCMs <NUM> and the EECM <NUM> onto the second memory <NUM>-<NUM> for subsequent execution by the one or more processing devices <NUM>. As described below in further detail with reference to <FIG>, when the initialization module <NUM> is executed, the one or more processing devices <NUM> may cryptographically authenticate and/or verify a first set of machine-readable instructions associated with priority partitions <NUM>-<NUM>, <NUM>-<NUM> (collectively referred to as priority partitions <NUM>) of the DCMs <NUM> and the EECM <NUM>, respectively, prior to loading the first set of machine-readable instructions onto the second memory <NUM>-<NUM>. Additionally and as described below in further detail, when the initialization module <NUM> is executed, the one or more processing devices <NUM> may cryptographically authenticate and/or verify the configuration information associated with first set of machine-readable instructions.

Once the first set of machine-readable instructions are initialized, the one or more processing devices <NUM> may cryptographically authenticate and/or verify a second set of machine-readable instructions associated with non-priority partitions <NUM>-<NUM>, <NUM>-<NUM> (collectively referred to as non-priority partitions <NUM>) of the DCMs <NUM> and the EECM <NUM>, respectively, prior to loading the second set of machine-readable instructions onto the second memory <NUM>-<NUM>. Likewise, when the initialization module <NUM> is executed, the one or more processing devices <NUM> may cryptographically authenticate and/or verify the configuration information associated with second set of machine-readable instructions. By executing the staged initialization protocol, the initialization module <NUM> can identify suspicious activity and/or evidence of tampering while simultaneously minimizing the negative impacts to the operation of the engine <NUM> during an initializing protocol.

While the above embodiment describes loading the machine-readable instructions from the first memory <NUM>-<NUM> to the second memory <NUM>-<NUM>, it should be understood that in other embodiments, the machine-readable instructions may be loaded from a first portion of the first memory <NUM>-<NUM> to a second portion of the first memory <NUM>-<NUM> (i.e., the first memory <NUM>-<NUM> is a group memory circuit).

With reference to <FIG>, flow diagrams of an illustrative method <NUM> of executing the staged initialization protocol are depicted. Referring to <FIG>, at block <NUM>, the engine control system <NUM> releases the one or more processing devices <NUM> from reset via a hardware or software command (e.g., the engine control system <NUM> is released from reset once a power supply and clock source (not shown) of the engine control system <NUM> are stable after the hardware or software reset command). At block <NUM>, the one or more processing devices <NUM> begin authenticating a first stage boot loader <NUM>-<NUM> by executing the programming instructions of the authentication module <NUM>. Furthermore, at block <NUM>, the one or more processing devices <NUM> determine whether the first stage boot loader <NUM>-<NUM> is authenticated by executing the programming instructions of the authentication module <NUM>.

By executing the programming instructions of the authentication module <NUM> at block <NUM> and block <NUM>, the one or more processing devices <NUM> perform various cryptographic authentication algorithms including, but not limited to, symmetric key encryption (e.g., <NUM>-bit symmetric encryption, 3DES, AES, etc.), asymmetric key encryption (e.g., <NUM>-bit asymmetric encryption, RSA, ECDSA, etc.), and/or hashing algorithms (<NUM>-bit hash, HMAC-SHA256, etc.).

As a non-limiting example, the one or more processing devices <NUM> may generate a public key (i.e., an arbitrary bit string), encrypt the first stage boot loader <NUM>-<NUM> with the public key, and authenticate the first stage boot loader <NUM>-<NUM> if it corresponds to a private key stored in the key database <NUM>. In some embodiments, the public key may correspond to the private key if the one or more processing devices <NUM> can decrypt the contents of the first stage boot loader <NUM>-<NUM> using the private key. If the public key corresponds to the private key stored in the key database <NUM>, the one or more processing devices <NUM> may determine that the first stage boot loader <NUM>-<NUM> is authenticated and has not been subjected to tampering, and the one or more processing devices <NUM> may continue the staged initialization protocol. Otherwise, if the public key does not correspond to the private key stored in the key database <NUM>, the one or more processing devices <NUM> will not be able to decrypt the first stage boot loader <NUM>-<NUM>, thereby causing the one or more processing devices <NUM> to determine that the first stage boot loader <NUM>-<NUM> is not authenticated. Moreover, the one or more processing devices <NUM> may determine that the first stage boot loader <NUM>-<NUM> was subjected to tampering in response to the public key not corresponding to the private key.

As another non-limiting example, the one or more processing devices <NUM> may generate a public key (i.e., an arbitrary bit string) and transmit the public key to the key database <NUM>. Further, the one or more processing devices <NUM> may encrypt the first stage boot loader <NUM>-<NUM> with the public key and determine whether the public key corresponds to an entry in the key database <NUM> (i.e., determine whether the public key was successfully transmitted to the key database <NUM>). If the public key corresponds to an entry in the key database <NUM>, the one or more processing devices <NUM> may decrypt the first stage boot loader <NUM>-<NUM>. Accordingly, the one or more processing devices <NUM> may then determine that the first stage boot loader <NUM>-<NUM> is authenticated and has not been subjected to tampering, and the one or more processing devices <NUM> may continue the staged initialization protocol. Otherwise, if the generated public key does not correspond to an entry in the key database <NUM>, the one or more processing devices <NUM> will not be able to decrypt the first stage boot loader <NUM>-<NUM>, thereby causing the one or more processing devices <NUM> to determine that the first stage boot loader <NUM>-<NUM> is not authenticated. Moreover, the one or more processing devices <NUM> may determine that the first stage boot loader <NUM>-<NUM> was subjected to tampering in response to the public key not corresponding to an entry in the key database <NUM>.

If the one or more processing devices <NUM> determine that the first stage boot loader <NUM>-<NUM> is not authenticated at block <NUM>, the method <NUM> proceeds to block <NUM>; otherwise, the method <NUM> proceeds to block <NUM>. At block <NUM>, the one or more processing devices <NUM> determine whether the initialization module <NUM> includes the first stage boot loader backup image <NUM> (i.e., a copy of the first stage boot loader <NUM>-<NUM>). If so, the method <NUM> proceeds to block <NUM>; otherwise, the method <NUM> proceeds to block <NUM>, where the engine control system <NUM> is reset and then proceeds to block <NUM>. In some embodiments, the engine control system <NUM> temporarily discontinues receiving electrical power from a power supply (not shown) and removes any machine-readable instructions stored on the second memory <NUM>-<NUM> when the engine control system <NUM> is reset.

At block <NUM>, the one or more processing devices <NUM> determine whether the first stage boot loader backup image <NUM> is authenticated by executing the programming instructions of the authentication module <NUM>. As described above, the one or more processing devices <NUM> perform various cryptographic authentication algorithms including, but not limited to, symmetric key encryption, asymmetric key encryption, and/or hashing algorithms to authenticate whether the first stage boot loader backup image <NUM>. If the first stage boot loader backup image <NUM> is authenticated at block <NUM>, the method <NUM> proceeds to block <NUM>; otherwise, the method <NUM> proceeds to block <NUM>.

At block <NUM>, the one or more processing devices <NUM> begin executing the first stage boot loader <NUM>-<NUM>. In the illustrated embodiment, executing the first stage boot loader <NUM>-<NUM> includes determining whether the engine control system <NUM> is in a memory loader mode. As described herein, the engine control system <NUM> is in the memory loader mode when the engine control system <NUM> is connected to the memory loader <NUM> of the GSE <NUM> via the network interface hardware <NUM>. If the engine control system <NUM> is in the memory loader mode, the method <NUM> proceeds to block <NUM> illustrated in <FIG>; otherwise, the method <NUM> proceeds to block <NUM> illustrated in <FIG>.

It should be understood that in other embodiments, beginning the execution of the first stage boot loader <NUM>-<NUM> (i.e., block <NUM> in <FIG>) may include and/or be preceded by other functions. As non-limiting examples, executing the first stage boot loader <NUM>-<NUM> may be preceded by a power on self test (POST) of the engine control system <NUM>.

With reference to <FIG> and <FIG>, at block <NUM> (i.e., when block <NUM> in <FIG> determines the engine control system <NUM> is in the memory loader mode), the one or more processing devices <NUM> begin authenticating the memory loader <NUM> by executing the programming instructions of the authentication module <NUM>. Furthermore, at block <NUM>, the one or more processing devices <NUM> determine whether the memory loader <NUM> is authenticated by executing the programming instructions of the authentication module <NUM>. By executing the programming instructions of the authentication module <NUM> at block <NUM> and block <NUM>, the one or more processing devices <NUM> perform various cryptographic authentication algorithms including, but not limited to, symmetric key encryption, asymmetric key encryption, and/or hashing algorithms.

If the memory loader <NUM> is authenticated at block <NUM>, the method <NUM> proceeds to block <NUM>, where the one or more processing devices <NUM> execute the memory loader <NUM>. The method <NUM> then ends. Still referring to <FIG> and <FIG>, if the memory loader <NUM> is not authenticated at block <NUM>, the method <NUM> proceeds to block <NUM>. At block <NUM>, the one or more processing devices <NUM> record a security log indicating the failed authentication of the memory loader <NUM> and then generate a corresponding output at block <NUM>. In some embodiments, the corresponding output may be a hardware output consistent with a FADEC standard and/or protocol. In other embodiments, the corresponding output may be other hardware outputs, such as an activation of a light-emitting diode (LED) circuit and/or other similar circuits of the engine control system <NUM>.

At block <NUM>, the one or more processing devices <NUM> reboot the first stage boot loader <NUM>-<NUM>, and then the method <NUM> proceeds to block <NUM>. As a non-limiting example, rebooting the first stage boot loader <NUM>-<NUM> may include executing machine-readable instructions that cause one or more processing devices <NUM> to repeat the authentication of the memory loader <NUM> described at block <NUM> and block <NUM>. Accordingly, in some embodiments, the method <NUM> may not complete the staged initialization protocol if the memory loader <NUM> is not authenticated, thereby enhancing the security of the engine control system <NUM> by preventing an unauthenticated external device from initializing and/or manipulating the engine control system <NUM>.

Referring now to <FIG> and <FIG>, at block <NUM> (i.e., when block <NUM> in <FIG> determines the engine control system <NUM> is not in the memory loader mode), the one or more processing devices <NUM> begin authenticating the second stage boot loader <NUM>-<NUM> by executing the programming instructions of the authentication module <NUM>. By executing the programming instructions of the authentication module <NUM> at block <NUM>, the one or more processing devices <NUM> perform various cryptographic authentication algorithms including, but not limited to, symmetric key encryption, asymmetric key encryption, and/or hashing algorithms.

As a non-limiting example, the one or more processing devices <NUM> may generate a public key (i.e., an arbitrary bit string), encrypt the second stage boot loader <NUM>-<NUM> with the public key, and authenticate the second stage boot loader <NUM>-<NUM> if it corresponds to a private key stored in the key database <NUM>. In some embodiments, the public key may correspond to the private key if the one or more processing devices <NUM> can decrypt the contents of the second stage boot loader <NUM>-<NUM> using the private key. If the public key corresponds to the private key stored in the key database <NUM>, the one or more processing devices <NUM> may determine that the second stage boot loader <NUM>-<NUM> is authenticated and has not been subjected to tampering, and the one or more processing devices <NUM> may continue the staged initialization protocol. Otherwise, if the public key does not correspond to the private key stored in the key database <NUM>, the one or more processing devices <NUM> will not be able to decrypt the second stage boot loader <NUM>-<NUM>, thereby causing the one or more processing devices <NUM> to determine that the second stage boot loader <NUM>-<NUM> is not authenticated. Moreover, the one or more processing devices <NUM> may determine that the second stage boot loader <NUM>-<NUM> was subjected to tampering in response to the public key not corresponding to the private key.

As another non-limiting example, the one or more processing devices <NUM> may generate a public key (i.e., an arbitrary bit string), transmit the public key to the key database <NUM>, encrypt the second stage boot loader <NUM>-<NUM> with the public key, and determine whether the public key corresponds to an entry in the key database <NUM> (i.e., determine whether the public key was successfully transmitted to the key database <NUM>). If the public key corresponds to an entry in the key database <NUM>, the one or more processing devices <NUM> may decrypt the second stage boot loader <NUM>-<NUM>. Accordingly, the one or more processing devices <NUM> may then determine that the second stage boot loader <NUM>-<NUM> is authenticated and has not been subjected to tampering, and the one or more processing devices <NUM> may continue the staged initialization protocol. Otherwise, if the generated public key does not correspond to an entry in the key database <NUM>, the one or more processing devices <NUM> will not be able to decrypt the second stage boot loader <NUM>-<NUM>, thereby causing the one or more processing devices <NUM> to determine that the second stage boot loader <NUM>-<NUM> is not authenticated. Moreover, the one or more processing devices <NUM> may determine that the second stage boot loader <NUM>-<NUM> was subjected to tampering in response to the public key not corresponding to an entry in the key database <NUM>.

At block <NUM>, the one or more processing devices <NUM> record the authentication result obtained at block <NUM>. At block <NUM>, the one or more processing devices <NUM> determine whether the second stage boot loader <NUM>-<NUM> was authenticated. If so, the method <NUM> proceeds to block <NUM>, where the one or more processing devices <NUM> record a security log indicating the failed authentication of the second stage boot loader <NUM>-<NUM>. At block <NUM>, the one or more processing devices <NUM> generate an output indicating potential suspicious activity at block <NUM> (e.g., a hardware output, such as an activation of an LED circuit and/or other similar circuits of the engine control system <NUM>) and then proceeds to block <NUM> in <FIG>. Accordingly, in some embodiments, the staged initialization protocol may be completed when the second stage boot loader <NUM>-<NUM> is not authenticated, and an operator of the aircraft <NUM> may be notified of the failed authentication based on the hardware output at block <NUM>. In some embodiments, the authentication result of the second stage boot loader <NUM>-<NUM> illustrated in <FIG> may be utilized by the engine control system <NUM> to determine a channel health of the engine control system <NUM>, which may indicate a redundancy of the engine control system <NUM>.

With reference to <FIG> and <FIG>, an illustrative overview of executing the second stage boot loader <NUM>-<NUM> is depicted. As described above, executing the second stage boot loader <NUM>-<NUM> begins in response to authenticating the first stage boot loader <NUM>-<NUM> (as illustrated in <FIG> and <FIG>) and authenticating the memory loader <NUM> (as illustrated in <FIG> and <FIG>). Furthermore, executing the second stage boot loader <NUM>-<NUM> begins in response to authenticating the first stage boot loader <NUM>-<NUM> (as illustrated in <FIG> and <FIG>) and authentication of the second stage boot loader <NUM>-<NUM> (as illustrated in <FIG> and <FIG>).

Referring now to <FIG> and <FIG>, at block <NUM> illustrated in <FIG>, one or more processing devices <NUM> load the operating system onto the second memory <NUM>-<NUM> by executing the OS kernel <NUM>. Furthermore, at block <NUM>, the one or more processing devices <NUM> load a first set of machine-readable instructions associated with the priority partitions <NUM> onto the second memory <NUM>-<NUM>. As used herein, the first set of machine-readable instructions associated with the priority partitions <NUM> refer to machine-readable instructions related to controlling the engine <NUM>, such as returning the engine <NUM> to normal operation when the one or more processing devices <NUM> are released from reset.

Additionally, at block <NUM>, the one or more processing devices <NUM> load configuration information associated with the first set of machine-readable instructions by executing the configuration module <NUM>. As used herein, configuration information refers to digital signatures associated with the machine-readable instructions and a verification method to be employed for verifying data utilized by the machine-readable instructions and data stored in the data storage device <NUM>.

At block <NUM>, the one or more processing devices <NUM> authenticate the operating system, the configuration information, and the first set of machine-readable instructions. As non-limiting examples, the one or more processing devices <NUM> may perform the authentication using various cryptographic authentication algorithms including, but not limited to, symmetric key encryption, asymmetric key encryption, hashing algorithms, and/or the like. At block <NUM>, the one or more processing devices <NUM> records the authentication result and generates a corresponding output.

At block <NUM>, the one or more processing devices <NUM> verify the data utilized by the first set of machine-readable instructions by executing the verification module <NUM>. As non-limiting examples, the verification module <NUM> may include instructions corresponding to a data type validation, a range and constraint validation, a code and cross-reference validation, a structured validation, and/or any other suitable data verification methods. At block <NUM>, the one or more processing devices <NUM> initialize the first set of machine-readable instructions and then execute the first set of machine-readable instructions within an allocated time at block <NUM>. By executing the first set of machine-readable instructions within an allocated period of time (i.e., a predetermined period of time), the engine <NUM> is less prone to damage during the staged initialization protocol, as critical engine control software can be executed during the staged initialization protocol.

In response to the allocated period of time elapsing, the one or more processing devices <NUM> load a second set of machine-readable instructions associated with the non-priority partitions <NUM> onto the second memory <NUM>-<NUM> at block <NUM>. As used herein, the second set of machine-readable instructions associated with the non-priority partitions <NUM> refers to machine-readable instructions unrelated to controlling the engine <NUM>, such as monitoring engine health, computing maximum available power, and component health. In addition, at block <NUM>, the one or more processing devices <NUM> load configuration information associated with the second set of machine-readable instructions onto the second memory <NUM>-<NUM> by executing the configuration module <NUM>.

At block <NUM>, the one or more processing devices <NUM> authenticate the second set of machine-readable instructions. As non-limiting examples, the one or more processing devices <NUM> may perform the authentication using various cryptographic authentication algorithms including, but not limited to, symmetric key encryption, asymmetric key encryption, hashing algorithms, and/or the like. Furthermore, at block <NUM>, the one or more processing devices <NUM> verify the data utilized by the second set of machine-readable instructions by executing the verification module <NUM>.

At block <NUM>, the one or more processing devices <NUM> generate an output corresponding to the verification and authentication results. In some embodiments, the corresponding output may be a hardware output consistent with a FADEC standard and/or protocol. In other embodiments, the corresponding output may be other hardware outputs, such as an activation of a light-emitting diode (LED) circuit and/or other similar circuits of the engine control system <NUM>.

At block <NUM>, the one or more processing devices <NUM> initialize the second set of machine-readable instructions and then execute the second set of machine-readable instructions within an allocated time at block <NUM>. By executing the second set of machine-readable instructions within an allocated predetermined period of time, the staged initialization protocol can be completed within a suitable period of time, thereby enabling the engine control system <NUM> to perform the functionality described herein.

At block <NUM>, the one or more processing devices <NUM> determine whether additional boot loaders <NUM> are located on the first memory <NUM>-<NUM> (e.g., a third boot loader). If so, the method <NUM> proceeds to block <NUM>, where the one or more processing devices <NUM> load an additional set of machine-readable instructions onto the second memory <NUM>-<NUM> and configuration information associated with the additional set of machine-readable instructions. At block <NUM>, the one or more processing devices <NUM> authenticate the additional set of machine-readable instructions. As non-limiting examples, the one or more processing devices <NUM> may perform the authentication using various cryptographic authentication algorithms including, but not limited to, symmetric key encryption, asymmetric key encryption, hashing algorithms, and/or the like. Furthermore, at block <NUM>, the one or more processing devices <NUM> verify the data utilized by the additional set of machine-readable instructions by executing the verification module <NUM>. The method <NUM> then proceeds to block <NUM>.

Still referring to <FIG> and <FIG>, if the one or more processing devices <NUM> determine that no additional boot loaders <NUM> are located on the first memory <NUM>-<NUM>, the method <NUM> proceeds to block <NUM>, where the one or more processing devices <NUM> determines that the staged initialization protocol is complete and delegates control of the engine control system <NUM> to the operating system.

By executing the staged initialization protocol described above with reference to <FIG>, the priority software programs related to the control of the engine are authenticated, loaded, and executed prior to the authentication, loading, and execution of non-priority software programs. By executing the staged initialization protocol described herein, the software programs can quickly identify suspicious activity and/or evidence of tampering while simultaneously minimizing the negative impacts to the operation of the engine during the staged initialization protocol.

The functional blocks and/or flowchart elements described herein may be translated onto machine-readable instructions. As non-limiting examples, the machine-readable instructions may be written using any programming protocol, such as: descriptive text to be parsed (e.g., such as hypertext markup language, extensible markup language, etc.), (ii) assembly language, (iii) object code generated from source code by a compiler, (iv) source code written using syntax from any suitable programming language for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. Alternatively, the machine-readable instructions may be written in a hardware description language (HDL), such as logic implemented via either a field programmable gate array (FPGA) configuration or an application-specific integrated circuit (ASIC), or their equivalents. Accordingly, the functionality described herein may be implemented in any conventional computer programming language, as pre-programmed hardware elements, or as a combination of hardware and software components.

Claim 1:
A method (<NUM>) for initiating an engine control system (<NUM>) of an aircraft, the method comprising:
authenticating (<NUM>), by one or more processors (<NUM>), a first stage boot loader (<NUM>-<NUM>);
executing, by the one or more processors (<NUM>), the first stage boot loader in response to authentication of the first stage boot loader (<NUM>-<NUM>), wherein executing the first stage boot loader (<NUM>-<NUM>) comprises:
determining (<NUM>), by the one or more processors, whether the engine control system (<NUM>) is in a memory loader mode based on whether the engine control system (<NUM>) is connected to a memory loader (<NUM>);
upon determination that the engine control system (<NUM>) is not in the memory loader mode:
authenticating (<NUM>), by the one or more processors (<NUM>), a second stage boot loader (<NUM>-<NUM>); and
executing, by the one or more processors (<NUM>), the second stage boot loader (<NUM>-<NUM>) in response to authentication of the second stage boot loader (<NUM>-<NUM>), wherein executing the second stage boot loader (<NUM>-<NUM>) comprises:
loading (<NUM>), by the one or more processors (<NUM>), an operating system, a first set of machine-readable instructions, and first configuration information associated with the first set of machine-readable instructions onto a non-transitory computer-readable medium (<NUM>-<NUM>), wherein the first set of machine-readable instructions and the first configuration information are associated with one or more priority partitions (<NUM>);
authenticating (<NUM>), by the one or more processors (<NUM>), the operating system and the first set of machine-readable instructions; and
executing (<NUM>), by the one or more processors (<NUM>), the first set of machine-readable instructions in response to authentication of the operating system and the first set of machine-readable instructions.