Service and system for supporting coherent data access on a multicore controller

Abstract

Method for accessing coherent data on a controller, wherein the method comprises the following steps: Providing a first buffer (72) and a second buffer (74), each of which can be read or written; Providing an indicator (76) that indicates which is read from the first or second buffer, while the other is written to by the first or second buffer; Executing a read synchronization protocol that allows the coherent data to be read from the buffer that indicator (76) specifies as the read buffer; and Executing a write synchronization protocol that allows the coherent data to be written to the buffer that indicator (76) specifies as the write buffer, and where the coherent data to be written together are grouped into data sets.

Description

BACKGROUND OF THE INVENTIONField of the invention

[0001] The present invention relates generally to a system and method for supporting coherent data access on a multicore controller, and more particularly to a system and method that provides two buffers, an indicator, and a synchronization protocol that allows one buffer to be read while the other buffer is being written, and wherein the write and read responsibilities alternate between the two buffers. Description of related technology

[0002] Modern vehicles use various embedded electronic controllers that enhance the vehicle's performance, comfort, safety, and so on. Such controllers include engine controllers, suspension controllers, steering controllers, powertrain controllers, climate control controllers, infotainment system controllers, chassis system controllers, and so on. These controllers typically require specialized software and algorithms to perform their control functions.

[0003] The current trend for vehicle electronic controllers is to provide multiple software applications for different functions that operate on a common controller. For example, adaptive cruise control (ACC) systems, lane centering systems, stability control systems, etc. are all well known in the art and all automatically control vehicle steering and / or braking in some way. These systems often use the same sensor inputs and other variables, sometimes called global variables, which, when stored in memory, can be used by more than one software application. For example, the ACC system can read the sensor data and write the sensor data to the controller memory during its operation on the processor, and the lane centering system and other software applications can read this data when they run on the processor.Therefore, in many cases, such as these, it makes sense to run multiple software applications on the same processor.

[0004] Deploying multiple related software applications running on a common controller has obvious advantages for reducing system hardware and costs. However, running different software applications on the same processor increases the controller's complexity due to the scheduling required to run the different software applications and prevent them from interfering with each other. Such mixed-use applications running on a single processor become even more complicated when a vehicle OEM deploys additional software on a controller that already has software provided by a vendor.

[0005] In multiple software applications and / or multi-core computing environments, a problem can arise when one or more software execution applications attempt concurrent operations on the same critical resources. For example, if the software applications attempt concurrent access to a shared data entry that needs to be automatically updated, a race situation can occur, which in turn can cause a program crash. Synchronization procedures are used to prevent such situations. Common synchronization techniques use locking mechanisms or lock-free mechanisms to provide software applications with access to critical resources, preventing race situations or similar problems.

[0006] Locking mechanisms use a method that allows only one software application at a time to acquire a lock and subsequently perform processing operations on a critical resource. When a software application holds a lock on a critical resource, other software applications attempting to access the critical resource are suspended and placed in a queue. Once the lock is released, the next software application at the front of the queue obtains the lock and is allowed to continue processing operations. Although the lock synchronization approach discussed above prevents race conditions, the necessary suspension of software applications slows processing. In addition, if a software application that holds a lock fails to terminate processing properly, the program may become unresponsive.

[0007] Another well-known technique, commonly referred to as lock-free synchronization, ensures that only one software application can update a critical resource. If a second software application attempts an update while a first software application is updating the critical resource, the second software application's attempt fails. If the second software application fails, it restarts the update attempt after the first software application completes the update for the critical resource. Although lock-free synchronization can provide better execution performance than lock synchronization, it cannot always be implemented for certain critical resources.

[0008] Other known approaches, such as those without waiting, require excessive memory and require at least three copies of the records.

[0009] US 7,657,673 B2 relates to a data transfer control device that transfers a large amount of data quickly and sequentially. The device has three buffers used as WR (write) buffers, intermediate buffers, and RD (read) buffers. To send data sequentially, the data transfer control device switches the buffers in one of the following three ways (A), (B), and (C), using determination flags that indicate whether the buffers store effective data (data not yet referenced).A buffer control device switches (A) the WR buffer and the RD buffer when a WR buffer effectiveness flag 33 is on and an intermediate buffer effectiveness flag 34 and an RD buffer effectiveness flag 35 are off, (B) the WR buffer and the intermediate buffer when the WR buffer effectiveness flag 33 and the RD buffer effectiveness flag 35 are on and the intermediate buffer effectiveness flag 34 is off, and (C) the intermediate buffer and the RD buffer when the intermediate buffer effectiveness flag 34 is on and the RD buffer effectiveness flag 35 is off.

