GATEWAY

FIELD

[0001] The disclosed embodiments relate generally to motor vehicle systems and in particular, but not exclusively, to enforcing security within a communications network of a motor vehicle.

BACKGROUND

[0002] Motor vehicles, such as cars, trucks, trains, etc., are becoming more connected.

That is, a motor vehicle may include network communication capabilities enabling the motor vehicle to communicate via a network, such as a cellular communications network, with one or more remote systems, and also to receive communications from such systems. Furthermore, the systems of the motor vehicle, such as motor vehicle computer systems, components, user interfaces, etc., may also exchange communications via an internal communications network, such as controller area network (CAN) bus, Ethernet network, wireless network, etc.

[0003] The data received, sent, and exchanged between the various systems of the motor vehicle, however, may not be benign. That is, for example, malicious traffic may be

purposefully introduced into the motor vehicle via one or more of the communication networks in an attempt to harm one or more systems of the motor vehicle or the passengers. As another example, network traffic that is not necessarily intentionally malicious, such as network communications that inadvertently attempt to cause a non-allowed action (e.g., access encrypted data), misconfigure a motor vehicle system (e.g., set a component operating parameter outside of an acceptable range), or take any other action that could inadvertently damage or impact the safety, operational integrity or efficiency of the vehicles operations. Therefore, there is a need for security within a communications network of a motor vehicle to safeguard the systems of the motor vehicle.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure l is a block diagram of an exemplary system architecture for enforcing network security in a motor vehicle;

[0005] Figure 2 is block diagram of one embodiment of a system including a motor vehicle and a security server;

[0006] Figure 3 is a flow diagram of one embodiment of a method for enforcing network security in a motor vehicle; [0007] Figure 4 is a flow diagram of one embodiment of a method for a security server generating a machine learning model for motor vehicle network security including simulation of vehicle network traffic.

D TATT/FD DESCRIPTION

[0008] The word“exemplary” or“example” is used herein to mean“serving as an example, instance, or illustration.” Any aspect or embodiment described herein as“exemplary” or as an“example” in not necessarily to be construed as preferred or advantageous over other aspects or embodiments.

[0009] Figure 1 is a block diagram of an exemplary system architecture 100 for enforcing network security in a motor vehicle. System 100 implements a method for securely scaling enforcement of network security to communications that occur within a communications network of motor vehicle 102. In embodiments, motor vehicle 102 may a fully electric vehicle, partially electric (i.e., hybrid) vehicle, or non-electric vehicle (i.e., vehicle with a traditional internal combustion engine). Furthermore, although described mostly in the context of automobiles, the illustrated systems and methods can also be used in other wheeled vehicles such as trucks, motorcycles, buses, trains, etc. It can also be used in non-wheeled vehicles such as ships, airplanes (powered or gliders), and rockets. In fact, the illustrated embodiments can be used in any situation in which it is useful to monitor, detect, and remedy security threats that originate from the exchange of communications on a vehicles communications network.

Furthermore, as discussed herein, threats may be considered any communication that impacts the operations, safety, data security, integrity, etc. of one or more systems of a motor vehicle.

[0010] System 100 includes motor vehicle 102 communicatively coupled to vehicle security server 150. In the context of this application,“communicatively coupled” means coupled in such a way that data can be exchanged, in one or both directions, between two entities or components (e.g., between the motor vehicle 102 and the vehicle security server 150).

Although only one motor vehicle 102 is shown, in other embodiments there need not be a one-to- one correspondence between motor vehicles and the vehicle security server. Furthermore, vehicle security server 150 may be comprised of two or more server computer systems distributed over network 130.

[0011] In one embodiment, motor vehicle 102 includes one or more systems, such as components 101, each having an electronic control unit (ECU) 105, and each ECU 105 is communicatively coupled via a communications network 107 to a vehicle control unit (VCU) 106. The communications network 107 may be a controller area network (CAN), an Ethernet network, a wireless communications network, another type of communications network, or a combination of different communication networks. VCU 106 is also a system of the motor vehicle 102 and is communicatively coupled to other motor vehicle systems, such as a GPS unit 110, a user interface 112, and a transceiver 114. Transceiver 114 is communicatively coupled to an antenna 116, through which motor vehicle 102 can wirelessly transmit data to, and receive data from, vehicle security server 150. In the illustrated embodiment, motor vehicle 102 communicates wirelessly via antenna 116 with a tower 132, which can then communicate via network 124 (e.g., a cellular communication network, a local area network, a wide area network, etc.) with vehicle security server 150. The motor vehicle may include other systems, with although are not illustrated, would be included in a motor vehicle and exchange communications via network 107.

