Mechanisms and devices for reconfigurable interprocessor communications with embedded controller

Abstract

A method for reconfigurable interprocessor communications in a controller (10), the method comprising the following steps: - providing a plurality of processors (30, 32) in the controller (10), wherein the plurality of processors (30, 32) execute executable elements (34, 36, 38) of the controller (10); - encoding a protocol in each message generated by the processors (30, 32), the protocol being used to send and receive messages from one processor to another; - providing a transmit buffer (60) for messages to be sent and a receive buffer (62) for messages to be received in each of the processors (30, 32); - providing a transmit table (244) and a receive table (252) comprising information about messages in each of the processors (30, 32); and - Providing infrastructure services for each processor (30, 32) comprising determining whether a message is present in a receive buffer (62), comparing the received message data in the message with data in the receive table (252) if a message is present to ensure that the message is received correctly, and decoding the message and copying the signaling data of the message into variables on the processor receiving the message, and wherein the infrastructure services comprise an interrupt service called upon arrival of a message, wherein the interrupt service reads a message header and compares the message header with information in the receive table (252) to determine whether the message is valid, placing a valid message in the receive buffer (62) and discarding an invalid message.

Description

BACKGROUND OF THE INVENTIONField of the invention

[0001] The present invention relates generally to a system and method for reconfiguring interprocessor communications, and more particularly to a system and method that provides multiple processors that provide a send and receive buffer, a send and receive table, and infrastructure software services including protocols for sending and receiving messages between the processors in a controller. 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 electronic vehicle 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, lane keeping systems, stability control systems, etc., are all well known in the art and all control vehicle steering and / or braking to some extent automatically. 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 may write sensor data to the controller memory while running on the processor, and the lane centering system may write this data to its software when running on the processor.Therefore, in cases like these, it often 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 complexity of the controller 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. Furthermore, a single processor has limited resources, such as memory, CPU throughput, etc. The resources required to run multiple applications often exceed the capacity of a single processor.

[0005] Interprocessor communication (IPC) is a set of methods for exchanging data between multiple threads in one or more processes. The one or more processes or executables may run on one or more processors connected by a network. As used herein, the term "executable" refers to a small executable software component or software function that runs at a specific operating system cadence. In interprocessor communication, executables may be allocated to different processors. The executables may also run in different threads at different cadence. Allocation of executables requires frequent changes, which can be burdensome in terms of core / processor throughput as well as bus / memory bandwidth.Current practice, which assumes that executable elements cannot be reallocated during design, is untenable. Messages in known controller implementations comprise node-specific syntax, i.e., hard-wired source / destination information. Moving executable elements from one core to another requires significant effort to identify and modify IPC messages. Thus, there is a need in the art for mechanisms that allow reconfiguration of interprocessor communication according to diverse function layouts, function execution frequencies, and low-level communication links.

[0006] US 2011 / 0 173 635 A1 relates to a multiprocessor system comprising a transmitting processor suitable for transmitting a data message, a receiving processor suitable for receiving the data message, and a memory unit connected to the receiving processor. The multiprocessor system has a size index table associated with the transmitting processor, and the transmitting processor is configured to map a size of a payload portion of the data message to an index of the size index table and to transmit the data message containing the size, the index, and the payload portion to the receiving processor. The multiprocessor system also has a mapping circuit connected to the receiving processor. The mapping circuit is configured to map the index contained in the data message received by the transmitting processor to a pointer, the pointer being connected to a buffer of the memory unit.The receiving processor is configured to write the payload portion of the received data message into the buffer, as specified by the pointer. A receiving processor that can be integrated into a multiprocessor system, an electronic device comprising a multiprocessor system and / or a receiving processor, and a method for receiving a data message in a processor are described.

[0007] US 8 286 188 B1 relates to an interprocess memory controller that can be used to grant multiple processes within a multiprocess device access to shared physical memory. The described interprocess memory controller can enforce access rights to shared memory allocated to the respective processes, thereby protecting the multiprocess device from instability due to unauthorized overwriting and / or unauthorized release of allocated memory.

[0008] The present disclosure is based on the object of specifying a method and a system which are each suitable for enriching the state of the art.

[0009] The problem is solved by the features of the independent claim. The subordinate claim and the dependent claims each contain further developments of the disclosure. SUMMARY OF THE INVENTION

