The Collins Class Submarine Story

by Peter Yule

  slow, and could produce corrupt code. Nevertheless, the Rockwell

  consortium was stuck with them.5 The problem became critical

  when Rockwell wanted to further upgrade its processor (after hav-

  ing done so before with the 68030 and 68040) and Verdix refused

  to develop another new compiler for the 68060.

  The decision to use the Motorola family of 68000 processors

  was itself an issue, heading up a dead end. In the mid-1980s the

  68000s were the best available, but the triumph of Microsoft and

  Windows over Apple’s Macs meant development of the 68000

  ceased while the power of Intel processors multiplied exponen-

  tially. The decision to use Motorola processors was made by Rock-

  well (with the encouragement, at least, of the project office) at

  an early stage in putting together its bid, and was subsequently

  incorporated in the combat system specification.6 This was one of

  several decisions that pushed the project into technological back-

  waters.

  Many of the woes of the combat system project were the result

  of unlucky timing. Critical decisions were made just as the PC

  revolution was beginning. One of the consequences of this was

  that almost all the hardware the project used was custom built

  and better commercial hardware was available shortly afterwards.

  Chris Miller of Computer Sciences recalled that:

  The displays were custom built and programmed using

  Librascope code. The disks were built using custom

  hardware and then programmed from the ground up (with

  156

  T H E C O L L I N S C L A S S S U B M A R I N E S T O R Y

  the result that accessing the disks was a task in itself). The

  backbone fibre optic bus that connected all the components

  and the software that was written to run it was developed

  from scratch. Likewise for the command plot, the plasma

  display units and so on.7

  The use of custom-built hardware separated the project from the

  rapid progress of the computer industry in the late 1980s and early

  1990s. Further, the use of standard hardware would have allowed

  the use of standard software.

  The structure of the contract for the combat system was

  unusual and bitterly opposed by both ASC and the Rockwell

  consortium. Essentially the Commonwealth forced contractual

  responsibility onto ASC, though it neither chose the sub-

  contractor nor knew, for security reasons, the specifications of

  the system. ASC was responsible for the successful delivery of the

  combat system, but it had limited ability to ensure that this hap-

  pened. Just the night before the contracts were signed, Rockwell

  was pushing to have a contract directly with the Commonwealth,

  not wanting to be subservient to a fledgling prime contractor.

  ‘Team Rockwell’, which had seemed from the outside to be a

  powerful and united consortium during the contract negotiations,

  rapidly began to fall apart under the stress of its internal tensions.

  Singer Librascope’s relations with Rockwell remained poisonous

  and it offered no help to other members of the consortium.

  Rick Neilson, with Oscar Hughes’ agreement, joined Rockwell

  in August 1987. At that time Rockwell had no organisation in

  Australia, but about 20 people from the team that had been in

  Canberra for the final stages of the bid stayed on to form the

  nucleus of Rockwell Ship Systems Australia, with Neilson joining

  as the first Australian employee.

  Rockwell set up in Sydney in late 1987 and Neilson remembers

  that they scoured the universities and hired dozens of graduates,

  who joined with enormous enthusiasm but ‘they were old, old

  men after a couple of years’. They tried to make the combat system

  happen and ‘it turned out not to be all that easy’.

  Meanwhile, John Pascall, another from the SWSC team, was

  in Anaheim as part of the submarine project’s liaison team. He

  found Rockwell treated the Australian system like any project for

  the US Navy, where it would produce the first version, find all

  T H E A U T O M A T E D I N T E G R A T E D V I S I O N

  157

  the bugs and then re-engineer the system to fix them. Feasible

  with American production runs, the approach was not viable for

  Australia’s six units. With the Collins system each fix was a loss

  and by 1990 the company was starting to lose money.

  Pascall recalls an incident revealing something of Rockwell’s

  approach to the project. At one stage he had told Rockwell that

  its practice of adding patches with myriad wires and switches

  breached all NATO standards, to be told that the patches were

  temporary and would be fixed ‘at the next contract’. Rockwell did

  not understand that Oscar Hughes was determined there would

  not be a ‘next contract’.

  Computer Sciences of Australia’s primary task was writing

  the software for the tactical data handling system, ‘the bubble

  in the middle of the combat system’. Within the tactical data

  handling system were three major elements: the multi-function

  common consoles, the command plot and the two systems super-

  visory units, with CSA’s software running these central hardware

  systems.

  Computer Sciences was taking on by far the biggest defence

  project it had been involved with, and attempted to plan its work

  using the latest tools. ‘Teamwork’ – ‘a structured analysis

  technique using data flow diagrams’ – was used to produce its

  ‘requirement specification’ based on the contracted performance

  specification. It took a team of about 25 engineers 18 months to do

  the requirements analysis but at the end ‘the navy saw it and asked

  “What does it mean and what can we do with it?”’ Teamwork had

  ‘pushed out documents that were monumental and unreadable by

  humans’.8

  The story of Teamwork epitomises a central problem with

  Computer Sciences’ approach to its task: it became overly con-

  cerned with computer science issues and lost sight of the ultimate

  aim of the project – to produce an efficient and effective sub-

  marine combat system. Computer Sciences spent over 18 months

  planning its work and undertaking the requirement analysis. Rod

  Farrow, who was project manager from 1988 to 1993, thinks that

  in hindsight the timetable was ludicrous. Computer Sciences had a

  contract to develop the tactical data handling system in 48 months

  from 9 September 1987. After about 36 months, Computer Sci-

  ences produced a ‘build zero’ of the system. This ‘showed they’d

  got the run time execution working’ and a few other parts of the

  158

  T H E C O L L I N S C L A S S S U B M A R I N E S T O R Y

  system also, but ‘it wasn’t very much and they were a long way

  from producing a tactical data handling system that would enable

  Rockwell to make a combat system’.9

  Chris Miller, who had worked with Computer Sciences on the

  navy’s helicopter simulator at Nowra before moving to the sub-

  marine project in 1989, had the same view. He ‘never saw a plain


  English description of what the combat system was meant to do’

  and felt that the combat system project was focused more on com-

  puter sciences than ‘how it would work with people sailing around

  with it’.

  The biggest challenge for Computer Sciences was the require-

  ment for ‘graceful degradation’. In the architecture of the system

  there were two systems supervisory units (which were like servers

  with hard disks), seven multi-function consoles and a command

  plot. The system had to be able to keep working even if the SSUs

  and three of the consoles were damaged or otherwise out of action,

  ‘gracefully degrade’ down to just four consoles that could take

  over the functions of the SSUs the instant they crashed. At this

  time computer memory was a scarce and precious commodity

  and the requirement for graceful degradation was responsible for

  ‘eating up’ much of the available memory and crashing the system.

  Tony Smith, a former submarine commander who had worked

  on the specifications in the early 1980s and later tried to build

  the combat system when Boeing took over Rockwell’s defence

  business, argues that the initial operational requirements were

  misinterpreted when they were converted into performance spec-

  ifications. The submarine operators wanted all the information

  available on all the multi-function consoles so that there would

  be no loss of data if one or more crashed or were damaged. In

  the specifications this was interpreted as a requirement for zero

  latency – that the information had to be available simultaneously

  and instantly on all consoles – but the processing power to do

  this was still 10 years away. It did not really have to be instan-

  taneous for all functions – a three-second delay for some would

  have been quite acceptable for the submariners. Smith’s view is

  that the requirements had become too demanding for no sensible

  reason and there was no contractual flexibility to change these

  requirements.

  While the teams at Rockwell and Computer Sciences in Syd-

  ney were facing growing difficulties with their parts of the combat

  T H E A U T O M A T E D I N T E G R A T E D V I S I O N

  159

  system project, the two main overseas sub-contractors, Thomson

  Sintra in Cagnes-sur-Mer, France, and Singer Librascope in Glen-

  dale, California, had work that was technically within their abil-

  ities, although both still found the project challenging.

  Bob Clark, another graduate of the SWSC, was sent to Singer

  Librascope as leader of the liaison team. Bitter that it had been

  cut out of a major role, Singer Librascope had decided it would

  fulfil its contract and nothing more. However, as Clark sees it the

  contract had been based on work value and not ability. This meant

  Thomson – the sonar experts – did not write all the software for

  the sonars, and Singer Librascope – the weapons experts – did not

  write the software for the weapon displays. Neither was there an

  overall systems architect – Rockwell was meant to carry out this

  role, but few would say it succeeded.

  Singer Librascope fulfilled its part of the contract quickly and

  its work was delivered before Computer Sciences was ready; it was

  not until several years later that it became obvious there were seri-

  ous problems, when Computer Sciences’ software did not merge

  with Singer Librascope’s work.

  Rod Fayle and Ted Vanderhoek went to Cagnes-sur-Mer as

  part of the submarine project’s liaison team with Thomson Sintra,

  and Fayle recalls that he had hardly arrived in France before

  Rockwell and Thomson were arguing about the boundaries of

  their contracts. Ted Vanderhoek also felt that the relationship

  between Thomson and Rockwell was adversarial and both sides

  became locked into their contractual positions. ‘The Rockwell

  people would come to visit Thomson and say, “There’s a prob-

  lem and it’s your problem”, rather than “We have a problem”.’

  He describes Thomson’s reaction to this as ‘Gallic’, withdrawing

  to strict contractual obligations while protecting its intellectual

  property and its reputation.

  By 1991 Thomson’s development work was nearly complete,

  the consoles from Singer Librascope had already been delivered

  and other parts of the system were gradually following. Computer

  Sciences had built the land-based test site at HMAS Watson and

  in the early 1990s began to test the equipment from the various

  suppliers.

  Most equipment functioned satisfactorily by itself but, as John

  Pascall recalls: ‘The problems started when you plugged them

  together – we would sit at the consoles and be scared to touch any

  160

  T H E C O L L I N S C L A S S S U B M A R I N E S T O R Y

  buttons because the system would crash.’ In Ted Vanderhoek’s

  words: ‘It was a mind-numbing integration period.’ The combat

  system was emerging as a major problem for the whole project.

  Ron Dicker had been analysing Rockwell’s progress report

  data, and at a design review in September 1992 he argued this

  showed the system could not be completed until after 1997. Mike

  Shearer, the Rockwell program manager, ‘exploded in a volatile

  fashion’ and Dicker received no support from either ASC or the

  project office.

  From the start Rockwell acted as though it was a prime con-

  tractor, and the navy tended to encourage this attitude. Tomy

  Hjorth recalls asking Oscar Hughes how the combat system was

  progressing and Hughes replied, ‘I’ll work with Rockwell and you

  work with the rest’. Hjorth and the ASC board agreed that it was

  important for ASC to minimise its involvement with Rockwell.

  For Oscar Hughes the central focus was on the integrity of the

  hull: he knew that the project could not survive if a hull failed,

  while the combat system could be fixed or replaced.

  By 1992 the combat system project was in disarray, with great

  concern that the system would not be operating at anything like

  the minimum level needed to begin sea trials in the first submarine.

  Within ASC and Kockums there were the first whispers of support

  for defaulting Rockwell, and there were even suggestions that the

  combat system should be scrapped and the whole project started

  again.

  Part 2: The ship control system

  The idea of using automation to reduce crew sizes had great appeal

  for those planning the requirements for Australia’s new subma-

  rine. Crew size is a fundamental design criterion because each

  person adds to the demand for space, weight, heat and food.

  In addition, the Australian submarine squadron suffered from a

  chronic shortage of volunteers and it was hoped that the new sub-

  marines could be operated with a crew of about 41 rather than

  the standard 63 of the Oberons.10

  The Swedish navy also had difficulties crewing its submarines,

  and Kockums, working closely with Saab Instruments, had

  designed submarines to operate with small crews b
