Bus-independent Instruction Set Architecture for Handling Long Protocol Data Units in AUTOSAR-based Automotive ECUs

Abstract

"Research and/or Engineering Questions/Objective Today’s AUTOSAR-based automotive SW applications mandates high communication throughput. These SW applications deal with thousands of signals and hundreds of IPDUs periodically in very short periods (e.g., 5ms). This requires using communication protocols that are able to handle such high throughput (e.g., CAN-FD, FlexRay, Ethernet, etc…). Introducing these communication protocols requires dealing with long signals (longer than the traditional UINT32 signals). These long signals are transmitted in long IPDUs (longer than the traditional 8-bytes IPDUs used with CAN and LIN buses). The objective of our work is to design an ISA that handles signals and IPDUs of any arbitrary length in a very short time. The ISA will be realized on an ASIP to be used on real ECUs to enhance their performance. Methodology The idea of our approach is to design an ISA that maps the most ECU time-consuming AUTOSAR-based APIs (i.e., Com_SendSignal and Com_ReceiveSignal) to instructions. We extended our previous work by introducing two new instructions (i.e., Send Long Signal and Receive Long Signal). Introducing these instructions makes our design bus-independent, as it handles signals and IPDUs of any arbitrary length. The new instructions require 12 execution cycles to complete their execution. Our ISA consists of four phases, which are Fetching, Decoding, Execution, and Delivery. The Execution phase consists of two sub phases, which are Extraction and Packing/Unpacking. We realized our ISA on an ASIP using ArtixTM-7 FPGA. Our ASIP is used to accelerate handling such signals and IPDUs to enhance the performance of AUTOSAR-based ECUs and cope with the throughput needed by the high-speed communication protocols (e.g., CAN-FD, FlexRay, Ethernet, etc…). Results The clock speed achieved by our ASIP is 180 MHz. Our ASIP, to be compatible with any communication bus (e.g., Ethernet), handles signals and ComIpdus of any arbitrary length. Our ASIP handles the 64-bytes and 254-bytes ComIpdus, which correspond to the longest transmitted frames using CAN-FD and FlexRay protocols, in 1 us and 4 us respectively. The throughput achieved by our ASIP is 50-100x more than the throughput needed by these high-speed communication protocols. For example, transmitting 64-bytes CAN-FD frame on CAN bus running on 1 Mbps baud rate and 254-bytes FlexRay frame on FlexRay bus running on 10 Mbps baud rate takes 100 us and 200 us respectively. What does the paper offer that is new in the field? Our paper introduced bus-independent HW-based optimization approach for the most ECU time consuming AUTOSAR-based APIS (i.e., Com_SendSignal and Com_ReceiveSignal) by designing an ISA and realizing it on an ASIP. This approach has not been addressed before for AUTOSAR-based ECUs. Conclusions The great throughput, 50-100x more than the throughput for CAN-FD and FlexRay communication protocols, achieved by our COM ASIP allows OEMs and Tier1s to use it to cope with the communication throughput required by today’s AUTOSAR-based automotive SW applications. Our ASIP is bus-independent so it can work with all types of ECUs, which are connected through different communication buses."

Two-Layer Bus-Independent Instruction Set Architecture for Securing Long Protocol Data Units in Automotive Open System Architecture-Based Automotive Electronic Control Units

“…The above number of signals and their lengths were selected for compatibility with our previous COM ASIP (i.e., COM ASIP V2). We used 2000 virtual signals [12]. Sizes of the IPDU component and the rom_n component for our previous COM ASIP were the same as the sizes of the IPDU component and the rom_n component in our new COM ASIP (i.e., COM ASIP V3).…”

“…We performed the same tests (i.e., transmitting/receiving a 64-byte CAN FD frame and a 254-byte FlexRay frame) [12] using COM ASIP V3. COM ASIP V3 was able to handle a 64-byte CAN FD frame in 1.575 µs.…”

“…The throughput achieved by our new COM ASIP is much more, 42× to 75×, than the throughput needed by these high-speed communication buses. For example, transmitting a 64-byte CAN FD frame on CAN bus running on 1 Mbit/s baud rate (i.e., the highest baud rate for CAN bus) takes 118 µs [12], and transmitting a 254-byte FlexRay frame on FlexRay bus running on 10 Mbit/s baud rate (i.e., the highest baud rate for FlexRay bus) takes 262.4 µs [12]. However, COM ASIP V3 can handle (i.e., transmit, receive, calculate hash, or hash verify) a 64-byte CAN FD frame and a 254-byte FlexRay frame in 1.575 µs or 6.301 µs, respectively.…”

“…This is done by handling signals no larger than 32 bits individually, inside these PDUs either by packing them during PDU transmission (i.e., through send signal instructions) or by unpacking them during PDU reception (i.e., through receive signal instructions). The second COM ASIP (i.e., COM ASIP V2) [12] introduced two extra instructions (i.e., the send long signal instruction and the receive long signal instruction) to handle long signals and PDUs of arbitrary lengths. The additions to COM ASIP V1 to support the long signal instructions are shown in Figure 2.…”