automated test systems

The third Thales system we were invited to work on was the TSS system. This system was designed and developed as an in-house replacement for the third-party supplied VIP system mentioned here. It was being developed in parallel to the VIP system by a second team of programmers.

The TSS project was based around the design and construction of a new solid core based sonar array. The array itself was built within Australia using ATM communication links on hardware obtained from Scotland. These links were fed into multiple ATM cards running on an Irix 4 Processor SG3000. The front end was a java based display supporting both the Microsoft Explorer and Netscape browsers. This front end was a graphically representation of the array with drill down capabilities in order to control and configure the array at various levels. This range was from an individual sonar element in the array to each line in the array to the entire array. The array itself consisted of 72 elements at various distances from each other in a single line. A maximum of eight lines were then combined to produce the array. The main processor also controlled the data fed to tape system in a similar manner to the VIP system.

This system was already designed but progress was far less than was expected. There was an imminent design review that the existing team was unprepared to carry out as the system had gotten itself separated into a number of little projects with no realcoordination between each of these mini projects. Thus the main tasks to be carried out for this system was to get the documentation up to a standard and consistency whereby the design review could be carried out. In addition to this the design review team were also expecting a demonstration of the software.

The initial challenges in this project were more managerial than technical. Interfaces between the various modules were finalized and checked, build environments were constructed and the basics of a regression test system were introduced. Very simple processes were put into place such that it could be shown that there was a cohesiveness within the system and that a great deal of progress had been made although there was still major hurdles to overcome.

It became apparent that the expected throughput of the system was not going to reach the required throughput of the system. The system as implemented could barely handle three lines rather than the eight designed for. Although this was later found to be a software implementation problem, assurances from the supplier, yes it was the same supplier as the VIP system, suggested everything in the long term would be fine.

As part of the risk mitigation for the project the software running on the quad processor was platform independent and thus could be easily ported to a fast X86 server (Dell rack mount). The first stage of this was to move the human interface system to an X86 based system. The IO and tape control was left on the quad CPU machine. This was successful and allowed the demonstration of the basic functionality of the system. The second stage of risk mitigation, although not fully implemented, was to allow the Dell to process the data in parallel with the quad CPU machine in order to provide a proof of concept. This then allowed 4 dells to replace the single SGI box. The only change to the overall system was to program the ATM to send the data to two ATM ports not one. The parallel Dell system showed the Dell implementation was also feasible.

After that it was just a matter of noting the technical problems and solving them. As stated earlier this was more a series of management and team focus problems not technical. The technical problems were along the lines of difference between the browsers, missing functionality in the java classes and reliability issues in the streamer hardware.

This system, like the VIP system was well received by the customer.