Sanitation
PlatformDomainsAcademyDesign SystemFeedback
v1.4
v1.4
  • Introducing Water-Sanitation
  • Water-Sanitation
    • Solution Design
    • Approach
    • Release Notes
      • FSM 1.4 - Technical Release Summary
      • Service Build Update
        • Release Builds for Core
      • MDMS Changes
      • Configuration Updates
      • Test Cases
      • Localisation
      • Impel Release Notes
      • Gate 2 Checklist
      • Workflow Configuration Changes
      • Master Migration Document
      • Driver-Individual Migration Script
  • Water-Sanitation Product Suite
    • Waste Management System
      • Functional Specifications
        • TQM UI
          • How to Enable TQM UI
          • UI: Plant Operator
            • Landing and Home Page
            • Plant-User Mapping
            • Inbox/Update Tests
            • View Past Test Results/Test's Summary Screen
            • Help Section
          • UI: ULB Admin
            • ULB Admin Home Page
            • Inbox/Test Details Screen
            • View Past Test Results
            • Create Adhoc Test
        • TQM UI/UX Audit
      • Faecal Sludge Management (FSM)
        • Features
        • Sanitation Actors & Interactions
        • User Interface Design
        • FSM User Manual
          • FSM Citizen User Manual
          • Employee User Manual
          • Manage Vendor, Sanitation Worker and Vehicle Details
          • DSO User Manual
          • Septage Treatment Plant Operator User Manual
        • Test Cases
        • FSM Functional Specification
          • Sanitation Worker UI
            • FSM Registry
            • Create Sanitation Worker
            • Edit Sanitation Worker
            • Assign Sanitation Workers to FSM Applications
            • Sanitation Worker Details
          • FSM UI Docs
            • FSM Citizen UI
            • FSM Employee UI
            • FSM DSO UI
            • FSM FSTPO UI
          • FSM UI/UX Audit
        • FSM Technical Specification
          • Vehicle Technical Specification
          • Vendor Technical Specification
          • Calculator Technical Specification
        • FSM Release Notes
          • Known Issues List
        • Product Requirement Document
        • Training
        • Sanitation Worker Welfare
          • Vendor Registry
          • FSM Service
          • Sanitation Worker( FSM 1.4) UI/UX Audit
        • FSM-DSS Technical Documentation
        • Enablement toolkits(Assetization) for FSM
          • Getting started with DIGIT
          • Requirements to enable FSM Module in a new evironment
          • Dependency services of the FSM module
          • Data templates for data collection
          • Data loading steps
            • Loading Billing Slab Data
            • Loading Vendor,Vehicle and Driver Data
            • Loading Localisations
            • Plant Mapping of FSTP
            • Creating users for FSM
          • Preparation of MDMS Data for Data Loading
          • SMS Templates for FSM
        • URC Release Notes
          • Steps to Configure URC
        • Garima Release Notes
          • Steps to Configure Garima
        • User Personas
      • Treatment Quality Monitoring (TQM)
        • Features
        • User Stories
          • Treatment Quality Monitoring Dashboard KPIs
        • User Interface Design
        • User Manual
          • Employee User Manual
          • Treatment Plant Operator User Manual
        • TQM Setup
          • User Manual
        • Release Notes
          • Known Issue List
        • Product Requirement Document: Treatment Quality Monitoring (TQM)
        • PQM Technical Specification
        • TQM Impel Checklist & Roll-out Plan
    • Water & Sewerage Connections
    • NalJal
  • Technology
    • Architecture
      • PQM
        • Low Level Design
          • Services
            • PQM Service
            • PQM Anomaly Finder
            • PQM Scheduler
      • FSM
        • Low Level Design
          • Services
            • FSM Service
            • FSM Calculator
          • Registries
            • FSM Vendor Registry
            • FSM Vehicle Registry
    • Source Code
  • Reference Implementations
    • Odisha - SUJOG
      • Functional Customisation
        • Urban-Rural Convergence
        • Garima Implementation
          • User Interface Design
          • Product Requirement Document (PRD)
      • Technical Customisation
      • Technical Specification: Urban-Rural Convergence
      • Standard Operating Procedure (SOP)
      • Program Rollout Plan
      • Implementation Plan
      • Implementation Guide
      • Implementation Checklist
      • TQM Gate 2 Plans & Checklist
  • Setup
    • Setup
      • On AWS
    • Deployment Guide
      • Legacy/Re-Indexing the FSM Data
      • Legacy/Re-Indexing the PQM Data
      • FSM devops setups
      • FSM Calculator devops setup
      • Vendor registry devops setup
      • Vehicle registry devops setup
    • Development Guide
      • Backend Developer Guide
      • UI Developer Guide
    • Configuration
      • TQM
        • PQM Service
        • PQM Anomaly Finder
        • PQM Scheduler
      • FSM
        • FSM Service
        • Vendor Registry
        • Vehicle Registry
        • FSM Calculator
    • Operations Guide
  • COMMUNITY
    • Community Project: Vehicle Tracking
      • Release Notes
        • Service Build Update
          • Release Builds for Core
        • Test Cases
      • Architecture
        • Vehicle Tracking
          • High Level Design
          • Low Level Design
      • User Manuals
        • Employee User Manual
        • Driver User Manual
      • Demo
      • Product Requirement Document (PRD)
      • Deployment Guide
      • Setup
      • Source Code
    • Contribute
    • Issues
