Embedded Software Course Notes On-Line

I'm just wrapping up my first semester teaching a new course on embedded system software. It covers code quality, safety, and security. Below is table of lecture handouts.

NOTE: there is an update here:
     https://users.ece.cmu.edu/~koopman/lectures/index.html#642
which includes newer course notes and quite a few YouTube videos of these lectures.
You should use that URL instead of this blog post, but I've left this post as-is for Fall 2017.

18-642 Embedded System Software Engineering
Prof. Philip Koopman, Carnegie Mellon University, Fall 2017

	Slides	Topics
1	Course Introduction	Software is eating the world; embedded applications and markets; bad code is a problem; coding is 0% of software; truths and management misconceptions
2	Software Development Processes	Waterfall; swiss cheese model; lessons learned in software; V model; design vs. code; agile methods; agile for embedded
3	Global Variables	Global vs. static variables; avoiding and removing globals
4	Spaghetti Code	McCabe Cyclomatic Complexity (MCC); SCC; Spaghetti Factor (SF)
5	Unit Testing	Black box testing; white box testing; unit testing strategies; MCDC coverage; unit testing frameworks (cunit)
6	Modal Code/Statecharts	Statechart elements; statechart example; statechart implementation
7	Peer Reviews	Effective code quality practices, peer review efficiency and effectiveness; Fagan inspections; rules for peer review; review report; perspective-based reviews; review checklist; case study; economics of peer review
8	Code Style/Humans	Making code easy to read; good code hygiene; avoiding premature optimization; coding style
9	Code Style/Language	Pitfalls and problems with C; language use guidelines and analysis tools; using language wisely (strong typing); Mars Climate Orbiter; deviations & legacy code
10	Testing Quality	Smoke testing, exploratory testing; methodical test coverage; types of testing; testing philosophy; coverage; testing resources
11	Requirements	Ariane 5 flight 501; rules for good requirements; problematic requirements; extra-functional requirements; requirements approaches; ambiguity
12	System-Level Test	First bug story; effective test plans; testing won't find all bugs; F-22 Raptor date line bug; bug farms; risks of bad software
13	SW Architecture	High Level Design (HLD); boxes and arrows; sequence diagrams (SD); statechart to SD relationship; 2011 Health Plan chart
14	Integration Testing	Integration test approaches; tracing integration tests to SDs; network message testing; using SDs to generate unit tests
15	Traceability	Traceability across the V; examples; best practices
16	SQA isn't testing	SQA elements; audits; SQA as coaching staff; cost of defect fixes over project cycle
17	Lifecycle CM	A400M crash; version control; configuration management; long lifecycles
18	Maintenance	Bug fix cycle; bug prioritization; maintenance as a large cost driver; technical debt
19	Process Key Metrics	Tester to developer ratio; code productivity; peer review effectiveness
33	Date Time Management	Keeping time; time terminology; clock synchronization; time zones; DST; local time; sunrise/sunset; mobility and time; date line; GMT/UTC; leap years; leap seconds; time rollovers; Zune leap year bug; internationalization.
21	Floating Point Pitfalls	Floating point formats; special values; NaN and robots; roundoff errors; Patriot Missile mishap
23	Stack Overflow	Stack overflow mechanics; memory corruption; stack sentinels; static analysis; memory protection; avoid recursion
25	Race Conditions	Therac 25; race condition example; disabling interrupts; mutex; blocking time; priority inversion; priority inheritance; Mars Pathfinder
27	Data Integrity	Sources of faults; soft errors; Hamming distance; parity; mirroring; SECDED; checksum; CRC
20	Safety+Security Overview	Challenges of embedded code; it only takes one line of bad code; problems with large scale production; your products live or die by their software; considering the worst case; designing for safety; security matters; industrial controls as targets; designing for security; testing isn't enough Fiat Chrysler jeep hack; Ford Mytouch update; Toyota UA code quality; Heartbleed; Nest thermostats; Honda UA recall; Samsung keyboard bug; hospital infusion pumps; LIFX smart lightbulbs; German steel mill hack; Ukraine power hack; SCADA attack data; Shodan; traffic light control vulnerability; hydroelectric plant vulnerability; zero-day shopping list
22	Dependability	Dependability; availability; Windows 2000 server crash; reliability; serial and parallel reliability; example reliability calculation; other aspects of dependability
24	Critical Systems	Safety critical vs. mission critical; worst case and safety; HVAC malfunction hazard; Safety Integrity Levels (SIL); Bhopal; IEC 61508; fleet exposure
26	Safety Plan	Safety plan elements; functional safety approaches; hazards & risks; safety goals & safety requirements; FMEA; FTA; safety case (GSN)
28	Safety Requirements	Identifying safety-related requirements; safety envelope; Doer/Checker pattern
29	Single Points of Failure	Fault containment regions (FCR); Toyota UA single point failure; multi-channel pattern; monitor pattern; safety gate pattern; correlated & accumulated faults
30	SIL Isolation	Isolating different SILs, mixed-SIL interference sources; mitigating cross-SIL interference; isolation and security; CarShark hack
31	Redundancy Management	Bellingham WA gasoline pipeline mishap; redundancy for availability; redundancy for fault detection; Ariane 5 Flight 501; fail operational; triplex modular redundancy (TMR) 2-of-3 pattern; dual 2-of-2 pattern; high-SIL Doer/Checker pattern; diagnostic effectiveness and proof tests
32	Safety Architecture Patterns	Supplemental lecture with more detail on patterns: low SIL; self-diagnosis; partitioning; fail operational; voting; fail silent; dual 2-of-2; Ariane 5 Flight 501; fail silent patterns (low, high, mixed SIL); high availability mixed SIL pattern
34	Security Plan	Security plan elements; Target Attack; security requirements; threats; vulnerabilities; mitigation; validation
35	Cryptography	Confusion & diffusion; Caesar cipher; frequency analysis; Enigma; Lorenz & Colossus; DES; AES; public key cryptography; secure hashing; digital signatures; certificates; PKI; encrypting vs. signing for firmware update
36	Security Threats	Stuxnet; attack motivation; attacker threat levels; DirectTV piracy; operational environment; porous firewalls; Davis Besse incident; BlueSniper rifle; integrity; authentication; secrecy; privacy; LG Smart TV privacy; DoS/DDos; feature activation; St. Jude pacemaker recall
37	Security Vulnerabilities	Exploit vs. attack; Kettle spambot; weak passwords; master passwords; crypto key length; Mirai botnet attack; crypto mistakes; LIFX revisited; CarShark revisited; chip peels; hidden functionality; counterfeit systems; cloud connected devices; embedded-specific attacks
38	Security Mitigation Validation	Password strength; storing passwords & salt/pepper/key stretching; Adobe password hack; least privilege; Jeep firewall hack; secure update; secure boot; encryption vs. signing revisited; penetration testing; code analysis; other security approaches; rubber hose attack
39	Security Pitfalls	Konami code; security via obscurity; hotel lock USB hack; Kerckhoff's principle; hospital WPA setup hack; DECSS; Lodz tram attack; proper use of cryptography; zero day exploits; security snake oil; realities of in-system firewalls; aircraft infotainment and firewalls; zombie road sign hack

