Apparatus, system and / or method for providing data communication protocol for vehicle

Abstract

An apparatus for in-vehicle communication includes: a memory device; and a first controller, the first controller comprising the memory device, the first controller operatively coupled to a plurality of vehicle controllers via an in-vehicle network, the first controller is programmed to: transmit, over the in-vehicle network, at least a first frame comprising a first field and first data to at least a second controller of the plurality of vehicle controllers; determining a first duration indicating a first amount of time to transmit at least the first frame to the second controller; positioning the first duration in the first field; and transmitting at least the first frame comprising the first duration in the first field and the first data to provide an indication to at least the second controller to avoid transmitting data over the in-vehicle network until the first amount of time has expired.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to communication networks. More specifically, the present disclosure relates to an in-vehicle communication network involving an improved Controller Area Network (CAN) protocol. BACKGROUND

[0002] Modern vehicles are provided with various controllers and devices that communicate with each other to perform various functions. Standard Controller Area Network (CAN) or extended CAN hardware and protocols can be used for in-vehicle communication. CAN broadcast messages are used to communicate between various components that each act as a node of an in-vehicle network. Each node in the in-vehicle network participates in winning arbitration using an arbitration field before attempting to transmit a packet.

[0003] When a node has a packet to transmit over a CAN bus and the packet includes multiple frames that are greater than 8 bytes, a delay between two consecutive frames cannot be guaranteed because the transmitting node needs to win arbitration before it attempts to transmit each frame due to limitations of the CAN protocol. This can result in delays in the in-vehicle network. As more features are provided to vehicles (e.g., video, audio, and multimedia features), the situation of one or more nodes transmitting larger data packets over the in-vehicle network becomes more frequent. SUMMARY

[0004] An apparatus for in-vehicle communication, the vehicle comprising: a memory device; and a first controller comprising the memory device, the first controller operatively coupled to a plurality of vehicle controllers over an in-vehicle network, the first controller programmed to: send at least a first frame comprising a first field and first data to at least a second controller of the plurality of vehicle controllers over the in-vehicle network; determine a first duration indicating a first amount of time to send at least the first frame to the second controller; position the first duration in the first field; and send at least the first frame comprising the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from sending data over the in-vehicle network until the first amount of time has expired.

[0005] A method for performing in-vehicle communications, the vehicle comprising: transmitting, by a first controller, at least a first frame including a first field and first data to at least a second controller of a plurality of vehicle controllers over an in-vehicle network; determining, by the first controller, a first duration indicating a first amount of time to transmit at least the first frame to the second controller; positioning, by the first controller, the first duration in the first field; and transmitting, by the first controller, at least the first frame including the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from transmitting data over the in-vehicle network until the first amount of time has expired.

[0006] A non-transitory computer-readable medium comprising instructions that, when executed by a first controller of a vehicle, cause the first controller to: transmit, over an in-vehicle network, at least a first frame including a first field and first data to at least a second controller of a plurality of vehicle controllers; determine a first duration indicating a first amount of time to transmit at least the first frame to the second controller; position the first duration in the first field; and transmit at least the first frame including the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from transmitting data over the in-vehicle network until the first amount of time has expired. BRIEF DESCRIPTION OF DRAWINGS

[0007] For a better understanding of the application, and to show how it can be carried into effect, embodiments of the application will now be described, by way of non-limiting examples only, with reference to the accompanying drawings in which:

[0008] Figure 1 An example block topology of a vehicle system with an in-vehicle network illustrating one embodiment of the present disclosure.

[0009] Figure 2 A bit identifier diagram illustrating an existing extended CAN protocol.

[0010] Figure 3 A bit identifier diagram illustrating an improved CAN protocol of the present disclosure.

[0011] Figure 4 A flowchart illustrating a process for transmitting data packets using an improved CAN protocol of one embodiment of the present disclosure. DETAILED DESCRIPTION

[0012] In accordance with the requirements of the present disclosure, detailed embodiments of the present application are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the present application that can be embodied in various alternative forms. The drawings are not necessarily to scale; some features can be exaggerated or minimized for the purpose of illustrative clarity. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to employ the present application in various ways.

