EECS 753: Embedded Real-Time Systems Heechul Yun 1
Welcome to EECS753 • About the course 2
About Instructor • Heechul Yun – Assistant Prof., Dept. of EECS, University of Kansas (Aug.’13 ~ ) – Office: 3040 Eaton, 236 Nichols – Email: heechul.yun@ku.edu • Educations – Ph.D. (CS), University of Illinois at Urbana-Champaign – M.S. (CS) and B.S (CS), KAIST • Professional Experiences – Senior software engineer @ Samsung Electronics • Research Areas – Operating systems, embedded/real-time systems • More Information – http://ittc.ku.edu/~heechul 3
About This Class • Topics – Embedded Real-Time Systems. Cyber Physical Systems • Prerequisite – EECS 645 Computer Architecture. – EECS 678 Introduction to Operating Systems. • No textbook! • Course website – http://ittc.ku.edu/~heechul/courses/eecs753 • Audience – Grad students (senior undergraduate) who are interested in research • Times – Lecture: M/W/F 10:00 – 11:00 LEA 1131 – Office hour: M/F 11:00 - 11:50 @ 3040 Eaton 4
About This Class • Seminar style – I and YOU will present (more on later) • Goals – Learn and discuss advanced topics in real-time embedded systems – Improve your research skills • Research skills – Learning skills • Quickly learn from papers, books, and the internet! – Communication skills • Written form = paper, oral form = presentation – Programming skills • Need to build some “interesting” things 5
Topics • Introduction to Real-Time Systems, CPS • CPS Applications: Intelligent Vehicles • Real-time Hardware Architecture • Real-time OS and Middleware • Fault tolerance and Security Amazon prime air 6
Methodology • Learning by reading research papers • Learning by building an actual system 7
Reading Papers • You are expected to – Read assigned papers (~two/week) – Summarize them • Reading paper well is an important skill – A good reference: “How to Read a Paper” 8
Written Summary • Each summary should include: – Summary of main ideas – What you liked – What you disliked • Submit via Blackboard 9
Written Summary: Example • [Summary] This paper presents a kernel level page allocator which is DRAM Bank- Aware. This allocator is able to allocate pages across cores in a way that causes banks to be shared or partitioned depending on user configuration. This can be used to provide more predictable memory access to multicore software. The authors implemented their memory allocator in a recent version of the Linux Kernel and compared its performance with the existing buddy allocator. • [The good] This paper is well written. The issue of DRAM banks was not familiar to me at the time of reading but was well explained which motivated the rest of the paper well. The algorithm used is quite straightforward and the explanation is easy to follow. • [The bad] While the authors acknowledge that the approach they take bears similarity to multi-core page coloring[1,2,3,4] the novelty of their work is not well established. This work appears to be a relatively straightforward application of rudimentary page coloring techniques. The related work section touches on these similarities but does not establish any particular novelty aside from the fact that this paper is addressing the problem of shared DRAM banks for the sake of isolation and not shared caches. 10
Lecture Organization • Typical week – Mon: Lecture on the week’s topic – Wed/Fri: Paper presentations • Paper presentation – I will Introduce the paper – I (or you) will present the paper – We will discuss the paper • You are required to present – One (or two) paper per semester – May change depending on the class size 11
Reading List • Posted on the class website – Subject to change – Mostly recent papers and some classic ones • Sign-up process – Email me the paper in the list you want to present – I will update the schedule on a First Come First Serve (FCFS) basis 12
Paper Presentation & Discussion • Suggested structure (30min) – Motivation & Background • Ask why the authors write this paper? – Explain the main ideas • From your perspective. Careful about their assumptions – Discussion topics • Questions: “I don’t understand XXX.” • Critiques: “This approach seems bad because …” • Submission – Draft: by 5:00 p.m. the day before your presentation – Final version: before the class begins 13
Final Exam • No midterm exam • Early final exam on April 15 14
Homework & Mini Projects • Plan – Two homework assignments on Linux PC – Two mini projects using a Raspberry Pi 3 • About – Basic real-time scheduling – Basic AI and self-driving car 15
NVIDIA DAVE-2 Self-Driving Car • Use a Convolutional Neural Network (CNN) to drive a car. • Trained with human driving data • Could successfully drive a car on public roads w/o human DAVE-2 CNN: 9 layers, ~250K parameters, Source: https://devblogs.nvidia.com/deep-learning-self-driving-cars/ ~27M connections Video: https://www.youtube.com/watch?v=NJU9ULQUwng 16
Term Project • 2 nd half of the semester • DeepPicar Competition – Build a self-driving car – Based on DeepPicar – Competition format 17
DeepPicar Competition • Goal – Safely drive autonomously on a given track – Using camera and Deep Neural Network (DNN) • Metrics – Distance and time • Your tasks – Build a car (instruction, materials will be given) – Develop/tune the AI (basic code will be given) 18
(Tentative) Project Schedule • 3/18: Materials ready (build start) • 4/22: Manual driving check • 4/29: Autonomous driving check • 5/06: Competition • 5/15: Final report due – 5 pages – Must be written using Latex 19
Latex • Everybody in CS uses it to write papers – Final report must be prepared using Latex • Overleaf – https://www.overleaf.com • Ubuntu – Install texlive-full • Window – Install MikTex. 20
Grading • Paper summaries (20%) • Student presentations (10%) • Final exam (30%) • Mini project(5%) • Homework (5%) • Project (30%) – Competition: 20% – Final report: 10% 21
Grading • 90+ : A • 80-89: B • 70-79: C • 50-69: D • 0-49: F 22
Office Hours • M/F 11:00 – 11:50 at 3040 Eaton • By appoint at 236 Nichols – heechul.yun@ku.com 23
Introduce Yourselves • Name • Status: grad/undergrad, year • Relevant background • Interests – What do you want to learn in this class? 24
Today • Course overview 25
Embedded Systems • Computing systems designed for specific purpose. • Embedded systems are everywhere 26
Today’s Car • Quiz. How many embedded processors are in a car? – A: ~100s Simon Fürst, BMW, EMCC2015 Munich, adopted from OSPERT2015 keynote 27
Future Automotive Systems A. Hamann. “Industrial challenges: Moving from classical to high performance real-time systems .” In International Workshop on Analysis Tools and Methodologies for Embedded and Real-time Systems (WATERS) , July 2018 28
Trends • More powerful and cheaper computing • More connected 29
Internet of Things (IoT) • IoT ~= Internet connected embedded systems 30
Cyber-Physical Systems (CPS) • Cyber system (Computer) + Physical system (Plant) • Still embedded systems, but integration of physical systems is emphasized. 31
Real-Time Systems • The correctness of the system depends on not only on the logical result of the computation but also on the time at which the results are produced • A correct value at a wrong time is a fault. • CPS are often real-time systems – Because physical process depends on time 32
CPS Requirements • Real-time performance – Meet deadlines in processing large amounts of real-time data from various sensors (e.g., autonomous cars) – Many constraints: size, weight, and power (SWaP); cost • Safety – Interact with the environment, human, in real-time – Can hurt humans, destroy things, blow up (e.g., Nuclear plants) – Need both logical and temporal (time) correctness • Security – Communicate over the internet (cloud servers etc.) – Remote software update (fix bugs, …) – Run untrusted 3 rd party software (e.g., Apple CarPlay) 33
Performance • Many cyber-physical systems (CPS) need: – More performance – Less cost, size, weight, and power Audi A8 Audi’s zFAS platform. 2016-2018 CMU’s “Boss” Self -driving car, circa 2007 10 dual-processor blade servers on the trunk A single-board computer with multiple CPUs, GPU, FPGA 34
Compute Performance Demand Intel, “ Technology and Computing Requirements for Self- Driving Cars” 35
Real-Time Data • from many sensors needs powerful computers Source: http://on-demand.gputechconf.com/gtc/2015/presentation/S5870-Daniel-Lipinski.pdf 36
Size, Weight, and Power (SWaP) Constraints • Maximum performance with minimal resources – Cannot afford too many or too power hungry ECUs Figure source: OSPERT 2015 Keynote by Leibinger 37
Mobileye EveQ4 • Real-time vision processor w/ DNN • 2.5 teraflops @ 3W • 8 cameras @ 36 fps • Tesla uses EveQ3 • 14 cores – 4 MIPS cores – 10 vector cores 38
Recommend
More recommend
