WO2018165981A1 - Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment - Google Patents

Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment Download PDF

Info

Publication number
WO2018165981A1
WO2018165981A1 PCT/CN2017/077113 CN2017077113W WO2018165981A1 WO 2018165981 A1 WO2018165981 A1 WO 2018165981A1 CN 2017077113 W CN2017077113 W CN 2017077113W WO 2018165981 A1 WO2018165981 A1 WO 2018165981A1
Authority
WO
WIPO (PCT)
Prior art keywords
unmanned aerial
aerial vehicle
navigation
operating system
control
Prior art date
Application number
PCT/CN2017/077113
Other languages
French (fr)
Inventor
Jiewen Yao
Vincent J. Zimmer
Rajesh Poornachandran
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Priority to PCT/CN2017/077113 priority Critical patent/WO2018165981A1/en
Publication of WO2018165981A1 publication Critical patent/WO2018165981A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0047—Navigation or guidance aids for a single aircraft
    • G08G5/0056—Navigation or guidance aids for a single aircraft in an emergency situation, e.g. hijacking
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0047—Navigation or guidance aids for a single aircraft
    • G08G5/0069—Navigation or guidance aids for a single aircraft specially adapted for an unmanned aircraft
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2201/00—UAVs characterised by their flight controls
    • B64U2201/10—UAVs characterised by their flight controls autonomous, i.e. by navigating independently from ground or air stations, e.g. by using inertial navigation systems [INS]

Abstract

Technologies for control of an unmanned aerial vehicle (UAV) include a UAV including a computing device having a processor and a trusted execution environment (TEE). The TEE may be executed by a converged security and manageability engine (CSME) of the computing device. The TEE determines whether to take control of the UAV from an operating system, for example in response to a watchdog reset event. In response to taking control, the TEE controls navigation of the UAV and the operating system is booted. The TEE may control the UAV based on a navigation plan from the operating system or a default control policy. The operating system sends a message requesting control of the UAV in response to booting, and then resumes control of the UAV. The operating system may control navigation of the UAV based on abstracted sensor data received from the TEE. Other embodiments are described and claimed.

Description

