Patent Description:
Modern transport vehicles (hereinafter, "vehicles") include helicopters, airplanes, cars, trucks, boats and trains. It is common for vehicles to include electronic sensors to monitor both the performance and the environment of a vehicle. A sensor may record data indicative of the environment impinging on or surrounding the vehicle, or data indicative of internal operations of parts of the vehicle, or data which is influenced by both external environment and internal operations. Commonly used sensors may include sensors for monitoring motion, vibration, velocities, temperatures, torques, liquid or gas pressures, liquid or gas volumes, concentrations of gases or liquids, electrical performance and parameters, and others as well.

The data obtained via parameter-specific sensors may be used for multiple purposes. For example, a sensor may monitor real-time performance of a vehicle component to ensure a component is operating within safe or appropriate parameters (for example, for heat, pressure, electrical performance, and similar). Where variations from expected performance ranges are detected by a sensor, a hardware processor with suitable code may be used to adjust operations of the vehicle to correct for problems. In the simplest cases, monitoring (with suitable displays) may simply alert an operator of a vehicle to changes in vehicle conditions, such as changes in vehicle speed or fuel levels, or total mileage travelled, leaving appropriate responses to the determination of the vehicle operator.

Another use of collected sensor data is for after-the-fact analysis of vehicle performance. In some cases, such after-the-fact analysis may be used to help with development of vehicle prototypes during a vehicle design process. In other cases, such data, when analyzed over time, may provide early-alert warnings to potential or pending problems for the vehicle.

Another application of sensor data is when the vehicle encounters unexpected problems or environments, or when the vehicle exhibits unexpected behaviors or performance, in order to analyze and assess vehicle performance after-the-fact. Such post-problem analysis, usually performed by researchers and/or computers some time after an event has occurred, can assist in identifying either the nature of unexpected stresses to which a vehicle was exposed; or unanticipated responses of the vehicle to various environment factors/stresses; or both.

One well-known application of vehicle sensor data is in aircraft in a variety of different systems which broadly fall under the category of "Health and Usage Monitoring/Management Systems" (HUMS). HUMS include, for example and without limitation:.

While the "black boxes" may be the publicly best-known devices, it is often desirable to obtain and analyze both routine vehicular sensor data; and also desirable to sometimes obtain still additional flight data even when a vehicle has not experienced a catastrophic failure, but rather when the vehicle has simply been subject to a high risk or high stress incident, or when a pilot or other aircraft operator decides that additional data collection may prove useful during a flight. Such routine data collection is handled by the OMS and HUMS systems.

Persons skilled in the art will appreciate that on-board recording elements may include cockpit voice recorders and image/video recorders as well. In some embodiments of the present system and method, data from such devices is not within the scope of the present system and method. In alternative embodiments, some data from flight voice recorders and/or image/video recorders may fall within the scope and application of the present system and method.

For convenience in the present document, the terms "flight data recorder", "HUMS", "flight data monitoring systems", and similar terms may be used interchangeably to refer broadly to devices which collect and store information pertinent to flight operations in the course of an aircraft transit. A further umbrella-term generally employed herein is, interchangeably with these other terms, is "Data Acquisition and Processing Unit (DAPU)" (see for example <FIG> below).

Flight Data: Persons skilled in the relevant arts will appreciate that the term "flight data" encompasses a variety of data pertaining to aircraft movement, altitude and performance, aircraft systems usage (for example, fuel usage, electrical operations, and similar data), and also to the detected operations of numerous aircraft components, such as engines, wings, and other systems. The exact type and extent of data collected may vary depending on the type of aircraft employed and the choice of data collection systems. Flight data may include various levels of detail, including varying levels of time-granularity.

For purposes of the present system and method, and as used in this document, "flight data" may include data pertaining to detected aircraft vibrations, and may include raw vibration data, processed vibration data, or both.

The collection of flight data is typically limited by some practical constraints. Aircraft, such as airplanes and helicopters, often employ hundreds of sensors of many different types, and which are positioned throughout the craft, all of which collect raw data in real time. Over the duration of any typical transport time (for example, even just one hour, let alone multiple hours), the amount of real-time raw data that can be collected from even just a few sensors can spill into the terabyte range. The data from dozens or hundreds of sensors can accumulate to hundreds of terabytes or more if aircraft vibration data is included.

With modern hard drives and other storage advances, it may be practical to store all this data in a flight recorder with multiple long-term storage devices. However, it would presently be unrealistic to transfer all the raw sensor data for an entire flight to off-site storage (for off-site analysis). The data transmission time could be on the order of hours, and would use up unacceptable bandwidth on communications channels.

For this reason, flight recorders typically engage in some preliminary processing and/or compression of some flight data. Some flight data-including data which may not be typically stored in legacy systems, but which may be recorded and stored within the scope of the present system and method-may require extremely high sampling rates. For example, vibration data for mechanical components and/or structural components may need to be sampled many thousands of times per second. Therefore, a flight recorder may determine and then record to its non-volatile storage a series of time averaged values of sensed levels of vibrations (as well as other parameters, such as electrical parameters, temperatures, pressures, speeds of rotation, and other parameters). For example, a time average of mechanical vibration values per second could be determined, and then saved to long-term flight recorder storage. Other processed values, such as maximum values or minimum values within a time unit (such as per second) may be calculated and recorded as well. Alternatively, some flight data, while collected continuously, may be stored only at selected time intervals (such as once per second, or once every five seconds, etc.) This greatly reduces the amount of data which needs to be saved and later transferred to off-vehicle storage.

A potential problem then arises, however, for later data analysis following a flight incident, accident, or crash (hereinafter, simply "flight incident" or "incident"). To determine the cause of an accident or incident, accident investigators must consider multiple factors. To make as complete an analysis as possible, it is often desirable to obtain the raw, unprocessed sensor data, especially for the time period(s) most strongly implicated in an incident or accident. This ideally would include raw flight data for some period of time prior to the incident.

Existing data monitoring systems, such as HUMS and flight recorders, are sometimes configured to store raw data from some sensors (along with processed sensor data) once an indication has been received of an incident. However, this means that raw sensor data is not available for the moment of the incident, and is also not available for any period of time prior to the incident.

