Manufacturing guy-at-large.

Filtering by Tag: data

Tags

Added on by Spencer Wright.

STEP files

Added on by Spencer Wright.

From Step Tools, Inc.'s excellent overview of STEP purpose, applications and development (emphasis mine):

The ultimate goal is for STEP to cover the entire life cycle, from conceptual design to final disposal, for all kinds of products. However, it will be a number of years before this goal is reached. The most tangible advantage of STEP to users today is the ability to exchange design data as solid models and assemblies of solid models. Other data exchange standards, such as the newer versions of IGES, also support the exchange of solid models, but less well.

But later, in the "Future of STEP" section: 

The real issue that stops faster STEP deployment is the commitment of those with the resources necessary to define the standards. The government does not like to pick solutions for industry, and industry does not like to fund the development of solutions that can also be used by their competitors. Consequently, much work only gets funded in situations of clear and desperate need such as when the high cost of manufacturing is causing excessive job losses.
The Internet and the World Wide Web broke through this cycle when "killer" applications made the benefits of the new infrastructure clear and compelling for all users. AP-203 made STEP useful by allowing solid models to be exchanged between design systems. AP-238 will make STEP compelling for some users by allowing them to machine parts more efficiently. However, like the early Internet there will be alternatives that are considered more reliable by other users. The killer application that makes STEP ubiquitous has yet to be identified.  

There's a lot of good info on STEP buried in obscure corners of the web. I hope to be summarizing some of my research on the topic soon. 

Faceted Classification

Added on by Spencer Wright.

From Wikipedia, emphasis mine: 

A faceted classification system allows the assignment of an object to multiple characteristics (attributes), enabling the classification to be ordered in multiple ways, rather than in a single, predetermined, taxonomic order. A facet comprises "clearly defined, mutually exclusive, and collectively exhaustive aspects, properties or characteristics of a class or specific subject". For example, a collection of books might be classified using an author facet, a subject facet, a date facet, etc.
Faceted classification is used in faceted search systems that enable a user to navigate information along multiple paths corresponding to different orderings of the facets. This contrasts with traditional taxonomies in which the hierarchy of categories is fixed and unchanging.

Back in the Napster days, I spent a not insignificant amount of time renaming song files and placing them in a hierarchical file system. Each track was named in the following format:

"#{artist_name} -  #{album_name} - #{track_number} - #{track_name}.mp3"

And my directory structure looked like this: 

 

  • Music
    • #{artist_name_1}
      • #{album_name_1}
      • #{album_name_2}
    • #{artist_name_2}
      • #{album_name_1}
    • #{artist_name_3}
      • #{album_name_1}
      • #{album_name_2}
      • #{album_name_3}
    • etc.

With individual track files living inside each album directory. 

At the time, I was running Linux on my home PC and spent a lot of time navigating file structures in a shell. Having my music organized hierarchically was useful there, and I spent a bit of effort maintaining the system, even going so far as to write a shell script that would automate the creation of file structures for unclassified files.

Today, my habits have held over even while technology has changed. I still think of my media collection in terms of files (so old fashioned, I know) , and I keep iTunes in the "column browser" view. It works, but it's antiquated; were I more modern, I'd stream media exclusively and would search a cloud library for tags (created through folksonomy), not browse by static, predetermined layers of organization. When I was running Linux that wasn't an option, and my hierarchical organization was my easiest and most effective way of sorting songs. Now, that advantage is slipping away in the music industry, as social and cloud-based streaming services become more and more intelligent about how they thing about the qualities of a song or artist.

In other facets of my life, hierarchical organization gets closer and closer to obsolescence. When managing 3D assembly models, I find it tricky to establish naming sequences that will make sense across projects and phases of development. I tend towards part names that begin with two letters and end with four numbers. In a given filename, I follow the part name with a short verbal description. The end result looks like this:

"BK1008 Rack End.ipt"

