Mastering Embedded Systems

Baurzhan Ismagulov

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.

Alexander Smirnov

Already at the Embedded World I have had an amazing talk at their booth. But how much more deeper do we get into our todays tech-chat. We’re tackling the main use cases for using virtualization: combination and isolation. We’re discussing the main feature of Mango, as there are: static partitioning, bounded latency, no scheduler and a marvellous small footprint. And we come up with the general pros and cons of virtualization in embedded systems. For the latter have a look at Alexander’s talk at the Embedded Conference Scandinavia last year.

For all the ones out there who believe in doing things by themselves. Here’s the deal: Ilbers provides a Mango-demonstrator for the BananaPI. Just study their Getting Started Manual and give it a try.

But first, stay with me and enjoy the chat.

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.

Stay tuned and be inspired.

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.

In this episode I will the first time take some parts out of one of my favourite books. The first book I ever bought about “Software Engineering”. Written by Tom Gilb in 1988. It’s not named Agile or Lean, but the idea is the same. He named it “Evolutionary Delivery”. And there’s one chapter inside about Deadline Pressure.

I want to use this episode to present you some really interestic principles and ideas how to beat deadline pressure.

Some of you might be complaining that they are not ethical or not following your personal policies. No problem, then simply take them as aphorisms you can use to bias your thinking. Especially when you undergo deadline pressure you will grab for every straw and perhaps you will be very thankful remember that there was this episode. If it gives you an escape – sometimes the End justifies the Means.

Stay tuned and be inspired.

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 multicore needs to be designed manually. What might happen if the amount of cores still increases in future? How shall we handle existing code bases? Migrate all of them manually? Or might there be automatica ways to move towards multicore structures? And how can we improve software design for multicore deployment? For all of that the SLX MultiCore Toolsuite’s solutions will support.

We’re discussing the benefits a tool has instead of redesigning code manually for multicore systems. We dive into the models and operations necessary to paralellize existing code. We identify user-stories and we mention tricky pitfalls. Jeronimo unveils details of automatic code-analysis and problems solved to provide a tool like SLX MultiCore.

Stay with me and enjoy the chat.

The business year starts with the Embedded World! According to a  former colleague of mine it does. He has aligned his whole business activities around this exhibition. And it seems there are a lot others who are doing the same. From their perspective the Embedded World should not be underestimated.

I was visiting Nuremberg at Tuesday, the first day of the Embedded World. My main intention was to feel the course, the track, like a compass needle. Where’s the market tending to go? What are new ideas, new products? What are the manufacturers doing? Are there any trends at all?

And I also wanted to reach out for interesting podcast topics. I have prepared myself by scrutinizing through the Embedded World catalogue. Also the Embedded World Award nominees and winners of 2015 and 2016 are on my bucket list. I’ve visited them all. Some of them are of real interest. And I will try to achieve an interview with them.

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. I will give you my impressions from the Embedded World 2016.

Stay tuned and be inspired.

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 came 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.

Stay tuned and be inspired.

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 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 a continuous integration specialist. He’s currently working for CloudBees in Neufchâtel in Switzerland.

Oleg has become responsible for testing hardware in an automatized way already in 2008. He get in touch with it from the very beginning. Later he provided several plugins before he gots elected as core-developer. Meanwhile we have more than 1000 plugins. And it has undergone a redefinition from a pure Continuous-Integration tool towards a more general, more framework like automation server.

The time we recorded this interview Oleg stayed in St. Petersburg. He has just finished his PhD-thesis and was in a quite relaxed mood. In our discussion we’re highlighting the way of development. We stress the chances and challenges. Why someone should use it. And the struggles you might run into. We also talk about the newest changes in its self-understanding. And Oleg provides an outview what we can expect from the next major release. The next version will cover mainly architectural needs, especially from User-Interface-perspective, which have been recognized and accumulated during the last years

Stay with me and enjoy the interview.

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.

25 episodes published. 9 episodes with technically related content, like Embedded Systems or similar. 13 episode with leadership or managing content, like Virtual Teams, Task-Forcing, etc. 3 episode not classifyable containing more general topics.

First, I see the problem that I’m doing two different things under the hood of one. Technial and non-technical stuff is combined into one podcast, however the distinct episodes are either the one or the other. This results in a lack of direction, clarity and focus.

I will launch an additional podcast. A podcast designed to:

In parallel I will continue the Mastering Embedded Systems podcast.

Huuh, that’s a weak point yet. I have not found a really handy name. I currently get stuck with:

If you have a name or phrase in mind, do not hesitate, pass it to me.

The Mastering Embedded Systems podcast will be released on demand. It will be mainly driven by interviews and other interesting items like conferences. The schedule is not fixed.

The New podcast (the one without a name yet), will be released every second week. It will be based on solo episodes and interviews.

I am interested in interview guests for both podcasts. If you find yourself able to tell the audience news, information and other topics, do not hesitate and drop me a note.

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 with even more immature software. The challenges when working together with multi-sited SW-development teams. And of course the mother of all questions: How to improve collaboration between developers and integrators.

Stay with me and enjoy the interview.