[0013] The present disclosure generally provides for a plurality of circuits or other electrical devices. All references to circuits and other electrical devices and the functionality provided thereby are not intended to limit the scope of the disclosure to only include what is explicitly described herein. Although specific tags can be assigned to various circuits or other electrical devices, such circuits and other electrical devices can be combined and / or separated in any manner based on the particular electrical implementation type required. It will be appreciated that any of the circuits or other electrical devices disclosed herein can include any number of microprocessors, integrated circuits, memory devices (e.g., flash memory, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants of the aforementioned memory devices), and software that cooperate with one another to perform the operations disclosed herein. Further, any one or more of the electronic devices can be configured to execute a computer program embodied in a non-transitory computer readable medium programmed to perform any number of the functions as disclosed.

[0014] The present disclosure, among other things, proposes an in-vehicle communication network that utilizes an improved Controller Area Network (CAN) protocol to enable sending large data packets in consecutive frames.

[0015] Reference is made to Figure 1 FIG. 1 illustrates an example block topology of a system 100 embodying one embodiment of the present disclosure. For example, the vehicle 102 can comprise various types of motor vehicles, crossover utility vehicles (CUVs), sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), watercraft, aircraft, or other mobile machinery for transporting people or cargo. In many cases, the vehicle 102 can be powered by an engine. As another possibility, the vehicle 102 can be a battery electric vehicle (BEV), a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a plug-in hybrid electric vehicle (PHEV), a parallel / series hybrid electric vehicle (PSHEV), or a fuel cell electric vehicle (FCEV). It should be noted that the illustrated system 100 is merely an example, and more, fewer, and / or differently located elements can be used.

[0016] AsFigure 1 As illustrated, the vehicle 102 can be provided with a vehicle system 104 that includes one or more processors 106 configured to execute instructions, commands, and other routines to support the processes described herein. For example, the vehicle system 104 can be configured to execute instructions of an application 108 to provide functionality such as vehicle operation control, multimedia, and the like. Such instructions and other data can be maintained in a non-volatile manner using a variety of types of computer-readable storage media 110. The computer-readable media 110 (also referred to as processor-readable media or storage) includes any non-transitory medium that participates in providing instructions to the processor 106 of the vehicle system 104 that are executable therefrom. The computer-executable instructions can be compiled or interpreted from computer programs written in a variety of current and future programming languages and / or technologies.

[0017] The vehicle system 104 can be provided with one or more in-vehicle networks 105 configured to enable communication between various components of the vehicle 102. The in-vehicle network 105 can be configured to support a variety of communication protocols. For example, as some examples, the in-vehicle network 105 can be configured to support, without limitation, one or more of a controller area network (CAN), an Ethernet network, and a media oriented systems transport (MOST). Further, the in-vehicle network 105 or portions of the in-vehicle network 166 can be a wireless network implemented over Bluetooth Low Energy (BLE), Wi-Fi, or the like. In the present example, the in-vehicle network 105 can be configured to support an improved CAN communication protocol as disclosed by the present disclosure (to be discussed in detail below).

[0018] The vehicle system 104 can be further provided with one or more gateway devices 107 connected to the in-vehicle network 105 and configured to perform various operations to enable operation of the in-vehicle network 105. For example, the gateway device 107 can be configured to perform arbitration on frames sent from different nodes connected to the in-vehicle network 105 to determine a priority of the frames in accordance with a CAN protocol or an improved CAN protocol of the present disclosure. It should be recognized that a node corresponds to any electronic controller that includes a memory and one or more processors to execute code stored on the memory to perform any of the functions described herein. Similarly, any device or controller as stated herein that is coupled to the in-vehicle network 105 can be defined as a node. The gateway device 107 can be a dedicated device connected to the in-vehicle network 105. Additionally or alternatively, the gateway device 107 can be integrated with one or more components of the vehicle system 104 (e.g., the processor 106).

