Back in 2016, the European Space Agency (ESA) lost the Schiaparelli Mars lander during its descent to the surface on Mars. From a software engineering and testing perspective, the story of why the landing failed (see for example the ESA final analysis, Space News, or the BBC) is instructive. It comes down to how software is written and tested to deal with unexpected inputs in unexpected circumstances. I published a blog post about this right after the event and before the final analysis was available. Thankfully, that has since been retired from its original location-it was a bit too full of speculation that turned out to be incorrect… So here is a mostly rewritten version of the post, quoting the final analysis and with new insights.Continue reading “The ESA Schiaparelli Crash & Simulation”
Wind River is celebrating their 40th anniversary as a company with a series of historical look-backs posted on the Wind River channel on YouTube. One of the videos is an interview with Jerry Fiddler who founded Wind River back in 1981, by Wind River current CEO Kevin Dallas. Jerry Fiddler talks about how he got started in computers, and especially about how Wind River got started and grew. It is both a fantastic set of historical anecdotes and some solid product management and strategy insights.Continue reading “Jerry Fiddler on the Early Days of Wind River and Building a Product”
I will be presenting an Exhibitor Forum talk at the Embedded World in Nürnberg next week, about how to get to Agile and small batches for embedded. Using simulation to get around the annoying hard aspect of hardware.
I just read an interesting paper from the 2004 Embedded System’s Conference (ESC) written by Gary Stringham. It is called “ASIC Design Practices from a Firmware Perspective” and straddles the boundary between hardware design and driver software development. It was good to see someone take the viewpoint of “how you actually program a hardware device is as important as what it does”. Gary seems to understand both the hardware design and implementation view of things, as well as that of the embedded software engineer. To me, that seems to be a fairly rare combination of skills, to the detriment of our entire economy of computer system development.
I am a skeptic when it comes to technology. Despite working in the tech field — or maybe because I am — I always expect technology to fail or at least disappoint. But sometimes that instinct is actually wrong! Here are two recent examples when I felt “wow, that was pretty good” about some fairly mundane pieces of computerized equipment.
The article/editoral “Using virtual platforms to improve AdvancedTCA software development practice” is now up at CompactPCI and AdvancedTCA Systems, an online and paper journal for the rack-based market. It is about our experience at Virtutech in using virtual platforms to drive system and software development for “pretty large” target systems, even those based on standard hardware.
And really, there is no such thing as a standard embedded system. Even if you use a standard backplane and buy off-the-shelf boards and cards to put in it, the combination of cards and added mezzanine cards makes each system quite unique. If you could use completely standard PC hardware for your system with no custom additions or special IO units, the thing would in likelihood not actually be an embedded system.
I have another short technical piece published about Multicore Debug at the EETimes (and their network of related publications, like Embedded.com). Pretty short piece, and they cut out some bits to make it fit their format. Nothing new to fans of virtual platforms for software development, basically we can use virtual platforms to reintroduce control over parallel and for all practical purposes chaotic hardware/software systems.
…the discussion, and the need to constantly define our terms (and redefine them, and discuss them when people disagree) makes me wish that the world of electronics, system and software design had some agreement on what the right terms are and what they mean…
I think this is a good idea, but we need to keep the core count out of it…
This is just a repeat post of http://jakob.engbloms.se/archives/75 . I will present at the ESC Silicon Valley, next Thursday, at 08.30 in the morning. On how to use simulation and virtualization to better develop embedded software.
As a side note, a few years ago, I presented on efficient C programming for IAR Systems, guess that would have made Jack Ganssle happy: he complained about the lack of resource-constrained C programming skills in today’s university graduates in a column at Embedded.com recently. Apparently, the major market-driven education companies in the US have also dropped plain C programming from the course rosters… sounds like an opportunity or void to be filled by the embedded companies. Buy a C compiler, get a free efficient programming course.
In the book “Programming Embedded Systems — with C and GNU Development Tools“, authors Michael Barr and Anthony Massa make some statements on simulation that I just have to disagree with on principle. Read on for what. Note that overall this is a good book, I am not claiming that it is not. The Amazon reviews are pretty good, and having a foreword by Jack Ganssle is always a sign of quality. But I just have to correct them on one little fact…
I attended a DATE 2008 open exhibition panel discussion on multicore programming, organized by Gary Smith EDA. The panel was a few people short, and ended up with just Simon Davidmann of Imperas, Grant Martin of Tensilica, and Rudy Lauwereins of IMEC. A user representative from Ericsson was supposed to have been there but he never arrived. Overall, the panel was geared towards data-plane processing-type thinking, and a bit short on internal dissonance.
I write this on (cramped, poor service Economy class SAS) the flight from Tokyo to Copenhagen. The aircraft attendants just told us that there are some issues with the movies in the in-flight entertainment system, and they will need to take down the system and reboot it. This process is supposed to take some twenty minutes! Nothing to be upset about, really, and likely totally unrelated to anything important for flying the plane. But still, needing twenty minutes for a reset is a bit much for something like this… makes Windows look positively fast in comparison. I guess it has to do with initializing some 200 individual screen units.
Anyway, in the end the system was up partially. All recent feature movies were missing (but the selection of older movies was intact), and the forward and downwards-looking cameras were inaccessible. Apart from that, it appeared to function normally. Interesting that it can be partially broken like that.
In a paper from USENIX 2007 by Microsoft Researchers Onur Mutlu and Thomas Moscibroda present a working “denial of service” attack for multicore processors. The idea is simple: since there is no fairness or security designed into current DRAM controllers, it is quite feasible for one program in a multicore system to hog almost all memory bandwidth and thus reduce or deny service to the others. There is no direct attack on software programs, just stealing the resources that they all need to share for all to work.
Continue reading “Multicore Denial-of-Service Attack”
I am scheduled to talk at the ESC SV 2008 in the technical program. In 2006 and 2007 my topic was Multicore Debugging, but this year I have changed to Using Simulation Tools for Embedded Software Development. The date is April 17, the time 8.30 to 10.00, and the place the San Jose Convention Center.
See you there!
In a column called The Good News and the Bad News in IEEE Computer magazine (November 2007 issue), Prof. Wayne Wolf at Georgia Tech (and a regular columnist on embedded systems for Computer magazine) talks about the impact of multiprocessing systems (multicore, multichip) on embedded systems. In general, his tone is much more optimistic and upbeat than most pundits.