System and method and defense system for adaptive method for vehicle intrusion detection for vehicles running in fleet or formation

Abstract

A method performed by an on-board unit of a vehicle includes receiving real-time data from a vehicle in a fleet, where the data includes an indicator regarding a type of vehicle within the fleet; providing a policy with a set of rules and comparing the data to the policy; providing a reference data set corresponding to the fleet, wherein the reference data set includes previous data trends indicative of normal operation of the fleet; comparing the data set with the reference data set, wherein a determination of whether the data set deviates from a previous data trend is based on operation of one of the vehicles in the fleet; and initiating an operation when both violations to the policy and deviations within the data set from the reference data set are detected.

Description

[0001] Cross-references to related applications This application claims the benefit and priority of U.S. Application No. 18 / 320,631, filed May 19, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure relates to intrusion detection systems (IDS), such as those in transportation vehicles. Background Technology

[0003] Controller Area Network (CAN) bus is a central communication network in several modern systems such as automotive, aerospace, and industrial systems. Nodes on the CAN bus, and more generally within the network of a transportation vehicle, are equipped with remote interfaces. These interfaces are frequently used to enable over-the-air updates and, along with them, to provide additional services, measure the use of applications, measure the use of certain functions in the ECU for maintenance services, etc.

[0004] Another trend in the automotive industry is the demand for vehicles equipped with attack detection systems, known as Intrusion Detection Systems (IDS). Modern vehicles are equipped with numerous Electronic Control Units (ECUs) connected via networks using CAN, automotive Ethernet, or other networking technologies. These ECUs control the vehicle by running increasingly sophisticated software, and network connectivity has been further enhanced by sensor data such as camera streams or lidar. The resulting automotive systems are becoming increasingly attractive targets for adversaries interested in compromising them. Manipulation of network traffic or process changes on the ECUs poses various threats to passengers, road users, and the vehicle itself.

[0005] The adoption of IDS is driven by the increased attack surface in transport vehicles and the resulting potential for catastrophic security risks. Consequently, new regulations (e.g., WP.29, UN R 155) have been developed that require transport vehicles to have IDS capable of detecting and potentially responding to attacks.

[0006] IDS is designed to detect such hazards and collect various vehicle data to verify consistency and ensure the integrity of network traffic, command, and control. Recent IDS solutions send this data to a cloud backend for further processing. Summary of the Invention

[0007] A first embodiment provides a method performed by an onboard unit of a transportation vehicle, comprising: receiving real-time data from transportation vehicles in a fleet, wherein the data includes indicators of the type of transportation vehicle within the fleet; providing a strategy having a set of rules and comparing the data with the strategy; providing reference data corresponding to the fleet, wherein the reference dataset includes previous data trends indicating normal operation of the fleet; comparing the dataset with the reference dataset, wherein the determination of whether the dataset deviates from the previous data trends is based on the operation of one of the transportation vehicles in the fleet; and initiating an operation when both a violation of the strategy and a deviation within the dataset from the reference dataset are detected.

[0008] A second embodiment discloses a method performed by an onboard unit of a transportation vehicle. The method includes receiving a dataset in real time from multiple transportation vehicles in a fleet, wherein a first dataset includes indicators of the types of transportation vehicles within the fleet. The method further includes providing a reference dataset corresponding to the multiple transportation vehicles in the fleet, wherein the reference dataset includes previous data trends indicating normal operation of the transportation vehicles in the fleet. The step further includes comparing the dataset with the reference dataset, wherein the determination of whether the dataset deviates from the previous data trend is based on the operation of one of the multiple transportation vehicles in the fleet. Further, the method includes initiating an operation when a deviation from the reference dataset is detected within the dataset.

[0009] A third embodiment discloses a system for monitoring multiple vehicles in a fleet. The system includes: a wireless transceiver, located in one or more of the multiple vehicles and configured to transmit data from the multiple vehicles; and one or more processors communicating with the wireless transceiver. The one or more processors are jointly programmed to: receive a dataset in real time from the multiple vehicles in the fleet, wherein a first dataset includes indicators of the type of vehicle in the fleet; provide a reference dataset corresponding to the multiple vehicles in the fleet, wherein the reference dataset includes previous data trends indicating normal operation of the vehicles in the fleet; compare the dataset with the reference dataset, wherein the determination of whether the dataset deviates from the previous data trend is based on the operation of one of the vehicles in the fleet; and when a deviation from the reference dataset is detected within the dataset, initiate an operation to output a notification. Attached Figure Description

[0011] Figure 1 This is a simplified block diagram of a communication system for analyzing the behavior of transportation vehicles in a network environment, according to an embodiment of the present disclosure. Figure 2 This is a simplified block diagram illustrating details of possible examples that can be associated with an embodiment of an on-board unit (OBU) of a communication system; Figure 3 This is a simplified block diagram illustrating a potential embodiment of a communication system in a network environment for analyzing the behavior of transportation vehicles according to the present disclosure; Figure 4 The illustration shows an example of the correlation on signals when two completely different vehicles from two different manufacturers travel the same route. Figure 5 An embodiment of a flowchart relating to the monitoring of transport vehicle formations is illustrated. Detailed Implementation

[0012] Embodiments of this disclosure are described herein. However, it should be understood that the disclosed embodiments are merely examples, and other embodiments may take various and alternative forms. The figures are not necessarily to scale; some features may be enlarged or reduced to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art to use the embodiments in various ways. As will be understood by those skilled in the art, the various features illustrated and described with reference to any figure may be combined with features illustrated in one or more other figures to produce embodiments not explicitly illustrated or described. The combinations of illustrated features provide representative embodiments of typical applications. However, various combinations and modifications of features consistent with the teachings of this disclosure may be desired for particular applications or implementations.

[0013] IDS can be utilized within a fleet of transportation vehicles. In addition to data collected from individual vehicles, IDS can also benefit from information gathered from external fleets of vehicles engaging in similar activities, such as trucks transporting goods from point A to point B. Anomalous correlations between relevant signals across different vehicles can reveal intrusions or attacks.

[0014] Potential anomalies can be detected locally within the vehicle using a so-called integrated on-board unit (OBU), and then compared with other vehicles for the purpose of detecting defects that can be corrected or mitigated by the vehicle manufacturer. Another feature may include a method that attempts to determine whether an anomaly occurred for more than a predefined threshold time, and if so, the method may report it or output an alarm or notification. Other embodiments may include a system that has an on-board unit (OBU) that monitors vehicle signals, driver physiological signals, and signals from changes or events around the monitored vehicle. The OBU may include a system that can include numerous nodes in a communication system, such as any device, network element, client, service, application, or other object that can send / receive / forward information via communication channels in a network. The system may determine whether the collected data deviates from a trend that depends at least in part on the current driver profile from the vehicle.

[0015] A policy-based trend analyzer can use reference data to modify policies or notify interested and authorized entities (e.g., manufacturers, government entities, etc.) of ongoing policy violations. For example, the policy-based trend analyzer can identify the speeds of most drivers on certain roads. In response, for example, speed limits can be changed or more speed enforcement can be used on that road. The performance of the model can be improved and the false positive or false negative rate reduced using probabilities from continuous training. Predictive diagnostics based on historical and real-time data can be used. In one embodiment, a cloud component can be utilized, enabling diagnostics to be implemented in the cloud and having the ability to collect and compare data from different deployments using different technologies.

