EECS 753: Embedded Real-Time Systems - KU ITTCheechul/courses/eecs753/S17/slides/W1-Intro.pdf · NHTSA Report, 1/19/2017 •Both the radar and camera sub-systems are designed for

EECS 753: Embedded Real-Time Systems

Heechul Yun

1

Welcome to EECS753

• Announcements

• About the course

2

About Instructor

• Assistant Prof., Dept. of EECS, University of Kansas (Aug.’13 ~ )– Office: 3040 Eaton, 236 Nichols

– Email: [email protected]

• 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

mailto:[email protected]

About This Class

• Topics: Embedded Real-Time Systems. Cyber Physical Systems– Emphasis on Automotive and Aviation domains

• Prerequisite: – EECS 645 Computer Architecture.– EECS 678 Introduction to Operating Systems.

• No textbook!– Optional: TBD

• 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

http://ittc.ku.edu/~heechul/courses/eecs753

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

• Fault tolerance, safety, security

• Real-time multicore architecture

• Real-time OS and middleware

6Amazon prime air

About This Class

• Academic research cycle

– Read papers

– Find problems

– Develop “novel” ideas

– Write a paper

– Present your ideas at a conference

7

Reading Papers

• You are expected to

– Read assigned papers (~two/week)

– Summarize them and submit before the class

• Reading paper well is an important skill

– A good reference: “How to Read a Paper”

• Your summary should be sent to me via email

8

http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/paper-reading.pdf

Written Summary

• Must be in ASCII text format (no words, pdf)

– Include “[EECS753]” in the subject line

• Each summary should include:

– Summary of main ideas

– What you liked

– What you disliked

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: Three phases– I will Introduce the paper

– I (or you) will present the paper

– We will discuss the paper

• You are required to present

– One 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 basis

12

http://www.ittc.ku.edu/~heechul/courses/eecs753/

http://www.ittc.ku.edu/~heechul/courses/eecs750

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 …”

• Send your slides (draft) to me by 5:00 p.m. the day before your presentation

13

Project

• A team– Two is recommended but you can do alone.

• A good project– A publishable research project

• Prathap Kumar Valsan, Heechul Yun. MEDUSA: A Predictable and High-Performance DRAM Controller for Multicore based Embedded Systems IEEE Intl. Conference on Cyber-Physical Systems, Networks, and Applications (CPSNA) , 2015.

• Santosh Gondi, Siddhartha Biswas, Heechul Yun. Performance Isolation for Real-Time Applications on Multicore Platforms using PALLOC and MemGuard. Real-Time Linux Workshop , 2014. (pdf)

– A re-implementation of a published paper• E.g., “I will re-implement paper XXX on my Linux machine” ⇒ example.

14

http://www.ittc.ku.edu/~heechul/papers/memguard-palloc-rtlws14.pdf

https://code.google.com/p/dpthread/wiki/README

Project Ideas

• Some ideas will be posted on the class website

• Your own idea is the best

– Feel free to discuss with me

15

(Tentative) Project Schedule

• Feb. 15: Email me about your group– Member names

• Mar. 1: Proposal due– 1 page: include what you will build/evaluate

• Apr. 1: Midterm progress report due– 3 pages: include intro, related work, progress and plan

• May 3 (3h): Project presentation

• May. 15: Final report due– 5~8 pages: include results and conclusion– a complete paper in two-column IEEE/ACM format

16

Latex

• Everybody in CS uses it to write papers

• Proposal/midterm/final report should be written with Latex– Paper template is on the course website

• Ubuntu– $ sudo apt-get install texlive-full

• Window– Install MikTex.

– Google “latex editor”

17

http://www.ittc.ku.edu/~heechul/courses/eecs750/S14/paper_template.tar.gz

Exam

• Midterm

• But no Final exam

18

Grading

• Paper summaries (30%)

• Student presentations (10%)

• Mini project(10%)

• Quiz (10%)

• Project (40%)– Proposal: 5%

– Midterm report: 10%

– Final presentation: 10%

– Final report: 15%

19

Office Hours

• M/F 11:00 – 11:50 at 3040 Eaton

• By appoint at 236 Nichols

– [email protected]

20

mailto:[email protected]

Introduce Yourselves

• Name

• Status: grad/undergrad, year

• Relevant background

• Interests

– What do you want to learn in this class?

21

Today

• Course overview

22

Embedded Systems

• Computing systems designed for specific purpose.

• Embedded systems are everywhere

23

Embedded Systems

• More embedded systems than PC/servers

– 10 billion chips in 2013 by ARM

24http://jbpress.ismedia.jp/articles/-/36814

Embedded Systems

• Quiz. How many embedded processors are in a car?

– A: ~100s

25

Simon Fürst, BMW, EMCC2015 Munich, adopted from OSPERT2015 keynote

Trends

• More powerful and cheaper computing

• More connected

26

Internet of Things (IoT)

• IoT ~= Internet connected embedded systems

27

Cyber-Physical Systems

• Cyber Physical Systems (CPS)

– Cyber system (Computer) + Physical system (Plant)

– Still embedded systems, but integration of physical systemsis emphasized.

28

Real-Time Systems

• What is a real-time system?

– 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 the wrong time is a fault.

• CPS are often real-time systems

– Because physical process depends on time

29

30

CPS Requirements

• 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 correctness

• Performance– Large amount of data flowing from various sensors in real-time

(e.g., image processing in autonomous cars)– Many have resource constraints: size, weight, and power

(SWaP); cost

• Security– Communicate with each other, over the internet– Security must be guaranteed

31

Safety Failures

32

• Computer controlled medical X-ray treatments

• Six people died/injured due to massive overdoses (1985-1987)

• Caused by synchronization mistakes

• 7 billion dollar rocket was destroyed after 40 secs (6/4/1996)

• “caused by the complete loss of guidance and altitude information ” Caused by 64bit floating to 16bit integer conversion

Therac 25 Arian 5

Safety Failures

• Air France 447

– Pitot tube (speed sensor) failure Flight Director (FD) malfunction (shows “head up”) pilots follow the faulty FD enter stall

33

http://www.spiegel.de/international/world/experts-say-focus-on-manual-flying-skills-needed-after-air-france-crash-a-843421.html

http://www.spiegel.de/international/world/experts-say-focus-on-manual-flying-skills-needed-after-air-france-crash-a-843421.html

Safety Failures

Failures in CPS have consequences34

http://rochester.nydatabases.com/map/domestic-drone-accidents

http://petapixel.com/2015/12/23/crashing-camera-drone-narrowly-misses-top-skiier/

http://www.nytimes.com/2015/01/28/us/white-house-drone.html

http://www.nytimes.com/interactive/2016/07/01/business/inside-tesla-accident.html

NHTSA Report, 1/19/2017

• Both the radar and camera sub-systems are designed for front-to-rear collision prediction mitigation or avoidance.

• The system requires agreement from both sensor systems to initiate automatic braking.

• The camera system uses Mobileye’s EyeQ3 processing chip which uses a large dataset of the rear images of vehicles to make its target classification decisions.

• Complex or unusual vehicle shapes may delay or prevent the system from classifying certain vehicles as targets/threats

35

https://static.nhtsa.gov/odi/inv/2016/INCLA-PE16007-7876.PDF


NHTSA Report, 1/19/2017

• Object classification algorithms in the Tesla and peer vehicles with AEB technologies are designed to avoid false positive brake activations.

• The Florida crash involved a target image (side of a tractor trailer) that would not be a “true” target in the EyeQ3 vision system dataset and

• The tractor trailer was not moving in the same longitudinal direction as the Tesla, which is the vehicle kinematic scenario the radar system is designed to detect

36



Sensors in an Autonomous Car

• Audi’s Jack

37

Source: http://on-demand.gputechconf.com/gtc/2015/presentation/S5870-Daniel-Lipinski.pdf

Performance Demand in CPS

• Compute demand for cars

38Intel, “Technology and Computing Requirements for Self-Driving Cars”

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/automotive-autonomous-driving-vision-paper.pdf

Size, Weight, and Power (SWaP)

• Maximum performance with minimal resources

– Cannot afford too many or too power hungry ECUs

39Figure source: OSPERT 2015 Keynote by Leibinger

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

40

Nvidia’s Drive PX2 Platform

• 12 CPU + 2 GPU

– 8 Tegraflops @250W

• Real-time processing of

– Up to 12 cameras, radar, ..

– Deep Neural Network (DNN) for detection, classification

41http://www.nvidia.com/object/drive-px.html

CPS: Related Areas

• CPS requires inter disciplinary approach– EECS

• Computer architecture

• Real-time systems

• Formal method

• Software engineering

• Control

– Aerospace, and other engineering• Physical systems (plant/actuator) modeling/control

– Problem: each field uses different methodologies

42

Challenge: Time Predictability

• At low-level, hardware is deterministic timing

• At higher-levels, not so much ignore timing– Pipeline, caches, Out-of-order execution,

speculation, ISA

– Process, thread, lock, interrupt

• Focus on average case, not worst-case. No guarantees– Fine in cyber world

– Real-world doesn’t work that way

43

Challenge: Timing Predictability

• Q. Can you tell exactly how long a piece of code will take to execute on a computer?

– Used to be (relatively) easy to do so.

• Measure timing. Use the timing for analysis.

– Very difficult to answer in today’s computers

• Pipeline, cache, out-of-order and speculative execution, multicore, shared cache/dram very high variance.

44

Example: Real-Time Obstacle Detection and Avoidance

• Requirements: 10 frames/sec (100ms/frame)• 5X slowdown in detection speed (10fps 2fps)

– can fail to avoid obstacle• e.g., ) 10m/s aircraft (MAV) can move 1m in 100ms

45

Run-alone w/ Co-runners

CPS Challenge: Complexity

• Software complexity increases

46

Lines of Code in Typical GM Car

1

10

100

1000

10000

100000

1970 1990 2010

Model Year

KL

OC

Figures are from NASA JPL. “Flight Software Complexity,” 2008

Growth in Software Size

0

200

400

600

800

1000

1200

1400

Apollo 1968 Space Shuttle Orion (est.)

Flight Vehicle

K S

LO

C

Challenges: Complexity

• Linux: > 15M SLOC, multithreaded

Software bugs are hard to weed out

47

https://www.quora.com/How-many-lines-of-code-are-in-the-Linux-kernel

Challenges: Reliability

• Hardware bugs

– Pentium floating point bug (FDIV bug)

– Intel CPU bugs in 2015: http://danluu.com/cpu-bugs/• “Certain Combinations of AVX Instructions May Cause Unpredictable System Behavior”

• “Processor May Experience a Spurious LLC-Related Machine Check During Periods of High Activity”

• …

• Transient hardware faults (soft errors)

– Single event upset (SEU) in SRAM, logic• Due to alpha particle, cosmic radiation

– Manifested as software failures• Crashes, wrong output: silent data corruption

– Bigger problem in advanced CPU• Increased density, freq higher soft error

48

http://www.cotsjournalonline.com/articles/view/102279

http://danluu.com/cpu-bugs/

Challenges: Security

• Interconnected CPS are open to attacks

• Examples– Stuxnet: Iranian nuclear power

plant hacking

– Vermont power grid hack by Russia

– Remote hack into cars (Zeep)

– Police drone hacking

– Sensor hacking: GPS spoofing. IMU spoofing

49

https://www.washingtonpost.com/world/national-security/russian-hackers-penetrated-us-electricity-grid-through-a-utility-in-vermont/2016/12/30/8fc90cc4-ceec-11e6-b8a2-8c2a61b0436f_story.html?utm_term=.1535ff81cfdb

Topics


• CPS Applications

• Real-time multicore architecture



50Amazon prime air

Topics


– Background on Real-time scheduling theory, timing analysis, server, priority inversion


• Real-time architecture



51

Topics



– More detailed look at individual CPS applications

– Intelligent vehicle development techniques




52

Topics




– Real-time cache, DRAM controller designs

– Predictable microarchitecture designs

– Real-time support for GPU/FPGA



53

Topics





– RTOS, ARINC 653, AUTOSAR, ROS, DDS


54

Topics






– CPS specific security issues, case studies

– Simplex architecture,

– CPS modeling and verification

55

Documents

EECS 753: Embedded Real-Time Systems - KU ITTCheechul/courses/eecs753/S17/slides/W1-Intro.pdf · NHTSA Report, 1/19/2017 •Both the radar and camera sub-systems are designed for