3Proposed_architecture.tex

%!TEX root = thesis.tex

\chapter{Proposed Architecture}
\label{chapter:Proposed architecture}

Based on the requirements pointed out in Chapter~\ref{chapter:Payment terminal acceptance testing}, this part of the master's thesis will present an architecture for automated acceptance testing environment for payment terminal software. Components of the environment can be divided into hardware and software components and this Chapter is divided to sections accordingly.

In order to automate the acceptance testing of the payment terminals, test environment that can manipulate and observe the device through physical means has to be created. In other words, environment has to have some sort of a robot for pressing the buttons and screen of the device has to be observed. All this must be also controlled by some kind of combination of software.

Motivation for this research came from a payment terminal software provider as they needed a cost-efficient and simple automated acceptance test environment in order to lower the costs and speed up the acceptance testing process of their software development. Costs of automated acceptance testing can be divided into three parts: environment costs, costs of creating new tests and maintenance costs \citep{laapas2014cost}. This Chapter will present an automated acceptance testing environment that is intended to minimize the costs of each part of this division.

Eficode Oy took responsibility of implementing the system according to the best practices of the industry. This proposal was initial plan for the project and it will be presented in this Chapter.

\section{Overview}

When planning an automated acceptance test environment for payment terminal software, environment has to be highly adaptive for different types of hardware and software features of different payment terminal models. This proposal was done for one payment terminal software provider who had several different models of payment terminals and altogether over 50 different software configurations for those devices.

Security is a top priority of payment terminal electronics and software. Therefore, it is not possible to access internals of the payment terminal hardware. This means that AAT environment has to be able to manipulate the physical interface of the device. This also creates requirement for supporting different types of keyboard layouts and screen locations. In other words, environment cannot be dependent of single manufacturer or payment terminal model.

One of the requirements for the AAT environment was also usage of open source technologies. For the reasons pointed out in Section~\ref{section:Open source}, customer wanted that the environment is as open as possible. This also creates reputation and visibility regarding the security matters.

Other requirements for the AAT environment was simplicity, low cost, low need for maintenance and ability to run the tests continuously around the clock.

\section{Hardware}
\label{section:Proposed hardware}

Hardware for this proposal was intendedly kept simple and low-cost as possible. This proposal presents the use of just one Raspberry Pi 2 Mode B \citep{raspberry} computer as a main computer for AAT environment. Raspberry Pi 2 is proposed as it offers sufficient computing power for this project with low purchasing costs and can run a full Linux operating system. It is also small-sized and does not require any cooling equipment. Therefore, it suites well to this project as it can be situated easily to the environment and can be run continuously around the clock without concerns about wearing cooling fans for example.

\FloatBarrier
\subsection{The Robot}
\label{subsection:The Robot proposal}

As internal electronics of the payment terminals are not accessible for security reasons, a robot is needed to be able to manipulate the physical UI of the payment terminals. The robot should therefore be able to accommodate different types of payment terminals and be able to press all types of buttons. Low cost and low need for maintenance are also requirements for this robot, as required by the customer. The robot should also be able to manipulate multiple payment terminals at the same time in order to allow parallel execution of acceptance tests. This is intended to reduce the time acceptance testing process takes overall, as the same tests have to be run on different models of payment terminals. Other option would be to make the changing of the device under test easy and fast so that the manual work required can be minimized.

One of the options for automating the pressing of the buttons of the payment terminals would be to manufacture a frame on top the payment terminal which would have actuators for pressing each button. This would allow quick entering of key sequences and simultaneous pressing of multiple buttons. Hobby-grade servo motors could be used as actuators in order to make this solution affordable. However, in order to support different kind of keyboard layouts and different sized payment terminals, the solution would require advanced mechanical engineering and thus the price of this solution could rise to become cost-ineffective for the customer. For these reasons, this option for payment terminal manipulator was not chosen.

Other option for automatically pressing the buttons of the payment terminals would be utilizing the use of robotic arm. A robotic arm would be able to emulate a human user accurately and depending on the used robotic arm, simultaneous pressing of the buttons could also be possible. Drawback on the use a robotic arm is the relatively high purchasing price of accurate and powerful robotic arms. This could be overcame by manufacturing the robotic arm with own resources and using some openly available plans \citep{bcn3d} but this would require extensive use of time for building the arm from bottom up. For these reasons, the use robotic arm was not chosen.

