Category: Interviews

System architects are in increasing demand in the high-tech industry. They provide focus, overview and results in complex development projects. This means value for customers and euros for their own business. We ask Gerrit Muller, founder of the Sysarch training courses at High Tech Institute, about the secrets of good system architects.

The image that most people have of system architects resembles that of architects of buildings and constructions. They expect these professionals to divide complex machines or products into parts, give them properties and define the interfaces between them. It all boils down to sketching and drawing. In practice, these tasks are also the most visible. In buildings, but also in the technical industry, where sketching is expressed in block diagrams, CAD drawings or piping and instrumentation diagrams. All the parts are made visible and you can see how things connect.

An architect indeed has to make a system or product transparent. But that’s only the basis and not what the job is really about. “If you cut it up into pieces, look at those pieces and at the connections between them, all you have is a static image,” says Gerrit Muller, professor at the University of Southeast Norway in Kongsberg and founder of the Sysarch training courses at High Tech Institute.

Of course, drawings are useful. “The interfaces allow us to disconnect the components. They’re important and interfaces need to be well defined, but with them, you still have a collection of parts, a box of parts.”

The problems, Muller explains, arise when those parts start interacting with each other. “That’s where the value of the system is. Because together, they take care of the intended function and together, they do it well enough, accurately enough, fast enough, reliably enough, safe enough – a lot of that kind of namable qualities.”

Behavior and qualities, therefore, stem from the parts that are interacting with each other. “As a system architect or systems engineer, you design to get the desired behavior and the desired properties and you prevent undesired behavior and annoying properties.”

Far from trivial

But in practice, this interaction is so complex that we can’t foresee and understand everything. “Getting the behavior we want is far from trivial. Designing a system without undesirable properties is also far from easy. In the integration phase, when parts are made, usually unforeseen things pop up – you don’t get the desired performance. Usually, things don’t turn out the way you intended.”

The better the system architect, the better he or she can assess whether the design will work?

“Yes, but I want to take it one step further. They mustn’t only make estimations but also be able to visualize and communicate. That can be done with sketches and models. The goal is to communicate with many stakeholders such as designers, product managers, customers, the boss and other architects. Good architects make the system explicit and thus discussable and reasonable. In this way, they ensure that everyone can think about it and contribute their ideas. For example, by asking questions such as: suppose we do this or that, what will happen? This leads to better decisions in the design or specification. Making this communication optimal in teams and companies is the core function of the architect.”

As an example, Muller remembers a description Guido de Boer made when still working at ASML. De Boer wrote down on paper the path a silicon wafer travels through a lithographic stepper: via the wafer handler and wafer stage, including all operations such as moving, measuring and exposure. He called the story “Life of the wafer.”

“‘Life of the wafer’ was a set of drawings that showed what was happening. It helped to understand what happens to a wafer, during alignment, measuring the profile and all that sort of things. The downside was that everyone used it to discuss their problems, precisely because it was such a handy tool.”

This proved to be ineffective. “To discuss a so-called aerial image, for example, it’s useful to know what happens in the light path of a stepper: from the light source via the illuminator, mask and lens to the photoresist. Such descriptions of dynamic paths next to each other provide a great deal of insight into how a system works. They provide understanding and the opportunity to discuss and reflect on the whole. To grasp the dynamic behavior, you often need a whole lot of complimentary drawings or models. This way, you make the whole system discussible.”

Everything to get a better grip on the dynamic behavior?

“Yes, because there’s infinite dynamic behavior of a system and its environment. In that infinite mountain of interactions, you want to visualize the context. This means making the events visible that have the greatest impact. It means the system architect has to know what he can delegate to others and what he can ignore because it will have too little impact. That’s where true architects come in, the professionals who know where to dig deeper and who understand the art of omission.”

How does that process of omitting work in practice?

Muller explains that this is a real art because system architects operate in an environment with a lot of noise. “There will always be a team member asking for more detail, while someone else is shouting that his part isn’t visible. But as soon as you see too much, details start to dominate and the function and application disappear to the background. You no longer see how it works and what the effect is.”

Hiding the details is part of getting to grips with the complexity. System architects are aware of the software stacks, circuit boards and chosen alloys, they can also discuss them with their software engineers, electricians and mechanics, but they shouldn’t exaggerate. They’re forced to focus on the more abstract levels.

The first level is quite recognizable for everyone, that of the modules, units or subsystems. “Whatever you want to call it,” says Muller. “It’s the things that are produced, that you can touch. These fit well into the mindset of technicians. In lithography, for example, these are units like a stage, a wafer handler or a lens.”

On top of that comes an abstraction layer, which usually is about functionality. “Placing the wafer or moving a wafer plane.”

On the level above that, the qualities are discussed. “Good overlay, good depth of focus, speed – that sort of thing.”

Then comes the layer where the qualities come together in properties of the application. “Those are the things your customers are waiting for, such as yield,” Muller points out. “So you need to understand what role that depth of focus has and what depth of focus is exactly essential and what deviations the patterns on a processed wafer may have. At that level, you place everything more in context.”

According to Muller, system architects should be able to switch between multiple viewpoints at all those levels. “Is your product about speed or accuracy? If it has to be accurate and fast, exactly how accurate and fast? I can make something fast or super accurate, but most of the time, you want both speed and accuracy. Then you have to find the sweet spot – that’s what it’s all about.”

How do you recognize the potential system architect?

“I’m sorry to say, but I don’t have a recipe for that. I know good system architects. They’re often peculiar figures, each with their own qualities. They often entered into the profession from different angles. In the first place, they’re generalists by nature. They shouldn’t shy away from the broad picture, never be afraid of things they don’t know or that are out of their sight. They shouldn’t shy away from new things. In fact, they should be energized by them.”

“An architect is somebody that everyone can talk to. Imagine a large building with a room where colleagues always drop by. That’s probably where the system architect has his desk, even though he may not officially have that job title. The interaction with him is a naturally occurring phenomenon in the team because others experience that this person helps them.”

If a company doesn’t have a system architect yet, this is the person to look for?

“Exactly. If you put the system architect’s profile next to that, as we define it in the Sysarch course, it usually matches nicely. One more thing: system architects are always multitasking.”

What exactly do you mean by that?

“Being able to continuously change viewpoints, as we call them. Looking at a problem from different angles. You can learn that or might be forced to learn it. This multitasking is essential but can be very tiring. Some people are very good at systems thinking but are completely lost when they need to multitask.”

What are the biggest challenges for people who are new to the role?

“People often concentrate too much on the system and the technology. You have to help them get out of the system and into the world of customers, the product lifecycle and the business. They need to get out more and they need a push to do so. Communication or soft skills are also useful.”

“Imagine a big building with a room where colleagues always walk in. That’s probably the office of the system architect, even though he may not officially carry that job title”

The complexity of systems is increasing. Does this increase the need for system architects?

“You’d hope the problems of twenty years ago are so well known that we can now solve them in a more structured way. That would enable today’s architects to focus on the more complex problems. There’s almost no system that’s not connected to other systems anymore. There are almost no functions and features that don’t depend on multiple systems anymore. I need to understand the system I’m working on but also other systems, including the interaction and the people around it. That complexity, that growth, that’s a fact of life.”

