Challenging C++

Despite a host of up-and-coming alternatives, C++ is still a force to be reckoned with, certainly in the legacy-fraught high-tech industry. In a series of articles, High Tech Institute trainer Kris van Rens puts the language in a modern perspective. In our new 4-day training course, Kris van Rens introduces participants to the language basics and essential best practices.

“There are only two kinds of programming languages: the ones people complain about and the ones nobody uses.” This is a famous quote attributed to Bjarne Stroustrup, the creator of C++. Hidden in it are a couple of truths.

First and most obvious: no single programming language is perfect for solving every problem in every domain. Especially when a language is advertised as “general-purpose,” like C++, it can be applied nearly everywhere, but chances are there’s a mismatch between the tool used and the tool required. For example, it’s perfectly feasible to write a complete web application in C++, but is it the right tool for the job? Personally, I wouldn’t say so.

Then, as a language evolves and ages, it’s very important that there’s a clear process to deal with (breaking?) changes. A conservative and safe approach is to maintain backward compatibility from the first stable release onward. This is the approach C++ has followed and abided by for decades now – which, unfortunately, also blocks the adoption of some language improvements.

Another hidden truth from the opening quote: the user base is extremely important. You could design the most beautiful, safe, secure and pleasant programming language ever. But what good does that do if only a few people are using it?

Good contenders

A good model for programming language significance is a mechanical flywheel; the larger the user base, the bigger the flywheel and rotational velocity. The user base size is defined by the number of active developers, existing code bases, separate code base interdependencies and other factors like third-party integration support. For C++ at least, this flywheel still has enormous momentum. Yet, there are forces at work slowly eating away at this momentum. Other languages in the systems programming realm are winning over parts of the C++ user base.

Previously, I wrote about the announcement of the Carbon programming language, a C++ successor started by Google, but there are many more alternatives. Some of them, like Zig, Odin and Go, are more aimed at C rather than C++ – I’m not going to cover these here. Then, for the sake of being pragmatic, I’m going to skip languages that are too small or experimental, like Nim, Val, Vale, Cpp2 and Jakt. That leaves only a handful of ‘serious’ alternatives, including Rust, Swift, D and Circle.

''A good model for programming language significance is a mechanical flywheel.''

What makes a language a good contender for large-scale C++ user base adoption? We can start by looking at the properties where C++ generally falls short. For example, does the alternative have a ‘modern syntax’ throughout? Does it feature built-in guaranteed safety of some kind, like memory or math operation safety? Does it come with a tooling/packaging ecosystem? C++ interoperability is another very important aspect. A C-style foreign function interface (FFI) is nice, but it feels like a downgrade if we have to adapt our C++ interfaces to that.

Having one of these properties isn’t enough, though. A modern and clean syntax is very nice but isn’t going to cut it on its own. A great tooling ecosystem is fantastic but, again, not good enough on its own. In my opinion, if you want to have any chance of succeeding C++, you’re going to need at least the following three ingredients: a 10x improvement on some aspect of the language, guaranteed memory safety and good interoperability with existing C++ code.

Ticking the boxes

Looking at our serious alternatives, a language like D is missing the 10x improvement. This is why I think it has never really taken off, even though it’s already 20 years old. One-man project Circle is very impressive, especially for its language development experimentation capabilities. And above all, except for taking feature flags to enable language improvements, it’s completely compatible with C++. Unfortunately, Circle isn’t openly governed and lacks guaranteed memory safety. Swift comes with excellent tooling, but it’s too focused on the Apple platform and it has only partial/work-in-progress C++ interoperability.

Rust ticks most of the boxes. It even has quite a decent user base already. Although it also lacks true, mature C++ interoperability, it’s the most promising contender today. More on Rust in my next contribution.

The state of C++

Despite a host of up-and-coming alternatives, C++ is still a force to be reckoned with, certainly in the legacy-fraught high-tech industry. In a series of articles, High Tech Institute trainer Kris van Rens puts the language in a modern perspective. In our new 4-day training course, Kris van Rens introduces participants to the language basics and essential best practices.

Last July, the Carbon programming language was officially announced at the CppNorth C++ conference in Toronto, Canada. Carbon is presented as “an experimental successor to C++” and was started as an open-source project, by Google no less. Wait… Google is going to create a C++ successor? Until recently, the company was heavily involved in developing the C++ language and engineering the Clang C++ front-end for the LLVM compiler. With tens of thousands of engineers within Google working on billions of lines of code, choosing the path of a completely new language seems rather bold.