Third option for automating the key strokes of the payment terminal would be to use a cartesian coordinate robot (CCR). Cartesian coordinate robot is a robot whose axis of control are linear and are perpendicular to each other \citep{costa1995three}. For pressing of one key of the payment terminal at a time would need a cartesian coordinate robot with at least three degrees of freedom allowing the robot to move in three dimensional space. For the scope of this project, this would be enough as it is only required to press one button of the payment terminal at a time. CCR would also be easily able to adapt to different kinds of keyboard layouts and payment terminal sizes as it can travel across any coordinates within its workspace. By choosing a CCR with a right-sized work space, it could be also possible to accommodate multiple payment terminals to the workspace at the same time. This would allow the execution of parallel acceptance tests within several different devices at the same time. For these reasons, the use of a CCR for manipulating the buttons of the payment terminals was chosen.

The master's thesis proposes the use of ShapeOko 2 3-axis Computer Numerical Control (CNC) milling machine \citep{shapeoko} to be used as a manipulator. Even though the machine is intended for milling purposes, it can be turned into a cartesian coordinate robot when milling tool is removed. As ShapeOko 2 is a CCR with horizontal member supported at both ends, it can be also referred as a gantry robot as it resembles a gantry crane.

ShapeOko 2 is an open-source hardware project and plans of the machine are openly available on their GitHub \citep{shapeoko_git}. This allows easy modifications to the hardware parts of the robot if needed.

ShapeOko 2 is controlled by an Arduino board running a program called GRBL \citep{grbl}. Controlling program is an open-source, high-performance G-code interpreter and it is used for controlling CNC milling machines in general \citep{shapeoko}. G-code commands are sent from Raspberry Pi 2 to the Arduino on the robot using serial communication.

Robot should be equipped with a pushing tool that can be manipulate the buttons. Pushing tool can be easily manufactured using for example 3D-printing techniques. Design of the pushing tool can be seen in Figure~\ref{fig:pushing_tool}

\FloatBarrier
\subsection{Computer Vision Hardware}
\label{subsection:computer vision hardware}

In order to automate human interaction with the payment terminals, AAT environment has to be able to observe the changing content on the screen of the payment terminal. As stated earlier, internal electronics are not accessible due to the security measures and this disallows for example the possibly to intercept the LCD communication line of the payment terminal in order to retrieve the image on the screen programmatically.

Therefore, AAT environment also requires computer vision as changes on the screen have to be observed visually. Manufacturer of Raspberry Pi offers low-price solution for this as a form of Raspberry Pi Camera Module \citep{raspberry_camera}. This module was chosen for use in computer vision tasks of the AAT environment.

As the size and the location of the display differs between different models of payment terminals, optical hardware has to be able to adapt to different kinds of imaging circumstances. As it is proposed that working area of the robot could be equipped with several payment terminals at the same time, also the displays of the payment terminals have to be able to be read regardless of the number of the devices under test.

One solution for this could be equipping the AAT environment with multiple stationary cameras, more precisely one camera per each device under test. If the cameras would be stationary, this would create boundaries for the location and the size of payment terminal displays depending on the location of the optical hardware. Cartesian coordinate robot proposed also has a rigid structure moving on top of the devices under test and this could cause blocking of the visual contact between camera and the display of the payment terminal.

Other solution would be having a moving camera that could be driven to a needed location in order to perform machine vision tasks. Location of the display could be configured regarding to the payment terminal model and this solution would adapt easily for different kinds of display layouts. Moving of the camera equipment can be achieved easily by attaching the camera directly to the robot. This will however exclude the ability to simultaneously pressing the buttons and reading the screen as robot has to be driven to certain position for capturing the image from the display. Regardless of this limitation, this solution was chosen. More precisely, the camera was situated to the Z-axis assembly of the robot to the other side in respect to the pushing tool. This would minimize the required transitions when changing from pressing the buttons to capturing the images as the displays are typically located on top the numeric keypads on the payment terminals.

\FloatBarrier
\subsection{Card Feeder}
\label{subsection:Card feeder}

In addition to the manipulation of the payment terminal buttons, also the card feeding functionality has to be automated. One option to accomplish this functionality would be using the ShapeOko 2 robot for inserting and removing the card from the payment terminal. This would require an attachment to the payment card in order to make the manipulation of the card possible with the same tool that is used to push the buttons of the devices under test. The AAT environment software would also require some kind of reset functionality in case the software would crash and the position of the card would be lost. Manipulation of the payment cards with the ShapeOko 2 robot would also make overall testing process slower as it would not be possible to press the buttons while inserting or removing the payment card to or from the payment terminal.

Other option would be manufacturing generally adaptable card feeders that could be used with different kinds of payment terminals. This solution would allow simultaneously inserting and removing of the payment card while manipulating the buttons with the robot. Advantage of this solution would also be that card feeders could know their state even if the software would crash as well as the reset functionality would be more simple to implement.