[0016] Fault detection of anomalous behavior can be performed locally within the vehicle. Then, it can be determined whether an anomalous behavior trend is observed on a specific vehicle over time and spatial sequences, and whether this trend correlates with anomalous behavior trends in other vehicles. If no correlation exists, it is possible that some components in the vehicle have malfunctioned. Correlation analysis can also be performed via clustering. Compared to other systems, the proposed disclosed method can monitor the interactions of desired machines (e.g., ECUs or sensors in a vehicle) to progressively learn their behavioral logic and construct a state machine for each machine that can potentially mimic its behavior. Furthermore, illustrative embodiments can monitor the correlations between these machines relative to each other. An illustrative example could include that when both accelerator and brake pedal signals are active simultaneously, the brake pedal signal should have higher priority and override the accelerator pedal signal, and should be monitored as a safety requirement for proper operation.

[0017] Truck platooning can consist of sequences of two or more trucks linked together in a fleet traveling at short distances between vehicles using connectivity technologies and autonomous driving support systems. The truck at the head of the platoon acts as a leader, with the following vehicles reacting and adapting to changes in its movement. The driver controls the leader truck, while the following vehicles will—in the future—be able to be fully autonomous. Initially, the driver will always maintain control, but they can also decide to leave the platoon and drive independently.

[0018] The benefits of this platooning system include reduced fuel consumption and CO2 emissions, more efficient road use, faster freight delivery, and reduced traffic congestion. In platooning, only the lead driver actively drives. This allows the semi-drivers behind the lead vehicle to dedicate their time to other tasks, such as administrative work or making phone calls. From the perspective of using autonomous transport, this reduces the number of drivers required. Truck platooning also contributes to improved safety. Braking is automatic; trucks following the lead vehicle require only one-fifth the reaction time of a human.

[0019] When trucks in a convoy move along the same route, the signals of the transport vehicles will change in a similar way depending on the physical phenomena that occur. Therefore, the system can collect a set of signals from one truck, calculate the correlation coefficient between these signals, and use this information as a reference if the system might assume that some signals from another truck have been tampered with.

[0020] It is anticipated that once autonomous vehicles become feasible at Levels 4 and 5, passenger cars will also operate in this configuration. Therefore, the ideas described herein apply to both trucks and passenger cars. It has also been demonstrated that vehicles not in a fleet configuration but following a similar driving plan (i.e., start and wait 2 minutes, drive for 50 minutes, stop for 10 minutes, continue driving for 20 minutes) can benefit from the technology described in this disclosure even if they do not follow exactly the same routes. Therefore, vehicles in, for example, located in traffic-intensive areas will also benefit from the technology described in the next section.

[0021] The system described herein can detect anomalies using correlations between signals within the same vehicle and between signals between different vehicles in a platoon. In one embodiment, the vehicles in the platoon may not utilize any physiological signals at all (e.g., physiological signals from the driver that are never collected). This can be advantageous because there is no need to collect health information about the vehicles, thus mitigating any privacy concerns. The system can also consider data from outside the vehicle's equipment (mobile phones, laptops, various gadgets, etc.). In one example, a large difference in signal values ​​can also indicate a malfunction in one of the trucks in the platoon and can be used as an additional maintenance call signal (e.g., in the case of worn spare parts). Historical values ​​of relevant parameters can be used as an additional source of information for road condition monitoring.

[0022] Figure 1 A simplified block diagram of a communication system 10 for analyzing vehicle behavior in a transportation network environment is shown. Figure 1 An exemplary architecture includes an end user (driver) 2 operating a vehicle 4 in an environment 11, which includes an on-board unit (OBU) 30 or a processor / controller. In this particular example, the OBU 30 includes one or more processing elements 21, including a computing processor 22 and a routing processor 23. The OBU 30 may also include a memory element 24, a behavior engine module 25, a network interface 26, a user interface 27, and a display 28, wherein these devices may be associated with a specific end user (passenger or driver) within the vehicle 4. Typically, the OBU 30 may be suitably coupled to numerous different nodes in the communication system 10, wherein the nodes may be any device (e.g., machine equipment or mobile equipment), network element, client, server, peer, service, application, or other object capable of sending, receiving, or forwarding information through communication channels in the network. For example, in one example, a node may be another vehicle with a wireless transceiver or mobile phone.

[0023] The OBU 30 can be coupled to machine devices in the communication system 10, such as multiple sensors 14 ac, multiple vehicle control devices (e.g., one or more electronic control units (ECUs)) 16 ac, and multiple actuators, such as actuator 13. In one example embodiment, the sensors 14 ab and control devices 16 ab can be part of an automotive diagnostic system indicated by vehicle diagnostics 19, which can also be suitably integrated with the OBU 30. The OBU 30 can also include the ability to be associated with a navigation system 17 (e.g., Global Positioning System (GPS)). The OBU 30 can also be suitably coupled to various on-board mobile devices 18 ab at any given time, which can be associated with a specific end user (passenger or driver) within the vehicle 4.

[0024] Figure 1 It also includes one or more networks 40 representing various types of connections to the vehicle 4 (e.g., via antenna 29). Each of the networks 40 may have logical coupling to one or more remote nodes, including remote nodes of other vehicles 59 and various remote servers or “clouds” 41. A “remote node” can be any node located outside a particular vehicle, such as vehicle 4. Examples of possible remote nodes that may be located outside a vehicle include end-user equipment, mobile devices, network elements, electronic devices (e.g., servers in a data center, end-user equipment in a local area network (LAN), etc.), OBUs of other vehicles, roadside infrastructure equipment, and roadside user equipment.

[0025] Figure 1 The components can be coupled to each other via one or more interfaces (e.g., network interface 26) using any suitable connection (wired or wireless), providing a feasible path for electronic communication. Furthermore, any one or more of these components can be combined or removed from the architecture based on specific configuration needs. Communication system 10 may include a configuration capable of Transmission Control Protocol / Internet Protocol (TCP / IP) communication for the electronic transmission or reception of packets within the network. Communication system 10 may also operate with User Datagram Protocol / IP (UDP / IP) or any other suitable protocol, as appropriate and based on specific needs. Additionally, communication system 10 may include a configuration capable of accommodating a conventional bus subsystem 20 that can be used to transmit information across numerous machines and devices (e.g., sensors 14 ac, control devices 16 ac, actuators 13) within transport vehicle 4.

[0026] Embodiments of the communication system 10 enable the analysis of vehicle behavior in a network environment, including on-board and remote behavior analysis, remote diagnostics, anomalous behavior detection, and machine behavior learning, or any other methods. The on-board unit (OBU) within the vehicle can be configured to facilitate the collection of information associated with the vehicle's subsystems and various associated machine devices (e.g., sensors, actuators, ECUs, etc.) to enable real-time analysis of vehicle behavior in a real-world environment. In some embodiments, a behavior engine can be provided to monitor network flows in the vehicle's environment to detect anomalous trends in the vehicle. Predictive diagnostic techniques can substantially reduce or eliminate human bias and / or error in determining whether the safety of the vehicle has been compromised. Additionally, the collected information can be used to create behavioral state machines for the machine devices of the subsystems. These behavioral state machines can be used as a reference for behavior.

[0027] Useful but diverse networks may exist within modern transportation vehicles (e.g., cars, airplanes, trains, ships, etc.). When communication links are available, external networks can be accessed from the transportation vehicle via certain electronic devices. An "external network" can include networks located outside the transportation vehicle, where the network is a cluster of nodes interconnected by communication channels that facilitate electronic communication between them. For example, a mobile phone inside the transportation vehicle can be used to access a 3G base station to connect to other mobile devices or the Internet.

[0028] In addition to wireless network communications outside the vehicle, multiple internal network subsystems (e.g., bus subsystems, IP networks) may exist within the vehicle to provide communication paths to various machines distributed throughout the vehicle. As used herein, "subsystem" is intended to encompass networks within the vehicle, where the network is a cluster of nodes interconnected by communication channels that facilitate electronic communication between the nodes, in which the nodes are integrated with or otherwise linked to the vehicle. Nodes in an internal network subsystem may include machines such as sensors, actuators, electronic control units (ECUs), detectors, entertainment systems, etc., including speakers, CD and / or DVD players, wireless equipment, etc. Furthermore, internal network subsystems may exist for IP machines, such as certain vehicle navigation systems (e.g., GPS), and any other machines configured for IP communication.

[0029] Other internal transportation network can also exist within the vehicle and may be associated with simple content delivery. For example, mobile devices can be used within the vehicle to communicate with other electronic devices within the vehicle or with external networks (e.g., mobile phones with 3G internet connectivity). Therefore, various levels of network use, different network usage purposes, and different agents associated with network use (e.g., humans, machines, external devices, mobile devices) can all occur within a single vehicle. Network use in each identified scenario can have different scopes, different latency, different associated routing, different policy requirements, etc.

[0030] Subsystems in a transportation vehicle typically comprise traditional bus subsystems (or subnets), each providing a communication path to specific machine devices distributed throughout the vehicle. For example, in a typical automobile, more than 80 ECUs exchange data across these bus subsystems. Many of these subnets are isolated, making communication between them infeasible. However, the number of ECUs and the traffic flow exchanged between them are expected to continue to grow.

[0031] Transportation vehicles can employ many different bus subsystems to transmit information across multiple sensors and actuators distributed throughout the vehicle. Typical examples of transportation bus subsystems include Controller Area Network (CAN), which uses a message-based protocol designed for and typically used by automotive applications. The CAN bus is a transportation bus standard designed to allow microcontrollers, sensors, and other devices to communicate with each other via CAN (e.g., without a host computer). CAN can be used for soft real-time control of devices such as anti-lock braking systems. Local Area Network (LIN) can be used to sense external conditions such as light or to control small mechanisms such as door lock systems. Another additional bus subsystem may include FlexRay—a dedicated network for hard real-time controllers used in drive-by-wire and / or brake-by-wire applications, where information from the engine and / or wheels is collected and transmitted to appropriate applications and / or databases. System Transmission to Media (MOST) can also exist in transportation vehicles for transmitting audio, video, and voice over fiber optics. Some of these buses include transportation-specific interconnects. Additionally, Ethernet can be used to interconnect machine equipment within the transportation vehicle.

[0032] According to the embodiments disclosed herein, communication system 10 can address problems related to analyzing vehicle behavior, including vehicle behavior analysis, remote diagnostics, predictive diagnostics, and machine behavior. Specifically, communication system 10 can utilize one or more fully integrated on-board units (OBUs) 30 to manage vehicle behavior anomalies and machine behavior states. More specifically, the integrated OBUs 30 are configured to manage behavior anomalies from the vehicle 4 by receiving data, comparing the data with a reference dataset (which can be done in various ways, as further explained below), and identifying any differences between the data and the reference dataset. Data can be identified using any currently existing or future-developed means. Furthermore, the OBUs can utilize learning and monitoring processes to define machine behavior specifications for each vehicle.

[0033] In other embodiments disclosed herein, a cloud-based platform can be accessed by the vehicle using available wireless network access options provided by the OBU 30 (e.g., multiple wireless interfaces 26) and appropriate routing protocols. The cloud-based platform can provide dynamic, real-time vehicle diagnostics from data provided by selected machinery and equipment of the vehicle. Thus, a vehicle with an onboard unit can provide data to the cloud for remote management of vehicle behavior anomalies and correlate anomalies between multiple vehicles with defined similarities (e.g., model, type, components, etc.). Additionally, the cloud-based platform can provide remote diagnostics of machinery and equipment to aid in determining the actual cause of specific faults. Finally, the cloud-based embodiments disclosed herein provide online monitoring and learning of the behavior of vehicle components based on interaction, combining learned behaviors from many vehicles to derive more complete behaviors via remote online services, updating the vehicle using current behavior specifications, and monitoring behavior for error detection and analysis.

[0034] Note that in this specification, references to various features (e.g., elements, structures, modules, components, steps, operations, characteristics, etc.) included in “one embodiment,” “example embodiment,” “embodiment,” “another embodiment,” “some embodiments,” “various embodiments,” “other embodiments,” “alternative embodiments,” and “alternative embodiments” may include any such feature in one or more embodiments included in this disclosure, but they do not necessarily have to be combined in the same embodiment.

[0035] Furthermore, those skilled in the art should understand that the terms “optimize,” “optimization,” “optimum,” and related terms refer to improvements in the speed and / or efficiency of a particular result, and are not intended to indicate that the process used to achieve a particular result has been or can achieve a “optimal” or completely fast / completely efficient state.

[0036] Turn Figure 1 In detail, end user 2 may be associated with a human agent (e.g., driver or passenger) of vehicle 4. End user 2 may initiate communications in communication system 10 via some of the networks in network 40, and such communications may be initiated by any suitable device, including in-vehicle mobile device 18a or 18b, display 28, and navigation system 17 that may be integrated with OBU 30 and / or infotainment system. In one embodiment, an additional display may be provided for one or more passengers in vehicle 4. Mobile devices such as in-vehicle mobile device 18ab include mobile phones, smartphones, e-book readers, tablets, iPads, personal digital assistants (PDAs), laptops or e-notebooks, portable navigation systems, multimedia gadgets (e.g., cameras, video and / or audio players, etc.), gaming systems, other handheld electronic devices, and any other devices, components, elements, or objects capable of initiating voice, audio, video, media, or data exchange within communication system 10. As used herein, data refers to any type of numerical, audio, video, or script data, or any type of source or object code, or any other suitable information in any appropriate format that can be transmitted from one point to another in an electronic device and / or network.

[0037] The onboard mobile device 18 ab and the external mobile device of the transport vehicle 4 can communicate with the OBU 30 of the communication system 10 via any wireless or suitable wired communication link, and can be configured as a Personal Area Network (PAN) or Wireless Personal Area Network (WPAN) or any other suitable networking architecture or system that facilitates communication in a networked environment. Wired and wireless communication links can include any electronic link, such as wireless technologies (e.g., Bluetooth, ZigBee, IEEE 802.11x, WiFi Direct, 60 GHz, Ultra Wideband (UWB), etc.), USB cables, HDMI cables, etc. The connection between the mobile device and the OBU 30 can be configured based on specific needs and logistics. In one example, when, for example, the external mobile device is a diagnostic tool used by a mechanic to repair the transport vehicle 4, the external mobile device can be connected to the OBU 30 via a USB cable or a wireless network.

