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.
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.
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?
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.
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.
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.
While preparing for our new module ‘Circular economy for the Built Environment: Principles, Practices and Methods’ I was reading three papers today in an effort to select some required readings for our students.
I then read chapter 18 ‘Products & Services’ from Lacy et al.’s book ‘The Circular Economy Handbook’. This chapter discussed possibilities to improve products during all stages of the product life-cycle from design, to use, to use extension, to end of use. I liked the inclusion of ‘use extension’ as a separate phase in the product life-cycle, certainly something we should do much more explicit. The chapter also again stressed the need for good business models, as well as, developing a sound understanding of the product portfolio of a company.
Finally I read Bocken et al. (2016) ‘Product design and business model strategies for a circular economy’. I truly enjoyed reading the paper as it introduced a strong framework about how to design products for slowing down the resource loop and for closing the resource loop. I thought these two goals are quite helpful concepts to think along when designing products. To slow loops, the authors suggest to design for attachment and trust, reliability and durability, ease of maintenance and repair, upgradability and adaptability, standardization and compatibility, as well as, dis- and reassembly. This reminded me at the classical idea of ‘ilities’ from de Weck. To close resource loops the authors suggested to design for a technological cycle that allows to reuse technical materials and sub-products, as well as, for a biological cycle. I found this again a powerful guide for designing products.
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.