Buffer in shared memory for sensor data in vehicle

Abstract

The embodiment of the invention relates to a buffer in a shared memory for sensor data in a vehicle. 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 memory for the plurality of sensors. The sensor service provides a first buffer to a sensor connector for receiving sensor data from a first sensor, and receives from the sensor connector an indication that the first buffer in the memory has been written to the 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 to read from the memory by the client.

Description

Background Art

[0001] 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 the client. The client may be located within the vehicle. Alternatively or additionally, the client may be outside the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some implementations of the present disclosure are described with reference to the following figures.

[0003] Figure 1 is a block diagram of an example arrangement including a vehicle according to some examples.

[0004] Figure 2A and Figure 2B Flowcharts depicting processes for sensor services and clients according to some examples.

[0005] Figure 3 is a flow chart of a maximum amount threshold setting process according to some examples.

[0006] Figure 4 is a flow chart of a buffer allocation process according to some examples.

[0007] Figure 5 is a flow chart of a buffer release process according to some examples.

[0008] Throughout the drawings, the same reference numerals designate similar, but not necessarily identical, elements. The drawings are not necessarily drawn to scale, and the sizes of certain parts may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description. However, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

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

[0010] Examples of further environmental conditions that sensors may monitor include temperature (inside or outside the vehicle), pressure (inside or outside the vehicle), vehicle altitude, road conditions on which the vehicle is traveling, traffic conditions surrounding the vehicle, or any other environmental condition.

[0011] Examples of components that sensors may monitor include the vehicle's brakes, the vehicle's engine, the vehicle's tires, the vehicle's transmission, the vehicle's battery charge, the position of the steering wheel, the status of the vehicle's safety systems, whether seat belts are used, software in the vehicle, or any other component. Sensors may also monitor the behavior of the driver and / or occupants in the vehicle.

[0012] While examples of sensors are given, it should be noted that in further examples, the vehicle may include additional sensors or alternative sensors.

[0013] The sensor data may be used by a client, which may be located inside the vehicle and / or outside the vehicle. The client may be a program or a hardware device. In some examples, the client may include a synthetic sensor, which is software that collects sensor data from one or more sensors. The client uses the sensor data by accessing the sensor data, processing the sensor data to generate an output, or storing the sensor data.

[0014] If a vehicle includes a large number of sensors, or has sensors (e.g., cameras) that generate a relatively large amount of sensor data (e.g., image data or video data), the transmission of sensor data from the sensors to the clients may be associated with performance issues. For example, if the bandwidth for transmission from the vehicle's sensors to the clients is limited, the clients may experience delays in receiving the sensor data. As a result, the clients may not be able to process the sensor data in a timely manner to provide output based on the sensor data. In addition, the transmission of large amounts of sensor data may overburden the resources of the vehicle, which may adversely affect other operations of the vehicle.

[0015] According to some implementations of the present disclosure, a sensor service executed in a vehicle uses a shared memory model to distribute sensor data from a sensor to a client. The shared memory model uses a shared memory including a buffer for storing sensor data accessible by the client. The sensor connector receives sensor data from the sensor and writes the sensor data to the buffer in the shared memory.

[0016] Distributing sensor data of sensors to clients using a shared memory buffer avoids transferring large amounts of sensor data through transmissions associated with limited bandwidth. In some examples, an inter-process communication (IPC) interface of a portable operating system interface (POSIX) includes various types of transmissions. A first type of transmission of POSIX IPC is a relatively slow socket-based transmission. A second type of transmission of POSIX IPC includes shared memory, which enables faster communication than socket-based transmissions. Although reference is made to POSIX in some examples, it should be noted that other types of operating systems support shared memory and socket-based interfaces.

[0017] Figure 1 An example arrangement is shown 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 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 (more specifically, the buffer allocated in the shared memory 106) to distribute the sensor data provided by the sensors of the vehicle 102 to various clients. The shared memory 106 can be implemented using one or more memory devices, such as 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. Figure 1 Three hardware sensors are shown in FIG. 1 , but it should be noted that in other examples, the vehicle 102 may include a greater or lesser number of hardware sensors. One or more of the hardware sensors 108 - 1 , 108 - 2 , and 108 - 3 may include a camera that generates image data or video data.

