Category: Interviews

You can turn writing good software security into a good habit. Something you barely stop to think about, like brushing your teeth or putting on your seat belt. High Tech Institute is working with the specialists at Hungary’s Cydrill to teach you how.
‘We teach developers how not to code.’ László Drajkó likes unsettling his conversational partners with this bold statement. Yet that’s what the software security courses taught by his company, Cydrill, revolve around: teaching coders the professional discipline to prevent weak spots in their software.

Perhaps ‘discipline’ is too strong a word. Drajkó thinks it’s more comparable to putting on your seat belt. ‘You no longer notice you’re putting it on. In the same way, you can teach yourself the good habit of writing good software security. And then you’ll automatically avoid pitfalls, without stopping to think about it. We teach people to instinctively use good coding habits.’ Secure coding doesn’t take more time, Drajkó says. ‘It takes time to learn how, but once you have there’s no difference.’

Teaching people to write secure code is a labour-intensive endeavour. Break-ins are continually happening around the world, exposing vulnerabilities. It takes a sizeable team to keep up with all that information and work it into training material as case studies. ‘An independent teacher would spend four hours staying up to date and incorporating new material for every hour of class,’ Drajkó estimates.

That’s why High Tech Institute is partnering with Cydrill, a specialist fully focused on training people to write secure code. The Hungarian company is especially focussed on security for embedded systems.

‘We aren’t selling painkillers and band-aids, but building an immune system that’s extremely resilient,’ say Ernõ Jeges (left) and László Drajkó (right), who visited the High Tech Campus in Eindhoven last summer.

The Commodore 64 and the ZX Spectrum

Cydrill is located in Hungary’s capital, Budapest. In the eighties young László Drajkó had access to computers, though within the Russian sphere of influence that access was very limited. His first acquaintance came when he was twelve. ‘Science was non-political. The educational system was highly theoretical, but quite good. Behind the Iron Curtain, we had to rely on our brains and we had few other resources.’

Drajkó and his fellow students wrote their code on paper. ‘We ran it in our heads. We checked for coding mistakes that had never been implemented. We made our corrections on paper, too. Because when we finally had access to a machine, we wanted to feed it error-free programs. We barely had money or computers.’

In the mid-eighties the Hungarian coders were permitted to travel to Germany and Austria, where they were able to buy Commodore 64s and ZX Spectrums. ‘The generation before ours had to shell out millions of dollars for a computer, but suddenly we could buy a home computer for five hundred dollars. The PC had a major impact on our age group.’

In the mid-eighties Drajkó was studying computer science in Hungary. The Iron Curtain fell while he was still in college, which had a huge impact on him. A European Economic Community grant enabled him to attend the Delft University of Technology. The result was culture shock. His first few months in the Netherlands immersed him in ‘total miscommunication’.

Though he spoke English, Drajkó didn’t understand his advisors’ questions. ‘Not in terms of language, but conceptually. The educational approach was completely different. They’d ask things like, ‘László, what problem would you like to work on?’ And I’d say, ‘No, no, I don’t have any problems. Just tell me what code you want me to write and I’ll find the best algorithm for it.’ But then they said things like, ‘How would you like to change the world for the better?’ And I thought, ‘I’ve wound up in art school!’’

‘When I went to college in Delft, I thought I’d wound up in art school’ – László Drajkó on the culture shock he experienced as a Hungarian university student in the Netherlands.

Novell, Compaq and Microsoft

After twenty-five years working for international companies such as Novell, Compaq and Microsoft, Drajkó decided to invest in a training company. He wanted to share what he knew and was looking for a suitable niche. He found it in security. ‘I asked myself what was going wrong and one of the answers was cybersecurity.’

Some time ago Drajkó ran into two familiar faces, Zoltán Hornák and Ernõ Jeges. All three studied at the Budapest University of Technology, but Hornák and Jeges have known each other since 1990. That year, the Hungarian and the Serbian competed against each other in the second International Olympiad in Informatics in Minsk. A few years later, Jeges decided to study computer science in Budapest.

Hornák and Jeges became fast friends and during their doctoral research they conducted tests for Nokia, breaking into mobile telephones and networked systems. Demand was so high they abandoned their PhDs and started hacking systems on assignment. ‘White hat hacking was uncharted territory back then,’ Jeges says. ‘Very few companies were doing it. Nokia had a ton of assignments, and we realized we were learning more on the job than we were at the university.’

The penetration testing (pentesting) assignments poured in to their company, Search Lab: the pair were hired to break into networking hardware, set-top boxes and more. Most of the target systems were embedded. ‘Not many security companies focus on those, because you need to understand the system at the chip level. Most pentesting companies focus on websites and web services, but we explicitly specialize in embedded.’

The 2008 crisis hit Search Lab hard. In that same period, the mobile phone industry switched entirely to the Iphone and Android platforms. Hornák and Jeges lost most of their business from clients with whom they had a long history.

Their shared focus on security sparked the click with Drajkó. ‘The number of incidents is growing exponentially, while awareness is minimal,’ he explains. ‘Only a handful of companies are doing something about it. Everyone’s busy patching errors, but that doesn’t address the problem. Education is the golden opportunity to prevent a software security crisis. Our stance is that we aren’t selling painkillers and band-aids, but building an immune system that’s extremely resilient.’

Ernõ Jeges’s goal is not to teach people how to hack, but to instil paranoia.

Instil paranoia

In 2018 Drajkó and Jeges founded Cydrill, the company that focusses on trainings. The security industry is in constant motion and to keep up with it, Cydrill offers online training in addition to traditional classroom fare. For a modest annual fee, participants can shore up their knowledge using a digital gamification platform. The online approach also makes it easy to track results. ‘We measure our success by the way clients translate our expertise into coding habits,’ Drajkó says.

The need for inherently secure code is high, but not all developers are enthusiastic about security classes. ‘If you ask developers to choose a course from nineteen different options, security will probably come in at the bottom. It sounds very prescriptive. A new platform, new language or new architecture is much more appealing to them.’

Cydrill’s software security courses don’t teach developers how to hack. There are plenty of classes that do that, Drajkó says. Many of his clients in the US have experience with them. ‘But they’ve been turned off by them, because the course designers couldn’t relate it to their daily work.’

Drajkó believes that learning hacking techniques in order to prevent hacks is a waste of time. ‘It doesn’t matter whether it’s ethical hacking or hacking with bad intent. Because in terms of technology there’s no difference; it’s a question of morality.’

Drajkó believes that developers do need to be well versed in what exactly hacking is. ‘That’s why we address it. Participants also need to understand that hackers have infinite time and infinite resources. They make use of bots and third-party computers. In the embedded domain that use is growing in lockstep with the Internet of Things.’

That’s why Cydrill’s courses always start with a peek inside the hacker’s mind. ‘For example, we show them that a buffer overflow can be a problem,’ Jeges says. ‘That someone can take control that way, and it will no longer be your program that’s running.’

Jeges’s goal is not to teach people how to hack, but to instil paranoia. ‘The first day, participants go home feeling uneasy. They realize they’ve made mistakes in the past. That feeling is important. It has an impact we can’t achieve through online training.’ After that experience participants are all ears, Jeges notes with a smile. ‘Emotionally and intellectually.’

That makes the class ripe for covering best practices. ‘We show them the difference between well-meant attempts to make code hack-proof and actual best practices,’ Jeges says. ‘They can apply the new techniques and skills they learn the next day.’

Case studies are an important component of those best practices. ‘We use every incident that’s been global news,’ Jeges explains.

This article is written by René Raaijmakers, tech editor of Bits&Chips.

Software development often focuses entirely on filling in functionality; there is no time for issues such as maintainability, architecture and performance. While it doesn’t need to be difficult, says software trainer Onno van Roosmalen, but there are misunderstandings about Agile, architecture, UML, object-oriented programming and test-driven development.

Modeling? We don’t do that. Design-patterns? Let’s skip it. Because we work agile. Onno van Roosmalen hears it regularly: Agile as an excuse, or even  a pretext not to take software architecture seriously. As a trainer in the field of software development, he sees that there are many misunderstandings around the issues related to non-functional requirements: architecture, interfaces, performance, modeling, maintainability, you name it.

Misunderstandings that can be easily explained because they have to do with the elusive concept of ‘software quality’. “Quality is not visible to many people,” says Van Roosmalen. “If it works, then it works and managers, customers and users think that it is pretty much done. It becomes  very difficult to argue why you have to do something extra. Developers get a clear return on that in practice, however.”

Many of these misunderstandings about software quality also live among the developers themselves. Popular software techniques, like test-driven development, do not contribute to this, he thinks: “Test-driven development completely focuses on functionality. Aspects that are typically linked to architecture, such as performance, reusability, extensibility and software evolution, are very difficult to test. Just like race conditions and deadlocks.”

“There is also the idea that architecture is something abstract that has to be thought up in advance, which then forces the direction of the project into a straitjacket – a big bang architecture that has to be right the first time. But you can’t do that; often you don’t know what’s coming next,” explains Van Roosmalen. “Of course, it’s good to have an idea of how you want to arrange it. But you sometimes see that projects are already preparing themselves for certain additions. Then I often think: Yes, and will they truly come?”

In addition, the underlying theory dusts over time. He notices this well, for example, in his basic training on object-oriented analysis and design (OOAD). He comes across participants with an electrical engineering background, for example, but also people who earned   an IT degree. “Yet, you see that many of them dissect problems procedurally instead of object-oriented,” says Van Roosmalen. “That’s what creeps in when people make software under pressure, while, really, you can make remarkably better software if you apply the guidelines properly.”

‘It’s not like that In C#’