[0019] The vehicle system 104 can be provided with various features that allow a vehicle user to interact with the vehicle system 104. For example, the computing platform 104 can receive input from human-machine interface (HMI) controls 112 that are connected to the in-vehicle network 105 and configured to allow a user to interact with the vehicle 102. As an example, the vehicle system 104 can interface with one or more buttons, switches, knobs, touchscreens, or other HMI controls that are configured to invoke functions on the vehicle system 104 (e.g., navigation, audio / video playback, etc.).

[0020] The vehicle system 104 can also drive or otherwise communicate with one or more displays 114 that are configured to provide visual output to a vehicle user over the in-vehicle network 105 by way of a video controller 116. In some cases, the display 114 can be a touchscreen that is further configured to receive user touch input by way of the video controller 116, while in other cases the display 114 can simply be a display without touch input capabilities. The vehicle system 104 can also drive or otherwise communicate with one or more cameras 117 that are configured to provide video input over the in-vehicle network 105 by way of the video controller 116. The camera 117 can include an exterior camera (e.g., a backup camera) to provide visual information to a vehicle user about the exterior conditions of the vehicle 102. Additionally or alternatively, the camera 117 can include multiple camera lenses and be configured to implement a surround view function. The camera 117 can also include an in-cabin camera that is configured to capture images within the cabin of the vehicle 102.

[0021] The vehicle system 104 can also drive or otherwise communicate with one or more speakers 118 that are configured to provide audio output to a vehicle user by way of an audio controller 120 that is connected to the in-vehicle network 105. The vehicle system 104 can also drive or otherwise communicate with one or more microphones 121 that are configured to capture audio input by way of the audio controller 120.

[0022] The vehicle system 104 can also be provided with navigation and route planning features through a navigation controller 122 connected to the in-vehicle network 105 and configured to calculate a navigation route in response to user input through, for example, the HMI controls 112, and output the planned route and instructions through the speakers 118 and / or the display 114. Location data required for navigation can be determined through communication with multiple satellites. Map data for route planning can be stored in the storage device 110 as part of the vehicle data 124. Navigation software can be stored in the storage device 110 as one of the vehicle applications 108.

[0023] The vehicle system 104 can also be provided with wireless communication capabilities through a wireless transceiver 124 connected to the in-vehicle network 105 and configured to wirelessly communicate with a mobile device 128 of a vehicle user through a wireless connection 126. The mobile device 128 can be any of various types of portable computing devices such as a cellular phone, a tablet computer, a wearable device, a smart watch, a smart fob, a notebook computer, a portable music player, or other device capable of communicating with the vehicle system 104. The wireless transceiver 126 can be configured to support multiple wireless communication protocols including Wi-Fi, Bluetooth, radio frequency identification (RFID), near field communication (NFC), and communicate with a compatible wireless transceiver (not shown) of the mobile device 128 to enable various functions. For example, the vehicle user can conduct audio and / or video phone calls through the vehicle system 104 with the mobile device 128. Additionally or alternatively, the vehicle system 104 can be configured to access a cloud network 130 through wireless connection technology such as a cellular network with the mobile device 128.

[0024] The vehicle system 104 can also be provided with a telematics control unit (TCU) 132 connected to the in-vehicle network 105 and configured to control telecommunications between the vehicle 102 and the cloud network 130 through a wireless connection 134 (e.g., using a modem) in addition to or instead of through the mobile device 128. For example, the vehicle system 104 can download data from and / or upload data to the cloud network 130 through the TCU 132 or through the mobile device 128. It is noted that the term cloud network is used as a general term in this disclosure and can include any computing network involving servers, operators, routers, computers, controllers, circuits, etc. configured to store data and perform data processing functions and facilitate communication between various entities.

[0025] The vehicle system 104 can also be provided with various electronic control units (ECUs) 136 that are connected to the in-vehicle network 105 and configured to perform various operations. For example, the ECUs 136 can include a powertrain control module (PCM) that is configured to operate the vehicle powertrain (e.g., engine, motor, transmission) based on user input and sensor data. The ECUs 136 can also include a body control module (BCM) that is configured to perform vehicle body operations (e.g., lights, doors, windows) based on user input and sensor data. The ECUs 136 can also include an autonomous driving controller (ADC) that is configured to provide autonomous driving features of the vehicle 102 based on user input and sensor data. The ECUs 136 can also include a heating, ventilation, and air conditioning (HVAC) controller that is configured to provide vehicle cabin climate control.

