Patent Description:
Many modern vehicles, such as aircraft, are heavily "e-Enabled. " Generally, e-enabled vehicles utilize a suitable communication protocol to interconnect one or more systems. Such systems may generate an extremely large amount of log data, which contain critical security and health information related to the vehicle systems. Proper understanding and usage of this information leads to effective situational awareness. Failure to understand this information may result in cybersecurity compromises. However, new types, formats, and content are constantly being introduced into security logs. As such, the ability to quickly and accurately profile and analyze rapidly evolving log data to detect anomalies and cybersecurity threats is becoming increasing difficult. Accordingly, those skilled in the art continue with research and development efforts in the field of system log management and analysis.

<CIT> describes, in accordance with its abstract, a vehicle cyber-attack detection system includes at least one first tier security module coupled to at least one onboard system of a respective vehicle and being configured so as to receive system log data generated by the at least one onboard system of the respective vehicle. The first tier security module extracts extracted features from the system log data with natural language processing and includes a first cyber-attack anomaly detection module that identifies a first cyber-attack based on system entropy measurements determined from the extracted features, and a second cyber-attack anomaly detection module that includes a deep learning component that identifies a second cyber-attack based on classification of the extracted features. A cyber-attack alert module is coupled to the first tier security module for generating a notification of one or more of the first cyber-attack and the second cyber-attack to effect cyber-attack diagnostics and remediation by vehicle personnel.

In a first aspect, there is provided a system for analyzing vehicle system logs in accordance with claim <NUM>. In a second aspect, there is provided a method for analyzing vehicle system logs in accordance with claim <NUM>.

Disclosed are examples of a system for analyzing vehicle system logs, a method for analyzing vehicle system logs, a program for analyzing vehicle system logs. The following is a non-exhaustive list of examples, which may or may not be claimed, of the subject matter according to the present disclosure.

In an example, the disclosed system includes a processor and a storage device containing instructions. Execution of the instructions causes the processor to: (<NUM>) connect with an onboard system of a vehicle, wherein the onboard system is connectable to a network; (<NUM>) collect an activity log generated by the onboard system, wherein the activity log includes log messages indicative of an activity of the onboard system; (<NUM>) extract a feature list from the activity log, wherein the feature list includes features and each one of the features includes select information from a corresponding one of the log messages; (<NUM>) extract an episode from the feature list, wherein the episode is indicative of the activity of the onboard system; and (<NUM>) classify the episode with an episode classification, wherein the episode classification is indicative of an event that occurred during the activity.

In an example, the disclosed method includes steps of: (<NUM>) connecting to an onboard system of a vehicle, wherein the onboard system is connectable to a network; (<NUM>) collecting an activity log from the onboard system, wherein the activity log includes log messages indicative of an activity of the onboard system; (<NUM>) extracting a feature list from the activity log, wherein the feature list includes features and each one of the features includes select information from a corresponding one of the log messages; (<NUM>) extracting an episode from the feature list, wherein the episode is indicative of the activity of the onboard system; and (<NUM>) classifying the episode with an episode classification, wherein the episode classification is indicative of an event that occurred during the activity.

In an example, the disclosed program includes a, optionally non-transitory, computer readable medium, containing instructions that cause a processor to execute a process including: (<NUM>) collecting an activity log from an onboard system of a vehicle, wherein the activity log includes log messages indicative of an activity of the onboard system; (<NUM>) extracting a feature list from the activity log, wherein the feature list includes features and each one of the features includes select information from a corresponding one of the log messages; (<NUM>) extracting an episode from the feature list, wherein the episode is indicative of the activity of the onboard system; and (<NUM>) classifying the episode with an episode classification, wherein the episode classification is indicative of an event that occurred during the activity.

Other examples of the disclosed system, method, and program will become apparent from the following detailed description, the accompanying drawings, and the appended claims.

Referring generally to <FIG>, the present disclosure is directed to examples of a method <NUM> for analyzing vehicle system logs (e.g., a log analysis method), a system <NUM> for analyzing vehicle system logs (e.g., a log analysis system), and a computer program <NUM> (e.g., a computer implemented program product) for analyzing vehicle system logs (e.g., a log analysis program). Examples of the system <NUM> and/or the program <NUM> enable implementation of the method <NUM> within a computing environment.

Examples of the method <NUM> (e.g., shown in <FIG>), the system <NUM> (e.g., shown in <FIG>), and the program <NUM> (e.g., shown in <FIG>) are described herein with respect to a vehicle <NUM> (e.g., as shown in <FIG>), such as an aircraft <NUM> (e.g., as shown in <FIG>). However, it should be understood that the examples of method <NUM>, system <NUM>, and program <NUM> can be implemented or deployed with any suitable vehicle <NUM> that includes one or more network connectable vehicle systems that produce activity logs, such as, but not limited to, aerospace vehicles, rotary wing aircraft, unmanned aerial vehicles (UAVs), fixed wing aircraft, lighter than air vehicles, maritime vehicles, and automotive vehicles.

Referring initially to <FIG>, which illustrates an example of the vehicle <NUM>, including at least one onboard system <NUM>, and the system <NUM> for managing at least one activity log <NUM> produced by at least the one onboard system <NUM>. In one or more examples, the vehicle <NUM> includes a plurality of the onboard systems <NUM>. Each one of the onboard systems <NUM> includes one or more respective components, such as control components and operating components.

In one or more examples, one or more of the onboard systems <NUM> includes a control unit <NUM> that utilizes a computer-implemented or computer-controlled operating system. One or more of the onboard systems <NUM> is configured to be connected to and to communicate with a network <NUM>. Additionally, one or more of the onboard systems <NUM> is also configured to be connected to and to communicate with another one or more of the onboard systems <NUM>. Connection of any one of the onboard systems <NUM> with the network <NUM> or another one of the onboard systems <NUM> is continuous or intermittent (e.g., at predetermined times or during specific activities). In some examples, connectability of the onboard systems <NUM> can leave the onboard systems <NUM> vulnerable to a cybersecurity threat.

Referring briefly to <FIG>, which illustrates an example of the aircraft <NUM>. In one or more aerospace examples, the onboard systems <NUM> of the aircraft <NUM> include avionics systems <NUM>, propulsion systems <NUM>, hydraulic systems <NUM>, electrical systems <NUM>, main landing gear systems <NUM>, nose landing gear systems <NUM>, environmental systems <NUM>, and communications systems <NUM>. The aircraft <NUM> also includes an airframe <NUM> having an interior <NUM>. In other examples, the onboard systems <NUM> also includes one or more control systems <NUM> coupled to an airframe <NUM> of the aircraft <NUM>, such as for example, flaps, spoilers, ailerons, slats, rudders, elevators, and trim tabs. In yet other examples, the onboard systems <NUM> also includes one or more other systems, such as, but not limited to, software distribution systems, network communications systems, passenger information/entertainment systems, guidance systems, radar systems, weapons systems, and the like. One or more of the onboard systems <NUM> includes at least one associated system control unit <NUM> (e.g., as shown in <FIG>). In some examples, the system control unit <NUM> can be susceptible to a cyber-attack. As such, collective reference to the onboard systems <NUM> and individual reference to an onboard system <NUM> herein are intended to be inclusive of any of the system control unit(s) <NUM> associated with one or more of the respective onboard systems <NUM>.

The present disclosure recognizes that an increasing number of the onboard systems <NUM> of vehicles <NUM>, such as the aircraft <NUM>, is continually or intermittently connected to the communication network <NUM> (e.g., an Internet/cloud-based communication network). For example, "e-Enabled" aircraft include highly integrated interconnected software and firmware driven computer systems with specific real-time computing and control tasks. Data links in-flight and on-ground transfer and receive critical control, navigation, operations, and maintenance information. Generally, an e-Enabled vehicle can use Transmission Control Protocols (TCP) and/or Internet Protocols (IP), or any other suitable communication protocol, to interconnect one or more of the onboard systems <NUM> in a manner that virtually makes the vehicle <NUM> an interconnected network domain server. Due to, for example, the increased reliance on the onboard systems <NUM> being connected to the network <NUM>, the vehicle <NUM> can face potential cyber-attacks including, for example, but not limited to zero-day attacks, denial of service, sophisticated/advanced persistent malware, structured query language (SQL) injection attacks, session hijacking and man-in-the-middle attacks, network probing, brute-force cracking, ransomware, and insider threats.

The onboard systems <NUM> of the vehicle <NUM> produce activity logs <NUM> (e.g., system log data) that capture a variety of information, such as, but not limited to, system health, data load, file service, network messages, network performance, communication status, security events, and the like. In one or more examples, the activity logs <NUM> (e.g., audit trail records, event logs, transaction logs, message logs, server logs, security logs, etc.) generated by onboard systems <NUM> document activities <NUM> of the onboard systems <NUM> and include a collection of security related messages that provide an opportunity to identify security risks of the vehicle <NUM>.

Log analysis is the evaluation of the activity logs <NUM> and is used to mitigate a variety of risks, to understand and respond to cybersecurity incidents, to conduct root cause investigations in response to an incident, and/or to comply with regulations or security policies. Generally, the activity logs <NUM> include a plurality of log messages <NUM> that are chronologically arranged and stored, for example, on a disk, in files, or in an application like a log collector. Each one of the log messages <NUM> contains information related to a specific activity <NUM> within the onboard system <NUM>. Many of the log messages <NUM> contain information related to security. As examples, the activity logs <NUM> (e.g., security logs) are generated by security software, operating systems, and applications of the onboard systems <NUM>.

The present disclosure also recognizes that the number, volume, and variety of activity logs <NUM> have greatly increased, which has created the need for improvements in log management and analysis. For example, each aircraft <NUM> in a fleet <NUM> generates anywhere from <NUM> gigabyte (GB) to <NUM> gigabytes of log data over the course of a year of service. Additionally, the log messages <NUM> of the activity logs <NUM> are generally recorded in text log message format that provides a description of relevant activities <NUM> and events <NUM>, rather than network traffic data. Typically, network traffic data is used by conventional cyber-attack infrastructure defenses and conventional cyber-attack infrastructure defenses generally are not capable of analyzing the text of the log messages <NUM>.

