ECU test

[conkel]

Hello everyone,

First l like to thank you all for a nice forum.
I am working with developing an ECU which will contents some functions (the functions itself will not be tested by me). The main task for the ECU is to control the functionality so those functions can run correctly.

I would like to ask what type of test possibility are they to test the ECU. I would like to make it more automatically and more advance testing or maybe using HIL (Hardware in Loop)

Normally, I have done some few test scenarios but tell you the true l can not come up with new scenarios.

My test scenarios:
--Running the ECU and activate it and deactivate it several times.
--Boot up test, to check the input is activating correctly
--CAN test, let the ECU go to "sleep" and then wake it up

ECU overview:
It has 4 inputs and the ECU itself is connected to other ECUs at the same time.


Thank you,

[Powertron]

Are you trying to verify that the ECU meets the design specification or are you trying to identify the reliability of the ECU? If you could describe the application that you are using the ECU in that might help us provide you with more better recommendations on what tests to perform. Have you performed any EMC/EMI tests on the ECU? I am guessing that ECU stands for Electronic Control Unit.

[conkel]

Thank you for your response.

Yes you are right with ECU stands for Electronic Control Unit.
Actually l am trying to do both....first to verify the ECU meets the design specification and also identify the reliability of the ECU.

The application which is used in the ECU, is a c code which has function to control the FPGA part, Master and slave Micro controllers and handle the inputs (in this case sensors) so the functions in ECU works correct. At the same time the ECU has the CAN interface receving/transmitting information to other ECUs.

What is EMC/EMI tests? I have never done it before.

Thank you,

[Powertron]

Besides doing the obvious checks that you have already mentioned, it might be worthwhile to check the operation of the ECU under conditions that maybe weren't encountered on the bench during development.

As one example of a design verification step, you might verify that the inputs/outputs and other functions operate correctly with an ambient temperature at the upper or lower design limit and with the input power to the ECU at the upper or lower design limit at the same time.

The level of design verification you need to do also depends on the end application. For example, an ECU used on a factory floor will see different operating conditions than an ECU that will be used inside a car or inside a house.

EMC/EMI are tests usually done to see if the ECU works with electrical noise present. Does the CAN interface still communicate with the other ECU's when electrical noise is present next to the communication cables or next to the sensor input cables? How does the ECU do if there is a voltage spike or dip on the input supply voltage? Does the ECU have a microcontroller and if it does is there a hardware or software watchdog to restart the ECU if the microcontroller should stop working during an electrical transient?

One more point, if you designed the ECU (hardware or software or both) then, if at all possible, someone else should verify the design using the specification as a guideline. A fresh pair of eyes will find more issues!

[conkel]

So the CAN interface is always communicate with the other ECU's when electrical noice is appering.
I mean from my point of view the electrical noise might be a important part to test but not that I should put main focus on it. The noice from communication cables, is more less in my case quite low to count it.
Same for the noice from the sensors which bring the data is also low in this case.

If we have a voltage spike, or dip, it is not a big deal because the ECU itself is done to handle those things. Our ECU can deal from 9 V up to 16 Volt so that should not be a problem. If we have a for second lower than 9V then the ECU will be out of picture, that means will not work as all other electronic parts.

The ECU has 2 microcontroller and we do have a watchdog checking if the microcontroller all the time.

Your tests are correct and l am thankful for your advice, but l am also intersting to test more other things as;

-->We have for our ECU diffierent of SW version which we flash it with,
which test secnarious are the best to test those SW's versions on the
ECU. Normally l flash the new SW and do the same scenarious (as l
wrote before) and then it is done.

-->How do l know if my new SW is better/fit better to my ECU. Of course l
can see if the SW is acting correct or not. But I am interesting to test
the SW itself very detailed.

-->The ECU is done for vehicles, which scenarious could be useful to do
when it is connceted in the vehicle? Are they any stress tests good,
and if so, which one? What can I test when the ECU is connceted with
all other ECU's?



Thank you,

[Powertron]

Software algorithms used in a vehicle ECU are implemented to prevent electrical noise from interfering with the operation of the ECU and the CAN commincations. The input operating voltage range for a vehicle ECU is typically from 6V to 20V, so your 9V to 16V range seems quite limited. With regard to software verification, have you had your software reviewed? Sometimes, having someone else do a software review can identify software reliability issues very quickly. And if the software was not written to be easily followed and understandable by someone other than the software designer, that might indicate underlying reliability issues. Basic functionallity is usually easy to check, it is addressing the real world issues that make designing a reliable product challenging.

[conkel]

Yes you right but as l wrote to you before, in my case the noise factor is quite low so l would not put so much time on it. Some tests has been done.

Typical operation voltage range for our ECU is around 9-16V, we are designing our unit on the following range.
I have SW review for every release, but that do not mean the task is finished. We have, as in my case also, the task of the Test engineer which has to verify the SW and make the SW relese process, thats why l asked concerning the test scenarious.

I dont get you in this point, why should it be an indicate underlying reliability issues if the SW is not written to be easily followed?