Determining speed from skid marks

Software Engineering Assignment

Spring Semester, 2020

Project Specifications and Instructions

Submission date: the last two weeks of the semester

Project Description (‘Estimating a vehicle’s velocity (that is, speed) based on skid marks, yaw marks and vault case’):

This project (‘Estimating a vehicle’s velocity (also known as speed) based on skid marks, yaw marks and vault case’) requires you to adopt a use-case driven object-oriented approach to develop a system to support the estimation of a vehicle’s velocity based on skid marks, yaw marks and vault (that is, when the vehicle is airborne) case.

Motivation:

We live in a society where vehicles play a very important role. Since the beginning of car industry, there were numerous efforts to traffic accident reconstruction based on skid marks, yaw marks and vault case. This particular software’s main purpose is the estimation of a vehicle’s velocity based on skid marks, yaw marks and vault case. The second purpose of the software is to publish the relevant data onto a website for the world to see the past accidents reconstruction and an automated velocity calculator based on various factors involved such as skid distance, drag factor, acceleration of gravity, radius of the yaw marks, horizontal and vertical distances, the takeoff angle and potential other data.

Difficulties:

Some of the challenges in analyzing accidents are the measurements’ accuracy and the time needed to deviate the traffic so that incoming traffic will not be derailed. In addition, there are a lot of environmental factors in determining the correct coefficient of friction also known as drag factor (table below):

image1.png

For example, the drag factor on a road made up of asphalt, dry weather and speed more than 30mph could be taken as f = 0.83.

The structure and the logic of the software:

The software should calculate the velocity for three cases: based on skid marks, based on yaw marks (when a vehicle negotiates a curve) and when a vehicle becomes airborne during some phase of the accident. The formula specifications have been taken from the following reference (The author of this Master Thesis “agrees that the Library shall make it freely available for reference and study”):

Karoly William Krajczar: A rule-based system for preliminary accident reconstruction. Master of Applied Science's Thesis at the University of British Columbia, 1986, retrieved from https://pdfs.semanticscholar.org/be65/5e2252deb670253b4330fc46b82ccf904ab8.pdf

