Identifying cyclic patterns of complex events

Data within a database are displayed to discover patterns of events in time-based data. A first display of a linear timeline indicating events within time-based data is provided. The linear timeline of the first display may be transformed into a second display to cluster the events within the time-based data, where the second display includes one or more from the group of a stacked linear timeline of the events, a polar (annular) timeline of the events, and a helical timeline of the events. Patterns of the events are revealed within the second display to identify event associations.

BACKGROUND

Present invention embodiments relate to manipulating states of data graphics, and more specifically, to manipulating states of time series data graphics to reveal event cycles.

Analysis of data or data analytics is a process of examining raw data to obtain useful information. For example, current techniques to explore time series data include examining multiple data displays or timelines. However, these techniques are laborious processes, and a user may not recognize certain insights when specific displays presenting the time series data have the data grouped differently or use different time scales.

SUMMARY

According to one embodiment of the present invention, patterns of events are revealed in time-based data. A first display of a linear timeline indicates events within time-based data. The linear timeline of the first display is transformed into a second display that presents clustering of the events within the time-based data, where the second display includes one or more from the group of a stacked linear timeline of the events, a polar timeline of the events, and a helical timeline of the events. Patterns of the events may be revealed within the second display to identify event associations.

Embodiments of the present invention further include a method, a system and computer program product for revealing patterns of events in substantially the same manner described above.

DETAILED DESCRIPTION

The techniques of present invention embodiments provide a mechanism to visually inspect and/or understand the nature of data using various forms of visualization that can be readily manipulated. In particular, the temporal nature of events by type may be analyzed to gain insight or information about the ongoing operations (of a business, system, or other entity) and then enable a decision maker to make more well informed decisions. In many cases, the decision may be automated using an event-rule combination. In this regard, an event may be considered a signal or series of signals that indicate a change of state has occurred in a given system, while a rule may be a logic statement that indicates that a decision should be made or that an action should be taken. For example, a rule may be that if a bank account goes below a certain balance, then notify the account owner. Accordingly, when an event such as a bank account withdrawal results in the bank account going below the certain balance, the rule is triggered and the bank account owner is notified.

A decision system may use distributed, autonomous rule processing components referred to as “agents.” The agents may be deployed at, and receive information from, various locations (e.g., from sensors in a sensor network). Receipt of an event message by an agent may cause the agent to fire or start to execute one or more rules. These rules process information that may be included in the payload of the message and initiate actions, if any, selected by the logic of the one or more rules. These actions may include firing other event messages or initiating additional processing by application components and services (e.g., as prescribed as part of the decision system).

A rule analyst (or other user) may be responsible for authoring, debugging, and improving the set of rules that drive decisions. When troubleshooting complex business or other events, these users need to understand the flow of events that lead to particular outcomes. The factors affecting outcomes and performance may not be completely understood, so the user may need to explore multiple hypotheses in order to identify problems or ways in which sets of rules may be improved. Accordingly, decision systems can be applied to a vast number of business or other problems, in a wide variety of domains such as financial services, transportation, banking, and healthcare, to name just a few. To provide an illustrative example, an air transportation system is described herein as an example application and it should be understood that the concepts described apply to many other domains.

Since these decision systems process events, the time and place of the events may be particularly important to the decision making processes. In other words, the time (e.g., the temporal nature of the event), as well as the place (e.g., the spatial or geolocation of the event) may have an impact on the best decision to make or rule to execute. A decision system typically includes a vast number of components interacting in real time. There may be hundreds or thousands of agents of various types and a similarly large number of objects (e.g. people, airplanes, airports, flight numbers, and so forth), and even greater numbers of events flowing through the system. The complexity of this system poses challenges in monitoring and analyzing the behavior of the system.

Time of day is a particularly important variable in the affairs of human beings. For example, in an air transportation example, flight traffic through airports usually begins around 6:00 A.M. with the first departures and often ends sometime around midnight with the last arrival, while overnight shipping services fly in the interim hours of the night. Other systems with events (e.g., e-commerce, hospital data systems, taxi cab dispatching, etc.) may have other patterns related to time of day. Some systems with events may also have feedback loops creating clusters of events at any number of intervals.

