HIGH LEVEL DESIGN DOCUMENT

Eme
FOR
IMPLEMENTATION OF ALERT MANAGEMENT SYSTEM
THROUGH
AWS CLOUD WATCH
IN
ECO-MONITORING PROJECT

Submitted By:

Swati Agarwal

Submitted To:

Abhay Mathur

Date: 10 Jan 2022

Version: V1.0 Draft
Version – V1.0 Draft High Level Design Documentat (HLD)

DOCUMENT INFORMATION

Application name Amazon Cloud Watch Alarm

Document
Prepared by Swati Agarwal 1.0.0
Version number
High Level Design Document
Title
Document version date
Reviewed by Review date

AUTHORS AND CONTRIBUTORS

Name Designation E-mail id
Swati Agarwal Specialist Swati.agarwal@zf.com

VERSION HISTORY
Sr. No Version Submission Date Author Section Description of Change
1 V1.0 Draft 10Jan-2022 Swati Agarwal NA NA

ZF (Confidential) Page 1 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

Contents
1. Introduction............................................................................................................................................3
2. High Level Solution Design......................................................................................................................5
3. Use Cases................................................................................................................................................6
3.1. Non-functioning Alert.......................................................................................................................6
4. NON-FUNCTIONAL REQUIREMENTS......................................................................................................10

ZF (Confidential) Page 2 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

1. Introduction

Purpose
This document intents to serve as a reference for the High-Level Design requirement of ALERT
MANAGEMENT SYSTEM, which will be implemented in Eco-Monitoring Project. It details out all the
high-level solution design and architecture, solution components and integrations to various
modules and capabilities that it will possess for the Eco-Monitoring Project.

The document will be basis to define and deliver ALERT MANAGEMENT SYSTEM for R&D purpose
and contains use cases which will be the reference to create project specific personas.

This document does not cover the functional and system requirement specifications requirements of
the ALERT MANAGEMENT SYSTEM.

The intended audiences for the document are business analysts, solution architects, project
managers/ coordinators, Client Project representatives, Developers and Test Engineers who are
seeking an understanding on the High-level Design of ALERT MANAGEMENT SYSTEM for Eco-
Monitoring Project.

SCOPE OF THE DOCUMENT

The scope of the document is limited to the translation of the behavioral requirements of the
ALERT MANAGEMENT SYSTEM to the High-level Design requirements of the Eco-Monitoring
Project.
Even though various types of streaming data metrics are available in the Kinesis Data streams such
GetRecords.bytes, GetRecords.IteratorAge, GetRecords.Latency, IncomingRecords, Incomingbytes
etc. IncomingRecords metric is associated with the overall requirement, the Alert management
System is currently scoped only for the requirement when SKY Ota Pump is not sending message to
Kinesis or the integration between them is broken. This is detailed in the document as follows:

Business
Functionality Sub-systems
Requirement

Data Integration Integrate rapid and continuous data AWS Kinesis

from device sensors and provide stream
level metrics
Alarm configuration Configuring the alarm by setting CloudWatch Alarm
threshold value as Zero or any other
value which falls in the malfunctioning
range of the device.
Notification System On detecting anomaly as per the AWS - SNS
configured threshold value, the system
sends a notification to the authorised
emails through SNS Topics

ZF (Confidential) Page 3 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

The document qualifies the descriptions of the input data, operations enabled by the application
system, system workflows, and system reports required for the implementation, configuration and
operations of ALERT MANAGEMENT SYSTEM.

ASSUMPTIONS & DEPENDENCIES

The following assumptions and dependencies must be considered to deliver and implement the
Alerting & Notification functionality of ALERT MANAGEMENT SYSTEM as detailed in this document:

1. Kinesis Metrics are configured and verified in the system

2. Standard Operating Procedure and Use case Finalization.
3. Understanding of existing architecture.
4. Sub-systems Integration is already place
5. Necessary APIs are already in place for various functions.

2. High Level Solution Design

The proposed application system is built on a modular basis (components) and is architected as
loosely coupled, asynchronous systems which can scale independently and can be deployed as a
software component. Further, the system is built on a platform and applications framework which is
as depicted below:

High-level Component Design for Software System

The current structure of Alert Management System comprises of the following components: SKY,
Odyssey Operational Platform, AWS Kinesis Data Stream, CloudWatch-Alarm and Amazon SNS
Topics. Each of the component functionality is described in the below table:

ZF (Confidential) Page 4 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

Component Service

Sky – Platform Receives Device data

The Platform transforms device data from SKY to raw Eco Messages
Odyssey Operational
using Data Pump, Asset Linker and Driver Linker feature and send to
Platform
AWS Kinesis data stream

Ingests the data from driver linker, buffer and process it in real time ,
providing metrics like GetRecords.Bytes, GetRecords.IteratorAge,
Kinesis GetRecords.Latency, GetRecords.Success, IncomingRecords,
PutRecord.Bytes, PutRecord.Latency, PutRecord.Success,
WriteProvisionedThroughputExceeded etc.

It will watch IncomingRecord Metric and perform one or more actions

CloudWatch Alarm based on the value of the metric or expression relative to a threshold
over specified time periods.

The action from CloudWatch alarm can be sending a notification to an

Amazon SNS – SNS
Amazon SNS topic, which will then trigger an email to distribution lists
Topic
provided.

After configuring above in terraform scripts we should be able to get alerts when anything goes
wrong with Kinesis stream.

3. Use Cases
The section briefs the use cases that are covered under ALERT MANAGEMENT SYSTEM. This will be
agreed and signed off with the customer.

3.1. Non-functioning Alert

Use Case ID: UC-Alert-001
Use Case Name: Non-functioning Alert
Actors: Authorised End User
The Authorised users will be able receive Email Notifications if the Source
Description:
device is not functioning or sending data to the AWS Kinesis.
Trigger: The source device should stop functioning or stop sending data
Preconditions: A Threshold value should be configured in the Cloud Watch Alarm
Post conditions: Notification alert in the form of email is received by the authorised person
Normal Flow: 1. Data from the source SKY, is generated and reaches to the Kinesis via
Odyssey Operational Platform

ZF (Confidential) Page 5 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

2. Device metrics are generated in the Kinesis

3. CloudWatch Alarm checks for the zero value in the metrics
4. CloudWatch Alarm triggers an alert showing the non-functioning of
the source
5. Emails is being sent to the authorised email IDs with the help of
Amazon SNS
Alternative The alerts will also be sent if the data/metrics in the Kinesis is not being
Flows: received due to some technical flaw between the Source and the kinesis.
Exceptions: None
Frequency of
Whenever the source device stops functioning or stops sending signal
Use:
Special
None
Requirements:
The integration is being completed for other all other components and the SNS Topics
Assumptions:
are appropriately configured

User Interface for Alert Configuration

Amazon CloudWatch monitors Amazon Web Services (AWS) resources and the applications run on
AWS in real time. It can be used to collect and track metrics, which are variables that can be
measures for resources and applications.

The CloudWatch home page automatically displays metrics about every AWS service used.
Additionally, dashboards can be created to display metrics about custom applications and display
custom collections of metrics that are chosen.

One can create both metric and composite alarms that watch metric(s) and send notifications or
automatically make changes to the resources being monitored when a threshold is breached. With
CloudWatch, one can gain system-wide visibility into resource utilization, application performance,
and operational health.

You can add alarms to CloudWatch dashboards and monitor them visually. When an alarm is on a
dashboard, it turns red when it is in the ALARM state, making it easier for you to monitor its status
proactively.

An alarm invokes actions only when the alarm changes state. The exception is for alarms with Auto
Scaling actions. For Auto Scaling actions, the alarm continues to invoke the action once per minute
that the alarm remains in the new state.

ZF (Confidential) Page 6 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

Below are the snippets given to create an alarm in CloudWatch

Fig – Configuring Metrics in CloudWatch

Fig – Configuring Conditions in CloudWatch

ZF (Confidential) Page 7 of 10
Version – V1.0 Draft High Level Design Documentat (HLD)

Fig – Configuring Notification

ZF (Confidential) Page 8 of 10