TECHNICAL FIELD

The present subject matter is, in general, related to aerial vehicles, but not exclusively, to method and system for transforming a manned aerial vehicle into an unmanned aerial vehicle.

BACKGROUND

An aircraft autopilot equipped with multiple features and various autopilot related systems, integrated into a single system, is in general referred to as an Automatic Flight Control System (AFCS). Previously, the AFCS was found only on high-performance aircrafts. However, presently, due to advances in digital technology for an aircraft, modern aircrafts of any size may be equipped with AFCS. The AFCS significantly reduces workload during critical phases of flight. A two-axis autopilot system installed in most general aviation aircraft controls the pitch and roll of the aircraft. Also, the autopilot can operate independently, controlling heading and altitude, or it can be coupled to a navigation system and fly a programmed course or an approach with glideslope.

It may be further advantageous if the manned aircrafts having AFCS can be converted into an unmanned aircraft, since such an unmanned aircraft may be used for carrying out a wide range of applications. However, the conventional AFCS systems do not provide provisions for transformation of a manned aircraft into an unmanned aircraft. Also, the conventional AFCS do not provide an option of having optional pilot in the aircraft.

Hence, there is a need for a mechanism, which allows transformation of manned aircraft into an unmanned aircraft.

The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art. SUMMARY

Disclosed herein is a method for transforming a manned aerial vehicle into an unmanned aerial vehicle. The method comprises optimizing, by an automation system, stability, control and basic Autopilot (AP) functionalities of the aerial vehicle by analyzing one or more predetermined operations performed by an Onboard Pilot (OP) of the aerial vehicle. Further, the method comprises enabling an Internal Pilot (IP) and an External Pilot (EP) to operate the aerial vehicle based on the optimization, through a ground-based Ground Control Station (GCS) and a Flight Control Box (FCB) respectively. The IP remotely flies the aerial vehicle and the EP controls taking-off and landing of the aerial vehicle based on visual perception of the aerial vehicle. Thereafter, the method comprises testing Optionally Piloted Aircraft (OPA) functionalities and completely autonomous aerial operation of the aerial vehicle by the IP and the EP. Finally, the method comprises unmanning the aerial vehicle upon successful testing of the OPA functionalities and autonomous aerial operation of the vehicle by deboarding the OP from the aerial vehicle, for enabling a fully autonomous functioning of the aerial vehicle.

Further, the present disclosure relates to an automation system for transforming a manned aerial vehicle into an unmanned aerial vehicle. The automation system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processorexecutable instructions, which on execution, cause the processor to optimize control and basic Autopilot (AP) functionalities of the aerial vehicle by analyzing one or more predetermined operations performed by an Onboard Pilot (OP) of the aerial vehicle. Further, the instructions cause the processor to enable an Internal Pilot (IP) and an External Pilot (EP) to operate the aerial vehicle based on the optimization, through a ground-based Ground Control Station (GCS) and a Flight Control Box (FCB) respectively. The IP remotely flies the aerial vehicle and the EP controls taking-off and landing of the aerial vehicle based on visual perception of the aerial vehicle. Thereafter, the instructions cause the processor to test Optionally Piloted Aircraft (OPA) functionalities and completely autonomous aerial operation of the aerial vehicle by the IP and the EP. Finally, the instructions cause the processor to unman the aerial vehicle upon successful testing of the OPA functionalities and autonomous aerial operation of the vehicle by deboarding the OP from the aerial vehicle, for enabling a fully autonomous functioning of the aerial vehicle. The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which:

FIG. 1 illustrates an exemplary environment for transforming a manned aerial vehicle into an unmanned aerial vehicle in accordance with some embodiments of the present disclosure.

FIG. 2 shows a detailed block diagram of an automation system in accordance with some embodiments of the present disclosure.

FIGS. 3A-3C show flowcharts illustrating various phases involved in transforming a manned aerial vehicle into an unmanned aerial vehicle in accordance with some embodiments of the present disclosure.

FIG. 4 shows a flowchart illustrating a method of transforming a manned aerial vehicle into an unmanned aerial vehicle in accordance with some embodiments of the present disclosure.

FIG. 5 illustrates a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown. DETAILED DESCRIPTION

In the present document, the word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or implementation of the present subject matter described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.

The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises. . . a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

