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."
I would start using alphanumeric characters in the serial number field (last 6 digits), giving them 36^6=2,176,782,336 possibilities instead of 10^6=1 million. Actually maybe they already do? If so, then start using the !@#$#$%^%^&*)(*& symbols!
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
Might work. I doubt if any of the code tries to manipulate it as a number. (Unless there's a checksum built into it.)
One line blog. I hear that they're called Twitters now.
Whoever came up with the the VIN system as it stands needs to be drawn and quartered. I assure you that had any engineer worth his salt been given the plan of VIN back in 1981, he wouldn't have allowed there to be the imminent shortage we face now. By simply giving the right data fields (specifically the last six) more than enough space, we would have never faced this crisis ... and I hesitate to call this a crisis ...
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.
Why? Cars have to be registered and insured. Typically, things that are registered (cars, guns, people, etc) have to be uniquely identifiable. Without a VIN or some similar system of identification, such registration would not be possible.
Lets see, for warranty verification, theft protection, automobile history tracking (for accidents), recall tracking (so your car doesnt explode, hopefully).
How many more reasons do you need?
I think it ges without saying that most, if not all Pentiums did not have these sorts of problems.
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.
You have to run it on every database. And you have to deal with every program that operates on it and allocates exactly 17 characters for the space. That means scanning the source code, which is wildly expensive (assuming you even still have the source code).
Every program which parses the VIN will be confused by a change in the format. Again, more code scanning.
When any two databases pass VINs to one another, they both have to use the same standard.
Once the code is fixed, you have to install it on every computer. You have to synchronize the database update and the code install, and every set of databases that hook up with each other. You can make things compatible enough to be prepared to communicate with non-upgraded databases, but that means more code, and more testing.
You have to test the bejeezus out of it, too, because some of these systems can't afford to crash.
So the change is going to be a lot more expensive than one SQL query.
allow letters in the serial number portion, overlay models onto the "old" model designations, revisit closed plant IDs for that section of the VIN... lots of possibilities out there. it's pretty simple to fix any code that demands that the last 6 characters be numeric, for instance, and the hardest part is for folks to accept that if you set too small an address space, you have to hack it later and fool up your pretty rules.
this is not rocket science, and civilization will not die.
if this is supposed to be a new economy, how come they still want my old fashioned money?
You'll never work in this town again! ... Unless, of course we need you.
20/20 hindsight brigade reporting for duty, I see. Besides, making your hardware (read: VIN stamper) modular is a bit harder.
This is my sig. There are many others like it, but this one is mine.
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...
Not to nitpick or anything -- but no. IPv4 allows for 4 billion (and change) possible addresses: 2^32, minus a bit for addresses which aren't usable for various reasons. "Digit" is not a synonym for a possible address.
OK, yeah, that was nitpicking, but since I've seen at least two people make the same mistake in this thread, I wanted to point it out
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
Considering every year they build and rearrange whole assembly lines to crank out thousands of vehicles no one has ever seen before, I'd say retooling is rather a minor issue here.
On the other hand, with the myriad of computers involved in DMV systems, parts management, etc, I can see how the programming part of the matter would be very difficult.
Alcohol, Tobacco and Firearms should be the name of a store, not a government agency.
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.)
Here's the complete table 1980 to 2039.
VINs, on the other hand, need to be unique globally.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON