DEVELOPMENT OF STANDARD-BASED INFORMATION REQUIREMENTS FOR THE FACILITY MANAGEMENT OF A CANTEEN

,


SUMMARY:
Facility Management (FM) is an essential practice for the operational phase of built assets.FM requires a vast range of data arising from diverse activities, which demands tools and processes for data collection and management.The Building Information Modeling (BIM) methodology implies an integrated information management process which helps in effective communication and information flow.Therefore, adopting BIM to support FM (BIM-FM) has become the subject of academic and industry interest.When BIM methodology is implemented, information models are the main information repository, while information requirements set the guidelines for their development.The EN ISO 19650 series and EN 17412-1 are currently the most recent standards in the European context to assist the development of information requirements.However, there is still a lack of research on their detailed application to realcase scenarios.In this context, the present article cooperates with the broad adoption of BIM-FM by presenting the establishment of information requirements to inform the development of an information model for the ongoing operational phase of a university canteen, focusing on developing Exchange Information Requirements (EIR), and including other activities of ISO19650's information management process to demonstrate the applicability of the requirements.The procedure applies the Level of Information Need (EN 17412-1) as the framework for defining the extent and granularity of the information requirements, and it employs the IFC schema to establish the required alphanumerical information.The paper thoroughly discusses the decision-making process and its implications, working as a detailed demonstration of the standards applied in a case study.The results demonstrate the efficiency of the purpose-driven process based on standardization, and the information model developed from the requirements is proven to deliver the required information accurately.Ultimately, the paper results in a robust source for process replication on FM real-case scenarios.

INTRODUCTION
Facilities are part of the built environment, being a place dedicated to a specific purpose.Its definition usually relates to buildings but also can include their surrounding infrastructure.A facility in its operational phase is already in use, and this phase corresponds to most of its life cycle, contributing to over half of its total costs (Heaton et al., 2019).The interdisciplinary practice associated with managing facilities during the operational phase is called Facility Management (FM), which is defined as a subject area of asset management within the ISO 55000:2014 (ISO, 2014).According to the International Facility Management Association (IFMA), FM is essential to the operational phase of a facility life cycle (IFMA, 2021) and its strategic objectives comprise diverse domains of administration, requiring effectiveness of communication and information flow (Araszkiewicz, 2017).ISO 55000 highlights that asset management is data-intensive, needing new processes and tools to assist in data collection, assembly, management, analysis, and use (ISO, 2014).Therefore, digital technology's high data storage and processing capability provide numerous solutions for FM activities (Araszkiewicz, 2017).
In this context, the FM industry has been growing interest in Building Information Modeling (BIM) as a methodology for integrated information management due to its foreseen benefits for the operational phase (Eastman et al., 2011;Demirdöğen et al., 2021), such as assistance in space management, accessibility studies, location of mobile building resources, safety and emergency management, energy analysis and control, among others (Nicał and Wodyński, 2016).The capacity for storing documentation and other data derived from BIM implementation often appears in studies as a benefit for FM processes (Durdyev et al., 2022).Despite what studies on the subject prove, the Architecture, Engineering, Construction and Operation (AECO) industry still presents low rates of BIM implementation in the operational phase of facilities (Borrmann et al., 2018).Considering the low adoption of BIM in the operational phase of facilities (Borrmann et al., 2018) and the fact that this phase represents most of a facility life cycle (Heaton et al., 2019), it is possible to imply that, in the current scenario, most facilities start the BIM implementation process with its operational phase already in course.
The low adoption of BIM to assist Facility Management (BIM-FM) accounts for the diverse challenges of its implementation.The main technological challenge is related to interoperability, with incompatible file exchange formats for information exchange between stakeholders and for using information models within FM platforms (Dixit et al., 2019;Jang and Collinge, 2020).The experience of this article's authors shows that the FM platforms usually do not easily incorporate the graphical representation of the facility to be managed and usually accept limited file formats to insert non-graphical information.In addition, there are also non-technological obstacles to BIM-FM adoption.Studies highlight process-related challenges, showing that the stakeholders involved in facilities operations currently lack an understanding of the information management processes using BIM and have an unclear understanding of BIM workflow, which implies information being captured improperly (Dixit et al., 2019;Rogage and Greenwood, 2020).The lack of awareness and experience of owners and facility managers tends to cause misunderstandings about what information is available and what they might require (Rogage and Greenwood, 2020).
To achieve a higher adoption of BIM-FM, facility managers need support in planning it strategically.Applying BIM to FM may require a shift in the information management process more than a technological shift (Yilmaz et al., 2023).Managing information using the BIM methodology includes, among others, a clear definition of what information is necessary about the assets to manage, where it will be stored, and how it will be accessed.Within the methodology, 'information models' serve as the collection of the information to manage.Therefore, the development of those models in an efficient way is critical to achieving high value from BIM implementation.To specify the information to be produced and stored on these information models (ISO, 2018a), it is necessary to develop the called 'information requirements' documents.Diverse authors have already pointed out the poor understanding of information requirements among facility managers as the main challenge to be faced by owners when implementing BIM (Parsanezhad and Dimyadi, 2015).Since inefficient requirements produce inefficient information models (G.Mayo and Issa, 2012), it is common for managers to deal with a lack of useful FM data (G.Mayo, 2014) within those information models.
Currently, guidance for the stakeholders involved in information management using BIM can be found on the normalization of the subject.First, the international standards series ISO 19650 is subdivided into different parts encompassing concepts, principles, documents and processes to assist the methodology's implementation.The published parts cover the concepts (part 1 (ISO, 2018a)), the application of the methodology for the delivery phase (part 2 (ISO, 2018b)) and the operational phase (part 3 (ISO, 2020a)), the information exchange process (part 4 (ISO, 2022)), and the approach for information security (part 5 (ISO, 2020b)).The part under development will encompass the health and safety approach (part 6).In addition, the European standard EN 17412 unravels the level of information need as the framework to define the extent and granularity of information requirements.The first part (EN 17412-1:2020(CEN, 2020)) covers concepts and principles to implement the framework, and the parts to be published will guide its application (part 2) and its foreseen data schema (part 3).The EN 17412 series is now under adoption at the international level as the ISO 7817 series.The standardized process defined by ISO 19650-3 and EN 17412-1 (ISO, 2020a;CEN, 2020) is crucial to delivering BIM business value for FM since clearly defined and purpose-driven information requirements is a key promoter of collaborative and effective information management (UK BIM Framework, 2019a).However, there is still a lack of documents that go beyond the standards, with insufficient real case examples and simplified methodologies addressing the development of information requirements for BIM-FM (G.Mayo and Issa, 2012).In addition, the available normalization about the level of information need currently only covers concepts and principles, and, despite a guidance under development, the stakeholders may miss an immediate reference for its usage, including the challenges and questions faced when applying the framework.
In this context, some studies address the development of information requirements for BIM-FM.Most authors present general information requirements that may serve as a starting point for those initiating the requirements definition (Luedy et al., 2020;Lu et al., 2018;Ashworth et al., 2019;Ashworth, S. & Tucker, 2017;Ashworth et al., 2017).Other researchers focus on requirements specific to case studies, considering individual information purposes, e.g.energy consumption and analysis (Farghaly et al., 2018;Sanhudo et al., 2021), HVAC-related corrective maintenance (Yang and Ergan, 2017) or fire evacuation simulations (Yakhou et al., 2023).The literature also shows some sources presenting a clear list of alphanumerical properties validated by FM professionals that can be consulted and included in the list of information requirements for general (Lu et al., 2018;Matarneh et al., 2020) or specific purposes (Luedy et al., 2020;Farghaly et al., 2018).Less often, there is also the demonstration of a thorough process to define such requirements with a robust final list of alphanumerical requirements for a specific purpose (Sanhudo et al., 2021).Even though such studies contribute to the definition of information requirements, dealing with general requirements may still be an obstacle to their replication in real cases.On the other hand, when case studies are considered, the developed requirements tend to be too restrictive due to considering only one purpose.In such cases, since FM activities have high variability among different facilities and organizations, and even within the same organization, those same studies may only partially assist such stakeholders if a detailed description of the process is unavailable.
Besides that, the literature still lacks standard-based and structured information requirements (Cavka et al., 2017).State-of-the-art studies (Luedy et al., 2020;Lu et al., 2018;Farghaly et al., 2018;Matarneh et al., 2020) that do not sort properties per object, suggesting them to groups with elements too distinct to have the same alphanumerical information associated, e.g.building systems (Luedy et al., 2020) or even with no mention to the objects the alphanumeric properties should be associated with (Matarneh et al., 2020).Furthermore, since the level of information need methodology requires, besides the alphanumeric information specification, the definition of geometrical information and documentation, the properties from those studies can not be considered part of a level of information need specification.In addition, some actors still refer to the concept of the Level of Development (LOD) for information requirements definition, even in recent works (Luedy et al., 2020;Sanhudo et al., 2021), which can be too generic and open to interpretation (Bolpagni, 2016) and disregarding the normalized concepts and processes from the ISO 19650 series.To the authors' knowledge, no publicly available study structures their information requirements definition entirely within the scope of the ISO 19650 series and the EN 17412.Therefore, a knowledge gap arises in the necessity of presenting a structured, detailed and standard-supported set of information requirements for the BIM implementation in the operational phase of facilities.
Based on the discussion above, this paper aims to present the implementation of the newest standards on the information management process using BIM (BIM according to the ISO 19650 series (ISO, 2018a)) to develop information requirements for the operational phase of an existing university canteen, applying the level of information need methodology from EN 174121 (CEN, 2020) as the metric for defining requirements in terms of geometrical, alphanumerical and documentary information, necessary to fulfil diverse purposes, and for different objects.The study suggests a case-related framework to support the operational information requirements definition according to the ISO 19650 series and provides a clear step-by-step application example of such standards (ISO, 2018a;CEN, 2020), demonstrating the challenges and problems faced during the decision-making process.Such scope avoids many generalities and encompasses different information purposes to cover various scenarios and increase the work's applicability.Consequently, the article's content supports the BIM adoption for the operational phase of facilities and helps enhance the digital transformation of the AECO industry.

INFORMATION MANAGEMENT STANDARDS AND MAIN CONCEPTS
Considering an asset as anything that has potential or actual value to an organization, the term can relate to complete buildings, parts of it, equipment inside it, or even any other type of construction or element relevant to its owner.The BIM methodology facilitates the operation of assets by using a shared digital representation of it as a reliable basis for decision-making (ISO, 2018a).This digital representation is a collection of information about the asset, "a reinterpretable representation of data in a formalized manner suitable for communication, interpretation or processing" (ISO, 2018a).To the extent that information is the main character of any management process, the implementation of BIM methodology can only have value to FM if its adoption is made through strategic planning on how to manage this information (Eastman et al., 2011;Pärn et al., 2017).The following subsections encompass the main concepts and specifications to support the implementation of information management processes using BIM methodology, taken from the normalization of the subject (ISO 19650 series and EN 17412-1).

Actors and respective responsibilities
ISO 19650-1 (ISO, 2018a) defines an actor as any unit (person or organization) involved in a construction process.The ISO 19650 series sort those actors as "parties" or "teams" and establish responsibilities to them within the information management process.The standards do not fix the following acronyms, but they were used here due to the numerous times the terms will appear in the text.According to the third part of the standard series, (ISO, 2020a), all the participants in the operational phase of an asset constitute the Asset Management and Operation Team.The central actor of any project is called the Appointing Party (AP), the primary requester and receiver of information (ISO, 2018a), which can be the owner or manager of an asset but may also be a third party hired for the information management function (ISO, 2020a).This paper uses the terms owner, facility manager and manager interchangeably.The remaining actors are arranged as part of one or various Delivery Teams (DTs).Due to the complexity and time scale of an operational phase, it is common for the AP (owner/manager) to deal with diverse DTs, such as external maintenance companies, cleaning companies, and suppliers, among others.These DTs have the main responsibility of producing and providing information to the AP (ISO, 2018a).All the actors inside a Delivery Team (DT) are called Appointed Parties (AedPs), which can either be: the Lead Appointed Party (LAedP), a type of coordinator, or be part of the called Task Teams (TTs).For instance, within a maintenance company (DT), there will be the insite workers (appointed parties forming a Task Team (TT)) and the maintenance coordinator (LAedP) who will not perform the maintenance actions themselves but will be responsible for planning the TT activities and for delivering the maintenance data to the manager (AP).

Information models and information requirements
An information model is defined in ISO 19650-1 (ISO, 2018a) as a "set of structured and unstructured information containers", being the information container a "set of information retrievable from within a file, system or application".Structured information is machine-interpretable and can include databases, geometrical models, etc.On the other hand, unstructured information is only human interpretable, including videos, documentation, etc.The development of information models results from information requirements, which are the "specification for what, when, how and for whom information is to be produced" (ISO, 2018a).The central statement of the ISO 19650 series is that information must be created for a specific purpose.Therefore, information requirements need to specify the precise necessary information that enables an action to happen so it can fulfil a purpose successfully.In other words, if the intended purpose of an information model is to assist with expense analysis by a university campus' manager, the information requirements he/she creates can demand monthly energy bill values for every building to be inserted in an information container (database linked to the information model) by the university's accounting team.Misleading input in the form of inadequate information requirements causes the development of an invaluable output, with inefficient information models being created.
According to the ISO 19650 management process, four main information requirement types exist, three of which relate to the facilities' operational phase.First, the Organisation Information Requirements (OIR) relate to the objectives and activities of the organisation.Such requirements can be strategic, tactical or operational and are specified in terms of what actions they need the information to support, e.g.overall financial analysis and control of the operational impact of asset failure.The second type is the Asset Information Requirements (AIR), which relates directly to a specific asset and shall define the information necessary during the operational phase of that asset (UK BIM Framework, 2019b).For a food manufacturer company, for instance, while the Organizational Information Requirements (OIR) level requires information to support its environment-friendly goals, for an asset like an administrative building, it may reflect in its Asset Information Requirements (AIR) as the request for placement of selective collection bins.In contrast, for the company's manufacturing buildings, the AIR may request the control and record of hazardous waste volume.
The Exchange Information Requirements (EIR) is the last document, being the only one not exclusively under the AP's responsibility.It can contain requirements from the AP to lead Appointed Party (AedP)s, or from the latter to AedP working for it (ISO, 2018a), e.g. the owner can prepare an EIR for an engineer responsible for a facility's construction management and, if this engineer hires a third company to perform specific work in the construction site, the engineer shall develop an EIR itself.There can be multiple EIRs if multiple appointments exist.The EIR shall answer the AIR by specifying the exact information required for the appointment, including the level of information need (see section 2.5 for further details).In addition, it shall contain security-minded considerations, the definition of timing and frequency of information exchange, and the acceptance criteria for each information requirement (ISO, 2020a).Finally, the standard also defines the Asset Information Model (AIM) as a response to the AIR, specified by the definitions from the EIR.

