Mastering Embedded Systems

Today we're talking about Virtualization in Embedded Systems. This is particularly different from host-based virtualization. For that reason I wanted to welcome major experts in this special area: Baurzhan Ismagulov and Alexander Smirnov from Ilbers - Technology for better life. Ilbers provides Mango - a bare-metal Type 1 hypervisor. If you do not understand a word what this means - jump back to the previous episode #33 of the MES-podcast Combining the Uncombinable and fill up your missing knowledge. Mango was nominated for the Embedded Award 2015 at the Embedded World exhibition in Nuremberg. They have created a great piece of software which will provide a lot of benefit into embedded projects.

Today's episode is an introduction episode. It's introducing into the topic of the next episode. We've tackling the big topic of Virtualization. Virtualizing is in. Everybody, everythings seems to be in some way virtualized. But what does it really mean? At least in the context of IT it definitely means something different as in day-by-day usage. In this episode I'll give you the big overview and dive a little bit into some details. Details you should know when talking about virtualization on computer-systems.

Today I wanted to talk about deadline pressure. Everybody of us might have some experience with these special working conditions. There's a deadline - and you have to achieve it.

Today it's up to Jeronimo Castrillon-Mazo. We got acquainted at the Embedded World 2016 in Nuremberg. He is co-founder and adviser at Silexica. They have won the Embedded Award 2015 in the Tools-category for SLX MultiCore Toolsuite. That drives me to visit their booth. Having an amazing talk I asked Jeronimo to appear in this podcast. Let's have some tech-chat, widen the topic and enlarge the audience for this interesting topic. Jeronimo has studied Electrical Engineering in Colombia, achieved his Master-degree at ALaRI-institute in Lugano, Switzerland. He has made his Ph.D. 2013 at the well known RWTH Aachen. In 2014 Jeronimo joined the department of computer science of the TU Dresden as professor for compiler construction. He has a proven track record of multi- and many-core programming. Moreover he is known as specialist within the realm of automatic code generation. Nowadays we have tons of single-core based legacy code. In parallel multicore hardware platforms have overtaken. Usually software for mult

A short review about my visit to the Embedded World 2016 last week in Nuremberg. This episode is for all of you who haven’t had the chance to visit the Embedded World. I wanted to introduce you for a virtual walk. Join with me some interesting booths and see the big players

In the first two sessions about root-cause-analysis I have introduced the 5-Whys and the Ishikawa techniques. Both have their pros and cons. For a long time I was looking for a better way to provide root cause analysis. More sophisticated than the 5-Whys, but not that compilicated and elaborate as the Ishikawa. And hereby I come across with an enhanced version of the regular Cause-Effect approach. It's again a graphical approach which combines simplicity and logic. It's especially useful for situations in which multiple goals are affected. The way to evaluate root-causes using the enhanced cause-effect is my preferred way. And that's due to two reasons. First, it's rather progressive and can be driven alone or in groups. You achieve quick results without spending too much effort into nasty categorizations or simplifications. Second, in it's final stage provided as a diagram, it can be quickly and fully understood. You do not need verbose explanations how to read it or why some things have been dropped. St

Embedded Systems without logging is a pain. But with logging it's very often a desaster, too. I wanted to present you my thoughts how to improve logging. It's not for the super experts knowing everything and every detail of your system by heart. But it's for all the regular engineers out there who are facing a failing system. A system providing either nothing or an awful lot of superfluous information. What if you would introduce an indicator describing the system's healthiness. Something what would highlight an immediate status of the system: healthy or unhealthy. Stable or unstable. Reliable or doomed. The system-healthiness indicator needs much effort before you can use it. But it will be a walk in the park afterwards. No longer fears of uncommon errors. No longer daylong investigation to find the failing parts in your system. Stay tuned and be inspired.

Today I'm happy to introduce you another presenter of the Embedded Testing conference in Munich. I got acquainted with Oleg Nenashev already in the first minutes of the conference. We're sitting aside of each other. He was working for his Jenkins presentation. Oleg is a 27 year old engineer from St. Petersburg in Russia. Although he has started as a hardware-engineer he's mainly engaged on the software side. With his presentation Integrating Jenkins with verification flows of Embedded Systems he has introduced himself as Jenkins specialist. He's currently working for CloudBees in Neufchâtel in Switzerland. Although I was in touch with Hudson and later on with Jenkins, I never get that deep inside of it. In contrary Oleg has become responsible for testing hardware in an automatized way already in 2008. He get in touch with Jenkins from the very beginning. Later he provided several plugins before he gots elected as core-developer. Meanwhile Jenkins has more than 1000 plugins. And it has undergone a redefinit