Approaches to debug event processing applications rely on log files and multiple data displays and timelines. However, the techniques of present invention embodiments described herein provide visualization transformations to provide a way of enabling monitoring of complex systems' behavior and for investigating cyclic or circadian patterns to readily identify problems, or so that processing rules can be improved. The present invention embodiments may be utilized for various scenarios (e.g., assist in debugging the event processing applications, monitoring system behavior, exploratory data analysis, etc.). Example display or visualization transformations are described below in connection withFIGS. 6-13.

The techniques of present invention embodiments described herein provide mechanisms for quickly transforming cyclic data displays to reveal temporal patterns. Present invention embodiments rapidly reconfigure data displays in order to enable identification (e.g., by a user or system) of patterns of events for subsequent analysis. The rapid transformation of the presentation of data allows the user (or system) to identity arbitrary patterns (e.g., anything that looks like a pattern). This enables a user to gather a deeper understanding of the nature of the data by allowing the data to be presented in different perspectives which may reveal patterns. The configuration of events in alternative displays may make patterns of events apparent to the user that were not discernable in one or more prior displays. The user (or system) may take action based on the pattern. For example, in the context of event processing applications (e.g., applications that act on events and patterns of events), revealing potential patterns enables development of rules to respond to identified patterns.

An example environment for use with present invention embodiments is illustrated inFIG. 1. Specifically, the environment includes one or more server or host systems10, and one or more client systems14. Host systems10and client systems14may be remote from each other and communicate over a network12. The network may be implemented by any number of any suitable communications media (e.g., wide area network (WAN), local area network (LAN), Internet, intranet, etc.). Alternatively, host systems10and client systems14may be local to each other, and communicate via any appropriate local communication medium (e.g., local area network (LAN), data center network, hardwire, wireless link, intranet, etc.). The environment inFIG. 1further includes a sensor or sensor network22that may include a plurality of nodes22(1)-22(N) coupled to host systems10and client systems14via network12. Sensor network22may include any type of sensor or other mechanism for detecting any types of events or conditions and generating and sending event or other messages.

Host systems10and client systems14may be implemented by any conventional or other computer systems preferably equipped with a display or monitor (not shown), a base (e.g., including at least one processor15, one or more memories35and/or internal or external network interfaces or communications devices25(e.g., modem, network cards, etc.)), optional input devices (e.g., a keyboard, mouse or other input device), and any commercially available and custom software (e.g., server/communications software, collection module, visualization module, browser/interface software, etc.).

Client systems14may receive user query information related to desired database information (e.g., events, rule sets, etc.) to query host systems10. In another example, the queries may be received by the hosts, either directly or indirectly. The host systems10may include a collection module16to collect event data (e.g., event type, location, time, etc.) from, for example, sensor network22. The host systems10may also include a visualization module20to transform visual displays from one form or type to another using data collected by collection module16(e.g., to switch from a linear timeline to a polar or stacked linear representation).

One or more components of the host systems10, network12and client systems14may comprise a database management system (DBMS) or database system18. The database system18may use any conventional or other database, or storage unit. Other DBMS components may be local to or remote from host systems10and client systems14, and may communicate via any appropriate communication medium such as network12(e.g., local area network (LAN), wide area network (WAN), Internet, hardwire, wireless link, intranet, etc.).

Any clients, hosts, or data servers may present a graphical user interface (e.g., GUI, etc.) or other interface (e.g., command line prompts, menu screens, etc.) to solicit information from users pertaining to rule sets, event data, queries, transforming visualizations and to provide results (e.g., query results, transformed visualizations, etc.). Further, these systems may provide reports to the user via the display or a printer, or may send the results or reports to another device/system for presenting to the user.

Alternatively, one or more hosts10or clients14may perform query processing when operating as a stand-alone unit. In a stand-alone mode of operation, the host/client stores or has access to the data (e.g., rule sets, event data, etc.), and includes collection module16to collect event data and visualization module20to allow transformation of event graphics that organize the event data collected by collection module16. The graphical user interface (e.g., GUI, etc.) or other interface (e.g., command line prompts, menu screens, etc.) solicits information from a corresponding user pertaining to rule sets, event data, queries, transforming visualizations and may provide reports (e.g., query results, transformed visualizations, etc.).

