Forums

A physical test emulator for embedded systems.

Started by omert 4 months ago10 replieslatest reply 4 months ago77 views

 Hi everyone, 

I have an idea for fast and realistic tests in embedded development environment. 

Problem: 

Embedded software development is depended on hardware a lot, any delay or interruption in hardware development affects the software development too. 

I think most of you will agree on this point, which is hardware development takes a lot of space in project timeline and once it is matured and ready to develop/test, the remaining time for software developers is very tight.

Usually we setup some circuitry around target MCU or CPU with passive components, so we replicate the PCB functions as much as possible. 

But in some scenarios we need to have time based functions or communication messages or variable analog responses etc. So our circuitry setup might not be that efficient to handle all of these. We might run some scripts in software to test these but again it might not be realistic as testing with physical components.

So this makes our development process quite slow and easy to fail in some extend.

Solution: 

My solution has 3 parts which are desktop interface, a code generator server and emulator MCU. I offer that we create our test scenarios and models in an user interface on desktop and this goes to a server, test scenarios gets converted to test code and being sent to emulator MCU thru OTA. Yet, we test our application with emulator MCU which actually imitates application PCB responses physically. 


I put the system diagram here.

screenshot from 2020-04-23 15-16-50_5879


My question is assuming there is a product like this in the market, would you buy and use it ? Do you see my problem and solution valid ? 

Best regards,
Ömer


[ - ]
Reply by DilbertoApril 23, 2020

Hi Ömer!

In my case I work with very small products, basically, Cortex M0, M0+, or M3, ranging from 8K to 128k of program memory, few analog stuff, and simple communication interfaces.

In the past, I used to use software simulators but it seems they are not available anymore for these µControllers. And, of course, they are a disaster concerning timing requirements, voltage levels, and simultaneity of events.

Nowadays I make extensive use of proven libraries, both mine and of third parts, which shortens the debug path length. Obviously, this is not enough to cope with the deadline of the project as the hardware people deliver it in the eve.   :-) 

Perhaps your approach is more suitable for larger projects, with multi-core application processors, rich color graphics, high-speed comm interfaces, high-performance instrumentation sensors, or other things like that.

That poses a doubt: will your physical emulation system be able to cope with these requirements, like high-speed multitasking, very tight timing specs, etc.?

Hope this is useful.

Daniel.


 

[ - ]
Reply by omertApril 24, 2020

Hi Daniel, 

Thanks for your reply. I will start answering from bottom to top.

That poses a doubt: will your physical emulation system be able to cope with these requirements, like high-speed multitasking, very tight timing specs, etc.?

A: It is just a concept now, but however if it becomes a product one day, I wouldn't expect to perform such requirements in v1.0. The emulator MCU would be a WiFi enabled module  like a ESP32 or TI CCXX which supports OTA. You can do a lot with these modules if your development doesn't require very high speed actions. 


Perhaps your approach is more suitable for larger projects, with multi-core application processors..

A: Well, it can fit to this case but not necessarily in v1.0


Nowadays I make extensive use of proven libraries, both mine and of third parts, which shortens the debug path length. Obviously, this is not enough to cope with the deadline of the project as the hardware people deliver it in the eve.   :-) 

A: I take the last sentence as confirmation of my problem :).


In the past, I used to use software simulators but it seems they are not available anymore for these µControllers. And, of course, they are a disaster concerning timing requirements, voltage levels, and simultaneity of events.

A: I used also some software simulators like Proteus, I was doing some stuff with PIC series. As per as I remember they don't have much support for various microcontrollers and they are expensive. Quality of simulation takes the project up to a point but it sucks in some extend. You need to have natural response from hardware to complete the project. 


In my case I work with very small products, basically, Cortex M0, M0+, or M3, ranging from 8K to 128k of program memory, few analog stuff, and simple communication interfaces.

A: My development cases are not much different than yours, I just wanna do something for us, to make test process more convenient and getting isolated from hardware people failures. :)


