Naval vessels undergo maintenance at regular intervals and are often modernised once during their operational lifetime. But technology and threats are evolving faster and faster, creating threats that didn’t even exist when the ship was built. Thales is thinking about how ships can keep up with this.
By Jaime Karremann - Naviesworldwide.com
“The small UAV [drone] is such an example,” says Adriaan Smits, head of Services at Thales. “They didn’t exist when for example the LW-08 radar for the S-frigates and M-frigates was developed and was not designed to detect UAVs. You might think that would require some small changes, but it is in fact quite complex. In terms of movement characteristics small UAVs are very similar to birds, with similar dimensions and fly at approximately the same speed. Old radars can detect them, but birds and UAVs are seen by the system as clutter and are not shown.”
“In order to be able to recognise and distinguish small UAVs, such as the average commercial drone, from birds, adjustments are needed. This requires special wave forms, special viewing frequency, search patterns, etc. That is very difficult. To do that you have to need a new radar.”
In the past, the only solution was to wait for the next ship or replace the radar with a new one during a midlife upgrade. But as with the previous radar, chances are that the new radar was not suitable for the next threat. In that case the user has to wait for another 15 years.
Incidentally, this does not only apply to radars, but to many more software based systems. For example combat management systems and cybersecurity systems.
Smits: “What is different now is that the operational needs change faster than before. It is not a question of whether your system will continue to work for thirty years, but whether the system does not suddenly become useless ten years after it has been put into operation due to new developments.”
“Of course a ship is maintained regularly and modernised once or twice”, says Smits, “but that maintenance is mainly intended so that ships can continue to do what they were once designed for. If parts can no longer be supplied, then a solution is found so that the system can continue to work.”
“We are now talking about functional obsolescence. We didn’t have a solution for functional obsolescence in the past. Apart from decommissioning old vessels and developing new ones.”
The solution to the problem sounds simple: software updates. Smits: “What is new is that much more systems are software based than in the past. This means that you can change the function of devices to a very large extent by changing the software. As a result, you can change the function during the life of the product. So apart from the traditional maintenance after fifteen years, removing on-board systems, painting over and replacing rotating parts, you can do an annual evaluation: does the system still do what you want? And if not, can we adjust it in such a way that it will do that?”
“It actually started with APAR,” says Smits, who has been working with that radar for years. “But with our latest radars, the hardware is mainly a way to send and and receive energy, but that hardware is controlled by software. There is a lot of room for adjustments in software.”
According to Smits, radars can for example be adapted to see UAVs. “Modern radars are flexible, but how that is implemented depends on the system. An adjustment goes further than only changes in software.”
“Technology has also become more scalable in terms of hardware. The NS-100 radar can also be expanded with more reception or transmission tiles for more power or other processing hardware. The interaction between hardware and software offers enormous flexibility. Due to the rapid technology development, you have to replace the processing power on a regular bases anyway. Because it can do more, there is more room to program new functionalities: faster computers, more possibilities.”
Design for change
According to Smits, these new possibilities are not limited to radars alone, but apply to the entire ship. That starts with the requirements and the design phase. Smits: “We call this design for change; you have to take adjustments into account in your product design. Try to keep parameters as broad as possible, so that you build in flexibility. You can also physically free up more space for upgrades.”
Can operators in operations rooms of navies around the world using Thales radars count on pop-ups, informing them that they can download radar software updates? Not for the time being.
Smits: “This is very common for civilian software, but does not fit well in the defense world. App updates on your phone can often be done because developers continuously receive data from those apps and can also send data to them. For military products this is not possible because that data has strategic value and is of course not freely shared.”
“Furthermore, in the defense world we cannot simply share all upgrades developed for a product with all users. A dialogue is also important here. Forming user groups could be a suitable approach here.”
“So we know the advantages, but there are blockages and we have to discuss that with each other,” says Smits.
Smits sees starting a dialogue as the first step in tackling other challenges of the new modernisation as well. Because although technically there are a lot of possibilities thanks to software, many navies are not equipped for it. “Everything, including Thales, is geared towards innovation and creating new generation systems and then doing maintenance. Existing processes at many organisations are often not designed for regular adjustments of systems.”
Of course, the industry itself can decide to offer updates for forty years, but that is financially unfeasible in this market without a suitable contract. When engineers retire, start working elsewhere or focus on a new generation of radars, knowledge of specific systems evaporates quickly. “If after fifteen years a customer suddenly says: I want to do an update, then we are both disappointed. We have to say that we no longer have the people with that knowledge and the customer does not get the desired update,” explains Smits. “Because in order to retain knowledge, you have to keep working with the product.”
“What I think is very important is that there is a continuous dialogue between navies, knowledge institutes and industry in order to come to solutions together. There is already a particularly effective collaboration in the Netherlands, called Nederland Radarland. That model could be extended to the entire asset life cycle management, which therefore not focuses at how we develop a new platform, but also at how we deal with it once it is up and running.”
“Another thing is: what agreements do you make? If a navy says: I want to buy that flexibility for 20 years, that means for us that we have to keep that knowledge available. We then have to be able to offer software updates during that period, but we still have no idea what needs to be reprogrammed, so it has organisational, contractual, and implementation aspects that challenge the status quo on a number of points.”
In the Netherlands there is the so-called Golden Helix, consisting of the Defense/Navy, knowledge institutes and industry. As a result, there is often contact, so a dialogue about this new topic is relatively easy to set up. But what about this idea in other countries?
Not all navies handle their equipment in the same way, there are navies that only do maintenance when something breaks. Other navies have highly professional maintenance organisations. But also the navies that now work with limited resources will sooner or later have to deal with the software possibilities that now come with, for example, the Thales NS-100 radar.
Thales already mention technological flexibility in tenders. Smits: “We describe the possibilities, but until now using them has been a separate transaction. To use the full flexibility, you want to move towards a relational model, in which we set up a basic technical capacity and you use an organised discussion platform together with the user decides what the correct updates will be.”
“Because,” Smits continues, “that is the way to achieve this. If you do not enter into a partnership, customers may still benefit, but much more from the traditional model. For example, if a new function is developed, then the navies which entered the partnership benefit first. They, however, also to help determine who we can sell that update to. So it could very well be that if you don’t participate in such a discussion platform, you can’t benefit from the updates or that you have to pay the entire development costs.”
“You could organise this through a user group, in which multiple users of a product, together with industry, coordinate the upgrade roadmap of the product. You could see the international cooperation towards the development of the APAR as a precursor of such a user group.
Within the group, agreements were also made at the time, if another party were to be added.”
Does Smits already see concrete opportunities for this model in the future? Certainly: “For the new SMART-L MM/N, the technology is ready.”