Most embedded systems have some aspect of safety or mission criticality involved in their design. All embedded developers need to know the safety basics. But this is not a typical safety talk that crawls through the various parts of some specific safety standard. Instead, we will discuss what makes safety engineering processes different from other types of engineering activities, how to think about safety when the loss event is less dramatic than an airplane falling out of the sky, and how to determine how much and what kind of safety engineering you need for your system.

This approach will give attendees a robust framework for thinking about safety without getting caught up in the details of any particular safety standard.

13:33:45 From Phil KOOPMAN to Everyone:
	Hi everyone -- you're watching me from a couple days (edited to remove the goofs).  Real me is here live. Happy to do minor discussion.  I'll also do live Q&A at the end.
	
13:35:38 From Phil KOOPMAN to Everyone:
	I stopped counting at 200 embedded design reviews and other interactions covering all those industries. And shipping some real products too. So this talk is based on a lot of dirt under my fingernails over the last 45 years.
	
13:38:05 From Viktor to Everyone:
	Hello BTW, is the keynote recorded?..
	
13:38:41 From Phil KOOPMAN to Everyone:
	You are watching a recording, so playback is available later for attendees.  (Meanwhile I am here live on chat)
	
13:39:00 From Viktor to Everyone:
	Great! Tnx)
	
13:41:22 From Phil KOOPMAN to Everyone:
	Hint: giving a hammer to a robot is an exceptionally bad idea 😂
	
13:41:37 From RF to Everyone:
	Any suggestions how one can vet Engineers in Safety Critical roles ... psychological elements!?
	
13:42:50 From Phil KOOPMAN to Everyone:
	Replying to "Any suggestions how one can vet Engineers in Safet...":
	Not a psychologist -- but it shares something with picking testers. It helps that they can think about what might go wrong.  But also engineering ability to create requirements.  We'll get there as we go.
	
13:44:16 From RF to Everyone:
	... tbc. Some Engineers 'go the extra mile!'
	
13:44:46 From Daniel Mendez-Lozada to Everyone:
	"Premature optimization is the root of all evil." D. Knuth
	
13:45:19 From Phil KOOPMAN to Everyone:
	Replying to "... tbc. Some Engineers 'go the extra mile!'":
	Some engineers make good safety engineers. Some engineers make good testers. But they are different although overlapped skill sest
	
13:46:37 From Pan to Everyone:
	could you recommand some books about this topic (safety enginner)
	
13:51:00 From Phil KOOPMAN to Everyone:
	The book coverage is somewhat thin.  A couple old classics:   Safeware by Leveson 1995;   "Safety critical computer systems" Storey 1996.  There might be newer ones that are good, but a lot of them are specialized.  A specialized one I like is "Fundamentals of Dependable Computing" Knight 2012
	
13:52:37 From Lloyd Moore to Everyone:
	I found "Developing Safety-Critical Software" by Rierson to be good.
	
13:52:38 From Otzen to Everyone:
	@RF Regarding psychological elements, you also have to facilitate an environment where failng is acceptet as human narure. You don't want a safe-developer trying to cover up mistakes.
	
13:52:42 From Phil KOOPMAN to Everyone:
	Would be happy to hear of examples for others.  There are other books that are specific to particular safety standards etc. rather than more general discussions  (For example  UL 4600 Guidebook, Koopman 2022 )
	
13:53:27 From Phil KOOPMAN to Everyone:
	Replying to "I found "Developing Safety-Critical Software" by R...":
	Thanks. I have been down the robotaxi safety rabbit hole for a while and have not done a book search in a while
	
13:53:47 From Phil KOOPMAN to Everyone:
	Replying to "@RF Regarding psychological elements, you also hav...":
	Yes, that is safety culture. We'll get there
	
13:54:19 From dteubl to Everyone:
	Replying to "could you recommand some books about this topic (s...":
	Embedded Software Development for Safety-Critical Systems by Chris Hobbs, has a good summary of the basics, overview of some standard for us and soem collection of tools. I highly recommend it.
	