Why would a huge company such as Google venture into such a daring project? Well, it’s a symptom of the state and development of C++. For those who haven’t caught up with the language’s evolution in the past few years: there have been some major discussions. Of course, having discussions is the whole point of the C++ committee meetings, but one topic has been popping up again and again without settlement: whether or not it’s worth improving language design at the cost of backward compatibility.

Leaner governance

C++ has been around for about forty years now and is being used to create performance-critical software all over the world. After a period of relative quiet following the initial ISO standardization in 1998, the committee managed to steadily introduce great improvements every three years since 2011. As a result, the language has grown quite different from what those of us old enough used to work with in the nineties and noughties. The addition of features like concepts, ranges and modules in C++20 alone pack a powerful punch.

At the same time, though, the C++ language evolution process is known to be extremely challenging. The weight of carrying decades of technical debt while maintaining backward compatibility is substantial – too much for some, it seems. Trying to add a significant language feature may cost up to ten years of lobbying, discussions, reviews, testing, more reviews and meticulous wording. Of course, introducing considerable changes in a project with this many stakeholders is no mean feat, but ten years in today’s tech world is a literal lifetime. Another challenge is that the ISO committee is predominantly Western, with a heavy underrepresentation of big Asian C++ users like India or China. These downsides don’t look good, especially not in the light of rapidly-growing, modern, openly governed (and relatively young) languages like Rust or Swift.

Sigasi Extension for Visual Studio Code

Sigasi announces the release of thei VS Code Extension with rich support for SystemVerilog, Verilog, and VHDL. Our extension provides features and language support such as code navigation, project management, linting, code formatting, tooltips, outline, autocomplete, hover, and much more!

''Still, I think right now is a very important time for C++ to consider its position in the systems programming universe; it can’t ignore the signals any longer.''

Is the technical debt of the C++ language really of such gargantuan proportions that it’s next to impossible to add new high-impact features? One-man army Sean Baxter of the Circle C++ compiler has shown that it’s not. In the past months alone, he single-handedly demonstrated that it’s possible to add considerable features like a true sum type and language-level tuples. Granted, an implementation in a single compiler of a C++ dialect without a thoroughly reviewed proposal is far from an official C++ language feature, but at least it shows how much wiggle room and opportunity there is in the syntax and language as a whole – if we really set our minds to it. It also shows that the burden of technical debt alone isn’t the limiting factor in the language development.

The C++ language governance model isn’t likely going to change anytime soon, being so tied in with the ISO process and the committee stakeholders. Still, I think right now is a very important time for the language to consider its position in the systems programming universe; it can’t ignore the signals any longer. Perhaps a leaner governance structure will help, or allowing for breaking changes to shed technical debt in a future version – who knows. Unfortunately, such substantial changes to the process will most likely take years as well.

Wait and see

Will the drawbacks cause C++ to be eliminated anytime soon? No, definitely not. The sheer momentum of the existing code and user base is overwhelming. ‘Just’ switching to another language isn’t an option for everyone, not even for Google. For that to work out, true interoperability with C++ (not just C) is needed, which is where alternatives like Rust and Swift still fall short. Not for nothing is Google advertising C++ interoperability as a key feature of Carbon, allowing to step-by-step adopt the language from a large existing C++ code base.

At the moment, however, Carbon isn’t much more than a rough specification and announcement. We’ll have to wait and see if it can live up to the expectations. In the meantime, C++ will evolve as well, hopefully positively inspired by the possibilities of Circle and other languages in the field.

 

A flying start in modern C++

C++ training
Despite a host of up-and-coming alternatives, C++ is still a force to be reckoned with, certainly in the legacy-fraught high-tech industry. Drawing from almost 25 years of experience, computer programming enthusiast Kris van Rens introduces coding rookies to the language basics and essential best practices in his new C++ Fundamentals training at High Tech Institute.

 

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

 
C++ training Kris van Rens

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

''A lot of legacy is written in some older version of C++.''

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

 
C++ training by Kris van Rens

 

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

''Nothing beats learning by doing.''

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.

Jan van Eijk’s wise lessons and advice

