Patent Description:
Urban air mobility (UAM) vehicles means airborne vehicles expected to provide supplemental sources of transportation in cities and urban environments to permit transport of passengers and cargo to avoid and alleviate road congestion. Like other airborne vehicles, such as commercial jet aircraft used by airlines, UAM vehicles require flight control and attitude and heading information.

For the larger airborne vehicles, provision of flight control and attitude and heading information is independently implemented by discrete systems, each of which has its own electronics interface and power supply. Because an UAM vehicle size and propulsion power is smaller in comparison to such larger airborne vehicles, the discrete systems used in the larger airborne vehicles can be too large and heavy to be used in an UAM vehicle. Further, the discrete system may consume more electrical power than can be supplied by the UAM vehicle. Document <CIT> discloses vehicle positioning and data integrating process and system, which employs integrated global positioning system/inertial measurement unit enhanced with altitude measurements to derive vehicle position, velocity, attitude, and body acceleration and rotation information. A control board of the vehicle positioning and data integrating system distributes navigation data to flight management system, flight control system, automatic dependent surveillance, cockpit display, enhanced ground proximity warning system, weather radar, and satellite communication system. Document <CIT> discloses methods and systems for a full-scale vertical takeoff and landing manned or unmanned aircraft, having an all-electric, low-emission or zero-emission lift and propulsion system, an integrated 'highway in the sky' avionics system for navigation and guidance, a tablet-based motion command, or mission planning system to provide the operator with 'drive by wire' style direction control, and automatic on-board-capability to provide traffic awareness, weather display and collision avoidance. Document <CIT> discloses a system including a receiver configured to receive a signal and processing circuitry configured to determine a velocity vector of an ownship vehicle and determine a position of a target vehicle relative to the ownship vehicle based on the signal, determine a velocity vector of the target vehicle relative to the ownship vehicle based on the signal and the velocity vector of the ownship vehicle, and determine a characteristic of a graphical vector icon of the velocity vector of the target vehicle based on a display range of a graphical user interface.

In one embodiment, a system is provided. The system comprises the feature of claim <NUM> below. Optional features of the system at set out in dependent claims <NUM> to <NUM>. In one embodiment, a method is provided. The method comprises the features of claim <NUM> below. Optional features of the method are set out in dependent claims <NUM> and <NUM>.

Exemplary features of the present disclosure, its nature, and various advantages will be apparent from the accompanying drawings and the following detailed description of various embodiments. Non-limiting and non-exhaustive embodiments are described with reference to the accompanying drawings, wherein like labels or reference numbers refer to like parts throughout the various views unless otherwise specified. The sizes and relative positions of elements in the drawings are not necessarily drawn to scale. For example, the shapes of various elements are selected, enlarged, and positioned to improve drawing legibility. The particular shapes of the elements as drawn have been selected for ease of recognition in the drawings. One or more embodiments are described hereinafter with reference to the accompanying drawings in which:.

In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments. However, it is to be understood that other embodiments may be utilized, and that logical, mechanical, and electrical changes may be made. Furthermore, the method presented in the drawing figures and the specification is not to be construed as limiting the order in which the individual steps may be performed. The following detailed description is, therefore, not to be taken in a limiting sense.

Techniques relating to integrating a travel control system and an attitude and heading reference system are subsequently described. The integrated travel control and the attitude and heading reference system (or integrated system) results in reduced size, weight, power, and cost (SWaP-C). The integrated system includes separate processing circuitry to perform travel control, and attitude and heading determination. Attitude and heading reference functionality determines pitch, roll, yaw, and heading of a vehicle, or an equivalent in any three-dimensional coordinate system.

Travel control means controlling at least one component of a vehicle, where each component is configured to alter vehicle velocity (i.e., vehicle speed and/or vehicle heading). Input for travel control may be received from crew of the vehicle and/or control system(s) (e.g., analog or digital computer and/or neural network circuitry) onboard and/or offboard the vehicle. Input for travel control may additionally or alternatively be from crew through control mechanism(s) such as a stick or a yoke, and/or actuators such as pedal(s), lever(s), switch(es), and any other type(s) of actuators. Such control system(s) may include one or more autopilots and/or one or more vehicle control system(s).

