In the large scale project game, you almost never ever want to be the service side of a relationship.
Never.
Here is the situation. We're responsible for the PA System. Whatever the Master Control System (MCS) in the Station Control Room (SCR) ask us to broadcast, we broadcast. Simple right?
In a perfect world where engineers are there to solve problems, yes, simple. In many case, things are unfortunately a ted bit more complicated.
Let me give you an example. There's this button in the SCR which, when pressed, would trigger MCS to send us a request to broadcast an emergency message to the whole station. Simple concept. The emergency message has a very high priority and would therefore interrupt all other messages and let passengers know something's wrong. When testing, they would press the button, no emergency PA came out, the immediate reaction is that PA system is not working. We receive e-call on that, came on site to find in the logs that it's MCS that never send us the request.
or in their request they'd asked us to put in a 30 seconds interval. Our system happily obeys the request, test engineers hear only one message being broadcast instead of continuously rotating broadcast, and we would get the call instead of MCS.
This happens all too often during the half year test and implementation that I'd been involved in.
In truth, the company that won the contract for building the MCS often has a very good relationship with MTRC that they wouldn't want to break, and thereby a noticible bias towards them whenever difference in opinion arises. MCS is a huge system. it handles handshaking with PA, CCTV, signaling, train locations, and a whole punch of other train station functionality, and it's extremely easy for them to make mistake. It's also extremely convenient for them to push it to the service sides so they can have more time finding out what's wrong.
Never.
Here is the situation. We're responsible for the PA System. Whatever the Master Control System (MCS) in the Station Control Room (SCR) ask us to broadcast, we broadcast. Simple right?
In a perfect world where engineers are there to solve problems, yes, simple. In many case, things are unfortunately a ted bit more complicated.
Let me give you an example. There's this button in the SCR which, when pressed, would trigger MCS to send us a request to broadcast an emergency message to the whole station. Simple concept. The emergency message has a very high priority and would therefore interrupt all other messages and let passengers know something's wrong. When testing, they would press the button, no emergency PA came out, the immediate reaction is that PA system is not working. We receive e-call on that, came on site to find in the logs that it's MCS that never send us the request.
or in their request they'd asked us to put in a 30 seconds interval. Our system happily obeys the request, test engineers hear only one message being broadcast instead of continuously rotating broadcast, and we would get the call instead of MCS.
This happens all too often during the half year test and implementation that I'd been involved in.
In truth, the company that won the contract for building the MCS often has a very good relationship with MTRC that they wouldn't want to break, and thereby a noticible bias towards them whenever difference in opinion arises. MCS is a huge system. it handles handshaking with PA, CCTV, signaling, train locations, and a whole punch of other train station functionality, and it's extremely easy for them to make mistake. It's also extremely convenient for them to push it to the service sides so they can have more time finding out what's wrong.
No comments:
Post a Comment