[0012] Components 101 are generally components of the systems of the motor vehicle

102. For example, components 101 can include adjustable seat actuators, power inverters, window controls, electronic braking systems, etc. Vehicle control unit (VCU) 106 is a controller including a microprocessor, memory, storage, and a communication interface with which it can communicate with components 101, global positioning system (GPS) 110, user interface 112, and transceiver 114 via network 107. In one embodiment VCU 106 is the vehicle’s main computer, but in other embodiments it can be a component separate from the vehicle’s main or primary computer.

[0013] Vehicle security server 150 is communicatively coupled to network 130, so that vehicle security server 1150 can exchange data with motor vehicle 102, as well as to exchange information with other systems. For example, vehicle security server 150 may schedule, notify, or consult with other systems, such as a repair facility and/or factory (not shown) via network 130. Although illustrated as a single server, in other embodiment’s server 120 can include multiple servers, each of which includes one or more microprocessors, memory, and storage.

[0014] In one embodiment, motor vehicle 107 includes vehicle gateway 120. Vehicle gateway 120 is a networking appliance that resides on motor vehicles communications network 107. Vehicle gateway 107 may include a network interface, processor, memory, and one or more processing modules as discussed herein. In one embodiment, vehicle gateway 120 may reside in VCU 106, as well as other components with sufficient access to network 107, processing power, and memory resources to perform the operations described in greater detail herein.

[0015] In embodiments, vehicle gateway 120 may be a hardened network appliance that routes communications to/from vehicle systems within network 107, monitors traffic

communicated over network 107, blocks traffic, performs firewall functions, etc., as discussed in greater detail herein. In embodiments, the vehicle gateway 120 is considered to be a hardened network appliance because it implements one or more physical and logical barriers for preventing access to the vehicle gateway 120. Vehicle gateway 120 may include pressure switches, electrical connectors, etc. that detects physical access to the internal components of the vehicle gateway 120, such as attempts to open a container housing the vehicle gateway 120. Vehicle gateway 120 may also include one or more software components that detect disallowed logical accesses to the internal components of the vehicle gateway 120, such as attempts to access secure storage, reprogram the vehicle gateway, or otherwise tamper with the operation of vehicle gateway 120. As a hardened appliance, in response to detecting a non-allowed physical or logical access, vehicle gateway 120 responds by taking one or more actions (e.g., shutting down, entering a safe mode, wiping storage and loading a clean configuration, etc.).

[0016] Vehicle gateway 120 performs one or more security functions for

communications sent/received from motor vehicle 102 (e.g., with external systems via transceiver 114), as well as one or more security functions for communications exchanged between systems (e.g., components 101, VCU 106, GPS 110, user interface 112, etc.) via network 107 of motor vehicle 102. In order to perform the security functions, vehicle gateway 120 monitors the exchange of all communications, such as the communication of data packets transmitted between motor vehicle systems (e.g., source, destination, content, timing, etc.). The data is logged and stored by vehicle gateway 120, such as in a memory or traffic data store, and then analyzed to detect communications, series of communications, etc. that are that indicate a potential security threat within network 107. For example, data exchanged that may set an operating parameter of component 101B outside of an acceptable range, an attempted access to a user’s private data stored in vehicle gateway 120 via user interface 112, an attempted access of the memory of VCU 106 received from an external entity (e.g., via network 130), as well as other potentially non-allowed network based communications.

[0017] In embodiments, vehicle gateway 120 monitors all data communicated over network 107, whether internally exchanged between motor vehicle systems or to/from motor vehicle and network 130, to detect security threats to motor vehicle 102. A security threat is detected by vehicle gateway 120 based on one or more rules and/or based on analysis of one or more communications with a machine learning model (MLM). For example, vehicle gateway 120 may be configured to analyze communications to detect a condition, and trigger a threat warning, when the condition is detected. For example, if a vehicle operator’s password for accessing their private data is entered incorrectly three times, then take a security action (e.g., trigger a warning, lock vehicle systems, etc.). As another example, if a communication is sent from user interface 112 to a particular component 101B that user interface 112 typically does not communicate with, or set a value of component 101C outside of an accepted range, then take another security action (e.g., trigger a warning on the user interface, set value within acceptable range but log error, etc.). Any number of conditions may be monitored by vehicle gateway 120, and any action taken as a result of a condition being detected.