Hi fellows, I wanted to welcome you in 2016. Hopefully you have survived all the holiday stress, the good food, the sometimes stressful family gatherings. And perhaps you have also taken your New Year's resolutions into mind and into heart. I have done my homework - not fully, but most part of it. 25 episodes done; half of a year. Time for making a review. What has gone fine? What has gone wrong? Where is the direction? What was the feedback? Am I still on course? These questions came into my mind during the last two weeks. Today's episode is about all that. And about the next steps of this podcast. About its future and the direction. About details and then big picture. Stay with me and see what's in for you.

It's an ever lasting story in Embedded Systems: Integrate hardware and software. You need to combine a new piece of hardware together with new software. That's the time you need engineers like my today's guest - Jürgen Salm. Jürgen has a proven track of experience as SW-developer. He's running his own zoo of Unix- and Linux-machines at his home-place. At work however he's engaged as SW-tester and mainly HW- and SW-integrator. Jürgen is working for one of the big mobile equipment manufacturers in Germany. Jürgen is a constant source of ideas about improvement and he has tons of experience you can participate from. As a former SW-developer Jürgen instantly provides the feedback the author of software will understand. More over he does regularly not only provide feedback about the failure, but also directly points to the failing component. Very often I have experienced by myself that he's already pointing to the wrong algorithm directly. We're highlighting the daily problems when integrating immature hardware

I have recorded this episode twice. Not by intention - far away from that. But I was neither convinced nor satisfied with the first recording. Also the subject was not really impressive and I decided to do it again from scratch. Thus I got a first hand impression what waste of time and effort is. However one detail in the first record was amazing. It was about waste in SW-development. You remember episode 4? Already there I have mentioned waste due to over-processing and over-engineering. Both are part of the 7 forms of regular waste in any kind of system. The Toyota Production System (TPS) has introduced to a broader audience the classification of waste forms. In this episode I wanted to connect traditional manufacturing based Kaizen and Muda, Mura, and Muri with Software-development. Is it possible? Do we have parallels? Or is the TPS not adaptable to nowadays IT-based technology? Stay with me and enjoy the show.

I have mentioned the Embedded Testing conference in Munich in episode 20. One of the presentation was about "Applying DevOps Principles to Software-Hardware Integration Test". Vassilis Rizopoulus, naming himself as DevOp and Tester, explained further details, their tooling, automated testing and the mandatory environment. I was excited and we have had an extraordinary talk after his contribution. Some days later I asked him for an interview. I am sure that Vassilis' ideas and thoughts will be helpful for a lot of engineers out there. Especially engineers who wanted to try something knew, but who might need some trigger to change their way of thinking and habit. Vassilis works as an engineer at Zühlke in Germany since 2001. He has tons of experience and knowledge. According his own statement on his company blog he has "... helped build software for devices as small as a cookie to as large as a 60-ton locomotive". Moreover he was co-organiser of the European Ruby Conference in Athens in 2013. You see, Vassili

In episode 20 I have described the main differences between traditional conferences and the idea of BarCamps. In this session I wanted to give you my 15 for your BarCamp visit. I have meanwhile joined several BarCamps. And I have made a lot of things wrong. Mainly because I was not aware of. Sometimes also I thought it is better done in another way. But there are a some main phases you are confronted with. And for all of them you can do things well and you do things much more better. Starting into a BarCamp well prepared lets you enjoy the atmosphere even more intensively. You get much more quicker into connection with the other BarCamp-members. And you finally get more out of the time you're staying at the event. All BarCamps can be separated in three different phases: BEFORE, DURING and AFTER the BarCamp. Even the AFTER phase is as much important as the other phases. If you do not care for the AFTER-phase you loose a lot of momentum you have gained during your time before. Please take these 15 tips into