The present disclosure relates to a method and an automation system for transforming a manned aerial vehicle into an unmanned aerial vehicle. In an embodiment, the proposed method follows a multi-phase training approach to develop an Automatic Flight Control System (AFCS). The AFCS system may consist of Stability Augmentation System (SAS) and Control Augmentation System (CAS) loops, and basic pilot relief modes. The SAS/CAS may be used for correcting the deficiencies in the airframe.

In an embodiment, the AFCS system may be operated by an Onboard Pilot (OP), an Internal Pilot (IP) and an External Pilot (EP), wherein the IP may remotely fly the aerial vehicle from a ground station and the EP may take care of take-off and landing of the aerial vehicle using a Flight Control Box (FCB). Alternatively, the AFCS may assist the OP in take-off/landing and flying of the aerial vehicle using control sticks and Mode Select and Annunciator Panel (MSAP) configured in the aerial vehicle. Additionally, the proposed method may be used for testing an Optionally Piloted Aircraft (OPA) functionality and complete autonomous in-air operation of the aerial vehicle by the ground station. The aerial vehicle may be soft-landed by the EP for checking the landing functionality when there is an onboard pilot in the aerial vehicle. Eventually, the aerial vehicle may be unmanned, and the EP may take-off and handover the control of the aerial vehicle to the IP. The IP may accomplish an entire mission and finally handover the control back to the EP for manually landing the aerial vehicle. In addition, the aerial vehicle may be operated as a fully autonomous system with no pilot on board and maintaining the IP and the EP on a standby for recovery in case of emergencies or failures.

In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

FIG. 1 illustrates an exemplary environment for transforming a manned aerial vehicle 103 into an unmanned aerial vehicle 103 in accordance with some embodiments of the present disclosure.

In an embodiment, the environment 100 may include an automation system 101, an aerial vehicle 103, a Ground Control Station (GCS) 107 and a Flight Control Box (FCB) 111. In an implementation, the aerial vehicle 103 may be operated by a pilot, referred as an Onboard Pilot (OP) 105. The GCS 107 and the FCB 111 may be operated and/or controlled by an Internal Pilot (IP) 109 and an External Pilot (EP) 113 respectively.

In an implementation, the automation system 101 may be a part of Full Authority Digital Engine Controller (FADEC) or an Electronic Engine Controller (EEC) of the aerial vehicle 103, which are configured for controlling all aspects of the aerial vehicle 103 engine performance. In an alternative implementation, the automation system 101 may be a standalone, ground-based computing device, which may be operated by a trained individual for performing various functionalities discussed in the present disclosure. In another implementation, the automation system 101 may be an Automaic Flight Control System (AFCS), which helps in unmanning of aerial vehicle 103, for example, a two-seater general aviation aircraft with 900 kg All-Up Weight (AUW) for Medium Altitude Long Endurance (MALE) surveillance and reconnaissance applications. In an embodiment, the automation system 101 may be trained for incrementally developing and/or transforming a manned aerial vehicle into an unmanned and/or an optionally manned aerial vehicle.

In an embodiment, as an initial step of transforming the aerial vehicle 103, the automation system 101 may analyse each of one or more predetermined operations performed by the OP 105 of the aerial vehicle 103, during regular flight of the aerial vehicle 103 to assess whether the aerial vehicle 103 is functioning as per requirements. In an embodiment, the one or more predetermined operations may be analysed by comparing results of the one or more predetermined operations, obtained during regular flight of the aerial vehicle 103, with corresponding results that the aerial vehicle 103 is expected to produce as per the technical requirements of the aerial vehicle 103. If any errors or deviations are detected during the analysis, the automation step may facilitate rectification of such errors/deviations to optimize overall stability, control and basic Autopilot (AP) functionalities of the aerial vehicle 103, before unmanning the aerial vehicle 103.

In an embodiment, after optimizing the stability, control and AP functionalities of the aerial vehicle 103, the automation system 101 may enable the IP 109 and the EP 113 to operate the aerial vehicle 103. As an example, the IP 109 may control, operate or remotely fly the aerial vehicle 103 using the GCS 107. Similarly, the EP 113 may be enabled to control take-off and landing of the aerial vehicle 103 based on visual perception of the aerial vehicle 103, using the FCB 111. In an embodiment, both the GCS 107 and the FCB 111 may be ground-based computing systems, external to the aerial vehicle 103.

