Category: Interviews

Over the years, a long list of programming languages has been put forward to supplant C++. D, Rust, Apple’s Swift, recent Google addition Carbon and lesser-known alternatives like Nim and Vale, to name a few – they all have their merits and their specific application areas. Nonetheless, C++ is still very much alive and kicking, contends computer programming enthusiast Kris van Rens.

“There’s this widely held view that you shouldn’t use C++ because it’s outdated,” says Van Rens. “But it’s actually this view that’s outdated. It’s based on old-style C++. Ever since modern C++ was born in 2011, the language has kept moving with the times. With the right provisions, it’s no less relevant than up-and-coming alternatives like Rust.”

In the new 4-day training course “C++ fundamentals,” organized by High Tech Institute in the last two weeks of March, Van Rens introduces participants to the language basics and essential best practices. “I aim to impart a positive vibe about C++. I want participants to leave feeling that they can really do something with it and knowing how to put it to good use.”

Bread and butter

Van Rens has been captivated by the wonderful world of programming ever since he first laid his hands on his dad’s ZX Spectrum home computer. “It was a machine from 1983, the year I was born. When I was 7 or 8, I started tinkering with it, using the Basic programming language. In high school, in an extracurricular activity, a fellow student taught me X86 real-time assembly, followed by C and then C++. In the past few years, I’ve been delving into Rust as well.”

After a bachelor’s in mechatronics at Niederrhein University of Applied Sciences in Krefeld, Germany, Van Rens did a master’s in electrical engineering at Eindhoven University of Technology (TUE), specializing in video coding and architectures under the supervision of professor Peter de With. “The university is where I became a software engineer and had my first taste of teaching. In parallel to my graduation project, which was about converting MPEG-2 into H.264 video streams, I created an image and video coding tutorial – for my own understanding but also just for the fun of it and to convey that fun to others. Spreading my enthusiasm has always been an important driver for me.”

In 2009, Van Rens started his professional career at his current employer, the smart surveillance specialist Vinotion. At the time, this TUE spinoff was still a startup, working from an office space belonging to De With’s research group. “From coding image analysis algorithms in C++, my focus slowly shifted to the development platform as a whole, including the language itself, the programming interfaces and the tooling. That became my bread and butter: enabling the creation of robust, high-performance, high-quality code using solid software architecture.”

Van Rens’ career in training got a leg up when he was asked to speak at one of the informal 040coders meetings for computer programmers in the Eindhoven region. “The meeting was hosted by Philips Image Guided Therapy and I did a skit about introducing kids to C++. Afterward, IGT invited me to give a serious presentation to their engineers. So I did a tryout on an in-depth C++ topic. They liked it so much that it’s grown into a quarterly event – so far all online, due to Covid, with me presenting from my attic to crowds as big as 150 people.”

Encounters with legacy

The new C++ classroom training at High Tech Institute is targeted at much smaller groups of max a dozen software engineers with basic programming skills – any language will do. It’s also much more hands-on, with practical exercises drawn from Van Rens’ 10+ years of industrial experience. “These exercises aren’t theoretical and made-up like I’ve seen in so many other courses. They’re real industrial cases, inspired by the problems I encounter in my daily work.”

A key concept addressed by Van Rens is the craft of systems programming. “When you’re writing embedded software for a high-tech system, you’re much closer to the hardware than when you’re creating a web application,” he points out. “In Javascript, for example, you generally don’t have to concern yourself with things like memory management; the interpreter takes care of that for you. In an embedded system, you do have to worry about the often limited resources and how to use them wisely. Systems programming is all about being aware of the intricacies on all levels and having the flexibility to act accordingly. The training provides the handles for that. This knowledge applies to any systems programming language.”

The omnipresence of legacy code in the high-tech industry is another reason why C++ and his training are so relevant, notes Van Rens. “A lot of that legacy is written in some older version of C++. Sooner or later, you’ll come across this code. Rewriting it or programming against it in Rust or another language is almost never a viable option; you’ll have to deal with it in C++, and my training will help you do that.”

To be prepared for legacy code, participants obviously need to know a thing or two about old-style C++, but the emphasis is on the safe, modern aspects. “After the first standardization in 1998, the language didn’t change much for a long time. It wasn’t until 2011 that C++ underwent a true metamorphosis with the introduction of modern concepts like smart pointers for safer memory usage. Since then, the language is regularly updated, and so are the best practices,” explains Van Rens. “My primary focus is on the state of the art. Later on in the training, I also equip the participants for their inevitable encounters with old-style C++ by going into the evolution of the language and providing exercises in which pieces of legacy code have to be rewritten using modern constructs.”

Supercharged learning

The fundamentals taught by Van Rens in the upcoming training are more than enough for participants to get off to a flying start, but they’re only a fraction of what there is to tell about C++. “It’s a huge language. I use the book “Beginning C++20” by Ivor Horton and Peter Van Weert as a reference during the course. It’s comprehensive, almost a thousand pages long, but even that’s not nearly enough to cover everything, not by a long shot. In four days, I aim to lay a solid foundation, showing participants the ropes and where to go if they want to dive deeper.”

Books and online tutorials only get you so far. Nothing beats learning by doing, maintains Van Rens, pointing to the added value of classroom teaching. “Working with C++ since 1998, I’ve built up almost 25 years of experience that I’m amply sharing in class. I’m not just explaining the language; I know where to put the right emphasis, supporting my story with relevant best practices, examples and exercises from industry. It’s supercharged learning.”

This article is written by Nieke Roos, tech editor of Bits&Chips.

In the Netherlands we like to pat ourselves on the back with how good we are in mechatronics and precision technology. Are we really world class or is it Dutch arrogance?

