[Turbanator]

So basically you are saying that a base model C-class is primitive compared to a full loaded C-class because it is missing some gadgets !!

Not aware about C Class but we are definitely shortchanged on some of the amazing stuff that new 7 series can do elsewhere, they have added/activated few gizmos recently but autonomous driving still a far distant. I think this has to do with the overall "primitive" status of the country as a whole as far as infrastructure is concerned.

https://www.youtube.com/watch?v=pOUHz6lqT5U

[shridhar.s.i]

"Never judge a thread by the number of pages or stars"
Yeah ok I said it, but this is one of those threads where within 3 pages i see a lot happening.
A few points from my side
1. I think what was being called primitive is the wiring + backup / fail-safe wiring which separates a good car from the others, but I am really not sure this is followed in 90% of cars manufactured (To be honest, i have only read about these practices for aviation systems, did not know cars also have it).
2. Lesser number of ECU's wont make a car primitive, as discussed in multiple posts, it depends on whether similar functions can be combined to utilize one ECU or they need to be distributed across many, I dont know how this will work for cars, but based on my basic knowledge of Microcontrollers and micro processors, i am saying this
3. I had a minor accident myself due to unwanted acceleration in my hyundai i10 and even the hyundai service center has received many such complaints and i believe the "Smart Pedal" was actually implemented to handle such bugs in ECU.

Now I have a question, what happens when we are using Piggyback ECU's like Pete's or RaceDynamics, i strongly believe they will not undergo as much testing as a car tested with manufacturer's standard ECU, any thoughts on the same

[motorhead16]

Originally Posted by freedom

Correct.
Toyota owners in US have reported they couldn't get the car into N. I find this very hard to believe. Some of the 911 calls wrt unintended acceleration problem were fake. Some cases were due to floor mats keeping the A pedal depressed.

Toyota might be at fault in this regard. Check here : http://embeddedgurus.com/barr-code/2...-acceleration/

[madhavgpai]

ECU functions by large are grouped by functionality. That means similar or interdependent tasks are generally programmed into one. Engine Management, Body Control, Driver Assistance and so on...

Number of ECUS under a functionality can be due to many reasons; manufacturer wanting to keep it separate so that they can roll out different variants, manufacturers buying them from different suppliers who want to keep their Intellectual property confidential, insufficient computational capability of a single ECU or new feature added into a car which was already a complete product and it simply did not make sense to tamper the fully tested ECU. Hope you get the picture. This sure does make the system complex, but...

As far as safety is considered, I second the points already stated in the discussion above: ECUs by concept design are failproof. Extensive thought is put behind to address every scenario that the car might come across. Networking (CAN), even though has been hacked numerous times, is safe if you are sure nobody has access to your Car. Communication protocols have priority mechanisms for different messages that addresses safety critical problems.

However, Bugs are the biggest threat. At some point of the software development, there could be a human error which is not captured by the test cases. Because test cases are also written by humans. The solution to this is extensive testing, retesting and independent testing another couple of times.

Here is where the integrity of the manufacturer/ECU supplier comes in. It comes down to what their answer is to "Do I ship this product with 99.99% quality or spend twice or thrice the money in testing to make it a 100%?"

[katchkamalesh]

Originally Posted by Jeroen

Of course,there is a Wiki page:

Face it guys, time to put away the spanners and get familiar with a laptop and some fancy software to work on your car.

Jeroen

Like it or not this is what is going to happen.

Today, on an average, the value of electronic content in the car amounts to around 30% to 35% of the total cost of the car and this figure is going to go up to 50% over the next couple of years.

Moreover, electronics is also the area where suppliers can make money and add more value at a significantly lower cost when compared to pure mechanical systems. Any bad move which will tarnish the suppliers image will be a strict "NO".

And as someone pointed out, OEMs will ensure safety of the occupants if in case something goes wrong. There will be fail-safe mechanisms which will engage the limp mode and ensure occupants' safety.

[Jeroen]

Originally Posted by madhavgpai

Here is where the integrity of the manufacturer/ECU supplier comes in. It comes down to what their answer is to "Do I ship this product with 99.99% quality or spend twice or thrice the money in testing to make it a 100%?"

No amount of money and or testing will get you up to 100%. There is always something that can wrong and according to Murphy it will at some point in time.

It is however a case of economics, legal requirements and, dare I say it, ethics, how far a company takes the quality of it’s product.

Jeroen

[Whiplash7]

Originally Posted by shridhar.s.i

3. I had a minor accident myself due to unwanted acceleration in my hyundai i10 and even the hyundai service center has received many such complaints and i believe the "Smart Pedal" was actually implemented to handle such bugs in ECU.

