Bus optimization to log sensor data

The disclosure includes a system and method for optimizing a bus to log sensor data. The system includes a processor and a memory storing instructions that, when executed by the processor, cause the system to: estimate a use case of a journey of a mobile device; retrieve a set of sensor configuration parameters associated with the estimated use case; and configure one or more sensors according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters.

BACKGROUND

The specification relates to optimizing a bus to log sensor data in vehicles and other mobile devices.

Sensors in vehicles and other mobile devices may generate a relatively large amount of data that may be collected and logged over a communication bus. In some instances, a capacity of the communication bus may be insufficient to collect all sensor data generated by the sensors. As a result, data acquisition performance may be reduced.

SUMMARY

According to one innovative aspect of the subject matter described in this disclosure, a system for optimizing a bus to log sensor data includes a processor and a memory storing instructions that, when executed by the processor, cause the system to: estimate a use case of a journey of a mobile device; retrieve a set of sensor configuration parameters associated with the estimated use case; and configure one or more sensors according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters.

In general, another innovative aspect of the subject matter described in this disclosure may be embodied in methods that include: estimating a use case of a journey of a mobile device; retrieving a set of sensor configuration parameters associated with the estimated use case; and configuring one or more sensors according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters.

Other aspects include corresponding methods, systems, apparatus, and computer program products for these and other innovative aspects.

These and other implementations may each optionally include one or more of the following operations and features. For instance, the features include the mobile device includes a vehicle, the operations further include estimating the use case responsive to the vehicle being started and receiving data that indicates the journey is to be a private journey in which the one or more sensors are disabled, and the features include estimating the use case includes estimating the use case as a private use case in which the one or more sensors are disabled, the set of sensor configuration parameters indicates that each of the one or more sensors is to be disabled, and configuring the one or more sensors according to the set of sensor configuration parameters includes disabling each of the one or more sensors during the at least the portion of the journey. For instance, the features include the journey is a first journey and the operations further include determining that the private use case is ended and estimating a subsequent use case after the private use case is ended. For instance, the features include determining that the private use case is ended responsive to at least one of: completion of a particular duration of time since a start of the first journey, completion of a second journey subsequent to the first journey; or the vehicle being started twice since the start of the first journey. For instance, the operations further include receiving data that indicates the journey is to be a private journey and the features include: estimating the use case includes estimating the use case as a private use case, and the set of sensor configuration parameters indicates that a first one of the one or more sensors that generates sensor data that relates to safety logging of a user is to be enabled during the at least the portion of the journey and that others of the one or more sensors that do not generate sensor data that relates to safety logging are to be disabled during the at least the portion of the journey. For instances, the operations further include receiving data that indicates the journey is to be a private journey, and anonymizing sensor data generated by the one or more sensors during the at least the portion of the journey. For instance, the features include the mobile device is a vehicle and the set of sensor configuration parameters is tuned to a particular driver of the vehicle. For instance, the features include the estimated use case includes an estimated first use case and the operations further include: estimating multiple use cases that the mobile device may experience during the journey, the estimated use cases including the estimated first use case and each of the estimated use cases including a different one of multiple sets of sensor configuration parameters; and reconfiguring the one or more sensors according to a corresponding one of the plurality of sets of sensor configuration parameters each time an estimated current use case of the mobile device changes from one of the estimated use cases to a different one of the estimated use cases. For instance, the operations further include, during the journey: determining that the estimated use case of the journey of the mobile device has changed such that the estimated use case is an estimated preceding use case, estimating a current use case of the journey of the mobile device, the estimated current use case being different than the estimated preceding use case, retrieving a set of sensor configuration parameters associated with the estimated current use case that is different than the set of sensor configuration parameters associated with the estimated preceding use case, and reconfiguring the one or more sensors according to the set of sensor configuration parameters associated with the estimated current use case to operate during at least a second portion of the journey according to the set of sensor configuration parameters associated with the estimated current use case.

The disclosure is particularly advantageous in a number of respects. For example, the system described herein may optimize a bus to log sensor data that is relevant to a particular driver experience and/or use case that is being monitored. The bus may be optimized by only or primarily collecting sensor data that is relevant to the driver experience and/or the use case that is being monitored. For a given driver experience and/or use case, some sensor data may be more relevant or important than other sensor data. Some implementations described herein may change the configuration of the sensors that are logged, e.g., by enabling or disabling sensors and/or adjusting up or down the sampling frequency, duration of sampling time, sampling precision, compression format, and/or other parameters of the enabled sensors according to the driver experience and/or use case being monitored. Some implementations described herein may thereby reduce and/or eliminate the presence of sensor data on the bus that is not relevant to the driver experience and/or use case being monitored.

DETAILED DESCRIPTION

System Overview

FIG. 1illustrates a block diagram of some implementations of a system100in which a bus may be optimized to log sensor data. The system100includes a server102, a social network server104, a calendar server106, and a mobile device108. The mobile device108can be accessed by a user110. In the illustrated implementation, these entities of the system100may be communicatively coupled via a network112. The system100may include other servers or devices not shown inFIG. 1including, for example, a traffic server for providing traffic data, a weather server for providing weather data, and a map server for providing map data, etc.

The mobile device108inFIG. 1is illustrated by way of example. WhileFIG. 1illustrates a single mobile device108, the disclosure applies to a system architecture having one or more mobile devices108. Furthermore, althoughFIG. 1illustrates one network112coupled to the mobile device108, the server102, the social network server104, and the calendar server106, in practice one or more networks112can be connected to these entities. WhileFIG. 1includes one server102, one social network server104, and one calendar server106, the system100could include one or more servers102, one or more social network servers104, and one or more calendar servers106.