[0018] The detection of security threats, however, may include more than detecting a single communication associated with a security condition. For example, a series of

communications that simultaneously set certain allowable values of components 101A, 101B, and 101C may be indicative of a security threat, a vehicle security system communicating with several other systems that it does not normally communicate with, receiving a security login for a user and then detecting vehicle customization options outside of the user’s saved options, etc. may be indicative of a security threat

[0019] In one embodiment, vehicle gateway 120 logs data indicative of the

communications exchanged over network 107, and then uses one or more MLMs to analyze the logged data. The MLM based analysis enables vehicle gateway 120 to monitor subsets of communications, what system originated communications, what system received

communications, sequences of communications, timing of communications, etc. to detect potential security threats when communications occur outside of a typical pattern. In

embodiment, the MLMs are received by vehicle security server 150, which as discussed in greater detail below, is responsible for generating the MLMs. Furthermore, vehicle gateway 120 may further refine a received MLM based on the monitored communications within the motor vehicle. For example, one or more communications exchanged over network 107 may trigger a warning that indicating a potential security threat. In response to the warning, an operator of the motor vehicle, vehicle service technician, etc. may indicate that the communications are not a security threat. In embodiments, vehicle gateway 120 would accordingly further train one or more machine learning model based on this data.

[0020] In embodiments, once vehicle gateway 120 detects a potential threat, the threat may be scaled according to a predetermined potential severity of the threat. In embodiments, the scaling of threats enables minor threats (e.g., those not effecting critical systems or data security) to trigger certain corrective actions or warnings, while more serious threats (e.g., detecting a major system compromise or an ongoing malicious attack) can trigger different corrective actions, warnings, a vehicle shutdown (e.g., an advanced driver assistance system navigating a vehicle to the side of a road, and shutting the vehicle down), as well as other actions.

Furthermore, the scaling can include escalating/de-escalating corrective actions/wamings as threats continue to be detected and/or corrected, the character of the threat changes over time, or the severity to effected systems changes. [0021] Vehicle gateway 120 may therefore detect security threats to the motor vehicle by monitoring communications and communications patterns, whether the communications are internal or external in origin, and respond to perceived threats based on a potential severity of the threat. Furthermore, the use of multiple threat detection mechanisms by the security gateway 120, when deployed within the motor vehicle’s communication network 107, enables security gateway 120 to effectively detect threats having different levels of complexity, such as single communications, a series of communications, multiple simultaneous communications, etc. Thus, the threat detection and overall security of the motor vehicle 102, and the various systems contained therein, may be made more secure,

[0022] Figure 2 is block diagram of one embodiment of a system 200 including a motor vehicle 202 and a vehicle security server 250. Motor vehicle 202 and a vehicle security server 250 provide additional details for motor vehicle 102 and a vehicle security server 150 discussed above in Figure 1.

[0023] In one embodiment, motor vehicle 202 is a system, which may include one or more processor(s) 212, a memory 205, and a network interface 204. It should be appreciated that motor vehicle 202 may also include, although not illustrated, a user and/or hardware interface, motor vehicle controls, one or more power device(s) (e.g., vehicle battery, drive control system, one or more vehicle systemsl700 (e.g., VCUs, components, positioning systems, etc.) etc.), a propulsion system (e.g. an electric, gasoline, etc. powered motor), a steering system, a braking system, as well as other components typically associated with motor vehicles. Although only a single network interface 204 is illustrated, it is understood that network interface 204 may be capable of communicatively coupling motor vehicle 202 to any number of wireless subsystems (e.g., Bluetooth, WiFi, Cellular, or other networks), internal motor vehicle communication networks (e.g., a CAN bus, an Ethernet network, a wireless network, etc.) to transmit and receive data streams through one or more communication links.

[0024] In one embodiment, vehicle security server 250 is also a system, which may include one or more processor(s) 252, memory 260, and communications subsystem 254. It should be appreciated that vehicle security server 250 may also include, although not illustrated, a user interface (e.g., keyboard, touch-screen, or similar devices), a power device (e.g., a battery), a display screen (e.g., an LCD display), as well as other components typically associated with computer processing systems.

