What is ACARS?
In a nutshell, Aircraft Communications, Addressing and Reporting System (ACARS) is a digital data link system for the transmission of messages between aircraft and ground stations, using primarily VHF, but also more recently a variety of new technologies (satcom, HDF, cellular, future AoIP). ACARS is central to most aircraft related operational processes.
ACARS messaging generally covers three types of content:
ATC messages include clearances and instructions to aircraft. They are often used to deliver pre-departure, datalink ATIS and enroute Oceanic clearances. AOC and AAC messages are used for communications between an aircraft and its base.
These messages may be of a standard form or as defined by users, but all must meet at least the guidelines of ARINC Standard 618. Any message content is possible, such as:
- Aircraft final load and trim sheets
- Weather/NOTAM information
- Aircraft status, position, ETA, and any course diversions
- Weather observations from aircraft sensors
- Technical performance data (e.g. exceedance or abnormal aircraft system status)
- Catering uplift requirements, special passenger advice, etc.
- Free text messages
ACARS was modelled on the Telex System. The system architecture is based on three main components: aircraft equipment, datalink provider and ground processing systems.
Aircraft equipment
ACARS equipment onboard the aircraft is called management unit (MU) or, in the case of newer versions with more functionality, communications management unit (CMU). These function as a router for all data transmitted or received externally and internally. The ACARS MU/CMU can automatically select the most efficient air-ground transmission method if choice is available.
Ground processing systems and aircraft operators
Ground System provision is the responsibility of either a participating ANSP or aircraft operator. Aircraft operators would often contract out the function to a DSP or to a separate service provider. Messages from aircraft can be pre-configured according to message type, so that they are automatically delivered to the appropriate recipient. Below are some examples of types:
What is it used for?
ACARS data is used for a variety of purposes, such as maintenance analytics, flight operations, safety monitoring, fuel management, ground operation, ops planning, etc. It’s one of the “mission critical” data sources for aviation. This is how the aircraft “talks” to the ground and sends updates about its flight status, various systems and components. And this is how the ground systems can communicate with the aircraft equipment and send updates to the crew.
However, working with the ACARS data is not straightforward. Airlines and operators will have different means of interacting with it, depending on how advanced their internal processes and data systems are. For some, ACARS source data may only reside with the DSP and is made available to the airline via the DSPs dashboard, but not as a downloadable extract or via an API. Others will already have a well-established process for accessing and storing the ACARS data in their own repositories as a raw data dump.
Even though the data standards are defined, there is enough variation in the datasets to get many an expert to pull their hairs out. Data quality, lineage and completeness are a constant challenge. On top of that, ACARS data is not used in isolation either. It is combined with multiple other data sources, mostly manually.
There is no real time analytical capability in the current state of play. You can observe trends and patterns, investigate past events, create static dashboards. But live decisions that would allow proactive management of events as they unfold aren’t possible due to the sheer complexity and cost of integrating ACARS data in a true real time fashion. But that is exactly where the value lies for airlines and their partners.
Imagine, live passenger and baggage information is fed to the ground handlers down at the destination so that the necessary specialty equipment can be made available at the correct gate at the exact time it is needed there so that delays can be avoided. Both the airline (and passengers!) and the ground operator will have a much better turn around experience that saves them time, money and resources.
Planning alone doesn’t address these issues as each day presents different challenges and surprises. The airlines have to be able to deal with the events as they unfold. They insert generic sizable “firebreaks” into schedules to create buffers, which are extremely expensive. Real time data analytics can allow them to reduce these firebreaks and perhaps even shorten turnaround times – planes sitting on the ground do not make money!
This is where IOblend can help
IOblend can fully automate and streamline data collection, processing and management of the ACARS data for the airline. We can connect directly to the DSP via their API or, if not available, request the DSP to provide the data in flat files for a secure download in real time. We can stream data from any source.
Our solution will evaluate the raw ACARS data with respect to data quality attributes: completeness, consistency, accuracy and timeliness – all in memory (cloud or prem). There is no requirement to “land” the data in an intermediate repository (e.g. data lake) for manual processing and enrichment or apply any other data management or transformation toolsets – IOblend does the full ETL end to end and can send the output back to the original systems just as easily (e.g. live updates to the EFB). Persist only what you need.
IOblend pipelines will process the business logic of any complexity (i.e. any integrations are possible). We approach the pipeline design in a modular way and can easily switch on/off various elements, define execution sequences and dependencies, add/remove data sources, and modify transformations. The ACARS data can also be enriched with additional internal and external data, computed fields and/or reference data “in flight”.
Once the business logic is integrated, IOblend does everything else automatically, batch and streaming in the same pipeline. IOblend ensures that only “good” data is used for analysis, meaning the solution will perform a number of processes to get the data into a production-grade state.
Example
Common flight data comes from a variety of operational systems, meaning the ACARS data can be supplemented with additional information in real time to provide a richer analysis. In the case of the airline operational data relating to a flight (other systems such as FMS, AMOS, Flight Ops, Flight Planning, Scheduling) these usually are:
- Flight designation
- Datetime
- Equipment
- Orig/Dest
- Crew ID
These fields drive the design of the primary keys that are then used to combine the data from any of the sources (or backfill missing data fields). IOblend automatically monitors data quality issues in real time. If the DSP fails to provide the data on time or the arrives corrupted, IOblend will highlight the missing records and attempt to automatically reacquire them from the main source. Failure to do that within parameters will trigger another process that will fetch the missing data from a specified secondary/tertiary/etc source (and log the data record origins).
The power of IOblend
Once the data has gone through the pipeline successfully, it can be used by any down route system or process to drive decisions. We connect to anything, ever your favourite Excel.
All data is archived. Nothing is ever lost. Every record has detailed lineage information and can be easily traced for audit purposes. This is especially important for any potential flight incident investigations.
And the best part is, you don’t have to spend months and months designing, coding and maintaining your data pipelines. The pipelines are not “fixed in stone” either. The SMEs themselves can easily develop the pipelines further (and create new ones) as they see fit and adapt to the changing requirements of the business.
IOblend is a drag-and-drop solution that allows you to create very complex data pipelines in a fraction of the time. Welcome to the next generation of data integration tools.
IOblend is a highly scalable platform, able to handle large amounts of data and lots of small data, batch and streaming. It has been developed on top of Apache Spark, the world’s most powerful data framework, and uses a Kappa architecture.
IOblend has been designed as a no-code/low code solution to greatly accelerate pipeline development. All created assets and templates are stored in JSON files and can be easily searched and re-used to further streamline development. Once the solution is running, very little supervision is required due to the high degree of system automation. You manage your ACARS data issues “by exception”.
Step-change your development effort and cost. What took months now takes days. Totally platform-agnostic. The advanced data capabilities you wished you could have in your airline, are now within easy reach.
Curious? Get in touch. Let’s discuss how we can propel you ahead of your competition!
Unlock new capabilities with real time ACARS data
In this short article we are looking at one of the key data sources for the aviation industry – ACARS – and how IOblend helps to unlock new analytical capabilities from it.
Time to automate your airline’s DOC data
How to automate Direct Operating Cost (DOC) data collection, processing and serving with IOblend.
Automate airline fuel data collection & management
Collecting and managing airline fuel data is complex and time consuming. IOblend can greatly streamline the process and enable real-time decisioning.
The Data Mesh Gotchas!
I think most practitioners in the data world would agree that the core data mesh principles of decentralisation to improve data enablement are sound. Originally penned by Zhamak Dehghani, Data Mesh architecture is attracting a lot of attention, and rightly so. However, there is a growing concern in the data industry regarding how the data
IOblend Data Mesh
IOblend Data Mesh – power to the data people! Analyst engineering made simple Hello folks, IOblend here. Hope you are all keeping well. Companies are increasingly leaning towards self-service data authoring. Why, you ask? It is because the prevailing monolithic data architecture (no matter how advanced) does not condone an easy way to manage the
Data lineage is a “must have”, not “nice to have”
Hello folks, IOblend here. Hope you are all keeping well. There is one thing that has been bugging us recently, which led to the writing of this blog. While working on several data projects with some of our clients, we observed instances when data lineage had not been implemented as part of the solutions. In