[0026] The vehicle system 104 can also include various vehicle sensors 138 that are connected to the in-vehicle network 105 and configured to capture various sensor data to facilitate vehicle operations. The sensor data can be communicated over the in-vehicle network 105 to the ECUs 168 and / or other components of the vehicle system 104.

[0027] As discussed above, the in-vehicle network 105 can be configured to facilitate communication between various components of the vehicle system 104 using the improved CAN protocol presented by the present disclosure. To better demonstrate the present disclosure, Figure 2 A bit identifier diagram of an extended frame 200 according to the existing extended CAN protocol is illustrated, and Figure 3 A bit identifier diagram of an improved frame 300 according to the improved CAN protocol of the present disclosure is illustrated.

[0028] Referring to Figure 2 The extended frame 200 according to the extended CAN protocol includes a plurality of bit fields for data identification. The extended frame 200 begins with a start of frame (SOF) bit that flags the beginning of a message and is used to synchronize the various nodes on the in-vehicle network 105 after an idle. In the present example, each component of the vehicle 104 can act as a separate node of the in-vehicle network 105. After the SOF, the extended frame 200 also includes an 11-bit identifier that establishes the priority of the message. Lower binary values are generally associated with higher priority of the extended frame 200. The in-vehicle network 105 can be associated with limited bandwidth or transmission capacity. To let a node transmit a data packet, arbitration can be based on the priority of the data packet.

[0029] The extended frame 200 also includes a substitute remote request (SRR) bit that provides a placeholder. The extended frame 200 also includes a single identifier extension (IDE) bit that indicates whether additional identifier bits follow. Since the extended frame 200 is an extended frame (as opposed to a standard CAN frame), the IDE bit should be recessive (e.g., logic 1) to indicate that additional identifier bits will follow. The additional identifier includes 18 bits in addition to the 11-bit identifier that precedes the SRR.

[0030] The extended frame 200 also includes a single remote transmission request (RTR) bit that follows the 18-bit additional identifier to identify whether the frame is a data frame or a remote frame. The extended frame 200 also includes a reserved bit r1 that follows the RTR bit. The extended frame 200 also includes another reserved bit r0 that follows the first reserved bit r1.

[0031] The extended frame 200 also includes a 4-bit data length code (DLC) that indicates the number of bytes of data being transmitted in the current extended frame 200. According to the extended CAN protocol, each frame 200 can contain 0 to 8 bytes (e.g., up to 64 bits) of data that follows the DLC.

[0032] The extended frame 200 also includes a 16-bit cyclic redundancy check (CRC) that includes a checksum of the previously applied data for error detection (e.g., the number of bits transmitted). The extended frame 200 also includes a 2-bit acknowledgement slot to acknowledge that an error-free message has been delivered.

[0033] The extended frame 200 also includes a 7-bit end of frame (EOF) field that marks the end of the current extended frame 200 and disables bit stuffing, which indicates a stuffing error when it is dominant (e.g., logic 0). The extended frame 200 also includes a 7-bit interframe space (IFS) that includes the time needed for the controller to move the correctly received frame to the correct location in the message buffer.

[0034] Reference is made to Figure 3 to illustrate an improved frame 300 according to the improved CAN protocol proposed by the present disclosure. With continued reference to Figure 2, the improved frame 300 is configured based on modifications to the extended frame 200 according to the extended CAN protocol. More specifically, the improved CAN protocol of the present disclosure replaces the 18-bit appended identifier located after the IDE with an 18-bit medium occupancy duration (MOD) identifier to indicate the number of microseconds that the transmitting node from which the improved frame 300 originated expects to hold and occupy the in-vehicle network 205 during which no other node can occupy the in-vehicle network 105. The improved CAN protocol further replaces the reserved bit r0 with a medium busy indicator to indicate whether the 18-bit MOD indicator is present. An explicit bit (e.g., a logical 0) can indicate that the MOD indicator is not present in the current frame 300, while an implicit bit (e.g., a logical 1) can indicate that the MOD indicator is present in the current frame 300. In response to detecting that the MOD indicator is present and indicates a microsecond value, the vehicle system 104 (e.g., through the gateway 107) reserves the in-vehicle network 105 for the duration indicated in the MOD indicator value. One or more nodes of the in-vehicle network 105 can use a countdown timer to determine whether the duration has elapsed. Once elapsed, the in-vehicle network reopens for other transmissions.

