Let go of my Lego

James looks at how the interconnected car can cause you headaches

By James Dillon | Published:  03 May, 2017

"Electronic Lego" is a phrase that was introduced to me by an engineering manager when I worked for the diagnostic company Crypton around 25 years ago. In the late 1980s the Company had developed engine tuning machines which moved away from bespoke central processing units (the so called Big Box tuners) to a PC based system. The elements of the PC based system could not just be bought and fitted together (like lego) and be expected to work. The PC components and peripherals had to be carefully selected, including the compatibility of their drivers and software to ensure a robust PC based diagnostic machine could be created. Over the past 10 years or so motor vehicles have moved away from their previous Lego like construction, where replacement parts were free to be plugged in and replaced at will. The change was due partly to the modern vehicle being constructed as a rolling network of computers and partly to the advent of the factory fitted immobiliser, where transponder keys and the relationship between vehicle computers became prevalent.


Anything remotely related to the immobiliser (instrument panel, body computer, engine computer, etc.) required coding. The coding process synchronised the new part which was foreign to the system. Information was exchanged relating to the vehicle VIN number, the start point for rolling security codes was synchronised and the vehicle system registry was updated with regard to the replacement component. This entire process was carried out offline. The processes were invoked by a scan tool with suitable functionality and the vehicle could "self-update" without having to refer to the big bad world of the internet. Definitely not electronic Lego. In some cases, the vehicle manufacturer would require independent workshops to register to enable them to have access to security PIN code retrieval (in case the customer lost the original vehicle security PIN information). This type of setup could preclude independent workshops from carrying out certain tasks, unless they were equipped with the correct scan tool and unless they had registered with the relevant vehicle manufacturer regarding authorised access to retrieve security PIN codes, which, in itself was onerous.


Over the past couple of years we have seen a new dimension; the online aspect of vehicle coding and programming. This new dimension, sometimes loosely referred to as DoIP, sees the vehicle having to be connected to the vehicle manufacturer server, via a vehicle to network interface, to enable the interchange of data to occur. The workshop involved (and in some cases the individual vehicle technician) must have a valid login to the relevant vehicle manufacturer server. Vehicles that conform to this DoIP protocol undergo a validation process once they are connected to the server. Access to vehicle manufacturer web portals usually has two tiers of access, the first provides access to technical information and usually some form of basic vehicle electronic access. The second requires formal authorisation and will open up security related functions. Once vehicles are connected, an online validation process occurs. Depending on the vehicle manufacturer, this can range from a simple validation of the VIN, right up to a full computer scan of VIN, part number and software version management. This is the point at which the situation can become particularly interesting and is best explained by a real-world example.


Imagine a vehicle which, at some time in its recent past, suffered an issue with a component such as an airbag, an entertainment or instrument module. Buying a new replacement module was prohibitively expensive and so the vehicle owner sourced a used module. Garage A fitted the used unit, but discovered that it did not function correctly as it was subject to the guardianship of a system called component protection (a system designed to restrict the market for stolen cars/parts). Garage A did not have the required access or authorisation to the vehicle manufacturer server, so they called out a guy who had a tool which could solve the component protection problem and the unit was unprotected using this tool, most likely of Eastern European origin. The module worked correctly and everyone was happy, for now. Seems like electronic Lego doesn't it? Sometime later, and perhaps after a change of ownership, the vehicle develops a symptom which requires analysis. The new owner lands at Garage B who search for technical service bulletins using the vehicle manufacturer portal and discover that there is a software update for the engine and transmission computers which will solve the customer's reported symptom. The vehicle is booked in and Garage B connects the vehicle to the manufacturer server via their account. As its first step, the system performs a software version check (all of the fitted components are checked for software version and VIN) to ensure that the engine and transmission are running the older, problematic version of software. The vehicle fails this check and is ungracefully ejected from the process which now cannot be completed for no apparent reason. Garage B reports back to the customer that the vehicle requires further investigation and the customer agrees to rebook the vehicle. In the following days, Garage B receive a telephone call from the police vehicle crime unit. They have received a call from the vehicle manufacturer who had identified a stolen computer during a scan of a vehicle connected to their server from garage B. They have the VIN, the vehicle make and model and the time and date and computer from which the vehicle was connected. They want to know the why, what, who and where of the vehicle. Oh! Definitely not electronic Lego now and this mess will require much metaphorical elbow grease to clean up.


There are obvious implications which are beyond the scope of this article, but the situation described here is real and is affecting workshops now. The use of OEM anddealer equipment by go-ahead businesses is growing and the implications of situations as described here must be considered. Training and education for garages is a big part of this and in order help garages, we have recently added manufacturer specific diagnostic equipment courses to our training programme.