“I don’t think we need to be too modest about that. In any case, there is little arrogance about it because there are enough points with which you can illustrate that. Not only in terms of knowledge, but also in terms of industrial application, we have built up a major lead over the rest of the world. ASML’s machines are a wonderful demonstration of this, but Thermo Fisher’s transmission electron microscopes are also technical marvels that are hardly unparalleled in the world. And it all comes from the same network, the same community of people who have taken technology to the next level.”

How did we achieve that level?

“The basis of this lies with Philips and the Natlab. The optics knowledge that has been built up there forms an important pillar. The machine building and mechanics capabilities also play a major role, as does all the know-how surrounding the construction principles for which Wim van der Hoek laid the groundwork. At its core, it revolves around the Natlab, where people could conduct scientific research at the highest level and link it to implementations in a practical application. The latter in particular has been decisive, plus the fact that that knowledge has been shared with others and that we have built an ecosystem in this way.”

“That willingness, or even the obligation, to share knowledge is crucial. A wonderful example are the famous Thursday morning lectures at the Natlab. There, researchers explained to the rest of the lab what they were doing, and what their plans and ambitions were. And it wasn’t just about what great successes they had achieved, but also what they wanted to do in the future. Employees were obliged to attend, and this created cross-fertilization in a collaborative environment. Colleagues who had virtually nothing to do with a field, nevertheless, asked questions. This curiosity to learn about each other’s profession has led to us not only building up the capacities, but also sharing that knowledge with a larger group, and learning to appreciate and respect each other’s fields.”

“Another example is the BM Landjuweel, where the 150 most prominent people within Philips Bedrijfsmechanisatie met every year to tell each other what they had learned and where things had gone wrong. It was an honor to be invited.”

“When BM got into a frenzy in the mid-eighties, those Landjuwelen stopped. They were followed by annual Philips conferences that alternated between control and mechanical topics. With the same goal: to make contacts and exchange technical information. That role has since been taken over by, among others, DSPE and the training programs of Mechatronics Academy and High Tech Institute.”

Prof. Jan van Eijk.

Is the region sufficiently aware of the importance for knowledge sharing?

“Especially in economically difficult times, it is hard to convince people that you might have to organize such meetings maybe even twice a year, because it is essential to maintain and nurture that network. It is one of the core values that has been an assignment for all executives within Philips since the era of famed director Hendrik Casimir. Philips is no longer such a central player, but the philosophy is quite deeply embedded in our community. The trick is to guarantee continuity in the rat race to earn money. That requires some effort. I think it is sufficiently embedded, but I have often been accused of being too naive.”

In recent years, ASML has taken over the dominance of Philips. How do those companies compare, the Philips of then versus the ASML of today?

“Unlike Philips, ASML is a mono company, focused on one application field. That’s a big difference. Within the old Philips, questions arose from all kinds of domains that were often based on the same basic problems. As a result, a specialized knowledge center could come up with excellent solutions for both electron microscopes and placement machines for discrete components.”

“When working at Philips, I have done pre-development work for ASML. Intimately connected, yet independent. That worked very well. We got a bag of money and could do whatever we wanted. We had a decisive organization that did not have to worry about the day-to-day problems within ASML. If there was a fire there, the siren went off and all ASML staff had to show up. But there was no siren at Philips; we could quietly work on their next problem. Planar motors are a good example of this. At first, ASML didn’t see any point in that, but we just started working on it anyway. When they saw what we had developed a year later, it was immediately snatched from our hands because those motors had to get into all kinds of machines quickly.”

“The current ASML is huge. I’ve said before that they have to be careful that they don’t become another Big Blue. That it, like IBM, will neglect some domains. ASML shouldn’t get arrogant because it’s the best at something. In my view, the organization is rapidly closing down and bureaucratizing. If they’re not careful, it will soon clog up with too many people sitting there just to safeguard their own jobs. If ASML falls into that trap, it will be very difficult to keep up the technical drive.”

“As an outsider, you have absolutely no chance if you want to make an improvement proposal. Internally there are so many experts in all kinds of fields that an entire army will jump up to explain why your idea is not possible. For an innovator like me, it is not a nice organization to work for; I don’t get any energy from it. On the other hand, ASML’s successes are undeniable.”

AI no panacea – The Netherlands is at the forefront of mechatronics and precision technology, but we are too small to do everything. Which markets and sectors should the Netherlands focus on?

“There are very interesting possibilities in machines for photonics. A new field that is very related to the production machine problems that we’ve already solved in existing systems. With many of the same companies we can make a positive contribution and claim part of that industry for the Netherlands. However, we shouldn’t try to become the production center. Don’t aim to be Samsung or TSMC in photonics. The focus should be on developing equipment for that sector.”

“Another area in which we can benefit from the technology base that has been built up, is robotics. The football-playing robots from the Eindhoven University of Technology are a nice example of that, but we really have a solid base to score high in robotics. Think of medical and surgical robots, because they also contain that high-tech precision component.”

And automotive, could that be interesting? There are many companies around Helmond, among others, that operate in that market.

“I’m not sure whether the Netherlands is big enough to play a leading role in automotive. Superpowers such as Bosch and the car manufacturers themselves are very dominant. We can certainly make important contributions with smart innovations, but we are not in a position to have a major industrial part. We may have missed the boat there. But even if we had done everything we could twenty years ago, I wonder whether we would have been able to gather enough manpower in the region. We can’t carry another ASML-sized company in the Netherlands.”

And artificial intelligence?

“That is mainly a buzzword for me, just like mechatronics was 35 years ago. You can attract money with it, but above all we have to keep our feet on the ground and not expect that all problems will be solved if we use AI. I don’t believe in that. AI is an interesting tool from which you can certainly derive value, as well as from CAD and finite element methods. I think AI can provide valuable insights that might help you better understand what is happening. This will allow you to improve devices effectively. If you only do data-based optimizations, you will only make limited profit. But if you understand the core of the problem, you can come up with new concepts. In any case, AI is certainly not a panacea.”