Jan van Eijk - Mechatronics trainings
The 2021 ASPE Lifetime Achievement Award that Jan van Eijk received last year marks the symbolic end of the active career of one of the driving forces behind the Dutch mechatronics industry in recent decades. In part 2 of an extensive interview, Van Eijk looks back and gives some valuable advice for the Dutch high-tech industry. “It is crucial to maintain and feed the network.”

 

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

'The willingness, or even the obligation, to share knowledge in the network is crucial.'

 

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

'ASML shouldn’t get arrogant because it’s the best at something. In my opinion, the organization is bureaucratizing 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.”

 

Jan van Eijk - Mechatronics Academy

 

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.

MBSE isn’t an overnight activity, it’s an evolution

Model-based systems engineering by Jon Holt
Jon Holt, Incose fellow and professor of systems engineering at Cranfield University, is sharing his 30-year experience in model-based systems engineering in the MBSE training course that will be offered in collaboration with High Tech Institute. “It’s not about technology, it’s about business change in a technical environment.”

 

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 - MBSE Training
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 need to understand what your key stakeholder expectations are and what success looks like.'

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

 

MBSE training by Jon Holt

 

 

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

'The more senior buy-in you can get, the smoother it goes.'

“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 goal of MBSE isn’t to produce a model, it’s to realize the system successfully.'

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

Model-based systems engineering training in Eindhoven
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.

Chasing a single source of truth

Model-based systems engineering by Jon Holt
At last year’s Sysarch conference, model-based systems engineering expert Jon Holt sat down with High Tech Institute’s Ger Schoeber to discuss the MBSE training. “In five years, all systems engineering will be model based,” according to Holt, currently the technical director of Incose UK.

 

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 - Trainer model-based systems engineering
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 five years, all systems engineering will be model based.'

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

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

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

Where does one start with MBSE? Holt points out it’s important to answer the why question. “If you can’t answer that, don’t do the work. It depends on the context. You have to ask what it is you’re looking to improve? What is it you’re setting out to do in the first place? It might have all kinds of emphasis, something commercial or things like quality attributes, a better product that’s safer, more reliable, more maintainable. Or look at security. You can steal a car by using a mobile phone, it’s crazy. The requirement to prevent that didn’t exist five or ten years ago. Now it’s becoming a standard demand from customers. There are no 100 percent autonomous vehicles yet, but we have driver assist, communication with road signs and collision avoidance to stop us from drifting between lanes. These are standard features, not optional extras in a modern car.”

Holy grail?

Is there a danger that MBSE is considered too much as a holy grail? Schoeber: “What worries me a bit is if we look at MBSE and all the tooling that comes with it, that we trust the tools too much. You have to make sure not to lose your common sense.” Holt shares Schoeber’s concern: “To think critically and question things is one of the systems engineer’s skills. We have to keep on asking why. You can’t bypass that.”

It’s also about managing people’s expectations, finds Holt. “Like any solution, MBSE isn’t a silver bullet. It’s not going to cure all our ills in one single shot. You have to know what you’re hoping to achieve, and very importantly, how you’re going to measure what you’ve achieved. Part of the problem is that people oversell the tools.”

According to Holt, the level of maturity in MBSE varies enormously between different organizations and industries. “Certainly in the UK. Traditionally, model-based systems engineering was always the domain of military, aerospace and later, rail. But now, if you look at the current roadmaps of automotive, they’re having a good time.”

Different industries also deal with different time schedules. Consumer electronics developments are shorter than infrastructure projects. Longer developments aren’t more relaxed per se, Schoeber points out. “The European Space Agency in Noordwijk has been using SysML for over 10 years. At ESA, a lot of countries work together to get satellites produced. You only have one chance for a successful launch. But on the other hand, they sometimes have to make tough choices when running out of time after 10 years of development. Then they have to decide: take the risk to skip some testing and verification phases to meet the launch window, or accept a huge amount of cost that comes with a year of delay?”

In the high-tech industry, Schoeber sees a playing field with many heroes, the creative and proactive people who take the lead in developments. “Look at ASML. That’s a hero-based company. But with a market share of almost 90 percent and enormously complex systems, they feel the need to do some processing and modeling in a more formal way. Otherwise, they won’t survive the next ten years.”

Are models replacing the heroes? Holt: “I think there’s always a need for heroes, but you won’t need anywhere near as many if you have a good approach in place. Often the heroes are there because things haven’t been done properly and they need to fight fires all the time. A lot of those things could be avoided. Space is a really good example. Until you fire your rocket into the sky, you don’t know what’s going to happen. You can put mechanisms in place to minimize the risk, but you can’t mitigate everything. Yes, you do need heroes, but we shouldn’t be relying on heroes for everything.”

