Buffers in shared memory for sensor data in vehicles

Abstract

To provide buffers in a shared memory for sensor data in vehicles.SOLUTION: In some examples, a sensor service receives from a client an indication of interest in sensor data of a first sensor of a plurality of sensors, and allocates buffers in a memory to the plurality of sensors. The sensor service provides a first buffer to a sensor connector that can receive the sensor data from the first sensor, and receives an indication that the sensor data from the first sensor has been written in the first buffer in the memory. Based on the indication of interest from the client, the sensor service notifies the client that the first buffer is available for reading by the client from the memory.SELECTED DRAWING: None

Description

[Background technology]

[0001] background The vehicle may include various sensors to monitor conditions within the vehicle and / or conditions outside the vehicle. Sensor data from the sensors may be provided to a client. The client may be located within the vehicle. Alternatively or in addition, the client may be outside the vehicle. Summary of the Invention [Means for solving the problem]

[0002] The sensors may include hardware sensors and / or software sensors. Examples of sensors in a vehicle include sensors that monitor any or some combination of the following: environmental conditions, the speed of the vehicle, the acceleration of the vehicle, the direction of the vehicle, the operational characteristics of components within the vehicle, or other conditions. An example of a sensor for capturing environmental conditions is a camera, which can capture video or image data of the environment within the vehicle or the environment outside the vehicle. The video and image data can be provided from the camera as frames. Another example of a sensor for capturing environmental conditions is a microphone, which can capture audio data of the environment within the vehicle or the environment outside the vehicle.

[0003] Examples of further environmental conditions that may be monitored by the sensors include temperature (inside or outside the vehicle), pressure (inside or outside the vehicle), the altitude of the vehicle, the conditions of the road on which the vehicle is traveling, traffic conditions around the vehicle, or other environmental conditions.

[0004] Examples of components that can be monitored by sensors include the brakes of a vehicle, the engine of a vehicle, the tires of a vehicle, the transmission of a vehicle, the level of a vehicle battery, the position of the steering wheel, the status of a safety system of a vehicle, whether a seat belt is being used, software within the vehicle, or other components. Sensors can also monitor the behavior of the driver and / or passengers within the vehicle.

[0005] Although examples of sensors are provided, it is understood that in further examples, a vehicle can include additional or alternative sensors.

[0006] The sensor data can be consumed by a client, which can be located within and / or outside the vehicle. The client can be a program or a hardware device. In some examples, the client can include a synthetic sensor, which is software that collects sensor data from one or more sensors. The client consumes the sensor data by accessing the sensor data, processing the sensor data to produce an output, or storing the sensor data.

[0007] When a vehicle has sensors, such as cameras, that include a large number of sensors or generate a relatively large amount of sensor data (e.g., image data or video data), the transport of the sensor data from the sensors to the client may be associated with performance issues. For example, if the transport from the vehicle's sensors to the client has limited bandwidth, the client may experience delays when receiving the sensor data. As a result, the client may not be able to process the sensor data in a timely manner to provide an output based on the sensor data. In addition, the transport of large amounts of sensor data may overtax the vehicle's resources, which may adversely affect other operations of the vehicle.

[0008] According to some embodiments of the present disclosure, a sensor service running in a vehicle uses a shared memory model for distributing sensor data from sensors to clients. The shared memory model uses a shared memory that includes a buffer for storing the sensor data accessible by the clients. A sensor connector receives sensor data from the sensors and writes the sensor data to the buffer in the shared memory.

