Automating the Flight Log Book in Maximo ACM

Body

This blog covers the work that the Maximo Asset Configuration Manager (ACM) team has been doing recently, in particular the last ACM release and the capability for electronic Flight Log Book (eFLB). This is not a user guide, but a brief insight into the approach and how we went about it, so even if you don’t use ACM it will (hopefully) be interesting.  

The Requirement for Automating the FLB for ACM:

The requirement to have an eFLB as part of Maximo ACM was driven by client demand to support the automation of aircraft operational / maintenance management and to improve the visibility of aircraft availability based on the operational status of the aircraft. In other words, automate the traditional paper based log and show me which are aircraft are available for service. 

As with many applications the key challenge is to develop the capability so that it meets the requirement in such a way that it is applicable for our clients across the globe, across business sectors and conforms to the Maximo framework. 

The traditional aircraft Log Book is a paper based folder that is specific to a single aircraft, it is divided into sections that allow aircrew (pilots) and groundcrew (mechanics) to record and review technical and operational information relating to the aircraft. The Log Book is a fundamental part of the maintenance management of the aircraft, it is strictly controlled and regulated by the relevant aviation regulatory authorities.  If the Log Book is not properly certified then the aircraft is not going anywhere! Fortunately the format of an aircraft eFLB is consistent across the globe, which makes the design approach ‘easier’. 

Working with a Development Partner:

Working with a Development Partner was essential for us to develop the eFLB capability, they have the industry expertise and an independent view.  other than the obvious requirement that the eFLB had to functionally replace the paper based FLB it also had to have a consistent ‘look and feel’ across all aircraft types.  What does this mean? If you think about the different types of aircraft that there are in operation…… helicopters, single engine business jets, multi-engine passenger aircraft, military aircraft with and without weapons systems; the eFLB has to be able to be configured to manage this vast range of aircraft types in such a way that aircrew and groundcrew are able to use the eFLB in the same way for each aircraft. 

Defining the Design Approach:

Working with the ACM Development team we soon realized that the most effective way to achieve this was to develop a ‘eFLB Set Up’ application that aligns with the ACM configuration management capabilities.  This is the Model application (where all the configuration details are defined and managed, see the other ACM blogs for more info). This approach enabled each eFLB type to be created by the user referring to the existing data in the Model. 

Other variables associated with each aircraft type can also be configured in the set up application, for example, are munitions required? (a passenger jet doesn’t typically have rockets fitted!), which meters are recorded against the aircraft? (so that the eFLB can automatically record flight hours based on departure and arrival times), how many fuel tanks are there? (so that the replenishments are recorded), how many engines are installed? (so that oil replenishment can be recorded after each flight)……….. the list goes on. All of the above are defined in the ACM Model application as part of the aircraft’s engineering definition, so it makes good sense to link the eFLB set up to this authoritative data source. 

Fortunately, from an architecture perspective, the Maximo framework and the use of multiple tabs and sub-tabs to present information and allow data entry fits very well with the traditional paper based FLB that is divided into sections and sub-sections. 

When aircrew accept an aircraft for flight they rely on the eFLB to give them a full picture of the status of the aircraft, what faults are there, what faults have been deferred, what scheduled maintenance is due in the next few days or flight hours, what is the maintenance history associated with the aircraft? From a design approach we were able to utilize existing Maximo ACM functionality in all of these areas to both display and record information relating to the entire range of functional requirements. Where possible we want to re-use code that is tried and tested so that we minimize development time and maximize efficiency. 

The eFLB can be seen as the initiation point of maintenance activities post flight, so the design had to allow for the recording of faults (also known as ‘discrepancies’) and linking into Work Orders and related processes. 

Lastly, but importantly the eFLB has to provide the user with the status of the aircraft, i.e. is the aircraft serviceable for flight? – this has to be derived automatically and clearly indicated to the user both graphically and textually. This represented a significant challenge to achieve as there are a large range of variables that impact the status of the aircraft. The different statuses were ranked in terms of severity and associated with the range of conditions that are possible for the aircraft to be in and the resultant condition displayed as a status and as a graphical symbol.

 Finally, a  couple of screenshots showing the FLB............

Fig 1 - The FLB List tab displaying the Aircraft Status Symbol on the right hand side - a clear view of the fleet status.

Fig 2 - The FLB record - multiple tabs representing the 'traditional paper log'