Schoeber: “Most important is to use common sense. Systems engineers have to be brave enough to stand up and take responsibility. Because that’s what really makes a hero.” Holt: “It’s not so much that they have to meet the letter of their contracts, but rather the underlying intent.”

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

“Requirements tooling suppliers aren’t up to date and it’s frustrating”

The profession of requirements engineering moves so fast that tool suppliers can barely keep up. “The software from major suppliers hardly takes into account the latest insights in our field,” says Cees Michielsen, trainer of System requirements engineering at High Tech Institute.

Customers becoming more central, systems becoming more complex and the design process becoming more and more intertwined. In a nutshell, these are the factors that drive change in requirements engineering. “Requirements engineering is out of its bubble,” says Cees Michielsen, trainer of system requirements engineering at High Tech Institute. “It’s now an integral part of systems engineering.”

“In the past, we only looked at the intrinsic value of a requirement. That’s also how the tooling was originally set up. In the meantime, we’re focusing more and more on what such a requirement does in the entirety of the product development. We zoom out more. Unfortunately, the software tools haven’t grown with us.”

In the coming months in Bits&Chips, Michielsen will highlight a handful of trends in his field. In this interview, we kick off with some of the topics he’s going to cover.

Major trends

Requirements engineering is about ensuring that customer wishes enter the product development process in a clear, unambiguous manner without losing information. That information can be very concrete: a 2,700-K, 350-lumen LED lamp. But it can also be vague: a comfortable truck. “We have to arrive at the right product,” notes Michielsen. “We have to implement what the customer wants in an efficient but correct way.”

Roughly speaking, Michielsen sees a handful of major trends in requirements engineering. For example, getting the requirements for a product complete is a perennial challenge for engineers. “It’s a recurring question from participants in my training courses,” observes Michielsen. There’s also a desire to increase the quality of requirements. Although not always exciting, this is a challenge for engineers because language and wording play a key role in drawing up good requirements and product specifications.

“We have to implement what the customer wants in an efficient but correct way.”

The increasing need for traceability could perhaps be called a truly new trend. “That term refers to being able to track all events and decisions in the requirements engineering, design and decision-making process, from stakeholders to product implementation,” Michielsen explains. “Conversely, it’s important, especially in larger projects, that for any requirement at any decomposition level, you know how to find your way back to the stakeholder’s needs. Why replace a side mirror on a truck with an exterior camera and a display in the cabin? You want to know why such a requirement exists in the first place and why it has the value it does. What should the features of that camera be, how large and what resolution is the display? What decision-making led to those specific values for that requirement?”

“A good requirements engineering process ensures that the stakeholder needs get to the implementation through the various development iterations without losing any information, including the intent of the customer requirement. Also, no requirements should be added for which there’s no stakeholder.”

Why is it so important to record not only the outcome of a decision but also the decision-making process?

“You want to be able to make changes to your product quickly and efficiently. To do that, you also need to know the reasoning by which you arrived at a solution. If you don’t record the decision-making process, you have to redo the entire reasoning process whenever changes are made. You have to go through the whole process again and start thinking again at a high level about what the proposed change means.”

“When you do record the decision-making, you save an awful lot of time. Especially in organizations that work with many product variants. When you know that an adjustment only has to do with the distinction between variant 1 and variant 2, you’re done much faster. You can work much more efficiently.”

That’s important when you’re making a hundred different shavers.

“Yes. For numbers like that, when you bring good traceability into your requirements engineering process, your administrative overhead is almost gone.”

20220204 Cees Michielsen RRA_1234

Trainer Cees Michielsen

To Michielsen’s big frustration, almost all requirements tooling vendors substantially lag behind the reality in product development. Things like traceability and the relationships between requirements have hardly been filled in in the software tools of suppliers like IBM and Siemens. “It seems as if they’ve never studied the stages that requirements go through from stakeholder needs to implementation. The lack of a functional and physical breakdown of the system means that you can’t link the requirements to those specific system elements. You’re actually missing most of the functional and physical breakdown – the left side of the V model.”

“I think vendors of product lifecycle management tools currently have too limited a view of the role of requirements engineering within systems engineering. In addition, they don’t or insufficiently support the left side of the V model. For this reason, I think they’re unworthy of the title ‘PLM tool vendor.’ After all, they only support a limited part of the lifecycle.”

