Kayoola Tracking System Design Specification TABLE OF CONTENTS

1 INTRODUCTION ................................................. ERROR! BOOKMARK NOT DEFINED. 1.1 Purpose ................................................................ Error! Bookmark not defined. 1.2 General Overview and Design Guidelines/ApproachError! Bookmark not defined. 1.3 Assumptions ........................................................ Error! Bookmark not defined. 1.4 Constraints ........................................................... Error! Bookmark not defined. 1.5 Standards ............................................................. Error! Bookmark not defined. 2 FUNCTIONAL ANALYSIS ................................. ERROR! BOOKMARK NOT DEFINED. 3 HARDWARE ARCHITECTURE ........................ ERROR! BOOKMARK NOT DEFINED. 4 SOFTWARE ARCHITECTURE ......................... ERROR! BOOKMARK NOT DEFINED. 5 BILL OF QUANTITIES ....................................... ERROR! BOOKMARK NOT DEFINED. 6 PRODUCT DESIGN SPECIFICATION APPROVALERROR! BOOKMARK NOT DEFINED. APPENDIX A: REFERENCES ................................ ERROR! BOOKMARK NOT DEFINED. APPENDIX B: KEY TERMS .................................... ERROR! BOOKMARK NOT DEFINED.

2. FUNCTIONAL ANALYSIS
The tracking system is designed to track the geographical locations of the vehicle, collect onboard information, transmit the information to a remotely located control station, handle voice communication with the control station and activate alarms at the control station.

2.1

Systems environment

The system is constantly interacting with its environment. In this stage of the analysis, the system is considered as a black box reacting to the requests and messages from the environment. The environment is composed of several agents. Each agent interacts with the system with a different purpose and it exchanges a different set of messages. 2.1.1 System dependence and interaction

Figure 1: Tracking System dependence and interaction

Figure 1 shows all the agents that interact with the tracking system. Three agents have been identified, the driver, the Vehicle Controller Area Network (CAN) and the remote control station. It also shows the sensors and actuators that allow the system to exchange messages with its agents.

The sensors for the messages from the driver are the microphone and the buttons. The actuators for the driver agent are the speaker and the display. The CAN interface is the sensor for the state of the particular messages on speed and ignition on/off status from vehicle CAN. The sensor for the EMS senses for messages from the EMS for the system to shut down if asked to. The interfaces and controllers provide a point of interaction between the system and the actuators/sensors. The figure also shows the interaction between the tracking system and the navigation system. The two systems work hand in hand and share the sensors and actuators such as the display and the keypad. The tracking system avails information that is essential for navigation purposes such as the location information to the navigation system.

2.2

Use Case model

Figure 2: Tracking System Use Case Model

2.2.1 Establish communication Use-case Title: Brief Description: Actors: Establish communication This use case allows the system to establish communication Primary: Secondary: Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 3: Activity diagram for establishing communication

2.2.2 Initiate a call Use-case Title: Brief Description: Actors: Initiate a call This use case allows the driver to initiate a call with the remote control station at the press of a button Primary: Secondary: Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 4: Activity diagram for initiating a call

2.2.3 Receive a call Use-case Title: Brief Description: Actors: Receive a call This use case allows the driver to receive a call at the press of a button. The call is initiated at the remote control station. Primary: Secondary: Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 5: Activity diagram for receiving a call

2.2.4 Initiate an alarm Use-case Title: Brief Description: Initiate an alarm This use case allows the driver to initiate an alarm by pressing a button. The alarm goes on at the control station Actors: Primary: Driver Secondary: Control station Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 6: Activity diagram for initiating an alarm

2.2.5 Obtain location information Use-case Title: Brief Description: Actors: Obtain location information This use case allows the system to obtain location information from the GPS receiver. Primary: Driver Secondary: Control station Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 7: Activity diagram for obtaining location information

2.2.6 Obtain on-board information Use-case Title: Brief Description: Actors: Obtain on-board information This use case allows the system to obtain speed and ignition on/off status from the vehicle CAN Primary: Driver Secondary: Control station Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 8: Activity diagram for obtaining on-board information

2.2.7 Transmit information Use-case Title: Brief Description: Actors: Transmit information This use case allows the system to transmit the obtained location and on-board information to the control station Primary: Driver Secondary: Control station Trigger: Pre-conditions: Main Scenario: Success Scenario: Basic Flow of Events:

Figure 9: Activity diagram for transmitting information

3. Hardware Architecture