A big ongoing activity of FLOWTRACK is with telemetry systems.
James worked early with JZA 711 / 715 systems, doing things with them that pleasantly suprised the designers from Sweden. Our latest effort was after a request from a vendor who unfortunately stopped communicating with us when the project was basically ready for deployment :-(
This is a new communications link setup, replacing TPM cards and
copper wires with modern age internet connectivity. This is not a
simple replacement, as the JZA system had discrete timing requirements
that cannot be met by normal means. Flowtrack has solved this using
our in-house translation systems, allowing any JZA systems to be kept
going basically forever.
In doing so, we used Arduino's to replicate master and field stations for testing. We thus have developed a suite of systems to enable JZA systems to live on.
The Arduino implementation versus the previous!
Nearly ten years ago, we were approached to rectify issues that beset the telemetry system running trains between Muswellbrook and Werris Creek. We pointed out that the system they asked us to work on was fundamentally flawed, and should be replaced. The ensuing project updated Westinghouse S2 systems to connect via the internet by means of microcontrollers interfacing between RS485 to the rack and telemetry servers in Newcastle. We eliminated the use of 'multi-drop' modem systems which were obsolete and unavailable in the process. We also added some interesting local logging and reporting systems, bringing the telemetry up to modern functionality without modifying the control systems themselves nor the interfaces to the signalling equipment in the field. Unfortunately, over time certain issues in the communications environment have led to the inability for the field devices to reconnect at need to the servers at Newcastle. This has been by and large invisible to the remote control system as the equipment we built had extensive redundancy provisions, so that control and indications to all stations was maintained. The inability to reconnect has been traced by lots of sleuthing to failures in the 'listener' threads of the servers. These servers were based on commercial products. We have been asked to update the systems to current operating systems, and have again offered to re-write the server programs so that they are not only far more reliable in the first place, but are able to detect internal failures and rectify themselves by periodically testing the ability to connect. This subsystem re-write has now been completed and tested, and is able to handle lockups of the 'listener' threads, along with network issues of all types, without interrupting in any way the operation of the system. We did this because it was necessary and was interesting. Its a little like HAL in 2001 predicting failure of some sub-system. Although our version won't lock the maintainer out in deep space, and will fix it itself. Just waiting on ARTC to buy the new product of us at a more than reasonable price.