In the subsequent phase, the automation system 101 may test Optionally Piloted Aircraft (OPA) functionalities and completely autonomous aerial operations of the aerial vehicle 103 by assigning complete control of the aerial vehicle 103 to the IP 109 and the EP. At this stage, the OP 105 may be maintained as a stand-by pilot, who needs to take control of the aerial vehicle 103 only in case of emergencies and/or malfunctioning of any of the OPA functionalities or autonomous operations of the aerial vehicle 103.

After the OPA functionalities and complete autonomous aerial operations of the aerial vehicle 103 are successfully verified and completed, the automation system 101 may facilitate unmanning of the aerial vehicle 103 by deboarding the OP 105 from the aerial vehicle 103. At this stage, the aerial vehicle 103 is enabled for a fully autonomous functioning. Here, the EP 113 may be maintained as the stand-by pilot for taking over the control of the aerial vehicle 103 in case of emergencies/malfunctioning. Thus, the automation system 101 helps in unmanning the aerial vehicle 103 using a multi-phase approach as explained above.

FIG. 2 shows a detailed block diagram of an automation system 101 in accordance with some embodiments of the present disclosure.

In some implementations, the automation system 101 may include an I/O interface 201, a processor 203 and a memory 205. The I/O interface 201 may be configured for exchanging data and/or one or more instructions among a control unit of the aerial vehicle 103, and a Ground Control Station (GCS) 107 and a Flight Control Box (FCB) 111 associated with the aerial vehicle 103. The data and instructions being exchanged through the I/O Interface 201 may be related to one or more functionalities of the aerial vehicle 103. The memory 205 may be communicatively coupled to the I/O Interface 201 and the processor 203. In an embodiment, the memory 205 may store data 207 and one or more modules 209. The processor 203 may be configured to perform one or more functions of the automation system 101, necessary for transforming a manned aerial vehicle into an unmanned aerial vehicle.

In an embodiment, the data 207 stored in the memory 205 may include, without limitation, operational parameters 211, technical requirements 213 and other data 215. In some implementations, the data 207 may be stored within the memory 205 in the form of various data structures. Additionally, the data 207 may be organized using data models, such as relational or hierarchical data models. The other data 215 may include various temporary data and files generated by the one or more modules 209 while performing various functions of the automation system 101.

In an embodiment, the operational parameters 211 may be related to the one or more predetermined operations of the aerial vehicle 103, performed by the OP. As an example, the operational parameters 211 may include results and observations of manually flying the aerial vehicle 103 or engaging pilot relief modes on the aerial vehicle 103 for maintaining altitude, pitch altitude, airspeed, bank angle, course, climbing, descending and turning of the aerial vehicle 103. The operational parameters 211 may be used for assessing the functioning of the aerial vehicle 103 by comparing them with corresponding technical requirements 213 of the aerial vehicle 103. Further, rectifying any errors or deviations in the operational parameters

211 helps in optimizing stability, control and basic AP functionalities of the aerial vehicle 103.

In an embodiment, the technical requirements 213 may be associated with a technical specification of the aerial vehicle 103 for which the aerial vehicle 103 has been designed. For example, the technical requirements 213 of the aerial vehicle 103 may include, without limiting to, functional requirements, performance requirements, interface requirements, environmental requirements, regulatory requirements, reliability requirements, human factors engineering requirements and safety requirements of the aerial vehicle 103. In an embodiment, the overall requirements of the aerial vehicle 103 may be captured in requirements document.

The requirements document may be a real-time/live document and may contain all the necessary technical requirements 213 of the aerial vehicle 103. Here, the functional requirements may indicate what functions need to be performed by the aerial vehicle 103. Performance requirements indicate how well the functional requirements or functions of the aerial vehicle 103 need to be performed. Interface requirements indicate performance, physical and functional requirements associated with product interfaces. The environmental requirements indicate identification of environmental conditions in which the aerial vehicle 103 needs to be operated/stored. Regulatory requirements indicate requirements imposed by statutes or regulations, such as Federal Aviation Regulations (FAR) or military standards. Reliability requirements indicate whether the aerial vehicle 103 meets the required level of operation, as well as fault and/or fault tolerance of the aerial vehicle 103 for all expected environments and conditions. Human factors and engineering requirements identify requirements on human-system interfaces and interactions. Safety requirements define the effects of failure conditions, hazards and/or safety related functions of the aerial vehicle 103.