You’re a professor in Norway and are working one day a week at ESI in Eindhoven. What’s the nature of the problems that companies ask you about?

“All questions that are also in the Sysarch training. What’s the role of the architect in my organization? How do I take long-term strategy into account? How should I help architects do their job in the best way?”

“Some companies say right away: I want to do model-based system engineering, MBSE. Then I’m always curious about their real question. Do they have an administrative need? Do they have to comply with the rules imposed by the American FDA? Or do they need to investigate or communicate better? You can model for many different reasons.”

“A lot of companies are struggling with the same question: they want to create a platform because they have products 1, 2 and 3 with a lot of synergy between them, but all different. Or they constantly have projects to make different product variants. Platforms, standardization – I often get questions about that. For an architect, this is a balancing act because standardization can make things rigid, thereby reducing the value for customers.”

Can the knowledge in the field of system architecture be packaged in manageable chunks?

“This begs the question: what’s the ability and what’s the art? What can we offer people in terms of methods and means, and what can’t you transfer as a teacher? Competent system architects have gone through quite a development. That’s an accumulation of time and experience. But if you’ve done something for a long time, it doesn’t mean you’ve developed the skill. Seasoned experience is needed. It’s about recognizing situations and thinking about them. Knowing why some things don’t work because you’ve experienced it and the next time, you know how to do it right the first time. Such a cycle of reflection is actually essential for a system architect to learn and reach a useful level of experience.”

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

Although machine learning security research is still in its early stages, it’s clear that input possibilities without barriers increase threats. You don’t need to touch a keyboard anymore to fool a machine learning system. Software security expert Balázs Kiss touches upon a few points in this new field and gives advice on the basic protection measures.

Just like software in general, machine learning systems are vulnerable. “On the one hand, they’re pretty much like newborn babies that rely entirely on their parents to learn how the world works – including ‘backdoors’ such as fairy tales, or Santa Claus,” says security expert Balázs Kiss from Cydrill, a company specialized in software security. “On the other hand, machine learning systems are like old cats with poor eyesight – when a mouse learns how the cat hunts, it can easily avoid being seen and caught.”

Things don’t look good, according to Kiss. “Machine learning security is becoming a critical topic.” He points out that most software developers and experts in machine learning are unaware of the attack techniques. “Not even those that have been known to the software security community for a long time. Neither do they know about the corresponding best practices. This should change.”

Security expert and experienced software trainer Balázs Kiss recently developed a new course on machine learning security to be rolled out shortly by High Tech Institute in the Netherlands.

Machine learning (ML) solutions – like software systems – are vulnerable in various ways and they increase the security needs. Last year, this was pointed out in a quite embarrassing and simple way by two students from Leuven. They easily managed to mislead Yolo (You Only Look Once), one of the most popular algorithms to detect objects and people. By carrying a cardboard sign with a colorful print of 40 by 40 cm in front of their body, Simen Thys and Wiebe Van Ranst made themselves undetectable as human persons. Another example comes from McAfee researchers who managed to fool the Tesla autopilot by misclassifying speed limit signs and made the car accelerate past 35 mph.

Know your enemy

“An essential cybersecurity prerequisite is: know your enemy,” states Kiss, who is also an experienced software trainer and recently developed a brand new course on ML security to be rolled out shortly by High Tech Institute in the Netherlands. “Most importantly, you have to think with the head of an attacker,” he says.

Let’s take a look at what the attackers are going to target in machine learning. It all starts with exploring what security experts call “the attack surface,” the combination of all the different points in a software environment where an unauthorized user can try to enter or extract data. Keeping the attack surface as small as possible is a basic security measure. Like the students from Leuven proved: to fool an ML system you don’t even have to touch a keyboard.

A common saying in the machine learning world is “garbage in, garbage out.” All algorithms use training data to establish and refine their behavior. Bad data results in unexpected behavior. This is possible due to the model performing well on the training data but unable to generalize the results to other examples (overfitting), the model being unable to capture the underlying trends of the data (underfitting) or due to problems with the dataset. Biased, faulty or ambiguous training data are of course accidental problems, and there are ways to deal with them. For instance, by using appropriate testing and validation datasets. However, an adversary feeding in such bad input intentionally is a completely different scenario for which we also need special protection approaches.

Attackers are smart

Kiss: “We simply must assume that there will be malicious users. These attackers don’t even need to have any particular privileges within the system, but they can provide raw input as training data and see the system’s output, typically the classification value. This already means that they can send purposefully bad or malicious data to trigger inadvertent ML errors.”

“But that’s just the tip of the iceberg,” finds Kiss. “Keep in mind that attackers are always working towards a goal. They will target specific aspects of the ML solution. By choosing the right input, they can actually do a lot of potential damage to the model, the generated prediction and even the various bits of code that process this input. Attackers are smart. They aren’t restricted to sending static inputs – they can learn how the model works and refine their inputs to adapt the attack.”

In case of supervised learning, it encompasses all three major steps of the ML workflow. For training, an attacker may be able to provide input data. For classification, an attacker can provide input data and read the classification result. If the ML system has feedback functionality, an attacker may also be able to give false feedback (“wrong” for a good classification and “correct” for a bad one) to confuse the system.

Crafted inputs

Many attacks make use of so-called adversarial examples. These crafted inputs either exploit the implicit trust an ML system puts in the training data received from the user to damage its security (poisoning) or trick the system into mis-categorizing its input (evasion). No foolproof method exists currently that can automatically detect and filter these examples; even the best solution, where a system is taught to recognize adversarial examples, is limited in scope.

By carrying a cardboard sign with a colorful print of 40 by 40 cm in front of their body, Simen Thys and Wiebe Van Ranst made themselves undetectable as human persons. Credit: KU Leuven/Eavise

There are defenses for detecting or mitigating adversarial examples, of course. However, an intelligent attacker can defeat solutions like obfuscation by producing a set of adversarial examples in an adaptive way. Kiss points to some excellent papers that highlighted these, like those from Nicholas Carlini and his colleagues at Google Brain.

All in all, ML security research is still in its early stages. The current studies mostly focus on image recognition. However, some defense techniques that work well for images may not be effective for text or audio. “That said, there are plenty of things you can still do to protect yourself in practice,” divulges Kiss. “Unfortunately, none will protect you completely from malicious activities. All of them will however add layers of protection, making the attacks harder to carry out.”

Most important, maintains the Cydrill expert, is that you think with the head of an attacker. “You have to train neural networks with adversarial samples to make them explicitly recognize this information as incorrect.” According to Kiss, it’s a good idea to create and use adversarial samples from all currently known attack techniques. A test framework can generate such samples to make the process easier. There are existing security testing tools that can help with this – like ML fuzz testers Tensorfuzzs and Deeptest, which automatically generate invalid or unexpected input.

Sanity checks

Limiting the attacker’s capabilities to send adversarial samples is always a good mitigation technique. One can easily achieve this by simply limiting the rate of inputs accepted from one user. Of course, detecting that the same user is behind a set of inputs might not be easy. “This is the same challenge as in the case of distributed denial-of-service attacks, but the same solutions might work as well.”

