1. A method for real-time management of a transport distress situation, the method comprising: receiving, by a distress managing system (107), at least one of connecting trip data (213) and preference data (215) of one or more passengers on encountering the transport distress situation, wherein the connecting trip data (213) comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip; determining, by the distress managing system (107), possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation; and performing, by the distress managing system (107), one of: generating a first optimal travel plan for the one or more passengers to reach the departure point based on the connecting trip data (213), the preference data (215) and real-time data (217) when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers; or receiving information related to an end destination and an urgency level to reach the end destination and generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data (215) and the real-time data (217) when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers.

2. The method as claimed in claim 1, wherein the possibility of reaching the departure point is determined based on real-time traffic data.

3. The method as claimed in claim 1 further comprises suggesting, by the distress managing system (107), alternatives to the end destination for the one or more passengers when the end destination is unreachable, wherein the alternatives comprises at least one of a location proximal to the distress location with availability of a transport facility to reach the corresponding end destination and a location proximal to the corresponding end destination, which is determined to be reachable.

4. The method as claimed in claim 1, wherein generating the first optimal travel plan and the second optimal travel plan comprises: detecting, by the distress managing system (107), availability of one or more modes of transport proximal to the distress location of the one or more passengers; and selecting, by the distress managing system (107), one of the one or more modes of transport for each of the one or more passengers using the real-time data (217).

5. The method as claimed in claim 4, wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or the end destination, seat availability in the one or more modes of transport and real-time traffic data.

6. The method as claimed in claim 4 further comprises implementing, by the distress managing system (107), at least one of the first or the second optimal travel plan by arranging the selected mode of transport for each of the one or more passengers based on the preference data (215), upon receiving approval from the one or more passengers for at least one of the first or the second optimal travel plan.

7. The method as claimed in claim 1 further comprises arranging, by the distress managing system (107), one of one or more modes of transport for each of the one or more passengers to reach corresponding original ticket destination based on sensor data (209), wherein the sensor data (209) is received from one or more sensors configured in a vehicle (101) associated with the transport distress situation.

8. The method as claimed in claim 7, wherein the original ticket destination of each of the one or more passengers is identified using ticket data (211) received from at least one of online and offline modes comprising an Electronic Ticketing Machine (ETM), fare collection system, mobile ticketing system and paper ticket.

9. The method as claimed in claim 1, wherein the preference data (215) comprises at least one of grouping preference, mode of transport preference and safety preference.

10. The method as claimed in claim 1 further comprises: receiving, by the distress managing system (107), the preference data (215) of the one or more passengers in absence of the connecting trip data (213); and generating, by the distress managing system (107), a third optimal travel plan for the one or more passengers to reach an original ticket destination based on the preference data (215) and the real-time data (217).

11. The method as claimed in claim 10, wherein generating the third optimal travel plan comprises: detecting, by the distress managing system (107), availability of one or more modes of transport proximal to the distress location of the one or more passengers; and selecting, by the distress managing system (107), one of the one or more modes of transport for each of the one or more passengers using the real-time data (217), wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the original ticket destination, seat availability in the one or more modes of transport and real-time traffic data.

12. A distress managing system (107) for real-time management of a transport distress situation, the distress managing system (107) comprising: a processor (109); and a memory (113) communicatively coupled to the processor (109), wherein the memory (113) stores the processor-executable instructions, which, on execution, causes the processor (109) to: receive at least one of connecting trip data (213) and preference data (215) of one or more passengers on encountering the transport distress situation, wherein the connecting trip data (213) comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip; determine possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation; and perform one of: generating a first optimal travel plan for the one or more passengers to reach the departure point based on the trip data, the preference data (215) and real-time data (217) when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers; or receiving information related to an end destination and an urgency level to reach the end destination and generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data (215) and the real-time data (217) when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers.

13. The distress managing system (107) as claimed in claim 12, wherein the processor (109) determines the possibility of reaching the departure point based on real-time traffic data.

14. The distress managing system (107) as claimed in claim 12, wherein the processor (109) is further configured to suggest alternatives to the end destination for the one or more passengers when the end destination is unreachable, wherein the alternatives comprises at least one of a location proximal to the distress location with availability of a transport facility to reach the corresponding end destination and a location proximal to the corresponding end destination, which is determined to be reachable.

15. The distress managing system (107) as claimed in claim 12, wherein to generate the first optimal travel plan and the second optimal travel plan, the processor (109) is configured to: detect availability of one or more modes of transport proximal to the distress location of the one or more passengers; and select one of the one or more modes of transport for each of the one or more passengers using the real-time data (217).

16. The distress managing system (107) as claimed in claim 15, wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or the end destination, seat availability in the one or more modes of transport and real-time traffic data.

17. The distress managing system (107) as claimed in claim 15, wherein the processor (109) is further configured to implement at least one of the first or the second optimal travel plan by arranging the selected mode of transport for each of the one or more passengers based on the preference data (215), upon receiving approval from the one or more passengers for at least one of the first or the second optimal travel plan.

18. The distress managing system (107) as claimed in claim 12, wherein the processor (109) is further configured to arrange one of one or more modes of transport for each of the one or more passengers to reach corresponding original ticket destination based on sensor data (209), wherein the sensor data (209) is received from one or more sensors configured in a vehicle (101) associated with the transport distress situation.

19. The distress managing system (107) as claimed in claim 18, wherein the processor (109) identifies the original ticket destination of each of the one or more passengers using ticket data (211) received from at least one of offline and online modes comprising an Electronic Ticketing Machine (ETM), a fare collection system, a mobile ticketing system and a paper ticket.

20. The distress managing system (107) as claimed in claim 12, wherein the preference data (215) comprises at least one of grouping preference, mode of transport preference and safety preference.

21. The distress managing system (107) as claimed in claim 12, wherein the processor (109) is further configured to: receiving, by the distress managing system (107), the preference data (215) of the one or more passengers in absence of the connecting trip data (213); and generating, by the distress managing system (107), a third optimal travel plan for the one or more passengers to reach an original ticket destination based on the preference data (215) and the real-time data (217).

