A Modular .NET Gateway for Naval Radar Simulation

Fabio Romano

Degree in Computer Science · School of Mathematical, Physical and Natural Sciences · Internship thesis

Background on the radar equipment is in the preliminary paper on the SharpEye radar, which is best read first.

1. Introduction

1.1 Context and objectives

This work reports on the internship project of developing a protocol gateway for the communication of naval radar equipment. The task was to convert messages written in the ASTERIX protocol into messages of a proprietary protocol that Cetena S.p.A. uses inside a naval simulation software.

The fundamental requirements were modularity and scalability. The interpretation of messages would later have to be added and removed, so the architecture had to accommodate such changes without being redesigned.

1.2 Host organisation: FOS S.p.A.

FOS was founded in 1999 and offers system integration and software development, application and infrastructure outsourcing, research, development and prototyping of innovative technological solutions, and telecommunication services. It operates across industry, services, finance, healthcare and public administration. More recently, through a network of joint Internet of Things laboratories, it has promoted technology transfer in several industrial sectors.

1.3 Client: Cetena S.p.A.

Cetena was founded in 1962 as a Fincantieri company. It has several branches in Italy and its headquarters in Genoa. The company offers consulting services, specific products, and training and testing laboratories in the merchant and military naval sectors, and collaborates with Italian and European research centres. The high specialisation of its staff in their respective fields characterises the company in these sectors.

2. Background and Instrumentation

2.1 Radar principles

A radar (radio detection and ranging) is a system that uses electromagnetic waves to detect objects, fixed or moving, and to determine their position and velocity. Radars are employed in many fields; this work concentrates on the maritime and naval domain.

2.2 The Kelvin Hughes SharpEye radar

Kelvin Hughes is a British company specialising in the production and distribution of naval and surveillance technologies. The product considered here is the SharpEye, an advanced radar with noise reduction and Doppler effect management. Its setup comprises three components:

• Antenna. The device that transmits and receives the electromagnetic waves. It can be configured for sensitivity and range, and several antennas can work together to cover a larger area.
• Radar. The device that draws the map traced by the antennas. It gives the user an intuitive interface from which the antennas can be configured through a master-slave mechanism.
• KH laptop. A Kelvin Hughes laptop running software that simulates the behaviour and response of a real antenna without the antenna being physically present. This makes it possible to trace the packets exchanged by radar and antenna without owning a real antenna.

2.3 The simulation

The simulation reconstructs in 3D a harbour, its surroundings and several moving ships. The electromagnetic waves emitted by an antenna are simulated with ray casting: rays leave the ship in all directions, describing a circumference. When a ray collides with an object, a string stores the coordinates of the collision point, the position of the antenna at that moment and other data. Every second, several messages of the Cetena protocol are produced, carrying the information on the rays and their collisions.

2.4 Message types

The messages handled in this work fall into three categories:

• Video messages are sent from the antenna to the radar and allow the radar to draw the image scanned by the antenna.
• Status messages are sent from the antenna to the radar and report the state of the antenna.
• Control messages are sent from the radar to the antenna to control it. From the radar's user interface it is possible to change the image acquisition sensitivity, add filters to remove rain, change the rotation speed of the antenna and more.

2.5 Technologies and tools

The conversion software was developed in the .NET environment using the C# language. Two further tools supported the work:

• UDP listener. To transmit packets in real time, a tool was created that receives UDP packets and forwards them to all interested devices connected to the network. The IP addresses and ports of the devices to receive from and transmit to are provided in a JSON configuration file.
• Wireshark. An open-source, cross-platform packet analyser. It was used to trace the packets sent by the simulated radar and antenna, and proved fundamental to understand which messages, and how many, the two devices exchange to work correctly.

3. Design and Implementation

3.1 Preliminary study

Before the gateway was programmed, one week was devoted to studying the operation of the equipment in detail through the official documentation, which is entirely in English. This also provided familiarity with the technical terminology of the maritime and naval domain. After the documentation, simulators of a real radar and a real antenna were made available, which allowed practice with the user interface and the main commands. Once the equipment was understood, the functional and non-functional requirements were defined, using the technical proposal agreed with the client as a guide.

3.2 JSON handling

The gateway is made modular and configurable through a JSON file. To serialise and deserialise it simply, the open-source library Newtonsoft Json.NET was used, which supports the following main operations in a few lines of code:

• JsonConvert.SerializeObject(Object o) converts a .NET object into a JSON string.
• JsonConvert.DeserializeObject<T>(json) is a generic method that converts a JSON string into the specified .NET type.
• LINQ access to JSON content through the JObject, JArray and JValue objects provided by the library.