[0009] Using shared memory buffers to distribute sensor data from sensors with clients avoids transporting large amounts of sensor data over transports associated with limited bandwidth. In some examples, a Portable Operating System Interface (POSIX) inter-process communication (IPC) interface includes various types of transports. A first type of transport for POSIX IPC is a relatively slow socket-based transport. A second type of transport for POSIX IPC includes shared memory, which allows for faster communication than socket-based transports. Although references to POSIX are made in some examples, it is known that other types of operating systems support shared memory and socket-based interfaces. The present invention provides, for example, the following items. (Item 1) A vehicle, the vehicle comprising: At least one processor; A plurality of sensors; Memory, A sensor service, receiving an indication of interest in sensor data of a first sensor of the plurality of sensors from a client; allocating buffers in memory for a plurality of sensors; providing a first one of the buffers in a sensor connector that receives sensor data from a first sensor; receiving an indication from the sensor connector that a first buffer in the memory is being written with sensor data from a first sensor; notifying the client that the first buffer is available for reading by the client from the memory based on an indication of interest from the client; a sensor service executable by at least one processor to A vehicle equipped with: (Item 2) The sensor service grants the client a read lock for read access to the first buffer in memory. The vehicle described in the above item, wherein the vehicle is executable by at least one processor to perform the above. (Item 3) 4. The vehicle of claim 1, wherein a read lock on the first buffer granted to the client blocks write access to the first buffer by the sensor connector. (Item 4) The sensor service is determining whether all read locks on the first buffer are released; enabling reuse of the first buffer based on determining that all read locks on the first buffer are released; 2. A vehicle as described in any of the preceding items, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 5) The sensor service is Granting multiple read locks to multiple clients for read access to the first buffer. and a method for determining whether a plurality of processors is available for executing the method, the method being executable by at least one processor to perform the steps of the method; 2. The vehicle of claim 1, wherein the determination that all read locks on the first buffer have been released includes a determination that multiple clients have released multiple read locks. (Item 6) The sensor service is Acquiring information from multiple sensors through a sensor connector 2. A vehicle as described in any of the preceding items, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 7) Item 2. The vehicle of any of the preceding items, wherein the information of the multiple sensors from the sensor connector includes identifiers of the multiple sensors. (Item 8) The sensor service is determining an amount of a buffer to allocate to the first sensor based on a subscription for the first sensor from the client; 2. A vehicle as described in any of the preceding items, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 9) The vehicle of any of the preceding items, wherein the sensor service is executable by the at least one processor to deallocate the buffer for the first sensor based on an unsubscribe instruction from the client or based on an amount of unused buffer for the first sensor exceeding a threshold. (Item 10) The indication of interest may include a subscription request from the client for the vehicle described in any of the preceding paragraphs. (Item 11) The vehicle of any of the preceding claims, wherein the client includes a synthetic sensor. (Item 12) 2. The vehicle of claim 1, wherein the sensor connector is a first sensor connector of a plurality of sensor connectors that receive sensor data from a set of different respective sensors. (Item 13) The client is a first client of a plurality of clients, and the sensor service Limiting the amount of read locks granted to the first client based on a target lock amount level. 2. A vehicle as described in any of the preceding items, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 14) Item 1. The vehicle of any of the preceding items, wherein the sensor service and the sensor connector are within a common process space. (Item 15) The vehicle of any of the preceding items, wherein the sensor service and the sensor connector can use respective references in a common process space to reference each of the buffers. (Item 16) 5. The vehicle of claim 1, wherein the notification to the client that the first buffer is available for reading by the client from the memory includes information usable by the client to access the first buffer, the information including an area of ​​the memory in which the first buffer is stored and information of a read lock for the first buffer. (Item 17) The sensor service is Adjusting the amount of buffer allocated to each sensor of the plurality of sensors based on one or more criteria. 2. A vehicle as described in any of the preceding items, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 18) A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a system to: receiving a subscription for sensor data from a client for a first sensor of a plurality of sensors in a vehicle; Allocating buffers in a shared memory of the vehicle for a plurality of sensors; providing write access of a first one of the buffers to a sensor connector that receives sensor data from a first sensor; receiving an indication from the sensor connector that a first buffer in the memory is being written with sensor data from a first sensor; granting read access to the first buffer by the client based on the subscription and instructions from the client; (a) A non-transitory machine-readable medium that causes (Item 19) 2. The non-transitory machine-readable medium of any preceding item, wherein granting read access to the first buffer by the client is based on a determination that the amount of the buffer granted to the client does not exceed a maximum amount. (Item 20) 1. A method, comprising: allocating a respective set of buffers for each sensor of a plurality of sensors in the vehicle by a sensor service executing on at least one processor in the vehicle; receiving, by the sensor service, a subscription for sensor data from a client for a first sensor of the plurality of sensors; providing write access to a first buffer of a first set of buffers in a memory to a sensor connector receiving sensor data from a first sensor, the first set of buffers being assigned to the first sensor; receiving, by the sensor service, an indication from the sensor connector that a first buffer in the memory is being written with sensor data from a first sensor; granting a shared read lock on the first buffer to a client by the sensor service based on the subscription and instructions from the client; A method comprising: (Summary) A buffer in a shared memory for sensor data in a vehicle is described. In some examples, a sensor service receives an indication of interest in sensor data of a first sensor of a plurality of sensors from a client and allocates a buffer in the memory for the plurality of sensors. The sensor service provides the first buffer to a sensor connector capable of receiving sensor data from the first sensor and receives an indication that the first buffer in the memory is being written with sensor data from the first sensor. Based on the indication of interest from the client, the sensor service notifies the client that the first buffer is available for reading by the client from the memory. [Brief description of the drawings]