<CIT> discloses a portable noise and vibration analyzer for vehicles, in which received vibration data is analyzed to identify a vehicle component that is likely causing the vibration. <CIT> discloses a system for monitoring the health of power plant such as a gas turbine engine using vibration data from the power plant, and storing the vibration data in a ring buffer and a hard disk, the vibration and performance data, as they are acquired, are temporarily stored in a ring buffer, the data is synchronised and subjected to novelty detection in a processor and comparator means which receives a synchronisation signal from a data acquisition means and the data from the ring buffer. Those sections of the data corresponding to novel events are then tagged and recorded with no loss of information in a permanent registration means. The performance and vibration data streams are asynchronous and stored together with the corresponding timestamps, as data is loaded into memory, synchronisation is performed between the performance and spectrum data on a line by line basis, markers are kept which record the last synchronised line in the vibration and performance data ring buffers. When new data is available in memory, the timestamp for the next vibration spectrum line is examined. The synchronisation algorithm starts from the last previously synchronised location in the performance data and searches forwards or backwards based on the timestamps of the performance data until the closest matching timestamp in the performance data ring buffer is identified, this location is recorded as being synchronised with the line in the vibration ring buffer. The algorithm then proceeds to the next line in the vibration ring buffer and so on.

<CIT> relates to reduction in road noise using a physical vibration signal.

What is needed, then, is a system and method to store, in long-term or non-volatile storage, raw sensor data for a period of time prior to an incident, as well as during an incident and for some period of time following an incident, without storing an amount of data with unacceptably large storage or bandwidth requirements.

The invention is defined by the accompanying claims. In at least one aspect, embodiments of the present system and method provide for a sensing and monitoring system (hereinafter, "monitoring system") with a volatile circular memory buffer which is coupled with multiple vibration sensors (accelerometers) in a vehicle; the system and method entails a long-term (non-volatile) storage as well (hereinafter, "storage").

The circular memory buffer continually records raw vibration data from the sensors for a designated length of time (for example, one minute, two minutes, or five minutes, or possibly other designated durations of time). As new, raw vibration data enters the circular buffer, the new data is stored in the buffer. To make room for new data, the oldest data in the buffer is overwritten (effectively erasing it).

A hardware processor is also associated with the system. The hardware processor (hereinafter, "processor") may generate processed, reduced-bandwidth vibration data based upon received raw vibration data. Under normal conditions, the raw vibration data in the circular buffer is not stored in the long-term storage, and so the long-term storage is only used to store the processed, reduced-bandwidth vibration data generated from the raw data by the hardware processor.

The monitoring system is configured to determine that an incident has occurred. The determination may be made by the present monitoring system itself, by another monitoring system of the vehicle, or by a indication received from a user of the system (such as a helicopter pilot or airplane pilot).

An exemplary monitoring system according to the present system and method may automatically determine that an incident has occurred; or the monitoring system according to the present system and method may receive a trigger signal from a pilot, so that the pilot may manually trigger vibration data acquisition when the pilot believes additional data would be useful. The monitoring system then copies the vibration data that has been collected prior to the incident or manual signal, and which is still resident in the circular buffer, to the long-term storage. Vibration data gathered post incident is also appended to the long-term storage.

In this way, the long-term memory is configured to store, for future analysis, raw vibration data from the vibration sensors which begins at some designated length of time (for example, two minutes or five minutes) before the incident, which further includes the vibration raw data at the time of the incident, and also includes the raw vibration data collected subsequent to the incident.

Additional features, modes of operations, advantages, and other aspects of various embodiments are described below with reference to the accompanying drawings. It is noted that the present disclosure is not limited to the specific embodiments described herein. These embodiments are presented for illustrative purposes only. Additional embodiments, or modifications of the embodiments disclosed, will be readily apparent to persons skilled in the relevant art(s) based on the teachings provided.

Advantageous designs of embodiment of the present invention result from independent and dependent claims, the description, and the drawing. In the following, preferred examples of embodiments of the invention are explained in detail with the aid of the attached drawings:.

The following detailed description is merely exemplary in nature and is not intended to limit the system and methods, the elements or steps of the system and method, its applications, and its uses disclosed herein. Further, there is no intention for the scope to be bound or limited to or by any theory presented in the preceding background or summary, nor in the following detailed description.

Throughout the application, description of various embodiments may use "comprising" language, indicating that the system and method may include certain elements or steps which are described; but that the system and method may also include other elements or steps which are not described, or which may be described in conjunction with other embodiments, or which may be shown in the figures only, or those which are well known in the art as necessary to the function of processing systems. However, it will be understood by one of skill in the art, that in some specific instances, an embodiment can alternatively be described using the language "consisting essentially of" or "consisting of.

<FIG> illustrates an exemplary vehicular transport system ("vehicle") <NUM>, in this instance an exemplary helicopter <NUM>. The use of a helicopter is for purposes of illustration only, and should not be construed as limiting. Numerous elements of transport vehicles in general, and helicopters in particular, are well known in the art and will not be described here.

The vehicle <NUM> may include a sensor or a multitude of sensors <NUM>, typically of different types. Sensors <NUM>, which may have elements which are electrical, mechanical, optical, and/or chemical, sense various environmental or vehicle phenomena or energies; the sensors operate in real-time to provide a time-series view of the magnitude or intensity of the phenomena they sense, the real-time data being provided as output as either raw electrical signals with varying voltages and currents, or as digital/numeric sampled data. Exemplary placements within or along the vehicle <NUM> of numerous exemplary sensors <NUM> are shown in the <FIG>, such as those for altitude, vehicular speed, vehicular direction and orientation, temperatures, pressures, location, vehicular acceleration, and others.