[0035] Reference is made to Figure 4 An example flowchart of a process 400 for transmitting data over the in-vehicle network 105 using the improved CAN protocol, illustrating one embodiment of the present disclosure, is shown. Reference is continued to Figure 1 In this example, there are at least four nodes connected to the in-vehicle network 105 to support the improved CAN protocol. A first node 401 (e.g., a first controller) can transmit a large packet (e.g., greater than 16 bytes) including three frames over the in-vehicle network 105 to other nodes in the system. It should be recognized that all nodes as disclosed herein can be referred to as “controllers,” and further that each node includes a memory and at least one processor including instructions to execute code stored on the memory to perform any of the functions disclosed herein. It should further be recognized that the number of nodes in the vehicle network 105 can vary based on the standards of the particular implementation. A second node 402 (e.g., a second controller) and a third node 403 (e.g., a third controller) of the plurality of nodes can each transmit a single frame over the in-vehicle network 105. In this example, a fourth node 404 of the plurality of nodes likewise has no frame to transmit. It is noted that although only four nodes participate in the process 400, the present disclosure is not so limited. The process 400 can be applicable to in-vehicle networks having more or fewer nodes connected.

[0036] At operation 412, each of the first node 401, the second node 402, and the third node 403 individually start a SOF at substantially the same time and transmit an 11-bit identifier for arbitration. Since the fourth node 404 does not have a frame to transmit, it does not participate in the arbitration. The 11-bit identifier from each respective node can be transmitted to the in-vehicle network 105 for arbitration. Arbitration can be performed in a variety of ways. For example, arbitration can be performed by one or more nodes connected to the in-vehicle network.

[0037] At operation 414, in response to receiving the 11-bit identifier for each of the first node 401, the second node 402, and the third node 403, the in-vehicle network 105 performs arbitration (by one or more nodes) to determine which of the three nodes will take over the in-vehicle network 105 and transmit data packets. As discussed above, the 11-bit identifier can include a priority of the data packet and / or frame. The in-vehicle network 105 can use the priority information to perform arbitration and determine that the data packet and / or frame with the highest priority wins the arbitration. In the present example, the in-vehicle network 105 determines that the first node 401 wins the arbitration and announces the results of the arbitration.

[0038] At operation 416, in response to losing the arbitration, the second node 402 and the third node 403 enter an idle mode and do not attempt to initiate a SOF until the in-vehicle network 105 is idle.

[0039] At operation 418, in response to winning the arbitration, the first node 401 calculates a first MOD that indicates a total medium occupancy duration for all frames to transmit the packet in a contiguous manner. As discussed above, the packet is large and must be split into three frames for transmission, and each frame is associated with a duration. For example, the first frame can be associated with a first duration Di and include a first portion of the data packet (e.g., first data), the second frame can be associated with a second duration D2and include a second portion of the data packet (e.g., second data), and the third frame can be associated with a third duration D3and include a third portion of the data packet (e.g., third data). The first MOD (e.g., total MOD) encompasses the total duration (e.g., Di+D2+D3) required to transmit all three frames. The total MOD (e.g., first MOD, second MOD, third MOD) can be calculated by dividing the frame length in bits by the in-vehicle network speed in bits / ps. In one example, the gateway device 107 can use the entire size of the packet to calculate the first MOD without determining the duration required for each frame. In an alternative example, the gateway device 107 can first determine the data size of each respective frame and determine the duration for transmitting each frame individually. The total MOD can be determined by adding the individual durations together. The in-vehicle network speed can be a predetermined speed associated with the in-vehicle network 105. Additionally or alternatively, the gateway device 107 can dynamically measure and update the in-vehicle network speed over time.