[0010] Some embodiments of the present disclosure are described with respect to the following figures.

[0011] [Figure 1] FIG. 1 is a block diagram of an example arrangement including a vehicle, in accordance with some examples.

[0012] [Figure 2A] 2A and 2B depict flow diagrams of sensor service and client processes, according to some examples. [Figure 2B] 2A and 2B depict flow diagrams of sensor service and client processes, according to some examples.

[0013] [Diagram 3] FIG. 3 is a flow diagram of a maximum volume threshold setting process, according to some examples.

[0014] [Figure 4] FIG. 4 is a flow diagram of a buffer allocation process, in accordance with some examples.

[0015] [Diagram 5] FIG. 5 is a flow diagram of a buffer deallocation process, in accordance with some examples.

[0016] Throughout the drawings, the same reference numbers designate similar (but not necessarily identical) elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the examples shown. Moreover, the drawings provide examples and / or implementations that are consistent with the description, but the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] 1 illustrates an example arrangement including a vehicle 102 having a sensor service 104 according to certain examples of the present disclosure. The sensor service 104 is implemented using machine-readable instructions that are executable by one or more hardware processors 130 of the vehicle 102. The hardware processor may include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0018] The sensor service 104 uses the shared memory 106, and more specifically, buffers allocated in the shared memory 106, to distribute sensor data provided by sensors in the vehicle 102 to various clients. The shared memory 106 can be implemented using one or more memory devices, such as, for example, dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, flash memory devices, disk-based storage devices, or other types of memory devices.

[0019] Vehicle 102 includes hardware sensors 108-1, 108-2, and 108-3. Although three hardware sensors are shown in FIG. 1, it is understood that vehicle 102 can include more or less hardware sensors in other examples. One or more of hardware sensors 108-1, 108-2, and 108-3 can include cameras that produce image data or video data.

[0020] Sensor drivers 110-1, 110-2, and 110-3 are provided for hardware sensors 108-1, 108-2, and 108-3, respectively. Sensor drivers 110-1 through 110-3 include machine-readable instructions that execute in vehicle 102. The sensor drivers are device drivers for the hardware sensors and manage interactions with the hardware sensors. In some examples, sensor drivers 110-1, 110-2, and 110-3 are part of an operating system (OS). In other examples, sensor drivers 110-1, 110-2, and 110-3 are external to the OS.

[0021] The vehicle 102 may also include software sensors 109. The software sensors 109 are implemented with machine-readable instructions that execute on the vehicle 102. For example, the software sensors 109 may include an agent that executes in a controller or another component of the vehicle 102. In other examples, there may be more than one software sensor on the vehicle 102.

[0022] 1, the sensor service 104 includes a sensor connector 112 coupled to the sensor drivers 110-1-110-3 to receive sensor data from the hardware sensors 108-1-108-3. The sensor connector 112 is also coupled to one or more software sensors 109 to receive sensor data from the one or more software sensors 109.

[0023] 1 depicts just one sensor connector 112, in other examples, there can be multiple sensor connectors in the sensor service 104. Each sensor connector of the multiple sensor connectors can interact with a respective set of sensors in the vehicle 102. For example, a first sensor connector can receive sensor data for a first set of sensors, a second sensor connector can receive sensor data for a second set of sensors, etc.

[0024] The sensor service 104 further includes a buffer allocation module 114 and a buffer sharing module 116. The buffer allocation module 114 allocates (and possibly deallocates) buffers in the shared memory 106 for use in sharing sensor data with clients. The buffer sharing module 116 can manage the sharing of buffers by the sensor connectors 112 and clients 118 to support the exchange of sensor data between the sensors and clients. The clients 118 in the vehicle can access the sensor data in the buffers in the shared memory 106. Each client 118 can include electronic components or programs.

[0025] In some examples, the sensor connector 112, the buffer allocation module 114, and the buffer sharing module each reference machine-readable instructions that are part of the sensor service 104. In other examples, one or more of the sensor connector 112, the buffer allocation module 114, and the buffer sharing module can be external to the sensor service 104.

[0026] In the example according to Fig. 1, the buffer allocation module 114 allocates multiple sets of buffers for each sensor. The buffer allocation module 114 allocates a first set of buffers 122-1 for storing sensor data for the hardware sensor 108-1, a second set of buffers 122-2 for storing sensor data for the hardware sensor 108-2, a third set of buffers 122-3 for storing sensor data for the hardware sensor 108-3, and a fourth set of buffers 122-4. A "sensor set" can refer to one sensor or a collection of multiple sensors. Different sets of sensors can include the same amount of sensors or different amounts of sensors.

[0027] The sensor connector 112 has read-write (R / W) access to the buffer in the shared memory 106. Read-write access gives the sensor connector 112 the right to read data from the buffer and write data to the buffer. The clients (e.g., 118) have read-only (RO) access to the buffer in the shared memory 106. The clients can read data from the buffer but do not have the ability to write to the buffer.

[0028] As used herein, a buffer in the shared memory 106 is "allocated" to a sensor when that buffer is designated for use in storing sensor data from that sensor (and not from another sensor as long as the buffer remains allocated to that sensor). In some examples, the buffer allocation module 114 may be able to deallocate a buffer, if permitted, so that the buffer is free for subsequent allocation to another sensor.

[0029] Buffer Sharing

[0030] 2A and 2B depict a flow diagram of a process performed by a client 200 and a sensor service 104 including a buffer sharing module 116 and a sensor connector 112 according to some examples. The client 200 can be the client 118 of FIG.

[0031] The sensor connector 112 obtains (at 202) information of sensors in the vehicle 102 that are associated with the sensor connector 112. It should be noted that if there are multiple sensor connectors, each sensor connector may obtain information of its respective set of sensors. In some examples, the sensor connector 112 may interact with sensor drivers 110-1-110-3 to obtain information of hardware sensors 108-1-108-3 in the vehicle 102. The sensor connector 112 may also interact directly with software sensors 109 to obtain information of the software sensors 109. The sensor information obtained by the sensor connector 112 may include, for example, a sensor identifier for the sensor. Additionally, the sensor information may include size information indicating an expected size of sensor data from the sensor.

[0032] After obtaining information of the sensor associated with the sensor connector 112, the sensor service 104 presents (at 204) the sensor information (including the sensor identifier) ​​to the client 200. The sensor connector 112 may provide the sensor information to the buffer sharing module 116, which in turn provides the sensor information to the client 200. In some examples, the sensor service 104 may present a list of sensors (or, more specifically, a list of sensor identifiers) to the client 200. The sensor service 104 may provide the list of sensors to the client 200 in response to a query from the client 200. Alternatively, the sensor service 104 may push the list of sensors to each client. The list of sensors is communicated to the client via, for example, a socket-based transport (not shown).

[0033] Alternatively, in another example, the list of sensors may be stored in shared memory 106 for retrieval by client 200. Client 200 may use the list of sensors to identify one or more sensors for which client 200 would like to obtain sensor data.

[0034] The client 200 sends (at 206) a subscription request to the sensor service 104, where the subscription request identifies one or more sensors of interest to the client 200 (e.g., one or more sensors identified in the list of sensors). In response to the subscription request, the buffer sharing module 116 records (at 208) a subscription indication associated with the client 200 for the sensor data of the identified one or more sensors. The subscription indication can be stored, for example, in the shared memory 106 or a different memory. The subscription indication can include information identifying the client 200 and the one or more sensors of interest to the client 200. In some examples, the buffer sharing module 116 can send the subscription information to the sensor connector 112 so that the sensor connector 112 knows which sensors are subscribed to by the client.

[0035] When the sensor connector 112 receives (at 210) sensor data produced by a sensor to which the client 200 has subscribed (a "subscribed sensor"), the sensor connector 112 issues (at 212) a request for a buffer to write the sensor data of the subscribed sensor to the buffer sharing module 116. The request for the buffer may include a sensor identifier for the subscribed sensor.

[0036] If a buffer is available for the subscribed sensor (having a sensor identifier), the buffer sharing module 116 grants (at 214) the buffer to the sensor connector 112 for use by the sensor connector 112. This buffer is called the "identified buffer." Note that if there is no buffer available for the subscribed sensor (e.g., all allocated buffers for the subscribed sensor are in use and are currently under a read lock by the client), the buffer sharing module 116 can deny the request for a buffer and the sensor connector 112 can drop the sensor data.

[0037] The grant of the identified buffer to the sensor connector 112 includes a reference to the identified buffer. The reference may include a pointer, a memory address, or other types of references. In some examples, the modules of the sensor service 104 (including the buffer sharing module 116, the sensor connector 112, and the buffer allocation module 114) are in a common process space. As a result, all of the modules of the sensor service 104 can use the same reference (defined in the common process space) to refer to any given buffer.

