Machine Translated by Google

SPECIFICATIONS –
GLOBO360

TERMINOLOGY

Active, mobile, tracker, vector = all active or inactive objects present on the web
interface; whether it be rolling stock (cars, trucks, machinery, two-wheelers…), fixed
equipment (generators, pumps…)

PF = abbreviation for Platform

POI = points of interest

FLEET MODULE – Context and objectives

Description of the FLEET module and its sub-modules
Current platforms primarily offer classic real-time map views, standard reports (routes, speeds, distances), and a
limited set of tracking widgets. Navigation is unintuitive, increasing the time required to find information.

The FLEET module is a core component of the "GLOBO360" platform. It integrates all the
functionalities necessary for planning, executing, and controlling fleet operations. It consolidates
data from all installed devices within a single user interface, eliminating the need to navigate
between multiple platforms.

This module is organized around four main sub-modules:

+ Geofence sub-module (POIs) : advanced management of zones and points of interest.

+ Missions sub-module : creation, scheduling and management of 2 types of

missions.
ÿ Route management (long-distance mission – single delivery)
ÿ Delivery Route Management (missions by zone – multiple points of
deliveries)

+ Track / Live sub-module : intelligent monitoring of objects with integration of data from
all connected sensors, a global visualization on the map via widgets and other visual
performance indicators (depending on subscribed options).

+ History/Replay sub-module : detailed review of journeys and in-depth analysis

data.
Machine Translated by Google

Current issues and objectives of the FLEET module

ÿ Current issues
+ The data from the different devices is not centralized, forcing the user to switch between
several platforms (e.g. 3 devices = 3 interfaces).
+ Lack of a structured tool for advanced mission management.
+ Lack of immediate visibility on the overall condition of an asset.
+ Difficulty in optimizing routes and reducing fuel costs.
+ Current interface is outdated and widgets are limited.
+ The platform's existing functionalities (driver/vehicle assignment, real-time mapping, remote
reporting) are not sufficiently integrated into a coherent "business" workflow oriented
towards missions and rapid decision-making.
ÿ Expected objectives
+ Offer a modern, modular and highly configurable user experience
(widgets).
+ Capitalize on a "plugin" model that allows functionalities to be activated by
customer account and according to the options subscribed.
+ Optimize routes (more points delivered / visited in less time).
+ Reduce operational costs (fuel, overtime, vehicle wear and tear).
+ Provide end customers with reliable, real-time visibility into the progress of
missions.

1.3 FLEET Module – Measurable Objectives

+ Reduce unnecessary distances travelled by 20%.
+ Implement a modular structure of customizable widgets.
+ Improve mission punctuality by 20% (deliveries / interventions within the window)
planned).
+ Reduce manual processing time (planning + reporting) by at least 30%: a click on an object
should allow you to see its performance at a glance.
+ Centralize 100% of the data from the equipment in a single interface
+ Improve navigation fluidity (target: average loading time < 2
seconds).

GEOFENCES SUB-MODULE
CONTEXT & OBJECTIVES
1.1 Description
The GEOFENCES sub-module allows modeling the client's geographic business environment in order to manage
operations, automate rules, analyze performance and secure fleet usage, in direct interaction with real-time
monitoring, missions, alerts and dashboards.

1.2 Objectives
ÿ Main functional objective

Create, organize, visualize and utilize geographic areas (geofences / POIs)

in order to :
+ Represent the key locations of the activity
Machine Translated by Google

+ To serve as a single geographic reference for the entire platform

ÿ Operational objectives

The GEOFENCES sub-module should allow a business user to:

+ Structuring your territory
ÿ Divide the space into logical, functional, and usable zones ÿ Group geofences by
category, group, mission, client
+ Manage operations
ÿ Quickly identify where the vehicles are located, whether they are inside or outside a
authorized area
ÿ Use geofences as mission milestones, delivery points, and waypoints
of routes
+ Automate business rules ÿ Trigger
automatic alerts : zone entry/exit, speeding in a zone, presence outside of scheduled hours, ÿ Apply IVMS
rules specific to certain zones

ÿ Analytical & decision-making objectives

Geofences should serve to:

+ Measure performance: ÿ Time
spent in a zone ÿ Number of entries/exits
ÿ Compliance with time slots

+ Populate the dashboards with : ÿ

Productivity ÿ
Delivery delays ÿ Route
adherence
+ Analyze behaviors: ÿ Unauthorized
detours ÿ Illegal parking ÿ
Repeated passage through
sensitive areas

ÿ Cross-cutting integration objectives

The GEOFENCES sub-module is designed as a common foundation that is integrated into the other sub-modules.

+ TRACK / LIVE : Simultaneous display of vehicles and geofences on the map

+ MISSIONS & TOURS : Selection of geofences as starting and ending points
and milestones
+ ALERTS & IVMS : Setting up specific rules per zone
+ HISTORY & REPLAY : Route analysis by area
+ IMPORT / EXPORT : Reuse of customer databases (POIs, parcels) in csv, xls and
kml.

ÿ UX objective & user adoption

The sub-module must: +

Be visual, intuitive and map-based
+ Allow selective display (by type, group, category)
+ Enables clear reading even with hundreds of geofences
Machine Translated by Google

+ To offer an experience similar to a simplified GIS, accessible to non-technical profiles

techniques

FUNCTIONAL SCOPE
ÿ Feature 1: Creating geofences
+ By entering GPS coordinates (longitude, latitude), by searching for an address, using the vehicles present on the
map (right-click)
+ Creation of circular (center + radius) or polygonal (list of GPS points) zones.
+ Attribute association:
ÿ Name, internal code, display color, icon, comments ÿ Association with a
category: danger zone, prohibited zone, routes, point of
delivery, loading zone, loading zone
ÿ Assignment to a geofence group, mission, or object, + IVMS criteria: choice of entry/
exit times, speed limits on geofence
+ Link with ÿ The
Dashboards: time spent in the area, number of entries/exits, etc.
ÿ Alarms: Enabling/disabling alerts on entry/exit of geofences
ÿ The mission management module: selection of starting points, arrival points, and stage(s)
based on existing geofences,

ÿ Feature 2: Viewing and Editing + View Page

+ List of geofences, +
Modification of one or more geofences at a time (traces and attributes),
+ Rights management: creation / editing limited to certain roles (administrator, supervisor).

ÿ Feature 3: Display on the map

+ Option to display or hide a geofence or group of geofences on the map
+ Simultaneous display of objects and geofences on map + export of routes in KML format.
+ Display on the map of the area, with or without the geofence name on the map, with
or without the icon
+ Display of all, or part (by category, by geofence group, by type)
+ Multi-layered display means that if geofences overlap, the geofence name displayed will be that of the smallest
created area. For example, I create a geofence for a built-up area to assign a 50 km/h speed limit zone. Within
this zone, I create gas stations. The geofence displayed will be that of the gas station.

ÿ Feature 4: Import/ export of POIS databases

A client must be able to import their own geofence database in .XLS or other file format.
KML
+ The client must visualize the expected column layout for the import by providing them with the
Template - column layout - of the expected input file.
+ A client must be able to export their geofencing database in .XLS format.

ÿ Feature 5: Alarm association

+ Overspeed
+ Restricted area
Machine Translated by Google

+ Time slot anomaly

ÿ Feature 6: Deletion of one or more geofences at a time

+ Removal of one or more geofences at a time

ÿ Feature 7: Settings
+ Creation of the list of available categories: the client can thus create the names of the geofence
categories they want to group their points (pharmacy categories, TOP100 clients, route A
waypoints, bars, gas stations, etc.)

+ It will be able to automatically assign a color to each category for the drawing of
geofences attached to it
He will also be able to choose an icon to display the categories on the map
+ Geofencing databases must be easily transferable from one client account to another in mode
administrator.

DETAILED USE CASES

ÿ Adding a geofence based on the location of an asset
+ Actor : Fleet operator
+ Actions :
ÿ The operator views the position of an asset located within a geofence that has not been
created. They zoom in on the asset
ÿ
It opens the geofence sub-module.
ÿ The list of all created geofences is displayed
ÿ
He clicks on the "+" to add a new geofence
ÿ
It records the geofence name and chooses the zone type (circle or polygon). It assigns the
POI to a group (if needed) and creates it if the group doesn't exist. If necessary, it records a
time limit and a speed limit associated with the geofence. It selects the color to assign to the
geofence.
+ Results : In just a few clicks, a new geofence is created based on the position
of an asset.

ÿ Modify the boundaries of a geofence

+ Actor : Fleet operator
+ Actions :
ÿ Display all geofences on the map page
Machine Translated by Google

ÿ Open the geofence sub-module and search for the point by typing part of the name in the
search bar. A selection of points with the name will be displayed.
ÿ Select the desired point and click on edit.
ÿ The geofence is displayed and the operator moves the points to adjust the area
+ Results : the operator can adjust the size of the geofences relative to each other to avoid
overlaps.

Example illustrating how to modify a geofence

ÿ Adding a geofence using GPS coordinates

+ Actor : Platform operator

+ Actions :
ÿ On the map page, the operator uses the display address function
ÿ
It provides the GPS coordinates of the point
ÿ The map zooms automatically
The operator opens the geofence module and clicks on the "+" to create the geofence.
+ Results : it is possible to create a geofence even if an asset is not on site.
Machine Translated by Google

Illustration showing a location with GPS coordinates

ÿ View the geofence list and change the color in batches

+ Actor : Platform operator

+ Actions : ÿ
Open the geofence sub-module ÿ Click on the
list icon ÿ The list of geofences is
displayed along with their attributes: color, group, speed limit, and access time range ÿ The
operator selects multiple geofences at once to change their color

For example
ÿ
He clicks on the batch processing button and confirms
+ Results : a single action allows you to modify several geofences at once.

ÿ Create a new group (category) of geofences and assign a point to it

+ Actor : Platform operator

Machine Translated by Google

+ Actions :
ÿ Open the geofence sub-module
ÿ Click on the three dots to the right of the "unbundled" directory and then on create
a new
ÿ In the window that appears, the operator enters the title
ÿ
He uses the search engine to find the geofences to associate, selects them,
and clicks save.
+ Results : a geofence category appears in the list; it is possible to request to display
only this category of geofences on the map.

ÿ View the trackers present on a geofence

+ Actor : Platform operator

+ Actions :
ÿ Open the geofence sub-module
ÿ Click on the three dots to the right of the geofence » then on plotter
ÿ A window opens displaying the list of trackers currently on the geofence
+ Results : we know the number and list of tracers present on a geofence, as well
as their arrival time and the time spent on site.
Machine Translated by Google

Illustration of the list of trackers present on a geofence

TECHNICAL REQUIREMENTS
The GEOFENCES sub-module is based on a high-performance geospatial engine, enabling the creation, editing,
display and use of business-specific geographic areas, integrated in real time with mission management, alert and
reporting modules.

ÿ Required data
Geospatial engine
+ Native support: ÿ
Points (POI) ÿ
Circles (center + radius) ÿ Polygons
(coordinate list)
+ Calculations required: ÿ
Inclusion/exclusion of the GPS point in the zone ÿ Entry/exit of
the zone ÿ Time spent in the zone

+ Mandatory geospatial indexing (performance)

IVMS rules / behavior

+ Speed limit in the area
+ Authorized time slots
+ Days of the week allowed
+ Minimum/maximum duration of presence threshold in the area

Relationships with other entities

+ Objects / vehicles
+ Drivers
+ Missions
+ Routes
+ Alerts
Machine Translated by Google

Creation & publishing

+ Creation by entering coordinates, address search (geocoding) or the

marking a location on the map
+ Individual or batch modification
+ Cancellation / visual validation

Map display
+ Layers that can be activated by category, group, type
+ Options: display the geofence name and/or the geofence icon and/or the zone
+ Overlay with objects, routes, missions

Import
+ XLS / XLSX / KML /CSV formats
+ Downloadable template

Export
+ XLS / XLSX / CSV / KML
+ Filters to apply before export
+
ÿ Required integrations

TRACK/LIVE integration
+ Real-time detection
+ Geofence entry/exit
+ Simultaneous display: vehicles + geofences

Integration MISSIONS & TOURS

+ Selection of geofences such as:
ÿ Starting and/or finishing points ÿ Stage
points ÿ Milestones

+ Validation: ÿ
Route adherence ÿ Detour

+ ETA calculation based on geofences

Integration of ALERTS & IVMS

+ Automatic activation: ÿ Entry/exit ÿ Zone
overspeed ÿ Outside
time range ÿ Outside
authorized days

+ Settings by geofence / Category / Group

+ Notifications: Email/Push/web Hook

Dashboard & Reporting Integration

+ KPIs per geofence: time spent / number of passages / delays
+ Aggregation: day / week / month
+ PDF / CSV / XLS / XLSX exports

External API integration

+ Geocoding / reverse geocoding
Machine Translated by Google

+ Import of customer databases

+ KML sharing (parcels, routes)

Technical UI/UX Requirements

+ Central card required
+ Dynamic side column
+ Refresh without reloading
+ Smooth performance even with many areas displayed
+ Desktop/tablet compatibility

USER INTERFACE
+ Central map occupying most of the screen
+ 3 icons on the right
ÿ One to display geofences on the map without their name (the name will be displayed by hovering
over the area)
ÿ The other to display the geofence names in addition to the zones. ÿ The last to
display the category icon
+ A sidebar has been opened on the left displaying the GEOFENCES. This replaces the asset listing for the
TRACK / LIVE module.
This column is composed of:
ÿ List of geofences already created
ÿ To the right of each geofence name, an icon gives the possibility to either delete the point, modify
it, or display the list of tracers present in the geofence.

ÿ To the left of each geofence name, a checkbox to make them

display or not on the map; you can thus decide to display only one type of geofence on the map
page.
ÿ A " + " icon allows you to display the list of geofences either separately, or
by group
ÿ When the view is grouped, the number of geofences is displayed to the right of the name
of the group
ÿ A search bar to find a geofence in the list
ÿ A " - " icon displays the detailed list of geofences with their attributes
ÿ A " ÿ " icon opens the window for creating a new geofence. ÿ A " ÿ " icon allows you to

reduce or enlarge the column.

Machine Translated by Google

Example user interface under the geofence module

Example: zoom in on the geofence list display

Machine Translated by Google

Example: zoom in on the geofence creation block

MANAGEMENT RULES
ÿ Identification Rules + Name /
Internal Code ÿ The name
can be non-unique (depending on business needs), but the internal code must be configurable and
unique per client (configurable option). ÿ If the internal code is required and unique:
creation will be refused in case of duplicate.

+ Stable reference system

ÿ Each geofence has an immutable ID (UUID) used by others
modules.
ÿ Changing the name/color must not break the Missions / Alerts / links
Dashboards

ÿ Geometric creation and validation rules + Allowed types ÿ The

geofence types are strictly:
Point, Circle, Polygon.
+ Validity of coordinates ÿ Latitude ÿ
[-90 ; 90], Longitude ÿ [-180 ; 180]. ÿ Any invalid geofence is
rejected.
+ Specific rules Circle ÿ Mandatory
radius, configurable min/max (e.g., 10 m to 50 km). ÿ The center must be defined.

+ Specific rules Polygon

ÿ Minimum number of points (e.g., ÿ 3). ÿ
Polygon automatically closed (last point = first) at the time of registration. ÿ Rejection if:

ÿ Self-intersecting polygon ÿ Area that is zero / too

small / too large (parameterizable thresholds)
+ “Active” geofence ÿ A
geofence can be created inactive (draft) and is then: ÿ Neither displayed by default ÿ
Nor used for alerts
Machine Translated by Google

ÿ Not taken into account in the calculations

ÿ Organizational rules (categories & groups)

+ Categories
ÿ A geofence can belong to both a category and a group. Some
examples:
ÿ A service station will be assigned to the category of stations but may
They can also be associated with the "Delivery Point" group for a customer
who transports fuel
ÿ A parcel to be delivered will be assigned to the delivery point category and may
also be associated with a tour
ÿ A waypoint will be assigned to the stage point category and may
can also be associated with a route…
ÿ The categories are configurable per client (free list).
ÿ A geofence must be attached to a single category (simple rule) or to several
(option), but a rule must be chosen and fixed.
ÿ A category can be defined by:
ÿ A default color
ÿ A default icon
ÿ Display rules (optional)
+ Groups
ÿ A group is a set of geofences (e.g., “Tour X”, “Route Y”, “TOP100 Clients”
…).
ÿ A geofence can belong to several groups
ÿ Deleting a group does not delete the geofences; it detaches the geofences
from the group in question.
+ Heritage color/icon
ÿ If a geofence does not have an explicit color/icon, it inherits that of the
category to which it is assigned
ÿ If she has one, she will change it and take the one from the category when she enters it.
will be affected

ÿ Map display rules