The input typically alters the velocity of the vehicle. Optionally, such components of the vehicle may include propulsion system(s) of a vehicle (e.g., motor(s), jet engine(s), rocket(s), and/or any other propulsion system(s). Such components may also include other components, e.g., wheel steering system(s), wheel and/or air braking system(s), systems for controlling the tilt of rotating blade(s), jet engine(s), and/or rocket(s), rudder(s), aileron(s), flap(s), and/or any other components configured to alter the alter the velocity of the vehicle. Flight control means travel control for airborne or space borne vehicles. Input for travel control may be also be received from one or more sensors, e.g., an inertial measurement unit, and one or more other sensors (subsequently described) including without limitation one or more global navigation satellite system receivers.

For pedagogical purposes, embodiments of the invention will be subsequently illustrated for an UAM vehicle, utilizing flight control and corresponding components. However, the invention is applicable for other types of vehicle, including spacecraft, commercial aircraft, and/or any other type of vehicle. Also, for pedagogical reasons, the term flight may be more generally referred to as travel, including with respect to a variety of vehicle terminology.

The processing circuitry for travel control and attitude and heading determination are separated because processing circuitry for travel control may require fault tolerance and processing circuitry for attitude and heading determination may require more processing power than the processing circuitry for travel control. Travel control may require fault tolerance to diminish errors in travel control which can lead to harm to the vehicle, cargo, and/or passengers. Attitude and heading determination may require more processing power because complex equations must be solved substantially in real time to provide timely and accurate attitude and heading data. Accurate attitude and heading information are needed to facilitate travel control.

Because travel control and attitude and heading functionality are integrated, the separate processing circuitry for travel control and attitude and heading determination are implemented with common input and output (I/O) interface provided by interface circuitry, and optionally with only one power supply to power both processing circuitry and the interface circuitry; however, two or more power supplies can be alternatively used. The common I/O interface reduces the amount of cabling required on an UAM vehicle, and thus improves the integrated system's SWaP-C. The optional use of only one power supply increases power efficiency, and reduces the number of power supplies, and thus also improves the integrated system's SWaP-C.

Vehicle inertial and/or position data is required to determine vehicle attitude and heading. According to the invention, vehicle inertial data is provided by one or more inertial measurement units (IMU). Although a single IMU is illustrated herein for pedagogical purposes, more than one IMU may be used. Vehicle position data means the three-dimensional position of a vehicle with respect to an object, e.g. the earth. Optionally, vehicle position data may be provided by at least one global navigation satellite system (GNSS) receiver (GNSS receiver(s)). The IMU comprises at least one accelerometer and at least one gyroscope. Optionally, the IMU may comprise one or more magnetometer(s). The GNSS receiver(s) may include one or more Global Positioning System (GPS) receivers, one or more Galileo receivers, one or more Beidou receivers, one or more Globalnaya Navigatsionnaya Sputnikovaya Sistema (GLONASS) receivers, and/or one or more of any other type(s) of GNSS receivers. Optionally, the vehicle inertial data is provided from the IMU and/or vehicle position data is provided by the GNSS receiver(s) through the common I/O interface, and thus the interface circuitry, to first processing circuitry. Inertial data means data about vehicle acceleration in and rotation about at least one axis of the vehicle.

The first processing circuitry is configured to calculate attitude parameters, e.g., pitch, roll, and yaw of the vehicle, and vehicle heading. The second processing circuitry is configured to implement a travel control. The interface circuitry is further configured to communicatively couple the vehicle inertial data and/or the vehicle position data to second processing circuitry. If inertial data is provided by an IMU and position data is provided by GNSS receiver(s), then, optionally, attitude and heading may be determined from the inertial data and the position data using non-linear estimation such as a Kalman filter(s).

<FIG> is a block diagram of one embodiment of an integrated travel control and attitude and heading reference system (integrated system) <NUM>. The integrated system <NUM> is according to the invention configured to be installed in a vehicle, e.g., an UAM vehicle. The integrated system <NUM> includes first processing system (first processing circuitry) <NUM>, a second processing system (second processing circuitry) <NUM>, and interface circuitry <NUM>. The first processing system <NUM> and the second processing system <NUM> may each comprise analog processing circuitry, a state machine, and/or a neural network.

Optionally, the integrated system <NUM> comprises a power supply (power supply circuitry) <NUM>. The power supply is configured to be coupled to and provide power to the first processing system <NUM>, the second processing system <NUM>, the interface circuitry <NUM>, and/or any other components of the integrated system <NUM>.

The first processing system <NUM> and the second processing system <NUM> are coupled to the interface circuitry <NUM> to facilitate transmission and receipt of signals, e.g., data, from external system(s) and/or sensor(s), e.g., an IMU and/or GNSS receiver(s). Optionally, the integrated system <NUM> may include an inertial measurement unit <NUM> coupled to the interface circuitry <NUM>. The optional IMU <NUM> may also be optionally coupled to the optional power supply <NUM>.

For pedagogical purposes, the first processing system <NUM> and the second processing system <NUM> are illustrated herein as state machines. The first processing system <NUM> includes first processor circuitry <NUM> and first memory circuitry <NUM>, which are communicatively coupled to one another. Similarly, second processing system <NUM> includes second processor circuitry <NUM> and second memory circuitry <NUM>, which are communicatively coupled to one another. The first processing system <NUM> and the second processing system <NUM> are communicatively coupled to one another through the interface circuitry <NUM>. The interface circuitry <NUM> includes a first bus interface 118A. Optionally, the first processing system <NUM> includes a third bus interface 118C. Optionally, the second processing system <NUM> includes a second bus interface 118B. Bus interface means an interface to one or more buses and/or networks, each of which bi- or uni-directionally transfers analog and/or digital signals between two or more components (e.g., between (a) at least one of: the interface circuitry <NUM>, the first processing system <NUM>, and the second processor system <NUM>, and (b) circuitry and/or component(s) external to the integrated system <NUM>; thus analog and/or digital signals may flow from (a) to (b), vice versa, or in both directions). An interface means electrical circuitry used to communicatively couple two or more devices. Signals include data and/or control signals, e.g., for and/or from actuators and/or other controlled components. Such buses and networks may comprise controller area network (CAN) bus(es), Ethernet network(s), variable differential transformer (VDT) bus, Aeronautical Radio, Inc. (ARINC) <NUM> compliant bus(es), strappable port(s), inter-integrated circuit (I<NUM>C) bus(es), RS-<NUM> compliant bus(es), RS-<NUM> compliant bus(es), and/or any other type of bus(es) and/or network(s). For example, VDT bus(es) can be used to couple control mechanism(s) to second processing system <NUM>. For example, CAN bus(es) and/or ARINC <NUM> compliant bus(es) can be used to couple control systems to the second processing system <NUM>.

The interface circuitry <NUM> is configured, through the first bus interface 118A, to receive and/or transmit signals, e.g., inertial data and/or position data, between the first processor system <NUM> (e.g., the first processor circuitry <NUM>) and other components, e.g., the IMU, GNSS receiver(s), and/or any other component(s), e.g., other sensor(s). The first bus interface 118a comprises an interface to one or more buses and/or networks shared by the first processing system <NUM> and the second processing system <NUM>. The interface circuitry <NUM> may be implemented by application specific integrated circuitry, programmable logic device circuitry, programmable gate array circuitry, and/or other circuitry.

The second processing system <NUM> is configured to implement the functions of a travel or vehicle control system. The first processor system <NUM> is configured to generate attitude and heading data. The interface circuitry <NUM> is configured to couple attitude and heading data generated by the first processing system <NUM>, e.g., by the first processor circuitry <NUM>, to the second processing system <NUM>, e.g., the second processor circuitry <NUM>, the second memory circuitry <NUM>, and/or an optional travel control application <NUM>. Optionally, an attitude and heading (AHR) application <NUM> is stored in the first memory circuitry <NUM>, executed by the first processor circuitry <NUM>, and is configured to generate the attitude and heading data using inertial data and/or position data. Optionally, the interface circuitry <NUM> is configured to couple inertial data and/or position data to the second processing system <NUM> from the first processing system <NUM>, if the first processing system <NUM> is configured to generate attitude and heading data from inertial data and/or position data.

Optionally, the second processor circuitry <NUM> may be implemented with one or more fault tolerant (e.g., lock-step) processors circuits (e.g., a Texas Instruments Inc. Hercules processor). For example, the second processor circuitry <NUM> is configured to execute data, e.g., instructions of an optional travel control application <NUM> stored in the second memory circuitry <NUM>. The second memory circuitry <NUM> is configured to store data generated by and/or processed (e.g., instructions of the optional travel control application <NUM>) by the second processor circuitry <NUM>. The optional travel control application <NUM> is a travel control algorithm which generates control signals configured to control components of the vehicle which alter vehicle velocity. The optional travel control application <NUM> optionally may receive control input signals from external control system(s) (e.g., optional one or more autopilots (autopilot(s)) <NUM> and/or optional one or more vehicle management systems (vehicle management system(s)) <NUM>) and/or control(s) manipulated by flight crew). The interface circuitry <NUM> may be coupled to the optional vehicle management system(s) <NUM> and/or the autopilot(s) <NUM>, to facilitate communicating commands from the vehicle management system(s) <NUM> and/or the autopilot(s) <NUM> to the second processing system <NUM>, e.g. the travel control application <NUM>.