As always in software security, input validation can help. It may not be trivial to automatically tell good inputs from bad ones, but it’s definitely worth trying. We can also use machine learning itself to identify anomalous patterns in the input. “In the simplest case, if data received from an untrusted user is consistently closer to the classification boundary than to the average, we can flag the data for manual review, or just omit it.”

Applying regular sanity checks with test data can also help. Running the same test dataset against the model upon each retraining cycle can uncover poisoning attack attempts. Kiss: “Reject on negative impact, Roni, is a typical defense here, detecting if the system’s capability to classify the test dataset degrades after the retraining.”

The most obvious fact about ML security is often overlooked, notes Kiss. “Machine learning solutions are software systems. We program them in Python – or possibly C++ – and thus they potentially carry all common security weaknesses that apply to those languages.” The Cydrill trainer especially advises us to be aware of point 9 from the OWASP Top Ten. The Open Web Application Security Project is a document that summarizes the ten most critical security issues in web applications to raise awareness and help minimize the risk of attacks. Point 9 warns developers about using components with known vulnerabilities. “Any vulnerability in a widespread ML framework such as Tensorflow or one of its many dependencies can have far-reaching consequences for all of the applications that use it.”

Potential attack targets

The attackers interact with the ML system by feeding in data through the attack surface. Start to think with the head of the attacker and ask questions. How does the application digest the information? What kind of data? Does the system accept images, as well as audio and video files? Or are there restrictions? If so, how does it check the types? Does the program do any parsing or does it delegate it entirely to an open-source or commercially available media library? And after preprocessing the data, does the program have any assumptions (empty field, requirements on values)? Is data stored in a relational database or in XML or JSON? If so, what operations does the code perform on this data when it gets processed? Where are the hyperparameters stored, and are they modifiable at runtime? Does the application use third-party libraries, frameworks, middleware or web service APIs as part of the workflow that handles user input? If so, which ones?

Kiss: “Each of these questions can indicate potential attack targets. Each of them can hide vulnerabilities that attackers can exploit to achieve their original goals.”

These vulnerability types are not related to machine learning as much as to the underlying technologies: the programming language itself (probably Python), the deployment environment (mobile, desktop, cloud) and the operating system. But the dangers they pose are just as critical as the adversarial examples – successful exploitation can lead to a full compromise of the ML system. This isn’t restricted to the code of the application itself. Researcher Rock Stevens from the University of Maryland explored vulnerabilities in commonly-used platforms such as Tensorflow and Pytorch.

Real threats

Kiss’ main message is that ML security covers many real threats. It isn’t just a subset of cybersecurity, it shares many traits of software security in general. We should be concerned about malicious samples and adversarial learning but also about all the common software security weaknesses. Machine learning is software after all.

ML security is a new discipline. Research has just begun, we are just starting to understand the threats, the possible weaknesses and the vulnerabilities. Nevertheless, ML experts can learn a lot from software security. The last couple of decades have taught us lots of lessons there.

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

As a project manager, system architect and crisis manager in the high-tech industry, Luud Engels has a reputation for not mincing words. In addition to his consultancy work, he recently started as a system architect(ing) trainer at High Tech Institute. “Clear communication is key in complex development environments.”

You don’t want to start with Luud Engels about how open-minded and communicative we are in the Dutch high tech as a system architect. He’ll be forceful in his response, underlining just how hypocritical it is to believe that. “Here in the Brabant region, we’re not that open at all. Just stand at a coffee machine and listen. We’re not talking with you, we’re talking about you.”

When it comes to direct communication – or rather, confrontation – Engels has a reputation. A few months ago, he was sent packing after strongly expressing – according to his client – what was wrong within the company. “I’m convinced that at the right time, you can say anything to anyone – be it in a team meeting or a discussion between two people. Of course, most Dutch don’t do that. But I don’t seem to excel at it either because I sometimes put things so bluntly that people tell me to get lost.”

Engels’ appreciation of factual and clear communication comes from his many years of experience as a project manager, a system architect, a crisis manager and a member of the management team at engineering firm TMC. His advice for development environments: “Speak your mind. Also, about personal stuff. It’s perfectly fine to tell someone his blue shirt bothers you. But statements like ‘Microsoft sucks and Apple is good’ don’t help. Make it factual: are we going to work object-oriented or process-oriented? Are we going to use glass or titanium? What are the advantages? What are the disadvantages? Talking about glass, I don’t need to know the whole history of glassworks. I want the five key criteria – in numbers, not in positives and negatives. If you know the dominant parameters, you also know how to measure them and we can agree on the first development steps to make the measurements possible.”

Engels emphasizes that in the development of high-tech systems, several roads lead to Rome and that it’s important to stick to the choice made. “Make sure the whole team is at least on the same path, rather than endlessly searching for the only right solution – which, by definition, doesn’t exist.”

But sometimes, even the simplest of things can go wrong. “Once, after a positive conversation with a client, I received the report in colloquial Dutch. I asked if the client representatives had approved the text. Of course, they had not. So I insisted on writing it down in English, presenting it to the client and asking them for their approval. After all, it’s often about decisions with far-reaching consequences. Still, syncing with the customer proved a daunting task.”

The laws of Luud

• If the financial people take over, the engineering interest becomes secondary; if the engineers take the lead, it will be financially broken
  (About balancing tech and money in high-tech OEMs)
• The client who asks for a crisis to be averted is half the culprit or part of the crisis in question (About crisis management)
• I firmly believe in the power of the outsider (About the crisis manager)
• We talk past each other: one talks in Newtons per square meter, the other in bits per second (About communication and collaboration in high tech)
• A crisis doesn’t go away by getting rid of the people who put their finger on the sore spots (About stranded development projects)

The outsider

Engels’ extensive technical career started with a study of electrical engineering, after which he joined Sattcontrol, a Swedish industrial automation specialist. He programmed PLCs for egg-grading machines, dairy factories and automated warehouses. Later, he switched to Fortran for PDP and Vax minicomputers.

After five years, Engels moved to Cap Volmac (later Cap Gemini), where he did projects. While he mainly worked in engineering, Cap’s core was business automation. “I learned a great deal about developing computer systems and software according to the rules.”

Engels started for Cap at ASML, he then worked on highway signaling at the Dutch Department of Waterways and Public Works, eventually taking on leadership roles. Later, audits were added to the mix. He estimates that he’s assessed about twenty projects. “After a day of walking around, you know what’s going on and where the project went wrong,” he says. Smilingly: “And certainly not because I’m so smart, or because I saw so much, but mainly because I was an outsider.”

Engels firmly believes in the power of the outsider. “You arrive at companies where things have gone completely wrong and then you’re allowed to walk around and speak to 5-10 people. They all have an opinion about the project in crisis. You get to hear the whole story. People want to pour their hearts out. You hear what’s wrong, and above all: what others aren’t allowed to say.”

The headstrong technician

Technicians are a stubborn, headstrong type – and Engels should know, as he certainly fits that mold. “We’re engineers, aren’t we? We think like this: ‘I’m an electrical engineer and according to my calculations, it’s 5 volts. If you don’t get it, I’ll explain again, but the outcome remains 5 volts. You’re crazy, not me.’ While in projects, it’s mainly about effective collaboration. That’s the difficult part. One talks in newtons per square meter, the other in bits per second. One talks about the goal, the other about the solution. The high tech is one big Tower of Babel. That starts with requirements and continues through to design, integration and testing. Just as well: if I do a project myself and an outsider comes in, he or she will also shoot holes in it.”