+ Default display
ÿ By default, the map loads “active” geofences up to a volume limit (e.g., 200
displayed), otherwise “load on demand”.
+ Filtering
ÿ The user can filter the display by category, by group
ÿ Filters only affect the display, not the alerts.
+ Name and icon
ÿ Multiple display modes:
The geofence is visible without its name. The name appears when hovering over the
area .
- The disintegration is displayed along with its name
The geofence is displayed with the category icon instead of the name.
ÿ The icons are visible if the geofence is "activated".
+ Visual priority
ÿ If several geofences overlap:
ÿ Manage a priority
– e.g., restricted area > danger > delivery > other
- e.g.: small area > medium area > large area
ÿ Use styles (opacity/outlines) to keep each area legible
Machine Translated by Google

ÿ Rules of Law (RBAC)

+ Roles ÿ
Administrator: all (import/export, deletion, configuration). ÿ Supervisor: create/edit
according to authorization. ÿ Operator: read + display +
exports. ÿ All sensitive actions are controlled by role. +
Bulk Editing ÿ Multiple editing is limited to authorized fields
(e.g., category, group, color,
activation). ÿ Disallow bulk geometry editing (or restrict it strictly).

ÿ Import/ export rules

+ Import template
ÿ The system provides an official XLS template. ÿ Only
expected columns are accepted (unknown columns are ignored or rejected according to the rule).

+ Import checks ÿ Rejection if

contact details are invalid. ÿ Duplicate
handling: “skip”, “update”, “reject” ÿ Errors must be reported line by
line.
+ Export ÿ
The export respects the selected filters (category/group/type). ÿ The export
includes an internal ID for re-import (if the update option is enabled).

ÿ Integration rules with TRACK (input/ output)

+ Definition of an “entry/exit” event ÿ An entry event is
created when an object moves from “outside” to
"inside".
ÿ An exit event occurs when it moves from “inside” to “outside”.
+ To avoid border fluctuations :
ÿ Buffer distance threshold (e.g., 10–30 m) or minimum time inside before validating entry (e.g., 30–60
s) ÿ Configurable by client / category.

+ Time spent
ÿ This is the sum of the intervals between validated entries and exits. ÿ If no exits
occur (network loss), the system closes via end of day / last known point.
or timeout (rule to be defined).

ÿ Alert rules / IVMS

+ Activation of alerts
ÿ Alerts (entry, exit, overspeed, time range) can be activated by
geofence, by category, by group ÿ In case of
conflict, a priority rule is defined (e.g., geofence > category >
band).
+ Speeding in zone ÿ If speed >
zone limit for X seconds: alert. ÿ X configurable (e.g., 5–10 sec).

+ Time slots ÿ Each

geofence can have allowed time slots. ÿ If an asset enters or leaves a
geofence outside of its allowed time slot, the geofence must send a notification.
a “time anomaly” alert
ÿ Rule to be established: alert only at the entrance, or continuously if the presence
hard.
Machine Translated by Google

ÿ Rule to be established: alert only upon exit, or continuously if the presence

hard.

ÿ Deletion rules
If the geofence is used by an active mission or in an alert rule, a warning message must be sent to
prevent the geofence from being removed and to offer the option to disable the links.

ACCEPTANCE CRITERIA
Geofence Creation Tests
ÿ Creation by positioning an asset
+ Clicking on an asset's icon allows you to create a geofence
+ Upon registration, the geofence immediately appears in the sidebar list and can be displayed on the map.

ÿ Creation by GPS coordinates

+ By entering a valid latitude/longitude, the user can create a geofence of
type Point.
+ If the latitude or longitude is out of range, the creation is refused with an explicit error message.

+ Upon registration, the geofence immediately appears in the sidebar list and can be displayed on the map.

ÿ Creation by address search

+ A search bar allows you to enter an address and positions the map on the
result.
+ The user can validate the point and create the geofence at that location.
+ If the address cannot be found, a message is displayed and no geofencing is
created.

ÿ Created via card interaction (right-click)

+ Right-clicking on the map allows you to “Create a geofence here”.
+ The clicked position is used as the basis for creation (center of the circle or point)
initial of the polygon).

ÿ Creation of a circular area

+ The user can choose “Circle”, define a center and a radius.
+ The radius respects configurable min/max limits (otherwise refusal with message).
+ The circle is visible on the map after saving.

ÿ Creating a polygonal area

+ The user can choose “Polygon” and draw a minimum of 3 points.
+ The system automatically closes the polygon upon saving.
+ A self-intersecting or invalid polygon is rejected with an explicit message.

ÿ Mandatory / optional attributes

+ Fields marked as “required” (e.g., Name, Category) will prevent registration if they
are empty.
+ Colour and icon are applied to the display as soon as it is created.
+ The comments are recorded and reproduced exactly as they were written.
Machine Translated by Google

Tests on Categories, Groups, and Settings

ÿ Category Management
+ An administrator can create / modify / delete categories.
+ A category can have a default color and icon.
+ Deleting a category is: ÿ either
prohibited if geofences are attached to it, ÿ or allowed
with mandatory migration to another category (rule to be chosen and respected).

ÿ Groups of geofences
+ An authorized user can create a group and give it a name.
+ A geofence can be attached to a group.
+ In “grouped” view, the group displays the geofence counter .
+ Deleting a group does not erase geofences (they are only
detached).

Tests for visualizing and editing geofences

ÿ Side list (replaces the TRACK listing)
+ The left sidebar displays the client's list of geofences.
+ The list can be filtered by category and
group. + A search bar allows you to find a geofence by name.

ÿ Actions on a geofence from the list

Each geofence has: ÿ A
checkbox (show/hide on the map) ÿ An action icon
(edit / delete / view existing trackers)
+ The “show/hide” button acts immediately on the map without reloading.

ÿ Single edition
+ An authorized user can modify:
o The attributes of a geofence (name, color, icon, category, group,
comment) o
Its perimeter (if allowed)
+ The changes are immediately reflected on the map.

ÿ Multiple edition
The user can select multiple geofences and edit fields in bulk.
allowed.

ÿ Rights management + An
unauthorized user cannot see the “Create / Edit / Delete” buttons.
Any attempt to directly access an unauthorized action via URL/API will return a
Access error.

Tests for display on the map ÿ Display

options (icons on the right)
Three buttons allow you to: ÿ
Display geofences without names (name appears on
hover) ÿ Display geofences with names
Machine Translated by Google

ÿ To display geofences with icons

+ Activation/deactivation is instantaneous.

ÿ Combined display of vehicles and geofences

+ It is possible to display objects (vehicles / trackers) and the
geofences
+ Performance remains smooth in a defined target scenario (e.g., 200 geofences + 100 visible objects).

Import/Export Test
ÿ Import template
+ The system offers a “Download import template” button.
+ The template corresponds exactly to the expected column layout (name, type, coordinates,
(Rail size, category, etc.).

ÿ Import XLS / KML

+ The user can import an XLS/XLSX or KML file.
The system validates the format, coordinates, and type, and reports errors line by line.
line
The system displays an import report with the number of geofences created, the number of
geofences ignored, the number of errors, and details .

ÿ Export
+ The user can export the geofence database in XLS/XLSX format.
+ The export respects the selected filters (category/group/type if applied).

Test on Alerts and IVMS

ÿ Enabling/ disabling alerts
+ On each geofence or category, the user can enable/disable entry/exit, overspeed, and
anomalies during specific time periods

ÿ Overspeed on geofence
+ If an object exceeds the maximum speed defined in the area for a threshold duration, an alert is
generated.
+ The alert contains at a minimum the object concerned, the name of the geofence, the date and
the time, the recorded speed and the GPS position

ÿ Time slot
+ If an object enters or remains in an area outside the permitted range, the alert
The corresponding item is generated (according to the rule).
+ The time slots are configurable (days + hours).

Test concerning the detection of “tracers present in the geofence”

+ From the dedicated icon, the user can display the list of currently active trackers
“within” the geofence.
The list displays the tracker's name, its last position, arrival time, and duration.
presence
+ The results are consistent with the real-time position.
Machine Translated by Google

Removal Test
ÿ Single deletion + Deletion
requires confirmation.
+ If a geofence is linked to an active mission or a critical rule, a request
Authorization request is sent with automatic action defined (disabling links).

ÿ Multiple deletion + The user

can delete multiple geofences in one action.
+ The system returns a summary: deleted / rejected / reasons.

Logging & auditing (to meet our certification requirements)

+ Every creation/edit/deletion/import/export action is logged with:
ÿ User identification ÿ Date/time ÿ Action
ÿ Before/after (at least
for key fields)

+ An administrator can view the history.

Non-functional criteria
ÿ Performance
+ Map display and geofence list loading: < 2 seconds (on dataset)
target).
+ API “geofence list”: < 200 ms for 1,000 geofences (with pagination).

ÿ Robustness
+ No UI crash if a geofence has missing data: message + fallback.
+ Imports do not block the application (async processing or with a bar)
progression).

ÿ Security
+ All API routes are secure (auth + RBAC).

CONSTRAINTS & DEPENDENCIES

Internal dependencies (platform modules) ÿ Dependence on the

mapping engine
The GEOFENCES module depends on a board component capable of:
+ Display layers (areas + objects)
+ Draw/edit polygons and circles
+ Manage zoom / clustering / performance

Constraint: without a stable mapping engine, the UX (drawing, editing, massive display) is unusable.

ÿ Dependence on the TRACK / LIVE module (real-time objects)

The requirements for "seeing trackers present in a geofence", entry/exit, etc., necessitate: + A reliable position
source (GPS) + A standardized point format
(latitude, longitude, timestamp, speed...
Machine Translated by Google

Constraint: if the TRACK / LIVE data is not in real time / out of service, the operational functionalities (presence,
alerts) are degraded.

ÿ Dependence on the MISSIONS / TOURS module

Geofences serve as:
+ Starting and/or arrival points
+ Milestones
+ Milestones
+ Route/corridor zones

Constraint: any modification/deletion of a geofence may impact an ongoing mission ÿ locking rules

ÿ Dependence on the ALERTS / IVMS module

The rules for “speeding”, “prohibited zone”, and “time zone” are based on:
+ An event engine
+ Threshold management

Constraint: without a robust alert engine, GEOFENCES is only a visual module (loss of business value).

ÿ Dependence on the DASHBOARDS / REPORTING module: The indicators

(time spent, entries/exits, etc.) are based on: + Historical storage of geofence
events + Aggregation (day/week/month)

Constraint: if historical data is not planned from the start, it will be difficult to reconstruct the KPIs.

External dependencies (third-party

services) ÿ Geocoding / Reverse geocoding (address lookup)
+ Dependence on an address service for: ÿ Searches ÿ
Converting addresses
to coordinates ÿ Converting coordinates to addresses

Constraints:
+ Quotas / costs
+ Coverage varies by country
+ Network latency
+ Need for a fallback (limited search or cache)

ÿ Import/ Export KML and XLS(X)

Dependence on KML import libraries and Excel parsing.
Constraints: +
Frequent malformed files + Large data
volume + Need for validation
+ Error reporting
Machine Translated by Google

Design constraints (business + UX) ÿ

Consistency between “display” and “engine”
What is displayed on the front end of the map must be identical to what is calculated on the back end.
(input/output).

Constraint: avoid calculation discrepancies between the information visible on the map and in
the reports ÿ define the “source of truth”.

ÿ GPS noise cancellation (hysteresis) mandatory Without

a buffer/minimum duration, a vehicle can generate hundreds of entries/exits at the border.

Constraint: imposes a configurable global rule (buffer in meters and/or delay in seconds).

ÿ Volume management (readability)

+ Too many areas displayed = unreadable and slow map.

UX constraints:
+ Loading limits (pagination / lazy load)
+ Required filters
+ Label clustering/masking

ÿ Overlapping zones (conflicts)

Multiple geofences can overlap.

Constraint: define a priority rule: • By

category (prohibited area > danger > delivery…) • Or multi-
alerts (generate all alerts) as needed.

Lifecycle constraints (deletion, modification) ÿ Deletion of a

referenced geofence
+ If a geofence is used in: ÿ An active mission ÿ
An alert rule ÿ A reporting
KPI

Constraints :
Physical removal is not recommended .
+ Prefer a soft delete + deactivation

ÿ Geometry modification and impacts

+ Changing the shape of an area can change the analysis history.

Constraint :
+ Option versioning (at a minimum, trace “old geometry”)
+ Locked if mission is active

Data dependencies
To function correctly, GEOFENCES needs:
+ Object data: object ID, last position, timestamp, speed, state
+ Customer reference data: categories, groups, roles
Machine Translated by Google

+ Customer settings: noise thresholds, default speeds, time rules

+ Historical events (if KPI): entries, exits, durations, violations

Constraint: without client reference data and parameters, multi-client usage cannot be industrialized.

TRACK/LIVE SUB-MODULE
CONTEXT & OBJECTIVES
1.1 Description
The TRACK/LIVE sub-module allows for the real-time display of all fleet assets and their
operational statuses. When a user selects an asset, they should be able to instantly view all
information from the installed devices: GPS beacons, probes, onboard cameras, LCD screens,
various sensors, etc.

1.2 Objectives
The goal is to offer a unified, modern, and seamless view, without having to navigate between
multiple independent interfaces. The module must consolidate all available data, making
monitoring faster, more reliable, and better structured.

This module is essential for the operational management of the fleet, as it constitutes the user's
entry point to monitor activity, detect anomalies, access strategic data and trigger actions.

FUNCTIONAL SCOPE
ÿ Feature 1: Real-time asset tracking – Priority P0
+ Display in real time the position and overall status of all assets on a map.
+ The map refreshes automatically at a configurable interval.
Each asset has a color code defining its overall state (stopped, moving, engine
running, engine off, and alert), based on the equipment
installed.

ÿ Feature 2: Asset Group Management – Priority P0

+ The user can select one or more groups of assets to display.
+ The groups are defined in advance.
+ The map only shows the selected assets, and the side listing updates automatically.

+ The map can display asset icons and/or asset names

ÿ Feature 3: Smart Search Bar – Priority P0

+ An instant search allows you to find an asset based on: its license plate, its brand, its
model, the driver, the equipment number, its personalized name, the associated
geofence, any other criterion... Instant results from the first letter.

ÿ Feature 4: Advanced Filters – Priority P1

+ Quick filters: movement/stop/pause status, GPS quality, anomalies, devices
offline, fuel problems, temperature out of range, etc.
Machine Translated by Google

We need to start with a filtering system that works in the search bar (e.g., Odoo's system).

ÿ Feature 5: Different maps available – Priority P1

+ Google Maps display (license), satellite mode, hybrid mode, route mode
+ OpenStreetMap display.
+ Ability to switch between modes.
+ Clickable icons on the map page

ÿ Feature 6: Google Street View Integration – Priority P2

By clicking on an asset, the user can display the Street View of the location they are in.
found. It is redirected to a Google Maps page

ÿ Feature 7: Traffic + Google Speed Limit – Priority P1

+ Overlay real-time traffic data provided by Google (traffic information) and display the Google speed limit at
the location of the asset (if available).

ÿ Feature 8: Display and management of geofences – Priority P0

+ Display all geofences on the map as needed (by selecting or not the
functionality). It will be possible to display either only the area without the name, or both.

+ Possibility of creating them directly from the TRACK module, using the visible assets as markers.
Machine Translated by Google

ÿ Feature 9: Display of the last trip

+ Display the last trip on the map if needed (by selecting or not the
functionality via a clickable icon on the map).

ÿ Feature 10: Map Adjustments – Priority P1

+ Framing button to automatically display all filtered assets
+ Floating banners to view the map in full size

ÿ Feature 11: Search for places/ addresses – Priority P1

+ Search for a location, address, or existing geofence from a bar
dedicated
ÿ By indicating the address
ÿ By providing your GPS coordinates (in degrees, minutes, or decimals)

ÿ Feature 12: Temporary Location Sharing – Priority P2

+ Allow the user to generate a temporary link (2h, 4h, 24h, X days)
allowing a third party to view the live position of an asset without creating an
account

ÿ Feature 13: Actual distance between two points – Priority P1

+ Calculation of road distance (not as the crow flies) between two assets or between an
asset and a selected address (identification of a smart path between two points).

ÿ Feature 14: Lateral asset listing – Priority P0

+ The left column lists the assets visible on the map, each with:
ÿ Color code according to overall status (stopped, moving, engine paused, engine ON, engine country)
OFF, alert)
ÿ Asset name (configurable according to the user)
ÿ Real-time icons (engine status, fuel level, key connected, temperature, if
equipped)
ÿ Exact address of the last location
ÿ Name of the geofence
ÿ Customizable visual display (show or hide certain information)
ÿ Subline by device
ÿ GPS beacon: battery level + GPS signal strength + GSM signal strength
- Camera: status (online, paused, alert) via color code
ÿ LCD screen: specific status icon
ÿ Other installed equipment: padlock, cutoff relay, reader
driver)
ÿ The listing is synchronized with the map: selection on the list = map focus
Machine Translated by Google

ÿ Feature 15: Real-Time Live Banner – Priority P0