Examples of the method <NUM>, the system <NUM>, and the program <NUM> facilitate efficient profiling and analyzing of the activity logs <NUM>. More particularly, examples of the method <NUM>, the system <NUM>, and the program <NUM> enable raw data (e.g., text) contained in the log messages <NUM> of the activity logs <NUM> to be parsed and formatted to extract select data related to or relevant to the activity <NUM> of the onboard system <NUM> of the vehicle <NUM>.

Examples of the method <NUM>, the system <NUM>, and the program <NUM> further enable sets or groups of the selected data to be classified, which indicate an event <NUM> associated with the activity <NUM>. Accordingly, examples of the method <NUM>, the system <NUM>, and the program <NUM> enable detection and identification of the onboard system <NUM> that is vulnerable to or that is a target of a cybersecurity threat or attack from among a plurality of onboard systems <NUM> and/or from among a plurality of vehicles <NUM>.

For the purpose of the present disclosure, the term "activity" (e.g., activity <NUM>) refers to and includes an action and/or function associated with (e.g., performed by, with, or on) the onboard system <NUM>. As examples, the onboard system <NUM> is configured to perform any one of various types of computer-implemented activities, such as data load activities, network communication activities, software staging activities, network and system startup activities, identity confirmation activities, software installation or deletion activities, certificate validation activities, file request operations, and the like. The term "event" (e.g., event <NUM>) refers to a particular type or task of the activity <NUM>, such as a particular operation, process, communication, and/or response occurring during performance of the activity <NUM>. As an example, the activity <NUM> includes one or more events <NUM>, such as initiation of an operation (e.g., loading, staging, installing, deleting, communicating, validating, etc.), a successful operation, a failed operation, a timed out operation, an error in performing the operation, termination of an operation, and the like. In other words, the event <NUM> is what happens during performance of an activity <NUM>.

The log messages <NUM> of the activity log <NUM> provide a record of the activities <NUM> and the events <NUM> that occur in the operating system of the onboard system <NUM>. For the purpose of the present disclosure, the term "episode" (e.g., episode <NUM>) refers to a description or characterization of an instance of the activity <NUM> as indicated by analysis of a number of log messages <NUM> in the activity log <NUM>. For example, the episode <NUM> is a filtered segment of the activity log <NUM> that represents a specific function of the onboard system <NUM> of the vehicle <NUM>. Further, the episode <NUM> is a subset of multiple log messages <NUM> selected from the activity log <NUM>. For example, the episode <NUM> that characterizes of described a data load activity will only contain log messages <NUM> that are related to data load and will filter out other log messages <NUM> that are generated throughout the duration of the data load activity and that are not related to the data load activity itself. The activity <NUM> can be characterized by any number of episodes <NUM> depending, for example, on a level of specificity to which the episode <NUM> characterizes the activity <NUM>. The term "episode classification" (e.g., episode classification <NUM>) refers to a description or characterization of an instance of the event <NUM> occurring during the activity <NUM> as indicated by analysis of the number of log messages <NUM>.

The disclosed method <NUM>, system <NUM>, and program <NUM> enable converting and mapping the log messages <NUM> into log features, referred to herein as features <NUM>, a combination of which characterize a particular type of activity <NUM> performed by the onboard system <NUM>. As will be described in more detail herein, the log features consist of an extraction of key terms (e.g., words) and/or values that represent semantic content embedded within the log messages <NUM>. The frequency, rate, and/or patterns of the log features provide cues related to behavior of the onboard systems <NUM> and, as such, serve as the basis for profiling and analyzing the log messages <NUM> to detect anomalies and cybersecurity incidents. The disclosed method <NUM>, system <NUM>, and program <NUM> enable automation to at least portions of the profiling and analyzing process. As an example, the disclosed method <NUM>, system <NUM>, and program <NUM> enable automatic profiling and categorizing the log messages <NUM> as various types of episodes <NUM>. As another example, the disclosed method <NUM>, system <NUM>, and program <NUM> enable creation of new types of episodes <NUM> and episode classifications <NUM> when new types and/or formats of data in the log messages <NUM> are introduced.

Accordingly, examples of the method <NUM>, the system <NUM>, and the program <NUM> apply analytical techniques to identify the events <NUM> that are frequently occurring and/or the events <NUM> that are rarely occurring (e.g., outlying events) from the textual log data of the log messages <NUM>. Identification of an occurrence (or rate of occurrence) of any one of the events <NUM> provides an indication that a mitigation act or remediation act may be needed in response to the event <NUM>.

Referring now to <FIG> and <FIG>, which illustrate examples of a process for managing (e.g., profiling and classifying) the activity log <NUM> for analysis. This process provides context to the activity <NUM> performed by the onboard system <NUM> of the vehicle <NUM> and enables analysis of the activity log <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) connecting to the onboard system <NUM> of the vehicle <NUM>. The onboard system <NUM> is connectable (e.g., is connected or is configured to be connected) to the network <NUM> (e.g., as shown in <FIG>). The onboard system <NUM> is also connectable (e.g., is connected to or is configured to be connected to) the system <NUM> (e.g., as shown in <FIG>), for example, directly or via the network <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) collecting the activity log <NUM> (e.g., at least one of the activity logs <NUM>) from the onboard system <NUM>. The activity log <NUM> includes the log messages <NUM> that are indicative of the activity <NUM> of the onboard system <NUM>. Generally, the activity log <NUM> (e.g., one or more of the activity logs <NUM>) is collected from the onboard system <NUM> (e.g., one or more of the onboard systems <NUM>). As an example, the system <NUM> (e.g., as shown in <FIG>) collects the log messages <NUM> of the activity log <NUM> directly from the onboard system <NUM> (e.g., from the control unit <NUM>). As another example, the system <NUM> collects the activity log <NUM> from a stored location or another application (e.g., a log collector).

In one or more examples, the activity log <NUM> includes the log messages <NUM> generated by one of the onboard systems <NUM> over a certain period of time (e.g., one day, one month, one year, etc.), which may also be referred to as a system log history. In other examples, the activity log <NUM> includes the log messages <NUM> generated by more than one of the onboard systems <NUM> (e.g., onboard system <NUM>-<NUM>, onboard system <NUM>-<NUM>, onboard system <NUM>-N shown in <FIG>) over a certain period of time, which may also be referred to as a vehicle systems log history. In other examples, the activity log <NUM> includes the log messages <NUM> generated by more than one of the onboard systems <NUM> of more than one vehicle <NUM> (e.g., from the fleet <NUM> of vehicles <NUM>) over a certain period of time, which may also be referred to as a fleet systems log history. Examples of the activity logs <NUM> include, but are not limited to, center for internet security (CIS) logs, copy services manager (CSM) logs, network interface module (NIM) logs, and any other system logs.

The activity log <NUM> includes any number of the log messages <NUM> (e.g., log message <NUM>-<NUM>, log message <NUM>-<NUM>, log message <NUM>-<NUM>, log message <NUM>-N shown in <FIG>). Generally, each log message <NUM> contains textual log data (e.g., text). In some examples, the textual log data of the log message <NUM> is without a well-defined structure. In some examples, the activity log <NUM> includes an extremely large amount of textual log data (e.g., multiple gigabytes of text), for example, log messages <NUM> from many onboard systems <NUM> of many vehicles <NUM>. In one or more examples, the activity log <NUM> refers to a raw log in which the textual log data of the log messages <NUM> is unmodified before extraction of the feature list <NUM> from the activity log <NUM>. However, in other examples (e.g., as shown in <FIG>), the activity log <NUM> is pre-processed to provide a formatted activity log <NUM> before extraction of the feature list <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) formatting or otherwise pre-processing the activity log <NUM>. In these examples, the feature list <NUM> is extracted from formatted log messages <NUM> of the formatted activity log <NUM>. As an example, the log messages <NUM> are formatted or otherwise processed to provide the formatted log messages <NUM> (e.g., formatted log massage <NUM>-<NUM>, formatted log massage <NUM>-<NUM>, formatted log massage <NUM>-<NUM>, formatted log massage <NUM>-N shown in <FIG>). Formatting or processing of the log messages <NUM> (e.g., raw log massages) to the formatted log message <NUM> prepares the textual log data for analysis, such as by removing fields of text that are not needed, not utilized, or not associated with the activity <NUM>, standardizing the date and time of the log message <NUM>, labelling the log message <NUM> with the source of the log message <NUM> (e.g., the corresponding onboard system <NUM>), filtering the contents of the textual log data (e.g., removing spaces, punctuation, non-standard or free-form text, etc.), and the like.

As examples, pre-processing the log messages <NUM> includes filtering out arbitrary values and/or parameters contained in the text of the log message <NUM> for the purpose of obtaining the core and invariant content of the log message <NUM>. As examples, various analysis context-irrelevant information, such as timestamps, punctuation, and parameters (e.g., text behind an "=" or ":") are removed. In one or more examples, pre-processing of the log messages <NUM> utilizes domain knowledge (e.g., of the vehicle <NUM> and the onboard system <NUM>) and/or subject matter experts to remove only context-irrelevant information and leave pertinent information, such as IP addresses, ports, web service status codes, and vehicle services names, which consist of a mixture of text (e.g., letters and digits).

As an example, prior domain knowledge is used to identify a set of digits, letters, and/or patterns that are particular to a specific vehicle <NUM> and/or onboard system <NUM>. As such, these system log messages are pre-processed differently from a generic filtering operation. For example, some IP addresses are converted to text, such as names of different onboard systems <NUM> or non-vehicle addresses, according to a knowledge-based mapping list.

