الفهرس 
IntroductionOnly 14 pages are availabe for public view
 |  | from | 174 |  |  |
| | | from | 174 | | |
Abstract
Today’s automotive Software (SW) applications exhibit high communication within Electronic Control Units (ECUs) and between networked vehicle nodes. Here comes the role of the AUTomotive Open System ARchitecture (AUTOSAR) Communication (COM) module that defines a standard for the common SW communication interfaces and behaviour for internal communication (i.e., communication within an ECU) and external communication (i.e., communication between networked vehicle nodes), which is independent of the communication protocol used.
Due to the improvement of exchanged information between ECUs, the need to deal with other types of protocols, which are able to transfer long Protocol Data Units (PDUs) and signals, has been aroused and it became possible to transfer other types of information (e.g., images and maps).
The idea of this research is to design a secure AUTOSAR-based COM ApplicationSpecific Instruction Set Processor (ASIP) for handling long PDUs and signals by packing long transmitted signals into their corresponding PDUs and unpacking long received signals from their corresponding PDUs. This circuitry will be designed directly on Hardware (HW) instead of SW to accelerate the process of packing/unpacking long signals into/from their corresponding long PDUs. Then integrating the accelerated part on HW with the core SW of the AUTOSAR COM module and measuring the performance improvement. The exchange of the PDUs between ECUs has to be done in a secure manner by using the appropriate cryptographic algorithms to prevent hackers from gaining access to the information inside these PDUs and altering it.
The research presents the design and implementation details of four versions of AUTOSAR COM ASIP. The first version is a non-pipelined version. This version introduced two new instructions that are used to handle long signals and PDUs. It can handle (i.e., send or receive) 4 bytes of any signal in only one instruction so it can handle signals and PDUs of any arbitrary length. The second version is a non-pipelined version as well. This version supports all functionalities available in the previous version. In addition, it introduced six new instructions that are used to secure exchanging PDUs between ECUs by applying a hashing algorithm on signals contained in these PDUs.
The third version is a pipelined version. This version supports all functionalities available in the previous versions. It increases throughput of instructions supported by the previous versions using a pipelined technique. Throughput of this third version is 169x more than throughput of Controller Area Network Flexible Data-rate (CAN FD) protocol, and 100x more than throughout of FlexRay protocol. The fourth version is a pipelined version as well. This version supports all functionalities available in the previous version in an enhanced fashion. Throughput of this third fourth version is 245x to 338x more than throughput of CAN FD protocol, and 156x to 229x more than throughout of FlexRay protocol.