Home > On-Demand Archives > Keynote Presentations >
Learning from Disaster
Jack Ganssle - Watch Now - EOC 2022 - Duration: 01:17:57
Boeing 737 pilot explains what can be learnt/learned from flight disasters:
https://www.youtube.com/c/MentourPilotaviation/videos
It shows me that details matter.
Great talk. +1 for asserts for detecting design bugs and contracts. I often wonder how requirements complexity affects reliability - we treat firmware as able to implement almost any functionality, but should it? Can we also write less buggy manual code, by using qualified code generators such as SCADE?
The recording has been posted.
Cannot access the Zoom call because maximum capacity has been reached. Well done!
Should be able to join now.
There was a setting on Zoom that wasn't properly set.
Sorry about that.
I had to punt after being shut out. How soon before the no longer live playback is available?
We'll try to process and upload the recording this afternoon.
Thank you!
Available now!
Thanks!
Same here. :(
Great talk! Will the slides be available for download?
14:13:31 From Clayton.Jones : What ever happened to the idea of software apprenticeship? Back in late 90s/eraly 2000s there was a lot of talk in the industry that we should train SW Engineers (and embedded systems specifically) with Apprenticeship after completion of degree or formal training. 14:14:13 From Leandro Pérez : This is right Tom... In my case I was exposed many years to the software industry and I come back to Embedded systems… I can apply many concepts learnt that I don't learn in my electronic career 14:15:23 From liam.bucci : We've been discussing leading vs lagging metrics. Lagging metrics are easy, just measure how often you see failures in the field. However, finding out your safety critical system has a failure by trying it in the field is not viable. How do we “predict” failures in software in order to use these metrics to inform what process improvements are necessary? 14:16:42 From Cole Wyant : Are there any pushes in the industry to have an official (government) oversight organization for software engineering/embedded engineering? Most other disciplines of engineering have some sort of official industry wide oversight body. 14:16:46 From Tom : Whatever happened to professional Software Engineering certification? Even the IEEE Computer Society certification effort has fallen on hard times. When they introduced this initiative, I signed up right away. But, my certificate is just collecting dust at this point. 14:17:01 From Phil Kasiecki : We have to seek out software concepts and principles - I am also an EE and sought out software work in co-ops and also took the more advanced computer engineering courses as tech electives, including one on data structures and algorithms. 14:20:38 From John Jeffers : If you had to use a RTOS is Azure TreadX STM32 or FreeRTOS STM32 a more successful RTOS? 14:21:16 From Jean Labrosse : What about Agile methods? Aren’t some of the requirements being decided as you go? 14:24:47 From Tom : Zephyr is a very interesting RTOS supported by numerous vendors 14:25:50 From Phil Kasiecki : Agreed, Tom - I'm intrigued by it and looking forward to making time to learn more about it (and possibly checking out the event the Linux Foundation is running in about a month and a half) 14:26:21 From Clayton.Jones : Back to my question about Apprenticeship. I think it's the responsibility of experienced engineers to establish learning path for entry-level at each organization. I try to do this myself and as recently as 3 years ago a brilliant entry-level Engr. joined our company that was woefully lacking in SW Engr principles such as effective Version Control and release processes. They were amazed at how much they didn't learn in school. 14:26:22 From Charles Miller : My experience regarding education was different. My BA CS 30 years ago did not include one EE course. I've tried to learn all I could since then, and fortunately, the HW guys and gals have helped me along. To what extent should HW education be a part of SW education? 14:26:52 From Keith J : The way most people use Agile = kick the can down the road 14:27:31 From naseh Alvi : When architecturing an embedded system how to design for something like power consumption e.g. managing for sleep current. of say 1.5 mA @ 12 V . Can we only do it after building the hardware and writing the most of the SW? 14:27:52 From Gonzalo : Sometimes happens that engineers know good practices, but cheaf officers are more worried on schedule and money than good practices, what do you think? 14:27:56 From Alex Ribero : Do we see an improvement on the firmware development processes over the years, compared with the 80's - 2000's? There are many more embedded systems being designed now, but maybe not that many failures... 14:28:45 From clamb : How do I find these managers that need that mix of HW & SW???? 14:28:56 From Phil Kasiecki : Charles - I suspect your experience is not uncommon even today. My sense - and someone can correct me if it's off - is that most CS curricula don't get you into anything remotely HW-related such as computer architecture or microprocessor design. That can be okay if you develop software that is mostly/entirely hardware-agnostic, but for embedded systems it puts one at a deficit. 14:29:24 From Bob Lee : Steve McConnell's More Effective Agile is a good look at Agile development practices that work and have empirical evidence. 14:30:15 From Susan McCord : Jack, can you point us to this data? 14:30:31 From Susan McCord : the best practices proven to increase productivity 14:31:11 From Keith J : Thank you Jack. Awesome talk! 14:31:18 From Alvaro Muro(Bilbao) : Thanks a lot! 14:31:26 From Jay Cosper : thanks for the talk! 14:31:33 From Phillip Kajubi : Thanks for the talk! 14:31:35 From Maxime L. : Very interesting! Thanks a lot! 14:31:40 From Susan McCord : thanks! 14:32:07 From iainbarkley : Sorry, I don't have a webcam where I work. 14:32:47 From Tim Michals : Maybe one issue to cover is maintenance in embedded software, I think it takes as much or more engineering to make sure it is correct. 14:32:56 From iainbarkley : Thanks a lot Jack! 14:33:16 From Praneet Kaur : thanks a lot jack, very interesting talk 14:33:25 From sleung : Thanks for the good insight! 14:33:31 From elazzaretti : thanks Jack, it's always a pleasure to watch your presentations! 14:33:47 From Eric Lundquist : Thanks! 14:33:51 From Javier Coronel (ITI) : Thanks for the talk! 14:33:52 From Gonzalo : Thanks a lot! 14:34:00 From schen : Thanks
And the most recent spacecraft failure, the Japanese Lunar Lander, which crashed into a crater. The spacecraft had originally been targeted to land on a flat plain, but at the last minute someone decided it would be better to land inside a crater (how cool!). Unfortunately, the crater walls confused the sensors during landing, because the software had not been programmed to recognize them as normal (there are no walls on a flat plain).