2017-08-23 By Robbin Laird
I have been writing for some time about the strategic shift or one could call revolution to building software upgradeable systems.
The new multi-mission platforms on sea or in the air such as the Australian ANZAC Class frigates or the Wedgetail are simply different from legacy platforms for they are modernized differently.
A key challenge for the acquisition and policy community is to adjust their thinking to the new reality and to understand how radically different the new “platforms” are compared to the legacy ones.
Recently, the head of Air Force Materiel Command highlighted how significant the challenge of changing the mental furniture and acquisition procedures to get out of the way of technology, and rather than retarding progress, accelerate it.
Recently, General Ellen Pawlikowski, Commander of Air Force Materiel Command, provided a hard-hitting overview on how important and necessary she believes a breakthrough is on the management of software upgradeability.
At a Mitchell Institute breakfast meeting on July 14, 2017, she focused on the barriers and the need to shape a combat force that is empowered by agile software development.
Her presentation focused on what she referred to as the cultural barriers to change. She bluntly asserted that the current acquisition approach guarantees that unnecessary review and control layers in the bureaucracy will persist and continue to slow software upgradeability.
One could easily ask how many acquisition officials can even read let alone write code, but the broader point is that the so-called oversight system needs to be radically changed.
The General was kinder and gentler than I am being here.
The General was kinder and gentler than I am being here.
But she was certainly direct enough in her outstanding presentation on the challenge and how to meet it.
The acquisition system has been built around a 20th century systems engineering model, one which sets requirements and designs the way ahead in a manner in an iterative requirements process which is simply inappropriate for a software driven force.
“We are very much enamored with our systems engineering processes in the Department of Defense.
“We have processes that drive us to start with requirements and continue to work those requirements through rigorous testing.
“When I was on the job at SMC I learned that OCS had failed their preliminary design review.
“But preliminary design reviews don’t make any sense when you are doing software development.
“Agile Software development is all about getting capability out there.
“The systems engineers approach drive you to a detailed requirements slow down.”
She highlighted that this cultural barrier, namely reliance on the historical systems engineering approach, needed to be removed.
“We have to change the way we think about requirements definition if we’re going to really adopt Agile Software Development.
“Maybe the answer isn’t this detailed requirements’ slow down.”
“By the way, once you put it in the hands of the operator maybe some of those requirements you had in the beginning, maybe they don’t make any sense anymore because the operator sees how they can actually use this and they change it.”
She went on to highlight what the Aussies are doing in Willliamtown with Wedgetail without mentioning them at all.
“You need to put the coder and the user together…
“We have to empower at the right level, and that has to be at the level of the person that’s going to use the software, and we have to stop thinking about independent OT.”
She then went after the way sustainment is thought about for the software enterprise.
“The other thing that we have is this idea that software is developed and then sustained.
“What the heck does that mean?
“Software doesn’t break.
“You may find something that doesn’t work the way you thought it was, but it doesn’t break.
“You don’t bring it in for corrosion mitigation or overhaul on the engines.
“When you’re look at what we do in software sustainment a lot of it is continually improving the software.”
I will focus again on the Wedgetail case in my most recent interview with the Wing Commander in charge of Wedgetail, but during this visit to Canberra had a chance to visit a leading center on developing software based radar technologies for the Australian Defence Force, and to view how the company builds its radars and evolves its technologies.
CEA Technologies was founded in 1983, and specializes in the design, development and manufacture of advanced radar and communications solutions for civil and military applications.
I had a chance during this visit to Canberra to discuss CEA and its approach with Ian Croser, Technical Director, CEA, with more than 30 years of experience in the radar business, a period in which radar technology has been transformed into a multi-function, multi-mission software enabled even defined combat capability.
Question: What is CEA Technologies?
Ian Croser: It’s a private Australian company, but it has a significant shareholding from Northrop Grumman. It is an Australian controlled company. CEA works closely with Defence to achieve National strategic outcomes.
Question: During the tour of the facility, it was clear that you tightly control the development and manufacturing process, in part certainly to enhance the security of the product and the process. Could you describe your approach?
Ian Croser: It’s hugely important to control the development and manufacturing processes because, the design and the development of individual modules and subsystems don’t all come together at the same time. And that brings with it some real issues when you subcontract out design to subcontractors.
Because the moment you subcontract them out, you’ve effectively lost daily control over them.
Having the ability for our teams to be co-resident, and all talking to each other, solves so many problems for us. In time, in quality, in functionality, you end up with a better, lower cost and more secure solution.
Question: When you viewed the racks and the boards, you noted that none of these boards was COTS and that they all are built internally.
How important is it to control that board, from a security and also a performance point of view?
Ian Croser: From both points of view it’s extraordinarily important because, if you are buying a board, you don’t necessarily have all the controls over where the components come from, how they got to you, and how they’re treated, before they actually get embedded in the board.
And they’re all points at which somebody may do something that you don’t desire.
From a performance point of view, COTS boards are all things for all people. Our boards are formed to fit into our space and weight and technology requirements, and we can better fit them into a smaller space.
For example, in the array digital backend area, if we had used COTS boards, it’d be many times larger than it is now, and it wouldn’t actually fit into our design baseline.
You wouldn’t be able to implement our approach.
There’s really no choice but to build our own boards and embed them in the system.
Question: Let us turn to the radar revolution in which we have moved from building a largely single purpose commodity into a multi-mission, multi-function upgradeable system.
How would you describe the shift?
Ian Croser: A conventional, mechanically-scanned radar, for example, is comprised of a large number of configuration items, all of them different and very few are used in multiple positions.
That means that in design and in build there is a lot of effort to mature those different elements.
These separate pieces have to be integrated and failures in just one subpart, generally impacts availability of the whole system. Integration requires significant time and effort to bring together the separate parts to form the whole.
It is completely different with active phased array radars.
The high density functional modularity has suddenly become available and implementable. As a result we are building a very small number of unique configuration items, but building lots of them.
When we put them together, we get the resilience of parallelism, so if one module fails, it’s just one of a large number operating in parallel.
The functional and physical modularity along with the independence of modules means that the resilience to damage and the resilience to occasional failures, is very high.
This has enormous beneficial impact on the sustainment process. Individual failures no longer force repairs before or during a mission; you can just carry on with a small proportion of the array that might have failed or have been damaged.
The repair can then be scheduled at a time and place of convenience.
It shapes a whole new way of sustaining capability at sea, for example.
Question: This new generation of radars is software defined and software rich. How does the software approach change the nature of the development and modernization game?
Ian Croser: The modularity of the hardware has to be matched by the modularity of the software and the firmware.
If you can isolate the application specific personality of the radar from the software base, then the software and the firmware becomes similar to an operating system.
It supports the rapid application change process without itself needing to change.
It’s sitting there underneath, and interfacing into the hardware, and when you tell it to do something, it does it. So if you tell it to point a beam in a given direction, then all of the distributed functionality that is across the array will do that, without needing to be ‘hard programmed’ to achieve new outcomes.
The radar personality, the application specific functionality is built into a small dataset that informs the system how it should operate under a given circumstance.
All of the software/firmware functions are just waiting to be organized in different directions and different sequences and with different parameters to be able to do their desired functions.
It is that small dataset running in an organizational set of boards that tell the system what to do, when to do it, how to do it, without changing the software and firmware.
Question: This provides for inherent transferability across radars operating in air, sea or land and can allow for enhanced efficiency in joint capabilities and joint investment.
How would you describe this process or approach?
Ian Croser: The objective is to reduce the number of software baselines being maintained across multiple platforms and operating domains.
This approach frees up a lot of development capability, and it means that the commonality and the interoperability is inherent and enhanced.
Even if you haven’t brought forward a particular function in a particular application and platform, if it’s in the common software base, then it’s a really simple thing to bring forward and use.
It’s more about integration with the rest of the platform capability than it is about the radar itself.
Implementation of a ‘Task Based Interface’ and control methodology has effectively insulated the Combat Management System from major change cycles in response to new applications.
This software baseline, when combined with the modularity of the hardware, allows the design and build of scalable radar, which can readily fit into different platforms across land, sea and air domains.
There is not a lot of work to bring a new application online.
It changes the whole way in which you think about multi-function capabilities, different applications, and how those applications interact with one another.
Question: The US Navy is starting to move forward with procuring a new frigate. I have written about the significant opportunity for the US forces to leverage allied investments and capabilities in accelerating the modernization of US forces as well.
It would seem to me that the frigate is an ideal case not only in terms of taking a foreign design but most certainly with the outstanding and combat tested frigate equipment already deployed on the frigates of our allies.
It would seem to be a no brainer to look seriously at your radar for this program so that the US Navy can ramp up the time when they could get a functioning frigate at sea.
After all, powerpoint slides for potential systems kill audiences, not adversaries.
What are your thoughts along these lines?
Ian Croser: It could make sense for the US Navy on several grounds.
Cost is a clear advantage and risk is contained by having operational systems already in place.
Shared investments with a core ally can also accelerate joint capabilities.
Interoperability is built in and the Australian Navy is already shaping the Conops of the system at sea.
It is only in the past decade that navies have looked beyond the organic role of radars onboard ships to think of fleet interactivity among radars at sea.
CEAFAR certainly is designed to do this and with the inbuilt multifunction capability and commonality there is significant enhancement to distributed lethality.
Question: With the shift in focus towards, high tempo and high intensity operations, mobilization becomes as important as modernization to combat success.
It is clear in walking around the plant and looking at your approach, mobilization capabilities are built in.
Could you highlight this aspect of the inherent potential of your manufacturing process?
Ian Croser: The key to ramp up is to embed high functionality and high performance at printed circuit board level.
Because now, component reliability has far outstripped system availability, it is possible to provide programmable and function rich systems with wide and inexpensive growth factors.
If you put all the effort into embedding rich functionality into the board itself, the flow on sustainment costs also benefit, that’s the really key process.
Now once you’ve got the board, if you’ve designed it right, it can be manufactured on standard automated production lines at very low cost.
Because of the modularity and building lots of a small number of configuration items, you can now build the synergy in manufacturing to push through large volumes of work, very quickly.
And of course, all of the test jigs and all of the capability to manage those few items also benefit from the modularity.
So you end up with a whole different way of manufacturing, testing, integrating, and delivering high capability at low cost.
Appendix: CEA Company Profile
CEA Technologies was established in 1983 by two former Naval Officers with a goal of creating a centre of excellence for the design and support of systems for the Australian Defence Force. From the outset, CEA Technologies was based on the provision of uncompromising design principles and robust through life system support, this philosophy became an enduring driver of CEA’s business.
“Solutions with Commitment” was established as a pivotal tenet of CEA practices and remains the company’s primary driver in business conduct ensuring that the company continues to be at the forefront of innovation. Throughout its brief history CEA’s achievements have continued to accumulate resulting in the company growing to become an internationally recognized, world-leading radar and communication systems supplier.
The company continually endeavors to expand its reach into the international market and successfully exports to the USA, Europe, the Middle East and Pacific countries. A steady and continuous corporate growth has resulted in a corporate staff exceeding 270 people located across its four facilities in Australia (Adelaide, Canberra [HQ], Melbourne and Perth) and in the USA.
One of the company’s greatest achievements came about in November 2010 when CEA delivered to the Royal Australian Navy (RAN) a world first – the first fourth generation Active Phased Array Radar (PAR) System to be brought into service.
http://www.cea.com.au/!Global/Directory.php?Location=Home:Home