13:58:54 From Eric Habets to Everyone:
	Replying to "could you recommand some books about this topic (s...":
	There are even three switches at the door of micro wave ovens ...
	
13:59:26 From dteubl to Everyone:
	The 'Software for Dependable systems - sufficient evidence?, National Researh Council, 2007", is quite old as well, but has some good and timeless advice.
	
14:00:22 From Phil KOOPMAN to Everyone:
	Replying to "could you recommand some books about this topic (s...":
	@Eric Habets   Yes, multiple switches helps. But then you need to throw a fault code when one or two switches fail rather than waiting for the third one to fail. And hope there are no common cause failures (that part is coming up soon).
	
14:02:48 From Phil KOOPMAN to Everyone:
	Replying to "The 'Software for Dependable systems - sufficient ...":
	I remember that one.  There is an imponderable that we have quite a lot of empirical evidence that safety standards are effective if followed in a reasonable way. But it is very difficult to pin down the individual contribution of each part of any particular standard.  So cherry-picking engineering rigor topics is fraught.  (you'll see the rigor table momentarily)
	
14:05:47 From Otzen to Everyone:
	MISRA dosn't help the compiler, it tries to help the reviwer :-)
	
14:07:01 From Phil KOOPMAN to Everyone:
	Replying to "MISRA dosn't help the compiler, it tries to help t...":
	To be clear, MISRA conformance:  (1) avoids undefined/ambiguous parts of the language, (2) avoids known dangerous parts of the language that are unambiguous (for example   if (a=b) {}   is well defined, but dangerous)
	
14:08:03 From Phil KOOPMAN to Everyone:
	Replying to "MISRA dosn't help the compiler, it tries to help t...":
	For (1) what you can see is different compilers or even different versions of the same compiler generating different code.
	
14:10:43 From James Grenning to Everyone:
	Why isn't "dynamic analysis" a.k.a. automated testing, one of the mitigation recommendations?   Did I miss that? 
	
14:11:42 From Phil KOOPMAN to Everyone:
	Replying to "Why isn't "dynamic analysis" a.k.a. automated test...":
	There are many, many pages of tables in a real standard. So I just picked some arbitrary stuff to include.  Something being left off does not mean anything on that slide.
	
14:12:40 From James Grenning to Everyone:
	Replying to "Why isn't "dynamic analysis" a.k.a. automated test...":
	Roger
	
14:14:31 From Phil KOOPMAN to Everyone:
	Silent data corruption is getting to be more of a problem these days, especially on really big compute tasks.
	
14:14:46 From Phil KOOPMAN to Everyone:
	Anyone remember when an IBM PC came with memory parity?
	
14:15:44 From Eric Habets to Everyone:
	Replying to "Anyone remember when an IBM PC came with memory pa...":
	Mid 1980?
	
14:16:15 From AndyH to Everyone:
	the 5 space shuttle computers
	
14:16:18 From Otzen to Everyone:
	The thing that I have seen that often required a re-think, is assumptions about an input being there. I.e. if I need to shut down in case temperature gets too high, won't be safe if the temperature sensor broke yesterday, and nothing detected that.,
	
14:16:19 From Phil KOOPMAN to Everyone:
	Replying to "Anyone remember when an IBM PC came with memory pa...":
	early 80s.   16KB motherboard upgraded to 64KB with four banks of DRAM 😁
	
14:18:50 From Phil KOOPMAN to Everyone:
	Typically you see hard-core cross-check at SIL 3 & SIL 4.  SIL 1 & SIL 2 are more likely to have self-check or something lighter weight.   A really common safety error is using lightweight checks (e.g., watchdog timer) at a higher SIL than one should.
	
14:22:29 From Phil KOOPMAN to Everyone:
	It is common for companies to rationalize rounding "???" down toward lower risk. That is baked into some standards such as ISO 26262.  And every once in a while that decision bites back.
	
14:26:44 From Otzen to Everyone:
	yes the understaffing in safe/sys eng. is funny. From my limited experience in safe SW, the procedures there added to much to the code quality. That I estimate we saved more than we spendt ;-)
	
