IMPLEMENTATION DECISION TO DELIVER AN ADAS FEATURE UPDATE FOR A VEHICLE

Abstract

A method implementing a feature update for an advanced driver assistance system (“an ADAS system”) (180) of a vehicle (123), the method comprising: Receiving (303) a dedicated short-range communication message (“a DSRC message”) on a 5.9 gigahertz band, the DSRC message comprising digital data (190) describing a driving situation of one or more other vehicles (124) in relation to the vehicle (123) and describing the conditions of the vehicle (123); Determining, based on the driving situation described by the digital data (190), whether the functional update for the ADAS system (180) is to be implemented by reconfiguring a field-programmable gate array (“an FPGA”) (184) of the vehicle (123) that is operable to control an operation of the ADAS system (180) or whether the functional update is to be implemented via software; and if it is determined to implement the functional update for the ADAS system (180) by reconfiguring the FPGA (184), reconfiguring (313; 315; 325) the FPGA (184) of the vehicle (123) to implement the functional update such that the FPGA (184) controls the operation of the ADAS system (180) in a manner consistent with the functional update.

Description

BACKGROUNDThe specification relates to providing an implementation decision as to how to implement an update for an advanced driver assistance system of a vehicle.Vehicle control systems are becoming increasingly popular. An example of a vehicle control system is an advanced driver assistance system ("advanced driver assistance system") ("ADAS system" in singular, "ADAS systems" in plural).Proper functioning of ADAS systems depends on the availability of function updates that modify the functionality provided by the ADAS systems.The document DE 10 2017 113 412 A1 discloses providing a notification about a traffic obstruction on the basis of wireless vehicle data included in a wireless message, wherein the wireless message may comprise a DSRC message.The document DE 10 2014 204 694 A1 discloses a use of information between a group of vehicles using the DSRC standard.The document DE 10 2017 120 708 A1 discloses an adaptive transmission power control for vehicle communication of a vehicle with a driver assistance unit by means of DSRC protocol.However, none of these references deals with the availability of function updates.SUMMARYModern vehicles are equipped with a set of ADAS systems. The set of ADAS systems includes one or more ADAS systems. The one or more ADAS systems require periodic update to modify or enhance the functionality they provide.Updates that modify or enhance the functionality of an ADAS system are referred to as a "function update.". There are two possible options for implementing a function update: (1) use of software to implement the function update; and (2) use of one or more field programmable gate arrays ("field programmable gate arrays") ("FPGA" in singular, "FPGA" in plural) to implement the function update.In most cases, implementation of function updates using FPGAs is faster than implementation of such updates via software only. However, implementation of such updates via FPGA is generally also more expensive and takes a longer time. Currently, there is no solution that helps a vehicle determine whether to implement function updates for an ADAS system of a vehicle via software updates or via FPGA. The update system described herein solves this problem. In this way, the update system improves performance of a vehicle by determining whether ADAS function updates for the vehicle are implemented by one or more of the following methods: (1) implementing software updates for one or more ADAS systems of the vehicle, in such a way that the functionality provided by the one or more ADAS systems is modified according to the function update [hereinafter referred to as "implementing the function update via software" or "implementing the function update via software"]; (2) Modifying one or more FPGAs of the vehicle in such a manner that the functionality provided by the one or more ADAS systems is modified according to the function update [hereinafter referred to as "implementing the function update via FPGA" or "implementing the function update via FPGA"].As used herein, an "implementation decision" is a decision as to whether a function update for an ADAS system of a vehicle is implemented via software or via FPGA.The update system described herein provides numerous advantages. For example, the update system determines whether it is better to implement the function update via software or FPGA based on real-time data describing the current situation of the vehicle. No other technology provides this functionality. Our research indicates that the update system will reduce cost and increase vehicle safety by implementing the function update of the ADAS systems in the fastest and most beneficial possible manner, while also meeting both system constraints and real-world constraints currently experienced by the vehicle at the time the implementation decision is made by the update system.In some embodiments, the update system is an element of a vehicle. In some embodiments, the update system is an element of a server. In some embodiments, the vehicle and the server each comprise their own instance of the update system and the functionality of the update system is distributed between the vehicle and the server. For example, in FIG. 1A, the update system is shown as an element of the vehicle and the server, and the update system itself is shown with a dashed line to indicate that the update system may be an element of the vehicle, the server, or both the vehicle and the server.In some embodiments, the vehicle comprising the update system is a DSRC-equipped vehicle. A DSRC-equipped vehicle may include a vehicle that includes one or more of the following elements: a DSRC transceiver and any software or hardware necessary to encode and transmit a DSRC message; a DSRC receiver and any software or hardware necessary to receive and decode a DSRC message; and a DSRC-compliant global positioning system (a "DSRC-compliant GPS unit").A DSRC message is a wireless message specifically configured to be transmitted and received by very mobile devices such as vehicles and is compliant with one or more of the following DSRC standards including any derivations or bifurcations thereof: EN 12253:2004 dedicated short-range communication physical layer using microwaves at 5.8 GHz (review); EN 12795:2002 dedicated short-range communication (DSRC) DSRC data link layer: media access and logic link control (review); EN 12834:2002 dedicated short-range communication - application layer (review); and EN 13372:2004 Dedicated Short Range Communication (DSRC) DSRC profiles for RTTT applications (review); EN ISO 14906:2004 Electronic Charging Application Interface.In the United States, Europe and Asia, DSRC messages are transmitted at 5.9 gigahertz ("GHz"). In the United States, DSRC messages are assigned 75 MHz of spectrum in the 5.9 GHz band. In Europe and Asia, DSRC messages are assigned 30 MHz of a spectrum in the 5.9 GHz band. A wireless message is therefore not a DSRC message as long as it is not operating in the 5.9 GHz band. A wireless message is also not a DSRC message as long as it is not transmitted by a DSRC transmitter of a DSRC radio.Accordingly, a DSRC message is not one of the following: a WiFi message; a 3G message; a 4G message; an LTE message; a millimeter wave communication message; a Bluetooth message; a satellite communication; and a short range radio message transmitted or broadcast by a fob at 315 megahertz (MHz) or 433.92 MHz. For example, in the United States, fobs for remote keyless systems include a short range radio transmitter operating at 315 MHz, and transmissions or broadcasts from that short range radio transmitter are not DSRC messages, for example, since such transmissions or broadcasts are not compliant with any DSRC standard, are not transmitted by a DSRC transmitter of a DSRC radio, and are not transmitted at 5.9 GHz. In another example, in Europe and Asia, fobs for remote keyless systems include a short range radio transmitter operating at 433.92 MHz, and transmissions or broadcasts from that short range radio transmitter are not DSRC messages for the same reasons as described above for the remote keyless systems in the United States.In some embodiments, the DSRC-equipped vehicle does not include a conventional global positioning system ("GPS") unit, and instead includes a DSRC-compliant GPS unit. A conventional GPS unit provides position information describing a position of the conventional GPS unit with an accuracy of plus or minus 10 meters of the current position of the conventional GPS unit. For comparison, a DSRC-compliant GPS unit provides GPS data describing a position of the DSRC-compliant GPS unit with an accuracy of plus or minus 1.5 meters of the current position of the DSRC-compliant GPS unit. This degree of accuracy is referred to as "lane level accuracy" because a lane of a road is generally about 3 meters wide, and an accuracy of plus or minus 1.5 meters is sufficient to identify which lane the vehicle is traveling on even if the vehicle is traveling on a road having a plurality of lanes in which traffic flows in the same direction.In some embodiments, the vehicle including the update system wirelessly communicates with other DSRC-equipped devices via DSRC. These other DSRC-equipped devices may be, for example, a different DSRC-powered vehicle, a roadside unit ("RSU" in singular, "RSUs" in plural), or many other communication devices equipped with DSRC. For example, a roadside unit ("RSU") or any other communication device may be equipped with DSRC if it comprises one or more of the following: a DSRC transceiver and any software or hardware necessary to encode and transmit a DSRC message; and a DSRC receiver and any software or hardware necessary to receive and decode a DSRC message.The embodiments described herein may wirelessly transmit digital data to the vehicle including the update system via a wireless message, such as a DSRC message or a basic safety massage (BSM) message. These wireless messages include BSM data, such as those illustrated in FIGS. 4A and 4B, or many other digital data that describes information similar to information described by the BSM data. The update system described herein uses this BSM data (or some other similar data transmitted over DSRC) to determine whether to implement the function update over software or FPGA. This BSM data provides real-time data describing the current driving situation or a context in which the function update will be implemented, which is advantageous, for example, to ensure that the function update is implemented in a safe and efficient manner.A system of one or more computers may be configured to perform certain operations or actions by installing software, firmware, hardware, or a combination thereof on the system, which, in operation, cause the system to perform the actions. One or more computer programs may be configured to perform certain operations or actions by including instructions that, when executed by a computing device, cause the device to perform the actions. One general aspect includes a method that implements a function update for an ADAS system of a vehicle, the method comprising: receiving a DSRC message on a 5.9 GHz band, the DSRC message including digital data describing a driving situation of one or more other vehicles relative to the vehicle and describing conditions of the vehicle; determining, based on the driving situation described by the digital data, whether to implement the function update for the ADAS system by reconfiguring an FPGA of the vehicle that is operable to control operation of the ADAS system or implement the function update via software; and when it is determined to implement the function update for the ADAS system by reconfiguring the FPGA, reconfiguring the FPGA of the vehicle to implement the function update such that the FPGA controls the operation of the ADAS system in a manner corresponding to the function update. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.Implementations may include one or more of the following features. The method wherein the DSRC message is a BSM message and the digital data is BSM data. The method where the DSRC message is transmitted to the vehicle by a roadside unit ("RSU"). The method where the digital data describes a geographic location of one or more other vehicles with an accuracy of plus or minus 1.5 meters relative to an actual geographic location of the one or more other vehicles. The method in which the FPGA is an element of an electronic control unit of the vehicle. The method in which the FPGA is reconfigured based on update data describing how to reconfigure the FPGA to implement the function update. The method where the function update modifies functionality provided by the ADAS system. Implementations of the described techniques may include hardware, a method, or a process, computer software on a computer-accessible medium.One general aspect includes a system including a vehicle, the vehicle including: an ADAS system; a DSRC receiver; an FPGA; and an on-vehicle vehicle computer system communicatively coupled to the ADAS system, the DSRC receiver, and the FPGA, the on-vehicle vehicle computer system comprising a non-volatile memory that stores computer code that, when executed by the on-vehicle vehicle computer system, causes the on-vehicle vehicle computer system to: receive, by the DSRC receiver, a DSRC message on a 5.9 GHz band, the DSRC message comprising digital data describing a driving situation of one or more vehicles relative to the vehicle and describing conditions of the vehicle (123); based on the driving situation described by the digital data, determining whether to implement a function update for the ADAS system by reconfiguring the FPGA operable to control an operation of the ADAS system or to implement the function update via software; and when determining to implement the function update for the ADAS system by reconfiguring the FPGA, reconfiguring the FPGA to implement the function update such that the FPGA controls the operation of the ADAS system in a manner corresponding to the function update. Further embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.Implementations may include one or more of the following features. The system where the DSRC message is a BSM message and the digital data is BSM data. The system where the DSRC message is transmitted to the vehicle through an RSU. The system where the digital data describes a geographic location of one or more other vehicles with an accuracy of plus or minus 1.5 meters relative to an actual graphical location of the one or more other vehicles. The system in which the FPGA is an element of an electronic control unit of the vehicle. The system where the FPGA is reconfigured based on update data describing how to reconfigure the FPGA to implement the function update. The system where the function update modifies functionality provided by the ADAS system. Implementations of the various techniques may include hardware, a method or process, or computer software on a computer-accessible medium.One general aspect includes a computer program product having a non-transitory memory of a vehicle onboard computer system of a vehicle storing computer executable code that, when executed by a processor, causes the processor to: receive a DSRC message on a 5.9 GHz band, the DSRC message including digital data describing a driving situation of one or more other vehicles relative to the vehicle and describing conditions of the vehicle; determine, based on the driving situation described by the digital data, a function update for an ADAS system of the vehicle by reconfiguring an FPGA of the vehicle operable to control operation of the ADAS system to be implemented or the function update to be implemented via software; and when it is determined to implement the function update for the ADAS system by reconfiguring the FPGA, reconfiguring the FPGA of the vehicle to implement the function update, so that the FPGA controls the operation of the ADAS system in a manner corresponding to the function update. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.Implementations may include one or more of the following features. The computer program product, wherein the DSRC message is a BSM message and the digital data is BSM data. The computer program product, wherein the DSRC message is transmitted to the vehicle through an RSU. The computer program product, wherein the digital data describes a geographic location of the one or more other vehicles with an accuracy of plus or minus 1.5 meters relative to an actual geographic location of the one or more other vehicles. The computer program product, wherein the FPGA is an element of an electronic control unit of the vehicle. The computer program product, wherein the FPGA is reconfigured based on update data describing how to reconfigure the FPGA to implement the function update. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.BRIEF DESCRIPTION OF THE DRAWINGSThis disclosure is shown by way of example and not limitation in the figures of the accompanying drawings, in which like reference numerals are used to designate similar elements. FIG. 1A is a block diagram illustrating an operating environment for an update system according to some embodiments. FIG. 1B is a block diagram illustrating system data according to some embodiments. FIG. 1C is a block diagram illustrating functional constraint data according to some embodiments. FIG. 1D is a block diagram illustrating resource constraint data according to some embodiments. FIG. 1E is a block diagram illustrating estimated time data according to some embodiments. FIG. 1F is a block diagram illustrating estimated consumption data according to some embodiments. FIG. 1G is a block diagram illustrating decision data according to some embodiments. FIG. 1H is a block diagram illustrating analysis data according to some embodiments. FIG. 1I is a block diagram illustrating a roadway environment, in accordance with some embodiments. FIG. 2 is a block diagram illustrating an example of a computer system including an update system, in accordance with some embodiments. FIGS. 3A to 3C are flowcharts of an example of a method for making an implementation decision according to some embodiments. FIG. 4A is a block diagram illustrating an example of BSM data, according to some embodiments. FIG. 4B is a block diagram illustrating an example of BSM data, according to some embodiments.DETAILED DESCRIPTIONA vehicle includes an ADAS system and an update system. Function updates are periodically implemented for the ADAS system to modify the functionality provided by the ADAS system. Described herein are embodiments of an update system that determines whether to implement the function update using either a software update for the ADAS system or by reconfiguring an FPGA of the vehicle that controls the operation of the ADAS system.Examples of Wireless MessagesVehicles are increasingly equipped with DSRC. A vehicle equipped with DSRC may be referred to as "equipped with DSRC.". A DSRC-equipped vehicle may include a DSRC antenna and any hardware or software necessary to transmit and receive DSRC messages, generate DSRC messages, and read DSRC messages. A DSRC-equipped vehicle may include, for example, any hardware or software necessary to receive a DSRC message, retrieve data included in the DSRC message, and read the data included in the DSRC message.The one or more wireless messages may include a DSRC message. There are many types of DSRC messages. One type of DSRC message is known as a BSM. A vehicle equipped with DSRC broadcasts a BSM at a regular interval. The interval may be adjustable by the user.A BSM includes BSM data. The BSM data describes features of the vehicle that originally transmitted the BSM. Vehicles equipped with DSRC may broadcast BSMs at an adjustable rate. In some embodiments, the rate may be once every 0.1 seconds. The BSM includes BSM data describing, among other things, one or more of: (1) the path shape of the vehicle transmitting the BSM; (2) the speed of the vehicle transmitting the BSM; and (3) the GPS data (sometimes described as "global positioning system data" or "GPS data") describing a location of the vehicle transmitting the BSM. FIGS. 4A and 4B described below illustrate examples of BSM data according to some embodiments.In some embodiments, DSRC-equipped vehicles may probe other DSRC-equipped vehicles / devices along the road for information describing their current and future conditions, including their path history, future path, and remote sensor data that they might have received or generated. This information is described as "DSRC probe data". The DSRC probe data may include any data received via a DSRC probe or in response to a DSRC probe.A DSRC message may include DSRC-based data. The DSRC-based data may include BSM data or DSRC probe data. In some embodiments, the DSRC-based data included in a DSRC message may include BSM data or DSRC probe data received from a plurality of DSRC-compliant vehicles (or other DSRC-equipped devices). This BSM data or DSRC probe data may include an identifier of its source and the location of the source or any traffic events described by the BSM data or the DSRC probe data.In some embodiments, the DSRC-enabled vehicles will include a DSRC-compliant GPS unit. The BSM data or DSRC probe data may specify which lane a vehicle is traveling on, as well as its travel speed and path shape. The BSM data or DSRC probe data may further specify one or more of: a speed of the vehicle at one or more different times or at one or more different locations; a direction of the vehicle at one or more different times or at one or more different locations; and an acceleration of the vehicle at one or more different times or at one or more different locations.Another type of wireless communication is a full-duplex wireless communication described in U.S. patent application US 2016 / 0 065 355 A1 filed Aug. 28, 2014, entitled "Full-Duplex Coordination System," the portions of this document relating to the full-duplex wireless communication being incorporated herein by reference.Examples of Track Level AccuracyVehicles are increasingly being manufactured to include a GPS-based navigation system. A GPS-based navigation system may provide navigation routes to a driver based on GPS data and knowledge of queue lengths along lanes.Lane level accuracy may mean that the location of a vehicle is accurately described such that the lane of the vehicle may be accurately determined. A conventional GPS system is unable to determine the location of a vehicle with a lane level accuracy. A typical lane of a road is about 3 meters wide. However, a conventional GPS system could only have an accuracy of plus or minus 10 meters relative to the actual location of the vehicle.A DSRC-compliant GPS unit provides GPS data that describes the location of a vehicle with lane level accuracy. A DSRC-compliant GPS unit may include hardware that wirelessly communicates with a GPS satellite to retrieve GPS data describing a location of a vehicle with an accuracy that conforms to the DSRC standard. The DSRC standard requires the GPS data to be precise enough to infer whether two vehicles are on the same lane. The lane may be a lane of a road. The DSRC-compliant GPS unit may be operable to identify, monitor, and track its two-dimensional position within 1.5 meters of its actual position to 68% of the time under a clear sky. Because lanes of a road are typically not less than 3 meters wide, the update system described herein, whenever the two-dimensional error of the GPS data is less than 1.5 meters, can analyze the GPS data provided by the DSRC-compliant GPS unit and determine which lane of the road the vehicle is travelling on based on the relative positions of the vehicles on the road.ADAS SystemExamples of an ADAS system include one or more of the following elements of a vehicle: an adaptive cruise control (ACC) system; an adaptive cruise control (ACC) system; an adaptive high beam system; an adaptive light control system; an automatic parking system; an automotive night vision system; a blind spot monitor; a collision avoidance system; a cross wind stabilization system; a driver fatigue detection system; a driver monitoring system; an emergency driver assistance system; a forward collision warning system; an intersection assistance system; a smart cruise control system; a lane departure warning system; a pedestrian protection system; a traffic sign detection system; a turn assist; and a wrong-way warning system.The ADAS system may also include software or hardware included in the vehicle that makes the vehicle an autonomous vehicle or a semi-autonomous vehicle.In some embodiments, a function update for one or more ADAS systems of the vehicle is implemented via a software update. In other embodiments, the one or more ADAS systems includes, or is communicatively coupled to, one or more FPGAs, the configuration of which controls or at least partially controls the operations of one or more of the ADAS systems such that the function update may be implemented by reconfiguring the one or more FPGAs.MessageIn some embodiments, the update system may provide a notification to a driver of the vehicle to inform it whether the function update is implemented using a software update for the ADAS system or by reconfiguring the FPGA of the vehicle. The message provided to the driver of the vehicle may be a visual message such as a graphical user interface ("GUI"), an audio message such as a sound generated by one or more speakers, or a combination of a visual message and an audio message provided simultaneously or simultaneously.The visual notification may be provided by a head-up display unit or an electronic display image. The head-up display unit may comprise a three-dimensional head-up display unit such as that described in U.S. Patent Application No. US 2017 / 0 274 771 A1, filed March 24, 2016, entitled "Wireless Data Sharing Between a Mobile Client Device and a Three-Dimensional Heads-Up Display Unit", the portions of this document relating to the head-up display unit being incorporated by reference. The electronic display panel may be a member of a head unit or an infotainment system installed in the vehicle.The audio message may be provided by one or more speakers operated by the head unit, infotainment system, or navigation system of the vehicle.Example OverviewReferring to FIG. 1A, an operating environment 100 for an update system 199 is illustrated. The operating environment 100 may include one or more of the following: a vehicle 123; a remote vehicle 124; a roadside unit 104 ("RSU 104"); and a server 103. These elements of the operating environment 100 may be communicatively coupled to a network 105.In some embodiments, the server 103 may be an element of the RSU 104. In some embodiments, the server 103 may be a separate element from the RSU. For example, the server 103 may be a server or some other processor-based computing device operable to send and receive messages over the network 105. The RSU 104 and the server 103 will be described in more detail below.The network 105 may be of a conventional type, wired or wireless, and may have a variety of different configurations, including a star configuration, a token ring configuration, or other configurations. Further, the network 105 may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), or other interconnected data paths over which multiple devices and / or entities may communicate. In some embodiments, the network 105 may comprise a peer-to-peer network. The network 105 may also be coupled to or include portions of a telecommunications network for transmitting data in a variety of different communication protocols. In some embodiments, the network 105 includes a Bluetooth® communication network or a cellular communication network for sending and receiving data including a short message service (SMS), a multimedia message service (MMS), hypertext transfer protocol (HTTP), a direct data connection, a wireless application protocol (WAP), email, DSRC, a full-duplex wireless communication, and so forth. The network 105 may also include a mobile data network, which may include 3G, 4G, LTE, VoTE, or any other mobile or cellular data network, or a combination of mobile data networks. Further, the network 105 may include one or more IEEE 802.11 wireless networks.In some embodiments, one or more of the vehicle 123, the remote vehicle 124, the RSU 104, and the server 103 may be equipped with DSRC. The network 105 may include one or more communication channels shared among the vehicle 123 and one or more other wireless communication devices (e.g., one or more remote vehicles 124, RSUs 104, servers 103, etc.). The communication channel may include DSRC, full-duplex wireless communication, or any other wireless communication protocol. For example, the network 105 may be used to transmit a DSRC message, DSRC probe, or BSM including BSM data 195 (or similar data) to the vehicle 123.The vehicle 123 and the remote vehicle 124 may include the same or similar elements. The vehicle 123 and the remote vehicle 124 may share a connection or link. For example, the vehicle 123 and the remote vehicle 124 may share a common manufacturer (e.g., Toyota), and the functionality described herein could only be provided to vehicles having that common manufacturer.The vehicle 123 may include a car, truck, sport utility vehicle, bus, semi-trailer, drone, or any other roadway-based vehicle. In some embodiments, the vehicle 123 may include an autonomous vehicle or a semi-autonomous vehicle. For example, the vehicle 123 may include an ADAS system including one or more ADAS systems that provide sufficient ADAS functionality to make the vehicle 123 an autonomous vehicle.The vehicle 123 includes one or more of the following: a sensor set 182; a processor 125A; a memory 127A; a communication unit 145A; a DSRC-compliant GPS unit 170; an ADAS system 180; an electronic control unit 183 ("ECU 183"); an FPGA 184; and an update system 199. These elements of the vehicle 123 may be communicatively coupled to each other via a bus 120A.In some embodiments, the update system 199 is an element of the vehicle 123. In some embodiments, update system 199 is an element of server 103. In some exemplary embodiments, the vehicle 123 and the server 103 each comprise their own instance of the update system 199 and the functionality of the update system 199 is distributed between the vehicle 123 and the server 103. For example, the update system 199 is shown in FIG. 1A with a dashed line to indicate that the update system 199 may be an element of the vehicle 123, the server 103, or both the vehicle 123 and the server 103.In some embodiments, processor 125A and memory 127A may be elements of an in-vehicle vehicle computer system (not shown). The vehicle-side vehicle computer system may be operable to cause or control the operation of the update system 199. The vehicle-side vehicle computer system may be operable to access and execute data stored on the memory 127A to provide the functionality described herein to the update system 199 or its elements. In some embodiments, processor 125A and memory 127A are elements of ECU 183.The sensor set 182 may include one or more sensors operable to measure the physical environment outside of the vehicle 123. For example, the sensor set 182 may record one or more physical characteristics of the physical environment that is proximate to the vehicle 123.In some embodiments, sensor set 182 may include one or more of the following vehicle sensors: a camera; a LIDAR sensor; a laser altimeter; a navigation sensor (e.g., a global positioning system sensor of DSRC-compliant GPS unit 170); an infrared detector; a motion detector; a thermostat; a sound detector; a carbon monoxide sensor; a carbon dioxide sensor; an oxygen sensor; an air mass sensor; an engine coolant temperature sensor; a throttle position sensor; a crankshaft position sensor; an automotive engine sensor; a valve timer; an air fuel ratio meter; a blind spot meter; a curb sensor; a fault detector; a Hall effect sensor; a manifold absolute pressure sensor; a park sensor; a radar gun; a speedometer; a speed sensor; a tire pressure monitoring sensor; a torque sensor; a transmission fluid temperature sensor; a turbine speed sensor (TSS); a variable reluctance sensor; a vehicle speed sensor (VSS); a water sensor; a wheel speed sensor; and any other type of automotive sensor.The sensor set 182 may be operable to record data (optionally referred to as "sensor data" below) describing one or more locations of the vehicle 123 at one or more different times; this data may be time stamped to indicate the time when the vehicle 123 was at that particular location.Processor 125A includes an arithmetic logic unit, a microprocessor, a general purpose controller, or any other processor array to perform computations and provide electronic display signals to a display device. Processor 125A processes data signals and may include various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Although FIG. 1A includes a single processor 125A, multiple processors may be included. Other processors, operating systems, sensors, displays, and physical configurations may also be possible.The memory 127A stores instructions or data that can be executed by the processor 125A. The instructions or data may include code for performing the techniques described herein. The memory 127A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or any other memory device. In some embodiments, memory 127A also includes non-volatile memory or similar persistent storage device and media including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or any other mass storage device for storing information on a persistent basis.As shown in FIG. 1A, in some embodiments, memory 127A stores one or more of system data 190; update data 191; decision data 192; analysis data 193; and ADAS data 194.The system data 190 is digital data describing one or more variables or factors that affect whether a function update for the ADAS system 180 should be implemented by either providing a software update for the ADAS data 194 or reconfiguring the FPGA 184. In some embodiments, the system data 190 includes BSM data 195 received from one or more of the remote vehicle 124 and the RSU 104. The system data 190 will be described in detail below with reference to FIGS. 1B, 1C, 1D, 1E, and 1F.The update data 191 is digital data describing how to implement the function update for the ADAS system 180. In some embodiments, the content of the update data 191 is variable based on the implementation decision.For example, if the implementation decision is to implement the function update using a software update for the ADAS system 180, then the update data 191 is digital data describing an executable file that implements the function update when installed in the memory 127A or executed by the processor 125A.In another example, if the implementation decision is to implement the function update by reconfiguring the FPGA 184, then the update data 191 is digital data describing how to reconfigure the FPGA 184 to implement the function update (i.e., to modify the operation of the ADAS system 180 such that the operation of the ADAS system 180 is consistent with the function update for the ADAS system 180).The decision data 192 is digital data that provides a framework or protocol for comparing elements of the system data 190 with each other so that the update system 199 can determine whether to implement a function update described by the update data 191 using either a software update for the ADAS data 194 or a reconfiguration of the FPGA 184. In some embodiments, update system 199 outputs a set of binary variables in response to an analysis of system data 190 using decision data 192. The set of binary variables is then input to a data structure described by the analytics data 193 as a substep of the update system 199 making the implementation decision. The decision data 192 will be described in detail below with reference to FIG. 1G.The analysis data 194 is digital data describing a data structure for analyzing the system data 190. In some embodiments, the analysis data 194 describes a data structure for analyzing the set of binary variables output by the update system 199 after analyzing the system data 190 using the decision data 192. In some embodiments, the analysis data 194 is a table, such as the one shown in FIG. 1H. The analysis data 194 will be described in more detail below with reference to FIG. 1H.The ADAS data 194 is digital data describing code and routines that, when executed by the processor 125A, cause the ADAS system 180 to provide functionality. For example, ADAS data 194 is software for ADAS system 180 that, when executed by processor 125A, causes ADAS system 180 to provide functionality.The communication unit 145A transmits and receives data to and from a network 105 and to another communication channel. In some embodiments, communication unit 145A includes a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make vehicle 123 a DSRC-enabled device. In some embodiments, one or more of the remote vehicle 124 and the RSU 104 includes a communication unit 145A and a DSRC-compliant GPS unit 170, such that these elements of the operating environment 100 are DSRC-compliant devices.In some embodiments, communication unit 145A includes a port for direct physical connection to network 105 or to another communication channel. For example, communication unit 145A includes a USB, SD, CAT-5, or similar port for wired communication with network 105. In some embodiments, communication unit 145A includes a wireless transceiver for exchanging data with network 105 or other communication channel and using one or more wireless communication methods, including: IEEE 802.11; IEEE 802.16, Bluetooth®; EN ISO 14906:2004 Electronic Charging, Application Interface, EN 11253:2004 Dedicated Short Range Communication - Physical Layer using microwaves at 5.8 GHz (review); EN 12795:2002 Dedicated Short Range Communication (DSRC) - DSRC data link layer: Media Access and Logic Link Control (review); EN 12834:2002 Dedicated Short Range Communication - Application Layer (review); EN 13372:2004 Dedicated Short Range Communication (DSRC) DSRC profiles for Review (RTTT) applications; the communication method described in U.S. patent application US 2016 / 0 065 355 A1 filed on Aug. 28, 2014, entitled "Full-Duplex Coordination System"; or another suitable wireless communication method.In some embodiments, communication unit 145A includes a full-duplex coordination system described in U.S. patent application US 2016 / 0 065 355 A1 filed on Aug. 28, 2014, entitled "Full-Duplex Coordination System.".In some embodiments, communication unit 145A includes a cellular communication transceiver for transmitting and receiving data over a cellular communication network including a short message service (SMS), a multimedia message service (MMS), a hypertext transfer protocol (HTTP), a direct data connection, WAP, email, or other suitable type of electronic communication. In some embodiments, communication unit 145A includes a wired port and a wireless transceiver. Communication unit 145A also provides other conventional connections to network 105 for distributing data or media files using standard network protocols including TCP / IP, HTTP, HTTPS, and SMTP, millimeter waves, DSRC, etc.The DSRC-compliant GPS unit 170 may include hardware that wirelessly communicates with a GPS satellite to retrieve GPS data describing a location of the vehicle 123. In some embodiments, a DSRC-compliant GPS unit 170 is operable to provide GPS data describing the location of the vehicle 123 with a degree of accuracy of a lane level. The DSRC standard requires that GPS data be precise enough to infer whether two vehicles (such as vehicle 123 and another vehicle on the same road as vehicle 123) are in the same lane. The DSRC-compliant GPS unit 170 may be operable to identify, monitor, and track its two-dimensional position within 1.5 meters of its current position to 68% of the time under a clear sky. Since lanes of a road are typically not less than 3 meters wide, whenever the two-dimensional error of the GPS data is less than 1.5 meters, the update system 199 may analyze the GPS data provided by the DSRC-compliant GPS unit 170 and determine which lane of the road the vehicle 123 is driving based on the relative positions of the vehicles on the road. Similarly, the remote vehicle 124 includes a DSRC-compliant GPS unit 170 that provides GPS data that is included as an element of the BSM data 195 and describes the geographical location of the remote vehicle 124 with the same degree of precision.For comparison, a GPS unit that is not compliant with the DSRC standard is far less accurate than the DSRC-compliant GPS unit 170 and is not able to reliably provide track level accuracy, as is the DSRC-compliant GPS unit 170. For example, a non-DSRC-compliant GPS unit may have an accuracy on the order of 10 meters, which is not sufficiently precise to provide the degree of precision of a track level provided by the DSRC-compliant GPS unit 170. For example, since a track may be as narrow as 3 meters wide, the DSRC standard may require a DSRC-compliant GPS unit 170 to have an accuracy on the order of 1.5 meters, which is significantly more precise than a non-DSRC-compliant GPS unit as described above. As a result, a non-DSRC-compliant GPS unit may not be able to provide GPS data that is accurate enough to enable the update system 199 to determine how close other vehicles (such as the remote vehicle 124) are to the vehicle 123, which affects the ability of the update system 199 to accurately understand the context of the vehicle 123 when a function update is implemented. If this context information is not present, this negatively affects the ability of the update system 199 to make the best possible implementation decision, as a decision whether to select a software update or an FPGA reconfiguration for implementation of the function update is determined based in part on such information. The functionality and precision of the GPS data provided by the DSRC-compliant GPS unit 170 is therefore advantageous for this example reason.The ADAS system 180 may include one or more advanced driver assistance systems. Examples of an ADAS system 180 include one or more of the following elements of the vehicle 123: an ACC system; an adaptive high beam system; an adaptive light control system; an automatic parking system; a night vision automotive system; a blind spot monitor; a collision avoidance system; a cross wind stabilization system; a driver fatigue detection system; a driver monitoring system; an emergency driver assistance system; a forward collision warning system; an intersection assistance system; a smart speed adjustment system; a lane departure warning system; a pedestrian protection system; a road sign detection system; a turn assist; and a wrong-way warning system.In some embodiments, the ADAS system 180 includes any hardware or software that controls one or more operations of the vehicle 123 such that the vehicle 123 is "autonomous" or "semi-autonomous.".The ECU 183 is a conventional electronic control unit. In some embodiments, the ECU 183 is an element of a vehicle-side vehicle computer of the vehicle 123. In some embodiments, the ECU 183 is a vehicle-side unit element bz 7 w. On-board unit of vehicle 123. In some embodiments, the ECU 183 is operable to control the operation of the ADAS system 180. For example, the ECU 183 is the processor-based computing device of the vehicle 123 that controls the operations of the ADAS system 180. In some embodiments, the ECU 183 executes the ADAS data 184 to provide the functionality of the ADAS system 180.The FPGA 184 is a conventional field programmable gate array. In some embodiments, the FPGA 184 is an element of the ADAS system 180. In some embodiments, the ADAS system 180 is an element of the FPGA 184.In some embodiments, the FPGA 184 is a hardware FPGA configured to provide the functionality of the ADAS system 180. For example, the FPGA 184 is operable such that execution of the FPGA 184 provides some or all of the functionality of the ADAS system 180 (hereinafter "ADAS functionality"). In some embodiments, modifying the configuration of the FPGA 184 modifies the ADAS functionality provided by the FPGA 184. For example, in some embodiments, the FPGA 184 is operable such that reconfiguring the FPGA 184 based on the update data 191 causes the FPGA 184 to provide modified ADAS functionality consistent with the function update described by the update data 191.In some embodiments, the FPGA 184 is an element of the ECU 183. In some embodiments, the ECU 183 is a processor-based computing device that executes the code and routines of the update system 199 of the vehicle 123.In some embodiments, update system 199 includes code or routines that are operable, when executed by processor 125A, to cause processor 125A to collect the system data and make the implementation decision for a function update based on one or more of system data 190, decision data 192, and analysis data 193.In some embodiments, the update system 199 includes code or routines that are operable, when executed by the processor 125A, to cause the processor 125A to generate and transmit wireless averaging to the network 105 that includes digital data, such as the system data 190; the server 103 receives the wireless message and makes the implementation decision for the function update based on one or more of the system data 190, the decision data 192, and the analysis data 193; the server 103 then provides the update data 191 to the update system 199 of the vehicle 123 via the network 105.In some embodiments, update system 199 includes code or routines operable, when executed by processor 125A, to cause processor 125A to perform one or more steps of method 300 described below with reference to FIGS. 3A through 3C.In some embodiments, the update system 199 may be implemented using hardware including an FPGA or an application specific integrated circuit ("ASIC"). In some other embodiments, the update system 199 may be implemented using a combination of hardware and software. The update system 199 may be stored in a combination of the devices (e.g., servers or other devices) or in one of the devices.The update system 199 will be described in more detail below with reference to Figures 1B through 1H, 2 and 3A through 3C.Although not shown in FIG. 1A, in some embodiments, the vehicle 123 may include a full-duplex coordination system described in U.S. patent application US 2016 / 0 065 355 A1 filed on Aug. 28, 2014, entitled "Full-Duplex Coordination System.".In some embodiments, the full-duplex coordination system of the vehicle 123 may receive a full-duplex wireless message including any of the digital data stored on the memory 127A.The server 103 is a processor-based computing device. For example, the computing device may include a stand-alone hardware server. In some embodiments, the server 103 is communicatively coupled to the network 105. The server 103 may include network communication capabilities.The server 103 includes one or more of the following: a processor 125B; a memory 127B; a communication unit 145B; and an update system 199. These elements of the server 103 are communicatively coupled to each other via a bus 120B.The following elements of the server 103 are similar to those described above for the vehicle 123, so the description thereof will not be repeated here: the processor 125B; the memory 127B; the communication unit 145B; and the update system 199. The memory 127B of the server 103 may store digital data similar to the digital data stored in the memory 127A of the vehicle 123.The server 103 may be operable to send and receive wireless messages over the network 105. For example, the vehicle 123 update system 199 causes the vehicle communication unit 145A to transmit a wireless message to the server 103 via the network 105. The wireless message includes a request for the update data 191 as well as the system data 190. The communication unit 145B of the server 103 receives the wireless message from the network 105 and provides the wireless message including the request and the system data 190 to the update system 199 of the server 103. The update system 199 of the server 103 makes the implementation decision based at least in part on the system data 190, generates the update data 191 based on the implementation decision, and causes the communication unit 145B of the server 103 to provide the update data 191 to the vehicle 123 via the network 105.The remote vehicle 124 may include elements similar to the vehicle 123, so the description thereof will not be repeated herein. As shown, the remote vehicle 124 is a DSRC-equipped device that includes a DSRC-compliant GPS unit 170 and a communication unit 145 having a DSRC transmitter and a DSRC receiver that are operable to transmit and receive DSRC messages (e.g., BSM messages) that include the BSM data 195 or data similar to the BSM data 195. The BSM data 195 will be described in more detail below with reference to FIGS. 4A and 4B.The RSU 104 may include non-volatile memory that stores BSM data 195. The RSU 104 may also include a communication unit 145A (not shown). The RSU 104 may also include a sensor set 182 that records the sensor data. As an alternative to recording the sensor data directly using the own sensor set 182, the RSU 104 may forward sensor data recorded by a sensor set of the remote vehicle 124 to the vehicle 123 as an element of a BSM message or any other DSRC message. For example, if the vehicle 123 is outside of the communication range of the remote vehicle 124, then the RSU 104 may forward a wireless message including the BSM data 195 to the vehicle 123.Referring now to FIG. 1B, a block diagram illustrating system data 190 is shown, in accordance with some embodiments. As illustrated, the system data 190 includes one or more of the following types of digital data: file size data 140; FPGA size data 141; file time data 142; FPGA time data 143; BSM data 195 from one or more of the remote vehicle 124 and the RSU 104; functional constraint data 144; resource constraint data 146; estimated time data 147; and estimated consumption data 148.The file size data 140 is digital data that describes a size of the executable file that would be used to implement the function update via a software update. For example, if the implementation decision is that the function update is implemented via a software update, then the file size data 140 describes the file size of the executable file installed in the vehicle 123 to implement the function update; the executable file itself is described by the update data 191 in this embodiment.The FPGA size data 141 is digital data describing a size (or range) of the FPGA 184 that would be reconfigured to implement the function update as an FPGA reconfiguration. For example, the FPGA 184 has a certain area, and if the implementation decision is that the function update is implemented via an FPGA reconfiguration, then the FPGA size data 141 describes a size or area of the FPGA 184 that is reconfigured to implement the function update; in this embodiment, the update data 191 is a bitstream describing how to reconfigure the FPGA 184.The file time data 142 is digital data describing a normalized amount of time necessary to install the executable file or fully execute the executable file used to implement the function update as a software update. For example, if the implementation decision is that the function update is implemented via a software update, then the file time data 142 describes a normalized amount of time needed to fully execute the executable file (e.g., install the executable file) on a standardized software platform, which may or may not be the same as the software platform present on the vehicle 123.The FPGA time data 143 is digital data that describes a normalized amount of time necessary to reconfigure or fully execute the executable file. For example, if the implementation decision is that the function update is implemented via an FPGA reconfiguration, then the FPGA time data 143 describes a normalized amount of time necessary to fully reconfigure the FPGA on a standardized software platform, which may or may not be the same as the software platform present on the vehicle 123.The BSM data 195 will be described in more detail below with reference to FIGS. 4A and 4B. The system data 190 may include any or all of the information included in the BSM data 195.In some embodiments, the system data 190 includes the following elements of the BSM data 195 included in a portion I of one or more BSM messages received from one or more remote vehicles 124: a latitude for one or more remote vehicles 124; a longitude for one or more remote vehicles 124; a altitude for one or more remote vehicles 124; a positional accuracy for one or more remote vehicles 124; a transmission setting for one or more remote vehicles 124; a current speed for one or more remote vehicles 124; a current direction for one or more remote vehicles 124; a current steering angle for one or more vehicles 124; a current acceleration for one or more remote vehicles 124; a current status of the brake systems for one or more remote vehicles 124; and a vehicle size for one or more remote vehicles 124.In some embodiments, system data 190 includes the following elements of BSM data 195 included in a portion II of one or more BSM messages received from one or more remote vehicles 124: one or more event markers describing one or more nearby roadway events relevant to determining an execution deadline (T E') for completing the function update; path history data describing one or more past locations of one or more remote vehicles 124; and path prediction data describing one or more intended future paths for one or more remote vehicles 124.The functional restriction data 144 will be described below with reference to FIG. 1C. The resource restriction data 146 will be described below with reference to FIG. 1D. The estimated time data 147 will be described below with reference to FIG. 1E. The estimated consumption data 148 will be described below with reference to FIG. 1F.Referring to FIG. 1C, a block diagram illustrating the functional constraint data 144 is shown, in accordance with some embodiments.The update deadline 150 is digital data describing a soft deadline for completing the function update. In some embodiments, if the soft deadline is not met, then the function update is still implemented by the update system 199 and the update system 199 causes an electronic display, an HUD or 3D HUD of the vehicle 123 to display a warning message to the driver of the vehicle 123 that visually indicates that the function update is completed later than expected.The update deadline 150 may be represented by the variable T U' to which a value is assigned (e.g., a soft deadline time) described by the update deadline 150.The execution deadline 151 is digital data describing a hard deadline for completing the function update. In some embodiments, if the hard deadline is not met, then the function update is not implemented by the update system 199 and the update system 199 causes an electronic display, a HUD or 3D HUD of the vehicle 123 to display a warning message to the driver of the vehicle 123 that visually indicates that the function update is being completed.In some embodiments, the execution deadline 151 is determined by the update system 199 based on the driving conditions experienced by the vehicle 123. The driving conditions are described by the BSM data 195 received from one or more other DSRC-equipped devices, such as the remote vehicle 124 or the RSU 104. For example, the update system 199 includes code and routines that are operable, when executed by the processor of the vehicle 123, to cause the processor to analyze the BSM data 195 and determine the execution deadline 151. For example, if the BSM data 195 includes digital data indicating that a location of an event marker is reached by the vehicle 123 in X seconds, then the update system 199 determines that the execution deadline 151 is equal to X - Y seconds, where Y < X. In some embodiments, multiple event markers received from multiple other DSRC-equipped devices increase the accuracy for the execution deadline 151 or increase the confidence of the update system 199 at the execution deadline 151.The execution deadline 151 may be represented by the variable T E' to which a value (for example, a hard deadline time) described by the execution deadline 151 is assigned.Referring now to FIG. 1D, a block diagram illustrating resource constraint data 146 is shown, in accordance with some embodiments.The FPGA maximum power consumption 152 is digital data describing a maximum allowed power consumption for the FPGA 184. In some embodiments, the FPGA maximum power consumption 152 sets a limit on how quickly the FPGA 184 can be reconfigured because the FPGA 184 can be reconfigured more quickly when more power is allowed to be consumed. In some embodiments, the FPGA maximum power consumption 152 sets a limit to whether an implementation decision may be to implement the function update via FPGA 184, as this may cause the operation of FPGA 184 to exceed the maximum allowed power consumption for FPGA 184, indicating that the implementation decision should be to implement the function update as a software update.The FPGA maximum power consumption 152 may be represented by the variable P EF' to which a value (e.g., an amount of watts or other unit of power) described by the FPGA maximum power consumption 152 is assigned.The FPGA maximum range 153 is digital data describing a maximum allowed range available for reconfiguration when the FPGA 184 is reconfigured to implement the function update. In some embodiments, the FPGA maximum area 153 sets a limit to whether an implementation decision may be to implement the function update via FPGA 184, as this may require reconfiguration of a larger area of the FPGA 184 than is permitted by the FPGA maximum area 153, indicating that the implementation decision should be to implement the function update as a software update.The FPGA maximum range 153 may be represented by the variable A EF' to which a value (e.g., a range) described by the FPGA maximum range 153 is assigned.Referring now to FIG. 1E, a block diagram illustrating the estimate time data 147 is shown, in accordance with some embodiments.The estimation server decision time 154 is digital data describing an estimation of the amount of time necessary for the update system 199 of the server 103 to make the implementation decision.The estimation server decision time 154 may be represented by the variable T DO to which a value (for example, a time amount) described by the estimation server decision time 154 is assigned.The estimated vehicle decision time 155 is digital data describing an estimate of an amount of time necessary for the update system 199 of the vehicle 123 to make the implementation decision.The estimated vehicle decision time 155 is represented by the variable T DE to which a value (for example, a time amount) described by the estimated vehicle decision time 155 is assigned.The estimated time for update via software 156 is digital data describing an estimate of the amount of time that will be necessary to complete one or more of the following tasks: downloading the update data 191 to the vehicle 123 from the server 103 via the network 105 when the function update is implemented via a software update; and fully installing the executable file described by the update data 191 such that the executable file is installed in the vehicle 123 (i.e., installed in the ADAS data 194).For example, the estimated time for update via software 156 describes an amount of time for downloading the update data 192 from the server 103 to the vehicle 123 via the network 105. In some embodiments, the estimated time for update via software 156 is digital data describing a size of the software installation (e.g., the size of the executable file) via the speed of the software installation (e.g., how fast the executable file can be fully executed).The estimated time for update via software 156 may be represented by the variable T US assigned a value (e.g., amount of time) described by the estimated time for update via software 156.The estimated time for update via FPGA 157 is digital data describing an estimate of the amount of time that will be necessary to complete one or more of the following tasks: transmit a bitstream including update data 191 to vehicle 123 from server 103 via network 105 when the function update is implemented by reconfiguring FPGA 184; and reconfigure FPGA 184 based on update data 191 such that the function update is installed in vehicle 123.The estimated time for update via FPGA 157 may be represented by the variable T UF assigned a value (e.g., a time amount) described by the estimated time for update via FPGA 157. In some embodiments, the estimated time to update via FPGA 157 describes a size of the FPGA configuration via or corresponding to a speed of the FPGA configuration. In some embodiments, the following condition is general, but not always true: T UF > T US.The estimated software execution time 158 is digital data that describes an estimate of the amount of time that will be necessary to execute the function update after it is installed in the vehicle 123. For example, the estimated execution time for software 158 describes the amount of time necessary to fully execute the ADAS data 194 after the executable file described by the update data 191 is installed in the ADAS data 194 (or replaces the ADAS data 194). In some embodiments, the estimated execution time for software 158 is a normalized execution time for the executable multiplied by a scale. In some embodiments, the scaling is variable depending on the type of hardware on which the function update is deployed within the vehicle 123.The estimated software execution time 158 may be represented by the variable T ES assigned a value (e.g., a time amount) described by the estimated software execution time 158.The estimated execution time for FPGA 159 is digital data describing an estimate of the amount of time that will be necessary to perform the function update after FPGA 184 is reconfigured based on the update data 191 (which may be provided via a bitstream). For example, the estimated execution time for FPGA 159 describes the amount of time necessary to fully execute the reconfigured FPGA 159 after the function update is implemented. In some embodiments, the estimated execution time for FPGA 159 is a normalized execution time for reconfigured FPGA 184 multiplied by a scale. In some embodiments, the scaling is variable depending on different characteristics of the FPGA 184.The estimated execution time for FPGA 159 may be represented by the variable T EF assigned to a value (e.g., a time amount) described by the estimated execution time for FPGA 159. In some embodiments, the following condition is general, but not always true: T EF< T ES.Referring now to FIG. 1F, a block diagram illustrating estimated consumption data 148 is shown, in accordance with some embodiments.The estimated power consumption for FPGA 160 is digital data that describes an estimate of the amount of power necessary to execute FPGA 184 after it is reconfigured based on update data 191.The estimated power consumption for FPGA 160 may be represented by the variable P EF assigned a value (e.g., amount of power) described by the estimated power consumption for FPGA 160.The estimated range for FPGA 161 is digital data that describes an estimate of the amount of a range of FPGA 184 that needs to be reconfigured to implement the function update described by update data 191.The estimated range for FPGA 161 may be represented by the variable A EF assigned a value (e.g., a range) described by the estimated range for FPGA 161.Referring now to FIG. 1G, a block diagram illustrating decision data 192 is shown, in accordance with some embodiments. In some embodiments, the decision data 192 is digital data describing variables and values associated with those variables based on the relative values of the different elements of the system data 190 illustrated in FIG. 1G.Referring now to FIG. 1H, a block diagram illustrating analysis data 193 is shown, in accordance with some embodiments. In some embodiments, the analysis data 193 is digital data describing the possible implementation decisions made by the update system 199 based on the variables and values assigned with respect to the decision data 192 and the system data 190. In some embodiments, the actual implementation decision made by the update system 199 is always described by the analysis data 193 depending on the application of the decision data 192 to the system data 190.Referring now to FIG. 1I, a block diagram illustrating a roadway environment 166 is shown, in accordance with some embodiments.Referring now to FIG. 2, a block diagram is shown illustrating an example of a computer system 200 including an update system 199, in accordance with some embodiments.In some embodiments, computer system 200 may include a special purpose computer system programmed to perform one or more steps of a method 300 described below with reference to FIGS. 3A through 3C.In some embodiments, the computer system 200 may be an element of one or more of the following: the vehicle 123; the server 103; the RSU 104; and the remote vehicle 124.In some embodiments, the computer system 200 may be a vehicle-side vehicle computer of a device such as one or more of the following: the vehicle 123; the server 103, the RSU 104, and the remote vehicle 124.In some embodiments, the computer system 200 may include an engine control unit, head unit, or many other processor-based computing device of the vehicle 123 or the remote vehicle 124.The computer system 200 may include one or more of the following elements, according to some examples: the update system 199; the processor 125; the communication unit 145; the sensor set 182; the DSRC-compliant GPS unit 170; the ADAS system 180; the memory 127; the ECU 183; and the FPGA 184. The components of computer system 200 are communicatively coupled by a bus 220.In the illustrated embodiment, processor 125 is communicatively coupled to bus 220 via a signal line 238. The communication unit 145 is communicatively coupled to the bus 220 via a signal line 246. The sensor set 182 is communicatively coupled to the bus 220 via a signal line 248. The DSRC-compliant GPS unit 170 is communicatively coupled to the bus 220 via a signal line 249. The ADAS system 180 is communicatively coupled to the bus 220 via a signal line 239. The memory 127 is communicatively coupled to the bus 220 via a signal line 244. The ECU 183 is communicatively coupled to the bus 220 via a signal line 241. The FPGA 184 is communicatively coupled to the bus 220 via a signal line 243.The following elements of computer system 200 have been described above with reference to FIG. 1A, such that their descriptions are not repeated herein: update system 199; processor 125 (whose description is the same as that of processor 125A); communication unit 145 (whose description is the same as that of communication unit 145A); sensor set 182; DSRC-compliant GPS unit 170; ADAS system 180; memory 127 (whose description is the same as that of memory 127A); ECU 183; and FPGA 184.The memory 127 stores any or all of the data described above with reference to FIGS. 1A to 1I and below with reference to FIGS. 3A to 3C, 4A, and 4B.In the illustrated embodiment shown in FIG. 2, the update system 199 includes a communication module 202 communicatively coupled to the bus 220. In some embodiments, components of the update system 199 may be stored in a single server or device. In some other embodiments, components of the update system 199 may be distributed and stored across multiple servers or devices. For example, some of the components of the update system 199 may be distributed across the server 103 and the vehicle 123.The communication module 202 may be software, including routines for handling communications between the update system 199 and other components of the computer system 200. In some embodiments, communication module 202 may be a set of instructions executable by processor 125 to provide the functionality described below for handling communications between update system 199 and other components of computer system 200.The communication module 202 sends and receives data to and from one or more elements of the operating environment 100 or the process 111 via the communication unit 145. For example, the communication module 202 receives or transmits, via the communication unit 145, some or all of the data described above with reference to FIGS. 1A to 1I, FIGS. 3A to 3C, and FIGS. 4A and 4B.In some embodiments, communication module 202 receives data from components of update system 199 and stores the data in memory 127. For example, the communication module 202 receives a BSM message including the BSM data 195 and stores the BSM data 195 in the memory 127.In some embodiments, communication module 202 may handle communications between components of update system 199. For example, communication module 202 may retrieve data from memory 127, which is then analyzed or processed by update system 199, as described below with reference to FIGS. 3A-3C.In some embodiments, communication module 202 may be stored in memory 127 of computer system 200 and may be accessible and executable by processor 125. Communication module 202 may be adapted for cooperation and communication with processor 125A and other components of computer system 200 via signal line 222.Referring now to FIGS. 3A through 3C, a flowchart of an example of a method 300 for making an implementation decision is shown, in accordance with some embodiments. One or more of the steps described herein for the method 300 may be performed by one or more update systems.In step 301, a function update is set for one or more ADAS systems of the ADAS system set.In step 303, system data for making an implementation decision is collected or accumulated. An implementation decision is an analysis of the system data (see, for example, FIG. 1B ) in view of the decision data (see, for example, FIG. 1G ) and the analysis data (see, for example, FIG. 1H ) to determine whether the function update is implemented via a software update or a reconfiguration of an FPGA.In step 305, a determination is made as to whether the implementation decision is made by the vehicle or server. For example, if T DO ≥ T DE, then the vehicle makes the implementation decision and the method 300 proceeds to step 307 of FIG. 3B. Otherwise, the server makes the implementation decision and the method 300 proceeds to step 306 of FIG. 3C.Reference is now made to FIG. 3B. In step 307, the update system of the vehicle makes the implementation decision based on: (1) the system data; (2) the decision data; and (3) the analysis data. If the implementation decision is to make the function update via a software update, the method 300 proceeds to step 309. If the implementation decision is to make the function update by reconfiguring the FPGA, then the method 300 proceeds to step 313. If the implementation decision is that the function update is not feasible, the method 300 proceeds to step 317.In step 309, the update system of the vehicle causes the communication unit of the vehicle to transmit a request for update data to the server via the network. The update data describes an executable file that is operable, when executed by the processor of the vehicle, to implement the function update.In step 311, a wireless message including the update data is received by the communication unit of the vehicle, and the executable file described by the update data is executed to install the function update.In step 313, the vehicle update system causes the vehicle communication unit to transmit a wireless message requesting update data, which in some embodiments is provided via a data stream describing how to reconfigure the FPGA to implement the function update, to the server via the network.In step 315, the bitstream is received by the communication unit of the vehicle and the FPGA is reconfigured by the update system based on the update data included in the bitstream.In step 317, the update system causes an electronic display, a HUD or 3D HUD of the vehicle to issue an error message.Reference is now made to FIG. 3C. In step 321, the update system of the server makes the implementation decision based on: (1) the system data; (2) the decision data; and (3) the analysis data. If the implementation decision is to make the function update via a software update, then the method 300 proceeds to step 323. If the implementation decision is to make the function update by reconfiguring the FPGA, then the method 300 proceeds to step 325. If the implementation decision is that the function update is not feasible, then the method 300 proceeds to step 327.In step 323, the server update system causes the server communication unit to transmit to the vehicle via the network update data describing an executable file that is operable, when executed by the vehicle processor, to implement the function update.In step 325, the update system of the server causes the communication unit of the server to establish a bit stream with the communication unit of the vehicle and then to transmit the update data to the communication unit of the vehicle via the bit stream.In step 327, the server update system causes the server communication unit to transmit an electronic signal (or electronic message) to the vehicle communication unit via the network, which causes the vehicle electronic display to display an error message.Referring now to FIG. 4A, a block diagram is shown illustrating an example of the BSM data 195, in accordance with some embodiments.The periodic interval for transmitting BSMs may be configurable by the user. In some embodiments, a default setting for this interval may be transmitting the BSM every 0.10 seconds or substantially every 0.10 seconds.A BSM is broadcast over the 5.9 GHz DSRC band. The DSRC range may be substantially 1000 meters. In some embodiments, the DSRC range may include a range from substantially 100 meters to substantially 1000 meters.Referring now to FIG. 4B, a block diagram illustrating an example of BSM data 195 is shown, in accordance with some embodiments.A BSM may comprise two parts. These two portions may include different BSM data 195, as shown in FIG. 4B.Portion 1 of the BSM data 195 may describe one or more of: a vehicle position; a vehicle direction; a vehicle speed; a vehicle acceleration; a vehicle steering wheel angle; and a vehicle size.A portion 2 of the BSM data 195 may include a variable set of data items selected from a list of optional items. Some of the BSM data 195 included in the BSM portion 2 is selected based on event triggers, for example, an activation of an anti-lock braking system ("ABS") BSM data 195 may trigger that is relevant to the ABS system of the vehicle.In some embodiments, some of the elements of part 2 are transmitted less often to conserve bandwidth.In some embodiments, the BSM data 195 included in a BSM includes momentary snapshot of a vehicle traveling along a roadway system.In the foregoing description, for purposes of explanation, numerous specific details have been set forth in order to provide a thorough understanding of the specification. It will be recognized, however, by those skilled in the art that the disclosure may be practiced without these specific details. In some instances, structures and devices are shown in block diagram form in order to avoid obscuring the description. For example, the present embodiments described above may be described mainly with reference to user interfaces and certain hardware. However, the present embodiments may be applied to any type of computer system that can receive data and instructions and any peripheral device that provides services.Reference in the specification to "some embodiments" or "some cases" means that a particular feature, structure, or characteristic described in connection with embodiments or cases may be included in at least one embodiment of the invention. The appearances of the phrase "in some embodiments" in various places in the specification are not necessarily all referring to the same embodiments.Some portions of the detailed descriptions that follow are presented in terms of the algorithm and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. An algorithm is here and generally considered to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulation of physical quantities. Usually, although not necessary, these quantities take the form of electrical or magnetic signals capable of being stored, transmitted, combined, compared, and otherwise manipulated. It has been found convenient at times, principally for reasons of common use, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.It should be understood, however, that all of these and similar terms are to be associated with suitable physical quantities and are merely convenient labels applied to these quantities. Unless otherwise stated, as will be apparent from the following discussion, it will be appreciated that throughout the specification discussions utilizing terms including "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system register and memory into other data similarly represented as physical quantities within the computer system memory or register, or other such information storage, transmission or display devices.The present embodiments of the specification may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purpose or may be a general purpose computer selectively activated and reconfigured by a computer program stored in the computer. Such a computer program may be recorded in a computer readable storage medium, including, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flash memories including USB sticks having a non-volatile memory, or any other type of media suitable for storing electronic instructions, each coupled to a computer system bus.The specification may take the form of some hardware integrated embodiments, some software integrated embodiments, or some embodiments that include both hardware and software elements. In such preferred embodiments, the specification is implemented in software, including, but not limited to, firmware, operating software (resident software), microcode, etc.Furthermore, the description may take the form of a computer program product accessible from a computer usable or computer readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this specification, a computer-usable or computer-readable medium may be any device capable of storing, communicating, propagating, or transporting the program for use by or in connection with the instruction execution system, apparatus, or apparatus.A data processing system suitable for storing or executing program code will include at least one processor directly or indirectly connected to memory elements through a system bus. The memory elements may include local memory deployed during actual execution of the program code, mass storage, and cache memories that provide temporary storage of at least certain program codes to reduce the number of times code must be retrieved from the mass storage during execution.Input / output devices or I / O devices (including, but not limited to, keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or using I / O controllers.Network adapters may also be coupled to the system to enable the data processing system to be coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are only a few of the currently available types of network adapters.Finally, the algorithms and displays presented herein are not inherently related to any particular computer or device. Various general purpose systems may be used with programs in accordance with the teachings described herein, or it may prove advantageous to construct specialized apparatus for performing the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the specification is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the specification described herein.The foregoing description of embodiments of the specification has been presented for purposes of illustration and description. This is not intended to be exhaustive or to limit the specification to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. It is intended that the scope of the disclosure be limited not by the detailed description, but by the claims of this application. As will be understood by those skilled in the art, the specification may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Similarly, the particular naming and partitioning of the modules, routines, features, attributes, methods, and other aspects are not mandatory or significant, and the mechanisms implementing the specification or its features may have different names, partitions, or formats. Furthermore, as will be apparent to those skilled in the art, the modules, routines, features, attributes, methods, and other aspects of the disclosure may be implemented as software, hardware, firmware, or any combination of these three. Also, wherever a component, such as a module of the specification, is implemented as software, the component may be embodied as a stand-alone program, as a portion of a larger program, as a plurality of separate programs, as a static or dynamically linked library, as a kernel loadable module, as a device driver, or in any other known manner known to those skilled in the art of computer programming now or in the future. In addition, the disclosure is in no way limited to an embodiment in any specific programming language, or to any specific operating system or environment. Accordingly, the disclosure is intended to represent and not limit the scope of the specification set forth in the following claims.The disclosure includes embodiments for implementing a function update for an advanced driver assistance system ("an ADAS system") of a vehicle. In some embodiments, the method includes the vehicle receiving a dedicated short-range communication message ("a DSRC message") on a 5.9 gigahertz band. The DSRC message includes digital data describing a driving situation of one or more other vehicles relative to the vehicle. The method includes determining, based on the driving situation described by the digital data, to implement the function update for the ADAS system by reconfiguring a field programmable gate array ("an FPGA") of the vehicle that is operable to control operation of the ADAS system. The method includes reconfiguring the FPGA of the vehicle to implement the function update such that the FPGA controls the operation of the ADAS system in such a manner that corresponds to the function update.

Claims

A method implementing a function update for an advanced driver assistance system ("an ADAS system") (180) of a vehicle (123), the method comprising: receiving (303) a dedicated short-range communication message ("a DSRC message") on a 5.9 gigahertz band, the DSRC message comprising digital data (190) describing a driving situation of one or more other vehicles (124) relative to the vehicle (123) and describing conditions of the vehicle (123); Determining, based on the driving situation described by the digital data (190), whether to implement the function update for the ADAS system (180) by reconfiguring a field programmable gate array ("an FPGA") (184) of the vehicle (123) operable to control an operation of the ADAS system (180), or to implement the function update via software; and when determining to implement the function update for the ADAS system (180) by reconfiguring the FPGA (184), reconfiguring (313; 315; 325) of the FPGA (184) of the vehicle (123) to implement the function update, such that the FPGA (184) controls the operation of the ADAS system (180) in a manner corresponding to the function update.The method of claim 1, wherein the DSRC message is a base security message ("a BSM message") and the digital data (190) is BSM data.The method of claim 1 or 2, wherein the DSRC message is transmitted to the vehicle (123) by a roadside unit ("an RSU") (104).The method of any of claims 1 to 3, wherein the digital data (190) describes a geographic location of the one or more other vehicles (124) with an accuracy of plus or minus 1.5 meters relative to an actual geographic location of the one or more other vehicles (124).The method according to any one of claims 1 to 4, wherein the FPGA (184) is an element of an electronic control unit (183) of the vehicle (123).The method of any of claims 1 to 5, wherein the FPGA (184) is reconfigured based on update data describing how to reconfigure the FPGA (184) to implement the function update.The method of any of claims 1 to 6, wherein the function update modifies functionality provided by the ADAS system (180).A system (100) comprising a vehicle (123), the vehicle (123) comprising: an advanced driver assistance system ("an ADAS system") (180); a dedicated short-range communication receiver ("a DSRC receiver") (145A); a field programmable gate array ("an FPGA") (184); and an on-vehicle vehicle computer system communicatively coupled to the ADAS system (180), the DSRC receiver (145A), and the FPGA (184), the on-vehicle vehicle computer system including non-volatile memory storing computer code that, when executed by the on-vehicle vehicle computer system, causes the on-vehicle vehicle computer system to: receive, by the DSRC receiver (145A), a dedicated short-range communication ("a DSRC") message on a 5.9 gigahertz band, the DSRC message including digital data (190) describing a driving situation of one or more other vehicles (124) relative to the vehicle (123) and describing conditions of the vehicle (123); based on the driving situation described by the digital data (190), determining whether to implement a function update for the ADAS system (180) by reconfiguring the FPGA (184) operable to control an operation of the ADAS system (180) or to implement the function update via software; and when determining to implement the function update for the ADAS system (180) by reconfiguring the FPGA (184), reconfiguring the FPGA (184) to implement the function update such that the FPGA (184) controls the operation of the ADAS system (180) in a manner corresponding to the function update.The system (100) of claim 8, wherein the DSRC message is a basic security message ("a BSM message") and the digital data (190) is BSM data.The system (100) of claim 8 or 9, wherein the DSRC message is transmitted to the vehicle (123) by a roadside unit ("an RSU") (104).The system (100) of any of claims 8 to 10, wherein the digital data (190) describes a geographic location of the one or more other vehicles (124) with an accuracy of plus or minus 1.5 meters relative to an actual geographic location of the one or more other vehicles (124).The system (100) according to any one of claims 8 to 11, wherein the FPGA (184) is an element of an electronic control unit (183) of the vehicle (123).The system (100) of any of claims 8 to 12, wherein the FPGA (184) is reconfigured based on update data describing how to reconfigure the FPGA (184) to implement the function update.The system (100) of any of claims 8 to 13, wherein the function update modifies functionality provided by the ADAS system (180).A computer program product comprising a non-transitory memory of an in-vehicle vehicle computer system of a vehicle (123) storing computer executable code that, when executed by the processor, causes the processor to: receive a dedicated short-range communication ("a DSRC") message on a 5.9 gigahertz band, the DSRC message comprising digital data (190) describing a driving situation of one or more other vehicles (124) relative to the vehicle (123) and describing conditions of the vehicle (123); based on the driving situation described by the digital data (190), determining whether to implement a function update for an advanced driver assistance system ("an ADAS system") (180) of the vehicle by reconfiguring a field programmable gate array ("an FPGA") (184) of the vehicle (123) operable to control an operation of the ADAS system (180), or to implement the function update via software; and when it is determined to implement the function update for the ADAS system ( 180) by reconfiguring the FPGA ( 184), reconfiguring the FPGA ( 184) of the vehicle ( 123) to implement the function update, so that the FPGA ( 184) controls the operation of the ADAS system ( 180) in a manner corresponding to the function update.The computer program product of claim 15, wherein the DSRC message is a basic security message ("a BSM message") and the digital data (190) is BSM data.The computer program product of claim 15 or 16, wherein the DSRC message is transmitted to the vehicle (123) by a roadside unit ("an RSU") (104).The computer program product of any of claims 15 to 17, wherein the digital data (190) describes a geographic location of the one or more other vehicles (124) with an accuracy of plus or minus 1.5 meters relative to an actual geographic location of the one or more other vehicles (124).The computer program product according to any one of claims 15 to 18, wherein the FPGA (184) is an element of an electronic control unit (183) of the vehicle (123).The computer program product of any of claims 15 to 19, wherein the FPGA (184) is reconfigured based on update data describing how to reconfigure the FPGA (184) to implement the function update.

Images