Enhanced reporting and configuration of airborne authentication software

Abstract

A method is provided for remotely transmitting software management tasks for authenticated software from a source to a software management module on an asset via a wireless communication link. The method includes encrypting the communication link between the source and the software management module to form a secure tunnel, and verifying the source's credentials via the software management module when transmitting the software management task file. Upon verification of the source's credentials, a portion of the transmitted software management task file undergoes a load assurance check to confirm the integrity of the transmitted file. Once file integrity is verified, the software management task is executed immediately, automatically without human intervention.

Description

Technical Field

[0001] This invention relates to remotely updating and managing software. In particular, it relates to wirelessly updating executable files via a wireless link in a highly controlled environment without human intervention. Background Technology

[0002] Historically, original equipment manufacturers (OEMs) or asset industry owners (such as airlines) have initiated the process of deploying new software onto their assets. Depending on the criticality of the software, a step in the process requires personnel (e.g., human resources personnel) to personally go on board the aircraft to manually install or distribute the software, or to provide permission to load the software.

[0003] As those skilled in the art understand, there are various methods, such as using Wi-Fi, cellular, Bluetooth, and optical, to wirelessly transmit new software to the aircraft. However, once the software is transmitted to the aircraft, it remains dormant until HR personnel physically approach the aircraft and activate it, causing it to begin execution. Therefore, in traditional systems, HR personnel remain in a loop. Consequently, deploying new software on an aircraft is a completely manual process requiring direct interaction between the customer or others and the aircraft.

[0004] As airports become more congested, obtaining the necessary aircraft access can be problematic. Furthermore, in some cases, HR personnel with the necessary expertise and software loading permissions may be located at one location preparing to upload software, while the aircraft is at another.

[0005] There are also limitations to the number of HR personnel who can perform updates. For example, it might be challenging to dispatch one person to accurately update and verify a fleet of 100 aircraft. Even assuming there are enough HR personnel to update a fleet of 100 aircraft, there are delays. After the update is performed, the OEM or airline will want to see the results of the software update immediately. However, because humans are still in the loop, the actual realization of results will always be limited by the bandwidth of the number of people required to access each aircraft being served.

[0006] As an example of traditional software updates based on a small subset of software-based systems, most commercial aircraft include Flight Data Recorders (FDRs) and Aircraft Communications and Reporting Systems (ACARS), as well as many other software-based Field Replaceable Units (LRUs). Another common system is the Aircraft Condition Monitoring System (ACMS). Software updates can be remotely transferred to these systems by operators. However, these software updates cannot be activated until maintenance personnel physically connect to each system or LRU in each aircraft and initiate or execute the software. This update functionality can be performed using certain types of Ground Support Equipment (GSEs) or by using built-in interfaces such as maintenance terminals.

[0007] Figure 1 The illustration depicts a conventional system 100 used for transferring and uploading executable software to aircraft 102 in a highly regulated environment. Figure 1 In this configuration, aircraft 102 includes an embedded LRU 104, which is configured to receive software updates. For example, LRU 104 could be an ACMS configured to receive software updates. Figure 1 In the example, the software update includes an executable file and may have been wirelessly transmitted to LRU 104 (not shown) via a wireless link.

[0008] Although transmitted wirelessly, the software remains inactive within LRU 104. A human operator (e.g., maintenance personnel 106) must physically and manually activate the software via a mechanism such as GSE 108. In conventional systems 100, maintenance personnel 106 manually perform software load verification checks, as well as any other required software security procedures. Historically, someone on board has always verified the software load, run software updates, and released executables. Summary of the Invention

[0009] Given the aforementioned shortcomings, methods and systems are needed to facilitate the automated uploading of executable files to systems operating in highly regulated environments, such as commercial aircraft. More specifically, the basic system architecture requires methods and systems for developing applications on desktops and wirelessly deploying them to highly regulated assets (e.g., aircraft) for execution without human intervention. Methods and systems are also needed to enable operators to remotely transfer software to assets, initiate software execution fully autonomously in real time, and provide appropriate security levels to verify the software's origin from a trusted source.

[0010] In some cases, embodiments of the present invention include a method for remotely transmitting software management tasks for authenticated software from a source to a software management module on an asset via a wireless communication link. The method includes encrypting the communication link between the source and the software management module to form a secure tunnel, and verifying the source's credentials via the software management module when transmitting the software management task file. Upon verification of the source's credentials, a portion of the transmitted software management task file undergoes a load assurance check to confirm the integrity of the transmitted file. Once file integrity is verified, the software management task is executed immediately, automatically, without human intervention.

