System and method for verifying the reliability of device operation data

Abstract

Systems, methods, and apparatus for verifying the reliability of local operational data of devices within a technological ecosystem, such as a V2X ecosystem. These systems, methods, and apparatus can perform operations including: acquiring local operational data of a device; acquiring messages from a plurality of external devices participating in the ecosystem, each of which includes external operational data from a sending external device; determining the reliability of the local operational data based on the local operational data and the external operational data from the messages; and taking corrective action if the reliability falls below a reliability threshold. The systems and apparatus may include a local data source for storing the local operational data and a communication interface.

Description

[Technical Field]

[0001] The present invention relates to a system, apparatus, and method for verifying the reliability of operational data received by and maintained within a device. More specifically, the present invention relates to a system, method, and technique for ensuring that time- and geolocation-related data used by various computer devices in an ecosystem has not been compromised, for example, by an external criminal. [Background technology]

[0002] As computers become increasingly smaller and commoditized, manufacturers are producing increasingly diverse devices that include one or more embedded computers or processors. The computer within a computer device can, among other things, control the device's operation, collect, store, and share data, communicate with other computers and other computer devices, and update its own software.

[0003] The Internet of Things (IoT) is a network or ecosystem of physical computer devices that have embedded processors, electronics, software, data, sensors, actuators, and / or network connectivity, enabling devices to connect and exchange data over digital networks, including the internet, cellular networks, and other wireless networks. Typically, each "thing" needs to be uniquely identifiable through its embedded computing system and be interoperable within existing internet infrastructure or by using other communication media.

[0004] In the context of IoT, "things" can refer to a wide variety of computer devices, particularly consumer electronics, business equipment used in business and corporate environments, manufacturing machinery, agricultural equipment, energy consumption devices in homes and buildings (such as switches, power outlets, electrical appliances, lighting systems, light bulbs, televisions, garage door openers, sprinkler systems, and security systems), medical and healthcare equipment, infrastructure management equipment, robots, drones, and transportation equipment and vehicles.

[0005] For example, most, though not all, modern vehicles and transport machines (e.g., cars, trucks, aircraft, trains, ships, motorcycles, scooters, etc.) incorporate several embedded processors or embedded computers within their subsystems and are computer-controlled in at least some aspects. Similarly, an increasing number of modern transport infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, roadside units, etc.) also incorporate at least one, and usually many, embedded processors or embedded computer systems and are computer-controlled in at least some aspects.

[0006] These computer control elements of a transportation network or transportation ecosystem typically communicate with each other and exchange various types of information. For example, a roadside unit (RSU) is a computer device located roadside that communicates with passing vehicles and other RSUs. An RSU may be fixed in one place (e.g., in a box incorporated beside a trunk road) or may be a mobile portable device carried and deployed as needed by road workers, emergency workers, etc. Various computer control elements of the transportation network can react, respond, change their own operations, or rely on the information received / sent from / to other vehicles via vehicle-to-vehicle (V2V, also known as car-to-car (C2C)) communication and / or from / to infrastructure elements (such as RSUs) via vehicle-to-infrastructure (V2I, also known as car-to-infrastructure (C2I)) communication for safe, accurate, efficient, and reliable operation. Generally, the transfer of information from a vehicle to anything that can affect the vehicle (e.g., other vehicles (V2V) and infrastructure elements (V2I)) and vice versa is called vehicle-to-everything (V2X) or car-to-everything (C2X). Some of the main goals of V2X are road safety, traffic efficiency, and energy conservation. Some of the messages exchanged in such an environment can be basic safety messages (BSMs), cooperative awareness messages (CAMs), and decentralized environmental notification messages (DENMs).

[0007] The computer within the computer device operates according to its software and / or firmware and data. To ensure safe and proper operation, the computer device needs to be appropriately initialized and updated (e.g., provisioned) and maintained with appropriate digital assets, such as software, firmware, executable instructions, digital certificates (e.g., public key certificates), cryptographic keys, time data, location data, etc. (hereinafter collectively referred to as "digital assets" or "software") as intended by the manufacturer or the V2X system operator. By doing so, the IoT consists only of devices that execute authorized software and data that have been confirmed to be in good condition.

[0008] The digital assets provided to the computer device are usually time-dependent, e.g., becoming available and expiring at a specific date and time. Further, the digital assets can be location-specific, e.g., based on regulations within a specific jurisdiction. Additionally, when time and location are extremely important (e.g., for autonomous vehicles, robot home patrols, etc.), it becomes crucial to obtain reliability for the time and geographical location used by the computer device.

Summary of the Invention

[0009] The inventor noticed that when a state-of-the-art system relies on the setting of operation data such as the internal time and / or location of a computer device, certain problems occur, and in some cases, it is impossible to prove and maintain the reliability of the time and location determined inside the device. For example, if an unauthorized and / or malicious person or organization (e.g., a hacker) spoofs the signals of the Global Navigation Satellite System (GNSS) and transmits the spoofed signals to the computer device together with incorrect operation information (e.g., especially incorrect time and / or location information), there is a possibility that an unauthorized person can "cheat" the computer device, and as a result, untrustworthy communications and / or actions are executed by the computer device.

[0010] As another example, computer devices designed to operate under geographical limitations, such as RSUs within a V2X infrastructure, may experience problems. These devices will not function properly if their geographic location and / or time and / or other operational data are incorrect. For instance, if the communicated geographic location differs from the RSU's actual geographical location, and / or if the date and time within the RSU are incorrect, certain digital assets provided to the RSU may become inappropriate and / or outdated.

[0011] Therefore, the inventors determined that it is desirable to provide improved systems, methods, and techniques for verifying the reliability of operating data of computer devices so that corrective measures can be taken as appropriate.

[0012] This specification describes systems, methods (e.g., computer implementations), computer-readable media, and apparatus for verifying the reliability of local operational data of devices within an ecosystem. In some embodiments, a system or apparatus may include a local data source configured to maintain the local operational data of a device, a communication interface, and a processor operably connected to the communication interface and the local data source. In various embodiments, a system, method, medium, and apparatus can perform processes, functions, and / or operations including: obtaining local operational data of a device (e.g., from a local data source); obtaining a plurality of messages from a plurality of external devices participating in the ecosystem (e.g., using a communication interface), each of which contains external operational data corresponding to the respective external device; determining the reliability of the local operational data (e.g., using a processor, based on the local operational data and the external operational data from the plurality of messages); and taking corrective action when the reliability falls below a reliability threshold, or if it does fall below a certain threshold.

[0013] In various embodiments, the operation may further include updating local operation data based on information received via a communication interface from a publicly available service. In some such embodiments, the updating may be performed at predetermined intervals. Also in some such embodiments, the information may be received from a publicly available service and may not be encrypted. Also in some such embodiments, the publicly available service may be a Global Navigation Satellite System (GNSS).

[0014] In various embodiments, each message in a group of messages may be digitally signed.

[0015] In various embodiments, local operation data may be local time data or may include local time data, and external operation data may include external time data, and the operation may further include generating updated local time by updating local time data to match time information received from a publicly available service, comparing external time data from each message of a plurality of messages with the updated local time data to determine the time deviation between the updated local time data and the external time data from each message, and incrementing a deviation counter based on the time deviation if it is determined that the time deviation of a message exceeds an acceptable value. In some such embodiments, the operation may further include tracking the deviation counter over a specified period of time to generate a tracking deviation, and using the tracking deviation in determining confidence.

[0016] In various embodiments, the multiple messages from multiple external devices may be, or include, basic safety messages (BSMs), cooperative recognition messages (CAMs), and / or decentralized environmental notification messages (DENMs), for example, used in a V2X ecosystem.

[0017] In various embodiments, the device may consist of an on-board unit (OBU), an electronic control unit (ECU), and a roadside unit (RSU).

[0018] In various embodiments, the device may be configured to be installed in ships, aircraft, spacecraft, medical devices, robots, drones, wireless communication modules, wired communication modules, electronic signs, digital billboards, and / or Internet of Things (IoT) devices.

