I was asked a question in the interview, the question is, suppose you have depeloped embedded system, you done hardware and software test and system is working fine then you deployed system at client location if after some time there is fault generate in the system how will you fix the fault ?

I said I will do the hardware and software test again to find out fault. but the interviwer was not convinced with my answer.

What will your answer for this question ?

I will tell you his answer after one I get your answer

 

I'm not a coder so I don't know what approach to take solving the issue. What I would do in the case of electrical wiring is to isolate the front half from the back half, then test for expected results on each side. If the fault appears to be in the front section I would divide THAT section in half and again test for fault location. Should the fault be in the back half of the first segment then I'm closing in on where the fault may be. It could be a loose plug or a mis-wired pin.

Assuming your system works and was installed and working but then later developed a fault I'd start with looking at the power supply. If its voltage has dropped off perhaps that's affecting something in the code or sensors or whatever the circuitry may be. If the supply is good then I'd check for the load on the supply. If the system is expected to draw 2000mA (2A) and it's drawing 3000mA then I'd suspect that some electronic component has failed. Since most IT experts don't troubleshoot and repair circuit boards it's likely you may have a board to replace with a known good. If there are multiple points of connection I'd start by isolating the system (in half) and again checking for anticipated loads. If the loads are in spec then I'd know that it's in the second half. If things are modular it may be easier to swap modules and see if things go right. If you remove and replace module 37-A,21 and the system now works then you've found your fault. At that point you can send the module back for manufacturing servicing OR if the cost is low enough you can just scrap that module.

But again, I'm not the IT expert here, so I'd just be guessing.

 

Ask how/when it failed.
Apply the sniff test.
Inspect for anything amiss - unplugged/damaged cables, overheated or damaged components, etc.
Then you can begin actually testing stuff.

 

read the status code that was set by error capture script. Guide user through hardware diagnostics, or code update procedure. If it appears to be onboard hardware failure, rush them out a replacement board, update as required, and determine the necessity at replacing current installations.

 

As an embedded systems engineer for several decades, I would say that you need to provide the "scaffolding" in your code for troubleshooting and debugging on the live system at the customer site. Even better if you can correct and rebuild the firmware onsite.

 

Agree with Papa. I think that the correct answer would be that you had to plan for that during the product development and then you would activate whatever you put in to get diagnostic information.

Bob

 

I asked answer to the question at the end of interview. he asked me if your mobile phone ever stop working or hangs then what do you do, I said I would reset phone

He said simillary microcontroller have watchdog timer that are used to reset system

I still can't convince myself this is right answer

 

Q1: after some time there is fault generate in the system how will you fix the fault ?

He said simillary microcontroller have watchdog timer that are used to reset system
hi micro,
If you had given me that answer during an interview, you would not get employed by me.
E

Update:
Ask yourself, what is the purpose of a watch dog timer.?

 

I asked answer to the question at the end of interview. he asked me if your mobile phone ever stop working or hangs then what do you do, I said I would reset phone

He said simillary microcontroller have watchdog timer that are used to reset system

I still can't convince myself this is right answer

I think that is manifestly the WRONG answer. The question posed in the thread title was: "how will you test system"? The "you" in this interrogatory is a systems developer, not an end user. I can tell you from decades of experience that resetting, or power cycling is NOT a particularly effective method of testing or getting to the root cause of a problem. I have a mountain of contempt for that interviewer.

 

I was responsible for maintaining 20 functional test systems. One morning the line supervisor came and 'all the boards are failing on all the testy bays'. There had been no change to the test systems since the last time these boards had been run.

So how would you tackle this?

I took my known good board out to the line and it passed the test.
So I did a 'spot the difference' between the good board and one of the failing boards. This almost instantly revealed the problem. There was a 28 pin DIL socket on the board for an EEPROM and the line had failed to fit that chip.

 

Stuck in an infinite reset loop. Probably not the team you want to work for.

 

Persons conducting interviews are often from HR departments and don’t have a clue about what they are saying.

 

Persons conducting interviews are often from HR departments and don’t have a clue about what they are saying.

Sometimes that is also true of the department manager you might end up working for, especially if nepotism or friendship circumstances are involved. This is extraordinarily reckless when large amounts of corporate debt or investor funds are at stake. It happens more than you might suspect or believe.

It has been suggested that half of the companies in the S&P 500 in the year 2000, no longer exist. Some of this might be due to mergers and acquisitions rather than bankruptcy, but it is kind of a startling assertion.