Here, the file extension is .ipt, which is the Autodesk Inventor extension for part files. This particular part is one I designed for custom bike racks, and the prefix "BK" refers to bikes. The part lives in a directory called "BK Bike Parts", along with a bunch of other - related and unrelated - parts. Parts are categorized in directories according to the purpose they're originally designed for, but they're often repurposed or discarded. Their part numbers are just placeholders, and the descriptive titles I give them are often mostly meaningless. Often times, one designs a part with a particular form in mind and names it accordingly. Over time, that form changes, and in the end the name is nothing but a vestige. It's a kind of a Theseus' Paradox, and one that conventional naming schemes - or mine, anyway - don't account for well.

I'm happy to say that I have no idea what my files naming sequences will look like in five years. Jordan Brandt, Technology Futurist at Autodesk, predicts the death of files in a way that strikes me as totally prescient here. I'm not totally clear on the implications, but he describes a world in which part metadata is stored at attribute tags, much like Facebook photo tagging. Such a system would, I presume, at least initially require the user to set up searchable tags in order to enable reliable part retrieval. Eventually I'd hope that attributes could be generated predictively, much like Facebook scans photos for faces and auto-suggests likely matches for who to tag. 

At this point, my file naming conventions would become irrelevant. Brandt puts it very well - I *never* need to look in a particular folder, or for a particular filename, when I want to find a photo on Facebook. It's tagged with all the relevant data, and with adequate search tools it'll never be hard to find.  Eventually I expect the same to be the case for the little gadgets I'm designing: their identities becomes more and more tied to their actual attributes, rather than some arbitrary and cumbersome naming sequence.

More Kahneman

Added on by Spencer Wright.
A disturbing demonstration of depletion effects in judgment was recently reported in the Proceedings of the National Academy of Sciences. The unwitting participants in the study were eight parole judges in Israel. They spend entire days reviewing applications for parole. The cases are presented in random order, and the judges spend little time on each one, an average of 6 minutes. (The default decision is denial of parole; only 35% of requests are approved. The exact time of each decision is recorded, and the times of the judges’ three food breaks – morning break, lunch, and afternoon break – during the day are recorded as well.) The authors of the study plotted the proportion of approved requests against the time since the last food break. The proportion spikes after each meal, when about 65% of request are granted. During the two hours or so until the judges’ next feeding, the approval rate drops steadily, to about zero just before the meal. As you might expect, this is an unwelcome result and the authors carefully checked many alternative explanations. The best possible account of the data provides bad news: tired and hungry judges tend to fall back on the easier default position of denying requests for parole. Both fatigue and hunger probably play a role.

Daniel Kahneman, Thinking, Fast and Slow; emphasis mine.

The Character of Prediction Errors

Added on by Spencer Wright.

Nassim Nicholas Taleb, The Black Swan, pp.159-160. 

Like many biological variables, life expectancy is from Mediocristan, that is, it is subjected to mild randomness.  It is not scalable, since the older we get, the less likely we are to live.  In a developed country a newborn female is expected to die at around 79, according to insurance tables.  When she reaches her 79th birthday, her life expectancy, assuming that she is in typical health, is another 10 years.  At the age of 90, she should have another 4.7 years to go.  At the age of 100, 2.5 years.  At the age of 119, if she miraculously lives that long, she should have about nine months left.  As she lives beyond the expected date of death, the number of additional years to go decreases.  This illustrates the major property of random variables related to the bell curve.  The conditional expectation of additional life drops as a person gets older.
With human projects and ventures we have another story.  These are often scalable...With scalable variables, the ones from Extremistan, you will witness the exact opposite effect.  Let's say a project is expected to terminate in 79 days, the same expectation in days as the newborn female has in years.  On the 79th day, if the project is not finished, it will be expected to take another 25 days to complete.  But on the 90th day, if the project is still not completed, it should have about 58 days to go.  On the 100th, it should have 89 days to go.  On the 119th, it should have an extra 149 days.  On day 600, if the project is not done, you will be expected to need an extra 1,590 days.  As you see, the longer you wait, the longer you will be expected to wait.
Let's say you are a refugee waiting for the return to your homeland.  Each day that passes you are getting farther from, not closer to, the day of triumphal return.  The same applies to the completion date of your next opera house.  If it was expected to take two years, and three years later you are asking questions, do not expect the project to be completed any time soon.  If wars last on average six months, and your conflict has been going on for two years, expect another few years of problems.