[0019] In various embodiments, corrective actions may include, or may include, sending a warning message to a remote device, terminating communication from the device, executing a self-correction algorithm, and / or shutting down the device.

[0020] In various embodiments, local operation data may be local location data or may include local location data, external operation data may include external location data, and the operation may further include generating an updated local location by updating the local location data among the local operation data based on location information received from a publicly available service, comparing the external location data from each message of a plurality of messages with the updated local location data to determine the positional deviation between the updated local location data and the external location data from each message, and incrementing a deviation counter based on the positional deviation if it is determined that the positional deviation of a message exceeds an acceptable value. In some such embodiments, the operation may further include tracking the deviation counter over a specified period of time to generate a tracking deviation, and using the tracking deviation for determining confidence.

[0021] The combination of the above elements and the elements described herein (including multiple dependent combinations) is anticipated by the inventors and is intended to be possible unless it is shown to be inconsistent. [Brief explanation of the drawing]

[0022] The accompanying drawings incorporated herein and constituting part of this specification illustrate the implementation of the present invention and, together with the description, explain the principles of the present invention. The drawings are as follows:

[0023] [Figure 1] This figure shows an exemplary configuration of a stationary and mobile computer device.

[0024] [Figure 2] This is a schematic diagram illustrating an example of a system according to an embodiment of the present disclosure.

[0025] [Figure 3] This graph illustrates an example of how local operational data can deviate from actual information based on one or more erroneous messages received from an external device.

[0026] [Figure 4] This figure shows an exemplary road intersection where one or more computer devices may be present, consistent with the disclosed implementation.

[0027] [Figure 5] This flowchart shows an exemplary set of operations for monitoring local operating data of a computer device.

[0028] [Figure 6] This flowchart shows an exemplary set of actions to demonstrate the reliability of local time operation data based on external information.

[0029] [Figure 7] This figure shows an exemplary computer device in which the system and method of this disclosure may be implemented. [Modes for carrying out the invention]

[0030] Detailed explanation Herein, various implementations of the present invention are given in detail, with examples shown in the accompanying drawings. For convenience, the same reference numerals are used throughout the drawings to refer to the same or similar parts.

[0031] In various embodiments, a computer control unit may be configured to receive and / or maintain operational data from one or more sources and to use the operational data to perform various tasks related to the computer control unit. Operational data may, or may include, date information, time information, and location information (e.g., longitude and latitude), among other things, but is not limited to, time and / or location information. One or more sources of operational data may, or may include, among other things, the time source of each device, over-the-air (OTA) transmissions (e.g., Global Navigation Satellite Systems (GNSS), cellular networks, etc.), and wired connections (e.g., USB, Ethernet®, etc.). Importantly, the use of GNSS to describe geographic positioning and location is not intended to limit, and any system suitable for providing information related to global positioning (e.g., Global Positioning System (GPS)) is intended to fall within the scope of this disclosure.

[0032] To ensure safe and proper operation in the field, computer control devices (e.g., in the V2X ecosystem, electronic control units (ECUs) and on-board units (OBUs) used in vehicles, as well as roadside units (RSUs) related to various traffic facilities) must have accurate date / time data and / or location data (also known as position data). If this data is corrupted, for example, by a malicious external actor (e.g., a criminal) or hardware malfunction, the functionality of the computer control device may be affected to such an extent that it becomes unreliable and dangerous. Therefore, it is desirable to determine the reliability of the operational data to ensure its validity, and in some embodiments, to take corrective measures to prevent the spread of erroneous data if the reliability is too low.

[0033] For example, in a V2X ecosystem, the RSU broadcasts GNSS correction data to the vehicle so that the vehicle can correct the location data determined inside the vehicle, which may be inaccurate or incorrect due to various location determination difficulties associated with the vehicle (especially a moving vehicle), including challenging environmental conditions, insufficient battery power, and satellite signal reflection. It is important that the RSU broadcasts precise location / position data to other devices in the ecosystem, and the various embodiments described herein can detect when the RSU has inaccurate or incorrect location data and take corrective measures, such as preventing the RSU from broadcasting incorrect location data to the vehicle or other devices.

[0034] Messages from mobile devices (e.g., devices within a vehicle) typically include location data, such as the direction of travel and position of the mobile device, as well as time data reflecting the time the message was created. Messages from mobile devices are typically broadcast continuously while the mobile device is operating. Therefore, the time and location calculated internally by the mobile device are continuously supplied by these messages. According to the principles of the present invention, since each mobile device independently calculates its internal time and location, other mobile devices (e.g., OBUs) and stationary devices (e.g., RSUs) can use the received messages to determine the reliability of their own internally calculated local time and / or location, and act accordingly based on that reliability.

[0035] In this application, and in the examples of embodiments disclosed herein, we refer to operational data received and / or maintained by vehicle-to-vehicle and vehicle-to-infrastructure (V2X) devices that form part of a V2X ecosystem. V2X devices may include, for example, an on-board unit (OBU), an electronic control unit (ECU), and a roadside unit (RSU). Many, though not all, autonomous vehicles, as well as most modern human-controlled vehicles, include similarly functioning OBUs and / or devices and subsystems. However, although examples are described in the context of a V2X ecosystem for clarity and ease of explanation, the present invention is not limited to a V2X ecosystem, and the implementations described herein are not limited to V2X devices. The principles disclosed can be applied to other types of computer control devices. For example, additional or alternative implementations may use the reliability verification of operational data received and maintained by a device to ensure the proper functioning of other computer devices. In various embodiments, the OBU and ECU (or similar computer device) may be configured to be installed in vehicles including autonomous vehicles, ships (e.g., boats), aircraft (e.g., airplanes and drones), spacecraft, medical devices, robots, wireless or wired communication modules, and IoT devices. Similarly, the RSU or similar device can be installed in, among other things, traffic control devices (e.g., traffic signals), roadside content distribution systems, electronic toll collection systems, electronic signage devices, ground-based drone and aircraft control systems, and digital display devices (e.g., electronic billboards).

[0036] As described herein, systems and methods can be implemented to verify and validate the reliability of operational data of computer devices in order to address the technical problems described above. For example, embodiments of this disclosure can leverage information available from other ecosystem members to validate the reliability of local information stored in another ecosystem member. In other words, local information can be authenticated to a desired level of confidence by "crowdsourcing" from within the ecosystem, and corrective actions can be taken if the desired level of confidence is not validated.

[0037] Figure 1 is an exemplary diagram of a stationary computer device 120 and a mobile computer device 130 according to embodiments of the present disclosure. Each of the stationary computer device 120 and the mobile computer device 130 may, among other things, include a processor (not shown), memory 150, a time source 155, a communication interface 160, and a positioning unit 165. Various embodiments of the stationary and mobile computing devices 120, 130 are described herein, but the embodiments are not limited to those including purely stationary and / or purely mobile devices. For example, the mobile device described herein may remain stationary for a certain period of time, and / or the stationary device described herein may move for a certain period of time, and both may still perform the functions and operations described herein. In general, devices 120, 130 may communicate with other devices 120, 130 within communication range, as described herein.

[0038] Memory 150 may be any suitable computer-readable storage device that can be accessed by computer devices 120 and 130, in particular, for the purpose of storing and providing information within computer devices 120 and 130. For example, memory 150 may comprise volatile memory (e.g., RAM), non-volatile memory (e.g., magnetic memory, optical memory, electronic memory, etc.), and any combination thereof.

[0039] Memory 150 is configured, in particular, to store or maintain local (e.g., internal to devices 120, 130) operational data that is desirable for performing the functions according to embodiments of the present disclosure. Thus, memory 150 can function as a local data source for device 120 for local operational data 151. For example, memory 150 may be configured to store, in particular, information received by the receiving component of the communication interface 160 (e.g., external messages), geographic location permits (e.g., those received by digital assets), geographic location information (e.g., determined or maintained by a positioning unit 165 that can calculate or determine its location based on location information from a public information source 260), and / or time information that may include dates, etc. (e.g., determined or maintained by a time source 155 that can process location information from a public information source 260).