[0038] Network 40 represents an external network, which can be a series of points or nodes in an interconnected communication path for receiving, sending, and / or forwarding information packets propagated through communication system 10. Network 40, for example, provides [something] in any [system / system]. Figure 1 The communication interface between the components of the cloud 41 and remote nodes and other electronic devices, as well as other transportation vehicles 59, is provided. Network 40 can be any local area network (LAN), wireless local area network (WLAN), wide area network (WAN), wireless wide area network (WWAN), metropolitan area network (MAN), wireless metropolitan area network (WMAN), wireless single-hop or multi-hop vehicle-to-vehicle network, vehicle-to-vehicle-to-infrastructure network, virtual private network (VPN), intranet, extranet, or any other suitable architecture or system facilitating communication within the network environment. Network 40 can include any suitable communication link to the OBU 30, such as wireless technologies (e.g., IEEE 802.11x, 802.16, WiFi, WiMAX, Near Field Communication (NFC), DSRC, etc.), satellite, cellular technologies (e.g., 3G, 4G, LTE, GSM / WCDMA / HSPA, CDMA1x / EVDO, etc.), or any combination thereof. Network 40 may also include configurations that enable the transmission of Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol / IP (UDP / IP), or any other suitable protocol, as appropriate and based on specific needs.

[0039] Embodiments of the OBU 30 may include one or more different interfaces represented by network interface 26 to facilitate communication via various networks described herein, including both internal and external networks. Such network interface 26 may include multiple wireless interfaces (e.g., WiFi, WiMAX, 3G, 4G, white space, 802.11x, satellite, Bluetooth, LTE, GSM / WCDMA / HSPA, CDMA1x / EVDO, DSRC, GPS, etc.). Other interfaces represented by network interface 26 may include physical ports (e.g., Ethernet, USB, HDMI, etc.), interfaces for wired and wireless internal subsystems, etc. Similarly, each node and user equipment (e.g., mobile device) of the communication system 10 may also include suitable interfaces for receiving, transmitting, and / or otherwise conveying data or information in the network environment.

[0040] In addition to multiple radio interfaces (e.g., network interface 26), the OBU 30 includes radio interface selection algorithms and appropriate routing protocols to enhance radio connectivity options from the vehicle 4 to external networks (e.g., directly to roadside infrastructure equipment, via single or multi-hop connections through other vehicles or nodes). Furthermore, this configuration enables a large number of connections between the OBU 30 and external networks. Therefore, the OBU 30 is configured to provide consistent and reliable external network access from the vehicle 4 via mobile network infrastructure (e.g., 3G, 4G, LTE, etc.) and / or via other wireless technology infrastructure (e.g., WiFi, WiMAX, other radio protocols, etc.).

[0041] Regarding the physical implementation of the OBU 30 and its associated components, any suitable arrangement can be applied based on specific needs and requirements, including the design of the specific vehicle in which the OBU 30 is implemented. In example embodiments, various other components of the OBU 30 can be installed in different physical areas of the vehicle, or can be installed as a single unit, with the display 28 positioned to allow driver access. Additional displays can be provided in suitable locations for passenger access from specific passenger seats. In one embodiment, multimedia, networking, and communication components can be located at a distance from the vehicle's engine (e.g., in or near the rear or trunk area if the engine is in the front area of ​​the vehicle).

[0042] The communication system 10 can be configured to facilitate communication with machine equipment (e.g., sensors, instruments, electronic control units (ECUs), embedded devices, actuators, displays, etc.). The OBU 30 can be implemented to provide one or more suitable communication interfaces (e.g., network interface 26) to a conventional bus subsystem in the vehicle, such as Controller Area Network (CAN), Low Speed ​​Network (LIN), FlexRay communication protocol network, Media-Oriented System Transport (MOST), etc.

[0043] Typically, numerous ECUs with different embedded software can exist in a single vehicle and can communicate via one or more internal network subsystems 20. Such subsystems 20 typically include conventional bus subsystems such as Controller Area Network (CAN), LIN, FlexRay, and MOST. For example, the vehicle control unit 16 ab can include any embedded system or ECU that controls one or more electrical subsystems in the vehicle 4. Sensors 14 ab can represent wheel and headlight sensors, respectively. Actuators 13 can represent vehicle setting devices, such as seat positioning devices for adjusting various seat positions (e.g., longitudinal position relative to the brake and accelerator pedals, recline position, lumbar support, etc.). Actuators 13 and other similar vehicle setting devices (e.g., temperature controllers, sunroof, door locks, power windows, etc.) can be configured to communicate via the LIN internal network subsystem. Sensors 14c represent a type of sensor or device that can be configured to communicate via the FlexRay communication protocol (e.g., radar collision sensor). The vehicle control unit 16c, representing one or more ECUs, can be suitably integrated to control the FlexRay network and sensors, as well as other associated components.

[0044] In other embodiments, subsystem 20 may have alternative configurations and may be suitably coupled to or integrated with OBU 30. For example, subsystem 20 may include a central hub that interconnects sensors and actuators and controls and manages communications to and from OBU 30. In yet another embodiment, subsystem 20 may be configured partially or fully using Ethernet networking technology, or other suitable technologies that implement Internet Protocol (IP) communication, User Datagram Protocol (UDP) communication, or other suitable communication protocols for relaying packets across networks. OBU 30 may be configured to provide one or more suitable communication interfaces (e.g., network interface 26) to accommodate possible implementations of subsystem 20, including interfaces for bus subsystems (e.g., CAN, LIN, FlexRay, MOST), IP networks, UDP networks, or any other suitable protocol or communication architecture provided to enable network communication with machinery in transport vehicle 4.

[0045] exist Figure 1In the specific example shown, vehicle 4 includes capabilities associated with navigation system 17 and vehicle diagnostics 19. Navigation system 17 may be provided in various embodiments, including, for example, a portable navigation system, or optionally a fixed navigation system, each of which may be configured for wireless or wired communication with OBU 30. In other embodiments, navigation system 17 may be integrated with OBU 30 and may display navigation information such as maps and points of interest to the user on display 28. Figure 1 Other more specific machinery and equipment not shown may include display panel instruments, climate control, interior lights, door locks, trunk opening / closing actuators, hood opening / closing actuators, seat heaters and / or coolers, sunroof opening / closing actuators, window heaters / defrosters / defoggers, infotainment systems (e.g., speakers, radios, DVDs, CDs, etc.), etc.

[0046] The behavior engine module 25 in the OBU 30 can be configured to identify anomalies in the transportation network environment, and specifically, to analyze transportation hardware behavior and detect unsafe behaviors. In one embodiment, the behavior engine module 25 is a hardware-based behavior analysis engine using content inspection and machine learning algorithms. The behavior analysis engine 25 can identify repetitions of certain attributes and generate behavior curves within a configurable time window. Abnormal trends in the behavior curves, where unwanted repetitive attributes appear, can be detected.

[0047] The behavior engine module 25 can receive datasets in real time from each of a plurality of machines associated with at least one vehicle in the consumer environment. The data can be any data output from the machines. In an example scenario, sensor 14a can send data indicating that braking has been applied to vehicle 4. This data can be a trend of the machine's response over time. For example, the data could indicate that actual braking of vehicle 4 occurs half a second after user 2 applies the brakes.

[0048] Data can be collected in real time. Real time can be defined as the earliest reasonable amount of time for data collection. For example, once braking is applied, sensor 14a can spend a short time recognizing that braking has been applied, converting the braking signal information into data, and then sending that data to the appropriate remote node of cloud 41. Therefore, even if data is not collected at the exact moment braking is applied, data is still collected in real time, including event recognition for the sensors and latency in data transmission.

[0049] Additionally, the consumer environment can be an example of environment 11. The consumer environment is the environment in which a consumer or user intends to use the vehicle 4. For example, the consumer environment for a conventional car could be roads and highways. Alternatively, the consumer environment for a tank could be rugged terrain or a battlefield. The consumer environment contrasts with the test environment, where conditions are controlled and the vehicle 4 is not used in a normal manner.

[0050] Furthermore, data can be collected from at least one piece of equipment in at least one means of transport. The OBU 30 of the means of transport 4 can collect data from the equipment of the means of transport 4 and / or from the equipment of other means of transport 59.

[0051] Additionally, the behavior engine module 25 can be configured to provide a reference dataset corresponding to one of the multiple machines. This reference dataset can be a trend of previous data received from that machine. For example, the reference dataset could be that braking occurs half a second after each application of brakes by user 2 in vehicle 4. Furthermore, the reference dataset can be a common trend based on previous datasets of machines in other vehicles. For example, data collected from other vehicles 59 could indicate that braking occurs half a second after each application of brakes in each other vehicle 59. Moreover, the reference dataset can be a common trend based on data from other machines similar to that machine from other vehicles. For example, data collected from similar vehicles among other vehicles 59 could indicate that braking occurs half a second after each application of brakes in each similar vehicle.

[0052] Additionally, the behavior engine module 25 can be configured to compare the dataset with the reference dataset. Data collected in real-time can be compared with the reference dataset in real-time or at a later point in time. The comparison can be performed by the behavior engine module 25 and / or by another processor in the network 40.

[0053] The behavior engine module 25 can also be configured to detect deviations within the dataset from the reference dataset. These deviations can be user-defined and / or set by the behavior engine module 25. In various illustrative embodiments, the deviation can be identified using an algorithm or analyzer program. For example, a deviation may occur when data from the machine indicates in real time that three seconds have elapsed between the user 2 applying the brakes and the actual braking operation. Conversely, if the reference dataset indicates a trend of only half a second elapsed between the applied brakes and the actual braking operation, a deviation may not be detected.

[0054] Additionally, the behavior engine module 25 can be configured to initiate an action in response to the detection of a deviation. The response can be an alarm and / or an action. For example, if a braking delay is detected, an alarm indicating a malfunction in the braking of the vehicle 4 can be sent to user 2. Besides alarms, the behavior engine module 25 can communicate with other systems in the vehicle 4 to compensate for the delayed braking.

[0055] By activating alarms and / or actions, the behavior engine module 25 can prevent catastrophic transportation incidents and potentially save lives. User 2 can react more quickly to dangers or problems with the transportation vehicle 4. Furthermore, the transportation vehicle 4 can take actions on behalf of User 2 and prevent accidents. By detecting changes in transportation control system information, and by detecting changes in surrounding events / objects based on visual / radar / LiDAR changes, and thus applying alarm systems, automatic feedback transportation control systems, and other driver assistance tools to the transportation vehicle, the behavior engine module 25 can prevent accidents.

[0056] Transportation manufacturers can receive data from different behavior engine modules across all their vehicles. For example, by aggregating and evaluating the data set, manufacturers can use it to identify recalls or to improve new models.

[0057] In addition to comparing machine data with a reference dataset, the behavior engine module 25 can also be configured to provide a policy with a set of rules. This policy could be, for example, a standard or preference indicated by a manufacturer or government entity. The set of rules could be specific elements applied to the machine. For example, in different illustrative embodiments, the safety policy could have the rule that the actual braking operation can occur no later than one second after the user 2 of the vehicle 4 applies the brakes.

[0058] Additionally, the behavior engine module 25 can be configured to compare data with a policy and detect violations of at least one rule in the rule set within the dataset. For example, in a braking scenario, a violation is detected if the policy indicates a delay of no more than one second and the data indicates a real-time detection of a two-second delay. In response to detecting a policy violation, the behavior engine module 25 can initiate actions such as warnings and / or remedial actions.

[0059] In addition to identifying deviations from trends and policy violations, the behavior engine module 25 can also adjust the reference dataset based on this dataset to form a new reference dataset when the detected deviations are within a certain range. For example, if data shows braking occurring three-quarters of a second after braking is applied, the reference dataset can be adjusted to include the three-quarters-second delay as part of a normal trend. This range can be set by the user, manufacturer, government policy, and / or algorithm. This range can be less than one second, half a second, or any other suitable range. By allowing the reference dataset to be adjusted, the behavior engine model 25 can learn as it collects more data and become more accurate in identifying problems.

[0060] The learning and monitoring module 31 of the OBU 30 can be configured to receive multiple data sets from multiple machine devices and use these datasets to identify the state of the machine devices. This dataset exists within multiple datasets, and the state is based on behavior associated with the machine devices. Multiple datasets can exist within these multiple datasets. These multiple datasets can be all data received from the machine devices. Each dataset can represent a different behavior from that machine device. For example, if sensor 14a is responsible for detecting braking, sensor 14a can have a dataset corresponding to braking being applied and a different dataset corresponding to braking not being applied. The learning and monitoring module 31 can receive each dataset and identify the state of each dataset; for example, the first dataset can be identified as a "brake applied" state, and the second dataset can be identified as a "brake not applied" state.

[0061] By identifying the different states of each machine, the learning and monitoring module 31 allows the traditional systems to communicate with each other. Once a state is identified, it can be sent to the network 40, subsequently used by other vehicles 59, and / or implemented in further coding of the system in the future. By utilizing this process across all vehicles, behavioral states can be quickly identified.

[0062] Figure 2 Block diagrams illustrating possible example details that can be associated with embodiments of an OBU are disclosed. In this illustrative embodiment, machine device 12 includes sensor 14. Sensor 14 can be used for vehicle control system information, changes in surrounding events / objects based on vision / radar / LiDAR, etc.

[0063] Sensor 14 may include data 42 and status 43. Data 42 may be data detected by sensor 14 in response to monitoring and transmitted to OBU 30. For example, the sensor may detect that the driver's eyes are closed. The sensor may then convert this information into data for transmission to behavior engine module 25 and / or learning and monitoring module 31 (which will be further described herein). Data 42 may represent all data sent from sensor 14. Within data 42 is status 43, which may be a behavioral state. The dataset within data 42 may indicate that a certain behavioral state is occurring. For example, the dataset within data 42 may indicate that there is an object in the road. This dataset can be identified and associated with a state within status 43. Although sensor 14 is primarily shown and described herein, it is apparent that other types of machine devices 12, such as ECUs or actuators, may also have associated data and status. Therefore, the activities described herein apply to data from any type of machine device 12 that provides suitable data for monitoring, identifying anomalous behavior, diagnosing and predicting faults, and / or learning behavioral states.

[0064] The behavior engine module 25 of the OBU 30 can be configured to analyze data 42 from machine equipment 12. In one embodiment, the behavior engine module 25 can use a time- and space-based trend analyzer 32a and a policy-based trend analyzer 32b to identify anomalies / deviations within machine equipment 12. Referring to analyzers 32a and 32b, "time" refers to date and may refer to time, while "space" refers to location.

[0065] The time- and space-series-based trend analyzer 32A identifies and monitors trends over time in machine equipment 12. When data indicates a deviation from past data received about that machine equipment or similar equipment, the time- and space-series-based trend analyzer 32A can identify anomalies within machine equipment 12. The policy-based trend analyzer 32b compares trends and data from machine equipment 12 with policies and a set of rules. Violations of those rules can be identified by the policy-based trend analyzer 32b.

[0066] The behavior engine module 25 can provide reference data 34 for both the time- and space-based trend analyzer 32a and the policy-based trend analyzer 32b. The time- and space-based analyzer 32a uses the reference data 34 to compare the data 42 with a relevant trend 35. The trend 35 can be a behavioral trend identified from a particular machine in the machine device 12. For example, the trend 35 could be the number of times the driver blinks or the average length of time the driver's eyes are closed.

[0067] The time- and space-series-based analyzer 32a also uses reference data 34 to compare data 42 with a common trend 36. The common trend 36 can be, for example, a common trend among similar machines or equipment, or a common trend among identical or similar machines or equipment in similar modes of transport.

[0068] The policy-based trend analyzer 3b can use reference data 34 to modify policies or notify interested and authorized entities (e.g., manufacturers, government entities, etc.) of ongoing policy violations. For example, the policy-based trend analyzer can identify the speeds of most drivers on certain roads. In response, speed limits can be changed or enforcement can use higher speeds on that road. The policy-based trend analyzer 32b can also use policy 37. Policy 37 can be a government entity policy, a manufacturer policy, or any other suitable type of policy based on specific needs and implementation methods. For example, policy 37 can be based on city regulations, such as speed limits and other laws, and / or it can be based on manufacturer safety specifications. Policy 37 includes multiple sets of rules represented by rule set 38. Rule set 38 can be specific elements applied to a particular machine or equipment. For example, a rule can provide the maximum reaction time for the steering wheel to produce actual tire movement.

[0069] Furthermore, the behavior engine can include new reference data 39. When the time- and space-series-based trend analyzer 32a detects anomalies and deviations from the trend 35, some of these anomalies may be normal reactions. When a reaction is normal and does not require action, the data corresponding to that reaction is included in the new reference data 39. To determine whether a deviation should trigger an action or be included in the new reference data 39, a range can be used. The range can be the distance between the data and the trend 35 in which the data is still considered normal. This range can be set by the user, manufacturer, or other authorized entity, or by a computer using an algorithm.

[0070] The behavior engine module 25 can communicate with the feedback and active control module 33. Once an anomaly or deviation from the strategy or trend analysis is identified, the feedback and active control module 33 can initiate an action. When an action is initiated, alarms can be sent to different entities and physical / mechanical actions can be taken. These physical / mechanical actions may include applying brakes to prevent accidents, shutting down the vehicle 4, or any other appropriate and authorized action.

[0071] OBU 30 can connect to network 40. Network 40 can be as follows: Figure 1This is an example of one implementation of network 40. Network 40 can connect to cloud 41 and other vehicles in fleet 51. While the system can connect to cloud 41, this is not mandatory. For example, V2V and V2X communication can be utilized. Cloud 41 can provide processing and storage for data received from machine equipment 12 or vehicles in fleet 51. Cloud 41 can represent one or more clouds, such as private, public, or government networks, including, for example, data center / private individual clouds, private clouds operated by regulatory agencies, federated clouds, distributed clouds, or any other suitable type of cloud, which can be accessed by vehicles 4 via network 40. In this way, data can be transmitted from other vehicles in fleet 51 and shared between vehicles in the fleet or other vehicles.

[0072] Figure 3 Block diagrams illustrating possible examples of details that can be associated with embodiments of the OBU are disclosed. The diagrams illustrate... Figure 3 —An example embodiment of a cloud-based platform for communication system 10, wherein OBU 30 is shown coupled to agent 90 and network 40. In one embodiment, agent 90 may include machine device 92 and mobile device 96. Furthermore, the agent may also include software agent 95 and authorized entity 98. Software agent 95 may include any application or executable file containing instructions that can be understood and processed on a computer and is provided in memory elements accessible to OBU 30 (e.g., memory element 24), and may be automatically activated in response to a specific set of criteria or conditions (e.g., whenever network connectivity is detected on OBU 30, whenever OBU 30 is powered on and a specific time interval has elapsed, in response to another software agent, etc.).

[0073] like Figure 3 As shown, the different architectural components of the cloud-based platform of communication system 10 may include wireless access, cloud computing, and data mining. Various wireless technologies represented by network 40 can be used in vehicles with an OBU (e.g., via network interface 26): 3G, 4G LTE, WiFi, WiMAX, DSRC, etc. Cloud computing can have multiple embodiments, including but not limited to various clouds 41, such as data center / private cloud 45, or any other type of cloud. Network 40 can facilitate communication between certain agents 90 of OBU 30 (e.g., machine equipment 92, software agent 95, mobile device 96) and authorized entities 98, other vehicles 59, and remote servers or entities.

[0074] To detect anomalies, this system can utilize the correlation between signals within the same vehicle and the correlation between signals between different vehicles in a platoon. Therefore, the system can analyze how vehicles communicate with each other to detect anomalies. The system can operate without any physiological signals (never collecting physiological signals from the driver). The system can disregard data from external sources such as vehicle equipment (mobile phones, laptops, various accessories, etc.). The system can analyze signals and determine if significant differences in signal values ​​indicate a truck malfunction in the platoon and can be used as an additional service call signal (e.g., in the case of worn spare parts), then historical values ​​of relevant parameters can serve as an additional source of information for road condition monitoring.

[0075] This system can utilize vehicle IDS (In-Vehicle Data Storage) to collect vehicle signal data and detect safety events, which are then sent to a cloud backend for further processing. Vehicle signal data can include all CAN traffic on the CAN network within a specific time period. For example, this signal data could be represented as a set of values ​​without a specific order. Here, v1 refers to the vehicle identified as v1. There can be multiple vehicles in a convoy. For vehicle 2, vehicle 3, etc., their signals will be represented by v2, v3, v...

[0076] It is understandable that the signals in a vehicle (e.g., v1, and the set referred to as S_v1) can be correlated because they describe some physical phenomenon, and therefore there can be easily computed linear or nonlinear relationships between some of these signals. The main observation is that, within a fleet of vehicles, the signals in all vehicles in the fleet are correlated across the vehicles, and this can be used to detect attacks targeting a subset of vehicles in the fleet.

[0077] Figure 4 The illustration shows an example of the correlation of signals between two completely different vehicles from two different manufacturers traveling along the same driving plan (an example of a driving plan would be all vehicles starting and waiting for 3 minutes, driving for 10 minutes, stopping for 3 minutes, driving for another 10 minutes, stopping, parking the vehicles, and turning off the engines). For example, signals could be observed such as the engine speed or driving speed of either the Toyota or Mercedes vehicle. Figure 4 In the scenario shown, the vehicle can begin as a parked car, turning off the radio and then the headlights. The system can detect that the car is moving, and the driver can open and close the driver's door three times. The system can then reopen the driver's door, move around the passenger doors, and open and close those doors three times.

[0078] Figure 5 This is a flowchart related to the monitoring of transport vehicle platoons according to one embodiment. The system can assume that most transport vehicles are not attacked, therefore, in a platoon with K transport vehicles, at least more than The individual vehicle is one that the system can reliably assume to be safe. Alternatively, it can be assumed that one of the vehicles in the platoon / fleet will not be harmed because it has been built with a highly secure architecture or ECU unit.

[0079] Therefore, in systems where majority voting determines whether a particular measurement or signal is correct (such as those requiring minimal...), In a system where multiple vehicles operate reliably, vehicles with additional safety hardware (e.g., a lead vehicle) can have a higher weight than any other "normal" vehicle. Under this assumption, in step 501, the vehicles (e.g., v1 to vk) can continuously send their signal sets S_v1 to S_vk to the backend server. In step 503, the system can enable one or more servers to continuously monitor all signal sets, so that monitoring can be performed continuously as signals arrive. Signals can be tagged relative to the vehicle. Therefore, vehicle name, model, manufacturer, and other information may be included.

[0080] Under normal circumstances (e.g., no data leakage), all signal sets should behave similarly. For example, if S1_v1, S1_v2, ..., S1_vk correspond to signals encoding the speed of vehicles and all vehicles are in platoon formation, then all speeds should be encoded at the same speed (with small tolerances or very small variations). For example, a tolerance or variation of + / -1 to 5 mph might be normal. While this might be true for one class of signals, it is also likely to be expected for most of the signals in the platoon. During this training or controlled measurement, the algorithm can compute a threshold that defines the maximum distance between any two identical signals from different vehicles observed during the training phase. This will be defined as the threshold T_Si for a single signal type Si_Vj for all vehicles vj in the set (for j=1 to k). This operation can be performed on all signals being monitored.

[0081] The threshold can be calculated using different types of distance metrics. For example, Euclidean distance, dynamic time warping (DTW) distance, correlation between two signals, L1 distance, machine learning algorithms that classify two signals as sufficiently close to each other (e.g., random forest, gradient boosting, linear regression, etc.), or trained deep learning algorithms (e.g., binary classification, which divides into two classes: below a certain threshold or above a certain threshold, corresponding to normal or abnormal / abnormal behavior, respectively) can be used to calculate the threshold for measurement bias.

[0082] Once the threshold T_Si is defined, the differences between the signals can be continuously monitored in the cloud backend at step 504 by comparing the signals from different vehicles with the threshold T_Si of all relevant signals. As further discussed, monitoring can be performed at the lead vehicle. In one illustrative embodiment, the lead vehicle may have higher security standards and may transmit logs, thresholds, and other information to a remote server. The system can collect data from all the different vehicles. Once collected, it can be analyzed later on vehicles within the fleet or even on vehicles located far from the fleet.

[0083] At decision 505, the system can determine whether the difference from the comparison exceeds a threshold. If the difference between signal Si_vr and any other signal Si from different vehicles is greater than the threshold T_Si, the backend checks whether this is true for a majority of vehicles in the convoy. If yes, an output or alarm or notification can be issued at step 507. If not, the event is logged at step 506 without issuing an alarm; in one embodiment, this log can later be used to verify whether an actual attack occurred without being detected. The backend server can use software or manual analysis to observe the deviation. In another embodiment, the log can be used to understand the lateral movement of the attack, for forensic analysis, etc. Determining whether signals are close to each other may not be based on the detection of a first event and subsequent comparison, but rather by continuously comparing signals at the backend and implementing or executing an algorithm that allows for majority voting. In one embodiment, the system may not use any input from the driver or the surrounding environment of the vehicles, except for measurements of signals from within the vehicles.

[0084] In another embodiment, a possible variation includes an alternative implementation where the system is fully autonomous and all comparisons with a given threshold occur within the fleet. This can be implemented as follows: During the setup phase, the fleet (possibly in a secure location) selects one (or several) transport vehicles that will collect data from all other transport vehicles in the queue. For example, in a fleet of three transport vehicles, one can be selected as the "leader" of that fleet. This transport vehicle will act as the backend in the primary embodiment. Therefore, all other transport vehicles will send data to the leader transport vehicle. Except for the leader performing the operations initially performed by the cloud, the remainder of this implementation will operate in the same manner as in embodiment 3.1. Note that the number of messages and bandwidth consumed in this implementation are slightly less than in a cloud deployment (because one less transport vehicle, such as the leader, is involved in sending data).

[0085] In embodiments where a large fleet is to be deployed, having multiple lead vehicles can be advantageous. In one embodiment, a fleet may include two or more vehicles. In another embodiment, a large fleet may include more than three vehicles. Thus, the vehicles can be organized in a hierarchical manner, where the fleet is organized into multiple subsets that send messages to their corresponding lead vehicles, which in turn send data to a master lead vehicle. The grouping of the fleet can be selected by vehicle type (e.g., the same manufacturer or model) or other similar structure. Optionally, all lead vehicles can send messages to each other. A different approach may include having all non-lead vehicles send messages to all lead vehicles. This would require more bandwidth but could potentially provide another layer of checks and therefore higher guarantees.

[0086] In deployment, it can be assumed that the lead vehicle is a more secure vehicle because it is compared against specific thresholds to determine whether an attack has occurred. For example, the lead vehicle may have enhanced security measures or monitoring. The lead vehicle may include different security hardware than the other vehicles in the convoy.

[0087] For example, higher-level hardware security modules or additional hardware security can be deployed in the lead vehicle's internal network. In another embodiment, the lead vehicle can include more IDS nodes (e.g., typically the vehicle will have a central deployment with IDS in the gateway), deployed in more ECUs, or the vehicle's network design can have more gateways, each with an IDS. In another embodiment, the lead vehicle can be remotely monitored or verified by hardware, a remote server, or other security services. In yet another embodiment, the lead vehicle's system can include more bandwidth to send more granular data back to the cloud or perform checks more frequently. The lead vehicle can also include fewer network interfaces to focus on improving security. For example, the lead vehicle can be designed without physical access to the CAN bus from the OBD port (e.g., no OBD port), or without physical access from certain nodes that typically have access (e.g., headlights). Therefore, even with the same vehicle model or manufacturer, the lead vehicle can have a completely different network design. Additionally, the traffic signals in the lead vehicle can differ, as CAN traffic is typically not encrypted, but in the case of a lead vehicle, CAN data can be encrypted. This embodiment of a transport vehicle convoy may require special configuration during manufacturing or convoy trip setup or planning. In one embodiment, data and signals from other vehicles in the convoy can be sent to the convoy leader's device. These signals can then be compared with behavior recorded in the convoy leader's device. This can be the opposite of a scenario where a check is first performed locally and then sent for further analysis based on that check. Cloud components are not envisioned in this embodiment, but they can be added as an additional layer of security. In the disclosed embodiments of this example, driver behavior or environmental conditions are not necessarily utilized.