In one or more examples, the method <NUM> includes a step of (block <NUM>) extracting a feature list <NUM> from the activity log <NUM>. The feature list <NUM> is extracted or otherwise generated from the log messages <NUM> of the activity log <NUM> or, alternatively, the formatted log messages <NUM> of the formatted activity log <NUM>. The feature list <NUM> includes a number of the features <NUM> (e.g., feature <NUM>-<NUM>, feature <NUM>-<NUM>, feature <NUM>-<NUM>, feature <NUM>-N as shown in <FIG>). In one or more examples, the feature list <NUM> includes a chronological list of the features <NUM> that have been extracted, generated, or defined from the log messages <NUM> of the activity log <NUM> over a predetermined period of time (e.g., the log history). In one or more examples, each one of the features <NUM> includes a timestamp, a numerical feature identification (e.g., F1, F2, F3, FN) and at least one field of text, referred to herein as a field <NUM>, from one of the log messages <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) generating (e.g., defining or designating) the features <NUM>. In one or more examples, the features <NUM> are defined prior commencement of the log analysis process of the activity log <NUM>. In one or more examples, the features <NUM> are designated or otherwise selected from any suitable source, such as current log messages or historical log messages. In one or more examples, the features <NUM> are generated (e.g., defined or designated) based on pre-existing log messages of historical activity logs related to known activities and events of the onboard system <NUM> (e.g., features <NUM> are pre-defined). In one or more examples, the features <NUM> are generated from the log messages <NUM> of the activity log <NUM> collected from the onboard system <NUM> (e.g., features <NUM> are defined in real-time).

Selection or designation of the features <NUM> are performed by any suitable technique. As an example, selection of particular fields <NUM> and designation of the features <NUM> from those fields <NUM> are performed manually by a subject matter expert using vehicle and/or system domain knowledge.

In one or more examples, each one of the features <NUM> includes select information (e.g., a selection of textual data) from a log message generated by the onboard system <NUM>. Once the features <NUM> are designated, the features <NUM> are identified within the log messages <NUM> of the activity log <NUM> being analyzed to create the feature list <NUM> and to provide a technique for parsing the log messages <NUM> into manageable, unique segments of information, which are then used to identify the episode <NUM> (e.g., a particular activity <NUM>) and to classify the episode <NUM> (e.g., a particular event <NUM>) from the feature list <NUM> (e.g., based on the log messages <NUM> of the activity log <NUM>).

In one or more examples, at least one of the features <NUM> is associated with (e.g., generated from or identified within) one of the log messages <NUM>. As an example, a first feature <NUM>-<NUM> consists of relevant information from a first log massage <NUM>-<NUM>. As such, the first feature <NUM>-<NUM> is associated with or can be used to describe the activity <NUM> performed by the onboard system <NUM>.

In one or more examples, more than one of the features <NUM> is associated with (e.g., generated from or identified within) one of the log messages <NUM>. As an example, the first feature <NUM>-<NUM> consists of a first sub-set of relevant information (e.g., a first sub-string of text) from the first log massage <NUM>-<NUM>, a second feature <NUM>-<NUM> consists of a second sub-set of relevant information (e.g., a second sub-string of text) from the first log massage <NUM>-<NUM>, and a third feature <NUM>-<NUM> consists of a third sub-set of relevant information (e.g., a third sub-string of text) from the first log massage <NUM>-<NUM>. As such, the first feature <NUM>-<NUM> is associated with or is used to describe the activity <NUM> performed by the onboard system <NUM> in a first manner or at a first (e.g., general or broad) level of specificity. The combination of the first feature <NUM>-<NUM> and the second feature <NUM>-<NUM> is associated with or is used to describe the activity <NUM> performed by the onboard system <NUM> in a second (e.g., different) manner or at a second (e.g., more detailed) level of specificity. The combination of the first feature <NUM>-<NUM>, the second feature <NUM>-<NUM>, and the third feature <NUM>-<NUM> is associated with or is used to describe the activity <NUM> performed by the onboard system <NUM> in a third (e.g., different) manner or at a third (e.g., even more detailed) level of specificity.

The selection or designation of one or more of the features <NUM> used to characterize the activity <NUM> is referred to herein as a feature set <NUM>. The feature set <NUM> is used to define the episode <NUM>. In one or more examples, the feature set <NUM> is found in a single log message <NUM>. In one or more examples, the feature set <NUM> is found in a plurality of the log messages <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) defining the episode <NUM> as the feature set <NUM> (e.g., a predetermined set of a number of the features <NUM>). The feature set <NUM> is created based on the predetermined or predefined selection of one or more of the features <NUM> that, individually or in combination, describe one of the activities <NUM> performed by one of the onboard systems <NUM>.

As an example, a first feature set <NUM>-<NUM> includes the first feature <NUM>-<NUM>, the second feature <NUM>-<NUM>, and the third feature <NUM>-<NUM> (e.g., as shown in <FIG>). As such, the specific selection and combination of feature <NUM>-<NUM>, feature <NUM>-<NUM>, and feature <NUM>-<NUM> (e.g., feature set <NUM>-<NUM>) is indicative of or describes the activity <NUM> of the onboard system <NUM>. In one or more examples, the feature set <NUM> includes any combination of and/or any number of the features <NUM>.

In one or more examples, the feature set <NUM> is generated and the episode <NUM> is defined based on pre-existing log messages of historical activity logs related to known activities and events of the onboard system <NUM> (e.g., feature set <NUM> is pre-defined). In one or more examples, the feature set <NUM> is generated and the episode <NUM> is defined from the log messages <NUM> of the activity log <NUM> collected from the onboard system <NUM> (e.g., feature set <NUM> is defined in real-time).

Selection or designation of the features <NUM> that define the feature set <NUM> is performed by any suitable technique. As an example, selection of particular features <NUM> and inclusion of those features <NUM> to define the feature set <NUM> representing the episode <NUM> is performed manually by a subject matter expert using vehicle and/or system domain knowledge.

Referring now to <FIG>, which illustrates an example of the log message <NUM>. In one or more examples, the log message <NUM> shown in <FIG> is an example of a log message from which the features <NUM> are originally defined. In one or more examples, the log message <NUM> shown in <FIG> is an example of a log message from which the feature list <NUM> is created.

Generally, each one of the log messages <NUM> of the activity log <NUM> includes a string of text (e.g., textual log data). The log message <NUM> includes a plurality of fields <NUM> (e.g., a text field). Each field <NUM> consists of a sub-string of the text related to a piece of contextual information.

As examples, the field <NUM> includes a designation of the date and time that the log message <NUM> was created (e.g., a timestamp), a designation of the onboard system <NUM> or component thereof that generated the log message <NUM>, a designation of the process (e.g., file path or filename) executed by the onboard system <NUM>, designations for the communications gateway (e.g., source internet protocol (IP) address, destination IP address, media access control (MAC) address, communications port, communications protocol, etc.) and the like. In one or more examples, one or more of the fields <NUM> includes a parameter (e.g., system identification, source IP address, destination port, etc.) and a numerical value or textual descriptor that is associated with the parameter (e.g., the system name, the IP address number, the destination port number, etc.). Additionally, in one or more examples, one or more of the fields <NUM> includes freeform text, additional informational messages, and the like (e.g., vehicle identification number, software part number, etc.) that is associated with the activity <NUM>, the onboard system <NUM>, and/or the vehicle <NUM>).

It should be understood that, in most cases, the fields <NUM> of the log messages <NUM> are not standardized and there can be wide variations in the format and content of the log messages <NUM> in the activity log <NUM>. For example, the fields <NUM> may or may not be separated by spaces, the parameter may or may not be separated from the associated value or descriptor by punctuation (e.g., colon), the terminology (e.g., text) used to describe the parameter in one log message may or may not be different from that of a different log message, and the like.

Referring now to <FIG>, which illustrates an example of features <NUM> designated from the log message <NUM> shown in <FIG> and examples of a plurality of episodes <NUM> defined by a selected set of one or more of the features <NUM>. In one or more examples, the log message <NUM> shown in <FIG> is an example of a log message from which the features <NUM> are originally defined. In one or more examples, the log message <NUM> shown in <FIG> is an example of a log message from which the feature list <NUM> is created.

Generally, one or more of the fields <NUM> of the log message <NUM> are designated as features <NUM>, which are used to define the episode <NUM> and classify the episode <NUM>. Additionally, in one or more examples, one or more of the fields <NUM> are designated as metadata <NUM>, which are not used to define or classify the episode <NUM> but which are included in the episode definition to supply additional contextual information, for example, which are used during a follow-on investigation of a cybersecurity threat or attack.

In the illustrative example, each one of field <NUM>-<NUM>, field <NUM>-<NUM>, field <NUM>-<NUM>, field <NUM>-<NUM>, field <NUM>-<NUM>, and field <NUM>-<NUM> is selected and designated as one of the features <NUM>. Each one of field <NUM>-<NUM> and field <NUM>-<NUM> is selected and designated metadata <NUM>.

In a first example, first episode <NUM>-<NUM> is defined by first feature set <NUM>-<NUM>, consisting of first feature <NUM>-<NUM> and first metadata <NUM>-<NUM>. In this example, first feature <NUM>-<NUM> includes feature identification F1 and field <NUM>-<NUM> (e.g., a system identification that identifies the onboard system <NUM> that generated the log message <NUM>). First metadata <NUM>-<NUM> includes first metadata identification G1 and field <NUM>-<NUM> (e.g., a timestamp associated with the log message <NUM>). As such, as an example, first episode <NUM>-<NUM> is very broad and characterizes any instance of the activity <NUM> performed by the onboard system <NUM>.