[0025] In embodiments, the memories (e.g., memory 205 and memory 260) of motor vehicle 202 and vehicle security server 250 may be coupled to processor(s) to store instructions for execution by the processors, such as processor (s) 212 and processors 252. In some embodiments, the memory is non-transitory, and may store one or more processing modules. In one embodiment, memory 205 of motor vehicle 202 may store one or more processing modules of vehicle gateway 220, such as an encryption engine 234, logger 224, network traffic monitor 222, machine learning engine 228, security analysis engine 226, and one or more machine learning models (MLMs), to implement embodiments described herein. Furthermore, memory 260 of vehicle security server 250 may also include a security manager 270, including a vehicle manager 272, vehicle configuration data store 274, machine learning (ML) model analysis engine 276, and a vehicle simulator 278.

[0026] It should be appreciated that the embodiments as will be hereinafter described may be implemented through the execution of instructions, for example as stored in memory or other element, by processor(s) and/or other circuity of motor vehicle 202 and vehicle security server 250. Particularly, circuitry of motor vehicle 202 and vehicle security server 250, including but not limited to processor(s) 212 and processor(s) 252 may operate under the control of a program, routine, or the execution of instructions to execute methods or processes in accordance with the aspects and features described herein. For example, such a program may be implemented in firmware or software (e.g. stored in memory 205 and/or memory 260) and may be implemented by processors, such as processor(s) 212 and processor(s) 252, and/or other circuitry. Further, it should be appreciated that the terms processor, microprocessor, circuitry, controller, etc., may refer to any type of logic or circuitry capable of executing logic, commands, instructions, software, firmware, functionality and the like.

[0027] Further, it should be appreciated that some or all of the functions, engines, or modules described herein may be performed by motor vehicle 202 itself and/or some or all of the functions, engines or modules described herein may be performed by another system connected through network interface 204 to motor vehicle 202. Thus, some and/or all of the functions may be performed by another system, and the results or intermediate calculations may be transferred back to motor vehicle 202. In some embodiments, such other system may comprise a server, such as vehicle security server 250 and/or another server (not shown).

[0028] In one embodiment, motor vehicle 202 includes vehicle gateway 220 for enforcing network security in the motor vehicle 202. Network traffic monitor 222 is responsible for monitoring and gathering all communications exchanged over the motor vehicle’s communications network(s) (e.g., network 107). As discussed herein, the network

communications can include data messages exchanged between internal vehicle systems (e.g., motor vehicle components, a user interface, a positioning system, etc.), as well as data exchanged with external systems (e.g., vehicle security server 250, as well as other external systems). Logger 224 then logs the gathered network communications, and stores the network communications in memory 205. In embodiments, logger 224 may generate a network traffic data store. Furthermore, logger 224 may utilize encryption engine 224 to encrypt the network communications prior to storage in memory 205 so that any sensitive and/or proprietary information contained within the data is protected. In another embodiment, other than storing the communications, logger 224 and/or encryption engine 224 may store data indicative of the communications, such as source, destination, time, purpose, etc.

[0029] Security analysis engine 225 is configured to periodically access the logged network communications, using the encryption engine 234 as necessary to decrypt any encrypted information, for security analysis. In one embodiment, the period is selected to ensure that threats to critical motor vehicle systems are detected in a timely manner (e.g., analysis every minute, 1 second, 1/10 ^th of a second, etc.). As discussed herein, the security analysis includes detecting one or more preconfigured conditions within the network communications, so that if the condition is detected, then an associated action can be performed. Security analysis engine

225 further utilizes one or more MLM(s) 230 to analyze the logged network communications. The MLM(s), which may include one or more trained neural networks, support vector machines, deep learning models, other MLMs, or a combination of models, enable security analysis engine

226 to analyze multiple communications that may be occurring simultaneously, over a period of time, among different systems, etc. As will be discussed in greater detail below, vehicle security server 250 generates the one or more MLM(s) 230 by performing a simulation of vehicle communications and introducing various threats into the simulation, as well as based on crowdsourced reports from vehicles such as motor vehicle 202.

[0030] In one embodiment, security analysis engine 226 associates detected threats (e.g., those detected based on a detected condition associated with a communication, based on MLM analysis of multiple communications, or both) with various security levels based on the potential severity of the detected threat. For example, an initial security level associated with the lack of a detectable threat (e.g., a communication or group of communications are as expected and do not pose any harm to systems of motor vehicle 202); a first security level associated with a suspected attack or threat (e.g., a communication is not exchanged in an expected way, a vehicle system communicates with a component it does not usually communicate with, an incorrect password or security key has been received by a vehicle operator, etc.) that does not necessarily pose physical harm to the operator of the vehicle or vehicle systems; a second security level associated with a higher likelihood of suspected attach (e.g., continued communication between two systems that do not normally communicate with one another, more incorrect passwords entered, attempts to access a user’s secured and encrypted data (e.g., user profile data), etc.); a third security level associated with detection of an attack that is currently ongoing (e.g., determining that incoming communications from a network are malicious, detecting one system is attempting to harm another based on a series of communications, etc.); a forth security level associated with an ongoing attack that will impact a major vehicle system (e.g., a purposeful misconfiguration of a critical system, such as the vehicles steering, braking, access to secure storage, etc. that could affect the motor vehicle’s operator, passengers, or the motor vehicle itself); and a fifth security level associated with a detected system compromise (e.g., an attempt to physically or logically access the security gateway).

