by Peter Yule
ing data for a management program to minimise the damage
that malfunction of these components can cause. This is a prob-
lem that has occasionally appeared in Hedemora engines for
many years, but is more common in the submarine environment.
Goodwin thinks they are approaching an understanding of the
issue that will allow a lasting solution, and will further improve
engine reliability and effectiveness. DSTO hopes to contribute to
further gains in reliability and performance, and reductions in fuel
consumption and noise, so the engines will serve the Collins class
well in the remaining 20 or so years of life for the class.
C H A P T E R 21
‘A patch on this and chewing gum on
that’: the combat system 1993–97
In 1993 the submarine project office told ASC that the combat
system would be delivered in two stages – the first stage (release
1.5) sufficient for the first submarine’s trials, with the second stage
(release 2) being the complete system to be delivered for the trials
of the second submarine. Throughout the period 1993 to 1997
this remained the plan, but the delivery of stage two increas-
ingly seemed like a mirage, shimmering in the distance, while the
submarine project staggered thirstily through the desert of end-
less ‘releases’ and ‘drops’ of successive versions of stage one. As
the contractors and the project office tried desperately to cobble
together a system that would allow the submarines to go to sea,
the hopes that had inspired the ambitious specifications for the
‘world’s best combat system’ seemed distant indeed.
The project office’s quarterly reports chart the story of the
incremental releases, together with the ever more distant deliv-
ery of the complete combat system and the steady elimination of
the more demanding requirements.
In September 1993 Computer Sciences was testing release 1.5
of the combat system software and ‘to date there do not appear
to be any fundamental problems’, although ‘the overall stability
244
T H E C O M B A T S Y S T E M 1 9 9 3 – 9 7
245
of the combat system remains a concern’. Three months later ‘the
stability of the release 1.5 tactical data handling system software
continues to be of concern’ and the system was regularly crashing.
There were also concerns that the integration of the sonar software
into the tactical data handling system was proving difficult and
this was putting additional pressure on the schedule for release
1.5 to be ready for the start of sea trials.
It was at this time that the project office began to think that it
might be necessary to use ‘stand-alone’ equipment for Collins’ sea
trials and started investigating possible choices. At the same time
the project office was resisting ‘contractor initiated reductions in
functionality’ – in other words, Rockwell was effectively admitting
it could not meet the requirements, but as yet the project was not
willing to accept this.
In March 1994 the project office reported that ‘the combat
system software is the greatest single concern’ and this prompted
a major review to assess the problems and recommend solutions.
The meeting was attended by software engineers from every com-
pany and organisation involved, and the project office reported
that ‘the outcome was positive and gives confidence although
there are still risks to be overcome’. ASC was not convinced, with
Hans Ohff commenting that: ‘During the Project Progress Review
meeting with the Commonwealth, ASC was assured by both RSA
[Rockwell Ship Systems Australia] and CSC that the architectural
integrity of the combat system software is not at question. We do
not necessarily share that belief.’1
There was a consensus among the experts that the system
required more processing power and on-board memory, but they
also recommended simplifying the specifications because these had
made the system so complicated that they negated the flexibil-
ity that had been one of the main aims in the first place. How-
ever, it was far easier to agree on these measures at a progress
review than implement them through changes to the contract –
so much so that some people have argued that from this time
on there were no technical barriers to completing the combat
system successfully, but the contractual barriers made resolution
impossible.2
The review effectively marked the acceptance by the Defence
Department and the navy that they would not be able to achieve
the full level of performance promised for the combat system.
246
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
From this time on there was a gradual reduction in what was
expected and a more rapid reduction in the performance of what
was actually delivered.3
In June 1994 the project office accepted that even the minimally
functional release 1.5 software would be delivered incrementally,
and the risk of ‘the release of version 1.5.4, which is required to
start dived under way trials, being late remains high’. The same
report also noted that there was concern that ‘deficiencies’ in the
sonar ‘may place a submarine at risk when dived’, so there was
need for a stand-alone sonar ‘for use during the early sea trials of
the first two submarines’.
Late in 1994 Rockwell, Computer Sciences and Thomson Sin-
tra carried out yet another review of the combat system soft-
ware architecture ‘to ensure that the required performance can
be achieved for a fully functional system’. The review found ‘no
fundamental flaws in the architecture’ but ‘several areas of de-
sign and performance have been identified as warranting further
investigation’.
Throughout 1995 and 1996 successive releases of the com-
bat system consistently failed to perform as hoped, causing delays
in the trials of Collins and Farncomb and leading to increasing doubts as to whether the final version could ever be completed.
In September 1995 the project office reported that there was no
prospect that release 2 would be ready until ‘well into 1997’, so a
contract amendment was negotiated under which Rockwell under-
took to deliver release 1.7 by 30 June 1996 to ‘provide interim
combat system functionality sufficient to enable operational use
of the submarine including weapon discharge and control and all
major sonar functionality’.
In March 1996 the project office reported that release 1.5.5 had
completed shore testing and would be installed in Collins in April,
but it would need to be supplemented with further stand-alone
equipment to ‘provide the submarine with sufficient operational
capability to commence the operational test and evaluation phase
of trials’. However, release 1.7 had been abandoned because of
the effort that had been ‘diverted to fixing 1.5.5’.
The initial sea trials of combat system release 1.5.5 were
&nbs
p; ‘encouraging’ but then ‘a complex fault related to both hardware
and software led to several system failures which resulted in the
combat system endurance trial being abandoned’. The cause of
the problem was a faulty electronic card in a sonar cabinet,
T H E C O M B A T S Y S T E M 1 9 9 3 – 9 7
247
together with related software problems. The fact that this caused
system-wide failures shows the immaturity and fragility of the
system.
In September 1996 the project office reported on a further
review of the combat system, which concluded that Rockwell
could not complete the final software release as scheduled. The
stark reality now was that the schedule for the withdrawal of
the Oberons from service meant that soon only the new sub-
marines would be in service and, unless the combat system rapidly
improved, these would be less capable than the submarines they
were replacing.
During late 1996 and early 1997 several drops of release 1.5.5
followed each other in quick succession, but with only marginal
improvements in performance. One of the priorities was to get the
software to the level where the submarines could fire torpedoes.
In March 1997 the project office reported on firing preparations,
saying that ‘confidence in the system as a whole has increased, but
unexplained behaviour still occurs’. By the end of 1997 progress
on release 2 had stalled so that its completion by September 1999
was seen as ‘high risk’.
The project office reports are a chronicle of endless delays and
frustrations with the combat system, numerous reductions in per-
formance expectations and frantic efforts to stitch together a sys-
tem to get the submarines to sea. For the crews of Collins and
Farncomb the situation was extremely discouraging. Having been
led to believe that they would be given the world’s best conven-
tional submarine with the world’s most advanced combat system,
it was deflating to find that the performance of the combat system
struggled to match that of the Oberons. Peter Sinclair felt that:
‘The biggest bugbear was the combat system because this just did
not eventuate and we ended up commissioning the submarine with
what could only be described as an antiquated system and no real
fix in hand.’ Asked how the system compared with the Oberons,
Sinclair described it as
‘Oberonish’ and in some cases it was not even that good.
Certainly the active intercept capability was not as good, but
it wasn’t dissimilar to the Oberon’s in many regards. But it
certainly wasn’t state of the art and there were much better
systems available off-the-shelf that we could have plugged in
and used.
248
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
Mike Gallagher, with a slightly more developed combat system
on Farncomb, found that it was possible to ‘make it work and do
good things with it’, but the structure was hard to work with. As
an example, the way the menus were structured was clumsy and
counter-intuitive so that it could take up to 32 key strokes to track
a sonar contact and ‘if you touched the wrong key you could head
off down the wrong menu path and it would be cumbersome and
time consuming to get back to where you should be’.
The combat system was a victim of rapid technological change.
At the time it was designed PCs did not exist and the general expec-
tations of what computers could do was fairly low. By the end of
the project PCs were widespread and the average expectations of
what an expensive combat system should be able to do were set
against the PC – with the result that the combat system’s expecta-
tion gap kept growing and growing. Bob Clark saw that: ‘Young
people would come into the navy knowing what a PC could do
and this far surpassed what we were doing with the combat sys-
tem – the displays looked horribly old-fashioned for kids brought
up on PCs.’
John Dikkenberg managed the navy’s tests and evaluation of
Collins after July 1996, and was confronted with failings of the
combat system. He recalls:
Under most circumstances I would never have taken that
submarine to sea, but I was prepared to go because South
Australia was a quiet part of the world and we put other
checks and balances in place to make sure that the submarine
remained safe.
The combat system was fragile and barely worked. I was
determined to make sure it had some level of robustness and
declared that it was not allowed to be rebooted in any
24 hour period. On the first occasion at sea, it crashed
continuously and we actually brought the submarine home,
much to Hans Ohff’s chagrin at the time. The submarine
remained alongside for about two weeks while they did more
work on it.
When the trials resumed, the situation had hardly
changed. Over a short period at sea, the combat system got
worse and worse and eventually, for all intents and purposes,
it was entirely dead. The Rockwell and Librascope people
T H E C O M B A T S Y S T E M 1 9 9 3 – 9 7
249
onboard refused to reboot it because they knew that the
moment they did so, I was going to say: ‘Right, that’s the end
of the trial, let’s go home.’ I can remember these guys
eventually standing in the passageway outside the wardroom
going through their list of problems. As the conversation
went on, they explained how they were going to put a patch
on this and chewing gum on that. Eventually I just said:
‘Reboot it. We’re going home.’ That was the sort of state it
was in. It had difficulty tracking contacts, it had difficulty
taking periscope cuts. Half the system wasn’t integrated . . .
The electronic warfare system wasn’t integrated. Half the
sonar functions weren’t working. You couldn’t even really be
certain that the results on the sonars were all that good. I
mean it had huge problems.
For those who had spent years working on the combat system,
reports of this sort were devastating – nobody ever questioned
that they were trying their best to get it right. At Rockwell and
its main sub-contractor Computer Sciences of Australia the mid-
1990s were years of turmoil and upheaval, with changes of own-
ership adding to the technical and contractual quagmire of the
combat system project.
During 1993 AMP sold Computer Sciences Australia to its
original parent company, Computer Sciences Corporation of
America. Chris Miller recalls that the takeover process took a
long time, during which the company was in limbo, although the
technical people tried hard ‘to clean up the mess’ and many things
were fixed before the new management moved in.
The new American owners sent out ‘a couple of really hard-
nosed guys’, Martin Babst and Al David, to run the combat sys-
tem project and they introduced a new focus into the company’s
> work.4 They were prompted largely by a major dispute with Rock-
well in late 1993, when Rockwell defaulted Computer Sciences
for failing to agree to a release 2 delivery date. This action by
Rockwell prompted the new American management of Computer
Sciences, together with the contract manager, Tony Houseman,
to take the approach that it would do what it was contracted
to do and nothing more – there would be no more changes of
direction and no more changes to the requirements. The empha-
sis in the company changed from development to closure, from
250
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
dealing with technical computer science issues to making sure a
particular release of the software got out of the door on the given
day.5
Eventually Rockwell and Computer Sciences agreed on a revi-
sion to their contract so it was no longer fixed-price but became a
time and materials contract. Tony Houseman saw this as making a
great difference, and the relationship between the companies and
the progress on the combat system greatly improved from that
time.
In 1996 Rockwell sold its aerospace and military businesses
to Boeing. Apparently Boeing was rather surprised to find that it
had also bought a submarine combat system contract that was
losing money and had no end in sight. Although it had no experi-
ence with submarine combat systems, Boeing sent several senior
aerospace managers to Australia and threw millions of dollars at
the combat system to try to make it work. It also sought help in
the United States from large defence contractors including Lock-
heed Martin and Raytheon, foreshadowing the direction the com-
bat system would take in the next phase of the new submarine
project.6
The management of Boeing Australia felt that the company
was caught in a contractual vice, and others agreed with this view.
Tony Smith (another with multiple involvements in the submarine
project)7 headed Boeing’s combat system team and was frustrated
by
the total refusal of the Commonwealth to relax the
contracted requirements without significant pain for the
contractor. I knew the navy would not use all the capability
and they could have used the extra money to start designing
the next combat system, but the commercial side insisted on