The network112can be a conventional type, wired or wireless, and may have numerous different configurations including a star configuration, token ring configuration, or other configurations. Furthermore, the network112may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), or other interconnected data paths across which multiple devices and/or entities may communicate. In some implementations, the network112may be a peer-to-peer network. The network112may also be coupled to or includes portions of a telecommunications network for sending data in a variety of different communication protocols. In some implementations, the network112includes Bluetooth® communication networks or a cellular communications network for sending and receiving data including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, wireless application protocol (WAP), e-mail, etc. In some implementations, the network112may include a global positioning system (GPS) satellite or multiple GPS satellites for providing GPS navigation to the mobile device108. The network112may be a mobile data network that may include third-generation (3G), fourth-generation (4G), long-term evolution (LTE), Voice-over-LTE (“VoLTE”) or any other mobile data network or combination of mobile data networks.

The server102can be a hardware server that includes a processor, a memory, and network communication capabilities. In the illustrated implementation, the server102is coupled to the network112via a signal line114. The server102sends and receives data to and from other entities of the system100via the network112. The server102includes storage116for storing data to provide at least some of the functionality described herein. The storage116is described below in more detail. In the illustrated implementation, the server102includes a data collection application118. The server102may execute the data collection application118to collect data from one or more mobile devices that may include the mobile device108and to write the data to and/or read the data from the storage116. The collected data can be used for any of a variety of purposes, including for behavioral, safety, and/or performance monitoring of specific mobile devices, of a group or groups of mobile devices, of specific users of the mobile devices, and/or of a group or groups of users, for generating traffic information, and/or for any other suitable purpose.

The social network server104can be a hardware server that includes a processor, a memory, and network communication capabilities. In the illustrated implementation, the social network server104is coupled to the network112via a signal line103. The social network server104sends and receives data to and from other entities of the system100via the network112. The social network server104includes a social network application105. A social network can be a type of social structure where the user110and other users may be connected by a common feature or features. Each of the common features may include relationships/connections, e.g., friendship, family, work, an interest, etc. The common features may be provided by one or more social networking systems including explicitly defined relationships and relationships implied by social connections with other online users, where the relationships form a social graph. In some examples, the social graph can reflect a mapping of these users and how they can be related.

The social network server104and the social network application105can be representative of one social network and there may be multiple social networks coupled to the network112, each having its own server, application, and social graph. For example, a first social network may be more directed to business networking, a second may be more directed to or centered on academics, a third may be more directed to local business, a fourth may be directed to dating, and others may be of general interest or a specific focus.

The calendar server106can be a hardware server that includes a processor, a memory, and network communication capabilities. In the illustrated implementation, the calendar server106is coupled to the network112via a signal line107. The calendar server106sends and receives data to and from other entities of the system100via the network112. For example, the calendar server106may send data describing a user's calendar to the server102with permission from the user.

In some implementations, the mobile device108may include a vehicle (e.g., an automobile, a bus), a bionic implant, a wearable device, a laptop computer, a tablet computer, a mobile telephone, a personal digital assistant (PDA), a mobile e-mail device, a portable game player, a portable music player, or another electronic device that is capable of accessing the network112. In some implementations, the mobile device108may include a computing device that includes a memory and a processor. In the illustrated implementation, the mobile device108is communicatively coupled to the network112via a signal line120. The user110may interact with the mobile device108via a signal line122. The user110may include a driver of the mobile device108implemented as a vehicle, or more generally a user or operator of the mobile device108.

In some implementations, the mobile device108may include a data log module124, a bus optimization module126, and storage128for storing data to provide at least some of the functionality described herein. The data log module124, the bus optimization module126, and the storage128will be described in more detail below.

In some implementations, the mobile device108may include and/or may be communicatively coupled to one or more sensors130(labeled “Sensor(s)130” in the Figures and referred to hereinafter as sensor130or sensors130). The sensor130may be coupled to the mobile device108via a signal line132. Each of the sensors130may include, but is not limited to, a navigation sensor (e.g., a global positioning system (GPS) sensor), an infrared detector, a motion detector, a thermostat, a sound detector, or any other type of sensor. For example, the mobile device108may include sensors130for measuring one or more of a current time, a location (e.g., a latitude, longitude, and altitude of a location), an acceleration of a vehicle, a velocity of a vehicle, a fuel tank level, a behavior of a driver, environmental information inside and/or outside of the vehicle, etc. The sensors130may generate sensor data describing the measurements and the sensor data may be aggregated from the mobile device108and/or from other mobile devices by the data collection application118.

The data log module124may include code and routines for logging sensor data associated with a user or a vehicle, which sensor data may be generated by the sensors130. In some implementations, the sensor data may be recorded in the storage128. The sensor data may include journey data, driver data, situation data, time synchronicity data, and/or other data as described in more detail below. In some implementations, the data log module124can be implemented using hardware including a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). In some other implementations, the data log module124can be implemented using a combination of hardware and software. The sensor data logged by the data log module124for the mobile device108may be aggregated at the server102with sensor data from other mobile devices by the data collection application118and may be stored in the storage116. The data log module124may be stored in a combination of the devices and servers, or in one of the devices or servers ofFIG. 1. The data log module124is described below in more detail with reference toFIG. 2.

The bus optimization module126may include code and routines for optimizing a bus over which the sensor data is collected and logged by the data log module124. In some implementations, the bus optimization module126can be implemented using hardware including an FPGA or an ASIC. In some other implementations, the bus optimization module126can be implemented using a combination of hardware and software. The bus optimization module126may be stored in a combination of the devices and servers, or in one of the devices or servers ofFIG. 1. The bus optimization module126is described below in more detail with reference toFIG. 3A.

Each of the storage116and the storage128can include a non-transitory storage medium that stores data for providing the functionality described herein. The storage116and/or128may include a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory devices. In some implementations, the storage116and/or128may also include a non-volatile memory or similar permanent 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 some other mass storage device for storing information on a more permanent basis.

In some implementations, the storage116stores sensor data and/or other data collected from the mobile device108and/or other mobile devices. Additionally or alternatively, the storage116may store use case templates that may be provided by the server102to the mobile device108and/or to other mobile devices. In some implementations, the storage128stores use case estimation data, sensor configuration data, sensor data, and/or other data. The sensor data stored in the storage116may include sensor data aggregated from multiple mobile devices. The use case estimation data may include, but is not limited to, sensor data, journey data, situation data, use case templates, and user profile data. The journey data may be associated with the user110and/or the mobile device108and may describe journeys previously taken by the user110and/or the mobile device108. The journey data may include data describing one or more of a start point, an end point, a departure time from the start point, an arrival time at the end point, a route, a journey duration, a direction, and other journey context data associated with each of one or more journeys taken by the user110. The use case templates may include data describing different use cases defined for different driver experiences. In some implementations, the use case templates are distributed by the server102to the mobile device108and/or to other mobile devices. The user profile data can be data describing user profiles. For example, the user profile data associated with the user110may include a user name, an e-mail address, user preferences, hobbies, interests, education, work experience, driving behavior, and other demographic data describing the user110. The sensor configuration data may include different sets of sensor configuration parameters associated with each of the use cases described by the use case templates.

In some implementations, the bus optimization module126may use one or more of the use case estimation data, the sensor configuration data, and/or other data to optimize—in the mobile device108—a bus for logging the sensor data generated by the sensors130. In some implementations, the bus optimization module126may estimate a use case of a journey of the mobile device108using the use case estimation data. The bus optimization module126may retrieve, from the sensor configuration data, a set of sensor configuration parameters associated with the estimated use case. The bus optimization module126may configure the sensors130according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters. Additionally or alternatively, the bus optimization module126may determine from the sensor data generated by the sensors130and/or from other data that the estimated use case has changed to a different estimated use case during the journey, may retrieve a corresponding set of sensor configuration parameters, and may reconfigure the one or more sensors according to the corresponding set of sensor configuration parameters to operate during at least a subsequent portion of the journey according to the corresponding set of sensor configuration parameters.

In some implementations, each of the sets of sensor configuration parameters may indicate at least one of: which of the sensors130to enable, which of the sensors130to disable, a sampling frequency of at least one of the sensors130that is enabled, a duration of time for which data from at least one of the sensors130is to be sampled, a sampling precision of at least one of the sensors130that is enabled, a compression format of sensor data generated by at least one of the sensors130that is enabled, and other sensor configuration parameters. In some implementations, configuring the sensors130according to the set of sensor configuration parameters to operate during at least a corresponding portion of the journey may include enabling at least some and/or disabling at least some of the sensors130, setting a sampling frequency of at least one of the sensors130that is enabled, setting a duration of time for which data from at least one of the sensors130is to be sampled, setting a sampling precision of at least one of the sensors130that is enabled, setting a compression format of sensor data generated by at least one of the sensors130that is enabled, and otherwise configuring the sensors130according to the retrieved set of sensor configuration parameters.

Example Data Log Module

Referring now toFIG. 2, an example of the data log module124is shown in more detail.FIG. 2is a block diagram of a computing device200that includes the data log module124, a processor202, a communication unit204, a storage206, and a memory208according to some examples. The components of the computing device200are communicatively coupled by a bus210. The bus210may include, but is not limited to, a controller area network (CAN) bus, a memory bus, a storage interface bus, a bus/interface controller, an interface bus, or the like or any combination thereof. In some implementations, the computing device200additionally includes the sensors130coupled to the bus210via a signal line211. Additionally or alternatively, the computing device200can be one of the server102and the mobile device108.

The processor202includes an arithmetic logic unit, a microprocessor, a general-purpose controller, or some other processor array to perform computations and provide electronic display signals to a display device. The processor202is coupled to the bus210for communication with the other components via a signal line212. The processor202processes 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. AlthoughFIG. 2includes a single processor202, multiple processors202may be included. Other processors, operating systems, sensors, displays, and physical configurations may be possible.

The memory208stores instructions or data that may be executed by the processor202. The memory208is coupled to the bus210for communication with the other components via a signal line214. The instructions or data may include code for performing the techniques described herein. The memory208may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory device. In some implementations, the memory208also includes a non-volatile memory or similar permanent storage 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 some other mass storage for storing information on a more permanent basis.

As illustrated inFIG. 2, the memory208stores sensor data216. The sensor data216may be generated by the sensors130and may include journey data218, driver data220, situation data222, and time synchronicity data224. The journey data218may include data describing a user's historical journeys. The driver data220may include data describing a behavior of a driver while operating a vehicle that may include the computing device200. The situation data222may include environmental data or other data describing what is happening inside and/or outside of the vehicle while it is operated. The time synchronicity data224can be data used to synchronize a device time with a universal time. For example, the time synchronicity data224can be configured to synchronize a local time associated with the vehicle with a universal time. In some implementations, a local time may be synchronized with the Coordinated Universal Time (UTC) defined by International Telecommunications Union Recommendation (ITU-R TF.460-6) according to a corresponding local time zone. In some other implementations, a local time may be synchronized by timekeeping technologies including GPS satellites and a network time protocol (NTP). The network time protocol may include a networking protocol for clock synchronization between computer systems over packet-switched variable-latency data networks. Although not illustrated inFIG. 2, the sensor data216may additionally include data generated as an aggregate of data collected from multiple journeys with the same or different use cases. The sensor data216may be collected for and/or in the context of one or more driver experiences and associated use cases.

The communication unit204transmits and receives data to and from at least one of the mobile device108, the server102, and any other entities of the system100ofFIG. 1. The communication unit204is coupled to the bus210via a signal line217. In some implementations, the communication unit204includes a port for direct physical connection to the network112ofFIG. 1or to another communication channel. For example, the communication unit204may include a universal serial bus (USB) port, a secure digital (SD) port, a category 5 cable (CAT-5) port, or similar port for wired communication with the mobile device108or the server102. In some implementations, the communication unit204includes a wireless transceiver for exchanging data with at least one of the mobile device108, the server102, and any other entities of the system100ofFIG. 1or other communication channels using one or more wireless communication methods, including IEEE 802.11, IEEE 802.16, BLUETOOTH®, or another suitable wireless communication method.