3.3 Interfaces

Several classes of the gateway share common functionality. Interfaces were therefore introduced to make the behaviour of these objects clearer and uniform:

• IReceiver abstracts a receiver. It contains the methods to connect to and disconnect from other transmitters, and the delegate that handles the event of a completed reception.
• ISender governs the objects that send messages over the network. It contains the method Send(message m), which sends a message, and a delegate that handles the event of a completed send.
• IModule abstracts modules. It contains the methods subscribe(IModule m) and unsubscribe(IModule m), which link two modules together.
• AbstractModule is an abstract class that implements IModule and handles the message update event.

3.4 Message queues

It became clear early on that the gateway had to receive and transmit a high number of messages per second while preserving the order in which they were sent and received. The requirements also called for video messages, which are sent at a high frequency, to be conveyed over UDP, and for status and control messages to be conveyed over TCP. The latter are sent less frequently, but their delivery must be guaranteed.

The most effective solution was to design and develop input and output queues that operate independently of, and decoupled from, the actual processing and conversion of the messages. The Transmitter class contains the classes that receive, transmit and organise messages in their respective queues. This is achieved by managing subscriptions to, and unsubscriptions from, the events of the receiver and the sender.

3.5 Packet verification

After the transmission and queueing system had been implemented, the packets exchanged by radar and antenna were verified with Wireshark. A setup consisting of the KH laptop (acting as the antenna) and the KH radar was cabled on the same network. The packets were traced, and their content and order of transmission were compared with how they were presented in the official documentation.

Some subtle differences emerged, which later proved fundamental to make the whole system work correctly. They were due to the fact that most of the documentation referred to a slightly different radar model from the one used.

3.6 Gateway architecture

One of the client's fundamental requirements was the ability to add and remove messages after delivery. The gateway was therefore made as configurable as possible through a JSON file that defines three categories of main actors: peers, modules and routes.

3.6.1 Peers

Peers are the components that communicate with one another, ensuring the correct sending, routing and reception of packets. A peer is defined by:

• name, a string that uniquely identifies it within the gateway;
• description, an arbitrary string that helps to understand the role of the peer in the system;
• a sender or a receiver, either of which may be null. If it is not null, an IP address and a port must be assigned to it.

3.6.2 Modules

Modules are the representations of the messages that the gateway must interpret and convert. Each message is usually represented by two modules: one for the message in the ASTERIX protocol, interpretable by the radar, and one for the message in the simulation protocol. A module is identified by:

• name, a unique string that identifies the module in the gateway;
• type, the path of the .NET class that is loaded at runtime through reflection and processes the message;
• configuration, an optional set of parameters needed to interpret the message correctly.

3.6.3 Routes

Routes create links between a module and another module, or between a module and a peer. They are built on the keywords from and to, whose values are the name of a module or of a peer. Routes make the gateway fully modular, because the paths along which messages are converted can be created or changed simply by editing the routes in the JSON file.

3.7 Runtime operation

Once peers, modules and routes have been configured, the program can be started. Start-up proceeds in four steps:

1. The JSON file is read, deserialised and parsed into objects of type Network (the list of peers) and of type Gateway (the lists of modules and routes).
2. A foreach loop instantiates, for each peer, a TCP or UDP transmitter and stores its reference in a dictionary keyed by the name of the peer. Since every transmitter must keep working in the background, each one is started as a Task.
3. All modules are instantiated. The program first checks that the module type in the JSON is not null and that a corresponding type exists in the code. It then uses the .NET Activator class to create the object of the type defined in the module. As with the transmitters, the references to the module instances are stored in a dictionary keyed by their names.
4. Following the directives in the routes, the program uses the names stored as dictionary keys to retrieve the transmitter and module instances and to link them. A link is created by subscribing to the events of the transmitters, which are raised whenever a message of a given type is received or sent.

4. Results

At the end of the three-month internship the gateway could connect the radar and the naval simulation easily and convert a large number of messages. Further messages will be implemented later, according to the client's requests.

5. Conclusions

Building software for a real client offered a new perspective on the organisation and development of a project of this kind and, above all, on the priorities to be considered. The prospect that the client will use the product, and that other professionals will improve it over time, provides a kind of satisfaction that is not found in work with purely educational aims. The internship was also valuable from a purely technical standpoint, as it improved the author's knowledge of, and experience with, the .NET ecosystem.