Engineers invent, design, analyze, build, test and maintain complex physical systems, structures, and materials to solve some of societies most urgent problems, but also to improve the quality of life of individuals. Engineering is artifact-centered and concerned with realizing physical products of all shapes, sizes, and functions. At intengineering I am motivated by the quest to empower these engineers to cope with the ever increasing complexity of the systems they have to provide. I provide science and innovation based reports, thoughts, ideas, and interesting news – informal, but current – thought provoking and open.
How engineering designers talk
In a recent study, my colleague Dr. Lucian Ungureanu analyzed the details of how engineering designers communicate with each other. Lucian closely looked at the language designers used in two recorded design meetings that were concerned with the design of a crematorium . To this end, he applied a text mining technique called n-grams, that identify sequences of words (with length n) that are frequently used within a specific communication event. For example, during the two design meetings of the crematorium, participants used the 4-gram ‘it would be nice’ 17 times.
Looking at the n-grams Lucian found that many of the most frequently used ones, are used by designers to express ambiguity and vagueness. For example, ambiguous and vague statements. For example, the 6-gram ‘it would be nice to have’ points towards a vague statement as it also opens possibilities to alternative choices. Instances of vague 2-grams would be, for example, ‘bit bigger’ or ‘additional space. Both of these 2-grams do only point towards an extension, but do not point to the precise magnitude of the extension.
One conclusion that can be drawn from the relative frequency of ambiguous and vague n-grams is that designers use such ambiguous and vague phrases to indicate important ‘design acts’ – statements and discussions within meetings that lead to crucial design changes or new innovative design ideas. The findings also point to the overall importance of ambiguous and vague statements during the evolution of design ideas and changes. They allow designers to suggest new avenues and angles without necessary specifying specific solutions already and invite others into the discussion.
Thinking about computational design tools, this research can provide many insights. Most importantly, the results point towards the need of computational design support tools that allow designers to include ambiguous and vague ideas – something that is, by large, not possible with existing tools yet. At the same time, it is probably possible to develop intelligent support agents that can detect ambiguous and vague statements and then provide dedicated design support during meetings, such as triggering specific visualizations or additional supporting information and data, on the fly, within meetings.
If you are interested in this research you can find the full paper here.
Modeling, abstraction, and digital twins
In our recently granted Horizon 2020 project Ashvin, we defined a digital twin as a digital replica of a building or infrastructure system together with possibilities to accurately simulate its multi-physics behaviour (think of structural, energy, etc.). Additionally, digital twins provide possibilities to represent all important processes around the building or infrastructure system throughout its product development lifecycle. These processes include evolving design information (as-designed vs. as-built) and an accurate description of all relevant construction, as well as, maintenance activities. The technical enabler for such digital twin representations is the internet of things (IoT) that allows establishing connections between real-time data coming from sensors and cameras as to establish a close correspondence of the physical entities and processes with their virtual representation. This definition is similar to the definitions provided by others, such as the one provided by for example Sacks et al. (2020) – https://doi.org/10.1017/dce.2020.16.
A closer look at these definitions, however, reveal the inherent danger of blurring technical possibilities with the realities of engineering design work and the constraints that are imposed on engineering by the boundaries of human cognition. The technical possibilities we have nowadays in terms of increasing the sophistication and depth of models representing products and their behavior is growing quickly. At the same time, we are more and more able to fuse and combine different data-driven and physics based models with each other in ways that would have not been computational possible just a number of years earlier. What is missing from technically driven definitions is however a clear focus on how an increase in model complexity can support engineers.
Reflecting some more, the notion of the ‘twin’ of the real world that exists in the digital might be ill chosen. After all, engineers establish models as simplified and highly abstracted representations of the reality so that they can cognitively deal with reality’s complexity. Instead of ‘accurately simulating the multi-physics behavior’ and ‘representing all important processes’, engineers are probably better supported by models that are supported by simplified simulations of the multi-physics behavior and by the representation of very few processes. Of course, all with the aim to support engineers within their limited cognitive abilities. But also from the utilitarian understanding that a simpler model that allows for similar understanding, is superior to a more complex model.
To account for this aspect, it might be appropriate to start technical research and development efforts from a solid and in depth empirical understanding of engineering work. From this understanding clear requirements can be derived, not only in terms, of what needs to be modeled, but equally important how abstract these models need to be for allowing engineers to still come to creative conclusions within their cognitive abilities.
To allow for such a development approach, the strategy we will follow therefore on Ashvin is a clear focus on how engineers can impact the productivity, resource efficiency, and safety of construction processes within different phases of the design and engineering life-cycle. From this we derived a number of very specific applications for supporting engineers (we call this the Ashvin tool kit) and drive all digital twin related development work based on the requirements for these applications. The next three years will show how successful we can be with such an approach to achieve our envisioned impact. The project’s website should be online soon at www.ashvin.eu.
cod and off-shore wind farm engineering
The complexity of engineering systems is thrilling and exciting and the factors that need to be accounted for during design. Few systems we engineer within the natural and built environment can be realized in isolation; most of them need to be designed accounting for many different influences in their environment.
The design and engineering of off-shore wind farms is a great example of this complexity. On the surface it seems rather simple to design and engineer off-shore wind parks, at least, in comparision to urban systems. After all, wind-parks are operated in isolation. Weather and water are influencing the structure, but though chaotic these processes are well understood from an engineering perspective. It seems as if little integration with other systems need to be considered.
Looking closer, however, many intriguing processes come to the fore that influence the design. For example, by now, it is well understood that the maintenance of off-shore wind farms needs to be accounted for and integrated already during the early design activities. One of our previous studies, for example, looks at health and safety conditions of these maintenance activities and the problems of reaching turbines in harsh weather conditions.
How to best design and engineer off-shore wind farms, however, does not stop here. For example, the design and choice of different possibilities for foundations influences how the marine ecosystem can develop and thrive within the parks. An interesting study of the Thünen institute, for example, showed that cod, a species of fish whose population collapse in recent years, can thrive in between the foundations of the off-shore wind-farms. Of course, how the wind farm foundation is designed can influence the development of the marine ecosystem that can thrive within the park.
Knowing the surroundings before renovating
To design, plan, and execute a building renovation, engineers need to not only understand the building itself, but also need to know quite some about the building’s environment. Knowledge about the environment is already required in the early stages of building condition assessment. For example, to plan drone flights round a building it is important to know whether there are trees of other objects around that would inhibit the drone flight. To evaluate different design options later on in the process with respect to the energy and occupant related performance knowledge about the local weather conditions or objects that might provide shading is required. During the execution one of the most important aspects that need to be accounted for is accessibility.
The above are only a couple of examples of the required knowledge. On our projects, more often than not, this knowledge is not systematically managed using our existing information models. To overcome this problem, in her research within the European BIM-Speed project Maryam Daneshfar explored the knowledge that engineers require to for renovating buildings. She formalized her findings in an ontology that is freely available here and discussed in a preliminary conference paper. I am sure publications about the ontology will soon follow in scientific journals. I will keep you posted.
Automated Text Mining to the Rescue of Knowledge Management
Over the years I have worked with and for a great number of large engineering and design companies operating globally. The secret towards successfully managing these companies evolves largely about strategies to accurately manage knowledge. As my colleague and good friend Amy Javernick-Will wrote, this knowledge can be categorized along two main lines: local market knowledge and global technical engineering knowledge (Javernick-Will and Scott 2010). I feel that most large design and engineering organizations have a good handle on managing the local knowledge by creating decentralized organizational structures and by having an extensive merger and acquisition strategy. However, I also feel that most of the companies I worked for still struggle to a certain extent with managing their global technical expertise. Maybe these struggles are most visible in the efforts to establish central knowledge management systems and trying to convince the majority of the workforce to use this systems to post knowledge, best practice studies, and establish global discussion networks around central technical topics of importance.
The main problem with these traditional platforms is that it requires extra efforts of employees to post, maintain entries, and to discuss. In a business that is still mainly oriented on billing hours to clients this is a difficult problem, as most employees are mainly concerned with selling their valuable work hours. This of course in particular holds for the experienced and knowledgeable people that hardly ever find time to support knowledge management tasks. At the same time, however, the large design and engineering organizations sit on a large gold mine of information that could be leveraged for establishing central knowledge management systems: Reports, Project Reviews, Internal Memos, and all type of other textual data. In recent years many studies have also shown the feasibility of automatically text mining these documents to establish automated knowledge categories, dedicated search engines, and knowledge networks that link important concepts. One of my most notable colleagues in this area is for example Nora El-Gohary that has shown the potential in a myriad of different studies. In some of our recent work we also have shown the potential for renovation projects. Commercially some early start-ups are also trying to leverage this idea, such as, for example the Berlin based Architrave. However, I believe that the true potential to leverage the power of automated text mining lies with the large design and engineering companies. The methods and algorithms exist, however, the key to successful implementations lies with the availability of large textual databases that only exist at these multi-national large scale corporations.
What’s that fuzz about geometry
Looking at the scientific discourse and, partly what we teach our students in engineering one might wonder about the above question a lot. We have very vibrant research and teaching lines in engineering that focus on computational geometry. Also in practice, we often see that the discussion around Building Information Modeling and related standards is to a great extent focusing on geometry (the 3D model as the equivalent of the Building Information Model).
Since quite some time I am wondering whether this focus is still relevant in light of the ever advancing BIM practice. After all BIM based design is parametric by nature, designers choose different building components (walls, doors, windows, roofs) choose parameters of the components (height, width, depth) and the computer automatically generates the geometry of the elements. Moreover, the computer not only generates one geometry, but many different geometric representations. This allows to represent the object in the multiple views (and levels of representational detail) that the software provides.
Considering that modern design practice moves more and more towards parametric design tools, I am wondering whether teaching and science about how to generate complex geometric models should move more and more into the domain of software developers.
Does it really make sense to represent geometry within our interoperable product model exchange formats? Or do we rather need to think better about ways to exchange the logical design parameters and leave it to the software engineers that implement the standards to think about the best way for geometric representation? Do we need geometric model checkers – or can these be replaces by software that can check parameters by large? Will engineers in the future start their design efforts by drawing geometry or will they directly jump into creating parametric networks of design logic and let the computer generate the geometry automatically for them?
Design optimization: Searching for the Impact
Design optimization tools become readily available and easy to use (see for example Karamba or Dynamo. It is not surprising that studies exploring these tools are exploding. Many examples exist that illustrate how to design optimization models and execute optimizations. Often, however, these studies fail to provide the true impact that was expected in terms of improving the (simulated) performance of the engineering design. Showing that the deflection of a structure could be reduce by a centimeter or the material utilization used for the structure was reduced by some percent remains of course an academic exercise that can provide little evidence on the engineering impact of optimization technologies.
As we move forward in this field of research, we need to develop more studies that move away from simply showing the feasibility to apply relatively mature optimization methods towards formalizing optimization problems that matter. Finding such problems is not easy as we cannot truly estimate the outcomes of mathematical optimizations upfront. Whether a specific impact can be achieved can only be determined through experimentation – a long, labor extensive and hard process.
Even worse, identifying relevant optimization problems through a discussion with experts is difficult. The outcomes of each design optimization needs to be compared with the solution an expert designer would have developed using his intuition and a traditional design process. Hence, working with expert designers to identify problems might be tricky. After all they are experts and probably already can come up with pretty good solutions. It seems as one would rather need to identify problems that are less well understood, but still relevant. These problems might also be scarce as relevant problems are of course much more widely researched.
In the end, I think we need to set us up towards a humble and slow approach. An approach that is time consuming, that will require large scale cooperation, and needs to face many set-back in terms of providing an impact that truly matters. Maybe this is also the reason why a disruption of design practice is not yet visible. Until we will be able to truly understand how we can impact design practice with optimization we will still need to rely on human creativity and expertise for some time to come. (not saying that we should stop our efforts.
Engineering Design Tools, UX, and Flow
In psychology flow is the state in which a person performing an activity is fully emersed in the activity feeling an energizing focus, full involvment, and joy. The concept of flow was introduced into psychology by Mihály Csíkszentmihályi a Hungarian Psychologist.
I believe that the concept of flow is also relevant for practicing designers who probably develop their best design ideas within this state. The feeling of being immersed in an activity of quickly sketching, evaluating, discarding or changing ideas is maybe a very accurate description for highly productive , innovative, and creative design (it would be very interesting to hear from you how and whether they experience such flow states during their work).
Looking at the ongoing digitalization of design work with computational design support software, I am wondering whether the user interfaces of these applications are really designed towards getting a user into the flow state. Though I think it is possible to smartly design user interfaces that would seamlessly allow for this. I think we can borrow here from the computer game industry that has designed a number of games that are highly addictive (yes, I started playing Aven Colony yesterday evening and went too bed much too late) that could be considered integrated design tools.
Aven Colony is such an example. The goal of the game is to design a space station that is economically prosperous and provides a happy living space for colonists. Basically an integrated urban planning design support tool with advanced simulation features. The user interface of Aven Colony is highly intuitive, after playing the game for 30-60 minutes its functionality is entirely understood. But of course, it does not stop there … once understood, of course, the flow starts, so it is very easy to forget the time and play all night long … something to be avoided for real design support applications from employee health and safety aspects.
Product Modeling and Product Development Processes (Are we doing this with BIM?)
The design of complex engineering products is characterized by parallel problem solving of large design teams, distributed team work, and complex project management patterns. So the long standing question remains how to support this work with digital technologies and databases that can store the quickly evolving, changing, and complex data over the product development life-cycle.
The digital solutions to support complex process patterns have to support a number of different varying needs with respect to how product information is represented. A good categorization of different representation forms is provided in the seminal paper of Krause et al. that I want to reiterate here:
- Structure-oriented product models that describe the components of an engineering system and that lend themselves well for managing the suppliers, parts, quantities of the engineering product
- Geometry-oriented product models that, well, describe the geometrical shape of the engineering product
- Feature-oriented product models that represent the product in terms of form-features that often can be directly related to different geometries
- Knowledge-based product models that describe the engineering product in terms of an ontology mapping the knowledge that is required during the product development process
All these different ways to represent a product, of course, are required during designing and engineering a complex engineering product. All these different ways also need to be combined and adjusted to the required engineering processes at each stage of the engineering design process. Now quite some of the processes at each stage are also running in parallel (yes: Integrated engineering). So the question is how well we support this with the existing BIM applications in civil engineering design? Again something I would like to post here as food for though for an ongoing discussion.
Robotic Construction Automation and Engineering Knowledge
The worldwide labor shortage, a continuous push towards increasing construction productivity, and the surge in computational power has triggered a new wave of research into construction robotics lately. So far, much of this work has focused on exploring the technical aspects of robotic design in terms of locomotion, sensing, and manipulating technology. Moreover, research into new construction materials, in particular, to allow for additive manufacturing moves prominently into the spotlight of our research activities.
To pave the way forward, I believe that an additional topic for scientific research will be equally important: Formalizing advanced engineering and trade knowledge. Considering that robots need to take over tasks that humans are conducting on construction sites (not only labor related, but also planning related), we need to clearly and explicitly understand the knowledge these humans possess to inform the design of robots. Gaining such an understanding will be important for all aspects of robotic design; for deciding upon robotic hardware in terms of locomotion, sensing, and manipulating and for developing robotic software – from sensor interpretation to path finding. Equally important, formalizing engineering knowledge is required to develop new design methods and materials.
To understand and formalize engineering knowledge for robotic design, research is required: a sound body of research methodologies will need to be developed that is based on design thinking, but also provide the means for sound validation (in the real world and simulation based). We also should review the existing robotic solutions that have been proposed in the past and understand how engineering knowledge has influenced their design in retrospective studies.