[0010] The following disclosure describes a system and method for reconfigurable interprocessor communications in a controller. The method and system comprise the features of claims 1 and 8.

[0011] Additional features of the present invention will become apparent from the following description and the appended claims, taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] They show: Fig. 1a to 1c show a controller with executable elements configured on first and second processors according to two different configurations; Fig. 2 a map of message buffers that are part of each processor; Fig. 3 a flow diagram of a function that is part of a transmission processor; Fig. 4 is a flowchart of a work step that sends messages to a buffer of the sending core / processor; Fig. 5 is a flowchart of a function that copies sent messages into a buffer of the receiving core / processor; Fig. 6 is a flowchart of a step that copies signal data in a message into a suitable variable; Fig. 7 is a diagram showing an example of how four executable elements R1, R2, R3 and R4 communicate with each other; Fig. 8 is a diagram of a controller comprising the executable elements R1, R2, R3 and R4 distributed across three cores / processors; and Fig. 9 a diagram of a controller comprising the executable elements R1, R2, R3 and R4 distributed across two cores / processors. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0013] The following discussion of embodiments of the invention relating to a system and method for reconfiguring interprocessor communications is merely exemplary in nature and is in no way intended to limit the invention or its applications or uses.

[0014] Fig. 1a depicts a controller 10, such as a controller in a vehicle, comprising executable elements 34, 36, and 38. Fig. 1b and Fig. 1c depicts the executable elements 34, 36 and 38 arranged on the processors 30 and 32, respectively, according to two different configurations. Fig. Figure 1a illustrates how the data signals are shared between the executable elements 34, 36, and 38. As in Fig. As shown in Figure 1a, executable element 34 sends signal data to executable element 36 on line 40 and also sends signal data to executable element 38 on line 42. Executable element 36 sends signal data to executable element 38 on line 44. Executable element 34 may, for example, correspond to vehicle sensor input data. Executable element 36 may be a vehicle trajectory prediction filter, and executable element 38 may be a process for determining a collision risk.

[0015] Fig. Figure 1b depicts the executable elements 34, 36, and 38 distributed among processors 30 and 32. According to this configuration, two messages 52 and 54 are sent on a communication link 50, such as a bus. Fig. 1c depicts executable elements 34, 36, and 38 distributed differently among processors 30 and 32 so that only one message needs to be sent on communication link 50. Thus, varying the configuration of executable elements, such as executable elements 34, 36, and 38, may be desirable to optimize the throughput of processors, such as processors 30 and 32, and also to effectively utilize the bandwidth of communication link 50 and the memory of controller 10.

[0016] To provide a way to reconfigure interprocessor configurations, a protocol encoded in a static message structure, ring buffers for message storage, and infrastructure services are used, as described in detail below. The message sending and receiving protocol is encoded in a message structure with reduced overhead, meaning it is a higher-level protocol unlike a network protocol. The message sending and receiving protocol is capable of supporting multiple message frequencies based on a consumer's bandwidth and throughput optimization needs, which is different from existing fixed-frequency solutions, which, as previously mentioned, unnecessarily consume additional bandwidth and throughput.Thus, the message sending and receiving protocol described here enables robust communications and allows the implementation of various diagnostic and fault-tolerant strategies. The message structure for the message sending and receiving protocol includes a leading byte, denoted here by _sync, which indicates the beginning of a message. The _sync byte is used to identify a new message in the event of header corruption. The message structure also includes system-wide, unique encoding signals / actions, denoted here by _id, which have a predetermined frequency compressed for transmission between a sending site and a destination site, described in more detail below. The sending site, denoted here by _src, is the core / processor that receives the signals / messages.Also included in the message structure is a running message count, denoted here by _cnt, which is a serial number of the particular message structure, unique for each _id, _src, and _dst. For example, _cnt can represent a packet of multiple messages, so that a message missing from the middle of the packet is detected, as discussed in more detail below.

[0017] The protocol's message structure for sending and receiving messages also includes information about the length of the message, denoted here by _size. The _size byte is statically determined and used to ensure correct reception of a message, because _size indicates when the message has ended or should end. Detection of header data corruption, denoted here by _hdr_chksum, is also part of the protocol's message structure. Verifying that the data in the message comes from the same source, has the same destination, and has the same frequency, denoted here by _data, is also part of the message structure. Furthermore, the message structure includes what is denoted here by _data_checksum, which is used by a core / processor receiving the signals, such as processor 32, to detect data corruption.If data corruption is detected, the data is discarded to save storage space, as described below. Table 1 msg_id dst cnt size V-Liste m1 p2 5 10 V1, V3, V8 m2 p2 3 10 V1, V2, V8 m3 p3 1 8 V3, V4 ... ... ... ... ...

[0018] Table 1 depicts how signal data is organized in a transmit table of the transmitting core / processor, such as processor 30. Each processor includes a transmit table and a receive table, as described in more detail below. Each row of Table 1 includes _id, _dst, _size, and a variable list with references and positions of variables. The data is statically organized into a message, where the position of a signal in the message is fixed and determined at configuration time. As shown in Table 1, a message m1 is sent to a receiving core / processor p2 and has a count of 5 and a size of 10. The variable sequence for m1 is V1 followed by V3 followed by V8. A second message in Table 1, m2, is also sent to the receiving core / processor p2 and has a count of 3 and a size of 10 and a variable sequence of V1 followed by V2 followed by V8.A third message, shown in Table 1 as m3, is sent to a receiving core / processor p3 and has a count of 1 and a size of 8, and the variable sequence is V3 followed by V4. Table 2 msg_id Src cnt size V-Liste m1 p1 5 10 V1, V3, V8 m2 p1 2 10 V1, V2, V8 m5 p3 2 6 V7, V5 ... ... ... ... ...

[0019] Table 2 depicts a receive table of the receiving core / processor, such as processor 32. Each row of Table 2 includes _id, _src, _size, and a variable list with references and positions of variables. As previously mentioned, _id, _src, and _size are used to correctly receive messages in the event of header corruption. For example, the size of message m1 is expected to be 10; thus, if the actual size is not 10, the message is discarded, as discussed further below. Message m1 of Table 1 is expected to match message m1 of Table 2. Using the information in the rows of Tables 1 and 2, the receiving core / processor 32 is able to determine whether the received message is correct, i.e., has not been corrupted. As previously stated, each core / processor maintains two tables, one for sending and one for receiving.Both tables are generated at setup time, i.e., at design time, and the _cnt count of the message structure is used on the receiving side to determine whether a message should be discarded.

[0020] Fig. Figure 2 depicts message buffers 60 and 62, which are part of each core / processor, such as processors 30 and 32. Message buffer 60 is a transmit buffer used to store a transmitted message before processing the transmitted message, for example, by delivering the message over a bus, as described in more detail below. Buffer 62 is a receive buffer used to store a received message before processing the received message, as described in more detail below. Each of buffers 60 and 62 is a circular buffer, with each of buffers 60 and 62 including two pointers. A first pointer 64 points to the location where the buffer is written to, and the other pointer 66 points to the location where the buffer is read from. To determine the size that transmit buffer 60 must be, the following equation is used: Bsend=∑∀j∈rate∑∀i∈dstsizeof(mi,j)

[0021] Where B send is the allocated size for the transmit buffer, ∀j ∈ rate is the sum of all possible frequencies at which the data to be transmitted is generated, ∀i ∈ dst is the sum of all possible target processors / cores, and sizeof(m i,j ) is the size of the message, including the header and data.

[0022] Using equation (1), an algorithm calculates the size, _size, or length of each message to ensure that buffer 60 is capable of containing all the data communications it is expected to receive between each Tx_task task, i.e., between each write command task that writes data communications to buffer 30. For example, buffer 60 may be expected to receive 20 data communications from executable R1 and 1 data communication from executable R2. If the size of each data communication is 1 and the message header size is 10, the buffer size can be calculated as 20 * (10 + 1) + (10 + 1) = 231. Similarly, to determine the size that receive buffer 32 must have, the following equation is used: Breceive=∑∀j∈rate∑∀i∈srcsizeof(mi,j)

[0023] Where B receiveis the allocated size for the receive buffer, ∀j ∈ rate is the sum of all possible frequencies at which the data to be transmitted is generated, and ∀i ∈ src is the sum of all messages originating from different source processors, and is the size of the message including the header and data.

