IL224493A - Real-time recording and data analysis - Google Patents

Description

REAL-TIME RECORDING AND DATA ANALYSIS FIELD OF THE PRESENTLY DISCLOSED SUBJECT MATTER This invention relates to the field of data recording and data analysis.

BACKGROUND Systems are often designed as an assembly of different interconnected operating units including one or more main processing units (or main computers) and a plurality of subsystems. Such systems are referred to herein as "composite systems". Each operating unit typically comprises a plurality of components and has a dedicated function. Subsystems are sometimes provided with independent processing power and dedicated computer memory.

Composite systems include, but are not limited to, different types of vehicles such as aircrafts, ships, locomotives, cars, trucks etc. A vehicle, for instance, comprises, in addition to a main computer (central control module (CCM)), a plurality of subsystems, each with a dedicated function which include inter alia, engine control unit, transmission control unit, anti-lock breaking system, suspension control unit, etc.

Subsystems, within a composite system, often communicate with a main computer (main processing unit) which is configured in turn to monitor and/or control operation of the subsystems. Different subsystems also communicate with each other during operation of the composite system. This is done for example, in order to accomplish an integrative task, or in case operation of one subsystem is dependent on data generated by another subsystem, the subsystems inter-communicate in order to transfer the required data from one subsystem to the other. 0218Ϊ689U7-07 During the operation of composite systems, digital data (referred to herein as "operational data") is communicated between different operating units within the system over a communication network which interconnects the different operating units within a composite system. A "channel" is a specific connection in the communication network, transmitting operational data between two or more operating units within the system. Operational data is communicated over a channel, in accordance with a predefined communication protocol. Protocols include for example Controller Area Network (CAN-bus), muxbus (1553), Local Interconnect Network (LIN) and others. In some cases conventional computer networking technologies such as Ethernet and TCP/IP are also used.

Operational data which is communicated between different operating units, includes for example input data from sensors and servos, commands being transmitted to the different subsystems from the main computer, responses transmitted back to the main computer indicating for example that a command has been received and/or whether it has been successfully executed, information in respect of the status of a subsystem (e.g. lights are on or off), and information in respect of malfunction of a subsystem etc.

Organizing data in a database enables to manipulate and analyze the data and obtain information, which is otherwise difficult and sometimes impossible to obtain from the raw data. For example, the stored data can be used for monitoring the operation of the system and detecting system malfunctions. The stored data can also be used for identifying patterns in the system performance and using this information for improving the monitoring and performance of the system.

Accordingly, composite systems can be connected to a recording system configured to hook up to the communication buses of the communication network in the composite system, download the operational data being communicated over these buses, and insert the communicated operational data into a database (e.g. a relational database).

Commonly, standard databases make use of a database management system (DBMS), which is computer software adapted for managing the database. Well-known products include the Oracle DBMS, Access and SQL Server from Microsoft, DB2 from IBM and the Open source DBMS MySQL.

GENERAL DESCRIPTION According to an aspect of the presently disclosed subject matter there is provided a method of monitoring a composite system comprising a plurality of operating units characterized by respective types, the method comprising: obtaining at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated based on both pre-recorded operational data related to respective operating unit type and on pre-recorded operational data related to at least one other operating unit type; the operating units of the corresponding types operating in a same composite system; obtaining real-time operational data recorded during operation of the monitored composite system; the real-time operational data including real time operational data values indicative of operational data parameters of a monitored operating unit in the monitored composite system, the monitored unit characterized by a given operational unit type; determining whether a deviation exists between real-time operational data of the monitored operating unit and an operational profile corresponding to the given operational unit type.

According to certain embodiments of the presently disclosed subject matter the method further comprising: obtaining the pre-recorded operational data, pre-recorded during operation of an at least one composite system; the operational data comprising operational data values indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system.

According to certain embodiments of the presently disclosed subject matter the method further comprising: compressing the recorded operational data; storing the compressed operational data in a database; and obtaining the operational data from the database.

According to certain embodiments of the presently disclosed subject matter the method further comprising: receiving a package, generated during operation of the at least one composite system; the package comprising one or more information units, each information unit is characterized by a value corresponding to a respective operational data; and inserting to a database operational data corresponding to the package or part thereof, in case the package or part thereof is different than one or more previous packages or respective part thereof, stored in a computer memory.

According to certain embodiments of the presently disclosed subject matter the method further comprising: in case the package or part thereof is different than one or more previous packages or respective part thereof and prior to the inserting: identifying the one or more information units in the package; for at least one information unit of the one or more information units: inserting to the database, operational data corresponding to the at least one information unit, in case a value corresponding to the at least one information unit is different than a value of one or more respective information units of the same type, in the one or more previous package stored in the computer memory.

According to certain embodiments of the presently disclosed subject matter wherein the at least one operational profile includes operational data which goes beyond the mere combination of pre-recorded operational data related to respective operating unit type and on pre-recorded operational data related to at least one other operating unit type.

According to another aspect of the presently disclosed subject matter there is provide a system of monitoring a composite system comprising a plurality of operating units characterized by respective type, the system comprising: at least one processor and a non-transitory storage medium in communication with the processor, the non-transitory storage medium storing machine instructions cause the at least one processor to perform the following operations: generate at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated based on the pre-recorded operational data related to respective operating unit type and on pre-recorded operational data related to at least one other operating unit type; the operating units of the corresponding types operating in a same composite system; obtain real-time operational data recorded during operation of the monitored composite system; the real-time operational data including real time operational data values indicative of operational data parameters of a monitored operating unit in the monitored composite system, the monitored unit characterized by a given operational unit type; determine whether a deviation exists between real-time operational data of the monitored operating unit and an operational profile corresponding to the given operational unit type According to certain embodiments of the presently disclosed subject matter the operations further include: obtaining operational data pre-recorded during operation of an at least one composite system; the operational data comprising operational data values indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system.

According to another aspect of the presently disclosed subject matter there is provided a non-transitory program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps of A method of monitoring a composite system comprising a plurality of operating units characterized by respective types, the method comprising: obtaining operational data pre-recorded during operation of an at least one composite system; the operational data comprising operational data values indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system; generating at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated based on the pre-recorded operational data related to respective operating unit type and on pre-recorded operational data related to at least one other operating unit type; the operating units of the corresponding types operating in a same composite system; obtaining real-time operational data recorded during operation of the monitored composite system; the real-time operational data including realtime operational data values indicative of operational data parameters of a monitored operating unit in the monitored composite system, the monitored unit characterized by a given operational unit type; determining whether a deviation exists between real-time operational data of the monitored operating unit and an operational profile corresponding to the given operational unit type.

BRIEF DESCRIPTION OF THE DRAWINGS In order to understand the presently disclosed subject matter and to see how it may be carried out in practice, the subject matter will now be described, by way of non-limiting examples only, with reference to the accompanying drawings, in which: Fig. I is a functional block diagram schematically illustrating a recording system-architecture, according to the presently disclosed subject matter; Fig. 2 is a flowchart illustrating an example of operations carried out, in accordance with the presently disclosed subject matter; Fig. 3 is a flowchart illustrating another example of operations carried out in a comparison process, in accordance with the presently disclosed subject matter; Fig. 4 is a flowchart illustrating another example of operations carried out in a comparison process, in accordance with the presently disclosed subject matter; Fig. 5 is a schematic block diagram demonstrating a division scheme of a package into a number of division-levels, in accordance with the presently disclosed subject matter; Fig. 6 is a functional block diagram schematically illustrating a nonlimiting example of system-architecture of operational data analyzing system 600, according to the presently disclosed subject matter; and Fig. 7 is a flowchart illustrating operations performed, in accordance with the presently disclosed subject matter.