The first case, velocity calculation based on skid marks, is given by the equation: vi = √(2fgd+vf2), where vi is the initial velocity (m/s), vf is the final velocity (m/s), d is the skid distance (m), f is the drag factor and g is the acceleration of gravity (m/s2). Note that vf may be set to 0 after impact, acceleration of gravity is set to 9.8 m/s2 (in fact, at the surface of Earth shortest radius, g = 9.83, and on high mountains g can be as low as 9.76. We have already explained the values of the drag factor (above table). Your software tool may use the following flow diagram:

image2.png

The second case, velocity calculation based on skid marks, is given by the equation: vc = √(Rg(f+e)/(1-fe)), where vc is the critical curve velocity (m/s), R is the radius of the yaw mark (m), e is the super-elevation (%/100), f is the drag factor and g is the acceleration of gravity (m/s2). For a precise estimate, the first one-third of the yaw marks should be used to calculate R.

The third case, vault calculation, is needed if a vehicle becomes airborne during some phase of the accident. In this case, it is possible to calculate the vehicle’s speed at the point of takeoff using kinematics. The vault formula to calculate the vehicle’s velocity is v = √(gD2)/(2(H+De)), where v is the velocity at takeoff (m/s), D is the horizontal distance (m), H is the vertical distance (m) and e is the takeoff angle (%/100). For a better understanding of the vault parameters, please see the below figure:

image3.png

The software should include:

1. One database containing the road condition used to estimate the drag factor.

2. Your software tool should distinguish between the three cases discussed above: based on skid marks, based on yaw marks (when a vehicle negotiates a curve) and when a vehicle becomes airborne during some phase of the accident.

Your software should provide three methods for estimating the velocity of each of the three cases.

The ‘Estimating a vehicle’s velocity based on skid marks, yaw marks and vault case’ Computer Support:

All services enumerated in the above structures should be accompanied by the computer. For example, the database with drag factors should be maintained as files (text, DB2, EXCEL, or more). The software should also include a way to interact with the software administrator about the skid distance, drag factor, acceleration of gravity, radius of the yaw marks, horizontal and vertical distances, the takeoff angle and potential other data.

The ‘Estimating a vehicle’s velocity based on skid marks, yaw marks and vault case’ Requirements:

1. To develop a system that will hold information about the data needed and their services.

1.1. To be able to calculate the drag factors based on the current environmental conditions.

1.2. To be able to calculate the acceleration of gravity based on the current altitude.

1.3. To be able to input the other variables, such as skid distance, drag factor, acceleration of gravity, radius of the yaw marks, horizontal and vertical distances, the takeoff angle and potential other data.

1.4. To be able to interact with the Administrator who will validate these values.

1.5. To generate a report about the traffic accident reconstruction justifying the results.

1.6. To inform the customers about other related news on safe driving.

2. To provide a simulation of traffic accident reconstruction (either by animation or simply by mentioning the speed at various times).

2.1. If a authorized personnel wants to see a previous saved traffic accident reconstruction, then the software system should provide this service for free.

3. The system must be able of future expansion to incorporate information about more meals and how to expand them in the future.

Your team will work together to perform Object-Oriented Analysis and design and implementation of the proposed System. If you find that certain important information about the requirements is missing or ambiguous, you may explore on your own and suggest additional requirements or refine given requirements. While doing so, make reasonable assumptions. Your assumptions must not conflict with each other or with the given requirements. The problem and solution space need to be decomposed among the classes. The system is to be modeled in UML and implemented in Java. It is not however compulsory to program in Java, hence you can actually choose any other object-oriented programming language, such as C++, Python, etc.

Instructions

You are required to use Java (or another object-oriented programming language) to implement classes according to specific software requirements, especially the persistency requirement. You should be able to demonstrate the functionality of the system through a menu-driven interface. It can be a text-based menu, GUI or web-based interface. Type of interface does not have any impact on project evaluation.

You should make all functions very easy to use (user friendly). For example, you should not expect the user to enter all parameters required in one long string. You can use GUI, but you may have to bear the risk of having a system that does not work correctly with the test driver (see following paragraph).

Testing

You are required to perform black box testing on the functionality of classes and the interaction between them. To carry this out you may either implement a test driver or use JUnit to execute automated testing. Ideally the menu-driven interface and the test driver can be combined as one program. If you have difficulty in combining them, it is acceptable to separate them into 2 programs.

Data Persistency

You are allowed to use Java file system to retrieve and populate the data by using the object serialization to meet the persistency requirement.

Deliverables:

I. Project Report:

Your report should include the following:

(a) A complete use-case diagram of the proposed system illustrating functionality to be developed by your team. A domain model is also requested for later refinement into the class diagram.

(b) A class diagram to illustrate design for the proposed system. The diagram should include classes, associations, multiplicities, attributes, and methods. You are required to use UML notation for drawing the class diagram. Please choose relevant and meaningful names for classes, attributes, associations, and methods. Level of details for class diagram e.g. how detailed method signature should be, is left to the team members’ decision.

(c) Any assumptions, interpretation, and limitations that you have included while developing the models. Please be concise. Write all these as a separate section at the beginning of your report or after the introductory note, if you have any.

(d) An interaction diagram of the most complex use case scenario chosen by your team; a state chart for any object from your design; and an activity diagram for the system you propose. If you find that drawing one activity diagram is difficult or not possible, you are allowed to provide multiple activity diagrams. However, a brief reasoning for the same should be included in the report.

(e) Test cases used for automated testing.

Important: The total page limit for report is 15 pages, single spaced letter report (include all diagrams, appendix and references if any). The report will be assessed for abstraction, completeness, clarity, correctness, structure and innovative design /discussion /presentation.

II Project Demonstration

Each team is required to demonstrate:

- functionality of its system through a menu-driven interface;

- testing of its system through an automated test driver.

Each team is to submit its project source code along with report. Put the source code in a CD. The content of the CD should at least include the following:

a) Source code of the system. Put them in a subdirectory called “source”.

b) Test driver and test cases that team used for testing your system. Put them in a subdirectory called “testing”.

c) A “Readme.txt” file containing instructions on how to compile and run your system. Indicate important configuration information, e.g., the class-paths (if any) that need to be set. Any special requirements, e.g., a web server must be installed, or MySQL must be installed etc., should be indicated as well.

Note: As we will be using the source code on your CD for demonstration, please ensure that all the required files in your CD are not corrupted. You will not be allowed to use a fresh copy of your source code during the demonstration. Remember to label your CD with your team members' names (at least).

There is no need to include additional third party software in your CD.

What to bring for the demonstration: Each team is to bring one laptop for doing the demo. We will run your system on this laptop. Ensure any third party software necessary for running your system is installed.

Important points to note:

Each team has about 10-15 minutes to do the demonstration during the last two weeks of the semester using Blackboard Discussion Board. You will be providing your own test data. Size and variety of data should be adequate to demonstrate the functionalities of your system. It is preferable that your system has a 'bulk loading' function to load all the test data in a single operation (say from text file(s) containing the test data), rather than adding all the test data one-by-one into your system (which can be painfully slow).