Trigger events, appointments, and information delivery milestones
The ISO 19650 series define trigger events as planned or unplanned events to happen during an asset life cycle that cause a change in an asset and lead to information creation or update (ISO, 2018a).During the operational phase, the handover can be considered the first trigger event.The RIBA Plan of Work 2020 (Riba Architecture, 2020) defines the handover as the moment the facility is handed over to the client, initiating its operational phase (ISO, 2018a), or use stage (Riba Architecture, 2020).Considering a context where the ISO 19650 is implemented, the handover event will imply that an information model will also need to be handed over to the client.After that event, many are the possible trigger events to happen while the facility is in use: equipment breakdown, periodic inspections, renovation projects, and change in ownership of an asset, among others.To deal with such events, a facility manager (AP) shall plan the actions to respond to them, implying information updates or creation.An agreed instruction for providing the information is called an appointment within the ISO 19650 series, and such appointments can be linked to one or more trigger events.For instance, a manager (AP), when hiring an external maintenance company (DT) to execute repairing actions and send updated information about the equipment repaired, is performing an appointment.Also, when the AP establishes that this repairing work will be necessary if and when any equipment breakdown occurs, the actor is linking the appointment with multiple trigger events (equipment breakdowns).In addition, the AP shall define the information delivery milestones, which are agreed moments for exchanging information, and can be unique or multiple for the same trigger event.If we consider the illustrative appointment cited before, if it is agreed that the maintenance company must not only perform the repairing action but also, some months later, carry out an inspection on the equipment to verify its condition, the same trigger event (equipment breakdown) would generate two different information delivery milestones: when information on the repairing work is delivered and after the inspection.

Common data environment (CDE)
ISO 19650-1 (ISO, 2018a) defines the Common Data Environment (CDE) as the agreed source of information for collecting, managing and disseminating information containers, including an information storage solution to support the information exchange and the workflow necessary to use it.First, the AP establishes the technology to support the process, including a storage technology system, which can be a generic one (e.g.Google Drive, Dropbox, One Drive, Notion, among others) or one specialised in information management (e.g.BIM360, usBIM, Trimble Connect, among others).When deciding upon the storage system, the AP must opt for one that the information container to transit between three states: work in progress, shared, and published (ISO, 2020a).Second, the AP establishes how the information exchange will happen, the criteria for the information container to transit between the states, and the access limits for each actor in terms of information stages and containers.

Level of information need
The first part of the ISO 19650 series (ISO, 2018a) designates the level of information need as the "framework which defines the extent and granularity of information", and ISO 19650-3 (ISO, 2020a) states its definition as a part of the EIR.The European Standard EN 17412-1 (CEN, 2020) regulates the utilization of the level of information need framework and establishes four prerequisites to be previously defined to allow its specification.The prerequisites are the Purposes, the Information Delivery Milestone, the Actors, and the Objects, which relate directly and respectively to the why and when the information is to be delivered, from who and for whom, and finally, for what objects the information is needed.
When defining the first prerequisite (purposes), the AP needs to clarify the needs for the information, e.g.allowing clash detection analysis, informing maintainers workers on assets data necessary to perform their jobs, or serving as a historical record of alterations suffered by a given asset.The second prerequisite (information delivery milestones) relates to defining when the information exchange will occur, e.g. at handover or during the remaining asset life cycle, after a given information updating event occurs (trigger event).The third prerequisite (actors) is to specify who will develop each information container and for whom it must be delivered.Assuming the operational life of an asset, the actors involved may be numerous, including the manager of the facility but also maintenance crews or equipment vendors.The last prerequisite (objects) defines the assets to which the level of information need refers.The objects must be considered within a breakdown structure, and their level within the breakdown structure may vary from a unit to a group of objects, i.e. from a single bolt to a car, from a unique wall to all the architectural elements as a group, or from a faucet to the whole water supply system of a building.Within the same project, the level of information need can be the same for the whole water supply system or may be separately specified for the faucets and sinks.
Combining the four prerequisites assists the level of information need definition.For instance, for a car industry operation, it is required that the vendor (actor delivering information) of the wheels sends an information model of the specific wheel type (object) to the manager of the production line (actor requesting information) on the day of the wheels purchase (information delivery milestone) in order to keep a record of the product specification (purpose).For this combination, the manager of the industry should have a level of information need where the information necessary for such actions is requested.The level of information need that the information model must answer to is segregated in terms of geometrical information, alphanumerical information, and documentation, which are better explained in the following paragraphs.

Geometrical Information
It is divided into five aspects: detail, dimensionality, location and parametric behaviour.The Detail is a continuum ranging from simplified to detailed, describing the object's geometry complexity.As more refined, the more features it presents and the closer to the shape of the real world the object will be.For instance, in this aspect, the requirements for a specific purpose will define if the information model of a printer shall have its buttons or if just the object's volume.Dimensionality describes the number of spatial dimensions required, varying from one point to a three-dimensional representation.Location can be relative or absolute and describes the position and orientation of an object, i.e., if it is against another object or a reference point.Appearance is a continuum ranging from symbolic to realistic, describing the visual representation of the object.As more refined, the object will look closer to its actual appearance.For instance, in this aspect, the requirements for a specific purpose will specify if a wooden door will have a representative colour or if it must be represented with the exact texture of the material.Finally, Parametric behaviour is composed of three degrees, which describes if the object's shape, orientation, and position allow full or partial reconfiguration by those manipulating the information model in the future.

Alphanumerical Information
The alphanumerical information is subdivided into two aspects: Identification and Information Content.The former allows locating the object within the predefined breakdown structure, so it is possible to understand to which object the level of information need refers.The latter is the list of all required alphanumerical properties that must be associated with a given object, e.g. if the information model of a lamp must have a property called voltage associated with it.The quality of the alphanumerical properties inside an information model impacts the feasibility of its use and sharing by the various actors throughout the course of a facility's lifecycle (Cassano and Trani, 2017;Cheng et al., 2020).The standards on BIM methodology (ISO19650 and EN 17412) are inherently generic, not providing specific information to standardise alphanumerical data for construction materials and products.The EN ISO 23387 (ISO, 2020c) defines 'Data Templates' as standardised, interoperable data structures used to describe the characteristics of construction products, systems and objects.Therefore, Product Data Templates (PDTs) can be a source for helping define alphanumerical information to populate an information model (Mêda et al., 2021), depending on the purpose considered.In the Portuguese context in which this article fits, there is an absence of normalized PDTs and the first Portuguese initiatives in this direction are being initiated by the Standardization Technical Committee CT197.

Documentation
As for the last aspect, Documentation is defined as a set of required documents about an object that must be delivered.The documentation not necessarily relates to physical papers and can be virtual documents directly linked to the geometrical or alphanumerical information.For instance, obeying the maintenance purpose, the aspect documentation can be required as the need for a machine's insurance certificate as a web link inside the information model's alphanumerical properties.
It is crucial to highlight that the requirements for a given object may vary among purposes for the same delivery milestone involving the same actors.For instance, maintenance purposes may require insurance documentation for pieces of equipment, but for space management purposes, this is not required.In this case, if we consider the information exchange to be unique, meaning one information model for both purposes, the documentation must be required in the final level of information need; otherwise, one of the purposes (maintenance) will not have all the necessary information.Such action will generate the combined level of information need, encompassing a more comprehensive requirement for each framework aspect to satisfy them individually.