[0020] Sensor drivers 110-1, 110-2, and 110-3 are provided for the corresponding hardware sensors 108-1, 108-2, and 108-3. The sensor drivers 110-1 to 110-3 include machine-readable instructions executed in the vehicle 102. The sensor driver is a device driver for the hardware sensor that manages the interaction with the hardware sensor. In some examples, the sensor drivers 110-1, 110-2, and 110-3 are part of the operating system (OS). In other examples, the sensor drivers 110-1, 110-2, and 110-3 are located outside the OS.

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

[0022] In accordance with Figure 1 In the example of , the sensor service 104 includes a sensor connector 112, which is coupled to the sensor drivers 110-1 to 110-3 to receive sensor data from the hardware sensors 108-1 to 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] although Figure 1 Only one sensor connector 112 is depicted, but in other examples, multiple sensor connectors may be present in the sensor service 104. Each of the multiple sensor connectors may interact with a corresponding set of sensors in the vehicle 102. For example, a first sensor connector may receive sensor data of a first set of sensors, a second sensor connector may receive sensor data of a second set of sensors, and so on.

[0024] The sensor service 104 also includes a buffer allocation module 114 and a buffer sharing module 116. The buffer allocation module 114 allocates (and possibly releases) buffers in the shared memory 106 for use by sharing sensor data with clients. The buffer sharing module 116 is used to manage the sharing of buffers by the sensor connector 112 and the client 118 to support sensor data exchange between the sensor and the client. The client 118 in the vehicle can access the sensor data in the buffer in the shared memory 106. Each client 118 may include an electronic component or program.

[0025] In some examples, each of the sensor connector 112, the buffer allocation module 114, and the buffer sharing module refers 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 located external to the sensor service 104.

[0026] In accordance with Figure 1 In the example of , the buffer allocation module 114 allocates multiple buffer sets for corresponding sensors. The buffer allocation module 114 allocates a first buffer set 122-1 to store sensor data for the hardware sensor 108-1, a second buffer set 122-2 to store sensor data for the hardware sensor 108-2, a third buffer set 122-3 to store sensor data for the hardware sensor 108-3, and a fourth buffer set 122-4. A "sensor set" may refer to a sensor or a set of multiple sensors. Different sensor sets may 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 allows the sensor connector 112 to have the right to read data from the buffer 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 cannot write to the buffer.

[0028] As used herein, a buffer in shared memory 106 is "allocated" to a sensor if the buffer is designated for storing sensor data from the sensor (but not data from another sensor, as long as the buffer remains allocated to the sensor). In some examples, buffer allocation module 114 may be able to release a buffer so that the buffer can be subsequently allocated to another sensor if necessary.

[0029] Buffer Sharing

[0030] According to some examples, Figure 2A and Figure 2B A flowchart depicting a process performed by a client 200 and a sensor service 104, the sensor service 104 including a buffer sharing module 116 and a sensor connector 112. The client 200 may be Figure 1 Client 118 in.

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

[0032] After acquiring the information of the sensor associated with the sensor connector 112, the sensor service 104 presents (at 204) the information of the sensor (including the sensor identifier) ​​to the client 200. The sensor connector 112 may provide the information of the sensor to the buffer sharing module 116, which in turn provides the information of the sensor 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 sensor list to the client 200 in response to a query from the client 200. Alternatively, the sensor service 104 may push the sensor list to each client. For example, the sensor list may be delivered to the client via a socket-based transmission (not shown).

[0033] Alternatively, in another example, the sensor list may be stored in the shared memory 106 for retrieval by the client 200. The client 200 may use the sensor list to identify one or more sensors for which the 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 sensors identified in a sensor list). In response to the subscription request, the buffer sharing module 116 records (at 208) a subscription indication associated with the client 200 for sensor data of the identified one or more sensors. The subscription indication may be stored in a memory, such as the shared memory 106 or a different memory. The subscription indication may include information identifying the client 200 and the one or more sensors of interest to the client 200. In some cases, the buffer sharing module 116 may 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 generated by a sensor subscribed by the client 200 ("subscribed sensor"), the sensor connector 112 issues (at 212) a request to the buffer sharing module 116 to request a buffer to write the sensor data of the subscribed sensor. The request for the buffer may include a sensor identifier of the subscribed sensor.