In an embodiment, the data 207 may be processed by the one or more modules 209 of the automation system 101. In some implementations, the one or more modules 209 may be communicatively coupled to the processor 203 for performing one or more functions of the automation system 101. In an implementation, the one or more modules 209 may include, without limiting to, an optimization module 217, a coordination module 219, a testing module 221, a control transfer module 223 and other modules 225.

As used herein, the term module may refer to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a hardware processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In an implementation, each of the one or more modules 209 may be configured as stand-alone hardware computing units. In an embodiment, the other modules 225 may be used to perform various miscellaneous functionalities of the automation system 101. It will be appreciated that such one or more modules 209 may be represented as a single module or a combination of different modules.

In an embodiment, the optimization module 217 may be configured for optimizing the stability, control and basic Autopilot (AP) functionalities of the aerial vehicle 103 by analysing the one or more predetermined operations of the aerial vehicle 103. Here, the optimization module 217 may compare results of the one or more predetermined operations with corresponding technical requirements 213 of the aerial vehicle 103 for identifying any errors/deviations in the regular functioning of the aerial vehicle 103 and may subsequently rectify the errors/deviations to optimize the various functions of the aerial vehicle 103.

In an embodiment, the coordination module 219 may be configured for ensuring a coordination between the OP, the IP 109 and the EP 113 of the aerial vehicle 103 during various phases of unmanning the aerial vehicle 103. For instance, the coordination module 219 may be used for enabling the IP 109 and the EP 113 to operate the aerial vehicle 103 through ground-based GCS 107 and FCB 111 respectively. Also, the coordination module 219 ensures that the OP 105 is maintained as a stand-by pilot while IP 109 and OP 105 are operating/controlling the aerial vehicle 103.

In an embodiment, the testing module 221 may be configured for testing the Optionally Piloted Aircraft (OPA) functionalities and other autonomous aerial operations of the aerial vehicle 103. At this stage, the testing module 221 may engage only the IP 109 and the EP 113 to fully operate and control the aerial vehicle 103, as if the OP 105 is not boarded on the aerial vehicle 103. In other words, the testing module 221 conducts a trial flight of the aerial vehicle 103 to conduct the OPA/complete autonomous functionalities of the aerial vehicle 103.

In an embodiment, the control transfer module 223 may be configured for transferring the control and operation of the aerial vehicle 103 from the OP 105 to the IP 109 and the EP 113 once the aerial vehicle 103 has been successfully tested for its OPA/completely autonomous functionalities. That is, the control transfer module 223 helps in unmanning the aerial vehicle 103 by deboarding the OP 105 and then handing-over the complete control of the aerial vehicle 103 to the ground-based IP, while maintaining the EP 113 as a stand-by pilot for cases of emergency.

FIGS. 3A-3C show flowcharts illustrating various phases involved in transforming a manned aerial vehicle 103 into an unmanned aerial vehicle 103 in accordance with some embodiments of the present disclosure.

FIG. 3A illustrates the first phase of the unmanning process. The first phase may essentially consist of the inner most Stability Augmentation System (SAS)/Control Augmentation System (CAS) loops and Basic Autopilot (AP) modes. The SAS/CAS may be used for correcting the deficiencies, if any, in the airframe dynamic characteristics. The basic AP modes may consist of a two-axis system that controls the pitch and roll attitudes of the aerial vehicle 103. During this phase, the OP 105 can either fly the aerial vehicle 103 manually or engage the pilot relief modes, which include maintaining pitch attitude, airspeed, altitude, bank angle, heading/course, climbing or descending to an assigned altitude and turning to and maintaining an assigned heading/course. In an embodiment, as shown in FIG. 3A, in the first phase, the OP 105 may control/operate the aerial vehicle 103 during taxiing and take-off of the aerial vehicle 103 and hand-over the control to the Automatic Flight Control System (AFCS) while cruising the aerial vehicle 103. The OP 105 may once again take control of the aerial vehicle 103 for landing the aerial vehicle 103, after the AFCS has completed the cruise.