METHODOLOGY AND FRAMEWORK
The developments of this study are framed within the scope of the Cognitive Computerized Maintenance Management System (Cognitive CMMS) consortium, a partnership involving the company Valuekeep and university bodies from University of Minho (UMinho), including the Social Action Services (SASUM).Valuekeep specialises in developing maintenance management software orientated to industrial clients, focusing on maintaining largescale equipment (Valuekeep, 2021).SASUM is one of the services units of the University, being responsible for providing students with services in the areas of accommodation and food (SASUM, 2022).The consortium is a research project aiming to develop a platform for integrated management activities and considering the BIM methodology premises.From the consortium's extensive scope, the present research goal is to develop information requirements documents using the guidance of the newest standards on the BIM subject (ISO 19650 series and EN 17412) to support the development of an information model of one of the consortium's case studies.Therefore, even though the standards cover the broad scope of information management processes, this research narrows its content to focus on the steps related to supporting and developing an information model.The project's scope defined the case study as a building already on the FM stage for which there was no information model, and its management was not under the ISO 19650 series premises.The information model developed would be later used as a primary information source for FM simulated activities and analyses, and the whole process had to be done using open formats.
The case study selected was the canteen of the UMinho, located on the Azurém campus in Guimarães, Portugal.SASUM is the manager of the chosen facility, being responsible for its administration and management.The canteen began operating in 1996 and can serve 1.500 meals per hour (SASUM, 2022).It is a multi-story building with five different levels, three main ones and two intermediates, with a total of 3.126,71 m 2 .Floorplans of the building can be seen in Figure 2. The canteen comprises boundary elements, moving components, building systems, and spaces.The boundary elements group includes architectural and structural elements.The architectural elements are non-structural walls, doors, windows, floors, and any other element in the building or exterior facades with architectural functions.The structural elements are the concrete columns and walls, beams and slabs and also the foundation of the building.The canteen also presents structural masonry walls that can be noted on the exterior facade of the building and interior ones serving as support for the internal stairs.For the moving components, the group is composed of four subgroups: kitchen equipment, kitchen support equipment, furniture, and monitoring equipment.The kitchen equipment has the function of preparing or storing food, the kitchen support equipment assists the food preparation and serving, and the furniture helps in the canteen utilization.Finally, the monitoring equipment is still to be installed in the canteen, they are the sensors to measure the spaces' temperature, humidity, and CO2 concentration; and the beacons to monitor the equipment positions.The building systems group comprises the facility's critical systems (water supply system, rainwater drain system, sewage system, gas supply system, fire protection system, electrical system, and HVAC).The space group is self-explanatory, delimited by physical and non-physical limits, depending mainly on their usage.
Based on the well-defined scope and goals of the consortium and selection of the case study, a literature review assisted the knowledge collection on concepts and principles about the research aim (section 2), including the standardization (ISO 19650-1:2018, ISO 19650-3:2020, and EN 17412-1:2020), guides (UK BIM Framework, 2019b), manuals (NATSPEC BIM, 2018;NBS, 2019) and other studies that propose to support information requirements definition.With the aim of establishing what framework this research would follow, the information management process framework from ISO 19650-3 (ISO, 2020a) was analysed and applied in the research context for the assessment of which of the framework steps would be relevant to keep on the research context, generating a summarized version of the framework that is presented later in this section (Figure 3).
Following the given framework (Figure 3), the information requirements were created (section 4).Section 4 includes the definition of information purposes, selection of relevant objects within the case study, and development of the level of information need (CEN, 2020), using the Industry Foundation Classes (IFC) schema (IFC4 ADD2 TC1) as the main source for the alphanumerical information establishment.The level of information need was created using spreadsheets presenting tables with their content and then structured as a relational database using the MySQL workbench.The complete process described in section 4 happened as a cycle of pre-definitions performed by the authors that were later on assessed by Valuekeep experts and SASUM (canteen manager) on a sequence of meetings to define their approval or rejection.
Valuekeep's experts already had prior knowledge of what information would be relevant to the assets due to their direct work with their own clients.On the other hand, SASUM contributed to what information was needed to fulfil their current management system.However, SASUM had no prior expertise in implementing the BIM methodology, the documentation involved in the process, and potential formats for information exchange.In this process, the authors' contribution filled the knowledge gaps of the other experts, resulting in an effectual output.During the assessment process by those experts, their years of experience with dozens of clients and the clear intention of the information model to be later used on Valukeep's management platform were the central conductors to the requirements definition.After the final review by the experts from the consortium, the requirements were also discussed in a series of meetings with two FM professionals from a multinational food retail company with a combined time of more than 15 years of experience.
With the requirements defined, the documents informed the case study's modelling process using the architectural module of Autodesk Revit 2021 (section 5).The information model created was exported as a STEP file following the IFC schema, verified using the Solibri Office and imported as the primary information source on the PowerBI platform to perform simulations of FM analyses, such as a search on the warranty end date of the equipment.Finally, the main conclusions were outlined in section 6.The process and results described in this article guide the reader through the steps of implementing BIM for FM, using a simplified and yet standard-based framework applied to a case study and giving a basis for its replicability to similar real case scenarios.The process of simplification of the ISO 19650-3's framework (ISO, 2020a) is detailed next.

ISO 19650-3's information management framework applied to the case study
The information management framework which guides this study was developed as a simplification of the one presented in clause 4.1 of the third part of the ISO 19650 series (ISO, 2020a).In an orderly manner, the original framework introduces the actions foreseen to be taken by stakeholders involved in the process, subdivided into groups of activities, activities and sub-processes (called steps here).Three different paths of action are suggested and vary depending on when the agreement for information provision is taken: before or after a trigger event or if the information model is already developed and will be transferred from one owner/manager to another.In the context of the Cognitive CMMS consortium, the case study has no information model developed, and the trigger event was considered as the moment of the cooperation agreement between the parts involved.Therefore, all the actions in this study were taken after the trigger event, i.e. cooperation agreement.This scenario relates to the "steps undertaken for each appointment made after trigger event" path (Path C) suggested by the standard (ISO, 2020a), which is represented in Figure 3.
Figure 3 is an adaptation of the standard's framework, and the letters and numbering codes agree with those used in the original image to facilitate correspondence with the reference (ISO, 2020a).Following the statement from ISO 19650 series (ISO, 2018a; ISO, 2020a), the activities and steps from the original framework (ISO, 2020a) were evaluated and developed according to the scale and complexity of the intended project.In the project context, the framework should correspond to the implementation of ISO 19650 series guidance in the FM of an existing facility, where the operational phase was already in course.A scenario in which the case study was a newly constructed building would imply a slightly different application of the steps from the methodology framework.The cases in which this difference can be observed are cited throughout the article.In Figure 3, the activities highlighted by the grey boxes relate to those relevant to this research and which were undertaken during the development of this work.In contrast, the white boxes relate to activities foreseen by the standard but with no relevance in this study's context.The decision-making process to select the activities is detailed in the next sections.

Assessment and need (A1)
Assessment and need (A1) is the first activity of the framework, and all thirteen steps within it are the responsibility of the AP. Figure 4 breaks down the steps within A1, and the grey colouring identifies the relevant ones in the scope of this paper.All the steps from this activity are developed in section 4.1 of this article, with some being grouped and simplified.The definition of OIR and AIR is described together in section 4.1.1,and the information standards and information production methods and procedures are joined and simplified in section 4.1.2.Originally, the activity of assessment and need (A1) does not relate to any appointment or trigger event, appearing before those definitions in Figure 3.However, in our context, since the process of ISO 19650 implementation started during an operational phase, all the steps performed happened after the agreement to develop the information model, which is considered the only trigger event of this study.This is the only case where the fact the building is not a newly constructed one interferes with the decision on the relevant steps from the framework.From the grey steps in Figure 4, four of them have their outcomes predefined in the consortium's scope.The main pre-definition is the authors involved in the process (Step 1.1).The Appointing Party (AP) is the SASUM as it is the facility's manager, which has the information management function and is responsible for developing the information requirements.The role of the actor developing the information model (Appointed Party and Task Team) and exchanging it with the owner (Lead Appointed Party) was assumed by the authors, referred here as the Delivery Team (DT).Due to the academic profile of the project, the authors had the function of closely supporting the AP on the development of the information requirements.This definition also relates to the obligations of each actor being already pre-established (Step 1.13).In addition, the case study is already defined as the asset relevant to the organization in the given project (Step 1.3).On the other hand, three steps were suppressed from the framework (white boxes in Figure 4).Given the provider and requester of information (AP and DT) are the same individuals, no information exchange is necessary until the moment the information model is sent to the facility's manager; thus, neither a CDE workflow nor a CDE solution is necessary (Step 1.9).With no enterprise system, Step 1.10 is irrelevant to the study.Considering this is the first information model of the facility, there is no existing AIM to be established (Step 1.11).

Procurement stage (Group E)
There are two main activities within the procurement stage (Group E in Figure 3): the request to provide service (Activity A2) and the response to such request (Activity A3).The first (A2) involves five steps under the Appointing Party's responsibility (AP), and the latter (A3) defines different responsibilities within the Delivery Team (DT) for different activities.In the consortium's scope, there was no official procurement and hiring process, the agreement for information provision happened through an oral, non-contractual accordance.Such context does not entirely eliminate the framework's procurement stage (Group E) but implies a simplified process (Figure 5).The activities providing the information (Step 2.1) are already established in the consortium's scope, being unique and corresponding exclusively to the trigger event considered for the project.The definition of the EIR (Step 2.2) represents the main content of this work and it is developed in section 4.2.1, including the definition of the level of information need (section 4.2.2).The definition of reference information is in section 4.2.4 (Step 2.3 of Figure 5), but the shared resources are not included due to the simplified agreement process.This simplification also implies neither the evaluation criteria nor the compilation of documents for the invitation to tender is necessary, suppressing Steps 2.4 and 2.5 from Figure 5.

Information planning stage (Group F)
The Information planning stage (Group F in Figure 3) also encompasses two activities: appointment (Activity A4) and mobilization (Activity A5).Due to the simplified procurement process of the project, A4 is excluded from the framework (Figure 3).On the other hand, mobilization is included in the process (Figure 6).A5 is extremely simplified, and the software testing is the only relevant action (Step 5.2), which is included in section 5.

AIM aggregation (A8)
The AIM aggregation (Activity A8) is not considered for the framework (Figure 3) since there is no existing AIM in which the new one would be aggregated (Step 8.1) and because the maintenance of the information model is beyond the project scope (Step 8.2).

INFORMATION REQUIREMENTS DEVELOPMENT
This section unravels how the methodology and framework described in section 3 are applied to the case study, following the ordering of Figure 3 and presenting the decision process and main discussions together with the requirements.

OIR and AIR
Following step 1.2 (Figure 4), the OIR needs to be developed since the owner does not have it formalized.Considering that SASUM has a broad range of responsibilities within the university, the AP and the SASUM's administrator analysed the organization's missions and strategic guidelines to filter them into the main organizational objectives on the scope of the present study.Therefore, the objectives are the SASUM's missions aligned to the case study, i.e. related to buildings management (Table 1).After establishing four main objectives, a set of OIR was derived, and the information required for the AIR was defined considering the canteen as asset (Table 1).Finally, a list of ten purposes at AIR level was established (Table 1).For instance, SASUM has as an objective to "keep the university installations and infrastructure efficient and prepared to feed the occupants' needs", in the OIR level, they need the information to keep "an accurate computerized record of the building's assets".At an asset level (AIR), the SASUM needs to have "maintenance manuals and equipment specifications" for the equipment to fulfil the "asset maintenance" purpose.
Although ISO 19650 series and EN 17412 only use the term "purposes", the concept of "BIM Uses" is still spread in current and well-accepted bibliographies about BIM.Therefore, the BIMExcellence Model Uses Table (BIMExcellence, 2019) was used in this study as a reference source to define information management purposes, creating a direct association between the model uses from the reference list and the purposes (Table 1).

Information standard, production methods and procedures
Equivalent to steps 1.6 and 1.7 in Figure 4, the definitions within the information standards and production methods and procedures were joined and developed on a small scale (Table 2) due to the project's reduced magnitude in terms of objectives and stakeholders involved.
Table 2: Information standard, production methods and procedures.

Key point Definitions a) the capture of existing asset information
The party responsible for information production will have access to the reference information and shared resources that must be provided by the owner of the building.

General
The building file must be named as follow: Building_UMinho_NameOfTheBuilding.The individual objects' files must be named as follow: Type_Manufacturer_Model All selected assets must be modelled following the guidelines of their respective Level of Information Need The assets should be classified using the newest version of the Uniclass 2015 classification system.
The model must be built considering the architectural finished floor levels.
The model should be georeferenced using the Coordinate System ETRS89 / Portugal TM06.
For alphanumerical information, neutral values must be used to avoid empty properties when no information is available.The neutral values: "n/a" (alphanumeric), "0" (numerical), and "1900-12-31T23:59:59" date.The only exception is the booleans value that should be left empty.

Architectural Elements and Structural Elements
Walls and columns must be modelled per floor.
Interior walls should be modelled from the top of the floor finish to the bottom surface of the above slab or beam.
There must be no overlap or gap between slabs and walls.
Floor slabs should be aligned with the inside surface of the outside walls if there is no other design orientation.
The slabs must be properly connected to adjacent elements.
Doors and windows must be contained within the wall elements.
If windows are spanning more than one floor, they should be modelled as openings in the walls of each floor of the building.

d) the delivery of information
It is required the information provider to check the authoring software exporting certificates to ensure their capability to export models in the IFC version agreed for the project.
The project agreed version of the IFC schema must be IFC4 ADD2 TC1, since it is the most recent regulated one.The list of official releases of the IFC specification can be check at: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ The objects must be associated correctly to the native classes of objects from the IFC schema.
Invariably, it is imperative to guarantee the correct and appropriate definition of the properties to export the information about the IFC Entity and Predefined Type for all the elements modelled, according to the IFC schema version defined for the project.

Exchange Information Requirements
Step 2.2 (Figure 5) encompasses the definition of the EIR.To answer the main points ISO 19650-3 (ISO, 2020a) requests, it was established that: (i) security considerations are covered in section 4.1.2,(ii) about the timing and frequency of information exchange, there is only one information exchange equivalent to the moment the DT delivers the information model to the manager of the building, (iii) for the acceptance criteria, the only determination is that the information model and respective information containers must be 23following the geometrical requirements and hold all the established properties from the alphanumerical information requested, (iv) and composing the largest part of the EIR developed, the level of information need from EN 17412-1 (CEN, 2020) was used to establish the information to be captured as a response to the trigger event.

Level of information need
This section presents the definition of the level of information need for the case study, starting with the prerequisites and then explaining the decision process to define geometrical information, alphanumerical information and documentation.

