Vehicle Predictive Control System and Method

The subject matter described herein relates to a predictive system and method for controlling a vehicle system.

Precision railroading was established from the continued pressure in the railroad industry to improve route and load efficiencies. Precision railroading is designed to reduce the overall transportation costs and maximize crew resources for the operating railroad. This trend has led to a bias for increasing the overall length of trains, which can be relatively more challenging to operate. Train separations and derailments may negatively impact the railway system and contribute to overall system costs and delays.

One method of mitigating in-train forces is through end-of-car-cushioning (EOC) couplers. EOC couplers help to absorb the in-train forces that contribute to train separations and derailments but create train-handling changes depending on their placement within the train. However, larger trains and trains that require a higher percentage of EOC couplers are limited to lower speeds when they use EOC couplers. In many cases, the extra care required in the operation of trains with EOC couplers that may counter the benefits provided by precision railroading.

Once load distribution/ length issues are identified for trains with EOC couplers it may be too late to easily reconfigure the train build, add distributed power sources, or place equipment handling speed restrictions on the train. These issues may be identified for trains with EOC couplers once the train is in operation on the rails, and so leave train operators with very few options to mitigate potential issues. It may be desirable to have a system and method that differs from those that are currently available.

In one aspect, the present disclosure provides a method comprising executing a first simulation based on build data, trip data, and a driving profile, and the first simulation computationally renders a numerical representation of a vehicle system traversing a route, wherein the vehicle system comprises a plurality of vehicles; and determining a risk potential for an undesired event of the vehicle system at a determined location along the route based at least in part on the first simulation; determining the risk potential for the undesired event exceeds a determined risk threshold at the determined location along the route based at least in part on the first simulation; and communicating a notification to a client device that indicates of the undesired event of the vehicle system at the determined location along the route.

In another aspect, the present disclosure provides a system comprising a route simulation server for communicating with a client device in a communication network that is configured to: obtain build data of a plurality of vehicles that form a vehicle system; obtain trip data comprising a route and route parameters; obtain a driving profile comprising operational settings for the vehicle system to traverse the route constrained by route operating rules based at least in part on the trip data; execute a first simulation based at least in part on the build data, the driving profile, the trip data, wherein the first simulation computationally models the vehicle system traversing the route; determine a risk likelihood that the vehicle system will experience a undesired event based on the first simulation; and communicate a notification to the client device that indicates a risk likelihood value for whether the vehicle system will experience the undesired event.

In yet another aspect, the present disclosure provides a system comprising a route simulation server for communicating with a client device in a communication network that is configured to: obtain build data of a plurality of vehicles that form a vehicle system; obtain trip data comprising a route and route parameters; obtain a driving profile comprising operational settings for the vehicle system to traverse the route constrained by route operating rules based at least in part on the trip data; execute a first simulation based at least in part on the build data, the driving profile, the trip data, wherein the first simulation computationally models the vehicle system traversing the route; determine a risk potential of an undesired event of the vehicle system at a location along the route based at least in part on the first simulation; determine a remediation strategy based on the undesired event in the first simulation selected from a modification to the driving profile, a route change, a reconfiguration of the vehicle system, or a combination of two or more thereof; execute a second simulation for the vehicle system based on the remediation strategy; determine the second simulation does not result in a subsequent undesired event; and communicate a notification to the client device that indicates the risk potential of the undesired event of the vehicle system at the location along the route after the remediation strategy reduces the risk potential of a subsequent undesired event to less than a determined risk threshold value.

The subject matter described herein relates to a system and method for a predictive vehicle control system and method. In one aspect, the present disclosure provides a method and system for evaluating load distribution in a vehicle system as a function of a vehicle driving profile, route, and route parameters. A system, according to one embodiment, may evaluate vehicle build data through computational simulations. The simulation can be based on the vehicle build data, a generated driving profile, and the route and route parameters. The methods and systems may model/simulate one or more potential events based on the computational simulations and may further generate and execute remediation strategies. The modeling may be done prior to the train being built, and/or may be done prior to the train (once built) leaving the yard. Forearmed with this knowledge, the train build may be modified prior to leaving the yard, or other changes (such as route, trip plan, driving profile, etc.) may be made that, according to the modeling simulation, provide a more desirable outcome during the actual vehicle operation.

1 FIG. 100 102 104 106 110 108 shows a communication systemfor simulating vehicle build data, including a client systemin communication with a simulation serverin a communication network, according to at least one embodiment of the present disclosure. The simulation server may include a databaseof trip data (e.g., routes and route parameters) or may request the trip data from a database server. Suitable route parameters may include elevation loss/gain, route grade, degree of curvature of the route, track health, track infrastructure, and geographical features (e.g., crossing, bridge, intersection). Other route parameters may include environmental data (weather, e.g.) Yet other parameters that may be considered by the system may include vehicle system information (e.g., model information for couplers, propulsion systems for vehicles, distribution of the propulsion vehicles within the train, and non-propulsion vehicle information). Suitable non-propulsion vehicle information may include the placement and type of rail car, its status (as being full/empty), its measured or estimated weight, brake health and type, and the like. The simulation server may generate a computation model of the route based on the route parameters and other parameters to simulate the vehicle build data.

Additionally, the database may store historical performance data from previous trips, allowing for comparisons between simulated results and actual real-world outcomes. By incorporating historical data, the simulation server can adjust its algorithms to account for real-world deviations from the expected model, improving the accuracy of future simulations. Additionally, external factors such as weather conditions (e.g., temperature, wind speed, precipitation) may be integrated into the simulation to further enhance the predictive accuracy of the simulation server.

112 The simulation server may request a driving profile, from an energy management system(e.g., vTrip, TripOptimizer; both are commercially available from Wabtec Corporation), and/or generate the driving profile based on the vehicle build data, the route, route parameters, and/or the computational model of the route. The driving profile may be based on optimized fuel efficiency, operating rules (e.g., speed limits at specific locations), the propulsion vehicle specifications (e.g., load rating, power rating, fuel efficiency). The energy management system may generate a driving profile based on a desired operating profile. This profile can be varied to fulfill railroad business objective. (e.g., fastest runtime, most fuel-efficiency, targeted arrival time). The energy management system may only consider operational restrictions along a route and the capabilities of a propulsion vehicle when designing a driving profile. Therefore, the simulation server is needed to evaluate the likelihood of an undesirable event that could arise on a route with the driving profile.

In one embodiment, the energy management system may provide multiple driving profiles based on different criteria, such as minimizing travel time, reducing wear and tear on equipment, controlling emission aspects, or balancing fuel efficiency with other operational considerations. The simulation server may then run multiple simulations based on these profiles, comparing the results to identify the most optimal driving strategy, not just in terms of fuel savings, but also in reducing the likelihood of an undesirable event like separations or derailments. The simulation server may factor in operational constraints (e.g., crew scheduling or delivery deadlines), which can conflict with the most fuel-efficient route.

Once the simulation server has received the data (e.g., the driving profile, the vehicle build data, and the route, route features), it may simulate a plurality of intra-vehicle forces for each vehicle in the vehicle system. The simulation may compute the plurality of forces at a determined locations on each vehicle, at a continuous sampling interval throughout the duration of the entire route/trip, determined mile markers or points on the route, or determined distance intervals along the route. The simulation server may identify mile markers along the route based on determined route parameter thresholds (e.g., grade change threshold, a curvature threshold, or a combination thereof). The plurality of forces may include lateral, longitudinal, vertical, inertial, centripetal, centrifugal, and dynamic forces. The simulation server may determine resultant force vectors based on a combination of the plurality of forces. The simulation server may then calculate or determine force thresholds for an undesirable event. The simulation server compares a plurality of simulated forces to force thresholds for the undesirable event. With regard to undesirable events, these may include vehicle separation, tip over, overspeed, undue wear on track components or vehicle components, operational misses, operational anomalies, other safety concerns, and vehicle system derailment.

Additionally, in predicting an undesirable event occurrence, the simulation server may further analyze the force vectors to determine their impact on various components of the vehicle system, including the couplers, brakes, and suspension systems. The simulation server may further analyze dynamic load balancing between vehicles, particularly for trains with mixed freight (e.g., heavy cargo interspersed with lighter loads), which could influence the distribution of forces along the length of the train. In one embodiment, the simulation server may incorporate probabilistic models to account for uncertainties in the data, such as variations in track conditions or minor discrepancies in vehicle build configurations. This may allow the system to assess the risk of an undesirable event occurring in a more comprehensive manner.