TECHNOLOGIES FOR FAST UNMANNED AERIAL VEHICLE STATE MIGRATION USING A TRUSTED EXECUTION ENVIRONMENT BACKGROUND
Drones, also known as unmanned aerial vehicles (UAVs) or unmanned aircraft systems (UASs) , are pilotless or remotely piloted aerial vehicles that may include varying degrees of autonomy. Typical drones may include an embedded computing platform for vehicle control and other functions. Drones are becoming increasingly popular for military, commercial, educational, recreational, and other applications.
Avionics and similar control systems typically include redundant computer systems to provide high reliability and/or fault tolerance. For example, the United States space shuttle orbiter included five hardware-identical general-purpose computers to perform spacecraft guidance, navigation, and control tasks. In a typical configuration, four of those computers acted as redundant primary computers and used a complex voting system to control vehicle functions. The fifth computer included a backup flight system and could be manually activated by shuttle crew in case of failure of the four primary computers.
BRIEF DESCRIPTION OF THE DRAWINGS
The concepts described herein are illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements.
FIG. 1 is a simplified block diagram of at least one embodiment of an unmanned aerial vehicle for fast vehicle state migration using a trusted execution environment；
FIG. 2 is a simplified block diagram of at least one embodiment of an environment that may be established by a computing device of the unmanned aerial vehicle of FIG. 1；
FIG. 3 is a simplified flow diagram of at least one embodiment of a method for unmanned aerial vehicle control that may be executed by the computing device of FIGS. 1-2； and
FIGS. 4A and 4B are a simplified flow diagram of at least one embodiment of a method for unmanned aerial vehicle control that may be executed by a trusted execution environment of the computing device of FIGS. 1-2.
DETAILED DESCRIPTION OF THE DRAWINGS
While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.
References in the specification to “one embodiment, ” “an embodiment, ” “an illustrative embodiment, ” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Additionally, it should be appreciated that items included in a list in the form of “at least one of A, B, and C” can mean (A) ； (B) ； (C) ； (Aand B) ； (Aand C) ； (B and C) ； or (A, B, and C) . Similarly, items listed in the form of “at least one of A, B, or C” can mean (A) ； (B) ； (C) ； (Aand B) ； (Aand C) ； (B and C) ； or (A, B, and C) .
The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device) .
In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.
Referring now to FIG. 1, in an illustrative embodiment, an unmanned aerial vehicle (UAV) 100 for fast state migration using a trusted execution environment includes a computing device 102 as well as one or more sensors 104 and motors 106. As described below, during operation the computing device 102 establishes an operating system and an isolated, tamper-resistant trusted execution environment (TEE) . During ordinary operation, the operating system controls navigation of the UAV 100, for example responding to user inputs provided via a UAV application. As described further below, the TEE may determine to take control of the UAV 100 from the operating system, for example in response to a software failure of the operating system or other failure event. The TEE takes control of navigation of the UAV 100, and while the TEE is in control the operating system may reboot or perform other remediation tasks. After resuming operation, the operating system may send a request to the TEE to take control of the UAV 100, and the operating system may then resume control of the UAV 100. The TEE may take control of the UAV 100 much more quickly than the time required for the computing device 102 to reset and/or for the operating system to reboot. Thus, the UAV 100 may provide improved fault tolerance and thereby improve vehicle safety and/or reliability. Additionally, fault tolerance may be provided by a TEE established using hardware that is independent from the processor used to execute the operating system. The UAV 100 may provide hardware-based fault tolerance without requiring fully redundant computing devices and thus may have reduced board space, reduced battery needs, reduced footprint for point of failure and synchronization, or otherwise reduced cost compared to other fault tolerant control systems.
The computing device 102 may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a computer, an embedded controller, an avionics system, a mobile computing device, a network appliance, a web appliance, a wearable computing device, a laptop computer, a  notebook computer, a tablet computer, a desktop computer, a workstation, a server, a distributed computing system, a processor-based system, and/or a consumer electronic device. As shown in FIG. 1, the computing device 102 illustratively includes a processor 120, an input/output subsystem 122, a memory 124, a data storage device 126, a communication subsystem 128, and/or other components and devices commonly found in embedded controller or similar computing device. Of course, the computing device 102 may include other or additional components, such as those commonly found in a mobile computing device (e.g., various input/output devices) , in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory 124, or portions thereof, may be incorporated in the processor 120 in some embodiments.
The processor 120 may be embodied as any type of processor capable of performing the functions described herein. The processor 120 may be embodied as a single or multi-core processor (s) , digital signal processor, microcontroller, or other processor or processing/controlling circuit. Similarly, the memory 124 may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory 124 may store various data and software used during operation of the computing device 102, such as operating systems, applications, programs, libraries, and drivers. The memory 124 is communicatively coupled to the processor 120 via the I/O subsystem 122, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor 120, the memory 124, and other components of the computing device 102. For example, the I/O subsystem 122 may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, platform controller hubs, integrated control circuitry, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc. ) and/or other components and subsystems to facilitate the input/output operations. In some embodiments, the I/O subsystem 122 may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor 120, the memory 124, and other components of the computing device 102, on a single integrated circuit chip.
The data storage device 126 may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and  circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. The communication subsystem 128 of the computing device 102 may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the computing device 102 and other remote devices over a network. The communication subsystem 128 may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, 
Figure PCTCN2017077113-appb-000001
WiMAX, 
Figure PCTCN2017077113-appb-000002
etc. ) to effect such communication.
As shown, the illustrative computing device 102 further includes a converged security and manageability engine (CSME) 130 and a hardware watchdog 132. The CSME 130 may be embodied as any hardware component (s) or circuitry capable of providing manageability and security-related services to the computing device 102. In particular, the CSME 130 may include a microprocessor, microcontroller, or other embedded controller capable of executing firmware and/or other code independently and securely from the processor 120. Thus, the CSME 130 may be used to establish a trusted execution environment and/or trusted data storage for the computing device 102. The CSME 130 may communicate with the processor 120 and/or other components of the computing device 102 over a dedicated bus, such as a host embedded controller interface (HECI) . The CSME 130 may also provide remote configuration, control, or management of the computing device 102. Further, in some embodiments, the CSME 130 is also capable of communicating using the communication subsystem 128 or a dedicated communication circuit independently of the state of the computing device 102 (e.g., independently of the state of the main processor 120) , also known as “out-of-band” communication. Illustratively, the CSME 130 is incorporated in a system-on-a-chip (SoC) of the computing device 102. For example, the CSME 130 may be embodied as an IP core or other functional block of the I/O subsystem 122. Thus, the CSME 130 may provide a trusted execution environment for the computing device 102 with minimal extra cost. Additionally or alternatively, it should be understood that in some embodiments, the computing device 102 may include one or more additional components capable of establishing a trusted execution environment, such as a security engine, an out-of-band processor, a Trusted Platform Module (TPM) , and/or another security engine device or collection of devices.
The hardware watchdog 132 may be embodied as any timer or other circuit or component capable of determining whether the processor 120 is responsive and, if not, cause the processor 120 to reset. For example, as described further below, the processor 120 may execute a software task that periodically resets the hardware watchdog 132. In the event of a hardware or software crash of the processor 120, the periodic resets may cease. After a predetermined amount of time has expired without the hardware watchdog 132 being reset, the hardware watchdog 132 may cause the processor 120 to reset, which may allow the computing device 102 to recover from certain software failures. In some embodiments, the hardware watchdog 132 may also notify the CSME 130 that a hardware or software crash of the processor 120 has occurred, for example by sending an interrupt or other signal to the CSME 130. In some embodiments, the hardware watchdog 132 may send an interrupt to the CSME 130 and the CSME 130 may be responsible for resetting the processor 120.
As described above, the UAV 100 may further include one or more sensors 104 and one or more motors 106. The sensors 104 may be embodied as any environmental sensors or other devices used during navigation of the UAV 100. For example, the sensors 104 may include gyroscopes, accelerometers, altimeters, magnetometers or compasses, global positioning system receivers, cameras, proximity sensors, and/or other sensors. In some embodiments, the sensors 104 may include one or more sensor hubs or other soft sensors that generate sensor data that is calculated or otherwise derived using sensor fusion techniques based on sensor data generated by other sensors 104. Similarly, the motors 106 may be embodied as any motors, motor controllers, engines, or other actuators used to control navigation of the UAV 100. The motors 106 may include, for example, motors to drive one or more propellers of the UAV 100, jet engines to provide thrust, electric or hydraulic actuators to adjust control surfaces of the UAV 100, and/or other motors. Additionally, although illustrated as separate components from the computing device 102, it should be understood that in some embodiments one or more of the sensors 104 and/or the motors 106 may be included with the computing device 102 and/or one or more components of the computing device 102 in an SoC or other integrated circuit chip. As described further below, the CSME 130 may manage sensors 104 involved with UAV 100 navigation, thereby protecting the UAV 100 from potentially malicious software executed by the processor 120. As further described below, the CSME 130 may also take control of UAV 100  navigation (e.g., controlling the sensors 104 and motors 106) in response to a software or hardware failure event of the processor 120.
Referring now to FIG. 2, in an illustrative embodiment, the computing device 102 establishes an environment 200 during operation. The illustrative environment 200 includes a UAV application 202, an operating system 204, a watchdog unit 210, and a trusted execution environment (TEE) 212. As shown, the operating system 204 further includes a vehicle controller 206 and a failure response manager 208, and the TEE 212 further includes a migration manager 214, a failsafe vehicle controller 216, and a sensor unit 220. The various components of the environment 200 may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of the environment 200 may be embodied as circuitry or collection of electrical devices (e.g., vehicle controller circuitry 206, failure response manager circuitry 208, watchdog unit circuitry 210, migration manager circuitry 214, failsafe vehicle controller circuitry 216, and/or sensor unit circuitry 220) . It should be appreciated that, in such embodiments, one or more of the vehicle controller circuitry 206, the failure response manager circuitry 208, the watchdog unit circuitry 210, the migration manager circuitry 214, the failsafe vehicle controller circuitry 216, and/or the sensor unit circuitry 220 may form a portion of one or more of the processor 120, the I/O subsystem 122, and/or other components of the computing device 102. Additionally, in some embodiments, one or more of the illustrative components may form a portion of another component and/or one or more of the illustrative components may be independent of one another.
The UAV application 202 may be embodied as any user application, system application, or other computer program executed by the computing device 102 that directs navigation of the UAV 100. For example, the UAV application 202 may be embodied as a user-facing application that allows a user to direct navigation via remote control, via a predetermined navigation plan, or via another control scheme. As another example, the UAV application 202 may be embodied as an autonomous flight application. In some embodiments, the UAV application 202 may be compatible for execution by the TEE 212 for failover response.
The operating system 204 may be embodied as any operating system, virtual machine monitor, hypervisor, or other control structure of the computing device 102. The operating system 204 may execute the UAV application 202 and/or other applications, drivers, or computer programs that control navigation of the UAV 100. The operating system 204 and  related applications and drivers may be executed by the processor 120 of the computing device 102.
The TEE 212 may be embodied as any tamper-resistant execution environment that is isolated from the operating system 204. In the illustrative embodiment, the TEE 212 is an isolated execution environment established by the CSME 130. Because the CSME 130 includes a separate processor independent from the processor 120, the TEE 212 may be isolated from the operating system 204 and thus resistant to software and/or hardware faults that may crash the operating system 204. In other embodiments, the TEE 212 may be provided using any other isolated execution environment. For example, in some embodiments the TEE 212 may be embodied as a secure enclave established by the processor 120, such as a secure enclave established using
Figure PCTCN2017077113-appb-000003
SGX technology. As another example, in some embodiments the TEE 212 may be embodied as a secure world established by the processor 120, such as a secure world established using
Figure PCTCN2017077113-appb-000004
technology.
The watchdog unit 210 is configured to generate a watchdog reset event in response to a hardware crash, software crash, or other crash of the operating system 204. The watchdog unit 210 may use the hardware watchdog 132 to monitor for crashes. In some embodiments, the watchdog unit 210 may be configured to generate a watchdog reset event in response to a trigger event from the TEE 212, for example in response to a policy violation.
The vehicle controller 206 is configured to control navigation of the UAV 100 using the operating system 204 of the computing device 102. Controlling navigation of the UAV 100 may include sending a navigation plan to the TEE 212 that includes one or more navigation parameters for a prediction time period. Controlling navigation of the UAV 100 with the operating system 204 may also include controlling navigation based on abstracted sensor data received from the TEE 212. Accordingly, the sensor unit 220 of the TEE 212 is configured to send abstracted sensor data from one or more sensors 104 of the UAV 100 to the operating system 204. In some embodiments, the vehicle controller 206 may be further configured to receive, by the operating system 204, a navigation event log from the TEE 212 in response to sending a request to control the UAV 100.
The failure response manager 208 is configured to boot the operating system 204 in response to the TEE 212 determining to take control of the UAV 100. As described further below, the TEE 212 may take control of the UAV 100, for example, in response to a watchdog  reset event (e.g., in response to a software or hardware failure or other policy violation scenario) . The failure response manager 208 is further configured to send, by the operating system 204, a request to control the UAV 100 to the TEE 212 in response to booting the operating system 204. The vehicle controller 206 may be further configured to control navigation of the UAV 100 using the operating system 204 in response to sending the request to control the UAV 100.
The migration manager 214 is configured to determine whether to take control of the UAV 100. For example, the TEE 212 may take control of the UAV 100 in response to determining that a watchdog reset event of the operating system 204 has occurred, in response to failing to verify the authenticity of the operating system 204 with an attestation procedure, in response to determining that the geographic location of the UAV 100 has a predetermined relationship with a predetermined geographic region (e.g., is within the boundaries of a geo-fence) , in response to failing to validate a navigation plan provided by the operating system 204 with a remote management entity, and/or in response to violation of another predetermined vehicle policy.
The failsafe vehicle controller 216 is configured to control navigation of the UAV 100 using the TEE 212 in response to determining to take control of the UAV 100. The failsafe vehicle controller 216 may be configured to record the navigation event log by the TEE 212. The failsafe vehicle controller 216 may be configured to control navigation of the UAV 100 based on a navigation plan received from the operating system 204 and/or based on a default control policy 218. In some embodiments, the failsafe vehicle controller 216 may be further configured to disable one or more optional systems of the UAV 100 (e.g., video recording) to reduce power consumption of the UAV 100, for example to improve vehicle control.
Referring now to FIG. 3, in use, the computing device 102 may execute a method 300 for controlling the UAV 100. It should be appreciated that, in some embodiments, the operations of the method 300 may be performed by one or more components of the environment 200 of the computing device 102 as shown in FIG. 2. For example, the method 300 may be executed by the operating system 204, which may be executed by the processor 120. The method 300 begins in block 302, in which the computing device 102 comes out of a watchdog reset. The hardware watchdog 132 may reset the processor 120 in response to a hardware or software crash. Thus, the computing device 102 may come out of the watchdog reset while the UAV 100 is in flight or otherwise in use. After the watchdog reset, the computing device 102  may initialize the processor 120 and/or other components of the computing device 102 and otherwise prepare the computing device 102 to execute code. As described further below, the trusted execution environment (TEE) 212 controls navigation of the UAV 100 while the computing device 102 responds to the watchdog reset event.
In block 304, the computing device 102 boots the operating system 204. The computing device 102 may perform any appropriate boot sequence, including loading any necessary drivers, system processes, and/or application processes. In particular, the computing device 102 may load the UAV application 202 in order to control navigation of the UAV 100. As described further below, the TEE 212 may control navigation of the UAV 100 while the operating system 204 is booted, the UAV application 202 is loaded, and/or any other initialization is performed. In some embodiments, the computing device 102 may perform an ordinary boot sequence. Additionally or alternatively, in some embodiments the computing device 102 may perform one or more crash-recovery operations, such as patching the operating system 204 to eliminate software faults, restoring the previous state of the operating system 204 and/or the UAV application 202, or otherwise recovering from a crash. Further, although illustrated as booting the operating system 204 in response to a watchdog reset event, it should be understood that the operating system 204 may also be booted when powering on the computing device 102 or otherwise power-cycling the computing device 102.
After booting the operating system 204, in block 306, the operating system 204 sends a message to the TEE 212 requesting to take control of the UAV 100. The operating system 204 may use any technique to send the message. For example, the operating system 204 may send the message to the CSME 130 via a hardware bus such as the HECI bus or via a network connection. In some embodiments, in block 308 the operating system 204 performs an attestation procedure with the TEE 212. The attestation procedure allows the TEE 212 to verify that the operating system 204 is authentic, unmodified, or otherwise trustworthy. For example, the TEE 212 may verify one or more digital signatures of the operating system 204. As described further below, if the operating system 204 is not successfully authenticated, the TEE 212 may not allow the operating system 204 to take control of the UAV 100.
After sending the request to take control of the UAV 100, in block 310 the operating system 204 receives UAV state information from the TEE 212. The state information may include three-dimensional orientation information, navigation parameters, or other  information describing the current state of the UAV 100. In some embodiments, in block 312 the operating system 204 may receive a UAV event log from the TEE 212. The event log may record events (e.g., navigation parameters, sensor data, or other events) that occurred while the TEE 212 was in control of the UAV 100. The operating system 204 may replay or otherwise process the UAV event log to update the current state of the UAV 100. For example, the operating system 204 may update the state of the UAV application 202 based on the UAV event log.
In block 314, after sending the request to take control of the UAV 100, the operating system 204 controls navigation of the UAV 100. The operating system 204 may, for example, receive navigation commands from the UAV application 202 and then convert those commands to control signals for the motors 106 and/or sensors 104 of the UAV 100. The operating system 204 may base the control signals on sensor data generated by the sensors 104, such as motion data, altitude data, heading and/or location data, camera data, proximity data, or other sensor data. In block 316, the operating system 204 receives abstracted sensor data from the TEE 212. The TEE 212 receives sensor data from the sensors 104 and then passes sensor data to the operating system 204. The TEE 212 may pass sensor data with minimal or no processing, or in some embodiments the TEE 212 may generate abstracted sensor data and pass the abstracted sensor data to the operating system 204. The operating system 204 may not directly manage or otherwise communicate with the sensors 104. Because the TEE 212 is isolated and tamper-resistant, the operating system 204 may trust that the abstracted sensor data received from the TEE 212 has not been generated by malware or another malicious actor. Additionally, because the operating system 204 receives the abstracted sensor data from the TEE 212, there is no need for the operating system 204 to provide a dedicated synchronization thread or process to provide the sensor data to the TEE 212.
In block 318, the operating system 204 sends a heartbeat message to the hardware watchdog 132. The heartbeat message may be embodied as any message that resets the hardware watchdog 132 or otherwise prevents the hardware watchdog 132 from generating a watchdog reset event. The operating system 204 may send the heartbeat message periodically to indicate that the operating system 204 continues to control the UAV 100 and has not crashed. The watchdog timer interval may be small enough to allow for the TEE 212 to take control of the  UAV 100 in response to a crash of the operating system 204 and maintain flight safely. For example, the watchdog timer interval may be on the order of microseconds.
In block 320, the operating system 204 sends UAV state information to the TEE 212. The operating system 204 may send the state information to the TEE 212, for example, via the HECI bus to the CSME 130 or via a network connection. The state information may include navigation parameters, a navigation plan, sensor data, and/or other information on the current state of the UAV 100. The navigation plan represents the current control objectives for the UAV 100. The navigation plan may be embodied as one or more navigation parameters for the UAV 100, such as speed, direction, altitude, source location, destination location, or other parameters. In some embodiments, in block 322 the operating system 204 may send a navigation plan that has been determined for a prediction time period into the future. For example, the operating system 204 may predict changes in vehicle speed, direction, altitude, or destination location for the prediction time period. The prediction may be based on, for example, input received by the UAV application 202. The prediction time period may be embodied as any length of time, and in many embodiments, the prediction time period may be longer than a length of time required to reboot the operating system 204. After sending the UAV state information, including the UAV navigation plan, to the TEE 212, the method 300 loops back to block 314 to continue controlling navigation of the UAV 100. The computing device 102 may continue to execute the method 300 until a watchdog reset event occurs, after which the method 300 restarts at block 302.
Referring now to FIGS. 4A and 4B, in use, the computing device 102 may execute a method 400 for controlling the UAV 100. It should be appreciated that, in some embodiments, the operations of the method 400 may be performed by one or more components of the environment 200 of the computing device 102 as shown in FIG. 2. For example, the method 400 may be executed by the trusted execution environment (TEE) 212, which may be executed by the CSME 130. The method 400 begins in block 402, in which the TEE 212 receives UAV state information from the operating system 204. The operating system 204 is executed by the processor 120, and the TEE 212 is executed concurrently by the CSME 130. As described above in connection with FIG. 3, during normal operation of the UAV 100, the operating system 204 controls navigation of the UAV 100 and repeatedly sends UAV state information to the TEE 212. As described above, the UAV state information includes a navigation plan, which may be embodied as one or more navigation parameters for the UAV 100,  such as speed, direction, altitude, source location, destination location, or other parameters. The navigation plan may include forecasted data for a prediction time period. Thus, the TEE 212 receives the navigation plan while the operating system 204 executes normally and controls navigation of the UAV 100. The TEE 212 may store the navigation plan or otherwise update the UAV state maintained by the TEE 212 based on the navigation plan. The TEE 212 may store the UAV state information in secure storage.
In block 404, the TEE 212 provides abstracted sensor data to the operating system 204. As described above, the TEE 212 receives the sensor data from the sensors 104 and then passes sensor data to the operating system 204. The TEE 212 may pass sensor data with minimal or no processing, or in some embodiments the TEE 212 may generate abstracted sensor data and pass the abstracted sensor data to the operating system 204. The TEE 212 may enumerate, control, and otherwise manage the sensors 104. As the TEE 212 abstracts the sensor data and provides the sensor data to the operating system 204, the TEE 212 may also maintain or otherwise update the three-dimensional navigation context of the UAV 100 or other UAV state information.
In block 406, the TEE 212 determines whether to take control of the UAV 100 from the operating system 204. The TEE 212 may determine to take control of the UAV 100 based on one or more safety, reliability, security, or other policy factors. In some embodiments, in block 408, the TEE 212 may monitor for a watchdog reset event generated by the hardware watchdog 132. The TEE 212 may take control of the UAV 100 in response to a watchdog reset event. As described above, the hardware watchdog 132 may reset the processor 120 in response to a hardware or software crash of the operating system 204. The TEE 212 may use any technique to monitor for the watchdog reset event, such as monitoring for an interrupt generated by the hardware watchdog 132 in response to a crash of the operating system 204. In some embodiments, the TEE 212 may also trigger a reboot of the operating system 204 or other remedial action (e.g., patching the operating system 204) in response to the watchdog reset event.
In some embodiments, in block 410 the TEE 212 may perform an attestation procedure with the operating system 204. As describe above, the attestation procedure allows the TEE 212 to verify that the operating system 204 is authentic, unmodified, or otherwise trustworthy. For example, the TEE 212 may verify one or more digital signatures of the operating system 204. The TEE 212 may take control of the UAV 100 if the operating system  204 fails the attestation procedure. In some embodiments, if the UAV 100 fails the attestation procedure, the TEE 212 may perform one or more other policy-based actions such as grounding the UAV 100 to the nearest safe landing zone or alerting a remote administrator. Additionally, although illustrated as performing the attestation procedure while the operating system 204 is in control of the UAV 100, in some embodiments the TEE 212 may perform the attestation procedure at other times, such as in response to an initialization or power cycle of the computing device 102 or in response to a watchdog reset event.
In some embodiments, in block 412 the TEE 212 may evaluate a geo-fence policy. The geo-fence policy may define a geographic location in which manual control of the UAV 100 is not permitted, such as an airport, military installation, or other restricted location. The TEE 212 may analyze sensor data from the sensors 104 (e.g., global positioning system location data and/or inertial sensor location data) to determine whether the UAV 100 is within the geographic bounds of the geo-fence policy. The TEE 212 may take control of the UAV 100 if the UAV 100 is within the geographic bounds of the geo-fence policy.
In some embodiments, in block 414 the TEE 212 may validate the navigation plan received from the operating system 204 with a remote management entity. The remote management entity may use any policy or other criteria to validate the navigation plan. For example, the remote management entity may determine whether the navigation plan will take the UAV 100 into a restricted geographic location, similar to a geo-fence policy. As another example, the remote management entity may analyze the navigation plan for anomalies to determine whether the operating system 204 has crashed, been modified or compromised, or if the operating system 204 has otherwise been corrupted. The TEE 212 may take control of the UAV 100 if the navigation plan is not successfully validated by the remote management entity.
In block 416, the TEE 212 checks whether to take control of the UAV 100. If not, the method 400 loops back to block 402 to continue receiving the UAV state information while the operating system 204 remains in control of the UAV 100. If the TEE 212 determines to take control of the UAV 100, the method 400 advances to block 418.
In block 418, the TEE 212 controls navigation of the UAV 100. The TEE 212 may, for example, generate control signals for the motors 106 and/or sensors 104 of the UAV 100. The TEE 212 may base the control signals on sensor data received by the sensors 104, such as motion data, altitude data, heading and/or location data, camera data, proximity data, or other  sensor data. While the TEE 212 is in control of the UAV 100, the operating system 204 may reboot or otherwise recover from a crash as described above in connection with FIG. 3. Additionally or alternatively, in some embodiments, the operating system 204 may remain operational while the TEE 212 controls the UAV 100. For example, if the operating system 204 fails to be verified or if the UAV 100 violates a geo-fence policy, the TEE 212 may take control of the UAV 100 even though the operating system 204 remains operational.
In some embodiments, in block 420 the TEE 212 may follow the most recent UAV navigation plan received from the operating system 204 and/or from a remote administrator. For example, the TEE 212 may control the UAV 100 based on as one or more navigation parameters for the UAV 100 included in the navigation plan, such as speed, direction, altitude, source location, destination location, or other parameters. As described above, the navigation plan may cover a prediction time period after the TEE 212 takes control. After the prediction time period has expired, the TEE 212 may control the UAV 100 using the default control policy 218, as described further below.
In some embodiments, in block 422 the TEE 212 may perform automated collision avoidance based on sensor data received from the sensors 104. The collision avoidance may be performed while the TEE 212 also attempts to follow the navigation plan. In some embodiments, in block 424 the TEE 212 may record a UAV event log. The event log may record navigation parameters, sensor data, or other events that occur while the TEE 212 is in control of the UAV 100. The TEE 212 may store the UAV event log in secure storage associated with the TEE 212.
In block 426, the TEE 212 monitors for a message from the operating system 204 requesting control of the UAV 100. As described above in connection with FIG. 3, the operating system 204 may transmit the request after rebooting or otherwise recovering from a crash. The operating system 204 may use any technique to send the message. For example, the operating system 204 may send the message to the CSME 130 via a hardware bus such as the HECI bus or via a network connection. In block 428, the TEE 212 determines whether such a message has been received. The TEE 212 may also determine whether the operating system 204 has been successfully verified, for example by performing an attestation procedure as described above. If no message has been received (or if the operating system 204 has not been verified) , the method  branches to block 434, shown in FIG. 4B and described below. If a message requesting control of the UAV 100 has been received, the method 400 advances to block 430.
In block 430 the TEE 212 sends UAV state information to the operating system 204. As described above, the state information may include navigation parameters or other information describing the current state of the UAV 100. The TEE 212 may also send the UAV event log to the operating system 204. As described above, the operating system 204 may replay or otherwise process the UAV event log to update the current state of the UAV 100 based on events that occurred while the TEE 212 was in control of the UAV 100. In block 432, the TEE 212 stops controlling navigation of the UAV 100. As described above in connection with FIG. 3, the operating system 204 continues to control navigation of the UAV 100. After stopping, the method 400 loops back to block 402, in which the TEE 212 continues receiving the UAV state information while the operating system 204 remains in control of the UAV 100.
Referring back to block 428, if a request to take control of the UAV 100 is not received, the method 400 branches to block 434, shown in FIG. 4B. In block 434, the TEE 212 determines whether additional navigation plan information remains. In some embodiments, in block 436 the TEE 212 may determine whether the prediction time period associated with the navigation plan has expired since the TEE 212 took control of the UAV 100. Additional navigation plan information may not remain if the prediction time period has expired. In block 438, the TEE 212 checks whether additional navigation plan information remains. If so, the method 400 loops back to block 418, shown in FIG. 4A, to continue controlling navigation of the UAV 100 based on the navigation plan. If no additional navigation plan remains, then the method 400 advances to block 440.
In block 440, the TEE 212 controls navigation of the UAV 100 using the default control policy 218. The TEE 212 may be pre-configured with the default control policy 218. The default control policy 218 indicates one or more navigation actions that should be performed by the UAV 100 when no additional navigation plan exists and the operating system 204 is not in control of the UAV 100. For example, the default control policy 218 may call for the UAV 100 to hold its current position, navigate to its start position, or navigate to a predetermined geographic location. The predetermined geographic location may be, for example, a predetermined location for lost UAVs. In some embodiments, in block 442 the default control policy 218 may be based on one or more machine learning algorithms. For example, the default  control policy 218 may be based on the observed behavior of many UAVs 100 in similar circumstances. The machine learning algorithm may be performed by the computing device 102 or by a remote system such as a cloud computing service. After identifying the default control policy 218, the method 400 loops back to block 418, shown in FIG. 4A, to continue controlling navigation of the UAV 100 based on the default control policy 218.
It should be appreciated that, in some embodiments, the methods 300 and/or 400 may be embodied as various instructions stored on a computer-readable media, which may be executed by the processor 120, the I/O subsystem 122, the CSME 130, and/or other components of a computing device 102 to cause the computing device 102 to perform the respective method 300 and/or 400. The computer-readable media may be embodied as any type of media capable of being read by the computing device 102 including, but not limited to, the memory 124, the data storage device 126, firmware devices, and/or other media.
EXAMPLES
Illustrative examples of the technologies disclosed herein are provided below. An embodiment of the technologies may include any one or more, and any combination of, the examples described below.
Example 1 includes a computing device for unmanned aerial vehicle control, the computing device comprising: a vehicle controller to control navigation of an unmanned aerial vehicle with an operating system of the computing device； a trusted execution environment, wherein the trusted execution environment comprises: a migration manager to determine whether to take control of the unmanned aerial vehicle； and a failsafe vehicle controller to control navigation of the unmanned aerial vehicle with the trusted execution environment in response to a determination to take control of the unmanned aerial vehicle； and a failure response manager to (i) boot the operating system in response to the determination to take control of the unmanned aerial vehicle, and (ii) send, by the operating system, a request to control the unmanned aerial vehicle to the trusted execution environment in response to booting of the operating system； wherein to control navigation of the unmanned aerial vehicle with the operating system further comprises to control navigation of the unmanned aerial vehicle in response to sending of the request to control the unmanned aerial vehicle.
Example 2 includes the subject matter of Example 1, and wherein: to determine whether to take control of the unmanned aerial vehicle comprises to determine whether a watchdog reset event of the operating system has occurred； and to boot the operating system comprises to boot the operating system in response to the watchdog reset event.
Example 3 includes the subject matter of any of Examples 1 and 2, and further comprising a watchdog unit to generate the watchdog reset event in response to a crash of the operating system.
Example 4 includes the subject matter of any of Examples 1-3, and wherein: the vehicle controller is further to receive, by the operating system, a navigation event log from the trusted execution environment in response to the sending of the request to control the unmanned aerial vehicle； and to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to record the navigation event log by the trusted execution environment.
Example 5 includes the subject matter of any of Examples 1-4, and wherein: to control navigation of the unmanned aerial vehicle with the operating system comprises to send a navigation plan to the trusted execution environment, wherein the navigation plan comprises a navigation parameter for a prediction time period； and to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to control navigation of the unmanned aerial vehicle based on the navigation plan.
Example 6 includes the subject matter of any of Examples 1-5, and wherein the navigation parameter comprises a vehicle speed, a vehicle direction, a vehicle altitude, or a vehicle destination.
Example 7 includes the subject matter of any of Examples 1-6, and wherein to determine whether to take control of the unmanned aerial vehicle comprises to validate the navigation plan with a remote management entity.
Example 8 includes the subject matter of any of Examples 1-7, and wherein to control navigation of the unmanned aerial vehicle with the trusted execution environment further comprises to: determine whether the prediction time period associated with the navigation parameter has expired； and control navigation of the unmanned aerial vehicle based on a default control policy in response to a determination that the prediction time period associated with the navigation parameter has expired.
Example 9 includes the subject matter of any of Examples 1-8, and wherein to control navigation of the unmanned aerial vehicle based on the default control policy comprises to hold position of the unmanned aerial vehicle.
Example 10 includes the subject matter of any of Examples 1-9, and wherein to control navigation of the unmanned aerial vehicle based on the default control policy comprises to return to a start position of the unmanned aerial vehicle.
Example 11 includes the subject matter of any of Examples 1-10, and wherein to control navigation of the unmanned aerial vehicle based on the default control policy comprises to navigate to a predetermined location.
Example 12 includes the subject matter of any of Examples 1-11, and wherein to control navigation of the unmanned aerial vehicle based on the default control policy comprises to select the default control policy with a machine learning algorithm.
Example 13 includes the subject matter of any of Examples 1-12, and wherein: the trusted execution environment further comprises a sensory unit to send abstracted sensor data from one or more sensors of the unmanned aerial vehicle to the operating system； wherein to control navigation of the unmanned aerial vehicle with the operating system comprises to control navigation of the unmanned aerial vehicle by the operating system with the abstracted sensor data.
Example 14 includes the subject matter of any of Examples 1-13, and wherein to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to control navigation of the unmanned aerial vehicle by the trusted execution environment with sensor data from one or more sensors of the unmanned aerial vehicle.
Example 15 includes the subject matter of any of Examples 1-14, and wherein to determine whether to take control of the unmanned aerial vehicle comprises to verify the authenticity of the operating system with an attestation procedure.
Example 16 includes the subject matter of any of Examples 1-15, and wherein to determine whether to take control of the unmanned aerial vehicle comprises to determine whether a geographic location of the unmanned aerial vehicle has a predetermined relationship with a predetermined geographic region.
Example 17 includes the subject matter of any of Examples 1-16, and wherein the unmanned aerial vehicle comprises the computing device.
Example 18 includes the subject matter of any of Examples 1-17, and wherein the trusted execution environment comprises an execution environment that is isolated from the operating system of the computing device.
Example 19 includes the subject matter of any of Examples 1-18, and wherein the computing device comprises a processor to execute the operating system and a converged security and manageability engine to execute the trusted execution environment.
Example 20 includes the subject matter of any of Examples 1-19, and wherein: to control navigation of the unmanned aerial vehicle with the operating system comprises to execute an unmanned aerial vehicle application with the operating system； and to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to execute the unmanned aerial vehicle application with the trusted execution environment.
Example 21 includes the subject matter of any of Examples 1-20, and wherein the failsafe vehicle controller is further to disable an optional system of the unmanned aerial vehicle to reduce power consumption of the unmanned aerial vehicle in response to control of navigation of the unmanned aerial vehicle with the trusted execution environment.
Example 22 includes the subject matter of any of Examples 1-21, and wherein to determine whether to take control of the unmanned aerial vehicle comprises to determine whether a predetermined vehicle policy has been violated.
Example 23 includes a method for unmanned aerial vehicle control, the method comprising: controlling, a computing device, navigation of an unmanned aerial vehicle with an operating system of the computing device； determining, by a trusted execution environment of the computing device, whether to take control of the unmanned aerial vehicle； controlling, by the computing device, navigation of the unmanned aerial vehicle with the trusted execution environment in response to determining to take control of the unmanned aerial vehicle； booting, by the computing device, the operating system in response to determining to take control of the unmanned aerial vehicle； and sending, by the operating system, a request to control the unmanned aerial vehicle to the trusted execution environment in response to booting the operating system； wherein controlling navigation of the unmanned aerial vehicle with the operating system further comprises controlling navigation of the unmanned aerial vehicle in response to sending the request to control the unmanned aerial vehicle.
Example 24 includes the subject matter of Example 23, and wherein: determining whether to take control of the unmanned aerial vehicle comprises determining whether a watchdog reset event has occurred； and booting the operating system comprises booting the operating system in response to the watchdog reset event.
Example 25 includes the subject matter of any of Examples 23 and 24, and further comprising generating, by the computing device, the watchdog reset event in response to a crash of the operating system.
Example 26 includes the subject matter of any of Examples 23-25, and further comprising: receiving, by the operating system, a navigation event log from the trusted execution environment in response to sending the request to control the unmanned aerial vehicle； wherein controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises recording the navigation event log by the trusted execution environment.
Example 27 includes the subject matter of any of Examples 23-26, and wherein: controlling navigation of the unmanned aerial vehicle with the operating system comprises sending a navigation plan to the trusted execution environment, wherein the navigation plan comprises a navigation parameter for a prediction time period； and controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises controlling navigation of the unmanned aerial vehicle based on the navigation plan.
Example 28 includes the subject matter of any of Examples 23-27, and wherein the navigation parameter comprises a vehicle speed, a vehicle direction, a vehicle altitude, or a vehicle destination.
Example 29 includes the subject matter of any of Examples 23-28, and wherein determining whether to take control of the unmanned aerial vehicle comprises validating the navigation plan with a remote management entity.
Example 30 includes the subject matter of any of Examples 23-29, and wherein controlling navigation of the unmanned aerial vehicle with the trusted execution environment further comprises: determining whether the prediction time period associated with the navigation parameter has expired； and controlling navigation of the unmanned aerial vehicle based on a default control policy in response to determining that the prediction time period associated with the navigation parameter has expired.
Example 31 includes the subject matter of any of Examples 23-30, and wherein controlling navigation of the unmanned aerial vehicle based on the default control policy comprises holding position of the unmanned aerial vehicle.
Example 32 includes the subject matter of any of Examples 23-31, and wherein controlling navigation of the unmanned aerial vehicle based on the default control policy comprises returning to a start position of the unmanned aerial vehicle.
Example 33 includes the subject matter of any of Examples 23-32, and wherein controlling navigation of the unmanned aerial vehicle based on the default control policy comprises navigating to a predetermined location.
Example 34 includes the subject matter of any of Examples 23-33, and wherein controlling navigation of the unmanned aerial vehicle based on the default control policy comprises selecting the default control policy using a machine learning algorithm.
Example 35 includes the subject matter of any of Examples 23-34, and further comprising: sending, by the trusted execution environment, abstracted sensor data from one or more sensors of the unmanned aerial vehicle to the operating system； wherein controlling navigation of the unmanned aerial vehicle with the operating system comprises controlling navigation of the unmanned aerial vehicle by the operating system using the abstracted sensor data.
Example 36 includes the subject matter of any of Examples 23-35, and wherein controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises controlling navigation of the unmanned aerial vehicle by the trusted execution environment using sensor data from one or more sensors of the unmanned aerial vehicle.
Example 37 includes the subject matter of any of Examples 23-36, and wherein determining whether to take control of the unmanned aerial vehicle comprises verifying the authenticity of the operating system with an attestation procedure.
Example 38 includes the subject matter of any of Examples 23-37, and wherein determining whether to take control of the unmanned aerial vehicle comprises determining whether a geographic location of the unmanned aerial vehicle has a predetermined relationship with a predetermined geographic region.
Example 39 includes the subject matter of any of Examples 23-38, and wherein the unmanned aerial vehicle comprises the computing device.
Example 40 includes the subject matter of any of Examples 23-39, and wherein the trusted execution environment comprises an execution environment that is isolated from the operating system of the computing device.
Example 41 includes the subject matter of any of Examples 23-40, and wherein the computing device comprises a processor to execute the operating system and a converged security and manageability engine to execute the trusted execution environment.
Example 42 includes the subject matter of any of Examples 23-41, and wherein: controlling navigation of the unmanned aerial vehicle with the operating system comprises executing an unmanned aerial vehicle application with the operating system； and controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises executing the unmanned aerial vehicle application with the trusted execution environment.
Example 43 includes the subject matter of any of Examples 23-42, and further comprising disabling an optional system of the unmanned aerial vehicle to reduce power consumption of the unmanned aerial vehicle in response to controlling navigation of the unmanned aerial vehicle with the trusted execution environment.
Example 44 includes the subject matter of any of Examples 23-43, and wherein determining whether to take control of the unmanned aerial vehicle comprises determining whether a predetermined vehicle policy has been violated.
Example 45 includes a computing device comprising: a processor； and a memory having stored therein a plurality of instructions that when executed by the processor cause the computing device to perform the method of any of Examples 23-44.
Example 46 includes one or more machine readable storage media comprising a plurality of instructions stored thereon that in response to being executed result in a computing device performing the method of any of Examples 23-44.
Example 47 includes a computing device comprising means for performing the method of any of Examples 23-44.
Example 48 includes a computing device for unmanned aerial vehicle control, the computing device comprising: means for controlling navigation of an unmanned aerial vehicle with an operating system of the computing device； means for determining, by a trusted execution environment of the computing device, whether to take control of the unmanned aerial vehicle； means for controlling navigation of the unmanned aerial vehicle with the trusted execution  environment in response to determining to take control of the unmanned aerial vehicle； means for booting the operating system in response to determining to take control of the unmanned aerial vehicle； and means for sending, by the operating system, a request to control the unmanned aerial vehicle to the trusted execution environment in response to booting the operating system； wherein the means for controlling navigation of the unmanned aerial vehicle with the operating system further comprises means for controlling navigation of the unmanned aerial vehicle in response to sending the request to control the unmanned aerial vehicle.
Example 49 includes the subject matter of Example 48, and wherein: the means for determining whether to take control of the unmanned aerial vehicle comprises means for determining whether a watchdog reset event has occurred； and the means for booting the operating system comprises means for booting the operating system in response to the watchdog reset event.
Example 50 includes the subject matter of any of Examples 48 and 49, and further comprising means for generating the watchdog reset event in response to a crash of the operating system.
Example 51 includes the subject matter of any of Examples 48-50, and further comprising: means for receiving, by the operating system, a navigation event log from the trusted execution environment in response to sending the request to control the unmanned aerial vehicle； wherein the means for controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises means for recording the navigation event log by the trusted execution environment.
Example 52 includes the subject matter of any of Examples 48-51, and wherein: the means for controlling navigation of the unmanned aerial vehicle with the operating system comprises means for sending a navigation plan to the trusted execution environment, wherein the navigation plan comprises a navigation parameter for a prediction time period； and the means for controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises means for controlling navigation of the unmanned aerial vehicle based on the navigation plan.
Example 53 includes the subject matter of any of Examples 48-52, and wherein the navigation parameter comprises a vehicle speed, a vehicle direction, a vehicle altitude, or a vehicle destination.
Example 54 includes the subject matter of any of Examples 48-53, and wherein the means for determining whether to take control of the unmanned aerial vehicle comprises means for validating the navigation plan with a remote management entity.
Example 55 includes the subject matter of any of Examples 48-54, and wherein the means for controlling navigation of the unmanned aerial vehicle with the trusted execution environment further comprises: means for determining whether the prediction time period associated with the navigation parameter has expired； and means for controlling navigation of the unmanned aerial vehicle based on a default control policy in response to determining that the prediction time period associated with the navigation parameter has expired.
Example 56 includes the subject matter of any of Examples 48-55, and wherein the means for controlling navigation of the unmanned aerial vehicle based on the default control policy comprises means for holding position of the unmanned aerial vehicle.
Example 57 includes the subject matter of any of Examples 48-56, and wherein the means for controlling navigation of the unmanned aerial vehicle based on the default control policy comprises means for returning to a start position of the unmanned aerial vehicle.
Example 58 includes the subject matter of any of Examples 48-57, and wherein the means for controlling navigation of the unmanned aerial vehicle based on the default control policy comprises means for navigating to a predetermined location.
Example 59 includes the subject matter of any of Examples 48-58, and wherein the means for controlling navigation of the unmanned aerial vehicle based on the default control policy comprises means for selecting the default control policy using a machine learning algorithm.
Example 60 includes the subject matter of any of Examples 48-59, and further comprising: means for sending, by the trusted execution environment, abstracted sensor data from one or more sensors of the unmanned aerial vehicle to the operating system； wherein the means for controlling navigation of the unmanned aerial vehicle with the operating system comprises means for controlling navigation of the unmanned aerial vehicle by the operating system using the abstracted sensor data.
Example 61 includes the subject matter of any of Examples 48-60, and wherein the means for controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises means for controlling navigation of the unmanned aerial vehicle by the  trusted execution environment using sensor data from one or more sensors of the unmanned aerial vehicle.
Example 62 includes the subject matter of any of Examples 48-61, and wherein the means for determining whether to take control of the unmanned aerial vehicle comprises means for verifying the authenticity of the operating system with an attestation procedure.
Example 63 includes the subject matter of any of Examples 48-62, and wherein the means for determining whether to take control of the unmanned aerial vehicle comprises means for determining whether a geographic location of the unmanned aerial vehicle has a predetermined relationship with a predetermined geographic region.
Example 64 includes the subject matter of any of Examples 48-63, and wherein the unmanned aerial vehicle comprises the computing device.
Example 65 includes the subject matter of any of Examples 48-64, and wherein the trusted execution environment comprises an execution environment that is isolated from the operating system of the computing device.
Example 66 includes the subject matter of any of Examples 48-65, and wherein the computing device comprises a processor to execute the operating system and a converged security and manageability engine to execute the trusted execution environment.
Example 67 includes the subject matter of any of Examples 48-66, and wherein: the means for controlling navigation of the unmanned aerial vehicle with the operating system comprises means for executing an unmanned aerial vehicle application with the operating system； and the means for controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises means for executing the unmanned aerial vehicle application with the trusted execution environment.
Example 68 includes the subject matter of any of Examples 48-67, and further comprising means for disabling an optional system of the unmanned aerial vehicle to reduce power consumption of the unmanned aerial vehicle in response to controlling navigation of the unmanned aerial vehicle with the trusted execution environment.
Example 69 includes the subject matter of any of Examples 48-68, and wherein the means for determining whether to take control of the unmanned aerial vehicle comprises means for determining whether a predetermined vehicle policy has been violated.

