Assignment 4. Developing Operational Profiles. Due Date: November 21, Group Number: 6

Size: px

Start display at page:

Download "Assignment 4. Developing Operational Profiles. Due Date: November 21, Group Number: 6"

Melinda Robinson
5 years ago
Views:

1 Assignment 4 Developing Operational Profiles Due Date: November 21, 2016 Group Number: 6 Members: Brandon Lee, , btlee@ucalgary.ca Veronica Eaton, , veaton@ucalgary.ca Dominic Hul, , dahul@ucalgary.ca Reid Sigsworth, , rsigswor@ucalgary.ca

Executive Summary This report will provide a brief specification for the project at hand, along with the finalized requirements of the system and the operational modes.

2 Executive Summary This report will provide a brief specification for the project at hand, along with the finalized requirements of the system and the operational modes. The project to be developed involves a cloud based solution, monitoring information sent from a vehicle to a database server. The data is to be analyzed in order to improve driver safety in the future. The user s vehicle will report data from an OBD-II (On-Board Diagnostics system), through a Raspberry Pi via ethernet, and transfer it to a database server over the Raspberry Pi s Wi-Fi adapter. Since we will be using a Wi-Fi connection, data may only be sent from the RPi when a wireless connection can be made with the server. If there is no connection available, the Raspberry Pi will store data within its SD card until a connection is made. While storing data may be useful for later analysis; we want to make this data easily available to the user as well. To solve this, an Android app will be developed to allow for easy viewing by the user. The app will report any vehicle errors/warnings to the user. The user will also be able to view all current and previous trip data. If a connection to the server is unavailable through the mobile app, the user may still view previous trip data through a local cache on their phone. In order to have a better understanding we will set our operational modes and represent them in a tabular form. Project Specification The objectives of our developed project are to acquire precise data, process it and utilize it for the user or owner s benefit. The following is a diagram of the four separate hardware modules that we plan to use and implement in our design. Figure 1.0: System Hardware Model

3 Figure 1.1: Data Flow Diagram Figure 1.2: ER Diagram

4 Requirements Data Acquisition Unit (OBDII, RPi, and Database Server) Functional Requirements OBDII input data is to be filtered/parsed by desired status codes before storing on Raspberry Pi s SD card Data to be stored: Cylinder Misfire (P P0312) Fuel Pump Status (P P1239) Engine RPM/Speed limiter reached (P1270) Seat Belt Status (B B1430) Brake Pedal Status (B B1486) ABS Status (C C1103) Power Steering Failure (C1778) Heater System Failure (C1776) OBDII data is stored on the RPi on an SD card OBDII data is transferred to the backend server through RPi s Wi-Fi adapter OBDII is stored on a database on the backend server OBDII data is transferred from the SD card automatically when the RPi is within range of the server s Wi-Fi connection OBDII data is transferred to the RPi at 10 second samples OBDII data is not modified/deleted before it is transferred to the server Hardware Requirements OBDII is connected physically through an RS232 to USB adapter Raspberry Pi should be powered through an adapter connected to the vehicle s electric system SD card may be replaced at any time System must be compatible with Ford F150 System must be able to run for 12 hours at a time without failure Data is transferred from Rpi to DBMS through ethernet cable User Interface Application Unit Functional Requirements The mobile application connects to the database through WiFi or LTE, to read data and display the status of each data field sent by the RPi Data to be sent to the database server: Time X coordinate Y coordinate Speed

5 All data received and sent by the phone should be stored on the phone locally and grouped in trips (user determines manually when to complete a trip) Application should issue a warning to the user when an error code is read from the database Maintain local database for all collected data Ability to search database for previous trips and display all of its data Operate in offline mode by displaying locally collected data Non Functional A maximum latency of 50ms when querying database on WiFi and 200ms when querying database on a cellular network Simple UX (user experience) Developing Operational Profiles 1. What factors are likely to yield different operational modes for your system? Different factors will affect the operational modes we have chosen in our three different modules.the following are the operational modes and their factors taken into account. Overall system modes: Mode 1. Active Trip (Online) - When the driver is in an active trip Mode 2. Viewing Mode (Online) - When the user views previous trip data, not while driving or in vehicle Mode 3. Offline Mode (Offline) - When the Android application is on but not viewing previous trip data nor in an active trip. User may view locally cached data in Android application Separate modes for each component: Raspberry Pi (2 modes): 1. Connected to Wi-Fi access point -> Required for Modes 1, 2 2. Disconnected from Wi-Fi access point -> Prevents Mode 1. Modes 2, 3 still possible Database Server (2 operational modes)