Luud Engels will lead the mid-November edition of the System Architect (Sysarch) training in Leuven.(Belgium).

Engels prefers to step in when the crisis is at its deepest. Take the Fusion project that ran at Philips at the end of the nineties. Its ambitious goal was to use a single platform to cover the mechanical, electrical and software construction for medical diagnostic systems. The idea was that cost savings through reuse would justify the extensive operation. “The director outlined his problem as follows: every month, thirty new developers joined the project and every month, they told him that completion was delayed for another two months.”

Engels, again, applied the power of the outsider. “The outsider is allowed to speak up. The deeper the crisis, the more receptive one is to outside messages. Usually, other people have already had a look at it. But often, they put their fingers on sore spots that they weren’t allowed to point to and ended up having to leave. They asked me to replace the current project leader because he couldn’t make up for the delay. But a crisis doesn’t go away when you get rid of the people who put their finger on the sore spots. Instead, I went to help the incumbent project leader. Together, we contained the crisis by adjusting the scope and working with early feedback. One of my laws is: the client who asks for a crisis to be averted is half the culprit or has at least a dominant part in it.”

Is it tunnel vision?

“Please note: you’re talking about very competent people with very relevant arguments and tons of knowledge. But gradually, the solution or working method has been placed in different silos. Very skilled people wear down paths, creating trenches that are so deep that you can barely look over the edge. Everyone has his trench and is defending it stubbornly. You hear people say things like: ‘This isn’t negotiable!’ When you hear that, it points you to where it went wrong and where a possible beginning of the solution lies.”

Where does the solution start?

“The first law of crisis management is containment. With Fusion, it meant that they had to stop adding thirty people per month. Instead, they had to cut twenty a month and reduce scope. The deeper cause – in my opinion – was pure self-overestimation. The platform idea for software alone is a major challenge. But when you start including mechanics and electronics, for all diagnostic products, it becomes too much at once. It’s difficult enough to develop electronics, software and mechanics together for a single system, but trying to develop one platform for different product lines in one project is naive, to say the least. At the time, they also had to work with developers in Bangalore, and they wanted to go from CCM level 2 to level 3 at the same time. That had to stop right away. You need to limit the scope of a project in crisis and postpone long-term improvement initiatives.”

“It’s often the case that the technicians already know what’s wrong and so does management. Both are right, but they won’t reach a solution together. Much later, I did a job at Philips DPS, where I saw that Philips had made significant progress. Putting fingers on sore spots, however, was still not allowed, unfortunately.”

How does this get done the right way?

Start small, says Engels. “You need early feedback, preferably a launching customer. I’ve heard Martin van den Brink say it many times at ASML: put everything together, show me that it works. Then he challenges people by stating: ‘Your physics don’t work.’ There was a lot of that during early integration. Much later, the industry introduced fancy words for it, calling it Scrum, Agile and rapid development. But the point is that you need feedback, and it’s important to start getting it at an early stage. The goal has to be to deliver every six weeks and to deliver something that actually works. If not, you have the means available to find out why it failed, why the physics didn’t work. At that point, you might have to accept that you’re not going to meet your deadline. What you definitely shouldn’t do is bring in more people.”

“When technicians tell you they need more time to investigate something, you have to get suspicious. Van den Brink is also a master at assessing or challenging that.”

Another necessity: “Make people owners of a problem. Certainly in environments with complex developments, where there’s not even a beginning of a solution and new inventions are required, everyone feels like the master of their idea, with their personal insight. We Dutch are also very good at seizing every opportunity to talk about this in a very broad sense. But you simply need to take the next step. That’s the only thing from which a project benefits. So if you’re sitting in a room with thirty people and problems come up, the project manager, the crisis manager or the system architect must assign a person responsible to each problem. This also includes deadlines for results and decisions.”

According to Engels, it’s definitely in the culture of ASML, but there was a point in time when it got out of hand there. “They appointed an owner for everything and called him a project leader. McKinsey once did an analysis at ASML of project leaders and project sizes. They found that, on average, there were 1.2 people on each project, including the project leader! Then you run the risk that these owners, these project leaders, start competing over available resources and the underlying issue disappears into the background.”

Engels has extensive experience as a project manager, system architect and crisis manager in the high-tech industry.

The product manager defines the product that will perform well in the market. He determines the available budget – often too little – and negotiates with the system architect whether it can be made for that money. Engels: “It’s a balancing act. With mature products, it works differently, but with a first development, you want a proof of concept as soon as possible. Or at least a confirmation that your ideas are right and that you’re on the right track.”

To what extent should the system architect, like the product manager, talk directly to customers?

“In high tech, that’s beyond dispute. That’s where the product manager and the system architect come together. They have to. The former has more business focus, the latter looks at the technology and whether it’s feasible. They’re two sides of the same coin. This collaboration between the product manager and system architect is becoming more and more commonplace. However, I still see system architects who downplay the necessary coordination with the project manager or operational management. You then run the risk that a solution that perfectly meets market needs will ultimately fail in the realization phase.”

In smaller development projects, with ten to twenty developers, one person can take on the role of both project manager and system architect. In larger projects, with tens or hundreds of developers and several dozen suppliers, it’s important to split up. Engels has experience in both roles. “The project manager sets hard deadlines and a system architect has to work with them.”

“The project manager must define which issues the system architect still has to solve and with whom. Together, you discuss the ins and outs, weigh the benefits and concerns, decide on key parameters, and then the project manager calls the system architect: at the end of next week, we’ll make a decision! It’s all about direction, coming up with a format that involves knowledgeable people to arrive at quantified statements with which you can really make an assessment.”

A system architect has a major impact on product development, yet often has a less than visible role.

“He’s an experienced technician, but his value lies primarily in his view of the business. Ninety-nine times out of a hundred, the system architect knows the market in which his product or system is going to land. This is necessary to translate the market and product requirements into the system requirements and then outline the design.”

It takes quite a bit of experience to reach that level. At the same time, Engels observes that the concept of a system architect is subject to inflation. “Nowadays, there are architects all over the place. A software architect is usually a senior software developer, a requirements engineer or someone in charge of engineering. I wouldn’t say anything to the detriment of such a lead engineer. Still, the difference with the system architect is that the latter has to know the business, understand how value is generated and thus understand why it has to be done within a certain amount of time and money.”

“This is also the case in construction. Your architect asks you what you are going to do with your future house and adapts his design accordingly. Are you going to cook a lot, or do you mainly want to drink wine? That’s why Van den Brink does so well at ASML. He goes to customers and explains what kind of litho systems they need. He knows the market like no other. Even stronger, he dictates the market. That means he understands the goals and the timing of chip manufacturers like no other, including what their production processes look like. If they talk about critical dimension and overlay, he can explain that his machine can do that and also substantiate why.”

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

With the growing reliance on software in an increasingly high-tech world, it’s more important than ever to master the art of software engineering as software architects. Trainers Robert Deckers and Bart Vanderbeke have taken it upon themselves to turn developers into craftsmen.