22. The distress managing system (107) as claimed in claim 21, wherein to generate the third optimal travel plan, the processor (109) is configured to: detect availability of one or more modes of transport proximal to the distress location of the one or more passengers; and select one of the one or more modes of transport for each of the one or more passengers using the real-time data (217), wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the original ticket destination, seat availability in the one or more modes of transport and real-time traffic data. , Description:TECHNICAL FIELD The present subject matter is related, in general to field of transportation management and more particularly, but not exclusively to a method and system for real-time management of a transport distress situation. BACKGROUND In rural areas and metropolitan cities, there exists an enormous demand for public transport. The public transport may include, buses, trains, flights, metro and the like. On a daily basis, millions of people depend on public transport for meeting their daily travel needs. However, the public transport often faces transport distress situations such as vehicle breakdown, accidents and the like. Transport distress situations are inevitable and may disturb the schedule of people travelling by such public transport. Such transport distress situations need to be managed by arranging an alternative transport for the passengers of the public transport stuck in the transport distress situation. Currently, the traditional way of handling the transport distress situation includes accommodating the passengers in another public transport passing along the same route. However, shifting the passengers to another public transport passing along the same route may not be convenient for the passengers. Firstly, the waiting time is undefined as the passengers have to wait until another public transport that can accommodate all the passengers arrives in that route. Secondly, undefined waiting time may disturb scheduled passenger activities. Further, the passengers may have to bear extra money in availing services of another public transport. Few of the advanced techniques involve detecting the transport distress situation. Upon detecting the transport distress situation, the passengers of that public transport vehicle may be provided with an alternate travel advisory which advises the commuter to leave that public transport vehicle and to board another public transport vehicle. The alternate travel advisory may determine a nearest stop where the passengers can board another public transport vehicle. Though these techniques provide the alternate travel advisory that could guide the passengers to another public transport, these techniques do not solve the problem of undefined waiting period for boarding another public transport that would take them to their destination. Further, some of the existing techniques performs pattern analysis of various passengers to understand time of their travel, preferred routes of their travel, preferred modes of transport and the like. Based on the pattern analysis, these techniques provide a prior notification to the passengers regarding a disruption in their travel route such as traffic jam, accidents, road blocks due to rain and the like, such that the passengers may avoid taking that route. Firstly, these techniques do not address the problem of managing transport distress situation in real-time, instead these techniques provide a way to avoid navigating along the routes that have encountered such transport distress situations. Also, these techniques work solely on predicted patterns of the passengers which may not be completely correct and reliable. The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art. SUMMARY One or more shortcomings of the prior art are overcome and additional advantages are provided through the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure. Disclosed herein is a method for real-time management of a transport distress situation, the method comprising receiving, by a distress managing system, at least one of connecting trip data and preference data of one or more passengers on encountering the transport distress situation. The connecting trip data comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip. Further, the method comprises determining possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation. Subsequently, the method comprises performing one of generating a first optimal travel plan for the one or more passengers to reach the departure point based on the connecting trip data, the preference data and real-time data when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers, or, receiving information related to an end destination and an urgency level to reach the end destination and generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data and the real-time data when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers. Further, the present disclosure includes a distress managing system for real-time management of a transport distress situation. The distress managing system comprises a processor and a memory communicatively coupled to the processor. The memory stores the processor-executable instructions, which, on execution, causes the processor to receive at least one of connecting trip data and preference data of one or more passengers on encountering the transport distress situation. The connecting trip data comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip. Further, the processor determines possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation. Subsequently, the processor performs one of generating a first optimal travel plan for the one or more passengers to reach the departure point based on the trip data, the preference data and real-time data when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers, or, receiving information related to an end destination and an urgency level to reach the end destination and generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data and the real-time data when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers. The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. 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 figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which: FIG.1 shows an exemplary architecture for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure; FIG.2 shows a detailed block diagram of a distress managing system for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure; FIG.3A and FIG.3B show a flowchart illustrating a method for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure; and FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown. DETAILED DESCRIPTION In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure. The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method. Disclosed herein are a method and system for real-time management of a transport distress situation. The method includes detecting a transport distress situation through one or more data sources. As an example, the transport distress situation may be any situation that involves events such as insufficiency of fuel, damage of vehicle parts, accident and the like that result in breakdown of a vehicle or immobility of the vehicle. Upon detecting the transport distress situation, a distress managing system may communicate with one or more passengers of the vehicle associated with the transport distress situation, to receive intention of the one or more passengers. In some embodiments, the intention of the one or more passengers may be related to connecting trip, end destination, urgency level, grouping preference, transport type preference, safety preference and the like. Further, the distress managing system may correlate real-time traffic data and the intention received from the one or more passengers to generate an optimal travel plan for each of the one or more passengers, in real-time, thereby managing the transport distress situation in real-time. The present disclosure includes collecting the intention and preference of the one or more passengers based on which the distress managing system generates an optimal travel plan. Therefore, the present disclosure not only manages the transport distress situation, but manages it in a way that the one or more passengers reach their respective destinations based on their preferences and intention. Mainly, the present disclosure collects data related to connecting trip of the one or more passengers to generate the optimal travel plan that helps the user reach departure point of the connecting trip within departure time, thereby ensuring that the transport distress situation does not affect the connecting trip of the one or more passengers. In scenarios where the departure point is unreachable within the departure time, the present disclosure provides an opportunity for the one or more passengers to choose an alternate destination and also determine urgency level to reach the alternate destination. Further, the present disclosure is workable for transport distress situations related to multiple modes of transports such as road transport, rail transport, air transport and the like. Also, the present disclosure provides a feature wherein the one or more passengers can choose to travel by a mode of transport of their choice among multiple modes. The present disclosure increases transport reliability and customer patronage. Further, the present disclosure effectively addresses the issue of service continuity and passenger convenience, based on data received in real-time. Further, the present disclosure ensures safety of the passengers. Also, the present disclosure provides a feature of grouping the passengers based on destination of the passengers, that helps in transporting the passengers in the most optimal and cost-effective way. In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense. FIG.1 shows an exemplary architecture for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure. The architecture 100 comprises a vehicle 101, a ticketing means 102, one or more sensors 103, a data source 1 1051 to a data source n 105n (collectively referred to as one or more data sources 105) and a distress managing system 107. The one or more data sources 105 may provide data related to a transport distress situation (also referred as distress data) and real-time data. As an example, the one or more data sources 105 may include, but are not limited to, a device used by one or more passengers to communicate with the distress managing system 107 through a voice call, voice message, a mobile application, a text message and the like, a wired or a wireless communication module configured in the vehicle 101, social networking sites and a control centre. In some embodiments, the one or more sensors 103 may also be a part of the one or more data sources 105. As an example, the one or more sensors 103 may include, but are not limited to, image sensors, vision sensors, pressure sensors, occupancy detection sensors and foot board sensors. The one or more sensors 103 may be configured in the vehicle 101. Further, the ticketing means 102 may be associated with the vehicle 101 for issuing journey related tickets for one or more passengers of the vehicle 101. In some embodiments, the ticketing means 102 may operate either in an online mode or an offline mode. As an example, the ticketing means 102 may include, but are not limited to, Electronic Ticketing Machine (ETM), a fare collection system, a mobile ticketing system and a paper ticket. In some embodiments, the ticketing means 102, the one or more sensors 103 and the one or more data sources 105 may communicate with the distress managing system 107 via a communication network (not shown in the FIG.1). The communication network may be a wired communication network, a wireless communication network and a combination of both wired and wireless communication network. The distress managing system 107 comprises a processor 109, an Input/output (I/O) interface 111 and a memory 113. In an embodiment, the I/O interface 111 may receive data related to the transport distress situation from the one or more data sources 105 that may be operated by the one or more passengers. As an example, data related to the transport distress situation may include location where the transport distress situation occurred (also referred as distress location), details of vehicle 101 associated with the transport distress situation such as vehicle number, type of vehicle and the like, reason for the transport distress situation, approximate count of the passengers, time at which the transport distress situation occurred and the like. Further, the I/O interface 111 may receive ticket data from the ticketing means 102 configured in the vehicle 101. As an example, the ticket data may include boarding location of the passenger, destination of the passenger, cost of the ticket, time when the ticket is issued, seat number and the like. Furthermore, the I/O interface 111 may receive sensor data from the one or more sensors 103 configured in the vehicle 101. As an example, the sensor data may include images of the one or more passengers, count of the one or more passengers, seat occupancy by the one or more passengers and the like. Further, the I/O interface 111 may also receive the real-time data. In some embodiments, the real-time data may be collected from one or more data sources 105 or may be determined by the processor 109. In some embodiments, the real-time data may include, but not limited to, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of a departure point or an end destination, seat availability in the one or more modes of transport and real-time traffic data. Upon receiving data related to the transport distress situation, the processor 109 may request the one or more passengers who have encountered the transport distress situation to provide at least one of connecting trip data and preference data. In some embodiments, the connecting trip data may be provided by the one or more passengers who have a scheduled connecting trip which may be affected due to the encounter of the transport distress situation. The connecting trip data may include, but is not limited to, a departure point, a departure time and a mode of transport for the connecting trip. Further, the preference data may be related to preferences of the one or more passengers. The preference data may include, but is not limited to, grouping preference, mode of transport preference and safety preference. Upon receiving the connecting trip data, the processor 109 may determine possibility of reaching the departure point, within the departure time, from the distress location of the one or more passengers in the transport distress situation. In some embodiments, the distress managing system 107 may use real-time traffic data to determine the reachability. If the departure point is reachable within the departure time, the processor 109 may generate a first optimal travel plan for the one or more passengers to reach the departure point. If the departure point is not reachable within the departure time, then the processor 109 may request the one or more passengers to provide an end destination and urgency level to reach the end destination. In some embodiments, the end destination may be an alternative destination provided by the one or more passengers when the departure point is unreachable. Further, the processor 109 may determine whether the end destination is reachable or not. If the end destination is reachable, the processor 109 may generate a second optimal travel plan for the one or more passengers to reach the end destination. In some scenarios, if the end destination is not reachable, the processor 109 may suggest alternatives to the end destination for the one or more passengers. Further, in some scenarios where the one or more passengers do not have a connecting trip, the processor 109 may generate a third optimal travel plan for the one or more passengers to reach an original ticket destination (destination indicated by the ticket issued by the ticketing means 102). However, in some scenarios, the one or more passengers may not be able to communicate with distress managing system 107 due to factors such as network unavailability, misplacing of user devices and the like. In such scenarios, the processor 109 may arrange one of one or more modes of transport for each of the one or more passengers to the original ticket destination (also referred as a default trip arrangement). In some embodiments, the processor 109 may identify the one or more passengers unable to communicate with the distress managing system 107 using the sensor data. Finally, the processor 109 may arrange one of the one or more modes of transport for each of the one or more passengers in accordance with either the first optimal travel plan, the second optimal travel plan, the third optimal travel plan or the default trip to corresponding destinations. FIG.2 shows a detailed block diagram of a distress managing system for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure. In some implementations, the distress managing system 107 may include data 203 and modules 205. As an example, the data 203 is stored in the memory 113 configured in the distress managing system 107 as shown in the FIG.2. In one embodiment, the data 203 may include distress data 207, sensor data 209, ticket data 211, connecting trip data 213, preference data 215, real-time data 217 and other data 219. In the illustrated FIG.2, modules 205 are described herein in detail. In some embodiments, the data 203 may be stored in the memory 113 in form of various data structures. Additionally, the data 203 can be organized using data models, such as relational or hierarchical data models. In some embodiments, the distress data 207 may be data related to the transport distress situation received from one or more data sources 105. The distress data 207 may include, but is not limited to, location where the transport distress situation occurred (also referred as distress location), details of a vehicle 101 associated with the transport distress situation such as vehicle number, type of vehicle and the like, reason for the transport distress situation, approximate count of passengers, time at which the transport distress situation occurred and the like. In some embodiments, the sensor data 209 may be data received from one or more sensors 103 configured in the vehicle 101. The sensor data 209 may include, but is not limited to, images of the one or more passengers, count of the one or more passengers and seat occupancy by the one or more passengers. In some embodiments, the ticket data 211 may be data related to ticket issued to one or more passengers boarding the vehicle 101, using ticketing means 102 associated with the vehicle 101. The ticket data 211 may include, but is not limited to, boarding location of the passenger, destination of the passenger (also referred as original ticket destination), cost of the ticket, time when the ticket is issued and the seat number. In some embodiments, the connecting trip data 213 may be related to a connecting trip of the one or more passengers, which is pre-scheduled. As an example, consider a passenger boards a bus, whose original ticket destination is railway station. The passenger may have a trip scheduled from railway station to another destination (end destination), for example “Chennai”. Therefore, such trips which are pre-scheduled may be referred as the connecting trips of the one or more passengers. The connecting trip data 213 may include, but is not limited to, a departure point, a departure time and a mode of transport for the connecting trip. In the above mentioned example, the mode of transport for the connecting trip is rail transport. In some embodiments, the preference data 215 may indicate preferences of the one or more passengers. In some embodiments, the preferences may be related to transportation of the one or more passengers from the distress location when the one or more passengers encounter the transport distress situation. The preference data 215 may include, but is not limited to, grouping preference, mode of transport preference and safety preference. In some embodiments, the grouping preference may indicate whether a passenger wishes to be grouped with other passengers at the distress location. In some embodiments, the mode of transport preference may indicate the mode through which the passenger wishes to travel from the distress location. In some embodiments, the safety preference may indicate level of safety required, for example, the passenger may select a level from a scale of 1 to 10. As an example, when the passenger is a woman, the safety preference may be between 8-10 indicating that the passenger has set safety as the highest priority during the travel. In some embodiments, the preference data 215 may also include miscellaneous/additional information such as gender of the passenger, time constraints of the passenger and the like. In some embodiments, the real-time data 217 may indicate data collected or determined in real-time to generate optimal travel plan for each of the one or more passengers. In some embodiments, the real-time data 217 may be collected from the one or more data sources 105. The real-time data 217 may include, but is not limited to, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or an end destination, seat availability in the one or more modes of transport and real-time traffic data. In some embodiments, the other data 219 may store data, including temporary data and temporary files, generated by the modules 205 for performing the various functions of the distress managing system 107. In some embodiments, the end destination and urgency level to reach the end destination, provided by the one or more passengers having pre-scheduled connecting trips, may be stored as part of the temporary data. In some embodiments, the data 203 stored in the memory 113 may be processed by the modules 205 of the distress managing system 107. The modules 205 may be stored within the memory 113. In an example, the modules 205 communicatively coupled to the processor 109 configured in the distress managing system 107, may also be present outside the memory 113 as shown in FIG.2 and implemented as hardware. As used herein, the term modules refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In an embodiment, the modules 205 may include, for example, a receiving module 231, an intention collecting module 233, a reachability determining module 235, a plan generating module 237, a plan implementing module 239 and other modules 241. The other modules 241 may be used to perform various miscellaneous functionalities of the distress managing system 107. It will be appreciated that such aforementioned modules 205 may be represented as a single module or a combination of different modules. In some embodiments, the receiving module 231 may receive distress data 207 from the one or more data sources 105. As an example, the one or more data sources 105 may include, but are not limited to, a user device wherein the one or more passengers may communicate via a voice call, voice message, a mobile application, a text message and the like, a wired or a wireless communication module configured in the vehicle 101, social networking websites and a control centre. Further, the receiving module 231 may receive the sensor data 209 and the ticket data 211 from the one or more sensors 103 and the ticketing means 102 respectively. As an example, the one or more sensors 103 may include, but are not limited to, image sensors, vision sensors, pressure sensors, occupancy detection sensors and foot board sensors. As an example, the ticketing means 102 may include, but are not limited to, Electronic Ticketing Machine (ETM), a fare collection system, a mobile ticketing system and a paper ticket. In some embodiments, the ticketing means 102 may operate either in an online mode or an offline mode. In some embodiments, the intention collecting module 233 may request the one or more passengers to provide at least one of the connecting trip data 213 and the preference data 215. In some embodiments, the intention collecting module 233 may receive both the connecting trip data 213 and the preference data 215 from the one or more passengers who have a pre-scheduled connecting trip which may be affected due to the encounter of the transport distress situation. In an alternate embodiment, when the one or more passengers do not have a pre-scheduled connecting trip, the intention collecting module 233 may receive only the preference data 215 to reach the original ticket destination from the distress location. When the intention collecting module 233 receives both the connecting trip data 213 and the preference data 215 from the one or more passengers, the processor 109 may activate the reachability determining module 235. In some embodiments, the reachability determining module 235 may determine reachability of the one or more passengers to a given location. In the current scenario, the reachability determining module 235 may determine possibility of reaching the departure point within the departure time from the distress location. In some embodiments, the distress managing system 107 may use real-time traffic data to determine the reachability to the departure point. When the reachability determining module 235 determines that the departure point is reachable within the departure time, the processor 109 may activate a plan generating module 237 to generate a first optimal travel plan for the one or more passengers. When the reachability determining module 235 determines that the departure point is not reachable within the departure time, the intention collecting module 233 may request the one or more passengers to provide the end destination and urgency level to reach the end destination. In some embodiments, the end destination may be any alternative destination that the one or more passengers would select, when the departure point is determined to be unreachable. In some embodiments, the end destination may be the original ticket destination. The urgency level may indicate how quickly the one or more passengers want to reach the end destination. Upon receiving the end destination and the urgency level, the reachability determining module 235 may determine whether the end destination is reachable as per the urgency level intended by the one or more passengers. In some embodiments, when the reachability determining module 235 determines the end destination to be reachable, the processor 109 may activate the plan generating module 237 to generate a second optimal travel plan for the one or more passengers. In some embodiments, when both the departure point and the end destination are determined to be unreachable, the reachability determining module 235 may suggest alternatives to the end destination for the one or more passengers. In a non-limiting embodiment, the alternatives may include suggesting a location proximal to the distress location with availability of a transport facility to reach the corresponding end destination. In another non-limiting embodiment, the alternatives may include a location proximal to the corresponding end destination, which the reachability determining module 235 may determine as reachable. If the one or more passengers select one of the suggested alternatives, the plan generating module 237 may generate a suitable optimal travel plan to reach the selected alternative. In some embodiments, when the intention collecting module 233 initially receives only the preference data 215 from the one or more passengers and not the connecting trip data 213, the processor 109 may activate the plan generating module 237 to generate a third optimal travel plan. In some embodiments, the third optimal travel plan may be generated to transport the one or more passengers to respective original ticket destinations, when the one or more passengers do not have a connecting trip. In some embodiments, the plan generating module 237 may generate the optimal travel plans for the one or more passengers as discussed below. In some embodiments, for generating the first optimal travel plan, the plan generating module 237 may initially detect availability of one or more modes of transport proximal to the distress location of the one or more passengers. Further, the plan generating module 237 may generate the first optimal travel plan based on the connecting trip data 213, the preference data 215 and the real-time data 217. In other words, generating the first optimal travel plan includes selecting one of the one or more modes of transport for each of the one or more passengers based on the connecting trip data 213, the preference data 215, the real-time data 217. In some embodiments, the plan generating module 237 may receive or determine the real-time data 217 to generate optimal travel plan for each of the one or more passengers. In some embodiments, the plan generating module 237 may determine the real-time data 217 using the preference data 215 and destination of the one or more passengers. As an example, the destination may be the departure point, the end destination, the original ticket destination or an alternative. In the context of the first optimal travel plan, the destination of the one or more passengers used for determining the real-time data 217 may be the departure point. The real-time data 217 may include, but is not limited to, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or an end destination, seat availability in the one or more modes of transport and real-time traffic data. In some embodiments, the plan generating module 237 may determine the distance from each of the one or more modes of transport to the distress location based on current location of the one or more modes of transport, using a pre-existing navigation application. As an example, the pre-existing navigation application may be, but is not limited to, GoogleTM Maps. In some embodiments, plan generating module 237 may determine the time required for each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the departure point (also referred as total time to reach the destination) using the below Equation 1. g(t)=b_0+T(?)*y -------------------- Equation 1 In the above Equation 1, g(t) indicates the total time to reach the destination; b0 indicates a constant failure cost; T(i) indicates traffic density at a given instance. The plan generating module 237 may derive traffic density from the real-time traffic data received from traffic data sources such as navigation applications, road sensors, vehicle surveillance device and the like; and y indicates distance from the one or more modes of transport to the distress location. Alternatively, the plan generating module 237 may determine the total time to reach the destination using the below Equation 2. g(t)=z_1+z_2 -------------------- Equation 2 In the above Equation 2, g(t) indicates the total time to reach the destination; z1 indicates time required for each of the one or more modes of transport to reach the distress location; and z2 indicates time required to transport the one or more passengers to the destination. Further, the plan generating module 237 may determine expenditure for each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the departure point (also referred as total expenditure to be borne for each of the one or more passengers by service provider associated with the vehicle 101, who is operating the distress managing system 107) using the below Equation 3. f(c)=a_0+per Km_tt*P_k ---------------- Equation 3 In the above Equation 3, f(c) indicates the total expenditure to reach the destination; a0 indicates a constant failure cost; Per Kmtt indicates cost per kilometre based on transport type (tt); and Pk indicates number of kilometres each passenger would travel from the distress location, where k indicates the number of stranded passengers in the distress location. Alternatively, the plan generating module 237 may determine the total expenditure to reach the destination using the below Equation 4. f(c)=x_1+x_2 -------------------- Equation 4 In the above Equation 4, f(c) indicates the total expenditure to reach the destination; x1 indicates cost for each of the one or more modes of transport to reach the distress location; and x2 indicates cost for transporting each of the one or more passengers to the destination. In some embodiments, when the one or more passengers travel in a group, the total expenditure to reach the destination may be determined using the below Equation 5. f(c)=a_0+per Km_tt ?*S?_0^n P_k/P_gm ---------------- Equation 5 In the above Equation 5, f(c) indicates the total expenditure to reach the destination; a0 indicates a constant failure cost; Per Kmtt indicates cost per kilometre based on transport type (tt); Pk indicates number of kilometres each passenger would travel from the distress location, where k indicates the number of stranded passengers in the distress location; Pgm indicates number of passengers travelling in the group; and n indicates total number of passengers in the distress location. In some embodiments, the total expenditure to reach the destination for each of the one or more passengers may vary depending upon the preference data 215. Consider a passenger has preferred “car” as the mode of transport and wishes to travel alone i.e. group preference is not selected In such scenario, the total expenditure that the service provider should bear to transport the passenger to the destination may be high when compared to the total expenditure in the case where the passengers have preferred to travel in a group. In some embodiments, when the one or more passengers have preferred to travel in a group i.e. when the group preference of the one or more passengers is “preferred”, the plan generating module 237 may consider the following conditions or factors while grouping the one or more passengers, that makes the grouping process efficient when compared to the process of grouping existing in the art: Grouping is performed based on destination of the one or more passengers and not the origin, since the origin location is the distress location and is same for each of the one or more passengers. Grouping is performed in a way that most optimal and a cost-effective option is determined for transportation without affecting the preferences of the one or more passengers. In some scenarios, grouping may be performed when the one or more modes of transport preferred by one or more passengers are unavailable or when the time for the one or more modes of transport to reach the distress location has exceeded a predefined threshold. When the grouping preference of the one or more passengers is unrealistic or highly expensive, the plan generating module 237 may reject such preference and group the one or more passengers with other passengers in a cost-effective manner. As an example, when a passenger prefers to travel individually in a bus, the preference may be unrealistic. Similarly, when the mode of transport preference is unrealistic, the plan generating module 237 may reject such preference and suggest an alternate mode of transport. In some embodiments, the plan generating module 237 may group the passenger corresponding to the unrealistic preference with other passengers in a cost-effective manner. As an example, when the passenger’s preference includes make and model of a car to travel, which is extremely expensive, the preference may be termed as unrealistic. Grouping may also be performed based on the safety preference of the one or more passengers. As an example, when the safety scale is high, the plan generating module 237 may group the passenger with other passengers instead of individually transporting the passenger to the destination. In some embodiments, selecting an optimal and the cost-effective option may be based on an objective function determined by the plan generating module 237 using the below Equation 6. objective function=w_0+ ?_(n=1)^k¦?f(x)?+?_(n=1)^k¦?g(x)?-----Equation 6 In the above Equation 6, w0 indicates a constant failure cost; f(x) is a function indicating the total expenditure to be borne by the service provider with respect to each mode of transport for transporting the one or more passengers; g(x) is a function indicating the total time required with respect to each mode of transport for transporting the one or more passengers; k indicates the number of stranded passengers; and n indicates the total number of passengers in the distress location. In some embodiments, the objective function represents total resource utilization by the service provider. Therefore, the plan generating module 237 may generate the first optimal travel plan in accordance with the objective function i.e. the plan generating module 237 may select one of the one or more modes of transport for transporting each of the one or more passengers. In some embodiments, the first optimal travel plan thus generated in accordance with the objective function is the most optimal and effective option in terms of cost and time, for the service providers. In some embodiments, the one or more passengers may be suggested to board one or more alternate modes of transport in view of the first optimal travel plan, to reach the departure point within the departure time. Further, to generate the second optimal travel plan, the plan generating module 237 may initially detect availability of the one or more modes of transport proximal to the distress location of the one or more passengers. Further, the plan generating module 237 may generate the second optimal travel plan based on the urgency level to reach the end destination, the preference data 215 and the real-time data 217. In other words, generating the second optimal travel plan includes selecting one of the one or more modes of transport for each of the one or more passengers based on the urgency level to reach the end destination, the preference data 215 and the real-time data 217. In some embodiments, the real-time data 217 may be received or determined as explained in detail under generation of the first optimal travel plan. However, in context of the second optimal travel plan, the real-time data 217 may be determined considering the destination of the one or more passengers as the end destination instead of the departure point as considered in the first optimal travel plan. In some embodiments, when the end destination is determined to be unreachable, the destination of the one or more passengers in the context of second optimal travel plan may be one of the alternatives suggested by the plan generating module 237. Further, the plan generating module 237 may determine the objective function using the Equation 6. The plan generating module 237 may generate the first optimal travel plan in accordance with the objective function i.e. the plan generating module 237 may select one of the one or more modes of transport for transporting each of the one or more passengers. In some embodiments, the second optimal travel plan thus generated in accordance with the objective function is the most optimal and effective option in terms of cost and time, for the service providers, without compromising on the urgency level and the preference of one or more passengers. In some embodiments, the one or more passengers may be suggested to board one or more alternate modes of transport in view of the second optimal travel plan, to reach the end destination at the urgency level specified by the one or more passengers. Similarly, the plan generating module 237 may generate the third optimal travel plan. However, to generate the third optimal travel plan, the plan generating module 237 may initially detect availability of the one or more modes of transport proximal to the distress location of the one or more passengers. Further, the plan generating module 237 may generate the third optimal travel plan based on the preference data 215 and the real-time data 217. In other words, generating the third optimal travel plan includes selecting one of the one or more modes of transport for each of the one or more passengers based on the preference data 215 and the real-time data 217. In some embodiments, the real-time data 217 may be received or determined as explained in detail under generation of the first optimal travel plan. However, in context of the third optimal travel plan, the real-time data 217 would be determined considering the destination of the one or more passengers as the original ticket destination instead of the departure point as considered in the first optimal travel plan or the end destination as considered in the second optimal travel plan. Further, the plan generating module 237 may determine the objective function using the Equation 6. The plan generating module 237 may generate the third optimal travel plan in accordance with the objective function i.e. the plan generating module 237 may select one of the one or more modes of transport for transporting each of the one or more passengers. In some embodiments, the third optimal travel plan thus generated in accordance with the objective function is the most optimal and effective option in terms of cost and time, for the service providers, without compromising on the preference of one or more passengers. Further, the plan implementing module 239 may provide at least one of the first, second or the third optimal travel plan to the corresponding one or more passengers on at least one device that the one or more passengers may be using to communicate with the distress managing system 107. In some embodiments, the device may be one of the one or more data sources 105. In some embodiments, the plan implementing module 239 may also provide the suggestion of the one or more alternate modes of transport for the one or more passengers. Further, the plan implementing module 239 may request the one or more passengers to provide an approval for implementing at least one of the first, second or the third optimal travel plan. If the one or more passengers provide approval, the plan implementing module 239 may implement the at least one of the first, second or the third optimal travel plan by arranging the selected mode of transport for each of the one or more passengers based on the preference data 215. If the one or more passengers do not provide approval or reject the at least one of the first, second or the third optimal travel plan, the plan implementing module 239 may not arrange any mode of transport for such passengers. Now referring back to the intention collecting module 233, consider the scenario when the intention collecting module 233 does not receive the preference data 215 or the connecting trip data 213 from the one or more passengers. The processor 109 may detect that the one or more passengers are not able to communicate with the distress managing system 107 due to factors such as network unavailability, misplacing of user devices and the like. In such scenarios, the processor 109 may initially identify the number of passengers present in the distress location, who are not able to communicate with the distress managing system 107, using the sensor data 209. As an example, consider the vehicle 101 is configured with vision sensors that may provide details related to presence, orientation or seating of the one or more passengers in the vehicle 101. Therefore, the processor 109 may derive the exact count of the one or more passengers stuck in the transport distress situation, using the details provided by the vision sensors. When the processor 109 does not receive communication from each of the one or more passengers who are stuck in the transport distress situation i.e. when the number of communications from the one or more passengers does not match the exact count, the processor 109 may determine the number of passengers who are not be able to communicate with the distress managing system 107. Further, based on the ticket data 211 received from the ticketing means 102, the processor 109 may determine the original ticket destination of each of the one or more passengers who are not able to communicate with the distress managing system 107. Further, based on the number of passengers and the original ticket destination of the one or more passengers, the plan implementing module 239 may directly arrange one of one or more modes of transport for each of the one or more passengers to the original ticket destination (also referred as a default trip arrangement). In some embodiments, the plan implementing module 239 may arrange one of one or more modes of transport for each of the one or more passengers based on the real-time data 217. In some embodiments, the real-time data 217 may be received and also determined as explained under the first optimal travel plan. Also, the plan implementing module 239 may ensure that the one or more modes of transport are arranged in accordance with the objective function (determined using the Equation 6), thereby ensuring selection of the most optimal and cost effective option. Henceforth, the process of real-time management of a transport distress situation is explained with the help of one or more examples for better understanding of the present disclosure. However, the one or more examples should not be considered as limitation of the present disclosure. Consider an exemplary scenario where a bus with 10 passengers breaks down at 10:00AM at “XYZ” location (distress location). The passengers in the bus may communicate with the distress managing system 107 using user devices such as mobile phones to inform current situation at the distress location. The distress managing system 107 may immediately respond to collect intention of the passengers. Exemplary intentions of the passengers may be as shown in the Table 1. Passenger number Original ticket destination Connecting trip- mode of transport Connecting trip- departure point Connecting trip- departure time Grouping preference Mode of transport preference Safety preference or additional information 1 Hebbal Bus Yelahan-ka 10.25 Not Preferred Car Women traveler. 2 Bel Circle None None None Preferred Car -- 3 Manyata Tech park Train Railway station 10.55 Not preferred Car/ Bus -- ----- 10 Hennur Not available Not available Not available Not available Not available Not available Table 1 From the above Table 1, the distress managing system 107 may retrieve necessary information based on which the distress managing system 107 may generate the optimal travel plans as illustrated below. Passenger 1: Connecting trip: Yes Departure point and time: Yelahanka at 10.25AM; Reachability within the departure time: No; Therefore, request for end destination and urgency level to reach the end destination from passenger 1: Intention: End destination: Chikballapur; Urgency level: Should reach Chikaballapur by 12PM. Reachability of the End destination: Yes; Passenger 1 prefers to travel alone by car i.e. Passenger 1 does not prefer grouping. The distress managing system 107 may generate a second optimal travel plan for the Passenger 1 based on the urgency level to reach the end destination, the preference data 215 and the real-time data 217, and provide the plan to the passenger 1 for approval. Second optimal travel plan for Passenger 1: Mode of transport: Car Destination: Chikaballapur Approximate time to reach: 11.45AM Consider passenger 1 approves the second optimal travel plan. The distress managing system 107 would arrange the car for passenger 1. Also, since the Passenger 1 is a woman traveler, the distress managing system 107 may provide priority to safety and perform one or more actions such as tracking route taken by the car, avoiding routes that are isolated and the like. However, consider a scenario where the distress managing system 107 determines that the end destination is also not reachable based on the real-time data 217. In such scenarios, the distress managing system 107 may suggest alternatives to the Passenger 1. In this scenario, the exemplary alternatives for Passenger 1 may be: Dropping at a bus stand from where the Passenger 1 could board other buses to Chikaballapur (location proximal to the distress location with availability of a transport facility to reach the corresponding end destination); Dropping at Devanahalli (location proximal to the corresponding end destination). If the Passenger 1 selects anyone of the alternatives provided by the distress managing system 107, accordingly, the second optimal travel plan considering the alternative destination would be generated for the Passenger 1. Passenger 2: Connecting trip: No; Original ticket destination: BEL circle; Since passenger 1 prefers grouping and the mode of transport preferred is car, the distress managing system 107 may identify other passengers who prefer grouping and also whose destination is proximal to BEL circle to generate a third optimal travel plan for passenger 2 based on the preference data 215 and the real-time data 217. Further, the distress managing system 107 may provide the third optimal travel plan to the passenger 2 for approval. Third optimal travel plan for passenger 2: Mode of transport: Car Destination: BEL circle Approximate time to reach: 10.30AM Consider passenger 2 approves the third optimal travel plan. The distress managing system 107 would arrange the car for passenger 2. Passenger 3: Connecting trip: Yes; Departure point and time: Railway station at 10.55AM; Reachability within the departure time: Yes; Passenger 3 has preferred to travel alone by Car/Bus. The distress managing system 107 may detect preference of Passenger 3 of traveling alone by bus to be an unrealistic preference. However, since travelling alone by car is still a possible option, the distress managing system 107 may try to generate the first optimal travel plan for the passenger 3 based on the connecting trip data 213, the preference data 215 and the real-time data 217. Further, the distress managing system 107 may provide the first optimal travel plan to the passenger 3 for approval. First optimal travel plan for passenger 3: Mode of transport: Car Destination: Railway station Approximate time to reach: 10.45AM Consider passenger 3 approves the first optimal travel plan. The distress managing system 107 arranges the car for passenger 3 according to his preference of traveling alone by car. However, consider a scenario where according to the real-time data 217, arranging a car for passenger 3 to travel alone is not feasible because of the time and cost constraints. In such scenarios, the distress managing system 107 may provide a suggestion to passenger 3 to group with other passengers who are travelling along the same route, to reach the departure point before the departure time. If the passenger 3 agrees, the distress managing system 107 may check seat availability and group passenger 3 with passenger 2 in the car arranged for passenger 2. Therefore, in this way, the service provider chooses the most optimal option for transporting the one or more passengers without majorly affecting preferences of the one or more passengers. Passenger 10: Based on sensor data 209, the distress managing system 107 identifies that Passenger 10, who is also a victim of the transport distress situation, has not provided either connecting trip data 213 or the preference data 215. This may be due to network connectivity issues. Therefore, based on ticket data 211, the distress managing system 107 may determine that the original ticket destination of Passenger 10 is Hennur. Further, the distress managing system 107 arranges a default trip to the Passenger 10 to the original ticket destination i.e. Hennur, though the Passenger 10 could not communicate with the distress managing system 107. FIG.3A and FIG.3B show flowcharts illustrating a method real-time management of a transport distress situation in accordance with some embodiments of the present disclosure. As illustrated in FIG.3A and FIG.3B, the methods 300a and 300b includes one or more blocks illustrating a method of real-time management of a transport distress situation. The methods 300a and 300b may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types. The order in which the methods 300a and 300b is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the methods 300a and 300b. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods 300a and 300b can be implemented in any suitable hardware, software, firmware, or combination thereof. . At block 301a, the processor 109 of the distress managing system 107 checks whether both connecting trip data 213 and preference data 215 of one or more passengers is received on encountering the transport distress situation. In some embodiments, the connecting trip data 213 may include, but is not limited to, a departure point, a departure time and a mode of transport for a connecting trip. If the processor 109 receives both the connecting trip data 213 and the preference data 215, the method 300a proceeds to block 303a via “Yes”. If the processor 109 does not receive both the connecting trip data 213 and preference data 215, the method 300a proceeds to block 301b via “No”. At block 301b, the method 300a checks whether the processor 109 received only the preference data 215. If the processor 109 receives only the preference data 215, the method 300a proceeds to block 303b via “Yes”. If the processor 109 does not satisfy the condition, i.e. when the processor 109 does not receive either the connecting trip data 213 or the preference data 215, the method 300a proceeds to block 303c via “No”. Now referring to the method 300b illustrated in FIG.3B, at block 303a, the method 300 may include determining, by the processor 109, a possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation. If the processor 109 determines the departure point to be reachable within the departure time, the method may proceed to block 305a via “Yes”. If the processor 109 determines the departure point to be unreachable within the departure time, the method may proceed to block 305b via “No”. At block 305a, the method 300 may include generating, by the processor 109, a first optimal travel plan for the one or more passengers to reach the departure point based on the connecting trip data 213, the preference data 215 and real-time data 217, and providing the first optimal travel plan to the one or more passengers. Further, the method proceeds to block 307. At block 307, the processor 109 checks whether an approval or a rejection for the optimal travel plan (first/second/third) is received from the one or more passengers. If the processor 109 received an approval for the optimal travel plan (first/second/third), the method 300b proceeds to block 308a via “Yes”. If the processor 109 received a rejection for the first optimal travel plan (first/second/third), the method 300b proceeds to block 308b via “No”. At block 308a, the processor 109 may implement the optimal travel plan (first/second/third) by arranging the selected mode of transport for each of the one or more passengers based on the preference data 215. At block 308b, the processor 109 may assign a default trip arrangement to the one or more passengers. Where the default trip arrangement considers an original ticket destination as the destination of the one or more passengers and does not consider any preference of the one or more passengers. Now referring to block 303a, when the processor 109 determines the departure point to be unreachable within the departure time, the method may proceed to block 305b via “No”. At block 305b, the processor 109 may receive information related to an end destination and an urgency level to reach the end destination from the one or more passengers. Further, at block 309, the processor 109 may generate a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data 215 and the real-time data 217, and may provide the second optimal travel plan to the one or more passengers. Thereafter, the method proceeds to block 307. Now referring to block 301b, when the one or more passengers do not provide the connecting trip and provide only the preference data 215, then the method proceeds to block 303b. At block 303b, the processor 109 may generate a third optimal travel plan for the one or more passengers to reach the original ticket destination based on the preference data 215 and the real-time data 217. Thereafter, the method proceeds to block 307. Now referring to the condition when the one or more passengers neither provide the connecting trip data 213 nor the preference data 215, the method proceeds to block 303c. At block 303c, the processor 109 may identify the number of passengers who could not communicate with the distress managing system 107 based on sensor data 209. In some embodiments, the sensor data 209 may be received from one or more sensors 103 configured in vehicle 101. Thereafter, the method proceeds to block 308b. FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. In some embodiments, FIG.4 illustrates a block diagram of an exemplary computer system 400 for implementing embodiments consistent with the present invention. In some embodiments, the computer system 400 can be a distress managing system 107 that is used for real-time management of a transport distress situation. The computer system 400 may include a central processing unit (“CPU” or “processor”) 402. The processor 402 may include at least one data processor for executing program components for executing user or system-generated business processes. A passenger may be, a person travelling by a vehicle 101 and using a device such as those included in this invention, or such a device itself. The processor 402 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. The processor 402 may be disposed in communication with input devices 411 and output devices 412 via I/O interface 401. The I/O interface 401 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc. Using the I/O interface 401, computer system 400 may communicate with input devices 411 and output devices 412. In some embodiments, the processor 402 may be disposed in communication with a communication network 409 via a network interface 403. The network interface 403 may communicate with the communication network 409. The network interface 403 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 403 and the communication network 409, the computer system 400 may communicate with ticketing means 102, one or more sensors 103 (1031 up to 103n) and one or more data sources 105 (1051 up to 105n), for which examples are mentioned in description of FIG.1. The communication network 409 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN), Closed Area Network (CAN) and such from the vehicle 101. The communication network 409 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), CAN Protocol, Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 409 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. In some embodiments, the processor 402 may be disposed in communication with a memory 405 (e.g., RAM, ROM, etc. not shown in FIG.4) via a storage interface 404. The storage interface 404 may connect to memory 405 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc. The memory 405 may store a collection of program or database components, including, without limitation, a user interface 406, an operating system 407, a web browser 408 etc. In some embodiments, the computer system 400 may store user/application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. The operating system 407 may facilitate resource management and operation of the computer system 400. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM®OS/2®, MICROSOFT® WINDOWS® (XP®, VISTA®/7/8, 10 etc.), APPLE® IOS®, GOOGLETM ANDROIDTM, BLACKBERRY® OS, or the like. The User interface 406 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 400, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple® Macintosh® operating systems’ Aqua®, IBM® OS/2®, Microsoft® Windows® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, Java®, Javascript®, AJAX, HTML, Adobe® Flash®, etc.), or the like. In some embodiments, the computer system 400 may implement the web browser 408 stored program components. The web browser 408 may be a hypertext viewing application, such as MICROSOFT® INTERNET EXPLORER®, GOOGLETM CHROMETM, MOZILLA® FIREFOX®, APPLE® SAFARI®, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browsers 408 may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), etc. In some embodiments, the computer system 400 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as Active Server Pages (ASP), ACTIVEX®, ANSI® C++/C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 400 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, etc. Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media. Advantages of the embodiment of the present disclosure are illustrated herein. The present disclosure includes collecting the intention of the one or more passengers, that allows the distress managing system to generate an optimal travel plan according to intention and preference of the one or more passengers. Therefore, the present disclosure not only manages the transport distress situation, but manages in a way that the one or more passengers are satisfied since the intention is captured. The present disclosure collects data related to connecting trips of the one or more passengers to generate the optimal travel plan that helps the user reach departure point of the connecting trip within departure time, thereby ensuring that the transport distress situation does not affect the connecting trip of the one or more passengers. When the departure point is unreachable within the departure time, the present disclosure provides an opportunity for the one or more passengers to choose an alternate destination and to indicate urgency level to reach the alternate destination, thereby allowing the passengers to choose location of their preference. When the end destination is unreachable, the present disclosure suggests alternatives to the end destination from which the passengers can select their destination. When no option works out, the present disclosure assigns a default trip to the passengers, thus ensuring that the passengers are pulled out of the distress situation at the earliest. The present disclosure provides a feature wherein even when the passengers are not able to communicate with the distress managing system, the distress managing system identifies the passengers based on the sensor data, determines their original ticket destination based on the ticket data and then automatically assigns the default trip to the original ticket destination. This ensures that all the passengers are relieved from the distress situation without any hassle or delay even when few passengers cannot communicate with the distress managing system. The present disclosure is workable for transport distress situations related to multiple modes of transports such as road transport, rail transport, air transport and the like. Also, the present disclosure provides a feature wherein the one or more passengers can choose to travel by a mode of transport of their choice among multiple modes. The present disclosure increases transport reliability and customer patronage. Further, the present disclosure effectively addresses the issue of service continuity and passenger convenience, based on data received in real-time. Further, the present disclosure ensures safety of the passengers. Also, the present disclosure provides a feature of grouping the passengers based on destination of the passengers, that helps in transporting the passengers in the most optimal and cost-effective way. A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself. The specification has described a method and a system for real-time management of a transport distress situation. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that on-going technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims. Referral numerals Reference Number Description 100 Architecture 101 Vehicle 102 Ticketing means 103 One or more sensors 107 Distress managing system 109 Processor 111 I/O interface 113 Memory 203 Data 205 Modules 207 Distress data 209 Sensor data 211 Ticket data 213 Connecting trip data 215 Preference data 217 Real-time data 219 Other data 231 Receiving module 233 Intention collecting module 235 Reachability determining module 237 Plan generating module 239 Plan implementing module 241 Other modules 400 Exemplary computer system 401 I/O Interface of the exemplary computer system 402 Processor of the exemplary computer system 403 Network interface 404 Storage interface 405 Memory of the exemplary computer system 406 User interface 407 Operating system 408 Web browser 409 Communication network 411 Input devices 412 Output devices

Claims:1. A method for real-time management of a transport distress situation, the method comprising:
receiving, by a distress managing system (107), at least one of connecting trip data (213) and preference data (215) of one or more passengers on encountering the transport distress situation, wherein the connecting trip data (213) comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip;

determining, by the distress managing system (107), possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation; and
performing, by the distress managing system (107), one of:

generating a first optimal travel plan for the one or more passengers to reach the departure point based on the connecting trip data (213), the preference data (215) and real-time data (217) when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers; or

receiving information related to an end destination and an urgency level to reach the end destination and
generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data (215) and the real-time data (217) when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers.
2. The method as claimed in claim 1, wherein the possibility of reaching the departure point is determined based on real-time traffic data.

3. The method as claimed in claim 1 further comprises suggesting, by the distress managing system (107), alternatives to the end destination for the one or more passengers when the end destination is unreachable, wherein the alternatives comprises at least one of a location proximal to the distress location with availability of a transport facility to reach the corresponding end destination and a location proximal to the corresponding end destination, which is determined to be reachable.

4. The method as claimed in claim 1, wherein generating the first optimal travel plan and the second optimal travel plan comprises:
detecting, by the distress managing system (107), availability of one or more modes of transport proximal to the distress location of the one or more passengers; and
selecting, by the distress managing system (107), one of the one or more modes of transport for each of the one or more passengers using the real-time data (217).
5. The method as claimed in claim 4, wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or the end destination, seat availability in the one or more modes of transport and real-time traffic data.