FIG. 3B illustrates the second phase of unmanning the aerial vehicle 103. In an embodiment, the second phase may enable the IP 109 and the EP 113 to take control of the aerial vehicle 103. As shown in FIG. 3B, the IP 109 may remotely fly the aircraft from a Ground Control Station (GCS) 107 exercising all the AFCS functions incorporated in the first phase. Further, the EP 113 may control take-off and landing of the aerial vehicle 103 using Flight Control Box (FCB) 111, based on visual perception of aerial vehicle 103. In this phase, the OP 105 may essentially act as a safety pilot, overseeing proper AFCS functioning in the air and having the ability to take control and manually land the aircraft in case of any AFCS malfunction, malfunction of FCB 111 or datalink malfunction.

In the third phase of the unmanning procedure, the functionality of the AFCS may be further enhanced to include additional Autopilot (AP) and auto navigation flight modes to augment basic and Coupled pilot relief modes described in the first and second phases. The third phase will enable testing of the Optionally Piloted Aircraft (OPA) functionality and complete aerial autonomous operation by the ground-based IP/ EP. Here, the OP 105 acts as the safety pilot. The aerial vehicle 103 will be soft landed by the EP 113 for checking the landing functionality.

In the second stage of the third phase, the aircraft is unmanned (i.e., no onboard pilot 105 present) after gaining enough confidence in the previous phase. The EP 113 takes care of the take-off and handovers the control to the IP/ Autopilot. After the handover, the entire mission is accomplished by the IP. Finally, the IP 109 hands-over the control to the EP 113 and the EP 113 manually lands the aerial vehicle 103 with basic stabilization and flight envelope protection in place.

FIG. 3C illustrates the fourth phase or final phase of the unmanning process. In the fourth phase, the aerial vehicle 103 has fully autonomous operation with Automated Take-Off and Landing (ATOL) functionalities. In this phase, there will be no pilot on board. The IP 109 and EP 113 may be maintained on stand-by for recovery in case of emergencies.

In an embodiment, the AFCS engaged in the second, third and fourth phase of the unmanning process may consist of three components, namely an onboard autopilot drive system, Flight Management (FM) component and a ground control station 107 with associated data/ communication links. In an embodiment, the onboard autopilot drive system may control the movement of a set of electromechanical servo actuators by actuating the primary and secondary aerodynamic control surfaces (i.e., for example, components like elevator, aileron, rudder and flaps/airbrakes), the propeller lever and throttle level position by a correct amount to perform selected tasks. In an embodiment, the FM component may act as the brain of the AFCS. The FM component may accept data inputs from an Inertial Management Unit (IMU) aided by Global Positioning System (GPS), air data sensors, other navigation sources, the Pilot Control Panel (PCP) and AP servo feedbacks. These inputs may be suitably processed according to control laws resident in the onboard computers of the aerial vehicle 103, which in turn will generate required output commands to drive the flight displays and servo actuators for achieving the desired AP functionalities and performance. Additionally, the FM component may be equipped with a software that includes the mode select and transition logic. The GCS 107, along with the associated data/communication links, helps the IP 109/EP 113 in remotely operating the aerial vehicle 103.

In an embodiment, the AFCS hardware architecture for first and second phases may be dual redundant with limited authority for achieving fail-safe operation. However, the hardware components and overall architecture may be designed to enable the AFCS to be expanded to a dual-dual configuration for Fail op - Fail safe operations with higher control authority for meeting the unmanned autonomous flight requirements in third and fourth phases of the unmanning process. In an embodiment, the AFCS and associated control software may be developed and certified to meet Design Assurance Level (DAL) A standards.

In an embodiment, an adequate understanding of the aircraft flight dynamics may be essential to start designing of the automation system 101. With the help of a 3D CAD geometrical model of an airframe, mass, inertia and relevant computer graphics data, preliminary analytical data that defines the aerodynamic coefficients of the nonlinear differential equations may be obtained using industry standard and proven software packages like Advanced Aircraft Analysis (AAA) and other stability and control analysis software. In an embodiment, the Aerodynamic forces and moments may be supplemented with propulsive forces and moments from the engine, generated using low order functional dynamic models of the power plant. To account for the main landing gear suitable, corrections to the drag and moment coefficients may be also made, if found to be significant.