Note that in Spring 2018 these are likely to be updated, so if want to see the latest also check the main course page:  https://www.ece.cmu.edu/~ece642/   For other lectures and copyright notes, please see my general lecture notes & video page: https://users.ece.cmu.edu/~koopman/lectures/index.html

Read More

Highly Autonomous Vehicle Validation

Here are the slides from my TechAD talk today.

Highly Autonomous Vehicle Validation from Philip Koopman

Highly Autonomous Vehicle Validation: it's more than just road testing!
- Why a billion miles of testing might not be enough to ensure self-driving car safety.
- Why it's important to distinguish testing for requirements validation vs. testing for implementation validation.
- Why machine learning is the hard part of mapping autonomy validation to ISO 26262

Read More

Need For Speed Rivals PC Car Racing Game

Need For Speed Rivals PC Car Racing Game

Need for Speed Rivals is a racing video game set in an open world environment. Developed by Swedish and British developers Ghost Games and Ghost Games UK and developer Criterion Games, this is the twentieth installment in the long-running Need for Speed series.

Rivals feature a rapturous gameplay bearing some resemblance to the earlier Hot Pursuit, with exotic cars and high-speed police chases. Players take on the role of a Racer or a Cop, with each side of the law offering its own set of challenges, risks, and rewards. Rivals feature eleven upgradeable gadgets such as EMPs, shockwaves and the ability to call in roadblocks. The game takes place in a fictional location known as Review County. It’s an open world and features over 100 miles (160 km) of open road, larger than that of 2012’s Need for Speed Most Wanted, but on the same size as Criterion’s Hot Pursuit. The open world features a similar set-up to Most Wanted, with several jumps, speed traps, and unlockable cars, as well as shortcuts that are not shown on the map.

