INTEGRATED PROJECT AND EQUIPMENT MANAGEMENT SYSTEM AND METHOD USING IOT DEVICES AND SOFTWARE APPLICATIONS
FIELD OF THE INVENTION
The present disclosure relates to an integrated project and equipment management system and a method to be adopted in the field of construction, specifically suited for heavy civil construction industry, infrastructure development and mining industries. Specifically, the present invention relates to a system and method for integrated project and equipment management involving real¬time tracking of material, equipment, manpower, and finally, work accomplished.
BACKGROUND
Construction and mining projects are difficult to manage due to fragmentation and inaccessibility of relevant data related to work being done and equipment, plants, and machinery being used. The heavy civil construction including the construction of irrigation, road and rail infrastructure face the same issues. Thus, an owner/operator of a site does not have access to concise, accurate, and meaningful data on either performance of the plants, machinery and equipment, the material being produced and consumed, or on the work being done. Lack of transparency for such data increases time to take necessary action during critical issues such as stoppage of work, breakdown of equipment etc. Also, significant time, money and resources are consumed to routinely survey the work being performed by heavy civil construction/infrastructure equipment.
The conventional approach to manage such projects is to manually capture and consolidate data from a variety of sources either in the form of physical paperwork or isolated spreadsheets. In the case of 'project work-done data', daily progress reports are collected orally, on paper or on spreadsheets. In the case of 'equipment, plant and machinery data', usage and production logs are manually collected from the existing instruments available on the equipment. All these isolated fragments of data are to either be manually reconciled or entered into a traditional Enterprise Resource Planning (ERP) system. Due to the human intervention required to capture and process this plethora of data, the conventional approaches are liable to inaccuracy, irregularity and even deliberate mismanagement. Hence, this is an unreliable option and any training required to capture data effectively is an expensive and tedious proposition. While the existing plants, machinery and equipment generate data logs using OEM-specific data formats, such data is

fragmented and does not follow any set standard. Also, the data transfer protocols and interfaces used by various manufacturers also differ widely. As such, it is difficult for the operator of the site to process and use this information uniformly. Considering the fact that materials constitute a large part of the project cost, managing such an abuse becomes extremely crucial as costs of a project are an essential parameter of assessment of feasibility of a particular civil project. Also, the construction machinery which constitutes a significant part of the project cost is capital intensive and proper use of this asset reflects in the machine up-time, wear and tear, thus impacting the project cost and time schedules.
The problem being addressed is lack of insight into the project management for the heavy construction civil industry, where there is lack of equipment management, real-time coordination between the data generation, collection, tracking from various material production equipment and transport equipment operating at the site and the project contextual data (project plan & design, material codes, work codes, equipment codes etc.), which results in escalated costs, low profit margins and mismanagement of material and equipment.
SUMMARY
In order to overcome disadvantages of the current status-quo, the embodiment of the present invention provides a system for real-time data flow from construction site to management office, by monitoring every activity and event at a micro-level. This provides the much needed visibility in a system and provides access to any required data at any time. Further, embodiments of the application provide an end to end system for information capture and flow, which ensures that available data is not fragmented in any form. The embodiment also provides a single platform for construction companies and equipment companies to enable integrated project and equipment management. Project management comprises the monitoring of material, equipment and manpower inputs of work. Equipment management comprises tracking of all equipment operations metrics as well as maintenance-related data. Equipment maintenance is streamlined by enabling seamless integration of information from various equipment manufacturers. The embodiment also enables interaction, communication and coordination between construction companies and equipment companies to enable seamless equipment maintenance.
Embodiments of the application provide hardware to physically track materials and machinery, which helps avoid any abuse of the existing system and resources. An embodiment of hardware and the protocol used is described, along with the software application. Material movement, stock and utilization can be verified using computer-vision technology. The embodiments may

