Digitizing of EFB, Flight Operations and Compliance

Bruno Speck, Head of Ops Support at Edelweiss Air, chronicles the airline’s transformation from static documentation to dynamic content management.

Edelweiss Air

Edelweiss (a member of the Lufthansa Group) operates 16 Airbus aircraft and serves over 70 destinations worldwide. We have about 300 pilots with 750 Cabin Crew, plus roughly 150 employees in the back office and administration. Looking at where we fly to (figure 1), the operation covers quite a large area. There are also a significant number of destinations throughout Europe, albeit not shown in the figure below.

The current EFB setup

Looking at our present EFB setup, we use iPads as electronic flight bags with the following applications (figure 2).

• Airbus FS+ (performance and ACFT manuals)
• Sabre eFM (flightplanning)
• LIDO mPilot (route material + manual access)
• Honeywell WIS (weather)
• IQSMS reporting (compliance and reports)
• GoodReader (manual access)

We have all of the OEM software from Airbus and FS+ for performance and aircraft manuals. In the flight planning domain, we use Sabre EFM for charting material and both Lido/mPilot and Honeywell WIS for weather information. Meanwhile, reporting is managed via the IQSMS reporting system. However, most noteworthy for the topic at hand is that we used GoodReader to display manuals in the past. These were also synchronized with mPilot, as we’ll discuss in more detail below.

In figure 3 you can see an example of how we presented documents to our pilots, namely via the Edelweiss Intranet that was based on a SharePoint site collection.

As can be seen in figure 3, documents were presented to pilots via a static library of PDF documents. While SharePoint may be a good collaboration tool, it certainly isn’t for publishing documents that need to be managed rather rigidly. For example: SharePoint doesn’t devise a naming convention nor does it check whether a given file name adheres to a pre-defined set of rules. Thus, we manually had to stick to our naming convention, which frequently led to mistakes, mainly due to documents being published by editors and publishers that didn’t necessarily adhere to the agreed upon naming convention. In fact, we had to address this issue by providing additional training and reducing the overall number of administrators in order to stabilize our setup and to ensure that crews were able to locate the necessary information in a timely manner.

When it comes to uploading files to our electronic flight bag (EFB), there were two ways on how Edelweiss has done this in the past (figure 4).

One way was for the documentation to be automatically synchronized with Lido/mPilot via an API (Application Programming Interface). However, results were rather unreliable since SharePoint failed to execute the upload correctly at times. The second method synced files from the Intranet to GoodReader. Unfortunately, we’ve also encountered some issues with that approach, since admins could alter documents on GoodReader and would then push them back into our SharePoint Library, thereby accidently changing files without adhering to our document revision processes.

Speaking of revision and approval processes: These were available to us by means of paper based Process Manuals, without a dedicated workflow tool at our disposal. To that end, change requests were usually sent to us either by email, physically by passing on a piece of paper, via the reporting system, and sometimes even orally over the counter. It goes without saying that this was not really a workflow that we could stick to and by no means a reliable alternative to a workflow-based IT system.

Why change the system?

We really wanted to get rid of the fixed file names for the sake of organizing files more reliably and to avoid that editors publish documentation that doesn’t adhere to our naming convention. At times, admins may have even put in a wrong file name altogether or uploaded a document in the wrong format (e.g. Word instead of a PDF). In short, there was room for improvement. We also wanted to avoid the extensive publisher trainings from the past and were aiming for a system that carefully controls what and how content is published. As alluded to before, the process of syncing documentation to mPilot wasn’t reliable and, on the GoodReader App, there was the potential issue of altering files by accident and pushing these changes back to the document library. Another issue that we faced with GoodReader was that it didn’t provide a full text search functionality, which surely would be advantageous to have. All things considered, we certainly wanted to achieve reliable document synchronization to one single App in the future. Yet another priority was to limit the amount of sources for revision inputs and to manage approval processes by means of document specific workflows.

Requirements

Given all of the above, what were the requirements established for a new system at Edelweiss Air? We needed the new system to include the following features:

• One publishing system for all documents
• XML based structure with the possibility to publish different kind of files (e.g. PDF)
• Custom role-based content view
• Customisable filters
• Customisable revision workflow (that can include external authorities, e.g. CAA)
• Document access control including read status of the users
• Seamless audit trail
• Regulatory compliance links

The new system needed to be capable of managing the entire documentation life cycle. Hence, from creating and publishing content, all the way to revising it based on document specific workflow and approval procedures. And although we still wanted the possibility to publish to different file types (e.g. PDF), we wanted documents to be based on an XML based structure via an editor that allows to specify documentary units (DUs) that can be easily controlled. Furthermore, the visible content of a given document shall be limited to display only information that is actually relevant to someone’s particular role and that can be dynamically filtered even further based on document specific metatags. Document specific workflows must ensure that we can reflect our internal revision and approval procedures without compromise. Moreover, such workflows must allow for inclusion of the Civil Aviation Authorities (CAA) on a documentary unit level, thereby enabling the collaboration with our CAA and allowing it to review changes in a transparent and efficient manner. The system must further allow to limit access to information based on user permission (document access control) and also provide insights on who has read what and when. A seamless audit and revision trail must be available at all times, in order to accommodate for CAA and IOSA (IATA Operational Safety Audits) related audits, which would facilitate demonstrating how changes are managed and on what grounds changes were issued to begin with. Last but not least, we also wanted to link DUs directly to the corresponding regulation (e.g. IOSA) whenever that applies, and to receive automatic change requests whenever the official counterpart changes.

