• Syllabus
• Resources

PROJECT: Home Security System - Part 1 - UPDATED - 4/19/21 (TJR)

Project Description

For this project you will develop a home security system written in C that collects and prints data from sensors around the home. A given sensor detects and reports one or more of the following types of information:

• Temperature - the temperature in Fahrenheit at the sensor.
• CO - carbon monoxide level in parts per million detected by the sensor.
• Intruder - the home was entered without appropriate authorization.

The system logs all sensor reports on a per room basis; each room has an associated log of all its sensor reports (or events). This log is kept in a fixed size circular buffer, along with an event count of all the events that have been logged for the room since the system was last (re)started, and the indices in the buffer of the oldest and newest log entries for the room.

• Each room's buffer is initially empty, and the event count, as well as the oldest and newest indices are zero.
• Each new event from a sensor in the room increments the room's event count.
• Until the buffer is full, each new event is recorded in the next free buffer slot, updating the newest index to reflect this. See the following example with a 3-element buffer:
  
• Once full, a new event replaces the oldest event in the buffer, updating both the oldest and newest indices to reflect this. See the following example with a 3-element buffer:
  

Initial configuration

1. The room's buffer has space to hold five(5) events.
2. The buffer is empty (event count, oldest, and newest are all 0).

Input definition

Readings of sensor events are provided to your program via standard input as lines of comma separated values (CSV):

ROOM,SID,HH:MM:SS,TYPE[,VALUE]

where each of the values is defined as follows:

ROOM is the room number (0 to 4,inclusive).
SID is the sensor ID number within the room (≥ 1).
HH:MM:SS is the time of the event using a 24 hour clock (HH is hours, MM is minutes, SS is seconds).
TYPE is an integer flag indicating event type:

VALUE is an integer,and is only found on type 1 and 2 events. For type 1 the value is the temperature; for type 2 the value is carbon monoxide concentration in parts per billion (PPB).

The PRINT command prints the room alarm system status and the room event log from the newest entry back to the oldest one.

Output

In addition to the output produced by the PRINT command your system must print alerts based on temperature, carbon monoxide level, and intruder events as follows (R is the room number, S is the sensor in the room, T is the temperature, C is the CO concentration, and HH:MM:SS is the time of the event).

If the temperature is less than 50 degrees or over 110 degrees print the message:

Temperature alert @ HH:MM:SS: room R / sensor S / T degrees.

If the carbon monoxide level exceeds 3000 print the message:

Carbon monoxide alert @ HH:MM:SS: room R / sensor S / C PPB.

For any intruder detection, print the message

Intruder alert @ HH:MM:SS: room R / sensor S.

Sample Execution

Here is a sample interaction with the system: This example only uses room 1 so as to (a) keep down the number of sensor observations and (b) make it clear what is printed and why. In general, sensor events from multiple rooms would be intermingled on the standard input stream.

Text that appears in italics corresponds to input given to the system in CSV format; this would NOT be printed. Anything in appearing in bold is part of the output from the program. Lines bracketed in << and >> are notes on the previous output command.

<< Note that the there are no events yet so nothing is printed from the log >>

<< Note that 4 events have been logged, so all of them show up in the printout. >>

<< Note that the first two readings were "dropped off" as the log wrapped around >>

1,5,08:16:00,1,112

Temperature alert @ 08:16:00: room 1 / sensor 5 / 112 degrees.

1,4,08:16:32,2,2

1,2,08:18:35,1,64

1,2,08:20:15,9

*****
Home Security System: Room 1 @ 08:20:15
Triggered by sensor 2
10 total room events
Sensor 2 @ 08:18:35 temperature reading 64 degrees
Sensor 4 @ 08:16:32 carbon monoxide reading 2717 PPB
Sensor 5 @ 08:16:00 temperature reading 112 degrees
Sensor 4 @ 08:14:45 intruder alert
Sensor 2 @ 08:13:10 carbon monoxide reading 1923 PPB

<< Note that the three more readings were "dropped off" as the log wrapped around >>

• Line 1 contains 5 stars (asterisks),
• Line 2 gives the room number and time of the report,
• Line 3 tells which sensor generated the event,
• Line 4 reports the total number of events for the room,
• The remaining lines give the event buffer contents from newest to oldest event.

Here are some assumptions you may make:

1. The input is read from standard input and the all printing is to standard output.
2. All input is well-formed. That is:
1. Each input line will have exactly the number of fields required by the corresponding event type.
2. Room numbers range from 0 to 4.
3. The sensor IDs are all positive integers.
4. The time strings are all properly formatted eight character strings, with leading zeros as necessary.
5. The type is always 1-3 or 9.
6. The value is given if and only if it is required by the type, and is always a well-formed integer.

General Project Process (Note Updated hs-v2.zip)

Download the ZIP archive hs-v2.zip and extract the files into a directory named exactly  CHomeSecurity at the top level of your git working area. The CHomeSecurity directory is where we will look for everything related to your project; files in other directories will be simply ignored.

The following files are in the archive:

• Activity_Journal.txt - the standard activity journal you will fill out as part of the project.
• hs.c - the template file for the project work. The only  files you may change are this one and the activity journal!
• hs_config.h - configuration information and data structure declarations. You need to understand this, but you are not allowed to change the file.
• hs_util.h - interface declarations for functions we are providing to you. The functions read a line of text into a character array, attempt to parse a string (character array) as a reading line (see above), and, if the parsing succeeds, return the parsed information as a C struct for your use.
  You need to understand this to use the functions, but you are not allowed to change the file.
• hs_util.c - the implementation of the hs_util.h interface. You are encouraged to read this as an expanded example of C code, but you are not to change this. All you need to do is compile and link this module with your code in hs.c.
• hs_l1_in.txt / hs_l1_out.txt - a test input data set and the expected output for level 1. There are actually 5 such test file pairs, one for each level (see System Levels below).

You can check that you downloaded and extracted the files successfully by compiling and executing the skeleton program:

make
./hs < hs_l1_in.txt

This will do nothing except exit - now it's your turn to add functionality!

To encourage incremental development there are multiple levels of submissions. You may stop at any level and receive up to the cumulative grade at that point, but you must have submitted an entry for all preceding levels. When you have completed a level, use a commit message with the format stated below before starting the next level. Only your last completed level will be graded, but your git log must demonstrate that you developed and tested the application incrementally to receive full credit.

You are also to complete a process and reflection document which records your activities. NOTE: You need not finish all levels in order to receive full credit for this component of the project. We will be assessing the quality of the planning and reflection for however many levels you complete, along with the project Summary.

1. We strongly encourage you to complete the process and reflection for each level before going on to its successor. In doing so, complete the activity journal Start section by including:
   • An estimate of the time it will take to design, implement, and test the required code for that level.
   • A brief (1-2 paragraphs max.) description of your plan for meeting the level requirements (including setup & implementation).
2. Be sure to commit all work done for any level under CHomeSecurity folder.
3. Begin the first level with the skeleton hs.c - this contains the main program, the function you have complete (process_a_reading), and any additional functions you define. This file will be compiled and executed to test your submissions. For the second and later levels, continue to build on hs.c file and add any other files you need in support of that level requirements.
   • For testing, use the sample input files and compare your program's output to that desired. You may need to create your own tests to help ferret out bugs.
   • We strongly encourage you to break the work down by using additional helper functions. A program that has one huge process_a_reading function will be hard to work with, and will not earn you many quality points.
4. While keeping track of the actual (wall clock) time spent, do the design, implementation and testing of that level until you are confident the program works as required.
5. Record the following on the Complete section of the journal for the achieved level.
   • Report the actual (wall clock) time spent in the journal. Your ratio for that level will be (actual / estimated) time.
   • If the ratio is greater than 1.10,provide a brief, informative (1-3 sentences) explanation of why the work proceeded more slowly than you estimated.
   • If the velocity is less than 0.90,provide a brief, informative (1-3 sentences) explanation of why the work proceeded more quickly than you estimated.
   • Finally be sure to include a brief (1-2 short paragraphs) description of any other problems encountered, lessons learned and how you overcame any obstacles and consider these as you move to plan the next level. Be sure to give credit to any TAs, classmates, or faculty members who helped you over hurdles.
6. Be sure all files have been added to git, commit the files, and push the repository to the grading area. At the completion of a level use exactly the following commit message: "*** Level N Complete ***" where N is the level just completed. We may use the commit messages to find the various versions for each level, so using the correct commit message format is essential.

As a final entry to the journal you must record:

• The overall (actual / estimated) time ratio.
• A one paragraph critical assessment on how this ratio changed over time. Did it converge towards 1? Were you consistently optimistic or pessimistic? Where there any contributing factors to any inaccuracies. How can you use what you learned in later course project?
• A brief (1-3 paragraphs) assessment of the project as a whole. Did you learn much from it? Did you become more proficient in the language, and do you think this is of value? What parts of the project were particularly difficult or easy? How would you suggest we structure such projects in future offerings of this course?

System Levels

Level 1 - Read and print each individual CSV line.

Simply read, parse,and print the contents of each valid input line. This will insure that you are properly interpreting input and establish test scripts that can be extended in future levels. (Note this is a temporary output format for testing only!) .

As before italics represent your input and bold represents the output.

4,1,14:09:01,1,72
Room 4 / Sensor 1: 14:09:01: temperature reading 72 degrees
1,2,05:23:46,2,2128
Room 1 / Sensor 2: 05:23:46: carbon monoxide reading 2128 PPB
2,6,23:18:56,3
Room 2 / Sensor 6: 23:18:56: intruder alert
0,1,03:48:13,9
Room 0 / Sensor 1: 03:48:13: print

Level 2 - Read accumulate sensor data for one room without exceeding the buffer size

Read and log multiple pieces of sensor data for a given room, print alerts as required, and print the result using the PRINT command for the room.

0,1,05:19:01,1,72
0,2,05:23:46,2,2128
0,6,06:18:56,3
Intruder alert @ 06:18:56: room 0 / sensor 6.
0,3,06:52:48,1,70
0,2,07:01:35,2,2189
0,1,07:10:00,9

*****
Home Security System: Room 0 @ 07:10:00
Triggered by sensor 1
5 total room events
Sensor 2 @ 07:01:35 carbon monoxide reading 2189 PPB
Sensor 3 @ 06:52:48 temperature reading 70 degrees
Sensor 6 @ 06:18:56 intruder alert
Sensor 2 @ 05:23:46 carbon monoxide reading 2128 PPB
Sensor 1 @ 05:19:01 temperature reading 72 degrees

Level 3 - Read accumulate sensor data for several rooms without exceeding the buffer size for any given room

Read and log sensor data across multiple rooms, but none of the rooms overflows the buffer capacity.

1,1,05:19:01,1,72
1,2,05:23:46,2,2128
1,6,06:18:56,3
Intruder alert @ 06:18:56: room 1 / sensor 6.
4,5,06:38:17,1,62
1,3,06:52:48,1,70
1,2,07:01:35,2,2189
4,2,07:05:12,1,64
4,3,07:07:28,2,1893
1,1,07:10:00,9
4,2,07:11:00,9

*****
Home Security System: Room 1 @ 07:10:00
Triggered by sensor 1
5 total room events
Sensor 2 @ 07:01:35 carbon monoxide reading 2189 PPB
Sensor 3 @ 06:52:48 temperature reading 70 degrees
Sensor 6 @ 06:18:56 intruder alert
Sensor 2 @ 05:23:46 carbon monoxide reading 2128 PPB
Sensor 1 @ 05:19:01 temperature reading 72 degrees

*****
Home Security System: Room 4 @ 07:11:00
Triggered by sensor 2
3 total room events
Sensor 3 @ 07:07:28 carbon monoxide reading 1893 PPB
Sensor 2 @ 07:05:12 temperature reading 64 degrees
Sensor 5 @ 06:38:17 temperature reading 62 degrees

Level 4 - Read accumulate sensor data for one room while exceeding the buffer size.

0,1,08:01:00,1,60
0,4,08:01:02,3
Intruder alert @ 08:01:02: room 0 / sensor 4.
0,3,08:05:32,2,2154
0,2,08:06:35,1,60
0,1,08:12:01,1,63
0,4,08:14:45,3
Intruder alert @ 08:14:45: room 0 / sensor 4.
0,5,08:16:00,1,62
0,4,08:16:32,2,2717
0,2,08:18:35,1,64
0,2,08:20:15,9

*****
Home Security System: Room 0 @ 08:20:15
Triggered by sensor 2
9 total room events
Sensor 2 @ 08:18:35 temperature reading 64 degrees
Sensor 4 @ 08:16:32 carbon monoxide reading 2717 PPB
Sensor 5 @ 08:16:00 temperature reading 62 degrees
Sensor 4 @ 08:14:45 intruder alert
Sensor 1 @ 08:12:01 temperature reading 63 degrees