[0010] US 2010 / 0 125 695 A1 relates to a flash memory storage system comprising at least one RAID controller, a plurality of flash memory cards electrically connected to the RAID controller, and a cache memory electrically connected to the RAID controller and shared by the RAID controller and the flash memory cards. The cache memory efficiently increases system performance. The storage system may comprise multiple RAID controllers to form a nested RAID architecture.

[0011] US 2012 / 0 140 861 A1 relates to a method for time synchronization in an unsynchronized vehicle control area network system. A master control unit receives a global time from a time synchronization source. The master control unit estimates a respective time delay in the transmission of messages by electronic control units on each controller area network bus. The time delay is the difference between the time at which a message is generated by a corresponding electronic control unit for transmission on a corresponding controller area network bus and the time at which the message is transmitted on the corresponding controller area network bus. The total time is adjusted for each individual controller area network bus based on the estimated time delays associated with each individual controller area network bus.Global time messages from the main control unit are transmitted to each electronic control unit containing the adjusted global times for an associated network bus of the control area.

[0012] US 5,727,233 A relates to a data transfer mechanism for a serial interface that allows for precise control of data transfer, eliminating the need for significant buffering. The data transfer mechanism also allows for flexible data transfer in either byte mode or burst mode to support various telecommunications devices with different capabilities and data rates, and minimizes host involvement in the data transfer process. SUMMARY OF THE INVENTION

[0013] The following disclosure describes a system and method for accessing coherent data on a controller. The system and method include a first buffer and a second buffer, each of which can be read from or written to, and an indicator indicating which of the first or second buffer is being read from and the other of the first or second buffer is being written to. The system and method also include a read synchronization protocol that allows the coherent data to be read from the buffer that the indicator indicates is the read buffer and a write synchronization protocol that allows the coherent data to be written to the buffer that the indicator indicates is the write buffer.

[0014] Additional features of the present invention will become apparent from the following description and the appended claims when viewed in conjunction with the accompanying drawings.

[0015] Against the background of this prior art, the object of the present disclosure is to provide a method and a system which are each suitable for enriching the prior art.

[0016] The problem is solved by the features of the independent claims. The subordinate claims and the dependent claims each contain optional developments of the disclosure.

[0017] The object is then achieved by a method for accessing coherent data on a controller having the features of claim 1.

[0018] Another solution provides a system for accessing coherent data on a controller having the features of claim 7. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] They show: Fig. 1 a mapping of coherent data to be updated together, i.e. coherently by the same executable provider element; Fig. 2 shows a diagram of a system comprising two buffers and an indicator; Fig. 3 a flowchart of a synchronization protocol for a read section of the Fig. 2 shown system; Fig. 4 a flowchart of a synchronization protocol for a write section of the Fig. 2 shown system; Fig. 5 a diagram of a specific executable software element R1, which the system consists of Fig. 2 used; Fig. 6 a time axis showing the executable software element R1 from Fig. 5 over time and another executable software element R2 attempting to read the coherent data provided by R1; Fig. 7 another time axis showing the executable software element R1 and the second executable software element R2 over time; and Fig. 8 another timeline showing the executable software elements R1 and R2 over time. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] The following discussion of embodiments of the invention relating to a system and method for supporting coherent data access on a multicore controller is merely exemplary in nature and is in no way intended to limit the invention or its applications or uses. Although a vehicle application is discussed, for example, the system and method described herein may be used in any computing environment.