a) Prerequisites
The first step for the level of information need specification was to consider the prerequisites established by EN 17412-1 (CEN, 2020): the prerequisite 'Purposes' is equivalent to those defined previously in 4.1.1 as the AIR purposes (table 1); the 'Information Delivery Milestone' prerequisite is unique and called Handover; considering the 'Actors' prerequisite, they are also unique for all the purposes, being the AP the actor requesting the information on behalf of SASUM, and the DT is the author in charge of developing the information model, responsible for delivering the information; the 'Objects' are established next.

Objects
The elements within the canteen were assessed and organized within a breakdown structure according to their functional decomposition.Three groups of assets to manage were selected and renamed from the elements composing the canteen (section 3): Architectural and Structural Elements, Equipment and Spaces, with the Equipment group presenting two subgroups: Monitoring Equipment and Kitchen Equipment.Each group or subgroup is composed of items and divided into sub-items (Table 3).The selection process is explained below.
In group 1, the boundary elements are included.Among those, the architectural elements are relevant for all scenarios as they constitute the physical building boundary.The superstructure's structural elements may influence maintenance activities in the building and were selected, even though no maintenance activity is foreseen for this type of element in the project's scope.In group 2, The sensors and beacons planned to be installed in the building were inserted within subgroup 2.1 in Table 3. Their selection is necessary since the information derived from those appliances is planned for FM analyses in the building and is included in the project's scope.
Still considering the Equipment group (group 2), the kitchen equipment has a crucial role in the operation and functioning of the canteen.Therefore, from the remaining equipment of the building inventory, the selection focused on the most typical type of equipment for the use case, which enables a more specialized information requirements definition, i.e. kitchen equipment.Within the kitchen equipment (subgroup 2.2), the goal was to avoid more than one type of equipment presenting similar functions and, consequently, similar information requirements.Therefore, a sampling of six types was selected (items 2.1.1 to 2.2.6).Considering the correlations between different types of equipment, 35 out of 47 units of kitchen equipment inside the canteen are encompassed by the requirements created.No systems were selected since no FM activity is planned for them considering the chosen purposes and project's scope.In addition, typical building equipment (e.g.HVAC system equipment) is already the subject of several research studies.Finally, group 3 relates to the assets' locations being relevant to many of the intended purposes.
The sub-items are analysed together by their general item for the requirements development.The objects in Table 3 were previously classified according to the available IFC entity types and predefined types.This is because the AP intends to use the IFC suggested property sets to formulate the required properties for the objects (item b in this section).This decision is based on two main points.First, following the IFC's nomenclature rules for properties and its hierarchical information organization would guarantee information exchange with low data loss.Second, IFC has a large relational data schema that includes elements, relationships and properties organized in groups associated per entity or intended use, being a substantial source of properties.
As allowed in EN 17412-1 (CEN, 2020), for the definition of the level of information need, the objects can be referenced by the items, names, groups, or subgroups, according to the most effective arrangement.For example, the Spaces group joins all different types of spaces, which are exported with the same IFC entities despite their usage, and such differentiation is not necessary for the foreseen purposes.Besides defining the relevant objects, some assumptions were made for the correlation between assets and purposes: spaces are just considered as assets for the purposes VI to X (Table 1); for the "Real Time Utilization", the assets from the kitchen equipment group is not considered; also, for the "Energy Utilization" purpose, the subgroup monitoring equipment is not considered since both genres of assets do not use energy for operating.
Table 4: Scale for the Detail aspect.

Architectural and Structural Elements
SIMPLIFIED_Arq.The object represents the real shape of the physical elements' external boundary.The object is a single element with no layers or components.
DETAILED_Arq.The object represents the real shape of the physical elements' external boundary.The object contains all the functional layers and components.The layers are in the order they are assembled and present their actual thickness.

Equipment
SIMPLIFIED_Eq.The object represents a simplified shape and volume of the physical element's external boundary.
DETAILED_Eq.The object represents a simplified shape and volume of the physical element's external boundary without providing any further detail, including the required volume of the operational and maintenance space (clearance zone).
TABLE 5: Scale for the Appearance aspect.

Object Scale
All objects SYMBOLIC.The object displays a grey colour.If requested, the clearance zone shall be transparent red.
REALISTIC.The object displays colours equivalent to reality, with no texture.If requested, the clearance zone shall be transparent red.

Geometrical Information -Appearance
Requirements for the Appearance aspect vary between "Not Applicable", "SYMBOLIC", and "REALISTIC" (Table 5).A SYMBOLIC appearance is requested for purposes where the object does not need a colour resemblance to reality, as for Asset Maintenance (Table 7).A REALISTIC appearance was requested for all objects related to "Visual Communication", meaning their modelling with colours equivalent to reality with no texture.The only exception to what was just mentioned is the group Spaces, for which the aspect is "Not Applicable" for all purposes since none of them presents the necessity of visualizing the spaces as a unit.

Geometrical Information -Dimensionality
For the Dimensionality, it is required for all purposes that the objects are presented three-dimensionally (3D) (as in Table 7).This decision considered the fact the requirements focus on the 3D information model as the main deliverable of the project.

Geometrical Information -Location
An "Implicit to IFC" location is required for the whole project's combinations of objects and purposes.This designation means all objects are georeferenced, and they also relate to other objects (including spaces) around them.

Geometrical Information -Parametric Behaviour
For the Architectural and Structural Elements, an alteration of the model would only be necessary in case of a building renovation takes place, which already would imply the development of another information model.For the Equipment, an alteration would imply a new piece of equipment is replacing another one being discarded, also requiring its substitution on the information model.Therefore, the Parametric Behaviour was set as "Not Applicable" for all the assets and purposes (as in Table 7).

Alphanumerical Information -Identification
The Identification aspect of all assets must present their respective types, following the breakdown structure presented in Table 3.