[0040] According to several embodiments, the stationary computer device 120 may consist of a geographic location permit corresponding to the installation location of the stationary computer device 120. In various embodiments, this can be done by consisting of georegion information that can be stored in memory 150 of a digital certificate installed on the stationary computer device 120. For example, at least one digital asset provided during the provisioning of the stationary computer device 120, such as a registration, pseudonym, or application certificate, may include information specifying the georegion on which the computer device 120 is authorized or permitted to operate. In various embodiments, the georegion information may specify a geographic area or region on which the computer device 120 can function appropriately as part of an ecosystem (e.g., a V2X environment or network). This geographic region may be referred to as the "authorized georegion" of the computer device 120, and examples include a region within any other geographic area or region, such as a specific country (e.g., USA), a state (e.g., Virginia or New England), a county (e.g., Fairfax County, Virginia), a city (e.g., Richmond, Virginia), or any other geographic area or region designated by coordinates or boundaries. In such embodiments, the computer device 120 can only operate and function properly within an authorized georegion and / or collaborate with other devices within the ecosystem (e.g., within a V2X environment).

[0041] In various embodiments, the computer device 120 is typically not yet deployed (e.g., still in the manufacturing stage) at the time the digital certificate is provided, and therefore the exact future operating location of the computer device 120 may not yet be clear. Therefore, the digital asset (e.g., the digital certificate) may be stored in memory 150 specifying a large "permitted" geographic area, such as a country, a group of states, or a state. However, the geographic location information may be updated throughout the lifespan of the stationary computer device 120, as well as the lifespan of the mobile computer device 130, based on the reception of information from a public information service 260 that provides navigation information by data broadcast (e.g., via the positioning unit 165).

[0042] In some embodiments, memory 150 may be shared among the components of the device and therefore may be configured to act as memory for a processor (not shown) to perform operations related to the functions of the associated computer devices 120, 130. Alternatively, memory 150 may be a dedicated memory for storing information related to verifying the reliability of operational data, while other data and information are stored elsewhere for access by computer devices 120, 130. Thus, memory 150 may be accessed by one or more components of computer devices 120, 130 (e.g., a processor, a communication interface 160, etc.) for the purpose of providing information to verify the reliability of the date / time and / or location of computer devices 120, 130. In some embodiments, the time source 155 and other operational data may be part of memory 155, stored in memory 155, and / or maintained in memory 155. For example, local time data of the fixed computer device 120 may be maintained and / or stored in memory 150, and similarly, local location data of the fixed computer device 120 may be maintained and / or stored in memory 150.

[0043] In various embodiments, the time source 155 is configured to maintain the local date and / or time of each computer device 120, 130 in order to determine the current local time, which may include date information, and to allow access by one or more applications running on the computer devices 120, 130. For example, the computer devices 120, 130 may receive one or more OTA updates that include a time window indicating the validity period of the OTA update. The computer devices 120, 130 may be configured to process the local date and time maintained by the computer device in order to determine whether they are within the validity period specified by the OTA update.

[0044] According to some embodiments, the time source 155 of computer devices 120, 130 may initially be set to the local date and time of computer devices 120, 130, for example, during provisioning. This initial information may then be stored in memory 150 as internal time data, and the time source 155 can then begin updating the date and time values ​​based on the internal time management system (for example, by manipulating the values ​​stored in memory 150). For example, the time source 155 may include one or more oscillators designed to track the time elapsed since the last update of memory 150 and determine the local time of computer devices 120, 130 by adding an incremental time measured by the oscillators to the internal time data stored in memory 150 (for example, by incrementing a counter). Thus, based on the last memory update, the processor of the computer device can determine the current time by adding the incremental time.

[0045] According to some embodiments, computer devices 120, 130 can provide date and time information by broadcast data received from a public information service 260 (e.g., GNSS, GPS, etc.), and computer devices 120, 130 can store the date and time information in memory 150 for access by one or more components of computer devices 120, 130. For example, information contained in a broadcast from GNSS includes date and time data that enables the receiving device to determine the actual external time according to GNSS. Thus, the time information in the broadcast data can be received, processed, and used to update the time source 155 with the time information received by GNSS.

[0046] In particular, as will be explained below, depending on the level of confidence demonstrated according to embodiments of this disclosure regarding the local date and time maintained by the time source 155 of computer devices 120 and 130, the local date and time may be ignored, and corrective actions may be triggered to correct the local date and time data. In other words, if devices 120 and 130 determine, based on external information, that their local date and time information is imprecise or inaccurate, they can perform actions to correct that local date and time information. While various embodiments described herein refer to “date and time” information, it should be understood that in some embodiments, time information and date information may be separated and processed separately.

[0047] The communication interface 160 may, in particular, include one or more receivers and / or one or more transmitters. The receivers may be configured for receiving information wirelessly (e.g., WiFi, Bluetooth®, cellular, etc.) and / or wiredly (e.g., Ethernet®, USB, serial COM, etc.). For example, the receivers may include one or more wireless receivers for receiving wireless messages transmitted from ecosystem members (e.g., mobile computer devices 130), including, for example, in the context of a v2X ecosystem, Basic Safety Messages (BSM), Cooperative Recognition Messages (CAM), and Decentralized Environment Notification Messages (DENM).

[0048] According to some embodiments, one of the receivers of the communication interface 160 may be configured to receive location / position information from a public information service 260 (e.g., GNSS) for use in determining the location of computer devices 120, 130. For example, the receiver of the communication interface 160 may be configured to receive GNSS broadcast information and, in particular, to provide such information to the positioning unit 165 in order to enable the determination of, for example, the longitude and latitude of computer devices 120, 130, which can be obtained based on the received GNSS broadcast information.

[0049] The transmitter portion of the communication interface 160 may include transmitters configured to wirelessly transmit information from each of the computer devices 120 and 130, if provided. For example, the first transmitter may be configured to transmit BSM, CAM, and DENM, as well as other messages related to the ecosystem.

[0050] In addition, the transmitter portion of the communication interface may include a second transmitter that transmits information related to functions associated with computer devices 120 and 130, such as traffic control signals. Such functions may, if desired, be provided by the first transmitter, in which case the second transmitter may or may not be implemented.

[0051] The location unit 165 is configured to acquire broadcast location information received by the communication interface 160 and to determine the geographical location of each computer device 120, 130 based on that information. For example, the receiver of the communication interface 160 can receive GNSS broadcast data and use the information received in the GNSS broadcast data to determine the geographical location (e.g., longitude and latitude) of the computer devices 120, 130, and, if desired, also acquire date and time data from the same broadcast data.

[0052] The position unit 165 may be configured to update one or more portions of the memory 150 based on information acquired by the position unit 165. For example, when the position unit 165 receives broadcast information from GNSS, it can determine location information, such as latitude and longitude indicated by a coordinate pair, and store the internally determined location information in the memory 150. In various embodiments, this update may be performed periodically or in real time, for example, depending on the installation location of the computer devices 120, 130.

[0053] As described above, the position unit 165 may also be configured to process, for example, parse date and time information from the GNSS broadcast and provide that information to the time source 155. The time source 155 can then update the memory 150 (i.e., the memory location where the local time is maintained) so that the local time maintained by the time source 155 matches the time received in the broadcast information (e.g., the time synchronized with the broadcast time information).

[0054] Figure 2 is an exemplary schematic diagram showing an example of communication that may occur with respect to the fixed computer device 120. As shown in the embodiment of Figure 2, the fixed computer device 120 has respective ecosystem members EM1, EM 2。。。 , EM nThey may be configured to receive multiple messages transmitted from. In particular, for the purpose of illustrating embodiments of the system herein, computer devices 120, 130 can become ecosystem member EMs if they obtain appropriate credentials, such as a digital certificate (e.g., a registration certificate) issued by an ecosystem authority. The registration certificate can function as a public key certificate that identifies its owner as an authorized participant / member within the ecosystem, and all participants within the ecosystem must share a valid registration certificate (e.g., a V2X ecosystem supported by USDOT). Since the registration certificate permits communication within the ecosystem, computer devices 120, 130 thus provisioned become authorized participants within the ecosystem and are able to receive other certificates, such as pseudonym certificates, that enable communication and operation of computer devices 120, 130 within the ecosystem (e.g., communication and operation between vehicles and roadside infrastructure in the V2X ecosystem example). Therefore, in the context of this disclosure, unless otherwise specified, it is assumed that the computer devices 120 and 130 discussed are provisioned with digital certificates that enable their membership and operation within the ecosystem.

