Designreport Group 14

University of Cape Town
EEE4113F
Engineering Design
Final Report
Authors: Student Numbers:

Keegan Crankshaw CRNKEE002
Taremekedzwa Mudzokora MDZTAR002
Joseph Adriano Nemours NMRJOS001
Nigel Mukandi MKNNIG001
Siphosethu Anthony Gxako GXKSIP001
22 April 2018
Contents
1 Problem Analysis 8
1.1 Background Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Initial interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Unpacking the interviews . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 The Team’s Point of View . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Low level Prototypes 11

2.1 Feedback on low level prototypes . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Deliberations based on feedback from the interviews . . . . . . . . . . 12
2.2 Final Design Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Important Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 STEEPLE Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 OPM Diagram and V-Model . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Brief Outline of Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Structural Design 18
3.1 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Requirements Analysis and functional/requirement tree . . . . . . . . . . . . 20
3.4.1 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.1 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.2 All possible solutions that the group listed both social solutions and
electrical-engineering based solutions . . . . . . . . . . . . . . . . . . . 26
3.5.3 Second Interviews were conducted to find out which solution better
addressed the needs of the passengers and met the course requirements 26
3.5.4 Final Design Chosen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 V Diagram and possible constraints/bottlenecks . . . . . . . . . . . . . . . . . 27
3.6.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.2 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.3 Possible Technical Disruptions . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1
3.7.1 OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7.2 Simulation for design strength . . . . . . . . . . . . . . . . . . . . . . 30
3.7.3 Possible Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7.4 Statistical Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Network Design - Taremekedzwa Mudzokora 31

4.1 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Requirements Analysis and Functional/Requirement tree . . . . . . . 32
4.3 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Possible Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2 Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.3 Final selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 V Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5.1 OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Back-end Software Design - Keegan Crankshaw 45

5.1 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Design Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5.1 Comparison of options . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6.1 V Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6.3 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2
5.7 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7.1 OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7.2 Simulation of Sub-Module . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.8 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6 Hardware Design and Testing 55

6.1 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.5 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5.1 Final Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.6.1 V Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.6.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7.1 OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7.2 Internal Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.7.3 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7 Hardware Design 76
7.1 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.4 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.5 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5.1 Possible Methods and Comaprison . . . . . . . . . . . . . . . . . . . . 80
7.5.2 Final Design Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.6.1 V Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.6.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.7 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3
7.7.1 OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.7.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.8 Potential Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8 Conclusion 90
8.1 Overview of project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4
List of Figures
1 Unpacking the interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Unpacking the interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 The summary of the activity leading to the point of view . . . . . . . . . . . 10
4 Low level design prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5 The OPM Diagram for the overall design . . . . . . . . . . . . . . . . . . . . 15
6 The V Diagram for the overall design . . . . . . . . . . . . . . . . . . . . . . . 16
7 Casing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8 USB port specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9 Components to be included . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12 V Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13 STEEPLE Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14 OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15 FEM simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
17 V diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
18 OPM diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
19 Simulink simulation of the wireless communication via the GPRS (GSM) . . 39
20 The building blocks of the transmitter . . . . . . . . . . . . . . . . . . . . . . 40
21 Simulink block illustration developing the coding scheme . . . . . . . . . . . . 40
22 Simulink block illustration developing the modulation scheme . . . . . . . . . 41
23 The building blocks of the receiver . . . . . . . . . . . . . . . . . . . . . . . . 41
24 Simulink block illustration developing the demodulation scheme . . . . . . . . 41
25 Simulink block illustration developing the decoding scheme . . . . . . . . . . 41
26 Simulink block illustration of the channel . . . . . . . . . . . . . . . . . . . . 42
27 a plot showing an improvement on the BER of a system with Interleaving and
without Interleaving using Coding and FEC . . . . . . . . . . . . . . . . . . . 43
28 An example of how a simple API operates . . . . . . . . . . . . . . . . . . . . 49
29 The Requirement Tree for the Module . . . . . . . . . . . . . . . . . . . . . . 50
30 V Diagram for implementing Back-end Software . . . . . . . . . . . . . . . . 51
31 An OPM diagram indicating the use of the API to the user. . . . . . . . . . . 53
Listing 1 Simple code saving a new user 53

32 Block diagram representation of peripherals needed on microcontroller . . . . 58
33 Multi-ISO Reader Core and Reader boards . . . . . . . . . . . . . . . . . . . 59
34 NFC RFID Smart Card Reader . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5
35 Thermal printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
36 Colour Touch Screen Module for Arduino . . . . . . . . . . . . . . . . . . . . 62
37 Graphic Symbol Font LCD Display Module Blue Backlight and keypad . . . 63
38 9V battery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
39 Arduino mega 2560 OEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
40 V diagram showing lifecycle of hardware design for the Smart Ticket Machine 68
41 OPM Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
42 Internal block diagram showing the connection among the main hardware
components of the Smart Ticket Machine (STM) . . . . . . . . . . . . . . . . 72
43 State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
44 Reliability bath tub [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
45 The MTBF as a function of number of years number of years of operation of
the Arduino Uno microcontroller board. [1] . . . . . . . . . . . . . . . . . . . 75
46 V Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
47 Top Level Data for Customer Payments . . . . . . . . . . . . . . . . . . . . . 84
48 Top Level OPM Diagram showing the architecture for web application . . . . 85
49 (a) Top Level Form Verification Model (b) Detailed Form Verification Model 86
50 Status Integrity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
51 Simulation Result signup API endpoint . . . . . . . . . . . . . . . . . . . . . 87
52 Simulation Result signin API endpoint . . . . . . . . . . . . . . . . . . . . . . 87
53 Simulation Request for protected resources with web token . . . . . . . . . . 87
54 Simulation Request for protected resources without web token . . . . . . . . . 88
55 Attempt to create user with already existing credentials . . . . . . . . . . . . 88
56 Database with hashed passwords for security . . . . . . . . . . . . . . . . . . 89
57 Form verification simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
58 Time GET requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6
List of Tables
I Feedback on Idea 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
II Feedback on Idea 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
III GXKSIP001 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IV User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
V R1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VI R2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VII R3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VIII Analysis of R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
IX Analysis of R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
X Analysis of R6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
XI Analysis of R7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
XII MDZTAR002 ELO table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
XIII User requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
XIV ber vs SNR with or without coding and interleaving . . . . . . . . . . . . . . 43
XV CRNKEE002 ELO table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
XVI User requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
XVIINMRJOS001 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
XVIIIUser requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
XIX Final Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
XX Technical Disruptions of Hardware, its impact on the device and ways to
respond to it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
XXI MKNNIG001 ELO Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
XXIIAccount access, status and updates . . . . . . . . . . . . . . . . . . . . . . . . 77
XXIIIPayment Options and Processing . . . . . . . . . . . . . . . . . . . . . . . . . 77
XXIVSecurity and Data Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
XXVUser Interface and User Experience . . . . . . . . . . . . . . . . . . . . . . . . 78
XXVISoftware and Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . 79
7
1 Problem Analysis
1.1 Background Description

The original problem statement given was:
How the commutation and travel by Minibus-taxis might be made safer in an

environment where the cab-owners do not have much capital for improving the
cabs and the commuters are ready to compromise safety for a cheaper and reliable
way to commute.
Through various interviews and deliberations through d-School initiated activities (as detailed
in the subsections of this section).
1.2 Initial interviews

In order to gain better insight into what the experience of the average person may be,
interviews were conducted. The team went to various points, and interviewed the following
people:
1. Ma Aggie, a member of the UCT cleaning staff and frequent taxi user
2. Two male university students, Kuziwa and Andy
3. An elderly female at taxi rank who is an everyday taxi user
4. Foreign UCT student in early 20s who is not a frequent taxi user
5. A high-school student, 16 years of age
The transcripts of these interviews can be found in Appendix ??
1.2.1 Unpacking the interviews
The interviews that had been conducted were broken down in an activity as displayed in
Figure 1.
Figure 1: Unpacking the interviews
8
The above points were considered by the team and discussed in detail. The team came to
realize that most taxi drivers do not care about the number of passengers in the vehicle, so
long as more money was involved. The outcome of the activity coming to this conclusion is
shown in Figure 2.
Figure 2: Unpacking the interviews
1.2.2 The Team’s Point of View
In order to try and compress the problem down to something the team could tackle and
confidently solve, the above perspectives of the passengers was distilled down to something
more manageable. This was done by creating a point of view that encompassed a user, a
context, a need, and an insight:
User:
Identify the users according to their profession or the activity that makes them need to
take a taxi.
9
Context:
Define the setting of the statement.
Need:
Identify the principle need that makes the user rely on the taxi service.
Insight:
Provide facts that will give a deeper and more accurate understanding of the point of
view.
The summary of the activity leading to the POV can be shown in figure 3.
Figure 3: The summary of the activity leading to the point of view
Finally, the point of view was formulated as follows:
A UCT staff cleaning staff member and a frequent taxi user, who needs a safe and
convenient means of travel to work daily in a world that is is willing to compromise
safety for money.
1.3 Design Choices

From the information obtained through interviews, our brainstorming sessions, and multiple
other sources, we realized that the safety of the taxi industry in its current state would
be difficult to change in a way that is high-impact, without somehow altering the current
infrastructure or adding a service to allow the industry to become more safe. Ultimately,
allowing high-impact change without completely uprooting the current infrastructure and
process (which would be detrimental to the thousands of South Africans using the taxi
service every day) entails the creation of products and services that would allow all parties
involved to expand their service offering. This means that the industry can go on as is, and
10
slowly adopt new features and functions enabled by new frameworks and services we could
provide.
Given the constraints, the team decided to prototype two ideas. The first idea was a simple
implementation of Driver Identity Cards roughly A4 sized posters displayed to occupants in
the taxi, showing them a photograph and name of the driver, along with their licence, the
licence plate number of the taxi, and numbers the occupants can call if they feel it would be
necessary to contact someone about the driver, their behaviours, or anything else that would
require some form of reporting or feedback. The second device was a small box that would
enable cashless payments based on SmartID cards. Users would be able to load credits on to
their cards and pay that way. The device could refuse payments if it knows that the taxi is
overloaded, and eventually be incorporated into social grant structure (as it is based on ID
number). Relative to each other, Idea 1 is low difficulty, with the potential for low impact,
whereas Idea 2 is high difficulty with potential for high impact.
2 Low level Prototypes

Images of the low-level prototypes can be found in Figure 4.
Figure 4: Low level design prototypes.
2.1 Feedback on low level prototypes

The team, having designed low-level prototypes for two addressable problems, set out to gain
feedback from users of the taxi system. The transcripts for the interviews can be found in
Appendix ??.
Summarized feedback from the interviews can be found in the ”Feedback Grids” below. Each
block in the grid represents a different type of feedback, namely: What worked, What could
be improved, Cons, and Ideas from those we interviewed. The feedback for Idea 1 (the driver
ID cards) can be found in Table I and for Idea 2 (the cashless payment system) in II.
11
Table I: Feedback on Idea 1
Worked Could be Improved

- People feel safer as drivers are more
accountable - Being certain of the information
- The driver feels more responsible to be included
as they are now accountable to their actions
Cons Ideas
- Taxi drivers may be opposed to it as
they feel they may be unfairly N/A
reported and lose their jobs
Table II: Feedback on Idea 2
Worked Could be Improved

-The device decreases fear, as there is
less cash involved, so robberies are
- Sometimes drivers prefer cash
less likely.
- Entering in an ID Number when
- Increases safety for passengers,
a card is not available will likely
as they do not have to carry cash.
take too long.
- Actual amounts charged, no
concern for getting change or not.
Cons Ideas
- Print receipts
- What about the apprehension of the
- Pay for multiple tickets
older generation with new technology?
- Incorporation of fingerprint for
- What if you lose your ID?
those who lose their card
2.1.1 Deliberations based on feedback from the interviews
For Idea 1 (poster), we were impressed at how eager people were with the idea, one
interviewee going so far to say theyd implement it immediately, if they had the authority.
While we realize that very few drivers may be opposed to it, the feedback from passengers
shows that its definitely something worth implementing.
For Idea 2 (ID payment system), the feedback we received was quite invaluable. We have
decided to add the possibility to pay for multiple tickets, as well as printing a receipt if it is
done (to prevent passengers being charged for more tickets than they pay for). Fingerprints
may be a good idea, but given the speed requirements, just tapping the card would likely be
faster. In terms of those opposed to the idea, we reiterate: this new system does not replace
12
the cash system, it works alongside it as a cashless alternative for those concerned about
their safety.
2.2 Final Design Choice

Given the requirements of the client (The Department of Electrical Engineering, UCT)
namely that the system needs to be electronic in nature, Idea 2 (the ID payment system) was
chosen. A more detailed explanation as to why can be given in Sections 2.2.1 and 2.2.2.
2.2.1 Important Questions
• Does the system meet user requirements?

From feedback on interviews, it was agreed by members of Group 14 that ID Pay does
indeed meet user requirements of safety and convenience/speed (the two biggest factors
of the initial problem statement).
• Does the user need this?

Passengers need to feel safer on public transport, for the betterment of their physical
and mental health and well-being. A constructive way to do this which not only meets
these requirements but allows for the implementation of new features and functionality,
is move to a cashless system based on ID number, which is what ID Pay implements.
• Is it probable? Is it possible?
Many cashless payment systems have been implemented, and the technology to do so
is easily accessible and relatively cheap.
• Does it wow?
Walking into a minibus taxi and simply swiping your wallet against a box is a smooth,
simple, painless method of paying for tickets which is drastically better than the
stressful, tedious and time-consuming job of fishing for cash, and waiting anxiously
for change. The simplicity and elegance of this system is sure to impress.
• Is it impactful?
By basing the system on ID numbers, there is much opportunity for high impact change.
To begin with, users would simply load credits to a system tied to their ID number.
But over time, through government involvement, users could pay for anything, and
have various subsidies based on their social standing (for example, funding). There has
already been a push towards this level of cross-field implementation in order to simplify
not only the bureaucracy involved in providing social grants, but also bettering the lives
of citizens by simplifying pre-existing systems. A perfect example of this coalescence is
the recent introduction of SASSA (South African Social Security Agency) debit cards.
13
2.2.2 STEEPLE Analysis
In order to be in accord with what Group 14 considers good engineering design practice,
we take into consideration what is known as STEEPLE Analysis Social, Technical,
Environmental, Economic, Political, Legal and Ethical contextual analysis. Below is a
breakdown of all these aspects:
• Social
ID Pay is considered to have a net positive social impact. Based on the interviews, we
know that most parties involved are excited and accepting of the idea, some surprised
by how this has not yet been implemented.
• Technical
ID Pay does not require any major technical breakthroughs, it is constructed out of
pre-existing components which are readily available.
• Environmental
ID Pay produces no excess waste as it is not a system based on consumption. Rather,
once the device is in the world, that is all. As the device is made of existing components
which already exist readily, production is fairly low-impact, too.
• Economic
Future integration of ID Pay with social grants means that there is a positive impact
on the financial lives of users. There is also no risk of having your money stolen, which
is better for users, too.
• Political
There is the issue of slow adaptation of the system into government programs, so the
first roll-out will be implemented using privately owned infrastructure.
• Legal and ethical

The only issue we foresee is that users have an issue with their ID number being used.
However this was not brought up in any of the interviews, and as a result we believe the
concern is not too large. Users are still able to pay with cash if they feel uncomfortable
using ID Pay.
2.3 Selection
2.3.1 OPM Diagram and V-Model
The overall OPM diagram can be found in Figure 5, and the V diagram can be seen in Figure
6.
14
Function
Cashless Payment
Means
Increase credit
Pay With ID Card
balance
Swipe Smart ID Artiﬁcial payment

Veriﬁcation
Card system (testing env.)
Smart ID with
Backend system
positive balance
Capturing Device
Authentication Balance updating
Battery RFID reader Screen Printing receipt Keypad Antenna/Comms
Figure 5: The OPM Diagram for the overall design
2.3.2 Brief Outline of Modules
The design has been split into 5 modules, as follows:
• Front-end Software Design

Nigel Mukandi will be responsible for designing a web portal based on the Back-end
system, where users can register and check and update balances. Security concerns,
accessibility and ease of use must be taken into account. Various levels of prototypes
will need to be developed, and consideration for development framework must be taken
into account.
• Back-end Systems Design

Keegan Crankshaw will be responsible for creating and testing the API and back-end
systems that the front-end software and hardware will implement in order to provide
users with the expected quality of service. Various hosting options will be considered,
along with security concerns (authentication and validation).
• Hardware Design
Joseph Adriano Nemours will be responsible for implementing hardware testing -
gathering required components and implementing them on a suitable microcontroller
based on requirements stipulated. Joseph will be responsible for designing appropriate
tests and test benches.
• Structural Design
15
V Diagram
System Requirements Verification
Cashless payment Meet functional requirements
Pay with Id Card Meet design specifications
Ability to recharge card Acceptance Testing Reliable
Balance check facility Work on low battery
Ability to process payment receipt Read ID card with minimum time
Work on low power Process receipt instantly
System
Electronic card reader: System Testing
RFID reader Module integration
System Verification
Screen Ability to read/process data
Keypad Network testing
Antenna/Comms User friendly
Receipt printer
Receipt printer
Battery/Fixed power supply
Subsystem Design Subsystem Subsystem Testing

CAD/Solid works design Requirement API testing
Circuit design (Altium) Front-end Software testing
C++ Code based Software Back-end Systems testing
Network simulations Interface electronics
Detailed Design
Front-end Software Components Testing
Back-end Systems Design Unit test Interface testing
Wiresless comm Ability to Read/Store user Data
Microcontroller Ability to send data
Control interface Programmable module
Hardware Casting
Implementation
Veroboard/PCB
Create interface
Integrate components
Figure 6: The V Diagram for the overall design
Siphosethu Anthony Gxako will be responsible for designing the aesthetic of the
16
product (the casing, etc). The prototyping will be iterative, based on feedback from
potential users. The design will be prototyped in a suitable CAD package.
• Networking and Communications

Taremekedzwa Mudzokora will be responsible for researching and implementing suitable
networking options for the device, as well as communications to the server. This involves
how the device will have access to the network, which network will be used (GSM, LTE,
etc), as well as security and authentication concerns. Taremekedzwa will be responsible
for designing appropriate simulations in a tool such as MATLAB.
17
3 Structural Design
3.1 ELO Table
Table III: GXKSIP001 ELO Table
ELO 3.1 Sections 3.4.1, 3.4.2

ELO 3.2 Section 3.6
ELO 3.3 Section 3.5
ELO 3.4 Section 3.6, ??
ELO 3.5 Section ??
ELO 3.6 Figure 13
3.2 Introduction
Initial problem statement
How can commutation and travel by Minibus-taxis be made safer in an environment where
the cab-owners do not have much capital for improving the cabs and the commuters are
ready to compromise safety for a cheaper and reliable way to commute.
Problemsconcerns that arose during passenger interviews:

Ma Aggie taxi owners being reluctant on change and being content with overloading
although it is an evident safety hazard for passengers. Moreover, not caring about passengers
concerns.
UCT student
Taxi drivers being reluctant on making their work more formalised since they are afraid
of their more being taxed, since now it is while they are operating informally and on the
outskirts of the law. Moreover, taxi drivers not wanting to incorporate technology into their
sector of work.
Elder female who is a taxi user

Being robbed during the mornings since they carry cash and other personal stuff while
waiting in taxi stops in the early hours of the days, and this is because there arent any
guards at any stops before reaching the taxi ranks.
A high school student

Highly concerned with a way of reporting misconduct of drivers during trips.
18
3.3 User Requirements
The Cashless payment system involves a smart I.D. card that passengers will be able to load
travelling credits on. These loading points (or stations) will be available at taxi ranks and
supermarkets. The crucialkey components of the system include:
• A structure to contain all the circuitry involved in the system as shown in Figure 7
Figure 7: Casing
• A power supply circuit involving a power source, protection circuit, voltage regulator,
voltage monitoring system and battery charger.
• A microcontroller for all central processing
The major requirement of this project is that the chosen solution must be cheap to implement
and must be easily accessible to all taxi owners. Therefore the system was designed with this
requirement in mind.
Key Issues with the Design:
• Being accessible to everyone with or without any disability for example passengers who
do not have hands to be to put in details when they do not have their smart cards with.
19
• People who do not yet own I.D smart cards due to being under the age of 16, since in
South Africa that is the age when one can acquire an I.D. card.
• Will gatyis be able operate such devices, since a majority of the gatyis are illiterate.
• Other measurement to ensure if passengers dont have neither their smart cards nor
hands to type in their details.
3.4 Requirements Analysis and functional/requirement tree

This section summarizes the key sub-user requirements and makes sure that all user
requirements are met while the design was being formulated. The requirements for this
system are analysed with considerations of comfort, robustness, general aesthetics and user
convenience taken into account.
3.4.1 User Requirements
Table IV: User Requirements
Requirement
Requirement
Description
R.U.01 The device should have an easy interface
The structure must compactly embody
R.U.02 all of the electronic components as well as
the battery.
The structure should incorporate charging
R.U.03
ports
The structure should be a convenient
R.U.04
size for the user.
The structure must be aesthetically
R.U.05
pleasing to the user.
R.U.06 Must be robust
R.U.07 Must be cheap and accessible
3.4.2 Requirements Analysis
Analysis of R1
The device should have an easy interface. This refers to Verification: Potential users will be
explained to, how the device works and then given the device to test. The requirement will
20
Table V: R1 Analysis
Requirement
Requirement id Derived from
text
The device
R.T.01 R.U.01
should be kept as simple as possible.
be met if at least 90% of the users in the trial are able to understand and use the device.
Analysis of R2
The structure must compactly embody all electronic components as well as the battery This
refers to.
Table VI: R2 Analysis
Requirement
text
The device
R.T.02 R.U.02
must be 15cm x 10cm x 0.75cm
Verification: This requirement can be verified by creating shapes and boxes for other
components to fit into and then designing accordingly. However, true verification can only
take place once the other components are completed and fitted into the structure.
Analysis of R3
The structure should also be designed for charging ports. This refers too...
Table VII: R3 Analysis
Requirement
text
R.T.03 The device has a USB input port R.U.03
Verification: This requirement can be verified by testing that USB, Aux cables and other
charging ports are capable of fitting into the structure. Furthermore, its position depends on
where in the structure the electronic components will be situated.
Analysis of R4
The structure should be a convenient size for the user. This refers to
Verification: This can be done through continuous consultation with the stake holders.
Analysis of R5
21
Figure 8: USB port specifications
Table VIII: Analysis of R4
Requirement
text (test)
The device
R.T.04 R.U.04
must be 15cm x 10cm x 0.75
The structure must be aesthetically pleasing to the user. This refers to
Table IX: Analysis of R5
Requirement
text (test)
The device
R.T.05 R.U.05
must receive an 85% approval rating from users.
Verification: The verification of this requirement can be done through continuous

consultations with the stakeholder. The rating will be decided upon by the user where they
discuss if they like the way the product looks.
Analysis of R6
The structure must be tough. This refers to
Verification: This requirement will be verified by continuous testing of the design structure,
by dropping it on different materials from different heights. The structure must be able to
withstand the damage during the test and no internal components should be damaged.
22
Table X: Analysis of R6
Requirement
text (test)
Dropped from
R.T.06 R.U.06
0.5m without breaking or cracking
Analysis of R7
Must be Affordable.
Table XI: Analysis of R7
Requirement
text (test)
Make us of
R.T.07 R.U.07
cheap, locally available materials
Verification: The materials used in constructing the device should cost less than R100.
3.5 Design
The structure will be designed into a volume of 15cm x 10cm x 0.75cm as per technical
requirement RT2. It will contain rounded edges and corners: this will make the structure
stronger and distribute the force on impact if the device falls. The structure will contain
compartments for the installation of all components including:
Figure 9: Components to be included
3.5.1 Detailed Design
??
23
24
25
3.5.2 All possible solutions that the group listed both social solutions and
electrical-engineering based solutions
• Taxi drivers details in the car for passengers to see and to be able copy down at any
sign of trouble or misconduct from the taxi drivers side, so that they can be able to
report to taxi marshals and also taxi owners(social solutions since it requires very little
funding and does not need any engineering skills to implement).
• Taxi permit and validity of licence on display as for passengers to know if the taxi they
are boarding is road worthy and is the driver qualified to be on the road driving people
(social solution).
• Cashless payment system to ensure passengers dont have to struggle with carrying cash
around to pay in taxis and that elderly passengers feel safe during the early hours
knowing they wont be mugged due to carrying cash on them (Electrical-engineering
based solution as it requires a system with data storage, programming and information
retrieval when the server need to connect to the bank for a transaction to be verified
and for a person to be billed according to their taxi trip).
3.5.3 Second Interviews were conducted to find out which solution better
addressed the needs of the passengers and met the course requirements
Ma Aggie
The social solutions are excellent however taxi drivers are very reluctant to share their
personal since they know now that people will be monitoring them at every instance on the
roads, this might have the reverse effect whereby passengers are disrespectful to drivers and
know that drivers cannot do anything about it since they will reported. Moreover this may
cause taxi drivers to have animosity towards passengers, so all in all this might cause more
damage than helping. The electrical-engineering based solution is the best in my view, but
Im not sure the taxi association will support it.
UCT student (taxi user)
I give my support to the all the solutions as they seem to help in their different ways.
High school student
Im very happy with the social solutions since my concern was a way on how passengers
can report any discrepancies during taxi trips, however the electrical-engineering based
solutions will be great at formalising the taxi industry and maybe in the future incorporating
technology into the taxi industry and ensuring safe and convenient taxi experiences. Moreover
it will ensure a decreased rate of muggings at taxi stops and ranks of taxi users under the
hands of merciless criminals. Elderly woman (taxi user)
26
The electrical-engineering solution is great! Since we wont get mugged anymore by these
kids who prey on us during early hours of the days while we are waiting for transport.
DR. Amit Mishra

Students since this is a design course and also and electrical engineering course we cannot
easily just look at social ideas/ solutions and implement them, we must therefore look at
electrical-engineering since this satisfies both criteria of this course.
3.5.4 Final Design Chosen
Based on the feedback from the second set of interviews to test all prototypes (possible
solutions) on passengers and drivers, the Cashless smart I.D. card payment system was chosen
to be implemented for the project. A majority of the interviewees all saw that safety is a
major issue in the taxi industry. The passengers felt that a cashless payment system would
ensure that the safety levels in the industry would be increased, since both taxi drivers and
passengers would not need to carry large amounts of money on them every day which therefore
makes them targets of gangsters. Moreover passengers cannot be pickpocketed or robbed in
the taxi due to miscalculations of change by the gatyis.
3.6 V Diagram and possible constraints/bottlenecks

The V diagram can be found in Figure 12.
Acceptance test plan compare results to user requirements to verify that all user
requirements are met, verify also that design specification are met and reliability of the
product design.
System testing Module integration and User friendliness of device, with the ability of the
device to store and relay data.
Component testing - interface testing of the device make sure LCD screen is well protected
and that it is fully functional.
Implementation use of the device in taxis and making sure it is accessible and affordable
to every taxi owner.
3.6.1 Constraints
Cost
According to the physical casing design of the system cost wasnt a major issues, however
since a lot of taxi drivers are reluctant in spending money of funding or incorporating new
ideas into the taxi industry very cheap prototypes were implemented in order for the design
27
Figure 12: V Diagram
solutions to be easily accessible to the taxi owners.
Accessibility to all people with or without disability

Since taxi commuters vary from kids to adults both with people who have disabilities
and people who do not, while designing such system, the priority was everyone which
was dealt with by ensuring we have a device user in each taxi preferably the gatyis so as
to preserve their jobs and also make sure no one is excluded from using this system of payment.
Possible Solutions to constraints:

The system allows a person to be able to enter their I.D. number physically or the gatyi
to be able to enter it hence solving the issues of passenger who do not yet have smart i.d.
To swipe into the system. Gatyis must obtain training in order to use the new payment
system which will not be hard since the system only need a person to swipe or type their
i.d. Number into the system for payment and the system does the rest. For passengers
who do not have hands the gatyi may assist in putting their I.D.number for them. The
system keeps track of the number of seats occupied with the number of payments made for a
particular trip and doesnt allows any further payments after that unless it is fair for a new trip.
28
3.6.2 Accuracy
In the physical context of the design the accuracy focuses on the dimensions of the device
casing so to ensure accuracy device dimension must be double checked to make sure to
minimise cost and maximise efficiency of the device.
3.6.3 Possible Technical Disruptions
This analysis examines the context in which Cashless payment system. It identifies
some of the key issues and impacts in the external environment and suggest how these
will or might impact on future strategy and resources. STEEPLE Analysis can be found in 13.
Figure 13: STEEPLE Analysis
29
3.7 Design
3.7.1 OPM
The diagram below shows the general block diagram for the power management system:
Figure 14: OPM
3.7.2 Simulation for design strength
In order to do worst case design of mechanical structures, Finite Element Analysis needs
to be done on the structure, this often involves the use of a CAD software such as FEM,
MATLAB, AutoCAD or Solidworks among others. The diagram below in figure 15 shows
a FEM simulation where unit forces were applied to the material and displacements were seen:
3.7.3 Possible Optimizations
Look into the use of more streamlined components to ensure the device is smaller. Look into
different materials to create a stronger and cheaper device.
3.7.4 Statistical Simulations
For the physical design of casing no uncertainty are related to the construction of the device.
30
Figure 15: FEM simulation
4 Network Design - Taremekedzwa Mudzokora
4.1 ELO Table
Table XII: MDZTAR002 ELO table
ELO 1 Table XIII, Section 4.2.2

ELO 2 Figure 17, Sections 4.4.2, 4.4.3, 4.4.4
ELO 3 Sections 4.3.1, 4.3.2
ELO 4 Figure 18, Sections 4.5.4, 4.5.3, 4.5.3
ELO 5 Section 4.3.3
ELO 6 Section 4.6
ELO 7 Section 4.2
4.2 Introduction
Smart Ticket Machine (STM) is a cashless payment system. In this design a user is granted
the capability of using his or her smart id card for transactions by just a tap onto the device.
The system comprises of a web that is responsible for storing and maintaining user profiles,
recharge and keeping records of user activity. Each time a user swipes their card information
including the name, card number, transaction amount, date and time is captured and used for
authorization. However information about each one of numerous and countless users cannot
be stored on the device itself hence the need for a decentralized database or server that is
located elsewhere .However the need for a remote server, brings about the requirement for
31
Figure 16
the device to communicate with the network and hence design of this module. This section
will focus mainly on the digital communication of the device to the server for authentication
and validation of the users as well as storage of the user information.
4.2.1 User Requirements
User requirements can be found in Table XIII.
4.2.2 Requirements Analysis and Functional/Requirement tree
Analysis of RQ 1
”In order to grant security to the user, captured information must be securely transmitted
to and from the server.”
32
Table XIII: User requirements
Requirement ID Requirements
Capturing the information linked to the card such as the name
and card number and securely transmitting the information to
RQ 1
a server or database for authentication through a digital
communication system.
Connect to a suitable network to establish the communication
RQ 2
with the server.
RQ 3 Send back access information to the user to access the taxi.
Very small bit error rate possibly insignificant and having no
RQ 4
noticeable effect on the overall communication system.
RQ 5 Low latency
This requirement is intended to provide privacy of the user information and hence security
to the user as the transmission of their information through a digital communication system
takes place. The system therefore needs to have the capability of encryption and decryption
of the user information to strengthen security and minimise fraud and revenue leakage.
Analysis of RQ 2
”Provide access to a suitable network to establish communication with the server.” This
requirement entails that the device must be network compatible , that is it must be capable
of connecting to network technologies such as Wi-Fi , 4g , 3g and or gsm.Whenever the
device is in the range of a network , it must be capable of automatically connecting to
it.Through this network communication between device and server is achieved.
Analysis of RQ 3
”Provide capability of sending back access information to the user to access the taxi.” This
requirement stipulates that the communication is not one way. The server must be capable
of sending back access information to the device via the same network connection.
Analysis of RQ 4
”Minimize bit error rate, possibly insignificant and having no noticeable effect on the overall
communication system.”
The number of bit errors is the number of received bits of a data stream over a communication
channel that have been altered due to noise, interference, distortion or bit synchronization
errors. The communication system must be capable of minimizing the number of errors that
occur during the transmission of the data via the network.
33
Analysis of RQ 5
”Low latency”
Lightning fast retrieval of information to and from the server is required, to ensure fast
boarding .The system should not slow down as the usage increases and the data grows. There
should be no delay to update records, to ensure that the data is up to date at all times.
4.3 Design Choices
4.3.1 Possible Methods
The device may connect to the server for communication over different available network
architectures and these include;
• Wi-Fi
• 3g
• 4g
• Gsm
The next section will discuss possible network architectures that the device can be capable
of using for communication purposes.
Wi-Fi
Using Wi-Fi to connect to the network is one solution were the device would not require the
use of a sim card however the device needs to be Wi-Fi compatible. Wi-Fi is a technology
for local area networking with devices based on IEEE 802.11 standards. This means that the
device has to be compatible to connect to the internet via a WLAN and a wireless access
point. The wireless access point is required to be in the range of about 100 metres to establish
strong and reliable connection. This will allow the device to wirelessly connect to the server
and exchange data between them.
GPRS
GPRS means General Packet Radio Services which is a packet-based wireless communication
service that promises data rates continuous network connection to the Internet for compatible
devices. In this solution the device will work with GPRS data network provided by a mobile
service provider with the help of a GSM SIM. The machines internet connection will be
established with wireless GPRS data. A SIM card will be installed in the device which will
provide a network platform so that it gets connected with the server for authentication and
authorization to access the taxi. [2]
3g /4g
In this solution the device will be networking through third generation , fourth generation
network architectures .These are recent network architectures currently being used by most
34
people. The device would also require a SIM card to connect to a network provided by a
service provider could be MTN, Vodacom or Telkom etc.
Bluetooth
The device is also capable of wireless communication with the server using Bluetooth.
Bluetooth sends and receives radio waves in a band of different frequencies
(channels).Bluetooth devices automatically detect and connect to one another and up to eight
of them can communicate at any one time. They don’t interfere with one another because
each pair of devices uses a different one of the 79 available channels. Bluetooth is a similar
radio-wave technology, but it’s mainly designed for communicating over short distances less
than about 10m. [3]
4.3.2 Comparisons
4.3.2.1 Cost
Compared to 4g and 3g Communication via GPRS is cheaper than through the regular GSM
network. Customers only pay for the amount of data transported, and not for the duration
of the Internet connection. The 4g type of connectivity is more expensive than traditional
Wi-Fi networks or gprs.
4.3.2.2 Constant Connection
Through GPRS technology, users are constantly connected to the Internet. As GPRS services
are available wherever there is GSM coverage; this is readily available in most places, it allows
you to connect to the Internet even when other services such as 3G or 4g are not available. [4]
4.3.2.3 Coverage
4G connectivity is still limited to certain specified carriers and regions. Of course, the number
of cities that have 4G coverage is increasing by the day but connection might be unavailable in
remote areas. GPRS is however available wherever GSM is available.GSM was one of the first
technologies and has become popular over the years, hence its availability is almost certain.
Bluetooth requires that the communicating devices are close to each, in the range of about 10
m, the taxi will not be as close to the server. Wi-Fi coverage is not guaranteed to be available
either as public Wi-Fi access is not yet common in South Africa.
4.3.2.4 Speed
4G and 3g network have fairly good speeds compared to GPRS. Increased bandwidth leads
to much faster data transfer speed. Although new, faster technology exists today, GPRS is
still faster than the older WAP (Wireless Application Protocol). GPRS data is transferred
at speeds ranging from 9.6 kilobytes per second up to 114 kbps.
35
4.3.3 Final selection
The device will work with GPRS data network provided by a mobile service provider with
the help of a GSM sim. The machines internet connection will be established with wireless
GPRS data. This solution was chosen because of the following reasons; [4]
• Connection via GPRS is much cheaper than other regular networks like 4g or 3g.
• Through GPRS technology you are constantly connected to the network as long as there
is GSM coverage which is much more readily available than some networks like WIFI.
• GPRS is still considerably fast ranging from 9.6 kilobytes per second up to 114 kbps.
• GPRS access is possible in remote areas.
4.4.1 V Diagram
The V Diagram can be found in Figure 17.
4.4.2 Constraints
Accessibility
Accessibility to the network can be limited by the coverage in certain areas. GPRS services
are available wherever there is GSM coverage, and this is a limitation when there is no GSM
connectivity.
Cost
There is a cost associated with accessing a network provided by the service providers. Hence
the owners of the taxis will incur a cost due to the use of services being provided.
Network failure
Device may be unable to function in case of a network failure. The device requires a constant
network connection, to enable the communication between the server and itself whenever a
card is swiped. However this has a loophole in case on a network failure, no communication
can be done therefore device may not be functional.
Connectivity
Connectivity is highly variable in performance and reliability as the bandwidth may vary with
a change in location. The taxi is constantly mobile and hence the device connectivity will
vary depending on its location and this may affect performance and reliability
36
Figure 17: V diagram
37
Network failure
As already been said under constraints Device may be unable to function in case of a network
failure. The device requires a constant network connection, to enable the communication
between the server and itself whenever a card is swiped.
Connectivity
Connectivity is also a possible technical disruption, connectivity varies as the bandwidth varies
with the change in location. The device may lose connection in areas of low bandwidth.
Economic
The use of GPRS as the choice of network connection is very economical as it is the least
expensive type of network technology at the moment. The drivers of the taxis will be capable
of affording to pay for the services rendered to them as the costs are low.
Technical
From the technical point of view, the use of gprs is very reliable as the gsm network is readily
available in most areas, and connectivity is assured.
Political
This module does not require modification of the government policies. Therefore it does not
have any negative political effect.
Environmental
No harm to the environment is introduced by the design of this module.
Ethical
The use of this module has no negative impact on the issues relating to moral principles.
Hence it is ethically sound.
Legal
From a legal standpoint this product has no issues as it helps people to stay safe, and does
not negatively affect any law abiding groups of people.
38
4.5 Design
4.5.1 OPM
The OPM Diagram can be found in 18.
Figure 18: OPM diagram
4.5.2 Simulation
Figure 19: Simulink simulation of the wireless communication via the GPRS (GSM)
The simulation of the digital communication system through gprs with the help of the gsm
network was tackled at the physical layer. The simulation design was done in mat lab
39
Simulink. Figure 19 illustrates the overall connection of the transmitter, receiver and the
channel. The sections to follow will unpack the detailed blocks used to build these individual
blocks.
What is the physical layer?

In the seven-layer OSI model of networking, the physical layer or layer 1 is the first and lowest
layer. The physical layer defines the means of transmitting raw bits rather than logical data
packets over a physical data link connecting network nodes. [5] The two nodes being the STM
device and the server. The next section will unpack the building blocks used to build the
transmitter, receiver and channel.
Transmitter The transmitter is made up of the coding scheme and the modulation
Figure 20: The building blocks of the transmitter
technique. Figure 20 illustrates the connection of these schemes to build the transmitter as
a whole.
What is modulation and coding?

Modulation is the process of encoding information from a message source in a way that is
suitable for transmission. This is achieved by altering the characteristics of a wave. By
superimposing a message on to a high frequency signal known as a carrier wave (or sinusoidal
signal), video, voice and other data can be transmitted. [6] In order to convey meaning, the
sender must begin encoding, which means translating information into a message in the form
of symbols that represent ideas or concepts. [7]
Figure 21: Simulink block illustration developing the coding scheme
Receiver
The receiver is made up of the decoding scheme and the demodulation technique. Fig 23
above illustrates the connection of these schemes to build the transmitter as a whole.
40
Figure 22: Simulink block illustration developing the modulation scheme
Figure 23: The building blocks of the receiver
What is demodulation and decoding?

In short demodulation is the reverse of modulation (has been discussed above).Decoding is
also the opposite process of encoding discussed above.
Figure 24: Simulink block illustration developing the demodulation scheme
Figure 25: Simulink block illustration developing the decoding scheme
Channel
A fading channel such as the Multipath Rayleigh Fading channel is a communications path
which imposes fading on any signal passing through it. In a wireless communication channel,
fading could occur due to multipath propagation or due to shadowing from obstacles. Fading
41
Figure 26: Simulink block illustration of the channel
could be characterized as slow if the coherency time is large compared to the delay time of
the signal. This characterizes the channel in which the data bits will transmitted through.
Bit error rate optimisation

Bit Error Rate (BER) is a metrics of importance in communication networks. The wireless
channels results in error prone links and lost or corrupted packets which in turn can
trigger retransmissions. As a result of retransmissions the delay and overhead can increase
therefore it is important to study metrics such as BER that capture multilayer interactions [8]
It is thus important to minimize the ber in order to reduce corruption of the user information.
Latency optimisation
The delay time between the user swiping and getting response to either board or not needs
to be minimized to improve user experience. Therefore the time delay of the round trip
transmission through the network requires optimisation.
Various parameters in the building blocks of the communication system were varied in a bid
to minimize the possible ber. The following trend and results were obtained.
Comparing column 1 and column 2 of table XIV, it is seen that interleaving without (forward
error correction coding) FEC makes no difference to the system as the BER remains almost
the same as when there is no interleaving and no FEC. This is because with interleaving
alone, the burst errors are only spread apart into bit errors without correction as shown in
figures 6, 7, 8, and 9. However comparing column 2 with column 3, FEC without interleaving
is an added advantage to the system because with FEC, errors are being corrected even
though FEC is not optimal without interleaving. The best scenario is obtained when FEC
is incorporated with interleaving. While the interleaver spreads out the burst errors into bit
errors, the FEC corrects these bit errors. Columns 1 and 2 show this significant improvement
42
Table XIV: ber vs SNR with or without coding and interleaving
BER (with no coding BER (with coding and BER (with coding and BER (with coding
SNR
and no interleaving) no interleaving) no interleaving) and interleaving)
0 0.102 0.11 0.059 0.11
1 0.09 0.08 0.046 0.067
2 0.07 0.07 0.025 0.024
3 0.05 0.059 0.017 0.013
4 0.04 0.049 0.013 0.011
5 0.038 0.039 0.012 0.0034
6 0.032 0.033 0.008 0.0017
7 0.025 0.026 0.007 0.0012
8 0.019 0.02 0.007 0.00064
9 0.016 0.017 0.005 0.00042
in BER with and without interleaving when using FEC. This improvement is noticed however,
from SNR values of about 4 and above.
Figure 27: a plot showing an improvement on the BER of a system with Interleaving and
without Interleaving using Coding and FEC
43
4.6 Issues
Some of the issues that may arise from the use of the module include technical disruptions such
as network failure which results in the communication process failing too. Lack of connectivity
in some areas is an issue that may also arise, bandwidth varies depending on location and
some areas may have a very low bandwidth resulting in a fluctuating connection.
44
5 Back-end Software Design - Keegan Crankshaw
5.1 ELO Table
Table XV: CRNKEE002 ELO table
ELO 3.1 Table XVI, Figure 29, Section 5.4

ELO 3.2 Section 5.6
ELO 3.3 Sections 5.5
ELO 3.4 Section 5.7
ELO 3.5 Section 5.5.1
ELO 3.7 Section 5
5.2 Introduction
This design details the API and back-end systems that the front-end software and hardware
will implement in order to provide both developers and users with the expected quality of
service. Various hosting options will be considered, along with security concerns, specifically
authentication and validation. Development requirements will also be considered.
Table XVI: User requirements
Requirement ID Requirements
RQ 1 Secure data storage
RQ 2 100% Server and API up-time
RQ 3 The API calls should be simple, and easy to use
RQ 4 Method calls should not be platform/program dependant
RQ 5 The system should be easily scalable
RQ 6 The system should be easy to maintain and well documented
RQ 7 The system should be secure and deny unauthorized access
RQ 8 The server should respond to queries rapidly.
RQ 9 The API should provide the expected methods.
45
RQ 1 - Secure Data Storage
The system should ensure that user data is securely stored and unable to be tampered with.
This requires good records of who access the server when, and encryption and protection of
the database on the server.
RQ 2 - 100% Server and API up-time

In order to provide a reliable service that is usable at any point in time, the server should
constantly be up. This requires reliable hardware to host the server, as well as reliable
software on the host machine and a reliable internet connection to the server.
RQ 3 - The API calls should be simple, and easy to use

In order to ensure usability, the method calls should follow standards which will allow
easy implementation for experienced programmers who have dealt with APIs in the past.
Conforming to standards also ensures a higher quality implementation.
RQ 4 - Method calls should not be platform/program dependant

In order to ensure re-usability, the API should be implemented in such a way that will not
require it to be written for separate platforms.
RQ 5 - The system should be easily scalable

In an effort to make improvements and additions to the system easier, the system should be
implemented in such a way that makes it easy to scale.
RQ 6 - The system should be easy to maintain and well documented

To make improvements and additions to the system easier and to make it easier for users to
implement the system, the system should be well documented.
RQ 7 - The system should be secure and deny unauthorized access

The server should not allow any unauthorized access. This will prevent tampering of the
server and data.
RQ 8 - The server should respond to queries rapidly

The server should be able to handle a heavy load and not slow down when there are many
requests successively, which would be expected in a system of this nature.
RQ 9 The API should provide the expected methods. An API should be easy to
use and, in order to do so, it should have a list of simple methods that can be called. These
46
should include:
• Authenticate user
• Add user
• Remove user
• Edit user details
• Check Balance
• Increase credit balance
• Decrease credit balance
5.5 Design Choice
5.5.1 Comparison of options
Hosting Hardware
For hosting the server, hardware is required. There are two broad options for this, namely
self-hosting, or hosting on a cloud through another company. In the past, hosting a server
on personal hardware was commonplace. However, as hardware prices rose and systems
became more complex, cloud hosting became the preferred choice. Using a cloud hosting
service means the hardware does not need to be bought or maintained, resulting in cheaper
overhead and running costs. Nothaving to maintain hardware helps with RQ 6, as only the
code base needs to be maintained. The hosting company is responsible for ensuring up-time,
and many reputable hosting services (AWS, Google, to name a few) guarantee 100% up-time
on their server and 100% up-time on an internet connection, fulfilling RQ 2. The servers are
more secure than self-hosted ones (unless the cloud server is intentionally exposed), partly
fulfilling RQ 1. RQ 5 is met by using cloud hosting servers. As opposed to having to buy
more hardware to scale up the server’s capacity, many cloud hosting servers offer dynamically
scaled hosting options, simply charging for how busy the server is (AWS’s EC2 instances do
this). These services are incredibly efficient, and are used by many large companies. They
guarantee almost instant response time, which leaves the burden of rapid response on the
software, which runs almost instantly on some of the faster instances, helping fulfill the
requirements of RQ 8. Due to the security that these companies ensure, RQ 1 is also partly
fulfilled.
API Structure An API is an Application Programming Interface. This is the core design
part of this section. In short, an API allows programmers to easily implement their system by
providing the building blocks for developers to use. As the system is about cashless payments,
the basic methods to implement should include:
47
• Authenticate user
• Add user
• Remove user
• Edit user details
• Check Balance
• Increase credit balance
• Decrease credit balance
These methods can be split up into modules: The Authentication module, the Transaction
module and the User Management module. This fulfills the requirements of RQ 9.
API Structure
SOAP (Simple Object Access Protocol) is used as a message exchange platform between
computing systems on networks. It is XML based, and data is passed via message passing.
REST (Representational State Transfer) on the other hand passes objects in a JSON
(JavaScript Object Notation) format. Its based on HTTP, and is more modern than SOAP.
It allows for more data formats (unlike SOAP), is faster, and considerably easier to work
with. Because it is based on HTTP, it is cross-browser compliant, and with the advent of
browser-based devices this allows for better interoperability. In order to fulfill requirements
3, 4, 5, 6, and 8.
Programming Language
In essence, an API can be implemented in almost any programming language, but there are
a few popular ones [9]. One example is DRF, or Django Rest Framework. This is a powerful
option, as it allows the user to develop the full stack, from front end (what the user sees and
interacts with) to back end (the server and underlying logic). Once that is done, it is possible
to implement an API from the base logic that is created. However, due to the constraints of
Django, this can be somewhat limiting if the system needed to scale very quickly. Another
common option is .Net/. This is a powerful option, and many APIs are written in C#. This
is due to it’s ease of implementation, as well as the fact that many libraries are available.
These libraries make implementation of various features and requirements such as RQ 1
fairly simple. By using source control, such as Git, RQ 5 and 6 are fulfilled. A simplified
overview of how an API can be implemented is shown in figure 28.
Database
There are many options for database, but due to the constraints of the system it will be
48
Figure 28: An example of how a simple API operates
limited to a relational (SQL) database. Many free options do exist, but to ensure security
and safety of data, Amazon RDS will be used. RDS provides a secure SQL database with
the option for regular back ups.
Final Design Selection

A cloud hosting option (AWS EC2) will be used alongside Amazon RDS to host a REST
API developed in C#. This allows for all requirements to be met, in the most time and cost
efficient manner.

The requirements tree can be seen in Figure 29.
49
Figure 29: The Requirement Tree for the Module
5.6.1 V Diagram
The diagram can be seen in Figure 30.
5.6.2 Constraints
Cost
In order to minimize cost, cloud hosting services will be used. These can be started cheaply,
and scaled up as the business grows. This saves costs as the purchasing and maintenance of
server hardware and software is no longer required.
Security
By using cloud hosting, better firewalls are in place by default. By using pre-existing
development frameworks, libraries that manage things such as encryption can be used,
ensuring the correct standards are applied.
Development Time
A short development time is more likely when using commonly used programming languages
as there will be less learning time involved when developing the system and there will be
many guides on implementing APIs.
50
Figure 30: V Diagram for implementing Back-end Software
5.6.3 Accuracy
Due to nature of implementation, accuracy in the engineering sense may not be entirely
applicable. However, unit tests can be written to ensure the accuracy of transactions
performed by users before the systems go live. A unit test is a piece of code that tests the
functionality of a simple functional aspect of the API (usually, one method). An example
of a unit test would be to check the creation of a user account results in the user object
being created in the database. Another example may be ensuring that the correct amount is
deducted off a user’s account upon purchase of a ticket.
Cloud Hosting and security

The hosting space has been fairly stable for a long time. However, there is the possible
disruption of a security breach in the frameworks used, or the discovery of a hardware bug
that may expose private and personal data, such as the recent Spectre/Nightmare bugs.
Service disruption
51
There is a possibility of a service disruption - the server going down or such. While the
best has been done to try and prevent this by choosing reliable and stable services, in the
worst-case scenario, back-ups and rapid deployment scripts can be used to ensure the server
get back up and running as soon as the relevant party is notified.
Social
There may be concerns with the storage of data but these are addressed under the Legal and
ethical section. Besides that, this module enables a system with a positive social impact.
Technical
From a technical point of view, using the above implementation is one of the better ways
to implement the system. This is due to historic reasons and how reliable these tools have
proven to be.
Environmental
By using cloud hardware and not running private servers, there is a net positive impact on
the environment as there is less electricity used.
Economic
The implementation described is quite economical as it is much more cost and time effective
for the reasons described above.
Political
While there may be political concerns surrounding the overall system, this module has no
direct political considerations other than the storing of ID numbers, which is commonplace
in many systems.
Legal and Ethical
While some people may be worried about their data being stored, it is all encrypted and
unable to be viewed by anyone, even those with direct access to the system.
5.7 Detailed Design
5.7.1 OPM
A diagram showing how the API works in relation to the user is given in Figure 31.
5.7.2 Simulation of Sub-Module
There is no simulation to be run, but some pseudo-code is given in Listing ??.
52
Figure 31: An OPM diagram indicating the use of the API to the user.
public bool SaveUser(User user)

{
var ctx = HttpContext.Current;
if (ctx != null)
{
try
{
var currentData = ((User[])ctx.Cache[CacheKey]).ToList();
currentData.Add(user);
ctx.Cache[CacheKey] = currentData.ToArray();
return true;
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
return false;
}
}
return false;
}
Listing 1. Simple code saving a new user
53
As the system scales, more refined sub-systems could be introduced, such as the caching of
specific data to speed up responses to API calls, or implementation of a completely different
system that uses distributed servers as opposed to one single one.
There are no statistical simulations involved with the writing of an API. Amazon AWS
however can experience downtime, but based on the legal agreement they offer an up time of
99.99%. [10]
5.8 Issues
Please see Section 5.6.5, as it goes over possible issues in detail.
54
6 Hardware Design and Testing
6.1 ELO Table
Table XVII: NMRJOS001 ELO Table
ELO 3.1 Section 6.2, Table XVIII

ELO 3.2 Section 6.6, Table XX
ELO 3.3 Section 6.5
ELO 3.4 Section 6.7
ELO 3.5 Table XIX
ELO 3.7
6.2 Introduction
Scenario of operation:
The driver or conductor selects functions, ticket types and fares according to the customers
request, and the ticket is issued by the device. A transaction record is created and stored, and
cumulative counters are incremented. In addition, issuing tickets for cash is also implemented
in case a passenger does not have his/her smart card on his/her person. The device will
have the facility to record various categories of prepaid tickets, and to issue a range of
supplemental tickets. The device will have management and reconciliation functions to assist
the driver/conductor in both administrative functions and cash reconciliation at various stages
of the working day.
Technical Description:
The Smart contactless card reader machines (STM: abbreviation for Smart Ticket Machine)
with computer processors, memory and wireless communication, which issue tickets for travel,
designed for in-vehicle use as handheld units. It is designed to only accept non-cash forms
of payment at the start. In the typical mode of operation, fare products, fare rules and
prices (e.g. as fare tables) are stored in the STM memory. STM will contain an embedded
GPS cards to provide location information and an embedded GSM/GPRS or wireless LAN
module. In terms of information transfer, route information can be automatically updated
when the driver makes the route selection on the STM at the start of the trip, and software
updates or data uploads and downloads can be transmitted wirelessly, using wireless local
area connection, to the control centre when service coverage is available.

The user requirements can be seen in Table XVIII.
55
Table XVIII: User requirements
Req. No. Requirement Description

1 The STM shall be able to accept payment from a smart ID card
2 The STM shall print a short ticket after receiving payment
3 The STM shall display appropriate information on the screen
4 The STM shall work on low power and be rechargeable
All the different component shall be integrated altogether through an embedded
5
system using a microcontroller

Analysis of requirement 1
The device shall scan the smart ID card and process the information.
• The STM should be a hand held device to allow practicability of scanning passenger
smart card by the drivers helper.
• The STM must be able to recognise the smart card and only the type of smart card
allowed, read the information and be able to process payment.
• It shall contain an embedded processor and information storage capability. The STM
must be able to store critical information about each transaction such as date, time,
fare, to and from destination to strengthen security and minimise fraud and revenue
leakage.
• The Embedded memory of transaction records shall be downloadable via USB, wireless
LAN or GSM/GPRS
• The STM shall be able to write back to the smart card to update balance
• An indicator should indicate if the card was successfully scanned and appropriate
information displayed on the screen.
• The STM shall be able to detect the card in a range of 0-5cm from the tap scanner.
The device shall print a short ticket with the required information
• The STM shall print out a ticket as soon as payment is validated and the ticket shall
contain date of transaction, the ticket fare and the license of the taxi driver and plate
number of the taxi. Additional information later such taxi owners details and contact
details of the taxi association may be added.
56
The STM shall display appropriate information on the screen.
• The screen needs to display information that would be given from the back-end software.
• The screen shall be able to display visible information during daylight as it is the
worktime of the taxis.
• The screen shall consume as less power as possible in order to save power in case a
rechargeable battery.
The STM shall work on low power and be rechargeable.
• The STM shall be power efficient as much as possible as it will be in operation mode
for a whole day most of the time thus reducing the need to charge up the battery and
not hinder the operation of the taxis.
• A good enough rechargeable battery shall be used in order to allow the use of the STM
as long as possible.
• The rechargeable battery will be the only power provider on board of the STM. Careful
considerations have to be taken regarding all the hardware power consumption so that
the battery can power all the hardware as needed for at least 6 hours until lunchtime
so that the driver can charge up the battery during that time.
• The rechargeable battery shall have a fast charging characteristic but at the beginning
we may privilege a normal charging technology and assume that the driver will charge
the STM during non-working hours (usually at night).
All the different component shall be integrated through an embedded system using a
microcontroller.
A system block diagram is invaluable for planning and can be used to know how many input
and output (I/O) pins and serial communication ports are needed for the project. A simplified
block diagram illustrating the operation of the embedded system with key hardware of the
STM is shown in Figure 32.
6.5 Design Choices

The design specifications as well as design solutions are presented in this section. Two different
solutions to solve each of the user requirements and functional requirements are given with
solution 1 as S1 and solution 2 as S2 for short. These solutions have to fit within the design
specifications. The basic elements of the STM are:
57
Figure 32: Block diagram representation of peripherals needed on microcontroller
• Microcontroller
• Memory (internal storage for fare table, rules, transaction data)
• Switch on/off key
• LCD Touch-screen (Display and select ticket options and fares)
• Ticket printer device (thermal)
• Power source (rechargeable battery)
• Communications port (to transfer transaction and other data, to communicate with
other devices)
• Built-in RFID (contact-less) card reader
Req 1: The device shall scan the smart ID card and process the information.
A smartcard validator is the key part of the fare collection system. It will be a device that
read smartcards and support the fare applications contained on them. On-board validator
units will be contactless and integrated into the STM. The validators will be connected to an
embedded processor.
Hardware needed: Mid-Range Reader with Antenna For the ISO RFID HF reader/writer
58
• Operating voltage: 10-15V
• Data Processing Rate: 26Kbps (Minimum)
• Frequency: 13.56MHz
• Standard: ISO 15693 and 18000-3
• Type: Read/Write Lockable with unlimited number of Read/Write cycles and must be
re-writable
• Reading Distance: Up to 20cm
• Status Indicator: LEDs
• Interface: I/O pins
S1: Multi-ISO Reader Core and Reader boards

It provides contactless read/write capabilities supporting various ISO14443A/B and
ISO15693 RFID devices. Reader Core can be easily embedded into a host application with
ultimate flexibility of external antenna and secure SAM (Secure application module) support.
Reader Board offers a built in USB or RS232 interface along with integrated antenna and
SAM socket. Key Features:
Figure 33: Multi-ISO Reader Core and Reader boards
• Supports ISO14443 AB & ISO 15693 (international standards for size and technology
of smart card (contactless))
• RF transmission speeds up to 848 Kbits/s
59
• Integrated Antenna on Reader Board
• External antenna support with reader core
• Integrated secure SAM socket on Reader Board
• External secure SAM support on Reader Core
S2: NFC RFID Smart Card Reader - ACR122U

The NFC RFID Smart Card Reader - ACR122U is a contactless smart card reader/writer
developed based on the 13.56 MHz Contactless (RFID) Technology, Compliant with the
ISO/IEC18092 standard for Near Field Communication (NFC). Furthermore, the ACR122U
NFC Reader is available in module form, permitting easy integration into the STM. It is a
plug-and-play USB device allowing interoperability with different devices and applications.
With an access speed of up to 424 kbps and a full USB speed of up to 12 Mbps, ACR122U
can also read and write more quickly and efficiently. To increase the security level, ACR122U
can be integrated with an ISO 7816-3 SAM slot.
Figure 34: NFC RFID Smart Card Reader
Key features:
• Identity verification, data exchange and contactless transaction
• Operating frequency: 13.56MHz
• Read/write speed up to 454 kbps
• Built in antenna for contactless tag access, with car reading distance of up to 5cm
Comaprison: Since the STM would preferably be a handheld device, solution S1 is the
preferred solution for implementing an RFID reader/writer. It is easier to implement as well
60
and comes in an embedded form.
Req 2: The STM shall print a short ticket after receiving payment
For this task a robust, high speed, thermal ticketing printer is preferable as transaction time
needs to be as low as possible. For this task only a thermal printer was found to be a a good
solution. Hardware needed: Thermal Printer
S1: POS-5805DD Portable Mini Thermal Printer It can operate as a standalone device
but due to it being lightweight and has a small compact size, it has the possibility of being
integrated into the STM by using a permanent connected USB cable to connect to the
interface microprocessor.
Figure 35: Thermal printer
Key features:
• Thermal printer, no need for ink cartridge or ribbons, cost saving.
• Powered by 2000mAh li-ion battery, with auto sleep, auto awake, save electricity, with
power indicator, stand-by time 2-3 days.
• With working indicator, easy to operate & maintain.
• Compact, mini & lightweight, portable to carry.
• Interface: USB/COM/Power Port
• Battery: 7.4V 1500mAh 11.1Wh
• Item Size: 10.7 * 7.5 * 5cm / 4.2 * 3.0 * 2.0in
• Item Weight: 193.5g / 6.8oz
Req 3: The STM shall display appropriate information on the screen.

Hardware needed: LCD module (Either touch screen or graphical)
• Display construction: 16 Characters * 2 Lines
61
• Operating voltage (VDD): 5V-7V
• Operating current (IDD): 0.3-0.6 mA
• Operating temperature: 0-40oC
• Number of data line: 4/8-bit parallel
• Connector: PIN
S1: 3.5 Inch Colour Touch Screen Module for Arduino UNO R3 Mega256
Capacitive touchscreens respond to the touch of a human finger and can handle multi-touch
gestures and proximity sensing for enhanced usability
Figure 36: Colour Touch Screen Module for Arduino
This efficient 3.5 TFT LCD has a 240 x 320 resolution and is available as a resistive touch
or capacitive touch display. The 3.5 TFT LCD is best interfaced either in 8-bit or 16-bit
mode via MCU parallel or RGB interfaces. The display can also be interfaced via a 3-wire
or 4-wire serial peripheral interface (SPI). However, this is not recommended as it tends to
have slower speeds than MCU RGB interfaces.
S2: 128 x 64 Graphic Symbol Font LCD Display Module Blue Backlight
This screen will need an alphanumeric keyboard for the user to interface with it.
Key features:
• VDD: 3.0V 5.5V
• Clock rate: 2MHz
62
Figure 37: Graphic Symbol Font LCD Display Module Blue Backlight and keypad
• LCD type: blue
• Resolution: 128 x 64
• Viewing angle: 6 O-Clock
• Operating temperature: -20C +70C
• Size: 93.0 x 70.0 x 13.50mm (L x W x H)
Comparison:
Based on the constraints, a touch screen implementation seems to be the most appropriate
solution regarding the user interface. It provides the ability for a more compact STM for
handheld use and reduces the number of components needed for implementation. The cost of
implementation is reduced as well. The Colour Touch Screen is more compact and will take
less space and reduce weight of the device. In terms of cost, the Colour Touch Screen unit
is around R275 while Graphic Symbol Font LCD Display Module is around the same price
and it needs and additional keyboard which make its implementation more costly and difficult.
Req 4: The STM shall work on low power and be rechargeable

Hardware needed: Fixed power supply/rechargeable battery
• Voltage needed: 5-12V
• Capacity: 1000mAh
S1: Fixed Power supply from car battery (Usually 12V supply)
A power cord can be integrated in the STM. The 12V supply can be regulated through 3.3V
and 5V regulators to supply the other components of the STM. However, this will cause the
STM to be a standalone device and can hinder usability and practicability of the device.
S2: Li-ion Rechargeable Battery
A rechargeable battery with enough power capacity to power the STM can be used in order
to provide the STM with the ability of being handheld. Since actual capacity is 600mAh, 3
batteries can be connected in series. This battery was preferred over a smartphone type of
63
battery because it can provide the required voltage for our application.
Figure 38: 9V battery
Key features:
• Voltage: 8.4V
• Built-in protection circuit: Yes
• Actual Capacity: 600mAh
• Over charging/ Discharging: Yes
Comparison:
This Li-ion Rechargeable Battery is the better for the operation of the STM as it rechargeable
and can output a voltage of 8.4V.
Req 5: All the different component shall be integrated altogether through an

embedded system using a microcontroller
Hardware needed: Embedded Microcontroller
• Memory: built-in FLASH and RAM memory
• Digital General Purpose Input and Output (GPIO)
• Analog I/O
• In Circuit Programming (ISP)( to program a microcontroller while it is installed in the

application circuit, instead of having to remove it for programming)
• Wireless connection
64
• Serial communication:
– Universal Asynchronous Receiver Transmitter (UART)

– Serial Peripheral Interface (SPI)
– Inter Integrated circuit (I2C)
– Universal Serial Bus (USB)
Two microcontrollers were found to be possible candidate to fit into the design specifications
aforementioned.
S1: ARM Cortex-M

The 32-bit ARM Cortex M series is one of the most commonly used microcontroller cores
used today. The STM32F051C6 microcontroller using the ARM cortex M0 architecture can
be used. The STM32F051xx microcontrollers incorporate the high-performance ARM Cortex
M0 32-bit RISC core operating at up to 48 MHz frequency, high-speed embedded memories
(up to 64 Kbytes of Flash memory and 8 Kbytes of SRAM), and an extensive range of
enhanced peripherals and I/Os. It also offers standard communication interfaces (up to two
I2Cs, up to two SPIs, one I2S, one HDMI CEC and up to two USARTs), one 12-bit ADC, one
12-bit DAC, six 16-bit timers. The STM32F051 microcontrollers operate in the -40 to +85 C
and -40 to +105 C temperature ranges, from a 2.0 to 3.6 V power supply. A comprehensive
set of power-saving modes allows the design of low-power applications.
Additional Key features:
• Memories
– 16 to 64 Kbytes of Flash memory

– 8 Kbytes of SRAM
• Reset and power management
– Digital and I/O supply: VDD = 2.0 V to 3.6 V

– Analog supply: VDDA = from VDD to 3.6 V
– Low power modes: Sleep, Stop, Standby
• Clock management
– 4 to 32 MHz crystal oscillator
• Up to 55 fast I/Os
– All mappable on external interrupt vectors

– Up to 36 I/Os with 5 V tolerant capability
65
S2: Arduino mega 2560 OEM
The Arduino Mega 2560 is a microcontroller board based on the ATmega2560 chip. It has
54 digital inputoutput pins (of which 15 can be used as PWM outputs), 16 analogue inputs,
4 UARTs (hardware serial ports), a 16 MHz crystal oscillator, a USB connection, a power
jack, an ICSP header, and a reset button. It contains everything needed to support the
microcontroller. It can be powered by a battery.
Figure 39: Arduino mega 2560 OEM
Key features:
• Operating voltage : 5V
• Clock Speed : 16 MHz
• SRAM: 8 KB
• EEPROM: 4 KB
• Flash Memory: 256 KB of which 8 KB used by bootloader
• Dimension: 101.52 mm * 53.3 mm
• Weight: 37 g
Comparison:
Both the Arduino mega 2560 OEM and STM32F051C6 microcontroller are suitable
microcontrollers for the STM. The STM32F051C6 has too many peripherals and modules
that would be left unused, due to cost constraint it is not the preferred one as we will only
be using about 60% of the cost.
6.5.1 Final Comparison
There are more than one solutions for addressing each of the main processes that the Smart
Ticket Machine(STM) must accomplish, however to make a viable final product a comparison
66
was performed amongst the different solutions. The main figures of merit were cost, ease of
integration, physical size and weight. The final selection for hardware implementation of the
STM is shown below in table XIX. Table XIX shows the selected hardware to accomplish
each of the main operational requirements of the STM. This selection was based on careful
assessment of figures of merit such as cost, ease of integration, physical size and weight.
Table XIX: Final Selection
Operation Selection
Smart Multi-ISO Reader Core and Reader
Card reading/writing boards
Ticket POS-5805DD Portable Mini Thermal
printing Printer
3.5 Inch Colour Touch Screen
Interfacing
Module for Arduino UNO R3 / Mega256
Power provider Li-ion Rechargeable Battery
Processing Arduino mega 2560 OEM
6.6.1 V Diagram
The V diagram showing the hard design lifecycle is shown in figure 40. It breaks down the
hardware design up to the detailed design specifications of the the main components used for
hardware design
6.6.2 Constraints
Limitations:
• The STM must be handheld to provide more practicability to the conductor and speed
up in an out movement of passengers from the taxis
• The STM must be small and light enough.
• The STM must work with a power supply of ¿=12V
• The device must operate on a rechargeable battery.
• The STM hardware must be robust due to the constant use the device and the
environment its operating in.
• The device must conform to the South African law. The device must agree with the
safety and communication regulations (for example ISO/IEC 7810:2003 regulation in
67
Figure 40: V diagram showing lifecycle of hardware design for the Smart Ticket Machine
68
case of RFID scanner). In terms of Regulation 7 of the Occupational health and
Safety act of South Africa: Electrical Regulations stipulates every user or lessor of an
electrical installation or components, as the case may be, shall have a valid certificate
of compliance for that installation.
Constraints
• Time allowed for planning and researching/designing different solutions for the
implementation of the project.
• Technical knowhow is limited to academic teaching and no industrial technical knowhow

is available in order to design better and more practical solution.
• Cost involved in buying components to implement the project as the design is made in
a way that could be implementable in the future.
• ISO (International Standards Organization) and the IEC (International Electrotechnical

Commission) compliancy.
Social
The Smart Ticket Machine (STM) could be a milestone towards modernising the taxi
service. It could reduce the amount of robberies of taxis and the commuters by taking off
the incentive for criminals to rob the taxis by implementing the cashless payment system.
The community attitude is mostly pro the use of the STM as they feel it may be a lot
safer by not having cash transaction during their travel. Jobs could be created locally both
for manufacturing or assembling and repairing the devices hardware. As for the operation
of the device, no breach would arise regarding the Occupational and Safety act of South Africa.
Technical
The STM would be designed to be robust with very performant and reliable hardware. The
life expectancy of the STM is expected to be from 5 to 7 years based on the hardware
implementation. Nevertheless, any fault occurring during operation could be easily
repaired. The fact that a rechargeable battery with a limited number of charging cycle is
used will render the device susceptible to have a battery replacement on a three years average.
Environmental
The hardware design of the STM would be done in the most sustainable way possible by
making the device as small as possible to reduce the amount of material used (plastic, glass,
PCB). Moreover, some of the hardware such as the thermal printer could be recycled.
69
Economic
The cost of the hardware would be kept minimal without comprising the performance of the
different components of the STM. The capital cost of procuring the hardware may at first
be of concern due to supplier costs as most parts would be bought abroad, testing costs in
the initial stage of development, tooling costs which might occur due to unavailability of
required tool locally, and hidden costs such as assembly costs, inspection costs, spare parts
cost costs that may arise at any stage of development. There is no intention to update
the hardware after being in operation for improving capabilities. The same hardware will
run throughout the life cycle of the device. In doing so, the price will be kept fixed for
a very long time which could be attractive to new service providers. Smartcard systems
allow operators to minimise costs while improving customer service. Considering the scale
of network and transport mode, the STM could be a very good option towards maximising
profit for the service providers and allowing proper tax implementation in the taxi community.
Political
New policies might emerge for the implementation of this module but at present no political
considerations needs to be considered when developing or assembling the hardware of the
device.
Ethical
The development and usage of this module has moral concerns or principles to be followed or
allowed. It can be used by anyone.
Legal
A permit for the hardware development of the device is needed but from a legal point of
view the operation of the module should not be of concern. It has the potential for fraud or
theft reduction and keeping commuters safe.
Technical issues might arise at any point during the operation of the STM since it is an
electronic device and perfect working condition cannot be fully guaranteed. The hardware
comprises of a microcontroller, an LCD touch screen and a RFID module which could
element at risk of technical problems. A risk matrix is shown in table 3.3. The matrix
describes the possible risk that a hardware failure might occur, its likelihood, the impact it
will have on the operation of the device and how to respond to the disruption.
70
Table XX: Technical Disruptions of Hardware, its impact on the device and ways to respond
to it
Technical Disruptions Likelihood Impact Risk response

Repairing or replacement of the
Very high
Failing microcontroller/ microcontroller will have to be done.
Low This will case a complete
malfunctioning board In the worst case the device has to be
inoperability of the device
replaced completely
Medium
The device will still function and the
Unresponsive touch screen,
screen might still be usable in case
broken glass due Screen replacement. Use a protective
High of broken screen. However, in case of
to fall or being hit, screen cover to minimise risk of damage
unresponsive screen the impact is very
LCD interfacing circuit fault
high as no task can be validated for
the device to perform
Low
Thermal Printer not printing In such an event operation of the Repair or replacement of hardware
Medium
or not powering up device can be carried on normally module
even though no ticket would be printed
High
This will cause reduce the amount of
Battery wear out Medium Replace rechargeable battery
power on time of the device and
increases the need to recharge the battery
High
Corrupted memory card Medium This will cause inability to Replace memory card
reconciliate data
6.7 Detailed Design

After the design choices were made and the appropriate components were chosen based on
cost and technical complexities, the OPM of the module was created. The OPM diagram is
shown below.
6.7.1 OPM
The OPM diagram shows the main components in terms of hardware and their
inter-component interaction. The smart ID card is tapped on the smart card reader which
comprises of a RFID technology. Data is exchanged between the microcontroller and the
smart card reader. Command can be selected through the touchscreen interface. A signal
from the microcontroller activates the thermal printer.
6.7.2 Internal Block Diagram
The internal block diagram shows the structure of the different blocks of the hardware design
in terms of their properties and connections among amongst them. A block includes properties
so that its values, parts, and references to other blocks can be specified. The Internal Block
Diagram indicates the inner elements of each components (parts, ports, and connectors).
71
Figure 41: OPM Diagram
Figure 42: Internal block diagram showing the connection among the main hardware
components of the Smart Ticket Machine (STM)
6.7.3 Simulations
The behaviour among the some of the sub module of the hardware design is captured in a
state machine diagram. It shows the behaviour among the some of the sub module of the
hardware design and the transitions between them. The STM is initially turn off. After
power on, it goes into the Idle state waiting for a smart card to be presented at the RFID
72
reader module. The composite state RFID reader card/writer comprises of the reading state
and the writing state. If reading is successful the process is terminated and data send to the
composite state Arduino where the data is processed in the data authentication state which
triggers the Command state which sends command to the touch screen module to interface
with the user. Then it goes to the Transaction state and if the transaction is processed then
new updated data is sent to RFID reader card/writer and if not successful a notification is
send to the screen with the indication LED indicating red. Finally, the data get transferred
to the Writing state in RFID reader card/writer composite state where data is written to the
smart card and a ticket is printed out. The device goes to idle state after this
Figure 43: State Diagram
A possible way of optimising the STM on a hardware level is to incorporate more functionality
but in a smaller electronic system. Therefore, several electronic components could be placed
on a multi-layered printed circuit board (PCB). This would decrease size of the device and
possibly cost as well as instead of using a module for each operation such as a separate
RFID module, this could be implemented on the PCB. It would also increase the system
performance.
73
Reliability predictions are one of the most common forms of reliability analysis. Reliability
predictions predict the failure rate of components and overall system reliability. These
predictions are used to evaluate design feasibility, compare design alternatives, identify
potential failure areas, trade-off system design factors, and track reliability improvement.
The Reliability, R(t), is defined as the probability that the component or system experiences
no failures during the time interval zero to t1 given that the component or system was
repaired to a like new condition or was functioning at t0. The Unreliability, F(t), of a
component or system at a given time is simply the number of components failed to time t
divided by the total number of samples tested. Thus, R(t) + F(t) = 1.
Consider the reliability bathtub in figure 44, we will focus on constant failure rate region
for estimating the reliability of the hardware components. The Mean time between failures
(MTBF) is a basic measure of reliability for repairable items. MTBF can be described as the
time passed before a component, assembly, or system fails, under the condition of a constant
failure rate
Figure 44: Reliability bath tub [1]
MTBF can be calculated as the inverse of the failure rate, , for constant failure rate systems.
For example, for a component with a failure rate of 2 failures per million hours, the MTBF
would be the inverse of that failure rate :
1 1
M T BF = OR = 500000hours/f ailure
λ 2f ailures/106 hours
74
This MTBF method can be used to estimate the reliability of all the hardware components
from the LCD touch screen, the thermal printer, the GPRS/GSM module and the Arduino
Uno microcontroller. However, we need to have data about the number of failures of each
hardware components per million of hours of operation. Fortunately, the MTBF for the
Arduino UNO microcontroller can be found on the internet.
Arduino UNO data:

λ = 2.3238E-5
MTBF = 43033
Thus, the number of hours of operation before failure is 430329. Considering that a taxi
would use the device for 12hours/day and that they work all year round that is 365 days.
The number of hours or operation of the device/year = 12 x 365 = 4380. Thus, the expected
life expectancy of the microcontroller is 43033/4380 = 9.6 years.
Figure 45: The MTBF as a function of number of years number of years of operation of the
Arduino Uno microcontroller board. [1]
75
7 Hardware Design
7.1 ELO Table
Table XXI: MKNNIG001 ELO Table
ELO 3.1 Sections 7.2, 7.3, 7.4

ELO 3.2 Figure 46, Sections 7.6.2 7.6.3
ELO 3.3 Section 7.5
ELO 3.4 Figure 48, Sections 7.7, 7.7.2, 7.7.3, 7.8
7.2 Introduction
The module is web portal based on the Back-end system, where users can register and
check and update balances. Security concerns, accessibility and ease of use must be taken
into account. Various levels of prototypes will need to be developed, and consideration for
development framework must be taken into account.
Smart Ticket Machine (STM) is a cashless taxi payment system. STM web system is
responsible for the maintaining user profiles, recharging of prepaid card and keeping a record
of user activity. User profiles are managed based on the following requirement specifications.

See Tables XXII to XXVI.
76
Table XXII: Account access, status and updates
RQ1. Account access, status and updates

The user must be able to create a
R01
user account 24/7
The user must be provided secure access
R02 to respective account 24/7 from any internet
capable computer or mobile device.
Account holder must be able to view and/or
R03 print account summary and history/activity
log.
Online support must be available during
R04 working hours Mon - Friday from 8am to 6pm
and issues contact
Account holder must have the option of
R05 making online payment via debit card or
credit card
Table XXIII: Payment Options and Processing
RQ2 Payment Options and Processing

System must process all account holder online
R1
payments via a secure HTTPS connection socket
The system must display available payment
R2 methods and allow user to select the payment
method.
System dashboard must display account
R3 holders Name, Account id and Balance at all
times when logged in
The System must deliver notification to the
R4
payer via email or SMS on payment
System transaction processing methodologies
R5 must conform to the Cardholder
Information Security CISP standards.
System transaction processing must be
R6
PCI compliant to guarantee secure transactions
77
Table XXIV: Security and Data Privacy
RQ3 Security and Data Privacy

Information obtained from user during signup must not be
R1 used for any other purpose other than payment processing to
ensure data privacy.
System must process all user requests and information via
R2
secure https sockets.
System must automatically log out user after 10 minutes
R3
of idle time.
System must not leave cookies on users mobile device
R4 or computer other than for the purposes of session
management.
User browser and Back end servers (Database) must never
display account holder Password in Plain Text or account
R5
holder credit/debit card number except for the last 4 Digits
of the card.
Systems back-end servers and Databases must be encrypted
R6
and and only accessible to authorized administrators.
Table XXV: User Interface and User Experience
RQ4 User Interface and User Experience

System/Website must be responsive i.e seamlessly
R1 work on both mobile browsers and large screen devices.
Same website must work for different screen sizes.
User interface must be user friendly. Eligible fonts
R2
and icons used must be lightweight and fast to load
Rendering speeds of the web pages must not be
R3
more than 15 seconds for a 2 MB web content.
System user interface must maintain uniform
R4 appearance when navigating between different
pages.
7.4 Requirements Analysis

RQ1: Account access, status and updates
The requirement is intended to ensure accessibility of the system to user by granting user
24/7 access to the web based application, allowing user to monitor account activity and
status as well as generate reports. This enables user to fully monitor and update user profiles.
78
Table XXVI: Software and Hardware Requirements
RQ5 Software and Hardware Requirements

System must be supported on all modern browsers, Opera,
R1 Mozilla Firefox, Safari,Netscape, Edge, Google Chrome,
Internet Explorer 5.0 or later versions
System must be supported on any Android 2.0 or later
R2
and iOS mobile devices
System must be supported on any internet capable mobile
R3
device or computer.
System requires user to be connected to internet using
R4
Modem, WAN, LAN, Ethernet
RQ2: Payment Options and Processing

The requirement is intended to enable user to make top up payments to their accounts.
System must be able to handle multiple online payment methods e.g Visa, MasterCard and
Bank Transfers. All the transaction processing methodologies must conform to the Card
Holder System Transaction Information Security standard (CISP) and PCI compliant to
ensure safe and secure transaction handling by system.
RQ3: Security and Data Privacy

System must ensure that data security and privacy is prioritized to safeguard against
costly data breaches. External intrusions can occur through unauthorized gaining of user
credentials , system hacking and discovery of lapses in security of the web based application.
Security protocols and policies employed by system should be strong and robust and provide
a unified approach for protecting all types of private and personal information.
RQ4: User Interface and User Experience

User Interface (UI) and User Experience (UX) as well as branding is vital. A good user
interface enables the user to intuitively understand how to use the web based application
with minimal help. Application must be responsive to allow user to seamlessly switch
between different screen sized devices. To much clutter and content may result in slow page
rendering and can adversely affect optimization especially on mobile. The UI should almost
blend into the background.
RQ5: Software and Hardware Requirements System must be supported on all

modern browsers, Opera browser, Mozilla Firefox, Safari, Netscape, Edge, Google Chrome ,
Internet Explorer 5.0 or later versions. Browser compatibility is the capability and flexibility
79
of web application to be supported on different websites. Developing applications with
cross-platform compatibility improves web applications reach and cuts down on loss in
performance.
7.5 Design Choices
7.5.1 Possible Methods and Comaprison
7.5.1.1 Native Applications vs Hybrid Application
Native Applications
Native Applications are applications designed to run on a specific a mobile operating
system. Native applications require developer to use different code base for each operating
system. For example using Java for Android OS, C#,Objective CSwift for iOS operating
system.However Native apps offer better functionality and performance when targeting
functionality of target device, hence less prone to error.
Hybrid Applications
Hybrid Applications are applications designed run work on multiple platforms. A single
code base can be compiled for specificmultiple operating systems. For example code written
in C#JavascriptHTML is compiled and executed on both Android OS and iOS. Readily
available plugins and community support provides a means of faster production and a more
cost effective means than Native apps. However plugin limitation in some cases result in
high costs of supporting them.
7.5.1.2 Security : HTTP Basic access authentication vs OAuth2.0
HTTP basic access authentication

This is based on username and password. User authentication is based on standard fields
in the HTTP header hence does not require use of cookies and session IDs. Use of HTTP
header to send credentials is however vulnerable to security breaches.
OAuth 2.0 Protocol

Enables user authentication via use of credentials of API service users e.g Facebook or Google
credentials. It has an edge over HTTP Basic access authentication due to its reliability is
based on creating unique authentication tokens for each user. Compromised access tokens
are deleted and new ones are issued to safeguard APIs credentials at all times.
80
7.5.1.3 Frontend UI Design Frameworks
Using pure HTML, CSS and Javascript is more cumbersome, time consuming and makes
codebase difficult to manage. Use of Front End development Frameworks allows use to use
packages made up of a structured files of standardized code which can be reused to save
time since there is no need to reinvent the wheel. The most popular possible UI Frontend
Frameworks considered.
Angularjs
Angularjs has a better global support community than Reactjs. It is a full fledged network
that is cross browser compatible, consistent and has many libraries available with reusable
components which are more robust and quite mature than React. However Angular has a
steep learning curve an complexity.
Reactjs
React technology has smarter methods of mitigating the amount of DOM operations, optimize
and accelerating updates processes. Virtual DOM allows handling vast databases. React is
far more simpler, focussed and consistent than Angularjs. However support community is not
as great as Angularjs. Reactjs is highly scalable and system testing is made easier using tools
like Redux.
7.5.2 Final Design Choice
The Front end system will be developed using Hybrid Application approach since it provides
a more cost effective way to support application on different operating system. Maintenance
is also made easier since one code base is maintained for all operating systems.
For security and login OAuth 2.0 is going to be used since it provides better security criteria
because requests for credentials are made via SSL protocol and its guaranteed access object
is a temporary token. It also provides faster user signing up as it saves user from typing all
the details though use of data from API.
User interface is going to be designed using Reactjs Web Framework. This is because of its
mobile first approach and responsive web design approach, simplicity and consistency.
81
Figure 46: V Diagram
7.6.1 V Diagram
7.6.2 Constraints
Accessibility
Making content seamlessly available/accessible to a wider range of people with disabilities,
including blindness, impaired low vision, hearing loss, cognitive limitations, photosensitivity
or any combination of these is a limitation.Complex UI component design to provide text
equivalence e.g braille screen readers and audio for visually impaired is required to cater for
all of the cases.
Cost
The high data costs hampering the South African economy is a limitation. System requires
user to be connected to the internet. The cost of mobile data and WiFi from service providers
can limit accessibility to the system.
Connectivity
System availability is not always guaranteed as system requires internet connection to
function. In cases of network failure user may not be able to access system. Consistent
speeds are not guaranteed as it depends on variable factors like amount of traffic on network
and internet speed provided by service provider.Performance of system might vary from
device to device due to location, device processing power and amount of traffic on the site.
82
Security
Most security breaches online occur via application rather than the server. In 2017 The
Gartner Group [11] made a report showing that about 75% of cyber attacks are generated via
web applications. Web application is always under threat from cross-site scripting, session
hijacking, parameter manipulation, denial of service and SQL injections.
Compatibility Issues
Browser compatibility may become an issue as most UI components from Reactjs Framework
are only compatible with modern browsers. System might not be supported on older mobile
devices with older versions of browsers.
Social
Subsystem involves data collection from the user hence may give rise to data ethical issues like
stigmatization, polarization as well as discrimination. Since Big Data Industry regulations
is still a grey area, holders of this information can use sophisticated Big data algorithms
in making automated choices e.g selection and pricing which may lead to profiling hence
weakening individual autonomy by manipulating choices. This results in loss of trust and
lack of moral responsibility. Legitimate manipulation of these datasets of customers often
lead to negative, unintended consequences.
Economic Factors
A 2017 research by ICT Africa revealed that South African data prices are the most expensive
out of all the leading African economies []. Cost of internet is expensive in South Africa
hence may be a limiting factor as the web based application requires internet connectivity to
function. However the increase in Mobile Technology suggests that service will be accessible
and affordable to majority of Taxi users.
Technical Factors
In 2017 the number of smartphone users is was estimated to be 18.48 million and is
expected to grow to over 25 million users by 2022[2]. This shows that people are becoming
technologically educated as connectivity is now assured in remote areas.
Political Factors
To date the Taxi industry is not regulated by the government but by Taxi association.
Money flowing within the taxi industry is no under any taxation by government. The web
based application emergence provides transparency in how much cash is handled within the
83
industry and may trigger Government to decide on taxing the industry.
Ethical
When user creates an account on the system, personal information is collected. There
are regulations and guidelines that help protect the user privacy. However there are no
transparent Big Data regulations regarding the kinds and extent processing of personal data,
the limits in kinds of decisions to be made from this data when they affect people’s lives.
Legislation is not up to date to address such issues hence ethical issues may become legal
issues.The definitions of private and privacy are ambiguous or contested in big data.
Legal
Subsystem like any other website handling consumer data must conform to the customer
protection regulations. Subsystem should guarantee
1. Terms and Conditions Policy clearly displayed.
2. it card and debit card transactions processes must conform to the requirements of
Payment Card Industry Data Security Standards.
3. Privacy Policy must be added to describe exactly what cookies are used on the website,
information collected by cookie and their expiry date.
7.7 Design
Figure 47: Top Level Data for Customer Payments
7.7.1 OPM
Figure 48 shows the architecture of the web application. The server is responsible for storing
a database and the client stores user profile data.
84
Figure 48: Top Level OPM Diagram showing the architecture for web application
Form Verification Model
1. Code requesting: When the system user sends the filled form from the browser
code requesting process is initiated and a request message is generated prompting form
verification process.
2. Code sending: Interacts with the individual form verification subprocess and sends it
to the client
3. Code activation: The encryption process terminates by activating the client side
hence the client resources
Data Integrity
Data integrity refers to the maintenance and assurance of consistency and accuracy of data
over its entire lifetime [12]. Figure 50 shows the relationship of the states of model:
As shown in Status Integrity model in figure Status Wrong results in Database instability.
Error handling processes is activated and restores Status and Database to ok when successful.
7.7.2 Simulation
1.Authorization and Status Integrity model

Simulation was done using Passport a tool to test API endpoints, Json Web Tokens used to
protect API endpoints and Hashing to encrypt passwords. For every API request made a
status code is generated, time taken for request as well as size of requested resource.
85
Figure 49: (a) Top Level Form Verification Model (b) Detailed Form Verification Model
Figure 50: Status Integrity Model
When the user signs up for an account email address and password are used as
authenticatication credentials. Password is hashed using hashing algorithm for storage
in database as shown in figure 52. Upon success user receives a web token which they can
Which can be used to request secret user information. When existing user logs into the
system they also receive a web token for authentication when making requests at secure ,
protected API endpoints.
When requests are made at protected endpoints without web token access is denied as shown
in figure 54 and figure 53. Attempt to create user with already existing credentials will be
declined as shown by simulation in figure 55.
86
Figure 51: Simulation Result signup API endpoint
Figure 52: Simulation Result signin API endpoint
Figure 53: Simulation Request for protected resources with web token
87
Figure 54: Simulation Request for protected resources without web token
Figure 56 shows the users stored in database with password encrypted. Passwords are hashed
when storing in database for user security.
Form Verification Simulation

User input into the system is done via form. All the user input is validated and verified to
prevent garbage data into the system databases. Figure 57 shows simulated results for an
input of wrong email format into the email field which is rejected using form verification.
Figure 55: Attempt to create user with already existing credentials
Time for response from multiple GET request for secret resource of 263B was logged on
console for an internet average speed 1.5Mb/s. A simulation is shown in Figure 58.
API response time varies with internet speed. To get faster speeds user should be connected
faster internet speeds.
88
Figure 56: Database with hashed passwords for security
Figure 57: Form verification simulation
7.8 Potential Issues

The web system is environment friendly and issues that come with the system are security
related. System has to ensure the privacy and integrity of user data and safeguard it from
network perpetrators and cyber attacks. Social Issues might arise due to data misuse by the
System Administrators.
89
Figure 58: Time GET requests
8 Conclusion
8.1 Overview of project

It was evident from our research that the taxi industry at large is an incredibly complex
system, where change will be difficult: not because change is not needed, rather change is
not wanted. The mafia-mentality with which the industry is run due to the eagerness of
government to tax those involved is, indeed, intimidating.
As mentioned, change is needed. However, the current industry does not have much place
for change. As a result, the introduction of our proposed system allows for slow change,
accepted over time. While the system does included some issues as analyzed in this paper,
perfection should not stand in the way of progress.
Over time, we intend that the system will be adopted not only by the taxi industry but
by many areas where social grants are used. This allows for better use and distribution of
social grants. It also ensures paychecks for drivers, allowing them to drive more responsibility.
90
8.2 Future work
In the future, the device will need to be prototyped. Once prototyped, it will need to be
tested in the lab, but also in the field by implementing it in a few taxis before roll out. It
should get government approval for SASSA integration.
8.3 Conclusion
Various interviews were conducted to gain perspective into users of the taxi system and
how their lives could be improved. This data was deli berated over thoroughly in order to
develop low-level prototypes. These prototypes were taken into the field, where feedback was
received. Based on this feedback, a final design was chosen. This design was broken into
modules, each of which was designed by a separate member of the group.
91
References
[1] “Number of smartphone users in South Africa from 2014 to 2022
(in millions),” 18.05.2018. [Online]. Available: https://www.ssatp.org/
sites/ssatp/files/publications/Toolkits/ITS%20Toolkit%20content/its-technologies/
electronic-fare-collection/electronic-ticket-issuing-machine.html
[2] “Wi-Fi,” 17.05.2018. [Online]. Available: https://en.wikipedia.org/wiki/Wi-Fi
[3] Techopedia.com, “What is Bluetooth? - Definition from Techopedia,” 17.05.2018.

[Online]. Available: https://www.techopedia.com/definition/26198/bluetooth
[4] “How do wireless swiping machines work? Quora,”

17.05.2018. [Online]. Available: https://www.quora.com/
How-do-wireless-swiping-machines-work-What-is-the-working-principle
[5] Techopedia.com, “What is the Physical Layer? - Definition from

Techopedia,” 17.05.2018. [Online]. Available: https://www.techopedia.com/definition/
8866/physical-layer
[6] “What is modulation and demodulation in a modem,” 17.05.2018. [Online]. Available:

https://www.quora.com/What-is-modulation-and-demodulation-in-a-modem
[7] “Why is encoding needed?” 17.05.2018. [Online]. Available: https://www.quora.com/

Why-is-encoding-needed
[8] R. Rezagah and A. Mohammadi, “capacity estimation of wireless ad hoc networks in

fading channels,” communications IET, vol. 3, no. 2, pp. 293–302, 2 2009.
[9] A. DuVander, “What Programming Language is Most Popular with

APIs?” 19.05.2018. [Online]. Available: https://www.programmableweb.com/
news/what-programming-language-most-popular-apis/2013/06/03
[10] “Amazon Compute Service Level Agreement,” 19.05.2018. [Online]. Available:

https://aws.amazon.com/compute/sla/
[11] “Number of smartphone users in South Africa from 2014 to 2022 (in
millions),” 18.05.2018. [Online]. Available: https://www.statista.com/statistics/
488376/forecast-of-smartphone-users-in-south-africa/
[12] J Boritz, International Journal of Accounting Information Systems, 18.05.2018. [Online].

Available: https://web.archive.org/web/20111005085820/http://www.fdewb.unimaas.
nl/marc/ecais new/files/boritz.doc
92

Designreport Group 14

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Designreport Group 14

Încărcat de

Drepturi de autor:

Formate disponibile

University of Cape Town

Authors: Student Numbers:

2 Low level Prototypes 11

4 Network Design - Taremekedzwa Mudzokora 31

5 Back-end Software Design - Keegan Crankshaw 45

6 Hardware Design and Testing 55

Listing 1 Simple code saving a new user 53

1.1 Background Description

How the commutation and travel by Minibus-taxis might be made safer in an

1.2 Initial interviews

2. Two male university students, Kuziwa and Andy

3. An elderly female at taxi rank who is an everyday taxi user

5. A high-school student, 16 years of age

The transcripts of these interviews can be found in Appendix ??

1.2.1 Unpacking the interviews

Figure 1: Unpacking the interviews

Figure 2: Unpacking the interviews

1.2.2 The Team’s Point of View

Figure 3: The summary of the activity leading to the point of view

Finally, the point of view was formulated as follows:

1.3 Design Choices

2 Low level Prototypes

Figure 4: Low level design prototypes.

2.1 Feedback on low level prototypes

Worked Could be Improved

Table II: Feedback on Idea 2

Worked Could be Improved

2.1.1 Deliberations based on feedback from the interviews

2.2 Final Design Choice

2.2.1 Important Questions

• Does the system meet user requirements?

• Does the user need this?

• Legal and ethical

2.3.1 OPM Diagram and V-Model

Swipe Smart ID Artiﬁcial payment

Authentication Balance updating

Battery RFID reader Screen Printing receipt Keypad Antenna/Comms

Figure 5: The OPM Diagram for the overall design

2.3.2 Brief Outline of Modules

The design has been split into 5 modules, as follows:

• Front-end Software Design

• Back-end Systems Design

Subsystem Design Subsystem Subsystem Testing

Figure 6: The V Diagram for the overall design

• Networking and Communications

3.1 ELO Table

Table III: GXKSIP001 ELO Table

ELO 3.1 Sections 3.4.1, 3.4.2

Problemsconcerns that arose during passenger interviews:

Elder female who is a taxi user

A high school student

• A microcontroller for all central processing

Key Issues with the Design:

3.4 Requirements Analysis and functional/requirement tree

3.4.1 User Requirements

Table IV: User Requirements

3.4.2 Requirements Analysis

Table VI: R2 Analysis

Table VII: R3 Analysis

Table VIII: Analysis of R4

The structure must be aesthetically pleasing to the user. This refers to

Table IX: Analysis of R5

Verification: The verification of this requirement can be done through continuous