Rivals feature a full career progression for both Cop and Racer. When playing as a Cop, there are three types of career that can be followed – patrol, enforcer, and undercover. Progression is by means of Speedlists for Racer and Assignments for Cop, which are sets of objectives which involve dangerous driving, maneuvers, and race standings. When the player completes a set of objectives, the player levels up and unlocks items, and is presented with another set of objectives to choose from. The Autolog system, a competition-between-friends system developed by Criterion for Hot Pursuit and since used in other titles in the Need for Speed series, factors into the progression system, comparing how quickly the player complete an Assignment or Speedlist to other players’ times and posts them to a Speed Wall for local and global leaderboards.

Rivals feature a new social system called the AllDrive, which allow players to seamlessly transition from playing alone to playing with friends, described as “destroying the line between single player and multiplayer”. This allows players to in engage co-op gameplay as well as play against each other. The game also features a dynamic weather system, which makes “the world feel alive in a much bigger sense than any other Need for Speed game.”

Rivals also take on some gameplay styles of earlier Underground titles in the franchise with cues on aesthetic vehicle personalization, as paint jobs, decals, rims and license plates and liveries can be modified, as well as vehicle performance, and various Pursuit Tech gadgets. With the exception of the Aston Martin Vanquish, other vehicles are only available in either racer or police variant. Ferrari officially returns to the franchise in full form for the first time in eleven years since Hot Pursuit 2 in 2002 (although they’ve appeared in 2009’s Shift as Xbox 360-exclusive downloadable content) with the F12berlinetta, 458 Spider, 458 Italia, FF, Enzo, and 599 GTO being the Ferrari vehicles featured.

Read More

SWAT 4 PC Game Free Download Full Action PC Game

SWAT 4 PC Game Free Download Full Action PC Game

SWAT 4 is a tactical first-person shooter video game developed by Irrational Games and published by Muhammad Niaz Games on FEB 16, 2014. SWAT 4 uses the concept of authorized and unauthorized use of weapons. Most situations require the officers to give the suspect a warning to give them the chance to surrender. Shooting without warning is considered unauthorized use of force or deadly force, depending on whether the player kills the suspect. A non-compliant suspect that does not point his weapon at another person may not be lawfully shot. A single unauthorized use of force deducts 5 points, while deadly force deducts 10 points in addition to the loss of score because of not taking suspects alive. Shooting without warning is allowed if the suspect is pointing their weapon at a hostage or a SWAT team member or if they open fire. Suspect reactions to warnings differ some may attempt to hide and set up an ambush, some immediately surrender, others will flee and some will open fire. Some suspects may also pretend to surrender and open fire or run. If a hostage is killed, the mission is automatically deemed a failure.The characters in SWAT 4 are easily injured. Even though all members of the element are equipped with armor, they can be incapacitated quickly. If the player is incapacitated, then the mission ends in failure. Lightly wounded players suffer gameplay penalties depending on injury locations. Leg injuries result in a limp, and arm injuries result in loss of accuracy.

System= Pentium IV CPU 1.4 GHz

RAM= 512 MB

Size= 780.1 MB

Video Memeory= 64 MB
OS= Windows 98 ME 2000 XP Vista 7 and Windows 8

Read More

Adobe premiere pro cc free download full register

Adobe premiere pro cc free download full register