[0055] Each ecosystem member EM n This corresponds to either a mobile computer device 130 or a fixed computer device 120, and is configured to communicate (for example, send and receive information) within the ecosystem in which it operates. For example, ecosystem member EM 1。。。n Each of these can receive broadcast information from public information services 260 (e.g., GNSS, cellular traffic data, etc.), which provide, among other things, date, time, and location data. Public information is distributed to each ecosystem member EM 1。。。nFor example, by using the positioning unit 165 and the processor, it is possible to determine the date, time, and geographical location of each computer device. The broadcast information provided by the public information service 260 may not be signed or encrypted. As a result, any computer device can receive and use the information included in the broadcast without using a key, certificate, or other digital assets used for secure communication. In some embodiments, the broadcast information provided by the public information service 260 may be digitally signed. In this case, the receiving computer device can verify the authenticity of the information before using it. In some embodiments, the broadcast information provided by the public information service 260 may be encrypted. In this case, only the computer device that can decrypt the information can use it.

[0056] Ecosystem member EM 1。。。n For example, in order to provide and share desirable information for safely performing functions within the ecosystem, such as autonomous driving and navigation within the V2X ecosystem, they can communicate with each other. For example, within the ecosystem, each of the computer devices 120, 130 (such as ECUs, OBUs, RSUs, etc.) may be configured to broadcast one or more messages at a specific frequency. For example, BSMs may be broadcast by each vehicle that is a member of the V2X ecosystem, and this broadcast is performed at a predetermined frequency (for example, 10 messages per second).

[0057] As described above, ecosystem member EM 1。。。n Each message transmitted and received between may be digitally signed (and optionally encrypted) based on digital assets (such as registration certificates, pseudonym certificates, etc.) provisioned to each of the ecosystem members EM 1。。。n within the ecosystem. For example, only verified, trusted, and participating ecosystem members EM 1。。。n can, from another ecosystem member EM 1。。。nTo authenticate messages from and allow access to sensitive data within them, each message (e.g., BSM, CAM, etc.) may be cryptographically signed using a key associated with a digital certificate provisioned on its respective device. The receiving ecosystem member EM then... 1。。。n The recipient can optionally decrypt the message (if necessary) and retrieve the data contained therein using the respective keys provided by the digital assets provisioned to the receiving device. As mentioned above, the message may be signed and sent, but in some embodiments (e.g., in the V2X ecosystem) it is not encrypted. Digital signatures allow each ecosystem member EM to... 1。。。n Messages received by can be considered secure and verifiable.

[0058] Based on these messages, the stationary computer unit 120 (and the mobile computer unit 130) will be an ecosystem member EM 1。。。n Receive messages sent between ecosystem members EM 1。。。n Situational data can be determined based on the information contained in the messages exchanged between them. For example, ecosystem member EM 1。。。n Each message exchanged between them may, in particular, include date and time data, as well as geographical location data of each computer device 130.

[0059] As shown in Figure 2, in some cases, broadcast data from the public information service 260 may be any combination of signed, unsigned, unencrypted, and / or weakly encrypted. If it is unsigned, unencrypted, or weakly encrypted, a sophisticated malicious actor could easily spoof the broadcast data, and an external criminal 250 could impersonate or mimic the public information service 260 and attempt to inject malicious data into the data broadcast by the public information service 260. Thus, an unauthorized third party 250 could spoof a device receiving its malicious data, in which case the device would believe it is receiving legitimate data from the public information service 260, particularly with respect to a fixed computer device 120 receiving location and / or time information. For example, an external criminal 250 might attempt to alter date, time, and / or geographic location information received by the computer device 120 with the aim of "extracting" local information stored within the fixed computer device 120. The criminal 250 may attempt to slowly extract information from the fixed computer device by transmitting information that deviates only slightly from the actual information (for example, a time deviation of a few milliseconds or a position deviation of a few centimeters), and may continue doing so for a considerable amount of time until the local time stored in the fixed computer device 120 deviates significantly from the actual time or place provided by the public information service 260.

[0060] Similarly, the criminal 250 may illegally modify, destroy, or alter the location information provided to the computer device 120 in a harmful manner, in which case, over time, the information stored in each computer device would indicate that the computer device is in a location different from its actual physical location. This location spoofing would continue until it indicated that the computer device 120 had left its permitted geographical area, in which case the computer device 120 would cease to function properly (for example, by shutting itself down).

[0061] Figure 3 is a graph illustrating how local information (e.g., date, time, location) of computer devices 120 and 130 can deviate from the actual, accurate information provided by the public information service 260, which can be caused by erroneous messages received over time from criminals 250. As can be seen from the figure, the initial deviation Δ of the local information (starting from time t=0) is small, but the deviation Δ can become significantly larger over time depending on the information injected into the system by criminals 250. Large deviations in date, time, and / or location data can lead to inaccurate operation, dangerous inaccuracies, and even the shutdown of computer devices 120 and 130, which in turn can lead to security and safety issues for the entire ecosystem. For example, if an autonomous vehicle relies on erroneous location information provided by an unauthorized external criminal 250, the autonomous vehicle may crash into another vehicle, roadside unit, road infrastructure, etc., due to the erroneous location information.

[0062] Figure 4 shows an exemplary road intersection 200 in which one or more computer devices 120, 130 may be present, consistent with an exemplary implementation of the System and Method. For ease and clarity of explanation, the operation of the System and Method of the Disclosure is often described in relation to a V2X ecosystem including at least one RSU 220 having a fixed computer device 120 and a plurality of vehicles 230, each vehicle including a mobile computer device 130, e.g., an OBU and / or ECU. In the embodiment of Figure 2, an exemplary GNSS 270 configured to provide broadcast information including navigation and time-related data functions as a public information service 260.

[0063] In this example, the RSU 220 may be present in various locations along the road (e.g., bridges, intersections, etc.) and may be configured to control one or more road features, such as traffic signals, signal lights, bridge operation, etc., and may also be configured to broadcast location data (e.g., location correction data) used by passing vehicles. One or more mobile computer devices 130 (e.g., ECU, OBU, etc.) installed in a vehicle 230 and capable of OTA digital signature communication for programming / updating may be present at and / or pass through an intersection 200. The vehicle 230 may, for example, stop at one or more traffic signals 240 that control the right of way through the intersection 200 and pass through the intersection 200 when the traffic signals controlled by the RSU 220 grant the right of way through the intersection to one or more vehicles 230.

[0064] As vehicle 230 passes through intersection 200, various messages are broadcast by the vehicle's mobile computer device 130, which can be received by other nearby vehicles 230 as well as by RSU 220. Messages transmitted by vehicle 230 may not be specifically intended for RSU 220, but RSU 220 can receive any transmitted message based on known V2X communication protocols. As mentioned above, these messages may include, among other things, BSM, CAM, and DENM. Each message transmitted by the mobile computer device 130 may contain various information related to the operation of the V2X network, such as the date, time, speed, and location of the vehicle 230 from which each message originates. In various embodiments, a mobile computer device 130 installed in a vehicle 230 can receive broadcast information from GNSS 270, which in particular enables the mobile computer device 130 installed in the vehicle 230 to determine its location and local date and time information in real time (i.e., without substantial delay or time lag, such as within 20 milliseconds, 10 milliseconds, 6 milliseconds, 3 milliseconds, or 0.5 milliseconds of reception). Each message transmitted by each computer device 130 may include the local time and location of the transmitting computer device 130, which may be referred to as external time data and external location / position data when discussed in relation to another computer device, such as RSU 220.

