Ara Guides

These guides explain how to use Ara to exchange real-time data with your systems and your consumers.

From a business standpoint, Ara is a real-time data concentrator. It collects data from one or more source systems (CAD/AVL, SIRI servers) in SIRI, SIRI Lite or GTFS-RT, normalises it, then broadcasts it to consumers (passenger app, Open Data, etc.) in those same protocols.

Each system Ara exchanges with is represented by an Exchange Partner, configured through connectors that enable the desired services.

Ara's models

Ara works on models, its internal representations of transport objects (stops, lines, vehicle journeys…). Collection feeds them by normalizing incoming data; broadcast exposes them, translated into SIRI or GTFS-RT. Identifiers (codes), collection filters, identifier generators, etc. all apply to these models.

Model	Definition

Model	Definition
StopArea	A stop point or stop area
Line	A commercial line
VehicleJourney	The planned trip of a vehicle on a line
StopVisit	A vehicle journey's visit to a stop (expected / actual times)
Vehicle	A vehicle tracked in real time (position, occupancy)
Operator	The operator of a line or vehicle journey
Situation	A passenger message or disruption (GeneralMessage, SituationExchange)
Facility	An in-station facility (lift, escalator…)

Choosing the right guide

Every exchange has a direction — collect (Ara is the client) or broadcast (Ara is the server) — and a protocol. The table below points to the matching guide.

Need	Direction	Protocol	Guide

Need	Direction	Protocol	Guide
Ara must collect data from a CAD/AVL or a SIRI server	Collect	SIRI / SIRI Lite	Collect real-time data with Ara via SIRI interface
Ara must collect a remote GTFS-RT feed	Collect	GTFS-RT	Collect real-time data via a GTFS-RT interface
A remote system must consume Ara's data over SIRI	Broadcast	SIRI / SIRI Lite	Broadcast real-time data using SIRI
Broadcast data in GTFS-RT	Broadcast	GTFS-RT	Broadcast real-time data in GTFS-RT
Broadcast open data to transport.data.gouv.fr	Broadcast	SIRI	Broadcast real-time data in SIRI to transport.data.gouv.fr

Request or subscription

In SIRI exchanges, two modes are possible:

Request: the client queries the server on demand (for example GetStopMonitoring) and receives an immediate response.
Subscription: the client subscribes once, then the server pushes notifications over time (for example NotifyStopMonitoring).

When the remote system supports subscriptions, this mode should be preferred: it is more efficient and delivers data continuously.

SIRI credentials: `remote_credential` and `local_credential`

Two identifiers govern the identity of the parties in SIRI exchanges (GTFS-RT, described below, follows a different model). The rule applies identically in both directions:

remote_credential is Ara’s identity towards the partner.
local_credential is the partner’s identity as seen by Ara.

Depending on the direction of the exchange, these identities are carried by the RequestorRef or the ProducerRef field of the SIRI messages:

Summary table:

Setting	Meaning	Broadcast (Ara = server)	Collect (Ara = client)

Setting	Meaning	Broadcast (Ara = server)	Collect (Ara = client)
`remote_credential`	Ara’s identity towards the partner	`ProducerRef` of the responses / notifications sent by Ara	`RequestorRef` sent by Ara to the partner
`local_credential`	The partner’s identity as seen by Ara	Incoming `RequestorRef` → identifies the partner	`ProducerRef` expected in the responses / notifications sent by the partner

local_credential identifies the Exchange Partner on incoming exchanges: the received RequestorRef is matched against it. It is therefore required as soon as Ara receives requests from that partner (broadcast, or a server connector such as CheckStatus Server in collect) and must be unique among the Partners of a given referential.

The GTFS-RT protocol

Besides SIRI, Ara supports GTFS-RT, both for collect and broadcast.

GTFS-RT relies on a polled feed (HTTP retrieval of a feed) rather than on RequestorRef / ProducerRef exchanges: the SIRI credential model described above does not apply.

For collect, Ara polls the remote feed: it needs the feed URL (remote_url) and the remote_code_space; if the feed is protected, the token is usually included in the URL.
For broadcast, remote_code_space is the only required setting and remote_credential is not used; local_credential is optional and acts as an access key for a private API (by default, the feed is public).

Secure exchanges

Network exchanges must be open between the remote SIRI HTTP server and the Ara SaaS servers. The remote interface must be reachable from the Internet on a public IP. Requests to Ara are made exclusively over HTTPS (https://ara-api.enroute.mobi).

Ara’s IP address is 104.199.25.59.