Cool Computer Program

This program is from MIT and it's called "Assist Sketch Understanding System and Operation".

Design Simulation Technologies develops, markets, and supports software products used by students, educators, and professionals to learn and teach physics principles and to use these principles to build virtual models of mechanical designs.

MIT Assist Sketch Understanding System and Operation works by sketching a simple mechanical device onto the drawing board and then demonstrating how the system understands the sketch through movement.

Draw objects like ramps, carts, wheels, baskets with springs, then hit run and this program MIT is developing will process physics-based simulations on what you drew. I could spend hours messing with something like this, I need it! Give it to me, MIT!! :-)

Design rationale is often not recorded in mechanical engineering designs because it is not convenient to stop the design process to record every design decision that is made. Designing directly on the computer could assist the process of design rationale capture. At the very least a computer design tool could record all the changes made to a design over its lifetime.

Unfortunately, current computer-based design tools for mechanical engineers are not tailored to early stages of design. Most designers use pencil and paper at first, and input their design into CAD systems only after it is nearly complete. The tradeoff between the ease of drawing and the precision of a CAD tool is too great for engineers who are just sketching out rough designs.

We aim to create a tool that allows the engineer to sketch a mechanical system as she would on paper, and then allows her to interact with the design as a mechanical system, for example by seeing a simulation of her drawing. We have built an early incarnation of such a tool, called ASSIST, which allows a user to sketch simple mechanical systems and see simulations of her drawings in a two-dimensional kinematic simulator.

Even with advanced design tools, the design process typically produces a description of the desired artifact, but leaves little or no indication of the design rationale. We end up knowing what was designed, but often have no idea why it is the way it is, what motivated the particular design, what alternatives were considered and rejected, etc.

Why is this so? We believe one important answer lies in the difficulty of producing rationales and the perception of their worth. Simply put, design rationales appear, especially to designers, to be both uninteresting and more trouble than they are worth. The exciting part is designing the artifact; documentation is a mundane task. Documenting is also a lot of work, and the value in doing it typically accrues to someone else: the designer knows how the artifact works and why, so writing it all down typically provides little personal benefit. It's those who come after who get the benefit, hence the feeling among designers that rationales are more trouble than they are worth.

The irony is that designers are often delighted to describe - to one another at least - the more interesting parts of their design. We just don't know how to make it as much fun to describe those things to a design rationale capture tool.

Numerous attempts have been made to create rationale capture tools; one frequent complaint about them is that they can make the design process more work. The designer now has the additional task of creating the rationale, using a tool that is often seen as getting in the way of the design process.

Our approach to rationale capture is inspired by this set of observations and claims that a successful process must be less trouble than it is worth. The key in turn to making it less trouble is to provide natural interaction with design tools. We want designers to be able to sketch, gesture, and talk with the computer about their work in the same way they would with another designer. Our vision is a design environment with intelligence embedded in the environment, allowing designers to work in familiar ways in familiar media (e.g., whiteboards), yet give those media new and powerful capabilities (e.g., the ability to understand a sketch, ask intelligent questions about a design, etc.).

We believe this in turn offers the possibility of making rationale capture an almost-effortless, almost-incidental byproduct of design.

From: http://rationale.csail.mit.edu/project_assist.shtml

Amit Vartak, 27 is working in wired and wireless security fields since last 3-4 years. His current area of interest includes IEEE 802.11 (Wi-Fi) suite of protocols, vulnerabilities in these protocols and countermeasure for those vulnerabilities. Working on cutting edge tools and technology always keeps him busy. He has contributed from concept level to final prototyping for the presentations in Defcon 2007 (The Emperor Has No Cloak - WEP Cloaking Exposed) and Toorcon 2007 (Caffe latte attack). He holds 2 patents with USPTO (current status: Patent Pending) and a few papers in IEEE journals on wireless protocol vulnerabilities. Prior to this, he was working on MEMS (Micro Electro Mechanical Systems) and has published a few papers in SPIE and ICMAT. (Yeah… kindda orthogonal fields… but technology really doesn’t limit the talent :) He did his masters in Electrical Engineering from one of the premier institutes in India, Indian Institute of Technology, Bombay (IIT-Bombay) and his under graduation, from University of Mumbai in Electronics and Telecommunication Engineering. He is currently working with AirTight Networks Inc. as a team lead in technology group since last 3 years.You can get in touch with him at amitcv[at]gmail[dot]com