Continued from Part 1
So, without further pontification, let me introduce you to the project I used to call Starshine, but that I now call Davinci (with no small amount of irony). Davinci is a family of four programs designed to work in close conjunction with each other: Scrawl, Workshop, Notion, and Plaza. Scrawl is a CAD/CAE solution designed to allow contributors to design and modify individual pieces easily and efficiently while remaining faithful to the requirements of the larger project. Workshop is a high-level assembly interface for connecting together designs made with Scrawl into larger, more complex projects. Notion is a modular simulation framework which is utilized by Scrawl and Workshop to simulate a wide range of behaviors and conditions. Finally, Plaza is a online versioning system akin to a SVN but custom built for organizing and storing large Davinci projects. Together they form a tight ecosystem of functionality that allows widespread collaboration. Allow me to describe each system with a bit more detail.
Scrawl's main functionality is fine-level design of individual parts within a larger project. Like most CAD/CAE programs, it would allow for both schematic and parametric (perspective) views of a design, the ability to define the solid geometry of the design, and define the physical properties of parts. To facilitate flexibility, Scrawl would allow the import and export of geometry from other programs outside of Davinci, a feature also shared by many CAD/CAE programs. However, Scrawl would allow for all of this within the context of the larger design. Should such limitations exist, the interface will show the physical space constraints, connection points, and other relevant data in relation to the design. The design can be tested by Notion, which will in turn create a metadata file, including the performance of the piece for use by Workshop. The files Scrawl will save out will be rich in metadata, including physical properties as well as the creator's name and the intellectual property license under which the creator wishes the work to be shared.
By itself Scrawl is nothing particularly special. Its true potential comes from its tight integration with Workshop, which allows for the assembly of higher-order designs. Workshop is all about applying a object-oriented approach to the design of multi-part inventions. Users can load Scrawl files and even other Workshop files into a single assembly environment. From the interface, users can combine these sub-components together much in the same manner LEGO piece can be pieced together. The user can define the level of binding between individual pieces, approximating bolts, welds, or greased joints. The user can inspect the metadata of each individual piece, as well as open it, either opening its respective Scrawl file or its Workshop file. This power to include other Workshop files, I feel, is a must. It is the equivalent of the #include command I mentioned earlier, as it allows for development of sub-components independent of the larger project. However, simply assembling these higher order designs is somewhat constrained in utility without the ability to test the system as a whole. This is where Notion comes into play.
Rather than be a monolithic simulation program such as those used by most CAD/CAE systems, Notion is far more akin to a rendering engine framework such as those found in professional 3D animation packages. The key thought behind this is flexibility. Different users will want to test for different things, and different projects will necessitate very different kinds of tests. For example, the designer of a airplane may not care much about simulated crowd-flow within a structure, but it is a essential consideration for the designer of a subway station. Conversely, the designer of a subway station probably cares little about hydrodynamic flow, whereas it is absolutely crucial for a airplane's design. This is a simplistic example, but the point is that forcing a single set of simulation tools not only limiting to users, it also limits the applications of Davinci. Notion would act as the ambassador between simulation engine modules and Scrawl/Workshop. A user looking to test a design would select the elements to test in either Scrawl or Workshop, and then specify the test and simulation engine to use. Notion would then glean the needed data/metadata from the selected elements and feed the information to the simulation engine. The output from the engine would be fed back through Notion and displayed within the interface of the originating program. Notion's functionality would not stop there however. For Workshop files, Notion would allow for multi-level simulation. This would allow for tests to be performed not just on static proxies of sub-components, but on a level of to-the-part accuracy. While far more computationally expensive, it would allow for the capturing of “gotcha” mistakes, such as a unintended weight shifts due to a sub-components movement or a unexpected loss in performance due to cross-component heat pollution. The aim of such functionality is to come as close as possible to a fully realistic virtual prototype. While perfection of such a prototype is probably out of the reach of any system in the near future, something close could be attainable.
With all these components and simulations creating piles of data and metadata, some sort of organizational system would be critical for any serious collaboration. This is where Plaza becomes crucial. Plaza would be a server platform consisting of several different services. The most critical service would be a specially-designed SVN system would intuitively and securely archive the data generated by the innovation process. A second service in Plaza would allow it to act as a abstracted simulation module for Notion. This service would allow for Notion to leverage large clusters of connected servers for especially complex simulations. To facilitate real-time collaboration on a single file, a service based on the Uni-Verse code-base would also run on Plaza. This would allow multiple contributors to collaboratively work on a unified design simultaneously, a important feature for when designs get above a certain level of complexity. One final service would be a API allowing third-party applications to securely access the data stored in the repositories. This will allow developers to expand upon the family of applications that can leverage Davinci. Such applications might include statistical comparison software for comparing the technical merits of different design variations, or a virtual reality walk-through of designs. The possibilities are endless, which is why creating a robust and flexible API would be so crucial.
I think I've rambled enough on this system for now. This was meant to be first and foremost a conversation starter, so I look forward to you thoughts. I most certainly lack much of the technical expertise it would require to build such a system, which is why I would very much like to see such a system developed as open source. There's something poetic about open source being the key to the creation of open source hardware. In short, if this has sparked a interest in you, feel free to adopt the concept and dive into fleshing this out.
0 comments:
Post a Comment