Adobe Premier pro cc free download. This guide will be straightforward and brief on how you cant activate Adobe Premiere Pro CC for free. Activating Adobe product with crack is very safe, not that Activating with an Adobe Premiere Pro serial key is not good... Unless you want to get silly notification updates, using Adobe Premiere Pro crack will automatically block does update and giving you access to your Adobe product even if your trial period is over, Now a guide to install activate your Adobe product with our Adobe pro keygen.

• Intel Core2 Duo or AMD Phenom II processor with 64-bit support.
• Microsoft Windows 7 with Service Pack 1 (64-bit) or Windows 8 (64-bit)
• 4 GB of RAM (8 GB recommended)
• 4GB of available hard- disk space for installation, additional free space  required during installation ( can not removable flash storage devices)
• 1 280 x 800 display with OpenGL 2.0- compatible graphics card
• Windows 7 with Service Pack 1, Windows 8, and windows 8.1 

Read More

Need for Speed 2 Fulll Edition Free Download

Need for Speed 2 Fulll Edition Free Download

Need for Speed 2 Special Edition  is a 1997 racing video game, developed by Electronic Arts Canada and published by Electronic Arts. It is a part of the Need for Speed series and sequel to The Need for Speed (1994), significantly deviating from the emphasis of realism in The Need for Speed to arcade-like gameplay, though it introduces the car tuning. As does its predecessor, Need for Speed II features several exotic cars, and includes tracks set in various parts of the world. The game also opted to remove police pursuits introduced in The Need for Speed.

Cheats Result
vip – Limousine
schoolzone – School Bus
madland – Wooden Stand
rexhour – Tyrannosaurus Rex
go18 – School Bus
go19 – Commanche Pick-up Truck
go20 – School Bus
go21 – Tractor Trailer
go22 – School Bus
go23 – Audi Quattro
go24 – School Bus
go25 – School Bus
go26 – Mercedes-Benz
go27 – Volkswagen Fastback
go28 – Mazda Miata
go29 – School Bus
go30 – School Bus
go31 – Mercedes Unimog Army Truck
go32 – School Bus
go33 – Mercedes Unimog Snow Truck
go34 – Monolithic Studios Tour Bus
go35 – Limousine
go36 – Mazda Miata
go37 – School Bus
go38 – School Bus
go39 – School Bus
go40 – Wooden Box
go41 – Hand Cart
go42 – Wooden Stand
go43 – Tyrannosaurus Rex
go44 – Wild West Style Wagon
go45 – Souvenir Stand 1
go46 – Souvenir Stand 2
go47 – Souvenir Stand 3
go48 – Log
go49 – Crate 1
go50 – Box of Beer
go51 – Block of Rock

North Country shortcut:

As you just pass through the blue tunnel suddenly
apply brakes and move to the right. You will be over
to the next road! It will save your 7 to 9 seconds.

Pacific Spirit shortcut:

Just before you reach the 180° turn you will see a
pathway on your left. Slow down and move to the left.
It can really improve your position if you are quick!

Cheat:

roadrage – this cheat enables the car to turn by itself
when ‘h’ (HORN) is pressed and when a opponent comes
near it gets thrown away.

Cheat:

Type these cheats in the main menu.

CHEATS – THEIR WORK
FZR2000 – gives u a bunus car(fastest)
Bomberbfs – gives u a bunus carschoolzone – gives u a bus.
vip – Makes all vehicles (including traffic)
limousines.
slip – Enables super slip ‘n’ slid mode. Makes
the cars skid more
than usual. Cooks some awesome doughnuts!
tombstone – Bonus car
bomber – Bonus car
rushhour – ?
fzr2000 – SUPER bonus car
pioneer – Pioneer mode, very FASThollywood – Secret track

System= Pentium II CPU 233 MHz
RAM= 16 MB
Size= 74 MB
Video Memory= 8 MB
OS= Windows 98 ME 2000 XP

Read More

Top Five Embedded Software Management Misconceptions

Here are five common management-level misconceptions I run into when I do design reviews of embedded systems. How many of these have you seen recently?

(1) Getting to compiled code quickly indicates progress. (FALSE!)

Many projects are judged by "coding completed" to indicate progress.  Once the code has been written, compiles, and kind of runs for a few minutes without crashing, management figures that they are 90% there.  In reality, a variant of the 90/90 rule holds:  the first 90% of the project is in coding, and the second 90% is in debugging.