When an asset is selected, a banner appears at the bottom of the screen with all the essential data. This
information, presented as a "summary card," is customizable. The user chooses which "summaries"
are displayed and the order in which they appear in the banner.

ÿ Main information:
ÿ Asset name / plaque
- State (moving, stopped, paused with engine OFF, paused with engine running)
and corresponding duration
ÿ Instantaneous speed
- Last communication with the platform (timestamp + time)
(elapsed)
- Exact address and/or geofence if available
- ECU odometer (priority) or GPS odometer by default

ÿ Signal quality:
- GSM power (low / medium / good / excellent)
- GPS quality (low / medium / good / excellent)

ÿ Vehicle identification card

- Make, model, registration number, chassis, energy type, tank size,

ÿ Driver's identity card (if assigned):

- Driver's name
- Phone number
- Permit number + expiry date
ÿ Email
ÿ Title / role (symbolized by an icon)

ÿ Sensors and real-time data:

Machine Translated by Google

- Real-time fuel level (% and/or liters)

- Real-time temperature(s) (fridge, compartment, etc.)
- Remote shutdown - Other
information available: door opening, other sensors etc.

ÿ Events and invariants:

- Display of event labels: fuel alert, speeding, geofence violation, signal loss, etc.

- Defined business invariants (energy type, vehicle class,

engine configuration, etc).

ÿ Administrative data (insurance, stickers, deadlines)

ÿ Maintenance data (last and next maintenance, alerts)

ÿ Fuel management data

ÿ Eco-driving data

ÿ Activity data: % stop, % engine pause ON, % engine pause OFF, %

rolling

ÿ Feature 16: LIVE Cameras Module – Priority P1

+ From the banner, clicking on the camera icon opens the asset's camera feeds.
+ Possibilities:
ÿ Display multiple assets simultaneously (up to 16 feeds max) ÿ Automatic mosaic
mode 1 / 2 / 4 / 9 / 16 ÿ Full-screen zoom of a camera ÿ
Camera network quality indicator ÿ Camera
status visible in the listing and banner
Machine Translated by Google

DETAILED USE CASES

ÿ Operational monitoring of an asset
+ Actor: Fleet operator
+ Actions: ÿ
Opens the TRACK / LIVE module.
ÿ The map displays all the assets of its group.
ÿ
He clicks on an asset in the left-hand list
ÿ The map centers on the asset, the last trip appears, the banner is displayed.
+ Result : The operator can see at a glance the asset's status, its current position, the
Driver data, their last trip, signal quality, fuel level, temperature, and ongoing events

ÿ Managing a "fuel" alert

+ Actor: Safety/Fuel Manager

+ Actions: ÿ A
"fuel alert" appears on an asset's banner.
ÿ
He clicks on the relevant asset.
ÿ
In the banner, he consults the fuel data and the recent route (trace on the map).

ÿ
It switches to fuel management data via the dedicated button.

+ Result: It quickly identifies a leak, siphoning, or inconsistency in

consumption and can trigger actions.

ÿ Multi-asset live camera viewing

+ Actor : Security Manager

+ Actions :
ÿ From an asset's banner, he clicks on the camera icon
ÿ The cameras of the asset are displayed in a mosaic.
Machine Translated by Google

ÿ
He selects a second asset equipped with cameras.
ÿ The camera module automatically switches to 4 views (for example)
+ Results : It simultaneously monitors several situations (site entry, loading, etc.), with the ability to
zoom in on a particular view

ÿ Creation of a geofence based on real-world routes

+ Actor : Operational Manager
+ Actions :
ÿ
It filters assets within a specific area.
ÿ
He selects an asset and views its last journey.
ÿ
He uses the geofence creation tool to draw an area corresponding to a client site + Result : A new
geofence is created
directly from TRACK/LIVE, immediately usable for future alerts
Machine Translated by Google

ÿ Temporary location sharing

+ Actor: Operator
+ Actions:
ÿ
He selects an asset to be monitored by an external client.
ÿ
He clicks on a "Share location" option.
ÿ
He chooses a duration (for example 24 hours).
ÿ
He obtains a link to send to the third party.
+ Result: The third party can only track this asset in real time for the duration
defined, without access to the rest of the platform.

TECHNICAL REQUIREMENTS
ÿ Required data
+ GPS data: latitude, longitude, altitude (if available).
+ Instantaneous speed, direction.
+ Engine status (on/off, RPM if available via ECU/CAN).
+ ECU odometer (priority) and/or GPS odometer.
+ GPS device data: battery, GPS signal quality, GSM quality.
+ Camera data: status (online / offline / paused), video stream, last image.
+ Fuel sensor data: fuel level (%, liters), consumption, alerts,
anomalies.
+ Temperature sensor data: temperature(s) per zone / compartment.
+ LCD screen data: connection status, last update.
+ Driver data: name, phone, email, license number + expiry date, role.
+ Vehicle administrative data: make, model, year, fuel type,
capacity, insurance dates / technical inspection, fuel type, fuel consumption per 100 km etc…
+ Maintenance data: last maintenance, next maintenance, odometer reading,
alerts.
+ Activity data: cumulative time spent driving, stopped, with engine ON, with engine OFF, etc…

+ Geofencing data: definition of zones, type (site, warehouse, client, restricted area, etc.).
+ Traffic and speed limit data (via map APIs).

ÿ Required integrations
+ FLEET CENTER module: list of assets, groups, vehicle data.
+ FLEET CENTER module: list of equipment by asset, status, technical data.
+ ANALYTICS module: fuel levels, alerts, history.
+ ANALYTICS module: other sensors, alerts.
+ FLEET CENTER module: driver information, documents, status.
+ TOOLS Module: GLOBOFLEET for maintenance integration, upkeep, and other
alerts
+ Video streaming service for dashcams (internal or external API).
+ Secure link generation service for temporary location sharing
+ Mapping APIs:
ÿ Google Maps (maps, traffic, Street View, speed limits)
ÿ OpenStreetMap

USER INTERFACE
+ Main screen TRACK / LIVE
+ Central map occupying most of the screen.
+ Floating left column (column size can be reduced):
Machine Translated by Google

ÿ Asset listing with color-coded overall status. ÿ Fuel/

temperature icons if equipment is present. ÿ Exact address
for each asset. ÿ Detailed device
information line by line (beacons, cameras, LCDs, etc.). ÿ Top
bar or dedicated area: ÿ Asset group
selection. ÿ Simple/advanced
filters. ÿ Smart search bar
(asset, driver, geofence, address, etc.). ÿ Buttons: map type, traffic, Street
View, full screen, geofences.
+ Live banner (bottom of the screen, visible only when an asset is selected)
+ Vehicle identity block and status: name, plate, status (on/off/pause) + duration, engine on/
off, last communication, address, geofence, odometer.
+ Signal blocker: GSM power, GPS quality.
+ Driver block: name, role icon, phone, license + experience, email +
Accessories block: fuel, temperature(s), other real-time sensors.
+ Events block: labels for current/recent events.
+ Invariant block.
+ Quick access buttons: ÿ Vehicle
ID card ÿ Driver ID card ÿ
Administrative data ÿ Maintenance
data ÿ Fuel data ÿ Activity data ÿ
Camera icon: opens the live
camera module. + Camera
module screen ÿ Dynamic
grid: 1, 2, 4, 9, 16 views. ÿ Ability to add/remove assets from
the mosaic. ÿ Camera status
information (online, paused, alert). ÿ Zoom/full
screen control on a view.

MANAGEMENT RULES
Rule 1
If a device has not communicated for more than X time (configurable), its status automatically
changes to offline and the information must be visible in the listing and banner.
Rule 2
When an asset is selected, the banner should display in less than 500ms with the
available data.
Rule 3
Elements not available for an asset (e.g., temperature if no sensor) should not appear in the
banner or in the listing (no empty areas).
Rule 4
If there are multiple position sources, the main GPS beacon takes priority; switching
to another source must be explicit (rule to be defined for example if GPS Beacon + GPS
MDVR).
Rule 5
In case of video camera data loss, a stream loss indicator is needed.
Machine Translated by Google

Rule 6
When a user changes their selected asset, the banner is updated with the new asset's information, and
the route displayed on the map corresponds to the last route taken by that new asset.

Rule 7
Temporary location sharing must respect the defined durations; beyond that, the link automatically becomes
invalid.
Rule 8
The maximum number of camera feeds displayed simultaneously is limited to 16. Beyond that, the user
must deselect a feed to add another.
Rule 9
The color codes for status (active while driving, stopped, paused, alert) must be standardized and consistent
across the map, listing, and banner.
Rule 10
The distance between two points used in the module must be the calculated road distance, not the straight-line
distance.

Rule 11
The display of widgets depends exclusively on the devices and accessories installed and active on the active device.

Rule 12
If a device is installed but temporarily offline, the widget remains displayed with an “offline” state.

Rule 13
The widgets must be updated independently of each other, without a full banner reload.

Rule 14
The order in which the widgets are displayed must remain consistent between the map, the listing and the
banner (same color codes, same statuses).
Rule 15
The display of widgets depends on the asset's configuration (assigned driver, installed accessories, activated
settings).
Rule 16
If an accessory is not installed on an asset, the corresponding widget should never be displayed.

Rule 17
The widgets can be rearranged in the banner without impacting their content or behavior.
Machine Translated by Google

ACCEPTANCE CRITERIA
Test 1

Condition: One asset is in circulation.

Action: The user opens TRACK / LIVE.
Expected result: The asset is visible on the map and in the listing, with a code or icon indicating the rolling
status.

Test 2

Condition: The user types a partial license plate into the search bar.
Action: He enters the first 3 letters/numbers.
Expected result: The corresponding asset appears in the list in less than 1 second.

Test 3

Condition: An asset is selected via the listing.

Action: Click on the asset.
Expected result: The map centers on it, the last route is displayed in color and the banner appears with real-
time data.

Test 4

Condition: One asset has a fuel probe and temperature sensor.

Action: Opening the banner.
Expected result: Fuel level and temperature appear with associated icons.

Test 5

Condition: Data from a device has stopped arriving after a certain period of time (X time).
Action: Refresh the TRACK screen.
Expected result: The device is marked offline in the listing and banner.

Test 6

Condition: The user clicks on the camera icon of an asset equipped with cameras.
Action: Opening the camera(s).
Expected result: Live feeds from this asset appear in mosaic; possibility to switch a camera to full screen.

Test 7

Condition: The user selects 3 assets equipped with cameras.

Action: Successive addition to the mosaic.
Expected result: The feeds are displayed in a 4-view mosaic (if 4 or more cameras), in the order of selection.
Machine Translated by Google

Test 8

Condition: The user creates a geofence from TRACK.

Action: He draws an area on the map and confirms.
Expected result: The geofence is saved and displayed on the map; it is instantly available to other modules.

Test 9

Condition: The user generates a location sharing link for 24 hours.

Action: He shares the link and waits for it to expire.
Expected result: The link allows real-time tracking for only 24 hours, then becomes invalid.

Test 10

Condition: The user enables the display of traffic and speed limits.
Action: He centers the card on a rolling asset.
Expected result: The Google traffic layer is visible and the local speed limit is indicated.

Test 11
Condition: An active unit without a fuel sensor is selected.
Action: Displaying the banner.
Expected result: No fuel widget is displayed.

Test 12
Condition: A device stops communicating.

Action: Real-time banner update.

Expected result: Only the widget in question changes state, without reloading the banner.

Test 13
Condition: An asset with an assigned driver.

Action: Displaying the banner.

Expected result: The Driver widget is visible with all available information.

Test 14
Condition: An asset without an assigned driver.

Action: Displaying the banner.

Expected result: The Driver widget does not appear.

Test 15
Condition: An active ingredient with a temperature sensor.

Action: Displaying the banner.

Expected result: The Temperature widget displays all available values.

Machine Translated by Google

Test 16
Condition: An accessory becomes offline.

Action: Real-time banner update.

Expected result: Only the widget in question changes state, without a global reload.

CONSTRAINTS & DEPENDENCIES

Technical constraints
+ Dependence on network quality and device transmission frequency.
+ Large volume of real-time data (GPS, video, probes) requiring an optimized architecture.

+ Need for standardization of information from different brands

devices.
+ Potential limitation related to map licenses (Google).
+ Need to properly manage disconnection/reconnection cases to avoid
display outdated data.

Module dependencies
+ FLEET module (asset structure, groups).
+ FLEET CENTER module.
+ ANALYTICS module.
+ DRIVER module.
+ TOOLS Module (GloboFleet)
+ Map integrations (Google Maps / OSM).
+ Video infrastructure for onboard cameras

HISTORY & REPLAY SUB-MODULE

GOALS
The History & Replay module allows a complete, interactive and animated review of the journeys made by a vehicle,
combined with a monthly summary calendar view.
The user can select a day, view all journeys, replay the vehicle's movement on the map at different speeds, analyze
events (stops, speeding, incidents, geofence entries/exits), and then export a complete report (PDF, CSV, or HD image).
The perfect synchronization between the map, the timeline, and the real-time indicators provides a detailed understanding
of the vehicle's behavior and any potential anomalies.

This sub-module must combine:

+ An interactive timeline,
+ A map with animated review,
+ Detailed statistics,
+ A summary monthly calendar view,
+ And visual and data exports.
Machine Translated by Google

FUNCTIONAL SCOPE
ÿ Feature 1: Selection criteria
+ Selection of a period, an asset or a driver from the list of assets and/or
driver

ÿ Feature 2: Detailed history by trip and stop

+ Activity History
ÿ In motion: with start, end, driver or vehicle, VMAX per trip,
distance, duration, fuel consumption, engine hours
ÿ At a standstill: location, start, end, duration
+ Event history (overspeed, entry/exit from geofences…)

ÿ Feature 3: Graphical visualization of speed peaks

ÿ Feature 4: Route display on map and replay mode

+ The asset moves around the map with controls for play, pause, stop, fast forward x2.
x4 to x6
+ On the route, using clickable icons on the map page, allow users to show or hide stop
markers, alarms, and route direction arrows.

ÿ Feature 5: Export Detailed Historical Report + HD Image of

the route
+ Export of activity history for a period of time, including images, in PDF and Excel formats.
journeys

ÿ Feature 6: Calendar View – Simplified Monthly Mileage

+ Display of a monthly calendar showing daily
Machine Translated by Google

ÿ Distance traveled or activity duration (selectable) ÿ Hovering over a cell

displays the driver, activity time, distance and
Fuel consumption ÿ Setting an indicative
color code based on customizable thresholds

ÿ Feature 7: Display of actual and theoretical route

+ Simultaneous display of the theoretical route (if configured in the mission module) and the actual display to
quickly visualize corridor exits

ÿ Feature 8: Export a replay in video format

+ Ability to export the replay in video format such as VLC, MOV or MP4 + Share the file via a
link that can be transferred by email or on WhatsApp.

DETAILED USE CASES

ÿ View a vehicle's route on the map over a given period
+ Actor : Operational Manager
+ Actions : ÿ
Open the History sub-module, "Movement Mapping" view ÿ Select the tracker ÿ Choose the time
period ÿ Click on "Show History"

+ Results : the manager visualizes the route for the period on the map.

ÿ Obtain speed curves and locations of infractions

+ Actor : Operational Manager
+ Actions : ÿ
Open the History sub-module, "Movement Mapping" view ÿ Select the tracker ÿ Choose the period
ÿ Click on: display history ÿ Click
on the "alarm" icon in the
right-hand bar

+ Results : the manager can visualize the locations of infractions as well as speeding peaks
Machine Translated by Google

ÿ Replay a journey
+ Actor : Operational Manager
+ Actions : ÿ
Open the History sub-module, "travel mapping" view
ÿ Select the plotter
ÿ Choose the period
ÿ Click on show history
ÿ Select the replay display speed
ÿ Press play
+ Results : The manager sees the tracker moving on the map

ÿ Identify excess mileage

+ Actor : Operational manager of a vehicle rental agency
+ Actions : ÿ
Open the History sub-module, "distance calendar" view
ÿ Select one or more plotters
ÿ Choose the period
ÿ Click on show calendar
+ Results : The manager sees the distance traveled per day by tracker. If he has applied
As a management rule, colors will be displayed to identify vehicles whose mileage
exceeds the rental contract in red...This will allow the end customer to be
alerted to the contractual overrun.
Machine Translated by Google

TECHNICAL REQUIREMENTS
The History & Replay module is based on the consumption and use of historical GPS data, enriched by geographical
and business events, and integrated across the tracking, geofencing, mission, alert and reporting modules.

ÿ Required data

Basic data – GPS history (required)

The History & Replay module relies on comprehensive, time-stamped storage of GPS positions. For each historical
point, the following fields are required: + Unique vehicle/tracker identifier + Client identifier
(multi-tenant)

+ Date & UTC time of the GPS point + Latitude

coordinates + Longitude
coordinates + Instantaneous speed
+ Vehicle orientation