[0065] As described above, the RSU220 can broadcast position correction data to passing vehicles 230, which can then use this data to adjust their location as determined by their GNSS and notify functions such as autonomous driving. Therefore, it is important that the position correction data broadcast by the RSU220 (and / or any other member of the ecosystem) is precise in order to avoid collisions and other undesirable consequences that may occur when vehicles 230 have inaccurate calculations regarding their position.

[0066] Therefore, other ecosystem member EMs 1。。。n Any computer device 120 or 130 within the receiving range of the other ecosystem member EM 1。。。n You can obtain signed, verifiable information from it and use that information to verify the confidence level of your own local operational data 151.

[0067] Figure 5 is a flowchart illustrating an exemplary set of actions (e.g., processes or methods) for monitoring local operational data 151 of a computer device and taking corrective action if the local operational data 151 is corrupted (e.g., by an external criminal 250). In various embodiments, the actions shown in Figure 5 may be performed by the processors, software, and other hardware of computer devices 120, 130. Initially, the computer device may be configured to perform a “reliability check” of the local operational data 151 at specific or predetermined intervals (e.g., every 5 minutes, every hour, every 24 hours, etc.), and / or the reliability check frequency may, among other things, be controlled by ecosystem member EM. 1。。。n This may be based on the availability of external data messages from. For example, during a specific period of the day (e.g., at night), ecosystem member EM may be within the receiving range of a specific fixed computer device 120. 1。。。n There may be little to no such presence. During other times of the day (e.g., rush hour), many ecosystem members EM are within the reception range of the fixed computer equipment. 1。。。n There is a possibility that such a thing exists. Therefore, because there is a large amount of external data to precisely calculate the confidence level, the fixed computer device 120 has more ecosystem members EM than at times when there are fewer members (for example, 2 a.m.). 1。。。n More reliability checks can be performed during periods of high activity (for example, during rush hour).

[0068] As shown in the example in Figure 5, when a reliability check begins, computer devices 120 and 130 can first obtain local operation data 151 (for example, data that the device stores and uses internally while operating) that they intend to authenticate, such as local operation data 151 corresponding to the date, time, and / or location (operation 502). Therefore, for example, if the date and / or time are being checked, the internal time source 155 can be requested to provide internal time data representing the local time of computer devices 120 and 130. The internal date and / or time may be obtained, for example, from memory 150 and / or from broadcast information obtained from public information service 260. Alternatively, or in addition, the internal time source 155 may obtain internal time data representing the local time of computer devices 120 and 130 using information stored in memory 150 and data associated with the transmitter of the internal time source 155.

[0069] Next, the computer devices 120 and 130 perform reliability checks, for example via the communication interface 160, on ecosystem members EM that are within the receiving range of the computer devices 120 and 130. 1。。。n Multiple messages (e.g., signed and encrypted) can be retrieved from (operation 504). For example, in the context of RSU220 in Figure 4, RSU220 can retrieve multiple messages from four vehicles 230 located around intersection 200 and communicating with each other within the V2X ecosystem. Each message (e.g., BSM, CAM, etc.) may contain external operational data from each of the four vehicle 230's transmitting computer devices 130, which, among other things, relates to the date, time, and / or location. The operational data from the four vehicles 230 is "external" from the perspective of RSU220, which is receiving the data. RSU220 in Figure 4 may also incidentally retrieve such messages, for example, if the message is not directly intended for RSU220, because RSU220 is within its receiving range and can receive the message wirelessly and retrieve the external operational data contained therein.

[0070] Again, using date / time as an example, ecosystem member EM 1。。。n Each message received from may be processed (e.g., decoded and parsed) by computer devices 120, 130 performing reliability checks, and external time data may be extracted from predetermined fields of each message. For example, BSM may include date and time information in a second field of the message, and latitude and longitude may be represented in each of the further fields of the message.

[0071] Computer devices 120 and 130 that perform reliability checks are ecosystem member EM 1。。。n If external operational data (e.g., external time data) is obtained from one or more messages received from the device, the reliability of local operational data 151 (e.g., local time data or local location data) can be calculated or determined based on it (operation 506).

[0072] At this point, we consider Figure 6, a flowchart 600 that illustrates an exemplary set of actions for verifying the reliability of local time or location data based on multiple messages, including external operational data. In various implementations, Figure 6 can be considered an exemplary implementation of action 506 in Figure 5.

[0073] As shown in the example in Figure 6, ecosystem member EM 1。。。n Each message M of a group of messages received from j Regarding this, local (e.g., internal) operating data can be compared with external operating data to determine whether a deviation or difference Δ (delta) exists between the two (operation 602). For example, when comparing time data, local operating data 151 corresponding to the local time of the computer device performing the reliability check can be used by ecosystem member EM. n Message M j Message M, corresponding to the external time when it was sent. j This can be compared with external operational data. The difference between these values, if any, will be reflected in message M. j Deviation Δ jIt can be considered as such.

[0074] Next, the determined deviation Δ j This can be stored (for example, temporarily) in memory 150 for future use (operation 604). In some embodiments, message M j If there is no deviation (for example, if the internal time value and the external time value are the same), the process in Figure 6 can store data indicating that there was no deviation (for example, store a deviation score of 0).

[0075] The determined deviation Δ j Following the memory, it is determined whether the loop termination condition is met, and in the illustrated embodiment, process 600 sends a further message M 1。。。j Determine if it exists (operation 606). Further message M 1。。。j If it exists (action 606: yes), actions 602 and 604 are repeated, and further message M 1。。。j The deviation Δ is processed and j If you have it, you can remember it. Further message M 1。。。j If it does not exist (action 606: No), the process proceeds to action 608.

[0076] According to some embodiments, as a loop termination condition, operation 606 may determine whether the messages processed by operations 602 and 604 are less than a certain sample size (e.g., 5 messages, 10 messages, 20 messages, 30 messages, 50 messages, 100 messages, 200 messages, 1000 messages, etc.), and if that sample size is reached, operation 608 can be initiated. This may be desirable in a busy V2X ecosystem where most vehicles have OBUs and the frequency of messages is nearly continuous (rarely intermittent), in which case process 600 can perform its function on a basis that is typically statistically sampled. In some similar embodiments, process 600 may perform its function every minute using the most recent messages of a predetermined sample size (e.g., 50) received by the end of each minute.

[0077] According to some embodiments, as a loop termination condition in 606, process 600 may use the number of messages collected during a specific period. For example, messages M used to validate the confidence of local operational data 151 over a specific period based on the start of the confidence check. 1。。。j A set or sample of these can be taken. For example, this period may be from 1-2 seconds before the confidence check starts to 1-2 seconds after the confidence check starts. In various embodiments, the period may be set based on the frequency of one or more message types in the ecosystem. For example, in a V2X ecosystem where BSMs are transmitted at a frequency of about 10 Hz, a predetermined period of 1 second, 2 seconds, or 3 seconds may be appropriate. This period may be dynamically adjusted depending on the number of different computer devices 120, 130 broadcasting the BSMs, and the more different computer devices there are, the shorter the period may be.

[0078] The specific time periods mentioned above are not intended to be limiting, and any suitable period that allows the comparison of values ​​to be performed may be used, such as plus or minus 0.2 seconds, 0.5 seconds, 1 second, 2 seconds, 5 seconds, 10 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes, 15 minutes, etc. Alternatively, or in addition, the comparison 602 and storage 604 may be performed when the message is acquired by the computer devices 120, 130 that perform the check. In other words, operation 606 may be removed, in which case each message received from an ecosystem participant can trigger a confidence check. Alternatively, or in addition, the acquired messages may be processed in batches, and a time offset may be applied for comparison based on the batch processing.