Would be interesting to know more about this incident. I could not find any thread or posts on unwanted acceleration complaints with Hyundai i10 here in team-BHP.

[madhavgpai]

Originally Posted by Jeroen

No amount of money and or testing will get you up to 100%.

It is good that you mentioned this. I should agree and also disagree. The target of developers is to develop something that does 100% of what it is intended to do. If that is met, it is a 100% bug free ECU. Its not impossible.

Now, if the requirements for the ECU given to the developers are incomplete, I think then it should account to technical incompetence of the people involved from the manufacturer or supplier and I cannot say that ECU hardware/software quality per se is the cause of any misbehavior. This is possible.

[ecenandu]

Originally Posted by madhavgpai

It is good that you mentioned this. I should agree and also disagree. The target of developers is to develop something that does 100% of what it is intended to do. If that is met, it is a 100% bug free ECU. Its not impossible.

Now, if the requirements for the ECU given to the developers are incomplete, I think then it should account to technical incompetence of the people involved from the manufacturer or supplier and I cannot say that ECU hardware/software quality per se is the cause of any misbehavior. This is possible.

Hmm, its an interesting definition that you have given for a software bug. I'm afraid it is not a correct one. You generate test cases from requirements, specifications, model/code, etc right. Code coverage, model coverage testing, etc can be used to make sure that you did the minimum required test cases.

A video from Matlab, if you are interested. Video

I agree with Jeroen on this one, it is almost impossible to design, implement and validate a 100% bug free software. 95,98,99.99%, maybe.

I would like to give an example, It is a well documented problem on KTM that during quick downshifting the bike used to cut off and sometimes you need to reset the bike ECU to start again. Imagine bike getting switched off during an overtaking maneuver, in case of an accident whom should we blame? Similar problem was there with Ford Figo as well I believe, engine switching off during downshift.

It might be a software issue with model/code/calibration values or could also be because of limitation of the hardware used, like idle air valve solenoid, throttle body design etc.

Autonomous driving is an all different ball game, here testing will be a difficult challenge.

Comma Ai there are many nice videos on the same.

[r_nairtvm]

I thought that these two news bits though slightly old, are still relevant here.



http://www.drivearabia.com/news/2011...ctronic-issue/



http://www.drivearabia.com/news/tag/...-acceleration/

Best Regards & Drive Safe

Ram

[audioholic]

An interesting read for anyone who is not aware of some of the standards /practices followed in automotive system development

https://en.m.wikipedia.org/wiki/Auto...ntegrity_Level

[vsaravind007]

Some of the reported cases were fake, but not all! Engineers from NASA were assigned to investigate the Toyota Unintended Acceleration issue since serious stakes were at play. They couldn't find the issue - they were not able to recreate the reported issues but formulated some hypothetical scenarios - which made them walk away free. However, in a different similar case, an independent investigation involving the analysis of Toyota's ECU software revealed serious flaws and hence Toyota was fined for the use of super low quality software for a mission critical application.

These are some of the interesting findings:

Toyota's ECU operating system:



The software architecture consists of several tasks running in parallel sharing same memory space and data structures on top of an RTOS. These tasks are nothing but software routines that monitor throttle position, braking force, AirCon etc. A single bit flip(memory corruption) will result in getting a task killed thereby losing critical functionalities of the vehicle. It was found out that each task takes a bit of time to get restarted and in some cases they restarted later on based on some programmed events like, release of the brake pedal - Effing serious flaw when you're panic braking!. This was confirmed by the research team.





The research team was able to recreate task deaths and confirming the issues in the software architecture. Memory corruption(Memory corruption is nothing but a condition where a 0 becomes a 1 or vice versa - common in digital systems which is easily avoidable) was surprisingly a common thing on the Toyota's software. The research team reported Spaghetti code - use of overly complex control structures using industry bad practices like GOTO Statements and unstructured control branching. Almost all types of bad programming practices were there in their code!





This means that Toyota used substandard software programming on their vehicles causing death and injuries. Being a software engineer myself, I can imagine the surprise researchers had when they found out about Toyota's code! I'm sure Toyota isn't the only one having issues with their software.

Honestly, I always have a chilling sensation down my spine whenever I step into cars having drive by wire systems, knowing that my driver instincts and reflexes have ZERO control if something goes wrong inside the car's ECU! I will never trust self driving cars either!

If anyone fancy reading the whole ECU software research findings from which I took the screenshots off, refer this, its quite interesting if you're into these kind of reads.

If anyone likes to read the court transcript of the case where Toyota was proven guilty, go here

One can somewhat say that it is impossible to create unbreakable code and is impossible to test it 100%, but multiple independent fail proof systems can be put into place to ensure passenger safety.