Level 5 - Collect and print information for more than one room that exceeds its buffer size.

1,1,08:01:00,1,60
1,4,08:01:02,3
Intruder alert @ 08:01:02: room 1 / sensor 4.
0,1,08:01:10,1,61
4,4,08:03:11,1,59
4,4,08:04:01,2,1598
1,3,08:05:32,2,2154
4,3,08:05:33,2,2099
0,3,08:05:34,2,2161
1,2,08:06:35,1,60
4,1,08:07:01,1,62
0,2,08:08:12,1,61
4,2,08:09:22,2,2233
1,1,08:12:01,1,63
4,1,08:13:10,3
Intruder alert @ 08:13:10: room 4 / sensor 1.
0,2,08:13:15,3
Intruder alert @ 08:13:15: room 0 / sensor 2.
1,4,08:14:45,3
Intruder alert @ 08:14:45: room 1 / sensor 4.
1,5,08:16:00,1,62
0,3,08:16:02,1,61
4,4,08:16:05,2,2222
4,3,08:16:08,1,60
0,1,08:16:21,2,1919
0,2,08:16:28,3
Intruder alert @ 08:16:28: room 0 / sensor 2.
1,4,08:16:32,2,2717
1,2,08:18:35,1,64
1,2,08:20:15,9

*****
Home Security System: Room 1 @ 08:20:15
Triggered by sensor 2
9 total room events
Sensor 2 @ 08:18:35 temperature reading 64 degrees
Sensor 4 @ 08:16:32 carbon monoxide reading 2717 PPB
Sensor 5 @ 08:16:00 temperature reading 62 degrees
Sensor 4 @ 08:14:45 intruder alert
Sensor 1 @ 08:12:01 temperature reading 63 degrees

0,1,08:20:18,9

*****
Home Security System: Room 0 @ 08:20:18
Triggered by sensor 1
7 total room events
Sensor 2 @ 08:16:28 intruder alert
Sensor 1 @ 08:16:21 carbon monoxide reading 1919 PPB
Sensor 3 @ 08:16:02 temperature reading 61 degrees
Sensor 2 @ 08:13:15 intruder alert
Sensor 2 @ 08:08:12 temperature reading 61 degrees

4,5,08:20:30,9

*****
Home Security System: Room 4 @ 08:20:30
Triggered by sensor 5
8 total room events
Sensor 3 @ 08:16:08 temperature reading 60 degrees
Sensor 4 @ 08:16:05 carbon monoxide reading 2222 PPB
Sensor 1 @ 08:13:10 intruder alert
Sensor 2 @ 08:09:22 carbon monoxide reading 2233 PPB
Sensor 1 @ 08:07:01 temperature reading 62 degrees

GRADING

The following grading breakdown will be used:

Component	%
Level 1	15%
Level 2	15%
Level 3	15%
Level 4	15%
Level 5	15%
Journal	5%
Solution Quality	20%
TOTAL	100%

** NO LATE SUBMISSIONS WILL BE ACCEPTED **
** ANY DEVIATION FROM THE SUBMISSION PROCESS WILL RESULT IN A 10% GRADE PENALTY **

The solution quality will be assessed using the following criteria:

• Naming: Are variable, function and other names meaningful? Do they have a clear relation to their role in the computation? Would a competent developer be able to pick up this code and understand why you chose the names you did?
• Documentation: Do you use comments to simply repeat the code or to provide insight into its context and intention? Are comments clear, concise, and correct? Are comments readable - do they avoid distracting grammatical and spelling errors? Are the aligned with the code to make it obvious which comments refer to which sections of code?
• Structure: Are the bodies of functions organized into clear, coherent sets of statements that clearly contribute to the function's goals? As appropriate, are sections of code factored out into local functions of their own, either to simplify the original function, to enhance readability, or to adhere to DRY (Don't Repeat Yourself)?
• Style: Does the layout of the code enhance its readability? Do you use consistent indentation in line with examples done in class? Do you use blank lines to separate distinct blocks of code? Do you use spaces to enhance readability (or are expressions scrunched together, making it difficult to distinguish variables from operators from constants)?
• Source Code Control: Did you demonstrate appropriate use of source code management during the development of the project? Did you provide well-written comments for each commit? Is your test code under source control?