Van Roosmalen himself has an entirely different background: he studied physics in Nijmegen and obtained his PhD at the Kernfysische Versneller Instituut in Groningen. He then made the jump to America for a postdoc position at the California Institute of Technology.

The turning point came in 1987. Van Roosmalen and his wife actually wanted to return to the Netherlands, but jobs in physics were not up for grabs. When a position in technical computer science became available at Eindhoven University of Technology, Van Roosmalen decided to take advantage of this opportunity; his work in the field of computational physics had aroused his interest in software and computers.

Moreover, Van Roosmalen noticed that he enjoyed teaching. Before his return to the Netherlands, he had already been teaching at Yale for three years, and when object-oriented techniques emerged in the early nineties, he started training for companies. After the turn of the millennium, he decided to reduce his employment at the TUE  to, ultimately, fully focus on training. He still works for the Eindhoven University, which hires him for the PDEng course in Software Technology.

So, moreover, Van Roosmalen  provides training for developers who have been employed by a company for a couple of years. A big difference with starters, he notices: the longer developers have spent behind the keyboard, the more receptive they generally become to advanced software engineering concepts. “You start looking at things in a different manner and I think you can see things more in context. It sticks a little bit better.”

“In most object-oriented programming languages, objects of the same class can, for example, directly access each other’s private attributes. People often don’t know that at all. Then they give it a try, and it turns out to be true.  They often say something like: ‘But it’s not like that in C#.’ And then again it turns out to be exactly the same there,” Van Roosmalen gives as an example. “It seems elementary, but there are important ideas behind it, and most developers like to talk about that again. Most training courses are about the process and all that, and not about the technical stuff.”

Defensive

”It is precisely this knowledge of object orientation that forms the basis for much of the architecture in a typical application. This means that you are automatically confronted with important software properties such as information hiding and encapsulation, i.e. the idea that you localize information and not throw it through the entire system. In practice, you  regularly see that a team provides one component with extra functionality and then the entire system starts to  topple like dominoes. That makes it problematic to add something. In many web applications you see that that idea is slightly broken,” says Van Roosmalen.

And then, thinking about hiding information goes hand in hand with the means by which components communicate with each other: the interface or API. “ It enables you to hide the detailed shape of your objects and ensure that no implementation details leak out. You  thus take care that the client code can only do what is currently requested, no more and no less,” explains Van Roosmalen.

The idea behind this is that the evolution of components can be decoupled in this way. If a new version of a component continues to do what it used to do via an interface, the software built on it does not have to be modified immediately. A development team that programs against the component can safely use the new version without being afraid that something will fall over in the process. When encapsulation and interfaces are in order, a maintainable, scalable architecture is created almost automatically that can grow with the application.

This requires, however, that teams adopt a defensive stance when designing their interfaces. “You shouldn’t just offer everything that other teams demand. The more you offer, the more unintended usages there are. This increases the chance that things will fall over with a new version. You can always expand an interface later on, but downsizing is a lot more difficult,” says Van Roosmalen.

“I have a very nice workshop for that, which I do with the TUE trainees. Several teams are given the task of developing a component with an interface. After that,  they have to make a functional extension to it – unexpectedly of course; I keep that secret. Then they have to try to make test cases for each other’s components that work against the first variant, but no longer against the second. These are real eye-openers, because often such tests are made in no time.

Box of tricks

Developers don’t have to reinvent the wheel every time. For many problems, best practices have been established over the years, in the form of patterns. “For example, you can lay out your architecture in layers: that’s an architecture pattern. To  structure those layers, you use  various design-patterns.”

Van Roosmalen provides a training course entirely dedicated to this subject: Design patterns and emergent architecture. That’s very broad of course, but the idea behind it is mainly to show that you have that box of tricks. “Actually, that’s one of my favorite training courses, because you really talk about software design and because you can use it to tackle all kinds of practical problems. There are also very different technical aspects involved, such as state machines with possible deadlocks.”

Van Roosmalen, together with a former TUE colleague, also provides a follow-up course on a different architecture theme: real-time behavior. Typically, you’re talking about problems with systems that have to perform several concurrent tasks  subjected to timing requirements. Nowadays, most modern programming languages allow you to program concurrency , and that gives rise to very  special problems such as race conditions and deadlocks.

Here, too, things  already go wrong in the basics, notes Van Roosmalen: “A lot of people who have real-time problems use an operating system like Microsoft Windows. Well, that’s not a real-time operating system. It does contain a lot of things  like real-time priorities and so on. But many other things are missing that are also necessary for real-time behavior. Then you have to stand on your head a bit to get it right.”

“In real-time systems, for example, you have the problem of priority inversion, where a low-priority task claims a resource so that higher-priority tasks cannot make use of it. There are mechanisms to keep this to a minimum, and they must be in the operating system.”

Vendor lock-in

Van Roosmalen also provides a basic training around SysML, a variant of UML for systems engineering. System engineers model a lot, yet SysML is only used sparsely in practice. There’s a reason for this: “A lot of commercially available tools, such as Matlab and Simulink, are used for systems engineering. These  do not deliver standardized models. That is not what  tool vendors want  at all anyway, because they might lose business. They play on vendor lock-in.”

But with SysML you can  yet integrate these models with each other and make an overarching model of your system. The OMG, the standardization group behind SysML, has tried to combine these modeling techniques in such a way that the whole  covers everything and at the same time  Is methodologically sound. “That worked out pretty well, but  it makes the modeling languages awfully big.”

As far as Van Roosmalen is concerned, software developers should likewise take modeling a bit more seriously. During his courses, he relies heavily on UML himself – partly because a training course is too short to go into extensive programming, although programs are provided as proof of concept. But also, because it offers good starting points to reason about the class structure and to think about the architecture.

“As for UML, most software developers have seen it once before, but the threshold to really get started with it is quite high. Making a good model really does require an investment before it pays off ,” Van Roosmalen agrees. In addition, software developers also lack a bit of the discipline that system developers do have, he observes.

But that again is a symptom of the fact that quality in software is hard to see and only makes itself felt in the long run, whereas that’s naturally different  with systems engineering. “For programmers it is therefore important to put quality on the map. And contrary to what is sometimes thought, Agile can help with that,” says Van Roosmalen: “The Agile Manifesto simply states that you need to pay attention to software quality. It states very sensible things about that, however you have to practice what is preached there.”

This article is written by Pieter Edelman, tech editor of Bits&Chips.

Jasper Nuyens was there at the cradle of Embedded Linux and developed the first Embedded Linux training in the world in 2005 in collaboration with Mind in Leuven (now Essensium). High Tech Institute has been offering the training in Embedded Linux in the Netherlands for a number of years, on an exclusive basis. The Belgian Linux pioneer tells us the ins and outs of his five-day course.

Jasper Nuyens, founder of Linux Belgium and Embedded Linux trainer at High Tech Institute.

Just as Jasper Nuyens went deep into Linux in the mid-nineties, there was an initiative to reduce the footprint of the system. This ‘Linux Router Project’ was an effort to run a complete Linux-based router from a 1.4 megabyte floppy disk. Nuyens: ‘This was done in order to use old PCs with a number of network cards as a server or router. It was a big challenge in which the Linux kernel compilation played a very important part. The tricks we had to pull out of our sleeves to make this work were actually a beginning of embedded Linux: a small system where you can add many applications.’ The project lives on in current router projects such as OpenWRT and DD-WRT.

Due to his extensive experience, organisations call in Nuyens’ help ‘if there are really difficult problems.’ This ensures that he can delve more deeply into very special cases. Nuyens: ‘That makes the job very interesting. It also ensures that our course stays up to date.’

Nuyens always adapts his training sessions to the latest developments. ‘We now had about a hundred editions, whilst we are on version 65 of the course.’ He cites an example of the embedded build-system Buildroot and OpenEmbedded / Yocto that became available in the new millennium. ‘We also include that in our training. We always adjust the material to recent developments.’

The biggest Embedded Linux problems land on Jasper Nuyens desk.

What is it that makes embedded Linux training so successful?
‘With Linux you have the source code of all the components, from the boot loader, kernel to the tens of thousands of applications that are available in user space. You can use everything and have a lot of choices. This means that you have to learn to see the wood through the trees. There are many possibilities. Many application behave a little different, but you can refine them. That is actually the core of our course: helping people find their way and make the best choices.’

You can also learn everything for yourself on Internet.
‘Of course, it is not really rocket science. You can learn individual topics online. The embedded Linux course, however, brings all things together and provides the whole picture, from the ground up. Even people who have been immersing themselves in Embedded Linux for a long time do not always see how things fit together or how each of the different components interacts with the others. The training provides you with a jump start, a push in the embedded Linux world.’

Linux is not a real-time operating system. To what extent does this play a role in the choice for this OS for embedded systems?
‘When people start using Embedded Linux, they usually think that real-time is an important requirement for their system. They often work with microcontrollers at a low clock speed. The timing restrictions can then impose real-time behaviour. Effectively, however, they often don’t need it. The current Systems On Chip sometimes run Linux with a gigahertz or more. As a result, real-time use of Linux is rarely required in practice.’
‘There are also different levels with which you can work in real time on Linux. We go into that in our training. With the standard Linux kernel you have soft real-time possibilities. But you can also turn Linux a hard real-time operating system and there are also intermediate forms. The students learn to make these choices depending on their needs.’

To what extent do you go into the legal aspects of Open Source?
‘We do not provide legal training, but we do make it clear what each of the different Open Source licenses mean and what their results are, including the patenting of software and hardware and trademark issues. Many software developers do not know enough about the consequences of having chosen Open Source. They need to be able to keep their management well informed about this and the few requirements imposed by Open Source licenses.’
‘Some are so enthusiastic about the Open Source story that they do not want to say anything negative about it. But companies that use and implement open source software need to know exactly what they need to do. They also need to have objective information about the obligations and risks.’

Participants should preferably have experience with Linux and C programming experience, but is it essential?
‘That’s right. It is nice to have it. We receive two types of students. We have those who have a lot of experience in embedded, but have limited Linux knowledge. And we have those with Linux experience, even with a lot of Embedded Linux experience, who want to deepen their knowledge.’
‘There is a very large difference in level between both profiles. The first group has hardly any experience on the command line. That is a big step for them. On their laptop they have a Linux ‘command prompt’ and on the embedded board they also have ‘command prompt.’ They cannot mix them up. If your embedded board enters the boot in boot mode, in the boot loader, then that is another prompt where you can type different kind of commands. The same occurs: you cannot mix them up.’
‘People from the embedded world without Linux experience usually find it tougher. We find that both groups help each other. We start the course with information that is fairly basic for people who have already worked with Linux. However, it offers the necessary depth to discover new things, so that the more experienced embedded Linux people do not get bored. It is a case of balancing, but the group is sufficiently small to deal with that properly and answer questions from each participant.’

Eight participants is the maximum number.
‘Yes, eight is our magic number, as we have gradually discovered. Because during the training everyone asks questions from their own perspective. The loose ends that they cannot immediately link to their existing knowledge. That is why we need a degree of interactivity. Students program their platform during the training and there are more advances optional exercises for those who are faster. It works well when they can immediately ask their questions and I can immediately look into them.’
‘Linux also has a very steep learning curve. In the beginning, you have to assimilate a lot of information. We want to help everyone move forward to really make a real jump start.’

Is that always possible?
‘We are actually doing pretty well there. The internal operation of the Linux kernel is the toughest part. That is not about how the programs work on the kernel, but about the kernel internally. That is a difficult part for people who already find the material tough. It adds an extra layer of complexity. If we notice that the whole group is slower, we will spend less time on it.’
‘We also offer a separate course for kernel development. People who have to build device drivers can follow the kernel development course after this training. Following the Embedded Linux course first, is a requirement unless people are working with Linux at least 5 years.’

Which people are actually too early?
‘Those who have only been working only with microcontrollers and have little knowledge of Linux. We make sure that they can work on the command line, that they can upgrade their board to a new software version that they have fully compiled themselves and that they can boot from the network, using the network file system as a root filesystem, and so on. That works without prior knowledge by letting them do a number of exercises, but all participants are helped with this if they have – in advance – learned working with the Linux command line.’

Will more experienced people get their money’s worth?
‘Absolutely. People with experience in Linux or embedded Linux won’t get bored. The more they know in advance, the more they will get out of it. We provide so much in-depth information and background information that they will always learn. We go wide and very deep.’

In his Embedded Linux training, participants start working with a Beaglebone Black platform.

This is a print with a Sitara system on chip from Texas Instruments. This American chip manufacturer founded the non-profit BeagleBone Foundation to provide Linux support for these platforms. ‘It is primarily a showcase for the Sitara platform,’ says Nuyens. ‘But it also gives developers a practical step forwards. Everyone can play around with the technology for free. ‘The entire BeagleBone design, the complete PCB layout with all its variants can be completely reused by the customers. By making minor changes to the reference design you can speed up the roll-out of new products by reducing possibly much long work on the software side.’

If desired, Nuyens also has other boards for the course available. It is possible to run the training on Freescale’s i.MX 6 platform (nowadays NXP). ‘This is also a popular platform in the Linux world. The i.MX6 family has single, double and quad core variants. The latter are more powerful for multimedia applications.’ Other variants on which the embedded Linux training can take place are the ZedBoard from Avnet and Atmel’s AVR32 platform. Training on these platforms by Nuyens usually runs on specific requests, typically delivered in-house at customer locations.

Also read the interview with Jasper Nuyens in Bits&Chips.

This article is written by René Raaijmakers, tech editor of Bits&Chips.

The high tech industry is exciting and dynamic. But if you get the feeling that you are always one step behind the facts, that your work is never finished and you still take your stress from work home, then it’s high time to change the way you work. Frank Rood, as an experienced system architect and technical manager, knows exactly which obstacles you can come up against and how to overcome them within time management. He also draws richly from his own experience. ‘I have learned how to deal with every single pitfall that exist.’

Frank Rood (1968) knows time management and the high tech world through-and-through. ‘After completing my degree in mechanical engineering, with a specialisation in precision engineering technology, a course that nowadays falls under mechatronics, I have been involved in multidisciplinary electronics and software all my life. During the first ten years of my career, I was involved in product development within the semiconductor industry, including the development of machines and medical instruments. After my time as a systems architect and technical project manager, I became manager of a mechanical department. Later that post became more and more multidisciplinary, with combinations between hardware, software and process technology.’

Choose what you enjoy doing

As a manager, Rood started in 2000 with an impossible assignment. Besides managing a department with more than fifty employees, he also continued his work as a designer. This resulted in enormous time pressure, with the accompanying stress and bad time management. ‘In order to be able to combine these two roles, I started looking into time management. Then I discovered tools and resources to deal with my available time in a smarter manner. I immediately deployed those skills. In the end, I succeeded in both completing the project well and leading the department. Due to the skills that I learned. I liked the subject so much, that I shared my knowledge with colleagues and with the people I managed.

My last role as R & D director at Besi was very interesting in terms of content, but I didn’t like the accompanying politics at the top of the organisation. I realised that I came home much happier after a day during which I had trained or coached people how to deal better with their working hours. That is why in 2013 I started full-time with my own coaching company. Now I have the freedom to choose assignments that I enjoy, that I get energy from and that really have value for others. In doing so, I mainly focus on the technical sector. For example, I currently work together with a Swedish company in the field of modular architecture. In doing so, I have partly an advisory role and partly a role as an organisation coach to make their company and product more modular, and above all to teach them how to work in a different way.’

Consultation overkill

Rood has now transferred his knowledge and experience of time management into a training that is specifically aimed at product developers in the high tech world. Trainees learn the skills with which they actually get done the things that they themselves consider to be important. ‘For 25 years I have been on the shop floor of companies that develop products and during that time I have seen companies where things are really fantastic and the most beautiful things are being created. There have also been companies that have failed completely, companies in which incredibly intelligent, beautiful, smart, creative people did not come into their own. And that really hurts me. Because those failures happen at companies that are poorly organised or due to all sorts of external factors, and because people have to work in conditions where there are too many disruptions. And those disruptions are totally unnecessary.’

Due to an overkill of consultations and distractions by mail, apps or other means of communication People no longer have either the room, the time or the peace in which to do creative work. During his training, Frank discusses these problems with the participants and tells them how to solve them.

Rood refers to noisy office gardens, an overkill of consultations and distractions by mail, apps or other means of communication. ‘This kind of distraction is increasing. People no longer have either the room, the time or the peace in which to do creative work. And without that, the fantastic potential of all these brilliant people is lost. Because creativity only thrives when there is real peace and time in which to create products. When people are in a stressful situation, the prefrontal cortex no longer works, they don’t get new ideas. And if you are disturbed every ten minutes, you can never go deeply into your brain. Then you cannot write, and are unable to design or code software. Therefore I coach these people and these companies so that all their developers are in the right environments and have the skills with which they can really do their work.’

Professionals often have difficulty with the tension between their actual work and the high intensity of their working environment. They are more concerned with day-to-day issues or their email than with their actual task. Or they find it difficult to say no to a colleague’s request. ‘It is all about managing all those external impulses in the right way, so that you can keep yourself busy with what you are hired for. If you don’t manage that well, you get stressed and if it really goes wrong, a burn-out. You need skills with which you can shield yourself without becoming a hermit.’

Sharing experiences on high work pressure is an important part of the time management training.

‘Saying no is particularly difficult, for example, because it is believed that the relationship with a colleague will suffer from a ‘no’ or that it will then become more difficult to ask the colleague for a favour. But those convictions usually turn out to be incorrect. ‘Don’t use too many words to say no, be clear in your message. It all starts by being clear to yourself about what your own goals are, what you really want to do. As soon as you know that, you can deal with impulses from your environment much more easily.’

Frank Rood is fanatic with time management since he is super sensitive to stress and feels responsible. Especially perfectionist and people having diffuculties saying no are sensitive to become over-worked or even to have a burn-out. ‘I show all the characteristics of an average trainee and therefore I understand the technicians who come to these trainings so well. I know their job, I understand their working conditions and I have learned by trial and error to deal with it. In a short period of time, I can teach them all those things.’

Mono-tasking and dealing with disruptions

Rood’s training course starts with a whole day’s explanation of the theory behind time management when trainees can also practice with each other. ‘The theoretical basis is perfectly understandable, the problem lies in actually putting it into practice. Therefore, the first day we look at what is actually going wrong, where the problem lies and what it is that people want to achieve. Setting goals is crucial. Once you have identified your goal, you can make choices and determine which things have priority and which are unnecessary because they don’t contribute to your goal. Then we look at the tools and at the time management matrix. With this matrix you can determine what is important and urgent and how you can sort your tasks accordingly. We go into mono-tasking, the benefit of doing only one thing at a time and finishing it off. And how to deal with disruptions. We then make a plan so that people really know what they will do differently the next day at work. And they get a tool to help them keep their intentions: a buddy from the group or a colleague who helps with practice in the method over the following weeks. Because everything is aimed at getting people to work immediately with what they have learned. I phone them during the week to hear how things are progressing.’

The quadrant with tasks and disruptions classified in order of importance and urgency, is a simple tool for setting priorities in your available time.