DETAILED DESCRIPTION In the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations.

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "receiving”, "comparing", "translating", "determining", "identifying”, "inserting", "storing", "intercepting", "utilizing", "translating", "analyzing" or the like, include actions and/or processes of a computer that manipulate and/or transform data into other data, the data represented as physical quantities, e.g. such as electronic quantities, and/or the data representing the physical objects.

As used herein, the phrase "for example," "such as", "for instance" and variants thereof describe non-limiting embodiments of the presently disclosed subject matter. Reference in the specification to "one case", "some cases", "other cases" or variants thereof means that a particular feature, structure or characteristic described in connection with the embodiment(s) is included in at least one embodiment of the presently disclosed subject matter. Thus the appearance of the phrase "one case", "some cases", "other cases" or variants thereof does not necessarily refer to the same embodiment(s).

It is appreciated that certain features of the presently disclosed subject matter, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. in embodiments of the presently disclosed subject matter, fewer, more and/or different stages than those shown in Figs. 2, 3 and 4 may be executed. In embodiments of the presently disclosed subject matter one or more stages illustrated in Figs. 2, 3 and 4 may be executed in a different order and/or one or more groups of stages may be executed simultaneously.

Figs. 1 and 6 illustrate a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Certain embodiments of the present invention are applicable to the architecture of a computer system described with reference to Figs. 1 and 6. Each module in Figs. 1 and 6 can be made up of a combination of software, hardware and/or firmware that performs the functions as defined and explained herein. The modules in Figs. 1 and 6 may be centralized in one location or dispersed over more than one location.

It is noted that the invention is not bound by the specific architecture; equivalent and/or modified functionality may be consolidated or divided in another manner. In different embodiments of the presently disclosed subject matter, the system may comprise fewer, more, and/or different modules than those shown in Figs. 1 and 6. In different embodiments of the invention the functional blocks and/or parts thereof may be placed in a single or in multiple geographical locations (including duplication for high-availability).