[0031] In embodiments, based on the threat level associated with a detected threat, security analysis engine 226 may adjust a security state of the car in order to take one or more corrective actions. For example, for minor threats or no threats, communications may simply be logged, potential threats logged for follow up, and the security state of the car is unchanged. However, for critical threats, such as those associated with the fourth and fifth level threats, the security state of the motor vehicle can be raised and more serious corrective actions, such as shutting down motor vehicle 202, restricting communications between components, wiping a motor vehicle’s operating system and installing a clean/safe system, scheduling maintenance, etc. may be triggered and carried out by security analysis engine 226.

[0032] Although several exemplary security levels are discussed above, any number of security levels could be implemented by security analysis engine 226 for associating different potential threats with different severity levels. This allows for more granular scaling of the potential threats that may be experienced by motor vehicle 202, and association of different corrective actions with the threat levels.

[0033] In one embodiment, security manager 270 of vehicle security server 250 is responsible for generating and providing the MLM(s) 230 to motor vehicle 202. One embodiment for generating such MLM(s) is to train the MLM(s) using vehicle simulator 278 and ML model analysis engine 276. In one embodiment, ML model analysis engine 276 access one or more configuration options for a motor vehicle in vehicle configurations data store 274. The configuration options include selection of various vehicle components, firmware versions, operating system versions, networks deployed, etc. ML model analysis engine 276 feeds a set of configuration options, for example associated with a specific motor vehicle (e.g., motor vehicle 202) or a class of motor vehicles (e.g. a model of a motor vehicle sold by a manufacturer with a set of options), into vehicle simulator 278. Vehicle simulator 278 is an execution environment capable of computationally simulating the operation of a motor vehicle’s communication between systems. Furthermore, vehicle simulator 278 may also introduce a plurality of threats into the simulation of the motor vehicle to detect how those threats will impact communication between the systems of the simulated motor vehicle. By doing this, one or more MLM(s) may be trained to recognize/detect normal system communications and patterns occurring on a motor vehicles communication network, as well as communications that are indicative of potential threats. Once trained, vehicle manager 272 provides an appropriate set of MLM(s) to motor vehicle 202 (e.g., for use by a security analysis engine 226, as discussed above).

[0034] In one embodiment, ML model analysis engine 276 further receives actual vehicle configurations, for example from vehicle 202 as well as other vehicles, for configuring/tailoring specific MLM(s) for specific configurations. That is, motor vehicle 202 may communication one or more actual configuration options of motor vehicle 202 (e.g., specific components, firmware versions, operating system versions, etc.), that ML model analysis engine 276 to generate specifically trained MLM(s). Furthermore, actual communications and/or detected threats encountered by motor vehicles may also be provided to vehicle security server 250.

These actual detected threats from a plurality of motor vehicles enables ML model analysis engine 276 to crowdsource and constantly refine existing MLM(s) based on actual

threats/attacks. Similarly, machine learning engine 228 of vehicle gateway 220 may similarly adjust, retrain, and/or refine its own MLM(s) 230 based on actual monitored and detected threats, using a machine learning analysis similar to that performed by vehicle security server 250.

[0035] Figure 3 is a flow diagram of one embodiment of a method 300 for enforcing network security in a motor vehicle. The method 300 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), firmware, or a combination. In one embodiment, the method 300 is performed by a security gateway of a motor vehicle (e.g., security gateway 120 or 220 of motor vehicle 102 or 202).

[0036] Referring to Figure 3, processing logic begins by monitoring data communicated over a communications network of a motor vehicle (processing block 302). In embodiments, the data may be network communications between systems of the motor vehicle (e.g., between vehicle components, a VCU, a positioning system, an user interface, etc.) or to/from a system of the motor vehicle and an external system (e.g., a remote server). Furthermore, the

communications network of the motor vehicle may include a combination of networks, such as a CAN bus, an Ethernet network, a wireless network, or any combination of networks.