After three weeks, there is an additional half-day meeting, during which the trainees recount what has and has not succeeded. This feedback day forms the basis for the success of the training course. ‘Because the course participants know that they have to be accountable on the feedback day, they actually get to work. By the time we meet again, they have worked for over a month using new daily habits and structurally changing their behaviour. For example, they create a to-do list every morning or they permanently switch off email notifications. Some people ask me if I want to call them again four or six weeks after the training course, as reinforcement. Or they agree to meet with their buddy.’

Three weeks after, participants come back for another half day of training. This half day is the basis for success since the participants feel their responsibility for being devoted. ‘By the time we see each other again, they have had one month in which they changed their daily habits and structural behaviour’ says lecturer Frank Rood.

A conscious choice

Also people who are heading towards a burn-out, have a burn-out or are just recovering from it, benefit from Rood’s training. Not least because he himself also suffered a burn-out. In that period he was manager at a department where, after a reorganisation, fewer people had to do exactly the same amount of work. ‘I felt bad about that reorganisation, where I had to send away a number of people. Everyone was then overstretched and due to a sense of responsibility to my employees I ended up trying to save them by partly taking over their work. That went fine for a long time, because I was strong and of course good at time management. My private environment did give alarm signals. For example, my partner asked if everything was alright, I noticed that I was so tired and sleeping badly and caught all sorts of ailments. But I ignored the signs, because in such a stress mode you are full of adrenaline and then you don’t see that things are going wrong.’

Rood collapsed on holiday. ‘Literally. I fell down and was unable to stand up anymore. It was quite shocking for someone who is quite a control freak to be completely out of control. Moreover, I felt extremely guilty: I finally had time to spend with my family and now I was just lying in my tent on my own…. Fortunately I was back on my feet after a few days.’

After that holiday, Rood changed course drastically. ‘Since then I have been running twice a week and I still do that. I started to slow down a lot and let things slide away from me more easily, I didn’t have to take on all the responsibility anymore. So I chose very consciously for my health and my family. And after that I went back to work fairly quickly, even though I went from almost sixty hours to forty hours a week. And I took a day off in between. That helped.’

Rood calls the loss of control, and a body that takes over, typical of a burn-out. ‘Your body understands that your head cannot handle it anymore and just stamps on the brakes. The trick is to recognise those symptoms the next time before your body takes over.’

He finds he himself the greatest enemy in this respect. ‘Why am I so fanatically involved with time management? I am super sensitive to stress, I feel very responsible, I am a perfectionist and relationship-oriented and I can hardly say no. So I show all the characteristics of the average trainee and have all the pitfalls within me. That’s why I understand the technicians who come to this training course so well. I know their work, I understand their working conditions and I learned to deal with them by trial and error. So they can learn all these things during the training course, in a short time.

Frank Rood; ‘Failures come from bad organisation, several external facts and the fact that people have to deal with too many disruptions. Those disruptions are unnessecary.’

In addition to this skills training course, Rood also guides people on an individual basis, as a coach. In doing so, he goes into detail on deeply-set themes and convictions that form obstacles at work. ‘In addition, I also pay attention to nutrition and exercise. With people who are in the midst of a burnout or crisis, we first look at practical measures: how do you get more sleep? How are you looking after yourself? What kind of exercise are you doing? And what can you do at work? Only when that is working do we work on your convictions. Ultimately, the question is: at the end of your life, will you have done what you wanted to do? So that you don’t think on your deathbed: if only I had spent more time on my relationship, or I wish I had seen my children more or that I had made that trip. Because then it is too late. My biggest wish is that people don’t get in that situation. And that they can conclude that they have done the things they wanted to do, things that make sense of their existence.’

This article is written by Mathilde van Hulzen, tech editor of High-Tech Systems.

Mechatronics System Design part 1 and part 2 are amongst the most popular training courses in the high tech industry. The courses originated in Philips CFT, where system development became increasingly complex in the 1980s. Rien Koster saw that the solution lay in better collaboration between disciplines. Former CFT member, Jan van Eijk, explains why it is good for top specialists to hang out with, and talk regularly to colleagues from other disciplines.

It is 1986, when Rien Koster – one of the godfathers of Dutch mechatronics – starts an ambitious project at Philips. His idea is to take all leading specialists from mechanics, electronics, control engineering, software and measurement technology out of their sanctuaries and have them work together on a mechatronic system. They baptise the project Fast and Accurate 86 (FA86). The plan seems to be a guarantee for success, but in practice the star players fight with each other. Each and every one of them thinks they should take the lead.

Koster continues. And finally FA86 delivers the Famm robot, a two-arm system with large direct drive engines such as you find in submarines. The Famm (fast and accurate manipulator module) is so strong and fast that other robots fade in comparison. Unfortunately, the solution is too expensive for the industry.

‘Technically speaking, the Famm robot was an amazing feat, a fantastic example of what you can achieve if you make all top specialists work together,’ says Jan van Eijk. Van Eijk was, for many years, the mechatronics figurehead at Philips. In 2010, together with former CFT colleagues Adrian Rankers and Maarten Steinbuch, he founded the Mechatronics Academy, the partner of the High Tech Institute which is responsible for all mechatronics training.

According to Van Eijk, the FA86 project showed, above all, how difficult it is to bring the various disciplines together on an equal basis. ‘A mechanical engineer can come up with an amazingly beautiful and feasible design, without realising that his design will never work in practice. The language that his colleague from control engineering uses to explain that – with his decibels and Bode diagrams – is a mystery for the mechanic. ‘

There is often a lack of mutual respect between the different technical disciplines, says Jan van Eijk. The mechatronic guru advocates training specialists, and, at the same time, training them to  communicate efficiently with their colleagues from related fields. They cannot master everything in detail, but they must understand a bit of everything, especially the discipline-specific language.

Koster often shows a graph which portrays all specialists as a Dirac function, remembers Van Eijk. ‘They are very good at one thing, but their knowledge is not wide,’ explains Van Eijk. ‘Their managers and directors were shown to be wide, with not so much height. On average, they were about equally intelligent. We were looking for specialists who were slightly more widely oriented so that they could talk to experts from other fields.’

Philips CFT started a ten-day course to bring down the walls between the specialist kingdoms. During the training, all relevant disciplines came into the limelight and the participants learned what their colleagues were concerned about. Teachers talked about their own expertise, so that the students got used to the jargon. The goal was to increase respect for oneother’s disciplines, says Van Eijk. ‘And arouse their curiosity about the other. If someone in another department asks why they are doing this way and not that way, it should not produce a hostile reaction. This had often happened in the past.’

All new employees at the mechatronics departments of Philips received the training. ‘Often we pulled the PhDs to pieces first’, laughs Van Eijk. ‘They thought they were great and we showed them what they did not know yet. We still wanted great specialists with the best scientific, latest knowledge, but they had to be able to talk to their colleagues. Otherwise it was no good.’

Demystification

The mechatronics training course was a great success at Philips and is now in its thirtieth year, and since 2010 running from the Mechatronics Academy. Mechatronics Academy is offering the course under the name Mechatronics System Design (abbreviated as ‘Metron’) via the High Tech Institute. Because it is difficult for many participants to be away from work for two weeks, the ten-day course has been divided into two sessions of one week each (part 1 and part 2).

Van Eijk is very clear about the usefulness of the Mechatronics System Design course: ‘It takes you a week. That is roughly two percent of what you work in a year. And it makes you ten percent more effective. That’s a gut feeling, but over these past thirty years, I’ve seen how it changes people, how it affects the relationship with colleagues in a multidisciplinary environment. People are able to communicate differently.’

Mechatronics System Design is about the demystification of all disciplines. ‘If I ask a professor about his profession, he will soon have a tendency to tell me about the latest developments. That takes place in a language that is cut out for him, but is totally unintelligible to me,’ says Van Eijk. ‘During the training we discuss a fictitious case about a printer concept from Océ. The trainees then notice that they can already say a great deal about the wishes that Océ has put on the table with a number of simple secondary school sums.’

Jan van Eijk: ‘The training course takes you a week and makes you ten percent more effective.’

The lecturers from all disciplines discuss exactly what is needed to enable mutual communication between the specialists. ‘We will not be able to avoid a number of basic tools,’ says Van Eijk. ‘A Bode diagram for example. Many people have seen that sometimes, but have hardly ever used it in practice. On the basis of such a diagram, a control engineer can explain clearly to a mechanical engineer what problem he is struggling with. If they want to find a solution together, it must therefore be part of their common language.’

Regarding the basic principles of the course, little has changed in the past thirty years. However, technical subjects have been added, such as thermal design and metrology. Is there more attention given to software, a discipline that is becoming increasingly important in mechatronics? ‘Well,’ Van Eijk answers thoughtfully, ‘that is a bit more nuanced. Yes, it is becoming more important because the amount of software used and the effort that it requires are increasing. But if we look at functionality, it is different. For high tech mechatronics, functionally, you only need a limited amount of software. Of course it should be well organized, in the background, with event handling, error messages, user interfaces, you name it. However, the contribution of the functional software is at most a few percent of the software as a whole.’

Master your profession

‘Mechatronics system design’ therefore revolves around the cooperation between the various disciplines. Is this not always reflected in the curricula in the universities?  ‘Collaborating across the boundaries of the university departments is still fairly incidental,’ says Van Eijk. ‘It goes terribly well in the definition phase and when it is decided who gets how much money for which PhD student. After that, everyone dives into his own foxhole to perform his own part in perfect, splendid isolation. The High Tech Systems Centre is a step in the right direction. Perhaps people will emerge that are more inclined towards a cooperative relationship ‘