Any one of the systems illustrated in Figs. 1 and 6 comprise or are otherwise associated with at least one processor operable for executing operations as described above. The term "processor" should be expansively construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, a personal computer, a server computer, a computing system, a communication device, a processor (e.g. digital signal processor (DSP), a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or any other electronic computing device, and or any combination thereof. Operative connections between the blocks and/or within the blocks may be implemented directly (e.g. via a bus) or indirectly, including remote connection.

The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a computer readable storage medium.

It should be noted that the term "criterion" as used herein should be expansively construed to include any compound criterion, including, for example, several criteria and/or their logical combinations.

As mentioned above, operational data generated within a composite system during its operation is often recorded and organized in a database for the purpose of monitoring and analysis. To this end a recording system is connected to one or more of the system’s buses and is adapted to download and store the communicated data in some type of a data-repository. Operational data being transmitted between the different operating units is delivered in groups of bytes, which are organized and packed as units of data according to a predefined format. These data units are referred to herein as “packages” or “data packages” which are otherwise known as "frames" or "data frames". The size of each package can be defined for example, by the specific communication protocol which is used, and may therefore vary from one channel to another, depending for example on the specific protocol which is used for transmitting data in each channel. Each package can comprise one or more information units. Each information unit consists of one or more bits, representing a binary value being indicative of a respective operational data. Each type of information unit corresponds to a specific type of operational data.

Once downloaded, the information which is embedded within a package in its binary format, can be extracted and converted into actual operational data with the help of translation rules, which enable to convert a given information unit to the respective operational data based for example, on its value and its location within the package.

For example, an information unit light command represents operational data indicating whether the lights are on or off. This information unit can be located for example at the second bit on the 20th byte within a package. Thus, with the help of translation rules, the second bit on the 20th byte is associated to a light _command. If the value of the bit equals 0, this means that the lights are On if the value equals 1, this means the lights are Off. Based on this information an information unit of light command type can be identified within a package and translated into its respective operational data.

Composite systems which comprise a large number of subsystems generate a large amount of operational data. For instance, according to one non-limiting example, in a medium commercial aircraft (e.g. Boeing 727) a package can be generated by each channel somewhere in between every 40 to every 100 millisecond. Assuming that a medium commercial aircraft comprises about 240 channels which generate each a package every 50 millisecond, with an average package size of about 65 bytes, the recording speed of the recording system should be as high as 300 kilobytes per second and around a gigabyte per hour (of binary data) in order to match the speed in which data is being generated.

Indeed the generated packages are downloaded by the recording system and can be stored as binary files on disks which are fast enough to match the downloading rate (e.g. disks with a writing speed of 60 gigabytes per hour). In order to manipulate and analyze the operational data, the packages are extracted from the binary files and stored in a database (e.g. SQL server) using for example, an appropriate DBMS.

It is often advantageous to manipulate and analyze the downloaded operational data in real-time (or near-real-time). This is helpful, for instance, in order to perform statistical analysis on the recorded data in real-time. For example, statistical values corresponding to operational data of an ongoing flight can be compared with respective statistical values corresponding to operational data of previous flights and thus enable to determine whether operational data values of an ongoing flight deviate from common flight patterns, and thus help to identify potential problems. In order to be able to do so, binary packages are required to be inserted into a database immediately after they are downloaded by the recording system, without delay, resulting for example from first storing the packages within binary files.

However, the process of transforming each downloaded binary package into the respective operational data and inserting this data into a database is time consuming, and thus when dealing with a high data-download-rate, (e.g. over 1000 packages per second) this creates a bottleneck which renders the process inadequate for real-time (or near real-time) analysis of the operational data.

Today composite systems are constantly growing in size and complexity as more subsystems, (e.g. new types of sensors and controllers), are being introduced and incorporated into such systems. As a result, more information is being generated by composite systems and the severity of the problem described above is constantly growing.

According to the presently disclosed subject matter there is provided inter alia , a method and corresponding system operable to enable insertion of data downloaded at a high download rate into a database (e.g. standard database such as SQL database) in substantially real-time. The term "substantially in real-time" as used herein includes real-time and near realtime.

According to the presently disclosed subject matter, packages which are communicated between operating units in a composite system are intercepted and the operational data which is carried within these packages is diluted. New operational data is transmitted to an associated database server and inserted into a database, while operational data which has been previously recorded and stored in the database is discarded. As used herein the term "new operational data" or "new data" includes operational data, which indicates a change in the measured operational parameters of the monitored sub-system in comparison with previously recorded operational parameters of the same sub-system.

This novel approach considerably reduces the amount of data which is inserted into the database when operational data of a composite system is being recorded. Thus, the system and method disclosed herein enable to record operational data (in binary format), compress the recorded data and insert the compressed recorded data into a database and thereby reduce the size of operational data which is needed to be inserted into a database for a given size of recorded operational data. This allows to increase the size of recorded operational data which can be inserted into a database, in real-time (or near real-time), during the operation of a composite system in a given period of time.

Furthermore, the system and method disclosed provide a lossless compression method which enables to compress recorded operational data and reduce the volume of the recorded operational data and thereby allow storing in a storage unit of a given size, compressed operational data, which includes more operational data than uncompressed data stored in a storage unit of the same size.

Fig. 1 is a functional block diagram schematically illustrating a non limiting example of a recording system-architecture, according to the presently disclosed subject matter. System 101 represents a non-limiting, general simulation of any type of composite system comprising a number of interconnected operating units. System 101 comprises a main processing unit 103 connected to a plurality of subsystems 102 i-n. Fig. 1 further illustrates communication buses interconnecting between the different operating units within system 101 (indicated by connecting lines). As illustrated in Fig. 1 communication buses can converge into a router (or switch) 104, however this is not always the case and in some cases part or all of subsystems 102t.„ can be directly connected to main processing unit 103 and/or to each other. It should be noted that the presently disclosed subject matter is not limited to a single composite system and also contemplates recording operational data being transmitted within and between multiple interconnected composite systems.

According to the presently disclosed subject matter, system 101 is connected to recording system 110. Recording system 110 comprises or is otherwise operatively connected to sniffing interface 111 (e.g. including a sniffer or packet analyzer) which is adapted to intercept the traffic of packages which are being transmitted between different operating units. Sniffing interface 111 can be configured to be, for example, connected to one or more of the digital communication buses in system 101 and adapted to intercept the traffic of packages which are being transmitted over these buses between the different operating units in system 101. Optionally, sniffing interface 111 can be connected to a monitor port in router 104. Alternatively or additionally, sniffing interface 111 can be directly connected to one or more operating units and adapted to intercept incoming and outgoing package traffic.

According to the presently disclosed subject matter, recording system HO can be implemented as a hardware device encapsulating different hardware and or software elements implementing the logic of system 110 as described below. Accordingly, recording system 110 can be implemented on a hardware device having appropriate computer memory and processing power for running the required logic and appropriate communication facility to communicate with system 101, other servers, computers or any other devices. For example recording system 110 can be implemented as a server computer which may be, but is not limited to, personal or portable computers or a dedicated server-computer which may be characterized by fast CPU, high performance RAM and possibly multiple hard drives and a large storage space.

It should be noted that the presently disclosed subject matter is not limited to communication which is made over communication buses and also contemplates intercepting communication trafic which is transmitted by other communication utilities such as wireless communication (e.g. Bluetooth, WiFi, RF, etc.). For example, communication between different composite systems can be established over a wireless communication facility. In such cases, snifing interface 111 can be adapted to intercept the relevant type of communication trafic.

In some cases, where communication between different operating units is performed according to different communication protocols, instead of one sniffer, a collection of sniffers can be used where each sniffer is configured to intercept packages which are being transmitted in accordance with a certain communication protocol.

Sniffing interface 111 is connected to a package processing unit 113, which is configured to process incoming packages and enable the insertion of the operational data carried by these packages to a database in real-time (or near real-time). Package processing unit 113 can comprise for example, package evaluator 115, comparator 117, translator 119 and sub-packages analyzer 120. The operation of the different components within package processing unit 113 is described in more detail below with reference to Figs. 2, 3 and 4.

Recording system 110 further comprises or is otherwise associated with data-repositories 121, 123 and 125. Data-repository 121 is adapted for storing binary files containing the downloaded packages. For example data-repository 121 can include fast writing disks as mentioned above. Data-repository 123 is adapted for storing translation rules for translating information units in binary format extracted from downloaded packages to corresponding operational data. Data-repository 125 is adapted for storing critical-data related information, enabling to identify packages carrying critical data.

Data-repositories 121, 123 and 125 can be directly associated with recording system 110, for example they may be located on the same device as the corresponding processing unit, or directly connected to the device of the corresponding processing unit. Alternatively, data-repositories 121, 123 and 125 can be located on a remote device which is accessible to recording system 110, via any type of communication facility or network (e.g. wired or wireless network). Data-repositories 121, 123 and 125 can be configured as a number of distributed data-repository units or as a single data-repository unit.

Recording system 110 can further comprise or can be operatively connected to a database server 130. Operational data which is extracted from the binary information units, extracted from the downloaded packages, is transmitted to database server 130, which is configured to insert the data into database 133. To this end, database server 130 comprises database management system (DBMS) 131.

Recording system 110 also comprises one or more processing units 140 configured, inter alia, to manage and control relevant components and operations, and to perform tasks in response to instructions generated by package processing unit 113. Computer memory 150 is adapted for storing previous packages, as explained in more detail below.

Turning now to Fig. 2, a flowchart showing an example of operations carried out in accordance with the presently disclosed subject matter, is illustrated. As explained above, package traffic between operating units within system 101 is intercepted by sniffing interface 111 and packages are downloaded and transmitted to package processing unit 113.

At block 201 a package (current package) is received by recording system 110. Optionally, all or part of the incoming packages, which are received by recording system 110, are stored in binary files (block 203). This can be done for example, for backup purposes. To this end incoming packages can be stored for example, in data-repository 121 designated for this purpose.

Optionally, each current package is evaluated to determine whether the package contains information units which comprise critical data (block 205). As used herein the term "critical data" refers to operational data which requires the immediate attention of a monitoring system or personnel. For example, when monitoring an aircraft, operational data in respect of the engine control subsystem indicating that a significant rise in engine temperature has occurred, can be considered critical data.

Types of information units and their respective values which represent critical data are predefined and stored in a designated data-repository (e.g. data-repository 125). Information units and their respective values which represent critical data can be updated in real-time. For example, in case a specific subsystem failed in a number of other aircrafts, information units generated by that specific subsystem can be defined in real-time as critical, to enable closer monitoring of the subsystem.

Determining whether a package carries critical data can be accomplished for example with the help of package evaluator 115. To this end, package evaluator 1X5 can be configured for example to extract information units from a current package and compare each information unit with the information stored in data-repository 125. Alternatively or additionally, a specific mark can be appended to part or all of information units which carry critical data (e.g. a specific sequence of bits) which can be identified by package evaluator 115 and indicate that the associated information unit carries critical data.

If critical data is identified, the incoming information unit is designated as critical data and is inserted to a database dedicated for storing critical data (block 207), to enable the immediate analysis of critical data. Identification of critical data can also cause an alert to be activated and/or be immediately displayed to an operator (e.g. flight controller). A database dedicated for storing critical data can be an on-line database.

According to the presently disclosed subject matter, a current package (or a part thereof) is compared with one or more previously intercepted packages. A current package is compared with previous packages carrying the same type of information units. As each designated channel usually carries a specific type of packages, in general a current package is compared with previous packages from the same channel. However, in some cases, for example where different channels carry the same type of packages, packages from different channels can also be compared. For the sake of better clarity only, the following discussion assumes that packages comparison is done between packages originating from the same channel, however as explained above, this should not be construed as limiting in any way.

In order to facilitate a comparison between current and previous packages, recording system 110 comprises a data-repository (e.g. computer memory 150) configured for storing one or more previously intercepted packages. The number of previous packages which are stored in computer memory 150 may vary depending on the specific implementation and needs.

According to one example, only one previous package (e.g. the latest) intercepted from each channel is stored in computer memory 150 and compared with a respective current package. According to another example, a number of previous packages intercepted from each channel can be stored in computer memory 150 and the current package is compared with all stored packages originating from the same channel. A package can be stored together with appropriate metadata indicating the respective channel of origin of the package or any information which indicates the type of the package, and optionally also with one or more respective timestamps.

According to one example when a current package is received (block 201) in recording system 110, it is also determined whether the current package is the first package intercepted from the channel. To this end, computer memory 150 can be searched for a package of the same type as the current package (e.g. intercepted from the same channel as the current package). If computer memory 150 does not contain a previous package of the same type, the current package is determined as the first package intercepted from the channel. In this case the package is stored in computer memory 150 and the process proceeds to handle the next received package.

If one or more previous packages of the same type as the current package (e.g. intercepted from the same channel), are found in computer memory 150, the received package can be stored (e.g. in non-transitory computer memory 150) and the process continues to determine whether the current package contains new data which is different than the data in one or more previous packages which are stored in computer memory 150.

According to the presently disclosed subject matter, each package can be logically divided into multiple sub-packages, where each sub-package comprises one or more information units. The size and the number of information units in each sub-package can be predefined and a package can be divided into a number of sub-packages each having a different size and/or comprising a different number of information units.

Furthermore, a sub-package can be further divided into additional subpackages representing a higher division-level wherein one division-level is inclusive of the next division-level. A division scheme of a package defines the division of the packages into different division-levels and the respective sub-packages in each division-level. In one example, according to a default division scheme, a package is divided into two division-levels, the first corresponding to the entire package (e.g. division-level 0) being inclusive of a second division-level, corresponding to the individual information units within the package (e.g. division-level 1).

Thus, in addition or instead of comparing an entire package with one or more previous packages stored in the computer memory 150, a subpackage (which in some cases can include a single information unit) within a current package can be compared with a respective sub-package within the one or more previous packages.

Fig. 5 is a schematic block diagram demonstrating a division scheme of a package into a number of division-levels. Information units in Fig. 5 are denoted by the acronym "IU". The complete package represents division-level 0, which is the highest division-level. The package is then divided into 3 subpackages representing division-level 1. The two sub-packages within division-level 1, which contain more than 1 information unit (IU) are further divided into 4 sub-packages corresponding to a division-level 2. Note that three of the 4 sub-packages in division-level 2 comprise a single information unit and therefore they are not divided any further. The fourth sub-package in division-level 2, which comprises multiple information units can be further divided into higher division-levels. It is noted that Fig. 5 is merely one non-limiting example of exemplifying the division of a package into a number of sub- packages in different levels and therefore should not construed as limiting in any way.

Processing unit 113 can be preconfigured with an "initial-level" parameter defining the first division-level which is compared during the comparison process. The initial-level parameter relates to a predefined division scheme of a package. An initial level can be for example level 0, in which case the comparison process will commence by comparing the entire current package with one or more previous packages. Alternatively, an initial level can be for example any one of levels 1 to n, in which the comparison process will commence by comparing the sub-packages in the specified initial-level with a respective sub-package of one or more previous packages.

In some cases only part of the sub-packages in a given level are compared instead of comparing all sub-packages. Consider for example that a package consists of six different information units each corresponding to a different type of operational data parameters. Three of the six information units which represent for example pitch, yaw and roll attitude parameters, are defined as a single sub-package. In case for example, only attitude parameters are of interest, package processing unit 113 can be configured to compare the attitude sub-package with respective attitude sub-packages in previous packages, instead of comparing the entire package.

In some cases, comparison between a current package and previous packages can be based on two or more sub-packages within a package. For example, in case a package is divided into say 6 sub-packages and each sub package consists of a single information unit, package processing unit 113 can be configured to compare 2 sub-packages (e.g. corresponding to speed and altitude) with respective 2 sub-packages in previous packages, instead of comparing the entire package.

Comparison instructions can be preconfigured in recording system 110. For example, comparison instructions can be stored in a designated data- repository (e.g. data-repository 123) being operatively connected to recording system 110 where processing unit 113 can be configured to receive this information from that data-repository at the onset of the recording operation. Comparison instructions can include for example, the division scheme of each type of package, the initial level, specific sub-packages that should be compared, etc.

In order to facilitate the comparison between a current package or parts thereof and a previous package and respective parts, package processor 113 can be configured to execute the same type of division (and/or translation) operation on both, the current and previous packages or parts thereof.

Reverting to block 210 in Fig. 2, a comparison process of incoming data packages with previous packages is illustrated. It should be noted that block 210 illustrates a non-limiting example of the comparison process and the specific stages of the comparison process may vary. Additional examples of comparison methods are described below with reference to Figs. 3 and 4.

At block 211, a current package is compared with one or more previously downloaded packages (e.g. from the same channel) and it is determined whether the current package contains new data.

Alternatively, one or more sub-packages within the current package can be compared with respective one or more sub-packages in one or more previous packages. To this end, before a comparison is executed, the relevant sub-packages are identified in the current package. The identified subpackages are compared with the respective sub-packages of the previous packages stored in computer memory 150. Identification of sub-packages can be carried out by package processing unit 113 (e.g. with the help of comparator 117) based on the division scheme of the package.

In some cases, comparison can be limited to packages which have been downloaded during a current recording session. The term recording session as used herein includes an operation of a composite system characterized by a predefined start event and end event. A recording session can be defined according to different criteria such as for example operation of a composite system during a predefined period of time or during a specific activity (e.g. a certain flight mission of an aircraft). For example, in case system 101 is an aircraft, a package can be compared with previous packages which were recorded during the current flight (being the current recording session) and not with packages recorded during previous flights. In case it is determined that a previous package (stored in computer memory 150) contains identical data to the data within a current package, the current package is not forwarded to database server 130 and can be discarded or ignored (block 219). In some cases, one or more timestamps indicative of a time and/or date in respect of the current package can be recorded in database server 130. A time stamp can indicate for example, the time and/or date the current package has been received by recording system 110. Recording system 110 can then proceed to process the next incoming package (block 201).

In case it is determined that the current package, (or one or more of its sub-packages), is different than the one or more previous packages stored in computer memory 150 (i.e the current package comprises new data) the process turns to identifying the information units within the current package (block 213). Alternatively, in case only specific one or more sub-packages of the current package were compared, the process turns to identifying the information units within the specific sub-packages which contain new data. Identification of the individual information units can be accomplished by package processing unit 113 with the help of the respective division scheme. Identification of information units can be carried out, for example, with the help of sub-package analyzer 120.

As explained above, each information unit consists of one or more bits in the packages which represent a certain binary value. The binary value represents a respective operational data. At block 215, before the data is sent to database server 130, information units are translated into respective operational data values. Translation of binary values can be accomplished with the help of translation rules (stored for example in data-repository 123), which enable to convert a given binary value to the respective operational data which is represented by this value. The translation of an information unit within a package (or with one or more sub-packages) to the corresponding operational data is performed based on the location of the bits which constitute the information unit within the package and the binary value of the information unit, as was demonstrated above by the light command example. Translation of the information units into respective operational data can be accomplished for example with the help of translator (119).

It should be noted that in an alternative approach, the information units can be translated into operational data values before the comparison process and the operational data values can be used during the comparison process instead of the binary values of the operation units.

Once the operational data is available, the operational data is transmitted to database server (block 217) possibly together with a respective one or more timestamps and additional metadata. As only packages which contain new data undergo the processing in accordance with blocks 213 to 217, less data is being processed and less data is being inserted into database server 130. As a result, the time which is required for inserting operational data into database server 130 is considerably reduced, while no data is lost. In addition, as only new data is inserted in the database, the operational data which is recorded is in effect being compressed and accordingly takes less storage space. Thus, the storage space which is required for storing operational data is reduced and a greater amount of operational data can be stored in a storage unit of a given size.

At block 221 the data stored in computer memory 150 is updated. In case only one previous package is stored in computer memory 150 and it is determined that the current package is different than the previous package, the current package is stored in computer memory 150 in place of the previous package and the previous package can be deleted from computer memory 150. In case a number of packages are stored in computer memory 150, the current package can be stored in computer memory 150 in place of one of the stored packages (e.g. the oldest package) or in addition to the stored packages.

In case it is determined that the current package is the same as a previous package stored in the computer memory 150, according to one example, the current package can be deleted from computer memory 150 and only a timestamp of the current package is recorded. As mentioned above, the time stamp can be indicative for example, of the time and/or date the current package (i.e. the last package) was received by recording system 110.

New operational data which is transmitted to database server 130 is inserted into database 133 which can be for example a relational database. Insertion of data into database 133 can be accomplished for example with the help of DBMS 131.

If data recording continues, the process turns to the processing of the next incoming package which is intercepted from communication in system 101 Database server 130 can be configured to index the downloaded packages according to a predefined indexing scheme to enable faster retrieval of the stored data (block 225).

Operational data which is stored in database server 130 can be analyzed. Owing to the presently disclosed subject matter, which enables to reduce the time which is needed for storing new operational data in database server 130 the analysis of the stored operational data can be performed substantially in real-time (block 227).

Comparison of current and previous packages can be based on multiple comparisons of one or more of the sub-packages, each comparison corresponding to a different division-level. The first comparison can start at any division-level (an initial division-level) and the last comparison can be at any division-level as well (a terminal division-level).

In some cases, after an entire package is compared with a respective previous one or more packages and it is determined that the current package contains new data, additional comparisons between sub-packages within the current package are made with respective sub-packages in the one or more previous packages. A sub-package which contains new data and comprises more than one information unit can be further divided into additional subpackages of a higher level and undergo additional comparisons with respective sub-packages of previous packages stored in computer memory 150.

This comparison mechanism enables to identify one or more specific sub-packages in the current package which contain new data and send only these sub-packages to the database server 130 instead of sending the entire package. As a result, the amount of data which is transferred to and processed by database server 130 is further reduced and the time which is needed for recording information in database server 130 is reduced as well.

Continuing to Fig. 3 which is a flowchart illustrating another example of operations carried out in a comparison process, in accordance with the presently disclosed subject matter. Fig 3 is an additional non-limiting example of an implementation of the operations described above with reference to block 210 in Fig. 2. Operations described with reference to Fig. 3 can be carried out, for example, by packages processing unit 113.

At blocks 301, 303 and 305 similar operations to the operation described above with reference to blocks 211, 219 and 213, respectively, are performed. At block 307 all or part of the identified information units are compared with respective information units in the one or more previous packages stored in computer memory 105, and it is determined which of the information units contains new data. Any information unit which does not contain new data is discarded and is not sent to database server 130 (block 309). In some cases a time stamp of a discarded information unit is maintained and stored in database server 130 in order to indicate, for example, when the last information unit of a given type was received. Operations described with reference to block 307 can be carried out for example with the help of sub-package analyzer 120.

Otherwise one or more information units which contain new data are translated into their respective operational data values e.g. with the help of translator 119 (block 311). The operational data values are transmitted to database server 130, where they are stored (block 313). As was explained earlier with reference to block 221 in Fig. 2 the data stored in computer memory is updated (block 315).

Note that according to the example disclosed with reference to Fig. 3 specific information units which comprise new data are identified and only these information units, rather than the entire packages, are translated into respective operational data which is stored in database server 130. This enables to further reduce the processing time which is required for recording operational data in database server 130.

In some cases, only if the difference between a given operational data value translated from an information unit of a current package and operational data value translated from a respective information unit of a previous package, is greater than a predefined threshold, the operational data is forwarded to database server 130. Consider for example a subsystem which is configured to monitor the temperature of an engine. The heat sensor which is used by this subsystem can be a micro sensor having high sensitivity, sensing temperature changes of a fraction of a degree. However, in practice only a change in the engine temperature which is equal or greater than 1 degree is considered a significant change which is relevant for operational purposes. Thus, in some cases, although an incoming information unit contains values which are different than the values of information units of a previous package, the actual difference between their operational data values may be smaller than one degree and therefore insignificant. It would be therefore advantageous to forward to database server 130 only operational data which is significantly different than previously stored operational data and thereby further reduce the load on database server 130.

In order to ascertain that only operational data which is significantly different than previously stored operational data, after information units are translated into corresponding operational data (block 311) the operational data values can be compared with corresponding operational data values of information units in the previous one or more data packages. It can then be determined whether the difference between the current operational data values and respective previous operational data values is greater than a predefined threshold. Only if the difference is greater than the prescribed difference the operational data is transmitted to database server 130 Otherwise, the operational data is discarded and optionally one or more respective time stamps are stored instead.

Proceeding to Fig. 4, a block diagram illustrates another example of operations carried out in a comparison process, in accordance with the presently disclosed subject matter. Fig 4 is another non-limiting example of a possible implementation of the operations described above with reference to block 210 in Fig. 2. Operations described with reference to Fig. 4 can be carried out, for example, by packages processing unit 113.

At block 401 data entities, including the received package or one or more of its sub-packages, which correspond to a current division-level, are compared with respective data entities in one or more previous packages stored in computer memory 150. Based on this comparison, it is determined whether any one of the data entities contains new operational data. As explained above, depending on the specific configuration of processing unit 113, the entire current package can be compared with one or more previous packages, or, alternatively, one or more sub-packages within the current package can be compared with respective one or more sub-packages in one or more previous packages.

The first comparison begins at a predefined "initial level" level, as explained above. As further explained above, optionally, only specific one or more sub-packages in a given division level, are compared with respective sub-packages of the previous one or more packages.

A data entity (e.g. packages or sub-packages) which does not contain new operational data is discarded and is not sent to database server 130 (block 403). In some cases a time stamp of the current package is stored in order to indicate for example, when the last package was received (arrow connecting block 403 to block 413).

Otherwise in case it is determined that any one of the compared data-entities contains new data, the process proceeds to block 405. At block 405 it is determined whether a terminal division-level has been reached. As used herein the term "terminal division-level" or "terminal level" refers to a predefined last division- level. Once a current package is divided into components comprising a specified terminal division-level, no additional divisions are made. A "terminal level" parameter can be stored and made available to packages processing unit 113 as part of the comparison instructions described above. Operations described with reference to blocks 401 to 405 can be performed, for example, with the help of comparator 117.

In case it is determined that the terminal level has not yet been reached, the process proceeds to block 407, where data entities (including the current package or sub-packages thereof) which contain new data are divided into smaller sub-packages corresponding to the next division-level. The process then returns to block 401 where the comparison process is repeated. The operation in blocks 401 to 407 is repeated until the terminal level is reached.

Referring to the example illustrated in Fig. 5, consider for example that the predefined initial level is division-level 0 and the predefined terminal division-level is level 2. In such cases, the operations in block 401 will be repeated 3 times at the maximum. In the first comparison, the entire current package (i.e. division-level 0) is compared with the one or more previous packages. In case new data is found in the current package, the package is divided to its division-level 1 sub-packages. In the second comparison, division-level 1 sub-packages are compared with division-level 1 subpackages within the previous one or more packages. In the last comparison any division-level 1 sub-package which contains new data is further divided into division-level 2 sub-packages and the division-level 2 sub-packages are compared with division-level 2 sub-package within one or more previous packages. In case a sub-package is an information unit, it is not divided any further.

In case it is determined that the terminal level has been reached, no further divisions are made and the process proceeds to block 409. At block 409 information units within data entities which contain new data are identified. The identified information units are translated into their respective operational data, with the help of the translation rules (block 411) and the operational data is transmitted to recording database server 130 and stored therein. Operations described with reference to blocks 407 and 409 can be performed, for example, with the help of sub-package analyzer 120.

As described above with reference to Fig. 3 in some cases only operational data which is significantly different than previously stored operational data is transmitted to database server 130. In order to ascertain that only operational data which is significantly different than previously stored operational data, after information units are translated into corresponding operational data (block 411) the operational data values can be compared with corresponding operational data values of information units in the previous one or more data packages. It can then be determined whether the difference between the current operational data values and respective previous operational data values is greater than a predefined threshold. Only if the difference is greater than the prescribed difference, the operational data is transmitted to database server 130. Otherwise, the operational data is discarded and optionally one or more respective time stamps are stored instead.

As mentioned above, operational data which is recorded and stored can be used for analyzing the performance of a monitored composite system. Monitoring operational data generated by operating imits (e.g. subsystems) in a composite system can help to detect operational data which is indicative of one or more operating units in the composite system that their performance deviate from an expected or desired performance.

To this end, the operational data of one or more monitored operating units in a monitored composite system is compared to predetermined operational profiles. Each operational profile includes one or more reference values. As used herein the term “reference values” represents acceptable values of operational data parameters which represent proper operation of a given operating unit.

For example, operational profiles of an engine subsystem can include reference values indicating a range of engine temperatures (temperature being an example of operational data parameters) which is considered safe and an operational profile of a hydraulic pump subsystem can include reference values indicating a range of pressure values (pressure being another example of operational data parameters) in the pump which is considered safe.

According to the presently disclosed subject matter, operational data of different operating units in a monitored composite system can be compared in real-time to predetermined operational profiles, in order to ensure the operating units operate properly, detect abnormal performance and allow taking appropriate measures in case such performance is detected. As explained above, one obstacle exists in real-time monitoring of operating units in a composite system, due to the large amount of data which is being generated and the difficulty in storing this data in a database in real-time.

In addition, operational data of different operating units in a monitored composite system can be analyzed and compared to predetermined operational profiles in off-line mode in order to examine the performance of operating units in retrospect.

Commonly today, monitoring systems, configured to monitor the operation of composite systems (e.g. a system for monitoring the operation of an aircraft), use reference values which are supplied by the manufacturer of a specific operating unit . However, the reference values which are provided by the manufacturers provide only limited information which may be inadequate for monitoring the respective operating unit.

For example, the reference values which are provided by the manufacturer are often limited in scope as they typically address only part of the different operating units in composite subsystems.

Furthermore, in some cases reference values which are provided by the manufacturer with respect to a certain operating unit are measured in certain operational-conditions which are different than the desired operational conditions in which the operating units operates in reality.

This results from a number of reasons. Firstly, operating units are sometimes monitored and tested while operating independently and not after being assembled in a composite-system. Secondly, even where operating units are monitored and tested after being assembled in a composite-system, the type of the composite system in which the operating unit is tested may not be the same type of composite system in which the operating unit is operated in actual operation by the user. The term “type” as used herein with respect to a composite system or an operating unit can be broadly interpreted as the functionality of a respective composite systems or operating unit (e.g. all aircrafts are of the same type and all engines are of the same type) or can be interpreted to include more specific characteristics of a respective composite system or operating system in addition to its functionality. The characteristics can include for example one or more of: specific brand, specific model, specific batch, etc.

For example, assuming a certain subsystem was originally manufactured to operate in a certain type of aircraft (e.g. fighter plane) and in reality it is assembled and used in a different type of aircraft (e.g unmanned aerial vehicle) the reference values provided by the manufactures, which are based on testing of the engine subsystem made in the first type of composite system, may not be adequate for monitoring the operation of the subsystem in the second type of aircraft.

Furthermore, when an operating unit is tested in a composite system, it may be integrated in the composite system together with other operating units which are different than the operating units which are integrated in the composite system which is used in actual operation. As the interaction between the different operating units within the composite system can affect the operation of individual operating units, the reference values which are obtained when testing an operating unit while operating in combination with one set of one or more operating units, may be significantly different than the reference values which are obtained while operating the tested operating unit in combination with a different set of one or more other operating units. In such cases, the reference values which are determined based on measurements made in a first type of operational conditions may be inadequate or insufficient for monitoring the respective subsystem when operated in other operational conditions.

In addition to the above, as a result of an excessively conservative approach which may be adopted by the manufacturer, the operational profiles which are provided by the manufacture specify reference values which are too strict while operating units may be used in more extreme conditions than those recommended by the manufacturer (e.g. higher altitude, colder/warmer temperatures, faster speed and so forth).

It is therefore often advantageous and sometimes necessary to generate operational profiles for different operating units in a composite system, based on operational data which is recorded and stored during the actual operation of operating units in the desired operational conditions.

According to the teaching disclosed herein, in order to generate the required operational profiles, operational data which is recorded during the actual operation of operating units of a given type in the desired operational conditions, are recorded and stored in a database. This data is then statistically analyzed to calculate new reference values representing acceptable operational data parameter values which match the desired operational conditions. The desired operational conditions include for example recording operational data of an operating unit of a given type, operating in a specific type of composite system and/or possibly together with a predefined combination of one or more other operating units of other respective types. Operational conditions can also include other parameters of a mission such as average flying height of an aircraft or average speed of any vehicle, maximal depth of an underwater vehicle etc.

The calculation of new operational profiles comprising new reference values requires that the size of the available operational data (the sample size) is large enough to allow statistical analysis which provides statistically significant results. In general, there is a connection between the amount of operational data which is available in the database and the accuracy and quality of the results of the analysis of this data.

As mentioned above, composite systems often generate large amounts of operational data which require very large storage space. For instance, a flight mission of an aircraft can generate around 700 Gigabytes of operational data. This means that a database of around a few Terabytes is required in order to store operational data performed during 10 flights. Thus, in addition to the problem of translating and inserting recorded operational data to a database in real-time, which was discussed above in detail, as a result of the large amount of data that is being generated during the operation of composite systems, the ability of previously known recording systems to store operational data in a database is limited.

Due to these problems, systems for monitoring the operation of operating units in composite systems have a limited ability to statistically analyze the data and generate operational profiles, and as a result have a limited ability to effectively analyze real-time operational data.

In contrast, the presently disclosed subject matter provides a novel data recording and compression technique which enables to compress recorded operational data by a few orders of magnitudes and to store a larger size of operational data in a database (e.g. a relational database) of a given size. The proposed recording and compression (described above with reference to figs. 1 to 5) technique enables to store in a database compressed operational data of a significantly greater number of recording sessions than equivalent uncompressed operational data.

For example, operational data generated during a single recording session (e.g. a single flight) which is of a total of around 700 Gigabytes (including operational data generated by all operating units in the aircraft) can be compressed by two orders of magnitude to around 3-6 Gigabytes. Thus, with the help of the presently disclosed subject matter, operational data which is greater in volume by at least two orders of magnitude than the uncompressed operational data can be stored in a database of a given size. For example, a database of a 7 Terabytes which can be used for storing operational data recorded during 10 flights (each flight generating operational data of around 700 Gigabytes) can be used for storing compressed operational data from more than 1000 flights.

As the recording and compression system disclosed herein enables to store in a database of a given size a significantly greater amount of operational data, operational data of a much greater number (possibly all) of operating units in a composite system can be recorded and stored in a database, enabling to monitor more operating units, operating in a composite system.

Fig. 6 is a functional block diagram schematically illustrating a non-limiting example of system-architecture of operational data analyzing system 600, according to the presently disclosed subject matter. System 600 comprises an operational data analyzer 160 which is operatively connectible to a database, storing operational data. In the non-limiting example illustrated in Fig. 6 operational data analyzer 160 is connected to database server 130 described earlier with reference to Fig. 1. As explained above, database server 130 is configured for storing operational data which is recorded and compressed by recording system 110.

Operational data analyzer 1 0 is configured to analyze the operational data which is stored in database 131. Operational data analyzer 160 can be configured to statistically analyze different operational data values, stored during the operation of different operating units and based on this analysis to calculate reference values and generate operational profiles of the respective operating units. The calculated reference values and operational profiles can be stored in a designated data repository (e.g, operational profiles data repository 170).

Operational data analyzer 160 can be used to use the operational data values which were obtained during recording sessions in the desired operational conditions, and enable to set reference values, which are suitable for monitoring a composite system in the same operational conditions System 600 can further comprise monitoring unit 180. Alternatively, monitoring unit can be configured as a separate unit which is operatively connected to database 170. Monitoring unit 180 is configured to monitor the operation of one or more operating units operating in a composite system. Monitoring unit 180 can be connected to one or more composite systems (e.g. system 101) and/or to recording system 110 and be operable to receive operational data which is recorded in real-time. The real-time operational data of a given operating unit is analyzed by monitoring unit 180 and compared to respective operational profiles of the respective type of operating unit, stored in data repository 170.

By comparing between the measured operational data values and the stored reference values, monitoring unit 180 can identify a deviation of the measured operational data value from respective reference values and determine whether this deviation is indicative of abnormal performance of respective monitored operating units. Monitoring unit 180 can be further operable to determine whether the abnormal performance is within an expected tolerance or whether it is indicative of a problem which is currently occurring and/or of a potential problem which may occur in the future.

In case a discrepancy is found between the measured values and respective reference values, which are specified in a respective operational profile, preventative measures can be initiated. For example, an alert can be activated to indicate to an operator that a certain operating unit is entering a danger zone. Or, in another example, one or more operating units in a monitored composite system can be automatically controlled (in some cases it can be completely shutdown) in order to adjust the relevant operational parameters and avoid damage.

Fig. 7 is a flowchart illustrating operations performed, in accordance with the presently disclosed subject matter. The operations described below with reference to Fig. 7 can be executed for example by the system illustrated above with reference to Fig. 6.

According to the presently disclosed subject matter pre-recorded operational data recorded during the operation of one or more composite systems is made available for analyzing. As explained above, during the operation of a composite system, data packages which are communicated between different operating units operating within the composite systems are recorded (block 701). The packages are translated and the corresponding operational data, indicative of the operation of different operating units, is obtained from the packages. The operational data is then stored in a database (block 703).

The operational data can be compressed before it is stored in the database thereby enabling to store more operational data in a database of a given size.

As explained above in order to allow data analysis with significant statistical results, a large enough amount of operational data must be available. This can be accomplished, for example with the help of the recording and compression technique which is described above (with reference to Figs. 1 to 5) and enables to compress the recorded operational data by a ratio of at least 2 orders of magnitude, with respect to the uncompressed data, and accordingly store in a database of a given size operational data which is generated over time during a greater number of recording sessions.

As mentioned above, the operational data of the different operating units is recorded during the operation of the composite system and therefore operational data of plurality (and possibly all) operating units in the composite system can be made available to operational data analyzer 160. The stored operational data is automatically analyzed by a computer system (e.g. with the help of operational data analyzer 160) and used for automatically generating operational profiles, each including reference values indicative of acceptable operational data parameter values of a respective operating unit of a given type (block 705). Operational profiles can be stored in a designated data repository.

According to the presently disclosed subject matter, analysis of the operational data of a given operating unit of a given type and subsequent generation of a respective operational profile can be based both on operational data indicative of the specific operation of the given operating unit (e.g. subsystem) as well as the operational data indicative of the operation of at least one other operating unit of a different type, operating in the same composite system.

Thus, during the analysis of the operation of a given operating unit, the relation and interaction of the given operating units with other operating units operating together in the same composite system is considered. The relation between the operational data from two (or more) different operating units, each of a different type, in a given composite system may provide new operational data with respect to at least one of the operating units. The new operational data deduced from the relation between operational data of two or more operating units can include new information, with synergic quality, which goes beyond the mere combination of operational data of the individual operating units.

Consider for example, a GPS subsystem, operating in an aircraft, which provides operational data indicating when the GPS is operable and when it is not. A GPS can become inoperable as a result of a malfunction in the GPS subsystem. Alternatively, a GPS can become inoperable as a result of an aircraft maneuver which positions a part of the aircraft’s body between the GPS and the GPS satellites, thereby blocking the GPS signal.

In order to determine whether the GPS subsystem is working properly, it is desirable to check the relation between the inoperability of the GPS and the attitude of the aircraft. In accordance with the presently disclosed subject matter, operational data obtained from the GPS subsystem, which is indicative of the operation of the GPS can be analyzed in combination with operational data obtained from an INS and/or an IMU subsystem indicating the pitch, yaw and roll angles of the aircraft. Based on this analysis, it can be determined when the GPS subsystem is actually malfunctioning and when inoperability of the GPS subsystem is a result of GPS signal blockage by the body of the aircraft. A respective operational profile of the GPS subsystem operating in the specific composite system can be generated indicating in which attitude angles the GPS signals are blocked by the body of the aircraft.

Note that the operational data which is obtained with respect to the GPS subsystem provides new information which goes beyond the mere combination of operational data with respect to the GPS system and operational data with respect to the aircraft’s attitude.

As different aircraft have different structures and GPS subsystems are installed and operate differently in different aircraft, the relation between the GPS subsystem and the attitude of the aircraft has to be determined individually for different types of aircrafts and often it cannot be based on information obtained during the operation of other types of aircrafts. Accordingly, it is required to repeat this analysis for different aircraft and generate an operational profile for the GPS subsystem which is composite-system-specific.

Another example relates to the fuel consumption of an engine subsystem in an aircraft. It is important to monitor the fuel consumption of an operating composite system and determine whether the detected fuel consumption is within normal values or whether it is indicative of excessive consumption. To this end, a fuel subsystem is monitored and the fuel consumption rate is compared to expected fuel consumption values.

However, it can be difficult to determine what the acceptable fuel consumption rate is. As the manufacturer of the engine does not know the operational conditions in which the aircraft will be operating, he cannot accurately predict acceptable fuel consumption for the engine subsystem. For example the manufacture does not know: in which type of aircraft the engine is assembled, what is the weight of that aircraft, what type of other subsystems which are assembled in the aircraft which may add drag to the aircraft, at what height the aircraft will fly, etc.

According to the presently disclosed subject matter, this entire information can made available and considered by data analyzer 160 when the operational profile of the engine subsystem is being generated. The generated operational profile, which indicates acceptable fuel consumption values, is specifically tailored to the conditions in which the engine subsystem is operating and is therefore much more dependable.

Once one or more operational profiles are available they can be utilized during operation of a given type of composite system in order to monitor the operation of one or more respective operating units in the composite system and identify deviations of the operating units from acceptable operation. As described above, during operation of a composite system, real-time operational data is obtained from one or more operating units in the composite system (block 707). The real-time operational data is recorded and stored in a designated database. The real-time operational data includes measured operational data values indicative of real-time operation of a respective operating unit in the monitored composite system.

Real-time operational data recorded during the operation of a composite system can be analyzed and compared to respective operational profiles in real-time while the composite system is operating, or in offline mode in order to debrief the operation of the composite system.

As explained above in detail, insertion of recorded operational data in real-time, which is required in order to enable real-time analysis of the recorded operational data, is enabled with the help of the compression technique specified above, which considerably reduces the amount of data which is required to be inserted into the database.

The real-time operational data can also be used by operational data analyzer 160 as additional operational data for augmenting the previously calculated operational profiles.

The measured operational data values of one or more monitored operating units in a monitored composite system are compared to respective operational profiles (block 709). The comparison enables to determine whether a discrepancy exists between one or more real-time measured operational data values and the respective reference values (block 711).

At block 713, in case a discrepancy is found, it is determined whether the identified deviation matches a predefined criterion in order to determine whether it is indicative of an occurring operational problem or a potential future problem. For example, the criterion can be a predetermined threshold or an acceptable range of values. In case it is determined that the identified deviation is indicative of a current problem or a future problem, appropriate preventative measures are initiated, as exemplified above.

It will also be understood that the system according to the presently disclosed subject matter may be a suitably programmed computer. Likewise, the presently disclosed subject matter contemplates a computer program being readable by a computer for executing the method of the presently disclosed subject matter. The presently disclosed subject matter further contemplates a machine-readable memory tangibly embodying a program of instructions

Claims (27)

224493/3 45 Claims:

1. A method of monitoring a composite system comprising a plurality of operating units characterized by respective types, the method comprising, using a processor for: obtaining pre-recorded operational data which has been pre-recorded during operation of an at least one composite system; the operational data comprising operational data values indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system; generating at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated by statically analyzing the pre recorded operational data and thereby obtaining the reference values; obtaining real-time operational data recorded during operation of the monitored composite system; the real-time operational data including real-time operational data values indicative of operational data parameters of a monitored operating unit in the monitored composite system, the monitored unit characterized by a given operational unit type; determining whether a deviation exists between real-time operational data of the monitored operating unit and an operational profile corresponding to the given operational unit type.

2. The method according to claim 1 wherein in case a deviation exists, determining whether the deviation complies with a predefined criterion.

3. The method according to claim 2 further comprising: taking preventive measures in case the deviation complies with the predefined criterion.

4. The method according to claim 3 wherein the preventive measures include at least one of: activating an alert; and 224493/3 6 automatically controlling the operation of the monitored operating unit.

5. The method according to any one of the preceding claims further comprising: compressing the recorded operational data; storing the compressed operational data in a database; and obtaining the operational data from the database.

6. The method according to claim 5 wherein the compressing enables to compress the recorded operational data by at least 2 orders of magnitude.

7. The method according to claim 5 wherein the compressing enables to compress the recorded operational data by at least 3 orders of magnitude.

8. The method according to claims 1, wherein the obtaining comprises: receiving a package, generated during operation of the at least one composite system; the package comprising one or more information units, each information unit is characterized by a value corresponding to a respective operational data; and inserting to a database operational data corresponding to the package or part thereof, only if the package or part thereof is different than one or more previous packages or respective part thereof, stored in a computer memory.

9. The method according to claim 8 further comprising: in case the package or part thereof is different than one or more previous packages or respective part thereof and prior to the inserting: identifying the one or more information units in the package; for at least one information unit of the one or more information units: inserting to the database, operational data corresponding to the at least one information unit, only if a value corresponding to the at least one information unit is different than a value of one or more respective information units of the same type, in the one or more previous package stored in the computer memory. 224493/3 7

10. The method according to claim 1 wherein the at least one composite system and the monitored composite system are of the same type.

11. The method according to claim 1 wherein the at least one operational profile includes operational data which goes beyond the mere combination of pre recorded operational data related to respective operating unit type and on pre-recorded operational data related to at least one other operating unit type.

12. The method according to claim 1 wherein the determining is performed in real-time in order to monitor the performance of the monitored composite system during real-time operation.

13. The method according to claim 1 wherein the at least one operational profile includes a maximal operational data value and a minimal operational data value which characterize an acceptable range of operational values during operation of a respective operating unit.

14. The method according to claim 1 wherein the operational data is recorded during a plurality of real-time recording sessions of the at least one composite system.

15. The method according to claim 1 wherein the composite system is an aircraft.

16. The method according to claim 1 wherein said operational unit type includes one or more of: an operating unit brand; an operating unit model; and an operating unit batch.

17. A system of monitoring a composite system comprising a plurality of operating units characterized by respective type, the system comprising: at least one processor operatively connected to a non-transitory storage medium, the non-transitory storage medium storing machine instructions for causing the at least one processor to perform operations comprising: obtain pre-recorded operational data, pre-recorded during operation of an at least one composite system; the operational data comprising operational data values 224493/3 8 indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system; generate at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated by statistically analyzing the pre recorded operational data and thereby obtaining the reference values; obtain real-time operational data recorded during operation of the monitored composite system; the real-time operational data including real-time operational data values indicative of operational data parameters of a monitored operating unit in the monitored composite system, the monitored unit characterized by a given operational unit type; determine whether a deviation exists between real-time operational data of the monitored operating unit and an operational profile corresponding to the given operational unit type.

18. The system according to claim 17 wherein the operations further comprise: determine, in case a deviation exists, whether the deviation complies with a predefined criterion; and take preventive measures in case the deviation complies with the predefined criterion.

19. The system according to any one of claims 17 to 18 wherein the operations further comprise: compress the recorded operational data; and store the compressed operational data in a database.

20. The system according to claim 19 wherein the compressing enables to compress the recorded operational data by at least 2 orders of magnitude.

21. The system according to claim 17, wherein the operations further comprise: storing the operational data in the database, comprising: 224493/3 9 receive a package comprising one or more information units, each information unit is characterized by a value corresponding to a respective operational data; and insert to a database operational data corresponding to the package or part thereof, only if the package or part thereof is different than one or more previous packages or respective part thereof, stored in a computer memory.

22. The system according to claim 21 wherein the operations further comprise: in case the package or part thereof is different than one or more previous packages or respective part thereof and prior to the inserting: identify the one or more information units in the package; for at least one information unit of the one or more information units: inserting to the database, operational data corresponding to the at least one information unit, only if a value corresponding to the at least one information unit is different than a value of one or more respective information units of the same type, in the one or more previous packages stored in the computer memory.

23. The system according to claim 17 wherein the at least one operational profile includes operational data which goes beyond the mere combination of pre recorded operational data related to respective operating unit type and on pre-recorded operational data related to at least one other operating unit type.

24. The system according to claim 17 wherein the composite system is an aircraft.

25. A method of monitoring a composite system comprising a plurality of operating units characterized by respective types, the method comprising, using a processor for: obtaining at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated by statically analyzing the pre recorded operational data and thereby obtaining the reference values; 224493/3 -50- obtaining real-time operational data recorded during operation of the monitored composite system; the real-time operational data including real-time operational data values indicative of operational data parameters of a monitored operating unit in the monitored composite system, the monitored unit characterized by a given operational unit type; determining whether a deviation exists between real-time operational data of the monitored operating unit and an operational profile corresponding to the given operational unit type.

26. The method according to claim 25 further comprising: obtaining the pre-recorded operational data, pre-recorded during operation of an at least one composite system; the operational data comprising operational data values indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system.

27. A non-transitory program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform a method of monitoring a composite system comprising a plurality of operating units characterized by respective types, the method comprising: obtaining pre-recorded operational data, pre-recorded during operation of an at least one composite system; the operational data comprising operational data values indicative of one or more operational data parameters with respect to two or more operating unit types in the at least one composite system; generating at least one operational profile corresponding to a respective operational unit type, the operational profile comprising reference values which are indicative of acceptable operational data parameters of a corresponding operating unit type, wherein the operational profile is generated by statically analyzing the pre recorded operational data and thereby obtaining the reference values; obtaining real-time operational data recorded during operation of the monitored composite system; the real-time operational data including real-time operational data values indicative of operational data parameters of a monitored