How MissionLink Supports Integration & Interoperability of the CarteNav Ecosystem

The CarteNav Ecosystem

The CarteNav ecosystem is a software suite comprised of two systems: AIMS-ISR and AIMS-C4. And as Scott Richardson, VP of Product at CarteNav, pointed out during the broadcast  “our software is ITAR-free, which lets us do our solutions internationally. We have well over 125 customers in 60 countries, and 600 plus deployments.”

For the local operating picture there is AIMS-ISR. It is a geo-referenced, moving maps application which generally runs on a computer next to the operator on a variety of platforms (e.g., ground, airborne, fixed wing). Its plugin architecture allows for mission flexibility by accommodating a variety of sensors. What’s most important is that it can both control sensors and display their information (like radar tracks). According to Scott “For us, it’s really about sensor control and how do you get information from these powerful sensors to someone that needs to make decisions.”

The ISR system is built to be a mission system framework of technologies and applications which makes it modular, configurable, and interoperable.

For the common operating picture, there is the AIMS-C4. It is a browser-based application, hosted on a server, and available to anyone with the proper credentials. The system is the nexus for near real-time data distribution, both to and from AIMS-ISR systems, as well as other third-party systems. With C4, users can share and archive data, review and analyze information, and generate reports. A new feature recently added to C4 is the ability to create and manage points of interest.

The Ecosystem Challenge

The goal of any ecosystem is to be seamless, extendable and scalable. In the case of CarteNav, with AIMS-C4 as the hub, that means interfacing with the AIMS-ISR system, as well as other third-party ISR systems. It also means being able to accommodate many different sensors and sensor types.

So, the ecosystem challenge is really a communications challenge. And if the goal is to be able to seamlessly coordinate between mission systems, efficiently, then any solution to the ecosystem challenge will have the following properties:

• Real-time communication
• Synchronized communication
• Bi-directional communication
• Low-bandwidth
• Easy for third-parties to integrate
• Always on
• Simple, lightweight and extendable

With these features in place, an ecosystem could be platform agnostic while being able to unify data exchange across all the platforms. Does such a communication solution exist? It does now, and it’s called MissionLink.

The MissionLink Solution

MissionLink (MLink) can be thought of as a new component to the already existing software suite (AIMS-ISR and AIMS-C4). According to Scott, “MLink is essentially a lightweight Rust application that gets deployed as MLink server nodes. So it has an ability to have people get or post messages over HTTP.”

The way the rest of the ecosystem interacts with the C4 is via the MLink API. The MLink API offers the ability to integrate any sensor, on any platform, and share the real-time mission picture across various teams. And it does so securely from any location. To learn more about how the MLink API functions, check out the broadcast here.

With built-in API and protocol support, MLink reduces the complexity, time, and cost of third-party integrations. MLink simplifies the integration of mission systems by providing system integrators with this built-in API, standardized interfaces, and protocol compatibility. This makes it easier to connect various sensors, platforms, and communication channels.

MLink also secures mission data, ensuring the data remain protected during transmission. And using advanced synchronization protocols, it maintains data accuracy, even in challenging network conditions. This provides reliable data delivery in difficult operational environments.

With MLink, users can consolidate sensor and platform data into a single operational hub by using high-throughput data aggregation and storage systems. It enhances overall mission efficiency by providing seamless access to live and historical data, supporting analytics, mission planning, and real-time operational adjustments.

How MissionLink Works 

MLink works just like any other REST API: by using GET and POST messages over HTTP. APIs work by sending information using data structures like XML or JSON. For MLink, CarteNav, a PAL Aerospace company, has created a new technology to send and receive data using the API and it’s called AML: AIMS markup language.

According to Mark McManus, Software Architect, “AML is a newer technology that we’ve been working on here at CarteNav. And basically it’s an XML definition to define a user interface and to link that user interface up with our backend command system and modeling system to receive data. You can add functionality to these forms, these panels that you create through the XML definition using Lua script. So, for anybody who’s familiar with HTML and JavaScript development, web development or web page development at the simplest level, this is similar support within AIMS.”

So, by using AML to define a user interface to C4, the resulting interface will automatically inherit the look, feel, theme, and stylings of AIMS. This avoids the complexity of having to define the user interface with a compiled language like C++.

Consequently AML can be used to create things like custom camera and radar UI panels. That includes functionality down to the menu and overlay systems (i.e., details that show up on maps and menus). All of that is defined in AML. In fact, many of the camera and radar UI panels in AIMS-ISR are already using this technology. The real change is that it is now being made available externally for users and integrators.

With the extensibility of AML, MLink can be used by the C4 to ingest information in different formats and protocols, repackage it, and send it back out to a third-party or back to a deployed ISR. And all at very low bandwidth. In this way, MLink can be thought of as sequenced events with attachments. Attachments that may be of interest to different users.

It is clear that MLink does a good job of addressing the features required to seamlessly coordinate between mission systems, as previously detailed. It offers real-time, synchronized, bi-directional communication. It is low-bandwidth, always on and is easy for third-parties to integrate.

MissionLink Use Cases

One use case for MLink is a sudden route change. As Scott shared in the broadcast, imagine “we’ve been flying for a little while, doing a planned surveillance route. I was just supposed to fly along the coast, when lo and behold, we had a report of some environmental concerns from a ship. So, a third-party has now passed on to us a route that they would like to make sure the aircraft has covered.” This can all be done via MLink.

The ship can send a GPX file via MLink to the C4. The C4 will recognize the route change and post that to MLink. The AIMS-ISR will receive the event, along with the attachment, and immediately recognize that there has been a new route shared.

Another use case is to use the C4 as a planning mechanism. In this case the C4 sends a route to an ISR via MLink. If the ISR user accepts the task, the ISR is immediately populated with the route and the notice is posted back to C4 via MLink which updates its view accordingly. Data continuity is assured so both parties see what is happening with the same picture.