The course has a strong industrial background. ‘Recently ,there was a student who told me that he also attended a mechatronics course at the university and therefore might hear things that he had known for a long time,’ says Van Eijk. ‘That risk is not that great. In the case of a university course, the lecturer devotes a great deal of attention to his own discipline and the scientific depth of the same. We only have teachers from the industry. We tell you how it works in practice. And there is a considerable difference in emphasis. At university, students may learn more about how to count on an electronic network and make calculations about mechanics. You learn a few skills that can be very useful, but you cannot have a good discussion with another specialist. My conviction is that we have to train great mechanical engineers, electronics engineers and control engineers and have them work together to build great machines.’

Van Eijk is therefore very critical about the mechatronics education offered by a number of higher professional education programs. ‘We want nothing to do with someone who is half-electronic and half-mechanic. He does not do either discipline properly. Someone who knows half of two courses or, worse, a sixth of six subjects, is something I am not happy with. If you want to train a really good mechatronic, you need five years for each individual discipline. So, all together it takes about forty years and he can retire. That’s no good. Instead, we have to teach them to do something together with several people. That is the challenge. And you do not learn that from a formal mechatronics education.’

‘The biggest danger is that when you have done that education, you think you can do everything. You have seen many things, but you don’t speak any language really well. You cannot really get a complete mechatronic system off the ground on your own,’ says Van Eijk, who emphasizes that such a mechatronics program can attract pretty good people, but that it seems more sensible to everyone to become trained in their own field first. ‘In a company, a graduate in mechatronics will first be asked to develop expertise in one area. The baggage he carries will probably bear fruit in the long term, but first he has to gain more knowledge in mechanics or electronics. Only then can he play a valuable role in a mechatronic environment.’

This article is an adaptation of the interview of Jan van Eijk by Alexander Pil that appeared earlier in Mechatronics & Machinebouw.

 This article is written by Alexander Pil, tech editor of High-Tech Systems.

Are you tired of endless discussions and ineffective meetings? Or are you completely stuck in the development process due to lack of new ideas? In the high tech world, creativity is also an important skill for technical designers, developers, testers, automation specialists and engineers. The beauty is that everyone is creative. Trainer Rex Bierlaagh, helps technical experts step out of their usual thought patterns and solve really difficult tasks and issues both effectively and efficiently. ‘Creative innovation can be learned.’

We are living at the beginning of the fourth industrial revolution. A period in which technologies from different disciplines are converging and in which the boundaries between the physical, digital and biological worlds are becoming blurred. This 4.0 Industry cannot exist without 4.0 professionals, professionals who will still be important players in the market in three to five years’ time or who will at least be able to deal with the latest changes in the industry. In order for this to happen, it is necessary for employees to possess three important skills: to be able to solve complex problems; to be able to think critically; and to be creative (research results from the World Economic Forum). Creative Thinking thus plays an important role.

Rex Bierlaagh is the owner of the innovation provider TWNQL and gives the training course Creative thinking (1 or 2 days) at High Tech Institute, in collaboration with Technical Training for Professionals (T2Prof). Bierlaagh is a certified trainer for the De Bono methods: Lateral thinking & Six thinking hats. 

According to the trainer Rex Bierlaagh, creativity is the 21st century skill. ‘Problems and projects are becoming more and more complicated, but the way in which we tackle them continues to be rigid and not that effective. As adults, we are stuck in calibrated thinking patterns. Large companies are therefore struggling with the question of how to get their employees involved in change, how they can get them to work well together, also across borders, and how these employees can come up with new ideas. In small organizations that are growing fast, there are regularly high, repetitive discussions that distract from the actual goal. Other companies feel stuck in the innovation process or turn around and around in circles.’

The good news is that creative thinking and innovation can be learnt. ‘All children think creatively, but at home and in education people are taught that there is only one solution to a problem. In reality, there is of course more than one way to reach a solution. You come to these alternatives by making connections between things that at first sight have nothing to do with each other, by making free associations. Creativity is a skill that everyone possesses, whether they believe it or not. It makes a person more agile and resilient.’

Courses for creative thinking

Bierlaagh, in the Creative thinking training course, takes people back to their original way of thinking. Creative thinking can also be called lateral thinking, a method of thinking developed by Edward de Bono. Bierlaagh is a certified trainer for De Bono’s method. ‘If, during the course, people recognize what creativity is, what is done with it and what they themselves can do with it, then they literally get a twinkle in their eyes. You see them thinking: how cool is this, this gives me energy. After the two-day course, they are in possession of the tools with which they can come up with creative ideas at any time. For example, during brainstorming sessions, if they want to develop a new product or improve a work/production process.

There are two variants of the Creative thinking course: a short one-day course and a longer course of two days. The first day deals with creativity, with its effects and with two thinking techniques that stimulate creativity. On the second day two additional thinking techniques come into focus and students learn how to complete the thinking process: clustering ideas, choosing and reaching a solution. ‘After the second day you will be able to guide brainstorming sessions in an effective and efficient way and participate productively.’ Bierlaagh likes to keep matters practical. ‘We will practice and experience things. People often think that we are going to sing or dance, because that is what they see as creativity. But it is all about learning new ways of thinking. Many people, especially technicians, indicate at the start that they are not very creative. But gradually they find out that this is not true at all and that it is really nice to learn to think in these new ways, also as part of a group. And that it does not create tension at all, quite the opposite, it is motivating. ‘

Courses for creative cooperation

Creativity is also the solution to a daily recurring problem that many technicians struggle with: inefficient and ineffective meetings and team meetings. ‘At ordinary meetings people react to each other without knowing exactly what the other person means,’ says Bierlaagh. ‘As a result, each consultation takes longer than one would like, and you rarely reach the result that you had foreseen.’

In the Effective Communication for efficient and creative cooperation course, students learn how to collaborate creatively by using De Bono’s Six Thinking Hats. Each hat is a different colour and represents a specific way of thinking. By using the ‘hats’ in a fixed order, complex problems can be unravelled quickly.  What follows, is a workable solution. Individuals who use the six thinking hats during a meeting, don’t all take a different position; they think in the same way at the same time.

‘Analytical people, such as technicians, enjoy using information; thus, they are naturally inclined to put on the white hat. The white hat stands for facts and it forms the starting point for this way of creative collaboration. The blue hat, used to manage the thinking process (the chairperson/leader), and the red hat, which signifies feelings, hunches and intuitions, are less obvious to technicians. But these ways of thinking are often just as important as those aforementioned. By, together, passing through a number of ways of thinking in a short time, one comes rapidly to the correct conclusion. We also call this parallel thinking. In the beginning, for many people, this feels artificial and a-logical, but if you have applied this method a few times and have also been on the receiving end, you don’t want anything else. Because you come to the core so quickly in cooperation with others. Technicians who have followed this course are also very enthusiastic when they notice that, when using this method, they have more spare time, since they can act more quickly. In turn, this creates room for more creativity.’

A one-day training course is sufficient to cover the contents of Effective Communication for efficient & creative cooperation. The morning covers the theory and in the afternoon the students apply what has been learnt to practical situations. ‘This method ensures that the quality of your decisions increases much more rapidly.’

This article is written by Mathilde van Hulzen, tech editor of High-Tech Systems.

For technicians, communication can be likened to a black box. They know it’s important: once in a while, they have to deal with that dominant colleague or that coercive boss. But to get things done at their work, the logic of their story is of major importance. Jaco Friedrich, the trainer of soft skills and leadership at High Tech Institute, talks about the basics of communicating in the high tech working space.

Jaco Friedrich started as an engineer and studied psychology in the evenings. Now he trains technical leaders in communication and leadership.

Those who have been in the high tech world for several years will no doubt have experienced a major crisis at some point in time. One in which everything grinds to a standstill: the integration of the first prototype does not go without a hitch, colleagues sit with their heads in their hands and start to point fingers.

In a major crisis – one in which the company’s survival is at stake – management often resorts to extreme measures. It deletes the entire project or uses rigorous means to get things moving smoothly. A proven recipe for solution is to put together a team of the best experts and system architects. They receive a clear assignment and objective: save the project, at all costs!

Once a dream team has been formed, people often sigh with relief. Everyone knows: these people will sort it out. And often they do, very quickly: they have things running smoothly in no time. Why? Well, the experienced professionals are top experts, they know each other through and through, respond to each other with knowledge and ease and have a clear goal. The lines are short, they communicate well, and management gives them ample room to maneuver. The set goals take priority over anything else and within a few months, things are back on track. All’s well that ends well: marketing and sales are happy, and everyone goes home richer and more experienced.

Wonderboys

Why does everything suddenly run smoothly again after such a dip? Why is it that, at first, nothing works in the slightest, then in a matter of a few months, a small group of wonderboys turn it all around and get things going again? Technicians know it has to do with leadership and communication, but it’s often difficult for them to get the hang of it. “For technicians, communication can be likened to a black box. Everyone knows it is important, but nobody knows exactly why things are going well or not,” says Jaco Friedrich, the trainer of soft skills and leadership at High Tech Institute. “The good news is that everyone, even technicians, can learn communication skills quickly and efficiently.”

It starts with understanding each other well. That’s the underlying basis for good collaboration. This means not only being a good listener but also knowing how to make your point. Which is something that comes in handy every day, also at home. “It’s important to be sure that you understand the other person properly,” explains Friedrich. “And when you do that you must prevent yourself from drawing the conclusion that you do understand. Because then you notice later: shoot! I didn’t understand it at all. Then you usually have to pull out all the stops to straighten everything out again.”

A good listener