From a distance – The award of the 2021 ASPE Lifetime Achievement Award last November marks the end of your active career. What else do you want to do?

“Mechatronics Academy regularly gives fun training courses in Asia or America. If a nice location comes along, I would be happy to contribute. Companies can always knock on my door if they are looking for innovative solutions. Then I would like to join in to think along in the preliminary phase. After half a year I’m worthless because then I’m just going to say that it could have been better. Also when engineers are at a loss because their machine isn’t working properly and they have no idea why, I like to think along. Maybe I can help out. Not because I know better, but because I ask the right questions from a distance that help gain insight.”

“Other than that, not much has really changed. Just like the past ten years, I go on holiday very regularly. With the camper through Europe or to the US. I also play golf and bridge. I can keep doing that for a long long time.”

Jan van Eijk’s most important patents

Jan van Eijk has about fifty patents to his name. What are the two most important?

“I came up with one of my first patents together with Martin van den Brink. If you asked him this question, he would probably mention this patent as well. It is about the alignment of the mask and the wafer in a lithography machine. In ASML’s first machines, this was done with an optical system that compared one point on the mask against two points on the wafer. That means you can never control the rotation nor correct the magnification of the lens. Our invention was to add a second feature. Although that second optical measuring system made it twice as expensive, the big advantage was that you could measure the position and the angle perfectly, without being dependent on the stability of the machine frame. You could also correct the magnification of the lens based on the distance between the two mask features on the wafer. That was a very valuable step for ASML because it made sure that the first generation were guarded as a stable, well-producing machine, with a yield that was a factor of 2 to 3 higher.”

“Another important patent dates back to 1990 and deals with frame motion compensation. If you let a wafer stage make a step, a reaction force is generated on the machine frame. That frame will start vibrating which will lead to image errors. You can solve this with control technology by adding extra sensors and using smart feedforward tricks. But the mechanics themselves are not infinitely rigid. In the second generation of lithography machines, the structure had become so large and heavy that ASML ran the risk of low-frequency vibrations that were detrimental to the quality. You can of course wait for the vibrations to damp out, but that’s killing the productivity. We then came up with the idea of installing three DC motors between the machine frame and the floor. When the stage moves, those motors generate a force that compensates for the movement, causing the frame to stand still. It seems simple, but it has enabled the second generation of ASML machines to reach high positioning accuracy and throughput. That has been of decisive importance because from that generation onwards ASML started to make real money and they were on fire.”

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

Is model-based systems engineering a hype? “MBSE isn’t just the latest great idea,” replies Jon Holt, professor of systems engineering at Cranfield University. Holt states that there’s a genuine need to improve the way the tech industry works to remain competitive. “To produce products and services that we can trust. So that the general public can have trust in us engineers. MBSE is a very good way to achieve that.”

Holt will start as a trainer for the MBSE training at High Tech Institute in the Eindhoven region. Ger Schoeber, responsible for the systems training portfolio at High Tech Institute, is happy to have him on board. “Jon was identified as one of the 25 most influential system engineers in the last 25 years by Incose, the International Council on systems engineering,” says Schoeber. “He’s internationally recognized as an expert in the field of model-based systems engineering and has authored 17 books on the subject.”

According to Holt, “MBSE isn’t really that new or radical. It’s just an evolution of classic systems engineering, just like our systems have evolved. They’re all going to be connected in some way. Almost every system is now part of a wider system of systems, which ten to twenty years ago wasn’t the case. As this complexity increases, we also need to improve the way we do things in systems engineering. To me, MBSE is a natural evolution of traditional systems engineering.”

Trainer Jon Holt.

UML and SysML

In 1999, Holt started teaching how to use models in engineering for The Institution of Engineering and Technology. In his courses, he used UML (Unified Modellng Language) that was aimed at the software industry – SysML (System Modeling Language) didn’t exist yet. The main aim of the training was to try and convince people that modeling was a good idea. “Only about fifteen years ago, modeling became more widely accepted in engineering. The question changed from why should we model to how should we model? What are the techniques we need? How do we model effectively and efficiently?”

About five years ago, Holt experienced another transition. “Modeling became widely accepted and used in industry. The main question now is: how do we successfully implement model-based systems engineering in our business? How do we deploy it? Initially, many people just saw it as the latest buzzwords, but now, as our systems become more complex, there’s a genuine need to do this.”

How can companies benefit from MBSE?

“It really depends on what it is you want to achieve. Some people want to shorten their development timelines. Some want to improve the product quality or their communication. Some people want to improve their relationships with customers, suppliers and the tendering process. For some organizations, it comes down to things like compliance. In markets like medical devices, the main concern is compliance with regulations and standards. Different organizations have a different emphasis. It really depends on your business goals.”

“You have to bear in mind that you’re talking about business change. For that, you need to understand what your key stakeholder expectations are and what success looks like. What are the problems that you have at the moment? What are the benefits that you’re looking to achieve? You need to know if MBSE makes a difference for you. Would you have been equally successful without it?”

If MBSE means business change, where do you start if you want to implement it?

“It all starts with having a very clear picture of what you’re setting out to achieve. What’s your current position in systems engineering and what’s your goal? Where do you want to be? It’s like any business change. In the first place, you have to know why you want to do it.”

“The emphasis of your company is a good starting point for the transition you want to achieve. This will be different for producers of medical devices than for semiconductor equipment manufacturers.”

What’s the biggest pitfall?

“One of the biggest pitfalls is that people just go out and start to buy technologies and solutions. They’re essentially buying solutions to a problem that they don’t understand. That’s never going to be a particularly good outcome.”

How does the implementation of MBSE typically evolve?

