Considering your company’s area of activity, what was your motivation to participate in H2020 project ADMORPH?

Thales Nederland B.V. has been involved in the development of surveillance systems, both for civil and military purposes, since the early days of radar technology. This gives the company the know-how to build all kinds of surveillance systems, ranging from short-range 2D radars to long-range 3D radar systems from which stealthy targets cannot hide, and sophisticated multifunction radars using active phased array. Apart from radar systems, Thales Nederland B.V. also manufactures passive infrared surveillance systems, meant for radar silent operations.

These systems provide crucial situational awareness for command and control decisions, which can have far reaching impact on the vehicles carrying the surveillance systems, their crew and their surroundings. Because of this, the data on which these decisions are made needs to be highly accurate and reliable. To achieve this the surveillance systems have to be able to rely on trustworthy and robust real-time data processing. This requirement combined with the promise of the ADMORPH approach to achieve fault tolerance sparked our interest to participate in this project.

The ADMORPH project foresees the following three use cases: autonomous aerospace systems, radar surveillance systems and subway transportation systems. Can you explain in more detail the use case that you contributed to the project or in which you are more involved? Which challenges does it raise?

Figure 1: Example of a modern phased array radar system

The radar surveillance systems use case provides a laboratory set-up of a highly simplified radar processing chain running on a realistic processing platform, utilizing lightweight container virtualization in combination with an orchestration framework, where software updates are automatically identified and installed in a secure way using an update framework. In this use case, our primary interest is the coordination language to specify adaptive systems alongside adaptive runtimes. This approach ensures formal guarantees and facilitates comprehensive testing of the processing chain and the runtime system itself.

The challenge in this use case is to see if the ADMORPH approach can be applied to an application which’ components run distributed on an embedded networked multi-node system, instead of on multiple cores on an embedded system on chip (SOC).

The project started just before the COVID-19 pandemic and is now nearing completion. How do you feel the pandemic affected the project development (if at all)?

At the beginning of the project, the pandemic mainly hindered effective exchange of information between project partners, which was solved by using online collaboration tools. However, these forms of communication do not completely replace face-to-face communication.

Another area in which we were affected was when we needed to ramp up the size of the team to implement the demonstrator of the use case. Due to the restrictions on being allowed to meet each other it was more difficult to hire staff for the project, and once hired, introducing them to the way of work and the contents of the project was less effective than expected because all processes regarding information transfer were still oriented towards face-to-face transfer and had to be adapted to online means of communication on the spot. This took both extra time and proved to be less effective than the existing means.

Despite being less effective, it surprised us in a positive way how much still could be achieved using online tools, once they were properly in place. Working with techniques like this, while not completely replacing face-to-face information exchange, can certainly be a valuable addition to collaborating teams, especially once the project members are familiarized with each other.

As the project comes to an end, how would you describe the state of integration of ADMORPH technologies in the use case you are working on?

The level of integration with the AMDORPH architecture is a good fit. We recognize the same levels for control, monitoring and adaptation, and the update framework that has been selected and instantiated as part of the ADMORPH runtime system has been integrated successfully in the demonstrator. The level of integration with the actual ADMORPH technologies is low, as was to be expected: the main set of ADMORPH technologies, despite being very interesting, were either outside the scope of our use case or were developed for systems characterized by utilizing embedded multi-core SOCs, so in that context we did not expect a direct match for our system of multiple networked nodes.

The primary ADMORPH technology of interest for our use case, the coordination language, appeared to be less of a match than expected. This was not due to differences in the runtime environment, distributing components over multiple cores appeared to be similar enough when compared to distributing them over multiple nodes, nor a lack of features in the coordination language, but more to the assumption about the nature of the components that comprise the application. Where the coordination language has been designed for components utilizing stream based communication, the radar processing chain is built on components that are communicating state machines, invaliding formal guarantees that come with stream based processing.

Looking ahead, which of the ADMORPH results you see with more potential for exploitation? Do you plan to exploit any of them?

Even though the coordination language in its current form cannot be applied directly to model an application consisting of communicating state machines like the radar processing chain application, there are certainly some aspects that are interesting for further exploration within the context of our use case. Having non-functional aspects, like latency requirements, security levels or even multiple implementations of a single component, as part of the design model is something we already have identified as something we might need and the ADMORPH approach could certainly be used as inspiration of how to apply this in our own development environment. Especially the elegant solution to model the state of a component as part of the design, thus enabling relocation with retention of state, is something we will probably look in to.