Creating software to keep naval systems always-on

Imagine a system that, once turned on, will stay on for the rest of its life. Neither hardware failures nor code glitches can bring it down. At Thales, chief software architect René van Hees is putting his shoulders to the wheel to make this dream a reality.

Nieke Roos

“C ompanies like Tesla have set a new standard in software development. With a mere update over the air, they’re able to cut 6 meters o their cars’ braking distance at 100 km/h. at’s really something – we’re talking about millions of vehicles that have to remain safe to drive,” says René van Hees from ales. “Who’d have thought ve years ago that we’d be changing the functionality of our critical systems on the y?”

Chief software architect Van Hees is pushing hard to adopt a similar approach for naval systems. “We’re becoming much more software-intensive as well, with software playing an increasingly important role in our radars. New features are more and more enabled by software, while the hardware remains more or less the same. We’re heading towards a future where, once we’ve deployed a system on a ship, we’ll be adding functionality exclusively through software updates.”

Design for change

To get to that future, there are still some choppy waters to navigate. “For one, it means that we need to drastically increase the frequency with which we deploy new software versions to our systems in the eld,” clari es Van Hees. “Instead of doing a big bang every six months or so, we need to move to very frequent, very small, very local updates. Within our software development department, we’re already integrating continuously, ie adding new features to our software baseline every day. We’re looking to roll this out to the system level and eventually to the customer.” e main challenge is to keep the systems quali ed at all times. After a system has

passed all operational tests, customers tend the source and if so, to automatically and to become very wary of even the smallest securely install the new software version modi cations. Which is perfectly under- while remaining operational and quali ed.” standable considering that some of the radars are critically connected to heavy weaponry. So, at the very least, ales needs to be able to give the absolute guarantee that adding a new feature will allow operations to continue. Van Hees: “Such a task is far from trivial for software that’s so dependent on hardware. Design for change is key.” e software engineering team in Hengelo is exploring several means to this end. “We’re looking into the communication between the di erent software components,” gives Van Hees as an example. “If we update one such component and one of its interfaces changes as a result, this might a ect the components on the other side of that interface, in turn a ecting the components they’re talking to, and so on. One little modi cation could thus cause a tidal wave ooding the system. Building on the Comma framework developed in collaboration with Philips and ESI, we’re working on ways to keep the changes local.”

Another research project addresses the security considerations of software updates in the eld. “Wherever the system is, we need to make sure that it only gets the updates we want it to,” explains Van Hees. “We’re exploring ways to enable the system to verCredit: Thales ify that ales is indeed

Software fl exibility

All these e orts, and more, come together in Van Hees’ BHAG, big hairy audacious goal – building systems that are always-on. “My vision is to have a system that, once turned on, will stay on for the rest of its life. Hardware parts may break or go obsolete, software components may crash or be corrupted – nothing can bring it down. To get there, however, we have our work cut out for us. It has all kinds of rami cations, for software development as well as system design.”

Hardware is bound to go obsolete, for example, so at some point, a new processing board or module would have to be put in. “Since the system is always-on, I’d need to add the hardware at run time,” Van Hees points out. “It’s then up to the software architecture to manage this and keep the system up and running.”

The system also needs to be prepared for new features and the associated added complexity – like the Tesla update reducing the car’s braking distance. Van Hees: “I could deal with that by expanding the hardware, but I could also be more flexible in the software I’m running on my existing hardware. Based on the circumstances, I could redistribute my processing power from features that are less essential at a given moment to functionality that’s critical. Maybe I don’t need to be able to see 2,000 kilometers all the time and, for a short period, 150 kilometers is far enough. During that specific window, I could then allocate more resources to more demanding tasks.” e same mechanism could be used to fence o cyberattacks, Van Hees goes on to philosophize. “For this to work, my security would need to be completely implemented in software, though, which isn’t yet the case. Periodic updates, design for change and software-de ned security all presume that I can reason about my solution and, moreover, coordinate the required changes.”

Opening up

is vision of always-on systems, together with the software strategy to get there, is one of three pillars supporting Van Hees’ work as a chief software architect at ales. “But I’m going nowhere without skilled people,” he notes, introducing the second pillar. “As good software architects are extremely hard to get by, we’ve decided to train them ourselves. With Luminis, we’ve set up the Accelerate program: in 18 months, select mid-level software engineers have both their technical and human skills cranked up to senior level. is pressure cooker is expected to deliver its rst batch of twelve technical leaders come November.”

Van Hees’ third pillar is collaboration. “We simply can’t do everything ourselves so we need to work together. Collaboration in education, as illustrated by our Accelerate partnership with Luminis, which was born out of a mutual need for senior people – I’d like nothing more than to open up the program to other companies. But also, collaboration in sharing knowledge and technology. Take Inaetics for example, our dynamic, service-oriented software architecture. It was developed in a publicly funded consortium. We’re now looking to forge similar partnerships with companies to open-source it and broaden its application where feasible.”

“Our systems no longer operate on their own,” Van Hees concludes. “As the world around them is growing more complex, so are they. e move to systems that are always-on only adds to the complexity. Keeping them resilient, also over time, is our main challenge.”