grohgreg

Do not use that example in support of your doubt. A low battery is common to ALL connected modules, the BSP is common to none. It's merely an interface between the ECU and the fuel rail. And in the case od the BSP+, include the boost sensor.

//greg//

gnat

Greg, it's not directly connected, but they all share the same basic infrastructure.

While extremely unlikely, if the BSP sends a bad signal back to the ECU that it handles incorrectly, the ECU is then has a pathway to the "non-critical" side of the CAN-Bus which is where such things as E&D, PCM, etc.. operate.

All I'm saying is that it is in the realm of possibility, but cannon's issues have exponentially more likely causes that the tech should address first.

grohgreg

As does your house wiring. But - short of a ground fault - a defective device in one circuit will not affect devices on any other circuit - unless a supply or ground association can be inconclusively established. It's no different in automotive DC systems. They are isolated from each other, just like in AC systems.

You must prove relativity before you can assign -or even speculate on - blame. In this case, the only commonalities between the BSP and those two bad modules are battery and ground. If there are no indications of common denominator problems, its technically irresponsible to assign blame based upon speculation

Example in point: I occasionally get a random glow plug light. Curiously, its associated with a turbo overboost code. Service advisor jumps straight on the BSP. They're still chewing on the fact that disabling the BSP does not stop the random reoccurrence of this curiosity. As the fella said above, service advisers must PROVE that your mods are responsible for any given issue

//greg//

gnat

I think you are just focusing on the power aspect and in this you are correct. It's the networking functionality that I am referring too. In that regard it is more akin to the network in your home or office. If a device broadcasts a bad signal it is up to the receiving device to handle it correctly. Unfortunately this is a very real attack vector on computer networks and most of it is due to unintentional bugs in the receiving code. The CAN-Bus is a similar network and the various devices attached to it are no different than computers which means they are dependent on whomever wrote their code to expect and properly handle an odd out of band message correctly.

It's extremely unlikely that a random bad signal from the BSP could trigger a cascading fault in CAN connected devices (as I've continually said), but it is possible.

BSP -> ECU -> CAN ( -> Gateway -> non-critical CAN ) -> E&D related devices

That's a high level of how they are connected. It's just a matter of likelihood of the BSP being able to cause an event that would cascade through all that, which is remotely small.

Edit: There have been a bunch of cases of people hacking car radios with a simple audio CD and having it mess with other CAN devices. So this is far from a theory or mental masturbation about what may be possible (well the idea of a random bad signal still is).

It's also irresponsible to ignore a possibility because you don't fully understand the systems involved and how they interact.

The BSP is not the first thing that should be blamed in cannon's case as there are far more likely causes, my only point is that it can not be discounted entirely.

I was that fella

I wouldn't initially attribute the BSP to the glow plug issue, but again it is a remote possibility. The over boost code, however, has a much higher possibility even after the unit has been removed. Since the BSP (in your case since you have the boost module) directly connects to the boost sensor it is possible that a short or bad signal caused damage to the sensor which is causing it to give bad readings even after the BSP has been removed.

