Digitizing the EFB, Flight Operations and Compliance

Author: Bruno Speck, Heads of Ops Support, Edelweiss Air

Subscribe

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 operational applications (figure 2).

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 use GoodReader to display manuals. These are also synchronized with mPilot, as we’ll discuss in more detail below.

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

As can be seen in figure 3, documents are 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 have to manually implement our naming convention, which frequently leads to mistakes, mainly due to documents being published by editors and publishers that don’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 are able to locate the necessary information in a timely manner.

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

One way is for the documentation to be automatically synchronized with Lido/mPilot via an API (Application Programming Interface). However, results are rather unreliable since, at times, SharePoint fails to execute the upload correctly. The second method syncs 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 is not really a workflow that we can stick to and by no means a reliable alternative to a workflow-based IT system.

WHY CHANGE THE SYSTEM?
We really want to get rid of the fixed file names for the sake of organizing files more reliably and to avoid editors publishing 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’d also prefer to avoid the extensive publisher training from the past and would instead rather prefer a system that carefully controls what and how content is published. As alluded to before, the process of syncing documentation to mPilot is not reliable and, on the GoodReader App, there is the potential issue of altering files by accident and pushing these changes back to the document library. Another issue that we face with GoodReader is that it doesn’t provide a full text search functionality, which surely would be advantageous to have. All things being considered, we certainly want to achieve reliable document synchronization to one single App in the future. Yet another priority is to limit the number of sources for revision inputs and to manage approval processes by means of document specific workflows.

REQUIREMENTS
Given all of the above, what are the requirements established for a new system at Edelweiss Air? We need the new system to include the following features (figure 5).

The new system needs 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 want the possibility to publish to different file types (e.g. PDF), we want documents to be based on an XML based structure via an editor that allows users to specify documentary units (DUs) that can be easily controlled. Furthermore, the visible content of a given document should 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 will facilitate demonstrating how changes are managed and on what grounds changes were issued to begin with. Last but not least, we would also like for DUs to be directly linked to the corresponding regulation (e.g. IOSA) whenever that applies, and to receive automatic change requests whenever the official counterpart changes.

YONDER MIND
After researching the market, we came to the conclusion that Yonder Mind (YM) is the content management solution (CMS) best suited to our needs. It 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 YM and how we will work with it in the future. Figure 6 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 6) and filters (figure 7) to make it easier for crews to get straight to the information that they need. This custom role-based content view will be pre-set by our active directory. For A320 pilots, there will be a mark both on the A320 and cockpit field, ensuring that they’ll 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 7 shows the filters that we’ve decided to use for the OM-A: ‘Best Practice’, ‘Policy’, ‘Procedure’, and ‘Winter Ops’.

Document Revisions

Each and every information module can be accessed by means of clicking on the corresponding chevron displayed on the right-hand side of a given module (see figure 6 and 7 for examples). By clicking on a chevron, users can pull up additional information about the module at hand. It’s also where qualified users can issue change requests (figure 8), namely by clicking on the ‘CHANGE REQUEST’ tab and choosing the appropriate option.

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

We decided that we will 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.

Figure 9 shows an example of one of these workflows, namely the minor one. It’s key to understand that it is during the ‘In Analyze’ stage where the responsible person (Document Owner in this case) can classify the change request coming from a given user. Hence, this is where we decide whether to classify a change either as an editorial, minor, or major change. Depending on the classification, the workflow will branch out differently thereafter; in the case of figure 9, we get to see what that would look like for the minor workflow in particular. What follows are the respective steps necessary to approve a given change. During each of the stages (‘Preconsultation’, ‘In Edit’, ‘Internal Approval’), there’s a defined set of stakeholders (or roles) that can jointly discuss the change in detail and one that can move the workflow along. During the ‘In Edit’ stage for example, it is the Editor that can trigger the action ‘Request Approval’ to progress to the ‘Internal Approval’ stage of the workflow. Since all of the discussions and decisions are made within the system, a seamless audit and revision trail is available at all times.

Once the 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 only 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 10 shows a generic example of a Yonder Mind 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
Once we have all Edelweiss Air manuals in Yonder Mind, we will also tag them for regulatory compliance (figure 11). In fact, we’ll be 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 Mind 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 Mind 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. Also 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 Mind 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 set up to manage the entire document management life cycle without exception.

With that being said, 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.

Contributor’s Details

Bruno Speck

Bruno Speck has 30 years’ experience in the industry, starting as a Swiss Air Force pilot before transitioning to Swissair as a commander on the A320 and A330. Today he is a Captain and Type Rating Instructor on the A320. With a BA in law from the University of Zurich, Bruno flies fighter jets as a reserve officer. At Edelweiss Air, he leads the Flight OPS Support and Engineering team, responsible for the EFB and compliance for relevant operation manuals.

Edelweiss Air

Edelweiss Air is a Swiss leisure airline and the sister company of Swiss International Air Lines. It operates flights to European and intercontinental destinations from its base at Zurich Airport. The long-haul fleet consists of four Airbus A340-313 and two Airbus A330-300, while ten Airbus A320 serve short- and medium-haul routes. When necessary, the fleet is extended by SWISS aircraft types with a SWISS crew.

Yonder

Yonder has over 15 years’ experience with electronic documentation in aviation. The business calls on the diverse backgrounds of team members to bring operational documentation and manufacturer manuals together in one solution. Pilots work with the easy-to-use YM Offline App and profit from role-specific revision updates. While editors create and enhance content in the YM Editor, revisions become manageable thanks to the fully integrated YM Workflow. Company guides can be created without having to worry about duplicates anymore and regulations are never missed thanks to Yonder Mind’s IQSMS connector.