In some implementations, the communication unit204includes a cellular communications transceiver for sending and receiving data over a cellular communications network including via SMS, MMS, HTTP, direct data connection, WAP, e-mail, or another suitable type of electronic communication. In some implementations, the communication unit204includes a wired port and a wireless transceiver. The communication unit204also provides other conventional connections to the network112ofFIG. 1for distribution of files or media objects using standard network protocols including transmission control protocol/internet protocol (TCP/IP), HTTP, hypertext transfer protocol secure (HTTPS), and simple mail transfer protocol (SMTP), etc.

The storage206can be a non-transitory storage medium that stores data for providing the functionality described herein. The storage206may correspond to or be an example of the storage116and/or the storage128ofFIG. 1. The storage206may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory devices. In some implementations, the storage206also includes a non-volatile memory or similar permanent storage 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 some other mass storage for storing information on a more permanent basis. The storage206is communicatively coupled to the bus210via a signal line219. The storage206may also store data that was temporarily stored in the memory208.

In the illustrated implementation, the data log module124includes a communication module225, a journey data log module226, a driver data log module227, and a situation data log module228. The components of the data log module124are communicatively coupled to the bus210. For example, the communication module225is communicatively coupled to the bus210via a signal line229. The journey data log module226is communicatively coupled to the bus210via a signal line230. The driver data log module227is communicatively coupled to the bus210via a signal line232. The situation data log module228is communicatively coupled to the bus210via a signal line234.

The communication module225can be software including routines for handling communications between the journey data log module226, the driver data log module227, the situation data log module228, and other components of the computing device200. The communication module225sends and receives data, via the communication unit204, to and from one or more of the mobile device108, the server102, and/or other entities of the system100ofFIG. 1depending upon where the data log module124is stored. In some implementations, the communication module225receives sensor data from the journey data log module226, the driver data log module227, and/or the situation data log module228and stores the sensor data in one or more of the storage206and the memory208. In some implementations, the communication module225retrieves sensor data from the storage206or the memory208and sends the sensor data to the data collection application118ofFIG. 1.

The journey data log module226can be software including routines for aggregating journey data describing one or more journeys associated with the user110and/or the mobile device108ofFIG. 1. For example, the journey data log module226may record journey data associated with a vehicle or a user and may store the journey data in the storage206or the memory208via the communication module225. Additionally or alternatively, the journey data log module226uploads the journey data to the server102via the communication module225and the communication unit204. Additionally or alternatively, the journey data log module226sends the journey data to the bus optimization module126via at least one of the communication module225and the communication unit204.

The journey data recorded by the journey data log module226may include, but is not limited to, an identifier (ID) identifying the mobile device108(e.g., a vehicle identification number), one or more user IDs identifying one or more users associated with the mobile device108(e.g., a driver in a vehicle, a passenger in the vehicle), a start point, a destination, a journey duration, a route, a time of arrival, a time of departure, one or more points of interest along the route, and other data associated with a related journey.

The driver data log module227can be software including routines for aggregating driver data describing a behavior of a driver while operating the mobile device108. For example, the driver data log module227may record driver data associated with a vehicle or a driver and may store the driver data in the storage206or the memory208via the communication module225. Additionally or alternatively, the driver data log module227uploads the driver data to the server102via the communication module225and the communication unit204. Additionally or alternatively, the driver data log module227sends the driver data to the bus optimization module126via at least one of the communication module225and the communication unit204.

The driver data recorded by the driver data log module227may include, but is not limited to, an identifier (ID) identifying the mobile device108(e.g., a vehicle identification number), one or more user IDs identifying one or more drivers associated with the mobile device108, and data representing a behavior of the one or more drivers that may indicate interactions of the one or more drivers with one or more passengers and/or with one or more control elements of the mobile device108. The control elements of the mobile device108with which the one or more drivers may interact and for which driver data may be generated by one or more of the sensors130may include, but are not limited to, a steering wheel, a brake pedal, a gas pedal, a clutch pedal, a heating and/or air conditioning control system, and an infotainment system.

The situation data log module228can be software including routines for aggregating situation data describing an environment around or within the mobile device108and/or describing what is happening in the environment. For example, the situation data log module228may record situation data associated with a vehicle, a user, and/or a journey and may store the situation data in the storage206or the memory208via the communication module225. Additionally or alternatively, the situation data log module228uploads the situation data to the server102via the communication module225and the communication unit204. Additionally or alternatively, the situation data log module228sends the situation data to the bus optimization module126via at least one of the communication module225and the communication unit204.

The situation data recorded by the situation data log module228may include, but is not limited to, an identifier (ID) identifying the mobile device108(e.g., a vehicle identification number), one or more user IDs identifying one or more users associated with the mobile device108(e.g., a driver in a vehicle, a passenger in the vehicle), and data indicating at least one of a condition in an environment external to a vehicle (e.g., temperature, precipitation, visibility, humidity, etc.), a condition in an environment internal to the vehicle, a noise level in the environment internal to the vehicle, or other data that may indicate what is occurring around and/or within the vehicle.

Example Bus Optimization Module

Referring now toFIG. 3A, an example of the bus optimization module126is shown in more detail.FIG. 3Ais a block diagram of a computing device300that includes the bus optimization module126, a processor302, a communication unit304, a storage306, and a memory308according to some examples. The components of the computing device300are communicatively coupled by a bus310. The bus310may include, but is not limited to, a CAN bus, a memory bus, a storage interface bus, a bus/interface controller, an interface bus, or the like or any combination thereof. In some implementations, the computing device300additionally includes the sensors130coupled to the bus310via a signal line311, the data log module124coupled to the bus310via a signal line313, a privacy switch315coupled to the bus310via a signal line317, and an on/off switch319coupled to the bus310via a signal line321. Additionally or alternatively, the computing device300can be one of the server102and the mobile device108.