Constraints: +
The data is immutable (no modification afterward).
+ The original GPS accuracy must be maintained.
+ The temporal order must be strictly respected.

Data calculated (from GPS points)

This data is not always stored but must be able to be calculated or reconstructed :

+ Calculating the distance between two points

+ Mileage calculation
+ Journey time
+ Downtime
+ Asset status: on / off / paused
+ Average/maximum speed for performing analyses and graphs

Related parameters:
+ Stopping speed threshold (e.g., < 5 km/h)
+ Minimum duration to consider a stoppage (configurable)
Machine Translated by Google

Event data (related to history)

Events enrich the review and analysis:
+ Geofence entry/exit from the GEOFENCES module
+ Speeding according to the speed rules / IVMS
+ Extended pause since the historical calculation
+ Mission diversion from the MISSIONS module
+ Start/end of mission from the MISSIONS module

Constraints: +
Each event must be time-stamped.
+ The event must be synchronized with the replay timeline

Client configuration data: The module

must consume parameters configurable per client: + Stop threshold (minutes)

+ Stop speed threshold +

Trace colors + Graph
granularity (1 min, 5 min…)
+ Historical data retention period

Summary data / aggregates

Used for:
+ Calendar view
+ Widgets +
dashboards

Examples: Kilometers per day / week / month, driving time, stopping time, time spent in geofence

ÿ Required integrations

Integration with the TRACK / LIVE module:

Ensuring continuity between real-time and historical data.
+ Consumption: GPS position data and object states (movement, pause, stop)
+ Continuity: a real-time point becomes a historical point + Consistency: same
calculation logic (speed, state)

Integration with the GEOFENCES module to

contextualize journeys.
+ Display of geofences during replay
+ Event handling: input, output
+ Calculations: time spent in a zone, number of passages
+ Synchronization: display of a geofence event at the exact moment of the replay

Integration with the MISSIONS & TOURS module Execution control.

+ Overlay: planned route, actual route + Identification:

delays, diversions + Synchronization:
milestones/stages, planned ETA vs. actual

Integration with existing WIDGETS . Consistent

UX & navigation.
+ Widgets concerned:
Machine Translated by Google

ÿ Today's Activity ÿ
Today's Route ÿ
Distances ÿ
Speeds ÿ Eco-
driving ÿ Interaction:
click on widget ÿ opens filtered replay
+ Sharing of aggregated data

Integration with the ALERTS / IVMS module

Post-event analysis.
+ Review of alerts over time + Correlation:
speed, location, geographical context + Filtering by alert
type, by period

Integration with the DASHBOARDS & REPORTING module

for business intelligence.
+ Provision of aggregated data: distances, durations, infractions +
Graphical input, KPI indicators + Consistency:
same figures between replay and dashboard

Integration with exports (Reporting)

+ Export CSV / XLS: GPS points, routes, stops, events
+ Export PDF / image: map + route + summary
+ Strict adherence to filters, time periods and user rights

USER INTERFACE
The History & Replay module interface should allow the user to:
+ To visually reconstruct a past journey in a faithful and fluid manner
+ Analyze the activity of a vehicle over a given period
+ Understanding where, when, and why an event occurred
+ Generate actionable evidence and reporting materials

The interface must be:

+ Time -oriented + map
+ Readable for a non-technical user
+ Performs well even with high data volumes

ÿ Access to the module

The History & Replay module must be accessible from:
+ The main menu (under the "History / Replay" module)
+ One click from:
ÿ A vehicle in TRACK / LIVE ÿ A widget (Daily
trip, Daily activity, Distances, Speeds) ÿ A mission (replay filtered to the mission
period)
In all cases, the module opens with:
+ The pre-selected vehicle
+ The corresponding period (current day by default)

ÿ General screen structure

The main screen is structured into 4 fixed zones
+ Top selection bar (active / driver / period)
+ Data history sidebar
Machine Translated by Google

+ In the top right corner, the map with the route displayed
+ At the bottom, the timeline/schedule with the replay function buttons

Example illustration of the main screen

ÿ Top bar – Selection & filters

+ Vehicle selection
ÿ Drop-down list of vehicles accessible to the user ÿ Search by name /
registration number ÿ Changing vehicles
automatically reloads data without having
need to change the period
+ Driver selection ÿ Search by name
ÿ Driver change automatically
reloads data without having
Need to change the period ? + Select
period ÿ Date picker: day, custom
range ÿ Shortcuts: Today, Yesterday, Last 7 days, Current
month, Last month… ÿ Explicit message if no data available
Machine Translated by Google

Sidebar illustration

ÿ Central map – Route visualization

+ Display of the path
ÿ Complete route tracking over the selected period
ÿ Drawing style: continuous line, configurable color
ÿ State-based segmentation option: movement, stop, pause

+ Displayable elements (buttons)

The user can enable/disable the display of geofence zones, their names, the display of
event points (alerts, entries/exits), the display of breakpoints.

+ Vehicle position replay

• Animated vehicle icon
• Orientation according to the heading
• Tooltip on click showing GPS coordinates, a street view link, time data, speed, driver name, fuel consumption,
address and geofence (if available), event name if the click is on an event alert point.
Machine Translated by Google

ÿ Sidebar – Data & Summary

The left sidebar is organized into tabs:
+ Tab 1 – Summary ÿ Total
distance ÿ Driving time
ÿ Stop time ÿ Average/
maximum speed ÿ
Activity start/end time

+ Tab 2 – Routes
ÿ List of detected routes: start time, end time, distance ÿ Click on a
route: map zoom, replay filtering
+ Tab 3 – Stops
ÿ List of stops: location, duration, associated geofence (if applicable)
+ Tab 4 – Events
ÿ Alerts ÿ
Geofencing entries/exits ÿ Mission
diversions ÿ Filtering by
event type
Machine Translated by Google

Example illustration of the sidebar with data and summaries

ÿ Timeline and replay engine + Timeline

(chronogram) ÿ Horizontal timeline ÿ
Graphical representation: states
(on/off), events (icons) ÿ Time zoom: overview and detailed view + Playback control buttons
ÿ Play, Pause, Stop and playback speed increase (x2, x4 …)

+ Synchronization ÿ
Moving the cursor updates the map and side data ÿ Strict synchronization based on GPS
timestamp

ÿ Calendar view – Distances & activity

+ Monthly view
ÿ Calendar displaying kilometers per day ÿ Color coding
based on thresholds configurable by the client ÿ Clicking on a day opens
the day's replay
+ Comparative view (optional) ÿ
Comparison of days/weeks ÿ Highlighting
anomalies (days without activity, long distances)
Machine Translated by Google

ÿ Exports & sharing

+ Export actions (dedicated button)
ÿ Export to CSV/XLS of GPS waypoints, routes, and stops ÿ Export to
PDF with map and route, as well as summary ÿ Export to image with map
screenshot ÿ Export to video file

+ UI Constraints
ÿ Exports respect: the selected period and active filters ÿ Visual indication: export in
progress, export complete / error

ÿ Rights Management & UX

ÿ The displayed data respects user rights and the authorized scope. ÿ The export, replay, and event
buttons are hidden or disabled depending on the
role

ÿ Non-negotiable UX principles ÿ Smooth replay

(no UI freezes) ÿ Continuous user feedback
(loading time, missing data, etc.) ÿ Readability even with dense data ÿ Visual consistency with other modules
(TRACK, Missions, Widgets)

MANAGEMENT RULES
ÿ Data scope
+ The data displayed in History & Replay is strictly limited :
ÿ To the connected customer (multi-
tenant) ÿ To the vehicles to which the user has access according to their rights
No data belonging to another client should be accessible, even through manipulation.
URL or API.
+ Rights Management
ÿ Administrator : full access (history, replay, exports, graphs) ÿ Supervisor/Manager : access
to replay, analytics, exports
Machine Translated by Google

ÿ Operator / Read only : consultation only (no export if not

allowed)
Unauthorized buttons and actions are hidden or disabled .
with explicit message

ÿ Rules for selecting an asset and a period

+ Vehicle selection
ÿ Only one vehicle is selected at a time in the History & Replay module.
ÿ Any change of vehicle automatically reloads the data and resets the replay
and timeline
ÿ If no GPS points are available for the period, an explicit message is displayed
and the map remains centered on the last known position (if any).
+ Selecting the period
ÿ The period can be selected via:
- The calendar (day)
- Shortcuts (Today, Yesterday, Last 7 days)
- A personalized beach
ÿ Any change in the period triggers:
- A recalculation of the routes
- A recalculation of the stops
- A recalculation of the summary statistics
ÿ Out-of-period data should never appear in the map, timeline, or exports

ÿ Route planning rules

+ Definition of a route. A route is defined as a succession of GPS points
without interruption exceeding a configured stopping threshold
+ Definition of a stop. A stop is recognized if the speed is below a threshold
defined (e.g., < 5 km/h) for a duration exceeding a configurable threshold (e.g., 3, 5, or 10 minutes)