Claims (25)

  1. A computing device for unmanned aerial vehicle control, the computing device comprising:
    a vehicle controller to control navigation of an unmanned aerial vehicle with an operating system of the computing device；
    a trusted execution environment, wherein the trusted execution environment comprises:
    a migration manager to determine whether to take control of the unmanned aerial vehicle； and
    a failsafe vehicle controller to control navigation of the unmanned aerial vehicle with the trusted execution environment in response to a determination to take control of the unmanned aerial vehicle； and
    a failure response manager to (i) boot the operating system in response to the determination to take control of the unmanned aerial vehicle, and (ii) send, by the operating system, a request to control the unmanned aerial vehicle to the trusted execution environment in response to booting of the operating system；
    wherein to control navigation of the unmanned aerial vehicle with the operating system further comprises to control navigation of the unmanned aerial vehicle in response to sending of the request to control the unmanned aerial vehicle.
  2. The computing device of claim 1, further comprising:
    a watchdog unit to generate a watchdog reset event in response to a crash of the operating system；
    wherein to determine whether to take control of the unmanned aerial vehicle comprises to determine whether the watchdog reset event of the operating system has occurred； and
    wherein to boot the operating system comprises to boot the operating system in response to the watchdog reset event.
  3. The computing device of claim 1, wherein:
    the vehicle controller is further to receive, by the operating system, a navigation event log from the trusted execution environment in response to the sending of the request to control the unmanned aerial vehicle； and
    to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to record the navigation event log by the trusted execution environment.
  4. The computing device of claim 1, wherein:
    to control navigation of the unmanned aerial vehicle with the operating system comprises to send a navigation plan to the trusted execution environment, wherein the navigation plan comprises a navigation parameter for a prediction time period, wherein the navigation parameter comprises a vehicle speed, a vehicle direction, a vehicle altitude, or a vehicle destination； and
    to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to control navigation of the unmanned aerial vehicle based on the navigation plan.
  5. The computing device of claim 4, wherein to determine whether to take control of the unmanned aerial vehicle comprises to validate the navigation plan with a remote management entity.
  6. The computing device of claim 4, wherein to control navigation of the unmanned aerial vehicle with the trusted execution environment further comprises to:
    determine whether the prediction time period associated with the navigation parameter has expired； and
    control navigation of the unmanned aerial vehicle based on a default control policy in response to a determination that the prediction time period associated with the navigation parameter has expired.
  7. The computing device of claim 6, wherein to control navigation of the unmanned aerial vehicle based on the default control policy comprises:
    to hold position of the unmanned aerial vehicle；
    to return to a start position of the unmanned aerial vehicle； or
    to navigate to a predetermined location.
  8. The computing device of claim 6, wherein to control navigation of the unmanned aerial vehicle based on the default control policy comprises to select the default control policy with a machine learning algorithm.
  9. The computing device of any of claims 1-8, wherein:
    the trusted execution environment further comprises a sensory unit to send abstracted sensor data from one or more sensors of the unmanned aerial vehicle to the operating system；
    wherein to control navigation of the unmanned aerial vehicle with the operating system comprises to control navigation of the unmanned aerial vehicle by the operating system with the abstracted sensor data.
  10. The computing device of any of claims 1-8, wherein to control navigation of the unmanned aerial vehicle with the trusted execution environment comprises to control navigation of the unmanned aerial vehicle by the trusted execution environment with sensor data from one or more sensors of the unmanned aerial vehicle.
  11. The computing device of any of claims 1-8, wherein to determine whether to take control of the unmanned aerial vehicle comprises to verify the authenticity of the operating system with an attestation procedure.
  12. The computing device of any of claims 1-8, wherein to determine whether to take control of the unmanned aerial vehicle comprises to determine whether a geographic location of the unmanned aerial vehicle has a predetermined relationship with a predetermined geographic region.
  13. The computing device of any of claims 1-8, wherein the unmanned aerial vehicle comprises the computing device.
  14. The computing device of any of claims 1-8, wherein the trusted execution environment comprises an execution environment that is isolated from the operating system of the computing device.
  15. The computing device of any of claims 1-8, wherein the computing device comprises a processor to execute the operating system and a converged security and manageability engine to execute the trusted execution environment.
  16. A method for unmanned aerial vehicle control, the method comprising:
    controlling, a computing device, navigation of an unmanned aerial vehicle with an operating system of the computing device；
    determining, by a trusted execution environment of the computing device, whether to take control of the unmanned aerial vehicle；
    controlling, by the computing device, navigation of the unmanned aerial vehicle with the trusted execution environment in response to determining to take control of the unmanned aerial vehicle；
    booting, by the computing device, the operating system in response to determining to take control of the unmanned aerial vehicle； and
    sending, by the operating system, a request to control the unmanned aerial vehicle to the trusted execution environment in response to booting the operating system；
    wherein controlling navigation of the unmanned aerial vehicle with the operating system further comprises controlling navigation of the unmanned aerial vehicle in response to sending the request to control the unmanned aerial vehicle.
  17. The method of claim 16, wherein:
    determining whether to take control of the unmanned aerial vehicle comprises determining whether a watchdog reset event has occurred； and
    booting the operating system comprises booting the operating system in response to the watchdog reset event.
  18. The method of claim 16, further comprising:
    receiving, by the operating system, a navigation event log from the trusted execution environment in response to sending the request to control the unmanned aerial vehicle；
    wherein controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises recording the navigation event log by the trusted execution environment.
  19. The method of claim 16, wherein:
    controlling navigation of the unmanned aerial vehicle with the operating system comprises sending a navigation plan to the trusted execution environment, wherein the navigation plan comprises a navigation parameter for a prediction time period； and
    controlling navigation of the unmanned aerial vehicle with the trusted execution environment comprises controlling navigation of the unmanned aerial vehicle based on the navigation plan.
  20. The method of claim 19, wherein controlling navigation of the unmanned aerial vehicle with the trusted execution environment further comprises:
    determining whether the prediction time period associated with the navigation parameter has expired； and
    controlling navigation of the unmanned aerial vehicle based on a default control policy in response to determining that the prediction time period associated with the navigation parameter has expired.
  21. The method of claim 16, further comprising:
    sending, by the trusted execution environment, abstracted sensor data from one or more sensors of the unmanned aerial vehicle to the operating system；
    wherein controlling navigation of the unmanned aerial vehicle with the operating system comprises controlling navigation of the unmanned aerial vehicle by the operating system using the abstracted sensor data.
  22. The method of claim 16, wherein determining whether to take control of the unmanned aerial vehicle comprises verifying the authenticity of the operating system with an attestation procedure.
  23. A computing device comprising:
    a processor； and
    a memory having stored therein a plurality of instructions that when executed by the processor cause the computing device to perform the method of any of claims 16-22.
  24. One or more machine readable storage media comprising a plurality of instructions stored thereon that in response to being executed result in a computing device performing the method of any of claims 16-22.
  25. A computing device comprising means for performing the method of any of claims 16-22.