[0024] Equation (2) is used to calculate the size, _size, or length of each message to ensure that the ring buffer 32 is able to contain all the data communications it is to receive between each task Rx_task, e.g., each read command task that takes something from the buffer 30 to put it on the bus 50. Using the pointer 66 for reading and the pointer 64 for writing, a function, described in detail below, writes the data sequentially starting from a write index, e.g., starting from the pointer 64. A separate task function, described in more detail below, is called at the highest frequency of the sent messages to read a message to be sent from the read pointer 66 of the second buffer 62, formulates the message, and sends the message to the communication link, e.g.,a bus, in a manner described below. On the receive side, an interrupt service, described in more detail below, is invoked upon the arrival of a message such that the interrupt service compares it with information available in a receive table, such as Table 2. A valid message is placed in the receive buffer 62, and a receive operation, invoked with the highest frequency of received messages, decompresses the signaling data of the message and copies the signaling data into appropriate variables in a manner described in more detail below. The size of the buffers 60 and 62 is calculated using equations (1) and (2) described above to ensure that there is no overflow of the signaling data.

[0025] The message processing infrastructure services on each core / processor 30, 32 include a Tx_func() 70, a Tx_task() 90, an Rx_interrupt() 112 and an Rx_task() 134, as described below with reference to Fig. 3 to 6 are described in more detail.

[0026] Fig. Figure 3 is a flowchart of Tx_func() 70, which is a function of the sending core / processor 30. When there is a message generated by the executable running at a particular frequency and to be sent by the sending core / processor 30 via interprocess communications, such as message m1 from Table 1, Tx_func() 70 begins at box 72. At box 74, Tx_func() 70 uses the message identifier, _id, and destination, _dst, to acquire a signal list and count, _cnt. The Windex (i.e., the write index) of the send buffer 60 is acquired and used to write the message identifier and count to box 76. In box 78, the signal data from the variables, in the example of message m1 the variables V1, V3 and V8, are copied into the send buffer 60.At decision diamond 80, Tx_func() 70 determines whether all signal data from variables V1, V2, and V8 has been successfully copied. If so, the Windex and count are updated in box 82. If not, Tx_func() 70 returns to box 78 to recopy the variable data. Once the Windex and count have been updated in box 82, Tx_func() 70 terminates in box 84. Tx_func() 70 is called each time the executable element is executed.

[0027] Fig. Figure 4 is a flow diagram of the Tx_task() function 90. The Tx_task() 90 is a periodic task that retrieves messages from the transmit buffer and sends them on the communication link 50, such as a bus. The Tx_task() 90 begins at box 92. The Rindex (i.e., the read index) of the transmit buffer 60 is acquired at box 94. The Tx_task() 90 determines at decision diamond 96 whether there is a new message in the buffer 60. If not, the Tx_task() 90 terminates at box 110. If there is a new message in the buffer 60, the message is assembled to add the header and the _chksum, and the message is sent via interprocessor communication at box 98. Once the message has been sent, the Rindex of buffer 60 is updated in box 100, and Tx_task() 90 returns to decision diamond 96 to determine if there is another new message in buffer 60.