Alphanumerical Information -Information Content
Some assumptions were made for this section of the level of information need.First, the "Life Cycle Assessment" purpose is the only one where the Architectural and Structural Elements group has a list of required properties.For the remaining purposes, the group serves as a representation of the physical building boundary, implying only their Identification is required and the list of alphanumerical properties (Information Content) is established as "Not Applicable".Second, for the "Space Management" purpose, the only category that required alphanumerical properties was Spaces.For the remaining categories, the only aspect required from the Alphanumeric Information is their Identification.
The Information Content was defined per object type, i.e. the list of properties inside the Information Content is defined separately for dishwashers, ovens, and sensors, even if the group equipment has the exact requirements on geometrical information and documentation.For example, considering the "Real-time Utilization" purpose, sensors can require a list of alphanumeric properties to store their measurements while ovens do not need to require any property, even though both are represented with the same complexity of geometrical information.
An example of part of the Information Content tables is shown in Table 6.On the tables containing the information content, the properties were defined and categorized as Type or Instance properties, so it is clear if their values relate to those common to a type of object or to a unit of this type.In addition, the data type and units were established per property to guarantee the correct filing of its value inside the information model.The properties were grouped in their respective property groups and have a brief definition associated with each (Table 6).The process of properties' definition was subdivided depending on the source of the alphanumerical property, IFC schema (IFC4 ADD2 TC1) or created by the authors, and its grouping also obeyed its source.Combining all the purposes, the number of properties per object was thirty-seven for the Architectural and Structural Elements group, and it varied from eighty-one to ninety-seven properties for the Equipment group.
The properties from the IFC schema represented around 90% of the number of properties selected for the Equipment group, and the totality of it for the Architectural and Structural Elements group.Primarily, the available Property Sets and Quantity Sets (both called Psets in this article) from the schema were assessed per their relevance to the intended purposes.Primarily, the list of Psets related to each entity type was evaluated.As for a Dishwasher or an Oven (IfcElectricAppliance), both Psets suggested by the schema were considered relevant and all the properties within both sets were selected.Therefore, any asset identified as IfcElectricAppliance within the schema has these properties as requirements.In addition, among the objects identified as IfcElectricAppliance, there were also suggested Psets for each predefined type.The Pset_ElectricApplianceTypeElectricCooker was considered for objects with ELECTRICOOKER as PredefineType (Oven, Fryer, and Grill), and Pset_ElectricApplianceTypeDishwasher was considered for the Dishwasher.For the Refrigerating chamber, there were no Psets added to the ones already established by its entity type.
For the walls (IfcWall), the respective Pset_WallCommon was considered relevant for "Life Cycle Assessment", since this is the only purpose to which the group of this object have associated properties.When assessing the properties individually, Reference and Status were the only ones considered relevant.In the case of the Spaces group, the assets only have related Information Content for "Relocation Management", "Space Management", "Real-time Utilization", and "BIM/FM Integration" purposes.Specifically, for the purposes of "Asset Maintenance" and "Asset Tracking", just the positional association between assets and spaces is necessary, dismissing any alphanumerical property.In addition, the definition of properties for spaces is also irrelevant for: the "Visual Communication" and "Virtual Reality Simulation" purposes, since those are visualization oriented purposes; the "Energy Utilisation" calculation, since the purpose only considers the energy consumption of equipment; and the "Life Cycle Assessment", because spaces do not have associated environmental impacts.After analysing the suggested Psets per entity type and predefined type, the other available Psets from the schema were evaluated.For the Architectural and Structural Elements and the "Life Cycle Assessment", all properties from the Pset_EnvironmentalImpactIndicators and Pset_EnvironmentalImpactValues were added to their required information content.For the Equipment group, a total of nine Psets were added to the list of required properties.
Aiming on tracking the manufacturing and warranty relevant information, Pset_ManufacturerOccurrence, Pset_ManufacturerTypeInformation, and Pset_Warranty were chosen.Pset_Condition, Pset_ServiceLife and Pset_Asset were selected to maintain current asset status information available.Finally, another common Property Set (Pset_ElectricalDeviceCommon) was also added to the requirements for all IfcElectricAppliance.
After all the suggested properties from the IFC schema had been assessed, custom properties were defined and organized in user-defined Psets to cover needs that were not in the schema.For the Architectural and Structural Elements or spaces, the properties available in the IFC schema already encompass the required information for the stipulated purposes.However, for the Equipment group, two Psets were created: UMinho_TypeInventory and UMinho_Inventory, as in Table 6).The Psets relate to the identification of the pieces of equipment within the university's inventory and were applied to all assets of this group, encompassing Type and Instance properties, respectively.A third Pset was necessary for the Sensors (UMinho_SensorHistory in Table 6) since such type of equipment performs three different types of measurement (Temperature, Humidity, and CO2 concentration), and the IFC schema does not have built-in properties to keep the measurements from three different sources at the same time.The user-defined Psets were named according to the nomenclature rules established by OBOS (NATSPEC BIM, 2018) and BOS 2019), following the information production methods and procedures in 4.1.2.Specifically, the name begins with the properties source (UMinho) followed by an underscore and finishes with a property's content description.For each property within the Psets, the source (UMinho) was added at the end of their names, allowing their easy identification as user-defined.

Documentation
Documents are only required in the case of the object within the Equipment group, relating specifically to Installation Manuals and Technical Descriptions.The documents are required as hyperlinks for their web address inside the Alphanumerical Information into the adequate properties within the Information Content since it is the most current way of accessing this type of information.

Level of information need combination and database
The level of information need was developed primarily using excel spreadsheets, and then a relational database was created to store the requirements.Figure 9 shows the relational database diagram.All the prerequisites for developing the level of information need (Purposes, Actors, Milestones and Objects) were represented as individual entities and each type of information of the framework (geometrical information, alphanumerical information and documentation).The authors understand that the Object is the central prerequisite of the level of information need definition since the requirements translate individually the information necessary for a specific object (which can be unique or a group).Therefore, to develop the relationship among objects and other entities, two others were added ('infoexchange' and 'infoexchangeobjects').The 'infoexchange' entity (Figure 9) contains all the possible combinations among the other three prerequisites, in which each combination can be related to a variety of objects, i.e. for the same purpose, milestone, and actors involved, many are the that should include different level of information need.To correlate the combinations of prerequisites with the possible objects, the 'infoexchangeobjects' entity (Figure 9) was added.From this entity, individual requirements on geometrical information, alphanumerical information and documentation can be assessed through a one-to-one relationship.The use of a database assists in the definition of the combined level of information need making it easy to consult the requirements per purpose and compare requirements among all of them automatically.In addition, using databases allows for future integrations with FM systems.Considering there are only two actors (AP and DT) involved in the appointment and a unique delivery milestone (Handover), the final EIR is a collection of the information requirements per object for the combination of the ten purposes.Each aspect of the object's level of information need contains the most extensive requirement among those for the same aspect.The following paragraphs discuss the results of the combination of purposes per object, being each one dedicated to one group of objects.

Architectural and Structural Elements
The requirements for the Geometrical Information are the same for all aspects across all the purposes, except for Appearance.Appearance is Not Applicable for "Real-time Utilization", but a REALISTIC appearance (Table 5) is requested for the remaining ones.Therefore, following the principle of modelling the asset based on the highest requirement per combination of purposes, the elements are requested to be represented with colours equivalent to reality, with no texture.Considering the other aspects of Geometrical Information, all the objects must be threedimensional (3D), represented with the level DETAILED_Arq (Table 4), with no Location requirement, and full parametric behaviour.For the Information Content, there is no need to establish such a combination given that only one purpose requires this aspect and all properties required for it are in the final level of information

Spaces
In this group, the only requirements are for the Dimensionality to be 3D and the presence of the required properties from the Information Content, which are the sum of the properties for all purposes.

Equipment
The Equipment is the objects' group encompassing the highest variability of the level of information need.
Analysing the subgroup Monitoring Equipment, the assets are represented in a three-dimensional form since this is the unanimous requirement among all the purposes.The subgroup has fully requested Parametric Behaviour since this is required for all purposes except Space Management.The Appearance aspect follows the highest requirement (REALISTIC).For the Detail aspect, the objects of the subgroup are required to have the level DETAILED_Eq, with simplified form and volume but presenting the operation and maintenance spaces around it, as required by the "Asset Management" purpose.
For subgroup Kitchen Equipment, considering the Geometrical Information the assets are 3D since this is the requirement for all purposes.The Appearance and Parametric Behaviour are REALISTIC and fully requested, respectively, since this is the highest requirement for both aspects when combining all the purposes, except for "Space Management" and "Asset Tracking" for they are "Not Applicable".For the Detail aspect, the objects have the same requirements as the previous subgroup.
In the Alphanumeric Information, for the two subgroups (Monitoring Equipment and Kitchen Equipment), the list of properties is the union of all properties required, for all purposes, with no duplication.Most purposes have the Documentation aspect set as "Not Applicable", but since the "Asset Maintenance" purpose requires it, the documentation is requested.