Being a good listener is one of the skills needed in order to understand each other well. You can train and learn how to do that. In the world of soft skills, it’s known as LSA, which stands for listening, summarizing and asking further. The principle is simple, Friedrich explains: “It’s about knowing for sure that you understand the other person and, in return, also knowing that the other person has understood you. This scientific fact puts one’s mind at rest: we understand each other, it’s fine. This means that if you notice that your partner in conversation doesn’t understand, then you don’t immediately insist on repeating what you are saying, you learn to switch. Instead of going over the same information you start asking questions and you try to find out why your partner in conversation looks at things differently. It’s a balancing act, steering and moving forward. It’s not that easy.”

Many technicians have little trouble getting into this. It becomes exciting when the message is critical. For example, if you have to point out to someone that they’re not fulfilling their agreements, or if you have to put into words that you’re disappointed with the contribution made by a colleague. “Then there’s a good chance that the relationship is at stake,” says Friedrich. There are, according to him, two errors lurking. The first is not to comment on it or only to comment on half of it, the second is that you become extremely blunt, so that your message is clear, but your relationship is damaged. Friedrich: “You don’t want either situation, so you need the skill to get the message across and maintain the relationship.”

These types of principles are discussed in the basic communication skills training course. “Here, we focus primarily on behavior. The course is also about why people do what they do. Sometimes you see that someone can’t say no, even when he’s at a complete loss at work. In fact, such a person should say no for reasons of personal preservation, but he doesn’t. That’s not because he has a speech impediment. It’s not because he can’t say the word no. It’s due to personality, commitment and the feeling of being responsible. With training, it’s really possible to change that. People who learn to deal with this will grow enormously in self-confidence.”

The stakeholders’ shoes

Most of the time, colleagues work best amongst themselves. Certainly, colleagues working on the same topic are quickly on the same wavelength. Technicians seek each other out, speak the same language. Usually, the problems only start when the size of development teams increases and technicians have to work together on large complex projects. In these situations, they not only have to deal with other technical disciplines but with stakeholders of all sorts: the production manager at the supplier, their own management team, the customer and even the end user. Coordinating with colleagues from other technical disciplines is often quite a challenge, let alone with managers who don’t hide their irritation when they hear the first technical jargon.

Within large projects, it’s often a case of motivating. How do you convince your boss that this rare specialist has to work for you one day a week? How do you explain that you need that one training course? How do you express the fact that with an additional investment of two million euros in that one module, the margins on the total product will be tens of millions higher? “There’s a great deal to say about that,” says Friedrich. “It’s not only about what you say, but about how you bring the message across, your use of body language and intonation.”

The trick is to put yourself in the other person’s place. “You have to step into the stakeholders’ shoes and know exactly where their concerns lie. Perhaps they’re responsible for content, safety or the financial budget. Technicians must respond and express their concerns in such a way that their conversation partner thinks: Hey, this is interesting for me! I have to listen to this.”

Friedrich gives an example: “Suppose there’s a problem with a bolt that shakes loose quickly. A manager will say: ‘Why should I care? Make sure you tighten it.’ But you do have his attention if you make it clear that the bolt in question is very difficult to fix, that it’s an expensive assembly and that there’s a high risk that the complex module will pop out at the customer’s in the factory, with the risk of escalation and potential damage claims. If there’s a hole in the boat, the other person can say that you have to bail the water out because the hole is on your side. You then need to make it clear that he’s in the same boat. That the boat belongs to you both. So, if you want someone to listen to a technical problem, then you have to translate the problem into something that affects that other person.”

Motivation to collaborate

Jaco Friedrich’s soft skill and leadership training courses at High Tech Institute are specifically focused on people who have to work together in a technical setting. In this, content plays an important role. In high tech, good communication is not there to keep it fun and make life rosy. Friedrich explains that this is what makes his training courses essentially different from the bulk of communication training.

Certainly, technicians also have to deal with keeping the relationship right and dealing with a dominant colleague or coercive boss. “But the logic of the story is of major importance,” says Friedrich. “In high tech, you won’t get there with just talk and manipulation techniques. In high tech, people have the attitude ‘I’m an engineer, I don’t buy into stories.’ So, your story must be right when you talk to colleagues. If you invite that one product development manager or talk to customer support, you must know what you’re going to tell and how. If your objective threatens to go wrong, then your story must be substantive in order to convince the other person that it’s in their interest to help you. This is the only way to get buy-in: the motivation to collaborate.”

Friedrich: “It’s all about numbers, crucial details, risk assessment. Sometimes these discussions can be quite tough. It must be exactly right. Meetings, reviews and conversations always rely on making the right choices. Of course, you have to keep relationships good and understand each other well and listen well, but communication is only a means to an end. So convincing, understanding stakeholders, it’s all about doing the right things together as a team. Otherwise, it will not work.”

This article is written by René Raaijmakers, tech editor of Bits&Chips.

Met een kleine twintig jaar ervaring in systeemarchitectuur verhuisde Gerrit Muller in 1999 van ASML naar Philips Research. Hij vroeg of er interesse was in een cursus op zijn vakgebied. Hij broedde daar al een paar jaar op: hoe hij mensen kon bekwamen in zijn vak systems architecting.

Muller startte in die tijd ook zijn inmiddels vermaarde Gaudi-website waarop hij informatie over systeemarchitectuur vrij toegankelijk maakt. ‘Ik zag dat er weinig mensen waren die het vak begrepen, laat staan konden uitoefenen’, zegt hij daarover. ‘Ik was zo onbescheiden om te denken dat ik het wel wist.’

De kiem werd twee jaar eerder gelegd, toen Muller overstapte van Philips Medical Systems naar ASML. Om de kennis die hij in de medische apparaten had opgebouwd over te dragen, organiseerde hij een week lang interactieve sessies. ‘Dat ging niet erg gestructureerd, maar de deelnemers waardeerden het zeer’, herinnert hij zich.

Gerrit Muller – Grondlegger van de SYSARCH training

Deze kennissessies herhaalde hij, toen hij ruim twee jaar later van ASML naar Philips Research overstapte. ‘Bij ASML had ik veel bijgeleerd. Ik ontdekte bovendien hoe leuk het is om anderen te helpen om het onder de knie te krijgen. Toen ik in Veldhoven wegging heb ik aangeboden om één week training te geven in systems engineering.’

Muller zag dat bijna alle bedrijven een tekort hadden aan architecten. Hij constateerde ook dat dit leidde tot problemen in de systeemontwikkeling, iets dat vooral in de systeemintegratie de kop op stak en zich daarnaast uitte in problemen in het veld. Vooral het laatste is kostbaar en pijnlijk. ‘Terwijl je het kunt voorkomen door met een integrale bril te kijken naar de monodisciplinaire gezichtspunten die er al zijn’, aldus Muller.

Het was Vincent Ronteltap van Philips Centre for Technical Training (CTT) die Mullers aanbod zag zitten. De programmamanager voor trainingen adviseerde de aanstaande docent om deelnemers tijdens de systeem-architectuurtraining ook aan praktische opdrachten te laten werken. ‘Daarmee leverde hij een cruciale bijdrage’, zegt Muller. Ook de huidige trainers bij High Tech Institute kiezen steeds opnieuw een unieke case waaraan de deelnemers gedurende de hele week werken en die ze op de laatste dag ook daadwerkelijk moeten pitchen.

De opdracht – het is altijd een praktische case op maat – loopt als een rode draad door de vijf trainingsdagen. Elke dag werken de deelnemers een aantal uren aan de case, geïnspireerd door de theorie en talloze praktijkvoorbeelden die aan bod komen.

Zoals alle trainingen bij Philips CTT was Sysarch in de beginjaren alleen toegankelijk voor deelnemers binnen de Philips-organisatie. Dankzij mond-tot-mondreclame werd de cursus snel populair binnen de productdivisies van het gloeilampenconcern en kon CTT de training zonder probleem vier keer per jaar uitrollen.

Naast open enrollment startte Muller ook met in-huis varianten. ‘Met open inschrijvingen zit er veel waarde in kruisbestuiving’, legt Muller uit. ‘Het is vaak een feest van herkenning: mensen ontdekken dat in andere organisaties, domeinen en systemen dezelfde soorten problemen spelen.’ In-house cursussen geven juist weer de mogelijkheid om iets dieper op specifieke systemen en organisaties in te gaan. Ook dat heeft duidelijk zijn waarde.’

In de kern behandelt de training tien gezichtspunten op systeemarchitectuur, zoals requirements engineering, key drivers en strategieën voor systeemintegratie – ieder gemiddeld een halve dag. Deze invalshoeken en kennisdomeinen evolueren overigens. Sinds een aantal jaren geleden komen bijvoorbeeld ook scrum en agile technieken aan bod. ‘In de cursus simuleren we wat een systeemarchitect in zijn hoofd continu doet: heel snel meerdere gezichtspunten de revue laten passeren’, aldus Muller.

Mullers training was zo succesvol dat hij tijdens een bijeenkomst van de System Architecture Study Group vroeg om bijstand. De daar aanwezige Ger Schoeber voelde daar wel wat voor. Het leek hem een spannende uitdaging. Hij had volop ervaring opgedaan in de systeemontwikkeling bij High Tech Automation en Ordina en werkte nog niet zolang als zelfstandige. Schoeber: ‘Ik heb er kort over nagedacht. Het geven van presentaties of op een podium staan is niet mijn eerste natuur en dit gaf me een mooie kans om mijn comfort zone op te rekken.’

Na een gesprek met Gerrit Muller en de programmamanager van Philips CTT kreeg Schoeber september 2002 zijn vuurdoop met een vijfdaagse Sysarch. ‘Ik had absoluut de indruk dat de zestien deelnemers eigenlijk veel meer systeemarchitectuur-ervaring hadden dan ikzelf’, lacht de man die de training inmiddels vijftien jaar met veel succes geeft.