A vehicle management system means a system used to automatically manage a travel plan of a vehicle using sensor data. For example, a travel plan (e.g., including velocit(ies) and/or waypoint(s) along a travel path from a departure location to a destination location) may be provided by another system and/or vehicle crew. For a vehicle <NUM> that is an airborne or space borne vehicle (e.g. an aircraft), the travel plan is known as a flight plan, the travel path is known as a flight path, the vehicle management system(s) are known as a flight management system(s), and the optional travel control application <NUM> is known as the flight control application.

An autopilot means a system used to keep a vehicle at a specific velocity without intervention of vehicle crew, e.g., a pilot. Optionally, the specific velocity is provided by at least one of: (a) the vehicle management system(s) <NUM>, and (b) one or more of the vehicle crew. If the specific velocity is provided by the vehicle management system(s) <NUM>, it is to ensure that the vehicle <NUM> remains on an intended travel path eventually leading to a destination location. The autopilot(s) <NUM> provides commands to the second processing system <NUM> (e.g., the travel control application <NUM>) to cause components which adjust vehicle velocity so as to maintain the specific velocity. Commands as used in conjunction with commands provided for travel control (e.g., to the second processing system <NUM> (e.g., the second processor circuitry <NUM> and/or the travel control application <NUM>)) means instructions of any type and format, including without limitation control signals. Commands may also be referred to as command signals. Optionally, some or all of the functionality of one or more of the autopilot(s) <NUM> may be integrated into the second processing system <NUM> (e.g., integrated into the travel control application <NUM>).