also rely on certain plug and play automation to reduce reliance on any manual intervention, as well as training and setup cost and time. Additionally, multiple communication/network protocols are used by embodiments of the application for reliable transfer of data. Embodiments of the present application capture daily work report, real-time locational, track and transactional data from equipment, machinery, plants, weigh-stations and vehicles, using the Stationary Units (SU) and Mobile Units (MU) IoT (Internet-of-Things) devices, and provides all of this data/ information over communication/ networking software application.
The data processed through "Analytics" algorithms, when cross-correlated with the project "Context," generate actionable "Insights". This enables the real-time and remote monitoring and management of all site-related activity. For example, insights related to asset usage, misidentification and wrong quantification of materials, misappropriation of material being transported to and from the sites can be easily and quickly identified. This enables quick action by operator in case of any issue, thereby reducing financial losses to the project considerably.
BRIEF DESCRIPTION OF THE DRAWINGS
In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components. These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
Figure 1 illustrates a diagrammatic representation of set up according to an embodiment of the present disclosure.
Figure 2 illustrates a process flow according to an embodiment of the present disclosure.
Figure 3A and 3B illustrate the overall concept of the present disclosure.
Figure 4 illustrates a method of an activity in accordance with an embodiment of the present invention.
Figure 5 illustrates the Software Application based on Central Server
Figure 6 illustrates Machine Generated data from the Plants
Figure 7 illustrates Machine Generated data from the Weigh-Bridge

Figure 8 illustrates Machine Generated data from Vehicles and Machinery
Figure 9 illustrates Manually Entered Data from Daily Work Entry
Figure 10 illustrates Manually Entered Data from Material Request
Figure 11 illustrates Manually Entered Data from Equipment Request
Figure 12A and Figure 12B provides Insights regarding Work Check
Figure 12C provides Insights regarding Work Reports
Figure 13 provides Insights regarding Notifications
Figure 14 provides Insights regarding Reports
Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
DETAILED DESCRIPTION
The following discussion provides a brief, general description of a suitable computing environment in which various embodiments of the present disclosure can be implemented. The aspects and embodiments are described in the general context of computer executable mechanisms such as routines executed by a general-purpose computer e.g. a server or personal computer (PC) or a laptop or tablet or mobile phone. The software environment can be in cloud computing or edge computing or dedicated data center. The embodiments described herein can be practiced with other system configurations, including internet appliances, mobile electronic programmable devices, hand held devices, body-worn devices, microprocessor systems, multiprocessor systems, microprocessor based or programmable consumer electronics, networked computers, mini computers, mainframe computers and the like. The embodiments can be implemented in an embedded system (Internet-of-Things) or a special purpose computing

device or processor system integrated with sensors, actuators and network/communication subsystems that is specifically programmed configured or constructed to perform one or more of the computer executable mechanisms explained in detail below.
For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.
The specification may refer to "an", "one" or "some" embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, It will be further understood that the terms "includes", "comprises", "including" and/or "comprising" when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, "connected" or "coupled" as used herein may include wirelessly connected or coupled. As used herein, the term "and/or" includes any and all combinations and arrangements of one or more of the associated listed items.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. The system, methods, and examples provided herein are illustrative only and not intended to be limiting. It will be understood by those skilled in the art that the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.

The figures depict a simplified structure only showing some elements and functional entities, all being logical units whose implementation may differ from what is shown, the connections shown are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the structure may also comprise other functions and structures. It should be appreciated that the functions, structures, elements and the protocols used in communication are irrelevant to the present disclosure. Therefore, they need not be discussed in more detail here. In addition, all logical units described and depicted in the figures include the software and/or hardware components required for the unit to function. Further, each unit may comprise within itself one or more components, which are implicitly understood. These components may be operatively coupled to each other and be configured to communicate with each other to perform the function of the said unit.
The project's "Contextual Information" is divided into three basic types for the sake of simplicity in explaining the embodiment, (a) "Material Information" (b) "Asset Information" (c) "Work Information".
"Material Information" is identified by Material Code. There will be material codes for Raw Material (Cement, Steel, Aggregate, etc.) and Mixed Material (Concrete, Asphalt, etc.).
"Asset Information" is identified by Asset Code. There will be asset codes for Vehicles (Dump Trucks, transit-mixers etc.), Plants (for Concrete, Asphalt, etc.), Crushers, Heavy Machinery (Excavators, Earth Drills, Cranes, Pavers, Backhoes, Bulldozers, etc.), Weigh-stations etc.
"Work Information" is identified by Work Code. Work information are hierarchical in nature, in line with the work-breakdown-structure of a project. Work Codes are further broken-down into Activity codes. Material, manpower and asset usage contribute towards activity completion. Each quantum of Activity is proportional to relevant Material Input and Asset Input.
Concrete pavement of a certain length, an exemplary project design for highway project, is based on the project layout and locations, design of structures and carriageway (highway). Here, each element = work code x length/quantity. There will be Activity at the plants, crushers, weighbridges, etc. where materials are consumed and/or produced based on the work codes for producing material of a required material code by a certain asset code. There will be activity for the vehicles and heavy machinery that transport material between source and destination location with/without acknowledgement mechanism, where what type of material to be transported by what type of machine is determined by the material code, asset code and the work code. The