“You need to start small and grow it out into the business. It’s about evolution. You start on a small part of a project or maybe a pilot project to demonstrate the benefits of the improvements. And then you can grow that out into the rest of the business.”

“Your speed obviously does depend on the level of investment, but also very important are commitments from the people in the organization. As a crude measure, the more senior buy-in you can get, the smoother it goes. This will often mean that you get key stakeholders involved and show them what the benefits are.”

Joining the course isn’t enough. Your employer and team also h ave to be committed?

“Absolutely. You need to have a strategy in place and that strategy needs to have a timeline. You need to be aware of the time, effort and money that you need to invest. Depending on your original goals, you can realize the benefits very quickly. Sometimes it might take a year, but in many cases, you can win back any investment you make in the first project or the first implementation.”

“You have to be realistic. This isn’t an overnight activity. It’s an evolution from where you are now to where you want to be. Anticipating your expected goals and also how you’re going to demonstrate that you’ve met those goals. You need to know what success looks like, so you need to know how to measure that. It’s about the road to get there.”

Five stages

Holt identifies five stages on the road to full model-based systems engineering. “We have a scale of five maturity levels. It’s a path from working with documents, improving the way people work with the help of models, to full model-based systems engineering. Depending on the organization and the investment, it takes four to six months to get halfway to level three. That’s when you’re actually applying models properly. That’s also when you start to see immediate and measurable improvements.”

It might take eighteen months to two years to get to full automation with tooling and advanced applications, Holt reckons. “But at that stage, you’ll be able to see patterns roll out across the business and so on. It’s an evolution. You can consider each stage as a checkpoint to see if you’ve succeeded.”

The starting point for a transition to MBSE is understanding what you want to achieve. “For that, organizations have to look at the big picture and prioritize the effort they want to put in to get the optimum benefits,” says Holt. To get there, he guides people through five main aspects of MBSE in his course. “It allows them to focus on the aspects that are of most interest to them. They might have quite a lot of experience in some of the areas but typically not in all of them.”

The first area is the system. “At the end of the day, the goal of model-based systems engineering isn’t to produce a model, it’s to realize a system successfully. The way to do that is by collecting all of the relevant, all of the necessary information into the model. The system and the model are our day job if you like. That’s what we’re working on.”

Alongside that, the information needs to be visualized. “We need this to be able to communicate with different stakeholders. So this is where things like notations come in – SysML, UML, mathematical notations, whatever.”

Tooling has to be considered as well. That’s the third aspect. “Obviously, tools are needed to implement MBSE.”

The fourth area is the approach. This is where people usually lack experience. “Historically, when we talk about defining an approach for systems engineering, it’s been about defining processes. This is still absolutely crucial. But we have to separate the information that we produce and consume in our processes from the steps that we must take to execute the process. This is where the framework comes in, as the framework gives us the blueprint for the model and the model is our single source of truth for the information. So when we talk about the approach, it’s a combination of the processes we need to execute and the information we produce and consume – this is what we refer to as the framework.”

The fifth and final area is compliance. “What standards do you need to comply with? What legislation? What are your certification requirements? For aerospace, automotive and rail, certification is crucial. If we can’t certify our systems as being safe, secure and reliable, we can’t run them.”

All these five areas combined will result in model-based systems engineering. They’ll give organizations the power to maximize their techniques and practices. The starting point will differ from organization to organization. Some might be strong in tools or compliance, but not so strong in the approach. “We look at these five areas from their current position and their goals. That gives us the main input for understanding where you are on the evolutionary MBSE scale and what would be the best strategy to implement MBSE.”

Not every organization has to reach the full model-based maturity level. “Going fully model-based isn’t for everybody. But that doesn’t mean there aren’t benefits to reaching the ‘model-enhanced’ or ‘model-centric’ stage. It’s about understanding what your benefits are. What do you actually need and where should you possibly spend our money on? It’s a mistake to invest too quickly in frameworks, standards, tools and notations. You should know why in the first place. Unfortunately, the classic situation still exists where people start spending hundreds of thousands of euros on tools and solutions for problems they don’t understand. Companies buy tools, give them to the engineers and assume that everything will work from that point on. That’s not going to lead to optimal benefits. You first have to understand your problems. It’s a transition. It’s traveling down that road and having the checkpoints along the way.”

Training setting with Jon’s flipchart notes on the wall. 

If commitment from higher management is so important, would you say the course also benefits higher management?

“Absolutely. We see all sorts of different people getting involved with the training. Obviously, system engineers and more traditional disciplines like electrical engineers, mechanical engineers, software and so on. But also a lot of managers, even at the very senior levels, and people who don’t consider themselves as engineers like scientists, mathematicians and psychologists. We also have one-day courses aimed more at management or senior people. We intend to also schedule them with High Tech Institute in the future.”

“Not every aspect of MBSE is going to be beneficial to everyone involved. By knowing what you understand, you’re able to focus. If consistency of information is a big problem, you probably need to look at your framework. If people are more mature in their way of working, sometimes it comes down to improving the way they’re using their tools or their notations.”

Do participants need to have a technical background?

“It helps, but we don’t assume any prior knowledge. We start with the absolute basics, give real-life examples and then look at the problems we have. Then we move on to examples.”

Jon Holt during one of his MBSE trainings.

What do participants take home?

“You can’t expect to go on a three-day training course and be an expert in the field. But you will have a very strong awareness of what it’s all about, what’s in it for you and where you can go next. If you want to pursue MBSE, you’ll know what the next steps are.”

“We also show different applications, how you can get different benefits and different value from applying different aspects of the modeling. Because it’s not just about products or systems. You can also use MBSE to improve your processes, your projects, your lifecycles and all the different aspects of it.”