The privacy switch315may include one or more user interface elements with which a user can interact to activate a private mode. Activation of the private mode may include an indication by the user, e.g., through the privacy switch315, that the user desires a journey to be a private journey in which data collection is disabled and/or anonymized. The privacy switch315may include hardware, software, or a combination of hardware and software. In some implementations, the privacy switch315includes a light or other indicator that provides visual or other feedback to the user to confirm when the user has activated the private mode. The light or other indicator that provides visual or other feedback to the user may remain on while the private mode is activated and/or may be turned off when the private mode is deactivated or ends.

The on/off switch319may include one or more user interface elements with which a user can interact to turn the computing device300on and/or off. For example, the on/off switch319may include a vehicle ignition. More generally, the on/off switch319may include hardware, software, or a combination of hardware and software for turning the computing device300on and/or off.

The processor302includes an arithmetic logic unit, a microprocessor, a general-purpose controller, or some other processor array to perform computations and provide electronic display signals to a display device. The processor302is coupled to the bus310for communication with the other components via a signal line312. The processor302processes 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. AlthoughFIG. 3Aincludes a single processor302, multiple processors302may be included. Other processors, operating systems, sensors, displays, and physical configurations may be possible.

The memory308stores instructions or data that may be executed by the processor302. The memory308is coupled to the bus310for communication with the other components via a signal line314. The instructions or data may include code for performing the techniques described herein. The memory308may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory device. In some implementations, the memory308also includes a non-volatile memory or similar permanent storage 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 some other mass storage for storing information on a more permanent basis.

As illustrated inFIG. 3A, the memory308stores use case estimation data316and sensor configuration data318. The use case estimation data316may include journey data320and use case templates322. The journey data320and the use case templates322may be received from one or both of the data log module124or the server102or from some other source. The journey data320may include data describing a user's historical journeys. The use case templates322may include data describing different use cases defined for different driver experiences.

The communication unit304transmits and receives data to and from at least one of the mobile device108, the server102, and any other entities of the system100ofFIG. 1. The communication unit304is coupled to the bus310via a signal line324. In some implementations, the communication unit304includes a port for direct physical connection to the network112ofFIG. 1or to another communication channel. For example, the communication unit304may include a USB port, an SD port, a CAT-5 port, or similar port for wired communication with the mobile device108or the server102. In some implementations, the communication unit304includes a wireless transceiver for exchanging data with at least one of the mobile device108, the server102, and any other entities of the system100ofFIG. 1or other communication channels using one or more wireless communication methods, including IEEE 802.11, IEEE 802.16, BLUETOOTH®, or another suitable wireless communication method.

In some implementations, the communication unit304includes a cellular communications transceiver for sending and receiving data over a cellular communications network including via SMS, MMS, HTTP, direct data connection, WAP, e-mail, or another suitable type of electronic communication. In some implementations, the communication unit304includes a wired port and a wireless transceiver. The communication unit304also provides other conventional connections to the network112ofFIG. 1for distribution of files or media objects using standard network protocols including TCP/IP, HTTP, HTTPS, and SMTP, etc.

The storage306can be a non-transitory storage medium that stores data for providing the functionality described herein. The storage306may correspond to or be an example of the storage116and/or the storage128ofFIG. 1. The storage306may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory devices. In some implementations, the storage306also includes a non-volatile memory or similar permanent storage 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 some other mass storage for storing information on a more permanent basis. The storage306is communicatively coupled to the bus310via a signal line326. The storage306may also store data that was temporarily stored in the memory308.

In the illustrated implementation, the bus optimization module126includes a communication module328, a use case estimator module330, a retriever module332, and a sensor configurator module334. Additionally or alternatively, the bus optimization module126further includes a privacy determiner module336. The components of the bus optimization module126are communicatively coupled to the bus310. For example, the communication module328is communicatively coupled to the bus310via a signal line338. The use case estimator module330is communicatively coupled to the bus310via a signal line340. The retriever module332is communicatively coupled to the bus310via a signal line342. The sensor configurator module334is communicatively coupled to the bus310via a signal line344. The privacy determiner module336is communicatively coupled to the bus310via a signal line346.

The communication module328can be software including routines for handling communications between the use case estimator module330, the retriever module332, the sensor configurator module334, the privacy determiner module336, and other components of the computing device300. The communication module328sends and receives data, via the communication unit304, to and from one or more of the mobile device108, the server102, and/or other entities of the system100ofFIG. 1depending upon where the bus optimization module126is stored. In some implementations, the communication module328receives data from the use case estimator module330, the retriever module332, the sensor configurator module334, and/or the privacy determiner module336and stores the data in one or more of the storage306and the memory308. In some implementations, the communication module328retrieves data from the storage306or the memory308and sends the data to the use case estimator module330, the retriever module332, the sensor configurator module334, and/or the privacy determiner module336.

The use case estimator module330can be software including routines for estimating a use case of a journey of the mobile device108. For example, the use case estimator module330may use historical journey data and/or other data to estimate a journey, e.g., when the journey will occur, an endpoint of the journey, a route of the journey, and/or other associated journey context (e.g., traffic, weather, road conditions, and/or other journey context). The use case estimator330may also estimate a use case for the estimated journey based on use case templates that define use cases for one or more driver experiences. In some implementations, the use case estimator module330may estimate the use case by comparing one or more parameters and/or characteristics of the estimated journey to one or more parameters and/or characteristics of the use case templates. For example, a use case defined by a use case template may be determined as the estimated use case depending on how well the one or more parameters and/or characteristics of the estimated journey match the one or more parameters and/or characteristics of the use case template. Additionally or alternatively, the use case estimator module330may update or modify the estimated use case to an estimated current use case responsive to changes to the journey as indicated by new and/or current journey data. In these and other implementations, the use case estimator module330may estimate the current use case by comparing one or more parameters and/or characteristics of the journey as indicated by new and/or current journey data to one or more parameters and/or characteristics of the use case templates.