14:28:24 From Jui Yen Chua to Everyone:
	Any software tools that you recommend using for safety engineering? Thanks for your time!
	
14:30:17 From garyb to Everyone:
	Is there any hope for a small entity (limited team) to produce a qualified product with somewhat high operational risks - i.e. a utility vehicle.
	
14:31:20 From BanksG02 to Everyone:
	I thought "fail silent" meant to not indicate failure if it happens, which is surely a bad thing. "Fail silent strategy" was mentioned and my understanding was that a system would shut itself down silently if it failed. Did I misunderstand the strategy?
	
14:32:05 From Pan to Everyone:
	you mentioned safety musts designed in from start of project. Do you have any good practices or good habits from your experiences especially for a big project? 
	
14:32:16 From Otzen to Everyone:
	Talking tools, I have yet to see a good requirement tracking tool.
	None of the tools realize that a product requirement, almost newer leads to a piece of code, there is almost always a design decision in between.
	Ex. "shall operate in -20 to +50 deg. cel.". Then a design is done that involves a fan, this design puts requirement on the regilation of that fan.
	
14:35:22 From Raul Pando to Everyone:
	Do you have any opinion on what programming langagues are more conducive to safety based on your experience in industry?
	
14:35:48 From Viktor to Everyone:
	So in some sort, fail silent means to prefer Specificity over Sensibility ?
	
14:36:12 From nyquist to Everyone:
	Any recommendations on how to avoid the analysis that can lead to paralysis in maintaining one's perspective?
	
14:40:36 From RF to Everyone:
	Does UML (Unified Modelling Language) assist, and to what extent, in the Safety Critical Development cycle?
	
14:43:54 From BanksG02 to Everyone:
	Back in the 90's, assembly language was used in preference to compiled languages in the interests of provability. Has this changed?
	
14:44:49 From Phil KOOPMAN to Everyone:
	UL 4600
	
14:45:44 From Pan to Everyone:
	the AI is now applied in the autonomous driving area. Since the decision of AI is more like black-box, how can we ensure that the use of AI in the self-driving is safe?
	
14:52:37 From RF to Everyone:
	Thinking from the start (Day 1), prior everything is perhaps the key, for Safety Critical .... just like Security Critical! All too often, it is left until the end! Your comments please regarding this tragedy?
	
14:54:22 From nyquist to Everyone:
	This relates to programming. What measures and recommendations do you have in addressing the reliability of an RTOS as it relates to t states?
	
14:58:44 From Stephane to Phil KOOPMAN (direct message):
	THANK YOU Phil!
	
14:59:55 From Luke Hoffman to Everyone:
	Thanks! It was a great presentation!
	
14:59:56 From Eric Habets to Everyone:
	Thank you!
	
14:59:56 From AndyH to Everyone:
	Great info!  Thank you!
	
14:59:57 From Raul Pando to Everyone:
	Thanks Phil, always a pleasure 
	
15:00:03 From Chaance Graves to Everyone:
	Thank you!
	
15:00:03 From BanksG02 to Everyone:
	Thank you.
	
15:00:06 From Pan to Everyone:
	thank you very much
	
15:00:06 From Lloyd Moore to Everyone:
	Awesome talk! Thanks!!
	
15:00:10 From Vishwa to Everyone:
	Thanks for the great presentation
	
15:00:20 From Carlos Hidalgo to Everyone:
	Thank you! Great presentation
	
15:00:13 From dteubl to Everyone:
	Great Talk, Thanks!
	
15:00:15 From Oliver to Everyone:
	Thank you!
	
15:00:17 From Viktor to Everyone:
	Thanks a lot !
	
15:00:23 From Nick Tillich to Everyone:
	thank you!
	
15:00:20 From Andrew to Everyone:
	Thank you