[0036] If a buffer is available for the subscribing sensor (with 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 referred to as the "identified buffer." Note that if no buffer is available for the subscribing sensor (e.g., all allocated buffers for the subscribing sensor are already in use and are currently read-locked by the client), the buffer sharing module 116 may deny the request for the buffer, and the sensor connector 112 may discard 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 any other type of reference. In some examples, the various modules of the sensor service 104 (including the buffer sharing module 116, the sensor connector 112, and the buffer allocation module 114) are located in a common process space. Therefore, all modules of the sensor service 104 can use the same reference (defined in the common process space) to reference any given buffer.

[0038] The granting of the buffer to the sensor connector 112 provides the sensor connector 112 with implicit read and write access to the identified buffer. At this point, the sensor connector 112 is able to write (at 216) the sensor data of the subscribed sensor to the identified buffer. Note that in some cases, the buffer sharing module 116 may grant multiple buffers to the sensor connector 112 for use in writing data of the subscribed sensor.

[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 accessible to the client 200. The ready indication may be responsive to any of a variety of conditions, such as (1) the identified buffer has been filled to a threshold level with sensor data, or (2) the sensor connector 112 has completed 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 may be any predefined level of the identified buffer, such as 100% full, or filled to some other percentage less than 100% (e.g., 99%, 95%, 90%, 80%, etc.). If the identified buffer is filled to the threshold level with sensor data from the subscribing sensor, the sensor connector 112 may issue a ready indication to the buffer sharing module 116.

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

[0042] The ready indication from the sensor connector 112 returns control of the identified buffer to the buffer sharing module 116, so that the buffer sharing module 116 can allow the client (e.g., client 200) to access the identified buffer. Returning control to the buffer sharing module 116 implicitly releases the read-write lock acquired by the sensor connector 112 to write the sensor data of the subscribing sensor to the identified buffer.

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

[0044] The specified maximum amount for any given client can be based on the configuration of sensor service 104, or based on how much buffer a given client has requested. For example, sensor service 104 can store configuration information that specifies the configured maximum amount of buffer to be granted to each client. Additionally, in some examples, a client can request sensor service 104 to allocate a lower maximum amount of buffer to the client that is lower than the maximum amount configured according to the configuration information.

[0045] If the buffer sharing module 116 determines (at 222) that the amount of buffer granted to the client 200 exceeds the specified maximum amount, no further read access is granted to the client 200, which means that the sensor data written to the identified buffer by the sensor connector 112 at this time will not be provided to the client 200.

[0046] However, if the buffer sharing module 116 determines (at 222) that the amount of buffer granted to the client 200 does not exceed the specified maximum amount, the buffer sharing module 116 grants (at 224) the client 200 read access to the identified buffer. The granting of read access may 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 granting of read access includes granting a read lock that allows the client 200 to read (at 226) the identified buffer. While the client 200 has the read lock on the identified buffer, the sensor connector 112 cannot use the identified buffer to write other sensor data. The read lock on the identified buffer granted to the client 200 blocks the sensor connector 112 from write access to the identified buffer.

[0047] Note, however, that it is possible for multiple clients to hold read locks on the same buffer. Therefore, a read lock is a shared lock that can be shared by multiple clients.

[0048] In response to the 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 read lock release.

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

[0050] In some examples, authorization of read access to the identified buffer can be implemented using a buffer object that represents (a) a memory region for the identified buffer in shared memory 106 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 buffer objects). For example, the buffer objects can be made available to the client 200 using an application programming interface (API) of the sensor service 104.

[0051] The buffer object contains a reference that the client 200 can use 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 the buffer object held by the client 200. When the client 200 holds the buffer object, the client 200 has a read lock on the identified buffer.

[0052] When the client 200 completes read access to 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 (such as by calling an API) to the sensor service 104 to release the buffer object. The client 200 releasing the buffer object also causes the client 200 to release the read lock on the identified buffer.

[0053] In the case where multiple clients hold a read lock on a given buffer (framework object or instance of a framework object), if not all of the multiple clients release the read lock (by releasing the framework object or instance of the framework object representing the given buffer), the buffer sharing module 116 cannot reuse the given buffer. After all of the multiple clients release the read lock on the given buffer, the buffer sharing module 116 can reuse the given buffer, such as by granting read and 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 buffers in the shared memory 106 on a per-sensor basis. As explained below, the buffer allocation module 114 may adjust the amount of buffer allocated to each sensor based on one or more criteria.

[0056] Each sensor is allocated buffers up to the maximum per-sensor amount threshold for that sensor. Note that if there are multiple sensor connectors, each sensor connector is allocated at most the maximum per-sensor connector amount of buffers for use by the sensors associated with that sensor connector.

[0057] Figure 3 is a flow chart of a maximum threshold setting process 300 for a given sensor j (where “j” is an identifier of a given sensor). The maximum 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 from a client for sensor data of sensor j. The subscription request may include information indicating the maximum amount of buffers that the client expects to use. In response to the subscription request, the buffer allocation module 114 adds (at 304) the indicated maximum amount of buffers that the client expects to use to the maximum per-sensor amount threshold for sensor j. Thus, if client A has indicated that client A expects to use M buffers for sensor j, and client B has indicated 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 amount threshold for sensor j to M+N (or the configured buffer amount limit, whichever is smaller). More generally, when the buffer allocation module 114 detects a subscription request from a client for sensor data of sensor j, the buffer allocation module 114 sets the maximum per-sensor amount threshold for sensor j to the sum of the maximum amount of buffers that the client expects to use until the configured buffer limit is reached.

[0059] The buffer allocation module 114 may also detect (at 306) an unsubscribe indication from the client for sensor j. The unsubscribe indication may be in the form of an unsubscribe request to unsubscribe from sensor j (indicating that the client is no longer interested in sensor data from sensor j). Alternatively, the unsubscribe indication is based on the client closing its connection to the sensor service 104, indicating 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 amount of maximum buffer that the client expects to use from the maximum per-sensor amount threshold for sensor j.

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

[0062] In an alternative example, the maximum per-sensor quantity threshold for each sensor may be fixed (ie, not varied).

[0063] Figure 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 buffer allocation is required for sensor j. This determination may be based on one of two situations: (1) the sensor service 104 has just started operating and has not yet allocated any buffers for sensor j, or (2) all buffers allocated for sensor j are currently in use (e.g., a client has set a read lock on the buffers). In response to determining (at 402) that an increase in buffer allocation is required for sensor j, the buffer allocation module 114 determines (at 404) whether the amount of buffer allocated to sensor j exceeds a maximum per-sensor amount threshold for sensor j.

[0065] If the amount of buffer allocated to sensor j does not exceed the maximum per-sensor amount 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 buffer(s) does not exceed the maximum per-sensor amount 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 refrains (at 408 ) from allocating any additional buffer to sensor j.

[0067] Figure 5 is a flow chart of a buffer release process 500 of the buffer allocation module 114. The buffer allocation module 114 determines (at 502) whether to trigger a buffer release for sensor j.

[0068] The first trigger for buffer release is based on the client providing an unsubscribe indication, which can be a unsubscribe request to sensor j or by closing the client's connection to the sensor service 104. Based on the unsubscribe indication, the buffer allocation module 114 can reduce the maximum per-sensor amount threshold for sensor j ("new maximum per-sensor amount threshold"), as described above with respect to Figure 3 If the amount of buffer allocated for sensor j exceeds the new maximum per-sensor amount threshold for sensor j, the first trigger is activated.

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

[0070] In response to activating the first trigger or the second trigger (which follows the "yes" branch of decision diamond 502), the buffer allocation module 114 identifies (at 504) buffers of sensor j that are not subject to read locks and have not been granted for writing to the sensor connector 112. The buffer allocation module 114 releases (at 506) the identified buffers.

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

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

[0073] If condition A or condition B is true, the buffer allocation module 114 repeats iterative tasks 504 and 506 to release another buffer for sensor j. If both condition A and condition B are false, the buffer allocation module 114 exits (at 510) and does not perform any additional buffer releases for sensor j.

[0074] In the alternative example, instead of Figure 4 The buffer allocation process 400 and Figure 5 The buffer release process 500 dynamically allocates and releases buffers for each sensor. The buffer allocation module 114 may perform fixed buffer allocation for each sensor when the sensor service 104 is started.

[0075] A storage medium for storing machine-readable instructions may include any one or a combination of the following: semiconductor memory devices, such as DRAM or SRAM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) and flash memory, or other types of non-volatile memory devices; magnetic disks, such as fixed, floppy, and removable disks; another magnetic medium including tape; optical media, such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed 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 distributed in a large system that may have multiple nodes. Such a computer-readable or machine-readable storage medium is considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any single component or multiple components that are manufactured. The storage medium may be located in the machine that runs the machine-readable instructions, or may be located at a remote site from which the machine-readable instructions can be downloaded over a network for execution.

