A buffer in shared memory for sensor data in the vehicle

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 A 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 additionally, 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, vehicle speed, vehicle acceleration, vehicle direction, operating characteristics of components within the vehicle, or other conditions. An example of a sensor for capturing environmental conditions is a camera, which may capture video or image data of the environment within the vehicle or the environment outside the vehicle. The video and image data may be provided from the camera as frames. Another example of a sensor for capturing environmental conditions is a microphone, which may capture audio data of the environment within the vehicle or the environment outside the vehicle.

[0003] Examples of further environmental conditions that can be monitored by 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 vehicle's brakes, the vehicle's engine, the vehicle's tires, the vehicle's transmission, the vehicle's battery level, the position of the steering wheel, the status of the vehicle's safety systems, 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 given, it is understood that in further examples, a vehicle may 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 it, processing it to produce an output, or storing it.

[0007] When a vehicle includes a large number of sensors or has sensors, such as cameras, that 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 a 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. Additionally, the transport of large amounts of sensor data can place an excessive strain on the vehicle's resources, which can 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 including 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, the 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 POSIX is mentioned in some examples, other types of operating systems are known to 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 and A sensor service, receiving an indication of interest in sensor data from a client of a first sensor of the plurality of sensors; 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 perform 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 steps. (Item 3) Item 10. The vehicle of any preceding item, 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 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; and 2. The vehicle of claim 1, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 5) The sensor service granting multiple read locks to multiple clients for read access to the first buffer; and a method executable by at least one processor to perform Item 10. The vehicle of any preceding item, 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 Acquiring information from multiple sensors from the sensor connector 2. The vehicle of claim 1, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 7) Item 10. The vehicle of any preceding item, wherein the information of the plurality of sensors from the sensor connector includes identifiers of the plurality of sensors. (Item 8) The sensor service determining an amount of buffer to allocate to the first sensor based on a subscription for the first sensor from the client; 2. The vehicle of claim 1, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 9) 10. The vehicle of claim 9, wherein the sensor service is executable by the at least one processor to deallocate a 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 includes a subscription request from the client for the vehicle described in any of the above items. (Item 11) Item 10. The vehicle of any preceding item, wherein the client includes a synthetic sensor. (Item 12) Item 10. The vehicle of any of the preceding items, 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. The vehicle of claim 1, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 14) 2. The vehicle of claim 1, wherein the sensor service and the sensor connector are within a common process space. (Item 15) Item 10. 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 refer to each of the buffers. (Item 16) 10. The vehicle of claim 9, 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 Adjusting the amount of buffer allocated to each sensor of the plurality of sensors based on one or more criteria. 2. The vehicle of claim 1, wherein the vehicle is executable by at least one processor to perform the steps of: (Item 18) A non-transitory machine-readable storage medium, the non-transitory machine-readable medium containing 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 the 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 non-transitory machine-readable medium that causes (Item 19) 10. The non-transitory machine-readable medium of claim 1, wherein granting read access to the first buffer by the client is based on a determination that the amount of 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 of 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 from the sensor connector, an indication 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 the 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 that can receive 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 explanation 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 exemplary arrangement including a vehicle, according to 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] [Figure 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 according to some examples.

[0015] [Figure 5] FIG. 5 is a flow diagram of a buffer deallocation process, according to 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. Furthermore, the drawings provide examples and / or implementations consistent with the description, but the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION OF THE INVENTION

[0017] 1 illustrates an exemplary arrangement including a vehicle 102 having a sensor service 104 according to some 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 on 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. While three hardware sensors are shown in Figure 1, it is understood that vehicle 102 can include more or fewer hardware sensors in other examples. One or more of hardware sensors 108-1, 108-2, and 108-3 can include cameras that produce image 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 on 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 sensor drivers 110-1 through 110-3 to receive sensor data from hardware sensors 108-1 through 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 may be multiple sensor connectors in the sensor service 104. Each sensor connector of the multiple sensor connectors may interact with a respective set of sensors in the vehicle 102. For example, a first sensor connector may receive sensor data for a first set of sensors, a second sensor connector may receive sensor data for a second set of sensors, and so on.

