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."
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!
Case Sensitive?...smoke much crack? Have you ever tried to read a 25 year old rusty-arse VIN?
The Society of Automotive Engineers, which established the existing VIN system in 1981 and expected it to last 30 years, has formed a committee to address the impending shortage.
Good thing we survived the 80's so we can always point at mistakes on how not to build things to last. I really hate to see someone that points out that "It'll Last for X years" and it never does. Like IPv4, now we have IPv6 - which I can almost say for certain it will outlast most of us (IIRC it has more digits than atoms in the universe). 640k anyone, the list goes on and on. All of you as engineers have to think a little harder; did we really really save that much money when we used 2 digit dates verses 4 digits. Even into the 90's now the 00's how many use 04 are their checks - what if the Declaration of Independence just had 2-digit year? Its not like were running cat7 in the walls but now maybe there is a list long enough where we can start saying why don't we add a few spare digits for buffering.
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.'
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
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.
Y'all love the word 'dipshit' don't ya?
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.
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...
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.)
Well, actually the Dingbats are part of Unicode already...
Here's the complete table 1980 to 2039.
Have you considered storing your phone numbers in international format(AKA SMS format)? To contact a local number here you would use an example like this:
+16045551212
(+=internationl dialing prefix),(1= country code), (604=area code), (5551212=local number).
Regardless of where on the planet that number is dialled, the tower will determine if it's a local or international call and have it correctly forwarded and billed. The same numbering format used for sending international SMS text messages can also be used for placing phone calls. The 604 area code switched to 10 number dialing a few years back. I had no problems with the transistion.
VINs, on the other hand, need to be unique globally.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON