SSG Framework

Definition

Dominic Muren:

"The SSG Framework allows a product ... to keep as much of its embodied information as possible. SSG stands for Skin-Skeleton-Guts, and describes the functional separation that occurs between different components of a product." (http://www.humblefacture.com/2010/08/ssg-framework-for-more-sustainable.html)

Description

Dominic Muren:

"The main functionality of SSG devices is provided by the guts. These guts might contain electronic modules, motors, sensors, screens, or batteries. Each functional aspect of the device - the power, processing, and display, for example - are separated into interchangeable, reprogrammable modules. The image above shows a cellphone prototype mock-up built around the SSG framework. This phone has a number of modular "blades" of electronics, each of which has functional components (a power converter circuit for the battery module, for example), as well as re-programmable control components. This reprogrammability allows the modules to be re-arranged with respect to each other, and to have new functionality loaded onto them via software.

Because these modules can be rearranged, recombined and reprogrammed to create different functional collections, the same guts modules could be re-used in multiple designs - a cellphone and e-reader, for example. The diagram below shows how many of the same guts may be rolled over into a new design for an E-reader. In this case, a new e-ink screen, and larger battery are the only new hardware needed. The remaining functional differences are taken care of by firmware and software alterations to the existing modules." (http://www.humblefacture.com/2010/08/ssg-framework-for-more-sustainable.html)

Discussion

Dominic Muren on Cloud Manfacturing

"Sourceforge is a great example of what a distributed community can accomplish by working on small pieces together.

It was the need to allow local developers to work on small parts that lead to another important innovation: the creation of intercompatible, modular libraries of functions. Unlike interchangeable parts in products, these parts can be recombined into entirely new functional arrangements; imagine plugging parts from 10 different products from Target to form an entirely new product. While modular libraries may have been developed to help coders in giant corporations like Xerox and IBM, their true power has been harnessed by the OSS community. Amature coders might only have expertise in a single area, so being able to borrow functional pieces to shore up the rest of a program makes a massive difference.

The SSG Framework tries to bring some of this same modularity to matter, but with an awareness of the key difference between bits and atoms: Atoms take lots of energy to copy. This makes fabrication hard, or expensive, or both, so analogies of downloading atoms tend to fall apart. Instead, it's better to think of bits as being able to describe the relationships of atoms to one another. The cloud of information describing possible modules and collections of modules is only powerful as long as these modules are easy for lots of people to play around with. Its the difference between giving 1000 kids 1000 LEGO bricks each, or an equal quantity of raw plastic pellets. The first group would be overflowing with ideas. The second group would probably have a couple different kinds of piles. Ease of interaction is key.

...

he hope of Open Hardware needn't stop at filling niche markets. We should aim for a DJ culture for objects. One in which modules need not be re-manufactured every time that someone decides on a new specification. If we pursue this future, consumerism, and the waste associated with it will only accelerate.

Instead, imagine a future where the global cloud of possible modules and modular configurations evolves separately from the material modules themselves. Then, when a manufacturer/user decides which configuration they need most, they can use that digital description to inform the collection of modules and software on those modules which will come together to form a product. The manufacturer need not understand all the parts of their design, just as the DJ doesn't need to know how to play every instrument in her box of 45s.

In a future with cloud manufacturing, waste, if not irrelevant, at least becomes much more open to interpretation. Imagine a student getting ready to start high school. They want a desk -- a digital device which will allow them to work on digital files, watch movies, edit emails, and do homework. Rather than saving money at a job to buy this device and add it to their growing collection of things, the child gathers the toys they no longer want, and sets off to the local electronics shop. At the store, the clerk scans each toy, which builds a virtual inventory of modules available from within them. The clerk then brings up a listing of possible desk configurations which may be built using these modules, or with some few additional pieces. Once the child selects a device specification, the clerk dissociates the devices into modules, updates their firmware appropriately, and re-assembles them into the new device. The child pays them for the service, and might get a discount for selling back any unused modules -- some other customer will find the used parts a bargain.

With cloud manufacturing, manufacturers all have access to the same specifications (owing to their open design) so competitive advantage must be gained through better customer service (transparency, shared values, etc), more appealing build materials (possibly locally sourced, or materially rare), and aptitude at finding good matches between products and users. These are all things which current manufacturing has trouble with.

The most exciting part about a world with cloud manufacturing is that the scene above didn't have to happen in any one place. It could be in Brooklyn, just as easily as Detroit, and Dubai as easily as a slum outside of Delhi. The particulars of the interaction -- cost, possible materials, possible specifications, and desirable devices -- will change drastically from place to place. And they should. But they will change based on what is locally appropriate, not what is globally economical.

This is the difference between an industrial revolution, and a cloud: A revolution always has a general, an army, and someone who is conquered. Even if they are each very small, and very many. A cloud, on the other hand, cannot be contained. It cannot be formed to fit some larger intention. And everyone can have access to it, depending on the ability of their local systems to use it. Matter will never make up the cloud. Matter deserves local decision. But information wants to evaporate from open source projects." (http://www.humblefacture.com/2010/09/djs-cloud-manufacturing-and-need-for.html)