‚Fehler-Ausstrahlungs-Effekt‘ bei Modularität / ‚Error-Spreading-Effect‘ in Modularity

Two Mirrors of Blogposts about Modularity I wrote for the Mifactori Blog

[1] The ’Fehler-Ausstrahlungs-Effekt’ / ‘Error-Spreading-Effects’ in Modularity

(Meta: Post is part of Mifacori’s research project on modularity)

–

I had a fascinating (at least for me) discussion with Julian Ariza Alvarez on modularity today. Julian is an engineer and quality control researcher at TU-Berlin. He was once part of a large research project involving a car company. The idea of the project was to have cars build entirely with modular parts – hundreds of exchangeable parts – so you can customize and evolve more quickly. But when testing the system something strange occurred: When you combine a large number of different modular parts you get an even larger number of potential points of failures.

For example when they combined an exhaust pipe with a connector with a motor after less than two years the motor broke down. Because there was something in the connection that attacked the motor slowly but progressively. And stuff like that happened in other combinations too.

Of course! If you build one product – one car – you chose one motor, one exhaust pipe and one connector. You monitor and debug the connection, meaning you optimize the parts step by step till everything works in this particular combination. But if you have exchangeable building blocks the number of tests and optimizations you have to make explodes. 3 exhaust pipes and 3 motors and 3 connectors make already 27 combinations and test cases (instead of 3)! And when you test combination number 3 and discover that you have to change a part you have to do the first 2 tests again. And a car has many more parts that all play together. So the number of potential tests to make comes close to infinity. You might end up with a close to infinite number of points of failure.

Julian called this: “Fehler-Ausstrahlungs-Effekt” which is german and beautiful and might be translated with: “Spreading-Error-Effect”.

Here is OSVehicle’s “modularity” video that triggered the discussion.

–

The car is not the only example he told me about. He also spoke about a machine “to make everything” where you have just exchangeable heads/bits – a driller, a saw and so on. But every time with every new bit on top there are entirely different forces in the machine at work. Normally you would optimize the connector between the bit and the rest of the machine for this specific forces. But if the connector and the machine is modular and for every bit the same there is no optimization! The result is a machine that breaks much faster.

–

I think this is a serious issue for modularity. At least for a number of areas (not necessarily for furniture I guess).

–

I met Julian in the context of a research project that is about creating tools for collaborative open source hardware development. For open source hardware modularity and the use of standard parts is very important. Because if a software is open source I can download and install it in 5 minutes and start using it. If a tractor is open source I can download the building plan but I still have to build the whole tractor! I have to get all the parts and assemble the tractor with them. It is important to use commonly available parts and structures in the design to make it easier to get the necessary parts and build the tractor everywhere. Modularity is a big enabler of decentralized open hardware development, production and use.

So one of the obvious ideas we had was that the tool for collaborative open source hardware development could collect errors – errors occurring when developing modular designs.  And make them available as direct feedback for the designers when they create something. Every time someone plans something that is known to fail the software sends a warning. And designers teach the software by letting them know about points if failure. An open accessible, crowd created and intelligent database of errors. A huge, decentralized learning and development process for designing modularity.

This would actually be a really useful tool or feature in the tool.

Publish stuff that did not work! Publish studies that found nothing! This has always been a demand of the open science community! With the internet we have enough space to make also negative results available. And we should. To prevent people from making the same mistakes over and over again and enable us to learn faster and achieve more complex goals.

It could allow us to tackle and contain the “Fehler-Austrahlungs-Effekt” – the “Spreading-Error-Effect”.

–

AND HERE IS ANOTHER POST ON MODULARITY AND CIRCULARITY FROM THE MIFACTORI BLOG. ENJOY:

–

 

[2] Modular design and construction is too time consuming ?

(Meta: This blogpost is part of Mifacotri’s research project on modularity)

Exactly today a year agoI published a post in my blog about prototyping with circular materials and modular parts saying that it should be much cheaper in most cases, because you can reuse parts and materials from older prototypes for newer ones and don’t have to buy new parts and materials for every iteration.

That was true for the Lego Brick and I experience this again when developing the Hiebo Lamps that are also completely made from modular and circular parts.

      

Lego Brick and Hiebo 2 of the HIEBO SERIES

–

But when doing the lamps I experiences something else that is more a downside of that appraoch when it comes to resources: Prototyping with modular parts took a lot more time!

The Hiebo series starts with the premise to only use standard parts available in every common DIY market and leave the parts intact – deal with them as they are. Starting from that the goal is to find a lamp that is beautiful.

The problem is now that there are a lot of different standard screws and parts available. And this means that there is an incredible high number of possible combinations. I searched for a long time for a good shape and went through an incredible amount of iterations. I tested and created a lot of ideas and came closer and closer to an at least somehow good looking lamp. This was very time consuming.

The usual way to design a lamp nowadays would probably be to use some kind of 3d/vector software – to model the lamp. You start with a basic idea and than push and pull dots and lines till you have the shape you like. Every change is just a click away. And everything is possible. And once you are done you decide about materials and send it to a factory.

This is quicker. Especially compared to test a lot of different combinations of modular parts where you have to deal with what is already there and how does it look and behave, and doing it by hand.

A General Problem With Modularity?

This can be true for other cases as well. Jenni told me that she was experiencing something similar with this years OSCEdays design that she created. For this year we had come up with the idea to reflect modularity also in the graphic-design. Amongst other things it is supposed to help local organizers to adapt the design and build on it for their local communication.

So Jenni took a square and cutted it into pieces – the pieces are now a fixed set of building bricks for all other designs.

                 

Images by Ottilie, CC-BY-SA

–

Jenni created a whole construction kit explaining it available to download from our public design folder.

The interesting thing for our post here is that she told me on the phone that this technique takes sooooo much time! More then usual. Of course! Usually when Jenni creates a design and there is a shape she does not like she just changes the angle a bit and is done. Now she has to play with the modular parts and test different combinations and see which one comes closest to the shape she likes.

So I wonder, is this a general rule for modular design?

Let’s solve it!

I think it will be probably true for some maybe even for many cases.

But I think there are good ways to overcome the time problem.

(1) Open Source helps: When playing with my modular parts I learned a lot of things and discovered some good tricks and combinations. And of course I make them open. So others can be quicker. I am sure others discovered the same tricks before. But I could not find them where I would search for them – in the web. But this is something we can change and with growing open source hardware platforms will change.

(2) Software-Tools: And of course can we have intelligent software to help to test and discover all kinds of combinations with existing modular parts. In many areas something like this exists already. For example I recently learned about Brickify – they have a software where you can throw in a 3d model and the software will generate a plan for you how to build this structure with Lego bricks.

Sounds like a plan for a far future of Mifactori :-).

–––

So much for today on modularity. This post started with a downside of modularity and ended with an upturn. I have another post already in the pipe that will have mostly downsides of modularity. But I think it is the most interesting so far – with insights from real engineers…