[0040] In response to determining the first MOD, the first node 401 prepares to transmit the first frame of the packet. At operation 420, the first node 401 sets the MBI to true (e.g., implicit, logical 1) and assigns the first MOD to the MOD field of the first frame, and transmits the first frame to the in-vehicle network 105. As discussed above, the first MOD includes the total duration required to transmit all three frames (e.g., first MOD = Di+D2+D3).

[0041] Since the first packet is broadcast to the in-vehicle network 105, all nodes connected to the in-vehicle network 105 receive and / or observe the first packet. In response to receiving the first packet including the true MBI and the first MOD, at operation 422, the second node 402, the third node 403, and the fourth node 404 start a countdown timer using the first MOD in microseconds while continuing to refrain from attempting to transmit to the in-vehicle network 105 until the countdown timer expires. Note that although the fourth node 404 did not participate in the previous arbitration and does not have a data packet to transmit, it still participates in the countdown timer to refrain from occupying the in-vehicle network 105.

[0042] At operation 424, in response to completing the first frame (or alternatively while the first frame is still being transmitted), the first node 401 prepares to transmit a second frame of the packet. Similar to operation 418, the first node 401 calculates a second MOD (e.g., D2+D3) that encompasses the duration for transmitting the second frame and the third frame. In one example, the first node 401 can subtract the elapsed time (e.g., Di) from the first MOD to determine the second MOD. Alternatively, the first node 401 can separately calculate the second MOD using the sizes of the second frame and the third frame and the in-vehicle network speed. In a further example, the first node 401 can measure and / or determine an updated in-vehicle network speed at the time of transmitting the first frame, and consider the updated in-vehicle network speed when calculating the second MOD.

[0043] At operation 426, the first node 401 sets the MOD field of the second frame using the second MOD (e.g., D2+D3) and transmits the second frame to the in-vehicle network 105.

[0044] At operation 428, the second node 402, the third node 403, and the fourth node 404 continue the countdown timer that was initially set using the first MOD. Alternatively, if the second MOD included in the second frame significantly differs (e.g., by more than 10 ps) from the remaining time of the countdown timer, indicating that the first MOD was inaccurate, the second node 402, the third node 403, and the fourth node 404 can adjust the countdown timer using the second MOD included in the second frame.

[0045] At operation 430, in response to completing the second frame (or alternatively while the second frame is still being transmitted), the first node 401 prepares to transmit a third frame of the packet. Similar to operation 424, the first node 401 calculates a third MOD (e.g., D3) that encompasses the duration for transmitting the remaining third frame. In one example, the first node 401 can subtract the elapsed time (e.g., D2) from the second MOD to determine the third MOD. Alternatively, the first node 401 can separately calculate the third MOD using the size of the remaining third frame and the in-vehicle network speed. In a further example, the first node 401 can measure and / or determine an updated in-vehicle network speed at the time of transmitting the first frame and the second frame, and consider the updated in-vehicle network speed when calculating the third MOD.

[0046] At operation 432, the first node 401 sets the MOD field of the third frame using the third MOD (e.g., D3) and transmits the third frame to the in-vehicle network 105.

[0047] At operation 434, the second node 402, the third node 403, and the fourth node 404 continue the countdown timer initially set using the first MOD (or the adjusted countdown timer set using the second MOD). Alternatively, if the third MOD included in the third frame differs significantly (e.g., by more than 10 ps) from the remaining time of the countdown timer, indicating that the first MOD and / or the second MOD are inaccurate, the second node 402, the third node 403, and the fourth node 404 can adjust the countdown timer using the third MOD included in the third frame.

[0048] At operation 436, once the countdown timer has expired, indicating that the first node 401 has completed sending all three frames without interruption from other nodes, all nodes connected to the in-vehicle network 105 can be allowed to begin attempting to send a SOF after the IFS associated with the third frame has been received at the first node 401.

[0049] Since the second node 402 and the third node 403 each have data to send, at operation 438, the second node 402 and the third node 403 send, for example, an 11-bit identifier to the in-vehicle network 105 to arbitrate based on the priority of the respective data packets.