6. The method as claimed in claim 4 further comprises implementing, by the distress managing system (107), at least one of the first or the second optimal travel plan by arranging the selected mode of transport for each of the one or more passengers based on the preference data (215), upon receiving approval from the one or more passengers for at least one of the first or the second optimal travel plan.

7. The method as claimed in claim 1 further comprises arranging, by the distress managing system (107), one of one or more modes of transport for each of the one or more passengers to reach corresponding original ticket destination based on sensor data (209), wherein the sensor data (209) is received from one or more sensors configured in a vehicle (101) associated with the transport distress situation.

8. The method as claimed in claim 7, wherein the original ticket destination of each of the one or more passengers is identified using ticket data (211) received from at least one of online and offline modes comprising an Electronic Ticketing Machine (ETM), fare collection system, mobile ticketing system and paper ticket.

9. The method as claimed in claim 1, wherein the preference data (215) comprises at least one of grouping preference, mode of transport preference and safety preference.

10. The method as claimed in claim 1 further comprises:

receiving, by the distress managing system (107), the preference data (215) of the one or more passengers in absence of the connecting trip data (213); and
generating, by the distress managing system (107), a third optimal travel plan for the one or more passengers to reach an original ticket destination based on the preference data (215) and the real-time data (217).
11. The method as claimed in claim 10, wherein generating the third optimal travel plan comprises:
detecting, by the distress managing system (107), availability of one or more modes of transport proximal to the distress location of the one or more passengers; and
selecting, by the distress managing system (107), one of the one or more modes of transport for each of the one or more passengers using the real-time data (217), wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the original ticket destination, seat availability in the one or more modes of transport and real-time traffic data.
12. A distress managing system (107) for real-time management of a transport distress situation, the distress managing system (107) comprising:
a processor (109); and
a memory (113) communicatively coupled to the processor (109), wherein the memory (113) stores the processor-executable instructions, which, on execution, causes the processor (109) to:
receive at least one of connecting trip data (213) and preference data (215) of one or more passengers on encountering the transport distress situation, wherein the connecting trip data (213) comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip;
determine possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation; and
perform one of:
generating a first optimal travel plan for the one or more passengers to reach the departure point based on the trip data, the preference data (215) and real-time data (217) when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers; or