They should have procedures for validating the boost sensor. If it's bad, then I'd say it's reasonable for the replacement cost to come out of your pocket (unless you have it documented as happening before you ever installed the BSP). I think it would be more likely that it was just a bad sensor that would have failed anyway, but other than having them note my skepticism I'd suck it up to stay on good terms (and because I would judge the odds of winning a M-M case in that situation as not being in my favor even if they couldn't conclusively prove the BSP did something bad). If, instead, they find the sensor is fine (or replace it and the issue continues), then I'd say the likelihood of the BSP being at fault drops pretty significantly.

I'm all for using the BSP and I'm not trying to say it is at fault for either your's or cannon's issues. I'm just saying that the lines of connection aren't as clear as they used to be before the likes of CAN/OBD/etc.. started making their way into cars and dismissing the relationships out of hand is as bad as a Tech immediately blaming things on it without doing any basic troubleshooting first.

grohgreg

Or perhaps you're just over-thinking it. Or maybe confusing the ECU with the ECM. And here I'll confess to being slioppy with the acronyms myself. Yes, modern autos have an Electronic Control Unit (ECU) that can be likened to that server. An ECU typically controls up to 70 modules, and connectivity is indeed via the CAN bus. The engine control module (ECM) is one of them. But individual modules are seldom physically connected with each other. Between inter-dependent modules, the ECU acts as the intermediary (server).

But this is where your network analogy works against you. Consider the basic computer network; comprised of a server, work stations, peripherals. Any one work station can fail, and the others go chugging along without even noticing the loss. Any peripheral can fail, but said failure does not impact the work station itself. It's reasonable to compare the ECU to a server, the ECM to a work station, and the fuel rail/boost sensor to peripherals.

But the BSP+ is connected directly to the ECM, not to the ECU. Using the network analogy, it's merely a serial interface between the ECM (work station) and the fuel rail/boost sensors (peripherals). And I've already conceded selected module interdependency. Where I'll draw the line however, is accepting that there's any interdependency between the ECM and either the Entry and Drive module or the Dynamic Light module. So it defies logic to even suspect the BSP+ of influencing those two modules.

//greg//

gnat

Essentially what we are talking about here is a self replicating virus (although unintentionally triggered by random chance). Your example of a serial device not being able to do such a thing is flat wrong. Go look up the mess a few years ago where a bunch of cheap USB picture frames and flash drives infected the computers they were plugged into.

Every device in our cars that runs code has flaws regardless of if they are oversights or deliberate design decisions (e.g. too costly to fix against the likelihood of happening). Its just a matter of finding and triggering it.

Basically speaking the BSP is sending values back to the ECU in an expected pattern. The question is what does the ECU do if the values are outside the expected range (not just too high or low, but a exponentially higher than max level or a negative value) and/or the message doesn't fit the communication protocol (e.g. just random bits of data)? Then, should that particular failure cause it so send bad messages, how do the receiving devices react?

I've worked with embedded devices like we are talking about and many security corners are cut in the interest of memory space and processing performance. Especially in an environment where outside communication is not intended.

As I've continued to state, for this to happen by random chance is ridiculously unlikely. It is greater than 0 though. There are far more likely things causing cannon's issues that should be investigated first.

grohgreg

Virus? That's even more of a stretch. I can't tell if you're purposefully avoiding my reasoning, or if you're still mixing acronyms. Once again, the BSP+ is not connected to the ECU - it's connected by wire to the ECM. The ECU is generally uninvolved in any engine functions, unless linking the ECM to another module is required. And that requires an address. If it helps you visualize, review my previous post and substitute "router" for "server". Your faulty USB device (BSP+) may in fact affect PC performance (ECM), but it should have no effect on router (ECU) performance OR on any other device (module) connected to the router.

This is pyramid architecture that uses digital addressing between the ECU and the subservient modules, likely via fiber. Like I said, think "router". Data packets between legitimately related modules necessarily carry the address of the destination module. That's how the packets know when/where to leave the CAN bus. Beyond the modules, the packets proceed on dedicated paths, typically copper. No addressing involved. In this case, ECM mapping data travels by dedicated wire path to the fuel rail and boost sensor. The BSP+ is simply a serial device that has been placed into those dedicated paths. the BSP+ neither requires nor generates addresses. It simply takes mapping data from the ECM, alters it, then forwards the revised data on to the fuel rail and boost sensor.

I'm still far from convinced that BSP+ data ever even reaches the ECU. But for the sake of argument, the ECM would still have preface these packets with an address for Entry and Drive and Dynamic Light modules before the ECU would even know where to relay them. Alternatively, if unaddressed BSP+ packets actually do reach the ECU, it then require the ECU to assign a destination address - in this case that of the Entry & Drive and Dynamic Light modules. Virus or no virus, I simply can't accept that unaddressed BSP+ packets - by themselves - can cause faults in completely unrelated modules.

//greg//

mudman2

I think the only fiber in the car is the MOST net. Everything else is copper. The system does measure impedance changes for fault finding, and may detect foreign connections even if they do not appear to be impinging on any other system. How it interprets that is unknown and will no doubt depend on the subsystem being touched

The battery analogy is valid based on the wide and varied impact battery volts has.

I would not rule out anything, it may not have anything to do with digital data

grohgreg

I'm not familiar with that acronym. But I was led to believe that control modules on high end cars - such as the lighting and towing modules - are fed by fiber. It's not my intent to belabor the point, I'd just like to correct any erroneous information I've gathered regarding current electrical systems

//greg//

gnat

It's called an analogy, but it's the same principle. Someone writing a virus finds a fault in the targeted system that allows them to do things that they shouldn't be able to. In this case (BSP vs CAN devices) it would have to be a highly unlikely freak event that caused an issue down the line.

Routers/Switches/Firewalls/etc.. are just as vulnerable as desktop computers and desktops/servers are frequently the attack vector used and one of the most common attacks is sending various bad packets that will make the target device do something it shouldn't. If you have a support contract for any commercial gear you'd see that they are constantly releasing warnings and patches for vulnerabilities being found.

To continue down the computer network analogy, what we are talking about here is something crossing VLANs (logically separated networks that share a physical infrastructure) in that we are talking about something from the "diagnostic" bus talking to something on the "comfort/infotainment" bus. It's not something that is supposed to happen, but it can (and that is usually done by an attack on the switch/router).

In the computer network world much of this is mitigated by various layers of defense. It's be shown multiple times by many parties that CAN has very poor security at best. This is what makes me cringe at the idea of MFGs putting WiFi in cars these days.

If it's connected to the ECU or the ECM doesn't matter. It's that it is possible for it to send back bad information to the device(s) it is connected to which could cause it to do unexpected things and send bad messages further down the line. Beyond making it ever more unlikely the number of hops between points A and B don't matter as long as there is an unbroken path.

If you go look at the CAN protocols, the messages are not some detailed validated process. A device simply broadcasts a command and devices listen to what they want to care about. They should be ignoring messages that aren't tagged with the ID they care about, but if that part of the packet has something completely unexpected in it that is where things can fall apart if the device programmer was sloppy/lazy/inexperienced. The messages themselves have a pretty basic header and depending on how many unique listening devices there are on the it wouldn't be unexpected for a header with random data to actually generate a valid device ID.

I'm getting tired of repeating myself so I'll put it in bold this time:
The chance of the BSP randomly generating a signal that would cause a cascading failure that would reach all the way back to the E&D devices is insignificant. It is not, however, absolute zero. Until all the far more likely causes were debugged and ruled out (ECU re-flash, system/device tests, etc..), I wouldn't consider the BSP being a valid source.

I've spent too much of my career, however, debugging weird problems in code that were caused by strange things that should "never" have happened to rule anything out no matter how seemingly unrelated. That doesn't mean you should start with the off the wall stuff in troubleshooting, but refusing to look at it as you rule the obvious out will just make life more difficult.

grohgreg

Looks like we must settle by agreeing to disagree. The positive outcome however, is that the OP now has at least three opinions that he can assess in developing his own

//greg//

Divot

What about the 'installation of non-OEM parts voids the warranty' thingy.

grohgreg

That argument only gets potential legs when a sub-quality aftermarket part replaces an OEM part. This BlueSpark device we're discussing is installed between OEM parts, to improve performance and fuel economy. Read back aways in this topic, and you'll see that it's the dealer/manufacturer who has to PROVE that any given aftermarket installation/modification is conclusively at fault - before legally denying a warranty claim.

//greg//

gnat

That's the whole point of the Mag-Moss Act that I talked about earlier. Prior to its inception servicing your car other than at the dealer or using non-OEM parts would void the warranty.

With the Act in place, a non-OEM part does not void your warranty. Obviously they don't have to cover said part and if they can prove it was at fault for some other fault you are making a claim on, then they don't have to cover that either. Doesn't matter if its a no name spark plug or a plywood spoiler you built yourself, if it can't be proven to be the source of the failure, then the warranty remains intact. Furthermore, the warranty is only voided on the parts it does impact. The rest of the car remains covered normally.

They can, however, put standards in things that non-OEM options have to meet. As long as it meets those specs though, you are good.

Needsdecaf

But consider what the BSP does and you'll realize that it is instant cause for voiding your warranty, if Porsche calls it out.

The BSP, like other piggyback tunes, operates by deliberately feeding false information to the ECU / ECM. It raises boost pressure, fuel pressure, timing, etc., by using the car's normal tuning map, but deliberately feeding it false values from the various sensors it intercepts. So it causes the car to think it's running less boost than it is, the car keeps the wastegate closed longer, boost pressure is actually higher, and performance improves. It does this for fuel pressure, etc.

It's pretty easy for Porsche to point the finger and say..."you deliberately fooled the engine into operating at parameters outside of which it was designed to operate. You have voided your warranty".

Not sure how Porsche operates, but many manufacturers state that if your warranty is voided, it's voided. No warranty work whatsoever even if it's not related to the initial installation.

No, none of it is really plausible. But that's the way they normally work.

The purpose of M-M is to protect the end user's right to have the car serviced by someone other than the manufacturer, using non-OE parts that meet the same standards as OE parts, and not void the warranty. It does not, however, cover modifications that affect the parameters in which the vehicle operates.

Same manner if you have lowering springs with adaptive suspension. If your fancy adaptive shocks fail, I wouldn't be surprised to hear a dealer blame the lowering springs. Not because they are non-OE, but because they limited the range of motion of the shock, and allowed the shock to bang into it's travel stops repeatedly, causing damage. Is it true? Probably not. Hard to prove wrong? Certainly.