Embedded Controller Tests

The traditional software testing techniques were used to test the DAS controller model. This included testing each sub-model and verifying each sub-model operation using simulations (i.e. external mode feature). The DAS controller model implementation was simulated using a discrete solver option with a fixed step size. This was because the controller operates in the digital domain, with no continuous states. The fixed step size was set at 1µ (0.000001) steps. A smaller step size gives better accuracy, at the expense of simulation duration (i.e. it takes longer to simulate).

The DAS controller model indicates the high-level model of the system operation and interface to the DAS signal conditioning card. The model was tuned and evaluated, running from the target hardware using external mode feature of the Simulink® environment. In this mode, the model was compiled, loaded and executed on the Arduino® _{Due platform. The}

platform then runs the model in real time, and this allows the model to read and see what the target hardware was reporting. The Simulink® sink library blocks (i.e. display, scopes, simout, and others) are then used to display data reported by the target hardware. This was made possible by the server that was loaded automatically by Simulink® _{on the model running on}

Department of Electrical and Mining Engineering 76 (Xue and Chen, 2013). The data collected was compared and verified with multimeter measurements. The test set-up consists of the Arduino® _{Due platform, with channel inputs}

injected with DC voltage 0V, 1.5V and 3.3V. Measurements taken by the model were compared with measurements taken by the digital multimeter. The test set-up is shown in Figure 3.4.

Figure 3.4 DAS controller model test set-up

The DAS controller model was made of subsystems which perform different tasks to

Department of Electrical and Mining Engineering 78 The vector concatenate block was used to pack the measured data into a 12 x 1 vector matrix. The data is packed into contiguous locations in memory. Therefore, the output of the block is a contiguous output signal with 12 elements containing the measured signals. The data format sent by this model through the serial port is indicated in Figure 3.6.

Data Transmission subsystem is used to transmit data through the serial port to the host system. The Arduino® Due hardware platform provides access to two serial ports. Port1 interface is shown in Figure 3.7. The signal generated and received on the serial port RX1 and TX1 pins are at 3.3V transistor-transistor logic (TTL) levels. A signal level shifter or UBS-to- Serial converter (see Figure 3.4) was required to directly connect the Arduino® Due serial port pins and the host system serial port.

One of these subsystems is the Data Acquisition subsystem. The Data Acquisition subsystem model is highlighted in Figure 3.8. It consists of 12 inputs and one enable input. It contains other subsystems and MATLAB® function blocks to process acquired data. It contains the ADC Channels, Relay Data, Data Formatting and Data Transmission subsystems.

The enable input was used to control the Data Acquisition subsystem block. The whole subsystem can be enabled or disabled. The display and simout blocks are used to view, debug and verify data collected by the model.

The ADC Channels subsystem’s task was to read analogue inputs and pack sampled data. It was made of 12 analogue input blocks, which measure signals connected to channel A0 to A11 on the Arduino® Due hardware platform and the vector concatenate18 block. The ADC Channels subsystem model is shown in Figure 3.9. The display and simout blocks are used to view, debug and verify data collected by the model. The Arduino® _{Due hardware platform}

illustrating the ADC channels is shown in Figure 3.10.

Figure 3.6 Data message structure

The control subsystem’s task was to control the data acquisition process. The model receives a command sent by the host system, then decodes the command and executes the instruction.

The model consists of Arduino® serial receiver block19_{, a Command processing and Control}

signals subsystems. The control subsystem model can be seen in Figure 3.12. A

HyperTerminal application was used to send predefined command messages (Figure 6.9 and Figure 6.10) to the control subsystem model. The display and simout blocks were used to view, debug and verify data collected by the model.

Department of Electrical and Mining Engineering 80 Figure 3.7 Serial port interface

Department of Electrical and Mining Engineering 82 Figure 3.9 ADC channels subsystem

Figure 3.10 Arduino® Due hardware platform ADC channels

The System Alive subsystem was tested by measuring the signal generated on pin 51. This is shown in Figure 3.11

Department of Electrical and Mining Engineering 84 Figure 3.12 Control subsystem model

3.6 Host Controller Tests

The host system consists of a laptop/PC and GUI designed to interact with the DAS controller. Traditional software testing techniques are used to test the DAS Host controller application. This included testing each sub-module and verifying each sub-module’s operation using simulations. The components making up the DAS host user interface and layout are shown in Figure 3.13. The functions of each user interface (UI) components were tested using the set-up shown in Figure 3.4.

Department of Electrical and Mining Engineering 86 First, all buttons and checklist modules were tested. The host system UI generates events as the components were clicked or selected. These events contain algorithms that will perform operations on the data and generate messages to provide information to the user. These modules were tested using the simulation and debug feature of the MATLAB® GUI programming environment.

The command and communication modules were then tested. The DAS controller receives instructions from the host in response to events generated by the start or stop buttons. The DAS controller responds to the instruction and then sends data requested by the host system. These modules are tested using the simulation and debug feature of the MATLAB® GUI programming environment with USB-Serial Converter connected to the host system. This enabled the application to open the serial port used to send or receive data. A HyperTerminal application was used to send commands to the host controller GUI to evoke events generated by data received on the serial port. The HyperTerminal application was also used to verify data sent by the host controller GUI. This allowed verification of the commands structure Figure 3.14.

Figure 3.14 Start of data acquisition process command message structure As already indicated, the DAS controller receives instructions from the host in response to events generated by the start or stop buttons. Thereafter, the DAS controller responds to the

instruction and then sends data requested by the host system Figure 3.15.

Figure 3.15 Data message structure

The data storage and displaying modules were tested last. A HyperTerminal application was used to send data to the host controller GUI to evoke events used to plot the captured data on the axes component and the storage of data in a text file. The file was saved in text format, with data separated by commas. The data was saved in the following format: first number was the sample number, which was followed by a comma and the actual processed ADC data (equation 3.1) in fixed-point notation form, with six points precision.

•_•••= !"#$∗ '()•••*••

+, -∗ ,./0#$/.••"

(3.1)