The vehicle management system(s) <NUM> are configured to be coupled to one or more of the optional one or more other sensors (other sensor(s)) <NUM>, and receive data (e.g., position and/or velocity) from such sensor(s). Using sensor data, e.g., data about the vehicle's position and/or velocity, the vehicle management system <NUM> issues commands, for altering vehicle velocity, to the second processing system <NUM> (e.g., the optional travel control application <NUM>) and/or to one or more of the autopilot(s) <NUM> to attempt to have the vehicle <NUM> maintain velocity along the intended travel path. Optionally, some or all of the functionality of one or more of the vehicle management systems <NUM> may be integrated into the first processing system <NUM> and/or second processing system <NUM> (e.g., integrated into the travel control application <NUM> and/or the AHR application <NUM>). Data may be generated by the functionality of the one or more vehicle management systems where such functionality is located.

Optionally, the second processing system <NUM> (e.g., the second processor circuitry <NUM> executing the optional travel control application <NUM>) may receive input signals from optional other sensor(s) <NUM> as is exemplified elsewhere herein. Optionally, the second processing system <NUM> is configured to receive attitude and heading data, through the interface circuitry <NUM>, from the first processing system <NUM>; optionally, the second processing system <NUM>, (e.g., the travel control application <NUM> executed by the second processor circuitry <NUM>) is configured to use the attitude and heading data to perform the travel control function.