“A colleague once told me about one of his former project managers, who, upon realizing that the estimates didn’t align with his timeline, just cut them in half to make them fit. I find it unheard of, not only that you’d do such a thing as a project manager but also that people stand for that kind of behavior. You don’t have to scold him, but you can open your mouth. Instead, at the end of the project, when everything has gone haywire, everyone complains about how this has happened to them.”

Inspired by Google executive Fred Kofman and his book “Conscious business,” Bart Vanderbeke calls on software architects to stop playing the victim. “It’s unacceptable and unhealthy,” he claims. “You’re the craftsman. When someone tells you that you need to do something in half the time, or skip the design, or refrain from reviews, you say no – constructively. Software architects are scarce, so you’re in a comfortable position, certainly no position to self-victimize. Don’t hide behind ‘management.’ As a software craftsman, using a term coined by Kofman, you’re ‘unconditionally responsible’ for everything you do or don’t do.”

“You need to take unconditional responsibility, which literally means that you need to have the ability to respond – in a meaningful way,” says Bart Vanderbeke. Credit: Bart Vanderbeke

At NXP in Leuven, Vanderbeke leads a team of fifteen software architects, working on 2.4 GHz radio applications for personal health – think hearing aids, headphones and earplugs. “Tiny systems containing tiny software stacks,” he notes. “But even if you have a codebase of 100k or 200k, like us, software craftsmanship is of paramount importance. Building the hardware takes about a year, followed by maybe five years of software enhancement. I’ve developed a series of lectures to help my colleagues bring out their inner craftsman.”

The non-functional

A kindred spirit, Robert Deckers, too, aims to increase software craftsmanship, but with a focus on software architecture – “the most difficult trick of the trade,” as he calls it. “It already starts with the question: what is software architecture? You can find hundreds of books that try to give an answer. While some are bad, terrible even, most of them are meaningful, but they all tell a different story.” This was one of two triggers that led him to dive into the subject, develop his own view, write his own book and bestow his insights upon others.

The second trigger was the realization that in traditional methodologies, there’s too much focus on the functional requirements, whereas the non-functionals are the hardest to get to grips with and therefore take up the most time. “Way back when I was an OOTI trainee at Eindhoven University of Technology, I was the software architect for a copier,” reminisces Deckers. “After two months of design, the anomalous system behavior started to rear its ugly head and I realized that we had to do error handling as well – while obvious to someone with 20 years of experience, it hadn’t crossed my newbie mind. When we were finished, to my big surprise, no less than 85 percent of all our code turned out to be for error handling, so only 15 percent of our efforts had been focused on the functionality. That’s when I first experienced that the real challenge, the real complexity, is in the non-functional.”

After the OOTI traineeship – the PDEng Software Technology, as it’s known today – Deckers sharpened his views at several companies, including Philips Research and Sogeti. Since 2013, he’s running Atom Free IT, coaching organizations and their architects, helping them create architectures, set up the architecture process and embed it. The last five years, he’s combining this with a PhD project at the Vrije Universiteit Amsterdam, researching the cognitive aspects of systems engineering.

Come prepared

Vanderbeke and Deckers are the newest additions to the software and systems portfolio of High Tech Institute. Both want to help software architects be better at their work – become real craftsmen. “As a software craftsman, you know how to organize your work and you have the assertiveness not to accept compromises on the way of working. Instead, you go for the optimum, taking into account the influencing variables and conditions. You don’t do things because someone tells you to, but as you understand the need, you autonomously decide to do so,” summarizes Vanderbeke the values he intends to convey in his workshops.

Robert Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes.

Learning to say no in a constructive way is a key topic in Vanderbeke’s teachings. “That requires you to come prepared. When you’re asked to plot a course in a project, you need to have a couple of options readily available, not down to the minute detail but to such an extent that you can weigh them and make an informed choice. When someone steps up to you and says something can be done in half the time you estimated and you don’t have your facts straight, he may well be right – you have no way of telling. If you know what you’re talking about, that will not happen. You can have a constructive conversation and you might be challenged, persuaded even, but you won’t let yourself be blown away by unsubstantiated claims. Someone once asked me if we could speed things up by taking shortcuts, upon which I replied: ‘The only shortcut you can take is skimp on the specs’ – and that was the end of the discussion.”

“You need to take unconditional responsibility, which means that you need to have the ability to respond – in a meaningful way,” continues Vanderbeke. “In my workshops, I use several small examples, taken from my everyday work, to get my point across. For instance, someone escaping responsibility would say: ‘I cut my estimation in half because my project manager told me to,’ as opposed to someone keeping ownership, a ‘player’ in Fred Kofman’s terms, who would say: ‘I wanted to avoid a fight with my project manager, so I gave in.’ Likewise, a victim would say: ‘I make estimations because our process demands it,’ whereas a player would say: ‘I want to stay with the company, so I use the established process.’ By making them aware of these little things, people are more inclined to correct their behavior.”

A good architecture is correct, consistent and communicated. Credit: Robert Deckers

Fish nor fowl

In his training courses, Deckers relays his ideas about good architectures. “The role of architecture is to offer a solution approach for the key system properties that are the hardest to realize. As a system architect, you always have to make sure you’re working towards a solution, providing guidance and serving your stakeholders’ needs, while also keeping an eye out for things that could go wrong if not addressed in the architecture. If you’re not doing this, you’re probably not architecting. Also, I want software architects to understand that an architecture needs to offer business value and that it’s feasible to build the system within the organization at hand. You can only be an effective architect when you’re prepared to step out of your technology comfort zone.”

According to Deckers, a good architecture is correct, consistent and communicated. “A system has to be correct in that it has to adhere to the stakeholder concerns and the technical environment. The development process has to be consistent. At Philips in Bruges, I once witnessed a software architect testing all preconditions of all the functions he programmed because he wanted his code to be robust. Meanwhile, in the cubicle right next to his, a colleague was using pointers without testing anything because he wanted his code to be fast. Combined in one system, that gives you neither fish nor fowl. You need to be clear on the key properties – my advice: hang the top five on the wall. Finally, an architecture should be described in such a way that you can discuss it with the different stakeholders, which means using different views for different aspects.”

Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes. He acknowledges that this seems to be at odds with the popular Agile principle of delivering working software as quickly as possible. “People often ask me: how do you match Agile and architecture? My answer to them: you don’t. They’re two different mindsets. Architecture is about looking before you leap, whereas with Agile, you just go and adjust based on the feedback you get. That’s perfectly fine for some businesses, but not for a copier or a medical scanner, where aspects like reliability and safety are known beforehand. The closest way to match Agile and architecture is to bend the rules and dedicate the first few sprints to the key concerns.”

Descending down the management funnel, the focus narrows and the risk for conflict grows.

Better decisions

With collaboration, there’s bound to be friction. A software craftsman, therefore, also needs tools for conflict resolution. In his workshops, Vanderbeke presents a management funnel doubling as an inverse conflict pyramid. It goes from wide to narrow in three levels: strategic, tactical and operational – from the what to the how. Descending down the funnel, the focus narrows and the risk for conflict grows. When a conflict actually arises, going back up the funnel to try and find a shared goal or principle helps to smooth things over.

