Challenge Overview
Welcome to Barton Alarm System for Sensor Application C# DALC Code Challenge
For this Code challenge we need your help to design an alarm system for the sensor application.
- You must use MongoDB as the storage.
- Develop the Alarm Data Access Module in C#.
- Define a set of clean interfaces to do the CRUD operations on the alarms.
- Design the schema for the Mongo collection.
- Develop the unit tests.
- No UI is needed.
Read more details about the challenge requirements as explained below.
General Requirements:
- Pull the full stack source for the app and install it locally or on Heroku.
- You can see existing C# DALC folder for the implementation of the previous Devices CRUD Operation
- Create some sample data on MongoBD
- You might need create Postman configurations to allow us to test your solution
- Create unit test for this challenge submission.
- Put clear comments for any functions
- Challenge winner need responsible to do the Pull Request for this winning submission.
Submissions Requirements:
- For this code challenge, you need write the C# Data Access Layer Component (DALC) with the CRUD operations of Alarm System for Sensor Application
- Here is an example of alarm data:
{
"t": "2017-10-27T14:19:40Z", // UTC timestamp
"d": "ba4666de-49ad-4726-ab56-89125db061fd", // device UUID
"tag": 1234, // optional integer tag to identify which sensor (e.g. temperature) in the device.
"desc": "UPS temperature too high", // description
"state": "critical", // critical, high, low, closed, etc. User can define these states. We may or may not want to define a well-known list. But it must be customizable.
"ack": false, // whether this alarm is acknowledged by someone.
}
In addition to these basic fields, user can define some additional fields and store them in the same alarm storage. For example,
- “ack_t”: the time that the alarm is acked.
- “ack_user”: The user who acked the alarm.
- “notes”: User can enter a notes to the alarm.
- “active”: The condition (threshold) that triggered this alarm still exists.
- “attachment”: A list of sensor data that attached to this alarm. This can be the temperature reading of when the alarm is triggered, plus some other related readings. Create a flexible schema model so that the device can attach anything to when the device sends an alarm.
Another obstacles is that the alarm can have its own life history.
- For example, the device measures the temperature.
- A few thresholds (100, 110, etc.) can be set on the devices to trigger and escalate an alarm.
- The device will send a sequence of updates to the same alarm: first triggered a low level alarm, and then escalate to high, then back to normal and the alarm is closed. T
- he history of the same alarm shall be stored and can be queried.
Different devices’ alarm triggering model is different. We need to provide a generic storage to store and support basic queries. These are some of the query examples:
- Get a list of all alarms (just the latest update if an alarm has many updates) for a given device, or a list of devices, given a time range.
- Get a list of all critical alarms for a given device, or a list of devices.
- Get a list of critical alarms that have not be acked for a given device, or a list of devices.
- Get a complete update history for an alarm.
These operations shall be supported:
- User can enter some notes to an alarm.
- User can acknowledge an alarm or a list of alarms.
Another Obstacles:
- The system shall allow users to define additional fields that are customizable.
- Only the core set of fields are required and enforced. They are "t, "d", "tag", "desc", “state", and “ack”.
- Some attachment can be a small binary blob, such as a waveform capture triggered by the alarm.
- The blob itself may come within the alarm or outside of the alarm separately.
- In the second case, a URL or a blob UUID can be associated to this alarm.
- Provide documentation, (usage and deployment guide if needed ) for your solution in the main readme.md under a new section name Devices and/or edit the main readme to make it current.
- Provide a quick < 5-minute video of your solution in action. (You may annotate or narrate)
- A code walkthrough video is desired but not required.
For this Code challenge we need your help to design an alarm system for the sensor application.
- You must use MongoDB as the storage.
- Develop the Alarm Data Access Module in C#.
- Define a set of clean interfaces to do the CRUD operations on the alarms.
- Design the schema for the Mongo collection.
- Develop the unit tests.
- No UI is needed.
Read more details about the challenge requirements as explained below.
General Requirements:
- Pull the full stack source for the app and install it locally or on Heroku.
- You can see existing C# DALC folder for the implementation of the previous Devices CRUD Operation
- Create some sample data on MongoBD
- You might need create Postman configurations to allow us to test your solution
- Create unit test for this challenge submission.
- Put clear comments for any functions
- Challenge winner need responsible to do the Pull Request for this winning submission.
Submissions Requirements:
- For this code challenge, you need write the C# Data Access Layer Component (DALC) with the CRUD operations of Alarm System for Sensor Application
- Here is an example of alarm data:
{
"t": "2017-10-27T14:19:40Z", // UTC timestamp
"d": "ba4666de-49ad-4726-ab56-89125db061fd", // device UUID
"tag": 1234, // optional integer tag to identify which sensor (e.g. temperature) in the device.
"desc": "UPS temperature too high", // description
"state": "critical", // critical, high, low, closed, etc. User can define these states. We may or may not want to define a well-known list. But it must be customizable.
"ack": false, // whether this alarm is acknowledged by someone.
}
In addition to these basic fields, user can define some additional fields and store them in the same alarm storage. For example,
- “ack_t”: the time that the alarm is acked.
- “ack_user”: The user who acked the alarm.
- “notes”: User can enter a notes to the alarm.
- “active”: The condition (threshold) that triggered this alarm still exists.
- “attachment”: A list of sensor data that attached to this alarm. This can be the temperature reading of when the alarm is triggered, plus some other related readings. Create a flexible schema model so that the device can attach anything to when the device sends an alarm.
Another obstacles is that the alarm can have its own life history.
- For example, the device measures the temperature.
- A few thresholds (100, 110, etc.) can be set on the devices to trigger and escalate an alarm.
- The device will send a sequence of updates to the same alarm: first triggered a low level alarm, and then escalate to high, then back to normal and the alarm is closed. T
- he history of the same alarm shall be stored and can be queried.
Different devices’ alarm triggering model is different. We need to provide a generic storage to store and support basic queries. These are some of the query examples:
- Get a list of all alarms (just the latest update if an alarm has many updates) for a given device, or a list of devices, given a time range.
- Get a list of all critical alarms for a given device, or a list of devices.
- Get a list of critical alarms that have not be acked for a given device, or a list of devices.
- Get a complete update history for an alarm.
These operations shall be supported:
- User can enter some notes to an alarm.
- User can acknowledge an alarm or a list of alarms.
Another Obstacles:
- The system shall allow users to define additional fields that are customizable.
- Only the core set of fields are required and enforced. They are "t, "d", "tag", "desc", “state", and “ack”.
- Some attachment can be a small binary blob, such as a waveform capture triggered by the alarm.
- The blob itself may come within the alarm or outside of the alarm separately.
- In the second case, a URL or a blob UUID can be associated to this alarm.
Final Submission Guidelines
- Please submit a single zip file which includes the .git directory intact. You should create a new branch with the name of your tc handle.- Provide documentation, (usage and deployment guide if needed ) for your solution in the main readme.md under a new section name Devices and/or edit the main readme to make it current.
- Provide a quick < 5-minute video of your solution in action. (You may annotate or narrate)
- A code walkthrough video is desired but not required.