y automating

  T H E A U T O M A T E D I N T E G R A T E D V I S I O N

  161

  controls and using computers for shipboard management. Saab

  Instruments was closely involved with planning the ship manage-

  ment system for the Kockums bid. G östa Hardebring of Saab came

  to Australia several times after March 1984 to talk with Australian

  companies to find ‘a partner with capabilities not only for elec-

  tronics development and production but even more importantly

  with resources for advanced software development’. He assessed

  Wormald as the most suitable partner.11

  The final contractual negotiations for the ship management

  system took place in late 1987 and the contract between Saab

  and ASC was signed on 17 December 1987. The same day the

  sub-contract was signed between Saab and Wormald. The con-

  tractual relationship was complicated because Saab was building

  the system to a technical specification made by Kockums, with

  Kockums in turn being a sub-contractor for some parts of the

  system.

  G östa Hardebring recalls that Saab saw the requirements for

  the ship management system as ‘very advanced’ and that ‘the use of

  computers and the advanced and extensive software was definitely

  unusual at the time’. The navy realised the requirements were

  extremely ambitious and it saw the ship management system as

  one of the main areas of risk in the whole submarine project.

  The ‘integrated ship control and monitoring system’ is the fun-

  damental system for controlling the operation of the submarine,

  including everything from ‘driving’ the submarine to opening and

  closing valves. The system has 19 computers around the subma-

  rine on a network that monitors over 5000 data points, checking

  the status of every piece of equipment – when pumps turn on and

  off, what the battery status is, and so on throughout the subma-

  rine – and transferring the information to two points, the control

  room and the after machinery control room. At either of these

  points an operator can monitor and control all the systems on

  the submarine. This ‘fly by wire’ system for manoeuvring the sub-

  marine was absolutely critical for the success of the whole new

  submarine project.

  Saab had the overall responsibility for design, production and

  delivery, with a substantial Australian involvement by Wormald