In a second example, second episode <NUM>-<NUM> is defined by second feature set <NUM>-<NUM>, consisting of first feature <NUM>-<NUM>, second feature <NUM>-<NUM>, and first metadata <NUM>-<NUM>. In this example, first feature <NUM>-<NUM> includes feature identification F1 and field <NUM>-<NUM> (e.g., a system identification that identifies the onboard system <NUM> that generated the log message <NUM>). Second feature <NUM>-<NUM> includes feature identification F2 and field <NUM>-<NUM> (e.g., destination IP address). First metadata <NUM>-<NUM> includes metadata identification G1 and field <NUM>-<NUM> (e.g., a timestamp associated with the log message <NUM>). As such, as an example, second episode <NUM>-<NUM> increases the specificity of the activity <NUM> performed and, for example, characterizes any instance of the activity <NUM> performed by the onboard system <NUM> in communication with a particular IP address.

In other examples, designating additional and/or different fields <NUM> as features <NUM> and including those additional and/or different features <NUM> in the feature set <NUM> enables different episodes <NUM> to be defined, which characterize the same activity <NUM> at different levels of specificity or which characterize different activities <NUM>. As an example, third episode <NUM>-<NUM> is defined by third feature set <NUM>-<NUM>, which further increases the specificity of the activity <NUM> performed. As another example, fourth episode <NUM>-<NUM> is defined by fourth feature set <NUM>-<NUM>, which even further increases the specificity of the activity <NUM> performed.

Referring now to <FIG>, which illustrates an example of features <NUM> designated from more than one log message <NUM> to create the feature set <NUM>. In one or more examples, the feature set <NUM> that defines the episode <NUM>, which characterizes the activity <NUM>, includes features <NUM> designated from more than one type of log message <NUM> (e.g., log message <NUM>-<NUM> and log message <NUM>-<NUM>). In these examples, the activity <NUM> is characterized by information contained in a plurality of log messages <NUM>.

Additionally, in one or more examples, one of more of the features <NUM> includes more than one field <NUM>. As an example, rather than first feature <NUM>-<NUM> including field <NUM>-<NUM>, first feature <NUM>-<NUM> includes field <NUM>-<NUM> and field <NUM>-<NUM> or another combination of two or more fields <NUM>.

In one or more examples, the step of (block <NUM>) generating the features <NUM> includes a step of generating a master list <NUM> of the features <NUM> (e.g., as shown in <FIG>). The master list <NUM> includes all of the features <NUM> defined or designated from log messages.

In one or more examples, the master list <NUM> is created by clustering the features <NUM>, for example, using a text clustering algorithm. As an example, features <NUM> that include contextually related fields <NUM> are grouped together before extraction of the episode <NUM> from the feature list <NUM>.

In one or more examples, the master list <NUM> is created by aggregating the features <NUM>, for example, following the clustering operation. As an example, different text can be used in the log messages <NUM> for the same general contextually related field <NUM>. As such, the different text of the fields <NUM> represented by different features <NUM> can be substituted with the same text (e.g., a keyword).

In one or more examples, the master list <NUM> of the features <NUM> is updated, for example, during profiling and analysis of the log messages <NUM> of the activity log <NUM>. As an example, the content (e.g., fields <NUM>) of the log message <NUM> of the activity log <NUM> being analyzed is compared to the features <NUM> of the master list <NUM> in order to map the fields <NUM> of the log message <NUM> to corresponding ones of the features <NUM> and to further analyze the log message <NUM> based on the log profile (e.g., feature set <NUM> representing the episode <NUM>) established from historical data. Any log data (e.g., field <NUM>) that cannot be mapped to the features <NUM> of the master list <NUM> is processed and used to define a new feature <NUM> (e.g., as described above with respect to feature generation).

Referring again to <FIG> and <FIG>, as such, the features <NUM> are extracted (e.g., identified and pulled out) from each log message <NUM> of the activity log <NUM> to form the feature list <NUM>.

In one or more examples, the step of (block <NUM>) generating the features <NUM> from the log messages <NUM> of the activity log <NUM> and the step of (block <NUM>) extracting the feature list <NUM> from the activity log <NUM> are integrated into a unitary processing operation in which the feature list <NUM> is created as the features <NUM> are pulled from the log messages <NUM>. In other examples, the step of (block <NUM>) generating the features <NUM> from the log messages <NUM> of the activity log <NUM> and the step of (block <NUM>) extracting the feature list <NUM> from the activity log <NUM> are discrete processing operations in which the features <NUM> are defined or created from the log massages <NUM> and the feature list <NUM> is then generated from the list of created features <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) extracting an episode <NUM> from the feature list <NUM>. As described above, a number of feature sets <NUM> (e.g., feature set <NUM>-<NUM>, feature set <NUM>-<NUM>, feature set <NUM>-<NUM>, feature set <NUM>-N shown in <FIG>) are extracted from the feature list <NUM> and the episode <NUM> is defined based on the feature set <NUM> (e.g., a select combination of the features <NUM>). Accordingly, the episode <NUM> is indicative or is representative of the activity <NUM> of the onboard system <NUM> as defined by the feature set <NUM>. In one or more examples, the step of (block <NUM>) extracting the episode <NUM> from the feature list <NUM> includes a step of searching for the feature set <NUM> (i.e., the episode <NUM>) from within the feature list <NUM>.

Referring now to <FIG>, which illustrates an example of an episode extraction operation (e.g., block <NUM>). In one or more examples, according to the method <NUM> (e.g., shown in <FIG>), the step of (block <NUM>) extracting the episode <NUM> from the feature list <NUM> includes a step of generating a window <NUM> within the feature list <NUM> that includes a batch <NUM> of the features <NUM>. The step of (block <NUM>) extracting the episode <NUM> from the feature list <NUM> also includes a step of searching for the feature set <NUM> from the batch <NUM> of the features <NUM> in the window <NUM>.

Generally, the window <NUM> includes a beginning <NUM> and an end <NUM> and can have any suitable size defined between the beginning <NUM> and the end <NUM>. In one or more examples, the window <NUM> is time-based. As an example, the window <NUM> is defined by a predetermined time duration (e.g., ten minutes) in which the beginning <NUM> is a start time and the end <NUM> is an end time. In one or more examples, the window <NUM> is feature-based. As an example, the window <NUM> is defined by a predetermined number of features <NUM> in which the beginning <NUM> is one of the features <NUM> (e.g., feature F1 shown in <FIG>) known to be contained in the log message <NUM> generated at a start of the activity <NUM> and the end <NUM> is another one of the features <NUM> (e.g., feature F7 shown in <FIG>) known to be contained in a log message <NUM> generated at an end of the activity <NUM>. In one or more examples, the window <NUM> is a combination of time-based and feature-based. As an example, the window <NUM> is defined by a predetermined time duration in which the beginning <NUM> is one of the features <NUM> (e.g., feature F1) known to be contained in a log message <NUM> generated at a start of the activity <NUM> and the end <NUM> is a predetermined time duration (e.g., ten minutes) after the occurrence of the feature <NUM>.

Referring now to <FIG>, in one or more examples, the step of searching for the episode <NUM> is performed incrementally through the feature list <NUM>. As an example, the features <NUM> defining the feature set <NUM> is searched within the window <NUM>. If the feature set <NUM> and, thus, the episode <NUM> is not found within the window <NUM>, the window <NUM> is shifted to include a new batch of features <NUM> and the feature set <NUM> is searched within the newly defined window <NUM>. If the feature set <NUM> and, thus, the episode <NUM> is found within the window <NUM>, the window <NUM> is shifted to include a new batch of features <NUM> and another feature set <NUM> (e.g., defining another instance of the same episode <NUM> or a different episode <NUM>) is searched within the newly defined window <NUM>.

Referring again to <FIG> and <FIG>, the method <NUM> also includes a step of (block <NUM>) classifying the episode <NUM> with the episode classification <NUM>. The episode classification <NUM> is indicative of the event <NUM> (e.g., one of the events <NUM>) that occurred during the activity <NUM>. In one or more examples, the episode <NUM> is classified as any one of a plurality of episode classifications <NUM> (e.g., episode classification <NUM>-<NUM>, episode classification <NUM>-<NUM>, episode classification <NUM>-<NUM>, episode classification <NUM>-N as shown in <FIG>) based on a tally or count of the number of times each feature <NUM> of the feature set <NUM> occurs within the feature list <NUM> when the feature set <NUM> is searched and the episode <NUM> is extracted from the feature list <NUM>.

As illustrated in <FIG>, in one or more examples, the episode <NUM>, defined by the feature set <NUM>, is identified and found within the search window <NUM>. In the illustrative example, the episode <NUM> is defined by (e.g., the feature set <NUM> includes) features F1, F2, F4, F5, and F7. The episode <NUM> is classified by a tally or count of the number of times each one of the features <NUM> occurs. In the illustrative example, feature F1 occurs in the features set <NUM> one time (F1=<NUM>), feature F2 occurs in the feature set <NUM> two times (F2=<NUM>), feature F4 occurs in the feature set <NUM> one time (F4=<NUM>), feature F5 occurs in the feature set <NUM> two times (F5=<NUM>), and feature F7 occurs in the feature set <NUM> one time (F7=<NUM>). This combination of designated ones of the features <NUM>, each occurring a predetermined number of times is indicative of a first event <NUM> of the activity <NUM> and, thus, the episode <NUM> is classified as a first episode classification <NUM>.

As illustrated in <FIG>, in one or more examples, another instance of the episode <NUM>, defined by the feature set <NUM>, is identified and found within the search window <NUM>, as the window <NUM> progresses through the feature list <NUM>. As described above, in the illustrative example, the episode <NUM> is defined by (e.g., the feature set <NUM> includes) features F1, F2, F4, F5, and F7. The episode <NUM> is classified by the tally or count of the number of times each one of the features <NUM> occurs. In the illustrative example, feature F1 occurs in the features set <NUM> one time (F1=<NUM>), feature F2 occurs in the feature set <NUM> two times (F2=<NUM>), feature F4 occurs in the feature set <NUM> two times (F4=<NUM>), feature F5 occurs in the feature set <NUM> one time (F5=<NUM>), and feature F7 occurs in the feature set <NUM> one time (F7=<NUM>). This combination of designated ones of the features <NUM>, each occurring a predetermined number of times is indicative of a second event <NUM> of the activity <NUM>, which is different than the first event <NUM> and, thus the episode <NUM> is classified as a second episode classification <NUM>.