[0079] Next, the stored group of deviations Δ 1。。。j The confidence level can be calculated or determined based on (operation 608). As a first example, according to some embodiments, the confidence level can be expressed as a percentage, where the percentage is the deviation Δ jThis is calculated as the percentage of messages where Δ is equal to 0. Considering such an example, the judged deviation Δ j If 90% of the deviations are equal to 0, i.e., no deviation, then a 90% confidence level can be established for the behavioral data being checked. Similarly, if 40% of the determined deviations are equal to 0, then a 40% confidence level can be established. In some similar embodiments, the deviation Δ j However, the percentage is calculated as the percentage of messages equal to an acceptable range, such as 0 plus or minus 5 milliseconds, 3 milliseconds, 1 millisecond, 0.5 milliseconds, 0.1 milliseconds, 0.01 milliseconds, or less. For example, in the case of an acceptable range of 0.5 milliseconds, if the system receives 10 external device messages and 7 of the external time data values ​​contained in those 10 messages are within + / - 0.5 msec of the system's internal operating time data value (i.e., 3 of the external time data values ​​have a deviation Δ greater than + / - 0.5 msec from the system's internal operating time data value), the system calculates or determines that its confidence level is 70%. In various embodiments, similar processing may be performed for location data, and the acceptable range may be 5 meters, 3 meters, 1 meter, 50 centimeters, 10 centimeters, 5 centimeters, 3 centimeters, 1 centimeter, or less.

[0080] As another example, according to some embodiments, the mean deviation Δ avg This can also be used as a basis for determining the reliability of the local operation data 151. In such embodiments, the mean deviation Δ determined across all messages for a particular reliability check is used. avg This is compared with the value in the lookup table stored in memory 150, for example, and the mean deviation Δ avg The correlation reliability related to can be determined. For example, using a time reliability check as an example, the mean deviation Δ avg If it is determined to be 0, the confidence level can be judged to be 100%, and the mean deviation Δ is in the range of 0 + / - 0.1 milliseconds. avg This can be equivalent to a 95% confidence level, with a mean deviation Δ in the range of 0 + / - 0.2 milliseconds.avg For example, this may correspond to a 90% confidence level. The range associated with a particular confidence level can be set as desired based on a specific application without departing from the scope of this disclosure, such as through a nonlinear correspondence between the range and the confidence level. In various embodiments, similar processing may be performed on location data, with the mean deviation Δ of 0 meters. avg It correlates with 100% confidence and has an average deviation Δ of 0.001 to 0.01 meters. avg This corresponds to a 98% confidence level, with an average deviation Δ in the range of 0.011 to 0.03 meters. avg This can be considered equivalent to a 95% confidence level, with an average deviation Δ in the range of 0.011 to 0.1 meters. avg This can be considered equivalent to a 90% confidence level, with an average deviation Δ in the range of 0.11 to 0.3 meters. avg This could be equivalent to an 83% confidence level.

[0081] According to further embodiments, a deviation counter can be implemented, and each deviation Δ greater than 0 or outside the 0+ / - tolerance range can be implemented. j The deviation counter increments by a specific value. For example, the time deviation Δ j If the range is greater than 0.2 milliseconds and up to 1 millisecond (corresponding to an acceptable range of 0.2 milliseconds), the counter may be incremented by 1. Time deviation Δ jFor example, if the range is greater than 1 millisecond and less than 2 milliseconds, the counter may be incremented by 2. The deviation counter can then be tracked over a specific period (e.g., 1 hour, 6 hours, 12 hours, etc.) to determine the final value of the deviation counter at the end of that period (e.g., the tracked deviation). In some embodiments, the period may be a rolling period, for example, the counter value calculated over the last 12 hours. The confidence level can then be determined based on the deviation counter value, for example, using a lookup table that correlates the counter value to a respective confidence level. For example, a deviation counter value of 0 (e.g., the sum of the tracked deviations over the period is 0) may correlate to a 100% confidence level, a deviation counter value of 0 may correlate to a 100% confidence level, a deviation counter value of 1 to 10 may correlate to a 95% confidence level, a deviation counter value of 11 to 15 may correlate to a 90% confidence level, a deviation counter value of 16 to 20 may correlate to an 80% confidence level, and so on. In various embodiments, similar processing may be performed on location data, for example, the location deviation Δ j If the range is between 0.05 and 0.2 meters, the counter may be incremented by 1, location deviation Δ j If the range is between 0.2 and 0.3 meters, the counter may be incremented by 2, and so on.

[0082] In some embodiments, the confidence level initially determined is the message M used by operation 608. 1。。。j It can be modified or adjusted based on the source. For example, message M 1。。。j If the message originates from a message source device with a small number or variety (for example, from a device with fewer than 10, 20, 30, or 40 devices, or fewer than a minimum threshold number), process 600 will process the message M 1。。。j To reflect the fact that the data is coming from a limited number of source devices, the confidence level determined in operation 608 can be reduced or adjusted to a negative value. If there are fewer types of source devices, message M 1。。。j(Thus, the calculated confidence) may be controlled, corrupted, or manipulated by messages and data from a malicious actor (e.g., an attacker). This may be the case if the device running process 600 (e.g., an RSU or OBU) is in a location or situation where the number of nearby vehicles changes slowly or does not change (e.g., during rush hour or near a red light). In some embodiments, process 600 may suspend confidence calculation 608 if the number or type of message source devices falls below a certain threshold (e.g., 10, 8, 5, etc.). Alternatively, or in addition, process 600 may increase the data sample size in operation 606 to reduce or eliminate the ability of an attacker to corrupt the operational data (e.g., time data and / or location data) of the device running process 600.

[0083] Meanwhile, message M 1。。。j If the message is originating from multiple source devices (for example, from more than 10, 20, 30, or 40 devices, or more than the minimum threshold number), the fact that the message (carrying operational data) is coming from multiple source devices is indicated in message M 1。。。j Process 600 does not need to change or adjust the confidence determined in operation 608, as it gives confidence that the system is not controlled, disrupted, or manipulated by messages from criminals. This may be the case if the device running process 600 (e.g., RSU or OBU) is located near a number of moving message source vehicles, and the nearby vehicles (i.e., message sources) change frequently.

[0084] Returning to Figure 5, once confidence is obtained, for example, by the method described in Figure 6 (operation 506), a determination is made as to whether the confidence falls below a specified threshold (operation 508). The confidence threshold can be set or determined in any manner appropriate for the specific application and / or type or use of the computer device performing the processes in Figures 5 and / or 6, such as computer devices 120, 130, 220, and / or 230. For example, in critical applications (e.g., where emergency services or autonomous vehicles are involved), if confidence is expressed as a percentage, a threshold confidence of 95% (or higher) may be set. In less critical applications (e.g., in home appliance control applications), a threshold confidence of 90% or even 80% may be considered acceptable. In some embodiments, the confidence threshold may be determined before the system operates, while in other embodiments, the confidence threshold may be calculated dynamically and may change during system operation.

[0085] If the reliability is determined to be above the threshold (operation 508: no), the reliability check is terminated. In various embodiments, the computer devices 120 and 130 can then perform another reliability check according to a period set for the computer devices 120 and 130.

[0086] If the confidence level is determined to be below a threshold (action 508: yes), the computer devices 120, 130 may perform, take, or trigger one or more corrective actions (action 510). According to some embodiments, in response to the determination that the confidence level is below a threshold, the computer devices 120, 130 may be configured to perform one or more of the following actions, among others: sending a warning message to a remote device; terminating communication; terminating broadcast; terminating a specific function that performs a self-correction algorithm (e.g., stopping or disabling automatic operation); resetting its own hardware; resetting or recalculating its own local operation data 151 (e.g., resetting its own internal time data or its own internal position data); notifying a human operator; and / or shutting itself down.

[0087] In various embodiments, the corrective actions taken may depend on the severity of the determined confidence level, for example, how far below a threshold the confidence level falls. For example, if the confidence level falls below a threshold confidence level by less than 5%, computer devices 120, 130 may first send a message that can be signed and / or encrypted to a remote monitoring device to indicate that the threshold confidence level is not met and that the service is desirable. In another example, if the confidence level falls more than 10% below the threshold, the computer device may first send a message to the remote monitoring device indicating a serious problem, and then immediately shut down itself to prevent problems arising from the use of imprecise operational data. For example, if the computer device executing the process in Figure 5 is RSU220, and RSU220 determines that its internal position operation data differs significantly (e.g., by 50M, 75M, 100M or more) from the position of a nearby vehicle 230 (e.g., if it determines that the reliability of its internal position operation data is very low), RSU220 can shut itself down to prevent broadcasting inaccurate position data to the passing vehicle 230, and / or stop broadcasting and take corrective action to correct its internal position operation data.

