Embedded system where the HW is not always available, difficult to debug and to test.
Problem:
Imagine that you develop in a complex embedded environment when the SW development is done in parallel to the HW development. Basically there is no option for you to test the SW till the HW is ready. Even when the HW is ready it is usually very slow to debug on the actual HW and in some cases only few HW devices are available for testing.
To make things even more problematic imagine that the code you develop requires several devices to perform a test, for instance in case you develop some network protocol that needs to interface with one or more devices to perform its operation.
Solution:
The proposed solution is based on development of HW simulator that can run on PC environment. Compilers of embedded OS (e.g. VxWorks) has an option to compile the code for X86 processors and have a version of the code running on PC environment.
Ha ha ha, well you think it's that easy? Imagine that part of your code (as often occurs in embedded systems) is writing data to FPGA, ASIC or other HW devices. Of course such code will fail on the PC environment since the actual HW does not exist.
So what can you do in order to test your code on PC environment? The answer resides in my 1st post: http://ranlevy-swarchitecture.blogspot.com/2009/10/decoupling-sw-from-platform.html. All you need to is to code plugins for PC environment that can simulate for you access for the HW and can simulate for you various events that are generated by the HW. A major issue to notice is that basically the application code remains unchanged.
Implications:
- Development Efforts: well indeed there is some development overhead in creating a project for PC environment, writing plugins for PC env. and so forth. However, the efforts really worth the extra development since the total development cost is dramatically reduced since debugging and testing are becoming much easier.
- Testing: SW that works well on the simulator environment will be easier to work well on the target, but of course it MUST be tested on the actual system. A common mistake in implementing "dummy" PC plugins that always return success. Such behavior might mislead application to developer from coding and testing the "bad" path of each flow. Beware!!!
- Debugging: debugging in simulator mode is much easier than the actual embedded system which is usually much more complex.
- Performance: the relatively good performance that might be achieved in PC environment are usually much slower in the actual embedded system since it uses slower CPU, memory, disk, etc. Therefore performance must be tested as soon as the HW is available and an extrapolation of the performance from the PC env. to the HW environment must be available for early performance prediction.
- Compilation: compilation of the code for several architectures usually improves the code stability since sometimes the compiler detects potential errors that are not detected for other architecture.