Referring again to <FIG>, in one or more example, the method <NUM> includes a step of (block <NUM>) generating a hierarchical tree <NUM> (e.g., as shown in <FIG>) of the features <NUM> associated with and defining a particular activity <NUM> at different levels of specificity. As described above, the activity <NUM> is characterized by any number of episodes <NUM>, defined by a particular feature set <NUM>. The hierarchical tree <NUM> includes a plurality of leaf nodes, in which each leaf node represents a particular episode <NUM> characterizing the activity <NUM>. Defining the activity <NUM> in the layered structure of the hierarchical tree <NUM> advantageously facilitates aggregated activity type construction and provides higher flexibility in constructing aggregated activity types. As an example, the hierarchical tree <NUM> is utilized to search for, profile, and analyze a particular activity <NUM> at different levels of specific operations of the onboard system <NUM>.

As illustrated in <FIG>, in one or more examples, a log profile can be built based upon a particular leaf node activity type, associated with a particular episode122 (e.g., episode E5). Alternatively, in one or more examples, a log profile can be built based on an aggregate of multiple layers of activity types, associated with more than one episode <NUM> (e.g., episode E1, episode E2, and episode E5). Accordingly, analysis of the activity log <NUM> can be performed at higher levels, which reduces computational requirements. For example, the activity log <NUM> is analyzed based on the second tier of the hierarchical tree <NUM> (e.g., leaf node representing episode E2), which requires a lesser number of comparisons to be conducted and improves analysis performance. If, for example, a problem is identified at the leaf node (e.g., episode E2), the activity log <NUM> is analyzed based on the third tier of the hierarchical tree <NUM> (e.g., leaf node representing episode E5).

In one or more examples, the hierarchical tree <NUM> is generated from the master list <NUM> of the features <NUM> (e.g., as shown in <FIG>). As such, the tree hierarchy of the features <NUM> is arranged based on the key concepts/key words relevant to the activity <NUM> of the onboard system <NUM>.

Referring now to <FIG> and <FIG>, in one or more examples, the method <NUM> (e.g., as shown in <FIG>) includes a step of (block <NUM>) graphically representing an occurrence of the episode classification <NUM> over a predetermined time period. As an example, a graphical display <NUM> (e.g., as shown in <FIG>) that is representative of an occurrence of each one of the episode classifications <NUM> over a predetermined time period is generated. The graphical display <NUM> facilitates identification of one or more of the episode classifications <NUM> that are indicative of an outlying event.

Graphically representing occurrences of the episode classifications <NUM> over a predetermined time period provides a simple visualization that facilitates context to specific activities <NUM> of the onboard system <NUM>. As illustrated in <FIG>, the graphical display <NUM> visually identifies which of the episode classifications <NUM> (e.g., certain events <NUM> of a given activity <NUM>) have a high occurrence frequency or rate and which of the episode classifications <NUM> have a low occurrence frequency or rate. Some episode classifications <NUM> occur very rarely. Episode classifications <NUM> having a rare occurrence rate can be automatically identified and can indicate an abnormal activity <NUM> or event <NUM> associated with a cybersecurity threat or vulnerability. For example, from a cybersecurity perspective, rare activities are of primary interest because the assumption is that high occurrence or common activities are normal and rare occurrences can be abnormal. Additionally, the event <NUM> can also be linked to time of occurrence (e.g., <NUM>:<NUM> AM when the vehicle <NUM> is not in service or when no activity should be occurring). As described in more detail below and illustrated in <FIG>, this visualization and analysis can be scaled and performed for each one of a plurality of vehicles <NUM>.

In one or more examples, the method <NUM> includes a step of (block <NUM>) comparing the occurrence of the episode classification <NUM> to a predetermined occurrence threshold <NUM>. In one or more examples, the occurrence threshold <NUM> is representative of a normal or expected number of occurrences of the event <NUM> characterized by the episode classification <NUM>.

As an example, the method <NUM> includes a step of identifying that the occurrence of the episode classification <NUM> is less than the predetermined occurrence threshold <NUM> over a predetermined time period. For example, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs frequently (e.g., over the occurrence threshold <NUM>), it can be assumed that the event <NUM> is normal and expected. Alternatively, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs rarely (e.g., under the occurrence threshold <NUM>), it can be assumed that the event <NUM> is abnormal and can be indicative of a cybersecurity incident that required a follow-on action.

As another example, the method <NUM> includes a step of identifying that the occurrence of the episode classification <NUM> is greater than the predetermined occurrence threshold <NUM> over a predetermined time period. For example, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs infrequently (e.g., under the occurrence threshold <NUM>), it can be assumed that the event <NUM> is rare. Alternatively, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs frequently (e.g., over the occurrence threshold <NUM>), it can be assumed that the event <NUM> is abnormal and can be indicative of a cybersecurity incident that required a follow-on action.

In one or more examples, the method <NUM> includes a step of (block <NUM>) generating a recommended action <NUM> (e.g., as shown in <FIG>) based on the comparison of the occurrence of the episode classification <NUM> to the predetermined occurrence threshold <NUM>. As an example, the method <NUM> includes a step of generating at least one recommended action <NUM> when the occurrence of the episode classification <NUM> is less than the predetermined occurrence threshold <NUM> over the predetermined time period. As another example, the method <NUM> includes a step of generating at least one recommended action <NUM> when the occurrence of the episode classification <NUM> is greater than the predetermined occurrence threshold <NUM> over the predetermined time period. Examples of the recommended action <NUM> include a root cause investigation, a lower-level leaf node analysis (e.g., based on the hierarchical tree <NUM> shown in <FIG>), and any other suitable guidance to mitigate a potential cybersecurity threat.

Accordingly, the method <NUM> provides a normal profile of the activity <NUM> and the event <NUM> associated with the onboard system <NUM> and/or the vehicle <NUM>, which can be based on the hierarchical event types, to be built based on historical operation data (e.g., using machine learning and/or statistical analysis). Detection of a cybersecurity incident or other anomaly is based on an event frequency-based threshold per flight. Additional, rule-based detection can further incorporate additional contextual information from any of the log messages <NUM>. Additionally, log event types (e.g., episode classifications <NUM>) can be assigned a numeric severity level to indicate priority for the purpose of further analysis.

In one or more examples, implementation of the method <NUM> is scaled and applied to any number of onboard systems <NUM> of the vehicle <NUM>. In these examples, the method <NUM> includes the step of (block <NUM>) connecting with a number of the onboard systems <NUM> of the vehicle <NUM>. Each one of the onboard systems <NUM> is connectable (e.g., is connected or has been connected) to the network <NUM>. The method <NUM> also includes the step of (block <NUM>) collecting a number of activity logs <NUM> generated by the onboard systems <NUM>. The activity logs <NUM> include the log messages <NUM> that are indicative of a number of activities <NUM> of the onboard systems <NUM>. As an example, each one of the activity logs <NUM> includes a number of log messages <NUM>. Each one of the log messages <NUM> is indicative of one of the activities <NUM> of one of the onboard systems <NUM>. The method <NUM> further includes a step of (block <NUM>) extracting the feature list <NUM> from the activity logs <NUM>. The method <NUM> additionally includes a step of (block <NUM>) extracting a number of episodes <NUM> from the feature list <NUM>. The episodes <NUM> are indicative of the activities <NUM> of the onboard systems <NUM>. As an example, each one of the episodes <NUM> is indicative of one of the activities <NUM> of one of the onboard systems <NUM>. The method <NUM> also includes a step of (block <NUM>) classifying the episodes <NUM> with episode classifications <NUM>. The episode classifications <NUM> are indicative of events <NUM> that occurred during the activities <NUM>. As an example, each one of the episode classifications <NUM> is indicative of one of the events <NUM> of a corresponding one of the activities <NUM> of one of the onboard systems <NUM>.

In one or more examples, the method <NUM> includes the step of (block <NUM>) the graphically representing an occurrence of each one of the episode classifications <NUM> associated with one of the episodes <NUM> for each one of the onboard systems <NUM> over a predetermined time period. As an example, the graphical display <NUM> (e.g., as shown in <FIG>) is generated for each one of the episodes <NUM> for each one of the onboard systems <NUM> of the vehicle <NUM>.

In one or more examples, the method <NUM> includes the step of (block <NUM>) comparing an occurrence of any one of the episode classifications <NUM> associated with one of the episodes <NUM> for any one of the onboard systems <NUM> with the predetermined occurrence threshold <NUM> over a predetermined time period.

In one or more examples, implementation of the method <NUM> is scaled and applied to any number of onboard systems <NUM> of any number of vehicles <NUM> (e.g., forming a fleet <NUM> as shown in <FIG>). In these examples, the method <NUM> includes the step of (block <NUM>) connecting with a number of the onboard systems <NUM> of a number of the vehicles <NUM>. Each one of the onboard systems <NUM> of each one of the vehicles <NUM> is connectable (e.g., is connected or has been connected) to the network <NUM>. The method <NUM> also includes a step of (block <NUM>) collecting a number of activity logs <NUM> generated by the onboard systems <NUM>. The activity logs <NUM> includes the log messages <NUM> that are indicative of a number of activities <NUM> of the onboard systems <NUM>. As an example, each one of the activity logs <NUM> includes a number of the log messages <NUM>. Each one of the log messages <NUM> is indicative of one of the activities <NUM> of one of the onboard systems <NUM> of one of the vehicles <NUM>. The method <NUM> further includes the step of (block <NUM>) extracting the feature list <NUM> from the activity logs <NUM>. The method <NUM> additionally includes the step of (block <NUM>) extracting a number of episodes <NUM> from the feature list <NUM>. The episodes <NUM> are indicative of the activities <NUM> of the onboard systems <NUM>. As an example, each one of the episodes <NUM> is indicative of one of the activities116 of one of the onboard systems <NUM> of one of the vehicles <NUM>. The method <NUM> also includes the step of (block <NUM>) classifying the episodes <NUM> with the episode classifications <NUM>. The episode classifications <NUM> are indicative of events <NUM> that occurred during the activities <NUM>. As an example, each one of the episode classifications <NUM> is indicative of one of the events <NUM> of a corresponding one of the activities <NUM> of one of the onboard systems <NUM> of one of the vehicles <NUM>.