[0011] As those skilled in the art will understand, the term "regulated assets" can be applied to many different types of equipment across various industry sectors. For example, the Department of Homeland Security has identified 16 critical infrastructure sectors, one of which is the transportation sector. The aviation industry is an industry within the transportation sector. The invention or embodiments thereof can also be applied to other industries within the transportation sector, such as autonomous vehicles. However, the invention can also be applied entirely to other critical infrastructure sectors, such as the energy sector (e.g., power generation) and the healthcare sector (e.g., medical devices), to name just a few.

[0012] Commercial aircraft are perhaps the most heavily regulated assets in the world's most regulated environments, with the public involved every day. A typical aircraft comprises multiple software-based systems that require regular software updates.

[0013] For example, an aircraft's ACMS monitors key parameters and abnormal outputs of the aircraft's engines, flight control system, and electrical system. The ACMS performs limited processing based on these monitored systems and creates reports transmitted from the aircraft, summarizing its performance. Various types of ACMS, ACMS software platforms, and vendors exist.

[0014] In traditional ACMS, if an operator needs a new type of report, they are required to submit a request for the new report to the supplier or avionics vendor. For example, a new report might require existing data to be processed in a new or unique way. Only the supplier possesses the tools and skills to rewrite the software to modify the report and upload the new software to the ACMS.

[0015] However, embodiments of the present invention can function using any object-oriented high-level programming language suitable for developing desktop and / or web-based applications. Python is an example of such a modern programming language, widely familiar to airline or airframe IT departments and software developers. Object-oriented high-level programming languages ​​typically support modularity and code readability. Therefore, leveraging the modularity and automation of programming languages ​​with built-in data update modules, operators, airframe personnel, or system administrators can create and deploy new software.

[0016] Embodiments of the present invention also incorporate appropriate security features, including trusted sources and load assurance checks. These features reduce the likelihood of malicious actors (e.g., passengers and other non-airline personnel) transmitting malware to trigger unwanted avionics consequences or other actions that would adversely affect aircraft performance.

[0017] Embodiments of the present invention also expand the types of wireless mechanisms for transmitting software updates to assets. For example, in some cases only WiFi is available, while in others only cellular is available. Embodiments extend these mechanisms to any suitable wireless transmission medium.

[0018] Various aspects of the embodiments make updating and managing software on devices more convenient, reliable, and user-friendly for airlines and OEMs. In these embodiments, the software management module provides remote querying, device self-reporting, real-time configuration / report creation, and configurable error reports / log files automatically sent upon connection and during flight access. The provided features can be generalized for any device requiring remote updates and management.

[0019] Other features, modes of operation, advantages, and other aspects of various embodiments are described below with reference to the accompanying drawings. It should be noted that this disclosure is not limited to the specific embodiments described herein. These embodiments are for illustrative purposes. Other embodiments, or modifications to the disclosed embodiments, will be apparent to those skilled in the art based on the teachings provided. Attached Figure Description

[0020] Illustrative embodiments may form various components and arrangements of components. Illustrative embodiments are shown in the accompanying drawings, and similar reference numerals may indicate corresponding or similar portions in different drawings throughout. These drawings are for illustrative purposes and are not to be construed as limiting this disclosure. The novel aspects of this disclosure will become apparent to those skilled in the art from the following description of the drawings.

[0021] Figure 1 A conventional system for uploading executable software to an aircraft is shown.

[0022] Figure 2 A system constructed according to an embodiment of the present invention is shown.

[0023] Figure 3 A more detailed description based on an outstanding embodiment is shown. Figure 2 An example update module.

[0024] Figure 4This is an exemplary illustration of a deployment embodiment of a single update module of the present invention in a hub configuration for serving three aircraft systems.

[0025] Figure 5 This is an exemplary illustration of an alternative deployment of multiple update modules, each coupled to multiple aircraft systems.

[0026] Figure 6 This is a flowchart illustrating an exemplary method for implementing an embodiment of the present invention.

[0027] Figure 7 This is a diagram of an exemplary computer system that can implement embodiments of the present invention.

[0028] Figure 8 This is an exemplary software management module constructed according to an alternative embodiment of the present invention.

