Zafer Attal, M.Sc.

Future cars have a wide variety of sensors, such as cameras, LiDARs, and RADARs that generate a large amount of data. This data has to be sent via an intra-vehicular network (IVN) to further processing nodes, and, ultimately, actuators have to react to the sensor input. In between the processing steps, the intra-vehicular network has to ensure that all of the data and control signals reach their destination in time. Hence, next to a large amount of data, there are also strict timing constraints that the intra-vehicular network has to cope with. Therefore, the so-called time-sensitive networking (TSN) has been introduced. The functional safety of such networks plays an important role against the background of highly automated driving. Emerging errors have to be detected early and potential countermeasures have to be taken to keep the vehicle in a safe state. Therefore, highly sophisticated monitoring and diagnosis algorithms are a key requirement for future cars. (See Project EMDRIVE)

Project Description:

To test the functionality of the Monitoring Hardware, a functional chain implemented on 3 Aurix Boards is used for demonstration. The Aurix boards implement a chain of commands similar to an automotive application to reflect a real-life scenario, where the input feed will be from the Carla simulator. Based on the already existing work that implements a lane-keeping Assistant system, this system will integrate the Carla Simulator, which will take the input from the generated environment and send feedback commands about the direction of the car movement to support in-lane driving. It will also improve the functionality and efficiency of the system by using multiple CPUs and having stable Ethernet communication between multiple Aurix boards.

The substance of this work is to implement the following tasks:

1.  Bring up the Aurix boards, including the Aurix development environment.
2. Implement a functional chain consisting of (F1-F2-F3) that represents an Lane Keeping Assistant System.
3. Establish a stable communication between Aurix boards over the Ethernet switch.
4. Integrate Carla Simulator into the demonistration loop.
5. Use CPU0~CPU5 for more efficient task execution and system implementation. 

Voraussetzungen

Context:

Future cars have a wide variety of sensors, such as cameras, LiDARs, and RADARs that generate a large amount of data. This data has to be sent via an intra-vehicular network (IVN) to further processing nodes, and, ultimately, actuators have to react to the sensor input. In between the processing steps, the intra-vehicular network has to ensure that all of the data and control signals reach their destination in time. Hence, next to a large amount of data, there are also strict timing constraints that the intra-vehicular network has to cope with. Therefore, the so-called time-sensitive networking (TSN) has been introduced. The functional safety of such networks plays an important role against the background of highly automated driving. Emerging errors have to be detected early and potential countermeasures have to be taken to keep the vehicle in a safe state. Therefore, highly sophisticated monitoring and diagnosis algorithms are a key requirement for future cars. When an anomaly is detected, the TAS server (Tool developed by Infineon) is used to request trace information from MultiCore Debug Solution (MCDS), which is a hardware feature available for Aurix boards that are used for debugging and tracing core and bus activities (See Project EMDRIVE).

The Zynq board consists of two parts: Programmable Logic (PL) and Processing System (PS). In this part of the work, the PL will implement the Companion Box, which will continuously monitor the traffic over the Ethernet. The PS part handles the tasks related to the TAS server and MCDS configuration, which will require Linux installation on the Zynq board to implement the TAS server. When an anomaly is detected from the Companion Box, a flag is set so that the software can detect and work accordingly. Then, a set of configurations will be automatically defined by the TAS server and sent to the MCDS of the targeted Aurix board that generated the anomaly. Upon the new configuration, the TAS server will retrieve the traces from the MCDS. 

FORSCHUNGSPRAXIS:

The substance of this work is to implement the following tasks:

1. Install Linux on the ZCU102 PS.
2. Test functionality of Linux.
3. Install TAS server on the Linux OS of ZCU102 board.
4. Configure MCDS of the Aurix boards using the TAS server and retrieve traces.
5. Establish a connection between SW and HW of ZCU102 board (Flag assertion, Memory access).
6. Automate the process of MCDS configuration and Trace retrieval. 

If you are interested, feel free to contact me! Please send your CV as well as a recent transcript.

Voraussetzungen

Context:

Future cars have a wide variety of sensors, such as cameras, LiDARs, and RADARs that generate a large amount of data. This data has to be sent via an intra-vehicular network (IVN) to further processing nodes, and, ultimately, actuators have to react to the sensor input. In between the processing steps, the intra-vehicular network has to ensure that all of the data and control signals reach their destination in time. Hence, next to a large amount of data, there are also strict timing constraints that the intra-vehicular network has to cope with. Therefore, the so-called time-sensitive networking (TSN) has been introduced. The functional safety of such networks plays an important role against the background of highly automated driving. Emerging errors have to be detected early and potential countermeasures have to be taken to keep the vehicle in a safe state. Therefore, highly sophisticated monitoring and diagnosis algorithms are a key requirement for future cars. (See Project EMDRIVE)  

Our approach for such diagnosis builds on non-intrusively monitoring the intra-vehicular network by snooping on data traffic at an interconnect in the car. An analysis of the traffic shall give information about anomalies that occur inside the network as symptoms of an error inside the electrical architecture.   FORSCHUNGSPRAXIS:   The substance of this work is to first work into an existing design of an anomaly detection module that monitors individual packets in a flow. Based on the already existing work, several extensions have to be implemented (Verilog/SystemVerilog) in the hardware design to support anomaly detection in a burst of packet transfer. Type of the faults and anomalies:

1. Arrival time of the Burst 
2. Timing in-between packets in a single Burst
3. Number of packets in a single Burst  

The system should be capable of detecting these fault classes and sending an alert/raising a flag to the software about the detected anomaly. It can then later on inject these types of fault classes during demonstration upon request.  The design should be simulated and implemented on an FPGA (ZCU102 Zync Board).  

If you are interested, feel free to contact me! Please send your CV as well as a recent transcript.

Voraussetzungen

The Aurix TC3x boards are used as ECUs emulators in a Car for in-vehicle network communication. These boards are used to represent this communication behavior, which will work as a benchmark for other network traffic monitors and fault detection modules.

To showcase the Aurix board's functional chain, an Optical Flow Detection algorithm is proposed, where the input is real-time video (Camera). At the same time, the output will be the processed video displayed on a screen or Aurix LCD.

The functional chain should be divided into 3 sub-functions (F1-F2-F3) that will represent the algorithm in which each Aurix board should implement a single function. The data transfer from one board to another uses an Ethernet switch, where the standard Ethernet protocols should be used for communication.  

This encompasses the following sub-tasks:

• Bring up the Aurix boards, including the Aurix development environment.
• Implement a functional chain consisting of (F1-F2-F3) that represents an Optical Flow Detection algorithm. 
• Display the results on a screen or on an Aurix board LCD.
• Establish Ethernet-based data exchange.

Voraussetzungen