As insertion and removal of the credit card might be hard to accomplish in a simple way using just the robot described in previous section. This work proposes the use of generally designed card feeders to accomplish this task. Proposed card feeders consist of 3D-printed base plate that attaches to the payment terminal, servo motor and 3D-printed tray that attaches to the servo and to the credit card. Design of the card feeder can be seen in Figure~\ref{fig:card_feeder}

Card feeders were designed in a way that they can be used with any types payment terminals that have the card slot at the bottom side of the device. Standard hobby servos were used as servo motors in order to keep the cost of the setup low.

Arduino board will be used to drive the servos as it can easily provide the needed pulse width modulated (PWM) signal for the servos. Arduino is suggested in order to ensure quality and accuracy of the PWM signal compared to what can be produced easily with non-real-time operating system running on the Raspberry Pi. Raspberry Pi on the robot will communicate with Arduino through serial communication.

\section{Software}
\label{section:software}

As stated in the section \ref{section:test suite syntax}, automated acceptance tests should be simple and understandable enough to actually make the automated testing efficient and beneficial. Open source solutions should be favored as this was requested by the customer and to achieve benefits described in the Section \ref{section:Open source}. For these reasons, software decisions of the AAT environment should be carefully considered in order to achieve good maintainability, compatibility and overall simplicity.

For software part of this AAT environment, Raspbian Wheezy is proposed for the operating system. Raspbian is the official supported operating system for Raspberry Pi by Raspberry Pi Foundation \citep{raspbian}. Raspbian is based on widely-used Debian Unix-like operating system. This allows the use of components developed for Debian to be used with this AAT environment.

\FloatBarrier
\subsection{Test Framework}
\label{subsection:test framework}

Based on the guidelines and comparison presented in Section \ref{section:test suite syntax}, the choice for test framework was considered in order to achieve the best usability, versatility and functionality. In order to maximize these measures, Robot Framework was chosen for the test framework. RF is an open-source, generic, keyword-driven test automation framework that has human readable test case syntax \citep{Rfuserguide}, \citep{robotframework}.

Robot Framework also has highly modular software architecture \citep{Rfuserguide} which allows the framework to be used with variety of testing libraries to connect to the system under test. This feature can be seen as a great advantage when implementing test libraries for machine control and computer vision. Illustration of this modular architecture can be seen in Figure~\ref{fig:modular_architecture} below.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[width=11cm]{images/architecture-big.png}
    \caption{Illustration of modular software architecture of Robot Framework \citep{rf-architecture}.}
    \label{fig:modular_architecture}
  \end{center}
\end{figure}
\FloatBarrier

When RF tests are being executed, it generates clear report and log files of the test case execution results \citep{Rfuserguide}. These files offer high level view of all test cases and step-by-step descriptions of individual test cases in order to make the debugging more easy.

Example of a test case can be seen in Figure~\ref{fig:invalid_pin_test}. This test case describes automated RF acceptance test for entering invalid PIN code when trying to execute card purchase.

\begin{figure}[ht]
  \begin{center}
    \includegraphics[width=\textwidth]{images/example_test.png}
    \caption{Example test case for invalid PIN code test}
    \label{fig:invalid_pin_test}
  \end{center}
\end{figure}

\FloatBarrier
\subsection{Test Libraries}
\label{subsection:test libraries}

As can be seen on Figure~\ref{fig:modular_architecture}, RF requires external libraries to connect to the system under test. In the case of this AAT environment, those libraries would be a library for machine control, a library for computer vision and a library for card feeder manipulation. All these libraries can be written using Python programming language that is supported out of the box by Robot Framework \citep{robotframework}.

For machine control library, the environment has to be able to send G-code commands through universal serial bus (USB) connection to Arduino on the robot. For this, pySerial Python library is proposed as it includes implementation of the needed serial communication functionalities \citep{pyserial}.

For the computer vision tasks of the environment, textual messages on the display are usually those that need to be verified. For this, character recognition is needed. Open source optical character recognition (OCR) engine called Tesseract OCR was chosen \citep{tesseract}. It was initially developed by HP but since 2006 it has been developed by Google. In order to use Tesseract OCR with Python, a library named pytesseract was used \citep{pytesseract}.

Library for controlling the card feeders is the most simplest one of these three libraries. For this, pySerial Python library was also chosen to send the serial communication command to the Arduino controlling the card feeders. Library will handle sending of control commands to the Arduino controlling the card feeder servo motors.