Could you give an example to explain what’s wrong?

“In the traditional way of working, engineers keep track of the extent to which each part or product is part of a functional module. Take as an example a bicycle handlebar of type X with an integrated bicycle bell Q in the handle of that handlebar. For bicycle handlebar type X, this is a fixed component. Bicycle handlebar type X contains bicycle bell type Q.”

“Assume that bicycle handlebar type Y has multiple options for placing a bicycle bell, including an integrated version. Bicycle handlebar type Y optionally contains bicycle bell type Q. Traditionally, we record the relationship between the object bike bell Q with the bike handlebars X and Y as characteristic information of bike bell Q. This results in the object bike bell Q having to be modified each time with each new relationship with a bike handlebar. The version or revision number, the status, and so on. In addition, all existing links must be checked. This means a large administrative overhead.”

“But this really isn’t necessary because the object bicycle bell Q hasn’t changed at all. Only the relationships between the parts have changed. The solution is relatively simple: make sure that the information indicating the nature of the relationship between objects is a conditional relationship. However, this capability is missing from current tools. The administrative overhead works through to the requirements, which also describe the relationship to other objects as an attribute. We’re talking about tooling from the big PLM vendors here! At the moment, they just can’t do it. So there’s still a lot to gain here.”

“The lack of a functional and physical breakdown of the system means that you can’t link the requirements to those specific system elements.”

You say that big players like IBM and Siemens with their enormous development departments aren’t up to date?

“They sure aren’t, yet. The requirements engineering practice has made huge steps, but these haven’t been followed by the tool vendors. Even smaller players like Top Team, Cockpit and Contact Software aren’t there yet. That’s a big frustration.”

New tool vendors have a market to conquer and should be motivated to add functionality.

“They don’t do that enough yet, while as newcomers, they do have the flexibility to do so. The Dutch company Relatics from Ridderkerk is a supplier that’s doing well, but they’re mainly focused on civil engineering and not mechanical engineering. Relatics has built its whole tool around semantic modeling, where you consider the whole world as objects and relationships between them and all the attributes that go with them.”

Requirements engineering also influences the way we look at product creation. In high tech, people often refer to the V model when they talk about the process from initial ideas to product implementation. This model starts with a functional breakdown, the left leg of the V. Michielsen: “A practical problem is that you can’t include all requirements in the traditional functional breakdown. That applies, among other things, to the physical properties of products. Mass, volume, that sort of information. It would be wise to start two parallel trajectories in that left leg. Because later it will turn out that in the ascending leg, when you integrate, you can’t test what you’ve specified. This occurs, for example, when a submodule or function is distributed or divided among several physical modules. In that case, you can’t test those particular subsystems as separate modules, one at a time.”

The subsystem can only be tested once the entire machine has been assembled?

“You would like to be able to test such a feature right at the start, but indeed, that doesn’t work. You then actually need two parallel development trajectories, including the responsibilities and budgets that you can allocate to them. Before you have anything made or assembled at all, you use simulation tooling to do a virtual functional integration and a virtual physical integration. The goal is to first establish that the design is correct. That everything works and everything fits.”

“When you get to the end of that virtual development, you also know exactly that you’ve developed the right building blocks. You’re complete with respect to functionality. At the same time, you also know where those building blocks end up in the different physical modules because you can demonstrate that through your physical design. Once it fits virtually, you start implementing, constructing, programming, and so on.”

The W model, as Michielsen calls this form of development, will be the topic of a separate episode in his trend series.

The system requirements engineering trend series is also available as Bits&Chips podcasts on Apple, Buzzsprout and Spotify.

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

Recommendation by former participants

By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 8.9 out of 10.

Training for internationals makes Jaco Friedrich teacher of the year

Training for internationals by Jaco Friedrich
Blunt new colleagues, group leaders with incomprehensible wishes – the Dutch high-tech culture sometimes causes frustration for starting internationals. Why is it not enough if they just do what’s asked? Jaco Friedrich gives them a helping hand. With his training, “How to be successful in the Dutch high tech work culture,” he became High Tech Institute’s teacher of the year.

“Internationals tend to give a higher rating than Dutch people.” With this remark, Jaco Friedrich put his proclamation as High Tech Institute’s Teacher of the Year 2021 in perspective. The honor fell to him along with trainer Onno van Roosmalen.