PCT/CN2017/077113 2017-03-17 2017-03-17 Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment WO2018165981A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/077113 WO2018165981A1 (en) 2017-03-17 2017-03-17 Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/077113 WO2018165981A1 (en) 2017-03-17 2017-03-17 Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment

Publications (1)

Publication Number Publication Date
WO2018165981A1 true WO2018165981A1 (en) 2018-09-20

Family

ID=63522817

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/077113 WO2018165981A1 (en) 2017-03-17 2017-03-17 Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment

Country Status (1)

Country Link
WO (1) WO2018165981A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013074843A1 (en) * 2011-11-15 2013-05-23 Insitu, Inc. Controlled range and payload for unmanned vehicles, and associated systems and methods
WO2016048177A1 (en) * 2014-09-26 2016-03-31 Intel Corporation Securely exchanging vehicular sensor information
WO2016087949A1 (en) * 2014-10-24 2016-06-09 King Abdullah University Of Science And Technology Flight envelope protection system for unmanned aerial vehicles
US20160274578A1 (en) * 2015-03-22 2016-09-22 Microsoft Technology Licensing, Llc Unmanned aerial vehicle piloting authorization

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013074843A1 (en) * 2011-11-15 2013-05-23 Insitu, Inc. Controlled range and payload for unmanned vehicles, and associated systems and methods
WO2016048177A1 (en) * 2014-09-26 2016-03-31 Intel Corporation Securely exchanging vehicular sensor information
WO2016087949A1 (en) * 2014-10-24 2016-06-09 King Abdullah University Of Science And Technology Flight envelope protection system for unmanned aerial vehicles
US20160274578A1 (en) * 2015-03-22 2016-09-22 Microsoft Technology Licensing, Llc Unmanned aerial vehicle piloting authorization