[0088] According to some embodiments, if the confidence level is determined to be below a threshold (508, yes), the computer devices 120 and 130 can implement a self-correction algorithm. For example, the computer devices 120 and 130 may be configured to calculate an approximate real-world time based on the initial operating time stored in memory 150 and information determined from an internal time source 155 (e.g., oscillator information). While waiting for a requested service, the computer devices 120 and 130 can use this approximate time as a temporary recalculated self-correction to its operational data.

[0089] Any other appropriate corrective actions are anticipated and are intended to fall within the scope of this disclosure.

[0090] In some embodiments, if the reliability of the operational data exceeds a threshold (508, no), i.e., if the process in Figure 5 determines with high confidence that the operational data is accurate or precise based on corresponding data received from other devices in the ecosystem, the process may perform one or more further operations or functions (not shown). In such embodiments, the process may create “checkpoints” where highly reliable operational data (e.g., highly reliable time data or highly reliable location data verified by the process in Figure 5) is stored. Checkpoints may be periodically written to non-volatile storage locations (e.g., in flash / solid-state memory, magnetic storage devices, optical storage devices, etc.) (e.g., every 1, 2, 5, 10, 15, 30, 60, 300, 600, 3,600 seconds or more) to verify that the checkpoint operational data is behaving correctly. For example, in the case of operational time data, that the time is monotonically increasing, or in the case of location data of a fixed RSU, that the location data is not changing. In some implementations, writing to solid-state devices (e.g., flash memory) at high frequencies over long periods, such as once per second, may be undesirable due to rapid device fatigue. In such implementations, it may be desirable to write checkpoint data less frequently than every second, but frequently enough to detect drift fairly quickly, such as every 10 seconds, 30 seconds, 60 seconds, or 300 seconds. Using a non-volatile storage location for checkpoint data is desirable (but not required) because it helps prevent an attacker (e.g., criminal 250) from tampering with operational data (such as time or location data) when the power is turned on, as the checkpoint data remains unchanged throughout power-off cycles. Another implementation could use RAM with battery backup to maintain the integrity of checkpoint data while the power is off, since RAM can be written to frequently (e.g., less than every second) without adverse effects.Furthermore, other implementations can use both RAM and non-volatile storage devices, which can be written to at different frequencies suited to each.

[0091] For ease of understanding, Figures 5 and 6 show a “termination” operation, but in various embodiments, the processes in Figures 5 and 6 are continuously repeated by the operating computer devices 120 and 130. In such embodiments, the processes in Figures 5 and 6 continuously collect or acquire messages, take statistical samples of those messages (based on, for example, the period, the number of messages, the number of independent message senders, or combinations thereof), determine the operation data delta for each sampled message, determine the confidence level of the local operation data 151, and, if optional, take corrective action if the confidence level is low.

[0092] Those skilled in the art will recognize that the components, processes, data, operations, and implementation details shown in Figures 1 to 6 are examples presented for the sake of brevity and clarity of the explanation. These examples are not intended to be limiting, and many variations are possible, so other components, processes, implementation details, and variations can be used without departing from the principles of the present invention. For example, in the processes of Figures 5 and 6, various operations can be added, removed, combined, or performed in parallel. As another example, the analysis method used to determine reliability (e.g., 506, Figures 6, 608), and / or the criteria for determining which messages and / or how many messages to analyze (e.g., 504, 606), may change dynamically depending on ecosystem factors such as the number of messages taken, the number of differences to be stored, how quickly messages change, how quickly message senders change, and / or may be done in other ways known to those skilled in the art. In general, the more messages received and the more different the message senders that produce those messages, the more precise the reliability calculation becomes.

[0093] Those skilled in the art will further recognize that while some of the examples and implementation details presented in connection with Figures 1 and 6 are in the realm of operating time data, similar functions, calculations, and operations can also be performed within the principles of this disclosure for operating location data (and other types of operating data).

[0094] Figure 7 shows an exemplary computer device 700 in which the systems, methods, and operations of the present disclosure may be implemented. The computing system 700 may be used, in particular, to implement at least partially any of the computer devices 120, 130, or a remote monitoring server (not shown) of the present disclosure.

[0095] In the example shown in Figure 7, the computing system 700 includes several components, including a CPU 705, memory 710, input / output (I / O) device 725, hardware security module (HSM) 740, and non-volatile storage device 720. The system 700 may be implemented in various ways. For example, an implementation as an RSU may include the CPU 705, memory 710, non-volatile storage device 720, and I / O device 725. In such a configuration, components 705, 710, 720, and 725 can connect and communicate through a local data bus 750 and access a data repository 716 (e.g., implemented as a separate data source or database system) via an external I / O connection. The I / O device 725 can connect to external devices via a direct communication link (e.g., wired or local WiFi connection), via a network such as a local area network (LAN) or wide area network (WAN such as a cellular network or the Internet), and / or other suitable connections. The system 700 may be standalone or a subsystem of a larger system.

[0096] The CPU 705 may be one or more known processors or processing units, such as a Core® family microprocessor manufactured by Intel® Corporation in Santa Clara, California, or an Athlon® family microprocessor manufactured by AMD® Corporation in Sunnyvale, California. The CPU 705 may also be an ARM CPU or a proprietary CPU. The memory 710 may be one or more high-speed storage devices configured to store instructions and information executed or used by the CPU 705 to perform certain functions, methods, and processes related to the implementation of the present invention. The memory 710 may, for example, correspond to the memory 150 of the computer devices 120, 130 described above.

[0097] The storage device 720 may be volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device, or it may be a computer-readable medium, including devices such as CDs and DVDs and solid-state devices, intended for long-term storage.

[0098] In the illustrated implementation, memory 710 may contain one or more programs or applications 715 loaded from storage device 720 or from a remote system (not shown) that, when executed by CPU 705, perform various operations, procedures, processes, or methods consistent with the present invention. Alternatively, CPU 705 may execute one or more programs located remotely from computing system 700. For example, computing system 700 may, when executed, have access via network 735 to one or more remote programs that perform functions and processes related to the implementation of the present invention.

[0099] In certain implementations, memory 710 may include a program 715 that performs special functions and operations described herein to perform reliability checks on local operational data 151 associated with computer devices 120, 130. In some implementations, memory 710 may also include other programs or applications that perform other methods and processes to provide auxiliary functions to the present invention.

[0100] Memory 710 may consist of other programs (not shown) unrelated to the present invention, and / or an operating system (not shown) that, when executed by CPU 705, performs some functions known in the art. For example, the operating system may be other operating systems including Microsoft Windows®, Unix®, Linux®, Apple Computer® operating systems, or real-time operating systems. The choice of operating system, and even the use of an operating system, is not important to the present invention.

[0101] The HSM740 may be a device equipped with its own processor that securely generates and stores digital security assets, and / or securely performs various cryptographic and sensitive calculations. The HSM740 protects digital security assets, such as cryptographic keys, and other sensitive data from potential access by attackers. In some implementations, the HSM may be a plug-in card or circuit board that is directly attached to the computing system 700.

[0102] The I / O device 725 may include one or more input / output devices that enable the computing system 700 to receive and / or transmit data. For example, the I / O device 725 may include one or more input devices, such as a keyboard, touchscreen, or mouse, that enable data input from a user. Furthermore, the I / O device 725 may include one or more output devices, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, or speaker device, that enable data output or presentation to the user. The I / O device 725 may also include one or more digital and / or analog communication input / output devices that enable the computing system 700 to communicate with other machines and devices, for example, digitally. The I / O device 725 may also incorporate a different configuration and / or number of input and / or output devices. The I / O device 725 can form part or all of the communication interface 160.