In an embodiment, upon finalization of the payload placement and changes to the external geometry of the airframe, the aerodynamic coefficients defining the equations of motion of the aircraft may be subsequently updated using Computational Fluid Dynamics (CFD) techniques at specific points in the flight envelope. Further, flight mechanics parameter analysis is done to identify the deficiencies, if any, in the airframe control and stability (modal) characteristics in the operational (design) flight envelope. Subsequently, once the aircraft starts flying, Parametric Identification (PI) flight tests may be conducted, and flight data thus generated may be used to refine the parameters and update the model to match flight.

In an embodiment, generating the linear models may include combining the aerodynamic, propulsion, gravitational forces and moments that act on the airframe, with kinematic and dynamic equations of motion of a rigid body results in the six-Degree of Freedom (6-DOF), 12-state, nonlinear dynamic model of the aircraft, which is used for simulation. The 6-DOF model may be complex to directly use in control law design, synthesis and analysis. Therefore, the design may be more easily accomplished using lower-order linear models, such as decoupled lower (4th) order linear models, that describe small deviations from trim in the longitudinal. The lateral directional axis may be derived using standard techniques at several flight conditions to cover the operational requirements. The state space and transfer function models thus generated may be used for designing the stability augmentation loops and autopilot modes.

In an embodiment, modeling of sensors, computers and actuators may include generating a low order (first or second order) equivalent mathematical models for the feedback sensors and actuators. The digital sampling and compute time delays may be added to these and respective aircraft transfer functions to compute the overall loop transfer functions as they directly affect the stability margins.

In an embodiment, the deficiencies in the flying and handling qualities (MIL-F-8785F and DEF-STAN 00-970) identified in the modal characteristics (i.e., damping and speed of response) may be corrected in the inner most stability/control augmentation loops using conventional control system synthesis methodology. Standard technique of successive loop closure may be used to design the autopilot control laws. Nested control loops may be closed one at a time, with inner loops maintaining roll and pitch angles and outer loops maintaining airspeed, altitude, heading, course etc. The feedback and command gains for SAS/CAS and AP modes may be derived based on root locus and bode plots. The stability, performance and flying quality requirements may be derived from the following specification documents or standards for Category I aircrafts: i. MIL F 9490E - detailed specification for flight control systems - design, installation and test of piloted aircraft. ii. MIL-F-8785C - Military specifications for flying qualities of piloted airplanes. iii. Background information and user guide for MIL F 8785C, military specifications for flying qualities of piloted airplanes - AFWAL TR-81-3109, July 1982. iv. FAR 23, advisory circulars for stability and controls.

In an embodiment, after the SAS/CAS inner most control loops and the basic AP modes are designed, the performance for command and disturbance inputs may be verified initially by closing the loops using nominal and off-nominal linear aircraft models that were used for design in series with the low order models of the sensors, computer and actuators. The off- nominal linear models may be generated by suitably perturbing the dominant aerodynamic stability and control coefficients from the nominal value.

In an embodiment, the above illustrated procedure may be repeated by incorporating the AFCS control laws and mode selection logic in a full six-DOF nonlinear simulation environment at several flight conditions with- and without- turbulence over the full operating envelope. In addition to verifying the performance of the different AFCS modes, the control surface deflections may be monitored to ensure that the limits of the control authority, chosen during design, are not exceeded for command and turbulence inputs. All the design details for the AFCS control laws may be captured in a functional requirements and structural definition document, which will serve as an input for the onboard embedded software design and testing team of the aerial vehicle 103.

FIG. 4 shows a flowchart illustrating a method of transforming a manned aerial vehicle 103 into an unmanned aerial vehicle 103 in accordance with some embodiments of the present disclosure.

As illustrated in FIG. 4, the method 400 may include one or more blocks illustrating a method for transforming a manned aerial vehicle 103 into an unmanned aerial vehicle 103 using an automation system 101 illustrated in FIG. 1. The method 400 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