[0088] In an alternative embodiment, the system can determine where the difference between the signal Si_vr in a particular vehicle VR and the signals Si_vl from different vehicles is greater than the threshold T_si of most vehicles in the convoy. This can indicate a defect / failure in one of the systems of the vehicle VR and can send a notification to the service center detailing that certain systems or vehicles should be inspected or replaced. Furthermore, if such a signal difference is detected in a large subset of vehicles, a notification can also be sent to the OEM, as there may be manufacturing problems in some subsystems within a batch of vehicles.

[0089] In yet another embodiment, historical data on signal relationships from one embodiment (which may be stored in the cloud) can then be used for road condition monitoring. For example, when a convoy travels along the same route from point A to point B and after a period of time, the system can determine or assess a significant signal variation in most vehicles on a certain segment of the trajectory, which can be signaled or indicated as deteriorating road conditions. Therefore, the system can determine that issues with the road surface, road signs, traffic lights, or any other problems should be investigated for a portion of the road or trajectory segment. Thus, a dataset from the convoy over a given time period can be compared to another dataset to see if there are discrepancies in another environmental aspect. Therefore, navigation data and GPS information can be used to evaluate a particular segment.

[0090] While exemplary embodiments have been described above, they are not intended to describe all possible forms included in the claims. The language used in this specification is descriptive rather than limiting, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. As previously stated, features of various embodiments may be combined to form other embodiments of the invention that may not be explicitly described or illustrated. While various embodiments may have been described as providing advantages over or preferred over other embodiments or prior art implementations in one or more desired characteristics, those skilled in the art will recognize that one or more features or characteristics may be compromised to achieve desired overall system properties depending on the specific application and implementation. These properties may include, but are not limited to, cost, strength, durability, lifecycle cost, merchantability, appearance, packaging, size, suitability, weight, manufacturability, ease of assembly, etc. Accordingly, any embodiment described as less desirable than other embodiments or prior art implementations in one or more characteristics is not outside the scope of this disclosure and may be desirable for a particular application.

Claims

1. A method performed by an onboard unit of a transport vehicle, comprising: Data sets are received in real time from multiple vehicles in the convoy, wherein the first dataset includes indicators of the types of vehicles in the convoy; Provide strategies with rule sets; Compare the dataset with the strategy; A reference dataset corresponding to multiple vehicles in the fleet is provided, wherein the reference dataset includes previous data trends indicating the normal operation of the vehicles in the fleet; The dataset is compared with the reference dataset, wherein the determination of whether the dataset deviates from the previous data trend is based on the operation of one of the multiple vehicles in the fleet; and An operation is initiated when both a violation of the policy and a deviation between the dataset and the reference dataset are detected.

2. The method of claim 1, wherein the comparison of the dataset with the strategy is performed at the convoy leader's vehicle.

3. The method of claim 2, wherein all vehicles in the convoy except the lead vehicle transmit data to the lead vehicle.

4. The method of claim 1, wherein the dataset does not include physiological signals.

5. The method of claim 1, wherein the dataset does not include any data outside of a mobile phone, laptop computer or other remote device.

6. The method of claim 1, wherein Euclidean distance, dynamic time warping distance, L1 distance, random forest, gradient boosting, correlation, or linear regression is used to determine whether the dataset is biased.

7. The method of claim 1, wherein one or more processors are programmed to determine, for most vehicles in the fleet, whether the dataset deviates from the previous data trend.

8. A method performed by an onboard unit of a transport vehicle, comprising: Data sets are received in real time from multiple vehicles in the convoy, wherein the first dataset includes indicators of the types of vehicles in the convoy; A reference dataset corresponding to multiple vehicles in the fleet is provided, wherein the reference dataset includes previous data trends indicating the normal operation of the vehicles in the fleet; The dataset is compared with the reference dataset, wherein the determination of whether the dataset deviates from the previous data trend is based on the operation of one of the multiple vehicles in the fleet; and An operation is initiated when a deviation between the dataset and the reference dataset is detected.

9. The method of claim 8, wherein the method further comprises providing a strategy having a set of rules and comparing the dataset with the strategy.

10. The method of claim 8, wherein Euclidean distance, dynamic time warping distance, L1 distance, random forest, gradient boosting, correlation, or linear regression is used to determine whether the dataset is biased.

11. The method of claim 8, wherein the method includes a setup phase in which data from all other vehicles in the convoy is collected from a lead vehicle selected by the convoy, wherein the lead vehicle receives the dataset from multiple vehicles in the convoy and performs a comparison of the dataset with a reference dataset and initiates the operation.

12. The method of claim 8, wherein the operation includes a countermeasure to the action that caused the deviation, wherein the action includes maneuvering to bring the vehicle that deviated from the convoy to a safe state, wherein the maneuvering includes stopping, changing speed, or adjusting steering.

13. A system for monitoring multiple vehicles in a convoy, comprising: A wireless transceiver, wherein the wireless transceiver is in one or more of the plurality of vehicles and is configured to transmit data from the plurality of vehicles; One or more processors, wherein the one or more processors communicate with the wireless transceiver, wherein the one or more processors are collectively programmed to: Data sets are received in real time from multiple vehicles in the convoy, wherein the first dataset includes indicators of the types of vehicles in the convoy; A reference dataset corresponding to multiple vehicles in the fleet is provided, wherein the reference dataset includes previous data trends indicating the normal operation of the vehicles in the fleet; The dataset is compared with the reference dataset, wherein the determination of whether the dataset deviates from the previous data trend is based on the operation of one of the multiple vehicles in the fleet; and When a deviation is detected between the dataset and the reference dataset, an operation is initiated to output a notification.

14. The system of claim 13, wherein a plurality of processors in the one or more processors are collectively configured to be programmed.

15. The system of claim 13, wherein a single processor of the one or more processors is configured to be programmed.

16. The system of claim 13, wherein the one or more processors are programmed to determine whether the dataset deviates from the previous data trend for the majority of vehicles in the fleet, and if the dataset deviates for the majority of vehicles, to initiate the operation to output the notification.

17. The system of claim 13, wherein the one or more processors are programmed to determine whether the dataset deviates from the previous data trend for the majority of vehicles in the fleet, and if the dataset does not deviate for the majority of vehicles, then the operation to output the notification is not initiated.

18. The system of claim 13, wherein the dataset does not include driver behavior data or environmental condition data.

19. The system of claim 13, wherein the one or more processors are programmed to perform a setup phase that collects data from multiple vehicles in the fleet at a secure location of the system.

20. The system of claim 13, wherein the one or more processors are programmed to continuously program the dataset.

Images