The solution: Yonder

After researching the market, we came to the conclusion that Yonder is the content management solution (CMS) best suited to our needs. Yonder includes an easy to use XML editor that allows for the creation of DUs or information modules, in Yonder speak. Information modules are discrete units of information that can be further refined by means of adding additional information to them. In that sense, a document is merely a collection of such information modules, which brings about many benefits: Information can easily be copied (or referenced, in Yonder speak) between documents without physical duplication. Meaning that whenever the source module is being changed, it is automatically updated wherever it has been reused, thereby avoiding conflicting information and outdated duplicates that may otherwise be scattered across the documentation landscape. As briefly mentioned, a given module can also be enriched with metadata and tags, consequently enabling functionalities such as dynamic filter capabilities (e.g. limit visible content of a document for a particular role or topic) and linking modules to regulatory databases (e.g. IQSMS), to state but two examples.

Now let’s take a brief look at Yonder and how we work with it. Figure 5 shows an excerpt of Edelweiss Air’s Operation Manual – Part A (OM-A), including the custom role-based content view (the sidebar can be collapsed at any time of course).

We defined some roles (figure 5) and filters (figure 6) to make it easier for crews to get straight to the information that they need. This custom role-based content view is pre-set by our active directory. For A320 pilots, there is a mark both on the A320 and cockpit field, ensuring that they see exactly what they need according to their function. Users are of course able to change these settings on the fly, should they like to display all of the content instead, for example. Meanwhile, figure 6 shows the filters that we’ve decided to use for the OM-A: “Best Practice”, “Policy”, “Procedure”, and “Winter Ops”.

Once a user has issued a change request, relevant stakeholders are automatically notified based on the document-specific approval and revision workflow.

We decided to manage changes by having three available workflow options, depending on the scope of the change:

• Editorial, which is used for change requests with no real impact (e.g. misspellings);
• Minor Changes, for true content changes without concern to the Swiss CAA; and…
• Major Changes, for changes that need to be approved by the Swiss CAA as well.

So, whenever someone issues a change request, the responsible person (e.g. document owner) gets to classify the item either as an editorial, minor, or major change request. And depending on the classification, the workflow will branch out differently thereafter, thereby only involving the right set of stakeholders at the right time. Since all of the discussions and decisions are made right in Yonder, a seamless audit and revision trail is available at all times.

Once a change is “Ready for Publish”, we can even specify which stakeholders shall be actively informed about it, thereby allowing us to selectively communicate changes based on someone’s particular role. Hence, instead of having to go through lengthy highlights of revisions, users get notified about those changes that actually have an impact on their role and are therefore relevant to them. A given notification also includes instructions on whether the related information only has to be read or whether a given user group must actively acknowledge having done so. Consequently, the system is indeed capable of providing us with insights on who has read what and when. Figure 8 shows a generic example of a Yonder Dashboard including two such change notifications in the “My Tasks” section for a particular user, who may access the change details simply by clicking on the respective item.

THE Outlook – Next Steps

Now that we have all Edelweiss Air manuals in Yonder, we are also tagging them for regulatory compliance (figure 11). In fact, we’re able to tag and link EASA and IOSA standards directly to related information modules within our documents.

The beauty of this is that, whenever an EASA or IOSA standard linked to an information module changes, Yonder automatically generates a workflow for Edelweiss, prompting us to have a look at the regulatory change and to decide thereafter whether we need to amend the content of the information module to reflect the new reality and remain compliant.

So, looking again at the requirements formulated at the beginning (figure 5), let’s see if we actually have met them.

We wanted one publishing system for all documents which we have achieved. Yonder features an easy to use editor that provides us with the desired xml based content structure, consequently allowing for dynamic filtering, thereby also addressing the need for a custom role-based content view and for customizable topic filters. As well of importance is the customizable revision workflow that allows us to reflect our internal approval and revision procedures without constraints and ensures proper control over our entire documentation.

Since everything in Yonder is role-based, document access control is ensured by default, including the provision of insights on the read status of users for crucial information.

Regulatory compliance is covered to our full satisfaction by linking content within our documentation directly to corresponding EASA and IOSA regulations, automatically triggering a workflow for the information module whenever the official counterpart changes.

Lastly, a seamless audit and revision trail is available at all times, since Yonder Mind is setup to manage the entire document management life cycle without exception.

With that being said and considering just how user-friendly Yonder Mind really is, it is safe to say that Edelweiss Air’s transition from static documentation to dynamic content management has been a true success for all stakeholders involved.