Measuring teams on code completion pressures them to skip design and peer reviews, ending up with buggy code. Take the time to do it right up front, and you'll more than make up for those "delays" with fewer problems later in the development cycle.  Rather than measure "code completed" do something more useful, like measure the fraction of modules with "peer review completed" (and defects found in peer review corrected).  There are many reasonable ways to manage, but waterfall-ish projects that treat "code completed" as the most critical milestone is not one of them.

(2) Smart developers can write production-quality code on a long weekend (FALSE!)

Alternate form: marketing sets both requirements and end date without engineering getting a chance to spend enough time on a preliminary design to figure out if it can actually be done.

The true bit is anyone can slap together some code that doesn't work.  Some folks can slap together code in a long weekend that almost works.  But even the best of us can only push so many lines of code in a short amount of time without making mistakes, much less producing something anyone else can understand.  Many of us remember putting together hundreds or thousands of lines on an all-nighter when we were students. That should not be mistaken for writing production embedded code.

Good embedded code tends to cost about an hour for every 1 or 2 lines of non-comment code all-in, including testing (on a really good day 3 lines/hr).  Some teams come from the Lake Wobegone school, where all the programmers are above average.  (Is that really true for your team?  Really?  Good for you!  But you still have to pay attention to the other four items on this list.)  And sure, you can game this metric if you try. Nonetheless, it is remarkable how often I see a number well above about 2 SLOC/hour of deeply embedded code corresponding to a project that is in trouble.

Regardless of the precise productivity number, if you want your system to really work, you need to treat software development as a core competency.  You need an appropriately methodical and rigorous engineering process. Slapping together code quickly gives the illusion of progress, but it doesn't produce reliable products for full-scale production.

(3) A “mostly working,” undisciplined prototype can be deployed.  (FALSE!)

Quick and dirty prototypes provide value by giving stakeholders an idea of what to expect and allowing iterations to converge on the right product. They are invaluable for solidifying nebulous requirements. However, such a prototype should not be mistaken for an actual product!   If you've hacked together a prototype, in my experience it's always more expensive to clean up the mess than it is to take a step back and start a project from scratch or a stable production code base.

What the prototype gives you is a solid sense of requirements and some insight into pitfalls in design.

A well executed incremental deployment strategy can be a compromise to iteratively add functionality if you don't know all your requirements up front. But an well-run Agile project is not what I'm talking about when I say "undisciplined prototype." A cool proof of concept can be very valuable.  It should not be mistaken for production code.

(4) Testing improves software quality (FALSE!)

If there are code quality problems (possibly caused by trying to bring an undisciplined prototype to market), the usual hammer that is brought to bear is more testing.  Nobody ever solved code quality problems by testing. All that testing does is make buggy code a little less buggy. If you've got spaghetti code that is full of bugs, testing can't possibly fix that. And testing will generally miss most subtle timing bugs and non-obvious edge cases.

If you're seeing lots of bugs in system test, your best bet is to use testing to find bug farms. The 90/10 rule applies: many times 90% of the bugs are in bug farms -- the worst 10% of the modules. That's only an approximate ratio, but regardless of the exact number, if you're seeing a lot of system test failures then there is a good chance some modules are especially bug-prone.  Generally the problem is not simply programming errors, but rather poor design of these bug-prone modules that makes bugs inevitable. When you identify a bug farm, throw the offending module away, redesign it clean, and write the code from scratch. It's tempting to think that each bug is the last one, but after you've found more than a handful of bugs in a module, who are you kidding? Especially if it's spaghetti code, bug farms will always be one bug away from being done, and you'll never get out of system test cleanly.

(5) Peer review is too expensive (FALSE!)

Many, many projects skip peer review to get to completed code (see item #1 above). They feel that they just don't have time to do peer reviews. However, good peer reviews are going to find 50-75% of your bugs before you ever get to testing, and do so for about 10% of your development budget.  How can you not afford peer reviews?   (Answer: you don't have time to do peer reviews because you're too busy writing bugs!)

Have you run into another management misconception on a par with these? Let me know what you think!

Read More