Collection module16and visualization module20may include one or more modules or units to perform the various functions of present invention embodiments described below. The various modules (e.g., collection module, visualization module, etc.) may be implemented by any combination of any quantity of software and/or hardware modules or units, and may reside within memory35of the host systems and/or client systems for execution by processor15. It should be understood, that the computing environment depicted inFIG. 1provides example platforms (e.g., host systems10, client systems14) for illustrating the techniques described herein. In this regard, data and database storage on one host10or client14may have no relationship with data and database storage on another host10or client14.

Sensor network22may contain sensors, nodes, or any other mechanism for recognizing an event, generating an event message, and sending the event message to a receiver (e.g., a collection agent may send an event message to collection module16). Continuing with the air transportation example mentioned above, consider a system with thousands of airplanes operated by airlines and individuals, numerous airports, and hundreds of air traffic controllers in an air traffic controller (ATC) system. When an aircraft operated by airline XYZ takes off (a takeoff event) or lands (a landing event) both the airline XYZ and ATC are interested in the takeoff and landing events of the aircraft. In other words, both the airline XYZ and ATC have data analysis systems for managing their respective domains. For example, airline XYZ is interested in revenue per passenger mile and on time arrivals, while ATC is interested in the safe flow of traffic across its network of controlled airports.

Thus, when an aircraft takes off, the event may be catalogued in several ways. In one example, one of the pilots radios the dispatcher for airline XYZ and the dispatcher generates a takeoff event for the aircraft. Similarly, the tower controller at the departure airport may enter a takeoff event into the control console, which is forwarded to the ATC system (e.g., by an event agent), thereby notifying en route controllers that the particular aircraft is airborne.

In another example, should the parties be properly equipped, the takeoff may be logged automatically. The aircraft has a switch in one of the landing gear struts (e.g., a squat switch) that detects whether there is weight on the wheels. When the plane lifts off, the weight of the aircraft is removed from the wheels and the gear strut (i.e., piston or shock absorber like structure) expands, thereby releasing the switch. Accordingly, at landing, the strut recompresses and activates the switch in the opposite manner. The aircraft systems can use the switch position and automatically signal both the airline dispatch and ATC (e.g., using a local digital radio link or a satellite uplink) without human interaction. One such system that is in use for automated signaling and/or aircraft parameter tracking is the Aircraft Communications Addressing and Reporting System (ACARS). Thus, the various mechanisms for detecting and logging the events may act as sensor nodes (e.g., sensor nodes22).

It should be noted, for purposes of illustration, that many types of sensors or sensor networks may be utilized (e.g., radiation sensors, weather sensors, fire or other disaster sensors, motion or presence sensors, diagnostic sensors, etc.). Accordingly, the techniques described herein may be applied to numerous scenarios.

A manner in which collection module16and visualization module20(e.g., via a host system10and/or client systems14) process event data for visual manipulation or visual transformation according to an embodiment of the present invention is illustrated inFIG. 2. Specifically, the process starts at step200, and at step210, event stream data are collected (e.g. by collection module16). The event stream data are stored (e.g., in database18) for analysis, either in real-time or at a later time. The event data collected at step210can be initially displayed in a variety of formats. A default display mode (format) is selected at step220. The default format may be preset into the system or a user may be prompted for the format.

As depicted inFIG. 2, the default display modes may be one of a linear or tickertape timeline230, a stacked timeline240, a linear histogram250, a radial histogram260, or a helical timeline270. Conceptually, the radial histogram may also be considered a polar or annular histogram. An example tickertape timeline is shown inFIG. 6, an example stacked timeline is shown inFIG. 7, an example linear histogram is shown inFIG. 12A, an example radial histogram is shown inFIG. 12D, and an example helical timeline is shown inFIG. 13, each as described below. The display modes described herein are by way of example, and other display modes may be used to accommodate the given system, event types and/or rules base (rule set).

Once the default display mode is selected, one mode may be transformed into another mode using gesturing techniques. For example, when a user has access to a display with a touch screen, a common gesture is to “spread” fingers apart to magnify a particular portion of the display or “squeeze” fingers together to compress a particular portion of the display. In some systems a “double tap” on the screen will cause a preset magnification at the double tap location or if the display is already magnified, the double tap will cause the display to return to the original magnification level. It should be understood that gestures may be provided along any axis (e.g., horizontal, vertical, diagonal/radial, polar, etc.) or for any rotational mode (e.g., bend, wrap, unwrap, unbend (straighten), etc.). Alternatively, the same gestures may be made by a standard or specialized pointing device (e.g. a mouse), or other device (e.g., a digitizer or drawing tablet). In addition, the actions associated with the gestures may alternatively be triggered by any type of input device (e.g., mouse, keyboard, voice recognition, touch screen, etc.). For example, a list of the gestures (or descriptions of the actions) may be presented, and the desired actions selected by any type of input device (e.g., mouse, keyboard, voice recognition, touch screen, etc.).