2 FIG. 200 202 204 210 208 202 206 216 a d a d a d shows a first simulationincluding a plurality of vehicles-, and a powered vehicleformed into a vehicle systemthat is traversing a determined route, according to at least one embodiment of the present disclosure. The vehicle system includes a plurality of non-propulsion vehicles-(e.g., railcars) and one or more propulsion vehicle (e.g., locomotive) physically coupled to each other by couplers-. The simulation server may evaluate the plurality of forces exerted on the vehicle system based on a generated driving profile, build data (e.g., load distribution, car position, total number of cars, vehicle system length) the route, route parameters (e.g., elevation, terrain, degree of curvature). The simulation server may determine the plurality of forces at a determined location or pointalong the route or may continuously sample the plurality of forces at a determined distance interval (e.g., every 50 ft or 15 m) along the route.

212 202 214 202 206 206 202 202 206 b c c b b c b In one example, the simulation server may evaluate the relative forces the couplers between adjacent vehicles to determine the likelihood of an undesirable event occurring. One such undesirable event is a break of couplers between vehicles, referred to as a separation event. A separation event may occur when cumulative forces acting on the couplers between two adjacent vehicles exceeds a force rating for the coupler. The simulation server generates a first force evaluationfor a first vehicleand a second force evaluationfor a second vehiclewhen the coupleris at point. The simulation server may estimate or determine a cumulative force acting on the couplerbased on the first force evaluation and the second force evaluation. If the cumulative force exceeds the force rating for the coupler, the simulation server may identify the associated vehicles,, coupler, and point on the route associated with the undesirable event occurrence. The force rating of the coupler may be stored in the database server and provided to the simulation server with the trip data.

Analogously, the simulation server may predict additional, or alternative, an undesirable event. Examples of predictable undesired events may include one or more of a brake system failure, traction failures, thermal management failures, and the like. Where the braking force is insufficient to stop or slow down the train effectively this may lead to a potential overspeed conditions, or a skid or slip where wheels lose traction. Traction may be especially affected by adverse weather conditions. In an overheating event there may be excessive friction or mechanical stress, and this may lead to equipment damage or a fire hazard. The simulation server may calculate a statistical value as the risk potential of an undesired event based on a different is simulated values to threshold values. In one example, if the risk potential exceeds a determined threshold, the simulation server may determine that a remediation action is required.

3 FIG. 300 312 316 302 304 shows a second simulationof a vehicle system including a plurality of vehicles traversing a determined route, according to at least one embodiment of the present disclosure. The simulation server may determine a plurality of forcesfor each of a plurality of vehicles in the vehicle system at a second pointalong the route. The second simulation may determine the likelihood or potential risk of a derailment based on the centrifugal forceexceeding a determined force based on the massof the vehicle. The simulation server may determine a plurality of forces associated with a plurality of adjacent vehicles at the second point. The simulation server may aggregate the forces of three adjacent vehicles to determine if the plurality of vehicles combine to increase or decrease the likelihood or potential risk of a derailment.

4 FIG. 400 412 416 402 404 shows a third simulationof a vehicle system including a plurality of vehicles traversing a portion of a determined route where the track is banked, according to at least one embodiment of the present disclosure. The simulation server may determine a plurality of forces, according to a vector diagram for each of a plurality of vehicles in the vehicle system at a third pointalong the route. The simulation server may computationally render the vector diagram but may not generate a visual image of the vector diagram. The third simulation may determine the likelihood of a derailment based on the centripetal forceexceeding a determined force based on the massof the vehicle. The simulation server may also determine a plurality of forces associated with a plurality of adjacent vehicles at the second point. The simulation server may aggregate the forces of three adjacent vehicles to determine if the plurality of vehicles combine to increase or decrease the likelihood of a derailment.

Once simulation server determines one or more points along the route that are susceptible to a undesired event, the simulation server may determine one or more remediation strategies including reconfiguring the build data, determining an alternative route, determining a location in the vehicle system to add a propulsion vehicle, modify the driving profile, relocation of cars with EOC couplers, or a combination thereof. The simulation server may perform a subsequent simulation with modified data based on the remediation strategy to verify that the remediation strategy does not result in an undesirable event. Additionally, the simulation server may notify the client device of the undesired event in a first simulation, the location on the route of the undesired event, and a remediation strategy. Alternatively, the simulation server may notify the client device of the undesired event and request a specific remediation strategies or updated build data.

In one example, the simulation server may identify the location of the undesired event and determine a different route that avoids the route parameter (e.g., change in grade over a determined distance, relative degree of curvature in the route over a determined distance). In another example, the simulation server may automatically implement a remediation strategy based on reconfiguring the build data, determining an alternative route, determining a location in the vehicle system to add a propulsion vehicle, modify the driving profile, relocation of cars with EOC couplers, or a combination thereof. For example, if the simulation server determines that a first driving profile results in a undesired event, the simulation server may automatically update an energy management system with an updated driving profile that does not result in an undesirable event. In another example, the simulation server may generate one or more recommended vehicle builds to the client device, where the client device may select a recommended vehicle build or select a different remediation strategy if the vehicle system cannot be reconfigured. Although it may be ideal from a physics perspective to configure a vehicle system in one manner, it may create unintended consequences for a rail yard. Some of these consequences may be operational in nature. Vehicle builds may consider the convenience of pickup and delivery that can influence certain vehicles being grouped together. There may be such soft constraints on build make up.

5 FIG. 500 502 504 506 508 510 512 514 516 518 shows a methodfor evaluating train build data by simulating the vehicle system traversing a route, according to at least one embodiment of the present disclosure. The simulation server receivesbuild data for a plurality of vehicles that include the vehicle system. The build data may include The simulation server further receivestrip data including a route between a starting location and a destination location and route parameters (e.g., route grade at various mile posts or points along the route, degree of route curvature at mile posts or points along the route, track health, track infrastructure, geographical features, ). The simulation server may generatea driving profile based operational settings for the vehicle system to traverse the route constrained by operating rules. Alternatively, the simulation server may request or receive the driving profile from an energy management system. The driving profile including operating settings throughout the route including vehicle system speeds, acceleration points, and deceleration or braking points. After obtaining the driving profile, the simulation server may executea first simulation based on the trip data, the build data, and the driving profile. The simulation server determinesa risk potential that a undesired event of the vehicle system is likely to occur at a location along the route based at least in part on the first simulation. The undesired event may be determined based on a comparison to the threshold forces determined for the vehicle system. The threshold forces may be based on vehicle specific information, the vehicle build data, and/or statistical analysis of calculated forces (e.g., standard deviation of a force required to result in the failure, breakage or separation of a coupler on a specific vehicle model). The risk potential may indicate the likelihood that a specific undesired event may occur or may indicate that there is a potential risk based on a weighting of multiple undesired events. The simulation server may determine that the build data exceeds a determined threshold for a undesired event when the vehicle is operated under the current driving profile. The simulation server may evaluate a plurality of remediation options and generatea remediation strategy based on reconfiguring the build data, determining an alternative route, determining a location in the vehicle system to add a propulsion vehicle, modify the driving profile, add EOC couplers, or a combination thereof. The simulation server may executea second simulation based on the remediation strategy. The simulation server may determinethe second simulation does not result in a undesired event or repeats the evaluation of the remediation options until a simulation does not result in a undesired event. The simulation server may communicatea notification to the client device, where notification indicates that a first simulation results in a undesired event, and either a recommended remediation strategy or an indication that a remediation strategy was automatically performed.

Examples of the methods and systems disclosed herein, according to various aspects of the present disclosure, are provided in various embodiments. An aspect of the method may include any one or more than one of, and any combination of, the embodiments described herein.

In a first embodiment a method begins by executing a first simulation based on build data, trip data, and a driving profile, and the first simulation computationally renders a numerical representation of a vehicle system traversing a route, wherein the vehicle system comprises a plurality of vehicles. Once the parameters are obtained, the method continues by determining a risk potential for an undesired event of the vehicle system at a determined location along the route based at least in part on the first simulation, and determining the risk potential for the undesired event exceeds a determined risk threshold at the determined location along the route based at least in part on the first simulation. Once the determinations are made, the method continues by communicating a notification to a client device that indicates of the undesired event of the vehicle system at the determined location along the route.

In a first aspect of the first embedment, the method continues by obtaining the build data for the plurality of vehicles that form the vehicle system, wherein the build data comprises, for each of the plurality of vehicles in the vehicle system at least one of: a vehicle identifier, an arrangement location of the plurality of vehicles in the vehicle system, a vehicle orientation, a vehicle health and maintenance status, a vehicle weight, or a vehicle type, or a combination of two or more thereof. Additionally or alternatively, the method continues by obtaining the trip data that has the route and route parameters, wherein the route parameters include for one or more locations on the route at least one of: a grade, an elevation, a degree of curvature, a track health, an infrastructure system, or a crossing, or a combination of two or more thereof.

In a second aspect of the first embedment, the method continues by modifying the build data of the vehicle system; executing a second simulation based on the modified build data, the trip data, and the driving profile; determining an updated risk potential of the undesired event at the determined location based on the second simulation; and determining whether the updated risk potential for the undesired event is lower than the determined risk threshold.

In a third aspect of the first embedment, the method continues by selecting a different route comprising different route parameters; changing the trip data based on the selected different route; determining a new driving profile based on the selected different route; executing a second simulation based on the build data, the changed trip data, and the new driving profile; determining an updated risk potential of the undesired event at the determined location based on the second simulation; and determining whether the updated risk potential for the undesired event is lower than the determined risk threshold.

In a fourth aspect of the first embedment, the method continues wherein the undesired event is a derailment of the vehicle system or a coupler separation between a first vehicle and a second vehicle in the vehicle system, wherein the notification comprises a request to redistribute a vehicle load for one or more vehicles in the vehicle system, and/or wherein the notification comprises at least one of: a request to rebuild the vehicle system, reroute the trip data, alter the driving profile, or two or more of a combination thereof.

In a fifth aspect of the first embedment, the method continues by executing the first simulation, which comprises: generating the driving profile comprising operational settings for the vehicle system to traverse the route constrained by route operating rules; determining a plurality of vehicle forces affecting the vehicle system in the route; and determining the undesired event is based at least in part on one of the plurality of vehicle forces exceeding a determined coupler force threshold value. The method continues wherein the plurality of vehicle forces are determined between each vehicle of the vehicle system, and are recalculated at a determined distance interval throughout the route or at determined route features associated with the route; and/or further comprising: modifying the driving profile at the determined location along the route at which the risk potential of an undesirable event is greater than a determined threshold value; executing a second simulation based on the build data, the trip data, and the modified driving profile; and determining an updated risk potential of the undesired event at the determined location based on the second simulation determining whether the updated risk potential for the undesired event is lower than the determined risk threshold.

In a sixth aspect of the first embedment, the method continues wherein executing the first simulation comprises determining lateral forces, longitudinal forces, centripetal forces, and/or centrifugal forces on two or more of the plurality of vehicles in the vehicle system; and/or wherein determining the undesired event is based on the lateral forces, the longitudinal forces, the centripetal forces, and/or the centrifugal forces exceeding a determined lateral force, longitudinal force, centripetal force, and/or centrifugal force threshold value.

In a second embodiment a system includes a route simulation server for communicating with a client device in a communication network. The route simulation server is configured to: obtain build data of a plurality of vehicles that form a vehicle system, trip data comprising a route and route parameters, and a driving profile comprising operational settings for the vehicle system to traverse the route constrained by route operating rules based at least in part on the trip data. Once the route simulation server has obtained the data, it is configured to execute a first simulation based at least in part on the build data, the driving profile, the trip data, wherein the first simulation computationally models the vehicle system traversing the route, determine a risk likelihood that the vehicle system will experience a undesired event based on the first simulation, and communicate a notification to the client device that indicates a risk likelihood value for whether the vehicle system will experience the undesired event.

In a first aspect to second embodiment, the build data comprises, for each of the plurality of vehicles in the vehicle system, one or more of: a vehicle identifier, an arrangement location of the plurality of vehicles within the vehicle system, a vehicle orientation, a vehicle health and maintenance status, a vehicle weight, a vehicle type, or a combination of two or more thereof.

In a second aspect to second embodiment, the route parameters comprise at one or more locations one or more of: a grade, an elevation, a degree of curvature, a track health, an infrastructure system, and a crossing, or a combination of two or more thereof.

In a third aspect to second embodiment, wherein the route simulation server is further configured to determine at least one of: the undesired event caused at least in part by vehicle forces exceeds a determined coupler force threshold value; or lateral forces, longitudinal forces, centripetal forces, and/or centrifugal forces on each of the plurality of vehicles in the vehicle system exceeds a determined lateral force threshold value, longitudinal force threshold value, centripetal force, and/or force centrifugal threshold value, or a combination of two or more thereof. Additionally or alternatively, the notification comprises a request to rebuild the vehicle system, reroute the trip data, or alter the driving profile; and/or the vehicle forces are determined between two or more vehicles of the vehicle system, and the vehicle forces are recalculated at a determined distance interval throughout the route or at determined route features associated with the route.