[0050] The operations of the process 400 can be applied in various situations. For example, in response to a user input indicating that a user intends to perform one or more vehicle operations, the HMI controller 112 server as a node can use the operations described in the process 400 to generate and send one or more data frames to one or more ECUs 136 (or other components). In response to receiving the one or more data frames, the corresponding ECUs 136 can perform the vehicle operations as instructed by the user. For example, the PCM 136 can perform vehicle powertrain operations such as accelerating, decelerating, entering electric vehicle regenerative mode, switching between drive modes, etc. The BCM 136 can perform vehicle body operations such as operating the vehicle’s lights, doors, windows, trunk, etc. The ADC 136 can perform autonomous driving maneuvers such as accelerating, braking, navigating, steering, etc. The HVAC controller 136 can perform vehicle cabin temperature control operations. Additionally or alternatively, the user input can originate from the mobile device 128 and be received by the vehicle system through the wireless transceiver 124 in addition to or instead of through the HMI controller 112. Additionally or alternatively, the user input can be received from the cloud network by the TCU.

[0051] The algorithms, methods, protocols, or processes disclosed herein can be capable of being carried out by or implemented by a computer, controller, or processing device, which can include any special-purpose or programmable electronic control unit. Similarly, the algorithms, methods, or processes can be stored as data and instructions executable by a computer or controller in a variety of forms including, but not limited to, information permanently stored on non- writable storage media such as read-only memory devices, and information alterably stored on writeable storage media such as optical, magnetic, and solid-state media. The algorithms, methods, or processes can also be implemented in software executable objects. Alternatively, the algorithms, methods, or processes can be embodied in whole or in part by appropriate hardware components, such as application-specific integrated circuits, field-programmable gate arrays, state machines, or other hardware components or devices, or a combination of firmware, hardware, and software components.

[0052] While the foregoing describes exemplary embodiments, these embodiments are not intended to describe all possible forms of the claims. The words used in this specification are words of description, not limitation, and it is understood that various changes can be made without departing from the spirit and scope of the disclosure. The words "processor" and "processors" can be used interchangeably herein, as can the words "controller" and "controllers."

[0053] As previously described, features of various embodiments can be combined to form further embodiments of the present application that can not be explicitly described or illustrated. While various embodiments can be described as providing advantages or being superior to other embodiments or prior art implementations, one of ordinary skill in the art will recognize that one or more features or characteristics can be substituted or omitted, depending on the particular application and implementation, without departing from the spirit and scope of the disclosure. Such attributes can include, but are not limited to, strength, durability, salability, appearance, packaging, size, suitability, weight, manufacturability, ease of assembly, and the like. Thus, embodiments described as being less desirable than other embodiments or prior art implementations in one or more characteristics are not outside the scope of the disclosure and can be desirable for particular applications.

Claims

1. An apparatus for in-vehicle communication, the apparatus comprising: a memory device; and a first controller comprising the memory device, the first controller operatively coupled to a plurality of vehicle controllers over an in-vehicle network, the first controller programmed to: send at least a first frame comprising a first field and first data to at least a second controller of the plurality of vehicle controllers over the in-vehicle network; determine a first duration, the first duration indicating a first amount of time to send at least the first frame to the second controller; position the first duration in the first field; and send at least the first frame comprising the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from sending data over the in-vehicle network until the first amount of time has expired.

2. The apparatus of claim 1, wherein the first controller is further programmed to: after sending the first frame, send at least a second frame comprising a second field and second data to at least the second controller over the in-vehicle network; determine a second duration, the second duration indicating a second amount of time to send at least the second frame to the second controller, wherein the second duration is shorter than the first duration; position the second duration in the second field, send at least the second frame; and send at least the second frame comprising the second duration in the second field and the second data to provide an indication to at least the second controller to refrain from sending data over the in-vehicle network at expiration of the second amount of time.

3. The apparatus of claim 2, wherein the first duration comprises an amount of time to deliver the first frame by the first controller and the second duration.

4. The apparatus of claim 2, wherein the first data and the second data belong to a data packet, the first controller further programmed to: determine the first duration using a total size of the packet and a transmission speed of the in-vehicle network.