“Software architects who are in disagreement about the way to tackle a problem often are at the bottom, stuck in their own solution. Taking them up and discussing the problem criteria usually ends the stalemate as they establish common ground,” illustrates Vanderbeke. “It’s a very useful instrument in process management as well. When you’re in a meeting that’s going nowhere, revisit the reasons why it was set up in the first place and a way out will present itself almost automatically.”

Stocked toolbox in hand, software engineers are well equipped for craftsmanship. With Deckers, Vanderbeke concludes: “It would be great to see them make better decisions. To see them operate more autonomously. And, at the same time, to see them have more fun in what they do.”

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

Deep at his core, Stefan Bäumer is an optics fanatic. He finds great passion in teaching because he likes to spread knowledge and, as he says, it keeps him on his toes. With undiminished enthusiasm, he has been providing the optics training “Modern optics for optical designers” at High Tech Institute for years. The training is tough – covering all aspects of optics – but also very valuable, participants tell him afterward.

 One of the nice things about the optics, Stefan Bäumer thinks, is the visual. “If you build a set-up in the laboratory with a light or laser beam and lenses, you can use your business card to follow the beam and see what happens to it and how it forms an image. I really like the fact that you can see the effect visually right away,” he says enthusiastically. He likes working in the field because optics are the heart of the optical (measuring) system, determining both the functions and the tolerance of the system.

“In the future, we will be moving more and more towards end-to-end modeling,” says Stefan Bäumer, lecturer at High Tech Institute.

Bäumer’s experience in optics goes back a long way. Already, during his Master’s in physics, which he followed at Washington State University, there was a link. Also, during his PhD at the Technical University Berlin, he was involved in optics at the Optical Institute.

After completing his PhD, Bäumer started his career at Philips in Eindhoven. Here he started as an optical designer at CFT and later at Philips High Tech Plastics. After that, he worked for eight years as a senior optical system designer at Philips Applied Technologies and Philips Research. After a short time, as senior principal engineer at Philips Lighting, TNO asked him if he wanted to join their team. He was happy to do so; it allowed him to turn on his light at another organization. After a career of seventeen years at Philips, he switched to the optical group at TNO in Delft.

Now Bäumer has been working as a senior optical designer at TNO for almost eight years. Since 2015, he has also been part of the principal scientists’ group, who help determine technical policy. As a principal scientist, Bäumer is co-responsible for the direction of research in optics at TNO.

Progress

To be able to determine which way to go with TNO Optics, it is certainly useful that Bäumer has been in the field for a long time. As a result, he is well informed of developments. “Actually, there are a number of important developments that have led to strong growth in optics. The accuracy with which you can model optical systems has increased enormously. The integration with other disciplines has also greatly improved. In addition, the making of optical elements has improved, because the manufacturing technology has made huge leaps forward. Finally, near-infrared possibilities for detectors and light sources have been added, which are used, for example, in medical research,” explains Bäumer.

Far-reaching technological developments in the field of optical system design have indeed significantly improved the performance of all kinds of simulation programs in recent years. Optics also benefit from this. “I used to work with rather rudimentary optical design programs with which you could model systems and create a layout. There was still a lot of manual work,” says Bäumer. “Nowadays, you can model much faster and more accurately. You can include all kinds of phenomena in your simulations, such as nanostructures and diffraction. The integration with other disciplines such as thermal disciplines, mechanics and the improved communication between software systems of the various disciplines have also led to progress.”

What is certain is that the more sophisticated manufacturing technologies now available have also greatly accelerated optical developments. This is due in part to lathes with much higher precision – diamond turning allows you to create incredibly precise optical surfaces, including free-form surfaces – and new techniques such as magneto-rheological finishing (MRF) and ion beam figuring (IBF). These techniques allow opticians to design optics with much better specifications. This has also led to the emergence of free form optics in the last ten years. This branch of the field designs new optical elements that have no translation or rotation symmetry over the optical axis. This offers room for better performance, miniaturization and new optical functionalities.

Stefan Bäumer: “I would like to give my students a good basic optical knowledge, which enables them to make a good estimate of what is possible with optical systems. And, of course, also where the boundaries of feasibility lie'” Photo: TNO.

 In the future, Bäumer predicts that we will be moving more and more towards end-to-end modeling. Bäumer: “By this, I mean that we are going to predict system performance, from source to detector, under all circumstances using high-performance computing, among other things, as is done with ray tracing (calculating how light rays behave in the optical system, AB) via graphics cards. This is a technique that they already use in the film industry, but it is also gaining ground in the scientific field. I also expect that more attention will be paid to computational optics. Because more and more computing power will become available, there will be more possibilities to find a better compromise between optical hardware and data processing via software. Because of this, different choices will be made in optical systems. Also, nanostructured surfaces and materials will increasingly find their application in optics. For optics in general, developments in the quantum field will unlock a whole new domain.”

Total overview

With all his knowledge about optical systems and the developments in the field, Bäumer can tell and show his students a lot during the training courses. The training course ‘Modern optics for optical designers‘ covers all the basic principles of optics. “It is important for trainees to understand how things work and which principles are behind them. How do electromagnetic waves and diffraction affect optical systems? What are the polarization effects? These questions all pass in review,” emphasizes Bäumer.

The fact that this training gives an overview of the entire field of optics makes it unique. However, there are many specialist optics courses, which zoom in on a specific area such as non-linear optics or optical design. What makes this training unique, however, is that it covers the entire domain of optics. A team of no less than seven qualified instructors, each working in the field of optics and specialized in a specific sub-area, provides high-quality training.

“Precisely the breadth and amount of homework that students have makes it a tough training. But that homework is the key to becoming familiar with the subject matter. When I talk to the students afterward and ask them what they thought of it, they say that it was tough, but that they learned a lot,” highlights Bäumer. “The training is also very strenuous for me. Every training takes a lot of preparation and there is a lot of after work, but I also learn from it every time and that keeps me on my toes. I want to give my students a good basic optical knowledge, which enables them to make a good estimate of what is possible with optical systems. And, of course, where the boundaries of feasibility lie.”

This article is written by Antoinette Brugman, freelance journalist and contributor to High-Tech Systems magazine.

A pioneer in the design of microelectromechanical systems (MEMS) with an additional passion for everything mechanical, a pragmatist and a very good teacher. That’s professor Bob Puers in a nutshell. He was chosen lecturer of the year in 2018 for his excellent MEMS training.

A curious course with overwhelming feedback from the trainees – that’s how Bob Puers describes the MEMS training course he taught in 2018 to a group of fifteen industrials from Pakistan. Puers: “It was held in China because of difficulties with the exchange of Pakistani. The trainees were all extremely willing to learn. I really appreciated this eagerness and also the particularly good interaction with the group. We had a lot of discussion on a very high level.”

In their feedback, the trainees said about Puers: “It was an excellent training both in terms of contents and presentation. The trainer was exceptional in answering questions raised” and “The professor’s way of teaching is extraordinarily good.” This positive feedback resulted in a review score of 9.8 out of 10 and the title “Lecturer of the year 2018.” Puers is modest about his contribution and points out that all the praise is probably due to accidental circumstances. However, when explaining his way of teaching and his knowledge about microelectromechanical systems (MEMS), it’s easily understood how he earned the title.

Bob Puers has always stimulated his PhDs to physically build a device. 