[ - ]
Reply by CustomSargeApril 23, 2020

I've been down this rabbit hole a few times and found it to be a zero sum game. The complexity of the test side roughly equals the objective side with similar uncertainties. So you just doubled the task scope.

I build smaller type objects. I start with as close an approximation in hardware as I can to let the software start getting structured. Then it's a matter of iterative convergence by both. But I suspect that becomes ineffective as complexity ramps up. My $.02 <<<)))

[ - ]
Reply by omertApril 24, 2020

Well, the plan is making it a product which you can purchase and write down (or draw) test scenarios in your desktop thru an interface, then test the scenario in emulator MCU by a click. So design in virtual get responses in real basically. 


It aims to make your dev-test cycles convenient. I am just trying to understand if it makes sense for you :)

[ - ]
Reply by std_logic_vectorApril 29, 2020
Hi Ömer!

we test our software in this way but our Emulator is not MCUs but FPGAs so that we can create very precise timing behavior (ns level).

Best regards,

Xuepeng

[ - ]
Reply by MichaelKellettApril 23, 2020

Such tools already exist - notable suppliers are D-Space and Mathworks (software). D-Space do lots of hardware in the loop stuff.

This kind of approach is widely used in aerospace and automotive. Typically you would design and simulate the system at a very high level of abstraction in MATLAB and associated tools and migrate to test hardware but still using the same model. Mathworks can support (limited) work of this type using Arduino or Raspberry pi but the software costs £10ks and serious hardware a lot more. 


It's a long time since I was involved in this kind of work -  I think it's the wrong approach.

The real problem is that it's taking too long to get the hardware - fix that - restructure the design process to be agile in hardware and get prototypes out quickly. Not always possible but often it is.

MK

[ - ]
Reply by omertApril 24, 2020

I knew that you can do some modeling in Mathworks and it converts to C code, you can use this for test purposes. How convenient ? I don't know. Also I know that these tools are expensive. Because they made for many purposes. 

I haven't heard about D-Space honestly.

Hardware development has a lot of phases, I don't think we can optimize it with focusing on design part only. It has production, assembly etc. But definitely, it worthes to study about it.

[ - ]
Reply by BVRameshApril 23, 2020

You can make the complete project int several portions and each one you can develop it on PC and test it extensively and use the same code in the project using cross compiler and emulator.

The only major difference will be the timing an you should be very careful in simulating those on PC as PC will have enough power during simulation it will work very well there, whereas you may come to stumbling blocks when you port over to the target.

Using core simulators also will not give you enough advantage regarding timing assessment as emulators will give a lot of lag and certain critical things as interrupt service you can never trust core simulators.

Even JTAG based emulators or debugging support from the core manufacturer will lack critical timing information.

The best way is to chalk the project from highest to lowest priority from timing point, and try them out first, for example, the modules which use ISR, Timer based tasks, critical communication tasks, you code them on target and test them thoroughly, giving enough margin.

All the other modules which are not time critical you can develop them on pC and port them wher you may have to do around 10-15% of modifications.

Regards,

BV Ramesh.


[ - ]
Reply by iansApril 24, 2020
A former colleague of mine has been working in this area for some time:

https://www.synopsys.com/

and as other posters have mentioned there are a number of companies who are developing solutions for exactly this type of problem.

The down side is of course that they are intended for commercial use and some of the licence costs are pretty scary, but it is a non-trivial problem and while there are basic simulators available today as soon as you try to emulate anything most than the simplest examples (particularly if you are simulating external interfaces) they rapidly become either useless or unrealistic as the complexity racks up.

As a hobby project it's an interesting activity, but for commercial use I would question whether you could emulate more than a tiny subset of possible scenarios in sufficient detail.

[ - ]
Reply by omertApril 25, 2020

As you know everything goes step by step, it might start with tiny subset of possible scenarios then could be converted to an advanced testing emulator. By the way may I have the contact of former colleague if you don't mind. 

I have sent contact request on Linkedin. 

Thanks :)