Similar Documents

Publication Publication Date Title
US10745127B2 (en) Systems and methods for execution of recovery actions on an unmanned aerial vehicle
EP2598993B1 (en) Providing application high availability in highly-available virtual machine environments
US8413144B1 (en) Providing application-aware high availability of virtual machines
Abdi et al. Preserving physical safety under cyber attacks
US9489274B2 (en) System and method for performing efficient failover and virtual machine (VM) migration in virtual desktop infrastructure (VDI)
EP3079063B1 (en) Flight control system command selection
US20140250320A1 (en) Cluster system
Abad et al. Reset-based recovery for real-time cyber-physical systems with temporal safety constraints
US11561868B1 (en) Management of microservices failover
US11893412B2 (en) Device initialization by an access-restricted virtual machine
WO2016172251A1 (en) Systems and methods for execution of recovery actions on an unmanned aerial vehicle
JP2010083480A (en) Method and system for restarting flight control system
US20130332751A1 (en) Power supply and program
US20200327023A1 (en) Redundant processing fabric for autonomous vehicles
WO2015104841A1 (en) Redundant system and method for managing redundant system
EP2784676A1 (en) DIMA extension health monitor supervisor
US20180322020A1 (en) Backup and recovery of configuration files in management device
Abdi et al. Restart-based fault-tolerance: System design and schedulability analysis
WO2018165981A1 (en) Technologies for fast unmanned aerial vehicle state migration using a trusted execution environment
US20180203718A1 (en) Shutting down of a virtual system
US20170344360A1 (en) Protecting firmware flashing from power operations
WO2019242133A1 (en) Software upgrading method in electronic device, apparatus and electronic device
Majumder et al. Reliable flight control system architecture for agile airborne platforms: an asymmetric multiprocessing approach
EP2691853B1 (en) Supervisor system resuming control
US20200326967A1 (en) Operating system modality switching in an autonomous vehicle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17901036

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17901036

Country of ref document: EP

Kind code of ref document: A1