Embedded System SW/HW Integration Process

1 Introduction

Every real-time embedded project has three major constraints: scope, cost, and schedule. In order to help project management ensure that all the three constraints are kept under control, this document provides a guideline for the embedded project SW/HW integration test process.

2 Scope

Starting from the real-time embedded project development life cycle perspective, this article focuses on the description of prerequisites, procedures, and resources for a particular stage, Software/Hardware (SW/HW) Integration, which is critical and time consuming.

3 Embedded Project Development Lifecycle

Figure 3-1 shows a typical life cycle of real-time embedded project development process. The process starts from a system requirement document (SRD), from which hardware requirement documents (HWRD), firmware requirement document (FWRD) if there is/are FPGA(s), and software requirement documents (SWRD) are derived. After the requirement documents are approved, and before the SW/HW integration testing starts, the hardware development activity, firmware development activity, and software development activity can be considered to be concurrent, providing that the interfaces between them are defined. From the high level management perspective, an embedded project life cycle can be divided to six stages: Initiation, Design, Implementation, Integration, Validation and Verification (V&V), Quality Assurance (QA) and Configuration Management (CM). In particular, QA activities are executed throughout the lifecycle of the process. Figure 3‑1 also indicates when the baseline of each stage is formed and where the check points of the lifecycle are.

Figure 3-1

4 SW/HW Integration Process

It can be seen from Figure 3‑1 that SW/HW integration test takes place after the target hardware and software modules are tested and ready. In addition, a good test plan and other resources are necessary to facilitate the activity.

4.1 Integration Prerequisites

There are prerequisite requirements that must be met before SW/HW integration test can be conducted efficiently.

4.1.1 Hardware Assembly

The target hardware assembly must be ready for integration test, which means the hardware must be fully tested, such as power supplies, clock, reset, watchdog, inputs, outputs, analog signal conditioning, scaling, drives, cables, etc, must be verified completely.

Some projects may not have a CPLD or FPGA device on the hardware. However, if there is one, make sure the firmware for the device is programmed and the device is configured properly.

4.1.2 Software Readiness

Real-time embedded project software usually consists of three layers, the hardware driver layer, the middleware layer, and the application layer. The code of all the three layers must be completed, and functions, modules should be tested as much as possible without the target hardware. Sometimes, the software can be tested on an evaluation board of the DSP/DSC used for the project. The source code should have been checked into the source control database.

4.1.3 Integration Test Plan

An integration test plan, which contains an introduction, entry criteria, test strategy, test cases and procedures, resource list, problem recording and resolution method, and exit criteria should be prepared and approved.

4.1.4 Test Tools and Equipment

Test tools and equipment include signal generators, power supplies, oscilloscope, probes, multi-meters, analyzer, test console, etc, depending on the requirements of the project, must be prepared.

4.1.5 Human Resources

The most responsible human resources are the software developers, firmware developers, and the hardware developers, while other resources are needed to provide support and cooperation. The role and participation of the human resources are shown in Table 4‑1.

Table 4‑1 Role and Participation

4.2 SW/HW Integration

Once all the prerequisites are ready, the SW/HW integration test can be started. The main purpose of the integration test is to verify that the software performs the required functions and features together with the target hardware. A bottom-up approach should be used to test the embedded software, i.e., debug the hardware drivers first, and then debug the middleware, and lastly debug the application code, which is shown in Figure 4‑1. A detailed SW/HW integration test process diagram is shown in Figure 4‑2, with the description of the steps given below.

Figure 4-1 Bottom-Up Test Approach

Figure 4-2 Real-Time Embedded SW/HW Integration Test Process

4.2.1 Sett Up Debugging Environment

Debugging a real-time embedded system could take a period of time from days to months. Every time starting a debugging session, make sure the main power source is switched on, test equipment is ready, test console is running, and the debugging connections are ready. Don’t assume that everything should be the same as the last debugging session as anything could happen during the debugging breaks.

4.2.2 Debugging Hardware Drivers

Debugging a real-time embedded system starts from the debugging of the hardware drivers, which not only finds out the bugs in the various driver modules, but also verifies the correctness of the hardware. The typical aspects of hardware driver debugging include the following:

·         Make sure the DSP/DSC emulator is connected to the target

·         Make sure the system reset signal is at normal state

·         Make sure the CPU clock is running at the designed frequency

·         Make sure the internal and external watchdogs are turned off

·         Check memory integrity

·         Verify CPU clock configuration

·         Test initialization code of each hardware module

·         Check each digital I/O pins to be at its initial state

·         Test ADC/DAC conversions

·         Verify input/output analog signal scaling

·         If there is a complex FPGA device on the target hardware, pay particular attention to the FPGA interface to make sure that the functionalities, accuracy, and the timing of the FPGA code are correct.

·         Verify gate drive logic

·         Verify fault detection logic

·         Test the communication protocols

·         Test any other hardware drivers

4.2.3 Debugging Middleware

The middleware for a real-time embedded project refers to the task scheduler, Finite State Machine (FSM), algorithms, control laws, etc.

·         To be deterministic, each task should be scheduled to execute in an assigned time slot and complete its execution within the time slot with at least 25% margin. Time overrun is not allowed.

·         Each state of FSM should be tested with all transition-in/-out conditions

·         Debug algorithms to verify their function and accuracy. In particular, if the DSP/DSC is fixed point type, high precision mathematical functions are done in software, so the calculation range and resolution of each variable must be verified.

Each function of the control laws must be debugged carefully. With the assistance of a test console and oscilloscope, monitor the state, amplitude, timing, and waveforms of the internal data of the control modules.

4.2.4 Debugging Application Code

After the debugging of the hardware drivers and the middleware are completed, the last step is to debug the application layer. The purpose of the debugging of this layer is to verify that the response of the system corresponds to the command, and the outputs of the system correspond to the inputs, correctly and timely. It is in this layer, the high voltage and high current may apply to the system, so be careful of the following:

·         Over voltage fault

·         Over current fault

·         Over temperature fault

·         Human safety

·         Avoid debugging this layer alone

4.2.5 Evaluate Performance

Even though all the layers of the software are debugged, it does not mean the integration process is completed. The performance of the system must be evaluated against the system requirements in terms of accuracy and completeness. For example, there might be monitor lane requirements in addition to the control lane requirements. If there are any discrepancies, modify the software to meet the system requirements.

4.2.6 Problem Reporting

Whenever and whatever a problem is discovered during the test, a PR should be generated in the problem reporting system (MKS) according to the problem reporting process. Analyze the cause of a problem to identify whether it is a hardware problem, firmware problem, or software problem. Fix the problem and restart the testing. If there are any requirement changes, the change control process should be followed.

4.2.7 Closing Actions

After the system requirements are satisfied, the system can be delivered to system engineers and V&V engineers for system test and verification test.

The hardware, firmware, and software engineers are responsible for documenting the test data, lessons learned, updating design documents, and checking the documents and source code into the respective databases.

4.3 Conclusion

At the end, there are other points worth mentioning.

Good preparation and planning of the hardware, firmware, software, and resources are the assurances of productive integration test. Lack of any of the prerequisites would slow down the integration progress ultimately.

On the other hand, documentations are often neglected, or paid less regard to. One reason is that developers are tendentiously more interested in developing than documentation; another reason is the resources are quickly assigned to the next project.

However, it is both necessary and beneficial to keeping good project history and the improvement of the later projects.

Although multiple iterations of the debugging sequence might not be avoidable, good design of software layers and thorough debugging of each layer could reduce the iterations.

Always power off the system during work breaks, because some accidents may not occur during a short period of debugging, but do occur over a long period of time.