Contract-First Manufacturing

From Open Source Ecology
Jump to: navigation, search

Before we build anything, we define the interface of that part to everything else.

From Microtrac Google Group:

"I'm writing this email in an effort to help the group understand contract driven design (CDD for short). I'll try to keep it brief, but will try to error on the side of having too much detail rather than leaving confusion. That said, please ask question or make comments or disagree. I'm not an authority on this-- just a software engineer that tries to use these ideas to make good software.

Okay, so the basic idea behind CDD is to identify the jobs that each module does and how the modules relate without identifying how they achieve their goal. This is a very important point. When talking about interfaces between modules, you avoid talking about how the module does its job. Why does this matter? It means that any module that achieves the goals of the interface can be used on the machine.

For this discussion, I'm going to use the Chassis and Drive Module as examples. If we get the interface between these two modules correct, then all sorts of drive modules could be used on MicroTrac. This is key! It means that FeF can attach a Tracked Drive Module to MicroTrac, and another user (like me) could attach a wheeled, no-skid drive module to MicroTrac and the machine will still work!

Here is an example of bad interface design. Hopefully they will help you understand why it's important to focus on the interface (rather than finding one set of modules that work together without thinking about how they relate.) A poor interface design would require that the loader arms mount to the tracks system in order to have the required stability. Why is this bad? It means that in order to use the loader arms, you've have to have Tracks! I would have to modify the loader arms in order to have them on my wheeled MicroTrac.

A major idea in CDD is 'separation of concerns'. This means that one module doesn't have to worry about how another module does its job. The Power Cube is a great example of this idea in motion. Any system that has a Power Cube doesn't worry about where the energy comes from. It just assumes that Hydraulic energy enters the system as needed. This means that we can easily and safely change many aspects of the Power Cube. We could switch it to steam power. We could add a bigger engine, we could add electronic starting and monitoring.

What can't we change on the Power Cube? We can't change the interface! Everything else is up for grabs. What is the interface of the Power Cube (note that it's not especially well documented right now)? It has a certain size (about 2'x2'x2'). Changing the size is against the rules of the interface (ie. contract). You can't change the size of the hydraulic return hose or the outlet hose. You can't make it so the Power Cube relies on an external component for it's strength and stability. So, it turns out there are a lot of things you can't change, but you still have a lot of opportunity to improve and change the Power Cube without having to change any other part of any GVCS maching.

As a counter example, think about a modern car. What parts of the engine system can you change without having to worry about systematic effects? Not very many. Modern cars are highly engineered systems where an all sorts of things depend on each other in unexpected ways. There are benefits to such a design paradigm. One major drawback is that every new car requires that the engine system be re-engineered. This makes design and development of cars very expensive. The GVCS doesn't waste it's time on that. We've got an contract between the engine system and any machine that it drives. If you make a new machine that respects that contract, then it will just work.

So when thinking about the contract for a module it often helps me to think about what a thing needs and what it provides. What does the drive module need? It needs a secure mounting point. It needs a certain amount of clear space in which to exist. Some of that clear space must be between the mounting point and that ground. We need energy input (see adapters below).

What does the drive system provide? It applies torque to the earth =). Okay, a little too general. It moves the thing that it is attached to by pushing on the earth. It is somewhat insensitive to the terrain that it traverses (soft or hard, hill or flat). At the risk of getting too abstract, you can think of there being a contract between the drive module and the earth. If the earth conforms to that contract, then the drive module will work. A souped up Jeep can handle a lot more kinds of earth (has a less strict contract) than a Ferrari does. But a Ferrari does the torque part of the contract exceptionally well.

Interestingly, this helps explain why a track design won't work on my MicroTrac. The contract I want my drive system to have with the earth isn't satisfied by skid steering. So that module won't work. If we do things right though, I'll be able to reuse all of MicroTrac, and just change out the drive module. In order to do this though, I have to know how my wheeled system will interface with MicroTrac. What is the contract?

So with that I'll leave you. I hope that you've found this helpful.