Title: Limits Of Modularity: The Spreading Error Effect
Made For: Self
I had an interesting discussion with Julian Ariza Alvarez on modularity today. Julian is an engineer and quality control researcher at Technical University 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: Almost certainly after 2 years of use the cars broke down. It turns out: 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 some areas (not 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”.
Meta: Post is part of Mifacori’s research project on modularity
from facebook discussion about the article:
This is where we should look back to software engineering for inspiration.
I write code. Modularity is key to scaling, separation of concerns, isolating faults within an area of responsibility, reusability, and keeping elements small enough that they fit in human working memory to cope with complexity.
# unit testing
What this means in software is you have to have known, explicit interfaces between elements and that any and all properties exposed to other elements are known, and their behaviour is testable independently of all other parts of the system.
This concept is known as unit testing.
In order for the tests to be ecologically valid, it’s usually necessary for and parts a unit depends on to be simulated/mocked. These mocks of other units feed back expected behaviour of other units to give
In mechanical engineering, all exposed properties may not be as oobvious as they are in code. If a class in code has a property called “vibration” whose intensity varies randomly and which in turn affects other properties, we can design the code to encapsulate that property (keeping it internal & invisible to connected components), so it has no effect on the other units in the system.
In mechanical engineering (particularly where design is completely manual – no material simulations etc.), one might not even predict that a completed will produce a vibration, let alone be able to engineer in dampening to encapsulate the vibration property (+ material properties & dimensions may require additional component units & space to dampen a vibration/prevent resonance etc.).
That’s why think material simulations are needed especially if you’re looking to democratise at the same time as you modularise – expertise in vehicle design, material properties, metal fatigue etc. are still needed if you’re modular (*). Having material simulations enables inexperienced designers to get their basic designs up to scratch, and provides a safety net for experienced designers to help predict unexpected properties (like the exhaust/engine combo in the article) ahead of time, and isolate as many properties as possible within each unit.
Once properties are well understood, we can unit test each module (and design iteration of each module) during development, and integration test module designs to see that the real module actually behaves like the mocked versions used during unit testing.
NOTE: isolating responsibility *will* image the architecture, so there may be some oddities/more overall weight/compexity etc. that are thrown up. In software, we just add another abstraction layer to hide the complexity, but on a physical level, that *could* make the system unusable, which I think will need a large number of iterations to optimise down to something useable.
I’ve long dreamt of a “build system” for mechanical parts, ultimately producing a library of parts that are defined by their exposed properties/interfaces. The scope of computer-driven optimisation of manufacture and part combinations just seems staggering to me. The tool I’ve seen with the most potential to enable this so far is Wolfram Mathematica. It doesn’t do all of what’s required, and it’s aimed at mathematicians, rather than engineers, designers and architects (or even most software rec’d), but something along those lines would enable a mechanical open source ecosystem, with development & testing tools rivaling what we now have for software.
If one person starts building this, well be waiting 30 years. If we can get a group together with a common vision – who knows. We might have a very basic version out in months, with a broader, more capable system in a couple of years.
(*) Though once a module is out there, it can be reused, so long as all exposed properties are well understood.
Comments are closed.