I enjoy Taleb's writing, but I often find his citations opaque. AFAICT, this is the only citation for the passage above:

If anyone can explain exactly what he's saying here, I hope they chime in - but, again, AFAICT, Taleb hasn't actually taken a survey of late projects to determine the numbers he quotes above. Again, I'd love to know if I'm mistaken here, and regardless I find his argument fascinating and compelling.

Name Three

Added on by Spencer Wright.

From Less Wrong, emphasis mine. 

Even with people who've had moderate amounts of exposure to Less Wrong, a fair amount of my helping them think effectively often consists of my saying, "Can you give me a specific example of that?" or "Can you be more concrete?"
A couple of formative childhood readings that taught me to be specific:
"What is meant by the word red?"
"It's a color."
"What's a color?"
"Why, it's a quality things have."
"What's a quality?"
"Say, what are you trying to do, anyway?"
You have pushed him into the clouds.  If, on the other hand, we habitually go down the abstraction ladder to lower levels of abstraction when we are asked the meaning of a word, we are less likely to get lost in verbal mazes; we will tend to "have our feet on the ground" and know what we are talking about.  This habit displays itself in an answer such as this:
"What is meant by the word red?"
"Well, the next time you see some cars stopped at an intersection, look at the traffic light facing them.  Also, you might go to the fire department and see how their trucks are painted."
-- S. I. Hayakawa, Language in Thought and Action
and:
"Beware, demon!" he intoned hollowly.  "I am not without defenses."
"Oh yeah?  Name three."
-- Robert Asprin, Another Fine Myth
And now, no sooner does someone tell me that they want to "facilitate communications between managers and employees" than I say, "Can you give me a concrete example of how you would do that?"  Hayakawa taught me to distinguish the concrete and the abstract; and from that small passage in Asprin, I picked up the dreadful personal habit of calling people's bluffs, often using the specific phrase, "Name three."

 

Post Hoc Perfect

Added on by Spencer Wright.

From  Christopher Chabris' review of Duncan Watts' "Everything is Obvious," emphasis mine.

Common sense is also inclined to conclude that individual successes (and failures) are determined by inherent qualities rather than by unpredictable circumstance. Mr. Watts asks why the "Mona Lisa" is the most admired painting in the world today—why most ­people believe it to possess unique, timeless features that set it apart.
Before the 20th century, the "Mona Lisa" wasn't even the most popular painting in the Louvre. But in 1911 it was stolen, smuggled to Italy and exhibited widely before being returned to France, whereupon Marcel Duchamp defaced a reproduction of it and labeled his work with an obscene pun. The painting rocketed to fame, its pigments and brushstrokes unchanged. The "Mona Lisa" is the artistic equivalent of the investor who did nothing special until he got lucky a few years (or quarters) in a row and was fêted as a genius.

Connections

Added on by Spencer Wright.

From "The Happiness Advantage," quoted (in a great post) by Eric Barker, via Michael Galpert.  

...when MIT researchers spent an entire year following 2,600 employees, observing their social ties, even using mathematical formulas to analyze the size and scope of their address books and buddy lists, they found that the more socially connected the IBM employees were, the better they performed. They could even quantify the difference: On average, every e-mail contact was worth an added $948 in revenue.

Two great thought problems

Added on by Spencer Wright.

The other night I got into a wikipedia hole, prompted by xkcd's excellent "What If?" post "Twitter Timeline Height." Two great finds:

The German Tank Problem

i.e. "the problem of estimating the maximum of a discrete uniform distribution from sampling without replacement." From xkcd:

Allied troops faced a version of this problem in World War II. German tank parts had serial numbers, many of which were sequential (1, 2 ... N). Suppose they captured a random tank. If they determined it was Tank #27, then they can be sure that the Germans had made at least 27 tanks. It also told them there probably weren't millions of tanks; if there were, they would have been unlikely to get a two-digit serial number.

Wikipedia describes the discrepancy, in WWII, between serial number analysis and what traditional intelligence believed about German tank production:

According to conventional Allied intelligence estimates the Germans were producing around 1,400 tanks a month between June 1940 and September 1942. Applying the formula below to the serial numbers of captured German tanks, (both serviceable and destroyed) the number was calculated to be 246 a month. After the war, captured German production figures from the ministry of Albert Speer showed the actual number to be 245. 

In case that's not clear: Spies (who were presumably fooled by counterintelligence) were saying that Germany was producing about 1,400 tanks per month, but serial number analysis said that it was closer to 246. The actual number was 245.  

The Two Envelopes Problem

From Wikipedia:

You have two indistinguishable envelopes that each contain money. One contains twice as much as the other. You may pick one envelope and keep the money it contains. You pick at random, but before you open the envelope, you are offered the chance to take the other envelope instead.
It can be argued that it is to your advantage to swap envelopes by showing that your expected return on swapping exceeds the sum in your envelope. This leads to the paradoxical conclusion that it is beneficial to continue to swap envelopes indefinitely. 
A partial explanation: There's a 50-50 split here - either you've got the smaller envelope or the larger one. Let's say there's $20 in your envelope:  
The probability of either of these scenarios is one half, since there is a 50% chance that I initially happened to select the larger envelope and a 50% chance that I initially happened to select the smaller envelope. The expected value calculation for how much money is in the other envelope would be the amount in the first scenario times the probability of the first scenario plus the amount in the second scenario times the probability of the second scenario, which is $10 * 1/2 + $40 * 1/2. The result of this calculation is that the expected value of money in the other envelope is $25. Since this is greater than my selected envelope, it would appear to my advantage to always switch envelopes.
This is totally weird. There are a few purported solutions on the wikipedia page, most of which elude me.  
The takeaway: I really need to get into some Bayesian probability theory. Stat. 

Seth Bunsen's Coffee experiment

Added on by Spencer Wright.

OMFG this is great! 

Basically, this guy did an informal (but blind, controlled, and apparently statistically serious) experiment to determine which variables affected people's feelings about a cup of coffee. The short of it:

  • People slightly prefer spinning-blade grinders to burr grinders
  • People actually prefer Aeropress coffee to drip brew. 
  • Seth Bunsen is awesome. 

A few takeaways (emphasis mine):

My longest running experiment centers on coffee grinders. A common belief among coffee pundits is that good coffee depends on good grinding. Specifically, coffee ground with a burr grinder purportedly tastes better because it grinds the beans more uniformly and doesn’t over-heat the grounds like traditional blade grinders. The experiment I setup tested this claim by brewing coffee using a burr grinder or a blade grinder and scored which of the two cups subjects preferred...Based on this analysis, subjects did not show a statistically significant preference to coffee brewed from a blade grinder or burr grinder. Therefore, I opted to save a few hundred dollars and not invest in a burr grinder based on these experiments.

And: 

Another variable I was interested in understanding was the impact of different brewing methods on flavor preferences. I wanted to know if house guests preferred coffee brewed via drip-extraction versus coffee brewed with the Aeropress. I setup my experiment as previously described and scored the number of house guest who preferred each brewing method. The objective of this analysis was similar to the burr grinder experiment, but this time I wanted to compare preferences between two different brewing methods...I observed that 15/20 or 75% of subjects preferred coffee from the Aeropress...Thus, there is reason to believe that the Aeropress may, in fact, produce better tasting coffee than drip-extraction.

And: 