receiving information related to an end destination and an urgency level to reach the end destination and
generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data (215) and the real-time data (217) when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers.
13. The distress managing system (107) as claimed in claim 12, wherein the processor (109) determines the possibility of reaching the departure point based on real-time traffic data.

14. The distress managing system (107) as claimed in claim 12, wherein the processor (109) is further configured to suggest alternatives to the end destination for the one or more passengers when the end destination is unreachable, wherein the alternatives comprises at least one of a location proximal to the distress location with availability of a transport facility to reach the corresponding end destination and a location proximal to the corresponding end destination, which is determined to be reachable.

15. The distress managing system (107) as claimed in claim 12, wherein to generate the first optimal travel plan and the second optimal travel plan, the processor (109) is configured to:
detect availability of one or more modes of transport proximal to the distress location of the one or more passengers; and
select one of the one or more modes of transport for each of the one or more passengers using the real-time data (217).
16. The distress managing system (107) as claimed in claim 15, wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or the end destination, seat availability in the one or more modes of transport and real-time traffic data.

17. The distress managing system (107) as claimed in claim 15, wherein the processor (109) is further configured to implement at least one of the first or the second optimal travel plan by arranging the selected mode of transport for each of the one or more passengers based on the preference data (215), upon receiving approval from the one or more passengers for at least one of the first or the second optimal travel plan.

18. The distress managing system (107) as claimed in claim 12, wherein the processor (109) is further configured to arrange one of one or more modes of transport for each of the one or more passengers to reach corresponding original ticket destination based on sensor data (209), wherein the sensor data (209) is received from one or more sensors configured in a vehicle (101) associated with the transport distress situation.

19. The distress managing system (107) as claimed in claim 18, wherein the processor (109) identifies the original ticket destination of each of the one or more passengers using ticket data (211) received from at least one of offline and online modes comprising an Electronic Ticketing Machine (ETM), a fare collection system, a mobile ticketing system and a paper ticket.

20. The distress managing system (107) as claimed in claim 12, wherein the preference data (215) comprises at least one of grouping preference, mode of transport preference and safety preference.

21. The distress managing system (107) as claimed in claim 12, wherein the processor (109) is further configured to:

receiving, by the distress managing system (107), the preference data (215) of the one or more passengers in absence of the connecting trip data (213); and
generating, by the distress managing system (107), a third optimal travel plan for the one or more passengers to reach an original ticket destination based on the preference data (215) and the real-time data (217).
22. The distress managing system (107) as claimed in claim 21, wherein to generate the third optimal travel plan, the processor (109) is configured to:
detect availability of one or more modes of transport proximal to the distress location of the one or more passengers; and
select one of the one or more modes of transport for each of the one or more passengers using the real-time data (217), wherein the real-time data (217) comprises, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the original ticket destination, seat availability in the one or more modes of transport and real-time traffic data.
, Description:TECHNICAL FIELD

The present subject matter is related, in general to field of transportation management and more particularly, but not exclusively to a method and system for real-time management of a transport distress situation.

BACKGROUND

In rural areas and metropolitan cities, there exists an enormous demand for public transport. The public transport may include, buses, trains, flights, metro and the like. On a daily basis, millions of people depend on public transport for meeting their daily travel needs. However, the public transport often faces transport distress situations such as vehicle breakdown, accidents and the like. Transport distress situations are inevitable and may disturb the schedule of people travelling by such public transport. Such transport distress situations need to be managed by arranging an alternative transport for the passengers of the public transport stuck in the transport distress situation.
Currently, the traditional way of handling the transport distress situation includes accommodating the passengers in another public transport passing along the same route. However, shifting the passengers to another public transport passing along the same route may not be convenient for the passengers. Firstly, the waiting time is undefined as the passengers have to wait until another public transport that can accommodate all the passengers arrives in that route. Secondly, undefined waiting time may disturb scheduled passenger activities. Further, the passengers may have to bear extra money in availing services of another public transport.
Few of the advanced techniques involve detecting the transport distress situation. Upon detecting the transport distress situation, the passengers of that public transport vehicle may be provided with an alternate travel advisory which advises the commuter to leave that public transport vehicle and to board another public transport vehicle. The alternate travel advisory may determine a nearest stop where the passengers can board another public transport vehicle. Though these techniques provide the alternate travel advisory that could guide the passengers to another public transport, these techniques do not solve the problem of undefined waiting period for boarding another public transport that would take them to their destination.
Further, some of the existing techniques performs pattern analysis of various passengers to understand time of their travel, preferred routes of their travel, preferred modes of transport and the like. Based on the pattern analysis, these techniques provide a prior notification to the passengers regarding a disruption in their travel route such as traffic jam, accidents, road blocks due to rain and the like, such that the passengers may avoid taking that route. Firstly, these techniques do not address the problem of managing transport distress situation in real-time, instead these techniques provide a way to avoid navigating along the routes that have encountered such transport distress situations. Also, these techniques work solely on predicted patterns of the passengers which may not be completely correct and reliable.
The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.
SUMMARY
One or more shortcomings of the prior art are overcome and additional advantages are provided through the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.
Disclosed herein is a method for real-time management of a transport distress situation, the method comprising receiving, by a distress managing system, at least one of connecting trip data and preference data of one or more passengers on encountering the transport distress situation. The connecting trip data comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip. Further, the method comprises determining possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation. Subsequently, the method comprises performing one of generating a first optimal travel plan for the one or more passengers to reach the departure point based on the connecting trip data, the preference data and real-time data when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers, or, receiving information related to an end destination and an urgency level to reach the end destination and generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data and the real-time data when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers.
Further, the present disclosure includes a distress managing system for real-time management of a transport distress situation. The distress managing system comprises a processor and a memory communicatively coupled to the processor. The memory stores the processor-executable instructions, which, on execution, causes the processor to receive at least one of connecting trip data and preference data of one or more passengers on encountering the transport distress situation. The connecting trip data comprises at least one of a departure point, a departure time and a mode of transport for a connecting trip. Further, the processor determines possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation. Subsequently, the processor performs one of generating a first optimal travel plan for the one or more passengers to reach the departure point based on the trip data, the preference data and real-time data when the departure point is reachable, and providing the first optimal travel plan to the one or more passengers, or, receiving information related to an end destination and an urgency level to reach the end destination and generating a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data and the real-time data when the departure point is unreachable, and providing the second optimal travel plan to the one or more passengers.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. 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 figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:
FIG.1 shows an exemplary architecture for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure;
FIG.2 shows a detailed block diagram of a distress managing system for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure;
FIG.3A and FIG.3B show a flowchart illustrating a method for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure; and

FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.
The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.
Disclosed herein are a method and system for real-time management of a transport distress situation. The method includes detecting a transport distress situation through one or more data sources. As an example, the transport distress situation may be any situation that involves events such as insufficiency of fuel, damage of vehicle parts, accident and the like that result in breakdown of a vehicle or immobility of the vehicle. Upon detecting the transport distress situation, a distress managing system may communicate with one or more passengers of the vehicle associated with the transport distress situation, to receive intention of the one or more passengers. In some embodiments, the intention of the one or more passengers may be related to connecting trip, end destination, urgency level, grouping preference, transport type preference, safety preference and the like. Further, the distress managing system may correlate real-time traffic data and the intention received from the one or more passengers to generate an optimal travel plan for each of the one or more passengers, in real-time, thereby managing the transport distress situation in real-time.
The present disclosure includes collecting the intention and preference of the one or more passengers based on which the distress managing system generates an optimal travel plan. Therefore, the present disclosure not only manages the transport distress situation, but manages it in a way that the one or more passengers reach their respective destinations based on their preferences and intention. Mainly, the present disclosure collects data related to connecting trip of the one or more passengers to generate the optimal travel plan that helps the user reach departure point of the connecting trip within departure time, thereby ensuring that the transport distress situation does not affect the connecting trip of the one or more passengers. In scenarios where the departure point is unreachable within the departure time, the present disclosure provides an opportunity for the one or more passengers to choose an alternate destination and also determine urgency level to reach the alternate destination. Further, the present disclosure is workable for transport distress situations related to multiple modes of transports such as road transport, rail transport, air transport and the like. Also, the present disclosure provides a feature wherein the one or more passengers can choose to travel by a mode of transport of their choice among multiple modes. The present disclosure increases transport reliability and customer patronage. Further, the present disclosure effectively addresses the issue of service continuity and passenger convenience, based on data received in real-time. Further, the present disclosure ensures safety of the passengers. Also, the present disclosure provides a feature of grouping the passengers based on destination of the passengers, that helps in transporting the passengers in the most optimal and cost-effective way.
In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

FIG.1 shows an exemplary architecture for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure.