[0029] Figure 9 This is an exemplary illustration of the deployment of an embodiment of a single software management module of the present invention in a hub configuration for providing services to one or more aircraft systems.

[0030] Figure 10 This is a flowchart illustrating an exemplary method for implementing an alternative embodiment of the present invention. Detailed Implementation

[0031] While illustrative embodiments are described herein for specific applications, it should be understood that this disclosure is not limited thereto. Those skilled in the art and those who have access to the teachings provided herein will recognize other applications, modifications, and embodiments within the scope of the art and in other areas where this disclosure has significant utility.

[0032] Embodiments of the present invention provide the following elements (a)-(f), regarding Figure 1-7 Let's discuss these elements in more detail:

[0033] a. Remote loading and activation (no one is in the asset department);

[0034] b. The equipment supplier's deployment options;

[0035] c. Utilizing wireless methods, including RF or optical methods applicable to all Design Assurance Levels (DAL) or similar regulated design requirements;

[0036] d. Includes both configuration content and executable software;

[0037] e. Deployment, updates, remote deactivation, and removal of new software;

[0038] f. Security features to ensure updates originating from trusted sources; and

[0039] g. Onboard checksums and or equivalent quality / load assurance checks to confirm the integrity of software loading.

[0040] Figure 2 This is an exemplary illustration of a system 200 constructed and arranged according to an embodiment. Figure 2 middle, Figure 1 Aircraft 100 has been upgraded to include system 200 according to an embodiment. System 200 is configured to allow operators to remotely transfer software to an asset, such as aircraft 100, and initiate the software's fully autonomous execution in real time. In other words, system 200 enables remote loading and activation without human intervention; this is the ability to wirelessly send new software to aircraft 100 and activate the software without requiring a human to be on aircraft 100.

[0041] System 200 includes a data update module 202 configured to receive uploads of executable files within the FAA-regulated environment of aircraft 100. System 200 allows human operators 204, such as OEMs, integrators (e.g., airframe personnel), customers, system administrators, or any authorized operator, to create applications (or use third-party applications) on devices (e.g., laptops 205). Human operator 204 can transfer these applications to data update module 202. Data update module 202 is configured to receive and monitor critical aircraft system data 208 (explained in more detail below). In this example, software update 206 changes the way aircraft system data 208 is analyzed or reported.

[0042] Human operator 204 has numerous wireless communication paths through which software update 206 is transmitted to data update module 202. As an example and not a limitation, other suitable wireless means and standards may be used to transmit software update 206 to data update module 202, such as Bluetooth 210, satellite radio frequency (RF) communication 212, cloud-based 213, cellular 214, optical communication 216, WiFi / wireless access point 218 links, and others.

[0043] More specifically, in Figure 2 In this embodiment, human operator 204 transmits software update 206 to update module 202. Software update 206 may include configuration data, content, and / or executable software, which may include applications, algorithms, or various functions. In limited cases, configuration data and content have previously been transmitted to the aircraft and uploaded / activated without user intervention. However, executable software always requires human intervention at the aircraft to execute. This embodiment moves the executable software into a domain that excludes human intervention to automatically execute software update 206 at aircraft 100.

[0044] Different types of digital information can be sent to aircraft 100, which can loosely fall into the category of software. Therefore, for clarity, configuration data, content, and executable software will be explained below within the context of embodiments of the present invention.

[0045] As an example and not a limitation, the configuration data used in the context herein may include several types of reports generated by aircraft 100. The configuration will employ one of these reports for automatic transmission or manual retrieval from aircraft 100. Embodiments of the invention do not affect the functionality or content of these reports. Rather, regarding the configuration data, embodiments of the invention act as a software switch to control whether reports are transmitted from aircraft 100.

[0046] Examples of content within the context of this embodiment would be navigation databases (NDBs), etc. For background, an NDB includes elements for constructing flight plans and is typically updated every 28 days to ensure its accuracy. An NDB formed from data according to the ARINC 424 navigation system database standard is considered content that can be uploaded to and used by the data upload module 202.

[0047] Executable software is considered to be software that performs mathematical calculations, producing results that can be accessed in reports or through some human-machine interface. Embodiments of the present invention allow operators to create, remotely deploy to update module 202, and automatically activate executable software without any manual intervention.

[0048] Software update 206 does not need to be new. Instead, update 206 can be a new update to existing functionality (e.g., version 2, version 3 of existing software). That is, update 206 can overwrite or remove older software.