An example flow diagram illustrating a manner in which a first display is transformed into second display according to an embodiment of the present invention is illustrated inFIG. 3. In this example, a first display may start as the default display as described above, and a second display is generated from the first display.FIG. 3depicts the tickertape timeline230, stacked timeline240, linear histogram250, radial histogram260, and helical timeline270fromFIG. 2as example display modes that can be transformed from one display mode to another.

The upper portion ofFIG. 3depicts display mode transition possibilities from left to right, and the lower portion ofFIG. 3depicts display mode transition possibilities to perform the reverse display transformation. As viewed inFIG. 3, tickertape mode230may be transformed into stacked timeline240using a display type (or mode) transition310using a horizontal compress gesture as described above (e.g., squeezing fingers together horizontally on a touch screen interface to compress a particular portion of the display). Briefly, referring toFIG. 6a tickertape display230includes different event types232depicted by shading on a horizontal timeline with the earlier events leftmost and later events depicted to the right. The events are presented in the tickertape based on the time of their occurrence within the time interval.

Once tickertape230is compressed into stacked timeline240, the results are shown by way of example inFIG. 7. Transformed tickertape data are represented inFIG. 7, by way of example, in 24-hour intervals or days. For ease of illustration, it may be assumed that six days of data are included in the original tickertape data set. The data on the horizontal axis represents hours of a 24-hour time interval while units of days (or 24-hour intervals) are represented on the vertical axis (i.e., represented as days 1 to 6). The events are presented based on the time of their occurrence within the appropriate hours of each day. Accordingly, the earlier events inFIG. 7reside on the upper left of the figure and the events run from left-to-right and top-to-bottom to the later events on the lower right of the figure (e.g., via an event wrapping or modulus operation based on the time of day in the 24-hour interval).

