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