[0049] Using wireless RF and optical communication methods Figure 2 The 200 system applies to all Software Critical Levels (AEs) associated with the DO-178 guideline for the certification process of airborne systems and equipment. These Software Critical Levels are commonly referred to as DALs.

[0050] In another example, the data update module 202 can be remotely activated and deactivated. That is, the data update module 202 communicates with the application currently running on aircraft 100, which may be temporarily deactivated and potentially reactivated later. This feature is particularly useful in cases where a user has received notification of an update but has reason to believe the update may be fraudulent or contain malicious code. Remote activation / deactivation allows the user to deactivate a new update until further verification is possible.

[0051] Figure 3 According to the embodiments Figure 2A more detailed illustration of an exemplary data update module 202 is provided. The data update module 202 includes computer logic for performing the steps of receiving a software update file 300, performing security check logic 302, and performing software execution steps 304.

[0052] In this embodiment, when a wireless transmission of software update 206 occurs, the update is received as input to data update module 202, as verified by file receiving logic step 300. If the source of the transmission (i.e., human operator 204) passes appropriate security checks and verifications, software update 206 undergoes security verification and validation at security check logic 302.

[0053] Security check logic 302 is performed to protect aircraft 100 from the potentially catastrophic consequences of malware transmitted by malicious actors. Security check logic 302 includes a secure / trusted source verification sub-step 302a and a load assurance sub-step 302b, which will be discussed in detail below. In embodiments, the secure / trusted source verification sub-step 302a and the load assurance sub-step 302b occur automatically in sequence, without manual intervention or in a loop.

[0054] Security / Trusted Source Verification Sub-Step 302a from Reference Figure 2 This begins with the data update module 202. Specifically, the data update module 202 on the aircraft 100 has a secure, encrypted connection to ground systems (such as laptops 205, personal electronic devices 210, and cloud-based computing platforms 213). Figure 2 Each lightning bolt in the image enters the aircraft 100, and each lightning bolt includes an image of a lock, which includes end-to-end encryption from the corresponding ground system to the data update module 202.

[0055] This end-to-end encryption provides a secure tunnel through which transactions can occur. Figure 3 The secure / trusted source verification sub-step 302a is provided in the data update module 202, which is capable of verifying whether any source transmitting software to the aircraft 100 is authorized to do so and has the appropriate credentials to send the software. For example, authorization (i.e., appropriate) credentials (e.g., license) can be pre-loaded onto a storage device, similar to a Subscriber Identity Module (SIM) card used in a mobile phone. A SIM card, similar to a storage device, can be inserted into the data update module 202 before initiating the software update.

[0056] Load assurance check step 302b ensures that the information initially transmitted to data update module 202 (i.e., data update 206) is actually received. For example, a checksum, hash function, or other type of digital data integrity verification function can be used to implement the load assurance check. A version of the cryptographic hash function will be used to calculate a portion of the received software update 206 for comparison with a check value provided by the transmission ground system or update source.

[0057] The purpose of the comparison is to ensure that the payload arrives completely intact and without errors during transmission. Once the load assurance check sub-step 302b has completed its operation and confirmed the load integrity, a software execution command is issued within the update module 202, and software update 206 begins immediately.

[0058] In this embodiment, most communication occurs from the ground (e.g., human operator 204) to aircraft 100, or from personal device 210 to aircraft 100, where new or updated software is being loaded. An alternative embodiment allows the data update module 202 on aircraft 100 to selectively respond with a verification or acknowledgment message 220, indicating that the software and all content have been verified.

[0059] Figure 4 This is an exemplary illustration of a deployment 400 of an embodiment of a single update module of the present invention in a hub configuration. The exemplary deployment 400 is for illustrative purposes only, as the invention is not limited to a single hub configuration. Figure 4 In this example, an exemplary deployment 400 is demonstrated using three of the most critical aircraft systems: the engine control unit (ECU) 402, the aircraft control unit (ACU) 404, and the auxiliary power unit (APU) 406.

[0060] In the exemplary deployment 400, human operator 204 uses laptop computer 205 to transmit software updates via a secure, encrypted connection to data update module 202 (on aircraft 100). In this example, data update module 202 acts as a single hub or front end for all software updates sent to each of ECU 402, ACU 404, and APU 406.

[0061] Figure 5 This is an exemplary illustration of deployment 500, which is an alternative deployment of multiple update modules that are respectively coupled to multiple aircraft systems.