volume of material, etc.) will indicate the type of activities to be handled and monitored by the project manpower.
The project management to solve the problems raised in the present execution methodology mentioned in the background section will be addressed in the below exemplary embodiment (Einsite™). This embodiment is a combination of (a) IoT devices (with sensors chosen/designed specifically for equipment related to heavy civil construction industry or mining industry) with Embedded Software Application which generates real-time activity data, which is uploaded to a database, typically in a cloud storage environment (b) Project Management Application (with knowledge base consisting of masters, reference data, norms) hosted on the Central Server, typically in a cloud computing environment, provides the input-output ports, does the data analytics by querying the database and cross-correlates with the context to generate actionable insights. The software application in IoT device deployed on the equipment is called Device Software Application (DSA), and the software application in the central server is called Central Software Application (CSA). The software application with the end-user (typically on a laptop or PC or tablet or mobile phone), that connects to the Central Software Application is called User Software Application (USA). The CSA can be deployed as a product or service. The DSA may vary depending on the variation in IoT for various equipment.
Using the embodiment we can do the "Project Management" by overseeing project progress & activity in real-time; see real-time location and status of all plants, machinery and vehicles; trace and play-back routes travelled; setup trigger-based custom notifications for various events so that issues that arise can be solved quickly; get automated report generation; ensure appropriate usage of materials and equipment; track inputs and costs of work done on a daily basis; improve project planning and execution; check all work that has been reported; compare work output with material and machinery inputs. We can do real-time, item-based, location-based reconciliation. This will provide material savings.
Using the embodiment, "Equipment Management" can be performed including monitor & manage equipment from multiple OEMs on single application; setup notifications for maintenance-related and other events; ensure appropriate utilization of plants, machinery & equipment; plan equipment deployment and utilization across projects; and seamless API integrations with all equipment OEMs. This will provide savings related to assets/equipment.
The embodiment combines Project Management and Equipment Management on a single software platform by enabling seamless integration, communication and coordination between

the end users, i.e. construction companies, and various equipment companies. The integration would be enabled and facilitated by APIs and intelligent systems created by the embodiment.
The embodiment's User Software Application responsible for providing the inputs and outputs for the end-user (here the construction company deploying and using the embodiment), primarily uses two types of inputs and generates two types of outputs. Inputs can be Machine generated (automated) or Manual (daily work report). The outputs of the project management software are in the form of Reports and Notifications. Both the types of outputs are used for process feedback loop by the end-user to improve the project efficiency via continued corrective actions taken by project staff.
The User Software Application allows three types of requests which are Material Request Information (MRI), Transport Request Information (TRI), and Equipment Request Information (ERI). The MRI is created based on planned-work, and can be used in both offline (lack of real¬time internet connectivity) and online situations. In offline situations, a smart card is programmed via User Software Application to produce a quantity (X) of material (M) and given to the plant operator. The information on the smart card cannot be tampered. This smart card is used to start the plant operation and decremented accordingly upon the status of production, by the plant's electronic controllers and devices, and the information is sent back to the User Application and Central Server. In online situations, a digital token can be created on mobile or web applications, and dispatched to the target plant. The TRI will be created at an appropriate time in synchronization with the plant's output delivery time, to carry the material to a destination location. The TRI typically goes to the vehicle garage, where a Handling Information (HI) with vehicle ID will be generated to confirm the type of vehicle to be used. Equipment Request Information (ERI) is created using the User Software Application (USA) running either on a PC or a Mobile Device. The ERI along with its associated information - like Equipment Type Code, intended Work/Activity Code, Chainage / Location where required - is logged into the Database. ERI typically is addressed to Garage where Handling Information (HI) like Equipment-ID, Fuel Quantity, Hour-Meter Reading are generated while confirming the allocation. Later in the day, this information is cross-correlated with real-time equipment logs and system generated trip-sheets as well as equipment operating thresh-holds to bring out aspects like Equipment Idle-Run-Time, Idle-Time, Duty-Cycle, Work-Fence-Straying etc. Once HI is generated the Central Software Application also dispatches appropriate Notification to all the concerned like Equipment Operators and Site Engineers.