The architecture 100 comprises a vehicle 101, a ticketing means 102, one or more sensors 103, a data source 1 1051 to a data source n 105n (collectively referred to as one or more data sources 105) and a distress managing system 107. The one or more data sources 105 may provide data related to a transport distress situation (also referred as distress data) and real-time data. As an example, the one or more data sources 105 may include, but are not limited to, a device used by one or more passengers to communicate with the distress managing system 107 through a voice call, voice message, a mobile application, a text message and the like, a wired or a wireless communication module configured in the vehicle 101, social networking sites and a control centre. In some embodiments, the one or more sensors 103 may also be a part of the one or more data sources 105. As an example, the one or more sensors 103 may include, but are not limited to, image sensors, vision sensors, pressure sensors, occupancy detection sensors and foot board sensors. The one or more sensors 103 may be configured in the vehicle 101. Further, the ticketing means 102 may be associated with the vehicle 101 for issuing journey related tickets for one or more passengers of the vehicle 101. In some embodiments, the ticketing means 102 may operate either in an online mode or an offline mode. As an example, the ticketing means 102 may include, but are not limited to, Electronic Ticketing Machine (ETM), a fare collection system, a mobile ticketing system and a paper ticket. In some embodiments, the ticketing means 102, the one or more sensors 103 and the one or more data sources 105 may communicate with the distress managing system 107 via a communication network (not shown in the FIG.1). The communication network may be a wired communication network, a wireless communication network and a combination of both wired and wireless communication network.
The distress managing system 107 comprises a processor 109, an Input/output (I/O) interface 111 and a memory 113. In an embodiment, the I/O interface 111 may receive data related to the transport distress situation from the one or more data sources 105 that may be operated by the one or more passengers. As an example, data related to the transport distress situation may include location where the transport distress situation occurred (also referred as distress location), details of vehicle 101 associated with the transport distress situation such as vehicle number, type of vehicle and the like, reason for the transport distress situation, approximate count of the passengers, time at which the transport distress situation occurred and the like. Further, the I/O interface 111 may receive ticket data from the ticketing means 102 configured in the vehicle 101. As an example, the ticket data may include boarding location of the passenger, destination of the passenger, cost of the ticket, time when the ticket is issued, seat number and the like. Furthermore, the I/O interface 111 may receive sensor data from the one or more sensors 103 configured in the vehicle 101. As an example, the sensor data may include images of the one or more passengers, count of the one or more passengers, seat occupancy by the one or more passengers and the like. Further, the I/O interface 111 may also receive the real-time data. In some embodiments, the real-time data may be collected from one or more data sources 105 or may be determined by the processor 109. In some embodiments, the real-time data may include, but not limited to, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of a departure point or an end destination, seat availability in the one or more modes of transport and real-time traffic data.
Upon receiving data related to the transport distress situation, the processor 109 may request the one or more passengers who have encountered the transport distress situation to provide at least one of connecting trip data and preference data. In some embodiments, the connecting trip data may be provided by the one or more passengers who have a scheduled connecting trip which may be affected due to the encounter of the transport distress situation. The connecting trip data may include, but is not limited to, a departure point, a departure time and a mode of transport for the connecting trip. Further, the preference data may be related to preferences of the one or more passengers. The preference data may include, but is not limited to, grouping preference, mode of transport preference and safety preference.
Upon receiving the connecting trip data, the processor 109 may determine possibility of reaching the departure point, within the departure time, from the distress location of the one or more passengers in the transport distress situation. In some embodiments, the distress managing system 107 may use real-time traffic data to determine the reachability. If the departure point is reachable within the departure time, the processor 109 may generate a first optimal travel plan for the one or more passengers to reach the departure point.
If the departure point is not reachable within the departure time, then the processor 109 may request the one or more passengers to provide an end destination and urgency level to reach the end destination. In some embodiments, the end destination may be an alternative destination provided by the one or more passengers when the departure point is unreachable. Further, the processor 109 may determine whether the end destination is reachable or not. If the end destination is reachable, the processor 109 may generate a second optimal travel plan for the one or more passengers to reach the end destination. In some scenarios, if the end destination is not reachable, the processor 109 may suggest alternatives to the end destination for the one or more passengers.
Further, in some scenarios where the one or more passengers do not have a connecting trip, the processor 109 may generate a third optimal travel plan for the one or more passengers to reach an original ticket destination (destination indicated by the ticket issued by the ticketing means 102).
However, in some scenarios, the one or more passengers may not be able to communicate with distress managing system 107 due to factors such as network unavailability, misplacing of user devices and the like. In such scenarios, the processor 109 may arrange one of one or more modes of transport for each of the one or more passengers to the original ticket destination (also referred as a default trip arrangement). In some embodiments, the processor 109 may identify the one or more passengers unable to communicate with the distress managing system 107 using the sensor data.
Finally, the processor 109 may arrange one of the one or more modes of transport for each of the one or more passengers in accordance with either the first optimal travel plan, the second optimal travel plan, the third optimal travel plan or the default trip to corresponding destinations.
FIG.2 shows a detailed block diagram of a distress managing system for real-time management of a transport distress situation in accordance with some embodiments of the present disclosure.
In some implementations, the distress managing system 107 may include data 203 and modules 205. As an example, the data 203 is stored in the memory 113 configured in the distress managing system 107 as shown in the FIG.2. In one embodiment, the data 203 may include distress data 207, sensor data 209, ticket data 211, connecting trip data 213, preference data 215, real-time data 217 and other data 219. In the illustrated FIG.2, modules 205 are described herein in detail.

In some embodiments, the data 203 may be stored in the memory 113 in form of various data structures. Additionally, the data 203 can be organized using data models, such as relational or hierarchical data models.
In some embodiments, the distress data 207 may be data related to the transport distress situation received from one or more data sources 105. The distress data 207 may include, but is not limited to, location where the transport distress situation occurred (also referred as distress location), details of a vehicle 101 associated with the transport distress situation such as vehicle number, type of vehicle and the like, reason for the transport distress situation, approximate count of passengers, time at which the transport distress situation occurred and the like.
In some embodiments, the sensor data 209 may be data received from one or more sensors 103 configured in the vehicle 101. The sensor data 209 may include, but is not limited to, images of the one or more passengers, count of the one or more passengers and seat occupancy by the one or more passengers.
In some embodiments, the ticket data 211 may be data related to ticket issued to one or more passengers boarding the vehicle 101, using ticketing means 102 associated with the vehicle 101. The ticket data 211 may include, but is not limited to, boarding location of the passenger, destination of the passenger (also referred as original ticket destination), cost of the ticket, time when the ticket is issued and the seat number.
In some embodiments, the connecting trip data 213 may be related to a connecting trip of the one or more passengers, which is pre-scheduled. As an example, consider a passenger boards a bus, whose original ticket destination is railway station. The passenger may have a trip scheduled from railway station to another destination (end destination), for example “Chennai”. Therefore, such trips which are pre-scheduled may be referred as the connecting trips of the one or more passengers. The connecting trip data 213 may include, but is not limited to, a departure point, a departure time and a mode of transport for the connecting trip. In the above mentioned example, the mode of transport for the connecting trip is rail transport.
In some embodiments, the preference data 215 may indicate preferences of the one or more passengers. In some embodiments, the preferences may be related to transportation of the one or more passengers from the distress location when the one or more passengers encounter the transport distress situation. The preference data 215 may include, but is not limited to, grouping preference, mode of transport preference and safety preference. In some embodiments, the grouping preference may indicate whether a passenger wishes to be grouped with other passengers at the distress location. In some embodiments, the mode of transport preference may indicate the mode through which the passenger wishes to travel from the distress location. In some embodiments, the safety preference may indicate level of safety required, for example, the passenger may select a level from a scale of 1 to 10. As an example, when the passenger is a woman, the safety preference may be between 8-10 indicating that the passenger has set safety as the highest priority during the travel. In some embodiments, the preference data 215 may also include miscellaneous/additional information such as gender of the passenger, time constraints of the passenger and the like.
In some embodiments, the real-time data 217 may indicate data collected or determined in real-time to generate optimal travel plan for each of the one or more passengers. In some embodiments, the real-time data 217 may be collected from the one or more data sources 105. The real-time data 217 may include, but is not limited to, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or an end destination, seat availability in the one or more modes of transport and real-time traffic data.
In some embodiments, the other data 219 may store data, including temporary data and temporary files, generated by the modules 205 for performing the various functions of the distress managing system 107. In some embodiments, the end destination and urgency level to reach the end destination, provided by the one or more passengers having pre-scheduled connecting trips, may be stored as part of the temporary data.
In some embodiments, the data 203 stored in the memory 113 may be processed by the modules 205 of the distress managing system 107. The modules 205 may be stored within the memory 113. In an example, the modules 205 communicatively coupled to the processor 109 configured in the distress managing system 107, may also be present outside the memory 113 as shown in FIG.2 and implemented as hardware. As used herein, the term modules refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
In an embodiment, the modules 205 may include, for example, a receiving module 231, an intention collecting module 233, a reachability determining module 235, a plan generating module 237, a plan implementing module 239 and other modules 241. The other modules 241 may be used to perform various miscellaneous functionalities of the distress managing system 107. It will be appreciated that such aforementioned modules 205 may be represented as a single module or a combination of different modules.
In some embodiments, the receiving module 231 may receive distress data 207 from the one or more data sources 105. As an example, the one or more data sources 105 may include, but are not limited to, a user device wherein the one or more passengers may communicate via a voice call, voice message, a mobile application, a text message and the like, a wired or a wireless communication module configured in the vehicle 101, social networking websites and a control centre. Further, the receiving module 231 may receive the sensor data 209 and the ticket data 211 from the one or more sensors 103 and the ticketing means 102 respectively. As an example, the one or more sensors 103 may include, but are not limited to, image sensors, vision sensors, pressure sensors, occupancy detection sensors and foot board sensors. As an example, the ticketing means 102 may include, but are not limited to, Electronic Ticketing Machine (ETM), a fare collection system, a mobile ticketing system and a paper ticket. In some embodiments, the ticketing means 102 may operate either in an online mode or an offline mode.
In some embodiments, the intention collecting module 233 may request the one or more passengers to provide at least one of the connecting trip data 213 and the preference data 215. In some embodiments, the intention collecting module 233 may receive both the connecting trip data 213 and the preference data 215 from the one or more passengers who have a pre-scheduled connecting trip which may be affected due to the encounter of the transport distress situation. In an alternate embodiment, when the one or more passengers do not have a pre-scheduled connecting trip, the intention collecting module 233 may receive only the preference data 215 to reach the original ticket destination from the distress location.
When the intention collecting module 233 receives both the connecting trip data 213 and the preference data 215 from the one or more passengers, the processor 109 may activate the reachability determining module 235.
In some embodiments, the reachability determining module 235 may determine reachability of the one or more passengers to a given location. In the current scenario, the reachability determining module 235 may determine possibility of reaching the departure point within the departure time from the distress location. In some embodiments, the distress managing system 107 may use real-time traffic data to determine the reachability to the departure point. When the reachability determining module 235 determines that the departure point is reachable within the departure time, the processor 109 may activate a plan generating module 237 to generate a first optimal travel plan for the one or more passengers. When the reachability determining module 235 determines that the departure point is not reachable within the departure time, the intention collecting module 233 may request the one or more passengers to provide the end destination and urgency level to reach the end destination.
In some embodiments, the end destination may be any alternative destination that the one or more passengers would select, when the departure point is determined to be unreachable. In some embodiments, the end destination may be the original ticket destination. The urgency level may indicate how quickly the one or more passengers want to reach the end destination. Upon receiving the end destination and the urgency level, the reachability determining module 235 may determine whether the end destination is reachable as per the urgency level intended by the one or more passengers. In some embodiments, when the reachability determining module 235 determines the end destination to be reachable, the processor 109 may activate the plan generating module 237 to generate a second optimal travel plan for the one or more passengers.
In some embodiments, when both the departure point and the end destination are determined to be unreachable, the reachability determining module 235 may suggest alternatives to the end destination for the one or more passengers. In a non-limiting embodiment, the alternatives may include suggesting a location proximal to the distress location with availability of a transport facility to reach the corresponding end destination. In another non-limiting embodiment, the alternatives may include a location proximal to the corresponding end destination, which the reachability determining module 235 may determine as reachable. If the one or more passengers select one of the suggested alternatives, the plan generating module 237 may generate a suitable optimal travel plan to reach the selected alternative.
In some embodiments, when the intention collecting module 233 initially receives only the preference data 215 from the one or more passengers and not the connecting trip data 213, the processor 109 may activate the plan generating module 237 to generate a third optimal travel plan. In some embodiments, the third optimal travel plan may be generated to transport the one or more passengers to respective original ticket destinations, when the one or more passengers do not have a connecting trip.
In some embodiments, the plan generating module 237 may generate the optimal travel plans for the one or more passengers as discussed below.
In some embodiments, for generating the first optimal travel plan, the plan generating module 237 may initially detect availability of one or more modes of transport proximal to the distress location of the one or more passengers. Further, the plan generating module 237 may generate the first optimal travel plan based on the connecting trip data 213, the preference data 215 and the real-time data 217. In other words, generating the first optimal travel plan includes selecting one of the one or more modes of transport for each of the one or more passengers based on the connecting trip data 213, the preference data 215, the real-time data 217. In some embodiments, the plan generating module 237 may receive or determine the real-time data 217 to generate optimal travel plan for each of the one or more passengers. In some embodiments, the plan generating module 237 may determine the real-time data 217 using the preference data 215 and destination of the one or more passengers. As an example, the destination may be the departure point, the end destination, the original ticket destination or an alternative. In the context of the first optimal travel plan, the destination of the one or more passengers used for determining the real-time data 217 may be the departure point.
The real-time data 217 may include, but is not limited to, distance from each of the one or more modes of transport to the distress location, time and expenditure of each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to at least one of the departure point or an end destination, seat availability in the one or more modes of transport and real-time traffic data.
In some embodiments, the plan generating module 237 may determine the distance from each of the one or more modes of transport to the distress location based on current location of the one or more modes of transport, using a pre-existing navigation application. As an example, the pre-existing navigation application may be, but is not limited to, GoogleTM Maps. In some embodiments, plan generating module 237 may determine the time required for each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the departure point (also referred as total time to reach the destination) using the below Equation 1.
g(t)=b_0+T(?)*y -------------------- Equation 1
In the above Equation 1,
g(t) indicates the total time to reach the destination;
b0 indicates a constant failure cost;
T(i) indicates traffic density at a given instance. The plan generating module 237 may derive traffic density from the real-time traffic data received from traffic data sources such as navigation applications, road sensors, vehicle surveillance device and the like; and
y indicates distance from the one or more modes of transport to the distress location.