Ger Schoeber – docent training System Architect(ing)

Schoeber was in zijn eerste Sysarch-jaren getuige van een sterke groei. Het aantal edities steeg en er kwam meer trainingsmateriaal beschikbaar. Gerrit Muller was inmiddels begonnen aan een promotie op het onderwerp systeemarchitectuur en zijn bevindingen werden vaak meteen doorvertaald naar onderwerpen voor de training.

Daarnaast leerde Schoeber zelf veel van zijn eigen ervaringen in projecten. Hij was tien jaar lang betrokken bij kleine en grotere multidisciplinaire projecten bij OEM’s. Sinds 2011 is hij in dienst bij Hotraco en vult bij de agri-onderneming de rol in van innovatie- en technologiemanager. ‘In al die gevallen heb ik de Sysarch-theorie ook in de praktijk kunnen toepassen. Het leverde mij veel waarde op voor mijn eigen projecten en directe ervaringen met toepassen van het materiaal, iets dat ik weer mooi kon inzetten als voorbeelden in de training.’

Nadat Gerrit Muller in 2004 promoveerde op CAFCR (Customer objectives, Application, Functional, Conceptual, Realization), gaf Schoeber dit framework steeds meer een expliciete plek in de training. ‘Ik ben de CAFCR-methode zelf voor het eerst gaan toepassen in 2005, waarbij ik in een project als systeem architect verantwoordelijk was. Dat heeft me heel veel inzicht, waarde en ervaring opgeleverd.’

In 2011 droeg Philips Centre for Technical Training zijn totale portfolio over aan expert-bedrijven in de regio Eindhoven. Dit leidde korte tijd later tot de oprichting van High Tech Institute, die de trainingen in samenwerking met de expert-partijen op de markt brengt.

Van 2011 tot 2016 maakte de Sysarch trainingen een mooie evolutie door. In de Philips-tijd kwamen deelnemers vooral uit de Philips-productdivisies en grote spin-off bedrijven als ASML, Fei en NXP. Tegenwoordig is de bezetting veel meer gevarieerd. Tijdens de editie van oktober 2017 namen bijvoorbeeld veertien verschillende bedrijven deel. Slechts twee daarvan stuurden twee deelnemers.

Dat onderstreept de waarde die de Sysarch-training met open inschrijving heeft: deelnemers maken kennis met andere professionals die met dezelfde problemen worstelen.

Ger Schoeber gives one of the most popular training courses at the High Tech Institute, in system architecture. He does this in addition to his full-time job as group leader and domain expert system engineering at Lightyear. Schoeber about the role, usefulness and pitfalls for the system architect.

Ger Schoeber attended a meeting of Gerrit Muller’s System Architecture Study Group of in 2002. Muller had set up a new training course based on his experience at ASML and Philips: Sysarch, short for ‘System architecting’. This five-day course had been running for a few years and was now so popular that Muller had asked, during the meeting, who would be interested in joining him as a teacher.

The question intrigued Schoeber. He had extensive experience in system development at High Tech Automation and Ordina and had not been working as a self-employed person for so long. ‘I was not at home standing on a podium and this gave me a great opportunity in which to stretch my comfort zone. When I received my baptism of fire in September 2002, I had the absolute impression that those sixteen participants actually had a lot more experience in system architecting than myself, ‘ Schoeber laughs.

Gerrit Muller received his PhD in system architecture during those years, a subject that was not taken very seriously in the academic world. His findings were often immediately translated into subjects for the training. After Muller’s promotion in 2004, Schoeber took over his method CAFCR (Customer Objectives, Application, Functional, Conceptual, Realization, pronounced as: kafkar). This framework grew into the core of the system architecting training in the years that followed. ‘I myself applied the CAFCR method as a system architect for the first time in practice in 2005. That gave me a lot of insight, value and experience,’ says Schoeber.

Above all, practical experience is valuable and Schoeber shares this with the participants in his courses, of whom there have been over a thousand. He has been involved for almost three decades in small and larger multidisciplinary projects at OEMs. Since 2011 he has been employed by Hotraco, an agri company where he fulfills the role of innovation and technology manager. ‘In recent years I have been able to apply Sysarch theory in practice. It has given a lot of value to my own projects and provided direct experiences with the application of the material, something that I have been able to use once again as examples in the training courses.’

Putting yourself into the client’s shoes seems natural, but it is the most difficult thing of all, says Ger Schoeber.

Thinking business-like

The system architect is responsible for the technical realization of a product or subsystem. System architects always have many years of development experience. Both this background and technical baggage are indispensable. But system architects must have social skills in order to fulfill their role, because they are in contact with all stakeholders. Not only with the people in the development team and suppliers, but also with the management team, investors, customers and end users.

Schoeber sporadically sees non-motivated course participants. These are often technicians who have been sent on the course by their boss. Schoeber considers them unsuitable for a role as a system architect. ‘System architects are proactive and must take the lead in technical development. They are motivated by definition, want to be at the forefront. They also have a vision: that’s what it is all about. They must also radiate their faith and trust in it.’

This has consequences for the way that system architects work within an organization. They have to be strong and confident and dare to say no. ‘If they do not have enough confidence in the successful completion of a project, they should not accept the assignment. Actually they should immediately say: I’m not going to do this. Because if system architects don’t trust it, the people in their team pick up on that immediately. They radiate it, non-verbally.’

Assessing whether a project can succeed or not, whether something is technically feasible and can lead to commercial success or not, is part of the task of a system architect. Schoeber: ‘The challenge often lies in the latter. Technically, something can be a fun job, but does it also have value for the customer and for the business? We also emphasize the last two steps in the training course. System architects need to think beyond just the fantastic technical aspect. It must also be right for a customer. That means that they have to be able to think from a customer’s point of view.’

In addition to having empathy, system architects should not lose sight of the value of the project for the business. ‘You can make something fantastic and make the customer very happy by offering it for nothing, but then it has no business value. So thinking business-like is also important for the system architect. ‘

What are the biggest pitfalls for system architects?

‘That they do not stand up enough for their team and say: I’m confident that this will work out. Because if you do not have that feeling yourself, then it will not work. An even bigger challenge is thinking from the customer’s point of view. I often say that you do not just have to make what the customer asks for, but to make what the customer needs. I ask the question: try to stand on the other side. Change places. What end result would you like to have as a customer? What do you need help with? If you need to create a subsystem that will be integrated into a larger whole, then imagine yourself as the party that needs to integrate that piece. What is it then that you need help with? Is there something extra that makes integration or verification easier? If you start thinking from that position, you discover that you have to do more than simply perform what is in the requirements.’

Why is putting yourself in someone else’s shoes so difficult? It sounds so easy?

“That’s the hardest thing. Not everyone has sufficient empathic ability. Empathy is perhaps even more difficult for men. Women can experience emotion better and put themselves in someone else’s position. For that you also have to dare to be vulnerable. Men are more macho: look what I made. It would be nice if more women took on the role of system architect.

So it’s nothing for the diehard technician who wants to be technically excellent?

‘No, technicians should never want to become system architects. They should, above all, continue to do what they like doing: being active with their technique and being a specialist in that. Technicians can be very good at thinking of solutions, but in order to make a commercially successful product, you also have to ask what the problem is. That means you have to be able to inquire: why do you really want this? With this you penetrate deeper into the real need. Because a customer, also one of the stakeholders, often thinks of the solution, instead of trying to explain what their problem is. ‘

In collaboration with Incose-NL (International Council on Systems Engineering) and the high-tech magazines Bits & Chips and Mechatronica & Machinebouw, the High Tech Institute recently organized the Dutch System Architecting conference. Schoeber was Chairman.

Is that the customer’s pitfall?

‘The customer has often devised a solution direction himself. It is tempting for the system architect to follow their lead: Oh yes, we have to do that! Instead, you have to counteract that and say: Why do you want this and why do you want to solve it that way? This is precisely where the CAFCR model devised by Gerrit Muller helps.

What does CAFCR mean?

‘It’s all about moving into the customer’s shoes. In doing so, you look at system architecture from five viewpoints. Only two of them are about technology, about the solution. For example, the C of ‘conceptual view’ says: I want to communicate wirelessly. That is more general than the R of ‘realization view’, which is about the technology that is needed to reach the solution, for example bluetooth, wifi or zigbee. ‘

‘The other three are about the customer’s perspective. In my opinion, that is where the greatest value of the CAFCR framework lies. The F of the functional view is about the specification, the requirements: What does the customer expect from the product or what do the stakeholders expect in functionality, quality and performance? The A of ‘application view’ requires that you look at the broader context. In which environment does the subsystem or system come? How is it applied? If you have a good idea of ​​that, then you also understand what is useful or not. That enables you to improve the requirements. ‘

‘The first C of customer objectives’ is all about the customer: What exactly is their business? How do they earn their money? What is the living environment of the customer or the colleague who is going to install my subsystem? If you understand that better, you will see better what it is that they need in order to do better business. CAFCR forces me to look not only at the technology, but also at the specification and the rationale of the requirements. It allows me to come up with solutions that help customers even more.’

As an example, Schoeber refers to Gerrit Muller, who experienced the development of a new generation of radiological equipment at Philips Medical in the late nineties. At that time the medical world sat in the middle of the transition from analogue to digital. At Philips they had designed a beautiful system that radiologists and other specialists could use to assess everything on high-resolution screens. The Philips technicians only discovered at a late stage that this did not match the practice. Radiologists hung photographs in a light box and if they had some time in between, they grabbed their dictaphone and whilst walking they discussed the diagnosis and treatment.

Schoeber: ‘Muller showed that it is useful to walk with a radiologist to see how they spend their day. That print function was not in the original design, it was added later. The lesson is that you have to empathize with the customer’s experience at an early stage.’