The driver experiences may represent or include different experiences for which it may be useful to collect data and/or may target behavior of a particular metric that may be better understood based on the collected data. The collected data may thereby be used for behavioral, safety, and/or performance monitoring relating to the driver experiences of specific mobile devices, of a group or groups of mobile devices, of specific users of the mobile devices, and/or of a group or groups of users, for generating traffic information, and/or for any other suitable purpose. Examples of driver experiences may include, but are not limited to, the effect of traffic on fuel consumption in daily commutes, the effect of changing commute time (e.g., commuting earlier or later than usually), difficulties associated with driving near school areas, the effect of traffic on braking, unusual or unsafe acceleration forces when driving above posted speed limits, and driving during and/or after abrupt weather changes. Additionally or alternatively, the driver experiences may include a private journey that a user desires to remain private by disabling and/or anonymizing data collection during the private journey.

One or more use cases may be defined for each of the driver experiences. In some implementations, multiple driver experiences may have similar use cases. Examples of use cases for the example driver experiences described previously may include, but are not limited to the following. The driver experience of the effect of traffic on fuel consumption in daily commutes may include one or more of a use case of going from home to work, a use case of going from work to home, a use case of dropping off kids at school, and a use case of picking up kids from school. The driver experience of the effect of changing commute time (e.g., commuting earlier or later than usual) may include one or more of a use case of going from home to work (or school) and a use case of going from work (or school) to home. The driver experience of difficulties associated with driving near school areas may include one or more of a use case of driving to a school from home, a use case of driving within a particular radius of the school, and a use case of driving curbside and dropping off a person near an entrance of the school. The driver experience of the effect of traffic on braking may include one or more of a use case of driving in stop-and-go traffic on the freeway, a use case of driving in heavy traffic before/during/after special events and within a particular radius of the special events, and a use case of driving in city traffic during rush hour. The driver experience of unusual or unsafe acceleration forces when driving above posted speed limits may include one or more of a use case of freeway driving during weekends, a use case of freeway exits with a radius of curvature lower than a particular threshold value, and a use case of re-recording for freeway exits that have been known to have unusual acceleration forces for other vehicles. The driver experience of driving during and/or after abrupt weather changes may include a use case of effect on speed of commute on same roads as usual commute, and a use case of effect on speed, gear, acceleration, and/or braking on journey to a snowy area from a warm area. The driver experience of a private journey may include a private use case.

In these and other implementations, the use case estimator module330may record estimated use cases in the storage306or the memory308via the communication module328. Additionally or alternatively, the use case estimator module330may download use case templates from the server102via the communication module328and the communication unit304. Additionally or alternatively, the use case estimator module330may receive use case estimation data from the storage306or the memory308via the communication module328to estimate use cases. Each estimated use case generated by the use case estimator module330may include a use case ID to identify the estimated use case.

The retriever module332can be software including routines for retrieving sets of sensor configuration parameters associated with estimated use cases. For example, the retriever module332may retrieve a set of sensor configuration parameters associated with a given estimated use case from the sensor configuration data318. In some implementations, the sensor configuration data318may be arranged in a table or other data structure in which each set of sensor configuration parameters is associated with one or more use case IDs. Accordingly, the retriever module332may use a corresponding use case ID to lookup or otherwise retrieve a corresponding set of sensor configuration parameters from the sensor configuration data318. The retriever module332may provide retrieved sets of sensor configuration parameters to the sensor configurator module334.

Non-limiting examples of sets of sensor configuration parameters for the example foregoing use cases defined for the driver experience of difficulties associated with driving near school areas are provided in Table 1.

TABLE 1Sets of sensor configuration parametersDriver experience: Difficulties associated with driving near school areasUse Case 1—Driving to a school from homeEnable:GPS at 1 hertz (Hz)Driver-facing camera at 5 HzBrake sensor at 5 HzDisable other sensorsUse Case 2—Driving within a particular radius of the schoolEnable:GPS at 0.2 HzDriver-facing camera at 3 HzBrake sensor at 10 HzVehicle front-facing camera 5 HzGas pedal position sensor at 10 HzDisable other sensorsUse Case 3—Driving curbside and dropping off a person nearan entrance of the schoolEnable:GPS at 3 HzBrake sensor at 10 HzGas pedal position sensor at 10 HzDoor sensors—upon useDisable other sensors

In the implementation of Table 1, the sets of sensor configuration parameters associated with the use cases specify different set of sensors to enable and disable. Each set of sensor configuration parameters additionally specifies a sampling frequency in hertz for some or all of the enabled sensors in the corresponding set. In use case 3, the door sensors are enabled “upon use” rather than specifying a particular sampling frequency. Table 1 is provided by way of example only and other implementations are possible for these and other use cases.

The sensor configurator module334can be software including routines for configuring the sensors130according to sets of sensor configuration parameters received from the retriever module332. For example, the sensor configurator module334may enable at least some and/or disable at least some of the sensors130, may set a sampling frequency of at least one of the sensors130that is enabled, may set a duration of time for which data from at least one of the sensors130is to be sampled, may set a sampling precision of at least one of the sensors130that is enabled, may set a compression format of sensor data generated by at least one of the sensors130that is enabled, or may otherwise configure the sensors130according to the corresponding retrieved set of sensor configuration parameters.

By configuring the sensors130according to use case-specific sets of sensor configuration parameters, the bus310may be optimized to log sensor data generated by the sensors130in a manner that may reduce and/or eliminate the presence of unnecessary sensor data on the bus310. For example, any of the sensors130that generate data that is not relevant to an estimated use case can be disabled for all or a part of a journey to reduce consumption of resources of the bus310. As another example, the sampling frequency, duration of sampling time, sampling precision, compression format, and/or other sensor configuration parameters may be adjusted up or down as appropriate for a given estimated use case to optimize the bus310for the given estimated use case.