+ The thresholds are configurable per client and are applied uniformly to calculations (UI,
(replay, export)

ÿ Rules for calculating indicators

+ Distances
ÿ Distances are calculated from successive GPS points using a consistent method (Haversine or
equivalent)
ÿ The total distance is the sum of the valid inter-point distances.
ÿ Outlier GPS points (unrealistic jumps) can be ignored or corrected according to a defined rule
(client option).
+ Time
ÿ Driving time: sum of times spent in motion
ÿ Downtime: sum of recognized stops
ÿ Times are always expressed: in hours/minutes with consistency between
summary, timeline and export

ÿ Replay engine rules

+ Time synchronization
ÿ The replay is strictly based on the GPS timestamp.
ÿ At any time, the replay, the position on the map, the displayed data and the
events occur at exactly the same time.
+ Reading and control
Machine Translated by Google

ÿ The motor must support play, pause, fast forward, and rewind.
ÿ The reading speeds (x1, x2, x4, x8, x16) must not change the order or accuracy of the points.

+ Navigation via the timeline

ÿ Manually moving the cursor on the timeline immediately positions the vehicle on the map and
updates the side data.
ÿ The cursor cannot move outside the selected period.

ÿ Timeline management rules

+ Timeline structure. The timeline represents:
ÿ The states (movement / stop)
ÿ Events (geofence, overspeed, mission, etc.)
ÿ Speed peaks
+ Display rules
ÿ The states are displayed as colored segments.
ÿ Events are represented by clickable icons.
ÿ Speed peaks are visible graphically and can be filtered by
threshold.

+ Interaction
• Clicking on an event positions the replay at the corresponding moment and puts it in
highlight the point on the map.

ÿ Rules related to geofences

+ Display
ÿ Geofencing can be shown or hidden via toggles.
ÿ The display of geofence names is independent of the display of the
zones.
+ Geofence events
ÿ Input and output events:
- are time-stamped
- appear in the timeline and the Events tab
ÿ Time spent in a geofence is calculated solely from
validated events (GPS noise cancellation).

ÿ 8. Rules for graphically visualizing speeds

+ Speed curve
ÿ A graphical view allows you to display the instantaneous speed and peaks of
speed
ÿ The graph is synchronized with the timeline and the replay
+ Peaks and overspeeds
ÿ A speed spike is detected if the speed exceeds a defined threshold
ÿ Speeding is visible on the graph, locatable on the map and
listed in the events

ÿ 9. Calendar View Rules

+ Monthly view
ÿ The calendar displays the distances traveled per day. Each day is coloured according to defined
thresholds: low activity, normal activity, high activity, no data.

+ Interaction
ÿ Clicking on a day opens the day's replay and automatically reloads the map, timeline, and statistics
Machine Translated by Google

ÿ Export rules
+ Scope. Exports strictly adhere to the selected vehicle and the period
selected and active filters
+ Export types
ÿ CSV/XLS with the following information: GPS points, routes, stops, events ÿ PDF/
image with map, track and numerical summary

ÿ Rules of overall consistency

+ The displayed figures must be identical across UI, replay, widgets, and exports.
+ A displayed data point must always be explainable by a GPS point and by a
event
+ In the absence of data, no approximate calculation is permitted and a
An explicit message is displayed.

ACCEPTANCE CRITERIA
Data access & scope
ÿ Module Access Test

+ The History & Replay module can be accessed from: the main
ÿ
menu, ÿ a click on
a vehicle from TRACK / LIVE, ÿ a widget (Daily trip,
Daily activity, Distances, Speeds).
+ Upon opening, the vehicle and the period are pre-selected if access comes from a
other module

Vehicle and period selection

ÿ Test by Selecting a Vehicle

+ The user can select a vehicle via a drop-down list.
+ Changing vehicles automatically reloads: ÿ The map, ÿ The side
column, ÿ
The timeline, ÿ The
graphs.

ÿ Test by selecting a period

+ The user chooses:
ÿ One day via calendar, ÿ
“Today”, “Yesterday”, “last 7 days”, ÿ A custom
range.
+ The displayed data corresponds strictly to the selected period.
+ If no data is available, an explicit message is displayed.

Map & historical route

ÿ Test on route display
+ The route is displayed on the map for the selected period.
+ The route is continuous and follows the recorded GPS points.
+ Zooming and panning the map is smooth.
Machine Translated by Google

ÿ Testing display options (buttons)

+ The user can enable/disable the display of: ÿ Geofence areas,
ÿ Geofence names, ÿ Geofence icons,
ÿ Last trip, ÿ Vehicle name, ÿ Vehicle
icon.

Each button acts immediately without reloading the page.

Sidebar – Data & Tabs

ÿ Review the Summary tab + The summary displays
at a minimum: ÿ Total distance, ÿ Driving time,
ÿ Stop time, ÿ Average
speed, ÿ Maximum speed, ÿ Start
and end times, ÿ The
name(s) of the driver(s) , ÿ The
number of alerts per triggered
event

+ The values are consistent with the plot and the timeline.

ÿ Checking the Trips tab + The list of each trip

is displayed with: ÿ Start time, ÿ End time, ÿ Distance , ÿ
Time spent driving and
resting , ÿ Maximum
speed , ÿ Fuel
consumption (GPS calculation or actual calculation if
a sensor is
installed) , ÿ Driver's name if equipment is installed. ÿ Clicking on a trip
zooms the map and positions the timeline on the trip.

selected.

ÿ Checking the Stops tab

+ The list of stops displays the duration of each stop, their location and the name of the geofence if
applicable.
+ Clicking on a stop positions the replay at the corresponding moment.

ÿ Checking the Events tab

+ The events displayed include:
ÿ Geofencing entries/exits, ÿ Overspeeds, ÿ
Mission-related events (if
applicable)
+ The name of the driver(s) will be displayed if applicable.
+ Events can be filtered by type.
+ Clicking on an event synchronizes the map and timeline.

Timeline & replay engine

ÿ Checking the information displayed in the Timeline
+ The timeline represents:
Machine Translated by Google

ÿ States (movement / stop), ÿ Events, ÿ

Speed peaks.

+ The timeline is strictly limited to the selected period.

ÿ Replay mode test

The following controls are available: play, pause, fast forward, and rewind.
back.
+ Speeds x1, x2, x4, x8, x16 are functional.
+ The timeline cursor is synchronized with the map.

ÿ Synchronization + At any
point during the replay, the vehicle's position, the displayed data, and the visible events correspond to
the same GPS timestamp.

Speed and peak graph

ÿ Graphical display
+ The graph displays speed as a function of time.
+ Speed peaks are visually identifiable.

ÿ Overspeeding
+ Speeding violations are: ÿ
Shown on the graph, ÿ Listed with time and
speed, ÿ Locatable on the map.

+ Clicking on an overspeed marker positions the replay at the exact moment.

Calendar view
ÿ Access to the calendar
+ The user can access the calendar view from the main interface.
+ The clickable area for the calendar is clearly visible.

ÿ Calendar content + The calendar

displays: ÿ Daily distances, ÿ A
color code according to the defined
thresholds.
+ Days without data are clearly identified.

ÿ Calendar interaction + One click

on a day: ÿ Automatically
selects the day, ÿ Opens the corresponding replay, ÿ
Updates the map, timeline and summary.

Geofences & Geographic Context ÿ Geofence

Events
+ Geofence entry/exit points are visible: ÿ On the timeline, ÿ In the
Events tab,

ÿ On the map.
Machine Translated by Google

+ The times spent in the zones are consistent with the GPS timestamps.

Exports
ÿ Tabular exports
+ The user can export in CSV/XLS format: ÿ GPS points, ÿ
Routes, ÿ Stops, ÿ Events.

+ The exported data respects the active filters.

ÿ Visual exports + The

user can export in the same document: ÿ A map with outline
(image), ÿ A PDF report with
summary.

Performance & robustness

ÿ Performance
+ Loading a standard day takes less than 2 seconds.
+ The replay is smooth with no interface freezing.

ÿ Robustness
+ In case of incomplete data:
ÿ The interface remains functional,
ÿ An explicit message is displayed.
+ No inconsistent calculations are displayed.

Overall coherence
ÿ Data consistency
+ The displayed values are identical between summary, timeline, graphs, exports and
widgets.
+ All displayed data is justifiable by a GPS point and a time-stamped event.

CONSTRAINTS & DEPENDENCIES

Internal functional dependencies ÿ Dependence on

the TRACK / LIVE module

+ Description: The History & Replay module depends directly on the module
TRACK, which provides the raw GPS data.
+ Addictions
ÿ Continuous reception of GPS positions: latitude, longitude, timestamp,
speed, heading (if available)
ÿ Continuity between last real-time position and first historical position
+ Constraints
ÿ If real-time tracking is unavailable or degraded, the history remains
Viewable but no new data is added ÿ Any inconsistency in
TRACK / LIVE (timestamp, GPS accuracy) directly impacts playback, distances, speeds
and events
Machine Translated by Google

ÿ Dependence on the GEOFENCES sub-module

+ Description: History & Replay uses geofencing to contextualize the
journeys.
+ Addictions
ÿ Access to the geofence database: zones, categories and associated rules ÿ
Access to geofence entry/exit events
+ Constraints
ÿ If a geofence is modified or removed, historical events
associated items must not be altered
ÿ The GPS noise reduction rules defined in GEOFENCES must be
respected identically in the replay
ÿ A discrepancy between the map display and the calculation engine is prohibited

ÿ Dependence on the MISSIONS / TOURS module

+ Description: The History & Replay module allows for retrospective review of
the execution of missions.
+ Addictions
ÿ Access to missions: theoretical routes, milestones, time windows ÿ Access
to mission events: start, end, deviation, delay
+ Constraints
ÿ Modifying or deleting a mission must never alter the recorded history. ÿ
“Planned vs. actual”
comparisons must be based on actual timestamps or routes actually recorded.

ÿ Dependence on WIDGETS +
Description The
widgets use the same aggregated data as the History & Replay module.

+ Addictions
ÿ Shared calculations: distances, activity time, speeds ÿ Cross-
navigation: widget click ÿ opens filtered replay
+ Constraints
ÿ The figures displayed in the widgets and in the replay must be strictly
identical ÿ
No divergent recalculation is allowed between modules

Cross-cutting technical dependencies

ÿ Historical storage & performance
+ Addictions
ÿ Database capable of: storing several million GPS points and
Perform fast temporal queries ÿ Indexing by
object, period (optional), geography
+ Constraints
ÿ Without proper indexing: the timeline becomes unusable and replays take a long time
become impassable
ÿ The module must support long histories (several months / years)

ÿ Time engine
+ Dependencies
ÿ Single source of truth: GPS timestamp ÿ Strict
synchronization: map, timeline, graphs, events
Machine Translated by Google

+ Constraints
ÿ No approximate time adjustments are permitted. ÿ All
interpolation must be documented and configurable.

ÿ Client settings
+ Addictions
ÿ Parameters defined in the platform: stopping thresholds, speed thresholds, codes
color, data retention period
+ Constraints
ÿ The rules must be consistent across all modules and applied retroactively or not,
according to explicit choice.
ÿ A parameter change must not modify the raw data
historical

Alert-related dependencies & IVMS

ÿ Dependence on the ALERTS / IVMS module +
Description : History & Replay allows post-event analysis of alerts.
+ Addictions
+ Access to alerts: Speeding, time anomalies, geofencing events
+ Access to thresholds and rules
+ Constraints
+ A triggered alert must be visible in the timeline, on the map, and in the graphs

Historical alerts should never be deleted or recalculated .

UX & ergonomic constraints

ÿ Inter-module consistency
+ The interactions (toggles, filters, icons) must be consistent with:
ÿ TRACK / LIVE ÿ
GEOFENCES ÿ
MISSIONS
+ User behavior must be identical from one module to another

ÿ Readability & Volume

+ Constraints ÿ
Limited simultaneous display to avoid visual overload and preserve performance ÿ Mandatory
implementation
of filters, conditional masking, and zooms
progressives

Data lifecycle constraints

ÿ Immutability of history
+ Historical GPS data is unmodifiable and cannot be deleted by default
+ Every purge is configurable, traceable and irreversible

ÿ Retention & archiving

+ The shelf life is defined by the customer
+ Archived data remains accessible (in degraded mode) and exportable according to
rights
Machine Translated by Google

SUB-MODULE MISSIONS
GOALS
The Missions sub-module forms the core of the FLEET module for delivery activities and route tracking. It allows users
to organize, optimize, and monitor the daily missions of drivers/couriers in real time.

He must solve the current problems:

+ Non-optimized routes,
+ Lack of alerts during mission stages
+ Exit from corridors difficult to identify
+ Excessive fuel consumption,
+ Waste of time,
+ Lack of reliable ETAs for customers,
+ Manual scheduling is difficult to maintain.
+ Difficulty in identifying available vehicles and drivers closest to a depot to assign them a new mission.

+ Sharing position with the client and analyzing the mission in real time is not straightforward.

The module must allow the definition of missions comprising a starting point, an ending point, and a list of milestones to
visit. Each milestone must be associated with a time window and execution constraints.

We distinguish 2 use cases for this sub-module (therefore 2 distinct sections):

The Missions sub-module forms the core of the FLEET module for delivery activities and route tracking. It allows users
to organize, optimize, and monitor their drivers'/couriers' daily missions in real time.

We distinguish 2 use cases for this sub-module (therefore 2 distinct sections):

A- Route Tracking B - Tour Management

Long-distance missions Delivery route missions ÿ With several

ÿ For a single large delivery ÿ With one or consecutive stops organized into routes.
more assets following the same route (convoy). ÿ
Milestones will be checkpoints
ÿ
1 mission = 1 vehicle
allowing verification of the journey's progress. ÿ Milestones are delivery points
(PDL)

User: long-haul transport company User: a company that delivers products or parcels
via delivery routes
This feature should allow multiple mobile devices to be This feature must transform a raw list of delivery points
associated with a mission, alert the planner at each (PDL) into an optimized route, organized according to
checkpoint to ensure that transit times are respected, availability (vehicles, drivers), feasible within time
and inform the end customer. resources constraints and adapted to the size
of the selected vehicle.
Machine Translated by Google

MISSIONS: Route Tracking Section – Priority P0

FUNCTIONAL SCOPE
ÿ Feature 1 – Creating a mission (starting and ending points)
The system must allow the logistics agent to:
+ Define a starting point and an ending point for the mission
+ Define theoretical departure and arrival time slots
+ Create these points: o
From an existing geofence o By entering
GPS coordinates o By entering an address o
By clicking directly on the map

+ Associate business attributes with the mission (reference, comment, mission

type, priority, etc.)
+ Activate the "smart route" option so that the platform automatically
calculates the optimal route between the start and finish

ÿ Feature 2 – Creating milestones / milestones

The system must allow:
+ The addition of intermediate milestones (optional)
+ Creating stages via: o Existing
geofences o GPS coordinates o An
address o A click on the map

+ The choice:
o Either the order in which the agent completes the
steps o Or an automatic calculation of the order by the platform (smart path)

ÿ Feature 3 – Setting time windows and transit times

For each step, the system must allow:
+ The entry of an expected time window between two steps
+ Automatic calculation of transit time if the field is not filled in
+ The route map displays bubbles indicating: ÿ Transit
time between stops ÿ Total time
since departure
+ The agent has the following
options: ÿ To accept the proposed
calculation ÿ To manually modify a step ÿ
To rerun an optimized calculation
Machine Translated by Google

Until this step is validated, the mission remains in “Creation” status.

System learning
The platform will eventually need to be able to optimize routes and transit times based on past
journeys, actual routes taken, and actual speeds per asset.

ÿ Feature 4 – Assigning mobile devices to a mission

The system must allow:
+ The selection of mobile devices available for a mission
+ Automatic exclusion of: ÿ
mobile devices that are malfunctioning/
damaged ÿ mobile devices already assigned to another active mission
+ Automatic sorting of mobiles from closest to furthest from the point of
departure
+ Filtering by vehicle type (e.g., tanker, tipper, flatbed, car, motorcycle)

ÿ Feature 5 – Mission start trigger

The system must allow:
+ The mission's status changes from "Creation" to "Active"
+ Two triggering modes: manual (agent action) or automatic (when
(the first mobile exits the starting geofence)

ÿ Feature 6 – MISSIONS module settings

The module must offer global parameters:
+ Mission trigger mode (Manual or automatic)
+ Transit time calculation method (Manual or automatic)
+ Frequency of transit time updates at each new GPS position (15 to
(60 seconds)
+ Visual customization: ÿ Route color
ÿ Transit time bubble color
Machine Translated by Google

ÿ Feature 7 – Management of mobile devices assigned to missions

The system must allow:
+ Visualization of the list of mobile devices assigned to each mission
+ Modifying or deleting a mobile device is only possible if the mission is in status
"Creation"
+ A blocking message will be displayed if the mission is already active.
+ Export the list to PDF, Excel, PowerPoint, Word format

ÿ Feature 8 – Mission Management and Tracking

The system must allow:
+ Displaying the list of missions
+ Status management: Created - Active - In progress - Completed - Cancelled
+ Data modification: only if the mission is in “Creation” status
+ Export of mission listings (PDF, Excel, PowerPoint, Word)

ÿ Feature 9 – Location sharing (external tracking)

The system must allow:
+ Sharing location and transit times via a secure link
+ Link settings: validity period, visible mobile devices, recipients (addresses)
e-mail)
+ Access to the link without a user account
Machine Translated by Google

ÿ Feature 10 – Real-time tracking & Dashboard gateway

When the mission is triggered:
+ The platform compares in real time: the actual location and the transit time
theoretical
+ Map visualization: ÿ Route traveled
and route remaining ÿ Mobile devices with color coding: on time
- delayed - acceptable - critically delayed

+ Summary: ÿ
First moving average ETA ÿ
Last moving average ETA
+ Zoom on a mobile device: ÿ
Its location ÿ Its
actual route (route departure detection) ÿ Its remaining distance ÿ
ETA ÿ Traffic violations

+ Report generation: ÿ An overall

mission summary ÿ A summary per mission
ÿ A detailed report per mobile device
(PDF / XLSX)
Machine Translated by Google

DETAILED USE CASES

ÿ Complete creation of a mission
+ Actor : Logistics Agent
+ Actions
ÿ The agent accesses the MISSIONS sub-module > route section.
ÿ
He creates a new mission.
ÿ
It defines the starting point and the ending point:
- from a geofence,
- or by entering address/contact details,
- or by clicking on the map.
ÿ
It provides information on the theoretical departure and arrival time slots.
ÿ
He adds intermediate milestones if necessary.
ÿ
He chooses:
- either the manual order of the steps,
- or the smart path option.
ÿ
He validates the mission data.
+ Expected result
ÿ The mission was successfully created.
ÿ The route and transit times are displayed on the map.
ÿ The mission is registered with the status “Creation”.
Machine Translated by Google

ÿ Assignment of mobile devices to a route tracking mission

+ Actor : Logistics Agent
+ Actions
ÿ The agent opens a mission in Creation status.
ÿ
He consults the list of available mobile phones.
ÿ The system automatically filters between operational and unaffected mobile devices
to another mission.
ÿ
It can filter mobiles by vehicle type.
ÿ
He selects one or more mobile phones to assign.
Machine Translated by Google

ÿ
He approves the assignment.
+ Expected result
ÿ The selected mobile devices are assigned to the mission. ÿ The list
of assigned mobile devices is updated. ÿ The mission
remains in "Creation" status until it is triggered.

ÿ Manual or automatic triggering of a route tracking mission

+ Actor : Logistics Agent + Actions
ÿ Manual
Mode 1. The agent
checks the mission parameters.
2. He clicks on Start Mission. ÿ Automatic
Mode 1. The agent activates
automatic trigger mode.
2. The system monitors the starting geofence.
3. The first mobile leaves the starting zone.
+ Expected result
ÿ The mission changes from Creation to Active status. ÿ Real-
time tracking starts automatically. ÿ Transit times begin to be
continuously recalculated.
Machine Translated by Google

ÿ Real-time tracking of an ongoing mission

+ Actor : Logistics Agent
+ Actions
ÿ The agent opens an ongoing mission.
ÿ He views the following on the map:

- The planned route, - The

route taken, - The real-time
position of the mobiles.
ÿ The system applies a color code: ÿ Mobile on time,
ÿ Mobile acceptably late,
ÿ Mobile critically late. ÿ The officer clicks
on a mobile to obtain the details: ÿ
Current position, ÿ Distance remaining, ÿ ETA, ÿ Detected violations.

+ Expected result
ÿ The agent has a clear view of the mission's progress. ÿ Delays and anomalies are
immediately identifiable. ÿ Data is updated in real time.

ÿ Sharing position with an end customer

+ Actor : Logistics agent, End customer (link reader)
+ Actions
ÿ The agent generates a secure sharing link from the mission.
ÿ
He chooses:
ÿ The validity period of the link, ÿ The
visible mobile(s).
ÿ
It captures the recipients' email addresses. ÿ The system
sends the link. ÿ The client opens the
link without authentication.
+ Expected result ÿ The
end customer views: ÿ The mobile's
location, ÿ The route, ÿ Transit
times and ETA. ÿ
Access is limited to the defined period. ÿ
The data is read-only.

ÿ Modification or cancellation of a mission

+ Actor : Logistics Agent
+ Actions
ÿ The agent opens an existing mission. ÿ If the
mission is in Creation status : ÿ They can modify
the steps, schedule, or mobile units, ÿ Or cancel the mission. ÿ If
the mission is Active or In
Progress : ÿ The system blocks structural
modifications, ÿ An explicit message is displayed.

+ Expected result
Machine Translated by Google

ÿ The changes are only taken into account if the mission has not
Started. ÿ
Operational consistency is guaranteed. ÿ Actions are
tracked.

ÿ Mission closure and reporting + Actor : System

logistics agent + Actions ÿ The last mobile
reaches the
destination. ÿ The system automatically closes the mission,
or the agent closes it manually. ÿ The mission status changes to Completed. ÿ The agent generates
the reports: ÿ Mission summary, ÿ Report per mobile,
ÿ PDF/XLSX export. ÿ The data is
archived.

+ Expected result
ÿ The mission is closed and its history is recorded.
ÿ The reports are available for analysis. ÿ The data can be
used in the History & Replay module.

ÿ Post-mission analysis + Actor :

Logistics agent / Supervisor + Actions ÿ The user
opens a
completed mission.
ÿ
He accesses the replay of the journey.
ÿ
It compares planned vs actual route and theoretical vs actual transit times.
ÿ
He analyzes delays and infractions.
+ Expected result ÿ The
user understands the performance gaps. ÿ The data is used for
continuous improvement. ÿ The lessons learned can be used to
optimize future tasks.

TECHNICAL REQUIREMENTS
The Routes section of the MISSIONS sub-module relies on the use of geographic, temporal and vehicle data,
integrated into a routing engine and interconnected with the tracking, geofencing, history and alert
modules to ensure consistent route planning and monitoring.

ÿ Required data

Geographic data (route structure)

This data is essential for constructing and displaying a route.
+ Unique mission identifier + Client identifier
+ Departure / Stage /
Arrival + GPS latitude coordinates
+ GPS longitude coordinates + Order
of passage (if required)

+ Geofencing reference (if applicable)

+ Text address (optional)
Machine Translated by Google

Time-based data (planning)

+ Scheduled departure time
+ Estimated arrival time
+ Beach allowed per stage
+ Transit time between two points
+ Cumulative time since the start

Constraints +
Time data is expressed in UTC.
Any modification to this data triggers a recalculation if the mission is in status
Creation

Vehicle data: This data

directly influences route calculation.
+ Vehicle assigned +
Vehicle type (Motorcycle, Car, Truck, Tanker, etc.)
+ Estimated average speed (Configurable by type)
+ Vehicle constraints: Height, tonnage, restrictions (optional)

Calculation & parameter data: Data required

by the route engine.
+ Calculation mode: automatic (smart path) vs manual
+ Customer thresholds: delay tolerance, automatic recalculation enabled or not
+ Display styles: route color, transit bubble color

Historical data retained

for post-mission analysis.
+ Theoretical route geometry + Theoretical
transit times per segment + Route version (if recalculated)

This data must never be modified after the mission has been activated.

ÿ Required integrations: Integration

with the mapping engine + Objective: visualization
and interaction.
+ Display: ÿ
Theoretical route ÿ Numbered
stages ÿ Transit time bubbles
+ Interaction: ÿ Clicking on a
point zooms in on
the map ÿ Drag and drop stages (if allowed)

+ Synchronization with UI controls (toggles)

Integration with the routing engine + Objective:

calculation and optimization.
+ Path calculation:
ÿ Start ÿ finish ÿ With or
without stages
+ Automatic sequencing of steps
+ Recalculation on:
Machine Translated by Google

ÿ Stage change ÿ Vehicle

change ÿ Parameter change

The engine must be called via an abstract (replaceable) API.

Integration with TRACK / LIVE

+ Objective: operational monitoring.
+ Overlay: ÿ Theoretical
route ÿ Actual route + Real-
time calculation:
ÿ Remaining distance ÿ ETA +
Detection: ÿ Route deviation
ÿ Delay
vs. scheduled
transit

Integration with GEOFENCES +

Objective: geographical structuring.
+ Selection of geofences such as: ÿ Starting
points ÿ Waypoints ÿ
Destination points +
Event detection: ÿ Route
entry/exit + Application of IVMS rules
(sensitive areas)

Integration with History & Replay

+ Objective: continuity of life cycle.
+ Preservation of the theoretical route after the mission + Comparison:
ÿ Planned route ÿ Actual
route + Synchronized
display in replay

Integration with ALERTS / IVMS

+ Objective: control & security.
+ Alert triggers: ÿ Excessive delay ÿ
Route deviation ÿ
Speeding on segment +
Alert ÿ route segment correlation

Integration with DASHBOARDS & REPORTING + Objective:

decision-making exploitation.
+ KPIs per route:
ÿ Respect for deadlines ÿ
Distance discrepancies ÿ
Unplanned downtime
+ Power supply: ÿ
Dashboards ÿ PDF/XLS
reports
Machine Translated by Google

USER INTERFACE
The user interface of the Routes section of the MISSIONS sub-module is based on a central map visualization,
associated with a side column structured in tabs and a theoretical timeline, guaranteeing ergonomic continuity between
the planning, monitoring and analysis of missions.

ÿ User interface objectives

The Routes section interface should allow the logistics agent to:
+ Visually construct a mission itinerary
+ Immediately understand the planned route, stages, and transit times
+ Modify and optimize the route before execution
+ Ensure ergonomic continuity with real-time tracking and the History module
& Replay

The interface should primarily be map-based , intuitive for non-technical users, and consistent with the other
modules of the platform.

ÿ Access to the Routes section

+ The Routes section is accessible:
ÿ When creating a mission ÿ When viewing a
mission in Creation status ÿ In read-only mode for an Active or Completed
mission
Any attempt to modify a non-modifiable mission must:
ÿ Be blocked ÿ
Display an explicit message

ÿ General screen structure

The Routes screen is structured according to a standard common to History & Replay

ÿ Top bar – Mission context

+ The top bar displays: ÿ Mission name
ÿ Mission status: Creating -
Active - Completed ÿ Action buttons: Save – Cancel - Recalculate
route (optional)
+ This bar allows the user to immediately understand the context
Machine Translated by Google

ÿ Sidebar – Route settings The sidebar is organized

into tabs, identical to those shown in your visuals.

"Main" tab
Contains the essential fields for defining the route:
+ Logistics agent name
+ Mission Name
+ Starting point: search - geofence selection - map click
+ Destination point (same selection methods)
+ Time slots: theoretical departure / estimated arrival
+ " Smart Path" activation button
+ Buttons: Save, Cancel

Any change takes immediate effect on the map.

"Attributes" tab
+ Allows entry of business information: ÿ File number /
reference ÿ Customer name ÿ Cargo ÿ
Customizable free
fields

+ This tab is: ÿ

Editable only in Creation status
ÿ Available in read-only mode afterwards

"Steps" tab. Central tab for route planning.

+ Contents:
ÿ List of steps: Step 1, Step 2, … ÿ For each step:
geographic location and estimated transit time ÿ Buttons: add a step and delete a
step ÿ Option: Optimized sequencing of steps + Associated map: ÿ
Display: ÿ Theoretical route ÿ Numbered steps ÿ Transit time
bubbles ÿ Any change in
the list triggers a
map update

"Assignments" tab
Displays the mobile units that can be assigned to the mission:
+ Table with columns: ÿ Name ÿ
Vehicle
type ÿ Current position ÿ
Status (available,
dispatched, broken down)
+ Filters by vehicle type, by condition
+ Selection of one or more mobile phones
Card interaction:
+ Click on a mobile device ÿ map zoom + estimated distance / ETA to departure

"Settings" tab
Allows you to configure the route behavior:
Machine Translated by Google

+ Automatic and manual transit time calculation modes

+ Colors: route, transit bubbles
These settings must be: ÿ Consistent with
History & Replay ÿ Applicable by default to future
missions

ÿ Central map – Route visualization

The map is the main element of the screen.

It displays: +
The complete theoretical route + Numbered
stages + Direction of travel +
Transit time bubbles

Map buttons (to the right of the map)

The following buttons must be available, identical to those in the History module:
+ Show/hide geofences
+ Show/hide geofence names
+ Show/hide route
+ Show/hide vehicle name
+ Show/hide vehicle icon

ÿ Theoretical timeline (bottom of screen)

A horizontal timeline displays: ÿ The start ÿ
Intermediate
stages ÿ The finish ÿ Cumulative times

This timeline is synchronized with the map. It foreshadows the actual timeline of the sub-map.
History & Replay module

ÿ Interface states according to mission status

Mission status UI behavior

Creation All editable fields
Active Read only (fixed itinerary)
Completed Read only + access to replay

ÿ Non-negotiable UX principles
+ Map always visible
No critical action without confirmation
+ Systematic user feedback: ÿ Recalculation in
progress ÿ Error ÿ Success

+ Full consistency with: ÿ TRACK

ÿ History &
Replay ÿ GEOFENCES
Machine Translated by Google
Machine Translated by Google

MANAGEMENT RULES
The Routes section of the MISSIONS sub-module is based on strict management rules governing the mission
lifecycle, route construction and calculation, transit time management, and consistency with real-time tracking and
historical data.

ÿ General rules of scope Client affiliation + A

mission and its route
belong to a single client.
+ The data (route, steps, parameters) is strictly isolated per client (multi-
(holder).

Mission Uniqueness
Each mission has a unique, unchanging identifier.
+ Route changes should never create a new mission, but a new internal version of the route if necessary.

ÿ Mission lifecycle rules

Authorized statuses
A mission can only have the following statuses:
+ Created +
Active +
Completed +
Cancelled No
other status is allowed.

Mission status: Creation

As long as the mission is in Creation status :
+ The route is fully customizable
+ The steps can be added, deleted, or reordered
Route settings can be changed .
+ Mobile phones can be assigned or removed

Mission status: Active

As soon as the mission changes to Active status :
+ The route is fixed
Any structural modification is prohibited: start, finish, stages, order of stages
+ Display settings can remain editable (colors, visibility)
An explicit message is displayed if an attempt is made to modify the prohibited area.

Mission Completed or Cancelled

The mission is now strictly read-only.
+ The route is kept for analysis, replay, and reporting purposes

ÿ Route creation rules

Mandatory points
A valid itinerary must include:
+ A starting point
+ A final destination + 0 to
N intermediate steps
Without these elements, the mission cannot be registered.
Machine Translated by Google

Sources of the points

Route points can originate from:
+ From an existing geofence
+ From an entered address
+ GPS coordinates
+ With a click on the map
All points must be converted into valid GPS coordinates.

ÿ Route calculation rules

Calculation method
Two exclusive modes are possible:
+ Automatic (smart path)
+ Manual The
chosen mode applies to the entire mission.

Automatic calculation
The system calculates: ÿ The
optimal order of steps ÿ Transit times
ÿ The ETA per step

+ The calculation is triggered: Upon

o creation, and at
o each structural modification.
+ The agent can: o
Accept the calculation o
Request a recalculation

Manual calculation

+ The agent imposes: ÿ

The order of the steps ÿ
The transit times
The system never changes these values automatically.
Manual values take precedence over any automatic recalculation

ÿ Rules related to transit times

Default transit time
If no transit time is entered, the system automatically calculates an estimated time based on distance, vehicle
type, and customer parameters.

Temporal coherence
+ The cumulative times must be strictly increasing
An inconsistency (arrival time < departure time) is prohibited
Any inconsistency will block the recording.

Vehicle Sorting: During

assignment, vehicles are automatically sorted from closest to furthest from the starting point. The distance is
calculated from the last GPS position.
known

ÿ Route tracking and control rules

Adherence to the route
+ During execution, the actual position is compared to the theoretical route.
+ A route deviation is detected if the deviation exceeds a configurable threshold
Machine Translated by Google

Delay and ETA

+ The ETA is recalculated in real time
+ The delay is assessed in relation to theoretical transit times
+ The delay thresholds are configurable: acceptable / critical

ÿ Integration rules with History & Replay

Preservation of the theoretical route
+ The theoretical route is retained even after the mission
+ It serves as a reference for comparison between planned and actual data and for post-mission analysis

Comparison between planned and actual

+ The differences are calculated based on distances, time, and stage passages
+ The data can be used in History & Replay

ACCEPTANCE CRITERIA
Access & perimeter
ÿ Access to the Routes section +
The user can access the Routes section from within a mission.
+ Access is only permitted for missions belonging to his client.
+ User rights are respected (edit / read only).

Route creation
ÿ Mandatory points
+ It is impossible to record a mission without a starting point and a point
arrival
+ An explicit message is displayed if a point is missing.

ÿ Sources of the points

A point can be defined: ÿ Via an
existing geofence ÿ By entering an
address ÿ By GPS coordinates
ÿ By clicking on the map

+ All points are converted into valid GPS coordinates.

Route calculation
ÿ Automatic calculation (smart path)
+ When smart path mode is activated, the order of steps is calculated
automatically and transit times are generated.
+ The route is displayed on the map after calculation.
+ Transit time bubbles are visible.

ÿ Manual calculation
+ When manual mode is selected: ÿ The order
of steps is respected ÿ Manually
entered transit times are not modified by the system
+ No automatic recalculation is triggered without user action.
Machine Translated by Google

ÿ Route recalculation
+ Any structural change (adding/deleting a step) triggers a recalculation if
The mission is in the Creation status.
+ No recalculation is allowed if the mission is Active or Completed.

Step management
ÿ Adding/ removing steps
The user can add or remove steps as long as the mission is in progress .
Creation.
+ The order of steps is updated immediately.
+ The map instantly reflects the changes.

ÿ Optimized scheduling
+ The Optimized Step Scheduling option :
ÿ Changes the order of the steps ÿ
Updates the route ÿ
Updates the cumulative times
+ The user can accept or refuse the optimization

Temporal data & consistency

ÿ Time consistency + Cumulative
times are strictly increasing.
+ A temporal inconsistency is blocking the recording.
+ An explicit error message is displayed.

Vehicle allocation (route impact)

ÿ Vehicle compatibility +
Only compatible vehicles (type, condition) can be affected.
+ The type of vehicle influences route calculation and transit times

ÿ Automatic ranking + Vehicles are

ranked by increasing distance from the starting point.
+ The distance is calculated from the last known GPS position.

Map & display

ÿ Map display
+ The map displays: ÿ
The theoretical route ÿ
Numbered stages ÿ Transit time
bubbles
+ Updates are visible without page reloading.

ÿ Map buttons + The following buttons

are functional: ÿ Show/hide route ÿ Show/hide geofences
ÿ Show/hide geofence names ÿ Show/
hide vehicle name ÿ Show/hide vehicle
icon + Each action has an immediate effect on the map.
Machine Translated by Google

Theoretical timeline
ÿ Displaying the timeline + A
theoretical timeline is displayed at the bottom of the screen.
+ It represents the start, the stages, the finish, the cumulative times + It is synchronized
with the map.

Mission lifecycle
ÿ Mission in Creation status + The route
is fully editable.
+ All fields are editable.

ÿ Active Mission + The

route is fixed.
+ Any attempt to modify the modification is blocked with an explicit message.

ÿ Mission Completed
+ The route is viewable in read-only mode.
+ It is accessible from History & Replay for analysis.

Integration with History & Replay

ÿ Route preservation + The theoretical
route is preserved after the mission.
+ It is compared to the actual route in the replay.

ÿ Planned/ actual comparison + Distance

and time differences are visible.
+ The data is consistent between:
ÿ MISSIONS ÿ
TRACK ÿ
History & Replay

Performance & robustness

ÿ Performance
+ Calculating a standard route takes less than 2 seconds.
+ The interface remains fluid during recalculations.

ÿ Robustness
+ In case of calculation error: ÿ The
previous route is retained ÿ An explicit message
is displayed + No inconsistent data is recorded.

Overall validation criteria

The MISSIONS – Routes sub-module is considered compliant when all the above acceptance criteria are met,
ensuring reliable planning, consistent monitoring, and functional continuity with real-time tracking and historical data.
Machine Translated by Google

CONSTRAINTS and DEPENDENCIES

The Routes section of the MISSIONS sub-module depends on the map engine, a routing
engine, the vehicle database, and cross-functional modules (TRACK, GEOFENCES, ALERTS,
History & Replay). It imposes strict constraints regarding immutability after activation, inter-
module consistency, performance, and management of degraded modes in case of external
service unavailability.

Internal dependencies (other modules of the platform)

ÿ Dependence on the GEOFENCES module

Why: routes can use geofences as starting/finishing/stage points.

+ Addictions
ÿ Access to the geofence database (list, details, categories, groups)
ÿ Geofence conversion ÿ coordinates usable by the route engine
+ Constraints
ÿ If a geofence used in a route is removed or modified:
- The route must not "break"
- The system must keep a copy of the coordinates at the time of creation
(snapshot)
ÿ The display of geofences on the map depends on the map engine
common

ÿ Dependence on the TRACK / LIVE module

Why: allocation and operational tracking are based on the latest vehicle positions.

+ Addictions
ÿ Last known GPS position of the mobile device (latitude, longitude, timestamp)
ÿ Availability status (available, assigned, out of service…) if managed on the tracking side
+ Constraints
ÿ If TRACK is not available:
- The "nearest mobile" ranking becomes impossible
- The system must switch to degraded mode (unsorted list + message)
ÿ GPS accuracy strongly influences the relevance of the “nearest” and the
ETA

ÿ Dependence on the ALERTS / IVMS module

Why: route deviation, delay, speeding on segments, etc.

+ Addictions
ÿ Event/alert engine capable of processing:
- The deviation threshold from the route
- The delay threshold
- The speed threshold
+ Constraints. If the alert engine does not exist or is minimal:
ÿ The Routes section remains a planner but loses its “control” function
ÿ The rules must be consistent with those of History & Replay (same
thresholds)
Machine Translated by Google

ÿ Dependence on the History & Replay module

Why: comparison of “planned vs actual” after the mission.

+ Addictions
ÿ Preservation of the theoretical route (geometry + transit time) ÿ Access to historical
actual journeys
+ Constraints ÿ The
theoretical route must be fixed when switching to “Active” ÿ If the GPS history
is incomplete:
- The comparison between expected and actual results is degraded
- The system must display a data quality indicator

ÿ Dependence on Widgets and Reporting

Why: the calculated indicators (ETA, delays, planned distances) must be reusable.

+ Addictions
ÿ Access to mission/route aggregates and metrics
+ Constraints ÿ
Prohibition of divergent calculations between: ÿ Routes Screen

ÿ Widgets
ÿ PDF/XLS Reports

Technical dependencies (cross-cutting components)

ÿ Dependence on the map engine

Why: map interaction (click, adding points), display of the route, transit time bubbles.

+ Addictions
ÿ Map library supporting: ÿ polylines (path) ÿ
markers (steps) ÿ layers
(geofences) ÿ custom
controls (buttons on the right)

+ Constraints
ÿ
The map must remain fluid even with: ÿ multiple
steps ÿ visible geofences
ÿ visible objects (if displayed)
ÿ obligation to standardize map
interactions for all modules

ÿ Routing engine dependency / optimization

Why: path calculation + transit times + optimized scheduling.

+ Dependencies ÿ
Routing API capable of: ÿ originÿarrival
route
Machine Translated by Google

- Multi-step -
Step order optimization (optional)
+ Constraints ÿ
Availability and latency of the routing service directly impact UX ÿ The system must manage: ÿ
timeouts

ÿ errors

- Quotas (if third-party

service) - Degraded mode (manual entry of transit times)

ÿ Dependence on geocoding (address ÿ coordinates)

Why: address entry for departure/arrival/stages.

+ Constraints ÿ
Variable geographical coverage depending on the country (important in Africa) ÿ Quotas /
potential costs ÿ Need for caching
of frequent results (deposits, recurring customers)

ÿ Dependence on the vehicle reference system

Why: Vehicle type impacts route and time

+ Addictions
ÿ Catalogue of vehicle types (motorcycle, passenger car, truck, tanker,
etc.) ÿ Optional attributes (capacity, restrictions)
+ Constraints ÿ If
this data is not normalized, the route engine cannot
adjust your calculations

Data lifecycle and consistency constraints ÿ Immutability after activation

• From the Active status onwards, the
theoretical path is fixed. • Any structural modification is
prohibited and will be audited (including attempted modifications).
ÿ Snapshot of sensitive data • To avoid
side effects (modified geofence, renamed address):
o The coordinates and labels must be saved “as-is” in the route
at the time of validation.
ÿ Version management (recommended option) • If
multiple recalculations are required before activation:
o keep an active version + previous versions (audit & traceability).

UX & performance constraints

ÿ Step volume management
+ The system must support at least 20–50 steps per mission (target value to be defined)
Furthermore , the UI must remain usable via:
ÿ Pagination in the step list ÿ Smart
grouping/zoom

ÿ Non-blocking recalculation
+ A recalculation should never "freeze" the screen:
Machine Translated by Google

ÿ Loader ÿ
“Calculating” message ÿ Saves the
last valid route if unsuccessful

ÿ Inter-module UI consistency
+ The map buttons on the right (geofences, names, route, vehicle name, icon) must
be: ÿ
Identical in MISSIONS and in History & Replay ÿ In the same location ÿ With
the same icons and statuses

Security constraints & audit

+ Strict multi-tenant isolation
+ RBAC applied to actions: ÿ Create/
modify route ÿ Recalculate ÿ
Validate ÿ Activate
mission

+ Mandatory logging of key actions: ÿ Adding/deleting steps

ÿ Optimization ÿ Switching between
automatic and
manual modes ÿ Mission validation

Project risks (to anticipate)

+ Latency or routing/geocoding cost ÿ plan for caching + manual mode
+ GPS TRACK quality ÿ impacts on “closer” and tracking
+ Geofence removal/modification ÿ snapshot required
+ Duplicate calculations (Mission vs Replay vs Widgets) ÿ backend source of truth
unique
+ UI overload if too many objects/layers are displayed ÿ filters/toggles required

MISSIONS: Touring section – Priority P1

GOALS
The Delivery Routes section relies on a daily scheduling process, allowing the logistics agent to:
Machine Translated by Google

+ Prepare the load to be delivered

(packages), + Qualify the available resources (vehicles, drivers), +
Let the system automatically generate optimized routes, + Adjust and validate
the routes before execution.

FUNCTIONAL SCOPE
The scheduling of delivery routes is based on a daily logic oriented towards resources and actual
workload, in which the route is not created manually but generated automatically by the system
from available packages, vehicles and drivers, then validated by the logistics agent.

This sub-module must integrate seamlessly with the Track / live sub-module and the overall mapping
of the platform.

Parcel registration (load preparation) ÿ Functionality –

Parcel management (unchanged, but repositioned)

Each morning (or earlier), the logistics agent: + Registers all

packages to be delivered that day + Or imports packages from a third-party
file/system. Each package includes: + A reference number + A delivery
address + A geographical area
+ A weight, volume +
A type (small, large, fragile…)

+ Specific constraints (time, signature, priority)

The delivery address of each package is converted into a geofence.

Key rule:
An unregistered parcel can never be taken into account in route optimization.

Qualification of available resources

ÿ Vehicle availability

Each vehicle is characterized by: + A

type (motorcycle, car, truck)
+ Weight/volume capacity + Authorized
traffic zone + Operational status (Breakdown,
Maintenance, Available…)

Before scheduling, the logistics agent:

+ View the list of vehicles
+ Automatically or manually excludes: ÿ Vehicles that are
broken down ÿ Vehicles undergoing
maintenance ÿ Unavailable vehicles

ÿ Availability of drivers / couriers

Each driver has a status:
+ Available
+ Unavailable
Machine Translated by Google

+ Already assigned
The logistics agent: +
Consults the list of drivers + Excludes those
who are absent, on leave, sick, or have left the workforce…

Key rule: A
tour can only be generated if a vehicle-driver pairing is possible.

Setting up the day's tour schedule

Before launching the optimization, the agent defines:
+ The start time of the delivery day
+ The end time of the day (corresponding to the couriers' working hours)
+ The common starting point (e.g., depot) + Possibly
the return point

These parameters serve as the overall time frame for the optimization engine.

Automatic route generation (core module)

ÿ Key Feature – Automatic Scheduling

Based on:
+ Packages to be delivered,
+ Vehicles available,
+ Drivers available,
+ Due to time constraints, the
system automatically generates:
+ One or more optimized routes
+ Each delivery route includes: ÿ A route
ÿ A list of parcels ÿ
A vehicle ÿ A driver ÿ
Estimated times
(departure, end,
return to depot)
Optimization criteria include:
+ Minimizing distances
+ Respect for capabilities
+ Punctuality
+ The geographical coherence of the areas

Validation and adjustment of routes by the logistics agent ÿ Route

adjustment
After automatic generation, the agent can:
+ View each tour on the map
+ View: ÿ Assigned
packages ÿ Assigned
vehicle ÿ Designated driver
ÿ Estimated times

+ Manually modify a delivery route (if necessary) to: ÿ Move a package to

another route ÿ Change a vehicle or driver ÿ Adjust the
order of delivery steps
Machine Translated by Google

ÿ Final validation
During validation, the agent:
+ Give the tour a name
+ Confirms the tour

The tour status changes to Planned / Ready

Execution, monitoring and closure (unchanged)

Once validated:
+ The tours are followed in TRACK / LIVE
+ ETAs are recalculated in real time
+ The routes are closed automatically or manually
+ The data is stored historically (replay, reporting)

DETAILED USE CASES

The use cases in the Delivery Routes section rely on a daily scheduling process in which routes are automatically
generated from available packages and resources, then validated and tracked by the logistics agent.

ÿ Daily preparation of packages for delivery

Actor : Logistics Agent

Actions
+ At the beginning of the day (or beforehand), the agent accesses the Parcel section.
+ It records or imports all the packages to be delivered.
+ For each package, it provides: ÿ The
reference, ÿ The
delivery address, ÿ The
geographical area, ÿ The weight,
volume, ÿ The type of
package, ÿ The specific
constraints (time, signature, priority).
He approves the list of packages for the day.

Expected result + All

packages of the day are registered in the system.
+ The packages are available for route scheduling.
+ No unregistered parcels will be accepted.

ÿ Qualification of available vehicles Actor: Logistics agent

Actions + The agent accesses
the list of
vehicles.
+ He checks their operational status.
+ It excludes from planning: ÿ Vehicles
that are broken down, ÿ Under
maintenance, ÿ Unavailable.

+ He approves the list of vehicles available for use that day. Expected result
Machine Translated by Google

+ The list of available vehicles is up to date.

+ Only compatible vehicles will be offered when generating routes

ÿ Assigning parcels to a route Actor : Logistics agent

Actions + The agent accesses

the list of
drivers.
+ He checks their status:
ÿ Present, ÿ
Absent, ÿ On
leave, ÿ
Unavailable.
+ It excludes unavailable drivers.
+ He approves the list of available drivers for the day.
Expected result +
The list of available drivers is up to date.
No unavailable driver will be assigned to a route.

ÿ Setting up the delivery day Actor : Logistics agent Actions

+ The agent accesses the route
planning
screen.
+ It provides
information on: ÿ The start time of the day, ÿ
The end time of the day (working hours), ÿ The common starting
point (depot), ÿ Possibly the return point.

+ He validates the daily parameters.

Expected result •
The temporal and geographical framework of the planning is defined. • These
parameters will serve as constraints for the scheduling engine.

ÿ Automatic route generation (central case)

Actor +
System +
Logistics Agent (supervision)
Actions
+ The agent initiates the automatic generation of routes.
+ The system analyzes: ÿ
Packages to be delivered,
ÿ Available vehicles, ÿ Available
drivers, ÿ Time constraints.

+ The system generates one or more optimized routes.

+ For each route, the system assigns: ÿ A route, ÿ A list of
parcels, ÿ A vehicle,
ÿ A driver, ÿ Estimated
times (departure,
end, return).

Expected result +
Routes are generated automatically.
+ Capacity, zone and time constraints are respected.
Machine Translated by Google

+ The routes are proposed to the agent in Draft / To be validated status.

ÿ Visualization and analysis of generated routes Actor: Logistics agent

Actions + The agent consults
the list of
generated routes.
+ He selects a tour.
+ It displays: ÿ The
route on the map, ÿ The delivery
stages, ÿ The assigned packages,
ÿ The vehicle-driver pair, ÿ
The estimated times.

+ He compares the tours with each other if necessary.

Expected result +
The agent has a clear and concise view of the proposed routes.
+ Inconsistencies or necessary adjustments are identified.

ÿ Manual adjustment of a generated route

Actor: Logistics Agent
Actions
+ The agent opens a route with the status " To be validated".
+ It can: ÿ
Move a package to another route, ÿ Change the order of
steps, ÿ Change vehicle, ÿ Change
driver.

+ The system automatically recalculates the impact (distance, time).

+ The agent records the adjustments.
Expected result +
The changes are taken into account.
+ The constraints remain respected.
+ The tour can still be modified until it is validated.

ÿ Final validation of a route Actor: Logistics

agent Actions + The agent
validates
a route.
+ He gives the tour a name.
+ The system freezes: ÿ
The packages,
ÿ The route, ÿ The
vehicle, ÿ The driver.

+ The tour changes to Planned / Ready status.

Expected result +
The tour is ready to be executed.
No structural changes are possible without cancellation.

ÿ Real-time tour execution and tracking

Actor
+ Logistics Agent
+ System
Machine Translated by Google

Actions
+ The tour starts automatically or manually.
+ Tracking is provided via TRACK / LIVE: ÿ Courier
position, ÿ Route, ÿ Status of
stages.

+ The statuses of the steps evolve: ÿ To do, ÿ

In progress,
ÿ Delivered, ÿ
Anomaly.

+ The ETAs are continuously recalculated.

Expected result +
The agent monitors the execution of the route in real time.
+ Delays or anomalies are visible immediately.

ÿ Detection of couriers who have become available again Actor +

System
+ Logistics
agent Actions + The
system
detects the end of a route.
+ It identifies the couriers: ÿ Without
an active route, ÿ Close to the
depot.
+ It sorts couriers by: ÿ Availability. ÿ
Distance to the
depot, ÿ Return time, + The agent
can launch a new
generation of routes if necessary.
Expected result +
Resources are reused without downtime.
+ Overall productivity is improved.

ÿ Post-tour closing and analysis

Actor
+ Logistics Agent / Actions Supervisor +
The tour
is closed automatically or manually.
+ The system generates a summary of: ÿ
Actual distance, ÿ Duration, ÿ
Packages delivered,
ÿ Delays.

+ The user has access to: ÿ

Replay, ÿ Exports
(CSV / PDF).
Expected result +
The tour is recorded.
+ The data can be used for management and continuous improvement.
Machine Translated by Google

TECHNICAL REQUIREMENTS
ÿ Required data

Parcel Reference
Minimum data required for each package: + Unique identifier
+ Reference / package
number (unique per customer or per day)
+ Customer name +
Delivery address (text) + GPS coordinates (latitude, longitude)
+ Delivery area (neighborhood/sector/city)
+ Dimensions (L, W, H) and/or volume + Weight
+ Package
type: small / medium / large / fragile / etc.
+ Time window +
Package status: created, assigned, loaded, in transit, delivered, failed, returned

Constraints +
Packages must be recorded (audit): creation / modification / assignment / delivery.
+ Addresses must be geocoded (or entered as coordinates) before
optimization.

Vehicle Reference Data

To enable automatic assignment and compatibility:
+ Vehicle designation on the registration
certificate + Vehicle registration number
+ Vehicle type: motorcycle / car / truck / van …
+ Maximum load weight +
Maximum load volume + Designated
traffic area (e.g., sectors)
+ Status: available, busy, maintenance, outage…
+ Last known position (if Track):

Driver/Courier Reference Guide

+ Driver Code (RFID key)
+ Identity (name/surname)
+ HR Status: active, inactive + Day-
of Availability: + Available,
absent, sick, + Skills / authorizations
(optional): authorized motorcycle / truck, etc.
+ Usual zone (optional): for preferred allocation

Daily scheduling parameters

Data required for automatic route generation:
+ Planning date
+ Start time of day
+ End of day time
+ Depot starting point (address + latitude/longitude)
+ Return point (address + latitude/longitude): optional
+ Planning rules: ÿ Maximum route
duration ÿ Maximum number of
packages per route ÿ Permissible
delay margin
Machine Translated by Google

Subject: “Tour”
Data produced by the system (and necessary for monitoring and history):
+ Tour code + Tour name
(entered upon validation)
+ Tour status: draft, planned, in progress, completed, cancelled + Created by, created at,
validated by, validated at...
+ Driver code, vehicle code + List of assigned
packages (in order)
+ List of stops: ÿ Stop code, zone
code ÿ Coordinates + address ÿ
Estimated ETA ÿ Time window ÿ
Stop status: to do,
in progress, delivered,
exception ÿ Actual timestamps: arrived at, finished at…

+ Theoretical route (map) + estimated distance/time

Real-time tracking and execution data

Required for operational monitoring and dynamic ETA:
+ Real-time courier position (Track): latitude/longitude/time stamp/speed/heading
+ Tour status and progress:
ÿ Completed stops ÿ
Remaining stops ÿ
Estimated return time to depot + Execution
events: ÿ Delay ÿ Delivery anomaly ÿ
Rescheduling

Historical data & reporting

For closing, replay, export:
+ Actual distance, actual duration
+ KPIs: o
Number of parcels delivered / failed o
Delays (per stop and overall)
+ Export: o
Route o
Stops + dwell time o Anomalies
+ reasons

ÿ Required integrations

Mapping Integration Objective:

visualization of routes and interaction.
+ Display: ÿ Drop-
off/Return ÿ Theoretical
Route ÿ Numbered Stops ÿ
Stop Status (Colors/Icons)

+ Filters (consistent with History): ÿ Show/hide

geofences ÿ Show geofence names ÿ
Show vehicle name / vehicle icon

+ Interaction:
Machine Translated by Google

ÿ Clicking on a stop point on the map allows you to view the package details and associated actions

Geocoding/Reverse geocoding integration . Objective:

to convert address ÿ coordinates.
+ Geocoding during: ÿ
Entering a warehouse address ÿ Entering a
delivery address ÿ Importing packages

+ Reverse geocoding (optional): displaying address from a GPS point

Constraints
+ Manage quotas/latency
+ Plan for caches for frequently used addresses (depots, recurring customers)

Optimization/scheduling engine integration . Objective: to

automatically generate routes.
+ Inputs: ÿ
Packages + constraints ÿ
Resources (vehicles, drivers) ÿ Daytime hours

+ Outings: N routes + assignments + order of stops + ETA

+ Required capacities: ÿ
Optimization by distance/time ÿ Consideration
of time windows ÿ Compliance with weight/
volume capacity limits ÿ Grouping by zone

Constraints
+ Abstract API (replaceable)
+ Timeout management + Degraded mode (semi-manual scheduling)

TRACK / LIVE integration

Objective: operational monitoring and courier availability.

+ Consume the last position of the vehicles/couriers

+ Calculate:
ÿ Dynamic ETA per stop ÿ End of
route time ÿ Return to
depot
+ Availability detection: ÿ Route
completed ÿ Distance/time
to depot

GEOFENCES integration
Objective: to contextualize and trigger statuses.
+ Use the "depot" geofence for: ÿ The actual
departure (depot exit) ÿ The actual return
(depot entry)
+ Optionally associate stops with existing geofences + Option: alert if exiting the zone

Historical Integration & Replay

Objective: post-tour analysis.
+ Maintain the theoretical route of the tour + Utilize the actual
route (GPS points) to:
Machine Translated by Google

ÿ A replay ÿ A
comparison between what was planned and what actually happened
+ Present an entry point: ÿ “Watch tour
replay”

Export Integration / Reporting

Objective: to produce operational deliverables.
+ CSV/XLS export: ÿ List of
packages ÿ Stops +
timestamps ÿ Anomalies

+ PDF Export: ÿ Tour

Summary ÿ Route Display on Map

+ Export logging (audit)

Notification integration (optional but highly recommended)

Objective: real-time control.
+ Notify the agent in case of: ÿ
Critical delay ÿ Delivery
anomaly ÿ Courier availability
+ Channels: in-app, Email,
WhatsApp

USER INTERFACE
General principles of the interface
The user interface of the Delivery Routes section is designed around a daily scheduling process,
allowing the logistics agent to: + Prepare the load (packages), + Qualify the resources (vehicles &
drivers), + Automatically generate the
routes, + Adjust and validate the routes, + Track their execution in
real time.

The route is not created manually; it is generated by the system and then validated by the user.

General structure of the main screen ÿ

Standard structure (aligned with History & Replay)
Machine Translated by Google

Top bar – Context of the day

The top bar allows you to define the daily frame :

+ Planning date
+ Start time of day
+ End of day time
+ Common starting point (depot)
+ Action buttons:
ÿ Generate routes ÿ Reset ÿ
Save schedule

This bar is mandatory before any automatic generation

Sidebar – Data Orchestration

The sidebar is structured into functional tabs, representing the inputs of the scheduling engine.

ÿ "Packages" tab
Content :
+ Today's package list
+ Status: unassigned / assigned / delivered
+ Filters:
ÿ zone

ÿ type ÿ
priority
+ Actions: ÿ
add / import ÿ
temporary exclusion

The parcels displayed here are the raw material for the delivery routes.

ÿ "Vehicles" tab
Content :
+ List of vehicles
+ Visible information:
ÿ Type ÿ
Capacity ÿ
Status (available / maintenance)
+ Checkbox:
ÿ Include / exclude from planning

ÿ "Drivers" tab
Content :
+ List of drivers
+ Status: ÿ
Available ÿ
Absent ÿ
Unavailable ÿ
Selection of drivers included in the schedule
Machine Translated by Google

An excluded driver cannot receive any deliveries.

ÿ "Generated Routes" tab

Content :
+ List of automatically generated routes
+ For each delivery route: ÿ The
Vehicle ÿ The Driver
ÿ The Number of
Packages ÿ The Estimated
Duration
+ Actions:
ÿ View on map ÿ Adjust ÿ Confirm

ÿ "Settings" tab
Global scheduling parameters:
+ Main criterion: ÿ Minimum
distance ÿ Minimum time

+ Constraints: ÿ
Vehicle capacity ÿ Scheduled
delivery times for the package
+ Delay tolerance
+ Maximum number of packages per delivery

Example illustration for the user interface of touring missions

Central map – Route visualization

The map displays:
+ Several tours simultaneously
Each route includes: o A dedicated
color o Its own itinerary
Machine Translated by Google

o Its numbered stages

+ Vehicle icons + Driver name

Map buttons (on the right)

+ Show/hide tours
+ Show/hide steps
+ Show/hide geofences
+ Show/hide names

Example illustration for the user interface of touring missions

Global Timeline – Time View of the Day

The timeline displays:
+ All the routes on the same day
+ Any potential overlaps
+ Departure/End Times
+ Deposit return times

This timeline is the operational key for the agent.

Example illustration for the user interface of touring missions

Key secondary screens

ÿ Manual adjustment of a tour
+ Moving a package from one delivery route to another
+ Immediate recalculation of impacts
Machine Translated by Google

+ Synchronized map visualization

ÿ Final validation of a tour

+ Enter the tour name
Summary : ÿ Packages
ÿ Vehicle ÿ
Driver ÿ Schedule

+ Confirm Tour Button

MANAGEMENT RULES
The management rules for the Delivery Routes section ensure automated, reliable and consistent daily planning,
from the preparation of packages and resources to operational monitoring and post-route analysis.

General management principles ÿ Scheduling

logic + Routes are not created manually.

+ They are automatically generated by the system from:

ÿ registered parcels, ÿ available
vehicles, ÿ available drivers, ÿ daily
parameters.

+ Every tour must be the result of a generation process.

ÿ Planning day + Tours are planned by

day.
+ Each day is defined by: ÿ a date, ÿ a start
time, ÿ an end
time.

+ The day's schedule corresponds to the drivers' working hours.

Parcel handling rules

ÿ Package
prerequisites + A package must be registered and geocoded to be taken into account.
+ A package that is not geolocated is excluded from the scheduling.
+ A parcel can only be assigned to one delivery route at a time.

ÿ Package constraints
+ The weight and volume of the package are mandatory if the vehicle capacity is activated.
+ The delivery time constraints for the package must be respected. If the delivery time cannot be met, the
package will not be assigned to the route and the logistics agent will be informed.

+ A package manually excluded by the agent cannot be automatically assigned.

ÿ Life cycle of a package

The possible statuses for a coli are:
Machine Translated by Google

+ unaffected +
affected + in
transit + delivered
+ faulty +
returned

The parcel status changes automatically as the delivery route progresses.

Vehicle management rules

ÿ Vehicle Availability • Only vehicles
with the status " available" are taken into account. • A vehicle in:

ÿ failure, ÿ
maintenance, ÿ
unavailable is
automatically excluded from scheduling.

ÿ Vehicle compatibility
+ A vehicle can only be assigned to a route if: ÿ its weight capacity ÿ sum
of the package weights, ÿ its volume capacity ÿ sum of the
volumes, the delivery area is authorized.
ÿ

+ A vehicle can only be assigned to one route at a time.

Driver management rules

ÿ Driver availability
+ Only drivers with the status " available" are taken into account.
+ Drivers who are: o
absent, o on
leave, o inactive
are
automatically excluded.

ÿ Driver assignment
+ A route must be assigned to a single driver.
+ A driver can only complete one route at a time.
+ A driver can only be assigned to a new route after the closure of
the previous one.

Rules for automatic route generation

ÿ Generation Trigger
+ Automatic generation can only be started if: ÿ at least one package is
available, ÿ at least one vehicle is available, ÿ
at least one driver is available, ÿ the daily
parameters are defined.

ÿ Optimization criteria
The scheduling engine must comply with: + minimization:

ÿ of the distance,
Machine Translated by Google

ÿ and/or time (depending on settings),

+ the constraints: ÿ
schedules, ÿ
capacities, ÿ
geographical areas, ÿ maximum
tour duration.

ÿ Generation result + The system

generates: ÿ one or more
routes, ÿ each route must consist of: ÿ
A route, ÿ Packages, ÿ 1 vehicle, ÿ 1 driver, ÿ Estimated
times.

+ The generated routes are in the status " To be validated".

Manual adjustment rules

ÿ Modification before validation
+ As long as a route is not validated: ÿ parcels can be
moved, the vehicle can be changed, the
ÿ
driver can be changed, ÿ the order
ÿ
of steps can be adjusted.

Each modification triggers an automatic recalculation.

ÿ Compliance with constraints after adjustment

+ Any modification must remain compliant with: ÿ
capacities, ÿ schedules,
ÿ compatibility rules.

+ A non-compliant modification is rejected with an explicit message.

Tour validation rules

ÿ Mandatory validation + A route
must be explicitly validated by the logistics agent.
+ During validation:
ÿ a tour name is mandatory, ÿ assignments are
fixed.

ÿ Data freeze
+ After validation: ÿ no
structural modification is allowed, ÿ only operational follow-up
actions are possible.

Operational monitoring rules ÿ Tour start +

A tour starts: ÿ automatically at the

scheduled time, ÿ or manually by
the agent.
Machine Translated by Google

+ The actual departure is confirmed: ÿ by

exiting the geofence repository, ÿ or by user
action.

ÿ Step tracking
+ Each step automatically goes through the statuses: to do ÿ in progress ÿ delivered +
An anomaly can be declared manually or automatically.

ÿ Dynamic ETA
+ ETAs are continuously recalculated based on: actual GPS position,
ÿ
speed, ÿ observed stops.
ÿ

+ A significant delay triggers a global recalculation.

Tour end and closing rules

ÿ Closure
+ A route is closed: ÿ automatically after the
last delivery, ÿ or manually by the agent. + Upon closure: ÿ the data is
frozen, the driver becomes available again.

ÿ Post-processing + At closing,

the system automatically generates: ÿ The actual distance traveled, ÿ The actual
duration, ÿ The number of packages delivered,
ÿ Any delays.

Rules for historical data recording and reporting

ÿ Historicization
+ All completed tours are kept: ÿ for consultation, ÿ replay, ÿ performance

analysis.

ÿ Inter-module consistency
+ Route data must be consistent with:
ÿ TRACK / LIVE, ÿ History
& Replay, ÿ Reporting, ÿ Exports.

Error handling and degraded scenarios

ÿ Impossible cases
+ If the system cannot generate any routes, an explicit message is sent to the user,
with a list of possible causes (capacities, schedules, resources).
Machine Translated by Google

ÿ Robustness + In
case of calculation error: ÿ no existing
data is overwritten, ÿ the user retains the last valid state.

ACCEPTANCE CRITERIA
The Delivery Routes sub-module is considered compliant when all the above acceptance criteria are met, ensuring
automated, reliable, consistent and actionable delivery route planning.

Data preparation (prerequisite)

ÿ Parcel registration
+ The system allows for manual registration or import of packages.
+ A package can only be used for scheduling if it is: ÿ registered, ÿ geocoded (valid GPS
coordinates).

+ A package without contact details is automatically excluded with an explicit message.

ÿ Vehicle availability + The

system displays the list of vehicles with their status.
+ Vehicles that are broken down, undergoing maintenance or are unavailable are automatically excluded.
+ Only available vehicles can be used for route generation.

ÿ Driver availability + The system

displays the list of drivers with their status.
+ Drivers who are absent, on leave or inactive are automatically excluded.
+ An unavailable driver cannot be assigned to any route.

Delivery day settings ÿ Mandatory daily parameters + Route

generation is impossible until: the date, ÿ start time, ÿ end

time, and depot are entered.
ÿ

+ An explicit message indicates the missing fields.

ÿ Temporal consistency +
The end time must be strictly greater than the start time.
+ An inconsistency is blocking the generation of routes.

Automatic route generation

ÿ Generation Trigger
+ The Generate routes button is only active if: ÿ at least one package is
available, ÿ at least one vehicle is available, ÿ
at least one driver is available.

Otherwise , the button is greyed out with an indication of the cause.

Machine Translated by Google

ÿ Generation result + The system

generates one or more routes.
+ Each generated route contains: ÿ at least one
package, ÿ a vehicle, ÿ a
driver, ÿ a route, ÿ
estimated times.

+ The generated routes are in the status " To be validated".

ÿ Compliance with constraints

+ No route exceeds: the vehicle's weight
ÿ
capacity, the vehicle's volume
ÿ
capacity, the maximum programmed
ÿ
duration.
+ The time constraints for parcels are respected.
+ The generated routes respect the authorized zones.

Visualization & Interface

ÿ Map visualization + The generated
routes are visible on the central map.
+ Each tour is displayed with: ÿ a distinct color, ÿ its
route, ÿ its numbered stages.

+ Selecting a tour highlights its route.

ÿ Side column
+ The Parcel / Vehicle / Driver / Routes / Settings tabs are
accessible.
+ The displayed data is consistent with the current state of the planning.

ÿ Global Timeline
+ The timeline displays all the day's routes.
+ Estimated departure and end times are visible.
+ Any overlaps are legible.

Manual adjustment of routes

ÿ Modification before validation + While a route is

in status To be validated: ÿ parcels can be moved, the vehicle can

be modified, the driver can be modified.
ÿ

Each modification triggers an automatic recalculation.

ÿ Blocking inconsistencies
+ A modification that violates: ÿ a capacity,
ÿ a time constraint, ÿ
an authorized zone

is refused.
Machine Translated by Google

+ An explicit message explains the reason for the refusal.

Tour validation
ÿ Mandatory validation +
A tour cannot be validated without a tour name being entered.
+ After validation: the tour
ÿ
changes to Planned status, ÿ the data is
frozen.

ÿ Data freeze
After validation, the packages, route, vehicle and driver can no longer be
modified.

Operational execution and monitoring

ÿ Starting the tour + A tour starts
automatically at the scheduled time or manually.
+ The status changes to In Progress.

ÿ Real-time tracking
+ The courier's position is visible in real time via TRACK / LIVE.
+ The status of the steps evolves automatically : to do ÿ in progress ÿ delivered.
+ The ETAs are recalculated dynamically.

ÿ Anomaly detection
+ An anomaly can be: ÿ declared
manually, ÿ detected automatically
(delay, prolonged stop).
+ The anomaly is immediately visible to the logistics agent.

Closing and post-processing

ÿ Tour closing
+ A delivery route is closed automatically after the last delivery or manually.

+ The driver becomes available again.

ÿ Summary generation + At closing,

the system automatically generates: ÿ The actual distance, ÿ The
actual duration, ÿ The
number of packages
delivered, ÿ Any delays.

Historical data and reporting

ÿ History + Completed
tours are kept in the history.
+ They are available for replay and analysis.

ÿ Exports +
Tour data can be exported to CSV, XLS or PDF.
+ The exports correspond exactly to the displayed data.
Machine Translated by Google

Robustness & degraded cases

ÿ No results possible + If no route can
be generated: the system displays an explicit message,
ÿ
ÿ the causes are listed (capacities, resources,
schedules).

ÿ Data security
+ In case of technical error: ÿ no
existing data is lost, the previous state is preserved.
ÿ

CONSTRAINTS and DEPENDENCIES

The Delivery Routes section has strong dependencies on the Parcel, Vehicle, and Driver repositories, as well as on
the TRACK, Mapping, Routes, and History & Replay modules. It imposes strict constraints regarding consistency,
immutability, performance, and management of degraded modes to guarantee reliable and operational delivery
scheduling.

Internal functional dependencies

ÿ Dependence on the Parcel Nature module :
critical + The Routes
sub-module depends directly on: ÿ the existence of a parcel
database, ÿ the quality of the parcel data
(address, weight, volume, constraints).
No scheduling can be initiated without valid packages.
Constraints
+ A package without usable GPS coordinates cannot be integrated.
+ Modifying a package after the routes have been generated invalidates the results and
require a recalculation.
+ Package statuses must be synchronized in real time with the status of the
tour.

ÿ Dependence on the Vehicle Nature reference system:

critical. Routes are
generated only from vehicles that are: + available, + compatible in capacity, +
authorized in the
areas concerned.

Constraints
+ A change in vehicle status (breakdown, maintenance):
ÿ automatically invalidates routes not yet validated, ÿ can trigger an alert for
routes already planned.
+ Vehicle capabilities constitute a hard, unavoidable constraint.

ÿ Dependence on Drivers / Couriers database Nature: critical +

Routes require
an available driver to be generated.
+ The vehicle-driver pair is mandatory.
Machine Translated by Google

Constraints
+ An unavailable driver should never be suggested by the system.
+ A change in driver availability:
o requires a recalculation or reallocation, o cannot be
ignored by the scheduling engine.

Cross-cutting technical dependencies

ÿ Dependence on the TRACK / LIVE module
Nature: critical
The Tours module depends on the TRACK for:
+ real-time tracking, + ETA
updates, + detection of available
couriers.
Constraints
+ In the absence of geolocation data: generation remains
ÿ
possible (planning phase), ÿ but real-time tracking and dynamic
ETAs are degraded.
+ The quality of the GPS directly impacts: the accuracy
ÿ
of ETAs, the detection of
ÿ
the end of the route, the availability
ÿ
of couriers.

ÿ Dependence on the mapping engine Nature: critical

Mapping is
necessary to: ÿ visualize tours, ÿ display routes,
ÿ represent stages and statuses.

Constraints
+ The map must support: ÿ several
simultaneous tours, ÿ multiple layers (tours,
geofences, vehicles).
+ A map degradation should never block: the generation, the validation of
ÿ
routes.
ÿ

ÿ Dependence on the Routing / Optimization engine Nature: critical The

scheduling engine
relies on: + a route calculation service, + a multi-
constraint optimization engine.

Constraints
+ The service must manage: ÿ
Multi-stages, ÿ Time
windows, ÿ Vehicle capacities.

+ In case of unavailability, the system must offer a degraded mode: ÿ partial scheduling, ÿ
or assisted manual validation.
Machine Translated by Google

ÿ Dependence on Geocoding Nature: strong

+ Used for: ÿ
converting parcel
addresses, ÿ locating depots and return
points.
Constraints
+ Geographic coverage varies depending on the country.
+ Requirement for: ÿ
caching, ÿ fallback on
manually entered coordinates.

Dependencies with other FLEET sub-modules

ÿ Dependence on the Itineraries section
Nature: structural
+ Each tour implicitly generates a theoretical route.
+ The rules for calculation, freezing and historical data must be consistent.
Constraints
+ A validated tour inherits the immutability rules of the itinerary.
+ Any inconsistency between Itineraries and Tours is prohibited.

ÿ Dependence on the History & Replay module

Nature: strong
+ The completed tours must be:
ÿ replayable, ÿ
analyzable, ÿ
exportable.
Constraints
+ The theoretical route must be kept as is.
+ The actual route must be compared without recalculating afterwards.

Lifecycle constraints and data consistency

ÿ Immutability after validation
+ A validated route is fixed with ÿ The parcels, ÿ
The allocated
resources, ÿ The route.

+ Any modification requires: ÿ A

cancellation, ÿ or a new
generation.

ÿ Exclusive scheduling + The same

package can only be present in one active or planned route.
+ A single driver or vehicle can only be assigned to one active route.

Performance and load scalability constraints

ÿ Volumetrics
The system must support:
+ several dozen / hundreds of parcels per day, + several routes
generated simultaneously.
Machine Translated by Google

ÿ Response time
+ Route generation must remain compatible with operational use:
ÿ display of a “calculation in progress”
status, ÿ progressive restoration if necessary.

Security constraints and rights

+ Role management: ÿ
planning, ÿ
validation, ÿ
consultation.
+ No critical action (validation, cancellation) without explicit rights.

Mandatory degraded modes (robustness)

The system must provide clear behaviors in the event of:

+ unavailability of the routing engine, +
unavailability of geocoding, +
absence of GPS data, +
incomplete parcel data.
In all cases:
+ an explicit message is displayed, +
no inconsistent data is recorded.