5. The vehicle system of claim 4, wherein the first controller is further configured to: determine the second duration by subtracting an amount of time to deliver the first frame from the first duration.

6. The vehicle system of claim 2, wherein the first controller is further programmed to: measure a transmission speed of the first frame sent by the first controller over the in-vehicle network, and adjust the second duration using the transmission speed.

7. A method for performing in-vehicle communication, the method comprising: sending, by a first controller, at least a first frame comprising a first field and first data to at least a second controller of a plurality of vehicle controllers over an in-vehicle network; determining, by the first controller, a first duration, the first duration indicating a first amount of time to transmit at least the first frame to the second controller; positioning, by the first controller, the first duration in the first field; and transmitting, by the first controller, at least the first frame including the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from transmitting data over the in-vehicle network until the first amount of time has expired.

8. The method of claim 7, further comprising: transmitting, by the first controller, at least a second frame including a second field and second data to at least the second controller over the in-vehicle network after transmitting the first frame; determining, by the first controller, a second duration, the second duration indicating a second amount of time to transmit at least the second frame to the second controller, wherein the second duration is shorter than the first duration; positioning, by the first controller, the second duration in the second field, transmitting at least the second frame; and transmitting, by the first controller, at least the second frame including the second duration in the second field and the second data to provide an indication to at least the second controller to refrain from transmitting data over the in-vehicle network at the expiration of the second amount of time.

9. The method of claim 8, wherein the first duration includes an amount of time to deliver the first frame by the first controller and the second duration.

10. The method of claim 8, wherein the first data and the second data belong to a data packet, the method further comprising: determining, by the first controller, the first duration using a total size of the packet and a transmission speed of the in-vehicle network.

11. The method of claim 10, further comprising: determining, by the first controller, the second duration by subtracting an amount of time to deliver the first frame from the first duration.

12. The method of claim 8, further comprising: measuring, by the first controller, a transmission speed of the first frame transmitted by the first controller over the in-vehicle network, and adjusting, by the first controller, the second duration using the transmission speed.

13. A non-transitory computer-readable medium comprising instructions that, when executed by a first controller of a vehicle, cause the first controller to: transmit, over an in-vehicle network, at least a first frame including a first field and first data to at least a second controller of a plurality of vehicle controllers; determine a first duration, the first duration indicating a first amount of time to transmit at least the first frame to the second controller; position the first duration in the first field; and transmit, by the first controller, at least the first frame including the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from transmitting data over the in-vehicle network until the first amount of time has expired. transmitting at least the first frame including the first duration in the first field and the first data to provide an indication to at least the second controller to refrain from transmitting data on the in-vehicle network until the first amount of time has expired.

14. The non-transitory computer-readable medium of claim 13, further comprising instructions that, when executed by the first controller of the vehicle, cause the first controller to: transmit, over the in-vehicle network, at least a second frame including a second field and second data to at least the second controller after transmitting the first frame; determine a second duration, the second duration indicating a second amount of time to transmit at least the second frame to the second controller, wherein the second duration is shorter than the first duration; position the second duration in the second field, transmit at least the second frame; and transmit at least the second frame including the second duration in the second field and the second data to provide an indication to at least the second controller to refrain from transmitting data on the in-vehicle network at the expiration of the second amount of time.

15. The non-transitory computer-readable medium of claim 14, wherein the first duration includes an amount of time to deliver the first frame by the first controller and the second duration.

16. The non-transitory computer-readable medium of claim 14, wherein the first data and the second data belong to a data packet, the non-transitory computer-readable medium further comprising instructions that, when executed by the first controller of the vehicle, cause the first controller to: determine the first duration using a total size of the packet and a transmission speed of the in-vehicle network.

17. The non-transitory computer-readable medium of claim 16, further comprising instructions that, when executed by the first controller of the vehicle, cause the first controller to: determine the second duration by subtracting an amount of time to deliver the first frame from the first duration.

18. The non-transitory computer-readable medium of claim 14, further comprising instructions that, when executed by the first controller of the vehicle, cause the first controller to: measure a transmission speed of the first frame transmitted by the first controller over the in-vehicle network, and adjust the second duration using the transmission speed.

Images