Slashdot Mirror
Auto Manufacturers Running Out Of Unique IDs
wakebrdr writes "Y2K all over again? A story in today's Detroit News explains how the vehicle ID numbering system (VIN) will soon run out of unique numbers. According to the article, a member of the Society of Automotive Engineers says, 'Longer codes would require a major overhaul of computer systems that would dwarf the challenges and expenses spawned by the Y2K computer dilemma.' Golly, if it's that serious maybe I should start stocking up on MREs and ammunition in preparation for the day the assembly lines come to a screeching halt."
The second character signifies the manufacturer (General Motors is G, Ford is F, Chrysler is C)
Why not just give GM, Ford, and Chrysler another letter? GM can have G and H, Ford E and F, and Chrysler B and C
Surely every manufacturer doesn't produce as many cars as the top few
As a software developer for a gargantuan insurance company, let me assure you that I would be rather grumpy (to say the least) if I came into work one day and was told we have to overhaul our VIN-handling code. That would suck. Royally.
However, automakers could start mixing some alphas into the numeric vehicle-identifier portions of VINs...this could provide a few million (at least...too lazy to do math) more string combinations, and wouldn't affect the parts that IT people care about.Just once I'd like someone to call me 'Sir' without adding 'You're making a scene.'
Um, actually, if they expected it to last 30 years and they expect to run out of unique VINs at the end of the current decade, it will have lasted 30 years.
I wouldn't worry too much about it. Every industry eventually hits this dilemma and every industry deals with it in their own way. Just a few years ago (actually prior to Y2K), some of the companies in the business of Livestock Genetics were worried they'd run out of Bull numbers. (I think the standard was something like AC0023 where the first two digits identified the company and the last four were the bull's number.)
The various companies formed an IT standards committee and came to an agreement on extending the numbers. It took a year or two, but the systems got converted and life went on. It really wasn't that big of a deal. As a bonus, a real standard for data processing showed up. The previous number scheme was designed for paper and allowed for certain variations which gave computer systems a fit. e.g. Sometimes the number might be written as AC23 or simply 23. This made it difficult for a computer to decide if the code was the domestic code or the international code.
Javascript + Nintendo DSi = DSiCade
- a claim that the VIN system was created in 1981, and expected to last 30 years
- a claim that the numbers could run out by the end of the decade
So, they expected it to last 30 years, and now somebody says it'll probably only last 29 years and you say, "I really hate to see somone that points out that 'It'll Last for X years' and it never does.'I don't know about anybody else, but if 23 years ago, someobdy engineered a system that was expected to last 30 years...and they were only off by one year...I'd cut them some slack.
Granted, they should've thought about what would happen after thirty years, but they probably did. In fact, they probably thought long and hard about it and decided either:
(a) we'll all be teleporting everywhere by then and cars won't matter anymore; or,
(b) we'll all be retired by then so who gives a rat's ass.
This would still result in having to rewrite a lot of software to take the extra field into account. Especially because you could say the exact same argument for Y2K: "So just expand the year field by adding a second field of 2 more digits. Years in the 20th century don't have anything in the second field, those outside do."
That said, who knows how much of a problem this is; Y2K turned out just fine, though it did take quite a bit of work to make it so...
The concept is not new - I stole it from "Database System Concepts, 2nd Ed. (c) 1991, Korth and Silberschatz", though they used the concept of "overflow blocks" for storing values that clash in a hash, and I'm using it for looking up the extended version of a vin (if it exists).
This way, since the original tables are not altered, existing queries that do not deal with the extended vin are not affected, and there's a lot less debugging to do - and a lot fewer areas where bugs can creep in.
The sql statements that do lookups of vins are the only ones that would have to be modified. Not a complex task, since the vin itself (in a properly-normalized database) is not the primary key, but rather gives you back an oid (object id).
Same problem with SINs, which are also not unique in every case.
This completey misses the point. It's not just the database: it's the software, forms, etc. for insurance companies, law enforcement, DMV, etc. for all cities, states, provinces, countries, etc everywhere in the world. Each of these systems probably validates what is a real VIN so any changes to the current scheme will cause massive problems. Any addition of a new field will be almost as hard.
This is obviosly why they are looking at this issue now, so in 10 - 20 years when the current numbers are gone, software can be ready for any new scheme (cause that's about how long it will take.) Hopefully BECAUSE of all the code rewrites for Y2K, this task will be much easier (many old systems were completely replaced in modern languages with modern coding techniques.)