Collecting and Sharing of Operations and Safety Data (2020)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

63 Developing an Operations and Safety Database Chapter 4 describes considerations for developing an operations and safety database, asso­ ciated challenges, and a method for collecting and sharing operations and safety data internal to airports for the purpose of improving risk­based decisionmaking at an airport. 4.1 Motivation The collection of operations and safety data internal to airports is primarily driven by the federal mandates of 14 CFR Part 139, Airport Certification. Under Part 139, safety data is collected through daily self­inspection reports and maintenance work orders to address defi­ ciencies. Some of the safety issues are reported to the FAA; however, many of the issues are not publicly reported. The FAA’s SMS concept at airports is designed to help airports detect and correct safety problems before an accident or incident occurs. The SMS program encourages the collection of safety data by airports and operators as a systematic process for identifying and quantifying potential hazards and risks and for managing and mitigating them. Sharing data collected from Part 139 compliance requirements, the SMS, and other areas of the operation can contribute to a broader awareness of the potential risks and strategies for mitigation that have a common thread among airports. The existing aviation safety databases are focused on the airspace (such as ATCTs) and the operator components of the NAS. The collection of operations and safety data occurs every day at hundreds of airports around the country; however, airports currently do not have a venue for sharing their operations and safety data. Based on interviews with airport personnel conducted for this and other ACRP projects, there appears to be an interest in participating in a collective database of operations and safety data if there were opportunities to do so. Airport operators share a common responsibility to identify and provide a safe environment for their users and are constantly looking for ways and means to mitigate risks that would compromise their mission. They have collectively expressed interest in the ability to determine if their issues are unique or shared by the other airports. Having access to a database to identify the extent of problems would be of great value. 4.2 A Method for Collecting and Sharing Operations and Safety Data Developing a standard method to collect and share airport operations and safety data would enable the airport community to analyze characteristics and trends with a goal to developing improvement strategies. To do this requires a common metadata platform and taxonomy that conform with existing internal data collection. C H A P T E R 4

64 Collecting and Sharing of Operations and Safety Data Operations data at airports is generally measured in terms of the volume and character of aircraft movements or passenger activity and is recorded on a regular basis (daily/monthly/ annually) by the airport or through a variety of federal resources. In the latter case, this data is available online in the public domain. The data is quantified in terms of the number of aircraft, people, or vehicles moving among the facilities and services at the airport at risk for safety issues. Aircraft operate within the airspace, on the airfield (i.e., runways and taxiways), and on the ramp and gates. Inside the terminal, passengers, staff, and others flow through the building for check­in, screening, enplaning and deplaning, and claiming baggage. Landside events occur on the access roads, terminal curb, and parking areas. Anything (people and property) moving within these areas can be exposed to risk, a victim to compromised safety. Figure 4­1 illustrates the relationship operations and safety data have in a typical commercial airport’s day­to­day activity. The figure also shows where the activity generally occurs and indicates the activity’s exposure to risk. The consequences related to events where safety may have been compromised can be connected to the levels of activity and to the services and facilities of the airport. Stakeholders are identified based on their relationship to the activity, and legal considerations affecting the collection of the data are also shown. A/C = air conditioning; ARFF = aircraft rescue and firefighting; ATC = air traffic control; EMT = emergency medical technician; FOD = foreign object damage/debris; LEO = law enforcement officer; Pax = passengers; SMS = Safety Management System; SRM = Safety Risk Management. Figure 4-1. Airport operations and safety data relationships.