Powered by GitBook

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

On this page
  • Tech use cases
  • 3. Tech design

Was this helpful?

Export as PDF
  1. COMMUNITY
  2. Community Project: Vehicle Tracking
  3. Architecture
  4. Vehicle Tracking

High Level Design

Was this helpful?

Overview

Urban Local Bodies (ULB) and other government agencies provide citizen centric services. Some of these services involve/require movement of people or assets(eg : vehicle, equipment etc). Below is a sample list of such services:

  • Pickup of Fecal sludge from a citizen’s premises and offloading at a designated place

  • Garbage pickup truck visits multiple collection points and deposits the load at a designated waste segregation yard

  • ULB assigns a drinking water tanker to supply water to schools in a particular area. The water tanker visits the assigned schools and supplies the required amount of water.

  • Fumigation to contain mosquitoes spread involves an operator moving in a 2-wheeler from one street to another.

  • Medicines have to be moved from district headquarters to mandal level villages.

Key challenges in the above scenarios are :

  1. Ensuring the vehicle / person took the designated route

  2. Checking if all pickup/dropoff locations are visited

  3. Monitoring if a restricted location is visited

  4. Tracking of live location

Challenges listed above are solved with a new tracking service component. This document captures the technical design of such a tracking service. For functional use cases related to a specific citizen service (Fecal Sludge Management), please refer to .

1.1 Design guidelines

Tech design for Tracking service addresses following key design goals. These goals are derived from DIGIT’s view of how a service should evolve and also the constraints arising from the usage of client side application.

  1. Client side devices may have network bandwidth constraints, hence the communication between client and Tracking service should be optimized on data.

  2. Tracking service should be generic enough to handle any kind of citizen services that involve movement of assets or service delivery by an operator on move. Type of service being rendered decides the monitoring rules (alerts, notifications) that are applied to the trip.

  3. Within the DIGIT platform, event based models processing should be used so that newer applications can be plugged in by consuming the event messages.

Tech use cases

Key terms

Term

Definition

Actual route

Route recorded by the tracking device. This can be different from the designated route. It is not created upfront.

Designated route

Pre-designated route to be taken by the person/asset.

Tracking service

A software component that stores data related to a trip, applies rules to identify anomalies and notifications.

Operator

A user responsible for delivering the service. For example, a PHC staff member doing a door to door survey to check for health details of citizens in a particular area.

Point of interest (POI)

A place on map that is of interest during service delivery. It consists of the geo location, name and additional tags. For example, a legal dumpyard for fecal sludge or customer location where a service has to be delivered..

Polygon

This is a type of POI which is formed on the basis of multiple geo-coordinates. It helps in identifying large areas on a map, like an illegal dump yard or a cluster of homes and check the trip progress w.r.t to the polygon.

Supervisor

A user with additional responsibilities like creation of a trip, registering points of interest.

Trip

Assignment of a designated route to an operator forms a trip. This is the actual work done by the operator. Monitoring of distance covered, route taken, anomalies, service delivery and payment are linked to completion of trip.

Use cases

Use Case

Use cases for the backend service

Triggered by

UC 1

Trip management

UC 1.1

Create a new trip based on citizen service, ULB, operator id, starting location, ending location, designated route (refer UC 2), timestamp and other relevant information

Supervisor

UC 1.2

Start an assigned trip

Operator

UC 1.3

Process continuous updates on geo location of the operator assigned to a trip