According to embodiments of the disclosure, smart cards are contact-less RFID cards that are used to enable and acknowledge transactions.
Embodiment(s) of the present invention will be described below in detail with reference to the accompanying drawings.
Figure 1 of the disclosure illustrates a diagrammatic representation of heavy civil construction project site set up according to an embodiment of the present disclosure. According to the embodiment, capture of data is performed through two types of electronic controllers/devices -Stationary Unit 101 abbreviated as SU (also referred to as Cabin Controllers for Plant Equipment) and a Mobile Unit 102 abbreviated as MU (also referred to Vehicle Units for Transport vehicles and heavy machinery etc.).
According to an embodiment of the disclosure, the Stationary Unit (SU) 101 is an embedded system that contains Wi-Fi, GPS, GSM/GPRS/Edge/3G/4G SIM card, Smart Card reader/writer, keyboard, mouse, touchscreen/LCD display, speaker, microphone, multiple sensors and multiple ports for data capture, rechargeable back-up battery, as well as any other I/O protocols, interfaces and modules. These devices are used to capture data from weigh bridges / weigh Stations by capturing weight of incoming and outgoing vehicles and from plants (Concrete, Asphalt), Crushers, etc. by capturing production related data, both input and output quantities.
According to an embodiment of the disclosure, the Mobile Unit (MU) 102 is an embedded system that contains Wi-Fi, GPS, GSM/GPRS/Edge/3G/4G SIM card, Smart Card reader/writer, touchscreen/LCD display, speaker, microphone, multiple sensors and multiple ports for data capture, rechargeable back-up battery, as well as any other I/O protocols, interfaces and modules. These devices are used to capture locational and transactional data from all trucks, moving equipment and machinery. Fuel consumption and vehicle health metrics are also captured.
Data packets are sent from SU 101 and MU 102 as location data and contain GPS coordinates, time-stamps, and vehicle identification information.
Data packets are sent during the transaction of materials as transaction data and may comprise plant transaction, weigh bridge transactions and site acknowledgements. Plant transactions contain quantified data of inputs and outputs at material processing plants, in addition to vehicle ID of the Material Carrying Vehicle (MCV), material request ID and plant-operator ID. Weigh¬bridge transactions contain material code, weight, vehicle ID, operator ID. Site acknowledgement is when supervisors acknowledge the delivery of materials to the work-site using smart cards or digital tokens.

