Abstract: This paper describes testing framework that is capable of testing heterogeneous embedded systems. There are three key contributions. The first is the introduction of a new approach of embedded system testing. The second is simple and efficient embedded system classifier interface, named as discovery interface device for embedded system. The third key contribution is a method for combining classifiers in one module, provides environment and testing methodology for embedded system testing. A set of different experiments in the domain of testing of embedded system is presented. This system yields of embedded system testing comparable to the best previous system implemented on traditional embedded software testing tools. This approach is capable to testing of host based and target based embedded systems.
Keywords: DID-Discovery interface device, HBT- Host based embedded system testing, and TBT- Target based embedded system testing.
Testing is most commonly used method for determining quality of software. In the embedded world testing is a great challenge. In test plan sole characteristics of Embedded systems must be reflected as they are bequest systems. So giving embedded systems testing exclusive and distinct flavor. There are two important classes of embedded systems, safety critical embedded systems and technical scientific algorithm based embedded systems. Host based embedded devices and target based embedded devices are sub classification for embedded systems. This paper brings together new approach and methodology to construct a frame work for heterogeneous and extremely complex embedded testing. Toward this end we have constructed a discovery interface device which provides classification and identification of embedded system as well as responsible for selection of testing methodology, this discovery interface device is the new concept in the embedded world. In the traditional testing approaches decision has to be made that whether to test hardware or software, but instead of finding heterogeneous testing techniques focus is on developing a mechanism which will assemble together all techniques of testing, This approach is capable to test host based and target based embedded system testing. Reminder of paper contains characteristics of embedded systems for soft real time and hard real time, literature survey, proposed methodology, experimental setup, conclusion, future scope and references.
Characteristics of Soft Real-Time and Hard Real Time Embedded Systems
Get your grade
or your money back
using our Essay Writing Service!
Before performing actual embedded software testing or hardware testing, embedded system testing characteristics are identified.  Embedded characteristics are different for soft as well as hard real time system, on the basis of which we can design test cases for testing.
For the soft real time system, first characteristics is embedded characteristics, as embedded system is application specific and dedicated to specific task in a specific runtime environment, it is very difficult for testers to test the system in host based or target based pattern and run the host based system to target based and target based on host based.
Second characteristic is interaction; it is used for system application and execution. An interaction is very important characteristics in the operation of embedded system. Inter task communication, parallel execution of multiple users task, resource sharing and strict priority based execution among multitask application are playing important role in testing. Failures of interactions among these may lead priority inversion and other execution anomalies.
Third characteristic is development practice where supporting platform and interfaces plays an important role.
Fourth characteristic is timeliness, timeliness is critical and a major concern in both design and testing phases in hard real time embedded systems. Timeliness is used to determine whether the system is meeting real time constraint or not. In soft real time embedded systems sometimes timing issues are not so much important.
This testing approach gives solution to testing of heterogeneous embedded systems. In a safety critical environment testing is risk based testing. We can test ten numbers of different embedded systems in a one universal embedded system testing platform. Our experimental result shows that our method is promising for deployment in real applications.
Embedded system testing is not a simple task ,it varies application to application, like software testing embedded system is also test manually as well as automatically. Some of the embedded system testing uses simulation based verification when new multi core application arises, so in order to improve the quality of software the test generation frame work is used static analysis, mutation testing and the model checking is used for the message passing programming libraries for distributed embedded system. The verification simulation testing model checking could be used in order to check the equivalency between the original program and the program with inserting fault depend on the result .The fault is detected by model checker used in order to generate the test cases. No time out were used for C bounded model checker, no scalability will explored in order to test. Unique test cases are used MCAPI which has no longer benchmark. 
Always on Time
Marked to Standard
Due to diverse architecture of software between the embedded systems, make it difficult to reuse, portability and dependability. Middleware is software between operating system and an application to solve any beginning problem some middleware consists of API module service manager and content manager module. API module is used with interface to communicate with lower and upper layer the application of touch screen for the embedded, middleware system is used in order to verify usability. functionality and the integrated test of embedded middleware used communication between system to system, operating system to libraries ,libraries to application were the issues related to the diverse architecture embedded system such issues were solved somewhere in some extend.
Some embedded software testers use supporting tool for embedded software testing. Embedded system requires hardware for testing purposes having very high development cost. Supporting tool can automatically generate test cases and test drivers, and supports coverage test and unit test which are based cross testing technology and multiple round mechanism results can be shown graphically by using constructed testing environment. The (ATEMES) Automatic testing environment for multi core embedded software is composed of four parts pre-processing module (PRPM), Host-side auto testing module (HSATM), Target-side auto-testing module (TSATM) and the last is post processing module. 
The construction and application of electronic port gate system, which is vivid application scenario of internet of vehicles, will benefits the entry and exit of vehicles for quick clearance guidance. It is also a great help for the monitoring of comprehensive import the efficiency of entry and exit port is a significant improvement on administrative work. 
Traditional PLC software about programming and monitoring all were designed in serial port debugging mode based on local. So the remote monitoring and controlling function couldn't be realized in the mode. In the article the virtual serial port (VSP) technology was imported into the system and it turned the PLC serial port software from local control function to remote one. 
The proposed methodology for research work is as shown in Figure 1. This is a new design approach for embedded systems testing, several embedded testing activity are performed simultaneously.
The designing of embedded system testing will contain the designing of the following systems, test interface design
Design of embedded systems
Test code for module testing
Module testing interface design
Test Automation and flow Design
Test cases and test code
Test script statement and flow
Test flow script interpreter
The testing of embedded system can be performed here on the basis of two types Host based testing and Target based testing. The very first module is the development of discovery interface design. The proposed plan is related to the testing of embedded devices.
This testing mechanism is divided in to three parts such as general testing, internal testing, and external testing. General testing is performed on components that are basically used in embedded devices and without that the circuit can't be complete, such as, capacitor, sensor, etc.
Internal testing deals with low-level implementation. Here each function or component is tested. This testing is accomplished by the implementation teams. This focus is also called clear-box testing, or sometimes white-box testing, because all details are visible to the test.
Test Case Interface
Fig. 1. Proposed Plan of work
Discovery interface design is responsible to identify and to discover drivers and API interfaces for circuit. Figure 2 shows the block diagram of discovery interface design. Microsoft has urbanized one operating system called WinCE for embedded systems. Device makers and OEMs are licensed by Microsoft. The OEMs and device makers provides functionality to transform and generate their own user interfaces. They also support MIPS, and ARM processors, and also the current version of Windows Embedded Compact supports Intel x86 and compatibles.
Windows CE kernel can also work with minimum capacity memory (Megabytes of memory). Devices may be configured as a "closed" system that does not allow for end-user expansion, example can be given as; it can be burned into ROM as they are frequently configured without disk storage space.  Windows CE competes to a real-time operating system characterization having deterministic interrupt latency. From Version 3 and forward, the system uses priority inheritance for dealing with priority inversion and priorities levels are 256. For this system thread is the fundamental unit of execution so execution time gets reduced and simplifies the interface.
This Essay is
a Student's Work
This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.Examples of our work
API (application programming interface) is an interface used by software components to communicate with each other. This may include specifications for routines, data structures, object classes, and variables An API may describes the way in which particular task is performed. In procedural languages like C language the action is usually medicated by a function call. Hence the API usually includes a description of all the functions/routines it provides.
Fig. 2. Block Diagram of Discovery Interface Design
MSP SDK 6.0 the MSP development SDK which is an add-on for the media service portal site and it gives the necessary tools and documentation for programming the MSP APIs included in the SDK is the Developers Guide.
For supervision of the execution of .NET programmers in a process known as Just in time compilation, Common language runtime (CLR) is used which is a virtual machine component of Microsoft's .NET framework .Here the compiled code is converted into machine instruction that, in turn, are executed by the computers CPU. Memory management, type safety, exception handling and some additional functionality are also given by CLR.
The basic aim of discovery interface design is to test whether hardware is present on embedded or not. Detection of system in order to categorize it as, in which group it is lying safety critical or of technical scientific.
Fig. 3. Proposed Architecture for DID(Discovery Interface Design)
Host based testing in Embedded Systems
In the host based testing, we are performing performance and load testing of hardware.  Basic aim is to find out which feature and facilities are provided by embedded system. In future we can also find out the details of processor used in embedded systems. To describe host based testing, small experiment is performed that is named as memory management.
To interact with hardware plug-ins are required. This is dynamically linked file which interact with system driver like mobile O.S. and will fetch low level information for hardware. In computing, a plug-in (or plug n) is a set of software components that adds specific abilities to a larger software application. Emulator provide virtual environment for mobile OS.HBT is used for all types of mobile phones, for tabs, mobiles having different operating system like android based symbion based window based on so on .
Fig.4. Approach-1 HBT, host based testing
Fig. 5. Approach-1 Results for host based testing
Here experimental results are shown to demonstrate host based testing, software program is written and embedded via cable to Mobile phone containing window CE operating system responsible to perform memory detection and platform detection.
Target based testing
Figure 6 introduces an approach for target based testing.  Embedded system contains application software which is directly and indirectly dependent on many other low-level software components. The target hardware may contain set of LCD display, a touch panel and a keypad. The application software is responsible to display graphics on the LCD screen, and it reads user input from the touch panel and keypad. The application code uses Application Programmer Interface functions and structures provided by basic middleware and a real time operating system (RTOS) kernel. The basic middleware code requires device drivers and the RTOS requires target specific components for their program execution. The device drivers and the target specific components of the RTOS kernel will execute only if the hardware is present at target side. Therefore, even when the application code does not directly depend on the target hardware, it cannot execute without it as other software components in the system depend on the target hardware for their execution. Therefore, the embedded application developer will need target hardware to develop and test his application code. Target hardware for embedded application development is generally available in the form of hardware reference boards.
Companies developing products based on embedded systems developers understand the fact that high quality and distinctive application software plays an important role in the differentiation of their products from their competitors. As a result, the majority of embedded software developers are engaged in developing differentiating, high quality applications using off-the-shelf middleware, device drivers and RTOS kernels. The problem faced by the embedded system application developers is that using hardware reference boards for application development is both expensive and complex..
Fig. 6. Approach-2 Target based testing for embedded system testing.
Buying hardware reference boards for each specific and dedicated application development of embedded system increases product development costs. Hardware reference boards require specialized development tools and connection probes that further add to the development cost. Hardware reference boards are difficult to set-up and use. The situation becomes too worse if it is yet to be decided which hardware should be used as a target base. In such case, the dependency on a hardware reference board will delay the application development. All of these factors are responsible for making hardware reference boards an unfavorable choice for embedded system application software development. 
Justification of research is achieved after performing smaller experiments on host based and target based embedded devices. These results are associated with target based testing. Testing is performed on different embedded devices and its components over one environment with the help of serial port data transmission, USB port data transmission, and parallel port data transmission. In the USB Port data transmission again host based embedded system testing and target based embedded system testing are performed
In host based mobiles, laptops are tested and in target based all type of printers are tested. Due to application specific characteristics, it is not possible for tester to test embedded device with one tool.
Case Study 1:
Serial port Testing-
Testing components of embedded device like LED, Relay, motor etc.
Manual Testing Results:
Figure 7 shows embedded device testing over serial port, for devise testing it is connected to com port one. After getting ok signal from controller we are ready to test different component of embedded device. For LED testing we have to send "LEDON" command on port, Controller listen to this command and perform task as given after completion will get the acknowledgement signal Relay testing also performed in these module
Fig. 7. Serial Data Transmission
Coding for setting of Serial Port Communucation:
private void UserInitialization()
_spManager = new SerialPortManager();
SerialSettings mySerialSettings = _spManager.CurrentSerialSettings;
serialSettingsBindingSource.DataSource = mySerialSettings;
portNameComboBox.DataSource = mySerialSettings.PortNameCollection;
baudRateComboBox.DataSource = mySerialSettings.BaudRateCollection;
dataBitsComboBox.DataSource = mySerialSettings.DataBitsCollection;
parityComboBox.DataSource = Enum.GetValues(typeof(System.IO.Ports.Parity));
stopBitsComboBox.DataSource = Enum.GetValues(typeof(System.IO.Ports.StopBits));
_spManager.NewSerialDataRecieved += new EventHandler<SerialDataEventArgs>(_spManager_NewSerialDataRecieved);
this.FormClosing += new FormClosingEventHandler(MainForm_FormClosing);
Fig. 8. USB port Testing
A major contributing factor in the success of USB as a peripheral interface has been the close adherence to the specification and the testing program that ensures USB interoperability. There are several instances in which might need to test USB port, might have built a computer and need to see that the port is properly connected, or a drive had plugged into the port could have suddenly stopped working, and need to determine the cause.
Figure 8 is for extracting information of any USB device connected on USB device, for any device there is particular product ID and virtual ID number, with the help of which we can extract information of that particular device.
We can tests performance of any flash drive device with the help of this module, logic is on the runtime we are writing one dummy file of particular size in a defined loop and we are calculating average performance.
Fig. 9. Performance of Flash drive
We have introduced a new approach for the testing of heterogeneous embedded systems in a real time environment. The Temb model serves as basis for heterogeneous embedded system testing. Testing of ten number of embedded system under one tool is not possible as testing of mobile is not similar to testing of card of washing machine, each embedded system requires its own specific tool.
Embedded systems are connected via serial port parallel port or via USB, are detected and identified by Discovery interface design. Discovery interface categorized it as safety critical embedded systems and technical scientific based embedded systems. For the host based embedded system memory management experiment is explained and for target based testing USB testing and flash performance testing is explained. Under one single environment target based as well as host based testing is achieved. We are proposing universal methodology for testing of heterogeneous embedded system
A set of different experiments in the domain of testing of embedded systems is presented. This approach is capable to test host based and target based embedded system testing. Low level testing methodology for embedded systems is proposed here. Our experimental result shows that our method is promising for deployment in real applications. To save energy, stamina and time; there is a requirement of advance methodology. This paper describes testing framework that is capable of testing several embedded systems and embedded system components. Future scope is development of testing tool for heterogeneous embedded system and embedding an artificial intelligence approach for improving embedded system testing.