[0037] Processing logic then analyzes the monitored data using one or more machine learning models trained to detect threats in data communicated over the communication network of the motor vehicle (processing block 304). As discussed herein, the trained machine learning models are generated by a vehicle security server, and communicated by the server to the motor vehicle. Processing logic may then utilize the trained MLMs when analyzing motor vehicle network communications. Furthermore, the MLMs may be trained for the specific vehicle (e.g., specific vehicle configuration options) in which processing logic is implemented, or a class of vehicles to which the current motor vehicle belongs. Based on the analysis, processing logic detects a threat in the monitored data and associates a security level with the threat (processing block 306). In embodiments, the detected threat may be based on a single communication where data within the communication satisfies a predefined condition indicative of a threat. In other embodiments, one or more communications may collectively be associated with a threat based on analysis performed by one or more machine learning models. In either embodiment, the threat level associated with the detected threat is based on the potential severity of the threat. For example, communications that are merely potentially part of a threat, but which do not impact any critical motor vehicle systems, may be associated with a low threat level. However, communications that directly impact safety of a an operator/passenger of a motor vehicle, the motor vehicle’s critical systems, data security of the motor vehicle, or a full system compromise, may be associated with a high threat level. One embodiment of a plurality of different threat levels is discussed in greater detail above.

[0038] Processing logic then adjusts a security state of the motor vehicle based on the security level associated with the detected threat (processing block 308), and performs at least one corrective action based on the security level associated with the detected threat (processing block 310). For example, processing logic may restrict one or more actions of an operator of a motor vehicle based on the adjusted security state. As another example, the motor vehicle may be placed into a safe state until a repair can be made to remedy a detected threat. As yet another example, a vehicle’s ADAS may safely remove a motor vehicle from a roadway, and shut down the vehicle. Any number of different security states and the corrective actions performed when entering those states may be performed consistent with the discussion herein.

[0039] Processing logic then optionally utilizes the detected threat and the monitored data to refine the one or more machine learning model(s) (processing block 312). In

embodiments, processing logic may perform a machine learning model analysis using the detected threat and the communications as training data to refine the machine learning model, in order to make the model more effective or more efficient in detecting similar threats in the particular motor vehicle.

[0040] Figure 4 is a flow diagram of one embodiment of a method 400 for security server generating a machine learning model for motor vehicle network security including simulation of vehicle network traffic. The method 400 is performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), firmware, or a combination. In one embodiment, the method 400 is performed by a vehicle security server (e.g., vehicle security server 150 or 250). [0041] Referring to Figure 4, accessing one or more configuration options for a motor vehicle (processing block 402). As discussed herein, the configuration options can include make and model of a motor vehicle, propulsion system, vehicle components, vehicle systems, communication networks, etc. Processing logic utilizes the configuration options to execute a simulation of the communications between systems of the motor vehicle (processing block 404), The simulation, for example, may be executed by a software simulation system that performs a coordinated simulation of all normal or expected communications that might occur between system of the motor vehicle before, during, and after operation of the motor vehicle.

Furthermore, the simulation system may also include external communication to/from the simulated motor vehicle with a other systems (e.g., a remote server, a mobile device, nearby motor vehicles, etc.).

[0042] Processing logic then introduces threats within one or more simulated

communications into the simulation (processing block 406). For example, the threats may be threats that are identifiable via single communications (e.g., within a single data packet exchanged over the motor vehicle’s communications network). As another example, the threats may include threats that develop over time via a plurality of communications exchanged between different motor vehicle systems. The normal communications and the threat communications are used by processing logic to train a threat detection machine learning model (processing block 408). The machine learning model may be trained iteratively by introducing any number of threats, variations on the same threat, benign communications, threats hidden within bending communications, etc. Furthermore, actual threats detected by motor vehicles (e.g., processing blocks 302-306 of Fig. 3) may be provided to processing logic of Fig. 4 and used as further training data.

[0043] Once the machine learning model has been trained, processing logic provides the trained machine learning model to a motor vehicle for detecting threats in data communicated over the communications network of the motor vehicle (processing block 410). In embodiments, processing logic may provide the trained MLMs to different motor vehicles on a period basis, on demand (e.g., upon request at vehicle startup), as well as at periodic intervals.

[0044] Those of skill would appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0045] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0046] The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[0047] In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium. Computer- readable media can include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such non-transitory computer-readable media can comprise RAM, ROM,

EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non-transitory computer-readable media.

[0048] The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the methods, systems, and apparatus of the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.