[0062] An example deployment of 500 is similar to Figure 4 The deployment is 400, therefore, similar instances will not be repeated here. Figure 5 middle, Figure 4The data update module 200 is implemented three times (202a, 202b, 202c) to cover three systems: ECU 402, ACU 404, and APU 406. Therefore, in deployment 500, data update module 202a performs file reception, source verification, and load assurance checks, and provides a pathway to ECU 402; data update module 202b performs file reception, source verification, and load assurance checks for ACU 404; and data update module 202c performs file reception, source verification, and load assurance checks for APU 406.

[0063] Many other implementations of the data update module 202, including a variety of other implementations, are within the spirit and scope of this invention.

[0064] Figure 6 This is an exemplary illustration of a flowchart implementing an exemplary method 600 of an embodiment of the present invention. Figure 6 In method 600, starting with step 602, the communication link between the ground system and the data module is encrypted to form a secure tunnel. In step 604, when transmitting the update file, the data update module verifies the credentials of the source of the transmitted software. In step 606, a load assurance check is performed on a portion of the transmitted update file to confirm the integrity of the verified file. In step 608, when the file integrity is verified, the software update is immediately activated, without manual intervention.

[0065] Figure 7 A block diagram of security check logic 302 is shown, including a processor 702 with a specific architecture. This specific architecture is provided to the processor 702 via instructions and / or instructions 720 stored in a memory 704, which is included therein. The processor 702 can retrieve instructions 720 from a storage medium 718.

[0066] The storage medium 718 may be located at the same location as the security check logic 302, as shown in the figure, or it may be located elsewhere and communicatively coupled to the security check logic 302. The security check logic 302 may be a stand-alone programmable system or a programmable module located in a larger system. For example, the security check logic 302 may be integrated into or embedded in the data module 202.

[0067] The security check logic 302 may include one or more hardware and / or software components configured to acquire, decode, execute, store, analyze, distribute, evaluate, diagnose, and / or classify information. Furthermore, the security check logic 302 may include an input / output (I / O) module 714 configured to interface with multiple remote devices, such as a drive controller module for a frequency converter. The I / O module 714 may also interface with a switch matrix or bypass module. In one embodiment, the I / O module may include one or more data acquisition modules.

[0068] Processor 702 may include one or more processing devices or cores (not shown). In some embodiments, processor 702 may be multiple processors, each having one or more cores. Processor 702 may be configured to execute instructions fetched from memory 704 (i.e., from memory block 712, memory block 710, load assurance check module 708, or memory block security / trusted source verification module 706). Instructions may be fetched from storage medium 718 or from a remote device connected to security check logic 302 via communication interface 716.

[0069] Furthermore, without loss of generality, storage medium 718 and / or memory 704 may include volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, read-only, random access, or any type of non-transitory computer-readable computer medium. Storage medium 718 and / or memory 704 may include programs and / or other information that can be used by processor 702.

[0070] Furthermore, storage medium 718 can be configured to record data processed, recorded, or collected during the operation of security check logic 302. For example, storage medium 718 can store historical patterns and predetermined thresholds for each measurable variable associated with security check logic 302. Data can be timestamped, location-stamped, cataloged, indexed, or organized in various ways consistent with data storage practices.

[0071] In one embodiment, memory block 706 may be a security / trusted source verification module, and memory block 708 may be a load assurance check module. Therefore, security check logic 302 can obtain instructions from these modules, which, when executed by processor 702, cause processor 702 to perform certain operations.

[0072] For example, operation may include receiving status data from a control unit coupled to safety check logic 302 via multiple sensors of the I / O module 714. Further operation may include performing diagnostic tests on the status data and subsequently instructing the control unit's driver to modify the control scheme of the control unit based on the results of the diagnostic tests. For example, instructions may be sent via communication interface 716.

[0073] Status data may include measurements associated with at least one of the following: the temperature of one avionics system sensed by the control unit, the vibration signal of another avionics system, and the isolation integrity of a third related system. Diagnostic testing may include comparing the status data with historical patterns or predetermined thresholds, or both, based on information stored in storage medium 718.

[0074] Figure 8 This is an exemplary software management module 800 constructed according to an embodiment. The following elements (h)-(l) are several examples of software management tasks that can be performed by the software management module 800 according to the embodiment. This document will focus on... Figure 8-10 To address these tasks in more detail.

