Published 11 March 2010
Posted by Al Dean
Image courtesy of the Lego Group.
Granularity. There’s a word I love. It just sounds nice and rolls off the tongue nicely, even with my dodgy mid-british accent - unlike ‘caramel machiato’ which sounds horrendous and causes American baristas to look at me in the same manner people look at dogs when they’re trying to tell them something - a look that says “Ummm… What?”. Now, where was i? Oh yes.
According to the source of all mildly accurate information, Wikipedia, Granularity is defined as:
...the extent to which a system is broken down into small parts, either the system itself or its description or observation. It is the extent to which a larger entity is subdivided.
Now. Why am I talking about this? The reason is that this is something I believe it’s going to become increasingly important to designer users as we progress through this century. Let me explain.
At present, when you look at the vast majority of tools we use to define a product, the data we store and the information we manage is quite basic. Most 3D CAD systems, while being granular in terms of feature-based descriptions, sketch entities and such, when it comes to management, we store parts, assemblies, sub-assemblies (and of course, subsequent to that, drawings). More advanced systems allow you to store and manage user defined feature sets and other such sub-part level information, but a collection of features is about as small as it gets.
This, I believe, will change. Why? Ok. Let’s do that.
There are two things that might influence this and push us into further levels of explicit detail and granularity. The first is the ‘cloud’ (yes, I broke my own rules). When you’re working on a system that’s remotely located on a server, whether that’s over your internal network or across the wider web, you’ll need to manage and exchange finite packets of information, features, sketch entities and such. the rise of collaborative working systems, such as Catia V6, will mean that users are working on the same data, in parallel, at the same time. If not at the same time, there will be times when design changes, down to feature and maybe sub-feature level, will need to be managed and rationalised. To do that, you need to manage and keep track of those individual parcels of data and oackets of change. That’s going to require a level of granularity that’s way beyond what most data management systems are currently capable of. I’m aware that some executives of their competition might disagree, but this is why Dassault acquired MatrixOne on a technical level. It has the ability to manage and control very large amounts of data, much more than Dassault’s existing data management products.
The other area is when you start to look at how the shift towards green is starting to effect how we design products and the technology that’s under development to allow us to gauge the environmental and legal impact of design choices as we work. Today, there are numerous vendors working in this field and its split into two camps. One is compliance led. The other is sustainability. The two fields are related, but quite often independent.
Sustainability often refers to the impact on the environment of not only the manufacture of a product, but the lifecycle surrounding it, from raw material extraction, material processing, production, logistics etc. It’s the warm fuzzy end of the green spectrum, but with real world impact potential. It’s a very early stage field with huge potential and we’ll be looking at what’s out there shortly.
Compliance on the other hand, is the cold hard end of the spectrum. Compliance relates to legal requirements, whether through regional, national or international, of what materials are in your products. This is about ensure that you can take your products in specific regions and areas and not have the wrath of the authorities (or indeed, Greenpeace) breathing down your neck, getting you fined and your product removed from the market. This is perhaps the area that granularity might effect the most. To carry out compliance auditing, you need the most granular level of information about your product - down to the CAS registry number level. Yes. We’re talking chemical element level. That, my friends is granularity of the highest order (or is that lowest order?).
Take these two figures as an example.
This shows a basic multi-level assembly. There’s three subassemblies, those sub-assemblies are then comprised of either parts or further sub-assemblies - down to five levels. There are three major sub-systems and in total, seven parts and 13 data records. Not a very complex part - whatsoever.
Now, this shows a new version of the same assembly. Remember, just a five level product structure, seven parts, but when you start to drive the requirement to discover compliance data, the order of magnitude of the data you’re looking at expands rapidly. Again, this is a very simplistic example, but you can see that that 17 data records very quickly becomes nearly 40 records, purely by tracking material within those data records, but also to the CAS Number level.
Now. Consider what would happen when you start to work on today’s products, in a highly collaborative environment, where data is being passed globally, between teams, between languages, between professional disciplines. And you still need to track data down to this type of level. And when you’re working on a product that looks like this:
X-Ray image courtesy of Samsung.
There you go. Granularity. It’s here to stay. Mark my words. And we’re going to need a new breed of data management system to handle this if all these processes and tasks are to be rationalised as part of the product development process.