Introduction and Engineering Challenge
Parking garages play a key role in urban areas by storing vehicles securely while helping manage everyday movement of traffic. With car numbers rising, these buildings must stay strong and functional over many years despite exposure to road salts, moisture, shifting temperatures, or heavy use. Documents like ACI 362.1R and 372.2R point out that lasting performance depends on consistent upkeep; inadequate runoff systems combined with delayed repairs tend to speed up damage and increase restoration expenses.
The engineering challenge addressed in this report is how to systematically organize information about a multi-level cark park so that asset managers can understand which components exist, what functions they support, what their current condition is, and which maintenance action is required. At the moment this knowledge is usually distributed across drawings, inspection reports and regulations. An ontology helps tie these bits together; enabling questions like “What elements on Level 1 have low ratings and need fixing?” to be answered efficiently
The purpose of the ontological model is therefore to formalize the physical, functional and maintenance aspects of a typical reinforced-concrete parking structure in a machine-readable way. The focus is on clarity of the domain, a clear engineering use (maintenance planning and condition tracking), and well-defined interfaces to the environment.
System Description
Physically, the concrete skeleton of the building is straightforward. It has horizontal parking decks (floors) and vertical elements for support. Reinforced concrete slabs are the main driving and parking surfaces, and beams and columns transfer loads through the structure. The ontology groups these into:
- Floors: Basement, Ground Floor, Floor 1, Floor 2
- Structural elements: Slab, Beam, Column
Building Service Systems
A parking garage depends heavily on its building services. From NFPA 88A, ASHRAE HVAC guidance, PCI manuals, and WBDG, the key subsystems are:
- HVAC / Ventilation system – jet fans, ducts, CO sensors. NFPA 88A requires enclosed parking structures to be mechanically ventilated to manage air quality (NFPA, 2019).
- Drainage system – floor drains and gullies. Drainage failures are repeatedly linked to corrosion and concrete deterioration (ACI, 2012).
- Fire protection system – detectors, alarms, sprinklers. NFPA 88A defines the fire-safety provisions needed (NFPA, 2019).
- Electrical system – lighting and power distribution. WBDG describes lighting requirements and general electrical needs for parking facilities (WBDG, 2024).
- Access control system – ticket machines, barriers. These systems manage vehicle entry/exit and interact with external traffic (WBDG, 2024).
Functional Domains
Based on all the references above, a parking structure must satisfy four core functions:
- Safety (structural safety, fire detection, alarms)
- Ventilation (air quality per NFPA 88A)
- Water Management (drainage per ACI durability guidance)
- Illumination (lighting levels per WBDG)
The ontology models these as functional classes. Components link to the function they support.
Environmental Interfaces
Parking structures link to various outside networks. At entrances, connections exist with city roads, poor operation can cause queues and congestions at peak times. Water run-off inside ties into public sewage lines, while power devices rely on regional electricity supply. Outside factors affect function, although these parts aren’t included in system models. Later on
Ontological Development
Class Hierarchy and Domains
Three Clear Domains:
- PhysicalDomain
- BuildingSystemDomain
- FunctionalDomain
Supporting Classes:
- Component
- ConditionState (Good, Moderate, Poor, Critical)
- MaintenanceAction (Cleaning, Inspection, Repair, Replacement, Testing)
- ParkingStructure
All domains are disjoint.
| Axiom Type | Example in Ontology | Reasoning |
| Subclass relationships | VentilationFan is a subclass of HVACSystem | The ventilation fan belongs to the HVAC subsystem |
| Slab is subclass of StructuralElement | It’s a part of the structural element | |
| Disjoint Classes | Basement, GroundFloor, Floor1, and Floor2 are disjoint | You cannot be on Floor1 and Floor2 at the same time its either or |
| The subsystems (HVAC, Drainage, FireProtection) are disjoint | A component cannot be both a drain and a ventilation fan | |
| Existential Restrictions | Every VentilationFan must support VentilatoinFunction | This ensures all fan instances always contribute to ventilation |
| Transitive Property | hasCompenent is transitive if the structure has Floor2 and floor2 has Drain then the structure also has Drain | This is the “belong” logic |
| Inverse Property | isComponentOf is the Inverse of hasComponent | What does Floor1 contain? Well, what floor is this lighting on? Both are answerable. |
| Domain & Range | requiresMaintenanceAction links a ConditionState to a MaintenanceAction (Critical à Replacement) | Ensures that each condition triggers a specific maintenance step. |
Engineering Use Cases
Use Case 1: Prioritizing Maintenance
Asset Managers are able to list the components and mark them with their respective maintenance status instantly and see which actions they require. Removing the inspection reviews and notes.
Use Case 2: External Impact of Traffic Flow
As the AccessControlSystem is a part of the Ontology it is able to determine if an internal failure will produce external impact on the Traffic. During peak hours a malfunction on the access points of the car park will lead to congestions, road blockages or maybe accidents.
Use Case 3: Digital Twin and Real-Time Monitoring Integration (IOT + Ontology)
For MEP sensors are easy to integrate and mapped directly into the ontology. This will allow an Automatic change of condition state when certain thresholds are breached. Trigger Alerts could also be integrated into the ontology, when multiple failures occur that will compromise one of the subsystems so before this occurs an automated alert will be sent.
This ontology is quite flexible; the logic can be applied as a General Building Facility Management. To use in hospitals for example, an addition of new individuals (Chiller_01) and only a few new subclasses. Having a construction engineering experience, this ontology with a few minor tweaks can become extremely powerful in progress tracking and snag list follow-ups. As soon as new elements are constructed, they are added, keeping the same ontological format and logic. The conditions will change from states into statuses (Installed, Tested). And the Maintenance Is switched to action on this current activity.
References
- ACI Committee 362, “ACI 362.1R: Guide for the Design of Durable Parking Structures,” American Concrete Institute, Farmington Hills, 2014.
- National Fire Protection Association (NFPA), “NFPA 88A: Standard for Parking Structures,” NFPA, Quincy, MA, 2019.
- ASHRAE, “ASHRAE Handbook – HVAC Applications: Parking Garages Chapter,” American Society of Heating, Refrigerating and Air-Conditioning Engineers,2023.
- U.S. General Services Administration (GSA), “Parking Structure Design Guide,” U.S. GSA, Washington, D.C., 2011
- N. F. Noy and D. L. McGuinness, “Ontology Development 101: A Guide to Creating Your First Ontology,” Stanford Knowledge Systems Laboratory Technical Report KSL-01-05, 2001.
- PCI, “Maintenance Manual for Precast Parking Structures,” PCI, 2015.
- WBDG (2024). Parking Facilities.
- Krötzsch, Horrocks & Patel-Schneider (2012). Description Logic Primer.
Main | Introduction | Individual Systems | Integration Context | Combined Ontology | Combined Parametric Model | Analysis and Conclusions | References