[0075] h. The applications currently running in the remote query system;

[0076] i. Device self-reporting updates / changes;

[0077] j. Real-time configuration / report creation; and

[0078] k. Automatically send configurable levels of error reports and log files upon connection.

[0079] In this embodiment, when a software management task, such as tasks (h)-(l) described above, is delivered, communication is received as input to the software management module 800, as verified by the software management task receiving logic step 802. If the source of the task (i.e., human operator 204) has passed appropriate security checks and been verified, the software management task step 802 performs security verification and validation at security check logic 302. The security check logic 302 in the software management module 800 is related to... Figure 3 The data update module 202 shown is the same, and its detailed description is available with reference to the data update module 202. Therefore, the details of the security check logic 302 will not be repeated here.

[0080] The elements (h)-(l) addressed in the following further details are examples of unrestricted tasks that can be performed by the software management module 800.

[0081] In a prominent example, the software management module 800 is a mechanism of the ground system that automatically or upon user request sends messages (i.e., communications) to the aircraft (e.g., aircraft 100) via the various wireless communication media discussed above. This message may request information related to the aircraft's software applications. Figure 8 In an exemplary embodiment, the software management module 800 includes computer logic for performing the steps of receiving an initial software management task 802, executing security check logic 302, and executing the software management task in logic step 804.

[0082] The software management module 800 can also be configured to provide various types of self-reporting of software updates and / or program changes. That is, the software management module 800 can provide status reports when any software or program changes occur to user-selectable applications (e.g., features or dial-up) on the user-selectable system. For example, when a software update (e.g., via the software update module 202) is received, and / or when software is activated / deactivated, the software management module 800 will periodically send a status report or alert to the user or ground system. The status report or alert conveys the status of the software application (i.e., what software is loaded, what has been updated, what is activated / deactivated, etc.).

[0083] In one scenario, a user may request reporting of software or flight procedure changes for a specific LRU or LRU function. In other scenarios, a user may request to be informed of these changes in real time or while the aircraft 100 is in flight. Different systems and different users may have different self-reporting rules. Therefore, the software management module 800 can be preset or reconfigured to accommodate these different rules.

[0084] In another exemplary embodiment, the software management module 800 facilitates the generation or creation of real-time configuration reports. That is, the aircraft 100, through the software management module 800, is able to communicate onboard with users or ground systems by creating data that includes measurement data (e.g., data collected from sensors) or processed data (i.e., data calculated from the measurement data). Processed data can also be generated by human input of the measurement data (e.g., input from the crew).

[0085] Aircraft 100 can bundle this real-time information into near real-time reports and provide these reports to users or ground systems while aircraft 100 is still in flight. In one example, aircraft 100 can be configured to begin providing these real-time reports when a user or ground system suspects a potential equipment malfunction. That is, via software management module 800, one or more systems on aircraft 100 can be instructed (e.g., via activation commands) to begin recording data associated with selected parameters during flight. Alternatively, these features can be activated when aircraft 100 is on the ground. In a ground example, aircraft 100 might be a door or pylon, with avionics powered but engines off.

[0086] The software management module 800 provides configurable levels of error reporting and log files, which are automatically sent upon connection to a wireless network. As described above, the software management module 800 establishes network connections through various media, including cellular, Wi-Fi, and satellite communications. These network connections generate various statuses and network communication metrics related to network connection quality.

[0087] For example, various indicators relate to the presence of errors connecting to the ground system; the specific communication channel where the error exists; whether the system itself is error-free; which applications are functioning correctly, and so on. The software management module 800 can be configured to select the appropriate type and level of these reports and send them to the user or ground system at a specific time. Alternatively, all reports can be delivered as early as possible, or postponed to a later date based on a programmable, selectable operational status.

[0088] Figure 9 This is an exemplary illustration of a deployment 900 of an embodiment of a single software management module 800 of the present invention in a hub configuration for providing services to one or more aircraft systems, similar to the one described above. Figure 4 .exist Figure 9 In the middle, as above Figure 4 As shown, human operator 204 uses laptop computer 205 to transmit software management tasks via a secure, encrypted connection to software management module 800 (on aircraft 100). In this example, software management module 800 acts as a single hub, front-end, or path for all software management tasks sent to each of ECU 402, ACU 404, and APU 406.

[0089] However, the software management module 800 is not limited to Figure 9 The hub configuration can be used for other deployment scenarios. (Above) Figure 5 The deployment shown is one such alternative deployment solution.