The first processing system <NUM> is configured to implement the functions of an attitude and heading reference unit (AHRU). Attitude and heading data may be determined from inertial data and position data using well known equations. For example, the first processor circuitry <NUM> is configured to execute data, e.g., (a) instructions of the optional AHR application <NUM>, and/or (b) inertial data and/or position data - stored in the first memory circuitry <NUM>. The interface circuitry <NUM> sends inertial data and/or position data as described above to first processing system <NUM>, e.g., the first processor circuitry <NUM> and/or the first memory circuitry <NUM>. The first processor circuitry <NUM> may comprise one or more processor circuits (e.g., an NXP Semiconductor T1014 processor) configured to compute attitude and heading of the vehicle. Optionally, the first processor circuitry <NUM> has a processing power, e.g., as characterized by mega floating-point operations per second (MFLOPs), that exceeds the processing power of the second processor circuitry <NUM>.

The first memory circuitry <NUM> is configured to store data generated by and/or processed (e.g., instructions of the optional AHR application <NUM>) by first processor circuitry <NUM>. The first processor circuitry <NUM> may optionally be configured to send attitude and/or heading data to the second processing system <NUM> and/or external components, through the interface circuitry <NUM>. Optionally, the second processing system <NUM>, the interface circuitry <NUM>, and the first processing system <NUM> are enclosed in an enclosure configured to be mounted in or on the vehicle <NUM>. Optionally, the IMU <NUM> and/or the power supply <NUM> are enclosed in the enclosure.

In some embodiments, the interface circuitry <NUM>, the second processing system <NUM>, and/or the first processing system <NUM> are coupled to one or more other sensors (other sensor(s)) <NUM>, and optionally to one or more vehicle management systems (vehicle management systems(s)) <NUM>, and/or one or more autopilots (autopilot(s)) <NUM>). For pedagogical purposes, <FIG> illustrates that the other sensor(s) <NUM>, the optional vehicle management system(s) <NUM>, and the optional autopilot(s) <NUM> are coupled to the first bus interface; however, each of the optional other sensor(s) <NUM>, vehicle management system(s) <NUM>, and autopilot(s) <NUM>, to the extent that they are utilized, may be coupled to the first bus interface 118A, the second bus interface 118B, and/or the third bus interface 118C. Each sensor of the optional other sensor(s) <NUM>, each vehicle management system of the vehicle management system(s) <NUM>, and each autopilot of the autopilot(s) <NUM> may be coupled, e.g., by a bus or network, to one or more of the bus interfaces. For example, an air data sensor such as a pitot tube, may be coupled to one or more bus interfaces by an ARINC <NUM> bus.

The other sensor(s) <NUM> are configured to acquire data about the vehicle <NUM> (e.g., vehicle position, vehicle speed, vehicle altitude above terrain and/or structure(s), vehicle heading, etc.) and/or about an environmental (e. , location of terrain and/or structure(s), air pressure, humidity, temperature, particle content, etc.) about the vehicle <NUM>. The other sensor(s) <NUM> may comprise one or more air data sensors (e.g., pitot tube(s), angle of attack sensor(s), barometric altimeter(s), temperature sensor(s) (e.g., thermistor(s)), and/or any other type of air data sensor(s)), GNSS receiver(s), RADAR(s) (e.g. phased array RADAR(s) and/or RADAR altimeter(s)), LIDAR(s), other imager(s) (e.g., camera(s)), magnetometer(s), particle sensor(s), hygrometer(s), automatic dependent surveillance receiver(s), and/or any other type of sensor(s). Thus, the second processing system <NUM> and/or the first processing system <NUM> are optionally configured to receive data from one or more of the optional other sensor(s) <NUM>.

Optionally, the first processing circuitry <NUM> (e.g., the AHR application <NUM>) is configured to receive and combine data (e.g., vehicle position, vehicle speed, vehicle heading, vehicle altitude, vehicle angle of attack, vehicle altitude above terrain, and/or other data) from one or more of the other sensors(s) <NUM>, e.g., using estimation, to determine attitude and/or heading of the vehicle <NUM>. Optionally, such estimation may use non-linear estimation such as Kalman filter(s) discussed elsewhere herein. Optionally, the estimation is performed on the first processing circuitry <NUM> (e.g., the AHR application <NUM>).

