Embedded Testing: Key to Ensuring System Stability and Reliability

Taking the “Water Flow Monitoring Billing Device” project as an example for relevant testing explanation.

(Image source: Internet)

For testing the simulated water flow monitoring billing device, it is first necessary to define the relevant protocols. For example, three custom communication types are defined: Protocol_1, Protocol_2, and CH_232_1. In the specific implementation, taking Protocol_1 as an example, its protocol includes multiple fields such as header, valve controller ID, water flow monitoring billing device ID, instantaneous flow, billing flag, pipeline pressure, checksum, and footer. Each field has specific default values and data types.

Testing requirements include multiple aspects. In the data collection and processing of the valve controller, once the software starts collecting, it opens the serial port, and the valve controller periodically (every 1s) sends instantaneous flow, billing flag, and pipeline pressure data to the system under test, which displays the received data on the software interface. At the same time, to ensure fault tolerance of the collected data, truncation processing must be performed when the collected data exceeds the range. In terms of controlling pipeline pressure, the pressure is controlled based on the pipeline pressure sent by the valve controller, limiting the water flow pressure in the pipeline to a certain range. In the instantaneous flow alarm processing, when the collected instantaneous flow is greater than or equal to 300m³, an instantaneous flow alarm prompt is given on the software interface. In the flow billing processing, when the collected billing flag is 1, the accumulated flow calculation for the received instantaneous flow must be performed, and the amount to be charged for the accumulated flow must be calculated.

(Image source: Internet)

During the testing process, fault tolerance handling of interfaces also needs to be considered. For example, during input interface handling, fault tolerance of data frame format must be considered, including correctly locating the start of a data frame, handling cases where the water flow monitoring billing device ID is not equal to 0x20, and situations where the checksum field has errors. During output interface handling, it is necessary to fill out the data frame format strictly, including filling in fixed value items, correctly filling in the valve controller ID, correctly calculating the checksum field, and ensuring that the “instantaneous flow alarm flag” and “pipeline pressure control command” do not output values outside the specified range.

In summary, the stability and reliability of embedded systems depend on improving the quality at all stages from hardware to upper-level software. In each stage of testing, different content is focused on, and different tools are required. Compared to pure software testing, embedded systems are more deeply integrated at the application end. Therefore, the corresponding capabilities need to be enhanced.