In one or more examples, the method <NUM> includes the step of (block <NUM>) graphically representing an occurrence of each one of the episode classifications <NUM> associated with one of the episodes <NUM> for each one of the vehicles <NUM> over a predetermined time period.

As an example, the graphical display <NUM> (e.g., as shown in <FIG>) is generated for each one of the episodes <NUM> of each one of the vehicles <NUM>. The graphical display <NUM> facilitates identification of one or more of the episode classifications <NUM> that are indicative of an outlying event based on or compared to other vehicles <NUM>.

As an example, all the vehicles <NUM> of the fleet <NUM> can perform a certain task (e.g., event <NUM>) of the activity <NUM> very frequently or very infrequently. As such, event classifications <NUM> that occur at substantially the same frequency among the vehicles <NUM> can be assumed to be normal. However, a certain event <NUM> (e.g., episode classification <NUM>) can have a substantially higher or lower rate of occurrence in one vehicle <NUM> as compared to the other vehicles <NUM>. Such outlying events <NUM> can be unusual and require further investigation.

In one or more examples, the method <NUM> includes the step of (block <NUM>) comparing the occurrence of the episode classification <NUM> to the predetermined occurrence threshold <NUM>. In one or more examples, the occurrence threshold <NUM> is representative of a normal or expected number of occurrences of the event <NUM> characterized by the episode classification <NUM>.

As an example, the method <NUM> includes a step of identifying that the occurrence of the episode classification <NUM> associated with a particular vehicle <NUM> is greater than the predetermined occurrence threshold <NUM> over a predetermined time period. For example, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs at approximately the same frequency or rate relative to other vehicles <NUM> (e.g., under the occurrence threshold <NUM>), it can be assumed that the event <NUM> is normal and expected. Alternatively, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs at a higher frequency or rate relative to other vehicles <NUM> (e.g., over the occurrence threshold <NUM>), it can be assumed that the event <NUM> is abnormal and can be indicative of a cybersecurity incident that required a follow-on action.

As another example, the method <NUM> includes a step of identifying that the occurrence of the episode classification <NUM> is less than the predetermined occurrence threshold <NUM> over a predetermined time period. For example, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs at approximately the same frequency or rate relative to other vehicles <NUM> (e.g., under the occurrence threshold <NUM>), it can be assumed that the event <NUM> is normal and expected. Alternatively, during analysis of the activity log <NUM>, if an episode classification <NUM> and, thus, an associated event <NUM> occurs a lower frequency or rate relative to other vehicles <NUM> (e.g., under the occurrence threshold <NUM>), it can be assumed that the event <NUM> is abnormal and can be indicative of a cybersecurity incident that required a follow-on action.

Referring now to <FIG>, the system <NUM> is an example of implementation of the method <NUM> (e.g., shown in <FIG>) within a computer system. In one or more examples, the system <NUM> includes a processor <NUM> and a storage device <NUM>. The storage device <NUM> contains instructions <NUM>. Execution of the instructions causes the processor <NUM> to connect with the onboard system <NUM> of the vehicle <NUM>. The onboard system <NUM> is connectable (e.g., is connected or has been connected) to the network <NUM>. Execution of the instructions also causes the processor <NUM> to collect the activity log <NUM> generated by the onboard system <NUM>. The activity log <NUM> includes the log messages <NUM> that are indicative of the activity <NUM> of the onboard system <NUM>. Execution of the instructions further causes the processor <NUM> to extract the feature list <NUM> from the activity log <NUM>. The feature list <NUM> includes the features <NUM> and each one of the features <NUM> includes select information from a corresponding one of the log messages <NUM>. Execution of the instructions additionally causes the processor <NUM> to extract the episode <NUM> from the feature list <NUM>. The episode <NUM> is indicative of the activity <NUM> of the onboard system <NUM>. Execution of the instructions also causes the processor <NUM> to classify the episode <NUM> with the episode classification <NUM>. The episode classification <NUM> is indicative of the event <NUM> that occurred during the activity <NUM>.

In one or more examples, the episode <NUM> is extracted from the feature list <NUM> according to a predetermined episode rule <NUM> that defines the episode <NUM> as the feature set <NUM> of the features <NUM> from the feature list <NUM>. The episode <NUM> is classified according to a predetermined classification rule <NUM> that defines the episode classification <NUM> as a number of times each one of the features <NUM> has occurred in the feature set <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to generate the features <NUM> from the log messages <NUM>. Each one of the features <NUM> includes at least one field <NUM> expressed in the corresponding one of the log messages <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to generate the hierarchical tree <NUM> (e.g., as shown in <FIG>) of the features <NUM> associated with the activity <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to generate the window <NUM> (e.g., as shown in <FIG>) within the feature list <NUM> that includes the batch <NUM> of the features <NUM> and to search for the feature set <NUM> from the batch <NUM> of the features <NUM> in the window <NUM>.

In one or more examples, the window <NUM> is a time duration and is bound by the beginning <NUM> (e.g., start time) and the end <NUM> (e.g., end time).

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to shift the window <NUM> within the feature list <NUM> by a time interval such that the window <NUM> include a second batch <NUM> (e.g., as shown in <FIG>) of the features <NUM> and to search for the feature set <NUM> from the second batch <NUM> of the features <NUM> in the window <NUM>.

In one or more examples, the window <NUM> is bound by a first one of the features <NUM> of the feature set <NUM> and a second one of the features <NUM> of the feature set <NUM>. The first one of the features <NUM> is indicative of a start of the activity <NUM> (e.g., beginning <NUM>). The second one of the features <NUM> is indicative of an end of the activity <NUM> (e.g., end <NUM>).

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to format the activity log <NUM> for extraction of the feature list <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to generate the graphical display <NUM> (e.g., as shown in <FIG>) that is representative of an occurrence of the episode classification <NUM> over a predetermined time period.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to compare an occurrence of the episode classification <NUM> to the predetermined occurrence threshold <NUM> over a predetermined time period and to identify that (or when) an occurrence of the episode classification <NUM> is less than (or greater than) the predetermined occurrence threshold <NUM> over the predetermined time period.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to generate the recommended action <NUM> based on the comparison of the occurrence of the episode classification <NUM> to the predetermined occurrence threshold <NUM>, for example, when the occurrence of the episode classification <NUM> is less than the predetermined occurrence threshold <NUM> over the predetermined time period.

In one or more examples, the system <NUM> is scalable and is applied to any number of the onboard systems <NUM> of the vehicle <NUM>. In such examples of the system <NUM>, execution of the instructions <NUM> causes the processor <NUM> to connect with a number of the onboard systems <NUM> of the vehicle <NUM>. Each one of the onboard systems <NUM> is connectable (e.g., is connected or has been connected) to the network <NUM>. Execution of the instructions <NUM> also causes the processor <NUM> to collect a number of the activity logs <NUM> generated by the onboard systems <NUM>. The activity logs <NUM> include the log messages <NUM> that are indicative of a number of the activities <NUM> of the onboard systems <NUM>. Execution of the instructions <NUM> further causes the processor <NUM> to extract the feature list <NUM> from the activity logs <NUM>. Execution of the instructions <NUM> additionally causes the processor <NUM> to extract a number of the episodes <NUM> from the feature list <NUM>. The episodes <NUM> are indicative of the activities <NUM> of the onboard systems <NUM>. Execution of the instructions <NUM> also causes the processor <NUM> to classify the episodes <NUM> with the episode classifications <NUM>. The episode classifications <NUM> are indicative of events <NUM> that occurred during the activities <NUM>.

In one or more examples of the system <NUM>, execution of the instructions <NUM> causes the processor <NUM> to generate the graphical display <NUM> (e.g., as shown in <FIG>) that is representative of an occurrence of each one of the episode classifications <NUM> over a predetermined time period.

In one or more examples of the system <NUM>, execution of the instructions <NUM> causes the processor <NUM> to compare an occurrence of any one of the episode classifications <NUM> to the predetermined occurrence threshold <NUM> and to identify that (e.g., when) an occurrence of any one of the episode classifications <NUM> is less than or greater than a predetermined occurrence threshold <NUM> over a predetermined time period.

In one or more examples, the system <NUM> is scalable and is configured to be applied to any number of the onboard systems <NUM> of any number of the vehicles <NUM> (e.g., forming the fleet <NUM>). In such examples of the system <NUM>, execution of the instructions <NUM> causes the processor <NUM> to connect with a number of onboard systems <NUM> of a number of vehicles <NUM>. Each one of the onboard systems <NUM> is connectable (e.g., is connected or has been connected) to the network <NUM>. Execution of the instructions <NUM> also causes the processor <NUM> to collect a number of the activity logs <NUM> generated by the onboard systems <NUM>. The activity logs <NUM> include the log messages <NUM> that are indicative of a number of the activities <NUM> of the onboard systems <NUM>. Execution of the instructions <NUM> further causes the processor <NUM> to extract the feature list <NUM> from the activity logs <NUM>. Execution of the instructions <NUM> additionally causes the processor <NUM> to extract a number of the episodes <NUM> from the feature list <NUM>. The episodes <NUM> are indicative of the activities <NUM> of the onboard systems <NUM>. Execution of the instructions <NUM> also causes the processor <NUM> to classify the episodes <NUM> with the episode classifications <NUM>. The episode classifications <NUM> are indicative of the events <NUM> that occurred during the activities <NUM>.