I’ve examined other coffee variables using a similar experimental approach and found only a few factors that had any measurable effect on coffee flavor in isolation. For example, variables like bean freshness or bean purveyor has little effect on flavor...Until I obtain convincing evidence that support investing additional money in brewing accouterments, I see little reason to deviate from this system. In the words of Carl Sagan, extra-ordinary claims require extra-ordinary evidence.

This is exactly the kind of study I want to do with wine. I'd also love to expand upon Bunsen's coffee experiments to include Moka pot, French Press, and - why not - Folgers. 

With thanks to Marco Arment for the link.

 

A real wine test

Added on by Spencer Wright.

Hey, look: we're all intelligent people who make careful, considered decisions. And in the interest of maximizing our reward-to-cost ratio, I think that we should inform ourselves as to what really makes us happy.

It's been a number of years since I first heard the Freakonomics on whether expensive wines taste better, and it has informed the way I think about my own tastes in profound ways. But every time I bring it up with people who know wine, the conversation goes nowhere.

I'd like to hold an event. Call it an experiment, call it a party, call it interactive performance art.  We find a venue - probably not a wine bar, but an event space with a liquor license - and all chip in on a big double-blind test. We pre-sell tickets to fund the purchase of a variety of bottles, and have some knowledgeable - and some not-so-knowledgeable - people curate the tasting selection. Then, while most of the crowd mingles, small batches of participants are called forward to have their preferences tested. As the night goes on, we all get to taste, and by the end of the evening we're ready to release results and show what we, as a group, all really like. 

I think it might teach us all a lot about ourselves and the degree to which we really know what we like - and better yet, I think it'll be fun! 

If you agree and live in/can get to NY, fill in your info below and I'll be in touch. 

The effect of total bullshit

Added on by Spencer Wright.

This week I somehow came across the Seminars About Long Term Thinking podcast, and listened to an episode with the psychologist Daniel Kahneman. At one point in the discussion, he mentioned a study by Paul Rozin that investigated the effect that placing a label saying "cyanide" on a bottle had on participants' willingness to drink the contents inside.

The results of the study, copied here from the Journal of Personality and Social Psychology under the title "Operation of the Laws of Sympathetic Magic in Disgust and Other Domains" (emphasis is mine):

Cyanide label-1. In this procedure, we ascertain whether the label "sodium cyanide" imparts its quality to the substance it labels...Subjects returned to their seat at the table and were presented with two brown glass 500ml "chemical" bottles, each about one-quarter filled with a white powder, which was, in fact, sucrose. One had a typed label on it that said "Sucrose (Table sugar)," the other had a typed label that said "Sodium Cyanide" with a red printed "Poison" sticker below it. The experimenter said:
"Here we have two bottles with powder in them. The powder in both bottles is sucrose, that is, table sugar. These are brand new bottles that we just bought. They never had anything in them but sugar. This bottle (on the subjects' left) has a sucrose label that we put on it. It's a brand new label, that was never on any other bottle. This other bottle (on the subjects' right) has a brand new sodium cyanide label on it. This label was never on any other bottle and was never even near cyanide. Remember, sugar is in both bottles."
The experimenter set out two different colored plastic cubs, one in front of each bottle, and poured water from a glass pitcher into both, until they were about half full. Now, using separate, new plastic spoons for each bottle, the experimenter put a half spoonful of powder from the "sugar" bottle into one cup, and stirred it. The spoon was discarded, and the same was done with the sugar in the cyanide bottle, with a new spoon. The subject then rated, on the 200mm line, how much he would like to drink from each of the cups, and stated a preference between the two. The subject was then asked to take a sip of the sugar water from the preferred cup, and subsequently to account for his or her choice.
Cyanide label-2. We thought avoidance of the cyanide-labeled bottle might be motivated by doubts about the real contents of the bottle (though it seems absurd that the experimenter woudl try to poison the subject by offering a poison-labeled bottle). For this reason, in the second sequence, the subject himself labels the bottles. Initially, we performed this second test only for subjects who indicated a substantial preference for the sugar-labeled bottle's contents. The last 20 subjects, however, were run on this procedure independent of their results on the first sequence. The total N for the second procedure was 38; that is, 12 subjects were eliminated on the basis of their performance on the first cyanide test.
Previously used bottles and glasses were taken away, and two similar, empty bottles were brought out. The covers were removed, and sugar from a 5-lb box of locally sold "Domino" sugar (sucrose) was poured into each bottle (to a level of about one-third full). The subject was then given two peel off labels on a piece of paper. On read "Sucrose (table sugar)," the other read "Sodium Cyanide." (Through an error, this cyanide label did not have a red "Poison" sticker affixed to it.) The subject was asked to put one label on each bottle, in any way he wanted. Then, the procedure used for Cyanide Label 1 was repeated (mixing sugar water, rating of both solutions, indicating a preference, and sipping the preferred solution). 
...
The sugar labeled as "Sucrose" was preferred to the sugar labeled as "Sodium Cyanide" by 41 of 50 subjects (p < .001). The mean difference between the cyanide- and sugar-label ratings was -30.58 (p < .001). When asked to explain their choice, the most common responses were reference to the label, and no response. Only 1 subject suggested the possibility that there might be cyanide in the cyanide-labeled bottle. The second cyanide manipulation, in which the subject put the labels on herself, showed a much smaller but still significant effect, with a net difference of 16.5 points between cyanide and sugar.
 

 

Wild.

This reminds me of the anchoring effect, described famously by Tversky and Kahneman in 1974 (nb. I was aware of this study previously - it comes up a lot in the literature on negotiation - but certainly couldn't have told you who the authors were. Before setting out to write this post, Kahneman's name would have meant nothing to me.). From their paper, "Judgment under Uncertainty: Heuristics and Biases" (emphasis is mine):

Insufficient adjustment. In a demonstration of the anchoring effect, subjects were asked to estimate various quantities, stated in percentages (for example, the percentage of African countries in the United Nations). For each quantity, a number between 0 and 100 was determined by spinning a wheel of fortune in the subjects' presence. The subjects were instructed to indicate first whether that number was higher or lower than the value of the quantity, and then to estimate the value of the quantity by moving upward or downward from the given number. Different groups were given different numbers for each quantity, and these arbitrary numbers had a marked effect on estimates. For example, the median estimates of the percentage of African countries in the United Nations were 25 and 45 for groups that received I0 and 65, respectively, as starting points. Payoffs for accuracy did not reduce the anchoring effect. 

Studies like these are totally fascinating to me, and have the effect of reinforcing the skepticism that I am inclined to approach all statements which lack some method of independent verification. I also try to remain aware of the danger of taking self-reported data at face value: In my experience, people (including myself) are notoriously bad at knowing what's going on in their own heads.

For the intrepid among you, there's a bunch of great throwaways on anchoring on its wikipedia page. An excerpt:

Even when the anchor value is obviously random or extreme, it can still contaminate estimates. One experiment asked subjects to estimate the year of Albert Einstein's first visit to the United States. Anchors of 1215 and 1992 contaminated the answers just as much as more sensible anchor years. Other experiments asked subjects if the average temperature in San Francisco is more or less than 558 degrees, or whether there had been more or fewer than 100,025 top ten albums by The Beatles. These deliberately absurd anchors still affected estimates of the true numbers.

Insane. It's worth stating explicitly that, when entering into negotiation, one should be acutely aware - and wary - of anchoring strategies. 

Feature Requirements: Parts Storage System

Added on by Spencer Wright.

Parts storage has been a key aspect of my product development career, and has consistently frustrated me. A few reasons for my ire:

  • Parts cabinets are expensive. I probably spent $200 on my cabinets, which were mostly used; at my last employer, we spent over $2K on "standard duty" parts drawers, shown here, from McMaster-Carr.
  • Traditional parts organizers are time consuming to organize, and often aren't formatted to hold the size and quantity of parts you need to store.
  • Most management systems don't allow for reorganization without significant amounts of work.
  • Every organization & labeling system I'm aware of is disconnected from the part specs that I usually want to have on-hand when making a selection from physical inventory.
  • Keeping a digital catalog of parts inventory on-hand is time consuming, difficult, and totally disconnected from the location and quantity of the parts themselves. 

In order for the full implications of digital product development, manufacturing and distribution to come to pass, I believe that industry will need to completely rethink how it addresses, organizes, processes and tracks parts inventory. I have a few ideas of what this will look like, but I'd like for now to focus on the requirements for such a system. 

  • Parts should be uniquely addressable. For many of my applications, McMaster-Carr, DigiKey, Sparkfun, and Amazon product numbers would be fine. Ultimately a system like IP would probably be preferable, if only to apply uniformity and allow manufacturers and distributors of all flavors to buy into a single standard. At some point, I wonder about the possibility of addressing not only each brand/make/spec of bolt, resistor, or chip - but also addressing each physical instance of each of those categories. With the enormous addressing capacity of IPv6, this is well within the realm of possibility - we simply need to find an appropriate tracking mechanism. (Side note: IPv6 has an addressing capacity of about 3.4*10^38. In comparison, there are estimated to be on the order of 7.5*10^18 grains of sand on all the beaches in the world. That's a ratio of 4.5*10^19 : 1, in favor of IPv6 addresses.)
  • Physical organization shouldn't need to be hierarchical. Hierarchical systems work fine on dynamic interfaces (e.g. on the web, where they're used in conjunction with tagging and search features), but parts organization is subject to so many other forces - not the least of which is the size and quantity of a given type of item. For example: if the bolts I have on hand vary in length from 5mm to 50mm, finding a single drawer to accommodate all of them will be difficult. Much better to allow locational organization to be loose, and instead encourage browsing through a database. Put a different way: I don't see the need to institute a browsable Dewey Decimal system on my parts; I'll just search for them on my computer, and it'll tell me where I should look.
  • Parts on hand should be treated as a subset of parts in the world. When I'm designing a new assembly and searching for a bolt to use in it, I want to access a single interface that will allow me to search either globally (the entire catalog of uniquely addressable parts in the world), from a single manufacturer/distributor, or only from my in-stock catalog. On the other hand, when I'm physically looking at a particular item in my inventory, I should have easy access to the product specs for replacement parts and compatible mating parts. 
  • Inventory should be tracked in real time. When I remove parts from physical inventory, my database of stocked components should be updated immediately. As sensor technology evolves, it is my hope that this will be possible with minimal user interaction (e.g. via the use of pressure, proximity, or chemical presence sensors within the parts cabinet). In the meantime, the parts cabinet itself (or at the very least a nearby iPad running dedicated software) should offer me the ability to quickly update quantity on hand.
  • Complete part data should be available at the part's physical location. If I'm browsing for a bolt, I should be able to have access to all available part data for that bolt - including specifications, tolerances, 3D models, compatible mates, replacements - right at the parts cabinet. For now, this could be achievable by some user gesture at the parts cabinet (e.g. pressing a tactile switch at the individual part compartment) pushing a notification to a nearby iPad. As interaction hardware evolves, I would hope that this would happen within the parts organizer itself, through the use of haptic/gestural info (picking a part out of a bin) and integrated displays.
  • My purchasing system should know what parts I have on hand. When I order parts, it's almost exclusively through webstores. When I hit the "confirm your order" page, I want my inventory tracking software to scan for similar parts in my database and alert me if I've got anything in stock that would work for what I'm doing. If I'm ordering M4x12 button head cap screws and I have M4x12 socket head cap screws in stock, it's possible that I could save time, money, and inventory space by redesigning my assembly to accept what I have in stock. Conversely: When I place an order, my inventory system should know about it and prepare my parts organizer to accept new inventory.
  • Everything should have a 3D model. This is a bit of a pet peeve of mine. It blows my mind that many PCBs are designed without a digital visual check for interferences, and the situation is even crazier when you consider integrating PCBs into mechanical assemblies. I've spent a lot of time modeling off-the-shelf components for my own use, and have begun posting them on GrabCAD  for others to use. It's my hope that this type of thing catches on, and that manufacturers find ways to support/help the effort.
  • No paper. My previous parts organizers relied heavily on sticky notes and Sharpies, as I suspect most contemporary systems do. This is absurd. What happens when you run through stock of a particular part, and decide not to reorder? Well, you spend ten minutes scraping a crusty old label off of the bin, or taping over it with a new one. Adhesives fail over time, and pen-and-paper just isn't modular enough for the rapid changes in direction that modern product development shops go through. My bins should be unlabeled. Instead, I'll identify parts by comparing them to their 3D models (viewable in my parts organizer's interactive display), or - better  yet - by my parts organizer knowing what I'm doing (through whatever gestural interaction it uses) and telling me what I'm looking at.

What I've described here is huge, but not that conceptually complex. It also has the capacity to be expanded recursively, to apply to all kinds of physical and digital objects. A cohesive, consistent system for tracking and managing parts will allow for improvements in innovation and distribution techniques to reach their full potential. And I worry that without such a system, the benefits of rapid prototyping, just-in-time manufacturing, and distributed, adaptive supply chains will be highly constrained.

What I want my sailboat to tell me.

Added on by Spencer Wright.

I only own a racing dinghy - a standard Laser - but I've been spending a lot of time thinking about the challenges of owning a midsized racer/cruiser. I'm thinking in particular about boats in the 25-50 foot range, whose owners who use them for recreation only. In my experience, a boat can become just like a second house - except that you don't live there, and a lot of what you do when you're there is maintain it. It's also particularly difficult to monitor, though with improvements in wireless technology and low-power sensor networks, there are a lot of opportunities in this space.

There are currently a few services for monitoring boat status. Siren Marine's products are especially cool, offering position/geofencing alerts, bilge activity, temperature battery monitoring, and basic security features - all accessible from an iOS app. BoatMonitor offers mooring/anchorage geofencing alerts too, though their system requires a smartphone or tablet to be left powered on onboard the boat. Gost Global offers what appears to be a robust marine security system, aimed specifically at protection from theft.

Of the three, Siren comes closest to what I would want: A full marine monitoring suite which treats a boat like Nest treats a home. In addition to what Siren, BoatMonitor and Gost give me, I would want access to the level of every consumable (fuel, water, cooking gas) onboard; a variety of exterior environmental monitors; detailed data on bilge and sump pump usage; a variety of sensor data from the living cabin; and the ability to trigger any number of onboard instruments and functions from a remote location. If you'll excuse the "x for y" analogy, it's Canary for your boat. Here, in more detail:

  • Quantity of available drinking water
  • Quantity of available fuel
  • Quantity of available cooking fuel (LPG)
  • Waste holding tank status
  • Boat bearing
  • Wind direction/speed
  • Barometric pressure
  • Wave height
  • GPS location (optimally via GPS RTK) 
  • Cabin temperature
  • Cabin humidity (taken in multiple locations to isolate potential leaks/open hatches)
  • Presence of fuel in the bilge
  • Presence of microbes in the bilge
  • Sound level in the cabin
  • Vibration on the mast/shrouds (useful for detecting rigging failure) 
  • Vibration on the hull (useful for detecting that the boat has run aground/been struck by another vessel) 
  • Cabin entry monitoring
  • Remote circuit breaker control
  • Most recent bilge/sump pump activity & duration
  • Bilge/sump water level

Most of these factors I'd want current and historical data on, so I could see, for instance, a sharp spike in cabin humidity due to a leak. I'd also insist that the entire system be self sustaining via solar cells or wind power - there's too much of each of those for me to be draining my batteries to power a couple of sensors and a GSM antenna.

I'm hoping to be working more on this system in the coming months, and will update my progress as I do.