[0076] In the present disclosure, unless the context clearly indicates otherwise, the use of the terms "a", "an" or "the" is also intended to include plural forms. In addition, the terms "comprising", "including", "comprising", "including" or "having" when used in the present disclosure specify the presence of the elements described, but do not exclude the presence or addition of other elements.

[0077] In the foregoing description, many details are set forth to provide an understanding of the subject matter disclosed herein. However, these implementations may be practiced without these details. Other implementations may include modifications and variations to the above details. The appended claims are intended to cover such modifications and variations.

Claims

1. A vehicle comprising: at least one processor; Multiple sensors; Memory; a sensor service executable by the at least one processor to: receiving, from a client, an indication of interest in sensor data 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 to a sensor connector for receiving the sensor data from the first sensor, receiving from the sensor connector an indication that the first buffer in the memory has been written with the sensor data from the first sensor, and Based on the interest indication from the client, the client is notified that the first buffer is available for reading from the memory by the client.

2. The vehicle of claim 1 , wherein the sensor service is executable by the at least one processor to: A read lock is granted to the client for read access to the first buffer in the memory. 3 . The vehicle of claim 2 , wherein a read lock of the first buffer granted to the client blocks write access to the first buffer by the sensor connector.

4. The vehicle of claim 3, wherein the sensor service is executable by the at least one processor to: determining whether all read locks on the first buffer have been released, and Based on a determination that all read locks on the first buffer have been released, reuse of the first buffer is permitted.

