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.

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

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 radar systems. 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 field,” clarifies 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.”

The main challenge is to keep the systems qualified at all times. After a system has passed all operational tests, customers tend to become very wary of even the smallest modifications. Which is perfectly understandable considering that some of the radars are critically connected to heavy weaponry. So, at the very least, Thales 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.”

The software engineering team in Hengelo is exploring several means to this end. “We’re looking into the communication between the different 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 affect the components on the other side of that interface, in turn affecting the components they’re talking to, and so on. One little modification could thus cause a tidal wave flooding the system. Building on the Comma framework developed in collaboration with Philips and TNO-ESI, we’re working on ways to keep the changes local.”

Another research project addresses the security considerations of software updates in the field. “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 verify that Thales is indeed the source and if so, to automatically and securely install the new software version while remaining operational and qualified.”

Software flexibility

All these efforts, 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 ramifications, 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.”

The same mechanism could be used to fence off 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-defined security all presume that I can reason about my solution and, moreover, coordinate the required changes.”

Opening up

This 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 Thales. “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. This pressure cooker is expected to deliver its first 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. The move to systems that are always-on only adds to the complexity. Keeping them resilient, also over time, is our main challenge.”

 

 

Want to learn more about what it feels like to work at Thales? Looking for a job at a true high-tech company in the Netherlands? Click here for our current job openings!