NASTF Information Requests

Tracking: 299 Status: Closed
State: TX Name: Rick
Category of Request: Reprogramming Manufacturer: 2004 BMW 330I

Have you checked the OEM website?
Description of Repair unable to perform
unable to program or diagnose using the factory BMW tool.
Description of Information not available
all repair and programming information contained in ISTA and ISTA/P
Description of steps taken to obtain information (help/contact function on website, websites, etc.)
Contacted 3G tech support through online form and spoke with Jason Kozak
Other Comments or Concerns
My complaint today has different issues involved in it. I will attempt to separate the issues even though they all interlock to create a situation in which it appears that BMW is meeting all NASTF requirements, but in reality they have created a system that is so unworkable as to not meet any of requirements of the release of a scan tool to the aftermarket, release of repair information, release of programming information and the ability to successfully program a vehicle as required by law.. My complaint today has 5 key issues: 1. Ridiculously incompetent tech support by SEILLC. 2. Bottlenecking or clamping down of download speed while in ISTA and ISTA/P to make for ridiculously long download times. 3. The deletion and reloading of these files EVERY time the tool is used which the dealers do not have to do. 4. Missing or removed repair information along with access times that make the repair information impossible to use profitably. 5. separation of BMW and Mini which effectively doubles the cost of working on these vehicles. Let's start with the ridiculous tech support by SEILLC. I want to state right here that my complaint does not include Jason Kozak who has tried diligently to rectify the situation. I filed 2 requests for tech support through the online system - I was able to solve the first issue myself before Tech support could come up with a resolution. The second request apparently had some information issues with my phone number but I referenced the first complaint in the body of the message which could have been a source for the phone number. My e-mail was also included in both requests which was accurate. The support system generates a ton of e-mail messages which makes it hard to tell when they actually need a response. After watching them for 4 days I have gotten pretty good at figuring out what they are doing which amounts to pretty much a game of "pass the buck" and see how long we take to get an issue resolved. These 2 help requests have generated 51 e-mails as of Friday night to my server with no resolution. In fact most of these e-mails do not contain anything other than passing my complaint back and forth without doing anything real to correct it. On the second complaint the first useful support e-mail I received 24 hours later was asking to re-answer all the questions asked on the support request form. This is typically a stalling tactic by the support people that is used to buy time. Unless they actually look at a log file this information is useless. They also mentioned my contact number was incorrect (I guess it was too much trouble to double-check the phone number on the complaint I referenced in the body of the request). I responded with the correct number. When I didn't hear from them on Thursday, I sent an e-mail asking for status (especially since in the multitude of e-mail they were bombarding me with there was one that said it was on hold until the 27th) and received a response that they were working on it. I then contacted Jason on Thursday afternoon to express my displeasure. He escalated my support call on Friday. I received a call around noon on Friday from Mate who finally requested log files to review. Let me reiterate that it had been three days since the request was placed and they were just now asking for information to solve the problem. I tried to pull the files and send them while we were talking so Mate could verify he got them. He refused to tell me which files he wanted and insisted that he must e-mail me the information. He told told me that someone would call me back before the day was out. I sent the files out within 20 minutes of receiving the e-mail. Guess what?? I'm still waiting on the phone call. Now let's proceed to talk about the server and the deliberate bandwidth reduction making for ridiculously long download times when loading and using ISTA/P. I would like to present first for the less computer literate that may be re
Mary Hutchinson - 6/8/2010
BMW Personnel responded as follows, after working with Mr. Layton extensively: Dear Mr. Layton: We at BMW are concerned that you experienced difficulties in using our online services. We would like to take this time to answer your service information request. SEI Support: As of 4/1/2010, support for independent dealers in the US was migrated to ISPI Complete Support. Thus, corporate dealers will be on equal footing as independents in Europe and the US. This will also be reflected in the processing of support cases through identical processes, tools, and through the same provider. The tool used for incident management is REMEDY SMS, the global company standard. The field “Suspend until” is not used by REMEDY SMS or ISPI Support; therefore, the information that was sent via system status notification, that the ticket is “on hold” until 4/27, is incorrect. The numerous emails that were received from our Remedy tool (Call tracking tool) were the result of erroneous system notifications. Support addressed this issue with the parties responsible and it will be corrected. Access to BMW and MINI information: An error in access link authorization has been resolved. Both BMW and MINI information is available. Deletion of ISTA/P Data: Generally, our first priority in vehicle programming is that a vehicle worked on with BMW (Online) Tools is safe for the customer, and that no unintended alteration (not approved by BMW) occurs. Various provisions were set up for this: For vehicle programming: - For 2G-Online, due to the low transmission bandwidth (dial-up) and the open system, intermediate storage with complex encoding of the content data on the dealer’s local PC was chosen. - For 3G-Online, due to the increasing availability of bandwidth worldwide and the growing number of ISTA/P versions, repeated downloads were chosen. In your situation (unusually slow download speed), this has had a very negative impact. - For the BMW sales organization, through the use of a monitored and closed system without user access to the data, the same level of security for the customer has been achieved for both 2G and 3G. Bandwidth Issues: The results you have reported are entirely unexpected and not what BMW intended. BMW does not restrict internet bandwidth. The internet connection capacity in Munich is 1Gbps. The peak load for this internet connection is currently 300Mbps. The internet bandwidth, including the underlying infrastructure, is used by numerous internet-based applications worldwide. None of these applications has reported performance problems. Aside from the distance, other transmission parameters also limit network capacity and performance. The ~35Kbps capacity is still far short of expectations, and cannot be explained by the factors mentioned. An important development target for ISTA/P is the use of the online application by independents. For this reason, within the framework of ISTA/P’s verification, we are conducting tests regularly on download performance. The observed times of our measurement results were always considerably better than those what you have reported (e.g., download times of the basic package with a 2 Mbit/s DSL line were always less than 50 minutes). In addition, we recently performed two “live tests” in production environments outside of BMW: - On 2/27/10, a live test was performed at a small independent dealer, located in Bavaria in a small town with 9,000 inhabitants. He has 4 shop workstations and internet access via a 2 Mbit DSL line. The download data (approximately 235 MB) was loaded onto the ISTA/P laptop in approximately 25 minutes. The subsequent programming of the footwell control module needed another 24 minutes. The entire programming was done in less than an hour. - On 3/18/10, programming was demonstrated to OSS representatives of the European Commission in Brusse