SU and MU run on Device Software Applications (typically embedded software with boot code, devices drivers and application based on cross-platform language like C, C++, Java & web technologies). SU and MU collect all the equipment-related operational data through telemetry interfaces. Some metadata can also be manually input by site-staff
The Central Server uses a Central Software Application (typically cross-platform language like Python, R, Java & web technologies) along with a Database, where all the manually reported, locational, tracking and transactional data are aggregated and analyzed.
Figure 2 of the disclosure illustrates a process flow according to an embodiment. In a standard process as per the embodiment, the method creates Material Request Information (MRI), Transport Request Information (TRI) and Equipment Request Information (ERI) 201on the User Software Application and writes requests on smart card. The smart cards or digital tokens are used by the plant operator, to initiate transaction at plant/crusher, which initiates collection of material 202. Transactional data is captured by SU 101 and MU 102 to include information such as weight of materials verified at weigh station 203; material dropped in requested site-location 204, and acknowledged by supervisor using smart card and daily progress report entered into the Distributed Software Application 205. All entries are verified using locational and transactional data from SUs 101 and MUs 102. An entire day's activities are visualized and analyzed on the Central Software Application 206.
Embodiments of the present disclosure may be utilized in the entire construction and mining domains to manage project more efficiently. It increases accountability by giving real-time visibility of project activity and identifies pilferage and misuse of materials and machinery.
It provides optimization of vehicle and plant efficiency and utilization with "Real-Time Feedback Loop" of project execution and improved project planning and execution. It increases scalability and convenience in project management and enables construction companies to take on more projects with limited management staff. It eliminates paperwork and manual data entry and reduces manpower requirements.
Figure 3A and Figure 3B illustrate the overall concept of the present disclosure through the embodiment (Einsite™). In figure 3A, the method 301 involves the collection and transmission of various types of real-time data from all vehicles, plants, crushers, heavy machinery and weighbridges using MUs and SUs. MUs are tethered onto vehicles and heavy machinery and collect and transmit to the cloud various activity-related data such as location, ignition status, activity status, work-output etc., via the available telemetry interfaces. SUs are tethered onto

plants, crushers and weighbridges using the available telemetry interfaces, and collect relevant production and maintenance related data. Production data includes to the consumption quantity of raw-materials and production quantity of output-materials in plants and crushers, weight of current MCV on weighbridges etc. Maintenance data includes any system alerts or notifications pertaining to the proper upkeep of all equipment. While all the data collected from equipment is valuable, it is fragmented and does not immediately lead to actionable insights. The embodiment consolidates equipment data from method 301 into actionable insights by linking it with method 302. Method 302 involves certain contextual information that would provide context and meaning to the data collected in method 301. Method 302 involves the use of work codes, material codes, asset codes, project plan & design, and work progress reports. Work codes comprise the Work Information which is related to the proportionate usage of relevant assets and materials, that can be identified via the asset codes and material codes that in turn comprise Asset Information and Material Information. Work progress reports are in the form of Daily Work Reports that contain information about quantities of work codes performed at specified locations. Only with the contextual data from method 302 can any actionable insights be deciphered from method 301. For example, as per project plan and design, if a particular work code is reported done at a location, the embodiment, using expert systems arrives at the material and asset usage norms. These norms are compared to the actual usage of material and assets, as per the data collected from MUs and SUs in 301. If the actual usage exceeds norms, it shall be identified as requiring the action and attention of the relevant project staff. Thus, by combining the results of methods 301 and 302, a holistic integrated project and equipment management service 303 can be provided to the end-user.
Figure 3B describes the present embodiment (Einsite™) of the integrated project and equipment management system, with a single platform for construction companies 305 and equipment companies 308. The project and equipment management method 304 provided by the embodiment 300 to the end user construction companies 305 has already been described in part by figure 3A. Method 306 of collecting contextual data from the end user has also been described in figure 3A. The method 304 is also augmented and improved by method 309 that involves the equipment companies 308. Method 309 is in turn dependent on method 307 provided by the embodiment 300 to equipment companies 308. The embodiment 300 provides API access for data sharing and communication to equipment companies 308 on its software platform 300. Equipment companies 308 can exercise the APIs given in method 307 to bring their own expert systems and intelligence, as well as service and support onto the embodiment's software platform 300, via method 309. Expert systems and intelligence refer the certain