Holy moly, seems I'm getting old. Two times in the last two weeks I was confronted with the PDP-11. Things which are part of my experience are nostalgic for others. They have never seen or touched them. Never experienced in real life. What has happened? One day I saw an update in LinkedIn highlighting DEC's PDP-11 as an old system. That's nothing extraordinary. It is old. But one of my colleagues mentioned it as nostalgic. Bumm, right in the face. Second, I got a mail by another colleague. In his signature he mentioned that this mail was written from his PDP-11. I doubted this, but he showed me a picture showing him from the backside (hopefully it is him) and a PDP-11 aside. That picture must be old. I do not consider that he really has a PDP-11 in his cellar. But both moments let me think back into that time 30, 40 years ago. Computer Systems were different. Computer Science was slightly different. And of course the systems you own or you could directly touch were dramitically different. Compared with the

You know conferences. For sure you do. You might be a fan of them. Or even not. You might be even disappointed, as I am after visiting the Embedded Testing 2015 in Munich last week. Although I was invented as presenter, I was not convinced. I mean the topic was really good - no other conference or meeting available covering exactly this specific part in the Embedded Systems realm. But the conference got stuck as a sponsor-driven event which highlights products over general knowledge, marketing over sharing of experience. One could have made a lot more out of this conference. So the participants have finally had only their others to get acquainted with each other, hear the problems, discuss and finally detect the old rule, that the best of conferences are the pauses. Free time which can be used for connecting and sharing. In this episode I wanted to highlight the approach of traditional conferences in comparison to BarCamps. A BarCamp is an un-conference born from the desire for people to share and learn in

Talking about bug-hunting has become a regular topic in this podcast. However there are tons of different persons out there using their own approach to handle bugs. All of them might have different attitudes, different approaches and different experiences. And it might be of interest to get more familiar with them and the details they can tell us. Within today's episode we have Bero Brekalo as a guest for interview. Bero is one of my very first listeners not directly related to me. We got acquainted after release of Episode 2. We have had a long mail-discussion about debugging, our different and common understanding. Especially Bero's very interesting debugging tools made me curious. As more as we discussed and as more as I got familiar with Bero, I more and more get the impression, that he's Mr. Bug-Hunting in person. Today I have the pleasure to present you Bero Brekalo. We're talking about many details of debugging. You get further details about his approach and his understanding of debugging. And you ge

Everybody has his limit in handling emails. For one 10 per day are too much, another handles 150 without any problems. But sooner or later, everybody of us have to declare: it's too much. I have had a time in my life in which I have had to handle 750 mails per day in average. Nobody can say that this is possible to do. But that was the time I started a very strict and consequent filtering and categorization. However it still was too much. The combination of importance and urgency was back-breaking. In the first part of this episode I will show you some of the most successful approaches how to handle the flood of emails daily arriving in your inbox. There are different concepts, sometimes even contradicting systems, but give them a try and find the most acceptable way for you. But if you're in the same situation as I was, even the most sophisticated approaches to handle the flood, weren't succeeding, then you might be interested in the 2nd part of this episode. This summer I stumbled over the book of Rory

Do you have ever heard about Soft-Errors? No, I do not mean Software-Errors. That's something completely different. I mean Soft in difference to Hard. I first time get into contact with Soft-Errors in late 2011 as we have observed a spontaneous reset within a customer's appliance. There was no indication for a reset-request, the system simply resetted. Within some industries this is no case to be worried about. But in that time, in that type of industry, with this particular customer it was a challenge to find the root-cause of this spontaneous reset. And it was even more complicated to approve this root-cause. In this episode it is Michal Lewczyk joining us. Michal is one of the very seldom specialists available for Soft-Errors. Michal was one of my colleagues in 2011 and the years after. He was the main investigator for all Soft-Error issues we suspected. Michal has a deep knowledge in bare metal SW-programming. He's mainly engaged into developing software for Digital Signal Processors; thus he's not onl

In this episode I will give you further details and helpful hints how you can do all the aftermath in running and working with task-forces. You get a lot of details about how to provide meaningful and reliable meeting minutes. I provide you my experiences in doing minutes both, during and after the task-force meetings. Additionally you will also get my minutes template available for free at Google Docs. And last not least I will drop you my ideas about the retrospective you should have for each of your task-forces.

In this episode I will give you my thoughts and considerations about the Volkswagen Diesel scandal. I wanted to highlight some of the obvious technical problems as some of the not that visible intrinsic issues. Where do we have seen this kind of cheating before? What could the customer expect? How will Volkswagen deal with the situation? A big amount of questions let me consider about some potential answers or thoughts how this could have happened, why it has happened and whether it is not that simple to resolve the problems.