12 minute read
No systems engineering without digital engineering32 No systems engineering without digital engineering
Digitalization makes it possible to automate large parts of the engineering process. Much can be gained by better harmonizing information from various disciplines, stimulating reuse, formalization and simulation, digital twinning, smart feedback and the application of artificial intelligence. However, the implementation is so comprehensive that collaboration between academia and industry is the only logical step. The High Tech Systems Center is building a consortium around digital engineering to work together on continuous improvement of development processes without losing sight of the business aspects.
Advertisement
Alexander Pil
“M any companies struggle to keep up with technological progress. More and more, techniques and tools are coming onto the market that could be beneficial. Engineers have to be trained to master new cloud technology or simulation methods, for example. This is costly, time consuming and only a small piece of the puzzle. The big question is how to embed the acquired knowledge and potentially crucial methods in their organization and systems – a major problem for the industry. As a result, companies regularly get stuck in the choices they initially made when setting up the product line. And if you stick with the old, y ou quickly fall behind.”
These are the words of Marc Hamilton, a fellow at Eindhoven University of Technology’s High Tech Systems Center. He notes that these problems not only affect SMEs. “It’s also a hell of a job for large OEMs with a lot of knowledge and capacity to integrate new tools and techniques into their engineering process. It’s complicated and risky for them to adapt or change their existing workflow. Smaller companies have an advantage in this regard but often lack capacity. For all categories, it puts a brake on how quickly they can integrate new technologies, methodologies and tools.”
Another group for which this problem frustrates progress are the companies that traditionally have a mechatronic origin but increasingly come to the conclusion that they have to retrain themselves as a software company. “Building all kinds of apps, adding connectivity and monitoring in the cloud is becoming a normal requirement,” Hamilton sums up. “Even for something as simple as a toothbrush, there are now apps that track how well you’ve brushed. Companies are forced to transform into becoming software experts, and that’s a struggle. After all, it was never their core business and they simply don’t have the knowledge on board. Good software experts are hard to find. How do you ensure that you keep up to date with all the rapid developments? Tomorrow, a new technology will emerge and the same struggle starts all over again.”
Context
For the further evolution of systems engineering, an impulse is needed for digital engineering. “That involves the far-reaching digital support of the design process, especially in places where there’s still a lot of human intervention,” explains Hamilton. “System developers already use many tools for digital engineering. Each of these instruments works fine, but it’s still difficult to connect them in a flow. It takes a lot of human intervention to interpret how to transfer the outcome from one tool to the next. This often goes wrong, especially between the various disciplines in a development organization. It would be very nice if we could automatically transfer all that data.”
That’s easier said than done. “It’s difficult in two ways,” clarifies Hamilton. “First, each tool uses its own format to specify and save its input and output. Moreover, this is done based on its own paradigms or principles. Second, the context in which you apply them is crucial. For instance, you can easily make a state machine of the behavior of the weather. You could also generate code from such a model, but that doesn’t mean you can make it rain. Engineers must decide when to use which tool and how to use the results in the other steps. We as humans must manage that interpretation of what a tool contributes to the process.”
In many areas, there are already new standards and frameworks around digital engineering, or they’re emerging. In simulations, for example, models such as FMUs can be linked together based on the FMI standard. And the CAD world
has various widely supported data formats. Major industries such as defense, aerospace and automotive have a long tradition of engineering standards and frameworks. Hamilton: “However, modules that tie the models together in a simulation environment aren’t suitable for controlling a system. We’re flooded by all kinds of standards that solve partial problems. But the real trick is integrating all these types of technologies and reducing the knowledge required to apply them. We’re trying to get this under control with digital engineering so that we can take further steps to make engineering more efficient and to expand applications of artificial intelligence.”
“How do you keep up to date with all the lightning-fast developments? Tomorrow, another new technology will arrive and the same struggle starts all over again,” says Marc Hamilton, a fellow at the High Tech Systems Center.
Credit: Eindhoven University of Technology
Falling behind
Hamilton also looks at the competitiveness of the Netherlands against the rest of the world. “At the moment, we’re not behind in system development, but we’re certainly not ahead. Take artificial intelligence, which plays an increasingly important role in engineering. Many of the examples come from the US or China, where investments are huge. Europe is lagging. We may not be doing badly at the moment, but at this rate, we’re going to fall further and further behind.”
“We have a lot of specialized knowledge in the region and we’re really good at building high-tech systems,” Hamilton continues. “You want to maintain and expand that position by using the knowledge to make valuable products. That means we have to engineer faster and better. We need to build an ecosystem where we can continuously and quickly explore improvements and new engineering tools, get the results to the market and get businesses to apply them.”
Three main themes
The call for better digital engineering isn’t new. “I notice that many companies have been feeling the pain for some time,” says Hamilton. “Some of them have taken the first steps themselves. However, almost all of them lack the capacity to encompass the complex complete picture.”
A few years ago, the High Tech Systems Center (HTSC) took the initiative to set up a consortium and bring parties together to work on better systems engineering. “During the first meetings, topics and challenges continued to come up. It only diverged. There turned out to be so many aspects of the engineering process that needed to be addressed in one way or another that it was difficult to pick and focus,” explains Hamilton how comprehensive the issue is.
HTSC has put its back into it and brought the problem down to three main themes. The first is platform engineering. “Many companies are working towards a platform for their product lines so that they can reuse parts and knowledge more easily,” Hamilton points out. “In high tech, with its high degree of optimization, it’s rarely the case that you can transfer subsystems from one machine to another. However, it’s certainly possible to reuse building blocks and modules at higher design levels and to refine them for the new system.”
The second theme is the large number of available tools. “A new package or another license sounds expensive, but they can speed up your process tremendously. However, that’s difficult to quantify, which means it will encounter a lot of resistance in the higher management layers. So you
have to link them to the company KPIs. Naturally, this di ers per sector. Sometimes, time to market is crucial. If you can gain a month of development time with a new tool, you have a clear business case. In another branch, it may be about reliability and wanting the product to be one hundred percent right. en it makes sense to invest in veri cation tools.”
Data and feedback are the third main theme. Today’s systems collect a wealth of data. With that input, you can make very valuable improvements for an update or in the next system. Of course, this only works with meaningful data, which can also be expensive to collect.
Data lake
Many relevant research proposals have been collected around these themes, which have subsequently been clustered. is clustering has now led to a clear starting point for further research in the other clusters. erefore, the consortium’s rst concrete step is presented. “We’re going to work on a foundation that we call systems engineering process orchestration,” says Hamilton. “In doing so, we link models, data and tools to a data lake so that the possibilities for tackling the challenges are expanded with modern data analysis and AI technologies. Essential is the context
HTSC is building a consortium on digital engineering from its new location in the Meulensteen House of Robotics on the TUE campus.
Credit: Eindhoven University of Technology
of the models and data. After all, data has no value if you don’t know where it came from in the engineering process and how it relates to the systems being developed. In addition, you must be able to value the steps of that engineering process in terms of relevant company KPIs to be able to optimize. Such engineering knowledge must be injected into the data lake.”
While this basis o ers opportunities for embedding and tackling digital developments in engineering processes, other clusters emphasize improvements in process support. is includes process optimization, automation of synthesis, support of system design decisions, application of digital twins, the design of the data generated by the system and processing of that data to design improvements.
Fast spinoff
e High Tech Systems Center is now building a consortium on digital engineering. “We’re currently in the phase of pitching these new ideas to companies. We want to build a proof of concept. at would make it a lot more tangible. We’re not starting blindly; we rely on existing technology and we work to expand it. ere are already many options and parts. Aside from the necessary fundamental research, the consortium also wants to give full attention to the coupling of applied research, and rapid spino and feedback of the results to practice.” e sooner Hamilton can discuss his plans with partners, the better. “Hopefully, then we can make everything much more concrete based on use cases that participants contribute themselves. When will we have the rst meeting? I hope this fall. at may be ambitious, but I think we have a good roadmap, a good campaign plan.”
Interested parties are welcome to participate. Please contact Marc Hamilton via m.a.m.hamilton@tue.nl.
Do you have an unstructured design flow and no time or knowledge to improve it?
www.dizain-sync.com
PCB, FPGA, Cabling and Chip design environments
Han Schaminée is a product innovation consultant.
What’s this thing called software engineering?
In September 2018, Corinne Vigreux started CODAM, a training program in programming. Corinne is one of the founders of Tomtom and she devotes part of the capital she earned there to make this world a better place. And since this world needs software, it needs talent that can create that software. Claiming everybody can learn to program in 3.5 years, CODAM believes there’s still a lot of untapped talent around, especially among people who can’t afford to take a course or to attend university. The program is for free and in this way, Corinne believes she cannot only help these people but also help industry find the software talent that it so desperately needs.
Checking out CODAM’s website, I noticed it talks about programming. Is that the same as software engineering, I wondered. Where does software engineering fit in, actually? Many engineering disciplines make use of coding, like mechatronics, automotive system design and healthcare system design. Is software engineering just a capability within these engineering disciplines, like thermal analysis for hardware design, construction calculations for an architect or solving a differential equation for a motion control engineer? Or is software engineering a discipline in itself? And if it is, will it benefit from CODAM?
In my daily work, I notice many different definitions of software engineering. People, especially without a background in computer science, often see software engineering as coding or programming. That doesn’t feel like an engineering discipline, does it? To me, an engineering discipline includes understanding the problem and applying technology to find a solution for it.
In fact, I feel coding is the smallest and easiest part of software engineering. And as a consequence, I believe, efforts to just optimize the coding part fail to address our biggest problem.
Wikipedia defines software engineering as the systematic application of engineering approaches to the development of software. It also says
software engineering is a subfield of computer science, management science and systems engineering.
The latter is quite interesting. Indeed, the field of system design is part of different departments at different universities, be it computer sciences, mechatronics or management sciences. These all approach things differently. I’ve seen the same in companies – in some, system architects preferably do not have a software engineering background!
To me, software engineering has a lot to do with system design. But especially the design of systems in which the complexity isn’t so much in the components itself, but in the interactions between them. I have yet to hear other system design disciplines consider association and inheritance relations to better understand the interactions between. The complexity is not in fighting physical constraints, but in managing all these interactions and all the possible states caused by the many interactions.
Software engineering is a rather new discipline. And like many other new disciplines, people believe it’s easy, just common sense, something everybody can do and not as difficult as real disciplines like physics or chemistry. The same is true about user interface design or even leadership.
Of course, we need algorithms and programs. But that’s not unique for software engineering; the other disciplines need that as well. It would be good when we as professional software engineers would do a better job communicating what our discipline is all about.
I believe 3.5 years of programming training in CODAM doesn’t make you a software engineer, like a soldering training doesn’t make you an electronic engineer. But it’s still a very good basis and a fantastic initiative. Thank you, Corinne.