[0090] Figure 10 This is a flowchart illustrating an exemplary method 1000 for implementing an alternative embodiment of the present invention. Figure 10 In method 1000, starting with step 1002, the communication link between the ground system and the software management module is encrypted to form a secure tunnel. In step 1004, when transmitting the software management task file, the software management module verifies the credentials of the source transmitting the software management task. In step 1006, a load assurance check is performed on a portion of the transmitted management task file to confirm the integrity of the verified file. Once the file integrity is verified, the software management task is executed immediately in step 1008, without human intervention.

[0091] Those skilled in the art will understand that various adaptations and modifications of the above embodiments can be configured without departing from the scope and spirit of this disclosure. Therefore, it is understood that, within the scope of the appended claims, the teachings set forth in this disclosure, in addition to those specifically described herein, can also be practiced.

[0092] Further aspects of the invention are provided by way of the subject matter of the following clauses:

[0093] 1. A method for remotely transmitting a software management task of authenticated software from a source to a software management module on an asset via a wireless communication link, the method comprising: encrypting the communication link between the source and the software management module to form a secure tunnel; verifying the credentials of the source via the software management module when transmitting a software management task file; performing a load assurance check on a portion of the transmitted software management task file to confirm the integrity of the transmitted file when the credentials of the source are verified; and immediately executing the software management task when the file integrity is verified, the execution occurring automatically without human intervention.

[0094] 2. The method according to any of the preceding claims, wherein the source is a ground unit.

[0095] 3. The verification according to any of the preceding claims includes security / trusted source verification and load assurance checks.

[0096] 4. According to the method of any of the preceding claims, at least one software management module performs a safety check on all critical function control modules of the aircraft.

[0097] 5. In the method according to any of the preceding claims, each software management module forms a path to only one corresponding aircraft critical function control module.

[0098] 6. The method according to any of the preceding claims, wherein the load guarantee check includes at least one of a checksum and a hash function.

[0099] 7. The method according to any of the preceding claims further includes sending a verification message from the software management module, the verification message notifying the source of the final disposal of the software management task.

[0100] 8. The method according to any of the preceding claims, wherein the execution includes at least one of querying the currently running application, remotely activating / deactivating the application, and providing a self-report of device updates / changes.

[0101] 9. A tangible computer-readable medium storing computer-executable instructions that, if executed by a computing device, cause the computing device to remotely transmit a software management task of authenticated software from a source to a software management module on an asset via a wireless communication link, the method comprising: encrypting the communication link between the source and the software management module to form a secure tunnel; verifying the credentials of the source via the software management module when transmitting a software management task file; performing a load assurance check on a portion of the transmitted software management task file to confirm the integrity of the transmitted file when the credentials of the source are verified; and immediately executing the software management task when the file integrity is verified, the execution occurring automatically without human intervention.

[0102] 10. The tangible computer-readable medium according to any of the preceding claims, wherein the source is a ground unit.

[0103] 11. The tangible computer-readable medium according to any of the preceding claims, wherein the verification includes secure / trusted source verification and load assurance checks.

[0104] 12. The tangible computer-readable medium according to any of the preceding claims, wherein at least one software management module performs a safety check on all aircraft critical function control modules.

[0105] 13. In any of the preceding claims, each software management module forms a path to only one corresponding aircraft critical function control module.

[0106] 14. The tangible computer-readable medium according to any of the preceding claims, wherein the load guarantee check includes at least one of a checksum and a hash function.

[0107] 15. The tangible computer-readable medium according to any of the preceding claims further includes sending a verification message from the software management module, the verification message notifying the source of the final disposition of the software management task.

[0108] 16. The tangible computer-readable medium according to any of the preceding claims, wherein the execution includes at least one of querying a currently running application, remotely activating / deactivating an application, and providing a self-report of device updates / changes.

[0109] 17. A system for remotely transmitting a software management task of certified software from a source to an aircraft, the system comprising: a software management module configured to be located on the aircraft and receiving a file representing a software management task transmitted from the source; a wireless communication link forming an encrypted tunnel between the source and the software management module on the aircraft; wherein the software management module is configured to (i) verify credentials of the source when transmitting the software management task file; and (ii) perform a load assurance check on a portion of the transmitted update file to confirm the integrity of the transmitted file when the credentials of the source are verified; and wherein, upon verification of file integrity, the software management module immediately executes the software management task, the execution occurring automatically without human intervention.