In a third embodiment, a system comprises a route simulation server for communicating with a client device in a communication network. The route simulation server is configured to: obtain build data of a plurality of vehicles that form a vehicle system, trip data comprising a route and route parameters, and a driving profile comprising operational settings for the vehicle system to traverse the route constrained by route operating rules based at least in part on the trip data. Once the simulation server obtains these parameter, it executes a first simulation based at least in part on the build data, the driving profile, the trip data, wherein the first simulation computationally models the vehicle system traversing the route, and determines a risk potential of an undesired event of the vehicle system at a location along the route based at least in part on the first simulation, and a remediation strategy based on the undesired event in the first simulation selected from a modification to the driving profile, a route change, a reconfiguration of the vehicle system, or a combination of two or more thereof. The route simulation server then executes a second simulation for the vehicle system based on the remediation strategy, determines the second simulation does not result in a subsequent undesired event; and communicates a notification to the client device that indicates the risk potential of the undesired event of the vehicle system at the location along the route after the remediation strategy reduces the risk potential of a subsequent undesired event to less than a determined risk threshold value.

In a third embodiment, a system comprises a route simulation server for communicating with a client device in a communication network. The route simulation server is configured to: obtain build data of a plurality of vehicles that form a vehicle system, trip data comprising a route and route parameters, and a driving profile comprising operational settings for the vehicle system to traverse the route constrained by route operating rules based at least in part on the trip data. Once the simulation server obtains these parameter, it executes a first simulation based at least in part on the build data, the driving profile, the trip data, wherein the first simulation computationally models the vehicle system traversing the route, and determines a risk potential of an undesired event of the vehicle system at a location along the route based at least in part on the first simulation, and a remediation strategy based on the undesired event in the first simulation selected from a modification to the driving profile, a route change, a reconfiguration of the vehicle system, or a combination of two or more thereof. The route simulation server then executes a second simulation for the vehicle system based on the remediation strategy, determines the second simulation does not result in a subsequent undesired event; and communicates a notification to the client device that indicates the risk potential of the undesired event of the vehicle system at the location along the route after the remediation strategy reduces the risk potential of a subsequent undesired event to less than a determined risk threshold value.

In various aspects, one or more systems (e.g., control system) in the communication network may process data using artificial intelligence or machine learning. The communication network includes a local data collection system deployed that may use machine learning to enable derivation-based learning outcomes. The communication network may learn from and make decisions on a set of data (including data provided by the various sensors), by making data-driven predictions and adapting according to the set of data. In embodiments, machine learning may involve performing a plurality of machine learning tasks by machine learning systems, such as supervised learning, unsupervised learning, and reinforcement learning. Supervised learning may include presenting a set of example inputs and desired outputs to the machine learning systems. Unsupervised learning may include the learning algorithm structuring its input by methods such as pattern detection and/or feature learning. Reinforcement learning may include the machine learning systems performing in a dynamic environment and then providing feedback about correct and incorrect decisions. In examples, machine learning may include a plurality of other tasks based on an output of the machine learning system. In examples, the tasks may be machine learning problems such as classification, regression, clustering, density estimation, dimensionality reduction, anomaly detection, and the like. In examples, machine learning may include a plurality of mathematical and statistical techniques. In examples, the many types of machine learning algorithms may include decision tree based learning, association rule learning, deep learning, artificial neural networks, genetic learning algorithms, inductive logic programming, support vector machines (SVMs), Bayesian network, reinforcement learning, representation learning, rule-based machine learning, sparse dictionary learning, similarity and metric learning, learning classifier systems (LCS), logistic regression, random forest, K-Means, gradient boost, K-nearest neighbors (KNN), a priori algorithms, and the like. In embodiments, certain machine learning algorithms may be used (e.g., for solving both constrained and unconstrained optimization problems that may be based on natural selection). In an example, the algorithm may be used to address problems of mixed integer programming, where some components restricted to being integer-valued. Algorithms and machine learning techniques and systems may be used in computational intelligence systems, computer vision, Natural Language Processing (NLP), recommender systems, reinforcement learning, building graphical models, and the like. In an example, machine learning may be used for vehicle performance and behavior analytics, and the like.

The foregoing detailed description has set forth various forms of the systems and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, and/or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Those skilled in the art will recognize that some aspects of the forms disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as one or more program products in a variety of forms, and that an illustrative form of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution.

As used in any aspect herein, the term “logic” may refer to an app, software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices.

As used in any aspect herein, the terms “component,” “system,” “module” and the like can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution.

As used in any aspect herein, an “algorithm” refers to a self-consistent sequence of steps leading to a desired result, where a “step” refers to a manipulation of physical quantities and/or logic states which may, though need not necessarily, take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is common usage to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. These and similar terms may be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities and/or states.

This written description uses examples to disclose several embodiments of the inventive subject matter and also to enable a person of ordinary skill in the art to practice the embodiments of the inventive subject matter, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the inventive subject matter is defined by the claims, and may include other examples that occur to those of ordinary skill in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.