5. The vehicle of claim 4, wherein the sensor service is executable by the at least one processor to: granting a plurality of read locks to a plurality of clients for read access to the first buffer, 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.

6. The vehicle of claim 1 , wherein the sensor service is executable by the at least one processor to: Information of the plurality of sensors is obtained from the sensor connector. 7 . The vehicle of claim 6 , wherein the information from the plurality of sensors of the sensor connector includes a plurality of identifiers of the plurality of sensors.

8. The vehicle of claim 1 , wherein the sensor service is executable by the at least one processor to: An amount of buffer to be allocated to the first sensor is determined based on subscriptions from a plurality of clients for the first sensor.

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

10. The vehicle of claim 1, wherein the interest indication comprises a subscription request from the client.

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

12. The vehicle of claim 1, wherein the sensor connector is a first sensor connector of a plurality of sensor connectors for receiving sensor data from different corresponding sets of sensors.

13. The vehicle of claim 1 , wherein the client is a first client of a plurality of clients, and the sensor service is executable by the at least one processor to: An amount of read locks granted to the first client is limited based on a target lock amount level.

14. The vehicle of claim 1, wherein the sensor service and the sensor connector are within a common process space.

15. The vehicle of claim 14, wherein the sensor service and the sensor connector are operable to reference each of the plurality of buffers using a corresponding reference in the common process space.

16. The vehicle of claim 1 , wherein notification to the client that the first buffer is available for reading from the memory by the client includes information that the first buffer is available for access by the client to the first buffer and a read lock for the first buffer, the information including information of an area of ​​the memory in which the first buffer is stored.

17. The vehicle of claim 1, wherein the sensor service is executable by the at least one processor to: An amount of a plurality of buffers allocated to each of the plurality of sensors is adjusted based on one or more criteria.

18. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a system to: receiving, from a client, a subscription for sensor data of a first sensor of a plurality of sensors in a vehicle; allocating a plurality of buffers in a shared memory of the vehicle for the plurality of sensors, providing write access to a first buffer of the plurality of buffers to a sensor connector for receiving the sensor data from the first sensor; receiving, from the sensor connector, an indication that the first buffer in the memory has been written with the sensor data from the first sensor; as well as Based on the subscription and the indication from the client, read access to the first buffer by the client is granted.

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

20. A method comprising: allocating, by a sensor service executing on at least one processor in a vehicle, a respective set of buffers for each of a plurality of sensors in the vehicle; receiving, by the sensor service, a subscription from a client for sensor data of a first sensor among the plurality of sensors; providing a sensor connector for receiving the sensor data from the first sensor, the first sensor set being assigned to the first sensor, with write access to a first buffer in a first set of buffers in a memory; receiving, by the sensor service from the sensor connector, an indication that the first buffer in the memory has been written with the sensor data from the first sensor; as well as Based on the subscription and the indication from the client, a shared read lock on the first buffer is granted to the client by the sensor service.

Images