dashboards and analytics frameworks to better present the data collected by MUs and SUs to the end-users 305. These expert systems and frameworks will be regulated by 300 to ensure the appropriate level of service to the construction companies 305. Service and support refer to seamless coordination on the repair and upkeep of all equipment. For example, if an equipment is in need of repair or service, the embodiment 300 will inform both parties 308 and 305, and create a channel for their communication and coordination on its software platform so that the service and support are streamlined and effectively completed. The services comprising method 309 will thus form a subset of the services offered by the embodiment 300 to construction companies 305, via method 304. As an added benefit, the embodiment 300 also brings equipment companies 308 closer to their end-user 305 and improves overall customer satisfaction. This symbiotic relationship created by the embodiment 300 via its integrated project and equipment management software and hardware platform for construction companies 305 and equipment companies 308 will create a win-win situation for the benefit of all parties involved.
Equipment companies 308 share and update through method 309 various equipment optimization parameters, efficiency norms, alarm thresholds and predictive maintenance algorithms. This manufacturer and equipment specific data set is used by the embodiment 300 to analyse the project data 306 and presents valuable insights 304 to the construction companies 305.
The method 309 that facilitates expert system reference data may adopt various modes of data sharing mechanisms like API provided by embodiment 300, API provided by equipment manufacturer 308, document import and/or a physical document.
Using embodiment 300 construction companies 305 now can enable various equipment related notifications to be sent to equipment manufacturer 308. Based on these notifications, equipment companies 308 provide required service and support acknowledging through method 309 to the construction company 305 using method 304.
Figure 4 illustrates a method 400 to manage an exemplary Project Activity, involving transport of an amount (X) of material (M) from a source location (SL) to a destination location (DL) via a material carrying vehicle (MCV), in accordance with an embodiment of the present invention. Unless otherwise specified, the terms, have the meanings commonly used in the field of construction and/mining and machines involved therein. Specifically, the following terms have the meanings indicated below.
The project can be heavy civil constructions projects, mining projects and other industrial projects that involve a project activity including transport of materials and surveillance of the

quantities of materials being transferred from one source location (SL) to another destination location (DL). The destination location (DL) can include one or more sites and can also include mid-way locations allocated to monitor the transportation.
The material (M) can include both raw and produced material such as fuel and other substances such as cement, concrete, sand, stones, asphalt, crushers etc. The amount (X) refers to a measured quantitative value of the material (M).
The material carrying vehicle (MCV) includes a variety of transportation vehicles that can be used to carry the material (M), such transportation vehicles including trucks (light, medium, heavy, super-heavy), fuel tanks equipped trucks, dump trucks, concrete transport trucks, haul trucks, cranes, mining vehicles and many more.
As illustrated in Figure 4, the method 400 includes at step 401 receiving Transport Request Information (TRI), which typically goes to the garage. In one implementation, the transport request information (TRI) can be received at a central server (CS). The CS can be accessed by one or more project operators who can monitor and survey the material (M) being transported in a desired material carrying vehicle (MCV) implementing the method 400 of the present invention.
The TRI is typically a networking protocol packet comprises of information about the material (M), information about the amount (X) of material, information about the source location (SL), and information about the destination location (DL). The X refers to the actual quantitative value of that M being measured at the SL. Further, information about SL and DL refers to details identifying the location coordinates such as GPS data. The TRI can be received from SL (in this case plant producing the material), or from DL (where material needs to be used), or from the project operator or a third party.
The step 402 of the method 400, retrieving handling information (HI) based on TRI. HI comprises of information pertaining to the MCV. The HI enables identifying a type of MCV suitable to carry X amount of M. For example, M being heavy stones may require suitable heavy trucks as the MCV or M being a fuel will require a MCV equipped with a fuel tank. Further, the HI may comprise information pertaining to a person-in-charge at the SL and/or a person-in-charge at the DL.
The step 403 of the method 400, creating a Transport Data Packet (TDU) which is typically a network protocol packet comprising TRI and HI. Depending upon the TDU, the project managers

can supervise the transportation of materials and acknowledge accurate and precise data related to such transportation of the materials.
The step 404 of the method 400, providing the TDU to the electronic controllers/devices at SL and DL. Here the electronic controllers being either of Stationary Unit (SU) or Mobile Unit (MU) or smart card or digital token, an embedded system (IoT) with wireless connectivity as per the present embodiment. The TDU shall always include accurate data from the available information and cannot be altered by any person at the SL or DL or any other person not authorized to modify the TDU. An end-to-end transparency of data in TDU being shared is maintained in the implementation of the present invention.
The step 405 of method 400, receiving (a) Source Location Transaction Information (SLTI) or Source Location Manifest Information (SLMI) from SL, and (b) Destination Location Transaction Information (DLTI) or Destination Location Acknowledgement Information (DLAI) atDL.
The SLTI is automatically generated by the SU 101 at the SL. It can include information such as: (1) Information about M provided to the MCV; (2) information about the X provided to the MCV; (3) information about the SL; and (4) date & time stamp. Here SU is capable of generating SLTI information based on the interaction with sensor-complex at SL. The SL can have sensors that can include a weight sensor, an image sensor, location sensor, a plant telemetry sensor-complex and many other sensors that are enabled to capture (1) information about M and (2) information about the X, and provide a time stamp as described above. Such sensors enable capturing accurate data in relation to the M and X is used to ensure transparency during the entire implementation of the project activity. The time stamp may include multiple time stamps, wherein each corresponds to loading of M into the MCV, dispatch of MCV and other relevant events required to be captured by the project operator.
The SLMI is generated through an input device, such as an integrated virtual or physical keyboard on SU 101 at the SL, where SLMI includes information relevant to the project as provided by the person-in-charge at the SL. This information can be the same as SLTI associated with M, X, MCV, time stamp etc., but are provided by the person-in-charge. The person in-charge can communicate SLMI using the input device. In another implementation, both the SLTI and SLMI can be generated to ensure no discrepancy in the data received at CS.
The DLTI is generated by the SU at the DL. The DLTI can include information such as: (1) information about M received from the MCV; (2) information about the X received from the

MCV; (3) information about the DL; and (4) a date & time stamp. The SU gathers DLTI information on the basis of sensor data generated by sensors at various intermediate pre-specified locations where the MCV stops by or waits to be checked and monitored. For example, weight sensors, image sensors, RFID transponders (contactless cards), etc., can be used as sensors at such one or more intermediate locations and at DL. The DL can implement sensor devices to capture data regarding the location of the DL and time stamps, the time stamps being associated with one or more relevant activities and events at the DL during receiving the MCV at the DL and unloading the transported M from the MCV.
The DLAI is generated by the MU of the MCV at the DL, where DLAI includes acknowledgement information relevant to the project as provided by the person-in-charge at the DL. This information can be the same as DLTI associated with M, X, MCV, time stamp etc., but are provided by the person-in-charge. The person-in-charge generates the DLAI by indicating on a mobile app, or by flashing a smart card on the MU of the MCV. In another implementation, both the DLTI and DLAI can be generated to ensure no discrepancy in the data received at CS.
The step 406 of the method 400, generating "transaction information" based on: (a) at least one of SLTI and SLMI; and (b) at least one of DLTI and DLAI. Further, the method 400 includes at step 407 indicating completion of the activity if the "transaction information" satisfies at least one predetermined criterion.
In one implementation, the SLTI received from the SL can be compared quantitatively with the DLTI to assess if the M has been transported as desired in quantity X to the DL using the MCV allocated to the transportation. In another implementation, the SLMI received from the SL can be compared quantitatively with data received from DL. In one another implementation, the DLAI received from the DL can be compared quantitatively with data received from SL. Such comparisons, with a reasonable tolerance are used to generate transaction information. Accordingly, if the "transaction information" satisfies at least one predetermined criterion, the completion of the activity is indicated. The one or more predetermined criterion can be set by the project manager for validating the transaction information. However, these examples should not be construed as limiting and other criterions as suitable to the industrial project can be implemented.
The method 400 has provision for storing the TDU on a mobile device. The mobile device can be utilized by the user to manage projects efficiently. The mobile device provides real time visibility of project activity and prevents pilferage and misuse of materials and machinery.

The method 400 provides receiving tracking information from a Mobile Unit (MU) provided on the MCV, described in more detail below.
In one implementation, the "tracking information", which is typically a network protocol packet can comprise one or more of a location related data, a date &time stamp data, a vehicle condition related data, a vehicle fuel-level data, a vehicle driver-ID data and a vehicle driving-quality data (based on in-built inertial sensors). The MU enables tracking of the MCV during transportation. Further, the condition of the MCV can also be assessed from the above information such as vehicle fuel level data which can enable the project operator to further assess the progress of the project depending on factors related to the MCV. The MCV may have one or more sensors on the MCV that are enabled to monitor the tracking information listed above. The MCV may operate in accordance with the project requirement on road such as in the case of heavy machineries in road constructions, mining industries etc. The MU can also be used to gather data from MCV operations on road and provide such data to CS to enable mentoring of the MCV during operation.
The MCV can be adapted to receive and store the information gathered at the SL and DL using the in-built inertial sensors or a device capable of receiving information from SU located at SL and DL respectively. Such information gathered and stored can include SLTI, DLTI, SLMI, DLAI. This data gathered by the MCV is used to generate transaction information to be communicated to the CS.
Figure 5 shows an exemplary screenshot of software application based on Central Server as per the embodiment. The figure illustrates a view for the operator to have an overall understanding of the project progress right from the fuel and material stocks, incoming & outgoing material, plant production data, milestones and strip chart to monitor the work progress. The figure indicates a few enabled features in the application for the sake of understanding. Some of features the software are explained in the figures 6 to 14 through the screenshots below.
Figure 6 shows a screenshot of machine generated data packets from a plant wherein, the data packets are related to plant on the device server. The plant through connected IoT device (SU) automatically send Transaction and Telemetry data to the central server. This data is both periodic and event triggered.
Figure 7 shows a screenshot of machine generated data packets from weigh-bridge wherein, the data packets are related to weigh-bridge on the device server. The weigh-bridge post through

connected IoT device (SU) automatically sends Transaction data to the central device sever. This is usually event based.
Figure 8 shows a screenshot of machine generated data from Vehicle & Machinery. The data packets are related to Vehicle & Machinery on the device server. All the Vehicles and Machinery through the tagged IoT device (MU) automatically send the periodic Track and event based Load and Unload Transaction packets to the central device server to be populated on the database.
Figure 9 shows a screenshot of manually entered data regarding Daily Work Entry. Daily work progress is reported by the site-engineer using the software application. The work-codes and their relevant descriptions are shown to the user for easy and error-free data entry.
Figure 10 shows a screenshot of manually entered data regarding Material Request. Material Request is made through the application by site-engineer. Once approved the same is written on digital token in a mobile application or to a contact-less smart card which is dispatched to the plant operator. The card is then inserted in to the IoT plant device (SU) during the production at the plant. This data is embedded in to the Transaction Data packets of the concerned plant and propagated to the back-end.
Figure 11 shows a screenshot of manually entered data regarding Equipment Request. Equipment Requests are made through the application by the site-engineer / manager. Once approved the Garage / P&M in-charge allocates equipment and the same is notified to the requested party. The allocation data which is saved on the back-end is used for various work reconciliations and asset utilization validations.
Figure 12A shows a screenshot of a work check which provides insight of various parameters comparing the reported data to the norms.
Figure 12B shows a screenshot of a work check which provides insight of the progress of work in a visual manner, by juxtaposing the location coordinates with the context.
Figure 13 shows a screenshot of customized notifications, regarding certain event triggered. Actions can be taken swiftly to see that there is no hindrance in the project progress.
Figure 14 shows a screenshot of an automatically generated report.
As will be appreciated by one of skill in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the

form of an entirely hardware embodiment, a software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a "circuit" or "module."
Furthermore, the present invention was described in part above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. Instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
Instructions may also be loaded onto a computer or other programmable data processing apparatus like a scanner/check scanner to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Benefits, commercial advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.
While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein. The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be

combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.
It should also be noted that in other implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. In the drawings and specification, there have been disclosed exemplary embodiments of the invention. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being defined by the following claims.