The important design assumptions will be mentioned here. Some design assumptions for instance with respect to the tracking system would be that the pre-requisites for train tracking are already implemented in the system or the security of these systems are intact although some vulnerabilities have been traced. For each of the assumption there will be a proper discussion on why the assumption is necessary and what purpose the assumption achieves in this report.
Some of the key design assumptions that are used here are:
- The train name is considered only for the context of display purposes and will have not functional implementation. This is hence a redundant identifier
- The second main assumption here is that each of the tracking systems need not validate the input and output, here there are no checks constructed for ensuring there is input and output consistency. The input and output are assumed to be consistent with the required format.
- The third assumption is that the zone identifiers are unique, this might not be the case in real time. In real time there could be overlapping zones. The presence of overlapping zones might even impact on the number of trains that could cross through. However this project assumes no overlapping zones and hence this would mean that the detector will first check if a zone is free, if it is not then it will check for the train on that zone. It will not check if the train extends into another zone.
- In real time it would also be wise to check for whether a train in one zone would pass into another zone next. This would help to keep track of real time release of the zones. However here the assumption is that there is enough release distance or time between two zones, which would practically be impossible in real world.
- Lesser interdependencies are assumed, in real world scenario there would be more dependencies and hence a more complex structure would be required.