[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 refer to 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] 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 may include the same 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 and write data to the buffer. The client (e.g., 118) has read-only (RO) access to the buffer in the shared memory 106. The client can read data from the buffer but does not have the ability to write to the buffer.

[0028] As used herein, a buffer in shared memory 106 is "allocated" to a sensor when it 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. 1.

[0031] The sensor connector 112 obtains (at 202) information about sensors in the vehicle 102 that are associated with the sensor connector 112. Note that if there are multiple sensor connectors, each sensor connector may obtain information about its respective set of sensors. In some examples, the sensor connector 112 may interact with sensor drivers 110-1 through 110-3 to obtain information about hardware sensors 108-1 through 108-3 in the vehicle 102. The sensor connector 112 may also interact directly with software sensors 109 to obtain information about 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 the expected size of sensor data from the sensor.

[0032] After obtaining information about the sensors associated with the sensor connectors 112, the sensor service 104 presents (at 204) the sensor information (including the sensor identifiers) to the clients 200. The sensor connectors 112 may provide the sensor information to the buffer sharing module 116, which in turn provides the sensor information to the clients 200. In some examples, the sensor service 104 may present a list of sensors (or, more specifically, a list of sensor identifiers) to the clients 200. The sensor service 104 may provide the list of sensors to the clients 200 in response to a query from the clients 200. Alternatively, the sensor service 104 may push the list of sensors to each client. The list of sensors may be communicated to the clients 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 wishes 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 identified sensors in the list of sensors). In response to the subscription request, the buffer sharing module 116 records (at 208) a subscription directive associated with the client 200 for sensor data of the identified one or more sensors. The subscription directive can be stored, for example, in the shared memory 106 or a different memory. The subscription directive 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 the 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 sensors to the identified buffer. Note 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 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 has been written with sensor data from the identified sensor.

[0040] The threshold level of the identified buffer 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 to the threshold level with sensor data from the subscribed sensors, 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 can cause the buffer sharing module 116 to enable client (e.g., client 200) access to 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 indications recorded by the buffer sharing module 116 in response to subscription requests from the clients. Because the buffer sharing module 116 recorded the subscription indication for the client 200, the buffer sharing module 116 determines (at 222) whether the amount of buffer allowed for the client 200 to read exceeds a specified maximum amount.

[0044] The specified maximum amount for any given client can be based on the 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 the 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 time.