Reference information
As the last step considered on this EIR (step 2.3), the AP decided upon the reference information the DT could access to develop its roles within the information management process.The documentation available for consultation by the DT included .dwgfiles with 2D architectural floor plans and structural design projects, a point cloud of the building, and videos and photos as a reference for the geometrical representation of the objects.For the equipment, a summary of the Kitchen Equipment information and technical specifications of the Monitoring Equipment were also provided as pdf documents to support the completion of their properties' values.

INFORMATION PLANNING AND PRODUCTION
Activities developed in this section correspond to Activity A5 (mobilization, Figure 8), Activity A6 (production of information, in Figure 8) and Activity A7 (information model acceptance, Figure 8).All the section was under the responsibility of the Delivery Team (DT).The chosen authoring software (Revit) automatically attributes default sets of built-in alphanumerical properties to their objects.Therefore, some of these properties may encompass one required in the level of information need, e.g.Revit attributes the property "Area" to space elements which are equivalent to the "NetFloorArea" property required by the AP.As a consequence, the DT needed to analyse the properties from both sources and eliminate from the properties to add the ones considered equivalent to the built-in ones.The properties' source hierarchy was established in the production methods and procedures (Table 2 in section 4.1.2).
Considering the properties built-in within the authoring software and excepting those equivalents to the requested ones, the remaining built-in properties have no value to be fulfilled, meaning they would have to be deleted or would be left empty.This was not foreseen in section 4.1.2since this is a particular implication of the authoring software chosen.Since OBOS (NATSPEC BIM, 2018) and BOS (NBS, 2019) manuals indicate that no built-in property should be deleted from the authoring software since it may seem necessary for built-in operations, the other option is to leave empty properties.Therefore, for the built-in properties that are not equivalent to the requested ones, the properties fields were decided to be left blank instead of being deleted.Since the authoring software does not export empty alphanumerical properties to IFC, this decision will not compromise the model exportation according to the level of information need, which would not include the mentioned properties, but would maintain them inside the authoring file.
5.1.2Review of information and shared resources (Step 6.1) and information generation (Step 6. 2) The sources of information for modelling the architecture, structure and spaces were initially the floor plans, followed by a comparison and adjustment using a point cloud, photos, and videos.The technical specification documents provided the geometrical and alphanumerical information for modelling the objects for the kitchen equipment and monitoring equipment subgroups.The information semodel of the canteen was developed (Figure 10) using Autodesk Revit 2021 as authoring software and following the indications of the information standard, production methods and procedures.Later, the information model was exported following the IFC4 ADD2 TC1 version, being it the newest regulated one (BuildingSMART, 2021b,a).

Information model acceptance (Activity A7)
The verification and validation are different processes foreseen in EN 17412-1 (CEN, 2020).As a combination of steps 6.3 to 6.6 (Figure 7) and 7.1 and 7.2 (Figure 8) from the ISO 19650-2 (ISO, 2018b), the generated information model goes through a verification process to ensure that the Information Containers meet the level of information need requirements.For the Alphanumerical Information, the verification process was partially automated.It included a visual and individual comparison between the level of information need and the exported file using the Solibri Office version 9.12.10.On the other hand, verifying the Geometrical Information was somewhat subjective since there was no use of automated software, depending entirely on human visual analysis and with the verification being done by the same person responsible for the information model's development, making the process not ideal.
The validation process was not performed in this research.However, the exported file was used as the primary source of information in a business intelligence platform (Power BI) to verify the use of the information model for the intended purposes.A sample Asset Maintenance interactive dashboard was created to visualise the Equipment data, presenting their total number, localisation, the properties associated with each, and perform a warranty deadline analysis.
Figure 11 shows an overview of the dashboard created.The report shows the number of spaces, assets, and asset types in the information model together with a three-dimensional representation, allowing user interactions, such as elements hiding, localisation of assets and building sectioning.In addition, the manager can consult property values depending on the selected equipment, using their names or inventory numbers.The report shows the proportion of assets per group and their percentage by type.Additionally, each type's equipment quantity per floor is presented as a table.
A warranty deadline date analysis was simulated using warranty expiration dates inserted in the information model inside the WarrantyEndDate property.Thus, the dashboard displays the list of assets with respective inventory codes, localisation in the building, expiration dates of warranty, and a status message about the validity of their warranty.In this analysis, the assets that had the neutral value (1900-12-31T23:59:59') in the WarrantyEndDate property, as indicated by the production methods and procedures (Table 2 in section 4.1.2),received the status of "No Warranty" since those neutral values represent there is no available information for the property and, in that case, it is understood there is no warranty associated to the asset.The remaining assets received either an "Active Warranty" or "Expired Warranty" status, depending upon their defined warranty end dates.
Figure 11: FM dashboard in Power BI.

CONCLUSIONS
This work presented the development of information requirements following the ISO 19650 series and the EN 17412 to fill the research gap in detailed guidance for applying the recent normalization for information management processes using building information modelling (BIM).The final results were OIR, AIR and EIR developed for the operational phase of an existing university canteen (Canteen of Azurém of UMinho in Portugal).Within the EIR, the focus was defining precisely the level of information need for the objects of the canteen following the guidance of the EN 17412-1 (CEN, 2020).The work presented a simplified information management framework based on the one presented in ISO 19650-3 (ISO, 2020a), which served as a guide for the whole process.Finally, the information requirements informed the development of the information model for the case study.The final information model was exported as following the IFC schema (IFC4 ADD2 TC1), verified by visual comparison with the EIR and by its use as the primary source of information for FM analyses simulation in a business intelligence platform.
The ISO 19650 series was proved to help the understanding of the actors involved in a project implementing BIM and the role of those actors, presenting a detailed information management process to be followed.In addition, the European Standard EN 17412-1 allowed a lean process based on well-defined steps, concepts, and guidelines.The purpose-driven perspective from the ISO series and the European Standard proved to be quite helpful since this thread of thought assisted the decision-making process regarding the relevance of requiring one or another level of complexity for each type of information.On the other hand, in the case of the level of information need definition, the purpose-driven perspective adds the step of analysing the final set of requirements for different purposes at the same information delivery milestone for the same asset to combine the final set of requirements.
Besides the standards, it was noted that the extent of the scope of the IFC schema assisted the development of the requirements since it includes definitions that encompass diverse AECO industry topics, presenting pre-defined properties and groups of properties for different purposes.Moreover, using open formats minimises interoperability issues and implies the requirements defined can be replicated independently of software houses.
It is relevant to acknowledge the value of the work in the context of the strategic implementation of BIM-FM.For the current state of the art on the subject, the article fits the gap of studies covering the process of BIM following the ISO 19650 series for FM purposes.The developed work explained the steps of the procedure, summarized the main path to take, always considered the applicable standardization, and commented on the possible challenges to be faced.Therefore, the work construction allows it to be consulted as an example for owners and managers aiming at developing information requirements.Any facility manager can adapt its content to meet their business interests, generating useful requirements for effective BIM-FM performance and reproducing the available information requirements, including the database structure for the level of information need.Future research efforts could focus on exploring the real cases of adopting ISO 19650 series and EN 17412 standards for operating newly constructed buildings, as well as expand the definition of the standard-based requirements for other asset types beyond what is defined in this article.

Figure 1 :
Figure 1: Example of parties and teams involved in the operational phase of a facility and their relationship.

Figure 9 :
Figure 9: Structure of a relational database using SQL to contain the level of information need.

Figure 10 :
Figure 10: 3D view of the canteen in the authoring software.

Table 1 :
Relation between organization objectives, OIR and AIR.

TABLE 6 :
Part of the required properties for the Sensor type equipment under the "Asset Maintenance" purpose.

Table 7 :
Table of level of information need.