The order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block 401, the method 400 includes optimizing, by the automation system 101, stability, control and basic Autopilot (AP) functionalities of the aerial vehicle 103 by analysing one or more predetermined operations performed by an Onboard Pilot (OP) 105 of the aerial vehicle 103. As an example, the one or more predetermined operations performed by the OP 105 may include, without limiting to, manually flying the aerial vehicle 103 or engaging pilot relief modes on the aerial vehicle 103 for maintaining altitude, pitch altitude, airspeed, bank angle, course, climbing, descending and turning of the aerial vehicle 103. In an embodiment, the basic AP functionalities may include a two-axis system for controlling pitch and roll altitudes of the aerial vehicle 103. In an embodiment, the one or more predetermined operations may be analysed by initially comparing results of the one or more predetermined operations performed by the OP 105 with corresponding technical requirements 213 of the aerial vehicle 103, and subsequently identifying errors and deviations in the one or more predetermined operations based on the comparison. As an example, the technical requirements 213 of the aerial vehicle 103 may include, without limitation, functional requirements, performance requirements, interface requirements, environmental requirements, regulatory requirements, reliability requirements, human factors engineering requirements and safety requirements.

In an embodiment, the stability, control and basic AP functionalities of the aerial vehicle 103 may be optimized by rectifying the errors and deviations in the one or more predetermined operations using a pretrained dynamic linear model.

At block 403, the method 400 includes enabling, by the automation system 101, an Internal Pilot (IP) 109 and an External Pilot (EP) 113 to operate the aerial vehicle 103 based on the optimization. In an embodiment, the IP 109 may remotely fly the aerial vehicle 103 through a ground-based Ground Control Station (GCS) 107 and the EP 113 may control taking-off and landing of the aerial vehicle 103 based on visual perception of the aerial vehicle 103 using a Flight Control Box (FCB) 111.

At block 405, the method 400 includes testing, by the automation system 101, Optionally Piloted Aircraft (OPA) functionalities and completely autonomous aerial operation of the aerial vehicle 103 by the IP 109 and the EP. In an embodiment, when the IP 109 and the EP 113 are taking over the control and operation of the aerial vehicle 103, the OP 105 is maintained as a safety pilot for monitoring proper functioning of the aerial vehicle 103 and to manual control the aerial vehicle 103 whenever there is an emergency and/or when a malfunctioning is detected in the aerial vehicle 103.

At block 407, the method 400 includes unmanning, by the automation system 101, the aerial vehicle 103 upon successful testing of the OPA functionalities and autonomous aerial operation of the vehicle. In an embodiment, unmanning involves deboarding the OP 105 from the aerial vehicle 103 for enabling a fully autonomous functioning of the aerial vehicle 103. At this stage, the IP 109 and the EP 113 may be maintained at stand-by for monitoring the aerial vehicle 103 and handling any emergency conditions. Computer System

FIG. 5 illustrates a block diagram of an exemplary computer system 500 for implementing embodiments consistent with the present disclosure. In an embodiment, the computer system 500 may be the automation system 101 illustrated in FIG. 1, which may be used for transforming a manned aerial vehicle 103 into an unmanned aerial vehicle 103. The computer system 500 may include a central processing unit (“CPU” or “processor” or “memory controller”) 502. The processor 502 may comprise at least one data processor for executing program components for executing user- or system-generated business processes. A user may include a pilot, an aeronaut a flyer or any system/sub-system being operated parallelly to the computer system 500. The processor 502 may include specialized processing units such as integrated system (bus) controllers, memory controllers/memory management control units, floating point units, graphics processing units, digital signal processing units, etc.

The processor 502 may be disposed in communication with one or more Input/Output (I/O) devices (511 and 512) via I/O interface 501. The I/O interface 501 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE ^® - 1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE ^® 802. n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. Using the I/O interface 501, the computer system 500 may communicate with one or more I/O devices 511 and 512.

In some embodiments, the processor 502 may be disposed in communication with a communication network 509 via a network interface 503. The network interface 503 may communicate with the communication network 509. The network interface 503 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE ^® 802.1 la/b/g/n/x, etc. Using the network interface 503 and the communication network 509, the computer system 500 may connect with a Ground Control Station (GCS) 107 for enabling an Internal Pilot 109 to take control of the aerial vehicle 103 from a ground-based control unit. Further, the communication network 509 may be used for connecting with Flight Control Box (FCB) 111 for enabling an External Pilot 113 to control taking-off and landing of the aerial vehicle 103.

In an implementation, the communication network 509 may be implemented as one of the several types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 509 may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 509 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.