Friedrich has been training leadership and communication skills for twenty years. In doing so, he focuses primarily on technicians and especially professionals in high tech. Being an engineer himself, he became interested in team dynamics and personal interaction because he saw that this had a major impact on the success of technical development projects. He decided to study psychology and make training engineers his profession.

In recent years, Friedrich developed a training specifically for professionals who are relatively new to the Dutch high-tech sector. This training,”How to be successful in the Dutch high tech work culture,” is now very successfully running several times a year. For the September 2021 edition, he trained a group of twelve participants and got a personal score of 9.8.

All participants said that they’d highly recommend the course to others (they responded with a tremendous total average of 9.7 points out of a possible 10). They commented that Friedrich’s course was “very practical and useful”, a “good and energizing experience”, “positive and certainly useful” and “safe and engaging.” “A great teacher,” one of them remarked.

Inspiring

Apart from his modest reply, Friedrich has another explanation for his success. The training actually helps international knowledge workers. “One of the participants commented afterward that he had learned in one day what he had painfully experienced in recent years about what you do and don’t do in the Dutch high-tech culture.”

“Misinterpreting what’s happening around you can cause a lot of frustration.”

Through the training, participants better understand what the expectations are and how to meet them, Friedrich explains. “Misinterpreting what’s happening around you can cause a lot of frustration. Compare it to a complicated device that doesn’t come with an instruction manual. Before you know it, it takes you an unnecessary amount of time to get the thing to work. If you take the wrong approach, it will break down. The culture training also is a manual.”

The many possible ways to get a smooth interaction with colleagues Friedrich finds especially inspiring about his culture training. “The different backgrounds of the participants inspire me. All of them come up with their own way of handling something once they get the hang of how it works in the Netherlands.”

What helps is that most internationals are highly motivated. “They’ve left heart and home and are stepping into a whole new adventure. I respect that.”

Training for internationals by Jaco Friedrich
Trainer Jaco Friedrich

 

Johan Cruijff

The culture training lasts only one day, but in that short time, participants take a big step. “It’s not helpful for employers to let new people swim. Talented people themselves want to be productive as soon as possible. They don’t want to waste time. By following the training course after, say, six months of work experience in the Netherlands, the penny drops and that helps them to ‘onboard’ faster and be successful,” says Friedrich.

The participants, who come from all over the world, say that the more intricate communication points do not always come through quickly. “Generally, they’re frustrated that despite doing the best they can, they still receive signals that they need to do things differently.” For example, they’re advised to take more ownership. It also happens that they perceive people as aggressive, even though they’re aware of Dutch directness.

“It’s all about what you have to do what’s not necessarily asked from you.”

Most internationals have to get used to Dutch bosses who expect team members to have the guts to confront them. They expect to be challenged and like a critical attitude from all colleagues. Friedrich: “It’s all about what you have to do what’s not necessarily asked from you. These things are essentially foreign to internationals and require explanation. How do you give feedback to someone who’s direct but not aggressive? What exactly is meant by ‘ownership’ in the Dutch context. How do you approach that? All these issues are discussed during the training. The participants recognize each and every one of them and they want concrete handles. We give them those.”

Friedrich knows that trainees benefit from his course. Afterward, he often receives emails from participants who report that what they’ve learned is useful at work. “They definitely do something with it because frustration can be quite high. It’s like the Dutch soccer hero Johan Cruijff said: ‘You’ll only see it when you understand it.’ The moment the participants gain the insight and, moreover, experience it in exercises, for example on how to influence decision-making, they don’t forget it anymore. This gives them self-confidence and the motivation to apply what they’ve learned.”

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

Recommendation by former participants

By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 9.1 out of 10.

“The Dutch way of co-engineering is unique in the world”

Mechatronics Trainings by Jan van Eijk
Last November, Jan van Eijk received the 2021 ASPE Lifetime Achievement Award from the American Society for Precision Engineering (ASPE). As one of the driving forces behind the Dutch mechatronics industry in recent decades, Van Eijk has left his mark on the Americans as well. In this first of two articles, we look back at how he gained a foothold in the US with Dutch knowledge and knowhow. Jan van Eijk is co-founder of Mechatronics Academy, providing all mechatronics trainings for High Tech Institute.

 

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

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

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.

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

Onno van Roosmalen named teacher of the year at High Tech Institute