“At the end of the course, people will be in a position to say: ‘Actually, I think I can benefit from MBSE in these areas.’ It will give them a direction on where to go next. In many cases, they want to improve their business and therefore want to improve their products or services, for example, which they then go on to develop.”

“People get a very clear understanding of MBSE from the training, but they will also explore how they can apply it in different situations. From the basics of modeling to things like interfaces, requirements modeling and understanding business change.”

“Participants aren’t going home as world experts, but they will have an understanding of MBSE and see what the benefits are for them. They’ll know where to go next.”

You can sort out a lot about MBSE yourself by reading books and search the internet. But joining Jon Holt’s three-day course will save you months of research and give you a head start. He has spent thirty years of his career putting MBSE in practice. One of the big advantages of the training course is being face to face with him. You can ask direct questions about MBSE in your industry. You’ll get all the answers. His training is intended to be as interactive as possible. He doesn’t just do a lecture in front of the class, he’s delivering an interactive experience and gets everybody involved – a relatively quick way to learn the basics.

Holt brings up some other benefits: “What’s interesting is that you get to see other people from other industries. You get the appreciation that you’re not alone. These other people have a similar problem. Industries might differ, but the problems are similar. Sharing different experiences can be very, very powerful. More than once, you’ll realize: oh, I’m doing nothing wrong; other people are in the same situation.”

“In every course, I get lots of questions I’ve heard before, but there’s always a few I’ve never heard in all my thirty years of MBSE. For me, that’s part of the joy of delivering the courses. It challenges me as well, and it makes sure that I stay on top of my game. That’s exciting, and of course, I shouldn’t be standing at the front if I can’t answer unexpected questions.”

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

With his black outfit, Jon Holt is more likely to be recognized as a magician than a system engineer. Actually, he’s both.

Let’s start with the magic. This is the stuff he uses to inspire. As a professional magician, he performs at music festivals and various science and technology events, using magic, mind reading and sometimes escapology to explain engineering principles. “We do things that are based on mathematics, science and memory techniques. I try, for instance, to explain to people how important visualization is, as a design concept.” He smiles: “There’s a selfish aspect. I enjoy it as well. Give me an opportunity to show off and I’ll take it.”

Jon Holt: “Give me an opportunity to show off and I’ll take it.”

Holt has also written a rhyming storybook based on systems engineering, aimed at children from ages seven to eleven. As the technical director of the International Council on Systems Engineering (Incose) in the UK, he works to raise that awareness together with professional bodies aimed at families with children. “It’s important that we don’t just think about where we are but also about the next generation of all engineers.”

Holt encounters a lot of misconceptions about engineering. “The term is very badly understood. Many people still think I fix things that are broken. Well, not quite. Engineering is seen as boring or not interesting. For me, that couldn’t be further from the truth. Look at the incredible systems we work on. Children can’t be separated from their mobile phones now. I’d like to get people to appreciate the engineering in that phone.”

Incose has identified Holt as one of the 25 most-influential systems engineers in the last 25 years. He’s internationally recognized as an expert in the field of model-based systems engineering (MBSE) and has authored 17 books on the subject. He’s also a professor of systems engineering at Cranfield University.

In Holt’s career, MBSE has played a central role. At last year’s Bits&Chips Sysarch conference in Eindhoven, he stated that all systems engineering would be model based in 2025. “If you go back 10 years plus, I’d spend all my time arguing with people if modeling is a good idea. At conferences, people would throw things at me because they didn’t want to model,” he recollects. But this has changed. “Now, the question is no longer: should we model? But rather: how do we model effectively and efficiently?”

Holt sees the shift in his work with large multinational organizations that have twenty-year-long product life cycles. “They want to shorten those cycles. Quality is obviously a concern, but their main driver for employing MBSE is to improve the efficiency of their processes. The human side of things comes into play as well. Companies want to make sure their staff has the appropriate skills and apply MBSE to that.”

Four changes in complexity

To explain complexity, Jon Holt compares the old Triumph Herald car he owned in the seventies with his most recent car. “The basic need is still getting from A to B, the human-machine interface is still a steering wheel, a gear shift and three pedals. But the complexity of these systems has changed over the last few decades.” He describes the change in four specific ways.
“The first way it has changed has to do with the system elements. They were 95 percent mechanical. Probably slightly under 5 percent was electric. In terms of the interfaces, the Triumph had mechanical interfaces and electric to mechanical. Very few were electric interfaces. Now we’ve also got electrics and software. With these elements come networking and communication protocols. We’ve got far more complexity.”
Next are the constraints. “The only safety measures in the old car were the seat belts in the front, and you didn’t even have to wear them – that was optional. There were no seat belts in the back. In terms of crash protection, the car was made of very thick metal. You just had to make sure that it was thicker than whatever you were going to crash into. That was safety back in the 60s and 70s. Today, you wouldn’t get in a car without wearing seatbelts. A modern vehicle has airbags, antilock brakes, and it will stop you from crashing into something else and from veering into another lane. The complexity has gone up. Not only because of the constraints, but because of the source of all those constraints like standards and legislation. All those best-practice models didn’t exist in the 70s.”
Third, is connectivity. “In my Triumph, the main type of connectivity to the outside world was me. Now the car is actually part of a wider system of systems. It connects to the cloud, to road signs, to the UK and European road networks, and talks with other cars. That comes with a whole new level of interfaces. I’ve got an app to tell me where my electric scooter is at all times.”
The fourth wave is the shift in complexity. “In my old car, the complexity was in the internal combustion engine. The complexity has shifted to the software. The mechanical complexity of a motor in a modern electric vehicle is very, very low, whereas the software complexity is very, very high. The software does all the control and it takes care of all the connectivity. Over the last few decades, the complexity has increased beyond recognition.”

Connecting engineers