[0021] Fig. 1 is an illustration of coherent data 10 to be updated together by the same executable or software application. As used herein, the term "executable" encompasses a small executable software component or software function. The data group 12, comprising related data 14, 16, and 18, is to be updated such that the data 14, 16, and 18 are updated together (i.e., coherently) by the same provider executable Ra, represented by box 50. For example, the data 14, 16, and 18 may represent X-, Y-, and Z-axis position data from a vehicle's global positioning satellite (GPS). The data group 20, which includes the related data 22 and 24, is to be updated such that the data 22 and 24 are updated together by the same executable provider element represented by the box 52.For example, data 22 and 24 may represent the position of an engine cylinder and the position of a camshaft phase. Many different coherent data groups may be present in a vehicle's electronic control unit (ECU), as will be apparent to one skilled in the art. Data group 30 includes related data 32 and 34, which are to be updated together by the same executable provider element represented by box 56, and data group 40 includes related data 42 and 44, which are to be updated together by the same executable provider element represented by box 54.

[0022] The respective data 14, 16, 18, 22, 24, 32, 34, 42, and 44 are basic or atomic building blocks of executable programs. Although data groups 12, 20, 30, and 40 are intended to be written together, data 14, 16, 18, 22, 24, 32, 34, 42, and 44 can be read together according to different groups. In box 50, data 14, 16, and 18 are all written or updated together. For example, if data 14, 16, and 18 represent the X, Y, and Z coordinates of a vehicle, e.g., longitude, latitude, and altitude, the vehicle's location cannot be accurately determined if data 16 and 18 have been updated but data 14 has not. Thus, in this case, it is important that data 14, 16, and 18 are updated together. In another example, in box 52, data 22 and 24 are written together, and data 32 is read alone for a specific application.In another example, in box 54, data 34 is read alone, and data 42 and 44 are written by a particular application. In another example, in box 56, data 14, 16, and 22 are read together, and data 32 and 34 are written together by a particular application. The data 14 and 16 read by the provider executable in box 56 must be coherent, meaning that 14 and 16 read by the provider executable in box 56 must be coherently updated by the provider executable in box 50 at an earlier time, such as the vehicle's longitude and latitude coordinates discussed previously.In another example, in box 58, data 16 and 18 are read together and must be coherently updated by the provider executable in box 50, data 24 is read alone, and data 42 and 44 are read together after being coherently updated by the provider executable in box 54. Examples 50, 52, 54, 56, and 58 illustrate that read coherence may vary within a computing environment. Furthermore, different executables may read different versions of coherent data. For example, the data 16 in box 56 may not be the same data 16 read in box 58.Thus, the executable elements can be executed in truly parallel using scattered data in memory without requiring the use of lock synchronization or lock-free synchronization techniques known in the art, thus avoiding the problems associated with these approaches and identified previously.

[0023] Lock synchronization, which is known in the art and discussed previously, requires lock synchronization for data access. In this application, locking the operating system (OS) scheduler is proposed to synchronize the protocols described below. Locking the OS scheduler is intended to prevent the current software execution from being preempted by a higher-priority OS task in the same core. This is intended to ensure that read or write access to the coherent data can be performed as quickly as possible.

[0024] Fig. Figure 2 is an illustration of a system 70 that allows data groups 12, 20, 30, and 40 to be written together in a manner that is fast and reliable, does not require large amounts of memory, and uses two buffers. The system 70 includes a first buffer 72, a second buffer 74, and an indicator 76. The indicator 76 indicates which of the buffers 72 and 74 is to be read. When an executable reads Rr, the executable determines which of the buffers 72 or 74 the indicator 76 indicates is the buffer to read from. The executable reads the desired coherent data from the specified buffer 72 or 74. When an executable writes Rw, the executable determines which of the buffers 72 or 74 the indicator 76 indicates to read and writes to the buffer 72 or 74 that the indicator 76 does not indicate or point to.In other words, the indicator always points to the read buffer, so the other buffer is implicitly specified as the write buffer. A synchronization protocol, described below, is used in combination with buffers 72 and 74, one for reading and the other for update / write, and indicator 76 allows system 70 to utilize a single write element, which is a widely used standard practice for safety-critical software applications, thereby keeping costs low while providing updated core data without the delay of locking mechanisms, latency, expensive components, or the risk of executable element failures, as previously described.

