The acronym MSI is a deceptively innocuous – and frequently misused — description of a critically important aspect of planning, designing and constructing today’s airport facilities. MSI, or master systems integration, is considered interchangeable with the role of a master systems integrator.

The presence of complex governance models, finance options and program delivery methods underscores the value proposition of a program manager in any large-scale commercial aviation endeavor. One of the key deliverables for the program management function is a program definition document, or PDD. The PDD details owner requirements for everything the new or upgraded facility must include — from the number of new gates, runways or baggage carousels to amenities like fast Wi-Fi, more restaurant and retail space, and safety and security features. The PDD may even specify energy efficiency, aesthetics and sustainability goals.

Though the PDD defines dozens of functional requirements and expectations for architects, designers and builders, program requirements for systems integration are frequently omitted entirely.

Developing and implementing a master systems integration methodology can be a complicated process. Although integration results are implicitly expected by all stakeholders, many projects tend to dismiss it early or not even consider it altogether, as if the scope will be captured by a phantom safety net much later during construction. Although integration success is mandatory if one expects interconnected systems to exchange data, the process of effectively planning for it eludes many. Though not all accept MSI as a required process that is just as vital as individual system design, it is essential nonetheless in the development of a fully functional airport, integrating the technology that runs dozens of disparate operational systems in a cost-optimized fashion.

Why?

It’s mainly because there are no commonly accepted standards for planning, designing and implementing an MSI methodology. While there are well-documented physical, biological or chemical laws that govern engineering practices and scientific inquiry, there are no commonly accepted laws that govern the process of writing specifications and standards for the exchange of data between each complex system. Because there are no credentialed MSI degree programs from accredited educational institutions, it is generally relegated to the marketplace to create ad hoc standards or otherwise adopt models from academia or military applications. As a result, MSI standards may be defined, applied and executed in a number of different ways.

It’s important to understand what an MSI program is and what it is not.

First, it is not a software program or piece of hardware. It’s a framework — a thought process that directs the parameters and formats for data exchange so that data is accessible and ingested in such a manner as to be usable by other systems. The MSI framework must account for data producers and consumers. The specifications for all systems to be installed must be written to account for those requirements. This framework must be applied rigorously such that any system, regardless of its designer, contractor, supplier, tester or operator, functions as expected upon startup. Once a common methodology is defined, all design and build teams (and subsequent system delivery teams) must adhere to the MSI methodology for the systems installed to operate all critical functions.

Specifications must extend beyond just defining how data will be assimilated and shared. The MSI framework covers how systems are to be designed, specified, procured, delivered, installed and tested. Then it sets documentation standards so that the framework can be easily understood by terminal operators who will one day shoulder the responsibility for maintaining the systems in steady state once the engineers, architects and builders are finished.

Thus, because the marketplace produces dozens of variations, the more comprehensive definition is:

MSI is a framework that enables all systems to get the data they need when they need it and how they need it.

An MSI consultant keeps all entities moving in the same direction — designing, contracting, procuring and installing under the same specifications. If that happens on an enterprise-wide scale, the dozens of functions necessary to make an airport operate seamlessly will be prepared to function efficiently and effectively when the ribbon is cut at the grand opening ceremony.

By directing all the data exchanges required to keep a complex facility operating, an MSI creates a value proposition that enables alignment of data producers with data consumers. It creates the common standards that mitigate the scope gaps that would otherwise occur if all vendors who install a system or pieces of equipment were left to complete this installation without any guidance on how the data generated is controlled and consumed.

The value proposition, therefore, is twofold:

1. Getting MSI integrated as early as possible to mitigate risk and reduce overall costs.
2. Improving long-term operational efficiency.

If two systems aren’t sharing data, it’s somewhat like trying to run a sophisticated operation by sharing Post-it notes, or simply shouting instructions across the room. It may be possible to operate this way, but risks of mistakes, miscommunication and failures increase substantially. It’s neither a prudent business model for delivering a terminal program nor for operating one afterward.

Scope gaps are common on large, complex programs where each of the dozens of subcontractors are focused on executing their responsibilities and not looking outside of those boundaries. This is because contracts are written with each party responsible for their specific scope of work, making sure their systems and equipment are installed correctly and tested to meet all performance requirements.

The single worst assumption with any large terminal improvement program is that someone else is responsible for the MSI safety net. With each discipline focused on its own scope of work, a common attitude typically emerges that all scope gaps, mistakes and oversights will certainly be caught by someone else at some point. This is a common issue that can be thought of as the phantom safety net, an illusion that surely someone has been tasked with developing the data protocols needed to be certain all systems communicate and function efficiently.

An MSI is a valuable tool to keep all players in sync so that all know they are responsible for sharing data in formats that are compatible with all other systems operating inside the airport. The MSI can serve as a source of information that keeps all planners, designers and builders focused on designing to common standards that are well understood by all parties.

With these standards in place, documentation during installation becomes another key to success. The day after the grand opening, operators will be responsible for daily success. Operational readiness activation and transition (ORAT) functions can significantly improve familiarity, but eventually something fails or needs an update or upgrade. If there are dozens of unique documentation sets for each system, with each incorporating different diagrams and terminology about data exchange, confusion will result. The minute a malfunction occurs, troubleshooting will come with a large dose of anxiety.

With requirements set in all procurement contracts mandating that specifications will conform with common standards and that those standards will be documented the same way, each operator will have a common and easily understood source of information for how all data is transferred.

Key questions that direct the formulation of a successful MSI strategy include:

• Do you have the data you need in the format you need when you need it?
• When there is an interruption of data exchange (e.g., network outage, power surge, etc.), who is accountable for reestablishing connections?
• How is the MSI defined by the owner or program manager?
• Where will the MSI role fit in the program delivery governance model?
• How will we mitigate scope gaps?
• Is there a centralized knowledge base so that all vendors know who is budgeting, procuring and installing all hardware, software and components?
• Is there a plan to enumerate each system’s data needs?
• Who designs systems integration into each system?
• Who writes specifications for each system and for its integrations?
• Who will write the test plans for each integration?
• Who will cross-check designs for alignment?
• Who will establish documentation formats?
• Who will assimilate documentation?
• How will MSI be coordinated during the build phases?

With architects, engineers and builders intently focused on executing the scopes of their respective contracts, it’s no wonder that MSI is often an afterthought.

With the thousands of tasks being performed daily during construction of a new airport facility, it is prudent to engage a program manager at the earliest possible stage and that program manager be given a mandate to develop procedures for a master systems integration. The MSI directive should establish a clear expectation to:

• Document requirements.
• Specify, design, procure, commission and perform ORAT testing.
• Perform these activities under the auspices of a technical program with common standards and terminology designed specifically for data integration.

If these steps don’t occur until relatively late in the building program cycle, it will almost certainly be an expensive fix. Hiring an entity to develop an MSI at the 11^th hour will strain resources and induce cost pressures that may not have been budgeted.

With experience in every aspect of airport facility design, construction, commissioning and operation, we have seen firsthand the savings that can accrue on both the front end and back end when MSI development and implementation is addressed early.

The breadth and depth of commercial aviation makes it an unusually complicated enterprise, due in large part to the nature of airport operations and to governance models in which stakeholder engagement and decision-making authorities must flex to the myriad demands of many. Against this backdrop, the importance of a well-designed MSI is amplified. It is an essential tool that can be critical in keeping these enormously complex operations functioning smoothly over the long term.