The privacy determiner module336can be software including routines for ending a private mode activated by or through the privacy switch315. For example, the privacy determiner module336may determine that the private mode and/or a corresponding private use case of a journey is ended responsive to at least one of: completion of a particular duration of time since a start of the journey, completion of a second journey subsequent to the journey, or a vehicle being started twice since the start of the journey. If the private mode is determined to have ended when the vehicle is turned off at the end of the journey and data collection begins beginning at the second journey, then the endpoint of the journey may not be private. In some implementations, however, the privacy determiner module336may not determine that the private mode is ended until completion of the second journey or the vehicle being started twice, either or both of which may result in the endpoint of the journey remaining private. Responsive to determining that the private mode is ended, the privacy determiner module336may output a signal to turn off the privacy switch315or may otherwise deactivate the private mode.

Methods

Referring now toFIG. 3B, an example of a method350A to optimize the bus310of the computing device300ofFIG. 3Ais described. In some implementations, the use case estimator module330receives a signal from the on/off switch319indicating that a mobile device has been started or turned on, as generally denoted at352. The mobile device may include a vehicle. The use case estimator module330also receives use case estimation data316, as generally denoted at354. Responsive to the mobile device being started or turned on, the use case estimator module330estimates a use case of a journey of the mobile device based on the use case estimation data316and provides the estimated use case to the retriever module332, as denoted at356. The retriever module332retrieves, from the sensor configuration data318, a set of sensor configuration parameters associated with the estimated use case, as denoted at358. The retriever module332provides the set of sensor configuration parameters associated with the estimated use case to the sensor configurator module334, as denoted at360. The sensor configurator module334configures the sensors130according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters, as denoted at362. In some implementations, and as generally denoted at364, the method350A may further include the data log module124logging sensor data generated by at least one of the sensors130to the memory308and/or the storage306via the bus310as the sensors130operate during at least a portion of the journey according to the set of sensor configuration parameters. The method350A may optimize the bus310by configuring the sensors to only generate sensor data that is relevant to the estimated use case and to generate the sensor data at sampling frequencies, for durations of sampling time, at sampling precisions, and/or in compression formats that are relevant to the estimated use case.

Referring now toFIG. 3C, an example of another method350B to optimize the bus310of the computing device300ofFIG. 3Ais described. In some implementations, the use case estimator module330receives a signal from the on/off switch319indicating that a mobile device has been started or turned on, as generally denoted at366. The mobile device may include a vehicle. The use case estimator module330also receives use case estimation data316, as generally denoted at368. Responsive to the mobile device being started or turned on, the use case estimator module330estimates a use case of a journey of the mobile device based at least on the use case estimation data316and provides the estimated use case to the retriever module332, as denoted at370. The retriever module332retrieves, from the sensor configuration data318, a set of sensor configuration parameters associated with the estimated use case, as denoted at372. The retriever module332provides the set of sensor configuration parameters associated with the estimated use case to the sensor configurator module334, as denoted at374. The sensor configurator module334configures the sensors130according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters, as denoted at376. In some implementations, and as generally denoted at378, the method350B may further include the data log module124logging sensor data generated by at least one of the sensors130to the memory308and/or the storage306via the bus310as the sensors130operate during at least a portion of the journey according to the set of sensor configuration parameters. The method350B may optimize the bus310by configuring the sensors to only generate sensor data that is relevant to the estimated use case and to generate the sensor data at sampling frequencies, for durations of sampling time, at sampling precisions, and/or in compression formats that are relevant to the estimated use case.

In some implementations, the use case estimator module330additionally receives data from the privacy switch315indicating that a private mode has been activated and/or that the journey is to be a private journey, as denoted at380. In these and other implementations, the estimated use case may be estimated as a private use case and the associated set of sensor configuration parameters may disable all of the sensors130, may enable one or more of the sensors130that generate sensor data that relates to safety logging of a user while disabling the rest of the sensors130, and/or may anonymize sensor data by removing information from the sensor data that may identify the user. In some implementations, the privacy determiner module336determines when the private mode is ended and outputs a signal to turn off the privacy switch315and/or to deactivate the private mode, as denoted at382.

FIG. 4is a flowchart of an example method400to optimize a bus in a mobile device. The method400may be implemented, in whole or in part, by the mobile device108or the server102ofFIG. 1, the computing device200ofFIG. 2, the computing device300ofFIG. 3A, or another suitable device or system. The method400will be described in the context ofFIG. 3Afor convenience in the discussion that follows. For this and other processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, and some of the operations may be optional, combined into fewer operations, supplemented with other operations, or expanded into additional operations without detracting from the essence of the disclosed implementations.

In some implementations, the use case estimator module330retrieves401use case estimation data and estimates402a use case of a journey of a mobile device based on the use case estimation data. The retriever module332retrieves404a set of sensor configuration parameters associated with the estimated use case. The sensor configurator module334configures406one or more sensors (e.g., the sensors130) according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters.

The mobile device may include a vehicle. The method400may additionally or alternatively include the use case estimator module330estimating the use case responsive to the vehicle being started and the use case estimator module330receiving data that indicates the journey is to be a private journey in which the one or more sensors are disabled. Estimating the use case may include estimating the use case as a private use case in which the one or more sensors are disabled. The set of sensor configuration parameters may indicate that each of the one or more sensors is to be disabled. Configuring the one or more sensors according to the set of sensor configuration parameters may include disabling each of the one or more sensors during that at least the portion of the journey.