User app

UC 1.4

[Offline mode] Process the bulk updates related to geo location and timestamps related to operator movement

User app

UC 1.5

End a trip automatically once the operator reaches the destination. Supervisor can do a manual override

System, Supervisor

UC 1.6

Search for a trip based on trip id, ULB, service, operator, geo codes and other relevant information

Supervisor

UC 2

Citizen service master configuration

UC 2.1

Create designated route for a trip based on points of interest (refer UC 3), ULB and type of service

Supervisor

UC 2.2

Search for designated routes

Supervisor

UC 2.3

Update designated route status to active or inactive

Supervisor

UC 2.4

Register a new operator

Supervisor

UC 3

Points of interests and Geofencing

UC 3.1

Create points of interests based of LatLong coordinates

Supervisor

UC 3.2

Create polygon based geofence using multiple sets of LatLong coordinates

Supervisor

UC 3.3

Associate points of interest and geofences with various tags like pickup points, legal dumpyards, illegal dump yards and so on

Supervisor

UC 3.4

Search for the existing points of interest, geo fences and the associated tags

Supervisor

UC 3.5

Update geo points status to active or inactive

Supervisor

UC 4

Watcher and alerts

UC 4.1

Identify trip anomalies based on geo tags assigned in UC 3.

System

UC 4.2

Identify time based anomalies in a trip based on specific preconfigured rules

System

UC 4.3

Generate alerts (email, SMS) on detection of anomalies

System

UC 4.4

Search for anomalies based on trip id, geo location, ULB id and so on

Supervisor

UC 4.5

End trip if it goes beyond a time limit

System

3. Tech design

3.1 Components

Below is the list of entities, actors and tech components involved in tracking service.

Entities

  • Point of Interest (POI) - Latitude, longitude coordinates of various locations. Types of locations include citizen pickup point, intermediate points, destination location, polygons to identify larger areas and tags to identify anomalies (like illegal dump yards).

  • Designated route - A sequence of POIs which indicate the route an operator should take.

  • Trip - Created for each service delivery involving an operator. It is either created based on request or through an automatic scheduler. Trip is made up of operator details and designated routes. Actual route taken by the operator is also associated with the trip.

Actors

  • Supervisor - Individual is responsible for making configuration level changes. These can be two separate roles or just one

  • Operator - Travels from source to destination of a trip as part of service delivery.

  • System - Tracking service has the intelligence to take some actions on its own.

Tech components

  • Mobile App - User facing application to manage routes, trips and POIs

  • Tracking service - Stores entities, applies automated rules and generates alerts.

API specs

Tracking service has APIs to manage the 3 core entities - Point of interest (POI), Designated route and Trip. Basic details of these APIs are mentioned below.

Following are the list of APIs this service will support. For details of the request and response message structure, please refer to Appendix A in this document.

  • Point of interest

    • /poi/_create

    • /poi/_update

    • /poi/_search

  • Designated route

    • /designated_route/_create

    • /designated_route/_update

    • /designated_route/_search

  • Trip

    • /trip/_create

    • /trip/_update

    • /trip/_progress

    • /trip/_search

3.3 Event entity

Event entity has a generic format. Structure of the event is listed below.

Field

Description

id

GUID to uniquely identify an event

type

Event type indicates the nature of the event and helps consuming applications identify if/how to process it. For example - tracking service generates an event with type “LocationUpdate”. Similarly, trip monitoring service generated events will have the type “TripAnomaly”, “TripCompleted”

creation_time

Time at which the event is created

source

Application that published this event. This can be a short code / acronym of the source application

data

This is a JSON object. For example, “LocationUpdate” events will have fields like current_location and received_time.

Service design

  • Tracking service [New]

    • A gateway service for client endpoints. POI, Designated routes and Trips are managed by this service

    • Location updates received from client are published as events in a standard format

  • Trip monitoring module [New]

    • Consumes the location update events received from client (published by Tracking service)

    • Persists the location data, identifies anomalies, marks trips as complete based on rules

    • Events that should be notified are published by this service

  • Notification module [New]

    • Consumes the notification events

    • Fetches contact information from DIGIT User Service and sends SMS in predefined format

  • Tracking data store [New]

    • Data store for POIs, routes, trips, location updates and notifications

  • DIGIT user service [Existing]

    • Provides contact information of the user to which notification will have to be sent

    • User can be a supervisor or operator

this doc
Process Flow