Case Study: An iPad EFB Project at SmartLynx Airlines
Author: Steinar Sveinsson, EFB Project Manager, SmartLynx Airlines and Jens Pisarski, COO, International Flight SupportSubscribe
An iPad EFB Project at SmartLynx Airlines
Steinar Sveinsson, EFB Project Manager, SmartLynx Airlines and Jens Pisarski, COO, International Flight Support outline the successful iPad EFB project at SmartLynx
In this article, we’re will look at one of the key topics of the day, connected systems. We’ll do this by sharing SmartLynx’s experience connecting all of their systems through their EFB solution. But before that, some background information on SmartLynx to set the scene.
As at the time of writing, SmartLynx’s fleet included 13 aircraft on two AOCs (Air Operator’s Certificates) in Latvia and in Estonia. The Latvia fleet has 7 A320 and 1 A321 aircraft with a further 5 A320s based in Estonia. The Latvian fleet obtained EFB (Electronic Flight Bag) approval in September 2014 and ETL (Electronic Tech Log) approval in August 2017 while, in Estonia, the EFB approval came in January 2015 and the ETL was also approved in August 2017. The two parts of the airline operate together for training, including training pilots on the A320. Three further aircraft will be added to the fleet during 2018, bringing it up to 16.
SmartLynx is an ACMI (Aircraft, Crew, Maintenance and Insurance) service provider with an impressive customer community. The operation complies with EASA AIR-OPS-1 and IOSA (IATA Operational Safety Audit) as well as being EASA Part 145 approved. Competences include ad hoc wet lease, long-term wet lease and full charter operations. SmartLynx offers Cabin Crew conversion training, can issue CC (Cabin Crew) attestation and holds dangerous goods, low visibility on take-off and CAT2, CAT3A landing approvals. It also flies an extensive route system on its own account (own flight numbers) as the map (figure 1) illustrates…
… and if all the flights undertaken for other airlines are included, it can be seen in figure 2 that SmartLynx aircraft and crew fly over most of Europe and some of the Middle East plus a Vietnam operations not on this map.
SYSTEMS USED BY SMARTLYNX
Like all airlines, SmartLynx has a range of systems to deal with various aspects of the business. The EFB at SmartLynx is the Paperless Flight Bag™ from IFS – International Flight Support, the main subject for this article. The Airline Management System is Aviolinx RAIDO while Air Support PPS is the Flight Planning System, Navblue monitors performance and charts are Jeppesen Jepp FD-Pro. HubMobile supports the Document Library and Conduce eTechlog8 is the electronic techlog (ETL). The maintenance system is Commsoft OASES, MINT is the Training management system and AeroCloud is used for cosmic radiation calculations.
But it isn’t so much about the several systems in the EFB suite themselves as how they are connected that contributes to the EFB’s effectiveness (figure 3)
The IFS Paperless Flight Bag™ is an integrated and fully interfaced EFB platform solution which delivers the software for the aircraft with one or multiple modules as well as the ground based Back-Office system with integrations to multiple systems such as Maintenance, Flight Planning, Performance, Scheduling, etc. With the database, the EFB can manage all data flows into and out of the EFB system – a controlled environment in which the user can support the airline with any needs they have from the ground or in the aircraft. Some of the modules available in the Paperless Flight Bag™ can be seen in figure 4.
As an integrator, IFS with its Paperless Flight Bag™ does not provide any of the back-end system services but imports and integrate all data from/between partner systems and fill it into the work flow on the EFB.
Looking at the Paperless Flight Bag™ suite at SmartLynx, the information is pushed to the pilot’s iPad through the interface that feeds the systems with data from IFS. From there, the Jeppesen Charts system auto-loads departure, destination and alternate airports and plots a route using the EFB; this is a feature that pilots particularly like. Also, Navblue works as the online performance calculator. The maintenance Control System is OASES which also has online access to open MEL (Minimum Equipment List) items. Before SmartLynx got an eTechlog, the status of MEL items were just as put into the Maintenance Control System but, with the eTechlog online, OASES is immediately updated and from there it will give the pilot the latest information. Hub Mobile (a stand-alone app) is the document library where the manuals are kept. All of this is pushed to the iPad from where the data goes back to the Maintenance Control System and from there back into the EFB system as status information.
RAIDO feeds flight schedules to OASES from where it goes to the pilots’ iPads. The pilot has simply to press the ‘Aircraft Status’ which will show him the latest status for MEL items.
There is a button on the display which, when pressed, will deliver the charts (figure 6) for the departure and destination to the pilot, from which he can plot the route.
Crew information and General Declaration
The interface is used to feed flight deck crew information from RAIDO to PPS Flight Log, including Pilot in Command (PIC), First Officer (FO) and Additional Crew Member (ACM). It‘s managed through the Ops system where crew planning is undertaken. The PFB™ EFB matches the flight with data from the Ops system to check if there is a match with crew information (the crew is already shown on the EFB). That is useful for the pilot because he’ll see the crew’s full names with their three letter codes.
This connection led to another because, with a full name and a three letter code, a connection can be made to create a General Declaration (GenDec). The standard procedure is for the crewing department to create a GenDec and send it somewhere to be printed but once in a while, you end up in a place, especially in an operation like SmartLynx, where there is a GenDec missing. So SmartLynx had IFS build them a button for ‘GenDec’ which, when pushed, will pre-populate the General Declaration form, connect to the Ops system, grab the data (name, date of birth, passport number…) from all crew members available in the crewing department and put that information on the GenDec form so that the pilot can send to wherever is convenient to have it printed; it’s a nice back-up procedure.
On all flights, the load sheet is prepared by the pilot; it’s not connected to DCS (Data Coding Scheme) systems in the airport because SmartLynx flies for so many customers that it’s never worth the effort to set the uplink to a DCS system. The pilot creates the load sheet on the EFB which is fully OFF-line capable and which takes 25-30 seconds. He signs it and the load sheet goes to a pre-defined list in the back-Office so, when they’re departing from one place, it is sent to wherever the customer wants in a really easy process. But then we got a requirement from one customer that they wanted to have a type B message sent to their Ops system because their Ops system wasn’t reading the email or the copy of the load sheet itself and they, of course, wanted the numbers into their Ops system. So SmartLynx asked IFS to add the LDM (Load Distribution Message) format to the bottom of the load sheet itself but then had to work out how it could be taken from there and displayed as a type B message. The way this was resolved, SmartLynx asked IFS to pull the load message itself after it has been signed by the pilot and drop it into the airline’s database. Once there, it is processed using a Pentaho transformation engine to a Connector+ from AIRINC that can send type B messages; so the load sheet was dropped into the Connector+ Outbox where there is the opportunity to define a call sign and destination. It works well and, at SmartLynx, everything concerning the load sheet is done on the iPad. The pilot completes the load sheet, signs it, a copy is sent to the handling agent and a type B message is sent to whoever wants to receive it. In the final step for the load sheet, the process has to copy generated LDM files for ARINC using the eHub Connector+ from ARINC. From there, it is an automatic process using whatever settings have been loaded to the system.
Back end portal
The back-end portal in the IFS solution is also its strength. The focus is usually on what the pilot is doing from the Ops side and, from the company side, users are very interested to use the data that comes after a flight has completed. So, again SmartLynx approached IFS to make it easier to process the data. Now, there is an excellent back-end portal with all the data from which a user can select what they want, download it as a CSV file and then process it. SmartLynx is currently working with IFS to develop a report generator so the back-end portal digital data can be analyzed to detect areas on which the airline can take action and improve processes.
The report generator lets the system administrator create any rule using digital data from the portal. Also, warnings and notifications can be emailed based on the rule: if someone is over-tankering, putting on too much fuel, they can be notified; equally, if the landing/arrival fuel is less than it should be, an email to that effect can be sent to the dispatcher and to the civil aviation authority (mandatory) so that someone can check why that has happened. The important thing is that the tool allows users to take immediate action.
When the post-flight report has been signed, data from the flight is made available on the back-end portal. SmartLynx then sends the post-flight report to the customer with a full Journey Log, a copy of the load sheet and a picture of the fuel slip. Before this all became operational, emails were used for this job, copying in a lot of people which led to emails bouncing back and forth trying to find one fuel slip. Now that doesn’t happen because as soon as the post-flight report is signed, everybody gets a copy of everything.
SmartLynx grabs any digital data that can be taken and processed into information. For instance, navigation fees are calculated by the flight planning system, PPS from Air Support, which used to generate a printed report that the airline has used to challenge the navigation fee invoices from Eurocontrol. Now, finalizing the step, we are in a preparation process that will enable information to be automatically sent from PPS to the EFB, processed to SharePoint from where it goes directly to Ax/adapta to challenge invoices and into the Ops system where it will be used to forecast estimated navigation costs.
With post flight data, the data goes from the EFB server into RAIDO which is then locked for editing. SmartLynx considers the data as defined by the pilot to be the Master Data: as soon as he has signed it, it will go into the Ops systems and is locked so that all the duty times (figure 7) calculations become the actual data. Also available is the load information, fuel (figure 8), and take-off and landing pilots, to ensure that pilots complete their required number of take-offs and landings and to help manage pilot rotations.
The eTechlog8 from Conduce is the latest approval for SmartLynx: the goal is for SmartLynx to only have a single entry of data for the pilot to minimize the risk of typing mistakes. When the flight is completed and the post-flight report has been signed on the pilot’s PFB™ EFB, there is an interface from the EFB to the Conduce server so that, when the post flight report has been signed, the pilot will be able to refresh the eTechlog and pre-populate all the data that has been generated from the flight into the eTechlog.
In addition to the above, SmartLynx uses several other systems, all referred to above, including Aviolinx RAIDO, Airline Management System, Air Support PPS Flight Planning System, MINT Training management System and Aerocloud for Cosmic Radiation reporting.
The interface from RAIDO to PPS flight planning deals with the problem of flight call-sign similarities among aircraft operating in the same area on the same ATO (Air Traffic Organization) frequency giving rise to potential and actual flight safety incidents; the danger of an aircraft taking and acting on a clearance intended for another due to call sign confusion is a common occurrence. So SmartLynx has its flight numbers fed into the flight planning system and linked to the appropriate call signs and the process is reversed in the Ops system where a call sign list is linked to the appropriate flight numbers to check for consistency and accuracy.
SmartLynx did not wish to base calculations on a city pair but rather on an actual route flown. So the flight plans are fed to Aerocloud and PCAire who run it through their engine; there is an interface from Aerocloud to RAIDO that will predict the cosmic radiation dose for every flight. When the measured value is available post-flight, the file is updated with that actual dose. Crew members have access to these figures through their crew portal along with predicted doses for future flights. The effective dose should not exceed 50 milliSievert (mSv) in any single year. (1 mSv = 1000 microSievert (µSv). A warning appears in the rostering system if any of the following limits is exceeded:
- 20 mSv (20.000 uSv) – the average maximum dose in 1 year (soft rule);
- 50 mSv (50.000 uSv) – the maximum dose in 1 year;
- 100 mSv (100.000 uSv) – the maximum dose in 5 years.
All of Smart Lynx’s training is logged into Mint to determine that crews are legal (or not legal) to fly based on the most limiting expiry date which is exported to the Ops system. The status is then made available for the crew to see what they need to know:
- FCL (Flight Crew License)
- MED (Medical License)
- ENG (English)
- PPO (Passport)
- LC32 (Line check)
- FC (Master Qualification)
- CC (Master Qualification)
There is an interchange of information between the Ops system and the training management system so that the crew trainer knows if the crew member is off ill or on vacation. There is also an on-line access for SmartLynx to Sofia Flight Training web portal and, when the SmartLynx Training Coordinator books the SIM (Simulator) and manually enters it into the Training Management system which can automatically assign the training.
This is something with which SmartLynx is very pleased because nobody can fly to an airport unless it’s Airport categorized. SmartLynx devised a system whereby, if an airport is put into the Ops system it is checked against a list of airports that are already approved and, if the airport is not approved, an email warning will be sent to the person responsible for categorizing all the airports to which Smart Lynx aircraft fly asking him to categorize that airport and add it to the authorized list. For the pilot, if he is allocated to a flight that he has not flown for the last year, the system will detect that and send him a link with a briefing of the airport category. He will complete the briefing and, if it’s yes then he’s authorized to fly there but, if it’s no, he will not be able to fly there. If he does that flight within every 12 month period he will not have to go through the procedure again.
MASTER DATA FLOW
The flow chart (figure 9) shows the system and the key function that the Paperless Flight Bag occupies in the system.
This then is the successful EFB implementation that has added value to the whole SmartLynx software and data environment by providing a central point around which a great deal of what the airline does on the operations side can be linked. We hope it has proved of use for readers to see how this system has worked.
Steinar has 33 year work experience from Icelandair as Duty Manager Flight dispatch, later as Manager Operations Control and Chief Instructor FOO. He’s a busy man now as EFB Implementation Manager for BluebirdCargo, Operations Consultant for Smartlynx Airlines and (Now) flight dispatch for AirIcelandConnect along with consultant work for other airlines.
Jens Pisarski has an Academy Economist degree from the Danish Aarhus School of International Business and has worked the last 23 years within the flight operations software industry, including on establishing Danish flight planning software provider AIR SUPPORT PPS flight planning provider. The Last 5 years Jens has been COO and Partner of IFS, the company behind the Paperless Flight Bag™ software solution.
SmartLynx Airlines specializes in full-service ACMI (Aircraft-Crew-Maintenance-Insurance). The airline also has a full charter operation for its home markets in Latvia and Estonia. It also performs flight crew training – SmartLynx ATO is a leading approved airline pilot training company in the Baltic States providing type rating courses for Airbus A320 series.
IFS – International Flight Support
International Flight Support is a Copenhagen based EFB software technology and solution supplier, specializing since 2001 in Electronic Flight Bag software solutions for Stowable, Stowable+Viewable and Mounted EFB hardware classes covering Type A-B as well as Type C software classes. International Flight Support is the creator of the Paperless Flight Bag™ powered by IFS’ flexible software platform and Back-Office solutions which is available for Windows 8/10 as well as for iOS tablets.