Together with Jaco Friedrich, Onno van Roosmalen is High Tech Institute’s Teacher of the Year 2021. His “Design patterns” training received high praise and participants gave his lecturing skills a 9.8.

In October 2021, Onno van Roosmalen was invited to Tomtom in Eindhoven. They asked him to deliver the four-day “Design patterns and emergent architecture” training to a group of nine employees. When asked if they would recommend the course to others, participants responded with an emphatic 8.8 points out of a possible 10. They also gave the lecturer a score of 9.8. “Very, very good,” answered one of the trainees when asked about his experience. Another participant pointed out that the training was “great” and “exceeded expectations.”

“I suppose it has something to do with the fact that ‘Design patterns’ is my favorite,” Van Roosmalen responds soberly. “The training is a bit challenging and I’ve put all my ideas and energy into it.” The training being of a higher level evidently motivates him to execute it perfectly. “I like the subject and I think that comes across to the students.”

After studying physics in Nijmegen and earning a PhD in Groningen, Van Roosmalen worked at Yale University for three years in the mid-1980s. In 1987, he became an assistant professor of computer science at Eindhoven University of Technology. In the early 90s, a company invited him to give a training course on object-oriented programming. That proved very successful, mainly because the company’s management was the driving force behind the initiative. “The students were told to do exactly what I said.”

Van Roosmalen got the hang of it and continued to develop and deliver software design trainings for Ericsson, Philips and TUE, among others. Various versions of his object-oriented analysis and design courses have been running at High Tech Institute for over ten years now. This is also the case with his design patterns training.

Perfect analogy

The veteran has an interesting observation. According to him, participants in his training courses can be roughly divided into two types. “You have the interested ones. They drop out at a certain point. And you have the critics. They take a skeptical stance at first but later become very enthusiastic.” It fits with his own attitude to life. “Being a little suspicious can’t hurt. I like that: start with looking critically at the material you’re being offered. Then think about it. That’s how the knowledge lands best.”

Trainer Onno van Roosmalen

In bookstores, the software shelves are often full of titles on design patterns and object-oriented programming. “But those don’t convey what you actually want to convey,” notes Van Roosmalen. “Books contain lots of often simple code examples. The nice thing about patterns is that you can combine them and build something with them. I help students with this. Grady Booch, the co-founder of Rational, says that all object-oriented architectures are full of patterns. Combining those patterns is fun.”

Van Roosmalen once visited TUE’s mechanical engineering department. A professor there showed him a milled part, as an example of what his department had come up with. “He asked me if I could show him something too,” recalls Van Roosmalen. “That was a bit difficult. What could I show? A code listing? Instead, I told him about design patterns. That immediately created a click. He pulled a book about wheels and gears off the bookshelf and that indeed showed the perfect analogy.” Van Roosmalen’s point: every field has its own design aspects and those repeat themselves.

“Being a little suspicious can’t hurt. I like that: start with looking critically at the material you’re being offered.”

Dirty tricks

When Van Roosmalen was building architectures with software objects in the mid-1990s, it sometimes felt like he was just fooling around. “I thought I was doing something contrived. Call it dirty tricks. When the book ‘Design patterns’ by Erich Gamma came out in 1995, it was an aha experience for me. It turned out others were doing it too! It was a pattern! What I was doing turned out to be normal.”

According to Erich Gamma, it’s all about capturing the essence of a system in a model. Gamma draws his examples mostly from the world of user interfaces. Van Roosmalen focused his entire career more on control systems and embedded systems. “I use a lot of examples of that in my training courses, too.”

Companies developing software-intensive systems encounter a lot of patterns in their software and want to learn more about them. “Most of the time, they already have a large collection of design blocks and want to know how they can manipulate them,” observes Van Roosmalen. “Often they don’t understand all the patterns that are in them. The training is ideally suited to bring that to the surface.”

In turn, Van Roosmalen uses the new examples he gets from participants to enrich his own knowledge as well as the training itself. “The longer the training runs, the more cases are added,” he says. “The training at Ericsson ran for ten days distributed across a whole year. Together with their architects, we extracted a lot of great examples from their telephony system that you can apply patterns to. If that catches on and the learnings are actually applied in product development, that’s great.”

Together with Onno van Roosmalen, Jaco Friedrich has also been announced High Tech Institute Teacher of the Year 2021. He received equally high scores for his one-day boot camp training “How to be successful in the Dutch high tech work culture.”

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

Recommendation by former participants

By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 8.4 out of 10.