[0038] Granting a buffer to the sensor connector 112 provides implicit read-write access to the identified buffer by the sensor connector 112. At this point, the sensor connector 112 can write (at 216) sensor data for the subscribed sensor to the identified buffer. It should be noted that in some examples, the buffer sharing module 116 may grant multiple buffers to the sensor connector 112 for use in writing data for the subscribed sensors.

[0039] The sensor connector 112 sends (at 218) a ready indication to the buffer sharing module 116 indicating that the sensor data written to the identified buffer is available for access by the client 200. The ready indication may correspond to any of a variety of conditions, such as, for example, (1) the identified buffer has been filled with sensor data to a threshold level or (2) the sensor connector 112 has finished writing to the identified buffer. More generally, the ready indication indicates that the identified buffer in the shared memory 106 is being written with sensor data from the identified sensor.

[0040] The identified buffer threshold level can be any predefined level of the identified buffer (e.g., 100% full or some other percentage less than 100% (e.g., 99%, 95%, 90%, 80%, etc.)). When the identified buffer is filled with sensor data for the subscribed sensors up to the threshold level, the sensor connector 112 can issue a ready indication to the buffer sharing module 116.

[0041] Alternatively, the ready indication can be based on the sensor connector 112 determining that there is no more sensor data to write to the identified buffer (even if the identified buffer has not yet filled to the threshold level).

[0042] A ready indication from the sensor connector 112 returns control of the identified buffer to the buffer sharing module 116, which may cause the buffer sharing module 116 to enable a client (e.g., client 200) to access the identified buffer. The return of control to the buffer sharing module 116 implicitly releases the read-write lock obtained by the sensor connector 112 to write sensor data for the subscribed sensors to the identified buffer.

[0043] In response to the ready indication, the buffer sharing module 116 determines (at 220) which clients are subscribed to the subscribed sensor. This determination is based on the subscription indication recorded by the buffer sharing module 116 in response to the subscription request from the client. Because the buffer sharing module 116 has recorded a subscription indication for the client 200, the buffer sharing module 116 determines (at 222) whether the amount of buffer granted to the client 200 for reading exceeds a specified maximum amount.

[0044] The specified maximum amount for any given client can be based on a configuration of the sensor service 104 or based on how many buffers are requested by a given client. For example, the sensor service 104 can store configuration information that specifies a configured maximum amount of buffers to allow per client. Additionally, in some examples, a client can request that the sensor service 104 grant the client a lower maximum amount of buffers, the lower maximum amount being lower than the configured maximum amount according to the configuration information.

[0045] If the buffer sharing module 116 determines (at 222) that the amount of buffer allowed to the client 200 exceeds a specified maximum amount, no further read access is allowed to the client 200, which means that sensor data written by the sensor connector 112 to the identified buffer cannot be made available to the client 200 at this point.

[0046] However, if the buffer sharing module 116 determines (at 222) that the amount of buffer granted to the client 200 does not exceed a specified maximum amount, the buffer sharing module 116 grants (at 224) read access to the identified buffer to the client 200. The read access grant can be part of a notification provided from the buffer sharing module 116 to the client 200 in response to a subscription request (sent at 206) from the client 200. The read access grant includes granting a read lock that allows the client 200 to read (at 226) the identified buffer. When the client 200 has a read lock on the identified buffer, the identified buffer cannot be used by the sensor connector 112 to write other sensor data. The read lock granted to the client 200 on the identified buffer blocks write access to the identified buffer by the sensor connector 112.

[0047] However, it should be noted that multiple clients can hold read locks on the same buffer, hence a read lock is a shared lock that can be shared by multiple clients.

[0048] Upon completion of the read access, the client 200 may release (at 228) the read lock. The buffer sharing module 116 receives (at 230) an indication of the release of the read lock.