The visualization of the stacked timeline shown inFIG. 7clusters events of the same type near a same time of day (or events at the particular time of day) across several days. For example, there appears to be a slight clustering of like events242just after both the zero hour and the 12thhour (e.g., as shown by solid bars as viewed from day one (top) to day six (bottom).

To reverse the display type transition performed at step310(e.g., made by a horizontal compression gesture), an expansion of the stacked timeline240back to a tickertape timeline230may be performed using a horizontal stretch gesture350(e.g., moving fingers apart on a touch screen interface, etc.). Alternatively, the stacked timeline240may be further compressed by a horizontal compression gesture as shown inFIG. 8. The example event graphic depicted inFIG. 8shows the stacked timeline ofFIG. 7(e.g., in 24-hour intervals or days) wrapped into 12-hour intervals. The data on the horizontal axis has been compressed into a 12-hour interval, while the vertical axis represents half-days or 12-hour intervals. The events are presented based on the time of their occurrence within the appropriate hours of each half-day. As inFIG. 7, the earlier events inFIG. 8reside on the upper left of the figure and the events run from left-to-right and top-to-bottom to the later events on the lower right of the figure via an event wrapping or modulus operation based on the 12-hour intervals.

Referring now toFIG. 9, the stacked timeline ofFIG. 8is depicted with a dashed box910surrounding a leftmost portion of the figure from the zero hour. As viewed inFIG. 9, a cluster of like events (e.g., as shown by solid bars) is concentrated in box910, while a similar concentration of like events is visually absent throughout the remainder of the figure. In this regard, the relative concentration of events may constitute an actionable event as determined by an analyst and/or the system (e.g., via a software agent (e.g., visualization module20) that assists in highlighting data anomalies).

By transforming the 24-hour stacked timeline as shown inFIG. 7into the 12-hour stacked timeline shown inFIG. 9, the minor concentrations of events (solid bars) shown inFIG. 7just after the zero hour and the twelfth hour become more pronounced as highlighted by dashed box910. Accordingly, the like events represented by the solid bars form a nexus at 12-hour intervals (i.e., the events have a 12-hour cyclic or circadian pattern) that may not be readily apparent (but perceivable) in the 24-hour view.

By way of example, the blank or white filled bars may represent an aircraft takeoff event, the hash filled bars may represent an aircraft landing event and the solid bars may represent an aircraft that has been delayed on the ground before takeoff (e.g., by a predetermined delay). Accordingly, as viewed inFIG. 9, many of the delayed aircraft tend to cluster at 12-hour (circadian) intervals.

The delayed takeoff events clustered at 12-hour intervals would likely suggest (e.g., to an analyst, system, etc.) that something is occurring every 12 hours that delays takeoff. At this point, additional data may be added to the stacked timeline (e.g., potential causes, or causation reports), while extraneous data may be removed (e.g., remove data pertaining to on time takeoffs and landings that are not issues for the airline). For example, the pilot may have to file a report as to why the aircraft was delayed. Some example causes may be: waiting on maintenance, waiting on food service, or that the fuel load was incorrect. These potential issues may be traced to their respective sources. In a simple example, it may turn out that maintenance shifts were improperly scheduled, thereby rendering a slow response to aircraft maintenance issues.

The visualization transform techniques described herein may be further used to transform the stacked timeline240into a linear histogram250by way of a vertical compress gesture (e.g., vertically squeezing fingers together on a touch screen interface, etc.) at step320(FIG. 3). An example linear histogram is depicted inFIG. 12A. The linear histogram depicts a frequency of events at a given time (e.g., a given time of day for a 24-hour interval) across the defined time interval. The events are presented based on the time of their occurrence within the appropriate hours, where events with the a common time of occurrence are stacked. As in the previous examples, a clustering of solid bars252may be discerned near the both the zero hour and the twelfth hour (e.g., as shown by solid bars). The linear histogram250may be transformed back to a stacked timeline by way of a vertical stretch gesture (e.g., vertically moving fingers apart on a touch screen interface, etc.) at step360. The linear histogram250may also be further compressed to reveal, perhaps, a more pronounced view of the data910fromFIG. 9.

Another transform of the linear histogram may be had by way of a bending gesture330. The bending gesture330may be made by a slight linear motion on a touch screen interface followed by curve motion toward the axis perpendicular to slight linear motion axis (e.g., as indicated above display transition step330). It should be understood that fingers operating in like form may be used to create a circular “wrapping” gesture. For example, the linear histogram shown inFIG. 12Amay be bent by a finger gesture designed to transform the linear histogram into a circular histogram. As the linear histogram is transformed, it starts to bend as shown inFIG. 12B, with a further bending moment depicted inFIG. 12C. When the gesture is complete enough for the system to “recognize” the desired end form, the display may “snap” to the radial histogram260and shown, by way of example, inFIG. 12D. The radial histogram260is basically a circular version of the linear histogram, and may be reverted back to a linear histogram by way of “grabbing” disparate radial portions of the radial histogram260on a touch screen interface and merging the gesture to at least a slight linear motion along the desired axis (e.g., as indicated by the merging gesture below display transition at step370).

In a further example, the radial histogram260may be manipulated or transformed into a helical timeline or histogram270, as shown inFIG. 13by using a tilt to side (left or right) gesture340(e.g., on a touch screen interface). The helical timeline includes a helix or helical or spiral axis (e.g., within a cylinder with perimeter and height dimensions representing time), and events presented on the helix in accordance with a time of their occurrence. The display may be reversed from a helical display270to a radial histogram260, using a tilt to top (or bottom) gesture380(e.g., on a touch screen interface). It should be understood that any of the gesturing techniques may be adapted to provide visualization transitions from any graphic form to another (e.g., helical timeline/histogram270may be transformed to a tickertape230with a defined transformation gesture) and for any perspectives or orientations (e.g., right to left, left to right, top to bottom, bottom to top, etc.).

Example gesture logic (e.g., of visualization module20) is further shown inFIG. 4. A horizontal stretch gesture350, a horizontal compress gesture310, a vertical compress gesture320and a vertical stretch gesture360are depicted across the top of the figure.

When a horizontal stretch gesture350is initiated, the underlying graphic is stretched horizontally to a desired scale or form a graphic with a desired horizontal scaling width. Accordingly, the relative change in a given graphic may be based on the scale relative the transformational gesture.

Accordingly, with stacked events (e.g.,FIGS. 7-11), a horizontal stretch increases row width (or the time interval represented by each row) at step410. It is determined whether there is a row under run at step415. If there is a row under run (e.g., no events within the adjusted time interval for a given row), the row is removed at step420. At some point, if the stacked linear graphic becomes stretched enough, it is determined if a single row remains at step425. If a single row remains, the display transitions to a tickertape display, otherwise, the event data are redistributed and redisplayed based on time of occurrence at step430(e.g., by visualization module20). It should be understood that the event data may be redistributed and displayed during the gesture or after gesture release.

When a horizontal compress gesture310is initiated, the underlying graphic is compressed horizontally and the row width (or time interval represented by each row) is decreased at step440. It is determined whether a row overrun has occurred at step445(e.g., additional events in the row beyond the adjusted time interval). As the event data are compressed, event data that overruns is added to a new row at step450. By way of example,FIG. 10depicts six days of 24 hour data similar to the data shown inFIG. 7. In this example, a compression gesture is applied to the stacked linear graphic ofFIG. 10to form a stacked timeline with a 21-hour interval shown inFIG. 11. The overrun (spillover or remainder) values, when they do not fill a given continuous or discrete interval, may be used to form a new row at the top or bottom of the display depending on the underlying scaling definitions (e.g., inFIG. 11, the overflow event data are shown on the top row).

When a vertical compress gesture320is initiated, the underlying graphic is compressed vertically and rows are removed at step460. As the rows are removed, event data may be stacked to form a histogram. It is determined if a single row remains at step425. If a single row remains, the display transitions to a linear histogram (e.g., as shown inFIG. 12A), otherwise, the event data are redistributed and redisplayed based on their time of occurrence at step430. In contrast to the vertical compress, a vertical stretch gesture may be initiated360to stretch the underlying graphic vertically. If the underlying graphic is a histogram, rows are added at step470. Initially, a histogram may be vertically stretched into a number of rows that correspond to the respective event times. For example, if stacked timeline240(FIG. 7) was vertically compressed into linear histogram250shown inFIG. 12A, then vertical stretch360(e.g., as applied to linear histogram250) may be used to transform linear histogram250into stacked timeline240.

If the underlying graphic is a stacked timeline, rows are added at step470as the graphic is stretched vertically. For example, if stacked timeline240(FIG. 7) is subject to vertical stretch360, rows may be added during the vertical stretch. The data for the new rows come from a shrinking time interval (e.g., much in the same way a horizontal compress operates). For example, a 24-hour interval may shrink to a 21-hour interval, to an 18-hour interval, and so on as the event graphic is stretched vertically. At some point it does not make sense to provide additional vertical stretch (e.g., additional stretch does not provide any useful information (e.g., rows with a single or few events)). This may occur when predefined system parameters determine that an empty row may be added at step475. If an empty row is to be added, the process stops at485. Otherwise, the event data are redistributed and redisplayed based on their time of occurrence at step430.

The gestures discussed above (e.g., horizontal stretch gesture350, horizontal compress gesture310, vertical compress gesture320, and vertical stretch gesture360) may further be applied to a helical timeline or histogram to adjust a dimension of the cylindrical display to alter a level of granularity of the events within the cylindrical display. For example, the horizontal stretch and compress gestures alter the cylinder perimeter (and corresponding time interval), while the vertical stretch and compress gestures alter the cylinder height (and corresponding time interval), thereby adjusting the helix. The events are placed and/or stacked on the adjusted helical timeline based on their time of occurrence.

It should be noted that a 24-hour interval is a natural place to start due to the 24-hour circadian nature of the Earth. However, as described herein a cyclic artifact may arise at any interval. Furthermore, the intervals during compression or expansion may be selected based on an amount of squeeze (or compression or expansion) in the gesture. The compression or expansion may be continuous in nature or in discrete intervals (e.g., hours, quarter-hours, minutes, etc.). A pop-up graphic may be provided to give an indication of the level of compression or expansion. Furthermore, the compression or expansion scale may change based on the current level of compression or expansion. For example, if the initial interval is 24 hours, the compression may occur in one hour intervals, and when the interval reaches a 12-hour interval, the compression interval may be reduced to one-half hour intervals.

Referring now toFIGS. 5A and 5B, a flow diagram illustrating plural operational scenarios is described in which gestures are utilized to transform a first display into a second display according to an embodiment of the present invention (e.g., via visualization module20and server system10and/or client system14). As viewed inFIGS. 5A and 5B, the abbreviation “CT” represents that data that are transformed according to the flow diagram may be in a state of continuous transformation (CT) (e.g., steps530,545,560,615,630, and645), and the asterisk indicates that a data analyst (or other user) or the system automatically may make the determination (e.g., steps520,525,535,540,550,555,605,610,620,625,635,640, and650). The flow of data analysis starts at step500. Streams of emitted events are obtained at step505. The emitted events may be obtained by way of a query (e.g., a query to database18(FIG. 1)). The events may be streamed to server system10that may host or be coupled to a business rule management system (e.g., decision system) or a Complex Event Processing (CEP) system. The streamed or emitted events may be previously collected and stored (e.g., by collection module16) from sensors22.

The streams of event data may be recordings of like events. As such, the streams of events are presented on a specific time horizon at step515(e.g., by visualization module20). The result may be visualization of the data (e.g., a tickertape or stacked linear timeline) that may use color, hashing, stippling and/or other visualization techniques to distinguish event types. At this point, the stacked streams515are parsed to determine if a pattern has been identified at step520(e.g., a user views the stacked streams to identify a pattern). The patterns may be recognized based on various factors (e.g., experience, cognitive skill, the ability to swap event variables to establish correlations among the data that are worthy of further exploration, etc.). If a pattern is identified, the process terminates at step655(FIG. 5B).

If a pattern is not identified at step520, it is determined at step525as to whether further analysis is warranted. If not, the process terminates at step655(FIG. 5B). If the next phase of analysis is desired as determined at step525, any number of visualization transformations may be explored including those that are suggested by the techniques described herein. Accordingly, various horizontal compressions may be used at step530(e.g., by way of visualization module20).

The horizontal compression variations may be parsed to determine if a pattern has been identified at step535. If a pattern is identified, the process terminates at step655(FIG. 5B). If a pattern is not identified at step535, a decision is rendered at step540as to whether further analysis is warranted. If not, the process terminates at step655(FIG. 5B). If the next phase of analysis is desired as determined at step540, a portion of the data in the graphic visualization may be selected for further analysis at step545. In this regard, gesturing techniques may be utilized to “rubber band” around a portion of the data of interest to form a subset of data. The system then may cull any unselected data from consideration. The remaining, selected subset of data, can then be subject to further analysis according to any of the techniques described or suggested herein.

The selected data may be parsed to determine if a pattern has been identified at step550. If a pattern is identified, the process terminates at step655(FIG. 5B). If a pattern is not identified at step550, a decision is rendered at step555as to whether further analysis is warranted. If not, the process terminates at step655(FIG. 5B). If the next phase of analysis is desired at step555, a compression spillover may be analyzed at step560according to the techniques described herein. In this regard, some spillovers that result in incomplete data (or visually incomplete linear data, annular data, or the like), may provide visual cues that may become apparent.

Referring toFIG. 5B, the process continues at step605, to determine whether a pattern has been identified. If a pattern is identified, the process terminates at step655. If a pattern is not identified at step605, a decision is rendered at step610as to whether further analysis is warranted. If further analysis is not warranted at step610, the process terminates at step655. If the next phase of analysis is desired as determined at step610, vertical compression visualization transformations may be explored at step615(e.g., as described above) to identify a pattern at step620.

If a pattern is identified at step620, the process terminates at step655. If a pattern is not identified at step620, a decision is rendered at step625as to whether further analysis is warranted. If further analysis is not warranted, the process terminates at step655. If the next phase of analysis is desired as determined at step625, circular transformation techniques may be explored at step630(e.g., as described above) to identify a pattern at step635.

If a pattern is identified at step635, the process terminates at step655. If a pattern is not identified at step635, a decision is rendered at step640as to whether further analysis is warranted. If further analysis is not warranted, the process terminates at step655. If the next phase of analysis is desired as determined at step640, tiling to cylindrical modes (e.g., helical timelines or histograms) may be explored at step645to identify cyclic patterns at step650. At this point, whether or not a pattern is identified, the process terminates at step655.

The decisions to proceed with succeeding visualizations may be based on any desired criteria (e.g., processing time, quantity of iterations, predetermined or specific order, etc.). The patterns identified may be utilized to generate rules to control actions or processing of other systems. For example, the events may include times when certain jobs or tasks are scheduled within a computer system. At certain times of a day, degraded performance is encountered. The visualizations may enable patterns to be identified at those times that indicate certain jobs or tasks are being performed that are causing the degraded performance. Rules may be generated to distribute execution of the tasks to enhance performance. The pattern identification and rules may be generated automatically by the system, or by an analyst or other user. This may be applied to various scenarios to control operation of varying systems to enhance performance.

By way of example, a simplified air transport model has been described above. However, most systems are more complex, e.g., a Complex Event Processing (CEP) system includes computer hardware and software that receive events in the form of messages, applies logic to these event-messages, and makes a decision and issues an action. For example, an intelligent highway system may include traffic monitors and digital overhead highway signs. When traffic monitors detect congestion, the monitors may update travel times posted “upstream” from the congested area to let “downstream” drivers of the congestion. The intelligent highway system may also receive accident report information and adjust the digital overhead signs accordingly.

Initially, a scenario investigation or design may take place. A system programmer authors the logic for the simple traffic system outlined above. Before the software is written, the programmer should understand traffic congestion over time and that traffic congestion is cyclic in nature, and that accidents cause congestion based on the degree of damage. The historic patterns of congestion and accidents over time are considered to develop algorithms to predict congestion and modify messages on overhead signs and change traffic signaling times (i.e., it may be beneficial to leave certain traffic signals “green” for an extended period of time).

The traffic system monitors traffic events (each vehicle passing a milestone, accident incidents, etc.) and stores this information in a database. The visualization techniques described herein may be utilized to understand how events cluster over time. For example, to examine patterns of traffic light changes, traffic flow, and how accidents cluster. Congestion patterns may be analyzed to include more complex events than the simple morning and evening rush hours. Congestion patterns may occur at many times of the day (e.g., noon, school let out and so forth). In other instances, it may be discovered that there are echo patterns (an accordion effect), i.e., a short time after congestion clears there is a paradoxical spike in accidents (because frustrated drivers try to make up for lost time).

The patterns may be discovered by viewing the stored data using the techniques of present invention embodiments described herein. The temporal information may be quickly transformed into different representations in search of these patterns. Patterns that are not apparent in one view may become apparent in another view. Thus, an advantage arises by the discovery of unanticipated patterns (e.g., patterns that occur every three hours or relationships between clusters of different types of events). Having found a few unexpected patterns, appropriate actions (e.g., define rules) may be triggered, such as lighting signs or changing traffic light times. Further, rules may be generated by an analyst or the system based on future predicted behavior (i.e., the system does not have to wait until traffic becomes congested to respond because the developed rules modify system actions (signs and traffic lights) ahead of time).

The visualizations and rule/action definitions may be tested against debugging scenarios. For example, a system of rules may be generated for detecting certain types of patterns and issuing certain types of actions (actions may also be considered a events). An analyst or other user or a system may generate test data using simulation software and read it into the visualization (display) system. An analyst may explore whether the system behaves as expected and whether or not there are unexpected or unwanted side effects. The CEP system both receives events and generates action events (which can be received and responded to in turn), and becomes a complex dynamic system (with feedback). The tools for transforming the various visualizations/graphics allows quick exploration of the behavior across multiple time scales to discern a cyclic or circadian pattern with ease.

It will be appreciated that the embodiments described above and illustrated in the drawings represent only a few of the many ways of implementing embodiments for identifying cyclic patterns of complex events.

The system may employ any number of any conventional or other databases, data stores or storage structures (e.g., files, databases, data structures, data or other repositories, etc.) to store information (e.g., events, event timelines, and/or graphical representations thereof, etc.). The database system may be implemented by any number of any conventional or other databases, data stores or storage structures (e.g., files, databases, data structures, data or other repositories, etc.) to store information (e.g., events, event timelines, analysis results, etc.). The database system may be included within or coupled to the server and/or client systems. The database systems and/or storage structures may be remote from or local to the computer or other processing systems, and may store any desired data (e.g., events, event timelines, analysis results, etc.).

The visualizations may include any information arranged in any fashion, and may be configurable based on rules or other criteria to provide desired information to a user.

The present invention embodiments are not limited to the specific tasks or algorithms described above, but may be utilized for identifying any types of patterns within any types of event or other information.