The journey may include a first journey. The method400may additionally or alternatively include the privacy determiner module336determining that the private use case is ended responsive to at last one of: completion of a particular duration of time since a start of the first journey; completion of a second journey subsequent to the first journey; or the vehicle being started twice since the start of the first journey. The method400may additionally include the use case estimator module330estimating a subsequent use case after the private use case is ended, the retriever module332retrieving a set of sensor configuration parameters associated with the estimated subsequent use case, and/or the sensor configurator module334configuring the one or more sensors according to the set of sensor configuration parameters associated with the estimated subsequent use case to operate during at least a portion of the second journey according to the set of sensor configuration parameters associated with the estimated subsequent use case.

The method400may additionally or alternatively include the use case estimator module330receiving data that indicates the journey is to be a private journey. Estimating the use case may include estimating the use case as a private use case. The set of sensor configuration parameters may indicate that a first one of the one or more sensors that generates sensor data that relates to safety logging of a user is to be enabled during the at least the portion of the journey and that others of the one or more sensors that do not generate sensor data that relates to safety logging are to be disabled during the at least the portion of the journey.

The method400may additionally or alternatively include the use case estimator module330receiving data that indicates the journey is to be a private journey. The method400may additionally or alternatively include anonymizing sensor data generated by the one or more sensors during the at least the portion of the journey. For example, the sensor data may be anonymized by removing information from the sensor data that may identify the user according to the corresponding set of sensor configuration parameters.

In some implementations, the set of sensor configuration parameters may be tuned to a particular driver of the vehicle. Accordingly, the set of sensor configuration parameters associated with a given use case may be different for one driver than for another driver, as the set of sensor configuration parameters may be tuned consistent with, e.g., different driving styles and/or driving behaviors of the drivers.

In some implementations, the estimated use case may include an estimated first use case. In these and other implementations, the method400may additionally include the use case estimator module330estimating multiple use cases that the mobile device may experience during the journey. The estimated use cases include the estimated first use case and each of the estimated use cases may include a different one of multiple sets of sensor configuration parameters. The sensor configurator module334may reconfigure the one or more sensors according to a corresponding one of the sets of sensor configuration parameters each time an estimated current use case of the mobile device changes from one of the estimated use cases to a different one of the estimated use cases.

In some implementations, the method400may additionally include one or more of the following during the journey. The use case estimator module330may determine the estimated use case of the journey of the mobile device has changed such that the estimated use case is an estimated preceding use case. The use case estimator module330may estimate a current use case of the journey of the mobile device. The estimated current use case may be different than the estimated preceding use case. The retriever module332may retrieve a set of sensor configuration parameters associated with the estimated current use case that is different than the set of sensor configuration parameters associated with the estimated preceding use case. The sensor configurator module334may reconfigure the one or more sensors according to the set of sensor configuration parameters associated with the estimated current use case to operate during at least a second portion of the journey according to the set of sensor configuration parameters associated with the estimated current use case.

Some implementations disclosed herein include a computer program product including a non-transitory computer-usable medium that includes a computer-readable program. Execution of the computer-readable program on a computer may cause the computer to perform or may cause the computer to control performance of the method400and/or variations thereof. The non-transitory computer-usable medium may include, for example, the storage128ofFIG. 1, the memory308ofFIG. 3A, and/or the storage306ofFIG. 3A. The computer-readable program may include, for example, the bus optimization module126ofFIGS. 1 and 3A. The computer may include, for example, the computing device300ofFIG. 3A.

FIG. 5is a flowchart of another example method500to optimize a bus in a mobile device. The method500may be implemented, in whole or in part, by the mobile device108or the server102ofFIG. 1, the computing device200ofFIG. 2, the computing device300ofFIG. 3A, or another suitable device or system. The method500will be described in the context ofFIG. 3Afor convenience in the discussion that follows.

In some implementations, the use case estimator module330estimates502a current use case of a journey of a mobile device. The current use case may be estimated responsive to the mobile device being started, responsive to a change in use case, or responsive to some other factor or criterion. The retriever module332retrieves504sensor configurations for the estimated current use case. For example, the retriever module332may retrieve a set of sensor configuration parameters for the estimated current use case as described herein. The sensor configurator module334configures506one or more sensors (e.g., the sensors130) according to the sensor configurations for the estimated use case. For example, the sensor configurator module334may configure the one or more sensors according to the set of sensor configuration parameters to operate during at least a portion of the journey according to the set of sensor configuration parameters. The use case estimator module330determines508if the use case is changed. For example, the use case estimator module330may listen for a pattern of use in use case estimation data, where the use case estimation data may include sensor data about the mobile device (e.g., a range of speed, brake usage, gas pedal usage, camera images, etc.), sensor data about an external environment of the mobile device (e.g., traffic data, map data, weather data), user-entered data (e.g., the user manually switches to eco-mode, overdrive mode, private mode, etc.). If the use case is determined to have changed (“Yes” at508), the method500may return to502. If the use case is determined to not have changed (“No” at508), the data log module124may collect510sensor data. From510, the method500may return to508and/or may terminate, e.g., when the mobile device is turned off.

Some implementations disclosed herein include a computer program product including a non-transitory computer-usable medium that includes a computer-readable program. Execution of the computer-readable program on a computer may cause the computer to perform or may cause the computer to control performance of the method500and/or variations thereof. The non-transitory computer-usable medium may include, for example, the storage128ofFIG. 1, the memory308ofFIG. 3A, and/or the storage306ofFIG. 3A. The computer-readable program may include, for example, the bus optimization module126ofFIGS. 1 and 3A. The computer may include, for example, the computing device300ofFIG. 3A.

Reference in the specification to “some implementations” or “some instances” means that a particular feature, structure, or characteristic described in connection with the implementations or instances can be included in at least one implementation of the description. The appearances of the phrase “in some implementations” in various places in the specification are not necessarily all referring to the same implementations.

The specification can take the form of some entirely hardware implementations, some entirely software implementations or some implementations containing both hardware and software elements. In some preferred implementations, the specification is implemented in software, which includes, but is not limited to, firmware, resident software, microcode, etc.