The scientist

Puers’ MEMS experience goes back to his study in electrical engineering. He was very interested in research and had a special passion for everything mechanical. When he came in contact with Raoul Vereecken, a urologist at the University Hospital in Leuven, he got involved in the development of portable, implantable medical electronics. He continued his career in this domain and started his own research group at the KU Leuven in 1988. Soon he had the disposal of his own cleanroom to fabricate devices such as pressure sensors, accelerometers and flow sensors.

In his research, Puers focused on the application of medical implantable electronics and the development of technology to produce sensors – he’s always been motivated to develop devices and is working in a pragmatic way to realize this. If Puers knows a certain principle works, he doesn’t delve too much into the details of the theory but uses this knowledge to put it into practice and make new devices. And being a man of practice: he’s always stimulated his PhDs to physically build a device. As Puers puts it: “My PhDs weren’t allowed to leave without leaving something on the table.”

Puers continues: “In our cleanroom, I developed lithography and application techniques with our group of researchers. We made more sophisticated mechanical structures – on a miniature scale. The whole process of developing a very small mechanical structure, integrating it in an electronic component – to convert the mechanical signal into an electronic one – and finally building a sensor out of it – that still fascinates me.”

There have been many developments in Puers’ discipline. “Back in 1985, our group was one of the first to develop accelerometers. These devices were ground breaking at the time. Nowadays, accelerometers are integrated into commercial products like smartphones and cars at incredibly low cost. There are quite a lot of devices we laid the basis for, ideas that were taken over by the industry later on. So, we had to search for new research domains several times.”

MEMS developments are still ongoing. The current trends are far-reaching miniaturization and very low power consumption. This makes sense, for many sensors are applied in portable medical applications and thus have to be as energy efficient as possible.

The teacher

As a KU Leuven employee, teaching was part of Puers’ tasks.

He started as a teacher of courses in biomedical electronic systems. Later on, he also taught about MEMS production technology. These courses still form the basis of his MEMS systems training at High Tech Institute.

“It’s challenging to educate people and to get them excited about the science domains that you find fascinating yourself,” Puers explains. “You’ll never get them all interested. Only about one third to half of the university students get excited about the subject, the others only do what they’re told. However, High Tech Institute trainees are always people with specific interests who share my enthusiasm. They usually have some experience already, so we have a lot of detailed and specific discussions during the courses. I really like that interaction.

Puers started his MEMS training course for High Tech Institute in 2009 – being a specialist, he was asked to educate people about MEMS. His goal is to introduce his trainees to the domain. “I want them to know more about all the techniques that have been developed over the years to produce micromechanical systems. I explain the possibilities and the impossibilities of MEMS, zooming in at system level. About half of the MEMS training I spend on the instruments we have at our disposal to build a sensor or actuator. These are all necessary techniques, like etching, bonding, packaging and coating. In the second part of the training, I teach the trainees about all kinds of successful applications, like flow and pressure sensors, optical systems and medical implants. In the end, the trainees should know what’s possible and what’s almost impossible. I want them to be able to judge how realistic new concepts are.”

His vast MEMS experience, being involved from the very beginning, makes Puers a knowledgable teacher. But he’s also skillful in tuning to his audience. “I always answer questions that pop up during the course. Sometimes I can do that straight away because I know the answer from experience. If I don’t know the answer, I get back to the issue the next course day. I like to anticipate questions and feedback in my training. Teaching is a process of evolution. In every new course, I use the experience of previous courses, so my intellectual baggage as a teacher is continuously being enriched. In this way, I’m constantly refining my courses and adjusting them to my audience and their prior knowledge.”

This article is written by Antoinette Brugman, tech editor of Bits&Chips.

Adrian Rankers and Hans Vermeulen had a sudden challenge when ASML Wilton insisted on providing the planned four-day Dynamics and Modeling training online. Rankers started working with green screen, Open Broadcaster Software, a camcorder, and document camera and after taking countless bumps and hard lessons learned, the training was successfully completed a month later.

In this article, Rankers of Mechatronics Academy and co-trainer Vermeulen share their experience on how to roll out a highly practice-oriented training course full of exercises online. They talk about the considerations, choices and tricky bumps, as well as about their experience with an ultimately very successful session of Dynamics and Modeling. They didn’t hold back their comments either.

Dynamics and Modeling revolves around the many aspects that influence the performance of mechatronic precision systems. In order to get that knowledge into your head, participants in the training should mainly work with exercises. One way this is achieved is by giving putting participants to work using the design tool 20-sim. “They do this in groups of two or three, with us looking over their shoulders,” says Hans Vermeulen, senior principal architect of EUV Optics System at ASML and part-time professor at TU Eindhoven. This need for intensive interaction between participants and trainers is a big reason why the training was never offered online before.

Last May, Dynamics and Modeling was scheduled for twenty ASML employees in Wilton, Connecticut. But when the first measures against corona came into force, travelling to the US was no longer possible for Rankers and Vermeulen. To guarantee the quality, they proposed to postpone the training until the autumn. However, the machine builder insisted: the technical experts in Wilton really felt the need to obtain the knowledge. That’s when the duo decided to wring the four-day course into an online format.

Better connection between ppt-slide and speaker

Coincidentally, Rankers had recently taken part in a conference that the American Society for Precision Engineering was forced to hold in Zoom. He was pleased with the design and quality. However, his trainer-senses also noted a disadvantage. “It was very tiring for me to look at a powerpoint with a moving mouse and a presenter that was only visible in a small window,” he says.

Adrian Rankers for a green screen during the Dynamics and Modeling training. Top left the camera for recording trainer and green screen, bottom right the document camera.

Reflecting on the upcoming course, Rankers realized that it is much more fun to watch a video stream where the teacher is visible from the waist up next to the presentation. “This creates a better relationship between the slide and the speaker explaining the information.”

Rankers looked around and saw three options to achieve this. It is possible to project a powerpoint on a wall and video stream the teacher plus projection with a camera. You can do the same with a large TV screen.

The third option was to put the instructor in front of a well-lit green screen, cut him loose using software and then mount him in the powerpoint presentation and share that stream via Zoom or Teams. Just like the weatherman on the NOS news, the trainer has to coordinate his instructions via his own screen.

Experimenting with green screen and OBS

Rankers decided to experiment with green screen and Open Broadcaster Software (OBS). He borrowed a large green tablecloth from a friend and hung it over a telescopic handle for garden tools. Photo shops already sell good green screen cloths for 30 euro. But because they were all sold out, instead it became a 4 by 6 meter cloth for 80 euros – also reasonably affordable.

Through this screen Adrian Rankers coordinated his movements with the information on the powerpoint slides.

His first experiment with the tablecloth already worked “surprisingly well.” Rankers noticed that it was the exposure that counted. “If you go for Hollywood quality, seeing every hair of the presenter, it comes close. My wood and rope setup worked surprisingly well in sufficient daylight, especially when you consider that a lot of detail is lost in video streaming to the other side of the world anyway.” As a backup, he checked the available large-screen TVs in a nearby shop.

Because of the time difference, the training for ASML Wilton required afternoon and evening sessions, so Rankers also wanted to test the lighting conditions in the evening. “I figured this might be an issue,” he says. “From the information on the internet I concluded that evening shots were really different. Without good artificial light, the software doesn’t properly cut the person out of the green background.”