[0028] Fig. Figure 5 is a flow diagram of an Rx_interrupt() 112, which copies messages from the physical interprocessor communication link 50 into the receive buffer of the destination processor. At box 114, the Rx_interrupt() 112 is triggered by the arrival of a message. At box 116, the message header is read. The Rx_interrupt 112 determines at decision diamond 118 whether this is a valid message based on the locally stored receive table. Verifying the valid message includes determining whether any mismatched header information (_sync, _id, _src, _dst, _cnt, _hdr_chksum) indicates some corruption, which leads to discarding the message if mismatched header information is present. If a valid message is present, the Windex (i.e.The write index (the write index) of receive buffer 62 is captured at box 120, and the message is written to buffer 62 at box 122 with the message identification information. At decision diamond 124, Rx_interrupt 112 determines whether the data is corrupted. If the data is corrupted, or if it was not a valid message configured in the receive table, at decision diamond 118, the message is discarded at box 126, and the application is notified so that the application can determine what action to take. If the data is not corrupted at decision diamond 124, the Windex of receive buffer 62 is updated at box 128. At decision diamond 130, Rx_interrupt 112 determines whether another message was received via interprocessor communications.If so, Rx_interrupt 112 returns to box 116 to read the message header of that message. If no other message has been received, Rx_interrupt 112 ends in box 132.

[0029] Fig. Figure 6 is a flow diagram of the Rx_task() function 134, which parses the messages received in the receive buffer and copies the signal data into a message for the appropriate variable. The Rx_task() 134 is a periodic operation that runs. The Rx_task() 134 begins at box 136 and acquires the Rindex (i.e., the read index) of the receive buffer 62 at box 138. The Rx_task() 134 determines at decision diamond 140 whether a new message is present in the buffer 62. If no, the Rx_task() 134 ends in box 148. If yes, a signal list from a receive table, such as Table 2, is retrieved in box 142, and the message is decoded and the signal data is copied into the appropriate variables in box 144.Once the copying of the signal data in box 144 is completed, the Rindex of buffer 62 is updated and Rx_task() 134 returns to decision diamond 140 to determine if another new message is in buffer 62.

[0030] Fig. Figure 7 is an illustration of an example 200 of how four executable elements, an executable element R1 in box 202, an executable element R2 in box 204, an executable element R3 in box 206, and an executable element R4 in box 208, communicate with each other. Each circle in Fig. 7 is a data communication sent from one executable element to another. Each data communication includes variables written by a sending executable element and read by a receiving executable element. Data communications 210 and 212 are communications including variables V12a and V12b, each having a size of 6 and 4, written by executable element R1 every 5 milliseconds and sent to executable element R2. Data communication 214 is a data communication including variable V13, which has a size of 4, written by executable element R1 every 5 milliseconds and sent to executable element R3 as message m1.Data communications 216 and 218 are communications that include variables V23a and V23b, each having a size of 6 and 4, respectively, and are written by executable R2 every 10 milliseconds and sent to executable R3 as message m2. Data communication 220 is a data communication that includes variable V24, which has a size of 2, and is written by executable R2 every 10 milliseconds and sent to executable R4 as message m3.

[0031] Fig. 8 is an illustration of a controller 230 comprising the executable elements R1, R2, R3 and R4 previously described in Fig. 7. The executable elements R1, R2, R3 and R4 are distributed over three cores / processors, whereby the reference numerals of Fig. 7 can be used to refer to the same elements in Fig. 8. A first processor 232 includes the executable element R1 in box 202 and the executable element R2 in box 204. A second processor 234 includes the executable element R3 in box 206, and a third processor 236 includes the executable element R4 in box 208. Tables and buffers for each of the processors 232, 234, and 236 are generated at the time of configuration of the controller 230. According to this example, a receive table 240 of the first processor 232 is empty because no messages are being sent to the first processor 232. Similarly, the size of a receive buffer 242 is zero because no messages are being received.

[0032] A send table 244 includes all messages sent from a send buffer 246 from the processor 232.

[0033] Thus, the transmission table 244 contains the information in Table 3: Table 3 msg_id dst cnt size V-Liste m1 p2 1 4 V13 m2 P2 1 6+4 V23_a, V23_b m3 p3 1 2 V24

[0034] As shown in Table 3, the transmit buffer 246 sends the data communication 214 from the executable element R1 as m1 and also sends the data communications 216, 218 as m2 and the data communication 220 from the executable element R2 as m3. The period of Tx_task of the transmit buffer 246 is every 10 milliseconds, and the message header size is 10, that is, the total size of the fields besides the data payload is 10. Using the above equation (1), the size of the transmit buffer 246 is calculated as 2 * (10 + 4) + (10 + 6 + 4) + (10 + 2) = 60. Once the transmit buffer 246 writes the messages m1, m2, and m3 containing the appropriate data communications, the messages m1 and m2 are sent to the second processor 234, and the message m3 is sent to the third processor 236.Since message m1 originates from executable R2, two messages m1 are created (one every 5 milliseconds) when the send buffer 246 writes (which occurs every 10 milliseconds).

[0035] The second processor 234 includes a receive buffer 250 that receives incoming data communications and a receive table 252 that contains the information in Table 4: Table 4 msg_id src cnt size V-Liste m1 P1 1 4 V13 m2 P1 1 6+4 V23_a, V23_b

[0036] According to this example, a transmit buffer 254 of the second processor 234 has a size of zero, and a transmit table 256 is empty because the second processor 234 is not sending any data communications. The Rx_task read task of the receive buffer 250 occurs every 10 milliseconds. Using equation (2) above, the size of the receive buffer 250 is thus calculated as 2 * (10 + 4) + (10 + 6 + 4) = 48, again assuming that the header size is 10.

[0037] The third processor 236 receives the message m3, which comprises the data communication 220 from the executable element R2 of the first processor 232. A receive buffer 260 receives the message m1, and a receive table 262 contains the information shown in Table 5: Table 5 msg_id src cnt size V-Liste m3 p1 1 2 V24

[0038] A transmit buffer 264 of the third processor 236 has a size of zero, and a transmit table 266 is empty because the third processor 236 does not transmit any data communications according to this example.

[0039] The previously described Fig. 8 maps four executable elements to three processors. This configuration is an option that can be changed upon request.

[0040] Fig. Figure 9 is an illustration of a controller 300 that includes the executable elements R1, R2, R3 and R4 previously described in Fig. 7, in a different configuration, so that the executable elements R1, R2, R3 and R4 are distributed over two instead of three processors, as in Fig. 8. The reference numerals are the same for similar elements shown in Fig. 7 and Fig. 8. A first processor 302 includes the executable R1 in box 202 and the executable R4 in box 208. A second processor 304 includes the executable R2 in box 204 and the executable R3 in box 206. According to this example, a receive buffer 306 receives the data communications 210, 212, and 214 from the executable R1 in a message m1, and a transmit buffer 310 sends the data communication 220 from the second processor 304 to the first processor 302 in a message m3. A receive buffer 318 of the first processor has an Rx_task period of 30 milliseconds and receives the data communications 220 of the message m1.

[0041] The transmission table 316 of the first processor 302 contains the information shown in Table 6: Table 6 msg_id dst cnt size V-Liste m1 p2 1 4+2+4 V13, V12_a, V12_b

[0042] Based on the message size information as shown in Table 6, and assuming that the header size is 10, so using the above equation (1), the size of the transmit buffer 314 is calculated to be = (10 + 10) = 20, because in this example, the executable R1 runs every 5 ms and the Tx_task also runs every 5 ms.

[0043] In this example, since the first processor 302 is receiving messages, the receive buffer 318 is not zero and the receive table 320 is not empty. Instead, the receive table 320 contains the information shown in Table 7: Table 7 msg_id src cnt size V-Liste m3 p2 1 2 v24

[0044] As shown in Table 7, the message size is 2. The operating frequency of the receive buffer 318 is 30 milliseconds, whereas the operating frequency of the transmit buffer 310 is 10 milliseconds. Thus, 3 messages are stored in the receive buffer 318 before the messages are read. Again assuming the header size is 10, the size of the receive buffer 318 is calculated using equation (2) above as 3 * (10 + 2) = 36.

[0045] In the second processor 304, the receive table 308 of the second processor 304 contains the information shown in Table 8. The size of the receive buffer 306 is calculated using equation (2) above, i.e. = 2 * (10 + 10) = 40, because the message m1 arrives from the communication link 50 every 5 ms, whereas the Rx_task on the second processor 304 runs every 10 ms. Thus, Table 8 includes: Table 8 msg_id src cnt size V-Liste m1 p1 1 10 V13, V12_a, V12_b

[0046] The second processor 304 sends a message m3 to the first processor 302, as previously stated. Thus, the transmission table 312 of the second processor 304 contains the information shown in Table 9: Table 9 msg_id dst cnt size V-Liste m3 p1 1 2 V24

[0047] As stated previously, the header size is assumed to be 10. Thus, the size of the transmit buffer 310 is calculated using equation (1) above, i.e., = 10+2 = 12, because the executable R2 and the Tx_task on the second processor 304 both run every 10 ms.

[0048] Fig. 9 depicts the same executable elements R1, R2, R3 and R4 according to a different configuration. Fig. 8 shown configuration can be reconfigured to be allocated as in Fig. 9 by exchanging tables, buffer sizes and software components, which are all predefined and prestored. For example, if the third processor 236 in Fig. 8 fails, the controller 232 can be reconfigured to be the controller 300 by changing the tables and buffers such that the executable element R4 is moved from the third processor 236 to the first processor 302 and the executable element R2 is moved from the first processor 232 to the second processor 304. The so-called moving is achieved by changing the contents of the transmit and receive tables of the processors relative to their contents in Fig. 8 on the sending and receiving tables Fig. 9 and by changing the size of the buffers compared to their nature in Fig. 8 on the size of the buffers in Fig. 9 be changed.

[0049] The reconfigurable system and method described above enable truly parallel implementation of applications and components without requiring knowledge of their deployment. The bandwidth and throughput of the central processing unit are improved by supporting flexible reallocation of the location of function execution and the communication frequency. As previously stated, existing interprocessor communications in vendor systems require a fixed location of applications and transmit messages only at a fixed frequency, which unnecessarily consumes additional bandwidth and throughput. The above protocol provides robust communication and enables independence from low-level communication implementations that may be purchased from vendors.

[0050] 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 having stored 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.

[0051] 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 reconfigurable interprocessor communications in a controller (10), the method comprising the following steps: - providing a plurality of processors (30, 32) in the controller (10), wherein the plurality of processors (30, 32) execute executable elements (34, 36, 38) of the controller (10); - encoding a protocol in each message generated by the processors (30, 32), the protocol being used to send and receive messages from one processor to another; - providing a transmit buffer (60) for messages to be sent and a receive buffer (62) for messages to be received in each of the processors (30, 32); - providing a transmit table (244) and a receive table (252) comprising information about messages in each of the processors (30, 32); and - Providing infrastructure services for each processor (30, 32) comprising determining whether a message is present in a receive buffer (62), comparing the received message data in the message with data in the receive table (252) if a message is present to ensure that the message is received correctly, and decoding the message and copying the signaling data of the message into variables on the processor receiving the message, and wherein the infrastructure services comprise an interrupt service called upon arrival of a message, wherein the interrupt service reads a message header and compares the message header with information in the receive table (252) to determine whether the message is valid, placing a valid message in the receive buffer (62) and discarding an invalid message. [2] The method of claim 1, wherein each of the processors (30, 32) comprises at least one executable element (R1, R2, R3, R4), the executable element generating a message and sending the message to the send buffer (60) of the processor (30, 32) on which the executable element (R1, R2, R3, R4) is running when the executable element (R1, R2, R3, R4) needs to send a data communication to another executable element (R1, R2, R3, R4) on a different processor (30, 32). [3] The method of claim 1, wherein each of the transmit buffer (60), the receive buffer (62), the transmit table (244) and the receive table (252) is generated for each processor (30, 32) at the time of design of the controller (10). [4] The method of claim 1, wherein the size of each buffer is calculated using at least a message header size and a message size such that each buffer has an appropriate capacity to store messages. [5] The method of claim 1, wherein each table includes information about the message identification, the message destination, the message count, the message size and a variable list. [6] The method of claim 5, further comprising reconfiguring the controller (10) to change the interprocessor communications by changing the contents of at least one transmit table (244) and one receive table (252). [7] The method of claim 5, further comprising comparing information in a table with the message header information in a corresponding message to determine whether the corresponding message is corrupted. [8] A system for reconfigurable interprocessor communications in a controller (10), the system comprising: - a plurality of processors (30, 32) in the controller (10); - a transmit buffer (60) and a receive buffer (62) generated for each of the processors (30,32), the transmit buffer (60) being used to write, store and send messages, the receive buffer (62) being used to read, store and copy messages; - a transmit table (244) and a receive table (254) generated for each of the processors (30, 32), wherein the transmit table (244) stores identification information about messages being transmitted and the receive table (254) stores identification information about messages being received; and - infrastructure services programmed into the controller (10), the infrastructure services comprising protocols for sending and receiving messages between the processors in the controller (10), and the infrastructure services comprising an interrupt service invoked upon arrival of a message, the interrupt service reading a message header and comparing the message header with information in the receive table (254) to determine if the message is valid, placing a valid message in the receive buffer (62) and discarding an invalid message. [9] The system of claim 8, wherein each of the plurality of processors (30, 32) comprises at least one executable element (R1, R2, R3, R4), wherein the executable elements (R1, R2, R3, R4) generate a message and send the message to the send buffer (60) of the processor (30, 32) on which the executable element (R1, R2, R3, R4) is running when the executable element (R1, R2, R3, R4) needs to send a data communication to another executable element (R1, R2, R3, R4) on a different processor. [10] The system of claim 8, wherein each of the transmit buffer (60), the receive buffer (62), the transmit table (244), and the receive table (254) is generated at design time.

Images