[0025] Back to Fig. 2, at time t0, shown at point 82, buffer 74 is indicated by indicator 76 as the buffer to be read from, as shown by arrow 78. Buffer 72 is indicated by indicator 76 as the buffer to be written to or updated, as shown by dashed arrow 80. At time t1, shown at point 84, writing to buffer 72 is complete, and indicator 76 toggles. Thus, indicator 76 points to buffer 72 as the buffer to be read from, as shown by arrow 78, while buffer 74 is indicated as the buffer to be written to. At time t2, shown in point 86, the indicator has switched again so that buffer 74 has arrow 78 pointing to buffer 74 as the read buffer, while buffer 72 is indicated by indicator 76 as the write buffer, as shown by dashed arrow 80.In this way, the coherent data is never blocked by the executable elements, eliminating the risk of coherent data being read when only partially updated. Thus, the system 70 provides a single write operation at a time during operation, has the capability of multiple parallel read operations, does not require global (i.e., multi-core) scheduling control, and accesses to the coherent data can occur at different operating system cadence frequencies and on different cores.

[0026] Fig. 3 is a flowchart of a synchronization protocol or algorithm 90 for the read portion of system 70 that operates to prevent parallel access by indicator 76 to different cores or executables. At box 92, the host core's operating system (OS) scheduling program (for host core only), i.e., the core on which the current code is executing, is locked to ensure preemption by a higher priority work step. At box 94, indicator 76 is stored locally in the read executable to prevent corruption due to the indicator 76 switching process described previously. Then, the coherent data in box 96 is read from the specified read buffer. At decision diamond 98, the algorithm checks whether indicator 76 has switched to a different buffer.If indicator 76 now points to a different buffer, this means that the just-read buffer became a write buffer at some point during the previous read access 96, so the just-read data may not be coherent. If indicator 76 has toggled, the data must be read again. The algorithm returns to box 94 and stores the indicator locally again, providing the most recently updated coherent data. If, at decision diamond 98, indicator 76 has not switched buffers since the indicator was stored locally in box 94, the coherence of the data read is guaranteed. The OS control program is released, meaning that a coherent data read access has been completed on the host core at box 100.

[0027] Fig. 4 is a flowchart of a synchronization protocol or algorithm 110 for the write portion of the previously described system 70. In box 112, the host core's OS handler is locked to prevent preemption by a higher priority operation. In box 114, the coherent data is written to the buffer indicated by indicator 76 as the write buffer. In box 116, indicator 76 toggles to indicate the updated data as the read buffer because a new write operation has just completed in box 114. In box 118, the OS handler on the host core is enabled. Buffers 72 and 74 toggle, as previously described with reference to Fig. 2, using algorithms 90 and 110 of read buffer and write buffer. Write algorithm 110 is simpler than read algorithm 90 because write algorithm 110 does not have to worry about the read process. Read algorithm 90 checks when indicator 76 toggles, which works well because write algorithm 110, although simpler, takes longer to complete than read algorithm 90. The purpose of locking the OS control program is again to ensure that either the write access or the read access to the coherent data can be completed as quickly as possible.

[0028] Fig. Figure 5 depicts an executable software element R1 shown in box 120, which runs at a step frequency of 2.5 milliseconds and provides a set of coherent signals S in box 122. This is a set of signals to be accessed coherently, such as the previously described X, Y, and Z coordinates. Two buffers, such as the previously described buffers 74 and 76, are created for the set of coherent signals S. Simultaneously with the creation of buffers 72 and 74, a variable "read-index" is created, shown as indicator 76, to indicate which of the two buffers 72 and 74 is to be used for read access. The other buffer is used for write access only at that time. Switching occurs as in Fig. 2 described above, ie at any given time one buffer is the read buffer and the other buffer is the write buffer.

[0029] Fig. 6 to 8 show an exemplary timeline that shows the executable software element R1 of the Fig. 5 in operation over time. In Fig. 6, R1 is executed every 2.5 milliseconds in boxes 132, 134, and 136. Thus, as soon as R1 is executed in box 132, 2.5 milliseconds later R1 is executed again in box 134, and then 2.5 milliseconds after that R1 is executed again in box 136. At the end of each execution in boxes 132, 134, and 136, indicator 76 toggles the read buffer and the write buffer, because R1 generates a new set of signals S every 2.5 milliseconds. The individual signals of S can be generated at any time during R1's execution in boxes 132, 134, and 136. In box 138, another executable software element R2 must read S asynchronously and coherently. The executable software element R2 in box 138 compares “read_index”, ie the specification of indicator 76 with a read start and a read end using algorithm 90.If indicator 76 does not change, the coherent data read operation was completed successfully because the read buffer always contains coherent data.