Alternatively, the plan generating module 237 may determine the total time to reach the destination using the below Equation 2.
g(t)=z_1+z_2 -------------------- Equation 2
In the above Equation 2,
g(t) indicates the total time to reach the destination;
z1 indicates time required for each of the one or more modes of transport to reach the distress location; and
z2 indicates time required to transport the one or more passengers to the destination.

Further, the plan generating module 237 may determine expenditure for each of the one or more modes of transport to reach the distress location and to transport the one or more passengers to the departure point (also referred as total expenditure to be borne for each of the one or more passengers by service provider associated with the vehicle 101, who is operating the distress managing system 107) using the below Equation 3.
f(c)=a_0+per Km_tt*P_k ---------------- Equation 3
In the above Equation 3,
f(c) indicates the total expenditure to reach the destination;
a0 indicates a constant failure cost;
Per Kmtt indicates cost per kilometre based on transport type (tt); and
Pk indicates number of kilometres each passenger would travel from the distress location, where k indicates the number of stranded passengers in the distress location.

Alternatively, the plan generating module 237 may determine the total expenditure to reach the destination using the below Equation 4.
f(c)=x_1+x_2 -------------------- Equation 4
In the above Equation 4,
f(c) indicates the total expenditure to reach the destination;
x1 indicates cost for each of the one or more modes of transport to reach the distress location; and
x2 indicates cost for transporting each of the one or more passengers to the destination.

In some embodiments, when the one or more passengers travel in a group, the total expenditure to reach the destination may be determined using the below Equation 5.

f(c)=a_0+per Km_tt ?*S?_0^n P_k/P_gm ---------------- Equation 5
In the above Equation 5,
f(c) indicates the total expenditure to reach the destination;
a0 indicates a constant failure cost;
Per Kmtt indicates cost per kilometre based on transport type (tt);
Pk indicates number of kilometres each passenger would travel from the distress location, where k indicates the number of stranded passengers in the distress location;
Pgm indicates number of passengers travelling in the group; and
n indicates total number of passengers in the distress location.

In some embodiments, the total expenditure to reach the destination for each of the one or more passengers may vary depending upon the preference data 215. Consider a passenger has preferred “car” as the mode of transport and wishes to travel alone i.e. group preference is not selected In such scenario, the total expenditure that the service provider should bear to transport the passenger to the destination may be high when compared to the total expenditure in the case where the passengers have preferred to travel in a group.
In some embodiments, when the one or more passengers have preferred to travel in a group i.e. when the group preference of the one or more passengers is “preferred”, the plan generating module 237 may consider the following conditions or factors while grouping the one or more passengers, that makes the grouping process efficient when compared to the process of grouping existing in the art:
Grouping is performed based on destination of the one or more passengers and not the origin, since the origin location is the distress location and is same for each of the one or more passengers.
Grouping is performed in a way that most optimal and a cost-effective option is determined for transportation without affecting the preferences of the one or more passengers.
In some scenarios, grouping may be performed when the one or more modes of transport preferred by one or more passengers are unavailable or when the time for the one or more modes of transport to reach the distress location has exceeded a predefined threshold.
When the grouping preference of the one or more passengers is unrealistic or highly expensive, the plan generating module 237 may reject such preference and group the one or more passengers with other passengers in a cost-effective manner. As an example, when a passenger prefers to travel individually in a bus, the preference may be unrealistic. Similarly, when the mode of transport preference is unrealistic, the plan generating module 237 may reject such preference and suggest an alternate mode of transport. In some embodiments, the plan generating module 237 may group the passenger corresponding to the unrealistic preference with other passengers in a cost-effective manner. As an example, when the passenger’s preference includes make and model of a car to travel, which is extremely expensive, the preference may be termed as unrealistic.
Grouping may also be performed based on the safety preference of the one or more passengers. As an example, when the safety scale is high, the plan generating module 237 may group the passenger with other passengers instead of individually transporting the passenger to the destination.
In some embodiments, selecting an optimal and the cost-effective option may be based on an objective function determined by the plan generating module 237 using the below Equation 6.
objective function=w_0+ ?_(n=1)^k¦?f(x)?+?_(n=1)^k¦?g(x)?-----Equation 6
In the above Equation 6,

w0 indicates a constant failure cost;
f(x) is a function indicating the total expenditure to be borne by the service provider with respect to each mode of transport for transporting the one or more passengers;
g(x) is a function indicating the total time required with respect to each mode of transport for transporting the one or more passengers;
k indicates the number of stranded passengers; and
n indicates the total number of passengers in the distress location.

In some embodiments, the objective function represents total resource utilization by the service provider. Therefore, the plan generating module 237 may generate the first optimal travel plan in accordance with the objective function i.e. the plan generating module 237 may select one of the one or more modes of transport for transporting each of the one or more passengers. In some embodiments, the first optimal travel plan thus generated in accordance with the objective function is the most optimal and effective option in terms of cost and time, for the service providers. In some embodiments, the one or more passengers may be suggested to board one or more alternate modes of transport in view of the first optimal travel plan, to reach the departure point within the departure time.

Further, to generate the second optimal travel plan, the plan generating module 237 may initially detect availability of the one or more modes of transport proximal to the distress location of the one or more passengers. Further, the plan generating module 237 may generate the second optimal travel plan based on the urgency level to reach the end destination, the preference data 215 and the real-time data 217. In other words, generating the second optimal travel plan includes selecting one of the one or more modes of transport for each of the one or more passengers based on the urgency level to reach the end destination, the preference data 215 and the real-time data 217.

In some embodiments, the real-time data 217 may be received or determined as explained in detail under generation of the first optimal travel plan. However, in context of the second optimal travel plan, the real-time data 217 may be determined considering the destination of the one or more passengers as the end destination instead of the departure point as considered in the first optimal travel plan. In some embodiments, when the end destination is determined to be unreachable, the destination of the one or more passengers in the context of second optimal travel plan may be one of the alternatives suggested by the plan generating module 237.

Further, the plan generating module 237 may determine the objective function using the Equation 6. The plan generating module 237 may generate the first optimal travel plan in accordance with the objective function i.e. the plan generating module 237 may select one of the one or more modes of transport for transporting each of the one or more passengers. In some embodiments, the second optimal travel plan thus generated in accordance with the objective function is the most optimal and effective option in terms of cost and time, for the service providers, without compromising on the urgency level and the preference of one or more passengers. In some embodiments, the one or more passengers may be suggested to board one or more alternate modes of transport in view of the second optimal travel plan, to reach the end destination at the urgency level specified by the one or more passengers.

Similarly, the plan generating module 237 may generate the third optimal travel plan. However, to generate the third optimal travel plan, the plan generating module 237 may initially detect availability of the one or more modes of transport proximal to the distress location of the one or more passengers. Further, the plan generating module 237 may generate the third optimal travel plan based on the preference data 215 and the real-time data 217. In other words, generating the third optimal travel plan includes selecting one of the one or more modes of transport for each of the one or more passengers based on the preference data 215 and the real-time data 217.

In some embodiments, the real-time data 217 may be received or determined as explained in detail under generation of the first optimal travel plan. However, in context of the third optimal travel plan, the real-time data 217 would be determined considering the destination of the one or more passengers as the original ticket destination instead of the departure point as considered in the first optimal travel plan or the end destination as considered in the second optimal travel plan.

Further, the plan generating module 237 may determine the objective function using the Equation 6. The plan generating module 237 may generate the third optimal travel plan in accordance with the objective function i.e. the plan generating module 237 may select one of the one or more modes of transport for transporting each of the one or more passengers. In some embodiments, the third optimal travel plan thus generated in accordance with the objective function is the most optimal and effective option in terms of cost and time, for the service providers, without compromising on the preference of one or more passengers.

Further, the plan implementing module 239 may provide at least one of the first, second or the third optimal travel plan to the corresponding one or more passengers on at least one device that the one or more passengers may be using to communicate with the distress managing system 107. In some embodiments, the device may be one of the one or more data sources 105. In some embodiments, the plan implementing module 239 may also provide the suggestion of the one or more alternate modes of transport for the one or more passengers. Further, the plan implementing module 239 may request the one or more passengers to provide an approval for implementing at least one of the first, second or the third optimal travel plan. If the one or more passengers provide approval, the plan implementing module 239 may implement the at least one of the first, second or the third optimal travel plan by arranging the selected mode of transport for each of the one or more passengers based on the preference data 215. If the one or more passengers do not provide approval or reject the at least one of the first, second or the third optimal travel plan, the plan implementing module 239 may not arrange any mode of transport for such passengers.

Now referring back to the intention collecting module 233, consider the scenario when the intention collecting module 233 does not receive the preference data 215 or the connecting trip data 213 from the one or more passengers. The processor 109 may detect that the one or more passengers are not able to communicate with the distress managing system 107 due to factors such as network unavailability, misplacing of user devices and the like. In such scenarios, the processor 109 may initially identify the number of passengers present in the distress location, who are not able to communicate with the distress managing system 107, using the sensor data 209. As an example, consider the vehicle 101 is configured with vision sensors that may provide details related to presence, orientation or seating of the one or more passengers in the vehicle 101. Therefore, the processor 109 may derive the exact count of the one or more passengers stuck in the transport distress situation, using the details provided by the vision sensors. When the processor 109 does not receive communication from each of the one or more passengers who are stuck in the transport distress situation i.e. when the number of communications from the one or more passengers does not match the exact count, the processor 109 may determine the number of passengers who are not be able to communicate with the distress managing system 107. Further, based on the ticket data 211 received from the ticketing means 102, the processor 109 may determine the original ticket destination of each of the one or more passengers who are not able to communicate with the distress managing system 107. Further, based on the number of passengers and the original ticket destination of the one or more passengers, the plan implementing module 239 may directly arrange one of one or more modes of transport for each of the one or more passengers to the original ticket destination (also referred as a default trip arrangement). In some embodiments, the plan implementing module 239 may arrange one of one or more modes of transport for each of the one or more passengers based on the real-time data 217. In some embodiments, the real-time data 217 may be received and also determined as explained under the first optimal travel plan. Also, the plan implementing module 239 may ensure that the one or more modes of transport are arranged in accordance with the objective function (determined using the Equation 6), thereby ensuring selection of the most optimal and cost effective option.
Henceforth, the process of real-time management of a transport distress situation is explained with the help of one or more examples for better understanding of the present disclosure. However, the one or more examples should not be considered as limitation of the present disclosure.
Consider an exemplary scenario where a bus with 10 passengers breaks down at 10:00AM at “XYZ” location (distress location). The passengers in the bus may communicate with the distress managing system 107 using user devices such as mobile phones to inform current situation at the distress location. The distress managing system 107 may immediately respond to collect intention of the passengers. Exemplary intentions of the passengers may be as shown in the Table 1.
Passenger number Original ticket destination Connecting trip- mode of transport Connecting trip- departure point Connecting trip- departure time Grouping preference Mode of transport preference Safety preference or additional information
1 Hebbal Bus Yelahan-ka 10.25 Not Preferred Car Women traveler.
2 Bel Circle None None None Preferred Car --
3 Manyata Tech park Train Railway station 10.55 Not preferred Car/
Bus --
-----
10 Hennur Not available Not available Not available Not available Not available Not available

Table 1
From the above Table 1, the distress managing system 107 may retrieve necessary information based on which the distress managing system 107 may generate the optimal travel plans as illustrated below.
Passenger 1:
Connecting trip: Yes
Departure point and time: Yelahanka at 10.25AM;
Reachability within the departure time: No;
Therefore, request for end destination and urgency level to reach the end destination from passenger 1:

Intention: End destination: Chikballapur;
Urgency level: Should reach Chikaballapur by 12PM.

Reachability of the End destination: Yes;
Passenger 1 prefers to travel alone by car i.e. Passenger 1 does not prefer grouping. The distress managing system 107 may generate a second optimal travel plan for the Passenger 1 based on the urgency level to reach the end destination, the preference data 215 and the real-time data 217, and provide the plan to the passenger 1 for approval.