Optionally, the second processing system <NUM> is configured to receive data (e.g., vehicle position, vehicle speed, vehicle direction, vehicle altitude, vehicle angle of attack, vehicle altitude above terrain, and/or other data) to verify safety worthiness of commands received by and/or control signals generated by the second processing system <NUM> (e.g., the travel control application <NUM>). Commands may be received by the second processing system <NUM> (e.g., the travel control application <NUM>) from one or more of the actuator(s), one or more of the vehicle management system(s) <NUM>, and/or one or more of the autopilot(s) <NUM>. For example, if an air data sensor indicates that the vehicle (e.g., an aircraft) is at risk of stalling due to vehicle speed and/or vehicle angle of attack, then the second processing system <NUM> will disregard commands and/or will not issue control signals that would have otherwise caused the vehicle <NUM> to maintain and/or decrease vehicle speed and/or maintain and/or increase vehicle angle of attack so as to cause the vehicle <NUM> to stall. Also optionally, if one or more of the optional other sensor(s) (e.g., GNSS receiver(s), magnetometer(s), altimeter(s), RADAR(s), LIDAR(s), other imager(s), and/or any other type(s) of sensor) indicate potential imminent collision with structure such as terrain and/or a building, then the second processing system <NUM> will disregard commands (e.g., from vehicle crew, vehicle management system(s) <NUM>, autopilot(s) <NUM>, and/or other persons and/or systems) and/or not issue control signals that would have otherwise caused the vehicle <NUM> to collide with the terrain and/or the building.

The foregoing process may be referred to as integrity checking. Integrity checking or integrity means using data from one or more sensor(s) to verify whether command(s) and control signal(s) provided respectively to and from the first processing system (e.g., the travel control application <NUM>) may result a danger to the vehicle <NUM> such as a crash, loss of control, and/or other undesirable event. If the integrity checking determines that such commands and/or control signals would cause danger to the vehicle, then the commands are disregarded and/or control signals are not issued. Such integrity checking can be used to verify command(s) and/or control signal(s) related vehicle parameter(s), e.g., related to vehicle velocity and position; for example, integrity checking can be performed for maximum speed, minimum speed, maximum angle of attack, maximum angle of descent, maximum altitude, minimum altitude, and/or proximity to terrain, structure(s), and/or other vehicle(s).

<FIG> illustrates a flow diagram of one embodiment of a method for determining attitude and heading data and generating vehicle control signals using interface circuitry. Method <NUM> may be implemented using the systems described in <FIG>, but may be implemented by other means as well. The blocks of the flow diagram have been arranged in a generally sequential manner for ease of explanation; however, it is to be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with the methods (and the blocks shown in the Figures) can occur in a different order (for example, where at least some of the processing associated with the blocks is performed in parallel and/or in an event-driven manner).

Method <NUM> begins at block <NUM>. In block <NUM>, receive inertial data through interface circuitry. For example, the interface circuitry is coupled to first processing circuitry and second processing circuitry. Optionally, the inertial data may be acquired from one or more inertial measurement units through the interface circuitry or other interface(s).

In block <NUM>, using the received inertial data, generate attitude and heading data with the first processing system <NUM>, e.g., with the travel control application. Optionally, the attitude and heading data is estimated with the received inertial data and data received from other sensor(s) <NUM> - as is discussed elsewhere herein. In block <NUM>, communicate the attitude and heading data from the first processing system <NUM> to the second processing system <NUM>.

Optionally, in block <NUM>, receive a command at the second processing system <NUM> (e.g., at the travel control application <NUM>), e.g., from at least one of (a) at least one actuator and (b) at least one control system. The command may be received through the interface circuitry <NUM> or directly by the second processor system <NUM> through the second bus interface 118B. The at least one control system may be at least one of the control systems described elsewhere herein, and/or one or more of any other control systems. Proceed to block <NUM> or directly to block <NUM>.

According to the invention, in block <NUM>, verify the integrity of the received command using data received from one or more other sensors <NUM>. If the integrity of the command is not verified, proceed to block <NUM>. In block <NUM>, disregard the command that was not verified; that is, do not use the received, but unverified, command to generate one or more control signals in block <NUM>. Optionally, block <NUM> may be performed in the first processing system <NUM> and/or the second processing system <NUM>. Optionally, after block <NUM>, return to one of blocks <NUM>, <NUM>, and/or <NUM>. If integrity is verified, proceed to block <NUM>.