[0030] Fig. Figure 7 is another timeline that depicts the executable software elements R1 and R2 over time. As in Fig. 7, if the indicator 76 has switched from pointing, for example, to buffer 72 to buffer 74 during the read access, the data read by the executable software element R2 is repeated in box 140 until no change is detected by the indicator 76 between the beginning of the read operation and the end of the read operation in box 132.

[0031] Fig.Figure 8 is another timeline depicting the executable software elements R1 and R2, showing an extended execution time of R1 in box 132, with the signals S being updated during the read operation of the second executable software element R2 in box 138. The second executable software element R2 reads again in box 140, and in box 140, R2 completes the read operation before S is updated again at the end of execution in box 134 (when the indicator 76 toggles).

[0032] The advantage provided by the system and method described herein is a wait-free and lock-free system that ensures that, in the presence of parallel access, the write and read operations proceed without priority inversion. The accessed data is guaranteed to be coherent.

[0033] As will be well understood by those skilled in the art, the multiple and various steps and processes discussed herein to describe the invention may relate to operations performed by a computer, processor, or other electronic computing device that manipulates and / or transforms data using an electrical phenomenon. Such computers and electronic devices may utilize various volatile and / or non-volatile memories, including a non-transitory computer-readable medium storing thereon an executable program comprising various code or executable instructions capable of being executed by the computer or processor, wherein the memory and / or computer-readable medium may include all forms and types of storage and other computer-readable media.

[0034] The foregoing discussion discloses and describes purely exemplary embodiments of the present invention. Those skilled in the art will readily appreciate from this discussion and the accompanying drawings and claims that various changes, modifications, and variations may be made therein without departing from the spirit and scope of the invention as defined in the following claims.

Claims

[1] A method for accessing coherent data on a controller, the method comprising the steps of: Providing a first buffer (72) and a second buffer (74), each of which can be read or written; Providing an indicator (76) indicating which of the first or second buffers is being read from while the other of the first or second buffers is being written to; Executing a read synchronization protocol that enables the coherent data to be read from the buffer that the indicator (76) indicates as a read buffer; and Executing a write synchronization protocol that allows the coherent data to be written into the buffer that the indicator (76) indicates as a write buffer, and where the coherent data to be written together are grouped into data groups. [2] The method of claim 1, wherein the coherent data are atomic elements of executable programs. [3] The method of claim 1, wherein the indicator switches from indicating the write buffer to indicating the write buffer as a read buffer upon completion of the write process. [4] The method of claim 1, wherein executing the read synchronization protocol further comprises storing the indicator locally in an executable read element to prevent corruption due to the indicator changing the indication of which buffer is the read buffer and which buffer is the write buffer. [5] The method of claim 4, wherein executing the read synchronization protocol further comprises determining whether the indicator changed the indication of which buffer is the read buffer and which buffer is the write buffer during the read operation, and if so, locally re-storing the indicator and re-reading it to obtain the most recently updated coherent data. [6] The method of claim 1, wherein executing the write synchronization protocol further comprises disabling a control program of the operating system of a host kernel so that the coherent data can be written to the write buffer without preemption by a higher priority work step so that the writing of the coherent data occurs as quickly as possible. [7] A system (70) for accessing coherent data on a controller, the system comprising: first and second buffers (72; 74) each capable of being read or written to; an indicator (76) indicating which of the first or second buffers (72; 74) is being read while the other of the first or second buffers is being written; a read synchronization protocol that enables the coherent data to be read from the buffer that the indicator (76) indicates as a read buffer; and a write synchronization protocol that allows the coherent data to be written into the buffer that the indicator (76) indicates as a write buffer, wherein the coherent data to be written together are grouped into data groups. [8] The system of claim 7, wherein the coherent data are atomic elements of executable programs. [9] The system (70) of claim 7, wherein the indicator (76) switches from indicating the write buffer to indicating the write buffer as a read buffer upon completion of the write process.

Images