Schoeber therefore advises system architects to spend a day with customers to discover what they really need. ‘Océ does that too. They parachute their technicians into a customer environment to experience how they work with copiers and printers. They take that knowledge back to the organization.’

‘I also force myself to be in a chicken or pig house regularly or work with the installer of our items. This gives me plenty of ideas about handy adjustments or better working methods. In the nineties, during a project for patient monitoring systems, I once put on a green jacket with a green cap and I sat in on four operations in a hospital. I saw what an anesthetist did with a patient monitor in an environment with blood and stress. Only then did I see what was really needed in an operation and the necessary functionality required. I could not have thought of that behind a desk. You understand the priorities only when you go with the customer and spend a day with them.’

Does the product manager also have to know that?

“Yes, they should know that. The system architect hears from the product manager what is needed and must translate that into a specification that a multidisciplinary engineering team can then carry out under their management. But if an architect only hears it and never experiences it, then they miss that emotion. Moreover, the product manager is often outside the company, not in-house. So the system architect has to go to the customer every now and then.’

Isn’t it a waste of time?

‘The time is immediately recovered. I once had the opportunity to supervise an architect at Vanderlande. He started looking at the commissioning of a baggage handling system. So-called commissioning engineers work there. He saw that those installers had come up with a workaround. They wriggled around corners, but did not recognize it as a problem anymore because they were used to it. “Oh, can it be different?” They reacted amazed when they heard from the architect that he could incorporate a function in the system that would save their work. You could send a survey to all those engineers, but you would probably get a lot more useful information by just spending a day with them.’

It is also a skill to transfer the knowledge to the team. When Schoeber worked at a high-end remote control at Philips, he commissioned a team member to learn all the infrared protocols. The technician proudly returned with the result: his prototype could, in addition to signals for the video recorder and TV, also imitate the infrared of fluorescent tubes and the sun. ‘So my colleague had taken me literally, because the remote control had to filter out the infrared signals in the ambient light.’

How do you learn to transfer the knowledge well?

‘It is not a matter of writing down specifications as good as possible and sending them to your engineering team. You must continue to explain it and repeat it over and over again. The human brain just doesn’t work like a computer memory. System architects cannot hide behind a statement like: “But didn’t I say that anyway?” You have to explain the same thing over and over again, keep on repeating it, otherwise it will not be registered.’

‘It is not just about technical details, but also about the strategy and vision of the project. What is the goal we want to achieve? What is the end point? That must be clear. The endpoint is something that works as specified and that is reliable, but there is also a deadline. If you want to introduce a product at a market event, then that is the strict deadline. Then you sometimes have to take a shortcut to get it done.”

In the end, balance is the great magic word for the architect, says Schoeber. ‘You can think of the best architecture, apply the best technology, but if the development takes too long, you have no business and salaries cannot be paid. The architect is in the middle of that game. Their own engineers want to make the best product, but it shouldn’t be gold plated. The customer ultimately has to get value for their money. They pay. The architect must also ensure that there is lasting business. Think of production, easy maintenance and future generations. Taking into account all those interests and stakeholders, something has to be created.’

This article is written by René Raaijmakers, tech editor of Bits&Chips.

Jasper Nuyens stepped somewhat eagerly through information technology. He was the first Aibo owner in Belgium and programmed his own Tesla. The biggest embedded Linux problems land on his lap.

Jasper Nuyens with an OpenSource BeagleBone board that participants use in his embedded Linux training and a hug from Tux, the Linux penguin.

Linux & Tesla

It is Elon Musks’ biggest nightmare that hackers worldwide take control of all Teslas remotely. ‘A doom scenario, but it is not impossible,’ says Jasper Nuyens, founder of Linux Belgium and embedded Linux trainer at the High Tech Institute. One key to gain access to one of the computer systems – the so-called ssh-key of the navigation cluster – is the same for the entire Tesla fleet.

Nuyens knows, because ‘through a friend’ he has secured such a ssh-key (‘ssh’ stands for ‘secure shell’, the standard for communicating with Linux systems). Not to harass Musk, but to reprogram his own Tesla. These cars have different embedded subsystems: Nvidia Tegra-based electronics around the wheel and the media console and ARM64 for the autopilot. It all runs on Linux. Nuyens, among others, adapted his control panel himself. ‘A little customised,’ he laughs. ‘With an X Window application, for example, I make the colours fade.’

Nuyens has a tip for Musk: if you want to sleep peacefully at night, it might be better to give all systems of all Teslas their own ssh-key and store them in a secure central database. This is already happening with a daily changing key for remote access to the central display. ‘An extra layer of safety, why not? It is still true that everyone has the same ssh-key on the navigation cluster and in principle you can obtain them online.’

However, it’s not easy to get into a Tesla. A physical connection with the internal network is required and the dashboard must be open for this. “It is very well shielded,” says Nuyens. Yet his skill with Linux is not the main reason that he has bought one. ‘The decisive argument came to me when I saw the retreated glaciers in Iceland.’

He does not touch the Linux-based system for autopilot. ‘I do not want to do anything wrong with regard to the control of my car. It is possible, people do it, but I, personally, find it a bit too dangerous. That is why I do not play much with the CAN-bus. However, I would like to make another variant of Tesla’s Christmas light show. I already have the Game of Thrones tune ready for it.’

Robot woof

Nuyens acquired a Macintosh computer at the age of nine and founded a computer club a few years later. Not many years later later, he started publishing articles about computers. And then also about Linux. He even authored, in 1996, the books ‘The Internet in Belgium’ and ‘Maximise your Mac’. For the first time, he wrote a review for every Belgian website. ‘There were only a few hundred.’

Nuyens tasted mathematics, physics and computer science at KU Leuven and Hasselt Universities, but did not complete his studies. ‘When I started at university at the age of sixteen, I saw many Internet Service Providers start up. Netvision/Ubizen (now owned by Verizon, RR) also started. I missed that first boat, but I really wanted to grab the internet boom.’ So he stopped studying in 1998 to start his own company at the age of 21.

Two years later, before the dotcom bubble burst, Nuyens sold his business to the NASDAQ listed VA Linux Systems, the company behind Sourceforge and the websites Linux.com, Slashdot and Freshmeat. That was fairly independent at the age of 23. He then set up Linux Belgium and bought the Aibo robotic dog from Sony. He was the first in his country and even in TV programs he was invited to talk about his robot woof. Newspapers wrote hilarious pieces at that time about ‘the young manager with a Saab Cabrio under his rear’ (Het Belang van Limburg).

With Linux Belgium, he focuses on consultancy and training. ‘I’m lucky that they ask me for advice when there are really difficult problems. This ensures that we always receive very special cases and that makes the job very interesting. It also ensures that our course stays up-to-date.’

Although he is no blind follower, Nuyens is very positive about Linux. ‘It is one of the most impressive technical achievements of our century,’ he writes on his Linux Belgium website. ‘More than a billion mobile phones run on Linux-based Android. All known servers work with it. In addition, billions of smart devices have the operating system on board and tens of millions of people use the OS on their PC. Google, Facebook and Twitter, they all run on Linux. ‘

1,4 MB floppy disk

In 2005, Nuyens developed the ‘Embedded Linux’ training course in collaboration with Mind (now Essensium). It turned out to be the very first embedded Linux course in the world. ‘We did it at the request of a customer. Developing a new course for embedded Linux was a lot of work, but we did it anyway.’ To the great surprise of Nuyens and Mind, the training became very popular. ‘In the field of Linux, it is one of the most popular courses in Belgium’, Nuyens estimates. High Tech Institute has been offering the training in the Netherlands for a number of years on an exclusive basis.

‘In the late nineties there was a lot of buzz around Linux for servers. The operating system is still popular for that, but to keep track with the growth of Linux servers, you need far fewer extra system administrators than in the embedded world, where the number of Linux applications explodes, and they all need developers’ explains Nuyens as its success.

The Linux pioneer already worked on a project in 1996, to run a complete Linux-based router from a 1.4 MB floppy disk. ‘This was done in order to use old PCs with a number of network cards as a server or router. It was a big challenge in which the Linux kernel compilation played a very important part. The tricks we had to pull out of our sleeves to make this work were a lot like the first steps of embedded Linux: a small system where you can add many applications.’ The project lives on in current router projects such as OpenWRT and DD-WRT.

Much later, the embedded build systems Buildroot and Openembedded/Yocto became available. ‘We also included that in our training. We always adjust the material to recent developments. We did about a hundred sessions, whilst we are on version 65 of the course.’

Beaglebone Black

In his Embedded Linux training, participants start working with a Beaglebone Black platform. This is a print with a Sitara SOC from Texas Instruments. This American chip manufacturer founded the non-profit organisation Beaglebone Foundation to provide Linux support for these platforms. ‘It is primarily a showcase for the Sitara platform,’ says Nuyens. ‘But it also gives developers a handy step forwards. Everyone can play around with the technology for free. ‘The entire Beaglebone design, the complete PCB layout with all its variants, can be completely reused by customers. By making minor changes to the copied reference design, you can speed up the roll-out of new products.’

If desired, Nuyens also has other variants of the course available. It is also possible to run the training on Freescale’s i.MX 6 platform (nowadays NXP). ‘This is also a popular platform in the Linux world. i.MX has single, double and quad core variants. The latter are more powerful for multimedia applications.’ Other variants on which the embedded Linux training can take place are the ZedBoards from Avnet and Atmel’s AVR32 platform. Training on these boards usually happens on specific request and often in-house at customers.

This article was published earlier in the magazine Bits&Chips: read it here.

This article is written by René Raaijmakers, tech editor of Bits&Chips.