In one or more examples of the system <NUM>, execution of the instructions <NUM> causes the processor <NUM> to generate the graphical display <NUM> (e.g., as shown in <FIG>) that is representative of an occurrence of each one of the episode classifications <NUM> associated with one of the episodes <NUM> for each one of the vehicles <NUM> over a predetermined time period.

In one or more examples of the system <NUM>, execution of the instructions <NUM> causes the processor <NUM> to compare an occurrence of any one of the episode classifications <NUM> associated with one of the episodes <NUM> for any one of the vehicles <NUM> to the predetermined occurrence threshold <NUM> and/or relative to the other vehicles <NUM> and to identify that (e.g., when) an occurrence of any one of the episode classifications <NUM> associated with one of the episodes <NUM> for any one of the vehicles <NUM> is greater than or less than the predetermined occurrence threshold <NUM> over a predetermined time period.

Referring generally to <FIG> and <FIG> and particularly to <FIG>, in one of more examples, the program <NUM> takes the form of a computer program product. The program <NUM> includes a, optionally non-transitory, computer readable medium <NUM> containing the instructions <NUM> that causes the processor <NUM> to execute a process. In one or more examples, the process is a computer implementation of the method <NUM> (e.g., shown in <FIG>).

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of connecting to the onboard system <NUM> of a vehicle <NUM>. The onboard system <NUM> is connectable (e.g., is connected or has been connected) to the network <NUM>. The process also includes a step of collecting the activity log <NUM> from the onboard system <NUM>. The activity log <NUM> includes log messages <NUM> indicative of the activity <NUM> of the onboard system <NUM>. The process also includes a step of extracting the feature list <NUM> from the activity log <NUM>. The feature list <NUM> includes features <NUM> and each one of the features <NUM> includes select information from a corresponding one of the log messages <NUM>. The process further includes a step of extracting the episode <NUM> from the feature list <NUM>. The episode <NUM> is indicative of the activity <NUM> of the onboard system <NUM>. The process additionally includes a step of classifying the episode <NUM> with the episode classification <NUM>. The episode classification <NUM> is indicative of the event <NUM> that occurred during the activity <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of extracting the episode <NUM> from the feature list <NUM> according to the predetermined episode rule <NUM> (e.g., shown in <FIG>). The episode rule <NUM> defines the episode <NUM> as the feature set <NUM> of the features <NUM>. Execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of classifying the episode <NUM> according to the predetermined classification rule <NUM>. The classification rule <NUM> defines the episode classification <NUM> as a number of times each one of the features <NUM> has occurred in the feature set <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of generating the features <NUM> from the log messages <NUM>. Each one of the features <NUM> includes at least one field <NUM> expressed or contained in a corresponding one of the log messages <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of generating the hierarchical tree <NUM> (e.g., as shown in <FIG>) of the features <NUM> associated with the activity <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of graphically representing an occurrence of the episode classification <NUM> over a predetermined time period (e.g., as shown in <FIG> and <FIG>).

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of comparing an occurrence of the episode classification <NUM> to the predetermined occurrence threshold <NUM> and a step of identifying that an occurrence of the episode classification <NUM> is less than or greater than the predetermined occurrence threshold <NUM>.

In one or more examples, execution of the instructions <NUM> causes the processor <NUM> to execute the process, which includes a step of generating the recommended action <NUM> when the occurrence of the episode classification <NUM> is less than or greater than the predetermined occurrence threshold <NUM> over the predetermined time period.

Furthermore, in one or more examples, execution of the instructions <NUM> can be scaled and applied to any number of the onboard systems <NUM> of any number of the vehicles <NUM>, as described above with respect to the method <NUM> and the system <NUM>.

In one or more examples, the program <NUM> includes multiple modules or agents used to profile and classify the activities <NUM> and events <NUM> of the onboard systems <NUM>. The modules of the program <NUM> generally perform different functions, such as, identifying specific log messages <NUM> related to specific activities <NUM>, determining the start and end of the activity <NUM>, designation of the features <NUM> from the log messages <NUM>, designation of the episodes <NUM> from as the feature set <NUM> from the feature list <NUM>, and classification of each episode <NUM>.

Referring to <FIG>, in one or more examples, the computing device <NUM> (e.g., shown in <FIG>) includes a data processing system <NUM>. In one or more examples, the data processing system <NUM> includes a communications framework <NUM>, which provides communications between at least one processor unit <NUM>, one or more storage devices <NUM>, such as memory <NUM> and/or persistent storage <NUM>, a communications unit <NUM>, an input/output (I/O) unit <NUM>, and a display <NUM>. In this example, the communications framework <NUM> takes the form of a bus system.

In one or more examples, the at least one processor unit <NUM> is an example of the processor <NUM> of the computing device <NUM> (e.g., as shown in <FIG>). In one or more examples, the storage devices <NUM> are examples of the storage device <NUM> (e.g., memory) of the computing device <NUM> (e.g., as shown in <FIG>).

The processor unit <NUM> serves to execute instructions for software that can be loaded into the memory <NUM>. In one or more examples, the processor unit <NUM> is a number of processors, a multi-processor core, or some other type of processor, depending on the particular implementation.

The memory <NUM> and the persistent storage <NUM> are examples of the storage devices <NUM>. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, at least one of data, program code in functional form, or other suitable information either on a temporary basis, a permanent basis, or both on a temporary basis and a permanent basis. The storage devices <NUM> may also be referred to as computer readable storage devices in one or more examples. The memory <NUM> is, for example, a random-access memory or any other suitable volatile or non-volatile storage device. The persistent storage <NUM> can take various forms, depending on the particular implementation.

For example, the persistent storage <NUM> contains one or more components or devices. For example, the persistent storage <NUM> is a hard drive, a solid state hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by the persistent storage <NUM> also can be removable. For example, a removable hard drive can be used for the persistent storage <NUM>.

The communications unit <NUM> provides for communications with other data processing systems or devices. In one or more examples, the communications unit <NUM> is a network interface card.

Input/output unit <NUM> allows for input and output of data with other devices that can be connected to the data processing system <NUM>. For example, the input/output unit <NUM> provides a connection for user input through at least one of a keyboard, a mouse, or some other suitable input device. Further, the input/output unit <NUM> can send output to a printer. The display <NUM> provides a mechanism to display information to a user.

Instructions for at least one of the operating system, applications, or programs can be located in the storage devices <NUM>, which are in communication with the processor unit <NUM> through the communications framework <NUM>. The processes of the various examples and operations described herein can be performed by the processor unit <NUM> using computer-implemented instructions, which can be located in a memory, such as the memory <NUM>.

The instructions are referred to as program code, computer usable program code, or computer readable program code (e.g., the instructions <NUM> shown in <FIG>) that can be read and executed by a processor in processor unit <NUM> (e.g., the processor <NUM> shown in <FIG>). The program code in the different examples can be embodied on different physical or computer readable storage media, such as the memory <NUM> or the persistent storage <NUM>.

In one or more examples, application program code <NUM> is located in a functional form on computer readable media <NUM> that is selectively removable and can be loaded onto or transferred to the data processing system <NUM> for execution by the processor unit <NUM>. The application program code <NUM> is an example of the instructions <NUM> (e.g., shown in <FIG>). In one or more examples, the application program code <NUM> and computer readable media <NUM> form the computer program product <NUM>. In one or more examples, the computer readable media <NUM> is computer readable storage media <NUM>.

In one or more examples, the computer readable storage media <NUM> is a physical or tangible storage device used to store the application program code <NUM> rather than a medium that propagates or transmits the application program code <NUM>.

Alternatively, the application program code <NUM> can be transferred to the data processing system <NUM> using a computer readable signal media. The computer readable signal media can be, for example, a propagated data signal containing the application program code <NUM>. For example, the computer readable signal media can be at least one of an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals can be transmitted over at least one of communications links, such as wireless communications links, optical fiber cable, coaxial cable, a wire, or any other suitable type of communications link.

The different components illustrated for data processing system <NUM> are not meant to provide architectural limitations to the manner in which different examples can be implemented. The different examples can be implemented in a data processing system including components in addition to or in place of those illustrated for the data processing system <NUM>. Other components shown in <FIG> can be varied from the examples shown. The different examples can be implemented using any hardware device or system capable of running the application program code <NUM>.

Additionally, various components of the system <NUM> and/or the data processing system <NUM> of the computing device <NUM> may be described as modules. For the purpose of the present disclosure, the term "module" includes hardware, software or a combination of hardware and software. As an example, a module can include one or more circuits configured to perform or execute the described functions or operations of the executed processes described herein (e.g., the method <NUM>). As another example, a module includes a processor, a storage device (e.g., a memory), and computer-readable storage medium having instructions that, when executed by the processor causes the processor to perform or execute the described functions and operations. In one or more examples, a module takes the form of the program code <NUM> and the computer-readable media <NUM> together forming the computer program product <NUM>.

Accordingly, examples of the disclosed method <NUM>, system <NUM>, and program <NUM> provide various means for automated or semi-automated security log management and analysis, which further enable a system administrator to provide guidance related to proper defense against cybersecurity threats, attacks, and compromises. As an example, a supplier of the vehicle <NUM> (e.g., an aircraft manufacturer and/or supplier) can utilize examples of the method <NUM>, system <NUM>, and program <NUM> to perform root cause analysis and provide follow-on guidance to vehicle operators (e.g., airlines). As another example, an operator of the vehicle <NUM> (e.g., an airline) can utilize the examples of the method <NUM>, system <NUM>, and program <NUM> to perform root cause analysis and determine follow-on actions.

In an aerospace example, such as related to an e-Enabled aircraft, examples of the disclosed method <NUM>, system <NUM>, and program <NUM> provide a unique "flight-based" signature analytical technique for cybersecurity attach and anomaly detection using the aircraft system log data. In such as flight-based technique, log behaviors are characterized and quantified on a per flight basis. In addition to log event types (e.g., episodes <NUM> and episode classifications <NUM>) being defined, multiple flight-related factors, such as flight phases, airline, aircraft/fleet model, airport (e.g., departure and destination), region, communications method used, a number of devices connected to the onboard system <NUM>, and the like can be integrated into the feature set <NUM> (e.g., select features <NUM> and metadata <NUM>) to construct normal aircraft log profiles that are closely relevant to an aviation operation context.

Referring now to <FIG> and <FIG>, examples of the method <NUM>, system <NUM>, and program <NUM> may be related to, or used in the context of, an aircraft manufacturing and service method <NUM>, as shown in the flow diagram of <FIG> and the aircraft <NUM>, as schematically illustrated in <FIG>. For example, the aircraft <NUM> and/or the aircraft production and service method <NUM> may utilize implementations of the method <NUM>, the system <NUM>, and the program <NUM> to profile and analyze aircraft activity logs for detection and cybersecurity threats and vulnerabilities.

Referring to <FIG>, during pre-production, the method <NUM> includes specification and design of the aircraft <NUM> (block <NUM>) and material procurement (block <NUM>). During production of the aircraft <NUM>, component and subassembly manufacturing (block <NUM>) and system integration (block <NUM>) of the aircraft <NUM> take place. Thereafter, the aircraft <NUM> goes through certification and delivery (block <NUM>) to be placed in service (block <NUM>). Routine maintenance and service (block <NUM>) includes modification, reconfiguration, refurbishment, etc. of one or more systems of the aircraft <NUM>.

Each of the processes of the method <NUM> illustrated in <FIG> may be performed or carried out by a system integrator, a third party, and/or an operator (e.g., a customer). For the purposes of this description, a system integrator may include, without limitation, any number of spacecraft manufacturers and major-system subcontractors; a third party may include, without limitation, any number of vendors, subcontractors, and suppliers; and an operator may be an airline, leasing company, military entity, service organization, and so on.

Examples of the method <NUM>, the system <NUM>, and the program <NUM> shown and described herein, may be employed during any one or more of the stages of the manufacturing and service method <NUM> shown in the flow diagram illustrated by <FIG>. In an example, implementations of the method <NUM>, the system <NUM>, and the program <NUM> may form a portion of component and subassembly manufacturing (block <NUM>) and/or system integration (block <NUM>). Further, the method <NUM>, the system <NUM>, and the program <NUM> may be implemented in a manner similar to components or subassemblies prepared while the aircraft <NUM> is in service (block <NUM>). Also, implementations of the method <NUM>, the system <NUM>, and the program <NUM> may be utilized during system integration (block <NUM>) and certification and delivery (block <NUM>). Similarly, implementations of the method <NUM>, the system <NUM>, and the program <NUM> may be utilized, for example and without limitation, while the aircraft <NUM> is in service (block <NUM>) and during maintenance and service (block <NUM>).

The preceding detailed description refers to the accompanying drawings, which illustrate specific examples described by the present disclosure. Other examples having different structures and operations do not depart from the scope of the present disclosure. Like reference numerals may refer to the same feature, element, or component in the different drawings. Throughout the present disclosure, any one of a plurality of items may be referred to individually as the item and a plurality of items may be referred to collectively as the items and may be referred to with like reference numerals. Moreover, as used herein, a feature, element, component, or step preceded with the word "a" or "an" should be understood as not excluding a plurality of features, elements, components or steps, unless such exclusion is explicitly recited.

Illustrative, non-exhaustive examples, which may be, but are not necessarily, claimed, of the subject matter according to the present disclosure are provided above. Reference herein to "example" means that one or more feature, structure, element, component, characteristic, and/or operational step described in connection with the example is included in at least one aspect, embodiment, and/or implementation of the subject matter according to the present disclosure. Thus, the phrases "an example," "another example," "one or more examples," and similar language throughout the present disclosure may, but do not necessarily, refer to the same example. Further, the subject matter characterizing any one example may, but does not necessarily, include the subject matter characterizing any other example.

Moreover, the subject matter characterizing any one example may be, but is not necessarily, combined with the subject matter characterizing any other example.

As used here, the symbol "N" refers to any natural number and, more specifically, to any positive integer.

Unless otherwise indicated, the terms "first," "second," "third," etc. are used herein merely as labels, and are not intended to impose ordinal, positional, or hierarchical requirements on the items to which these terms refer.

As used herein, the phrase "at least one of", when used with a list of items, means different combinations of one or more of the listed items may be used and only one of each item in the list may be needed. For example, "at least one of item A, item B, and item C" may include, without limitation, item A or item A and item B. This example also may include item A, item B, and item C, or item B and item C. In other examples, "at least one of" may be, for example, without limitation, two of item A, one of item B, and ten of item C; four of item B and seven of item C; and other suitable combinations. As used herein, the term "and/or" and the "/" symbol includes any and all combinations of one or more of the associated listed items.

For the purpose of this disclosure, the terms "coupled," "coupling," and similar terms refer to two or more elements that are joined, linked, fastened, attached, connected, put in communication, or otherwise associated (e.g., mechanically, electrically, fluidly, optically, electromagnetically) with one another. In various examples, the elements may be associated directly or indirectly. As an example, element A may be directly associated with element B. As another example, element A may be indirectly associated with element B, for example, via another element C. It will be understood that not all associations among the various disclosed elements are necessarily represented. Accordingly, couplings other than those depicted in the figures may also exist.

As used herein, the term "approximately" refers to or represent a condition that is close to, but not exactly, the stated condition that still performs the desired function or achieves the desired result. As an example, the term "approximately" refers to a condition that is within an acceptable predetermined tolerance or accuracy, such as to a condition that is within <NUM>% of the stated condition. However, the term "approximately" does not exclude a condition that is exactly the stated condition. As used herein, the term "substantially" refers to a condition that is essentially the stated condition that performs the desired function or achieves the desired result.

To the extent that terms "includes," "including," "has," "contains," "containing," and variants thereof are used herein, such terms are intended to be inclusive in a manner similar to the term "comprises" as an open transition word without precluding any additional or other elements.

<FIG> and <FIG>, referred to above, may represent functional elements, features, or components thereof and do not necessarily imply any particular structure. Accordingly, modifications, additions and/or omissions may be made to the illustrated structure. Additionally, those skilled in the art will appreciate that not all elements, features, and/or components described and illustrated in <FIG> and <FIG>, referred to above, need be included in every example and not all elements, features, and/or components described herein are necessarily depicted in each illustrative example. Accordingly, some of the elements, features, and/or components described and illustrated in <FIG> and <FIG> may be combined in various ways without the need to include other features described and illustrated in <FIG> and <FIG>, other drawing figures, and/or the accompanying disclosure, even though such combination or combinations are not explicitly illustrated herein. Similarly, additional features not limited to the examples presented, may be combined with some or all of the features shown and described herein. Unless otherwise explicitly stated, the schematic illustrations of the examples depicted in <FIG> and <FIG>, referred to above, are not meant to imply structural limitations with respect to the illustrative example. Rather, although one illustrative structure is indicated, it is to be understood that the structure may be modified when appropriate. Accordingly, modifications, additions and/or omissions may be made to the illustrated structure. Furthermore, elements, features, and/or components that serve a similar, or at least substantially similar, purpose are labeled with like numbers in each of <FIG> and <FIG>, and such elements, features, and/or components may not be discussed in detail herein with reference to each of <FIG> and <FIG>. Similarly, all elements, features, and/or components may not be labeled in each of <FIG> and <FIG>, but reference numerals associated therewith may be utilized herein for consistency.

In <FIG> and <FIG>, referred to above, the blocks may represent operations, steps, and/or portions thereof and lines connecting the various blocks do not imply any particular order or dependency of the operations or portions thereof. It will be understood that not all dependencies among the various disclosed operations are necessarily represented. <FIG> and <FIG> and the accompanying disclosure describing the operations of the disclosed methods set forth herein should not be interpreted as necessarily determining a sequence in which the operations are to be performed. Rather, although one illustrative order is indicated, it is to be understood that the sequence of the operations may be modified when appropriate. Accordingly, modifications, additions and/or omissions may be made to the operations illustrated and certain operations may be performed in a different order or simultaneously. Additionally, those skilled in the art will appreciate that not all operations described need be performed.

Further, references throughout the present specification to features, advantages, or similar language used herein do not imply that all of the features and advantages that may be realized with the examples disclosed herein should be, or are in, any single example. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an example is included in at least one example. Thus, discussion of features, advantages, and similar language used throughout the present disclosure may, but do not necessarily, refer to the same example.

Claim 1:
A system (<NUM>) for analyzing vehicle system logs, the system (<NUM>) comprising:
a processor (<NUM>); and
a storage device (<NUM>) comprising instructions (<NUM>), execution of which causes the processor (<NUM>) to:
connect with an onboard system (<NUM>) of a vehicle (<NUM>), wherein the onboard system (<NUM>) is connectable to a network (<NUM>);
collect an activity log (<NUM>) generated by the onboard system (<NUM>), wherein the activity log (<NUM>) comprises log messages (<NUM>) indicative of an activity (<NUM>) of the onboard system (<NUM>);
extract a feature list (<NUM>) from the activity log (<NUM>), wherein the feature list (<NUM>) comprises features (<NUM>) and each one of the features (<NUM>) comprises select information from a corresponding one of the log messages (<NUM>);
extract an episode (<NUM>) from the feature list (<NUM>), wherein the episode (<NUM>) is indicative of the activity (<NUM>) of the onboard system (<NUM>); and
classify the episode (<NUM>) with an episode classification (<NUM>), wherein the episode classification (<NUM>) is indicative of an event (<NUM>) that occurred during the activity (<NUM>),
wherein execution of the instructions (<NUM>) causes the processor (<NUM>) to compare an occurrence of the episode classification (<NUM>) to a predetermined occurrence threshold (<NUM>) over a predetermined time period.