In some embodiments, the processor 502 may be disposed in communication with a memory 505 (e.g., RAM 513, ROM 514, etc. as shown in FIG. 5) via a storage interface 504. The storage interface 504 may connect to memory 505 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.

The memory 505 may store a collection of program or database components, including, without limitation, user/application interface 506, an operating system 507, a web browser 508, and the like. In some embodiments, computer system 500 may store user/application data 506, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle ^® or Sybase ^® .

The operating system 507 may facilitate resource management and operation of the computer system 500. Examples of operating systems include, without limitation, APPLE ^® MACINTOSH ^® OS X ^® , UNIX ^® , UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION ^® (BSD), FREEBSD ^® , NETBSD ^® , OPENBSD, etc.), LINUX ^® DISTRIBUTIONS (E.G., RED HAT ^® , UBUNTU ^® , KUBUNTU ^® , etc.), IBM ^® OS/2 ^® , MICROSOFT ^® WINDOWS ^® (XP ^® , VISTA ^® /7/8, 10 etc.), APPLE ^® IOS ^® , GOOGLE ™ ANDROID ™, BLACKBERRY ^® OS, or the like.

The user interface 506 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, the user interface 506 may provide computer interaction interface elements on a display system operatively connected to the computer system 500, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, and the like. Further, Graphical User Interfaces (GUIs) may be employed, including, without limitation, APPLE ^® MACINTOSH ^® operating systems’ Aqua ^® , IBM ^® OS/2 ^® , MICROSOFT ^® WINDOWS ^® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX ^® , JAVA ^® , JAVASCRIPT ^® , AJAX, HTML, ADOBE ^® FLASH ^® , etc.), or the like.

The web browser 508 may be a hypertext viewing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), and the like. The web browsers 508 may utilize facilities such as AJAX, DHTML, ADOBE ^® FLASH ^® , JAVASCRIPT ^® , JAVA ^® , Application Programming Interfaces (APIs), and the like. Further, the computer system 500 may implement a mail server stored program component. The mail server may utilize facilities such as ASP, ACTIVEX ^® , ANSI ^® C++/C#, MICROSOFT ^® , .NET, CGI SCRIPTS, JAVA ^® , JAVASCRIPT ^® , PERL ^® , PHP, PYTHON ^® , WEBOBJECTS ^® , etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT ^® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 500 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE ^® MAIL, MICROSOFT ^® ENTOURAGE ^® , MICROSOFT ^® OUTLOOK ^® , MOZILLA ^® THUNDERBIRD ^® , and the like.

Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

Advantages of the embodiments of the present disclosure are illustrated herein.

In an embodiment, the present disclosure helps in converting a manned aerial vehicle into an unmanned or an optionally piloted aerial vehicle using a reliable multi-phase training approach.

In an embodiment, the present disclosure ensures that an unmanned aircraft, used for ferrying, can still be used as a manned aircraft carrying an onboard pilot, who has a complete control from cockpit, as would have been available from a ground control station, without requiring major modifications in the design or configuration of the aerial vehicle.

In an embodiment, the proposed method ensures that an aerial vehicle can be used for both surveillance and reconnaissance applications by switching between piloted/optionally piloted modes of operation.

The aforesaid technical advancements and practical applications of the proposed method may be attributed to the aspect of enabling an Internal Pilot (IP) and an External Pilot (EP) to operate the aerial vehicle based on the optimization, through a ground-based Ground Control Station (GCS) and a Flight Control Box (FCB) respectively, such that the IP 109 can remotely fly the aerial vehicle and the EP can control taking-off and landing of the aerial vehicle based on visual perception of the aerial vehicle, as disclosed in step 2 of the independent claims 1 and 9 of the present disclosure.

In light of the technical advancements provided by the disclosed method and the automation system, the claimed steps, as discussed above, are not routine, conventional, or well-known aspects in the art, as the claimed steps provide the aforesaid solutions to the technical problems existing in the conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the system itself, as the claimed steps provide a technical solution to a technical problem.

The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise. The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise.

The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

When a single device or article is described herein, it will be clear that more than one device/article (whether they cooperate) may be used in place of a single device/article. Similarly, where more than one device/article is described herein (whether they cooperate), it will be clear that a single device/article may be used in place of the more than one device/article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality /features. Thus, other embodiments of invention need not include the device itself.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.