Apart from that, working model based might also be the key to connect engineers. Here, we touch on the ambitions of Ger Schoeber, the chairman of Incose Netherlands, who we invited to sit down with us during the interview. Schoeber recently joined Lightyear as group lead systems engineering. He’s also responsible for systems and software training at High Tech Institute. In his past years as Incose chairman, he worked on bridging the gap between the engineering worlds of infrastructure and high tech.

Painting these two very different worlds in black and white, Schoeber says: “Engineers in public projects deal with contractors, subcontractors and contracts. Their focus is paperwork and processes, and the system comes second.” On the other hand, the high-tech industry is commercially driven. “There, the focus is time to market. Otherwise, they can’t compete and certainly won’t conquer the world. That’s why the approach is pragmatic and focused on the system, the product.”

Schoeber’s roots are in high-tech, but as Incose chairman, he observes that the Dutch chapter members typically work in infrastructure projects, building railways, roads and tunnel systems. “We have a big high-tech industry, but not many engineers know Incose.” The opportunity, according to Schoeber: “I’m sure that both worlds can learn a lot from each other.”

Single source of truth

MBSE is a common denominator, Schoeber and Holt agree. It can help high-tech to make even better products. The techniques that high-tech and civil engineers apply to develop systems and deliver them successfully must improve to cope with the added demands and complexity. The most common way is to apply model-based techniques. Holt puts it in very simple terms: “Traditionally, engineering relied very heavily on documents. For design, for understanding the requirements and so on. That worked very well for many decades. A perfectly good, solid approach. But as the complexity starts to increase, if all the knowledge, data and information associated with a system is split across multiple documents – and we’re talking thousands – just maintaining consistency is very, very complex.”

Ger Schoeber: “Most important is not the model, but to use common sense.’

In a model-based approach, all knowledge and information relevant to the system are kept in one place and kept consistent. “In that way, we have what’s often referred to as a single source of truth,” says Holt. “We can maintain that single source, and if done properly, that guarantees that the documents based on this single source of truth will be consistent. So rather than distributing everything throughout thousands of different documents, we’re bringing it all together in a single source of truth. For anything we want to know about the system, we interrogate the model. That’s where the information resides.”

Elaborating: “People say: a model can never be complete. Well, it doesn’t have to be. It has to be as complete as necessary to deliver our system. It can never contain all the information of the system. There’s got to be things missing, but that doesn’t mean it’s wrong. We focus on the relevant information to develop that system. It’s got to be useful and has to benefit what we do. If it doesn’t, then forget about it.”

Brontosaurus of complexity

To explain the impact of complexity on systems engineering, Jon Holt uses the brontosaurus theory problem. This theory is an analogy that states that the magnitude and complexity are directly proportional to the thickness of the animal. “At the beginning of a project, you look into the smiling face of the brontosaurus,” clarifies Holt. “The complexity is low, it’s thin at that point. You look at your requirements and think: yeah, that makes sense. You smile because it’s simple and the brontosaurus smiles back at you. You live in a very happy, if somewhat naive world.”
But then systems engineers come in with their cost, time and resource estimates. They start to apply their systems engineering principles. “They start modeling, identifying stakeholders, creating scenarios and while heading down the neck of the brontosaurus, the complexity goes up. When someone is showing you diagrams as big as a wall, you know you’ve arrived in the belly of the brontosaurus. Because although the diagram is very clever, nobody can understand it. And you’ve got people using all kinds of different methodologies and tools. Or even worse, using the same tool but slightly different versions that aren’t remotely compatible with one another.” Holt, from his experience: “All contractors leave at this point. Life is getting a bit too tricky for them. It looks like it’s the end of the world.”
But there’s a solution. “The problem is complex. It’s difficult to understand and almost impossible to communicate to all the different stakeholders. It’s very frustrating because as a systems engineer, you say: hang on, I’ve done this thing right, I’ve applied these principles, yet, I’m in the belly of the brontosaurus.” Then something interesting happens, says Holt. “Because if you continue to apply your techniques, the complexity is going down and down and down, to the tail of the brontosaurus – and this is our goal. And at the tail of the brontosaurus, you’ve got a concise, elegant solution.”

Holt’s message: when you look at any kind of real problem, as soon as you start to apply systems engineering and modeling, it gets more complex before it’s going to result in an optimal solution.

The model and its views

The basic function of a model in MBSE is to communicate. It has to enable the system engineer to discuss the system in development with all its stakeholders, the financial department, the customer, the boss, the engineering team or some standards organization that wants to see if the system applies to all safety regulations.

For all those different stakeholders, there are so-called “views” (of the model). They’re the basic units in a model. Each of them is a collection of information with all the information a specific stakeholder needs to know about the system in development. Holt: “First of all, it has to be a valid view. If you can’t identify one of your stakeholders who would be interested in looking at that, then don’t do it.” Second, the stakeholder should benefit from looking at this particular view. “If you can’t answer that, it’s not relevant. It’s not a view.”

“If you imagine the model as a big amorphous blob of information, each view is like opening a tiny window into that model,” Holt continues. “We’ve got to make sure we open up enough of these windows to give us an understanding of the model as a whole. Because of the many stakeholders, we have to make sure that all views are consistent. Otherwise, it’s not a model.” He uses SysML as a modeling language, but in fact, you can use any language. It’s about doing it properly, to end up with a consistent model.

Holt uses models as a basis for the contract, for instance. “When companies in different sectors, like aerospace, power or the nuclear industry, put out a tender, they put out their specifications for the bids coming. What they actually do is putting out a set of views, which they submit as the technical part of their tender.”

The advantages are clear: “The model is becoming part of the contract. If four people bid for the tenders, they’ll have completed bids for the same set of views. For the customer, it’s far simpler to compare them than text-based descriptions, for example. The other advantage is that the set of views – the submitted model – actually then becomes a contract. Contractors will have to deliver on clear information.”

The high-level set of views in the conceptual level later become almost like the acceptance criteria for whatever is delivered. “This can be applied to infrastructure, as well as to more high-tech and commercial industries.”

Schoeber points out that the system architect or systems engineer plays an important role as the translator of the views in SysML to stakeholders without a technical background.

Appetite

Automotive is a good example of an industry that has developed a big appetite for MBSE, says Holt. “It started five years ago. The complexity has changed as time has passed. Compare an old car from 30, 40 years ago to a modern car and look at the complexity of the system elements, connectivity or the safety constraints. We’re seeing that the complexity has changed beyond all recognition. The techniques that we could apply to what was perceived as a modern motor car twenty years ago just aren’t good enough now. They aren’t rigorous enough to apply to a modern vehicle that’s part of a wider system of systems. MBSE gives automotive a competitive edge. If they don’t apply it, their competitors will produce better and more reliable products.”

Jan van Eijk typically reacts soberly when Mechatronica&Machinebouw congratulates him with the Lifetime Achievement Award from the ASPE. “During the award ceremony, I pointed out that I see it as a token of recognition for the quality of mechatronics and precision technology in the Netherlands. I was sent to the US as a delegate about twenty years ago to develop relationships. This award is an appreciation from that professional group in the US that we have achieved considerable quality and effectiveness in that area in our region. I just had the pleasure of representing the Netherlands.”

Van Eijk is downgrading his own achievements a little bit. After all, it is by no means evident to convince the Americans of our qualities in mechatronics and precision technology. Van Eijk still remembers his first presentation at an ASPE conference in 2001. “On behalf of Philips, I had to ensure that we would play a role in that community.” Van Eijk bought a three-piece suit for the occasion. “In the American technical world that is very unusual, so everyone knew straight away that there was a weird guy walking around”, he laughs.

“Dare to climb out of your foxhole and explain yourself”, advises Jan van Eijk. “It will give you a valuable view on your own work.”

In his presentation, Van Eijk emphasized the differences between the Dutch and American cultures. “At that time, KLM was negotiating a possible merger with an American airline. They didn’t get anywhere because the styles and cultures clashed. The focus on quick money with the Americans against the long-term vision at KLM”, says Van Eijk, who then dropped a bomb in his audience. “I said, “I was sent here to cooperate with you, but I think it’s a mission impossible because Americans and Dutch can’t do that at all.” Van Eijk had made an unforgettable first impression.

He hastens to say that it is not all so black and white. “Of course there are executives and engineers in the US who prefer the long term over the fast buck. We sometimes have that image of Americans in the Netherlands, but in practice it turns out that it is not too bad.”

However, Van Eijk’s deliberately provocative comment does make sense. He based himself on research by the Dutch organizational psychologist Geert Hofstede, who mapped different cultures in the world along six dimensions. One of those axes revolves around long-term thinking. The most recent data from research agency Hofstede Insights shows that the Netherlands scores 67 out of 100 points in this area, and the US only 26.

Alpha males

An important reason why the Dutch excel in mechatronics – “no, that isn’t arrogance”, according to Van Eijk – is linked to one of Hofstede’s other dimensions: masculinity. “The way in which we work together in the Netherlands is fairly unique in the world”, explains Van Eijk. “Norway and Sweden are pretty close, but otherwise most countries score much higher on the masculinity axis.” Hofstede Insights gives the Netherlands a 14 on that axis, compared to a 62 for the US. “It’s about behavior within companies, about wanting to be the main guy. In American companies, it is appreciated when a boss is masculine, decisive and self-aware. It must be a macho, maybe even a bit of a bastard. In the Netherlands, soft elements such as empathy and a collaborative approach play much more important roles. In this, we are drastically different from many other countries. If someone here calls me “Mr. Professor” I think I’m being tricked, when even across the border, in Germany, that’s common practice.”

The typical polder approach, the consensus-oriented way of solving problems, is an excellent starting point for mechatronic design, says Van Eijk. “When you want to find the best solution, you have to work together at a high level because of the multidisciplinary character of the field. You need specialists in electronics, control engineering and mechanics. But when they all want to be the alpha male, it won’t work.”

It is a wise lesson that Van Eijk learned from another Dutch mechatronics guru: Rien Koster. In the mid-eighties, Koster started an ambitious project at Philips. His idea was to pull the super specialists from the various disciplines out of their cubicles and have them work together on a mechatronic system. Fast and Accurate 86 (FA86) the project was named. The plan seemed a guaranteed success, but in practice the top players from mechanics, electronics, control technology, software and metrology only quarreled. “They all wanted to be the top dog”, says Van Eijk.

After a year, Koster pulled the plug and started over, but this time with a much better awareness of the challenge that when you put all those alpha males together, cooperation does not come naturally. In the end, FA86 delivered the FAMM robot, a two-armed system with gigantic direct drive motors that you would normally find in a submarine. The FAMM (‘fast and accurate manipulator module’) was so strong and so fast that other robots were pale in comparison. Unfortunately, the industry was not waiting for such an expensive solution to a problem that they could also solve with twenty small robots.

Out of your foxhole

Despite the technological success, Koster took that experience to heart and made it one of his missions to change the culture. “The general trend in the Netherlands at the time was already moving towards collaboration, but top technical specialists were eager to show that they were the best. That is how they were trained”, says Van Eijk, who still wholeheartedly endorses Koster’s vocation.

