Companion blog to the book Better Embedded System Software by Phil Koopman at Carnegie Mellon University
Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we see the problem that a static analysis tool or other way of automatically finding bugs inundates developers with so many possible bugs they turn it off in frustration. Or maybe they have a requirement to ship only "clean" code so they don't run the tool because…
I sometimes get requests from LinkedIn contacts about help deciding between job offers. I can't provide personalize advice, but here are my thoughts in general. You must accept personal ownership for choosing what you want to do with at least the next few years of your life. Nobody can do this for you. Some luck is always involved, but fortune favors the prepared. It is up to you to set your own…
Here is a brief piece I wrote that Jack Ganssle just ran in The Embedded Muse 460. The context was a previous discussion about enabling compiler warnings. John Carter's suggestion to use compiler warnings as a first step toward coding standards is an important one. I tend to split these up into "coding style for people" and "coding styles for the compiler." Often we talk about indenting curly…
There are only a handful of hardcover books left of the first edition, so I spend some time converting things over to an eBook & Paperback edition. Amazon Kindle: https://amazon.com/gp/product/B08TZ9LYXC Smashwords (epub): https://www.smashwords.com/books/view/1264918 Barnes & Noble (ebook): https://www.barnesandnoble.com/s/philip%20koopman This is not a 2nd edition, but more like version 1.1. The…
In the coming years, there will be other time rollovers beyond Y2K. The next big one isn't all that far away. Contrary to what you might have heard, the reason more computers didn't break on Jan 1st 2000 wasn't because it was a false alarm. It was because massive resources were poured into avoiding many of the problems. And many things did in fact break, but backup plans were in place. (I recall…
Karl Weigers has an essay about lessons he's learned from a long career in software development. You should benefit from his experience. The essay covers requirements, project management, quality, process improvement, and other insights. https://medium.com/swlh/62-lessons-from-50-years-of-software-experience-2db0f400f706 A good example from the article is: "You don’t have time to make every…
https://pixabay.com/vectors/code-programming-head-computer-2858768/ Once in a while I run into developers who think that peer review can be completely automated by using a good static analysis (generically "lint" or compiler warnings). In other words, run PC-LINT (or whatever), and when you have no warnings peer review is done. Nope. But the reality has some nuance, so here's how I see it. There…
In October 2018 Hong Kong had "six hours of turmoil" in their rail service due to as signalling outage. The culprit has now been identified as counter roll-over. https://www.scmp.com/news/hong-kong/transport/article/2178723/unknown-signalling-system-incompatibility-caused-october South China Morning Post…
Generally you need to take into account both the consequence of a software defect as well as how often it occurs when doing bug triage. (See: Using a Risk Analysis Table to Categorize Bug Priority ) But an important special case is one in which the consequence is a business consequence such as brand tarnish rather than a spectacular software crash. I used to use a hypothetical example of the…
It's always interesting to see data on industry software costs. I recently came across a report on software costs for the aviation industry. The context was flight-critical radio communications, but the safety standards discussed were DO-178B and DO-254, which apply to flight controls as well. Here's the most interesting picture from the report for my purposes: (Source: Page 28…
Page moved here: https://betterembsw.blogspot.com/p/potentially-deadly-automotive-software.html
When we talk about how much risk is enough, it is common to do things like compare the risk to current systems, or argue about whether something is more (or less) likely than events such as being killed by lightning. There are established ways to think about this topic, each with tradeoffs. The next time you need to think about how much risk is appropriate in a safety-critical system, try these…
For those who might have missed it, most of my recent blogging has been on my Safe Autonomy Blog: https://safeautonomy.blogspot.com Recent post topics include slides and paper preprints such as: Robustness Testing of Autonomy Software (ICSE 2018) Safety Validation and Edge Case Testing for Autonomous Vehicles Heavy Tail Ceiling Problem for AV Testing Toward a framework for Highly Automated Vehicle…
I've posted the full series of my available embedded system code quality and related best practices videos on YouTube. These are full-length narrated slides of the core set of safety topics from my new course. They concentrate on getting the big picture about code quality and good programming practices. Code Quality, Safety, Security overview Global Variables Spaghetti Code Coding Style for Humans…
I'm doing a lot more work on self-driving car (autonomous vehicle) safety, so I've decided to split my blogging for that activity. I'll still post more general embedded system topics here, perhaps with reduced frequency. You can see my new blog on self-driving car safety here: https://safeautonomy.blogspot.com Just to keep perspective, self-driving cars are still very complex embedded systems. You…
I'm very pleased that our research team will present a paper on Robustness Testing of Autonomy Software at the ICSE Software Engineering in Practice session in a late May. You can see a preprint of the paper here: https://goo.gl/Pkqxy6 The work summarizes what we've learned across several years of research stress testing many robots, including self-driving cars. ABSTRACT As robotic and autonomy…
Here's a new peer review checklist to help improve the quality of your embedded C code. To use the checklist, you should do a sit-down meeting with, ideally, three reviewers not including the code author. Divide the checklist up into three portions as indicated. Be sure to run decent static analysis before the review to safe reviewer time -- let the tools find the easy stuff before spending human…
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…
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…
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…
Here are the slides from my AV17 Presentation on self-driving car safety: Challenges and Solutions in Autonomous Vehicle Validation from Philip Koopman
I've had to review code that has spaghetti-level complexity in control flow (too high cyclomatic complexity). And I've had to review code that has spaghetti-level complexity its data flow (too many global variables mixed together into a single computation). And I've had to review procedures that just go on for page after page with no end in sight. But the stuff that will really make your brain…
It is common to see small helper functions implemented as macros, especially in older C code. Everyone seems to do it. But you should avoid macros, and instead use inline functions. The motivation for using macros was originally that you needed to use a small function in many places but were worried about the overhead of doing a subroutine call. So instead, you used a macro, which expands into…
Is your code full of "#define" statements? If so, you should consider switching to the const keyword. Old school C: #define MYVAL 7 Better approach: const uint32_t myVal = 7; Here are some reasons you should use const instead of #define: #define has global scope, so you're creating (read-only) global values every time you use #define. Global scope is evil, so don't do that. (Read-only global scope…
Geralt / CC0 PD/noattrib. Writing code should be made more difficult so that Verification &Validation can be made easier. I first heard this notion years ago at a workshop in which several folks from industry who build high assurance software (think flight controls) stood up and said that V&V is what matters. You might expect that from flight control folks, but their reasoning applies to pretty…