[0103] In the illustrated implementation, the computing system 700 connects to the Internet, private networks, Controller Area Network (CAN) bus, virtual private networks, cellular networks, GNSS networks, ecosystem networks (e.g., V2X networks and / or member EM) 1。。。n ), and / or other networks or combinations thereof, are connected to network 735, which may be connected to various systems and computing machines such as servers, personal computers, laptop computers, and computer devices 120, 130, 220, 230. Generally, computing system 700 can input data from and output data to external machines and devices via network 735.

[0104] In the exemplary implementation shown in Figure 7, the data repository 716 is hosted by the computing system 700. In other implementations, the repository 716 may be a standalone data source outside of the system 700, such as a database (not shown) connected via the network 735. In various implementations, the repository 716 can manage and store data used to implement systems and methods consistent with the present invention. For example, the repository 716 may be used, among other things, to store messages received from ecosystem members, determined deviations, and confidence judgments. In some implementations, the repository 716 may manage and store data structures containing status and log information for each computer device 120, 130.

[0105] In various implementations, the repository 716 may comprise one or more databases that store information and are accessed and / or managed through the computing system 700. For example, the repository 716 may be an Oracle® database, a Sybase® database, another relational database, or a non-relational database. However, systems and methods consistent with the present invention are not limited to separate data structures or databases, nor are they limited to the use of databases or data structures.

[0106] Those skilled in the art will recognize that the system components and implementation details in Figure 7 are examples presented for the sake of brevity and clarity in the explanation. Other components and implementation details may be used.

[0107] The examples described herein use specific examples of computer devices such as OBUs, ECUs, and RSUs to clarify the explanation, but the present invention is not limited to those specific examples. In addition to the V2X devices used herein to illustrate these new capabilities, devices, and methods, they can be applied to any IoT device, including those where time and / or geographical operating limitations are desired. Thus, various implementations consistent with the present invention can be used with and for a wide variety of computer devices, among others, such as medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, and wireless communication modules (e.g., embedded general-purpose integrated circuit cards (eUICCs)).

[0108] Various operations of the applications described herein may be performed, at least in part, by one or more processors that are temporarily or permanently configured (e.g., by software) to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute a processor implementation module that operates to perform one or more application operations, functions, and roles described herein. As used herein, the term “processor implementation module” refers to a hardware module implemented using one or more processors.

[0109] Similarly, the methods described herein may be at least partially processor-implemented, and one or more specific processors are examples of hardware. For example, at least part of the operation of a method may be performed by one or more processors or processor implementation modules. Furthermore, one or more processors may also operate to support the execution of the relevant operation in a “cloud computing” environment or as “software as a service” (SaaS). For example, at least part of the operation may be performed by a set of computers (as an example of a machine including a processor), and these operations may be accessible over a network (e.g., the Internet) and over one or more suitable interfaces (e.g., APIs).

[0110] The execution of a particular operation may reside not only within a single machine but may also be distributed across processors deployed across multiple machines. In some exemplary implementations, the processor or processor implementation module may be located in a single geographical location (e.g., within an office environment, manufacturing environment, or server farm). In other exemplary implementations, the processor or processor implementation module may be distributed across several geographical locations.

[0111] Throughout the description, including the claims, the term “including” should be understood to be synonymous with “including at least one” unless otherwise specified. In addition, any range described in the description, including the claims, should be understood to include its end value unless otherwise specified. The specific values ​​of the elements described should be understood to be within the acceptable manufacturing tolerances or industry tolerances known to those skilled in the art, and the use of the terms “substantially” and / or “approximately” and / or “generally” should be understood to mean that they are within such acceptable tolerances.

[0112] Other implementations of the invention will become apparent to those skilled in the art from the discussion herein and the practices of the invention disclosed herein. This specification and examples are intended to be illustrative only, and the true scope of the invention is given by the following claims.

Claims

1. A system for verifying the reliability of local operating data of devices within an ecosystem, wherein the system A local data source configured to maintain local operating data of the aforementioned device, Communication interface, A processor operably connected to the communication interface and the local data source, Equipped with, The aforementioned system The steps include: acquiring local operation data of the device using the local data source; A step of obtaining a plurality of messages from a plurality of external devices participating in the ecosystem using the communication interface, wherein each of the plurality of messages includes external operation data corresponding to the respective external device. The steps include using the processor to determine the reliability of the local operation data based on the local operation data and the external operation data from the plurality of messages, The steps include: taking corrective action when the confidence level falls below the confidence threshold; A system configured to perform actions that include the following.

2. The system according to claim 1, wherein the operation further includes the step of updating the local operation data based on information received via the communication interface from a publicly available service.

3. The system according to claim 2, wherein the updating step is performed at predetermined intervals.

4. The system according to claim 2, wherein the information is not encrypted and is received from the publicly available service.

5. The system according to claim 2, wherein the publicly available service is a Global Navigation Satellite System (GNSS).

6. The system according to claim 1, wherein each of the plurality of messages is digitally signed.

7. The local operation data includes local time data, the external operation data includes external time data, and the operation is A step of generating an updated local time by updating the local time data to match time information received from a publicly available service, A step of comparing the external time data from each of the plurality of messages with the updated local time data to determine the time deviation between the updated local time data and the external time data from each message. The steps include: incrementing a deviation counter based on the time deviation, in response to determining that the time deviation of the message exceeds an acceptable value; The system according to claim 1, further comprising:

8. The aforementioned operation is, To generate a tracking deviation, the steps include tracking the deviation counter over a specified period, The steps include using the tracking deviation to determine the reliability, The system according to claim 7, further comprising:

9. The system according to claim 1, wherein at least one of the plurality of messages corresponds to at least one of a Basic Safety Message (BSM), a Cooperative Recognition Message (CAM), or a Decentralized Environment Notification Message (DENM) within a V2X ecosystem.

10. The system according to claim 1, wherein the device includes one of an on-board unit (OBU), an electronic control unit (ECU), and a roadside unit (RSU).

11. The device is configured to be installed on one or more of the following: ships, aircraft, spacecraft, medical devices, robots, drones, wireless communication modules, wired communication modules, electronic signs, digital billboards, and Internet of Things (IoT) devices. The system according to claim 1.

12. The system according to claim 1, wherein the corrective action includes one or more of the following: sending a warning message to a remote device, terminating communication from the device, executing a self-correction algorithm, and shutting down the device.

13. The local operation data includes local location data, the external operation data includes external location data, and the operation is A step of generating an updated local location by updating the local location data among the local operation data based on location information received from a publicly available service, The steps include comparing the external location data from each of the plurality of messages with the updated local location data to determine the positional deviation between the updated local location data and the external location data from each message, The steps include: incrementing a deviation counter based on the position deviation, in response to determining that the position deviation of the message exceeds an acceptable value; The system according to claim 1, further comprising:

14. The aforementioned operation is, To generate a tracking deviation, the steps include tracking the deviation counter over a specified period, The steps include using the tracking deviation to determine the reliability, The system according to claim 13, further comprising:

15. When executed by the processor of a device within the ecosystem, The steps include: obtaining local operational data of the device using a local data source that maintains data for the device; A step of obtaining multiple messages from multiple external devices participating in the ecosystem, wherein each of the multiple messages includes external operation data corresponding to each external device. The steps include using the processor to determine the reliability of the local operation data based on the local operation data and the external operation data from the plurality of messages, The steps include: taking corrective action when the confidence level falls below the confidence threshold; A non-temporary computer-readable medium containing instructions that cause the processor to perform an operation including the above.

16. A computer implementation method for verifying the reliability of local operating data of devices within an ecosystem, wherein the method is The steps include: obtaining local operational data of the device using a local data source that maintains data for the device; A step of obtaining multiple messages from multiple external devices participating in the ecosystem, wherein each of the multiple messages includes external operation data corresponding to each external device. A step of determining the reliability of the local operation data based on the local operation data and the external operation data from the plurality of messages, The steps include: taking corrective action when the confidence level falls below the confidence threshold; A computer implementation method, including

Images