A result of the mission work is the mechatronics training that started at Philips in 1989 – and the mechatronics trainings can still be followed at the High Tech Institute. “The main message of that course is that if you want to do proper mechatronics, you have to collaborate closely”, says Van Eijk, who has instilled that idea as a teacher on nearly two thousand students. “In the introduction I always say that I have no intention to turn a mechanical engineer into a control technician, or vice versa, but that I hope that afterwards they will respect each other’s field of expertise, be curious about the challenges of the other, and dare to climb out of their foxholes to explain themselves, and thereby do the valuable exercise of looking at their own work from a distance.”

This Dutch approach is also highly valued in the US. According to Van Eijk, knowledge sharing is one of the main contributions of the Dutch high-tech industry to its American colleagues. “Of course you have a lot of American super specialists in the field of mechanical design, but they are really interested to hear that different approach”, says Van Eijk. “In the US, it is not customary to take courses such as our mechatronics trainings. It’s starting to happen a little around ASML’s San Diego and Wilton locations now, but other tech companies won’t be sending their employees to a course on a regular base. Tutorials are therefore given prior to an ASPE conference, for example, in which many Dutch specialists have already transferred our approach in bits and pieces.”

Along this technical axis, Van Eijk – with the help of various other delegates such as Adrian Rankers, Theo Ruijl, Ton Peijnenburg, Dick Laro, Leon Jabben, Dannis Brouwer and Piet van Rens – has managed to build up good relations with the American mechatronics sector. Van Eijk: “They became increasingly curious about what is happening here in the Netherlands, visited us, attended conferences and now there are many partnerships with companies in the region.” Van Eijks Lifetime Achievement Award is a token of appreciation of that sector for the knowledge that American mechatronical engineers can get here.

You’ve finally done it. After years of working your way up from junior to senior engineer and architect, now you’re ready to take on a leadership role. This is your chance to show the company that you’ve got what it takes to assume the wheel and drive a team to success. With all the technical knowledge you’ve gained through your experience, you’ve pretty much seen it all and are quite advanced to less-experienced team members. This transition should be a breeze, right? According to Jaco Friedrich, a former architect and team lead turned trainer, establishing your technical credibility can be a big help, but it’s your leadership skills that will bring you to the next step in your career development.

“Spending years working my way up through the different levels of engineering and then to group leader, I’ve experienced first-hand the difficulties and the pitfalls of making the jump to a leadership role,” recalls Friedrich, a training expert at High Tech Institute. While the high-tech domain is filled with some of the brightest technical minds, for many, it’s the non-technical soft skills of interaction and communication that are lacking. “It took me years of training and education to really understand those difficulties, which is why I use my time to share what I’ve learned with the engineers of today. Sometimes, you can best teach that which you most needed to learn in your own personal development. I think that’s definitely the case for me.”

For the last 20 years, Friedrich has put his focus into teaching and helping engineers grow into leadership roles. He has trained thousands of engineers and architects, in the Netherlands and abroad, to learn the skills he wished he possessed early in his career. This includes his High Tech Institute’s two-day training “Leadership skills for architects and other technical leaders.”

Call your bluff

In his experience as a trainer in high tech, Friedrich notices that engineers have two main challenges, or dilemmas, to overcome when moving into leadership. The first is that leaders are expected to plan or take a specific direction earlier in the process, which means making big decisions with only a limited amount of information and clarity. “What I see is that engineers are very technical at heart. They might be 80 percent comfortable and have an idea of the way to go, but they hesitate because making big decisions without 100 percent certainty can feel daunting,” suggests Friedrich. “The problem is, someone else in the group might only understand 30 percent but be much more vocal, and this often leads to the project being steered in the wrong direction.”

The solution, Friedrich says, is not to be afraid to take a position, even if you’re not fully certain. Instead, start by conveying what you know and pointing out the potential risks. This invites everyone into a dialog and allows the group to assess risks and rewards.

“You never want to be fake in these situations. Your colleagues will call your bluff and certainly won’t buy into what you’re saying,” explains Friedrich. “In this scenario, it’s really about positioning yourself and being open from the start. Being a leader means you’ll find yourself no longer in the world of science but in the world of risk management. It’s a real mind shift that has to take place.”

Trainer Jaco Friedrich.

Headspace

The second dilemma, according to Friedrich, is finding the right balance between the engineer’s mentality of finding solutions on your own and finding ways to delegate responsibilities to keep a broad view of a project and its stakeholders. “This is one of the more difficult shifts for engineers going into leadership roles. They still want to work like they always have but can lose sight of all the moving parts and pieces,” illustrates Friedrich. “To really make the jump to become a leader, you have to find ways to create headspace. This means you must learn to delegate tasks to others and then help by coaching them through the process.”

Friedrich points out that while your technical knowledge is a great asset to help guide these situations, coaching relies more heavily on patience, communication and an entire set of soft skills. “To be effective as a leader, you’ll need to find a way to really develop skills in diplomacy and influence to gain buy-in from the various stakeholders,” he reveals. “Teams today are extremely diverse in terms of culture and discipline. To get all the stakeholders on board with the direction you’re steering means knowing how to appeal to them and motivate them from a position without power. Formal power can be effective, but it’s certainly not a motivating force.”

Resistance

Of course, no matter how sharp your influencing skills are, it’s not always possible to win everyone over. When you’re working with diverse groups of highly intelligent, highly technical people, you’ll most certainly run into different levels of resistance. Learning to deal with this resistance is crucial to being successful in a leadership role – and is one of the focal points of Friedrich’s training.

“Something that a lot of engineers struggle with is how to turn resistance into positive momentum. In our trainings, participants are always stumped to learn that as much as 50 percent of that resistance actually stems from themselves,” teases Friedrich. “It typically comes from one’s inability to present information, options and consequences in a clear and meaningful manner. We teach some simple tactics for new leaders to maneuver themselves into a position of strength and clarity from the start. That way, they can avoid wasting time getting the ball rolling. Of course, there’s still the other 50 percent, but to learn that you’ll have to come to the course.”