[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 (at 226) a read lock that allows the client 200 to read 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 on the identified buffer granted to the client 200 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, and thus 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 given time. If a client does not release the read lock on the buffer granted to the client (e.g., due to the client's misbehavior or malfunction), the client will no longer receive notification 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 to receive sensor data. The specified maximum amount of buffers may depend on how frequently the client accesses the sensor data. If a 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 an identified buffer can be accomplished using a buffer object that represents (a) a memory region in shared memory 106 for the identified buffer and (b) a read lock for the memory region. Different buffers in shared memory 106 are represented by different buffer objects (or different instances of a buffer object). The buffer objects can be made available to clients 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 the 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 clients release their read locks (by releasing the frame object or instance of the frame object that represents the given buffer). Once all of the 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 may allocate a buffer in the shared memory 106 for each sensor. The buffer allocation module 114 may adjust the amount of buffer allocated to each sensor based on one or more criteria, as described below.

[0056] Each sensor is allocated 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 allocated a buffer up to the maximum per-sensor volume threshold 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 can 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 for sensor j from a client. The subscription request may include information indicating the maximum amount of buffer 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 buffer expected to be used by the client to the maximum per-sensor volume threshold for sensor j. Thus, if client A indicates that it expects to use M buffers for sensor j and client B indicates that it expects to use N buffers for sensor j (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 for 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 buffer 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 its 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 for 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 for 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 fully utilized (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 buffer allocated to sensor j exceeds the 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 buffer 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 instruction, either a request to unsubscribe from sensor j or by closing the client's connection to the sensor service 104. Based on the unsubscribe instruction, 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 buffers 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 on 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, 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, buffer allocation module 114 exits (at 510) and does not perform further buffer deallocation for sensor j.

[0074] In an alternative example, instead of dynamically allocating and deallocating buffers for each sensor according to 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 at the startup of the sensor service 104.

[0075] A storage medium for storing machine-readable instructions may include any one or a combination of the following: a semiconductor memory device, such as a dynamic random access memory (DRAM) or static random access memory (SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM), and a flash memory or other type of non-volatile memory device; a magnetic disk, such as a fixed disk, a floppy disk, and a removable disk; another magnetic medium, including tape; an optical medium, such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. It should be noted that the instructions described above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can 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 medium or media is considered to be part of a product (or article of manufacture). A product or article of manufacture can 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, where 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 otherwise. 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-described details. It is intended that the appended claims cover such modifications and variations.

Claims

1. A vehicle, the vehicle comprising: at least one processor; A plurality of sensors; Memory and A sensor service, the sensor service comprising: receiving a subscription request for sensor data from a client for a first sensor of the plurality of sensors; allocating a plurality of buffers in the memory for the plurality of sensors; providing a first buffer of the plurality of buffers in a sensor connector that receives the sensor data from the first sensor; receiving an indication from the sensor connector that the first buffer in the memory is being written with the sensor data from the first sensor; notifying the client that the first buffer is available for reading by the client from the memory based on the subscription request from the client; granting the client a read lock for read access of the first buffer in the memory; a sensor service executable by the at least one processor to A vehicle equipped with:

2. The vehicle of claim 1 , wherein the read lock on the first buffer granted to the client blocks write access of the first buffer by the sensor connector.

3. The sensor service determining whether all read locks on the first buffer are released; enabling reuse of the first buffer upon determining that all read locks on the first buffer are released; and 3. The vehicle of claim 2, wherein the vehicle is executable by the at least one processor to:

4. The sensor service granting multiple read locks to multiple clients for read access to the first buffer; and 4. The vehicle of claim 3, wherein the determination that all read locks on the first buffer have been released comprises a determination that the plurality of clients have released the plurality of read locks.

5. The sensor service acquiring information of the plurality of sensors from the sensor connector; 10. The vehicle of claim 1, wherein the at least one processor is executable to:

6. The vehicle of 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 determining an amount of buffer to allocate to the first sensor based on a subscription for the first sensor from a client; 10. The vehicle of claim 1, wherein the at least one processor is executable to:

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

9. The vehicle of claim 1 , wherein the client comprises a synthetic sensor.

10. The vehicle of claim 1 , wherein the sensor connector is a first of a plurality of sensor connectors that receive sensor data from a set of different respective sensors.

11. 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; The vehicle of claim 1 , wherein the vehicle is executable by at least one processor to:

12. 2. The vehicle of claim 1, wherein the sensor service and the sensor connector are configured to use a same reference to refer to each buffer of the plurality of buffers, the same reference comprising a pointer or memory address common to both the sensor service and the sensor connector.

13. 2. 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 a region of the memory in which the first buffer is stored and information of the read lock for the first buffer.

14. The sensor service adjusting the amount of buffer allocated to each sensor of the plurality of sensors based on one or more criteria; 10. The vehicle of claim 1, wherein the at least one processor is executable to:

15. 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 a plurality of buffers in the vehicle's shared memory for the plurality of sensors; providing write access of a first buffer of the plurality of buffers to a sensor connector that receives the sensor data from the first sensor; receiving an indication from the sensor connector that the first buffer in the shared memory is being written with the sensor data from the first sensor; granting a read lock to the client for read access of the first buffer based on the subscription and the instruction from the client; A non-transitory machine-readable storage medium that causes

16. 20. The non-transitory machine-readable storage medium of claim 17, wherein the granting of the read access of the first buffer by the client is based on a determination that the amount of buffer granted to the client does not exceed a maximum amount.

17. 1. A method, comprising: a sensor service executing on at least one processor in the vehicle allocating a respective set of a plurality of buffers for each sensor of a plurality of sensors in the vehicle; the sensor service receiving a subscription for sensor data for a first sensor of the plurality of sensors from a client; providing a sensor connector receiving the sensor data from the first sensor with write access to a first buffer of a first set of buffers in a memory, the first set of buffers being assigned to the first sensor; the sensor service receiving an indication from the sensor connector that the first buffer in the memory is being written with the sensor data from the first sensor; the sensor service granting a shared read lock on the first buffer to the client based on the subscription and the instruction from the client; A method comprising:

Images