In block <NUM>, using at least one of the attitude and heading data and the received and verified command, generate one or more vehicle control signals (vehicle control signal(s)) using the second processing system <NUM>. The vehicle control signal(s) are used by vehicle components to alter velocity of the vehicle. Optionally, second processing circuitry and/or a travel control application are configured to generate the one or more control signals. Optionally, the second processing circuitry is fault tolerant. Optionally, proceed to optional block <NUM> or directly to block <NUM>.

Optionally, in block <NUM>, verify the integrity of each of the generated one or more vehicle control signals generated in block <NUM>. If the all vehicle control signals are not verified, then in block <NUM> do not issue the vehicle control signal(s) that are not verified. Thus, some control signal(s) may be verified, and some control signals may not be verified. Optionally after block <NUM>, proceed from block <NUM> to block <NUM> to permit verified control signals (if any) to be issued, or (e.g., if there are no verified control signals) return to one of blocks <NUM>, <NUM>, and/or <NUM>.

If integrity of one or more of the control signal(s) are verified, proceed to block <NUM>.

In block <NUM>, issue the one or more vehicle control signals, which optionally have been verified, from the second processing system <NUM> through the interface circuitry <NUM> to alter vehicle velocity (e.g., by conveying the one or more control signals from the interface circuitry to one or more vehicle components that alter vehicle velocity). Optionally, then return to blocks <NUM>, <NUM>, and/or <NUM>.

The embodiments of software applications, e.g., the optional travel control application <NUM> and/or the AHR application <NUM>, can be implemented by computer executable instructions, such as program modules or components, which are executed by at least one processor. Generally, program modules include routines, programs, objects, data components, data structures, algorithms, and the like, which perform particular tasks or implement particular data types.

Instructions for carrying out the various process tasks, calculations, and generation of other data used in the operation of the methods described herein can be implemented in software, firmware, or other computer-readable or processor-readable instructions. These instructions are typically stored on any appropriate computer program product that includes a computer readable medium used for storage of computer readable instructions or data structures.

The circuitry described herein may include any one or combination of processors, microprocessors, digital signal processors, application specific integrated circuits, field programmable gate arrays, and/or other similar variants thereof. The processing circuitry may include or function with software programs, firmware, or other computer readable instructions for carrying out various process tasks, calculations, and control functions, used in the methods described herein. These instructions are typically tangibly embodied on any storage media (or computer readable media) used for storage of computer readable instructions or data structures.

Suitable computer readable media may include storage or memory media such as the memory circuitry illustrated herein. The memory circuitry described herein can be implemented with any available storage media (or computer readable medium) that can be accessed by a general purpose or special purpose computer or processor, or any programmable logic device. Suitable computer readable media may include storage or memory media such as semiconductor, magnetic, and/or optical media, and may be embodied as storing instructions in non-transitory computer readable media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM, electrically-erasable programmable ROM, flash memory, or other storage media.

Claim 1:
A system (<NUM>) configured to be installed in a vehicle, the system comprising:
first processing circuitry (<NUM>) configured to determine attitude and heading data of a vehicle (<NUM>) using vehicle inertial data provided by one or more inertial measurement units, IMU; second processing circuitry (<NUM>) configured to generate one or more control signals configured to control components of the vehicle which alter vehicle velocity, the control signal generated using the attitude and heading data and at least one command signal
interface circuitry (<NUM>) communicatively coupled between the first processing circuitry and the second processing circuitry, wherein the interface circuitry is configured to receive the inertial data, to provide the inertial data to the first processing circuitry, and to provide the attitude and heading data to the second processing circuitry, and wherein the interface circuitry comprises an interface to at least one of (a) at least one bus and (b) at least one network shared by the first processing circuitry and the second processing circuitry; and
at least one other sensor, configured to acquire vehicle position, vehicle speed, vehicle altitude above terrain and/or one or more structures and/or vehicle heading, and/or a location of terrain and/or one or more structures, air pressure, humidity, temperature and/or particle content, the at least one other sensor coupled to the interface circuitry (<NUM>);
characterized in that
the system is configured to receive data from the at least one other sensor, and verify the integrity of the command signal using data received from one or more other sensors (<NUM>),
and in that the system is configured to disregard a command signal that is not verified so that the one or more vehicle control signals are not generated by the second processing circuitry in response to the command signal.