Included among the sensors <NUM> may be vibrations sensors <NUM>, also referred to as accelerometers <NUM>. (Persons skilled in the art will appreciate that, as used herein, the term "accelerometer" is employed equivalently to "vibration sensors", as opposed to the types of acceleration detectors which may be employed to detect gross acceleration of the entire vehicle <NUM>.

In one embodiment, vibrations sensors <NUM> convert sensed mechanical vibrations into electrical signals whose voltages and/or current levels vary in proportion with the magnitude of sensed mechanical vibrations of mechanical and/or structural elements (hereinafter, "mechanical elements") of the vehicle <NUM>. As shown in <FIG>, vibration sensors <NUM> may be attached to or associated with numerous elements of the vehicle <NUM>, such as rotors, rotor track and balance systems (RT&B), engines, drive trains, and various stress bearing points along the frame of a helicopter. Rotation sensors <NUM> may be included at points throughout vehicle <NUM>, such as at rotors or along drive shafts.

<FIG> illustrates an exemplary, complex internal mechanical element <NUM> of the vehicle <NUM>, in this case an exemplary helicopter drive train <NUM> or gear system <NUM>. The gear system <NUM> is internal to helicopter <NUM> (and so not shown in the view of <FIG>), and includes gears, drive shafts and other elements which may be used to transfer power from the helicopter engine (not shown) to the helicopters rotors (not shown) and other elements within the helicopter, such as generators. Gears are typically enclosed within gear boxes <NUM>. Drive shafts may also have shaft enclosures <NUM>. The vibration sensors <NUM> associated with the drive drain <NUM> are generally located internally to the gear boxes <NUM> and shaft enclosures <NUM>, and so are not directly visible in <FIG>; but the vibration sensors <NUM> are thereby suitably situated to detect vibrations at numerous points along the drive train <NUM>.

As will be understood by persons skilled in the relevant arts, similar placements of vibration sensors <NUM> may be made at multiple points among and along numerous elements of the vehicle <NUM> (for example, along or within the engine, not illustrated in the figures). The result is a wealth of vibration data from and throughout critical points in the vehicle <NUM>, along with a large volume of raw data <NUM> (see <FIG>) from vibration sensors <NUM>.

The detailed operations of vibration sensors <NUM> are beyond this scope of this document and will not be presented here. In general, vibration sensors <NUM> detect accelerations of mechanical elements, and in some embodiments may be understood as being accelerometers, or an accelerometer may function in whole or in part as a vibration sensor <NUM>. In other embodiments a vibration sensor <NUM> may be an element distinct from an accelerometer. A vibration sensor <NUM> may output raw vibration data <NUM> in analogue form, as a current or voltage waveform which is directly output from the sensor <NUM> and conforms with sensed vibrations, indicating vibration frequency, vibration intensity, or both. In other embodiments a vibration sensor <NUM> may generate suitable analogue waveform(s) internally, and then output a digital representation, for example a time series of magnitudes.

<FIG> illustrates, in list form and tabular form, information which is indicative of exemplary types and volume of vibration data which may be collected by vibration sensors <NUM> on board an exemplary helicopter <NUM>. Table <NUM> lists operational parameters for exemplary vibration sensors <NUM> (listed in the figure as "Accelerometers") which may be found on board on exemplary helicopter <NUM>. It may be seen that some fifteen vibration sensors <NUM> are distributed throughout and collect vibration data at multiple locations within the helicopter <NUM>, with spare sensors available for potential use.

List <NUM> lists exemplary ranges of likely or potential operational configurations for vibration sensors <NUM> for some exemplary embodiments of the present system and method. An exemplary helicopter <NUM> may for example employ anywhere from twenty-four to forty-three vibration sensors <NUM> distributed around the transmission system, cabin, engines, and other vehicle locations and parts. Each vibration sensor <NUM> may detect vibrations in the frequency ranges indicated, with acquisition times in the indicated ranges with vibration levels as low as <NUM>'s up to about <NUM>'s. Other operational parameters for the vibration sensors <NUM> may be envisioned as well within the scope of the present system and method.

It will be apparent to persons skilled in the art that the volume of data, in total bytes, which may be collected over hours of transport time and by dozens of vibration sensors <NUM> (as part of the much larger collection of vehicle sensors <NUM>), will be of such a large volume as to make impractical the storage and transmission of all the raw data <NUM> for a flight or trip of the vehicle <NUM>. For this reason, present systems enable long-term storage of sensor data for a full duration of a flight only for condensed and/or selected and/or processed sensor data.

In some embodiments, the present system and method may be implemented in the context of a vehicle sensing/monitoring system <NUM>, also known as a health and usage monitoring system (hereinafter, "HUMS") <NUM> for a vehicle <NUM> such as a helicopter <NUM>. The terms "monitoring system", "health and monitoring system", and "HUMS" are used interchangeably and with the same meaning below in this document.

<FIG> illustrates an exemplary HUMS <NUM> which may be associated with a transport vehicle <NUM> such as a helicopter <NUM>. The HUMS <NUM> may include, for example and without limitation:.

As illustrated schematically in the callout in <FIG>, and in one exemplary embodiment, the DAPU <NUM> may include a motherboard <NUM> which typically holds and interconnects various microchips <NUM>/<NUM>/<NUM>, and volatile and non-volatile memory or storage <NUM>/<NUM>/<NUM>, which together enable at the hardware level the operations of the DAPU <NUM> and also enable the operations of the present system and method. Motherboard <NUM> may include, for example and without limitation:.

A hardware processor <NUM>, also known as a central processing unit (CPU) <NUM> or microcontroller unit (MCU) <NUM>, provides for overall operational control of the DAPU <NUM>. This includes but is not limited to receiving data from sensors <NUM>/<NUM>, and possibly modifying some operations of sensors <NUM>/<NUM> via various application specific integrated circuits (ASICs) <NUM>.

Static memory or firmware <NUM> may store non-volatile operational code, including but not limited to operating system code, computer code for locally processing and analyzing data from sensors <NUM>/<NUM>, and computer code which may be used specifically to enable the DAPU <NUM> to implement the methods described in this document and other methods within the scope and spirit of the appended claims. CPU <NUM> may employ the code stored in the static memory <NUM> to implement the methods described in this document and other methods within the scope of the appended claims.

Control circuits <NUM> may perform a variety of tasks, including data and control exchanges with sensors <NUM>/<NUM>, as well as input/output (I/O) tasks, network connection operations, control of the bus <NUM>, and other tasks generally known in the art of processing systems. Control circuits <NUM> may also control or interface with non-volatile data storage <NUM> and/or circular memory buffers <NUM>.

Control circuits <NUM> may also support such functions as external input/output (for example, via USB ports, an Ethernet port, or wireless communications, not illustrated in the figure); a control interface for a cockpit interface panel <NUM> and/or a cockpit control unit (CCU); addressing and receiving data from various aircraft and engine data buses <NUM>; and storing data in memory card receptacle (MCR) <NUM>.

Volatile memory <NUM>, such as dynamic RAM (DRAM), may be used to temporarily store data received from the sensors <NUM>/<NUM>; exemplary sensor data content is described elsewhere in this document. Volatile memory <NUM> may also be used to temporarily store some or all of the code from static memory <NUM>, and also for temporarily storing processed sensor data which is generated by hardware processor <NUM> based on the data received from sensors <NUM>/<NUM>.

Activation and control of sensors <NUM>/<NUM> (for such sensors <NUM> as may require dynamic operational fine-tuning) may in some embodiments be maintained directly by CPU <NUM>. In other instances, activation and control may be effectuated by CPU <NUM> via various application specific integrated circuits (ASICs) <NUM> which act as intermediary control circuits.

Non-volatile data storage <NUM> provides long-term storage for sensor data, which may include some raw sensor data <NUM> (see <FIG>) recorded over time; but typically includes processed (and thereby condensed) sensor data <NUM> (see <FIG>). Non-volatile storage may take the form of hard disk drives, solid state drives (including flash drives and memory cards), recording on magnetized tape, storage on DVD or similar optical disks, or other forms of non-volatile storage now known or to be developed. For reasons discussed elsewhere in this document, non-volatile storage <NUM> is typically not used to store all of the raw sensor data <NUM> collected from sensors <NUM> during the transit of the vehicle <NUM>.

Circular buffer memory <NUM> is a form of volatile, short-term data storage which may be employed by the present system and method to store limited amounts of raw sensor data <NUM>. In an embodiment, the circular buffer memory <NUM> may actually be a designated section or address area(s) of volatile memory <NUM> discussed above. In an alternative embodiment, the circular buffer memory <NUM> may be implemented via one or more high speed cache memory-buffers integrated into CPU <NUM>. In an alternative embodiment, the circular memory buffer <NUM> may be implemented as a separate, dedicated memory chip <NUM>.

Buffer storage time duration: The circular memory buffer <NUM> is typically configured to store selected raw sensor data <NUM> for up to a maximum of some designated time interval <NUM> (see <FIG> below), that time interval typically being much briefer than the length of a typical flight or trip by vehicle <NUM>. For example, the circular memory buffer <NUM> may be configured with an expectation of storing one minute of raw sensor data <NUM>, or two minutes of raw sensor data <NUM>, or five minutes or ten minutes. Other times, including longer times, may be envisioned as well. The circular memory buffer <NUM> is therefore configured to maintain a temporary, dynamic storage of a recent raw vibration data for a designated duration of time <NUM> (see again <FIG>) prior to and including the current real-time.

In one embodiment of the present system and method, the designated duration of time <NUM> for temporary, dynamic retention of raw vibration data <NUM> in the circular memory buffer <NUM> is determined or assigned as an amount of time which is anticipated to be at least sufficient to span several minutes of flight time prior to any physical vibration event <NUM> (see <FIG>, below), plus the time it is expected for a person (such as a pilot) to be aware of, and to generate a trigger signal for raw-data storage (TSRDS) <NUM> (see <FIG> below) for the physical vibration event <NUM>.

In an alternative embodiment of the present system and method, the designated duration of time <NUM> for temporary, dynamic retention of raw vibration data in the circular memory buffer <NUM> is determined or assigned as an amount of time which is anticipated to be at least sufficient to span: (i) several minutes of flight time prior to any physical vibration event <NUM>, plus (ii) the time it is expected for a the flight recorder <NUM> to identify a physical vibration event <NUM>, based on sensor data, and thereby to automatically generate a trigger signal for raw-data storage (TSRDS) <NUM>.

Data from multiple sensors: Typically, the circular memory buffer <NUM> is configured to store the raw data <NUM> from multiple sensors <NUM>, such as raw vibration data <NUM> from multiple vibration sensors <NUM>. The circular memory buffer <NUM> may be configured, or may be controlled by CPU <NUM> or one or more control circuits <NUM>, to ensure that the circular memory buffer <NUM> is continually updated with the most recent, instantaneous sensor data, in the process overwriting the oldest sensor data in the buffer.

Internal DAPU sensors: While not illustrated in <FIG>, the DAPU <NUM> may also contain its own internal sensors, including for example and without limitation one or more vibration sensors <NUM>, location sensors, gross acceleration sensors, heat sensors, internal electrical system (for example, motherboard) status sensors, memory/storage condition sensors, and other sensors as well.

Removable memory or storage: Above it is indicated that the DAPU <NUM> contains internal volatile memory <NUM>, non-volatile data storage <NUM>, and circular buffer memory <NUM>. In some embodiments, a DAPU may have or be connected to/coupled with one or more memory receptacles or storage receptacles (MCRs) <NUM> configured to contain the memory <NUM>/<NUM> or storage <NUM>, or in some embodiments to contain supplementary, backup, or additional memory <NUM>/<NUM> or storage <NUM>, which can be inserted and removed via an exterior access port of the MCR <NUM>.

A system bus <NUM> may serve to transfer data and messages between elements of motherboard <NUM>, and between motherboard <NUM> and various other sensors, microchips, and controllers of DAPU <NUM>.

Ports and connectors: Not shown in <FIG>, but present somewhere on the surface of the DAPU <NUM>, may be ports and connectors, such as USB ports, Ethernet ports, and various specialized connectors and ports for connecting distributed HUMS elements <NUM> to the DAPU <NUM>. In <FIG>, and for the exemplary DAPU <NUM> illustrated, such ports and connectors may be embedded within or integrated into a surface of the DAPU <NUM> which is hidden from view as the flight recorder <NUM> is oriented in the figure.

In some embodiments of the present system and method, some Vehicular Distributed HUMS elements <NUM> may communicate with the DAPU <NUM> via wireless communications, for example on-board WiFi or Bluetooth connections, or other wireless connections. The DAPU <NUM> may have antennas and/or internal wireless circuitry (not shown in the figure) to enable such wireless data communications.

Vehicular Distributed HUMS Elements: <FIG> illustrates a variety of exemplary HUMS elements <NUM> which are typically part of or integrated into the vehicle <NUM>, and which are connected to the flight recorder/DAPU <NUM> via wires, cables, optical fibers, or possibly wireless means. These may include, for example and without limitation, one or more sensors <NUM>/<NUM>/<NUM>; aircraft and engine data buses <NUM> to deliver data to and transmit analyzed sensor data results from the DAPU <NUM>; one or more blade trackers (or, for example, aircraft wing operations sensors) <NUM>; a cockpit control unit <NUM>, and a cockpit interface panel <NUM>.

The details of these and other possible vehicular distributed HUMS elements <NUM> are beyond the scope of this document, and are not presented here.

Off-Vehicle Processing Systems: The HUMS system <NUM> may include one or more off-vehicle analysis or response units (OVARU) <NUM>. These may communicate with the DAPU <NUM> via wireless connections, or via wired data connections or cloud data connections once the vehicle <NUM> is post-transit (for example, on the ground and in a hangar). Several exemplary off-vehicle processing systems <NUM> are illustrated in <FIG>, but many others may be envisioned as well. Such OVARUs <NUM> may operate either in real-time (receiving real-time flight/transit data) from the vehicle <NUM>, or which may be used after-the-fact for post-flight/post-operations/post-even analysis of the performance of vehicle <NUM>.

The details of such OVARUs <NUM> are beyond the scope of this document, but it will be noted that in typical embodiments, and OVARU <NUM> may:.

Particularly for the analysis of crashes, accidents, and other flight incidents:
An OVARU <NUM>, and the human analysts which the OVARUA may support in their flight/incident analysis work, may benefit from the availability of detailed, real-time flight vibration data, as may be enabled and made available, post-incident, according to the present system and method as described herein and as is within the scope of the appended claims.

Routine Data Monitoring, Flight Events (Incidents), and Trigger Signal: In the course of monitoring a trip or flight, a HUMS <NUM>, and in particular the vehicle sensors <NUM> and the DAPU <NUM> will engage in a great deal of routine, sustained data collection and analysis, the scope of which is beyond this document. However, and as discussed further elsewhere in this document, the DAPU <NUM>, in combination with other elements of the HUMS <NUM>, may be configured or programmed so that a trigger signal for raw-data storage (TSRDS) <NUM> may trigger any or all of additional data collection, more extended data storage or retention, or additional forms of data analysis. In turn, the trigger signal for raw-data storage (TSRDS) <NUM> may result from either of automatic detection of certain unusual flight or travel events <NUM> (also referred to as event conditions <NUM>); or from a manual trigger action <NUM> by a pilot, typically based on a pilot's determination of a flight event or incident.

One potential trigger action <NUM> by a pilot (or other aircraft technician or staff) is simply a pilot's decision to press an Event Button (not illustrated in the figures) on a cockpit control unit <NUM> or elsewhere in the vehicle <NUM>. Automated event conditions <NUM> may be initiated by sensors programmed to generate the TSRDS <NUM> when certain environmental thresholds are exceeded (for example, excess gross acceleration or reduced cabin pressures); and other automated event conditions <NUM> may be generated internally by DAPU <NUM> based on an analysis of data from or more sensors <NUM>.

The trigger signal for raw-data storage (TSRDS) <NUM> may be referred to equivalently in this document, including in the appended claims, as a "processing trigger condition" (PTC) <NUM> or simply as a "trigger condition" (TC) <NUM>. As above, a processing trigger condition <NUM> may be asserted automatically via hardware and software, or may be initiated by pilot or other human operator action. The term TSRDS is employed throughout most of this document.

<FIG> illustrates exemplary processing of exemplary raw vibration and tachometer data to exemplary processed data by an exemplary vehicular health and usage monitoring system (HUMS).

In a DAPU <NUM>, the hardware processor <NUM> typically receives raw sensor data <NUM> and then provides significant numerical processing or calculations to generate processed sensor data <NUM>. Processed data <NUM> may include, for example and without limitation: average values of sensor data collected over defined time periods (for example, tenths of a second, a second, five seconds or ten seconds, or other intervals), and similarly mean data values, maximum data values, minimum data values, statistical summaries of data values over defined short time intervals, along with associated specific times when the condensed, processed data <NUM> was collected (that is, the specific times during a flight or trip).

With reference to <FIG>, raw signal <NUM> is sensed by the vibration sensors <NUM> or accelerometers <NUM>. Tachometers <NUM> are used to sense rotation speed. The first step in the analysis of raw signal data <NUM> is to produce a signal average <NUM> over a number of rotations of the component (in some embodiments, <NUM> revs, but the average <NUM> may be over other numbers of rotations). The rotational speed and hence the number of rotations is derived from the signal from the tachometer <NUM>.

Averaging produces a processed signal <NUM> that is less noisy and from which it is easier to significant extract features: high amplitude vibrations at a particular point in the rotation will not be eliminated from the signal average, but random noise will be eliminated. The signal average <NUM> is then used to calculate the condition indications <NUM>. Signal averaging has benefits for routine calculation of condition indications <NUM>, which are looking for specific characteristics of the sensed sensor signals, but the raw sensors signals <NUM> contain all the sensed vibration data.

Limitations of processed signal data and conventional systems: Vibration engineers are often interested in features in the raw signal <NUM> that are eliminated by signal averaging. For example, if a pilot reported a loud bang, this would show up in the raw signal <NUM> as a large but brief amplitude increase, but may be masked by the signal averaging. Raw signal data <NUM> enables the analysis of flight events for various conditions and events which the condition indications <NUM> are not generally configured or defined to identify.

A further limitation of processed signal data <NUM> is that the raw data <NUM> for calculating condition indications <NUM> is only collected in steady state regimes. The HUMS <NUM> uses the flight data to determine that the aircraft is, say, flying straight and level at <NUM> Kts and performs the analyses that are assigned to this regime. This ensures that the condition indications <NUM> are comparable from one flight to another.

Flight Incidents (Flight Events) and Snapshots: Conventionally, snapshots (or time limited samples) of raw vibration data <NUM> may be captured whenever a pilot's Event Button is pressed (for example, a designated button on the Cockpit Control Unit <NUM>). Using the "loud bang" example as just one of many exemplary possibly flight events or flight incidents: Upon hearing the "bang" the pilot would press the Event Button; the flight recorders <NUM> in particular and the HUMS <NUM> generally would sense when the Event Button has been pressed. Legacy HUMS systems <NUM> (lacking a circular vibration data buffer <NUM>) would then initiate a capture of raw vibration data <NUM> to be stored in non-volatile storage <NUM>. But during the time leading up to and including the "loud bang", raw vibration data <NUM> would not be captured and so not saved in storage <NUM>. The vibration engineers then only have available, for analysis, the raw vibration data <NUM> starting some seconds after the "loud bang.

Present system and method: The present system and method employs a circular buffer memory <NUM> to continually capture the most recent raw vibration data for temporary storage; and upon receiving the TSRDS signal <NUM> when triggered manually (<NUM>) from a pilot pressing the Event Button, or when automatically triggered by other defined event conditions <NUM>, the flight recorder moves the contents of the buffer memory <NUM> to permanent storage <NUM>.

As long as the flight event/incident (such as a "bang") occurred within the recording time period of the buffer (in one exemplary embodiment, two minutes of raw vibration data, but other time durations may be envisioned), raw vibration data <NUM> leading up to the "bang" event, and immediately following the event (but before the pilot pressed the Event Button, would be saved to permanent storage <NUM>. Assuming the pilot is reasonably quick to press the Event Button-or other manual raw-data-capture triggers <NUM> or automated triggers <NUM> occur shortly after an actual physical <NUM> event-substantial raw vibration data <NUM> is saved for both before, during, and after the TSRDS signal <NUM> is generated.

In embodiments of the present system and method, there may be alternative or multiple different event conditions <NUM> or manual triggers <NUM> which may generate and send a TSRDS signal <NUM> to the flight recorder <NUM> to transfer raw, pre-event vibration data <NUM> and during-event-raw vibration data <NUM> from buffer memory <NUM> to non-volatile storage <NUM>. A pilot's Event Button is only one possible exemplary trigger. For example, the HUMS <NUM> could sense and identify many different exemplary states, such as for example a vertical acceleration exceeding <NUM> and then generate a TSRDS <NUM> to initiate a raw vibration capture from buffer <NUM> to storage <NUM>.

The present system and method further takes advantage of the fact that there are multiple accelerometers/vibration sensors <NUM> across the aircraft. Condition indicators <NUM> are generally calculated (in both prior systems and the present system and method) for specific components, and the condition indicator <NUM> for any one, specific component will typically employ data from one accelerometer/vibration sensor <NUM> or a few vibration sensors <NUM> which are structurally close to that specific component.

In the embodiments of the invention, the present system and method may employ multiple circular data buffers <NUM>, with one circular data buffer <NUM> allocated for obtaining raw vibration data <NUM> for each accelerometer/vibration sensor <NUM>. In the embodiments of the invention, the multiple data buffers <NUM> are synchronized in time. Referring again to the exemplary "loud bang" example, presented above: the vibration engineers analyzing the event will know (from design specifications for vehicle <NUM>) the location in vehicle <NUM> of each accelerometer/vibration sensor <NUM>.

Employing the captured, time-synchronized raw vibration data <NUM> at known locations from before, during, and after an event, vibration engineers can both (i) see the vibration characteristics of the "bang" event at certain known points, and also (ii) track the progression of vibrations through each sensing location in the vehicle <NUM>. This potentially aids in determining the source point of the "loud bang" (or other events) along or within vehicle <NUM>.

Summary: Capturing and saving to permanent storage <NUM> the raw vibration data <NUM> from vibration sensors <NUM> throughout vehicle <NUM>, from before, during, and after a trigger signal for raw-data storage (TSRDS):.

The circular memory buffer(s) <NUM> enables items (<NUM>) and (<NUM>) immediately above to be assessed from before the physical condition <NUM> is actually even sensed.

In alternative embodiments of the present system and method, processed sensor data <NUM> may be generated by CPU <NUM> by retaining, for long-term storage, only a subset of received raw sensor data <NUM>. For example, out of every <NUM> time sequential data values received from a vibration sensor <NUM>, the CPU <NUM> may be programmed via suitable control programs to store, in long term storage, only one-in-one-thousand data samples, or five-in-one-thousand, or one-hundred-of-one-thousand data samples. These selection ratios are strictly exemplary, and others may be employed as well to ensure suitable reduction and management of long-term sensor data storage.

As is known in the art for image processing, various advanced compression algorithms may be employed by a hardware processor to transform raw image bitmap data from a camera <NUM> into compressed formats such as jpg or png. Similar compression algorithms may be employed for other forms of data, such as vibration data from vibration sensors <NUM>.

The processing and condensing of raw sensor data <NUM> by CPU <NUM> means that large amounts of summary sensor data can be collected and then maintained in long-term, non-volatile storage <NUM> while using relatively manageable amounts of long-term storage <NUM>.

At the same time, there may occur during a flight or transit one or more flight events (equivalently, "flight incidents"), typically signaled automatically by event conditions <NUM> or by pilot manual trigger <NUM>, when it may be advantageous to retain, for long-term storage, selected raw sensor data <NUM>, for designated time intervals from before, during, and after a trigger signal for raw-data storage (TSRDS). It is an objective of the present system and method to advantageously stored selected raw data <NUM> from vibration sensors <NUM>, as discussed throughout this document.

Flight events or flight conditions may be defined by system design engineers or may be identified in real-time by a pilot or other human operator, and may include for example without limitation: unexpected or extreme aircraft motions, unexpected or extreme changes of aircraft orientation, undesirable mechanical events on-board or nearby the aircraft, unexpected in-flight sounds, or unexpected aircraft component failures. Other flight events or flight conditions may be envisioned as well.

Table <NUM>, immediately below, compares some aspects, such as required storage, for raw vibration data <NUM> versus processed vibration data <NUM>.

<FIG> presents a flow chart of an exemplary method <NUM> of storage of raw sensor vibration data <NUM> by an exemplary vehicular health and usage monitoring system <NUM> according to known systems and methods.

The method <NUM> begins with step <NUM>. In step <NUM>, a vehicle health and usage monitoring system <NUM> or HUMS <NUM>, and more particularly the flight recorder or DAPU <NUM>, continually monitors a vehicle <NUM> for a trigger signal for raw-data storage (TSRDS) <NUM>. An exemplary cause for a TSRDS <NUM> is the pilot's selection of the Event Button on the vehicle's cabin (manual trigger <NUM>), but defined flight events or flight incidents may generate automated event conditions <NUM> which initiate method <NUM>.

In step <NUM>, the method <NUM> determines if an TSRDS <NUM> has been generated. If no TSRDS <NUM> has been generated, the monitoring <NUM> simply continues. If a TSRDS <NUM> is detected, step <NUM> continues with step <NUM>.

Step <NUM> entails initiating the acquisition (for example, in dynamic memory <NUM>) of raw vibration data <NUM> from vibrations sensors <NUM>.

The method <NUM> continues with step <NUM>. In step <NUM>, the raw vibration data <NUM> is stored to non-volatile data storage <NUM>, and the vibration data <NUM> is associated with a specific event indicator data or tag (not illustrated). The event indicator tag may include storage of an event ID number, the time of the event, the nature of or data in the TSRDS <NUM>, and source of the TSRDS <NUM> (such as the Event Button or identification of a sensor <NUM> which generated the TSRDS <NUM>, or other hardware or software source).

Alternatively, elements of steps <NUM> and <NUM> may be combined, in that the acquired raw vibration data <NUM> with event association may be stored directly to non-volatile data storage <NUM>.

The method <NUM> ends at step <NUM>, which in some examples not forming part of the claimed invention, may entail terminating the collection of raw vibration data <NUM> after a designated time interval, such as two minutes, five minutes, or longer or shorter intervals.

It will be noted, however, that typically the entire method <NUM> remains in operation throughout a trip, in that monitoring for event conditions <NUM> may be maintained for the duration of flight or travel of vehicle <NUM>.

<FIG> is related to the method <NUM> of <FIG>. <FIG> illustrates an exemplary timeline <NUM> of acquisition of raw vibration data <NUM> into non-volatile data storage <NUM>, as the data may be collected according to legacy method <NUM> above. As may seen in <FIG>, an unexpected flight event <NUM>-illustrated in the figure as a "physical vibration event" <NUM> or PVE <NUM>, but the event <NUM> may be a bump or unexpected noise or some other unexpected event-occurs at a first time <NUM>. Persons skilled in the relevant arts will appreciated that a physical vibration event <NUM> may occur over some sustained duration of time <NUM>; for convenience of exposition herein, and without being limiting, a single PVE event time <NUM> is used for discussion in this document, the event time <NUM> being a time within the time range of duration <NUM>.

At a later time <NUM>, and in response to the physical vibration event <NUM>, a system-level trigger signal for raw-data storage (TSRDS) <NUM> is generated, for example by manual triggering <NUM> (a pilot pressing an Event Button or Record Button) or by an event condition <NUM>.

In some embodiments of the present system and method, the TSRDS <NUM> may be generated automatically by one or more sensors <NUM> or by flight recorder <NUM> itself. Even in such situations, some amount of time generally elapses between the physical vibration event <NUM> at time <NUM> and the TSRDS <NUM> at time <NUM>.

Following the TSRDS signal <NUM> at time <NUM>, some software and/or hardware setup, referred to in the figure as "Pre-acquisition setup", may be required to initiate the acquisition of raw sensor data <NUM>. Such pre-acquisition setup may continue for some time, for example an interval centered around time <NUM>, which is subsequent to time <NUM>.

The actual acquisition and storage in long-term storage <NUM> then commences at a time <NUM> which is later than time <NUM>. From time <NUM> through time <NUM>, raw vibration data <NUM> is then recorded in long-term storage <NUM> in a recorded data frame <NUM>, along with a suitable event indicator tag. The raw vibration data <NUM> is stored with suitable timeline data or indicators. Recording of raw vibration data <NUM> concludes at time <NUM>, typically upon the completion of some specified time interval (such as two minutes, five minutes, or other configurable time intervals).

As may be seen from the timeline, there is no raw vibration data <NUM> collected or stored for the time prior to the vibration event <NUM> at time <NUM>. Also, no raw vibration data <NUM> is collected at the time <NUM> of the physical vibration event <NUM>, nor at times <NUM> of the TSRDS <NUM>; and also not during the pre-acquisition setup time or interval <NUM>. The result is a cumulative time delay interval <NUM> between the time <NUM> of the vibration event <NUM> and the time <NUM> when raw vibration data acquisition begins. All such raw vibration data <NUM> for both the time <NUM> of the physical event <NUM> and prior, and raw vibration data <NUM> for time up to and including the TSRDS <NUM>, is not recorded, and is therefore not available for post-event/post-flight analysis. (For comparison, see <FIG> below.

<FIG> presents a flow chart of an exemplary method <NUM> of storage of raw sensor data <NUM> by an exemplary vehicular health and usage monitoring system <NUM> according to exemplary embodiments of the present system and method.

The method <NUM> begins with step <NUM>. Step <NUM> entails two activities <NUM> and <NUM> (which may also be referred to equivalently as two processes <NUM>/<NUM>), which logically operate in parallel with each other, and operationally are concurrent and substantially continuous in time. Put another way, in an embodiment both activities <NUM> and <NUM> occur continuously throughout the entire time the flight recorder/DAPU <NUM> monitors flight operations (which is typically for the entire duration of vehicular travel).

In activity <NUM>, a vehicle health and usage monitoring system <NUM> or HUMS <NUM>, and more particularly the flight recorder or DAPU <NUM>, continually monitors a vehicle <NUM> for a trigger signal for raw-data storage (TSRDS) <NUM>. An exemplary cause for a TSRDS <NUM> is the pilot's selection of the Event Button on the vehicle's cabin (manual trigger <NUM>), but automated event conditions <NUM> may also be asserted based on various defined flight incidents/events, as discussed elsewhere in this document.

In activity <NUM>, one, several, most, or all of the vibration sensors <NUM> throughout the vehicle <NUM> deliver raw vibration data <NUM> to respective vibration circular memory buffers <NUM> of DAPU <NUM>. As discussed in detail elsewhere in this document, circular memory buffers <NUM> may be reserved or partitioned memory in the general dynamic memory <NUM>, or in an alternative embodiment may be implemented in volatile memory chip(s) which is/are separate from the DAPU's general dynamic memory <NUM>.

As discussed in detail elsewhere in this document, the circular memory buffers <NUM> record and retain raw vibration data <NUM> from a determined interval of time up-to-and-including a present moment in time. Exemplary storage interval times might be one minute, two minutes, five minutes, fifteen minutes, or other shorter or longer periods of time. In one embodiment of the present system and method all circular memory buffers retain raw vibration data for a same time interval into the past. In an alternative embodiment, different circular memory buffers <NUM> for different vibration sensors <NUM> may be configured to retain raw vibration data <NUM> for differing intervals of time (for example, some for one minute, some for two minutes, some for five minutes, some for ten minutes, some for other intervals spanning from the present moment into the past). As new current raw vibration data <NUM> is saved to an appropriate circular memory buffer <NUM>, the oldest data in the buffer <NUM> is overwritten.

In step <NUM>, exemplary method <NUM> determines if a TSRDS <NUM> has been generated. If no TSRDS has been generated, then step <NUM>, with its two processes <NUM>/<NUM> simply continues. If a TSRDS has been generated, stop <NUM> continues with step <NUM>.

Step <NUM> entails: (i) retrieving the most recent raw vibration data <NUM> from the circular memory buffers <NUM> (as stated on the flow chart of <FIG>), and so obtaining the most recent data prior to, during, and in the seconds following the event condition <NUM>; and (ii) continuing the acquisition of raw vibration data <NUM> from the vibrations sensors <NUM> (omitted from the flow chart of <FIG>).

The method <NUM> continues with step <NUM>. In step <NUM>, the raw vibration data <NUM> currently in the circular memory buffer <NUM> is transferred to non-volatile data storage <NUM>, and the continuing raw vibration data <NUM> which is acquired after the event condition is also stored in non-volatile data storage <NUM>. The data is stored with suitable timeline data or indicators. The combined raw vibration data <NUM> is associated with a specific event indicator data or tag (not illustrated). The event indicator tag may include storage of an event ID number, the time of the event, the nature of or data in the TSRDS <NUM>, and source of the TSRDS <NUM> (such as the Event Button or identification of a sensor <NUM> which triggered the event, or other hardware or software source).

The method <NUM> ends at step <NUM>, which in an embodiment may entail terminating the collection of raw vibration data <NUM> after a designed time interval, such as two minutes, five minutes, or longer or shorter intervals.

It will be noted, however, that typically the entire method <NUM> remains in operation throughout a trip.

<FIG> is related to the exemplary method <NUM> of <FIG> according to the present system and method. <FIG> illustrates an exemplary timeline <NUM> of acquisition of raw vibration data <NUM> into non-volatile data storage <NUM>, as the data may be collected according to exemplary embodiments of the present system and method.

As may be seen in <FIG>, an unexpected flight event <NUM>-illustrated in the figure as a "physical vibration event" <NUM>, but the event <NUM> may be a bump or unexpected noise or some other unexpected event-occurs at a first time <NUM>. At a later time <NUM>, and in response to the physical vibration event <NUM>, a system-level trigger signal for raw-data storage (TSRDS) <NUM> is generated, for example a manual trigger <NUM> generated by a pilot pressing an Event Button or Record Button.

In some embodiments of the present system and method, the TSRDS <NUM> may be generated automatically by one or more sensors <NUM> or by flight recorder <NUM> itself. Even in such embodiments, some amount of time generally elapses between the vibration event <NUM> at time <NUM> and the TSRDS <NUM> at time <NUM>.

In embodiments of the present system and method according to the exemplary method <NUM> of <FIG> and similar embodiments, acquisition and short-term storage of raw vibration data <NUM> has already been in-progress for the duration of the flight, data from which has been temporarily saved in the circular memory buffer <NUM> starting from a first time <NUM> (which is before the time <NUM> of the physical vibration event <NUM>) and up-to, including, and possibly slightly beyond the trigger signal for raw-data storage (TSRDS) <NUM>. As a result of the TSRDS <NUM>, this raw vibration data <NUM> in the circular memory buffer <NUM> is now stored (that is, stored at or shortly after time <NUM>) in long-term storage <NUM> in a first frame part <NUM> of a recorded raw vibration data frame <NUM>. The circular memory buffer is configured, as discussed above, to maintain a temporary, dynamic storage of a recent raw vibration data <NUM> for a designated duration of time <NUM> prior to and including the current real-time. In an embodiment of the present system and method, the time-duration <NUM> captured by the data in first frame part <NUM> substantially reflects/equals the same the time-duration into the past as the time duration <NUM> of raw vibration data <NUM> which can be saved in the circular memory buffer <NUM>.

The raw vibration data which may continue to be recorded for some specified time duration (which extends in the exemplary timeline from or about from trigger time <NUM> up to a later time <NUM>) is stored in the long-term storage in a second part <NUM> of the recorded raw vibration data frame <NUM>. In an embodiment, the two frame parts <NUM>/<NUM> are concatenated and stored in long-term storage <NUM> as one concatenated or combined data frame <NUM>.

Frame <NUM> may also include other data which is pertinent for post-event analysis, including an event tag, time-stamp information, and the sensor sources of raw vibration data <NUM>.

According to the present system and method, and as may be seen from the timeline <NUM>, the full recorded data frame <NUM> saved in long-term storage <NUM> includes:.

The result is a long-term recorded, stored data raw vibration data frame <NUM> which includes continuous raw vibration data from a time <NUM> which is well before the physical vibration event <NUM>, to a time <NUM> which is well after the physical vibration event <NUM>.

It will be noted that, in embodiments of the present system and method-which may employ exemplary method <NUM> or similar methods (and unlike legacy methods such as method <NUM>)-and since there is continuous collection and short-term buffer memory retention of raw vibration data <NUM> throughout a flight-there is no pre-acquisition setup time or interval <NUM> for starting to obtain raw vibration data <NUM>. In embodiments of the present system and method, then, there may be no data gaps or timeline gaps in the recorded data frame <NUM> of the present system and method.

It will also be noted that in legacy methods such as exemplary method <NUM>, the long-term stored data frame <NUM> essentially includes only the data of second part <NUM> of stored data frame <NUM>, while the legacy data frame does not include the first part <NUM> of the long-term recorded data frame <NUM>.

The present system and method, by contrast, stores all the raw vibration data <NUM> recorded by legacy methods (now in data frame part <NUM> according to the present system and method), while storing additional earlier raw vibration data <NUM> in first part <NUM> of the stored raw vibration data frame <NUM>.

In an embodiment of the present system and method, circular buffer memory <NUM> may be implemented as a reserved portion of non-volatile, long-term data storage <NUM>.

In an alternative embodiment, the present system and method may be implemented in whole or part via enhanced vibration sensors <NUM> with on-board circular-buffer memory, on-board non-volatile data storage <NUM>, and/or possibly suitable CPU/memory logic to detect or initiate trigger signal for raw-data storage (TSRDS)s/event conditions <NUM> at each enhanced sensor <NUM>. Such enhanced vibration sensors may be configured to send their stored raw vibration data frames <NUM> to flight recorder <NUM> or other data processing units for consolidation of raw vibration data frames <NUM> (and possibly for time-synchronization of raw vibration data frames <NUM>) from multiple enhanced vibration sensors <NUM>.

Alternative embodiments, examples, and modifications which would still be encompassed by the disclosure may be made by those skilled in the art, particularly in light of the foregoing teachings. Further, it should be understood that the terminology used to describe the disclosure is intended to be in the nature of words of description rather than of limitation.

Claim 1:
A method for sensing via a data acquisition and processing unit, DAPU, (<NUM>) integrated into a vehicle, the method comprising:
receiving at the DAPU (<NUM>), from a vibration sensor (<NUM>) which is configured to detect vibrations from a mechanical element (<NUM>) of the transport vehicle (<NUM>), a real-time raw vibration data (<NUM>) for the mechanical element (<NUM>);
retaining in a buffer memory (<NUM>) of the DAPU (<NUM>) the received real-time raw vibration data (<NUM>) for the mechanical element (<NUM>), wherein data is retained in a circular memory buffer (<NUM>) which is configured to maintain a dynamic storage of a recent raw vibration data (<NUM>) for a designated duration of time (<NUM>) prior to and including a current time;
receiving, at a hardware processor of the DAPU (<NUM>), a trigger signal for raw-data storage, TSRDS, (<NUM>) indicative of a flight event (<NUM>) of the transport vehicle (<NUM>), the TSRDS (<NUM>) being generated at the time of the flight event (<NUM>) or after the flight event (<NUM>);
upon receiving the TSRDS (<NUM>), transferring the recent raw vibration data (<NUM>) from the circular memory buffer (<NUM>) to a non-volatile data storage (<NUM>) of the DAPU (<NUM>), wherein the method causes to be retained in the non-volatile data storage (<NUM>) a storage of raw vibration data (<NUM>) for the designated duration of time (<NUM>) prior to and including a time of the TSRDS (<NUM>);
receiving a plurality of real-time raw vibration data signals (<NUM>) from a plurality of respective vibration sensors (<NUM>), and storing the real-time raw vibration data signals (<NUM>), synchronized in time, in respective circular memory buffers (<NUM>);
generating and retaining in the non-volatile data storage (<NUM>) the plurality of respective raw vibration data signals (<NUM>) for the plurality of vibration sensors (<NUM>), each respective raw vibration data (<NUM>) signal being a time-continuous data including substantially all the raw vibration data (<NUM>) detected by each respective vibration sensor (<NUM>) over a time interval spanning from before a time of the TSRDS (<NUM>) to a second time (<NUM>) which is a time after the TSRDS (<NUM>); and
using the time-synchronized raw vibration data (<NUM>) to track a progression of vibrations through each sensing location of the vehicle.