Second optimal travel plan for Passenger 1:
Mode of transport: Car
Destination: Chikaballapur
Approximate time to reach: 11.45AM

Consider passenger 1 approves the second optimal travel plan. The distress managing system 107 would arrange the car for passenger 1. Also, since the Passenger 1 is a woman traveler, the distress managing system 107 may provide priority to safety and perform one or more actions such as tracking route taken by the car, avoiding routes that are isolated and the like.

However, consider a scenario where the distress managing system 107 determines that the end destination is also not reachable based on the real-time data 217. In such scenarios, the distress managing system 107 may suggest alternatives to the Passenger 1.

In this scenario, the exemplary alternatives for Passenger 1 may be:
Dropping at a bus stand from where the Passenger 1 could board other buses to Chikaballapur (location proximal to the distress location with availability of a transport facility to reach the corresponding end destination);
Dropping at Devanahalli (location proximal to the corresponding end destination).
If the Passenger 1 selects anyone of the alternatives provided by the distress managing system 107, accordingly, the second optimal travel plan considering the alternative destination would be generated for the Passenger 1.
Passenger 2:

Connecting trip: No;
Original ticket destination: BEL circle;
Since passenger 1 prefers grouping and the mode of transport preferred is car, the distress managing system 107 may identify other passengers who prefer grouping and also whose destination is proximal to BEL circle to generate a third optimal travel plan for passenger 2 based on the preference data 215 and the real-time data 217. Further, the distress managing system 107 may provide the third optimal travel plan to the passenger 2 for approval.
Third optimal travel plan for passenger 2:
Mode of transport: Car
Destination: BEL circle
Approximate time to reach: 10.30AM

Consider passenger 2 approves the third optimal travel plan. The distress managing system 107 would arrange the car for passenger 2.

Passenger 3:
Connecting trip: Yes;
Departure point and time: Railway station at 10.55AM;
Reachability within the departure time: Yes;
Passenger 3 has preferred to travel alone by Car/Bus.

The distress managing system 107 may detect preference of Passenger 3 of traveling alone by bus to be an unrealistic preference. However, since travelling alone by car is still a possible option, the distress managing system 107 may try to generate the first optimal travel plan for the passenger 3 based on the connecting trip data 213, the preference data 215 and the real-time data 217. Further, the distress managing system 107 may provide the first optimal travel plan to the passenger 3 for approval.

First optimal travel plan for passenger 3:
Mode of transport: Car
Destination: Railway station
Approximate time to reach: 10.45AM

Consider passenger 3 approves the first optimal travel plan. The distress managing system 107 arranges the car for passenger 3 according to his preference of traveling alone by car.

However, consider a scenario where according to the real-time data 217, arranging a car for passenger 3 to travel alone is not feasible because of the time and cost constraints. In such scenarios, the distress managing system 107 may provide a suggestion to passenger 3 to group with other passengers who are travelling along the same route, to reach the departure point before the departure time. If the passenger 3 agrees, the distress managing system 107 may check seat availability and group passenger 3 with passenger 2 in the car arranged for passenger 2.
Therefore, in this way, the service provider chooses the most optimal option for transporting the one or more passengers without majorly affecting preferences of the one or more passengers.

Passenger 10:

Based on sensor data 209, the distress managing system 107 identifies that Passenger 10, who is also a victim of the transport distress situation, has not provided either connecting trip data 213 or the preference data 215. This may be due to network connectivity issues. Therefore, based on ticket data 211, the distress managing system 107 may determine that the original ticket destination of Passenger 10 is Hennur. Further, the distress managing system 107 arranges a default trip to the Passenger 10 to the original ticket destination i.e. Hennur, though the Passenger 10 could not communicate with the distress managing system 107.
FIG.3A and FIG.3B show flowcharts illustrating a method real-time management of a transport distress situation in accordance with some embodiments of the present disclosure.
As illustrated in FIG.3A and FIG.3B, the methods 300a and 300b includes one or more blocks illustrating a method of real-time management of a transport distress situation. The methods 300a and 300b may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types.
The order in which the methods 300a and 300b is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the methods 300a and 300b. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods 300a and 300b can be implemented in any suitable hardware, software, firmware, or combination thereof.
. At block 301a, the processor 109 of the distress managing system 107 checks whether both connecting trip data 213 and preference data 215 of one or more passengers is received on encountering the transport distress situation. In some embodiments, the connecting trip data 213 may include, but is not limited to, a departure point, a departure time and a mode of transport for a connecting trip. If the processor 109 receives both the connecting trip data 213 and the preference data 215, the method 300a proceeds to block 303a via “Yes”. If the processor 109 does not receive both the connecting trip data 213 and preference data 215, the method 300a proceeds to block 301b via “No”.
At block 301b, the method 300a checks whether the processor 109 received only the preference data 215. If the processor 109 receives only the preference data 215, the method 300a proceeds to block 303b via “Yes”. If the processor 109 does not satisfy the condition, i.e. when the processor 109 does not receive either the connecting trip data 213 or the preference data 215, the method 300a proceeds to block 303c via “No”. Now referring to the method 300b illustrated in FIG.3B, at block 303a, the method 300 may include determining, by the processor 109, a possibility of reaching the departure point within the departure time from a distress location of the one or more passengers in the transport distress situation. If the processor 109 determines the departure point to be reachable within the departure time, the method may proceed to block 305a via “Yes”. If the processor 109 determines the departure point to be unreachable within the departure time, the method may proceed to block 305b via “No”.
At block 305a, the method 300 may include generating, by the processor 109, a first optimal travel plan for the one or more passengers to reach the departure point based on the connecting trip data 213, the preference data 215 and real-time data 217, and providing the first optimal travel plan to the one or more passengers. Further, the method proceeds to block 307.
At block 307, the processor 109 checks whether an approval or a rejection for the optimal travel plan (first/second/third) is received from the one or more passengers. If the processor 109 received an approval for the optimal travel plan (first/second/third), the method 300b proceeds to block 308a via “Yes”. If the processor 109 received a rejection for the first optimal travel plan (first/second/third), the method 300b proceeds to block 308b via “No”.
At block 308a, the processor 109 may implement the optimal travel plan (first/second/third) by arranging the selected mode of transport for each of the one or more passengers based on the preference data 215.
At block 308b, the processor 109 may assign a default trip arrangement to the one or more passengers. Where the default trip arrangement considers an original ticket destination as the destination of the one or more passengers and does not consider any preference of the one or more passengers.
Now referring to block 303a, when the processor 109 determines the departure point to be unreachable within the departure time, the method may proceed to block 305b via “No”. At block 305b, the processor 109 may receive information related to an end destination and an urgency level to reach the end destination from the one or more passengers. Further, at block 309, the processor 109 may generate a second optimal travel plan for the one or more passengers to reach the end destination based on the urgency level, the preference data 215 and the real-time data 217, and may provide the second optimal travel plan to the one or more passengers. Thereafter, the method proceeds to block 307.
Now referring to block 301b, when the one or more passengers do not provide the connecting trip and provide only the preference data 215, then the method proceeds to block 303b. At block 303b, the processor 109 may generate a third optimal travel plan for the one or more passengers to reach the original ticket destination based on the preference data 215 and the real-time data 217. Thereafter, the method proceeds to block 307.
Now referring to the condition when the one or more passengers neither provide the connecting trip data 213 nor the preference data 215, the method proceeds to block 303c. At block 303c, the processor 109 may identify the number of passengers who could not communicate with the distress managing system 107 based on sensor data 209. In some embodiments, the sensor data 209 may be received from one or more sensors 103 configured in vehicle 101. Thereafter, the method proceeds to block 308b.
FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.
In some embodiments, FIG.4 illustrates a block diagram of an exemplary computer system 400 for implementing embodiments consistent with the present invention. In some embodiments, the computer system 400 can be a distress managing system 107 that is used for real-time management of a transport distress situation. The computer system 400 may include a central processing unit (“CPU” or “processor”) 402. The processor 402 may include at least one data processor for executing program components for executing user or system-generated business processes. A passenger may be, a person travelling by a vehicle 101 and using a device such as those included in this invention, or such a device itself. The processor 402 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.
The processor 402 may be disposed in communication with input devices 411 and output devices 412 via I/O interface 401. The I/O interface 401 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc.
Using the I/O interface 401, computer system 400 may communicate with input devices 411 and output devices 412.
In some embodiments, the processor 402 may be disposed in communication with a communication network 409 via a network interface 403. The network interface 403 may communicate with the communication network 409. The network interface 403 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 403 and the communication network 409, the computer system 400 may communicate with ticketing means 102, one or more sensors 103 (1031 up to 103n) and one or more data sources 105 (1051 up to 105n), for which examples are mentioned in description of FIG.1. The communication network 409 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN), Closed Area Network (CAN) and such from the vehicle 101. The communication network 409 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), CAN Protocol, Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 409 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. In some embodiments, the processor 402 may be disposed in communication with a memory 405 (e.g., RAM, ROM, etc. not shown in FIG.4) via a storage interface 404. The storage interface 404 may connect to memory 405 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.
The memory 405 may store a collection of program or database components, including, without limitation, a user interface 406, an operating system 407, a web browser 408 etc. In some embodiments, the computer system 400 may store user/application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase.
The operating system 407 may facilitate resource management and operation of the computer system 400. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM®OS/2®, MICROSOFT® WINDOWS® (XP®, VISTA®/7/8, 10 etc.), APPLE® IOS®, GOOGLETM ANDROIDTM, BLACKBERRY® OS, or the like. The User interface 406 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 400, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple® Macintosh® operating systems’ Aqua®, IBM® OS/2®, Microsoft® Windows® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, Java®, Javascript®, AJAX, HTML, Adobe® Flash®, etc.), or the like.
In some embodiments, the computer system 400 may implement the web browser 408 stored program components. The web browser 408 may be a hypertext viewing application, such as MICROSOFT® INTERNET EXPLORER®, GOOGLETM CHROMETM, MOZILLA® FIREFOX®, APPLE® SAFARI®, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browsers 408 may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), etc. In some embodiments, the computer system 400 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as Active Server Pages (ASP), ACTIVEX®, ANSI® C++/C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 400 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, etc.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.
Advantages of the embodiment of the present disclosure are illustrated herein.
The present disclosure includes collecting the intention of the one or more passengers, that allows the distress managing system to generate an optimal travel plan according to intention and preference of the one or more passengers. Therefore, the present disclosure not only manages the transport distress situation, but manages in a way that the one or more passengers are satisfied since the intention is captured.
The present disclosure collects data related to connecting trips of the one or more passengers to generate the optimal travel plan that helps the user reach departure point of the connecting trip within departure time, thereby ensuring that the transport distress situation does not affect the connecting trip of the one or more passengers.
When the departure point is unreachable within the departure time, the present disclosure provides an opportunity for the one or more passengers to choose an alternate destination and to indicate urgency level to reach the alternate destination, thereby allowing the passengers to choose location of their preference. When the end destination is unreachable, the present disclosure suggests alternatives to the end destination from which the passengers can select their destination. When no option works out, the present disclosure assigns a default trip to the passengers, thus ensuring that the passengers are pulled out of the distress situation at the earliest.
The present disclosure provides a feature wherein even when the passengers are not able to communicate with the distress managing system, the distress managing system identifies the passengers based on the sensor data, determines their original ticket destination based on the ticket data and then automatically assigns the default trip to the original ticket destination. This ensures that all the passengers are relieved from the distress situation without any hassle or delay even when few passengers cannot communicate with the distress managing system.
The present disclosure is workable for transport distress situations related to multiple modes of transports such as road transport, rail transport, air transport and the like.
Also, the present disclosure provides a feature wherein the one or more passengers can choose to travel by a mode of transport of their choice among multiple modes.
The present disclosure increases transport reliability and customer patronage. Further, the present disclosure effectively addresses the issue of service continuity and passenger convenience, based on data received in real-time.
Further, the present disclosure ensures safety of the passengers. Also, the present disclosure provides a feature of grouping the passengers based on destination of the passengers, that helps in transporting the passengers in the most optimal and cost-effective way.
A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.
The specification has described a method and a system for real-time management of a transport distress situation. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that on-going technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Referral numerals
Reference Number Description
100 Architecture
101 Vehicle
102 Ticketing means
103 One or more sensors
107 Distress managing system
109 Processor
111 I/O interface
113 Memory
203 Data
205 Modules
207 Distress data
209 Sensor data
211 Ticket data
213 Connecting trip data
215 Preference data
217 Real-time data
219 Other data
231 Receiving module
233 Intention collecting module
235 Reachability determining module
237 Plan generating module
239 Plan implementing module
241 Other modules
400 Exemplary computer system
401 I/O Interface of the exemplary computer system
402 Processor of the exemplary computer system
403 Network interface
404 Storage interface
405 Memory of the exemplary computer system
406 User interface
407 Operating system
408 Web browser
409 Communication network
411 Input devices
412 Output devices