The nocturnal farewell drink at a distance at the end of an ASPE conference at MIT gave Rankers the opportunity to briefly test and experiment with it. Surprisingly, it turned out to work with the available artificial light in the space that Mechatronics Academy and High Tech Institute had set up at the Fellenoord location in Eindhoven. “I’ve had a lot of positive reactions and agreed with MIT pro Dave Trumper that I would share our first course experiences with him.”

Whiteboard and document camera

During their physical training Rankers and Vermeulen write a lot on a flipchart or whiteboard. Teams (which was chosen at the request of ASML) offers the possibility to write with the mouse, but that gave problems. In trials Rankers conducted in preparation with ASML Wilton, it was reported that participants could not use their whiteboard function. They also couldn’t share their own screen. The whiteboard problem was confirmed by Microsoft and appeared to be related to (GDPR) privacy rules.

That’s why Rankers on the trainer-side immediately sought refuge with a document camera. “A document camera is similar to a webcam on a tripod, which is aimed at a sheet of A4,” explains Rankers. “This can be easily autofocused on the paper at the touch of a button and then hold this setting. If you’re going to write, that’s fine. It’s not going to be disturbed by, say, autofocus on your hand.”

Both the trainer and his co-trainer have a screen on which you can see the image that is also presented to the participants.

Rankers and Vermeulen were both very satisfied with the document camera. “But switching between them is one of the minuses,” says Vermeulen. “In a physical training course, participants see everything side by side: powerpoint, whiteboard and trainer. Now they only saw our pen on the paper. If we switched to presentation, they’d have lost that image again.”

Rankers adds that entering an additional camera signal “still requires some dexterity” because of the switching between applications, presentations and the document camera. “That’s a bit more complicated because of the combi green screen and OBS,” he thinks. Especially switching to an application like 20-sim takes some practice. Operating the computer tool via a monitor a few meters away from you was not easy. As a double check, Rankers invited himself via private email so that he could see on his mobile phone at all times what the students had in view.

Data rate prioritized

A point of attention was the internet speed at High Tech Institute on location Fellenoord. This could be a potential bottleneck. The common throughput speed of all tenants together turned out to be only 100 Mb/s, while for a video stream 5 Mb/s is quickly needed. It turned out that the IT department wanted to give one IP address a higher priority for four days.

Rankers says, with a small sigh, that the people in Wilton, like his students at the TUE, only started installing 20-sim in the weekend before the training. “That didn’t go well because of the security of their ASML laptops,” says Rankers. The result was a lot of email communication just before the training and an escalation to the IT helpdesk to facilitate the final installations. “Next time, I’m really going to call everyone a week in advance and check on the preparation,” he laughs.

Rankers had made five short introductory videos for 20-sim and sent them in advance to teach the participants all the essentials of the tooling. In the future, he plans to add a video with the latest checks and send it well in advance. “So they know what we expect as basic knowledge.”

Interaction with the students

In the training setting Rankers and Vermeulen used a laptop with two external monitors. At an angle under the monitor with the constructed video image was also a second external monitor on which the Teams-meeting was shown.

In the training, in which everyone participated from home, most students unfortunately did not have a webcam. Rankers had also noticed that the connection would not work as well if everyone turned on their camera. That’s why they finally chose to only switch on the available webcams during the proposal round. “We didn’t see students, just the glowing balls with initials when questions were asked.”

Initially, Rankers asked the students to respond via the chat function and by raising their hands when they were in the picture. “Chat in itself worked well, but leaves little room for extensive discourse,” he says. “Hand-raising requires the presenter or his companion to be very alert, and that wasn’t always the case. In the end, after the first part of the day, we agreed that everyone would just interrupt and ask questions through their microphone. That worked well. There was a lot of interaction, but just like in an ordinary classroom, some stay quiet with a wait-and-see approach .” According to Rankers, there is still room for improvement. “Online, you could easily log the participation in order to more specifically encourage some people to participate.”

Practical exercises online

In the exercises, participants worked with teams that changed each day. Sometimes in pairs, sometimes in groups of four or five. In doing so, Rankers and invite Vermeulen to watch. Rankers: “There was good discussion within the groups, but there is still room for improvement in the guidance”. Vermeulen: “During an in-person training, you watch along and see immediately if the screen gets stuck. What we found is that online, participants didn’t speak up to let us know when it froze. It worked better with groups of four or five people than with couples,” describes Vermeulen. According to him, “Larger groups also work better online because there are always a number of people among them who are a bit more experienced and who pull the other along with them.”

Online training with a co-trainer on standby was a pleasant experience for Rankers and Vermeulen.

Rankers and Vermeulen alternated every hour and a half. In addition, they noticed that training is pleasant when someone is on standby. “Presenting the whole thing takes some getting used to. It’s really nice with two people.” Rankers also has training sessions in which he uses a different teacher every part of the day. “Then you actually always need someone to instruct and deal with calamities.”

The duo was largely spared the latter. During the four days, Rankers and Vermeulen had to do a hard restart only once, because the system got stuck. In the end, Rankers concluded that they had completed a successful edition, “with a lot of ideas to do it even better and perhaps simpler.”

Four afternoons and evenings of Dynamics and Modeling are intensive for Vermeulen. In the evening around 11 p.m. at home, preparing course in the morning while his children also asked for attention now and then. “It’s second best,” he says when asked to choose between an on-site training and saving a tiring journey. “Being there live is by far my preference,” he says. “Especially with all the exercises. I can imagine that you can give a very good training online. We do that in college. But a lot of interaction requires physical presence. I think for one or two days of training I would opt for online, for four or five days, I would choose to take the penalty of flying six hours there and six hours back. For Asia, online training is difficult because of the time difference, unless both teachers and students make concessions. At our upcoming online design principles training for ITRI in Taiwan, shortly after the summer holidays, we will start extra early in the morning on our side and the students will continue in their time zone in the evening until 22.00 hours”.

The evaluation of the first online training Dynamics and Modeling showed very satisfied participants. Apart from the remark whether this intensive training might not have been better given in five days, the students were full of praise afterwards. Below is a selection of the category ‘general remarks’ from the evaluations:

• “Lecturers are very experienced and have vast knowledge on these topics. I find this training very useful and a nice summary on multiple topics. It is a pity that the training was online, I feel like in person training would benefit all and it would be even better than it was.”
• “At times there were technological challenges. I do wonder if Zoom would have worked better.”
• “Intensive content, but very good learning experience with down to earth explanation. Thanks.”
• “The virtual setup was fairly successful, with very few disruptions. Overall a success!”
• “Great training overall — excellent instructors & good use of physical ‘case studies’ to illustrate concepts”
• “It would have been better if the training was given in 5-day time period instead of compressed 4-day period. There was a lot of good material. It would have helped to absorb that material better over 5-day period. It would also have given time to spend more time on the in-class exercises.”
• “Very practical training with the correct mix of theory and fundamental content. Very well delivered by the presenter.”

 

Hans Vermeulen (l) and Adrian Rankers are catching a breath during the break.

This article is written by René Raaijmakers, tech editor of High-Tech Systems.