James, through Technical Topics is running a range of vehicle manufacturer diagnostic equipment & software training courses the first of which cover VW & Audi and Vauxhall/Opel. Call 01278 428 699 for details and booking.

Related Articles

  • Ben appoints Steve Nash as Chair of its Board of Trustees  

    Ben has announced the appointment of Steve Nash as Chair of its Board of Trustees.

  • Servicesure network signs 500th member 

    The Servicesure garage network has hit its second major milestone in a matter of weeks with Birmingham-based Manor Motor Company becoming the 500th member.

  • Non-intrusive testing 

    As technicians we’re all expected to be able to diagnose a fault within a sensible timescale, for a reasonable price, then guarantee the fix. With correct training, information and tools this is possible. However, we are often faced with multiple faults where cause and effect may not always be straightforward. We can be in a situation where we need to rectify faults before we can move on to the next. Also, if the repair cost could outweigh the vehicle’s value or customer budget then great care must be taken explaining the situation, agreeing a starting fee and preparing and executing a successful diagnostic plan.

    Recently we were presented with a BMW X3 for poor performance and a suspected DPF fault. After interrogating the customer we gathered all necessary information. Initial diagnosis confirmed multiple fault codes and a blocked DPF. Determining what caused the DPF to block is vital for the correct diagnosis and preventing reoccurrence. We created a test plan to test each fault and separated them into faults that affect the performance, faults that can cause the DPF to block or prevent regeneration and ones that don’t. In order to fully test the vehicle we would need to clean the DPF first as the exhaust back pressure was so high, the vehicle was barely drivable. As a member of the DPF Doctor network we have a very successful method of cleaning the soot from the DPF without the need for removal and access to many manufacturer-specific tips with DPF faults. The information and knowledge within the DPF Doctor network has proved to be invaluable and has given us an outstanding success rate. With our test plan ready we were able to calculate a sensible labour figure to conduct the tests required. The customer authorised the labour and the DPF clean.

    Several faults were straightforward. A multimeter gave us conclusive results and made it easy to quote for replacement parts and labour time to fit them. The main fault causing poor performance required a little more thought to keep diagnosis time to a minimum. A low boost pressure fault code doesn’t tell us why the pressure is low. Driving the vehicle whilst monitoring the boost pressure showed the fault was intermittent, so an external boost leak was unlikely. A smoke test was also carried out which revealed no leaks. In this instance, the EGR valve could be a likely culprit. This engine uses a vacuum controlled EGR valve with a position sensor built into the diaphragm. As tempting as it was to unbolt it and take a look, this would all take more time then factor in the risk of rusted bolts etc. With a position sensor one would think if the valve was to stick then a fault code would be set. We had to plan a simple, conclusive, yet non-intrusive way of testing the EGR system quickly.

    The conventional vacuum controlled EGR system consists of the EGR valve which includes the diaphragm with a 5 Volt position sensor and the vacuum control solenoid valve which uses vacuum from the brake servo vacuum pump and is controlled by the ECU on a duty cycle. The position sensor will typically show 0.5 to 1.2 Volts when fully closed and 3.9 to 4.5 Volts when fully open. One side of the solenoid valve has a 12 Volt (battery Voltage) supply and the ECU switches the ground path on and off at varying duties to vary the vacuum amount thus varying the EGR valve position. The ECU looks at the position of the valve and adjusts the duty to achieve the position desired similar to how an ECU uses the oxygen sensor to adjust the air/fuel ratio. With the following tests we were able to check every component in the system.

    Test one
    We connected the Mityvac directly to the EGR valve and the oscilloscope connected between the signal wire and battery ground. As we had already smoke tested the entire inlet system we connected the smoke machine directly to the inlet manifold in place of the intercooler hose. With the smoke machine running and the ignition on (engine off) we used the Mityvac to fully the valve to check it had no vacuum leaks (split diaphragm), then we opened and closed the valve slowly and then quickly. This confirmed the following:

  • NGK training at Mechanex Sandown Park 

    NGK Spark Plugs (UK) Ltd will be holding product training sessions at the forthcoming MechanEx exhibition at Sandown Park following their success at its sister show in Manchester earlier this year.

  • Life with the top down: Cayman Autos  

    Driving along with the wind in your hair – having a convertible is wonderful isn't it? Well, until there's a noise, or a leak, or the roof seizes up completely. At that point, to coin a phrase, who you gonna call?

Most read content


Sign Up

For the latest news and updates from Aftermarket Magazine.


Where should the next Automechanika show be held?


©DFA Media 1999-2018