[0049] By setting a specified maximum amount of buffers to grant to each client (e.g., by limiting the amount of read locks granted to a client based on a target lock amount level), the sensor service 104 can limit the portion of the shared memory 106 granted to a client at any one time. If a client does not release the read locks of the buffers granted to the client (e.g., due to the client's misbehavior or malfunction), the client will no longer receive notifications of further sensor data, resulting in such further sensor data being dropped. The specified maximum amount of buffers per client prevents one client from over-consuming the shared memory 106, which may affect the ability of other clients in receiving sensor data. The specified maximum amount of buffers may depend on how frequently the client accesses the sensor data. If the client accesses the sensor data less frequently, the client may have a higher maximum amount of buffers. In some cases, a maximum duration may be specified such that the buffer sharing module 116 can revoke the granted read access and release the read lock if the client does not release the read lock within the maximum duration.

[0050] In some examples, granting read access to the identified buffer can be accomplished using a buffer object that represents (a) a memory region in the shared memory 106 for the identified buffer and (b) a read lock for the memory region. Different buffers in the shared memory 106 are represented by different buffer objects (or different instances of the buffer object). The buffer objects may be made available to the client 200 using, for example, an application programming interface (API) of the sensor service 104.

[0051] The buffer object stores a reference that can be used by the client 200 to access the memory region (corresponding to the identified buffer). The buffer sharing module 116 grants the buffer object for the identified buffer to the client 200. The client 200 obtains a reference to the identified buffer from a buffer object that the client 200 holds. While the client 200 holds the buffer object, the client 200 has a read lock on the identified buffer.

[0052] When the client 200 completes its read access of the identified buffer, the client 200 may release the buffer object (or instance of a buffer object) granted to the client 200 by the buffer sharing module 116. Releasing the buffer object is accomplished by the client 200 issuing a request of the sensor service 104 (e.g., via a call to an API) to release the buffer object. Releasing the buffer object by the client 200 also results in the client 200 releasing the read lock on the identified buffer.

[0053] If multiple clients hold read locks (frame objects or instances of frame objects) on a given buffer, the buffer sharing module 116 cannot reuse the given buffer unless all of the multiple clients release their read locks (by releasing the frame object or instance of a frame object that represents the given buffer). Once all of the multiple clients release their read locks on the given buffer, the buffer sharing module 116 can reuse the given buffer, for example, by granting read-write access to the given buffer for writing sensor data by the sensor connector 112.

[0054] Buffer Allocation

[0055] The buffer allocation module 114 can allocate buffers in the shared memory 106 for each sensor. The buffer allocation module 114 can adjust the amount of buffer allocated to each sensor based on one or more criteria, as described below.

[0056] Each sensor is assigned a buffer up to the maximum per-sensor volume threshold for the sensor. Note that if there are multiple sensor connectors, each sensor connector is assigned a buffer up to the maximum per-sensor volume for use by the sensors associated with the sensor connector.

[0057] 3 is a flow diagram of a maximum volume threshold setting process 300 for a given sensor j, where "j" is an identifier for the given sensor. The maximum volume threshold setting process 300 may be performed by the buffer allocation module 114 of the sensor service 104.

[0058] The buffer allocation module 114 detects (at 302) a subscription request for sensor data of sensor j from a client. The subscription request may include information indicating a maximum amount of buffers expected to be used by the client. In response to the subscription request, the buffer allocation module 114 adds (at 304) the indicated maximum amount of buffers expected to be used by the client to the maximum per-sensor volume threshold for sensor j. Thus, if client A indicates that client A expects to use M buffers for sensor j and client B indicates that client B expects to use N buffers for sensor j (where M and N are positive integers that may be the same or different from each other), the buffer allocation module 114 sets the maximum per-sensor volume threshold for sensor j to M+N (or the configured buffer volume limit, whichever is smaller). More generally, when a subscription request for sensor data of sensor j from a client is detected by the buffer allocation module 114, the buffer allocation module 114 sets the maximum per-sensor volume threshold for sensor j to the sum of the indicated maximum amount of buffers expected to be used by the client (up to the configured buffer limit).

[0059] The buffer allocation module 114 may also detect (at 306) an unsubscribe indication from the client for sensor j. The unsubscribe indication can be in the form of an unsubscribe request to unsubscribe from sensor j, which indicates that the client is no longer interested in sensor data from sensor j. Alternatively, the unsubscribe indication may be based on the client closing the client's connection to the sensor service 104, which indicates that the client is no longer interested in sensor data from any sensor.

[0060] In response to the unsubscribe indication, the buffer allocation module 114 subtracts (at 308) the maximum amount of buffer expected to be used by the client from the maximum per-sensor amount threshold for sensor j.

[0061] More generally, the maximum per-sensor volume threshold for sensor j can be based on the client's subscription for sensor data of sensor j. The buffer allocation module 114 can adjust the maximum per-sensor volume threshold for sensor j based on the client's subscription for sensor data of sensor j. The adjustment of the maximum per-sensor volume threshold can be performed for each of multiple sensors in the vehicle 102.

[0062] In the alternative, the maximum per-sensor volume threshold for each sensor may be fixed (ie, unchanging).

[0063] 4 is a flow diagram of a buffer allocation process 400 of the buffer allocation module 114 of the sensor service 104. The buffer allocation process 400 determines the amount of buffer to allocate for each sensor.

[0064] For a given sensor j, the buffer allocation module 114 determines (at 402) whether an increase in the buffer allocation for sensor j is necessary. This determination can be based on one of two scenarios: (1) the sensor service 104 has just started operation and no buffers have yet been allocated to sensor j, or (2) the buffers allocated for sensor j are currently exhausted (e.g., a read lock has been placed on the buffer by a client). In response to determining (at 402) whether an increase in the buffer allocation for sensor j is necessary, the buffer allocation module 114 determines (at 404) whether the amount of buffers allocated to sensor j exceeds a maximum per-sensor amount threshold for sensor j.

[0065] If the amount of buffers allocated to sensor j does not exceed the maximum per-sensor volume threshold for sensor j, the buffer allocation module 114 allocates (at 406) one or more additional buffers to sensor j (provided that the allocation of the additional buffers does not exceed the maximum per-sensor volume threshold for sensor j).

[0066] If the amount of buffers allocated to sensor j exceeds the maximum per-sensor amount threshold for sensor j, the buffer allocation module 114 ceases (at 408) allocating additional buffers to sensor j.

[0067] 5 is a flow diagram of a buffer deallocation process 500 of the buffer allocation module 114. The buffer allocation module 114 determines (at 502) whether buffer deallocation should be triggered for sensor j.

[0068] The first trigger for buffer deallocation is based on the client providing an unsubscribe indication, either an unsubscribe request for sensor j or by closing the client's connection to the sensor service 104. Based on the unsubscribe indication, the buffer allocation module 114 may decrease the maximum per-sensor volume threshold for sensor j (the "new maximum per-sensor volume threshold"), as described above in conjunction with FIG. 3. The first trigger is activated if the volume of the buffer allocated for sensor j exceeds the new maximum per-sensor volume threshold for sensor j.

[0069] The second trigger for buffer deallocation is based on the read lock of the buffer for sensor j being released. The second trigger is activated when the amount of unused (unlocked) buffers exceeds a specified unused buffer threshold.

[0070] In response to activation of either the first trigger or the second trigger (following the “Yes” branch of decision diamond 502), the buffer allocation module 114 identifies (at 504) a buffer for sensor j that is not under a read lock and is not authorized for writing to the sensor connector 112. The buffer allocation module 114 deallocates (at 506) the identified buffer.

[0071] The buffer allocation module 114 determines (at 508) whether condition A or condition B is true. If the allocated amount of buffer for sensor j exceeds the maximum per-sensor volume threshold for sensor j, then condition A is true. If the allocated amount of buffer for sensor j does not exceed the maximum per-sensor volume threshold for sensor j, then condition A is false.

[0072] If the amount of unused buffers for sensor j exceeds a specified unused buffer threshold, then condition B is true. If the amount of unused buffers for sensor j does not exceed a specified unused buffer threshold, then condition B is false.

[0073] If either condition A or condition B is true, then the buffer allocation module 114 repeats tasks 504 and 506 again to deallocate another buffer for sensor j. If both condition A and condition B are false, then the buffer allocation module 114 exits (at 510) and does not pursue further buffer deallocation for sensor j.

[0074] In an alternative example, instead of dynamically allocating and deallocating buffers for each sensor in accordance with the buffer allocation process 400 of FIG. 4 and the buffer deallocation process 500 of FIG. 5, the buffer allocation module 114 can perform a fixed allocation of buffers for each sensor upon startup of the sensor service 104.

[0075] The storage medium for storing the machine-readable instructions may include any one or some combination of the following: semiconductor memory devices such as DRAM or SRAM, erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory or other types of non-volatile memory devices; magnetic disks such as fixed disks, floppy disks, and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. It should be noted that the instructions described above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media, possibly distributed in a larger system having multiple nodes. Such computer-readable or machine-readable storage media or media are considered to be part of a product (or article of manufacture). A product or article of manufacture may refer to any manufactured single component or multiple components. The storage medium or media can be located either within the machine that executes the machine-readable instructions or at a remote site, and the machine-readable instructions can be downloaded over a network from the remote site for execution.

[0076] In this disclosure, the terms "a," "an," or "the" are intended to include the plural forms as well, unless the context clearly dictates to the contrary. Furthermore, the terms "comprise," "including," "comprises," "having," "having," when used in this disclosure, specify the presence of stated elements but do not preclude the presence or addition of other elements.

[0077] In the preceding description, numerous details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the above details. It is intended that the appended claims cover such modifications and variations.

Claims

1. A vehicle, wherein the vehicle comprises: at least one processor; a plurality of sensors; a memory; a sensor service, wherein the sensor service is configured to: receive an indication of interest in sensor data from a first sensor among the plurality of sensors from a client; allocate a buffer in the memory for the plurality of sensors; provide a first buffer among the buffers to a sensor connector that receives the sensor data from the first sensor; receive, from the sensor connector, an indication that the first buffer in the memory is being written with the sensor data from the first sensor; notify the client that the first buffer is available for reading by the client from the memory based on the indication of interest from the client; permit the client to have a read lock for reading access to the first buffer in the memory; a sensor service executable by the at least one processor to perform the above; and the vehicle comprises the above.

2. The vehicle according to claim 1, wherein the read lock for the first buffer permitted to the client blocks write access to the first buffer by the sensor connector.

3. The sensor service is configured to: determine whether all read locks on the first buffer are released; enable reuse of the first buffer based on the determination that all read locks on the first buffer are released; The vehicle according to claim 2, wherein the sensor service is executable by the at least one processor to perform the above.

4. The sensor service is configured to: permit a plurality of read locks to a plurality of clients for reading access to the first buffer; The vehicle according to claim 3, wherein the sensor service is executable by the at least one processor to perform the above, and the determination that all read locks on the first buffer are released includes a determination that the plurality of clients have released the plurality of read locks.

5. The sensor service is configured to: acquire information of the plurality of sensors from the sensor connector The vehicle according to claim 1, which is executable by the at least one processor to perform

6. The vehicle according to claim 5, wherein the information of the plurality of sensors from the sensor connector includes identifiers of the plurality of sensors.

7. The sensor service determines an amount of buffer for assignment to the first sensor based on a subscription of the first sensor from a client The vehicle according to claim 1, which is executable by the at least one processor to perform

8. The vehicle according to claim 7, wherein the sensor service is executable by the at least one processor to deallocate the buffer for the first sensor based on an unsubscribe instruction from a client or based on an unused buffer amount for the first sensor exceeding a threshold.

9. The vehicle according to claim 1, wherein the indication of interest includes a subscription request from the client.

10. The vehicle according to claim 1, wherein the client includes a synthetic sensor.

11. The vehicle according to claim 1, wherein the sensor connector is a first sensor connector among a plurality of sensor connectors that receive sensor data from different respective sets of sensors.

12. The client is a first client among a plurality of clients, and the sensor service limits an amount of read lock permitted to the first client based on a target lock amount level The vehicle according to claim 1, which is executable by at least one processor to perform

13. The vehicle according to claim 1, wherein the sensor service and the sensor connector are within a common process space.

14. The vehicle according to claim 13, wherein the sensor service and the sensor connector can use respective references in the common process space to refer to each buffer among the buffers.

15. The notification to the client that the first buffer is available for reading by the client from the memory includes information that can be used by the client to access the first buffer, the information including an area of the memory in which the first buffer is stored and information about the read lock for the first buffer. The vehicle according to claim 1.

16. The sensor service adjusts the amount of buffer allocated to each of the plurality of sensors based on one or more criteria to be performed by the at least one processor. The vehicle according to claim 1.

17. A non-transitory machine-readable storage medium, the non-transitory machine-readable storage medium including instructions that, when executed, cause a system to receive from a client a subscription to sensor data of a first sensor among a plurality of sensors in a vehicle; allocate a buffer in a shared memory of the vehicle for the plurality of sensors; provide a write access to a first buffer of the buffers to a sensor connector that receives the sensor data from the first sensor; receive from the sensor connector an indication that the first buffer in the shared memory has been written with the sensor data from the first sensor; permit a read lock for read access to the first buffer by the client based on the subscription and the indication from the client to cause. A non-transitory machine-readable storage medium.

18. The permission of the read access to the first buffer by the client is based on a determination that the amount of buffer permitted to the client does not exceed a maximum amount. The non-transitory machine-readable storage medium according to claim 17.

19. A method, the method including a sensor service executed on at least one processor in a vehicle allocating respective sets of buffers for each of a plurality of sensors in the vehicle; the sensor service receiving from a client a subscription to sensor data of a first sensor among the plurality of sensors; To provide write access to a first buffer of a first set of buffers in a memory to a sensor connector that receives the sensor data from the first sensor, wherein the first set of buffers is assigned to the first sensor, for the sensor service to receive from the sensor connector an indication that the first buffer in the memory is being written with the sensor data from the first sensor, and for the sensor service to grant the client a shared read lock on the first buffer based on the subscription and the indication from the client comprising a method.

Images