Developing an Operations and Safety Database 65 At an individual airport, the data can be useful for discerning unforeseen conditions, and to identify policies, practices, and trends that may require mitigation. By sharing the data with others, the collective understanding of common safety risks that can be avoided may be achieved, and in many cases, the development of a forum for sharing lessons learned and best practices to avoid future safety­related events. The platform used to store operations and safety data locally can be as simple as a spreadsheet or commercially available database. For the database to be useful for retrieving specific data, the data must be coded in a way that it can be easily queried. For the data to be shared collectively with other entities, a common database platform needs to be identified. In addition, a standard taxonomy accepted by the airport industry for standardizing the data to be included in the database is required. The development of any database requires long­term commitments by a sponsor to take ownership of the complete product and process. Candidates for sponsorship of an operations and safety database may be found in governmental agencies (such as FAA, NASA, etc.); industry organizations (such as the National Association of State Aviation Officials); academic institu­ tions; and private sector interests. However, the primary question that needs to be addressed is “what’s in it for them?” 4.2.1 Collection Mechanisms Collecting external operations data will require manually accessing any number of data sources as discussed in Chapter 3. This may occur on a regular basis, such as monthly or annually, although shorter or more recent intervals may be available. The data may be in the form of a text file (e.g., comma delimited format) or spreadsheet, which can easily be entered into the local database. On the other hand, safety data is primarily event driven, and collection will require some form of reporting mechanism to categorize specific details of the occurrence in a recordable format. Reporting safety data could be through an online form prompting the reporter for details about the event. A physical form could also be used to collect the same information; however, the data would have to be entered later into the database. When an event occurs or where a safety issue is identified, data can and should be reported in significant detail to (1) document the conditions and circumstances for what occurred, (2) describe the consequences, and (3) record what corrective actions were taken or recom­ mended for implementation to avoid future events. Safety data about specific events might include information about who is providing the report, circumstances that describe the event (what, where, and when), and the resulting consequences. Contributing factors, such as human factors and physical conditions, may also be provided to enhance report details. A narrative report describing the event from the reporter’s perspective might include details that would be difficult to categorize or otherwise be missed. 4.2.2 Safety Reporting Safety data can be collected through various forms, depending on the need for ease, detail, and end use. For example, a verbal report from an observer can immediately communicate certain aspects of a safety­related incident to a supervisor; however, this may preclude any documentation for collecting, analysis, and reporting purposes, and result in a loss of specific details. It has been said that the faintest ink is more powerful than the strongest memory. This suggests that a written report is more useful and reliable than a verbal account. Written safety reports can be prepared in several ways. A paper form can be simple and effective for collecting data in an objective format. Aside from the reporter’s information and a narrative summary of the event, which would be handwritten, all other data regarding the

66 Collecting and Sharing of Operations and Safety Data specific circumstances can be entered by checking the appropriate boxes. The report data will eventually have to be manually transcribed and entered into a digital database to be useful. The use of computers and mobile devices can ease data entry by providing a digital form to be completed so that the initial report is handled only once. Desktop and laptop computers can be used to collect safety data reports; however, these will usually require the reporter to enter data at the end of a shift or another point in time. Tablets and mobile phones may provide more functionality for submitting safety data by allowing real­time data entry. Certain devices may also allow pictures, GPS coordinates, and other data to be added to the report. 4.3 Challenges Associated with Collecting and Sharing Operations and Safety Data 4.3.1 Standardization The form and format in which operations and safety data are currently collected and stored vary across airports, depending on size and need. They are also diverse as a result of the technology and resources available. The framework for collecting and sharing operations and safety data requires common denominators that will allow for the standardized input of data to be organized, stored, and retrieved for a variety of analytical purposes. The data needs to be uniformly categorized, collected, stored, and reported. To do this requires a closer examination of the nature of the data in the context of metadata and its taxonomy. 4.3.1.1 Metadata Metadata is the principal concept of how data is organized. It primarily focuses on the end user and on how the data will be retrieved. Metadata considers the hierarchy of each data point or field and categorizes the data from the broadest perspective and filters down. For example, all data related to construction safety would fall under the “construction safety” category as a metadata filter as the first order sorting of data for a user looking for data on construction safety issues. A second order sort might include “airfield” to put the focus on safety issues related to runway or taxiway construction projects. 4.3.1.2 Taxonomy Taxonomy is the classification of data based on an objective system of organization that provides a framework for data contributions, retrieval, and analysis. The taxonomy for the development of an operations and safety database should conform to commonly accepted principles and practices for organizing data in a form that can be accessible and useful for the purpose it has been created. Some of these principles include the following: • Data is relevant to the intended audience (stakeholders). • Data is easily collected and stored. • Data is easily accessible. • Data is organized in a searchable format. • Data should not be redundant with other data sets. • Data should be easily classified, cataloged, and indexed where applicable. • Data should have limited stratification. 4.3.2 Disclosure Legal concerns related to collection of sensitive data are tied to Freedom of Information Act (FOIA) and various Sunshine laws enacted by most states. Many municipalities are required

