Mastering Embedded Systems Archiv

Hopefully you guys remember Episode 37 Hopefully you guys remember episode 37. We talked about Death March projects. How to identify them. What their characteristics are. The reasons they happen. And about your decision to stay for them. Episode 37 was the introduction. This new episode starts to emphasize the four major aspects how to survive a Death March project. In this context surviving more means to stay psychologially unharmed than physically shattered. Regularly these four aspects appear in certain combinations. That's the reason you need to know all four of them to get the whole picture. Today I will present you the first of these aspects. We're talking about negotiations in Death March projects. There are not only rational negotiations - the one you might know from your daily life. But there are also negotiation games and special trade-offs to put your free. In a first I will give you some additional support to make your decision whether to stay or leave a Death March project at all.

"We do not need specificiation because our product is its own specification!" You know such kind of statements? You suffer from such kind of attitudes? Then you're exactly right in this tech-chat with Joachim Reinke. Joachim is an elaborated specialist for such kind of hassle. He is an engineer who specialized in the area of Requirements Engineering. He's a crack in this area of the development and production process. We both got acquainted at the systems camp 2016 in Berlin. Requirements engineering refers to defining, documenting and maintaining requirements to the sub-fields of systems engineering and software engineering. But the major question is - why does it seem that neglected in real development life. We're discussing a lot about these aspects. The benefits you get out of well done requirements engineering are tremendous. But it's also a quite long way to go. However also the longest way starts with the first step. In this episode we're giving you the path to do the first steps and continue successfully. Stay with me and enjoy the chat.

Already at the very beginning of this podcast, in episode 5 I have talked about projects in problems. In this former episode I have talked about the warning signs if your project runs into trouble. Everybody of us has some kind of understanding the term "Death March". It's from the military indicating a task you have a good chance to not stay alive. And the same could be, if you take projects in civil life in which the project members are working 13-14 hours each day, 6-7 days per week, for months. There is a good chance to lose people. But there's also a good chance to fail the project itself. I wanted to explain how exactly a "Death March" project looks like. How you can identify it. And what general decision you have to make if you face a Death March project. Due to the bare amount of information I have to split this topic into two episodes. In the second one you will finally get a general guidance how to tackle "Death March" projects.

You know such kind of story - everybody is talking about security, but not really everybody knows what it effectively means. Especially security in Embedded Systems has become a valid topic in the last years. My today's guest has an intimate knowledge about all kind of aspects of security for Embedded Devices. I wanted to welcome Andrey Nikishin from Kaspersky Labs. Many of you will remember Kaspersky Labs as one of the main competitors in providing anti-virus software. However they have become much more. Andrey describes himself as evangelist of new technologies and new business directions. As an expert for cyber security he is working very closely with Kaspersky OS - an operating system designed for security from scratch. I got in touch with Andrey at the Embedded World in Nuremberg. I've seen their booth and initially thought: "What does the manufacturer of anti-virus software do at such exhibition?" I was so wrong! The threats towards security and integrity of embedded devices has grown heavily over the last decade. But that's only one aspect. The other side of the medal are the ubiquitously available small embedded devices connected via the Internet. The bare amount of embedded systems in all parts of our life has dramatically increased during the last years. And they will still grow for the next decades. Stay with me and enjoy the chat.

Taking minutes can be some real awkward story. But using Mind-Maps it gets more natural, more fluent, and more precise. But, doing it that way, I detected during running consecutive task-force meetings, that the Mind-Map approach is not that stringent. It needed some tweaks to get its real harmony and fluency. And this episode is about the five major tricks I have found during the last months when using Mind-Maps for taking meeting minutes.

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

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. 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 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 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 Jenkins 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. Jenkins 2.0 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.