6 1. During a driver s trip -> Active in Mode 1 2. User requesting previous trip data -> Active in Mode 2 Android Application (3 operational modes) 1. During an active trip -> Mode 1 2. Viewing mode (not in active trip) -> Mode 2 3. Offline mode -> Mode 3 2. Pick one operational mode of the product of broad scope and identify its operation initiators. With three components to the system, we can select a default operational mode for each of them. The default operations will not succeed if any of the following operational modes fail. The default operational mode will be defined as when the driver is in an active trip. In order to fulfill this requirement, the following operational modes must be active. Raspberry Pi -> Must have an active connection to the designated wireless access point. Without it, the driver will not receive error codes in real time Database server -> Current operational mode must be in an active trip. It is difficult to set operational modes for the database server, as it simply processes and sends data based on received queries. The only requirement for the database server is for it to be available to the android application within a trip. Android Application -> the main operational mode will be during a trip. The mode s initiator is the driver. The driver must select the Start Trip button within the application. This will trigger the operational mode. Once the user ends a trip by selecting the End Trip button, the operational mode returns to offline mode. 3. Decide between tabular or graphical representation for the operational profile.

7 Tabular representation will be used. Tabular representation provides a clean visual of operational modes, sub functions, the number of their transactions and probability of the transactions occurring. 4. If you are using the tabular representation, list the operations for the operational mode you have selected. Consider the different initiators to generate the list for each operational mode. For the operational mode selected above of Active Trip mode. A list of operations will be divided into three components of Android application operations, database server operations and Raspberry Pi operations. Raspberry Pi Operations -> Must be in the operational mode of connected to Wi-Fi - If any error codes exist in SD card memory, send all to database server. - Receive error code data from OBDII by CSV file. - Parse for valid error codes required by the Android Application. - Attach a timestamp to the table of valid codes. - Send a query to the database server, storing the table of valid codes along with their timestamps. Database Server Operations -> Must be in the operational mode of in active trip - Receives table of valid error codes from the RPi. - Stores the table of valid error codes into its own table. - Sends valid codes to Android application through requests received by the application on a timely basis. - Receives location, time and speed data from Android application on a timely basis. Android Application Operations -> Must be in active trip mode (e.g., Start Trip button) - Application sends requests for new valid error codes held by the database server. - Alert user if one or more error codes are found. Displayed in table of error codes with associated timestamp. - Send location, time, and speed data to the database on a timely basis - User terminates mode by pressing End Trip. 5. No graphical representation needed. 6. How will you determine occurrence rates and occurrence probabilities for the operational profile of the operational mode you have selected? 1 2 Is it

8 possible to estimate them? Can you obtain any data from already available resources, log files, project documentation, etc.? In either case represent the occurrence probabilities using simple numbers. Raspberry Pi Operation Occurrence Rate (operations per hour) Occurrence Probability Reasoning Connected to WiFi Disconnect ed from WiFi -Send saved error code 2 -receive error code 360 -parse for valid errors 360 -attach timestamp 360 -send 360 5% Send saved error code only occurs when starting the WiFi mode and the rest happen every ten seconds Only time it will be connected to WiFi is when the car is on and at home which will only be a small amount of the time 95% Most of the time spent on will be while on a trip away from WiFi Database Server Operation Occurrence Rate (operations per hour) Occurrence Probability Reasoning During active trip User requested trip -Receive error codes 360 -Store error codes 360 -Send any error codes requested by the app 360 -Receive data from phone % During a trip data is created every ten seconds and then will be sent to the database Most operations to the database will be writes from the trip since there will be so a data dump every five seconds 25% We assume users will not look at every trip and those they do will only be looked up Android Operation Occurrence Rate Occurrence Reasoning

9 During active trip Viewing mode (online) Viewing mode (Offline) (operations per hour) -Send database request for new error codes 360 -Alert user of error codes 360 -Send phone data to database 360 Probability 75% During a trip data is created every ten seconds and then will be sent to the database The app will be primarily used to start and stop active trips; viewing current error codes. 15% The app will be able to view prior trips by accessing the database. 10% The phone will have a data connection for the majority of the time whether WiFi or cellular.

Assignment 1. Software Project Size Workshop. Due Date: October 7th Group Number: 6

Assignment 1. Software Project Size Workshop. Due Date: October 7th Group Number: 6 Assignment 1 Software Project Size Workshop Due Date: October 7th 2016 Group Number: 6 Members: Brandon Lee, 10101116, btlee@ucalgary.ca Veronica Eaton, 10122660, veaton@ucalgary.ca Dominic Hul, 10097599,