[0110] 18. The system according to any of the preceding claims, wherein the source is a ground unit.

[0111] 19. The system according to any of the preceding claims, wherein the verification includes secure / trusted source verification.

[0112] 20. The system according to any of the preceding claims, wherein the load guarantee check includes at least one of a checksum and a hash function.

Claims

1. A method for remotely transmitting software management tasks of authentication software from a source to a software management module on an asset via a wireless communication link, characterized in that, The method includes: The wireless communication link between the source and the software management module is encrypted to form a secure tunnel; When transmitting software management task files, the credentials of the source are verified by the software management module, wherein the software management task files include executable software, and the verification is performed without human intervention. Upon verification of the credentials from the source, a portion of the transmitted software management task file undergoes a load assurance check to confirm the integrity of the transmitted software management task file; this process is performed without human intervention. Once the integrity of the file is verified, the transmitted software management task is executed immediately without human intervention.

2. The method according to claim 1, characterized in that, The source is a ground unit.

3. The method according to claim 1, characterized in that, The verification includes security / trusted source verification and load assurance checks.

4. The method according to claim 1, characterized in that, At least one software management module performs a safety check on all critical function control modules of the aircraft.

5. The method according to claim 1, characterized in that, Each software management module forms a path to only one corresponding aircraft critical function control module.

6. The method according to claim 1, characterized in that, The load guarantee check includes at least one of a checksum and a hash function.

7. The method according to claim 1, characterized in that, It further includes sending a verification message from the software management module, the verification message notifying the source of the final disposal of the software management task.

8. The method according to claim 1, characterized in that, The execution includes at least one of querying currently running applications, remotely activating / deactivating applications, and providing a self-report of device updates / changes.

9. A tangible computer-readable medium, characterized in that, The tangible computer-readable medium stores computer-executable instructions that, if executed by a computing device, cause the computing device to perform a method for remotely transmitting software management tasks of authentication software from a source to a software management module on an asset via a wireless communication link, the method comprising: The wireless communication link between the source and the software management module is encrypted to form a secure tunnel; When transmitting software management task files, the credentials of the source are verified by the software management module. The software management task files include executable software, and the verification is performed without human intervention. Upon verification of the credentials from the source, a portion of the transmitted software management task file undergoes a load assurance check to confirm the integrity of the transmitted software management task file; this process is performed without human intervention. Once the file integrity is verified, the transmitted software management task is executed immediately without human intervention.

10. The tangible computer-readable medium according to claim 9, characterized in that, The source is a ground unit.

11. The tangible computer-readable medium according to claim 9, characterized in that, The verification includes security / trusted source verification and load assurance checks.

12. The tangible computer-readable medium according to claim 9, characterized in that, At least one software management module performs a safety check on all critical function control modules of the aircraft.

13. The tangible computer-readable medium according to claim 9, characterized in that, Each software management module forms a path to only one corresponding aircraft critical function control module.

14. The tangible computer-readable medium according to claim 9, characterized in that, The load guarantee check includes at least one of a checksum and a hash function.

15. The tangible computer-readable medium according to claim 9, characterized in that, It further includes sending a verification message from the software management module, the verification message notifying the source of the final disposal of the software management task.

16. The tangible computer-readable medium according to claim 9, characterized in that, The execution includes at least one of querying currently running applications, remotely activating / deactivating applications, and providing a self-report of device updates / changes.

17. A system for remotely transferring software management tasks for authentication software from a source to an aircraft, characterized in that, The system includes: A software management module, configured to be located on the aircraft, and receiving a file representing the software management task transmitted from the source; A wireless communication link that forms an encrypted tunnel between the source and the software management module on the aircraft; The software management module is configured to (i) verify the credentials of the source when transmitting a software management task file, the software management task file including executable software, and the verification is performed without human intervention; and (ii) when the credentials of the source are verified, perform a load assurance check on a portion of the transmitted software management task file to confirm the integrity of the transmitted software management task file, the check being performed without human intervention; and When the integrity of the file is verified, the software management module immediately executes the transmitted software management task without human intervention.

18. The system according to claim 17, characterized in that, The source is a ground unit.

19. The system according to claim 17, characterized in that, The verification includes security / trusted source verification.

20. The system according to claim 17, characterized in that, The load guarantee check includes at least one of a checksum and a hash function.

Images