Developing an Operations and Safety Database 67 by their state laws to disclose public records (upon request). Under the federal FOIA, there are two distinct exceptions related to aviation safety data. One FOIA exception “permits the FAA to withhold safety or security information provided voluntarily from disclosure if the FAA determines that is consistent with the FAA’s safety and security responsibilities (see 49 U.S.C. §40123 and 14 CFR Part 193)” (Landry et al. 2014). This FOIA exception is central to the FAA’s Aviation Safety Action Program (ASAP) (https://www.faa.gov/about/initiatives/asap/). The second FOIA exception resulted from the FAA Modernization and Reform Act of 2010 (P.L. 112­095) and noted that aviation safety data is exempt from disclosure under FOIA if the information such as “reports, data, or other information produced or collected for the purposes of developing and implementing a safety management system acceptable to the Administrator (of the FAA)” is provided voluntarily (Landry et al. 2014). The act clearly notes that this exception is only applicable if the information, such as reports, data, or other infor­ mation, “is submitted to the Federal Aviation Administration voluntarily and is not required to be submitted to the Administrator under any other provision of law (see 49 U.S.C. §44735)” (Landry et al. 2014). However, even with both FOIA exceptions, the many state and local Sunshine laws appli­ cable to airports owned and operated by state or local governments and authorities cannot be modified. Sunshine laws do not have any exceptions that allow airports to withhold safety or security information provided voluntarily by airport stakeholders. States and local governments have enacted Sunshine laws that provide, with limited exceptions, that any public record must be disclosed if a request is made for that record. Applicable public records include any information, data, documents, and other materials held by a governmental entity; these public records are subject to disclosure when a person makes a request for the record, unless such data is subject to an exception set forth in the law. Presently, safety data is not subject to a statutory exception to allow it to be withheld from disclosure (Landry et al. 2014). The most effective means to facilitate an airport’s ability to share safety information without being subject to disclosure through FOIA requests is for airports to have the ability to provide reports directly to the federal agency for data collection and storage. The exceptions in FOIA allow federal agencies, like FAA and NASA, to collect safety data and protect it from disclosure until it is compiled, de­identified, and published. For example, in the case of FAA’s ASAP, “the data and other information gathered at the corporate level before they are submitted to the ASAP program are not subject to any state Sunshine laws, and once such data are submitted to the FAA, they are protected by the statutory exception from FOIA” (Landry et al. 2014). In the case of NASA’s Aviation Safety Reporting System (ASRS), “data in public reports issued under ASRS are gathered directly from individuals in the aviation system who are not subject to state sunshine laws, including pilots, air traffic controllers, flight attendants, and maintenance personnel. Such data are protected from disclosure when reported to NASA and is deidentified when the reports are issued” (Landry et al. 2014). Regardless of FOIA and Sunshine laws, maintaining some level of confidentiality of data is crucial to the functionality for any form of safety reporting system. The challenge for developing the ability for airports to share safety­related information through a national database requires the ability to collect and store standardized data locally. Although in many states Sunshine laws compel public entities such as an airport to provide copies of specific existing documents upon request, the airport is not required to compile data, prepare special reports, or otherwise produce new documents. 4.3.3 Sample Database Taxonomy Examples exist today for demonstrating how operations and safety data can be effectively collected, stored, and shared. NASA’s ASRS has provided a platform for individual contributors

68 Collecting and Sharing of Operations and Safety Data to anonymously report safety­related incidents. The ASRS database is available for querying and reporting relevant data to specific inquiries. A common taxonomy would assist airports to collect, store, and compare operations and safety data. Table 4­1 through Table 4­8 show how data points can be collected and organized into a structured taxonomy database usable by all airports. These tables closely follow the taxonomy of the ASRS database but are expanded to specifically address airport­related data points and issues. 4.3.4 Reporter Data Data regarding the reporter, either as an entity or individual, should be collected. Reporter­ related data points (Table 4­1) can include the following: • Airport ID—while the actual airport can be kept confidential, the characteristics of the airport (medium hub, northeast region, etc.) can be given for reporting purposes. • Responsibility of the reporter—the role of the reporter, either as a general entity or individual, should be identified. For individuals, their affiliation with the airport can be established with fields dedicated for airports, airlines, aircraft operators, or contractors. Other details can be collected such as event observer or participant, years of experience, and so forth. The opportunity for a follow­up conversation with the reporter may be provided if contact data, such as address, telephone, and email address, is collected. This data would be kept confidential as a default, but the reporter could opt in to allow disclosure of the data to validated parties interested in the event. Table 4­1 provides an example of the data obtained from the reporter of an event. 4.3.5 Event Conditions Details on the conditions related to the event are helpful to include in the data collected (Table 4­2). Conditions can include the date and time of the event, seasonality (e.g., winter operations), weather, visibility, and lighting. In addition, the parties involved in the event can be categorized such as a single aircraft, vehicle, person, or a combination of parties (aircraft/aircraft, aircraft/vehicle, etc.). 4.3.6 Human Factors Another aspect of data collection to be considered are the human factors related to the event. Although perhaps subjective, attempts to identify contributing factors are helpful for adding context to the data (see Table 4­3). Circumstances such as confusion, distraction, fatigue, and other factors could help describe the scenario that led to the event or resulting reactions. Citing communications failures among the parties could be a significant factor for describing underlying factors leading to the event. These data points are relevant for sharing safety infor­ mation with the intent of identifying risks and providing lessons learned from the event so that future events can be avoided. 4.3.7 Physical Conditions Describing the physical conditions of the event can allow for comparisons within the data­ base (see Table 4­4). The location of the event could range from the airfield, ramp, terminal, terminal curb, roadways, or parking lot. The nature of the event can also be identified, whether it was a runway or taxiway incursion, wildlife threat, environmental spill, slip and fall, and so forth.

Developing an Operations and Safety Database 69 Other AOX Checkbox/Alpha Experience (EX) 2 years or less EX1 Checkbox (Y/N) 3 to 5 years EX2 Checkbox (Y/N) 6 to 10 years EX3 Checkbox (Y/N) 11 to 15 years EX4 Checkbox (Y/N) more than 15 years EX5 Checkbox (Y/N) Field Name Code Format Remarks Reporter Note: All personal information to be kept confidential unless reporter opts in to allow contact. Name NM Alpha Report validation (Source) Mailing Address 1 MA1 Alpha Mailing Address 2 MA2 Alpha City CIT Alpha State ST ST Zip ZP Zip Phone (Preferred) PH1 (NNN) NNN-NNNN Phone (Alternate) PH2 (NNN) NNN-NNNN Best Time to Call TTC HHMM Email EM Alpha@Alpha Allowed to Contact (Opt in) AC Checkbox (Y/N) OK to contact reporter (Default = N) Intake Date ID YYYY/MM/DD System generated Intake Time IT HHMM System generated No Interview IN Checkbox (Y/N) Interview Attempted IA YYYY/MM/DD Interview Completed IC YYYY/MM/DD Airport Department (AP) Operations AP1 Checkbox (Y/N) Facilities AP2 Checkbox (Y/N) Snow Removal Equipment (SRE)/ Grounds keeping Public Safety AP3 Checkbox (Y/N) ARFF/Law Enforcement Officer (LEO) Management AP4 Checkbox (Y/N) Other APX Checkbox/Alpha Planning, Engineering, etc. Airline (AL) Ramp AL1 Checkbox (Y/N) Operations AL2 Checkbox (Y/N) Management AL3 Checkbox (Y/N) Other ALX Checkbox/Alpha e.g., Flight Crew Construction (CW) Work Crew CW1 Checkbox (Y/N) Supervision CW2 Checkbox (Y/N) Management CW3 Checkbox (Y/N) Other CWX Checkbox/Alpha Other (AO) FAA/Government AO1 Checkbox (Y/N) Consultant AO2 Checkbox (Y/N) FBO AO3 Checkbox (Y/N) Aircraft Operator AO4 Checkbox (Y/N) Table 4-1. Reporter data related to event.

70 Collecting and Sharing of Operations and Safety Data Airplane P1R Checkbox (Y/N) Helicopter P1H Checkbox (Y/N) Make/Model P1A Alpha {Describe} Vehicle Operations P1O Checkbox (Y/N) Ops Maintenance P1M Checkbox (Y/N) SRE, runway (RW) sweeper, mowers Medical/ARFF/LEO P1E Checkbox (Y/N) A/C Ground Equipment P1Q Checkbox (Y/N) Tugs, bag loaders, fuelers, catering Construction P1C Checkbox (Y/N) Loader, grader, bulldozer, dump trucks Other P1X Alpha {Describe} Person Airport P1T Checkbox (Y/N) Operations, maintenance Airline P1L Checkbox (Y/N) Ramp Construction P1C Checkbox (Y/N) Laborers, equipment operators Other P1Z Alpha {Describe} Party No. 2 (P2) Aircraft Checkbox (Y/N) Airplane P2R Checkbox (Y/N) Helicopter P2H Checkbox (Y/N) Make/Model P2A Alpha {Describe} Vehicle Operations P2O Checkbox (Y/N) Ops Field Name Code Format Remarks Airport ID LOC XXX Event Date (ED) ED YYYMM Event Time (ET) HHMM 0000 – 0600 ET1 Checkbox (Y/N) 0601 – 1200 ET2 Checkbox (Y/N) 1201 – 1800 ET3 Checkbox (Y/N) 1801 – 2400 ET4 Checkbox (Y/N) ZZZ ETZ Null Unreported Weather/Visibility (WX) Correlate with METAR data Clear/Partly Cloudy WX1 Checkbox (Y/N) Overcast WX2 Checkbox (Y/N) Fog WX3 Checkbox (Y/N) Icing WX4 Checkbox (Y/N) Rain WX5 Checkbox (Y/N) Snow WX6 Checkbox (Y/N) Thunderstorm WX7 Checkbox (Y/N) Severe (Tornado/Hurricane) WX9 Checkbox (Y/N) Other WXX Checkbox/Alpha Lighting Conditions (LC) Dawn LC1 Checkbox (Y/N) Daylight LC2 Checkbox (Y/N) Dusk LC3 Checkbox (Y/N) Night LC4 Checkbox (Y/N) Party No. 1 (P1) Aircraft Table 4-2. Conditions related to event.

Developing an Operations and Safety Database 71 4.3.8 Results Allowing the user to identify results related to the event can also assist with lessons learned. Details on physical injuries, damage to aircraft vehicles or equipment, and evasive maneuvers or similar data resulting from the event should be identified to establish the significance and importance of the event. The immediate response to the event such as dispatching ARFF or medical assistance can also provide enriched data about the significance of the event. Table 4­5 identifies data entries for results related to an event. 4.3.9 Contributing Factors Although possibly considered subjective, attributing other contributing factors could be useful for ascertaining causal factors that led to the event (see Table 4­6). As a postmortem Maintenance P2M Checkbox (Y/N) SRE, RW sweeper, mowers Medical/ARFF/LEO P2E Checkbox (Y/N) A/C Ground Equipment P2Q Checkbox (Y/N) Tugs, bag loaders, fuelers, catering Construction P2C Checkbox (Y/N) Loader, grader, bulldozer, dump trucks Other P2X Alpha {Describe} Person Airport P2T Checkbox (Y/N) Operations, maintenance Airline P2L Checkbox (Y/N) Ramp Construction P2C Checkbox (Y/N) Laborers, equipment operators Other P2Z Alpha Field Name Code Format Remarks A/C = air conditioning; LEO = law enforcement officer; METAR = Meteorological Aerodrome Reports; SRE = snow removal equipment. Table 4-2. (Continued). Field Name Code Format Remarks Human Factors (HF) Multiple Entries Allowed Confusion HFC Checkbox (Y/N) Distraction HFD Checkbox (Y/N) Fatigue HFF Checkbox (Y/N) Physiological Conditions HFP Checkbox (Y/N) Situational Awareness HFS Checkbox (Y/N) Time Pressure/Workload HFT Checkbox (Y/N) Training/Qualification HFQ Checkbox (Y/N) Equipment Failure HFE Checkbox (Y/N) Other HFX Alpha Communications Failure Between (CO) Party 1 & ATC CO1 Checkbox (Y/N) Party 2 & ATC CO2 Checkbox (Y/N) Party 1 & Party 2 CO3 Checkbox (Y/N) Other COX Alpha ATC = air traffic control. Table 4-3. Human factors related to event.

72 Collecting and Sharing of Operations and Safety Data Field Name Code Format Remarks Event Location (EL) Runway (Active) EL1 Checkbox (Y/N) Runway (Closed) EL2 Checkbox (Y/N) Taxiway (Active) EL3 Checkbox (Y/N) Taxiway (Closed) EL4 Checkbox (Y/N) Terminal Ramp EL5 Checkbox (Y/N) FBO Ramp EL6 Checkbox (Y/N) Hangar Area EL7 Checkbox (Y/N) Terminal Building EL8 Checkbox (Y/N) Terminal Curb/Access Road EL9 Checkbox (Y/N) Other ELX Alpha Event Conflict (EC) Runway Incursion ECR Checkbox (Y/N) Active Runway Intrusion Surface Incident on a Taxiway ECT Checkbox (Y/N) Active Taxiway Incident Aircraft Conflict ECA Checkbox (Y/N) Aircraft Movement Interference Vehicle Conflict ECV Checkbox (Y/N) SRE, GSE, ARFF Interference Pedestrian Conflict ECP Checkbox (Y/N) Unauthorized pedestrian Wildlife Conflict ECW Checkbox (Y/N) Deer, hogs, birds, reptiles FOD Conflict ECF Checkbox (Y/N) Construction debris, dropped item Airport Equipment ECQ Checkbox (Y/N) Cable cut, signage, lighting NAVAID Conflict ECN Checkbox (Y/N) IFR signal interference Obstruction Conflict ECO Checkbox (Y/N) Crane operations Environmental Spill ECS Checkbox (Y/N) Fuel spill, hydraulic failure Slip and Fall ECL Checkbox (Y/N) Wet floor, obstacle Pedestrian/Vehicle ECD Checkbox (Y/N) Automobile, golf cart, Segway, etc. Terminal Equipment ECE Checkbox (Y/N) Escalator/elevator Other/NA ECX Alpha GSE = ground service equipment; IFR = instrument flight rules; NAVAID = navigational aid; SRE = snow removal equipment. Table 4-4. Physical conditions related to event. perspective, the reporter can cite weaknesses that could serve as cautionary details to prevent similar events from occurring. Examples could include inadequate training, supervision, signage, or confusing or inaccurate procedures. 4.3.10 Narrative This data field, which allows the reporter to describe the event and circumstances leading up to it, can offer details about conditions extant that cannot otherwise be coded and categorized (see Table 4­7). They can also provide their own perspective on the cause, results, and reactions to the event. A reasonable limitation on the length of the narrative could be imposed, but the limit should allow ample space for the reporter to tell the story. The raw narrative report would be searchable based on keyword criteria. 4.3.11 Synopsis An abbreviated summary or synopsis can be derived from the event narrative based on keywords (see Table 4­8). The synopsis would serve as a searchable field and be useful for determining the context for searches of related events.

Developing an Operations and Safety Database 73 Event Response (ES) Multiple Entries Allowed Supervisor Dispatched ET1 Checkbox (Y/N) LEO Dispatched ET2 Checkbox (Y/N) Security Dispatched ET3 Checkbox (Y/N) Medical Dispatched ET4 Checkbox (Y/N) ARFF Dispatched ET5 Checkbox (Y/N) ATC Call Down (ARFF Alert for Aircraft Emergency) ET6 Checkbox (Y/N) Airline Dispatched ET7 Checkbox (Y/N) FBO Dispatched ET8 Checkbox (Y/N) Other/NA ETX Alpha Field Name Code Format Remarks Event Results (ER) Multiple Entries Allowed Physical Injury ER1 Checkbox (Y/N) Aircraft Damage ER2 Checkbox (Y/N) Vehicle Damage ER3 Checkbox (Y/N) Equipment Damage ER4 Checkbox (Y/N) Abort/Go-Around ER5 Checkbox (Y/N) Evasive Maneuver ER6 Checkbox (Y/N) Verbal Confrontation ER7 Checkbox (Y/N) Physical Confrontation ER8 Checkbox (Y/N) Environmental Contamination ER9 Checkbox (Y/N) Other/NA ERX Alpha Table 4-5. Results related to event. Field Name Code Format Remarks Contributing Factors (CF) Multiple Entries Allowed Confusing Procedures CFC Checkbox (Y/N) Construction Safety and Phasing Plan Inadequate Training CFT Checkbox (Y/N) New workers Inadequate Supervision CFB Checkbox (Y/N) Inexperienced foreman, supervisor Inadequate Equipment CFE Checkbox (Y/N) Inadequate Staffing CFS Checkbox (Y/N) No flagman Weather CFW Checkbox (Y/N) Fog, snow Airport Markings and Signage CFM Checkbox (Y/N) Construction barriers, stakes, etc., visible and/or present Airport Facilities CFF Checkbox (Y/N) Time of Day CFD Checkbox (Y/N) Dusk, dark Language Barriers CFL Checkbox (Y/N) Equipment Failure CFQ Checkbox (Y/N) Vehicle/radio breakdown Inadequate Communications CFO Checkbox (Y/N) Failure to read NOTAM Other CFX Alpha NOTAM = Notice to Airmen. Table 4-6. Contributing factors related to event.

74 Collecting and Sharing of Operations and Safety Data The metadata for each of these basic categories can be subdivided into specific data fields that serve as the taxonomy for the operations and safety database. Tables 4­1 through 4­8 are examples of a proposed taxonomy for an operations and safety database. Each event record will have a series of data fields following the metadata organizational structure that will allow it to be collected as input, and data categorized and indexed, with the filters established for data retrieval and reporting. Each of these components of a safety­related event can yield a robust sample that, when combined with similar events, will offer a much deeper understanding of their causes, circum­ stances, and consequences. Field Name Code Format Remarks Narrative NAR Alpha Describe what happened Table 4-7. Narrative of event. Field Name Code Format Remarks Synopsis SYN Alpha Brief summary (system generated) Table 4-8. Synopsis of event.