Andrew Rossi
Engine instrumentation for the cockpit of tomorrow.
Design System
Avionics
Garmin currently has solutions for their EIS (engine instrumentation system) on the G1000, G3000, and G5000 flight decks, but the creation of gauges has been completed by software engineers on an airframe by airframe basis, with no central foundations.
Prototyping new engine instrument layouts was often done in photoshop, with no pre-made elements to start with. It proved difficult and time consuming for team members to create layouts. Also, OEMs were not aware of their options.
Existing engine gauge designs are broadly captured within pilot’s guides specific to each aircraft. These guides do not go into the level of detail required to design gauges from scratch, and are not in a central location where they may be compared to each other. Graphical elements, colors, and behavior of gauges are scattered throughout code bases.
Create a system of engine elements that captures current functionality with a visual update appropriate for part 25 and 23 aviation.
I started by researching as much as I could find about our current engine instruments. This meant reading through every pilot’s guide available along with collecting screenshots from our simulators.
Additionally I dug into how other aircraft without our avionics treat instrumentation. In order to help future proof our library of gauges for when we eventually win more customers.
Once I understood the usage and variations of our current system, I started exploring visual styles. From stakeholders there was an emphasis on gradients and layering to create depth, but I couldn't get too carried away because they must meet certification requirements with regard to visibility and readability.
After a several reviews with flight ops and software, we found a visual style that fit the requirements and was feasible in software. From this point we still needed to test elements on actual hardware in all lighting conditions to verify our designs and make adjustments as needed.
I carried out a number of tests to get the size of elements just right. With the vector graphics I made in Adobe Illustrator I could easily edit, export, and load new mockups on hardware for evaluations. Participants were asked to evaluate gauges from a standard viewing angle, in both direct sunlight and dark rooms
Not the creepy crawly things, but rather symbols used on gauges! One of the main problems with previous implementations was a lack of variety of engine bugs. OEMs would use the same symbol on the same guage to represent different values. In the example below, a white tick is used for both the CRU, and MCT values, the only difference being that one is located inside the arc and one is located outside the arc.
To solve this I added several new shapes that OEMs could use to represent different values. Another benefit of this was that all bugs could be placed outside the arc so pilots would not lose sight of a bug when the needle moves over top of it. Finally, the shapes were scaled so that any one could be nested inside the V bug, which is a primary indicator for desired thrust.
This project would be a flop without any record of what I had created. I made a Figma library with all the design assets along with guidance videos on how to configure gauges. Components from the library are intended to be deatched, while each component inside can be configured to the OEM's specifications.
Since it's release, G3000 Prime has been announced for the Citation CJ4 Gen 3, Pilatus PC-12 Pro, Beta Alia, all using my engine intrumentation in their own configuration.
Teams from OEMs have been able to use my library to create their own designs, speeding up our workflows and better communicating their requirements.
